RFC 9107 - BGP Optimal Route Reflection (BGP ORR) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9107.html
タイトル : RFC 9107 - BGP最適経路反射（BGP ORR）
翻訳編集 : 自動生成

[要約] RFC 9107 - BGP最適ルートリフレクション (BGP ORR) は、ネットワーク内でのルートリフレクションの効率を向上させるためのプロトコル拡張です。この目的は、大規模ネットワークにおけるルーティング情報の伝播を最適化し、経路計算の負荷を軽減することにあります。利用場面としては、大規模ISPやデータセンターのネットワークでの運用が挙げられます。

Internet Engineering Task Force (IETF)                    R. Raszuk, Ed.
Request for Comments: 9107                       NTT Network Innovations
Category: Standards Track                               B. Decraene, Ed.
ISSN: 2070-1721                                                   Orange
                                                               C. Cassar

E. Åman

E.Åman.

K. Wang Juniper Networks August 2021

K.王ジュニパーネットワーク2021年8月

BGP Optimal Route Reflection (BGP ORR)

BGP最適経路反射（BGP ORR）

Abstract

概要

This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing").

このドキュメントはBGPルートリフレクタへの拡張子を定義します。ルートリフレクタでは、ルートリフレクタ自体の観点からはなく、クライアントの観点から最適なルートを選択するために、BGPルート選択が変更されます。スケーリングおよび精度の要件に応じて、ルート選択は1つのクライアントに特定され、一連のクライアントに共通、またはルートリフレクタのすべてのクライアントに共通しています。この解決策は、ルートリフレクタのIGP位置に基づく最良のルートを選択する集中ルートリフレクタを使用する展開に特に適用されます。これにより、例えば「最良出口点」方針（「ホットポテトルーティング」）が容易になります。

The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP.

このソリューションは、検討の対象となるすべてのパスを学習するすべてのルートリフレクタに依存しています。BGP経路選択は、リンク状態IGP内の構成された位置からIGPコストに基づいて経路反射器内で行われる。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9107.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9107で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Modifications to BGP Route Selection
     3.1.  Route Selection from a Different IGP Location
       3.1.1.  Restriction when the BGP Next Hop Is a BGP Route
     3.2.  Multiple Route Selections
   4.  Deployment Considerations
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1. Introduction

1. はじめに

There are three types of BGP deployments within Autonomous Systems (ASes) today: full mesh, confederations, and route reflection. BGP route reflection [RFC4456] is the most popular way to distribute BGP routes between BGP speakers belonging to the same AS. However, in some situations, this method suffers from non-optimal path selection.

今日の自律システム（ASES）には、BGP展開には3種類あります。フルメッシュ、コンフェデーション、およびルートリフレット。BGP Route Reflection [RFC4456]は、同じBGPスピーカー間でBGPルートを配布する最も一般的な方法です。ただし、状況によっては、この方法では最適ではないパス選択があります。

[RFC4456] asserts that, because the IGP cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." ("IBGP" stands for "Internal BGP".) One practical implication of this fact is that the deployment of route reflection may thwart the ability to achieve "hot potato routing". Hot potato routing attempts to direct traffic to the closest AS exit point in cases where no higher-priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the exit point that is optimal for the route reflector -- not necessarily the one that is optimal for its clients.

[RFC4456]ネットワーク内の特定のポイントへのIGPコストがルータ間で異なるため、「ルート反射アプローチは、全IBGPメッシュアプローチのルート選択結果と同じ経路選択結果を生成できない場合があります」と主張しています。（「IBGP」は「内部BGP」を表します。）この事実の実際的な意味は、経路反射の展開が「ホットポテトルーティング」を達成する能力を妨げる可能性があることです。ホットポテトルーティングは、優先順位の高いポリシーがそうでないと指示されていない場合に、終了点としてトラフィックを最も近くに直接転送しようとします。経路反射法の結果として、ルートリフレクタおよびそのクライアントの出口点の選択は、ルートリフレクタに最適な出口点となります - 必ずしもそのクライアントに最適なものではありません。

Section 11 of [RFC4456] describes a deployment approach and a set of constraints that, if satisfied, would result in the deployment of route reflection yielding the same results as the IBGP full mesh approach. This deployment approach makes route reflection compatible with the application of a hot potato routing policy. In accordance with these design rules, route reflectors have often been deployed in the forwarding path and carefully placed on the boundaries between the Point of Presence (POP) and the network core.

