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
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ルート選択ルールへの拡張を提案します。提案された拡張は、ネットワーク全体の安定性を助け、そしてより重要な一個の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ルート選択（セクション9.1.2.2、[BGP]）の最後の2つのステップは、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ルート選択ルールへの拡張を提案する。この観察に基づいています。提案された拡張は、ネットワーク全体の安定性を助け、そしてより重要な一個の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セッションが存在します）。パラレルセッションのピアリングアドレスは、典型的には、（おそらくルート選択の考慮を伴う）ものとしてによって割り当てられるように、（適用する場合）アルゴリズムが既存のルーティングの設定に影響を与える可能性があります。さらに、アルゴリズムを適用しないことによって、ピアリングアドレスの割り当ては、並列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.
次の例に示すように、より重要なことに、提案された拡張は、一つの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識別子としてパス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）および（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.
著者は、最初のアイデアに彼らのコメントのためのヤコフ・レックターとラヴィチャンドラに感謝したいと思います。
[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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]ベイツ、T.、チェン、E.、およびR.チャンドラ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]チェン、E.およびJ.元、 "BGP-4のためのASワイドユニーク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]マクファーソン、D.、ギル、V.、ウォルトン、D.、およびA. Retana、 "ボーダーゲートウェイプロトコル（BGP）永続的なルート発振条件"、RFC 3345、2002年8月。
Author Information
著者の情報
Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
エンケ陳シスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134
EMail: enkechen@cisco.com
メールアドレス：enkechen@cisco.com
Srihari R. Sangli Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
スリアリR.サングリシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134
EMail: rsrihari@cisco.com
メールアドレス：rsrihari@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。