[要約] RFC 9087は、セグメントルーティングを中心としたBGP出口ピアエンジニアリングに関する技術仕様です。この文書の目的は、ネットワークの効率性と柔軟性を向上させるために、中央集権的な制御を通じてBGP出口トラフィックのルーティングを最適化する方法を提供することです。主に、大規模ネットワーク運用者がトラフィックの流れをより細かく制御し、パフォーマンスを最適化する場面で利用されます。
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 9087 S. Previdi
Category: Informational G. Dawra, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
E. Aries
Juniper Networks
D. Afanasiev
Yandex
August 2021
Segment Routing Centralized BGP Egress Peer Engineering
セグメントルーティング集中BGP出力ピアエンジニアリング
Abstract
概要
Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.
セグメントルーティング（SR）は、ソースルーティングを活用しています。ノードは、パケットをSRヘッダと入力することによって、セグメントと呼ばれる制御セットのセットを介してパケットを操作する。セグメントは、任意の命令、トポロジカル、またはサービスベースを表すことができます。SRは、SRドメインの入力ノードでのみ、フローごとの状態を維持しながら、任意のトポロジパスを通過するフローの執行を可能にします。
The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.
セグメントルーティングアーキテクチャは、転送面に変更されずにMPLSデータプレーンに直接適用できます。既存のリンクステートルーティングプロトコルへのマイナーな拡張が必要です。
This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.
この文書は、BGP Egress Peer Engineering（BGP-EPE）要件を解決するためのセグメントルーティングのアプリケーションを示しています。SRベースのBGP-EPEソリューションにより、集中型（ソフトウェア定義ネットワーキング、またはSDN）コントローラは、入力ボーダールータまたはドメイン内のホストで任意の出力ピアポリシーをプログラムできます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc9087.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9087で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（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
1.1. Problem Statement
1.2. Requirements Language
2. BGP Peering Segments
3. Distribution of Topology and TE Information Using BGP-LS
3.1. PeerNode SID to D
3.2. PeerNode SID to E
3.3. PeerNode SID to F
3.4. First PeerAdj to F
3.5. Second PeerAdj to F
3.6. Fast Reroute (FRR)
4. BGP-EPE Controller
4.1. Valid Paths from Peers
4.2. Intra-Domain Topology
4.3. External Topology
4.4. SLA Characteristics of Each Peer
4.5. Traffic Matrix
4.6. Business Policies
4.7. BGP-EPE Policy
5. Programming an Input Policy
5.1. At a Host
5.2. At a Router - SR Traffic-Engineering Tunnel
5.3. At a Router - Unicast Route Labeled Using BGP (RFC 8277)
5.4. At a Router - VPN Policy Route
6. IPv6 Data Plane
7. Benefits
8. IANA Considerations
9. Manageability Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The document is structured as follows:
文書は次のように構成されています。
* Section 1 states the BGP-EPE problem statement and provides the key references.
* セクション1はBGP-EPE問題ステートメントを示し、キー参照を提供します。
* Section 2 defines the different BGP Peering Segments and the semantic associated to them.
* セクション2は、さまざまなBGPピアリングセグメントとそれらに関連付けられている意味を定義します。
* Section 3 describes the automated allocation of BGP Peering Segment-IDs (SIDs) by the BGP-EPE-enabled egress border router and the automated signaling of the external peering topology and the related BGP Peering SIDs to the collector [RFC9086].
* セクション3は、BGP-EPE対応の出力境界ルータによるBGPピアリングセグメントID（SID）の自動割り当てと、外部ピアリングトポロジーの自動シグナリングと、関連するBGPピアリングSIDSコレクタ[RFC9086]を示しています。
* Section 4 overviews the components of a centralized BGP-EPE controller. The definition of the BGP-EPE controller is outside the scope of this document.
* セクション4は集中型BGP-EPEコントローラのコンポーネントを概説します。BGP-EPEコントローラの定義はこの文書の範囲外です。
* Section 5 overviews the methods that could be used by the centralized BGP-EPE controller to implement a BGP-EPE policy at an ingress border router or at a source host within the domain. The exhaustive definition of all the means to program a BGP-EPE input policy is outside the scope of this document.
* セクション5の概要集中BGP-EPEコントローラによって使用される可能性があるメソッドは、内蔵のボーダールータまたはドメイン内のソースホストでBGP-EPポリシーを実装する方法を示しています。BGP-EPE入力ポリシーをプログラムするためのすべての手段の徹底的な定義は、この文書の範囲外です。
For editorial reasons, the solution is described with IPv6 addresses and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS SIDs and also to IPv6 with native IPv6 SIDs.
編集上の理由から、解決策はIPv6アドレスとMPLS SIDSで説明されています。この解決策は、MPLS SIDSを使用してIPv4、およびネイティブIPv6 SIDSを使用してIPv6にも同様に適用できます。
The BGP-EPE problem statement is defined in [RFC7855].
BGP-EPE問題ステートメントは[RFC7855]で定義されています。
A centralized controller should be able to instruct an ingress Provider Edge (PE) router or a content source within the domain to use a specific egress PE and a specific external interface/neighbor to reach a particular destination.
集中型コントローラは、特定の出口PEと特定の外部インタフェース/ネイバーを使用して特定の宛先に到達するために、ドメイン内の入力プロバイダエッジ（PE）ルータまたはコンテンツソースを指示することができなければなりません。
Let's call this solution "BGP-EPE" for "BGP Egress Peer Engineering". The centralized controller is called the "BGP-EPE controller". The egress border router where the BGP-EPE traffic steering functionality is implemented is called a BGP-EPE-enabled border router. The input policy programmed at an ingress border router or at a source host is called a BGP-EPE policy.
「BGP Egress Peer Engineering」のためにこのソリューション「BGP-EPE」と呼びましょう。集中型コントローラは「BGP-EPEコントローラ」と呼ばれます。BGP-EPのトラフィックステアリング機能が実装されている出力境界ルータは、BGP-EPE対応の境界線ルータと呼ばれます。入力ポリシーは、入力ポリシーまたはソースホストでプログラムされています.BGP-EPEポリシーと呼ばれます。
The requirements that have motivated the solution described in this document are listed here below:
この文書に記載されている解決策をやる気になっている要件は以下のとおりです。
* The solution MUST apply to the Internet use case where the Internet routes are assumed to use IPv4 unlabeled or IPv6 unlabeled. It is not required to place the Internet routes in a VPN Routing and Forwarding (VRF) instance and allocate labels on a per-route or per-path basis.
* インターネットルートがIPv4の非標識またはIPv6を使用すると仮定されているインターネットのユースケースには、解決策が適用されなければなりません。インターネットルートをVPNルーティングおよび転送（VRF）インスタンスに配置し、ルートごとまたはパスごとにラベルを割り当てる必要はありません。
* The solution MUST support any deployed Internal BGP (iBGP) schemes (Route Reflectors (RRs), confederations, or iBGP full meshes).
* このソリューションは、展開された内部BGP（IBGP）スキーム（Route Reflectors（RRS）、コンシュレーション、またはIBGPフルメッシュ）をサポートしている必要があります。
* The solution MUST be applicable to both routers with external and internal peers.
* ソリューションは、外部ピアと内部ピアを持つ両方のルータに適用できます。
* The solution should minimize the need for new BGP capabilities at the ingress PEs.
* このソリューションは、入力PESで新しいBGP機能の必要性を最小限に抑える必要があります。
* The solution MUST accommodate an ingress BGP-EPE policy at an ingress PE or directly at a source within the domain.
* このソリューションは、入力PEで、またはドメイン内のソースで直接入力されたBGP-EPのポリシーを収容する必要があります。
* The solution MAY support automated Fast Reroute (FRR) and fast convergence mechanisms.
* 解決策は、自動高速Reroute（FRR）および高速収束メカニズムをサポートすることができる。
The following reference diagram is used throughout this document.
この文書全体では、次の参照図が使用されています。
+---------+ +------+
| | | |
| H B------D G
| | +---/| AS 2 |\ +------+
| |/ +------+ \ | |---L/8
A AS1 C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8
| | \\ +-E |/ +------+
| X | \\ | K
| | +===F AS 3 |
+---------+ +------+
Figure 1: Reference Diagram
図1：参照図
IP addressing:
IPアドレッシング：
* C's interface to D: 2001:db8:cd::c/64, D's interface: 2001:db8:cd::d/64
* CのD：2001：DB8：CD :: C / 64、D'Sインターフェース：2001：DB8：CD :: D / 64
* C's interface to E: 2001:db8:ce::c/64, E's interface: 2001:db8:ce::e/64
* CのE：2001：DB8：CE :: C / 64、Eのインターフェース：2001：DB8：CE :: E / 64
* C's upper interface to F: 2001:db8:cf1::c/64, F's interface: 2001:db8:cf1::f/64
* CのApper InterfaceからF：2001：CF1 :: C / 64、Fのインタフェース：2001：DB8：CF1 :: F / 64
* C's lower interface to F: 2001:db8:cf2::c/64, F's interface: 2001:db8:cf2::f/64
* Cの下のインタフェースF：2001：DB8：CF2 :: C / 64、Fのインタフェース：2001：DB8：CF2 :: F / 64
* BGP router-ID of C: 192.0.2.3
* BGPルータIDのC：192.0.2.3
* BGP router-ID of D: 192.0.2.4
* BGPルータID D：192.0.2.4
* BGP router-ID of E: 192.0.2.5
* BGP Router-ID E：192.0.2.5
* BGP router-ID of F: 192.0.2.6
* BGPルータID f：192.0.2.6
* Loopback of F used for External BGP (eBGP) multi-hop peering to C: 2001:db8:f::f/128
* 外部BGP（EBGP）マルチホップピアリングに使用されるFのループバック：2001：DB8：F :: F / 128
* C's loopback is 2001:db8:c::c/128 with SID 64
* Cのループバックは2001です.SID 64のDB8：C :: C / 128
C's BGP peering:
CのBGPピアリング：
* Single-hop eBGP peering with neighbor 2001:db8:cd::d (D)
* 隣接2001のシングルホップEBGPピアリング：DB8：CD :: D（D）
* Single-hop eBGP peering with neighbor 2001:db8:ce::e (E)
* 隣人2001：DB8：CE :: E（E）のシングルホップEBGPピアリング
* Multi-hop eBGP peering with F on IP address 2001:db8:f::f (F)
* IPアドレス2001でFを使用したマルチホップEBGPピアリング：DB8：F :: f（f）
C's resolution of the multi-hop eBGP session to F:
CのマルチホップEBGPセッションのF：
* Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f
* 2001への静的経路：DB8：F :: F / 128経由2001：DB8：CF1 :: F
* Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f
* 2001への静的経路：DB8：F / 128経由2001：DB8：CF2 :: F
C is configured with a local policy that defines a BGP PeerSet as the set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F).
Cは、BGP PeerSetを1組のピアとして定義するローカルポリシー（Eおよび2001：DB8：F :: F）として構成されています。
X is the BGP-EPE controller within the AS1 domain.
XはAS1ドメイン内のBGP-EPEコントローラです。
H is a content source within the AS1 domain.
hはAS1ドメイン内のコンテンツソースです。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
As defined in [RFC8402], certain segments are defined by a BGP-EPE-capable node and correspond to their attached peers. These segments are called BGP Peering Segments or BGP Peering SIDs. They enable the expression of source-routed inter-domain paths.
[RFC8402]で定義されているように、特定のセグメントはBGP-EPE対応ノードによって定義され、それらの接続ピアに対応しています。これらのセグメントはBGPピアリングセグメントまたはBGPピアリングSIDと呼ばれます。それらは、ソースルードドメイン間パスの表現を有効にします。
An ingress border router of an AS may compose a list of segments to steer a flow along a selected path within the AS, towards a selected egress border router C of the AS and through a specific peer. At minimum, a BGP Egress Peer Engineering policy applied at an ingress EPE involves two segments: the Node SID of the chosen egress EPE and then the BGP Peering Segment for the chosen egress EPE peer or peering interface.
ASの入力境界ルータは、特定のピアのASとそれを介した選択された出力境界ルータCに向かって、選択されたパスに沿って選択された経路に沿って流れるためのセグメントのリストを構成することができる。最低限、入口EPEで適用されるBGP出力ピア工学ポリシーは、選択された出力EPEのノードSID、次に選択された出力EPEピアまたはピアリングインターフェースのためのBGPピアリングセグメントの2つのセグメントを含む。
[RFC8402] defines three types of BGP Peering Segments/SIDs: PeerNode SID, PeerAdj SID, and PeerSet SID.
[RFC8402]は、Peernode SID、PeerAdj SID、およびPeerSet SIDの3種類のBGPピアリングセグメント/ SIDを定義します。
Peer Node Segment: A segment describing a peer, including the SID (PeerNode SID) allocated to it
ピアノードセグメント：それに割り当てられたSID（Peernode SID）を含むピアを記述するセグメント
Peer Adjacency Segment: A segment describing a link, including the SID (PeerAdj SID) allocated to it
ピア隣接部セグメント：それに割り当てられたSID（PeerAdj SID）を含むリンクを記述するセグメント
Peer Set Segment: A segment describing a link or a node that is part of the set, including the SID (PeerSet SID) allocated to the set
ピアセットセグメント：セットに割り当てられたSID（PeerSet SID）を含む、セットの一部であるリンクまたはノードを記述するセグメント
In ships-in-the-night mode with respect to the pre-existing iBGP design, a Border Gateway Protocol - Link State (BGP-LS) [RFC7752] session is established between the BGP-EPE-enabled border router and the BGP-EPE controller.
既存のIBGP設計に関する船内の船内モードでは、BGP-EPE対応の境界線ルータとBGP-の間にBGP-LS（BGP-LS）[RFC7752]セッションが確立されます。EPEコントローラ
As a result of its local configuration and according to the behavior described in [RFC9086], Node C allocates the following BGP Peering Segments [RFC8402]:
ローカル構成の結果として、[RFC9086]で説明されている動作に従って、ノードCは次のBGPピアリングセグメントを割り当てます[RFC8402]
* A PeerNode segment for each of its defined peers (D: 1012, E: 1022 and F: 1052).
* 定義されたピアのそれぞれのピアノードセグメント（D：1012、E：1022、F：1052）。
* A PeerAdj segment for each recursing interface to a multi-hop peer (e.g., the upper and lower interfaces from C to F in Figure 1).
* 各再帰インターフェースのピアージャセグメント（図1のCからFへの上限および下部のインターフェース）へのマルチホップピアへのインタフェース（例えば、CからFへの下部のインターフェース）。
* A PeerSet segment to the set of peers (E and F). In this case, the PeerSet represents a set of peers (E, F) belonging to the same AS (AS 3).
* ピアセットセグメントのセット（EとF）。この場合、PeerSetは（3）と同じに属するピア（E、F）の集合を表す。
C programs its forwarding table accordingly:
cプログラムはそれに応じて転送テーブルをプログラムします。
+================+===========+===============================+
| Incoming Label | Operation | Outgoing Interface |
+================+===========+===============================+
| 1012 | POP | link to D |
+----------------+-----------+-------------------------------+
| 1022 | POP | link to E |
+----------------+-----------+-------------------------------+
| 1032 | POP | upper link to F |
+----------------+-----------+-------------------------------+
| 1042 | POP | lower link to F |
+----------------+-----------+-------------------------------+
| 1052 | POP | load balance on any link to F |
+----------------+-----------+-------------------------------+
| 1060 | POP | load balance on any link to E |
| | | or to F |
+----------------+-----------+-------------------------------+
Table 1
表1
C signals each related BGP-LS instance of Network Layer Reachability Information (NLRI) to the BGP-EPE controller. Each such BGP-LS route is described in the following subsections according to the encoding details defined in [RFC9086].
Cは、BGP-EPEコントローラにネットワーク層到達可能性情報（NLRI）の各関連BGP-LSインスタンスをシグナリングします。そのようなBGP-Lの各ルートは、[RFC9086]で定義された符号化の詳細に従って以下のサブセクションに記載されている。
Descriptors:
記述子：
* Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3, AS1, 1000
* ローカルノード記述子（BGP Router-ID、ASN、BGP-LS識別子）：192.0.2.3、AS1,1000
* Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2
* リモートノード記述子（BGP Router-ID、ASN）：192.0.2.4、AS2
* Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cd::c, 2001:db8:cd::d
* リンク記述子（IPv6インタフェースアドレス、IPv6ネイバーアドレス）：2001：DB8：CD :: C、2001：DB8：CD :: D
Attributes:
属性：
* PeerNode SID: 1012
* Peernode SID：1012
Descriptors:
記述子：
* Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3, AS1, 1000
* ローカルノード記述子（BGP Router-ID、ASN、BGP-LS識別子）：192.0.2.3、AS1,1000
* Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3
* リモートノード記述子（BGP Router-ID、ASN）：192.0.2.5、AS3
* Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:ce::c, 2001:db8:ce::e
* リンク記述子（IPv6インタフェースアドレス、IPv6隣接アドレス）：2001：DB8：CE :: C、2001：DB8：CE :: E
Attributes:
属性：
* PeerNode SID: 1022
* Peernode SID：1022
* PeerSetSID: 1060
* ペースセツィイド：1060
* Link Attributes: see Section 3.3.2 of [RFC7752]
* リンク属性：[RFC7752]のセクション3.3.2を参照してください。
Descriptors:
記述子：
* Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3, AS1, 1000
* ローカルノード記述子（BGP Router-ID、ASN、BGP-LS識別子）：192.0.2.3、AS1,1000
* Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3
* リモートノード記述子（BGP Router-ID、ASN）：192.0.2.6、AS3
* Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:c::c, 2001:db8:f::f
* リンク記述子（IPv6インタフェースアドレス、IPv6ネイバーアドレス）：2001：DB8：C :: C、2001：DB8：F :: F
Attributes:
属性：
* PeerNode SID: 1052
* Peernode SID：1052
* PeerSetSID: 1060
* ペースセツィイド：1060
Descriptors:
記述子：
* Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3, AS1, 1000
* ローカルノード記述子（BGP Router-ID、ASN、BGP-LS識別子）：192.0.2.3、AS1,1000
* Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3
* リモートノード記述子（BGP Router-ID、ASN）：192.0.2.6、AS3
* Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf1::c, 2001:db8:cf1::f
* リンク記述子（IPv6インタフェースアドレス、IPv6ネイバーアドレス）：2001：DB8：CF1 :: C、2001：DB8：CF1 :: F
Attributes:
属性：
* PeerAdj-SID: 1032
* Peeradj-Sid：1032
* Link Attributes: see Section 3.3.2 of [RFC7752]
* リンク属性：[RFC7752]のセクション3.3.2を参照してください。
Descriptors:
記述子：
* Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3 , AS1, 1000
* ローカルノード記述子（BGP Router-ID、ASN、BGP-LS識別子）：192.0.2.3、AS1,1000
* Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3
* リモートノード記述子（ピアルータID、ピアASN）：192.0.2.6、AS3
* Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf2::c, 2001:db8:cf2::f
* リンク記述子（IPv6インタフェースアドレス、IPv6ネイバーアドレス）：2001：DB8：CF2 :: C、2001：DB8：CF2 :: F
Attributes:
属性：
* PeerAdj-SID: 1042
* Peeradj-Sid：1042
* Link Attributes: see Section 3.3.2 of [RFC7752]
* リンク属性：[RFC7752]のセクション3.3.2を参照してください。
A BGP-EPE-enabled border router MAY allocate an FRR backup entry on a per-BGP-Peering-SID basis. One example is as follows:
BGP-EPE対応の境界線ルータは、BGPピアリングSIDベースでFRRバックアップエントリを割り当てることができます。一例は以下の通りである。
* PeerNode SID
* Peernode SID
1. If multi-hop, back up via the remaining PeerADJ SIDs (if available) to the same peer.
1. マルチホップの場合は、残りのPeerAdj SID（使用可能な場合）を介して同じピアにバックアップします。
2. Else, back up via another PeerNode SID to the same AS.
2. そうでなければ、別のPeernode SIDと同じにバックアップします。
3. Else, pop the PeerNode SID and perform an IP lookup.
3. それ以外の場合は、Peernode SIDをポップしてIPルックアップを実行します。
* PeerAdj SID
* Peeradj SID
1. If to a multi-hop peer, back up via the remaining PeerADJ SIDs (if available) to the same peer.
1. マルチホップピアに、残りのPeerAdj SID（使用可能な場合）を介して同じピアにバックアップします。
2. Else, back up via a PeerNode SID to the same AS.
2. そうでなければ、Peernode SIDを介して同じにバックアップします。
3. Else, pop the PeerNode SID and perform an IP lookup.
3. それ以外の場合は、Peernode SIDをポップしてIPルックアップを実行します。
* PeerSet SID
* ピースセットサイド
1. Back up via remaining PeerNode SIDs in the same PeerSet.
1. 同じPeerset内の残りのPeernode SIDを介してバックアップします。
2. Else, pop the PeerNode SID and IP lookup.
2. それ以外の場合は、Peernode SIDとIPルックアップをポップします。
Let's illustrate different types of possible backups using the reference diagram and considering the Peering SIDs allocated by C.
参照図を使用して、Cによって割り当てられたピアリングSIDを考慮して、さまざまな種類のバックアップを説明しましょう。
PeerNode SID 1052, allocated by C for peer F:
Peer FのCによって割り当てられたPeernode SID1052：
* Upon the failure of the upper connected link CF, C can reroute all the traffic onto the lower CF link to the same peer (F).
* 上位接続リンクCFが故障したとき、Cはすべてのトラフィックを下部CFリンクに同じピア（F）に再ルーティングすることができる。
PeerNode SID 1022, allocated by C for peer E:
Peer EのCによって割り当てられたPeernode SID 1022：
* Upon the failure of the connected link CE, C can reroute all the traffic onto the link to PeerNode SID 1052 (F).
* 接続リンクCEが故障したとき、Cはリンク上のすべてのトラフィックをピアノードSID1052（f）に再実行することができる。
PeerNode SID 1012, allocated by C for peer D:
Peer DのCによって割り当てられたPeernode SID1012：
* Upon the failure of the connected link CD, C can pop the PeerNode SID and look up the IP destination address in its FIB and route accordingly.
* 接続されているリンクCDが故障したところ、CはPeernode SIDをポップし、それに応じてRouteのIP宛先アドレスを調べることができます。
PeerSet SID 1060, allocated by C for the set of peers E and F:
PeerSet SID 1060は、Cによって割り当てられたPIERS EとF：
* Upon the failure of a connected link in the group, the traffic to PeerSet SID 1060 is rerouted on any other member of the group.
* グループ内の接続リンクが故障したところ、PeerSet SID1060へのトラフィックは、グループの他のどのメンバーに再ルーティングされる。
For specific business reasons, the operator might not want the default FRR behavior applied to a PeerNode SID or any of its dependent PeerADJ SIDs.
特定のビジネス上の理由から、オペレータは、デフォルトのFRR動作をPeernode SIDまたはその依存PeerAdj SIDに適用したくない場合があります。
The operator should be able to associate a specific backup PeerNode SID for a PeerNode SID; e.g., 1022 (E) must be backed up by 1012 (D), which overrules the default behavior that would have preferred F as a backup for E.
オペレータは、Peernode SIDに特定のバックアップのPeernode SIDを関連付けることができるはずです。例えば、1022（e）は1012（D）によってバックアップされなければならず、これはEのバックアップとして優先的に優先されるデフォルトの動作をオーバーローする。
In this section, Let's provide a non-exhaustive set of inputs that a BGP-EPE controller would likely collect such as to perform the BGP-EPE policy decision.
このセクションでは、BGP-EPEコントローラがBGP-EPEポリシー決定を実行するように収集する可能性が高い網羅的な入力のセットを提供しましょう。
The exhaustive definition is outside the scope of this document.
徹底的な定義はこの文書の範囲外です。
The BGP-EPE controller should collect all the BGP paths (i.e., IP destination prefixes) advertised by all the BGP-EPE-enabled border routers.
BGP-EPEコントローラは、すべてのBGP-EPE対応の境界線ルータによってアドバタイズされたすべてのBGPパス（すなわちIP宛先プレフィックス）を収集する必要があります。
This could be realized by setting an iBGP session with the BGP-EPE-enabled border router, with the router configured to advertise all paths using BGP ADD-PATH [RFC7911] and the original next hop preserved.
これは、BGP-EPE対応の境界線ルータとIBGPセッションを設定することによって実現できます。ルータは、BGP Add-Path [RFC7911]と元のネクストホップを保持しているオリジナルのネクストホップを使用して、ルータがすべてのパスをアドバタイズします。
In this case, C would advertise the following Internet routes to the BGP-EPE controller:
この場合、Cは次のインターネットルートをBGP-EPEコントローラにアドバタイズします。
* NLRI <2001:db8:abcd::/48>, next hop 2001:db8:cd::d, AS Path {AS 2, 4}
* NLRI <2001：DB8：ABCD :: / 48>、ネクストホップ2001：DB8：CD :: D、パス{AS 2,4}
- X (i.e., the BGP-EPE controller) knows that C receives a path to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2.
- X（すなわち、BGP - EPEコントローラ）は、Cへのパスを2001に受信することを知っていることを知っていることを知っている.AS2の隣接2001：DB8：DB8：CD :: Dを介して、abcd :: / 48。
* NLRI <2001:db8:abcd::/48>, next hop 2001:db8:ce::e, AS Path {AS 3, 4}
* NLRI <2001：DB8：ABCD :: / 48>、Next Hop 2001：DB8 :: :: E、PATH {3,4}
- X knows that C receives a path to 2001:db8:abcd::/48 via neighbor 2001:db8:ce::e of AS2.
- Xは、隣接2001を介してCEW :: / 48を介してCのパスを受信することを知っています。
* NLRI <2001:db8:abcd::/48>, next hop 2001:db8:f::f, AS Path {AS 3, 4}
* NLRI <2001：DB8：ABCD :: / 48>、Next Hop 2001：DB8：F :: f、パス{3,4}
- X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 via neighbor 2001:db8:f::f.
- Xは、Cを介して、Cを介して、Cを介して、Cを知っていることを知っています.DB8：f :: f。を介してAS3を介してAS3を介して、DB8：ABCD :: / 48を知っています。
An alternative option would be for a BGP-EPE collector to use the BGP Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP-EPE-enabled border routers.
別の選択肢は、BGP-EPEコレクタがBGP監視プロトコル（BMP）[RFC7854]を使用してBGP-EPE対応の境界線ルータのADJ-RIB-INを追跡することです。
The BGP-EPE controller should collect the internal topology and the related IGP SIDs.
BGP-EPEコントローラは、内部トポロジと関連IGP SIDを収集する必要があります。
This could be realized by collecting the IGP Link-State Database (LSDB) of each area or running a BGP-LS session with a node in each IGP area.
これは、各エリアのIGP Link-Stateデータベース（LSDB）を収集したり、各IGP領域のノードとBGP-LSセッションを実行することで実現できます。
Thanks to the collected BGP-LS routes described in Section 3, the BGP-EPE controller is able to maintain an accurate description of the egress topology of Node C. Furthermore, the BGP-EPE controller is able to associate BGP Peering SIDs to the various components of the external topology.
セクション3に記載されている収集されたBGP-LSルートのおかげで、BGP-EPEコントローラは、ノードCの出力トポロジの正確な説明を維持することができます。さらに、BGP-EPEコントローラはBGPピアリングSIDSを様々に関連付けることができます。外部トポロジの構成要素
The BGP-EPE controller might collect Service Level Agreement (SLA) characteristics across peers. This requires a BGP-EPE solution, as the SLA probes need to be steered via non-best-path peers.
BGP-EPEコントローラは、ピア間でサービスレベル契約（SLA）特性を収集する可能性があります。SLAプローブを非ベストパスピアを介して操縦する必要があるので、これはBGP - EPE溶液を必要とする。
Unidirectional SLA monitoring of the desired path is likely required. This might be possible when the application is controlled at the source and the receiver side. Unidirectional monitoring dissociates the SLA characteristic of the return path (which cannot usually be controlled) from the forward path (the one of interest for pushing content from a source to a consumer and the one that can be controlled).
所望の経路の一方向SLAモニタリングが必要となる可能性があります。これは、アプリケーションがソース側と受信側で制御されているときに可能かもしれません。一方向監視は、往路から（通常制御されるものの1つと消費者から管理できるもの、および制御可能なもの）の復路のSLA特性を解離させる。
Alternatively, Metric Extensions, as defined in [RFC8570], could also be advertised using BGP-LS [RFC8571].
あるいは、[RFC8570]で定義されているメトリック拡張も、BGP-LS [RFC8571]を使用してアドバタイズすることもできます。
The BGP-EPE controller might collect the traffic matrix to its peers or the final destinations. IP Flow Information Export (IPFIX) [RFC7011] is a likely option.
BGP-EPEコントローラは、トラフィックマトリックスをそのピアまたは最終目的地に収集することがあります。IPフロー情報エクスポート（IPFIX）[RFC7011]は可能性のあるオプションです。
An alternative option consists of collecting the link utilization statistics of each of the internal and external links, also available in the current definition in [RFC7752].
別のオプションは、[RFC7752]の現在の定義でも利用可能な各内部リンクのリンク使用率統計を収集することから構成されています。
The BGP-EPE controller should be configured or collect business policies through any desired mechanisms. These mechanisms by which these policies are configured or collected are outside the scope of this document.
BGP-EPEコントローラは、任意のメカニズムを介してビジネスポリシーを設定または収集する必要があります。これらのポリシーが設定または収集されるこれらのメカニズムは、この文書の範囲外です。
On the basis of all these inputs (and likely others), the BGP-EPE controller decides to steer some demands away from their best BGP path.
これらすべての入力に基づいて（そしておそらく他のもの）、BGP-EPEコントローラは、それらの最良のBGP経路からいくつかの要求を離れて操縦することを決定します。
The BGP-EPE policy is likely expressed as a two-entry segment list where the first element is the IGP Prefix-SID of the selected egress border router and the second element is a BGP Peering SID at the selected egress border router.
BGP-EPEポリシーは、最初の要素が選択された出力境界ルータのIGPプレフィックスSIDであり、2番目の要素は選択された出力境界ルータのBGPピアリングSIDである2エントリセグメントリストとして表されます。
A few examples are provided hereafter:
以下にいくつかの例が提供されています。
* Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID of PE C as defined in Section 1.1.
* EGRESS PE CとピアをAS2として好む：{64,1012}。「64」は、セクション1.1で定義されているようにPE CのSIDである。
* Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, {64, 1022}.
* EBGPピア2001を介してEGRESS PE Cとピアを添付してください.DB8：CE :: E、{64,1022}。
* Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, {64, 1052}.
* EBGPピア2001を介してEGRESS PE Cとピアを好む：DB8：F :: f、{64,1052}。
* Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f of multi-hop eBGP peer 2001:db8:f::f, {64, 1042}.
* インターフェース2001を介してEGRESS PE CおよびPeerをAS3として優先します.DB8：F :: f、{64,1042}。
* Prefer egress PE C and any interface to any peer in the group 1060: {64, 1060}.
* グループ1060の任意のピアへの出力PE Cと任意のインタフェースを好む：{64,1060}。
Note that the first SID could be replaced by a list of segments. This is useful when an explicit path within the domain is required for traffic-engineering purposes. For example, if the Prefix-SID of Node B is 60 and the BGP-EPE controller would like to steer the traffic from A to C via B then through the external link to peer D, then the segment list would be {60, 64, 1012}.
最初のSIDはセグメントのリストに置き換えることができます。これは、ドメイン内の明示的なパスがトラフィックエンジニアリングの目的に必要な場合に役立ちます。たとえば、ノードBの接頭辞-SIDが60で、BGP-EPEコントローラがAからBへのトラフィックをBからBへのトラフィックを移動してから、セグメントリストは{60,64にします。、1012}。
The detailed/exhaustive description of all the means to implement a BGP-EPE policy are outside the scope of this document. A few examples are provided in this section.
BGP-EPEポリシーを実装するためのすべての手段の詳細な/徹底的な説明は、この文書の範囲外です。このセクションにはいくつかの例があります。
A static IP/MPLS route can be programmed at the host H. The static route would define a destination prefix, a next hop, and a label stack to push. Assuming the same Segment Routing Global Block (SRGB), at least on all access routers connecting the hosts, the same policy can be programmed across all hosts, which is convenient.
静的IP / MPLSルートはホストHでプログラムできます。静的ルートは、宛先プレフィックス、ネクストホップ、およびプッシュするラベルスタックを定義します。同じセグメントルーティンググローバルブロック（SRGB）を仮定すると、少なくともホストを接続するすべてのアクセスルータでは、同じポリシーをすべてのホストにわたってプログラムできます。これは便利です。
The BGP-EPE controller can configure the ingress border router with an SR traffic-engineering tunnel T1 and a steering policy S1, which causes a certain class of traffic to be mapped on the tunnel T1.
BGP-EPEコントローラは、SRトラフィックエンジニアリングトンネルT1とステアリングポリシーS1を使用して入力ボーダールータを設定でき、これにより特定のクラスのトラフィックがトンネルT1にマッピングされます。
The tunnel T1 would be configured to push the required segment list.
トンネルT1は、必要なセグメントリストをプッシュするように構成されます。
The tunnel and the steering policy could be configured via multiple means. A few examples are given below:
トンネルとステアリングポリシーは、複数の手段を介して設定できます。いくつかの例を以下に示します。
* The Path Computation Element Communication Protocol (PCEP) according to [RFC8664] and [RFC8281]
* [RFC8664]と[RFC8281]に準拠したパス計算要素通信プロトコル（PCE）
* NETCONF [RFC6241]
* NETCONF [RFC6241]
* Other static or ephemeral APIs
* その他の静的またはエフェメラルAPI
Example: at router A (Figure 1).
例：ルーターA（図1）で。
Tunnel T1: push {64, 1042}
IP route L/8 set next-hop T1
The BGP-EPE controller could build a unicast route labeled using BGP [RFC8277] (from scratch) and send it to the ingress router.
BGP-EPEコントローラは、BGP [RFC8277]を使用してラベル付けされたユニキャストルートをビルドして（スクラッチから）入力ルータに送信できます。
Such a route would require the following:
そのような経路は次のことを必要とするでしょう：
NLRI the destination prefix to engineer (e.g., L/8)
NLRI宛先プレフィックスをエンジニアにプレフィックス（E.g.、L / 8）
Next Hop the selected egress border router: C
次に選択した出力境界ルーター：C.
Label the selected egress peer: 1042
選択した出力ピア：1042にラベルを付けます
Autonomous System (AS) path the selected valid AS path
自律システム（AS）パス選択されたパスとして有効
Some BGP policy to ensure it will be selected as best by the ingress router. Note that as discussed in Section 5 of [RFC8277], the comparison of a labeled and unlabeled unicast BGP route is implementation dependent and hence may require an implementation-specific policy on each ingress router.
それを確実に選択されるようにするためのいくつかのBGPポリシー。[RFC8277]のセクション5で説明されているように、ラベル付きおよび非標識ユニキャストBGPルートの比較は実装に依存しており、したがって各入力ルータで実装固有のポリシーが必要になる場合があります。
This unicast route labeled using BGP [RFC8277] "overwrites" an equivalent or less-specific "best path". As the best path is changed, this BGP-EPE input policy option may influence the path propagated to the upstream peer/customers. Indeed, implementations treating the SAFI-1 and SAFI-4 routes for a given prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route to their BGP upstream peers.
BGP [RFC8277]を使用してラベル付けされたこのユニキャストルートは、「上書き」と同等の「最高のパス」を上書きします。最良のパスが変更されると、このBGP-EPE入力ポリシーオプションは、アップストリームピア/顧客に伝播されたパスに影響を与える可能性があります。実際、実装は、特定のプレフィックスのSAFI-1とSAFI-4ルートを扱うことで、BGPアップストリームピアへのSAFI-1ルートのBGP撤回を引き起こします。
The BGP-EPE controller could build a VPNv4 route (from scratch) and send it to the ingress router.
BGP-EPEコントローラは（スクラッチから）VPNV4ルートを作成して入力ルータに送信できます。
Such a route would require the following:
そのような経路は次のことを必要とするでしょう：
NLRI the destination prefix to engineer: e.g., L/8
NLRIエンジニアへの移行先プレフィックス：例えばL / 8
Next Hop the selected egress border router: C
次に選択した出力境界ルーター：C.
Label the selected egress peer: 1042
選択した出力ピア：1042にラベルを付けます
Route-Target the selected appropriate VRF instance at the ingress router
ルート対象入力ルータで選択された適切なVRFインスタンス
AS path the selected valid AS path
選択した有効なパスとしてパスとして
Some BGP policy to ensure it will be selected as best by the ingress router in the related VRF instance.
関連するVRFインスタンス内の入力ルータで最適に選択されるようにするためのいくつかのBGPポリシー。
The related VRF instance must be preconfigured. A VRF fallback to the main FIB might be beneficial to avoid replicating all the "normal" Internet paths in each VRF instance.
関連するVRFインスタンスは事前設定されている必要があります。メインFIBへのVRFフォールバックは、各VRFインスタンス内のすべての「通常の」インターネットパスを複製しないようにするために有益です。
The described solution is applicable to IPv6, either with MPLS-based or IPv6-native segments. In both cases, the same three steps of the solution are applicable:
説明された解決策は、MPLSベースまたはIPv6ネイティブセグメントを使用して、IPv6に適用可能です。どちらの場合も、同じ3段階の解決策が適用可能です。
* BGP-LS-based signaling of the external topology and BGP Peering Segments to the BGP-EPE controller.
* BGP-LSベースの外部トポロジーとBGPピアリングセグメントのBGP-EPEコントローラへのシグナリング
* Collecting, by the BGP-EPE controller, various inputs to come up with a policy decision.
* BGP-EPEコントローラによって、政策決定が得られたさまざまな入力によって収集されます。
* Programming at an ingress router or source host of the desired BGP-EPE policy, which consists of a list of segments to push on a defined traffic class.
* 定義されたトラフィッククラスをプッシュするためのセグメントのリストからなる、希望のBGP-EPEポリシーの入力ルータまたはソースホストでのプログラミング。
The BGP-EPE solutions described in this document have the following benefits:
この文書に記載されているBGP-EPEソリューションには、次のような利点があります。
* No assumption on the iBGP design within AS1.
* AS1内のIBGP設計上の仮定はありません。
* Next-hop-self on the Internet routes propagated to the ingress border routers is possible. This is a common design rule to minimize the number of IGP routes and to avoid importing external churn into the internal routing domain.
* インターネット経路上のNext-Hop-Self Engressボーダールータに伝播できます。これは、IGPルートの数を最小限に抑え、内部ルーティングドメインへの外部チャーンのインポートを避けるための一般的な設計規則です。
* Consistent support for traffic engineering within the domain and at the external edge of the domain.
* ドメイン内およびドメインの外部エッジ内のトラフィックエンジニアリングの一貫したサポート。
* Support for both host and ingress border router BGP-EPE policy programming.
* ホストと入力ボーダールータBGP-EPEポリシープログラミングの両方のサポート。
* BGP-EPE functionality is only required on the BGP-EPE-enabled egress border router and the BGP-EPE controller; an ingress policy can be programmed at the ingress border router without any new functionality.
* BGP-EPE機能は、BGP-EPE対応の出力ボーダールータとBGP-EPEコントローラでのみ必要です。入力ポリシーは、新しい機能なしで入力ボーダールータでプログラムできます。
* Ability to deploy the same input policy across hosts connected to different routers (assuming the global property of IGP Prefix-SIDs).
* 異なるルータに接続されているホスト間で同じ入力ポリシーを展開する機能（IGPプレフィックスSIDSのグローバルプロパティを想定して）。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The BGP-EPE use case described in this document requires BGP-LS [RFC7752] extensions that are described in [RFC9086] and that consists of additional BGP-LS descriptors and TLVs. Manageability functions of BGP-LS, described in [RFC7752], also apply to the extensions required by the EPE use case.
このドキュメントに記載されているBGP-EPEの使用例には、[RFC9086]で説明されているBGP-LS [RFC7752]拡張子が必要であり、追加のBGP-LS記述子とTLVSで構成されています。[RFC7752]に記載されているBGP-LSの管理性機能は、EPEユースケースに必要な拡張機能にも適用されます。
Additional manageability considerations are described in [RFC9086].
追加の管理性の考慮事項は[RFC9086]に記載されています。
[RFC7752] defines BGP-LS NLRI instances and their associated security aspects.
[RFC7752] BGP-LS NLRIインスタンスとそれらに関連するセキュリティ側面を定義します。
[RFC9086] defines the BGP-LS extensions required by the BGP-EPE mechanisms described in this document. BGP-EPE BGP-LS extensions also include the related security.
[RFC9086]このドキュメントに記載されているBGP-EPEメカニズムに必要なBGP-LS拡張機能を定義します。BGP-EPE BGP-LS拡張には、関連セキュリティも含まれます。
[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>。
[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>。
[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>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/ RFC8402、2018年7月、<https：//www.rfc-editor.org/info/rfc8402>。
[RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, <https://www.rfc-editor.org/info/rfc9086>.
[RFC9086] Previdi、S.、Talaulikar、K。、ED。、Filsfils、C.、Patel、K.、Ray、S.、およびJ.Dong、「Border Gatewayプロトコル - リンク状態（BGP-LS）拡張子（BGP-LS）拡張子セグメントルーティングBGP Egress Peer Engineering "、RFC 9086、DOI 10.17487 / RFC9086、2021年8月、<https：//www.rfc-editor.org/info/rfc9086>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B、ED。、Trammell、B.、Ed。、およびP.Aitken、「フロー情報交換のIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、DOI 10.17487 / RFC7011、2013年9月、<https：//www.rfc-editor.org/info/rfc7011>。
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/info/rfc7854>.
[RFC7854] Scudder、J.、Ed。、Fernando、R.、およびS. Stuart、「BGPモニタリングプロトコル（BMP）」、RFC 7854、DOI 10.17487 / RFC7854、2016年6月、<https：//www.rfc-editor.org/info/rfc7854>。
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7855] PREVIDI、S、ED。、FILSFILS、C、ED。、Decraene、B.、Litkowski、S.、Horneffer、M.、およびR. Shakir、ネットワーキング（Spring）問題ステートメントのソースパケットルーティングそして、要件 "、RFC 7855、DOI 10.17487 / RFC7855、2016年5月、<https：//www.rfc-editor.org/info/rfc7855>。
[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>。
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
[RFC8277] Rosen、E.、「MPLSラベルをアドレスプレフィックスにバインドするためのBGPの使用」、RFC 8277、DOI 10.17487 / RFC8277、2017年10月、<https://www.rfc-editor.org/info/rfc8277>。
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S.、およびR. Varga、ステートフルPCEモデルにおけるPCE開始LSPセットアップのための「PCEP演算要素通信プロトコル（PCE）拡張」、RFC 8281、DOI2017487 / RFC8281、2017年12月、<https：//www.rfc-editor.org/info/rfc8281>。
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8570] Ginsberg、L.、Ed。、Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J.、およびQ. WU、 "IS IS IS Traffic Engineering（TE）メトリック拡張"、RFC 8570、DOI 10.17487 / RFC8570、2019年3月、<https://www.rfc-editor.org/info/rfc8570>。
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.
[RFC8571] Ginsberg、L.、ED。、Previdi、S.、Wu、Q.、Tantsura、J.、およびC.Filsfils、「BGP - Link State（BGP - LS）広告のIGPトラフィックエンジニアリングメトリック拡張機能」、RFC 8571、DOI 10.17487 / RFC8571、2019年3月、<https：//www.rfc-editor.org/info/rfc8571>。
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.
[RFC8664] Sivabalan、S、Filsfils、C、Tantura、J.、HenderickX、W.、およびJ.Hormwick、セグメントルーティングのためのPATH計算要素通信プロトコル（PCE）拡張（PCE）、RFC 8664、DOI 10.17487 / RFC86642019年12月、<https：//www.rfc-editor.org/info/rfc8664>。
Acknowledgements
謝辞
The authors would like to thank Acee Lindem for his comments and contribution.
著者らは彼のコメントと貢献のためにAcee Lindemに感謝したいと思います。
Contributors
貢献者
Daniel Ginsburg substantially contributed to the content of this document.
Daniel Ginsburgは実質的にこの文書の内容に貢献しました。
Authors' Addresses
著者の住所
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（編集）Cisco Systems、Inc。ブリュッセルベルギー
Email: cfilsfil@cisco.com
Stefano Previdi Cisco Systems, Inc. Italy
Stefano Previdi Cisco Systems、Inc。イタリア
Email: stefano@previdi.net
Gaurav Dawra (editor) Cisco Systems, Inc. United States of America
Gaurav Dawra（編集）Cisco Systems、Inc。アメリカ合衆国
Email: gdawra.ietf@gmail.com
Ebben Aries Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Ebben Aries Juniper Networks 1133イノベーションウェイSunnyvale、CA 94089アメリカ合衆国
Email: exa@juniper.net
Dmitry Afanasiev Yandex Russian Federation
Dmitry Afanasiv Yandexロシア連邦連邦
Email: fl0w@yandex-team.ru