[RFC4456]のセクション11は、展開アプローチと満足した場合には、IBGPフルメッシュアプローチと同じ結果をもたらすルートリフレクションの展開をもたらす制約のセットです。この展開アプローチは、ホットポテトルーティングポリシーの適用とルート反射を互換性のあるものにします。これらの設計規則によれば、ルートリフレクタはしばしば転送経路に展開され、プレゼンス（POP）とネットワークコアの間の境界に慎重に配置されています。

The evolving model of intra-domain network design has enabled deployments of route reflectors outside the forwarding path. Initially, this model was only employed for new services, e.g., IP VPNs [RFC4364]; however, it has been gradually extended to other BGP services, including the IPv4 and IPv6 Internet. In such environments, a hot potato routing policy remains desirable.

ドメイン内ネットワーク設計の進化モデルは、転送パスの外側のルートリフレクタの展開を可能にしました。最初は、このモデルは新しいサービス、例えばIP VPNS [RFC4364]にのみ使用されました。ただし、IPv4とIPv6インターネットなど、他のBGPサービスに徐々に拡張されています。そのような環境では、ホットポテトルーティングポリシーは望ましいままです。

Route reflectors outside the forwarding path can be placed on the boundaries between the POP and the network core, but they are often placed in arbitrary locations in the core of large networks.

転送経路の外側の経路反射器は、POPとネットワークコアの間の境界に配置することができますが、大規模ネットワークの中核の任意の場所に配置されることがよくあります。

Such deployments suffer from a critical drawback in the context of BGP route selection: a route reflector with knowledge of multiple paths for a given route will typically pick its best path and only advertise that best path to its clients. If the best path for a route is selected on the basis of an IGP tie-break, the path advertised will be the exit point closest to the route reflector. However, the clients are in a different place in the network topology than the route reflector. In networks where the route reflectors are not in the forwarding path, this difference will be even more acute.

そのような展開は、BGPルート選択の文脈における重大な欠点を抱えている。所与の経路の複数の経路に関する知識を有するルートリフレクタは、通常、その最良の経路を選択し、そのクライアントへの最良の経路だけを宣伝するだけである。IGPタイブレークに基づいて経路の最良の経路が選択されている場合、広告経路はルートリフレクタに最も近い出口点になります。ただし、クライアントはルートリフレクタよりもネットワークトポロジー内の異なる場所にあります。ルートリフレクタが転送経路にないネットワークでは、この差はさらに急性になります。

In addition, there are deployment scenarios where service providers want to have more control in choosing the exit points for clients based on other factors, such as traffic type, traffic load, etc. This further complicates the issue and makes it less likely for the route reflector to select the best path from the client's perspective. It follows that the best path chosen by the route reflector is not necessarily the same as the path that would have been chosen by the client if the client had considered the same set of candidate paths as the route reflector.

さらに、トラフィックの種類、トラフィック負荷などの他の要因に基づいてクライアントの出口ポイントを選択する際にサービスプロバイダがより多くの管理を希望する展開シナリオがあります。これにより問題が解決され、ルートの可能性が低くなります。リフレクタクライアントの観点から最適なパスを選択する。その結果、ルートリフレクタによって選択された最良の経路は、クライアントがルートリフレクタとして同じ候補パスのセットを検討した場合、クライアントによって選択されたであろうパスと必ずしも同じではないことになる。

2. Terminology

2. 用語

This memo makes use of the terms defined in [RFC4271] and [RFC4456].

このメモは[RFC4271]と[RFC4456]で定義されている用語を利用しています。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. Modifications to BGP Route Selection

3. BGPルート選択の変更

The core of this solution is the ability for an operator to specify the IGP location for which the route reflector calculates interior cost to the next hop. The IGP location is defined as a node in the IGP topology, it is identified by an IP address of this node (e.g., a loopback address), and it may be configured on a per-route-reflector basis, per set of clients, or on a per-client basis. Such configuration will allow the route reflector to select and distribute to a given set of clients routes with the shortest distance to the next hops from the position of the selected IGP location. This provides for freedom related to the route reflector's physical location and allows transient or permanent migration of this network control plane function to an arbitrary location with no impact on IP transit.

