[要約] RFC 6774は、異なるBGPパスの配布に関するガイドラインであり、BGPルーターの動作を改善するための方法を提供しています。目的は、ネットワークの冗長性と可用性を向上させ、トラフィックの最適な経路選択を可能にすることです。
Internet Engineering Task Force (IETF) R. Raszuk, Ed.
Request for Comments: 6774 NTT MCL
Category: Informational R. Fernando
ISSN: 2070-1721 K. Patel
Cisco Systems
D. McPherson
Verisign
K. Kumaki
KDDI Corporation
November 2012
Distribution of Diverse BGP Paths
多様なBGPパスの配布
Abstract
概要
The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.
BGP4プロトコルは、各プレフィックスの単一の最適パスの選択と伝播を指定します。今日定義され、広く展開されているように、BGPにはスピーカー間の最適パスとは見なされない代替パスを配布するメカニズムがありません。この動作は、新しいアプリケーションやサービスにとって多くの欠点をもたらします。
The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.
このドキュメントの主な目的は、ルートリフレクタとそのクライアントの間に新しいセッションを追加するだけで、N番目の最適パスを分散できることを確認することです。このドキュメントでは、最適なパスだけでなく、より多くのパスの配布を可能にする既存のソリューションと提案されたアイデアを比較します。
This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge (PE) routers acting as route reflector clients.
この提案では、BGPプロトコル定義への変更は指定されていません。ルートリフレクタクライアントとして機能するプロバイダーエッジ（PE）ルータのソフトウェアアップグレードは必要ありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6774.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6774で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. History .........................................................3
2.1. BGP Add-Paths Proposal .....................................3
3. Goals ...........................................................5
4. Multi-Plane Route Reflection ....................................6
4.1. Co-located Best- and Backup-Path RRs .......................8
4.2. Randomly Located Best- and Backup-Path RRs ................10
4.3. Multi-Plane Route Servers for Internet Exchanges ..........12
5. Discussion on Current Models of IBGP Route Distribution ........13
5.1. Full Mesh .................................................13
5.2. Confederations ............................................14
5.3. Route Reflectors ..........................................15
6. Deployment Considerations ......................................15
7. Summary of Benefits ............................................17
8. Applications ...................................................18
9. Security Considerations ........................................19
10. Contributors ..................................................19
11. Acknowledgments ...............................................20
12. References ....................................................20
12.1. Normative References ....................................20
12.2. Informative References ..................................20
The current BGP4 protocol specification [RFC4271] allows for the selection and propagation of only one best path for each prefix. As defined today, the BGP protocol has no mechanism to distribute paths other than best path between its speakers. This behavior results in a number of problems in the deployment of new applications and services.
現在のBGP4プロトコル仕様[RFC4271]では、各プレフィックスに対して1つの最適パスのみを選択および伝播できます。今日定義されているように、BGPプロトコルには、スピーカー間でベストパス以外のパスを配布するメカニズムがありません。この動作により、新しいアプリケーションとサービスのデプロイメントで多くの問題が発生します。
This document presents a mechanism for solving the problem based on the conceptual creation of parallel route-reflector planes. It also compares existing solutions and proposes ideas that enable distribution of more paths than just the best path. The parallel route-reflector planes solution brings very significant benefits at a negligible capex and opex deployment price as compared to the alternative techniques (full BGP mesh or add-paths [ADD-PATHS]) and is being considered by a number of network operators for deployment in their networks.
このドキュメントでは、平行ルートリフレクタプレーンの概念的な作成に基づいて問題を解決するメカニズムを紹介します。また、既存のソリューションを比較し、最適なパスだけでなく、より多くのパスを配布できるアイデアを提案します。パラレルルートリフレクタプレーンソリューションは、代替技術（完全なBGPメッシュまたは追加パス[ADD-PATHS]）と比較して、ごくわずかな設備投資と運用コストの導入価格で非常に大きな利点をもたらし、多くのネットワークオペレーターによって検討されています。ネットワークへの展開。
This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers, nor does it need network-wide upgrades. The only upgrade required is the new functionality on the new or current route reflectors.
この提案では、BGPプロトコル定義への変更は指定されていません。プロバイダーエッジまたはコアルーターへのアップグレードも、ネットワーク全体のアップグレードも必要ありません。必要な唯一のアップグレードは、新規または現在のルートリフレクタの新機能です。
The need to disseminate more paths than just the best path is primarily driven by three issues. The first is the problem of BGP oscillations [RFC3345]. The second is the desire for faster reachability restoration in the event of failure of the network link or network element. The third is a need to enhance BGP load-balancing capabilities. These issues have led to the proposal of BGP add-paths [ADD-PATHS].
最良のパスだけでなく、より多くのパスを普及させる必要性は、主に3つの問題によって引き起こされます。最初は、BGP振動の問題です[RFC3345]。 2つ目は、ネットワークリンクまたはネットワーク要素に障害が発生した場合に、到達可能性をより迅速に回復することです。 3つ目は、BGPロードバランシング機能を強化する必要があります。これらの問題により、BGP add-paths [ADD-PATHS]が提案されました。
As it has been proven that distribution of only the best path of a route is not sufficient to meet the needs of the continuously growing number of services carried over BGP, the add-paths proposal was submitted in 2002 to enable BGP to distribute more than one path. This is achieved by including an additional four-octet value called the "Path Identifier" as a part of the Network Layer Reachability Information (NLRI).
ルートの最良のパスだけを配信するだけでは、BGPを介して継続的に増加するサービス数のニーズを満たすには不十分であることが証明されているため、BGPが複数のパスを配信できるようにするために、2002年に追加パスの提案が提出されました。道。これは、「パス識別子」と呼ばれる追加の4オクテット値をネットワーク層到達可能性情報（NLRI）の一部として含めることによって実現されます。
The implication of this change on a BGP implementation is that it must now maintain a per-path, instead of per-prefix, peer advertisement state to track to which of the peers a given path was advertised. This new requirement comes with its own memory and processing cost.
この変更のBGP実装への影響は、特定のパスがアドバタイズされたピアを追跡するために、プレフィックスごとではなくパスごとのピアアドバタイズメント状態を維持する必要があることです。この新しい要件には、独自のメモリと処理コストが伴います。
An important observation is that distribution of more than one best path by the Autonomous System Border Routers (ASBRs) with multiple External BGP (EBGP) peers attached where no "next-hop self" is set may result in inconsistent best-path selection within the autonomous system. Therefore, it is also required to attach the possible tiebreakers in the form of a new attribute and propagate those within the domain. The example of such an attribute for the purpose of fast connectivity restoration to address that very case of ASBR injecting multiple external paths into the Internal BGP (IBGP) mesh has been presented and discussed in "Advertisement of Multiple Paths in BGP" [ADD-PATHS]. Based on the additionally propagated information, best-path selection is recommended to be modified to make sure that best-and backup-path selection within the domain stays consistent. More discussion on this particular point is contained in Section 6, "Deployment Considerations". In the proposed solution in this document, we observe that to address most of the applications, just use of the best external advertisement is required. For ASBRs that are peering to multiple upstream domains, setting "next-hop self" is recommended.
重要な観察は、「ネクストホップセルフ」が設定されていない複数の外部BGP（EBGP）ピアが接続された自律システムボーダールーター（ASBR）による複数のベストパスの配布は、自律システム。したがって、可能なタイブレーカーを新しい属性の形式で接続し、それらをドメイン内に伝搬することも必要です。 ASBRが内部BGP（IBGP）メッシュに複数の外部パスを挿入するまさにそのケースに対処するための高速接続の復元を目的としたそのような属性の例は、「BGPでの複数のパスのアドバタイズ」[ADD-PATHS ]。追加で伝達された情報に基づいて、ドメイン内のベストパスとバックアップパスの選択の一貫性を保つために、ベストパスの選択を変更することをお勧めします。この特定のポイントに関する詳細は、6項「配置に関する考慮事項」に含まれています。このドキュメントで提案されているソリューションでは、ほとんどのアプリケーションに対処するには、最適な外部広告を使用するだけでよいことがわかります。複数のアップストリームドメインとピアリングしているASBRの場合は、「next-hop self」を設定することをお勧めします。
The add-paths protocol extensions have to be implemented by all the routers within an Autonomous System (AS) in order for the system to work correctly. Analyzing the benefits or risks associated with partial add-paths deployments remains quite a topic for research. The risk becomes even greater in networks not using some form of edge-to-edge encapsulation.
add-pathsプロトコル拡張は、システムが正しく機能するために、自律システム（AS）内のすべてのルーターによって実装される必要があります。部分的な追加パスの展開に関連する利点またはリスクを分析することは、依然として研究の大きなテーマです。リスクは、何らかの形のエッジ間カプセル化を使用していないネットワークでさらに大きくなります。
The required code modifications can offer the foundation for enhancements, such as the "Fast Connectivity Restoration Using BGP Add-path" [FAST-CONN]. The deployment of such technology in an entire service-provider network requires software, and perhaps sometimes, in the case of End-of-Engineering or End-of-Life equipment, even hardware upgrades. Such an operation may or may not be economically feasible. Even if add-path functionality was available today on all commercial routing equipment and across all vendors, experience indicates that it may easily take years to achieve 100% deployment coverage within any medium or large global network.
必要なコード変更は、「BGP Add-pathを使用した高速接続の復元」[FAST-CONN]などの拡張機能の基盤を提供できます。このようなテクノロジーをサービスプロバイダーネットワーク全体に導入するには、ソフトウェアが必要です。場合によっては、エンジニアリング終了またはサポート終了機器の場合は、ハードウェアのアップグレードでさえ必要になることがあります。このような操作は、経済的に実行可能である場合とそうでない場合があります。今日、すべての商用ルーティング機器およびすべてのベンダーでアドパス機能が利用可能であったとしても、経験から、中規模または大規模のグローバルネットワーク内で100％の展開カバレッジを達成するには数年かかる可能性があります。
While it needs to be clearly acknowledged that the add-path mechanism provides the most general way to address the problem of distributing many paths between BGP speakers, this document provides a solution that is much easier to deploy and requires no modification to the BGP protocol where only a few additional paths may be required. The alternative method presented is capable of addressing critical service-provider requirements for disseminating more than a single path across an AS with a significantly lower deployment cost. That, in light of the number of general network scaling concerns documented in RFC 4984 [RFC4984], "Report from the IAB Workshop on Routing and Addressing", may provide a significant advantage.
add-pathメカニズムはBGPスピーカー間で多くのパスを分散する問題に対処する最も一般的な方法を提供することを明確に認識する必要がありますが、このドキュメントでは、展開がはるかに簡単で、BGPプロトコルを変更する必要がないソリューションを提供します。いくつかの追加パスのみが必要な場合があります。提示された代替方法は、AS全体で複数のパスを配布するための重要なサービスプロバイダー要件に対処でき、導入コストを大幅に削減できます。それは、RFC 4984 [RFC4984]に文書化されている一般的なネットワークスケーリングの懸念の数に照らして、「ルーティングとアドレッシングに関するIABワークショップからのレポート」は、大きな利点を提供する可能性があります。
The proposal described in this document is not intended to compete with add-paths. It provides an interim solution until add-paths are standardized and implemented and until support for that function can be deployed across the network.
このドキュメントで説明されている提案は、アドパスと競合することを意図していません。これは、追加パスが標準化および実装され、その機能のサポートをネットワーク全体に展開できるようになるまでの暫定的なソリューションを提供します。
It is presented to network operators as a possible choice and provides those operators who need additional paths today an alternative from the need to transition to a full mesh. The Nth best path describes a set of N paths with different BGP next hops with no implication of ordering or preference among said N paths.
これは可能な選択肢としてネットワークオペレーターに提示され、フルメッシュへの移行の必要性の代わりに、今日追加のパスが必要なオペレーターに代替案を提供します。 Ｎ番目の最良の経路は、前記Ｎ個の経路間の順序付けまたは優先順位の影響を伴わずに、異なるＢＧＰネクストホップを有するＮ個の経路のセットを表す。
It is intended as a way to buy more time, allowing for a smoother and gradual migration where router upgrades will be required for, perhaps, different reasons. It will also allow the time required so that standard RP/RE memory size can easily accommodate the associated overhead with other techniques without any compromises.
これは、より多くの時間を購入する方法として意図されており、おそらく異なる理由でルーターのアップグレードが必要になるスムーズで段階的な移行を可能にします。また、標準のRP / REメモリサイズが妥協することなく他の技術に関連するオーバーヘッドに簡単に対応できるように、必要な時間も許容されます。
The idea contained in the proposal assumes the use of route reflection within the network.
提案に含まれるアイデアは、ネットワーク内でルートリフレクションを使用することを前提としています。
Let's observe today's picture of a simple route-reflected domain:
単純なルートが反映されたドメインの今日の画像を見てみましょう。
ASBR3
***
* *
+------------* *-----------+
| AS1 * * |
| *** |
| |
| |
| |
| RR1 *** RR2 |
| *** * * *** |
|* * * P * * *|
|* * * * * *|
| *** *** *** |
| |
| IBGP |
| |
| |
| *** *** |
| * * * * |
+-----* *---------* *----+
* * * *
*** ***
ASBR1 ASBR2
EBGP
Figure 1: Simple route reflection
Abbreviations used: RR - Route Reflector P - Core router
使用される略語：RR-ルートリフレクターP-コアルーター
Figure 1 shows an AS that is connected via EBGP peering at ASBR1 and ASBR2 to an upstream AS or set of ASes. For a given destination "D", ASBR1 and ASBR2 may have an external path P1 and P2, respectively. The AS network uses two route reflectors, RR1 and RR2, for redundancy reasons. The route reflectors propagate the single BGP best path for each route to all clients. All ASBRs are clients of RR1 and RR2.
図1は、ASBR1およびASBR2でEBGPピアリングを介してアップストリームASまたはASセットに接続されているASを示しています。所与の宛先「Ｄ」について、ＡＳＢＲ１およびＡＳＢＲ２は、それぞれ外部経路Ｐ１およびＰ２を有し得る。 ASネットワークは、冗長性の理由から、RR1とRR2の2つのルートリフレクターを使用します。ルートリフレクタは、各ルートの単一のBGP最適パスをすべてのクライアントに伝播します。すべてのASBRはRR1およびRR2のクライアントです。
Following are the possible cases of the path information that ASBR3 may receive from route reflectors RR1 and RR2:
ASBR3がルートリフレクタRR1およびRR2から受信する可能性があるパス情報の考えられるケースを次に示します。
1. When the best-path tiebreaker is the IGP distance: When paths P1 and P2 are considered to be equally good best-path candidates, the selection will depend on the distance of the path's next hops from the route reflector making the decision. Depending on the positioning of the route reflectors in the IGP topology, they may choose the same best path or a different one. In such a case, ASBR3 may receive either the same path or different paths from each of the route reflectors.
1. 最適パスタイブレーカーがIGP距離である場合：パスP1とP2が同等に最適な最良パス候補であると見なされる場合、選択は、ルートリフレクターからのパスのネクストホップの距離によって異なります。 IGPトポロジでのルートリフレクタの配置に応じて、同じリフレクタを選択するか、別のパスを選択する場合があります。このような場合、ASBR3は各ルートリフレクタから同じパスまたは異なるパスのいずれかを受信します。
2. When the best-path tiebreaker is MULTI_EXIT_DISC (MED) or LOCAL_PREF: In this case, only one path from the preferred exit point ASBR will be available to RRs since the other peering ASBR will consider the IBGP path as best and will not announce (or if already announced will withdraw) its own external path. The exception here is the use of the BGP Best-External proposal [EXT-PATH], which will allow a stated ASBR to still propagate to the RRs on its own external path. Unfortunately, RRs will not be able to distribute it any further to other clients, as only the overall best path will be reflected.
2. 最適パスタイブレーカーがMULTI_EXIT_DISC（MED）またはLOCAL_PREFの場合：この場合、他のピアリングASBRはIBGPパスを最適と見なし、通知しないため、RRは優先出口ポイントASBRからの1つのパスしか使用できません（またはすでに発表されている場合は、撤回します）独自の外部パス。ここでの例外は、BGP Best-External提案[EXT-PATH]の使用です。これにより、指定されたASBRが独自の外部パス上のRRに引き続き伝播できるようになります。残念ながら、全体的な最適パスのみが反映されるため、RRはそれを他のクライアントにそれ以上配信できません。
There is no requirement of path ordering. The "Nth best path" really describes set of N paths with different BGP next hops.
パスの順序付けの要件はありません。 「N番目の最適パス」は、実際には、異なるBGPネクストホップを持つNパスのセットを表します。
The proposed solution is based on the use of additional route reflectors or new functionality enabled on the existing route reflectors that, instead of distributing the best path for each route, will distribute an alternative path other than best. The best-path (main) reflector plane distributes the best path for each route as it does today. The second plane distributes the second best path for each route, and so on. Distribution of N paths for each route can be achieved by using N reflector planes.
提案されたソリューションは、追加のルートリフレクターの使用または既存のルートリフレクターで有効になっている新機能に基づいており、各ルートに最適なパスを配布する代わりに、ベスト以外の代替パスを配布します。ベストパス（メイン）リフレクタプレーンは、今日のように各ルートのベストパスを分配します。 2番目のプレーンは、ルートごとに2番目に最適なパスを配布します。各ルートのN個のパスの分散は、N個のリフレクタープレーンを使用して実現できます。
As diverse-path functionality may be enabled on a per-peer basis, one of the deployment models can be realized to continue advertisement of the overall best path from both route reflectors, while in addition a new session can be provisioned to get an additional path. This will allow the uninterrupted use of the best path, even if one of the RRs goes down, provided that the overall best path is still a valid one.
ピアごとに多様なパス機能を有効にすることができるため、両方のルートリフレクタからの全体的な最適パスのアドバタイズを継続するために、展開モデルの1つを実現しながら、追加のパスを取得するために新しいセッションをプロビジョニングできます。 。これにより、RRの1つがダウンした場合でも、全体的な最適パスが有効なパスである限り、中断のない最適パスの使用が可能になります。
Each plane of the route reflectors is a logical entity and may or may not be co-located with the existing best-path route reflectors. Adding a route-reflector plane to a network may be as easy as enabling a logical router partition, new BGP process, or just a new configuration knob on an existing route reflector and configuring an additional IBGP session from the current clients if required. There are no code changes required on the route-reflector clients for this mechanism to work. It is easy to observe that the installation of one or more additional route-reflector control planes is much cheaper and is easier than upgrading hundreds of route-reflector clients in the entire network to support different BGP protocol encoding.
ルートリフレクタの各プレーンは論理エンティティであり、既存のベストパスルートリフレクタと同じ場所に配置されている場合とされていない場合があります。ネットワークにルートリフレクタープレーンを追加するのは、論理ルーターパーティション、新しいBGPプロセス、または既存のルートリフレクターの新しい構成ノブを有効にし、必要に応じて現在のクライアントから追加のIBGPセッションを構成するのと同じくらい簡単です。このメカニズムを機能させるために、ルートリフレクタクライアントで必要なコードの変更はありません。 1つ以上の追加のルートリフレクタコントロールプレーンのインストールは、ネットワーク全体で数百のルートリフレクタクライアントをアップグレードしてさまざまなBGPプロトコルエンコーディングをサポートするよりもはるかに安価で簡単であることが簡単にわかります。
Diverse-path route reflectors need the new ability to calculate and propagate the Nth best path instead of the overall best path. An implementation is encouraged to enable this new functionality on a per-neighbor basis.
多様なパスのルートリフレクタには、全体的な最適パスではなく、N番目の最適パスを計算して伝播する新しい機能が必要です。実装では、この新しい機能をネイバーごとに有効にすることが推奨されます。
While this is an implementation detail, the code to calculate the Nth best path is also required by other BGP solutions. For example, in the application of fast connectivity restoration, BGP must calculate a backup path for installation into the Routing Information Base (RIB) and Forwarding Information Base (FIB) ahead of the actual failure.
これは実装の詳細ですが、他のBGPソリューションでもN番目の最適パスを計算するコードが必要です。たとえば、高速接続復元のアプリケーションでは、BGPは実際の障害の前にルーティング情報ベース（RIB）および転送情報ベース（FIB）にインストールするためのバックアップパスを計算する必要があります。
To address the problem of external paths not being available to route reflectors due to LOCAL_PREF or MED factors, it is recommended that ASBRs enable [EXT-PATH] functionality in order to always inject their external paths to the route reflectors.
LOCAL_PREFまたはMED要因のためにルートリフレクターが外部パスを利用できないという問題に対処するには、ASBRが[EXT-PATH]機能を有効にして、常に外部パスをルートリフレクターに挿入することをお勧めします。
To simplify the description, let's assume that we only use two route-reflector planes (N=2). When co-located, the additional second-best-path reflectors are connected to the network at the same points from the perspective of the IGP as the existing best-path RRs. Let's also assume that best-external functionality is enabled on all ASBRs.
説明を簡単にするために、2つのルートリフレクタプレーン（N = 2）のみを使用するとします。同じ場所に配置すると、追加の2番目に最適なパスのリフレクターは、IGPの観点から、既存の最適なパスのRRと同じポイントでネットワークに接続されます。また、すべてのASBRで最高の外部機能が有効になっていると仮定します。
ASBR3
***
* *
+------------* *-----------+
| AS1 * * |
| *** |
| |
| RR1 RR2 |
| *** *** |
|* * *** * *|
|* * * * * *|
| *** * P * *** |
|* * * * * *|
|* * *** * *|
| *** *** |
| RR1' IBGP RR2'|
| |
| |
| *** *** |
| * * * * |
+-----* *---------* *----+
* * * *
*** ***
ASBR1 ASBR2
EBGP
EBGP
Figure 2: Co-located Second-Best-Path RR Plane
図2：同じ場所に配置された2番目に最適なパスのRR平面
The following is a list of configuration changes required to enable the second-best-path route-reflector plane:
次に、2番目に最適なルートリフレクタプレーンを有効にするために必要な設定変更のリストを示します。
1. Unless the same RR1/RR2 platform is being used, adding RR1' and RR2' either as the logical or physical new control-plane RRs in the same IGP points as RR1 and RR2, respectively.
1. 同じRR1 / RR2プラットフォームが使用されていない限り、RR1 'およびRR2'を、それぞれRR1およびRR2と同じIGPポイント内の論理または物理的な新しいコントロールプレーンRRとして追加します。
2. Enabling best-external functionality on ASBRs.
2. ASBRで最高の外部機能を有効にします。
3. Enabling RR1' and RR2' for second plane route reflection. Alternatively, instructing existing RR1 and RR2 to calculate the second-best path also.
3. 2番目の平面ルート反射でRR1 'およびRR2'を有効にします。または、既存のRR1およびRR2に2番目に最適なパスを計算するように指示します。
4. Unless one of the existing RRs is set to advertise only diverse path to its current clients, configuring new ASBRs-RR' IBGP sessions.
4. 既存のRRの1つが現在のクライアントに多様なパスのみをアドバタイズするように設定されていない限り、新しいASBR-RRのIBGPセッションを構成します。
The expected behavior is that under any BGP condition, the ASBR3 and P routers will receive both paths P1 and P2 for destination D. The availability of both paths will allow them to implement a number of new services as listed in Section 8 ("Applications").
予想される動作は、任意のBGP条件下で、ASBR3とPのルーターが宛先Dの両方のパスP1とP2を受信することです。両方のパスを使用できるため、セクション8（「アプリケーション」 ）。
As an alternative to fully meshing all RRs and RRs', an operator that has a large number of reflectors deployed today may choose to peer newly introduced RRs' to a hierarchical RR', which would be an IBGP interconnect point within the second plane as well as between planes.
すべてのRRとRRを完全にメッシュ化する代わりに、今日導入されているリフレクターの数が多いオペレーターは、新しく導入されたRRを階層RRにピアリングすることを選択できます。飛行機の間。
One deployment model of this scenario can be achieved by simply upgrading the existing route reflectors without deploying any new logical or physical platforms. Such an upgrade would allow route reflectors to service both peers that have upgraded to add-paths, as well as those peers that cannot be immediately upgraded while at the same time allowing distribution of more than a single best path. The obvious protocol benefit of using existing RRs to distribute towards their clients' best and diverse BGP paths over different IBGP sessions is the automatic assurance that such a client would always get different paths with their next hop being different.
このシナリオの1つの展開モデルは、新しい論理または物理プラットフォームを展開することなく、既存のルートリフレクターをアップグレードするだけで実現できます。このようなアップグレードにより、ルートリフレクタは、add-pathsにアップグレードされた両方のピアと、すぐにアップグレードできず、同時に複数の最適パスの配布を許可したピアにサービスを提供できます。既存のRRを使用して、さまざまなIBGPセッションを介してクライアントの最良の多様なBGPパスに配布することの明らかなプロトコルの利点は、そのようなクライアントが常に異なるパスを取得し、ネクストホップが異なることを自動的に保証することです。
The way to accomplish this would be to create a separate IBGP session for each Nth BGP path. Such a session should be preferably terminated at a different loopback address of the route reflector. At the BGP OPEN stage of each such session, a different bgp_router_id may be used. Correspondingly, the route reflector should also allow its clients to use the same bgp_router_id on each such session.
これを行う方法は、N番目のBGPパスごとに個別のIBGPセッションを作成することです。このようなセッションは、ルートリフレクタの別のループバックアドレスで終了することが望ましいです。このような各セッションのBGP OPENステージでは、異なるbgp_router_idを使用できます。同様に、ルートリフレクタは、クライアントがそのような各セッションで同じbgp_router_idを使用することも許可する必要があります。
Now let's consider a deployment case in which an operator wishes to enable a second RR' plane using only a single additional router in a different network location from his current route reflectors. This model would be of particular use in networks in which some form of end-to-end encapsulation (IP or MPLS) is enabled between provider-edge routers.
次に、オペレーターが現在のルートリフレクターとは別のネットワークロケーションにある1つの追加ルーターのみを使用して2番目のRR 'プレーンを有効にしたい配備ケースを考えてみましょう。このモデルは、プロバイダーエッジルーター間で何らかの形のエンドツーエンドカプセル化（IPまたはMPLS）が有効になっているネットワークで特に役立ちます。
Note that this model of operation assumes that the present best-path route reflectors are only control-plane devices. If the route reflector is in the data-forwarding path, then the implementation must be able to clearly separate the Nth best-path selection from the selection of the paths to be used for data forwarding. The basic premise of this mode of deployment assumes that all reflector planes have the same information to choose from, which includes the same set of BGP paths. It also requires the ability to ignore the step of comparison of the IGP metric to reach the BGP next hop during best-path calculation.
この動作モデルでは、現在のベストパスルートリフレクタはコントロールプレーンデバイスのみであると想定しています。ルートリフレクタがデータ転送パスにある場合、実装では、N番目の最適パスの選択とデータ転送に使用されるパスの選択を明確に区別できる必要があります。この展開モードの基本的な前提は、すべてのリフレクタープレーンに同じ情報があり、同じBGPパスのセットが含まれていることを前提としています。また、最適パスの計算中にBGPネクストホップに到達するために、IGPメトリックの比較のステップを無視する機能も必要です。
ASBR3
***
* *
+------------* *-----------+
| AS1 * * |
| IBGP *** |
| |
| *** |
| * * |
| RR1 * P * RR2 |
| *** * * *** |
|* * *** * *|
|* * * *|
| *** RR' *** |
| *** |
| * * |
| * * |
| *** |
| *** *** |
| * * * * |
+-----* *---------* *----+
* * * *
*** ***
ASBR1 ASBR2
EBGP
EBGP
Figure 3: Experimental Deployment of Second-Best-Path RR Plane
図3：2番目に最適なパスのRR平面の実験的な展開
The following is a list of configuration changes required to enable the second-best-path route reflector RR' as a single platform or to enable one of the existing control-plane RRs for diverse-path functionality:
次に、2番目に最適なパスのルートリフレクタRR 'を単一のプラットフォームとして有効にするか、既存のコントロールプレーンRRの1つを多様なパス機能で有効にするために必要な構成変更のリストを示します。
1. If needed, adding RR' logical or physical as a new route reflector anywhere in the network.
1. 必要に応じて、ネットワークの任意の場所に新しいルートリフレクタとしてRR '論理または物理を追加します。
2. Enabling best-external functionality on ASBRs.
2. ASBRで最高の外部機能を有効にします。
3. Disabling IGP metric check in BGP best path on all route reflectors.
3. すべてのルートリフレクタのBGPベストパスでIGPメトリックチェックを無効にします。
4. Enabling RR' or any of the existing RR for second plane path calculation.
4. 2番目の平面パス計算でRR 'または既存のRRを有効にする。
5. If required, fully meshing newly added RRs' with all the other reflectors in both planes. This condition does not apply if the newly added RR'(s) already have peering to all ASBRs/PEs.
5. 必要に応じて、新しく追加されたRRを両方の平面の他のすべてのリフレクターと完全にメッシュ化します。新しく追加されたRRがすでにすべてのASBR / PEへのピアリングを持っている場合、この条件は適用されません。
6. Configure new BGP sessions between ASBRs and RRs (unless one of the existing RRs is set to advertise only diverse path to its current clients).
6. ASBRとRRの間に新しいBGPセッションを構成します（既存のRRの1つが現在のクライアントに多様なパスのみを通知するように設定されている場合を除く）。
In this scenario, the operator has the flexibility to introduce the new additional route-reflector functionality on any existing or new hardware in the network. Any existing routers that are not already members of the best-path route-reflector plane can be easily configured to serve the second plane either by using a logical/virtual router partition or by having their BGP implementation compliant to this specification.
このシナリオでは、オペレーターはネットワーク内の既存のハードウェアまたは新しいハードウェアに新しい追加のルートリフレクター機能を導入する柔軟性を持っています。まだベストパスルートリフレクタプレーンのメンバーではない既存のルータは、論理/仮想ルータパーティションを使用するか、この仕様に準拠したBGP実装を使用することにより、2番目のプレーンにサービスを提供するように簡単に設定できます。
Even if the IGP metric is not taken into consideration when comparing paths during the best-path calculation, an implementation still has to consider paths with unreachable next hops invalid. It is worth pointing out that some implementations today already allow for configuration that results in no IGP metric comparison during the best-path calculation.
最良パスの計算中にパスを比較するときにIGPメトリックが考慮されない場合でも、実装では、到達不能なネクストホップが無効なパスを考慮する必要があります。今日の一部の実装では、ベストパスの計算中にIGPメトリックの比較が行われない構成がすでに許可されていることを指摘しておく必要があります。
The additional planes of route reflectors do not need to be fully redundant as the primary plane does. If we are preparing for a single network failure event, a failure of a non-backed-up Nth best-path route reflector would not result in a connectivity outage of the actual data plane. The reason is that this would, at most, affect the presence of a backup path (not an active one) on the same parts of the network. If the operator chooses to create the Nth best-path plane redundantly by installing not one, but two or more route reflectors serving each additional plane, the additional robustness will be achieved.
ルートリフレクタの追加のプレーンは、プライマリプレーンのように完全に冗長である必要はありません。単一のネットワーク障害イベントの準備をしている場合、バックアップされていないN番目のベストパスルートリフレクターの障害は、実際のデータプレーンの接続障害にはつながりません。これは、ネットワークの同じ部分にあるバックアップパス（アクティブパスではない）の存在に最大で影響するためです。オペレーターが1つではなく2つ以上のルートリフレクターを追加の平面ごとに提供することにより、N番目のベストパスプレーンを冗長的に作成することを選択した場合、追加の堅牢性が実現されます。
As a result of this solution, ASBR3 and other ASBRs peering to RR' will be receiving the second best path.
このソリューションの結果として、RR 'とピアリングするASBR3および他のASBRは、2番目に最適なパスを受信します。
Similarly to Section 4.1, as an alternative to fully meshing all RRs and diverse path RRs', operators may choose to peer newly introduced RRs' to a hierarchical RR', which would be an IBGP interconnect point between planes.
セクション4.1と同様に、すべてのRRと多様なパスRRを完全にメッシュ化する代わりに、オペレーターは新しく導入されたRRを階層RRにピアリングすることを選択できます。
It is recommended that an implementation advertise the overall best path over the Nth diverse-path session if there is no other BGP path with a different next hop present. This is equivalent to today's case where the client is connected to more than one RR.
別のネクストホップが存在する他のBGPパスが存在しない場合、実装はN番目の多様なパスセッションで全体の最適パスをアドバタイズすることをお勧めします。これは、クライアントが複数のRRに接続されている今日のケースに相当します。
Another group of devices in which the proposed multi-plane architecture may be of particular applicability is the EBGP route servers used at many Internet exchange points.
提案されているマルチプレーンアーキテクチャが特に適用できるデバイスの別のグループは、多くのインターネット交換ポイントで使用されるEBGPルートサーバーです。
In such cases, hundreds of ISPs are interconnected on a common LAN. Instead of having hundreds of direct EBGP sessions on each exchange client, a single peering is created to the transparent route server. The route server can only propagate a single best path. Mandating the upgrade for hundreds of different service providers in order to implement add-path may be much more difficult as compared to asking them to provision one new EBGP session to an Nth best path route server plane. This allows the distribution of more than the single best BGP path from a given route server to such an Internet exchange point (IX) peer.
このような場合、何百ものISPが共通のLANで相互接続されます。各Exchangeクライアントで数百の直接EBGPセッションを使用する代わりに、透過ルートサーバーへの単一のピアリングが作成されます。ルートサーバーは、1つの最適パスのみを伝達できます。 add-pathを実装するために何百もの異なるサービスプロバイダーにアップグレードを要求することは、N番目の最適パスルートサーバープレーンに1つの新しいEBGPセッションをプロビジョニングするように依頼するよりもはるかに難しい場合があります。これにより、特定のルートサーバーからそのようなインターネット交換ポイント（IX）ピアへの1つ以上の最良のBGPパスの配布が可能になります。
The solution proposed in this document fits very well with the requirement of having broader EBGP path diversity among the members of any Internet exchange point.
このドキュメントで提案されているソリューションは、インターネット交換ポイントのメンバー間でより広いEBGPパスダイバーシティを持つという要件に非常によく適合しています。
In today's networks, BGP4 operates as specified in [RFC4271].
今日のネットワークでは、BGP4は[RFC4271]で指定されているように動作します。
There are a number of technology choices for intra-AS BGP route distribution:
AS内BGPルート配信には、いくつかのテクノロジーの選択肢があります。
1. Full mesh
1. フルメッシュ
2. Confederations
2. 連合
3. Route reflectors
3. ルートリフレクター
A full mesh, the most basic IBGP architecture, exists when all BGP speaking routers within the AS peer directly with all other BGP speaking routers within the AS, irrespective of where a given router resides within the AS (e.g., P router, PE router, etc.).
フルメッシュ、最も基本的なIBGPアーキテクチャは、AS内のすべてのBGPスピーキングルーターが、AS内の特定のルーターがどこにあるかに関係なく、AS内の他のすべてのBGPスピーキングルーター（Pルーター、PEルーター、等。）。
While this is the simplest intra-domain path-distribution method, historically, there have been a number of challenges in realizing such an IBGP full mesh in a large-scale network. While some of these challenges are no longer applicable, the following (as well as others) may still apply:
これは最も単純なドメイン内パス配布方法ですが、歴史的には、大規模ネットワークでそのようなIBGPフルメッシュを実現する上で多くの課題がありました。これらの課題の一部は適用されなくなりましたが、以下（および他の課題）が引き続き適用される場合があります。
1. Number of TCP sessions: The number of IBGP sessions on a single router in a full-mesh topology of a large-scale service provider can easily reach hundreds. Such numbers could be a concern on hardware and software used in the late 70s, 80s, and 90s. Today, customer requirements for the number of BGP sessions per box are reaching thousands. This is already an order of magnitude more than the potential number of IBGP sessions. Advancements in the hardware and software used in production routers means that running a full mesh of IBGP sessions should not be dismissed due to the resulting number of TCP sessions alone.
1. TCPセッションの数：大規模サービスプロバイダーのフルメッシュトポロジの単一ルーター上のIBGPセッションの数は、数百に達する可能性があります。このような数値は、70年代後半、80年代、および90年代に使用されたハードウェアおよびソフトウェアの問題である可能性があります。現在、ボックスあたりのBGPセッション数に対する顧客の要件は数千に達しています。これは、IBGPセッションの潜在的な数よりもすでに1桁多いです。本番ルーターで使用されているハードウェアとソフトウェアの進歩により、TCPセッションの数だけが結果として生じるため、IBGPセッションのフルメッシュの実行を終了するべきではありません。
2. Provisioning: When operating and troubleshooting large networks, one of the topmost requirements is to keep the design as simple as possible. When the autonomous system's network is composed of hundreds of nodes, it becomes very difficult to manually provision a full mesh of IBGP sessions. Adding or removing a router requires reconfiguration of all other routers in the AS. While this is a real concern today, there is already work in progress in the IETF to define IBGP peering automation through an IBGP Auto Discovery mechanism [AUTO-MESH].
2. プロビジョニング：大規模ネットワークの運用とトラブルシューティングを行う場合、最も重要な要件の1つは、設計をできるだけシンプルに保つことです。自律システムのネットワークが数百のノードで構成されている場合、IBGPセッションのフルメッシュを手動でプロビジョニングすることは非常に困難になります。ルーターを追加または削除するには、AS内の他のすべてのルーターを再構成する必要があります。これは本当の関心事ですが、IETFでは、IBGP自動検出メカニズム[AUTO-MESH]によるIBGPピアリングの自動化を定義する作業がすでに進行中です。
3. Number of paths: Another concern when deploying a full IBGP mesh is the number of BGP paths for each route that have to be stored at every node. This number is very tightly related to the number of external peerings of an AS, the use of LOCAL_PREF or MED techniques, and the presence of best-external [EXT-PATH] advertisement configuration. If we make a rough assumption that the BGP4-path data structure consumes about 80-100 bytes, the resulting control-plane memory requirement for 500,000 IPv4 routes with one additional external path is 38-48 MB, while for 1 million IPv4 routes, it grows linearly to 76-95 MB. It is not possible to reach a general conclusion if this condition is negligible or if it is a show stopper for a full-mesh deployment without direct reference to a given network.
3. パスの数：フルIBGPメッシュを展開する際のもう1つの問題は、すべてのノードに格納する必要がある各ルートのBGPパスの数です。この数は、ASの外部ピアリングの数、LOCAL_PREFまたはMED技術の使用、およびベスト外部[EXT-PATH]アドバタイズメント構成の存在と密接に関連しています。 BGP4パスのデータ構造が約80〜100バイトを消費すると大まかに想定すると、追加の外部パスが1つある500,000のIPv4ルートに必要なコントロールプレーンのメモリ要件は38〜48 MBですが、100万のIPv4ルートでは、 76〜95 MBまで直線的に増加します。この状態が無視できる場合、または特定のネットワークを直接参照せずにフルメッシュ展開のショーストッパーである場合、一般的な結論に到達することはできません。
To summarize, a full-mesh IBGP peering can offer natural dissemination of multiple external paths among BGP speakers. When realized with the help of IBGP Auto Discovery peering automation, this seems like a viable deployment, especially in medium- and small-scale networks.
要約すると、フルメッシュIBGPピアリングは、BGPスピーカー間の複数の外部パスの自然な普及を提供できます。 IBGP自動検出ピアリング自動化の助けを借りて実現すると、これは特に中小規模のネットワークでは実行可能な展開のように見えます。
For the purpose of this document, let's observe that confederations [RFC5065] can be viewed as a hierarchical full-mesh model.
このドキュメントの目的のために、連合[RFC5065]は階層的なフルメッシュモデルと見なすことができることに注意してください。
Within each sub-AS, BGP speakers are fully meshed, and as discussed in Section 2.1, all full-mesh characteristics (number of TCP sessions, provisioning, and potential concern over number of paths still apply in the sub-AS scale).
各サブAS内で、BGPスピーカーは完全にメッシュ化されており、セクション2.1で説明したように、すべてのフルメッシュ特性（TCPセッションの数、プロビジョニング、およびパスの数に対する潜在的な懸念は、依然としてサブASスケールで適用されます）。
In addition to the direct peering of all BGP speakers within each sub-AS, all sub-AS border routers must also be fully meshed with each other. Sub-AS border routers configured with best-external functionality can inject additional (diverse) paths within a sub-AS.
各サブAS内のすべてのBGPスピーカーの直接ピアリングに加えて、すべてのサブAS境界ルーターも互いに完全にメッシュ化されている必要があります。最高の外部機能で構成されたサブAS境界ルーターは、サブAS内に追加の（多様な）パスを挿入できます。
To summarize, it is technically sound to use confederations with the combination of best-external to achieve distribution of more than a single best path per route in a large autonomous systems.
要約すると、大規模な自律システムでルートごとに複数の最適なパスの分散を実現するために、連合をbest-externalの組み合わせと組み合わせて使用することは技術的に適切です。
In topologies where route reflectors are deployed within the confederation sub-ASes, the technique described here applies.
ルートリフレクタがコンフェデレーションサブAS内に展開されているトポロジでは、ここで説明する手法が適用されます。
The main motivation behind the use of route reflectors [RFC4456] is the avoidance of the full-mesh session management problem described above. Route reflectors, for good or for bad, are the most common solution today for interconnecting BGP speakers within an internal routing domain.
ルートリフレクタ[RFC4456]の使用の背後にある主な動機は、上記のフルメッシュセッション管理の問題を回避することです。ルートリフレクターは、良いか悪いかを問わず、内部ルーティングドメイン内でBGPスピーカーを相互接続するための今日最も一般的なソリューションです。
Route-reflector peerings follow the advertisement rules defined by the BGP4 protocol. As a result, only a single best path per prefix is sent to client BGP peers. This is the main reason many current networks are exposed to a phenomenon called BGP path starvation, which essentially results in the inability to deliver a number of applications discussed later.
ルートリフレクタピアリングは、BGP4プロトコルで定義された通知ルールに従います。その結果、プレフィックスごとに1つの最適パスのみがクライアントBGPピアに送信されます。これが、現在の多くのネットワークがBGPパススタベーションと呼ばれる現象にさらされている主な理由です。これにより、後で説明する多くのアプリケーションを提供できなくなります。
When interconnecting BGP speakers between domains, the route reflection equivalent is popularly called the "Route Server" and is globally deployed today in many Internet exchange points.
ドメイン間でBGPスピーカーを相互接続する場合、同等のルートリフレクションは一般に「ルートサーバー」と呼ばれ、今日多くのインターネット交換ポイントでグローバルに展開されています。
Distribution of the diverse-BGP-paths proposal allows the dissemination of more paths than just the best path to the route-reflector or route-server clients of today's BGP4 implementations. As a deployment recommendation, it needs to be mentioned that fast connectivity restoration as well as a majority of intra-domain BGP-level load balancing needs can be accommodated with only two paths (overall best and second best). Therefore, as a deployment recommendation, this document suggests use of N=2 with diverse-path.
多様なBGPパスの提案の配布により、今日のBGP4実装のルートリフレクタまたはルートサーバークライアントへの最適なパスだけではなく、より多くのパスを配布できます。展開の推奨事項として、高速接続の復元とドメイン内のBGPレベルのロードバランシングのニーズの大部分は、2つのパス（全体として最適、2番目に最適）で対応できることに言及する必要があります。したがって、このドキュメントでは、展開の推奨事項として、多様なパスでN = 2を使用することを推奨しています。
From the client's point of view, receiving additional paths via separate IBGP sessions terminated at the new route-reflector plane is functionally equivalent to constructing a full-mesh peering without the problems such a full mesh would come with, as discussed in earlier section.
クライアントの観点から見ると、新しいルートリフレクタプレーンで終了した個別のIBGPセッションを介して追加のパスを受信することは、前のセクションで説明したように、フルメッシュで発生する問題なしにフルメッシュピアリングを構築することと機能的に同等です。
By precisely defining the number of reflector planes, network operators have full control over the number of redundant paths in the network. This number can be defined to address the needs of the service(s) being deployed.
リフレクタープレーンの数を正確に定義することにより、ネットワークオペレーターはネットワーク内の冗長パスの数を完全に制御できます。この数は、デプロイされるサービスのニーズに対応するように定義できます。
The Nth-plane route reflectors should act as control-plane network entities. While they can be provisioned on the current production routers, selected Nth-best BGP paths should not be used directly in the date plane with the exception of such paths being BGP multipath eligible and such functionality is enabled. Regarding RRs being in the data plane unless multipath is enabled, the second best path is expected to be a backup path and should be installed as such into the local RIB/FIB.
N番目のプレーンルートリフレクタは、コントロールプレーンネットワークエンティティとして機能する必要があります。それらは現在の実稼働ルーターでプロビジョニングできますが、選択されたN番目に最適なBGPパスは、日付平面で直接使用しないでください。マルチパスが有効になっていない限り、データプレーンにRRがある場合、2番目に最適なパスはバックアップパスであると予想され、ローカルRIB / FIBにそのようにインストールする必要があります。
The use of the term "planes" in this document is more of a conceptual nature. In practice, all paths are still kept in the single table where normal best path is calculated. This means that tools like the looking glass should not observe any changes or impact when diverse-path has been enabled.
このドキュメントでの「プレーン」という用語の使用は、概念的な性質のものです。実際には、すべてのパスは、通常の最適パスが計算される単一のテーブルに保持されます。これは、多様なパスが有効になっている場合、鏡のようなツールは変更や影響を観察しないことを意味します。
The proposed architecture deployed along with the BGP best-external functionality covers all three cases where the classic BGP route-reflection paradigm would fail to distribute alternate (diverse) paths. These are
BGPの最良外部機能とともに導入された提案されたアーキテクチャは、従来のBGPルートリフレクションパラダイムが代替（多様な）パスの配布に失敗する3つのケースすべてをカバーします。これらは
1. ASBRs advertising their single best-external paths with no LOCAL_PREF or MED present.
1. ASBRは、LOCAL_PREFまたはMEDが存在せずに単一の最良外部パスをアドバタイズします。
2. ASBRs advertising their single best-external paths with LOCAL_PREF or MED present and with BGP best-external functionality enabled.
2. ASBRは、LOCAL_PREFまたはMEDが存在し、BGPベスト外部機能が有効になっている単一のベスト外部パスをアドバタイズします。
3. ASBRs with multiple external paths.
3. 複数の外部パスを持つASBR。
This section focuses on discussion of case 3 above in more detail. This describes the scenario of a single ASBR connected to multiple EBGP peers. In practice, this peering scenario is quite common. It is mostly due to the geographic location of EBGP peers and the diversity of those peers (for example, peering to multiple tier-1 ISPs, etc.). It is not designed for failure-recovery scenarios, as single failure of the ASBR would simultaneously result in loss of connectivity to all of the peers. In most medium and large geographically distributed networks, there is always another ASBR or multiple ASBRs providing peering backups, typically in other geographically diverse locations in the network.
このセクションでは、上記のケース3について詳しく説明します。これは、複数のEBGPピアに接続された単一のASBRのシナリオを示しています。実際には、このピアリングのシナリオは非常に一般的です。これは主に、EBGPピアの地理的位置とそれらのピアの多様性によるものです（たとえば、複数のTier-1 ISPへのピアリングなど）。 ASBRの単一の障害が同時にすべてのピアへの接続を失う結果となるため、障害回復シナリオ用に設計されていません。ほとんどの中規模および大規模の地理的に分散したネットワークでは、通常、ネットワーク内の他の地理的に異なる場所に、ピアリングバックアップを提供する別のASBRまたは複数のASBRが常に存在します。
When an operator uses ASBRs with multiple peerings, setting next-hop self will effectively allow local repair of the atomic failure of any external peer without any compromise to the data plane. Traditionally, the most common reason for not setting next-hop self is the associated drawback of losing the ability to signal the external failures of peering ASBRs or links to those ASBRs by fast IGP flooding. Such a potential drawback can be easily avoided by using a different peering address from the address used for next-hop mapping and removing the next-hop from the IGP at the last possible BGP path failure.
オペレーターが複数のピアリングでASBRを使用する場合、ネクストホップセルフを設定すると、データプレーンに妥協することなく、外部ピアのアトミック障害をローカルで効率的に修復できます。従来、ネクストホップセルフを設定しない最も一般的な理由は、ピアリングASBRまたはそれらのASBRへのリンクの外部障害を高速IGPフラッディングによって通知する機能を失うという関連する欠点です。このような潜在的な欠点は、ネクストホップマッピングに使用されるアドレスとは異なるピアリングアドレスを使用し、最後に発生する可能性のあるBGPパス障害でIGPからネクストホップを削除することで簡単に回避できます。
Herein, one may correctly observe that in the case of setting next-hop self on an ASBR, attributes of other external paths such that the ASBR is peering with may be different from the attributes of its best external path. Therefore, not injecting all of those external paths with their corresponding attributes cannot be compared to equivalent paths for the same prefix coming from different ASBRs.
ここで、ASBRにネクストホップセルフを設定する場合、ASBRがピアリングするような他の外部パスの属性は、その最良の外部パスの属性とは異なる場合があることを正しく観察できます。したがって、対応する属性を持つそれらすべての外部パスを注入しないことは、異なるASBRからの同じプレフィックスの同等のパスと比較できません。
While such observation, in principle, is correct, one should put things in perspective of the overall goal, which is to provide data-plane connectivity upon a single failure with minimal interruption/packet loss. During such transient conditions, using even potentially suboptimal exit points is reasonable, so long as forwarding information loops are not introduced. In the mean time, the BGP control plane will on its own re-advertise the newly elected best external path, and route-reflector planes will calculate their Nth best paths and propagate them to its clients. The result is that after seconds, even if potential suboptimality were encountered, it will be quickly and naturally healed.
このような観察は原則として正しいものですが、全体的な目標の観点から物事を考える必要があります。つまり、単一の障害時にデータプレーン接続を最小限の中断/パケット損失で提供することです。このような一時的な状況では、転送情報ループが導入されない限り、最適ではない可能性のある出口点を使用することも妥当です。一方、BGPコントロールプレーンは、新しく選択された最適な外部パスを独自に再アドバタイズし、ルートリフレクタプレーンはN番目の最適パスを計算して、クライアントに伝達します。その結果、数秒後に潜在的な最適性に直面したとしても、それは迅速かつ自然に治癒されます。
Distribution of the diverse-BGP-paths proposal provides the following benefits when compared to the alternatives:
多様なBGPパスの提案の配布には、代替案と比較して次の利点があります。
1. No modifications to the BGP4 protocol.
1. BGP4プロトコルへの変更はありません。
2. No requirement for upgrades to edge and core routers (as required in [ADD-PATHS]). It is backward compatible with the existing BGP deployments.
2. エッジおよびコアルーターへのアップグレードは不要です（[ADD-PATHS]で必要）。既存のBGP展開との下位互換性があります。
3. Can be easily enabled by the introduction of a new route reflector, a route server plane dedicated to the selection and distribution of Nth best-path, or just by new configuration of the upgraded current route reflector(s).
3. 新しいルートリフレクターの導入、N番目のベストパスの選択と配信専用のルートサーバープレーンの導入、またはアップグレードされた現在のルートリフレクターの新しい構成によって簡単に有効化できます。
4. Does not require major modification to BGP implementations in the entire network, which would result in an unnecessary increase of memory and CPU consumption due to the shift from today's per-prefix to a per-path advertisement state tracking.
4. ネットワーク全体のBGP実装に大きな変更を加える必要はありません。これにより、今日のプレフィックス単位からパス単位のアドバタイズメント状態追跡への移行により、メモリとCPUの消費が不必要に増加します。
5. Can be safely deployed gradually on an RR cluster basis.
5. RRクラスターベースで徐々に安全に展開できます。
6. The proposed solution is equally applicable to any BGP address family as described in "Multiprotocol Extensions for BGP-4" [RFC4760]. In particular, it can be used "as is" without any modifications to both IPv4 and IPv6 address families.
6. 提案されたソリューションは、「BGP-4のマルチプロトコル拡張」[RFC4760]で説明されているように、どのBGPアドレスファミリにも等しく適用できます。特に、IPv4とIPv6の両方のアドレスファミリを変更せずに、「そのまま」使用できます。
This section lists the most common applications that require the presence of redundant BGP paths:
このセクションでは、冗長なBGPパスの存在を必要とする最も一般的なアプリケーションをリストします。
1. Fast connectivity restoration in which backup paths with alternate exit points would be pre-installed as well as pre-resolved in the FIB of routers. This allows for a local action upon reception of a critical event notification of network/node failure. This failure recovery mechanism that is based on the presence of backup paths is also suitable for gracefully addressing scheduled maintenance requirements as described in [BGP-SHUTDOWN].
1. 代替の出口ポイントを備えたバックアップパスが事前にインストールされ、ルータのFIBに事前に解決される高速接続復元。これにより、ネットワーク/ノード障害の重大なイベント通知を受信したときのローカルアクションが可能になります。バックアップパスの存在に基づくこの障害回復メカニズムは、[BGP-SHUTDOWN]で説明されているように、スケジュールされたメンテナンス要件に適切に対処するのにも適しています。
2. Multi-path load balancing for both IBGP and EBGP.
2. IBGPとEBGPの両方のマルチパスロードバランシング。
3. BGP control-plane churn reduction for both intra-domain and inter-domain.
3. ドメイン内とドメイン間の両方のBGPコントロールプレーンチャーンの削減。
An important point to observe is that all of the above intra-domain applications are based on the use of reflector planes but are also applicable in the inter-domain Internet exchange point examples. As discussed in Section 4.3, an Internet exchange can conceptually deploy shadow route server planes, each responsible for distribution of an Nth best path to its EBGP peers. In practice, it may just be equal to a new short configuration and establishment of new BGP sessions to IX peers.
注意すべき重要な点は、上記のドメイン内アプリケーションはすべて反射面の使用に基づいているが、ドメイン間のインターネット交換ポイントの例にも適用できるということです。セクション4.3で説明したように、インターネット交換は、それぞれがそのEBGPピアへのN番目の最適パスの配布を担当するシャドウルートサーバープレーンを概念的に展開できます。実際には、IXピアへの新しい短い構成と新しいBGPセッションの確立に等しい場合があります。
The new mechanism for diverse BGP path dissemination proposed in this document does not introduce any new security concerns as compared to the base BGP4 specification [RFC4271] and especially when compared against full-IBGP-mesh topology.
このドキュメントで提案された多様なBGPパス配布の新しいメカニズムは、ベースBGP4仕様[RFC4271]と比較して、特にフルIBGPメッシュトポロジーと比較した場合、新しいセキュリティ上の懸念をもたらしません。
In addition, the authors observe that all BGP security issues as described in [RFC4272] apply to the additional BGP session or sessions as recommended by this specification. Therefore, all recommended mitigation techniques to BGP security are applicable here.
さらに、著者は、[RFC4272]で説明されているすべてのBGPセキュリティ問題が、この仕様で推奨されている追加のBGPセッションに適用されることを認めています。したがって、BGPセキュリティに推奨されるすべての軽減技術がここで適用されます。
The following people contributed significantly to the content of the document:
次の人々は文書の内容に大きく貢献しました：
Selma Yilmaz Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: seyilmaz@cisco.com
Selma Yilmaz Cisco Systems 170 West Tasman Drive San Jose、CA 95134 US Eメール：seyilmaz@cisco.com
Satish Mynam Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 US Email: smynam@juniper.net
Satish Mynam Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089 USメール：smynam@juniper.net
Isidor Kouvelas Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: kouvelas@cisco.com
Isidor Kouvelas Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USメール：kouvelas@cisco.com
The authors would like to thank Bruno Decraene, Bart Peirens, Eric Rosen, Jim Uttaro, Renwei Li, Wes George, and Adrian Farrel for their valuable input.
著者は、貴重な情報を提供してくれたBruno Decraene、Bart Peirens、Eric Rosen、Jim Uttaro、Renwei Li、Wes George、およびAdrian Farrelに感謝します。
The authors would also like to express a special thank you to a number of operators who helped optimize the provided solution to be as close as possible to their daily operational practices. In particular, many thanks to Ted Seely, Shane Amante, Benson Schliesser, and Seiichi Kawamura.
著者はまた、提供されたソリューションを日常業務にできるだけ近くなるように最適化するのを助けてくれた多くのオペレーターに特別な感謝を表明したいと思います。特に、Ted Seely、Shane Amante、Benson Schliesser、Seiichi Kawamuraに感謝します。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[RFC4456]ベイツ、T。、チェン、E。、およびR.チャンドラ、「BGP Route Reflection：An Alternative to Full Mesh Internal BGP（IBGP）」、RFC 4456、2006年4月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[ADD-PATHS] Walton, D., Chen, E., Retana, A., and J. Scudder, "Advertisement of Multiple Paths in BGP", Work in Progress, June 2012.
[パスの追加] Walton、D.、Chen、E.、Retana、A。、およびJ. Scudder、「Advertisement of Multiple Paths in BGP」、Work in Progress、2012年6月。
[AUTO-MESH] Raszuk, R., "IBGP Auto Mesh", Work in Progress, January 2004.
[AUTO-MESH] Raszuk、R。、「IBGP Auto Mesh」、作業中、2004年1月。
[BGP-SHUTDOWN] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., and A. Armengol, "Requirements for the Graceful Shutdown of BGP Sessions", Work in Progress, September 2009.
[BGP-SHUTDOWN] Decraene、B.、Francois、P.、Pelsser、C.、Ahmad、Z。、およびA. Armengol、「BGPセッションの正常なシャットダウンの要件」、作業中、2009年9月。
[EXT-PATH] Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. Gredler, "Advertisement of the Best External Route in BGP", Work in Progress, January 2012.
[EXT-PATH] Marques、P.、Fernando、R.、Chen、E.、Mohapatra、P。、およびH. Gredler、「BGPでの最良の外部ルートの広告」、2012年1月、進行中。
[FAST-CONN] Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk, "Fast Connectivity Restoration Using BGP Add-path", Work in Progress), October 2011.
[FAST-CONN] Mohapatra、P.、Fernando、R.、Filsfils、C。、およびR. Raszuk、「BGP Add-pathを使用した高速接続の復元」、作業中）、2011年10月。
[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）Persistent Route Oscillation Condition」、RFC 3345、2002年8月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]マーフィーS。、「BGPセキュリティ脆弱性分析」、RFC 4272、2006年1月。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007.
[RFC5065] Traina、P.、McPherson、D。、およびJ. Scudder、「BGPの自律システム連合」、RFC 5065、2007年8月。
Authors' Addresses
著者のアドレス
Robert Raszuk (editor) NTT MCL 101 S Ellsworth Avenue Suite 350 San Mateo, CA 94401 United States
Robert Raszuk（編集者）NTT MCL 101 S Ellsworth Avenue Suite 350 San Mateo、CA 94401アメリカ合衆国
EMail: robert@raszuk.net
Rex Fernando Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
Rex Fernando Cisco Systems 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
EMail: rex@cisco.com
Keyur Patel Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
Keyur Patel Cisco Systems 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
EMail: keyupate@cisco.com
Danny McPherson Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 United States
Danny McPherson Verisign、Inc. 12061 Bluemont Way Reston、VA 20190アメリカ
EMail: dmcpherson@verisign.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460 Japan
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ １０２ー８４６０ じゃぱん
EMail: ke-kumaki@kddi.com