[要約] RFC 5004は、BGPのベストパスの移行を外部から別の外部へ避けるためのガイドラインです。目的は、ネットワークの安定性を向上させ、BGPのパフォーマンスを最適化することです。
Network Working Group E. Chen
Request for Comments: 5004 S. Sangli
Category: Standards Track Cisco Systems
September 2007
Avoid BGP Best Path Transitions from One External to Another
ある外部から別の外部へのBGPベストパス遷移を避けてください
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn.
このドキュメントでは、特定の条件下での外部パス間の不必要な最良のパス遷移を回避するBGPルート選択ルールの拡張を提案します。提案された拡張は、ネットワーク全体の安定性を支援し、さらに重要なことには、1つのBGPスピーカーから複数の外部パスが解約に貢献する特定のBGPルート振動を排除することです。
The last two steps of the BGP route selection (Section 9.1.2.2, [BGP]) involve comparing the BGP identifiers and the peering addresses. The BGP identifier (treated either as an IP address or just an integer [BGP-ID]) for a BGP speaker is allocated by the Autonomous System (AS) to which the speaker belongs. As a result, for a local BGP speaker, the BGP identifier of a route received from an external peer is just a random number. When routes under consideration are from external peers, the result from the last two steps of the route selection is therefore "random" as far as the local BGP speaker is concerned.
BGPルート選択の最後の2つのステップ（セクション9.1.2.2、[BGP]）には、BGP識別子とピアリングアドレスの比較が含まれます。BGPスピーカーのBGP識別子（IPアドレスまたは整数[BGP-ID]として扱われます）は、スピーカーが属する自律システム（AS）によって割り当てられます。その結果、ローカルBGPスピーカーの場合、外部ピアから受け取ったルートのBGP識別子は乱数にすぎません。検討中のルートが外部のピアからのものである場合、ルート選択の最後の2つのステップの結果は、ローカルBGPスピーカーに関する限り「ランダム」です。
It is based on this observation that we propose an extension to the BGP route selection rules that would avoid unnecessary best-path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn.
この観察に基づいて、特定の条件下での外部パス間の不必要なベストパス遷移を避けるBGPルート選択ルールの拡張を提案しています。提案された拡張は、ネットワーク全体の安定性を支援し、さらに重要なことには、1つのBGPスピーカーから複数の外部パスが解約に貢献する特定のBGPルート振動を排除することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Consider the case in which the existing best path A is from an external peer, and another external path B is then selected as the new best path by the route selection algorithm described in [BGP]. When comparing all the paths in route selection, if neither Path A nor Path B is eliminated by the route selection algorithm prior to Step f) -- BGP identifier comparison (Section 9.1.2.2, [BGP]) -- we propose that the existing best path (Path A) be kept as the best path (thus avoiding switching the best path to Path B).
既存の最良のパスAが外部ピアからである場合を検討し、別の外部パスBが[BGP]で説明されているルート選択アルゴリズムによる新しい最良のパスとして選択されます。ルート選択のすべてのパスを比較する場合、パスAもパスBもステップFの前にルート選択アルゴリズムによって排除されない場合、BGP識別子比較（セクション9.1.2.2、[BGP]） - 既存のものが既存のものを提案します最良のパス（パスa）は、最良のパスとして保持されます（したがって、パスbへの最適なパスの切り替えを避けます）。
This algorithm SHOULD NOT be applied when either path is from a BGP Confederation peer.
このアルゴリズムは、どちらのパスがBGP連合ピアからのものである場合、適用しないでください。
In addition, the algorithm SHOULD NOT be applied when both paths are from peers with an identical BGP identifier (i.e., there exist parallel BGP sessions between two BGP speakers). As the peering addresses for the parallel sessions are typically allocated by one AS (possibly with route selection considerations), the algorithm (if applied) could impact the existing routing setup. Furthermore, by not applying the algorithm, the allocation of peering addresses would remain as a simple and effective tool in influencing route selection when parallel BGP sessions exist.
さらに、両方のパスが同一のBGP識別子を持つピアからのものである場合、アルゴリズムを適用しないでください（つまり、2つのBGPスピーカー間に並列BGPセッションが存在します）。並列セッションのピアリングアドレスは通常、AS（おそらくルートの選択に関する考慮事項がある場合）によって割り当てられるため、アルゴリズム（適用されている場合）は既存のルーティングセットアップに影響を与える可能性があります。さらに、アルゴリズムを適用しないことにより、ピアリングアドレスの割り当ては、並列BGPセッションが存在する場合、ルート選択に影響を与えるためのシンプルで効果的なツールとして残ります。
The proposed extension to the BGP route selection rules avoids unnecessary best-path transitions between external paths under certain conditions. Clearly, the extension would help reduce routing and forwarding changes in a network, thus helping the overall network stability.
提案されたBGPルート選択ルールへの拡張は、特定の条件下での外部パス間の不必要なベストパス遷移を回避します。明らかに、この拡張機能は、ネットワークのルーティングと転送の変更を減らし、ネットワーク全体の安定性を支援するのに役立ちます。
More importantly, as shown in the following example, the proposed extension can be used to eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. Note however, that there are permanent BGP route oscillation scenarios [RFC3345] that the mechanism described in this document does not eliminate.
さらに重要なことは、次の例に示すように、提案された拡張を使用して、1つのBGPスピーカーから複数の外部パスが解約に貢献する特定のBGPルート振動を排除することができます。ただし、このドキュメントで説明されているメカニズムが排除しないという永続的なBGPルート振動シナリオ[RFC3345]があることに注意してください。
Consider the example in Figure 1 where
図1の例をどこで考えてください
o R1, R2, R3, and R4 belong to one AS. o R1 is a route reflector with R3 as its client. o R2 is a route reflector with R4 as its client. o The IGP metrics are as listed. o External paths (a), (b), and (c) are as described in Figure 2.
o R1、R2、R3、およびR4はASに属します。O R1は、クライアントとしてR3を含むルートリフレクターです。O R2は、クライアントとしてR4を含むルートリフレクターです。o IGPメトリックはリストされています。o外部パス（a）、（b）、および（c）は、図2に記載されています。
+----+ 40 +----+
| R1 |--------------| R2 |
+----+ +----+
| |
| |
| 10 | 10
| |
| |
+----+ +----+
| R3 | | R4 |
+----+ +----+
/ \ |
/ \ |
(a) (b) (c)
Figure 1
図1
Path AS MED Identifier a 1 0 2 b 2 20 1 c 2 10 5
Med Identifier A 1 0 2 B 2 20 1 C 2 10 5としてのパス
Figure 2
図2
Due to the interaction of the route reflection [BGP-RR] and the MULTI_EXIT_DISC (MED) attribute, the best path on R1 keeps churning between (a) and (c), and the best path on R3 keeps churning between (a) and (b).
ルート反射[BGP-RR]とMulti_Exit_Disc（MED）属性の相互作用により、R1の最適なパスは（a）と（c）の間を変え続け、R3の最良のパスは（a）と（a）と（a）と（（b）。
With the proposed algorithm, R3 would not switch the best path from (a) to (b) even after R1 withdraws (c) toward its clients, and that is enough to stop the route oscillation.
提案されたアルゴリズムでは、R3はR1が（c）をクライアントに撤回した後でも、（a）から（b）に最適なパスを切り替えません。これは、ルート振動を停止するのに十分です。
Although this type of route oscillation can also be eliminated by other route reflection enhancements being developed, the proposed algorithm is extremely simple and can be implemented and deployed immediately without introducing any backward compatibility issues.
このタイプのルート振動は、開発されている他のルート反射強化によっても排除できますが、提案されたアルゴリズムは非常に簡単であり、後方互換性の問題を導入することなく、すぐに実装および展開できます。
The proposed algorithm is backward-compatible, and can be deployed on a per-BGP-speaker basis. The deployment of the algorithm is highly recommended on a BGP speaker with multiple external BGP peers (especially the ones connecting to an inter-exchange point).
提案されたアルゴリズムは後方互換性があり、BGPスピーカーごとに展開できます。アルゴリズムの展開は、複数の外部BGPピア（特に交換間ポイントに接続するもの）を持つBGPスピーカーに強く推奨されます。
Compared to the existing behavior, the proposed algorithm may introduce some "non-determinism" in the BGP route selection -- although one can argue that the BGP Identifier comparison in the existing route selection has already introduced some "randomness" as described in the introduction section. Such "non-determinism" has not been shown to be detrimental in practice and can be completely eliminated by using the existing mechanisms (such as setting LOCAL_PREF or MED) if so desired.
既存の動作と比較して、提案されたアルゴリズムはBGPルートの選択に「非決定的」を導入する可能性がありますが、既存のルート選択におけるBGP識別子の比較は、紹介で説明されているようにすでに「ランダム性」を導入していると主張することができます。セクション。このような「非決定的」は、実際には有害であることが示されておらず、必要に応じて既存のメカニズム（Local_PrefやMEDの設定など）を使用して完全に排除できます。
This extension does not introduce any security issues.
この拡張機能は、セキュリティの問題を導入しません。
The idea presented was inspired by a route oscillation case observed in the BBN/Genuity network in 1998. The algorithm was also implemented and deployed at that time.
提示されたアイデアは、1998年にBBN/Genuityネットワークで観察されたルート振動ケースに触発されました。その時点でアルゴリズムも実装および展開されました。
The authors would like to thank Yakov Rekhter and Ravi Chandra for their comments on the initial idea.
著者は、Yakov RekhterとRavi Chandraに最初のアイデアについてのコメントに感謝したいと思います。
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、Ed。、Li、T.、Ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[BGP-RR] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[BGP-RR] Bates、T.、Chen、E。、およびR. Chandra、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[BGP-ID] Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for BGP-4", Work in Progress, November 2006.
[BGP-ID] Chen、E。およびJ. Yuan、「BGP-4の幅広いBGP識別子」、2006年11月、進行中の作業。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345] McPherson、D.、Gill、V.、Walton、D.、およびA. Retana、「Border Gateway Protocol（BGP）持続ルート振動条件」、RFC 3345、2002年8月。
Author Information
著者情報
Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
Enke Chen Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134
EMail: enkechen@cisco.com
Srihari R. Sangli Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
Srihari R. Sangli Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134
EMail: rsrihari@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。