この解決策のコアは、オペレータがルートリフレクタが次のホップに内部コストを計算するIGP位置を指定することができる能力である。IGPの位置は、IGPトポロジのノードとして定義されており、このノードのIPアドレス（例えば、ループバックアドレス）によって識別され、それはクライアントのセットごとにルートごとのリフレクタごとに設定されてもよい。またはクライアントごとに。そのような構成により、ルートリフレクタは、選択されたIGP位置の位置から次のホップまでの最短距離を有する所定のクライアントルートのセットを選択し配布することを可能にする。これは、ルートリフレクタの物理的な場所に関連する自由を提供し、このネットワーク制御プレーン関数の過渡的または永続的な移行をIPトランジットに影響されずに任意の場所に許可します。

The choice of specific granularity (route reflector, set of clients, or client) is configured by the network operator. An implementation is considered compliant with this document if it supports at least one such grouping category.

特定の粒度の選択（ルートリフレクタ、クライアントのセット、またはクライアント）は、ネットワークオペレータによって構成されています。実装は、少なくとも1つのそのようなグループ化カテゴリをサポートする場合、この文書に準拠していると見なされます。

For purposes of route selection, the perspective of a client can differ from that of a route reflector or another client in two distinct ways:

経路選択の目的のために、クライアントの観点は、2つの異なる方法でルートリフレクタまたは他のクライアントの観点とは異なる可能性があります。

* It has a different position in the IGP topology.

* IGPトポロジには異なる位置があります。

* It can have a different routing policy.

* それは異なるルーティングポリシーを持つことができます。

These factors correspond to the issues described earlier.

これらの要因は、前述の問題に対応しています。

This document defines, for BGP route reflectors [RFC4456], two changes to the BGP route selection algorithm:

このドキュメントでは、BGPルートリフレクタ[RFC4456]の場合、BGPルート選択アルゴリズムへの2つの変更が定義されています。

* The first change, introduced in Section 3.1, is related to the IGP cost to the BGP next hop in the BGP Decision Process. The change consists of using the IGP cost from a different IGP location than the route reflector itself.

* セクション3.1で導入された最初の変更は、BGP決定プロセスにおけるBGP次のホップへのIGPコストに関連しています。変更は、ルートリフレクタ自体とは異なるIGP位置からIGPコストを使用することからなります。

* The second change, introduced in Section 3.2, is to extend the granularity of the BGP Decision Process, to allow for running multiple Decision Processes using different perspectives or policies.

* セクション3.2で導入された2回目の変更は、異なる観点やポリシーを使用して複数の意思決定プロセスを実行できるように、BGP決定プロセスの粒度を拡張することです。

A route reflector can implement either or both of the modifications in order to allow it to choose the best path for its clients that the clients themselves would have chosen given the same set of candidate paths.

ルートリフレクタは、クライアント自体が同じ候補パスのセットを考慮して選択されたクライアントに対する最良の経路を選択できるようにするために、変更のいずれかまたは両方を実装することができる。

A significant advantage of these approaches is that the route reflector's clients do not need to be modified.

これらのアプローチの重要な利点は、ルートリフレクタのクライアントを変更する必要がないことです。

3.1. Route Selection from a Different IGP Location

3.1. 別のIGPロケーションからのルート選択

In this approach, "optimal" refers to the decision where the interior cost of a route is determined during step e) of Section 9.1.2.2 ("Breaking Ties (Phase 2)") of [RFC4271]. It does not apply to path selection preference based on other policy steps and provisions.

このアプローチでは、「最適」とは、ステップEのステップE）の間の内部コストがセクション9.1.2.2の（RFC4271]のステップE）の間に決定される決定を指す。他のポリシーステップや規定に基づく経路選択の好みには適用されません。

In addition to the change specified in Section 9 of [RFC4456], the text in step e) in Section 9.1.2.2 of [RFC4271] is modified as follows.

[RFC4456]のセクション9で指定された変更に加えて、[RFC4271]のセクション9.1.2.2のテキストは次のように変更されます。

RFC 4271 reads:

RFC 4271を読みます：

   |  e)  Remove from consideration any routes with less-preferred
   |      interior cost.  The interior cost of a route is determined by
   |      calculating the metric to the NEXT_HOP for the route using the
   |      Routing Table.

This document modifies this text to read:

この文書はこのテキストを読み込むように変更します。

   |  e)  Remove from consideration any routes with less-preferred
   |      interior cost.  The interior cost of a route is determined by
   |      calculating the metric from the selected IGP location to the
   |      NEXT_HOP for the route using the shortest IGP path tree rooted
   |      at the selected IGP location.

In order to be able to compute the shortest path tree rooted at the selected IGP locations, knowledge of the IGP topology for the area/ level that includes each of those locations is needed. This knowledge can be gained with the use of the link-state IGP, such as IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340], or via the Border Gateway Protocol - Link State (BGP-LS) [RFC7752]. When specifying the logical location of a route reflector for a group of clients, one or more backup IGP locations SHOULD be allowed to be specified for redundancy. Further deployment considerations are discussed in Section 4.

選択したIGP位置に根ざした最短パスツリーを計算できるようにするには、それらの各場所を含む領域/レベルのIGPトポロジの知識が必要です。この知識は、IS-IS [ISO10589]またはOSPF [RFC2328] [RFC5340]などのリンクステートIGPを使用して、またはボーダーゲートウェイプロトコルリンク状態（BGP-LS）[RFC7752]を介して取得できます。クライアントグループのルートリフレクタの論理位置を指定する場合、1つ以上のバックアップIGP位置を冗長性に指定することを許可する必要があります。さらに展開の考慮事項については、セクション4で説明されています。

3.1.1. Restriction when the BGP Next Hop Is a BGP Route

3.1.1. BGPネクストホップがBGPルートの場合の制限

In situations where the BGP next hop is a BGP route itself, the IGP metric of a route used for its resolution SHOULD be the final IGP cost to reach such a next hop. Implementations that cannot inform BGP of the final IGP metric to a recursive next hop MUST treat such paths as least preferred during next-hop metric comparisons. However, such paths MUST still be considered valid for BGP Phase 2 route selection.

BGPネクストホップがBGPルート自体である状況では、その解像度に使用されるルートのIGPメトリックは、そのような次のホップに到達するための最後のIGPコストであるべきです。再帰的な次のホップに最終的なIGPメトリックのBGPを知らせない実装は、次のホップメトリック比較中に少なくとも好まれるようにそのようなパスを扱う必要があります。ただし、そのようなパスはBGPフェーズ2のルート選択には依然として有効であると考える必要があります。

3.2. Multiple Route Selections

3.2. 複数の経路選択

A BGP route reflector as per [RFC4456] runs a single BGP Decision Process. BGP Optimal Route Reflection (BGP ORR) may require multiple BGP Decision Processes or subsets of the Decision Process in order to consider different IGP locations or BGP policies for different sets of clients. This is very similar to what is defined in [RFC7947], Section 2.3.2.1.

[RFC4456]のBGPルートリフレクタは単一のBGP決定プロセスを実行します。BGP最適経路反射（BGP ORR）は、異なる一連のクライアントに対する異なるIGP位置またはBGPポリシーを考慮するために、複数のBGP決定プロセスまたは決定プロセスのサブセットを必要とするかもしれません。これは[RFC7947]で定義されているものと非常によく似ています。セクション2.3.2.1。

If the required routing optimization is limited to the IGP cost to the BGP next hop, only step e) and subsequent steps as defined in [RFC4271], Section 9.1.2.2 need to be run multiple times.

必要なルーティングの最適化がBGPネクストホップへのIGPコストに制限されている場合は、[RFC4271]で定義されているステップEのステップe）、セクション9.1.2.2を複数回実行する必要があります。

If the routing optimization requires the use of different BGP policies for different sets of clients, a larger part of the Decision Process needs to be run multiple times, up to the whole Decision Process as defined in Section 9.1 of [RFC4271]. This is, for example, the case when there is a need to use different policies to compute different degrees of preference during Phase 1. This is needed for use cases involving traffic engineering or dedicating certain exit points for certain clients. In the latter case, the user may specify and apply a general policy on the route reflector for a set of clients. Regular path selection, including IGP perspectives for a set of clients as per Section 3.1, is then applied to the candidate paths to select the final paths to advertise to the clients.

ルーティングの最適化には異なるクライアントセットに対して異なるBGPポリシーの使用が必要な場合は、[RFC4271]のセクション9.1で定義されている決定プロセス全体まで、決定プロセスの大部分を複数回実行する必要があります。これは、例えばフェーズ1で異なる程度の好みを計算するために異なるポリシーを使用する必要がある場合の場合、これは、トラフィックエンジニアリングを含む使用例または特定のクライアントの特定の出口ポイントを損なうために必要です。後者の場合、ユーザは、一連のクライアントについてルートリフレクタ上で一般ポリシーを指定して適用することができる。セクション3.1に従って、一連のクライアントに対するIGPの視点を含む通常のパス選択が、クライアントにアドバタイズする最終パスを選択するための候補パスに適用されます。

4. Deployment Considerations

4. 展開に関する考慮事項

BGP ORR provides a model for integrating the client's perspective into the BGP route selection Decision Process for route reflectors. More specifically, the choice of BGP path takes into account either the IGP cost between the client and the next hop (rather than the IGP cost from the route reflector to the next hop) or other user-configured policies.

BGP ORRは、クライアントの視点をルートリフレクタのBGP経路選択決定プロセスに統合するためのモデルを提供します。より具体的には、BGPパスの選択は、クライアントと次のホップとの間のIGPコスト（ルートリフレクタから次のホップへのIGPコストではなく）または他のユーザ設定ポリシーのいずれかを考慮に入れる。

The achievement of optimal routing between clients of different clusters relies upon all route reflectors learning all paths that are eligible for consideration. In order to satisfy this requirement, BGP ADD-PATH [RFC7911] needs to be deployed between route reflectors.

異なるクラスタのクライアント間の最適ルーティングの達成は、検討の対象となるすべてのパスを学習するすべての経路リフレクタに依存しています。この要件を満たすためには、ルートリフレクタ間でBGP Add-Path [RFC7911]を展開する必要があります。

This solution can be deployed in hop-by-hop forwarding networks as well as in end-to-end tunneled environments. To avoid routing loops in networks with multiple route reflectors and hop-by-hop forwarding without encapsulation, it is essential that the network topology be carefully considered in designing a route reflection topology (see also Section 11 of [RFC4456]).

このソリューションは、ホップバイホップ転送ネットワークとエンドツーエンドのトンネリング環境で展開できます。複数のルートリフレクターとカプセル化なしのホップバイホップ転送を持つネットワークのルーティングループを回避するために、ネットワークトポロジーはルートリフレクショントポロジーの設計において慎重に考慮されることが不可欠です（[RFC4456]のセクション11も参照）。

As discussed in Section 11 of [RFC4456], the IGP locations of BGP route reflectors are important and have routing implications. This equally applies to the choice of the IGP locations configured on optimal route reflectors. If a backup location is provided, it is used when the primary IGP location disappears from the IGP (i.e., fails). Just like the failure of a route reflector [RFC4456], it may result in changing the paths selected and advertised to the clients, and in general, the post-failure paths are expected to be less optimal. This is dependent on the IGP topologies and the IGP distance between the primary and backup IGP locations: the smaller the distance, the smaller the potential impact.

[RFC4456]のセクション11で説明したように、BGPルートリフレクタのIGP位置は重要であり、ルーティングの意味を持ちます。これは、最適経路反射器上に構成されたIGP位置の選択に等しく適用されます。バックアップ場所が提供されている場合は、プライマリIGPロケーションがIGP（すなわち失敗）から消えたときに使用されます。ルートリフレクタ[RFC4456]の障害と同じように、それはクライアントに選択され広告されたパスを変更することになる可能性があり、一般に、障害後パスは最適ではないと予想されます。これは、IGPトポロジとプライマリとバックアップの間のIGP距離に依存します。距離が小さいほど、潜在的な影響は小さくなります。

After selecting N suitable IGP locations, an operator can choose to enable route selection for all of them on all or on a subset of their route reflectors. The operator may alternatively deploy single or multiple (backup case) route reflectors for each IGP location or create any design in between. This choice may depend on the operational model (centralized vs. per region), an acceptable blast radius in the case of failure, an acceptable number of IBGP sessions for the mesh between the route reflectors, performance, and configuration granularity of the equipment.

Nopod Proport IGP位置を選択した後、オペレータは、それらのすべてのまたはそれらのルート反射器のサブセット上のすべてのルート選択を有効にすることを選択できます。オペレータは、IGP位置ごとに単一または複数の（バックアップケース）ルートリフレクタを展開するか、またはその間に設計を作成することができる。この選択は、障害の場合には許容可能なBLAST半径、経路反射器、性能、および機器の構成の粒度の間のメッシュの許容可能な数のIBGPセッションの許容可能な数のBLAST半径に依存することがあります。

With this approach, an ISP can effect a hot potato routing policy even if route reflection has been moved out of the forwarding plane and hop-by-hop forwarding has been replaced by end-to-end MPLS or IP encapsulation. Compared with a deployment of ADD-PATH on all routers, BGP ORR reduces the amount of state that needs to be pushed to the edge of the network in order to perform hot potato routing.

このアプローチでは、経路反射が転送プレーンから移動されていても、ISPはホットポテトルーティングポリシーを実行することができ、ホップバイホップ転送はエンドツーエンドMPLSまたはIPカプセル化によって置き換えられました。すべてのルータでのアドパスの展開と比較して、BGP ORRは、ホットポテトルーティングを実行するためにネットワークのエッジにプッシュする必要がある状態の量を減らします。

Modifying the IGP location of BGP ORR does not interfere with policies enforced before IGP tie-breaking (step e) of [RFC4271], Section 9.1.2.2) in the BGP Decision Process.

BGP ORRのIGP位置を変更しても、BGP決定プロセスにおける[RFC4271]の[RFC4271]のIGPタイ破断（ステップE）の前に施行されないポリシーを妨げません。

Calculating routes for different IGP locations requires multiple Shortest Path First (SPF) calculations and multiple (subsets of) BGP Decision Processes. This scenario calls for more computing resources. This document allows for different granularity, such as one Decision Process per route reflector, per set of clients, or per client. A more fine-grained granularity may translate into more optimal hot potato routing at the cost of more computing power. Choosing to configure an IGP location per client has the highest precision, as each client can be associated with their ideal (own) IGP location. However, doing so may have an impact on performance (as explained above). Using an IGP location per set of clients implies a loss of precision but reduces the impact on the performance of the route reflector. Similarly, if an IGP location is selected for the whole routing instance, the lowest precision is achieved, but the impact on performance is minimal. In the last mode of operation (where an IGP location is selected for the whole routing instance), both precision and performance metrics are equal to route reflection as described in [RFC4456]. The ability to run fine-grained computations depends on the platform/hardware deployed, the number of clients, the number of BGP routes, and the size of the IGP topology. In essence, sizing considerations are similar to the deployments of BGP route reflectors.

さまざまなIGP位置のルートの計算には、複数の最短パスFirst（SPF）計算と複数（サブセット）BGPの決定プロセスが必要です。このシナリオは、より多くのコンピューティングリソースを呼び出します。この文書は、ルートリフレクタごとの1つの決定プロセス、クライアントのセット、またはクライアントごとに異なる粒度を可能にします。よりきめ細かい粒度は、より多くのコンピューティング電力のコストでより最適なホットポテトルーティングに変換することができる。クライアントごとにIGPの場所を設定することを選択するたびに、各クライアントは理想的な（自分の）IGPの場所に関連付けることができます。しかし、（上で説明したように）パフォーマンスに影響を与える可能性があります。一連のクライアントごとにIGP位置を使用すると、正確な損失がありますが、ルートリフレクタの性能への影響を少なくします。同様に、ルーティングインスタンス全体のIGP位置が選択されている場合、最低の精度が達成されますが、パフォーマンスへの影響は最小限です。最後の動作モード（ルーティングインスタンス全体に対してIGP位置が選択されている場合）では、PRECISIONメトリックとパフォーマンスメトリックの両方が[RFC4456]に記載されているように経路反射と同じです。きめ細かい計算を実行する機能は、プラットフォーム/ハードウェアの展開、クライアント数、BGPルート数、およびIGPトポロジのサイズによって異なります。本質的に、サイズの考慮事項はBGPルートリフレクタの展開と似ています。

5. Security Considerations

5. セキュリティに関する考慮事項

The extension specified in this document provides a new metric value using additional information for computing routes for BGP route reflectors. While any improperly used metric value could impact the resiliency of the network, this extension does not change the underlying security issues inherent in the existing IBGP per [RFC4456].

このドキュメントで指定されている拡張機能は、BGPルートリフレクタのルートを計算するための追加情報を使用して新しいメトリック値を提供します。不適切に使用されているメトリック値がネットワークの復元性に影響を与える可能性があるが、この拡張子は[RFC4456]ごとに既存のIBGPに固有の基になるセキュリティ問題を変更しません。

This document does not introduce requirements for any new protection measures.

この文書では、新しい保護対策の要件を導入していません。

6. IANA Considerations

6. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。

[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.

[RFC4456] Bates、T.、Chen、E.、R.Chandra、「BGPルート反射：フルメッシュ内部BGP（IBGP）」、RFC 4456、DOI 10.17487 / RFC4456、<https：//www.rfc-editor.org/info/rfc4456>。

[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/info/rfc7911>.

[RFC7911] Walton、D.、Retana、A.、Chen、E.、およびJ.Scudder、「BGPの複数の経路の広告」、RFC 7911、DOI 10.17487 / RFC7911、2016年7月、<https：// www。rfc-editor.org/info/rfc7911>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

7.2. Informative References

7.2. 参考引用

[ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.

[ISO10589]標準化のための国際標準化、「中間システムへの中間システムへの中間システムへの中間システムへの中間システムへのイントラクティブシステムイントラクションモードネットワークサービス（ISO 8473）」、ISO / IEC 10589：2002、Second2002年11月版。

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC2328] Moy、J.、 "OSPFバージョン2"、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC5340] Coltun、R.、Ferguson、D.、Moy、J.、およびA. Lindem、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：///www.rfc-編集者.org / info / rfc5340>。

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.

[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、およびS. Ray、「BGPを使用したリンク状態およびトラフィックエンジニアリングの北部分布」、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https：//www.rfc-editor.org/info/rfc7752>。

[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-editor.org/info/rfc7947>.

[RFC7947] Jasinska、E.、Hilliard、N.、Raszuk、R.、およびN. Bakker、 "Internet Exchange BGP Route Server"、RFC 7947、DOI 10.17487 / RFC7947、2016年9月、<https：//www.rfc-editor.org/info/rfc7947>。

Acknowledgments

謝辞

The authors would like to thank Keyur Patel, Eric Rosen, Clarence Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon Mitchell, John Scudder, Jeff Haas, Martin Djernæs, Daniele Ceccarelli, Kieran Milne, Job Snijders, Randy Bush, Alvaro Retana, Francesca Palombini, Benjamin Kaduk, Zaheduzzaman Sarker, Lars Eggert, Murray Kucherawy, Tom Petch, and Nick Hilliard for their valuable input.

著者らは、Keyur Patel、Eric Rosen、Clarence Filsfils、Clarence Filsfils、Uli Bornhauser、Russ White、Jakob Heitz、Mike Shand、Jeff Haas、Martin Djernss、Daniele Ceccarelli、Kieran Milne、Jemanele Ceccarelli、Kieran Milne、Randy Bush、Alvaro retana、Francesca Palombini、Benjamin Kaduk、ザヘデザマンザハル、LARS Eggert、Murray Kucherawy、Tom Petch、およびNick Hilliardの貴重な入力のため。

Contributors

貢献者

The following persons contributed substantially to the current format of the document:

以下の人は、文書の現在のフォーマットに実質的に貢献しました。

Stephane Litkowski Cisco Systems

Stephane Litkowski Cisco Systems.

   Email: slitkows.ietf@gmail.com

Adam Chappell GTT Communications, Inc. Aspira Business Centre Bucharova 2928/14a 158 00 Prague 13 Stodůlky Czech Republic

Adam Chappell GTT Communications、Inc。Aspira Business Center Bucharova 2928/14a 158 00プラハ13StodılkyCzech Republic

   Email: adam.chappell@gtt.net

Authors' Addresses

著者の住所

Robert Raszuk (editor) NTT Network Innovations

Robert Raszuk（編集）NTTネットワーク革新

   Email: robert@raszuk.net

Bruno Decraene (editor) Orange

ブルーノデトラエイン（編集）オレンジ

   Email: bruno.decraene@orange.com

Christian Cassar

クリスチャンキャッサル

   Email: cassar.christian@gmail.com

Erik Åman

エリックÅman.

   Email: erik.aman@aman.se

Kevin Wang Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America

Kevin Wang Juniper Networks 10テクノロジーパークドライブWestford、MA 01886アメリカ合衆国

   Email: kfwang@juniper.net