Internet Engineering Task Force (IETF) K. Vairavakkalai, Ed.
Request for Comments: 9832 N. Venkataraman, Ed.
Category: Experimental Juniper Networks, Inc.
ISSN: 2070-1721 September 2025
This document specifies a mechanism referred to as "Intent-Driven Service Mapping". The mechanism uses BGP to express Intent-based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes" or "TCs"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in the TEAS Network Slices framework (RFC 9543).
このドキュメントは、「意図駆動型のサービスマッピング」と呼ばれるメカニズムを指定します。このメカニズムは、BGPを使用して、特定のサービスレベル契約（SLA）を満たす特定の交通工学（TE）特性を持つアンダーレイルートとの意図ベースの関連性を表現します。これは、十分に類似したTE特性を持つルートを識別可能なクラス（「トランスポートクラス」または「TCS」と呼ばれる）にグループ化するルートをグループ化するために新しいコンストラクトを定義することによって達成されます。これは、サービスエンドポイントに到達可能性（解像度スキーム）を解決するために順序付けられたセットとして使用されます。これらのコンストラクトは、たとえば、TEASネットワークスライスフレームワーク（RFC 9543）で定義されている「IETFネットワークスライス」を実現するために使用できます。
Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages the procedures described in RFC 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)") and follows the NLRI encoding described in RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") is defined to enable each advertised underlay route to be identified by its class. This new address family is called "BGP Classful Transport" (or "BGP CT").
さらに、このドキュメントは、複数の協力管理ドメインにまたがる可能性のあるネットワーク内のサービスマッピング情報の普及を可能にするBGPのプロトコル手順を指定します。これらのドメインは、同じプロバイダーまたはプロバイダーを綿密に調整することによって管理される場合があります。RFC 4364（「BGP/MPLS IP仮想ネットワーク（VPNS）」）に記載されている手順を活用し、RFC 8277（「BGPを使用してMPLSラベルをバインドしてプレフィックスに対処する）に従うNLRIエンコードに従う新しいBGPアドレスファミリは、クラスによって有効になります。この新しいアドレスファミリは、「BGPクラスフルトランスポート」（または「BGP CT」）と呼ばれます。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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/rfc9832.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9832で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
2.1. Abbreviations
2.2. Definitions and Notations
2.3. Requirements Language
3. Architecture Overview
4. Transport Class
4.1. Classifying TE Tunnels
4.2. Transport Route Database (TRDB)
4.3. Transport Class Route Target
5. Resolution Scheme
5.1. Mapping Community
6. BGP Classful Transport Family
6.1. NLRI Encoding
6.2. Next Hop Encoding
6.3. Carrying Multiple Types of Encapsulation Information
6.4. Comparison with Other Families Using Encoding from RFC 8277
7. Protocol Procedures
7.1. Preparing the Network to Deploy Classful Transport Planes
7.2. Originating BGP CT Routes
7.3. Processing BGP CT Routes by Ingress Nodes
7.4. Readvertising BGP CT Route by Border Nodes
7.5. Border Nodes Receiving BGP CT Routes on EBGP
7.6. Avoiding Path Hiding Through Route Reflectors
7.7. Avoiding Loops Between Route Reflectors in Forwarding Paths
7.8. Ingress Nodes Receiving Service Routes with a Mapping
Community
7.9. Best-Effort Transport Class
7.10. Interaction with BGP Attributes Specifying Next Hop Address
and Color
7.11. Applicability to Flowspec Redirect-to-IP
7.12. Applicability to IPv6
7.13. SRv6 Support
7.14. Error-Handling Considerations
8. Illustration of BGP CT Procedures
8.1. Reference Topology
8.2. Service Layer Route Exchange
8.3. Transport Layer Route Propagation
8.4. Data Plane View
8.4.1. Steady State
8.4.2. Local Repair of Primary Path
8.4.3. Absorbing Failure of the Primary Path: Fallback to
Best-Effort Tunnels
9. Scaling Considerations
9.1. Avoiding Unintended Spread of BGP CT Routes Across Domains
9.2. Constrained Distribution of PNHs to SNs (On-Demand Next
Hop)
9.3. Limiting the Visibility Scope of PE Loopback as PNHs
10. Operations and Manageability Considerations
10.1. MPLS OAM
10.2. Usage of RD and Label-Allocation Modes
10.3. Managing Transport-Route Visibility
11. Deployment Considerations
11.1. Coordination Between Domains Using Different Community
Namespaces
11.2. Managing Intent at Service and Transport Layers
11.2.1. Service Layer Color Management
11.2.2. Non-Agreeing Color Transport Domains
11.2.3. Heterogeneous Agreeing Color Transport Domains
11.3. Migration Scenarios
11.3.1. BGP CT Islands Connected via BGP LU Domain
11.3.2. BGP CT: Interoperability Between MPLS and Other
Forwarding Technologies
11.4. MTU Considerations
11.5. Use of DSCP
12. Applicability to Network Slicing
13. IANA Considerations
13.1. New BGP SAFI
13.2. New Format for BGP Extended Community
13.2.1. Existing Registries
13.2.2. New Registries
13.3. MPLS OAM Code Points
14. Transport Class ID Registry
15. Security Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. Extensibility Considerations
A.1. Signaling Intent over a PE-CE Attachment Circuit
A.2. BGP CT Egress TE
Appendix B. Applicability to Intra-AS and Different Inter-AS
Deployments
B.1. Intra-AS Use Case
B.1.1. Topology
B.1.2. Transport Layer
B.1.3. Service Layer Route Exchange
B.2. Inter-AS Option A Use Case
B.2.1. Topology
B.2.2. Transport Layer
B.2.3. Service Layer Route Exchange
B.3. Inter-AS Option B Use Case
B.3.1. Topology
B.3.2. Transport Layer
B.3.3. Service Layer Route Exchange
Appendix C. Why reuse RFCs 8277 and 4364?
C.1. Update Packing Considerations
Appendix D. Scaling Using BGP MPLS Namespaces
Acknowledgements
Contributors
Authors' Addresses
Provider networks typically span across multiple domains where each domain can either represent an Autonomous System (AS) or an Interior Gateway Protocol (IGP) region within an AS. In these networks, several services are provisioned between different pairs of service endpoints (e.g., Provider Edge (PE) nodes) that can be either in the same domain or across different domains.
プロバイダーネットワークは通常、各ドメインがAS内の自律システム（AS）または内部ゲートウェイプロトコル（IGP）領域を表すことができる複数のドメインにまたがっています。これらのネットワークでは、同じドメインまたは異なるドメインにまたがる可能性のあるサービスエンドポイント（例：プロバイダーエッジ（PE）ノードなど）のペア間でいくつかのサービスがプロビジョニングされます。
[RFC9315] defines "Intent" as:
[RFC9315]は「意図」を次のように定義します。
A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them.
一連の運用目標（ネットワークが満たすべき）と結果（ネットワークが提供することになっている）は、それらを達成または実装する方法を指定せずに宣言的な方法で定義します。
This document prescribes constructs and procedures to realize "Intent" and enable provider networks to forward service traffic based on service-specific Intent from end-to-end across service endpoints.
このドキュメントは、「意図」を実現し、プロバイダーネットワークがサービスエンドポイント全体のエンドツーエンドからのサービス固有の意図に基づいてサービストラフィックを転送できるようにするための構成と手順を規定しています。
The mechanisms described in this document achieve "Intent-Driven Service Mapping" between any pair of service endpoints by:
このドキュメントで説明されているメカニズムは、以下のサービスエンドポイントのペア間で「意図駆動型サービスマッピング」を実現します。
* Provisioning end-to-end "Intent-aware" paths using BGP. For example, a low-latency path or a best-effort path.
* BGPを使用して、エンドツーエンドの「意図アウェア」パスをプロビジョニングします。たとえば、低遅延パスまたは最良のパス。
* Expressing a desired Intent. For example, use a low-latency path with a fallback to the best-effort path.
* 望ましい意図を表現する。たとえば、最良のエフォルトパスへのフォールバックを備えた低遅延パスを使用します。
* Forwarding service traffic "only" using end-to-end "Intent-aware" paths honoring that desired Intent.
* サービスのトラフィックは、その希望する意図を称えるエンドツーエンドの「意図的な」パスを使用して「のみ」。
The constructs and procedures defined in this document apply equally to intra-AS and inter-AS (a.k.a. multi-AS) deployments in the style of option A, option B, and option C (Section 10 of [RFC4364]) in provider networks.
このドキュメントで定義されている構成要素と手順は、プロバイダーネットワークのオプションA、オプションB、およびオプションC（[RFC4364]のセクション10）のスタイルで、AS内およびAS（別名Multi-AS）の展開に等しく適用されます。
Such networks provision intra-domain transport tunnels between a pair of endpoints, typically a service node or a border node that service traffic traverses through. These tunnels are signaled using various tunneling protocols depending on the forwarding architecture used in the domain, which can be Multiprotocol Label Switching (MPLS), Internet Protocol version 4 (IPv4), or Internet Protocol version 6 (IPv6).
このようなネットワークは、ドメイン内輸送トンネルのペアのエンドポイント、通常はサービスノードまたはサービストラフィックが通過するボーダーノードの間のトンネルを提供します。これらのトンネルは、ドメインで使用される転送アーキテクチャに応じて、さまざまなトンネルプロトコルを使用してシグナル伝達されます。これは、マルチプロトコルラベルスイッチング（MPLS）、インターネットプロトコルバージョン4（IPv4）、またはインターネットプロトコルバージョン6（IPv6）です。
The mechanisms defined in this document allow different tunneling technologies to become TC aware. These can be applied homogeneously to intra-domain tunneling technologies used in existing brownfield networks as well as new greenfield networks. For clarity, only some tunneling technologies are detailed in this document. In some examples, only MPLS Traffic Engineering (TE) is described. Other tunneling technologies have been described in detail in other documents (and only an overview has been included in this document). For example, the details for Segment Routing over IPv6 (SRv6) are provided in [BGP-CT-SRv6] and an overview is provided in Section 7.13.
このドキュメントで定義されているメカニズムにより、さまざまなトンネリング技術がTCを認識できるようになります。これらは、既存のブラウンフィールドネットワークや新しいグリーンフィールドネットワークで使用されるドメイン内トンネルテクノロジーに均一に適用できます。明確にするために、このドキュメントでは、一部のトンネル技術のみが詳しく説明されています。いくつかの例では、MPLSトラフィックエンジニアリング（TE）のみが説明されています。他のトンネル技術は、他のドキュメントで詳細に説明されています（そして、このドキュメントには概要のみが含まれています）。たとえば、IPv6（SRV6）を介したセグメントルーティングの詳細は[BGP-CT-SRV6]で提供されており、概要はセクション7.13に記載されています。
Customers need to be able to express desired Intent to the network, and the network needs to have constructs able to enact the customer's Intent. The network constructs defined in this document are used to classify and group these intra-domain tunnels based on various characteristics, like TE characteristics (e.g., low-latency), into identifiable classes that can pass "Intent-aware" traffic. These constructs enable services to signal their Intent to use one or more identifiable classes and mechanisms to selectively map traffic onto "Intent-aware" tunnels for these classes.
顧客はネットワークに望ましい意図を表明できる必要があり、ネットワークは顧客の意図を制定できる構成要素を持つ必要があります。このドキュメントで定義されているネットワークコンストラクトは、TE特性（低遅延）などのさまざまな特性に基づいて、これらのドメイン内トンネルを分類およびグループ化して、「意図的な」トラフィックに合格できる識別可能なクラスに分類します。これらのコンストラクトにより、サービスは、1つまたは複数の識別可能なクラスとメカニズムを使用して、これらのクラスの「意図的な」トンネルにトラフィックを選択的にマッピングすることを目的とすることができます。
This document introduces a new BGP address family called "BGP Classful Transport (BGP CT)", which extends/stitches Intent-aware intra-domain tunnels belonging to the same class across domain boundaries to establish end-to-end Intent-aware paths between service endpoints.
このドキュメントでは、「BGP Classful Transport（BGP CT）」と呼ばれる新しいBGPアドレスファミリを紹介します。これは、ドメインの境界を越えて同じクラスに属する意図的な意図的なドメイン内トンネルを拡張/ステッチして、サービスエンドポイント間のエンドツーエンドの意図的なパスを確立します。
[Intent-Routing-Color] describes various use cases and applications of the procedures described in this document.
[Intent-routing-color]は、このドキュメントに記載されている手順のさまざまなユースケースとアプリケーションについて説明しています。
Appendix C provides an outline of the design philosophy behind this specification. In particular, readers who are already familiar with one or more BGP VPN technologies may want to review this appendix before reading the main body of the specification.
付録Cは、この仕様の背後にある設計哲学の概要を示しています。特に、1つ以上のBGP VPNテクノロジーにすでに精通している読者は、仕様の本体を読む前にこの付録を確認することをお勧めします。
ABR:
ABR:
Area Border Router (readvertises BGP CT or BGP LU routes with NH self)
エリアボーダールーター（NHセルフを備えたBGP CTまたはBGP LUルートのReadvertise）
AFI:
AFI:
Address Family Identifier
住所ファミリ識別子
AS:
AS:
Autonomous System
自律システム
ASBR:
ASBR：
Autonomous System Border Router
自律システムボーダールーター
ASN:
ASN:
Autonomous System Number
自律システム番号
BGP VPN:
BGP VPN：
VPNs built using RD or RT; architecture described in [RFC4364]
RDまたはRTを使用して構築されたVPN。[RFC4364]に記載されているアーキテクチャ
BGP LU:
BGP LU：
BGP Labeled Unicast family (AFI/SAFIs 1/4, 2/4)
ユニキャストファミリーとラベル付けされたBGP（AFI/SAFIS 1/4、2/4）
BGP CT:
BGP CT：
BGP Classful Transport family (AFI/SAFIs 1/76, 2/76)
BGPクラスフルトランスポートファミリー（AFI/SAFIS 1/76、2/76）
BN:
BN:
Border Node
ボーダーノード
CBF:
CBF:
Class-Based Forwarding
クラスベースの転送
CCA:
CCA:
Community Carrying Attribute
コミュニティの運搬属性
CsC:
CsC:
Carriers' Carriers (serving the Carrier VPN)
キャリアのキャリア（キャリアVPNにサービスを提供）
DSCP:
DSCP：
Differentiated Services Code Point
差別化されたサービスコードポイント
EP:
EP:
Endpoint (of a tunnel, e.g., a loopback address in the network)
エンドポイント（トンネルの、たとえば、ネットワーク内のループバックアドレス）
EPE:
EPE:
Egress Peer Engineering
出力ピアエンジニアリング
eSN:
eSN:
Egress Service Node
出力サービスノード
FEC:
FEC:
Forwarding Equivalence Class
等価クラスを転送します
FRR:
FRR:
Fast Reroute (Preprogrammed NH leg in forwarding)
高速ルート（転送中の事前にプログラムされたNH脚）
iSN:
iSN:
Ingress Service Node
イングレスサービスノード
L-ISIS:
L-ISIS：
Labeled ISIS (see RFC 8667)
ラベル付きISIS（RFC 8667を参照）
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
NH:
NH:
Next Hop
次のホップ
NLRI:
NLRI：
Network Layer Reachability Information
ネットワークレイヤーの到達可能性情報
PE:
PE:
Provider Edge
プロバイダーエッジ
PIC:
PIC:
Prefix Independent Convergence
接頭辞独立コンバージェンス
PNH:
PNH:
Protocol Next Hop (address carried in a BGP UPDATE message)
Protocol Next Hop（BGPアップデートメッセージに掲載されたアドレス）
RD:
RD:
Route Distinguisher
ルートの違い
RD:EP:
RD：EP：
Route Distinguisher and Endpoint (in a BGP Prefix)
ルートの違いとエンドポイント（BGPプレフィックス内）
RSVP-TE:
RSVP-TE：
Resource Reservation Protocol - Traffic Engineering
リソース予約プロトコル - トラフィックエンジニアリング
RT:
RT:
Route Target (as used in Route Target extended community)
ルートターゲット（ルートターゲット拡張コミュニティで使用）
RTC:
RTC:
Route Target Constraint [RFC4684]
ルートターゲット制約[RFC4684]
SAFI:
サフィ：
Subsequent Address Family Identifier
後続のアドレスファミリ識別子
SID:
SID:
Segment Identifier
セグメント識別子
SLA:
SLA:
Service Level Agreement
サービスレベル契約
SN:
SN:
Service Node
サービスノード
SR:
SR:
Segment Routing
セグメントルーティング
SRTE:
SRTE：
Segment Routing Traffic Engineering
セグメントルーティングトラフィックエンジニアリング
TC:
TC:
Transport Class
トランスポートクラス
TC ID:
TC ID：
Transport Class Identifier
トランスポートクラス識別子
TC-BE:
TC-BE：
Transport Class - Best Effort
トランスポートクラス - 最善の努力
TE:
TE:
Traffic Engineering
交通工学
TEA:
TEA:
Tunnel Encapsulation Attribute (attribute code 23)
トンネルカプセル化属性（属性コード23）
TRDB:
TRDB：
Transport Route Database
輸送ルートデータベース
UHP:
UHP:
Ultimate Hop Popping
究極のホップポップ
VRF:
VRF:
Virtual Routing and Forwarding (used with a table)
仮想ルーティングと転送（テーブルで使用）
BGP CCA:
BGP CCA：
A BGP attribute that carries community. Examples of BGP CCAs are COMMUNITIES (attribute code 8), EXTENDED COMMUNITIES (attribute code 16), IPv6 Address Specific Extended Community (attribute code 25), and LARGE_COMMUNITY (attribute code 32).
コミュニティを運ぶBGP属性。BGP CCAの例は、コミュニティ（属性コード8）、拡張コミュニティ（属性コード16）、IPv6に固有の拡張コミュニティ（属性コード25）、およびlarge_community（属性コード32）に対処されます。
color:0:100 or col-100:
色：0：100またはCOL-100：
This notation denotes a Color extended community as defined in [RFC9012] with the "Flags" field set to 0 and the "Color Value" field set to 100.
この表記は、[RFC9012]で定義されている色の拡張コミュニティを、「フラグ」フィールドが0に設定され、「カラー値」フィールドが100に設定されていることを示します。
End-to-End Tunnel:
エンドツーエンドのトンネル：
A tunnel spanning several adjacent tunnel domains created by "stitching" them together using MPLS labels or an equivalent identifier based on the forwarding architecture.
MPLSラベルまたは転送アーキテクチャに基づく同等の識別子を使用して、それらを一緒に「ステッチ」することによって作成されたいくつかの隣接するトンネルドメインにまたがるトンネル。
Import processing:
インポート処理：
Receive-side processing of an overlay route, including things like import-policy application, Resolution Scheme selection, and NH resolution.
インポートポリシーアプリケーション、解像度スキームの選択、NH解像度など、オーバーレイルートの受信サイド処理。
Mapping Community:
マッピングコミュニティ：
Any BGP CCA (e.g., Community, Extended Community) on an overlay route that maps to a Resolution Scheme. For example, color:0:100, transport-target:0:100.
解像度スキームにマップするオーバーレイルート上のBGP CCA（コミュニティ、拡張コミュニティなど）。たとえば、色：0：100、トランスポートターゲット：0：100。
Provider Namespace:
プロバイダーネームスペース：
Internal Infrastructure address space in a provider network managed by the operator.
内部インフラストラクチャアドレススペースオペレーターが管理するプロバイダーネットワークのスペース。
Resolution Scheme:
解決スキーム：
A construct comprising of an ordered set of TRDBs to resolve NH reachability for realizing a desired Intent.
目的の意図を実現するためのNHの到達可能性を解決するための順序付けられたTRDBで構成されるコンストラクト。
Service Family:
サービスファミリ：
A BGP address family used for advertising routes for destinations in "data traffic". For example, AFI/SAFIs 1/1 or 1/128.
「データトラフィック」の目的地の広告ルートに使用されるBGPアドレスファミリー。たとえば、AFI/SAFIS 1/1または1/128。
Service Prefix:
サービスプレフィックス：
A destination in "data traffic". Routes to these prefixes are carried in a Service Family.
「データトラフィック」の目的地。これらのプレフィックスへのルートは、サービスファミリで運ばれます。
Transport Family:
トランスポートファミリー：
A BGP address family used for advertising tunnels, which are, in turn, used by service routes for resolution. For example, AFI/ SAFIs 1/4 or 1/76.
広告トンネルに使用されるBGPアドレスファミリ。これは、解像度のためにサービスルートで使用されます。たとえば、AFI/SAFIS 1/4または1/76。
Transport Tunnel:
輸送トンネル：
A tunnel over which a service may place traffic. Such a tunnel can be provisioned or signaled using a variety of means. For example, Generic Routing Encapsulation (GRE), UDP, LDP, RSVP-TE, IGP Flexible Algorithm (Flex-Algo), or SRTE.
サービスがトラフィックを配置するトンネル。このようなトンネルは、さまざまな手段を使用してプロビジョニングまたは合図することができます。たとえば、一般的なルーティングカプセル化（GRE）、UDP、LDP、RSVP-TE、IGPフレキシブルアルゴリズム（フレックスアルゴ）、またはSRTE。
Transport Layer:
輸送層：
A layer in the network that contains Transport Tunnels and Transport Families.
輸送トンネルと輸送ファミリを含むネットワーク内のレイヤー。
Tunnel Route:
トンネルルート：
A Route to Tunnel Destination/Endpoint that is installed at the headend (ingress) of the tunnel.
トンネルのヘッドエンド（イングレス）にインストールされているトンネル宛先/エンドポイントへのルート。
Tunnel Domain:
トンネルドメイン：
A domain of the network containing SNs and BNs under a single administrative control that has tunnels between them.
SNSとBNSを含むネットワークのドメインは、それらの間にトンネルを持つ単一の管理制御の下にあります。
Brownfield network:
ブラウンフィールドネットワーク：
An existing network that is already in service, deploying a chosen set of technologies and hardware. Enhancements and upgrades to such network deployments protect return on investment and should consider continuity of service.
既に使用されている既存のネットワークは、選択したテクノロジーとハードウェアのセットを展開しています。このようなネットワーク展開の強化とアップグレードは、投資収益率を保護し、サービスの継続性を考慮する必要があります。
Greenfield network:
グリーンフィールドネットワーク：
A new network deployment that can make choices of new technology or hardware as needed with fewer constraints than brownfield network.
Brownfieldネットワークよりも制約が少なく、必要に応じて新しいテクノロジーまたはハードウェアを選択できる新しいネットワーク展開。
Transport Class:
トランスポートクラス：
A construct to group transport tunnels offering similar SLAs (see Section 4.1).
同様のSLAを提供する輸送トンネルをグループ化する構造（セクション4.1を参照）。
Transport Class RT:
トランスポートクラスRT：
A Route Target extended community used to identify a specific Transport Class.
特定の輸送クラスを特定するために使用されるルートターゲット拡張コミュニティ。
transport-target:0:100:
トランスポートターゲット：0：100：
This notation denotes a Transport Class RT as defined in this document with the "Transport Class ID" field set to 100.
この表記は、このドキュメントで定義されている「トランスポートクラスID」フィールドが100に設定されたトランスポートクラスRTを示します。
Transport Route Database:
輸送ルートデータベース：
At the SN and BN, a Transport Class has an associated TRDB that collects its tunnel routes.
SNとBNでは、輸送クラスには、トンネルルートを収集する関連TRDBがあります。
Transport Plane:
輸送機：
An end-to-end plane consisting of transport tunnels belonging to the same Transport Class.
同じ輸送クラスに属する輸送トンネルで構成されるエンドツーエンドの平面。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section describes the BGP CT architecture with a brief illustration:
このセクションでは、BGP CTアーキテクチャについて簡単に説明します。
INET [RR21]--------------<<---[RR11]
Service / / | IP1,col-100
[PE21] <<--------+ : [SN11] <<-----+ ^ IP2,col-200
\ ___ : \ ___ | IP3,100:200
\ _( .) : \ _( .) | ^^^^^^^
+-- ( _) --[BN21]===[BN11]--- ( _)-[PE11] Mapping
(.__) : (.__) Community
Inter-AS-Link
:
[.......AS2:SR-TE........]:[.......AS1:RSVP-TE......]
---------Traffic Direction----------->
.-- [PE21]--<<--[BN21] [BN21]--<<--[BN11] --.
| <<--RD1:PE11(L3),PNH=BN21 : <<--RD1:PE11(L1),PNH=BN11 |
| transport-target:0:100 : transport-target:0:100 |
| : | BGP CT
| <<--RD2:PE11(L4),PNH=BN21 : <<--RD2:PE11(L2),PNH=BN11 |
| transport-target:0:200 : transport-target:0:200 |
| ^^^^^^^^^^^^^^^^^^^^^^ ^^^ |
'-- Route Target & Transport Class ID--'
Mapping Community
Intents at SN11 and PE21:
Scheme1: color:0:100, (TRDB[TC-100], TRDB[TC-BE])
Scheme2: color:0:200, (TRDB[TC-200], TRDB[TC-BE])
Scheme3: 100:200, (TRDB[TC-100], TRDB[TC-200])
^^^^^^^ ^^^^ ^^^^^^
Resolution Schemes Transport Route DB Transport Class
Figure 1: BGP CT Overview with Example Topology
図1：トポロジの例を備えたBGP CTの概要
To achieve end-to-end "Intent-Driven Service Mapping", this document defines the following constructs and BGP extensions:
エンドツーエンドの「意図駆動型サービスマッピング」を実現するために、このドキュメントでは、次の構成とBGP拡張機能を定義します。
* The "Transport Class" construct (see Section 4) to group underlay tunnels.
* 「輸送クラス」構成（セクション4を参照）をグループ化するトンネルをグループ化します。
* The "Resolution Scheme" construct (see Section 5) for overlay routes with Mapping Communities to resolve NH reachability from either one or an ordered set of Transport Classes.
* 「解像度スキーム」は、マッピングコミュニティを備えたオーバーレイルートの構成（セクション5を参照）を構築し、1つまたは順序付けられた輸送クラスのいずれかからのNHの到達可能性を解決します。
* The "BGP Classful Transport" (see Section 6) address family to extend these constructs to adjacent domains.
* 「BGPクラスフルトランスポート」（セクション6を参照）は、これらのコンストラクトを隣接するドメインに拡張するためにファミリに対応しています。
Figure 1 depicts the intra-AS and inter-AS application of these constructs. Interactions between SN1 and PE11 describe the intra-AS usage. Interactions between PE21 and PE11 describe the inter-AS usage.
図1は、これらのコンストラクトのASおよびAS間の適用を示しています。SN1とPE11の相互作用は、ASの使用法を説明しています。PE21とPE11間の相互作用は、Inter-Asの使用法を説明しています。
The example topology is an inter-AS option C network (Section 10 of [RFC4364]) with two AS domains; each domain contains tunnels serving two Intents, e.g., 'low-latency' denoted by color 100 and 'high-bandwidth' denoted by color 200. AS1 is an RSVP-TE network; AS2 is an SRTE network. BGP CT and BGP LU are transport families used between the two AS domains. IP1, IP2, and IP3 are service prefixes (AFI/SAFI: 1/1) behind egress PE11.
トポロジの例は、2つのドメインを持つオプションcネットワーク（[RFC4364]のセクション10）です。各ドメインには、2つの意図、たとえば「低遅延」と「低遅延」と色200で示される「高帯域幅」で示されるトンネルが含まれています。AS1はRSVP-TEネットワークです。AS2はSRTEネットワークです。BGP CTおよびBGP LUは、2つの間でドメインとして使用される輸送ファミリです。IP1、IP2、およびIP3は、出力PE11の背後にあるサービスプレフィックス（AFI/SAFI：1/1）です。
PE21, SN11, and PE11 are the SNs in this network. SN11 is an ingress PE with intra-domain reachability to PE11. PE21 is an ingress PE with inter-domain reachability to PE11.
PE21、SN11、およびPE11は、このネットワークのSNSです。SN11は、PE11にドメイン内の到達可能性を備えた侵入PEです。PE21は、PE11にドメイン間の到達可能性を備えた侵入PEです。
The tunneling mechanisms are made "Transport Class" aware. They publish their underlay tunnels for a Transport Class into an associated TRDB (see Section 4.2). In Figure 1, RSVP-TE publishes its underlay tunnels into TRDBs created for Transport Classes 100 and 200 at BN11 and SN11 within AS1; Similarly, SR-TE publishes its underlay tunnels into TRDBs created for Transport Classes 100 and 200 at PE21 within AS2.
トンネリングメカニズムは、「輸送クラス」を認識します。彼らは、関連するTRDBに輸送クラスのためにアンダーレイトンネルを公開します（セクション4.2を参照）。図1では、RSVP-TEは、AS1内のBN11およびSN11で輸送クラス100および200のために作成されたTRDBにアンダーレイトンネルを公開しています。同様に、SR-TEは、AS2内のPE21で輸送クラス100および200のために作成されたTRDBにアンダーレイトンネルを公開しています。
Resolution Schemes are used to realize Intent. A Resolution Scheme is identified by its "Mapping Community" and contains an ordered list of Transport Classes. Overlay routes carry an indication of the desired Intent using a BGP community, which assumes the role of "Mapping Community".
解像度スキームは、意図を実現するために使用されます。解決スキームは、「マッピングコミュニティ」によって特定され、輸送クラスの順序付けられたリストが含まれています。オーバーレイルートには、「コミュニティのマッピング」の役割を想定するBGPコミュニティを使用して、目的の意図を示しています。
Egress SN "PE11" advertises service routes with desired Mapping Community, e.g., color:0:100.
出力SN "PE11"は、目的のマッピングコミュニティを備えたサービスルートを宣伝します。たとえば、色：0：100。
For the intra-AS case, SN1 maps this intra-AS route on RSVP-TE tunnels with TC ID 100 by using the Resolution Scheme for color:0:100.
AS Intra-ASの場合、SN1は、Color：0：100の解像度スキームを使用して、TC ID 100のRSVP-TEトンネル上のこのイントラASルートをマッピングします。
For the inter-AS case, the underlay route in a TRDB is advertised in BGP to extend an underlay tunnel to adjacent domains. A new BGP transport family called "BGP Classful Transport", also known as BGP CT (AFI/SAFIs 1/76, 2/76), is defined for this purpose. BGP CT makes it possible to advertise multiple tunnels to the same destination address, thus avoiding the need for multiple loopbacks on the eSN.
AS Inter-ASの場合、TRDBのアンダーレイルートはBGPで宣伝され、隣接するドメインにアンダーレイトンネルを拡張します。BGP CT（AFI/SAFIS 1/76、2/76）とも呼ばれる「BGP Classful Transport」と呼ばれる新しいBGPトランスポートファミリーは、この目的のために定義されています。BGP CTにより、複数のトンネルを同じ宛先アドレスに宣伝することができるため、ESNの複数のループバックの必要性が回避されます。
The BGP CT address family carries transport prefixes across tunnel domain boundaries. Its design and operation are analogous to BGP LU (AFI/SAFIs 1/4 or 2/4). It disseminates "Transport Class" information for the transport prefixes across the participating domains while avoiding the need of per-TC loopback. This is not possible with BGP LU without using per-color loopback. This dissemination makes the end-to-end network a "Transport Class" aware tunneled network.
BGP CTアドレスファミリは、トンネルドメインの境界を越えて輸送のプレフィックスを搭載しています。その設計と操作は、BGP Lu（AFI/SAFIS 1/4または2/4）に類似しています。TCごとのループバックの必要性を回避しながら、参加ドメイン全体の輸送プレフィックスの「輸送クラス」情報を広めます。これは、1色のループバックを使用せずにBGP LUでは不可能です。この普及により、エンドツーエンドネットワークは「トランスポートクラス」を認識します。
In Figure 1, BGP CT routes are originated at BN11 in AS1 with NH "self" towards BN21 in AS2 to extend available RSVP-TE tunnels for Transport Classes 100 and 200 in AS1. BN21 propagates these routes with NH "self" to PE21, which resolves the BGP CT routes over SRTE tunnels belonging to same Transport Class, thus forming a BGP CT tunnel for each TC ID at PE21.
図1では、AS1のBN11でBN11でBN11でNH「Self」がAS2にBN21に向かって発信され、AS1で輸送クラス100および200の利用可能なRSVP-TEトンネルを拡張します。BN21は、これらのルートをNH「Self」からPE21に伝播します。PE21は、同じ輸送クラスに属するSRTEトンネル上のBGP CTルートを解決するため、PE21で各TC IDのBGP CTトンネルを形成します。
PE21 maps the inter-AS service routes received with color:0:100 from AS1 on BGP CT tunnel with TC ID 100 by using the Resolution Scheme for color:0:100. Note that this procedure is same as that followed by SN1 in the intra-AS case.
PE21は、色で受信したAS Inter-ASサービスルートをマップします：0：100 BGP CTトンネルのAS1からTC ID 100を使用して、Color：0：100を使用してTC ID 100を使用します。この手順は、AS Inter-ASの場合にSN1が続くものと同じであることに注意してください。
The following text illustrates how CT architecture provides tiered fallback options at a per-route granularity. Figure 1 shows the Resolution Schemes in use, which make the following NH resolution happen at SN11 (intra-AS) and PE21 (inter-AS) for the service routes of prefixes IP1, IP2, and IP3:
次のテキストは、CTアーキテクチャがルートごとの粒度で階層化されたフォールバックオプションをどのように提供するかを示しています。図1は、使用中の解像度スキームを示しています。これにより、プレフィックスIP1、IP2、およびIP3のサービスルートのSN11（Intra-AS）およびPE21（Inter-AS）で次のNH解像度が発生します。
* Resolve IP1 NH over available tunnels in TRDB for Transport Class 100 with fallback to TRDB for best effort.
* TRDBで利用可能なトンネルでIP1 NHを解決し、TRDBへのフォールバックを使用して、最善を尽くします。
* Resolve IP2 NH over available tunnels in TRDB for Transport Class 200 with fallback to TRDB for best effort.
* TRDBで利用可能なトンネルでIP2 NHを解決します。クラス200を輸送し、TRDBへのフォールバックを最善の努力で解決します。
* Resolve IP3 NH over available tunnels in TRDB for Transport Class 100 with fallback to TRDB for Transport Class 200.
* TRDBで利用可能なトンネルでIP3 NHを解決します。トランスポートクラス100のクラス100を輸送クラス200のFallbackを使用します。
In Figure 1, SN11 resolves IP1, IP2, and IP3 directly over RSVP-TE tunnels in AS1. PE21 resolves IP1, IP2, and IP3 over extended BGP CT tunnels that resolve over SR-TE tunnels in AS2.
図1では、SN11はAS1のRSVP-TEトンネルでIP1、IP2、およびIP3を直接解決します。PE21は、AS2のSR-TEトンネルを介して解決する拡張BGP CTトンネルを介してIP1、IP2、およびIP3を解決します。
This document describes procedures using MPLS forwarding architecture. However, these procedures would work in a similar manner for non-MPLS forwarding architectures as well. Section 7.13 describes the application of BGP CT over the SRv6 data plane.
このドキュメントは、MPLS転送アーキテクチャを使用した手順について説明します。ただし、これらの手順は、非MPLS転送アーキテクチャでも同様の方法で機能します。セクション7.13では、SRV6データプレーンに対するBGP CTの適用について説明します。
Transport Class is a construct that groups transport tunnels offering similar SLAs within the administrative domain of a provider network or closely coordinated provider networks.
トランスポートクラスは、プロバイダーネットワークまたは密接に調整されたプロバイダーネットワークの管理ドメイン内で同様のSLAを提供するトンネルを輸送するグループです。
A Transport Class is uniquely identified by a 32-bit "Transport Class ID" that is assigned by the operator. The operator consistently provisions a Transport Class on participating nodes (SNs and BNs) in a domain with its unique Transport Class ID.
トランスポートクラスは、オペレーターによって割り当てられた32ビットの「トランスポートクラスID」によって一意に識別されます。オペレーターは、一意のトランスポートクラスIDを備えたドメイン内の参加ノード（SNSおよびBNS）に関するトランスポートクラスを一貫して提供します。
A Transport Class is also configured with RD and import/export RT attributes. Creation of a Transport Class instantiates its corresponding TRDB and Resolution Schemes on that node.
また、輸送クラスはRDおよびインポート/エクスポートRT属性で構成されています。トランスポートクラスの作成は、そのノードに対応するTRDBおよび解像度スキームをインスタンス化します。
All nodes within a domain agree on a common Transport Class ID namespace. However, two cooperating domains may not always agree on the same namespace. Procedures to manage differences in Transport Class ID namespaces between cooperating domains are specified in Section 11.2.2.
ドメイン内のすべてのノードは、一般的なトランスポートクラスID名空間に同意します。ただし、2つの協力ドメインは、同じ名前空間で常に同意するとは限りません。協力ドメイン間のトランスポートクラスID名空間の違いを管理する手順は、セクション11.2.2で指定されています。
Transport Class ID conveys the Color of tunnels in a Transport Class. The terms 'Transport Class ID' and 'Color' are used interchangeably in this document.
トランスポートクラスIDは、輸送クラスのトンネルの色を伝えます。このドキュメントでは、「トランスポートクラスID」と「色」という用語が同じ意味で使用されます。
TE tunnels can be classified into a Transport Class based on the TE attributes they possess and the TE characteristics that the operator defines for that Transport Class. Due to the fact that multiple TE tunneling protocols exist, their TE attributes and characteristics may not be equal but sufficiently similar. Some examples of such classifications are as follows:
TEトンネルは、所有するTE属性と、オペレーターがその輸送クラスに定義するTE特性に基づいて、輸送クラスに分類できます。複数のTEトンネルプロトコルが存在するという事実により、それらの属性と特性は等しくなく、十分に類似している可能性があります。このような分類のいくつかの例は次のとおりです。
* Tunnels (RSVP-TE, IGP Flex-Algo, SR-TE) that support latency sensitive routing.
* レイテンシに敏感なルーティングをサポートするトンネル（RSVP-TE、IGP Flex-Algo、SR-TE）。
* RSVP-TE tunnels that only go over admin-group with Green links.
* 緑色のリンクを使用して管理者グループを介して行くRSVP-TEトンネル。
* Tunnels (RSVP-TE, SR-TE) that offer FRR.
* frrを提供するトンネル（RSVP-TE、SR-TE）。
* Tunnels (RSVP-TE, SR-TE) that share resources in the network based on Shared Risk Link Groups defined by TE policy.
* TEポリシーで定義された共有リスクリンクグループに基づいて、ネットワーク内のリソースを共有するトンネル（RSVP-TE、SR-TE）。
* Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in the network based on RSVP-TE Explicit Route Object (ERO), SR-TE policy, or BGP policy.
* RSVP-TE明示的ルートオブジェクト（ERO）、SR-TEポリシー、またはBGPポリシーに基づいてネットワーク内の特定のノードを回避するトンネル（RSVP-TE、SR-TE、BGP CT）。
An operator may configure an SN/BN to classify a tunnel into an appropriate Transport Class. How exactly these tunnels are made Transport Class aware is implementation specific and outside the scope of this document.
オペレーターは、SN/BNを構成して、トンネルを適切な輸送クラスに分類することができます。これらのトンネルがどのように正確に輸送クラスが認識されているかは、このドキュメントの範囲外であり、範囲外です。
When a tunnel is made Transport Class aware, it causes the Tunnel Route to be installed in the corresponding TRDB of that Transport Class. These routes are used to resolve overlay routes, including BGP CT. The BGP CT routes may be further readvertised to adjacent domains to extend these tunnels. While readvertising BGP CT routes, the "Transport Class ID" is encoded as part of the Transport Class RT, which is a new Route Target extended community defined in Section 4.3.
トンネルが輸送クラスを認識させると、その輸送クラスの対応するTRDBにトンネルルートが設置されます。これらのルートは、BGP CTを含むオーバーレイルートの解決に使用されます。BGP CTルートは、これらのトンネルを拡張するために隣接するドメインにさらに読み込まれます。BGP CTルートの読み取り中に、「トランスポートクラスID」は、セクション4.3で定義された新しいルートターゲット拡張コミュニティであるトランスポートクラスRTの一部としてエンコードされます。
An SN/BN receiving the transport routes via BGP with sufficient signaling information to identify a Transport Class can associate those tunnel routes with the corresponding Transport Class. For example, in BGP CT family routes, the Transport Class RT indicates the Transport Class. For BGP LU family routes, import processing based on communities or inter-AS source-peer may be used to place the route in the desired Transport Class.
輸送クラスを識別するのに十分な信号情報を使用してBGPを介して輸送ルートを受信するSN/BNは、それらのトンネルルートを対応する輸送クラスに関連付けることができます。たとえば、BGP CTファミリールートでは、輸送クラスRTが輸送クラスを示します。BGP LUファミリールートの場合、コミュニティまたはASの協会間ピアに基づく輸入処理を使用して、目的の輸送クラスにルートを配置することができます。
When the tunnel route is received via [RFC9830] with "Color:Endpoint" as the NLRI that encodes the Transport Class as an integer 'Color' in its Policy Color field, the 'Color' is mapped to a Transport Class during the import processing. The SRTE tunnel route for this 'Endpoint' is installed in the corresponding TRDB. The SRTE tunnel will be extended by a BGP CT advertisement with NLRI RD:EP, Transport Class RT, and a new label. The MPLS swap route thus installed for the new label will pop the label and forward the decapsulated traffic into the path determined by the SRTE route for further encapsulation.
トンネルルートが[RFC9830]を介して「Color：Endpoint」を介して、ポリシーカラーフィールドの整数「色」として輸送クラスをコードするNLRIとして受信すると、輸入処理中に「色」が輸送クラスにマッピングされます。この「エンドポイント」のSRTEトンネルルートは、対応するTRDBにインストールされています。SRTEトンネルは、NLRI RD：EP、Transport Class RT、および新しいラベルを使用したBGP CT広告によって拡張されます。このように新しいラベル用にインストールされたMPLSスワップルートは、ラベルをポップし、脱カプセル化されたトラフィックをSRTEルートによって決定されたパスに転送し、さらにカプセル化します。
[PCEP-SRPOLICY] extends the Path Computation Element Communication Protocol (PCEP) to signal attributes of an SR Policy that include Color. This Color is mapped to a Transport Class thus associating the SR Policy with the desired Transport Class.
[PCEP-Srpolicy]は、PATH計算要素通信プロトコル（PCEP）を拡張して、色を含むSRポリシーの属性を信号します。この色は輸送クラスにマッピングされているため、SRポリシーを目的の輸送クラスに関連付けます。
Similarly, [PCEP-RSVP-COLOR] extends PCEP to carry the Color attribute for its use with RSVP-TE LSPs. This Color is mapped to a Transport Class thus associating the RSVP-TE LSP with the desired Transport Class.
同様に、[PCEP-RSVP-COLOR]はPCEPを拡張して、RSVP-TE LSPで使用する色属性を運ぶ。この色は輸送クラスにマッピングされているため、RSVP-TE LSPを目的の輸送クラスに関連付けます。
A TRDB is a logical collection of transport routes pertaining to the same Transport Class. In any node, every Transport Class has an associated TRDB. Resolution Schemes resolve NH reachability for EP using the transport routes within the scope of the TRDBs.
TRDBは、同じ輸送クラスに関連する輸送ルートの論理的なコレクションです。任意のノードでは、すべてのトランスポートクラスに関連するTRDBがあります。解像度スキームは、TRDBSの範囲内の輸送ルートを使用して、EPのNHリーチビリティを解決します。
Tunnel EP addresses in a TRDB belong to the provider namespace representing the core transport region.
トンネルEPは、コアトランスポート領域を表すプロバイダー名空間に属しているTRDBにアドレスを与えます。
An implementation may realize the TRDB as a "Routing Table" referred to in Section 9.1.2.1 of [RFC4271], which is used only for resolving NH reachability in the control plane. An implementation may choose a different datastructure to realize this logical construct while still adhering to the procedures defined in this document. The tunnel routes in a TRDB require no footprint in the forwarding plane unless they are used to resolve an NH.
実装は、[RFC4271]のセクション9.1.2.1で言及されている「ルーティングテーブル」としてTRDBを実現する場合があります。実装は、このドキュメントで定義されている手順を順守しながら、この論理的な構成を実現するために別のデータストラクチャを選択する場合があります。TRDBのトンネルルートは、NHの解決に使用されない限り、転送面にフットプリントを必要としません。
SNs or BNs originate routes for the BGP CT address family from the TRDB. These routes have RD:EP in the NLRI, carry a Transport Class RT, and an MPLS label or equivalent identifier in different forwarding architecture. BGP CT family routes received with Transport Class RT are installed into their respective TRDB.
SNSまたはBNSは、TRDBからBGP CTアドレスファミリーのルートを開始します。これらのルートには、NLRIにRD：EPがあり、トランスポートクラスRTを運び、さまざまな転送アーキテクチャにMPLSラベルまたは同等の識別子があります。輸送クラスRTで受け取ったBGP CTファミリールートは、それぞれのTRDBにインストールされます。
This section defines a new type of Route Target called a "Transport Class Route Target extended community" (also known as a "Transport Class RT"). The procedures for use of this extended community with BGP CT routes (AFI/SAFI: 1/76 or 2/76) are described below.
このセクションでは、「トランスポートクラスルートターゲット拡張コミュニティ」（「トランスポートクラスRT」とも呼ばれる）と呼ばれる新しいタイプのルートターゲットを定義します。BGP CTルート（AFI/SAFI：1/76または2/76）でこの拡張コミュニティを使用する手順を以下に説明します。
The Transport Class RT is a transitive extended community [RFC4360] of extended type, which has the format as shown in Figure 2.
トランスポートクラスRTは、図2に示すように形式がある拡張タイプの推移的な拡張コミュニティ[RFC4360]です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= 0xa | SubType= 0x02 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Transport Class RT
図2：輸送クラスRT
Type:
タイプ：
A 1-octet field that MUST be set to 0xa to indicate 'Transport Class'.
「トランスポートクラス」を示すために0xAに設定する必要がある1オクテットのフィールド。
SubType:
サブタイプ：
A 1-octet field that MUST be set to 0x2 to indicate 'Route Target'.
「ルートターゲット」を示すために0x2に設定する必要がある1-OCTETフィールド。
Reserved:
予約済み：
A 2-octet reserved bits field.
2-OCTET予約ビットフィールド。
This field MUST be set to zero on transmission.
このフィールドは、送信時にゼロに設定する必要があります。
This field SHOULD be ignored on reception and MUST be left unaltered.
このフィールドはレセプションで無視する必要があり、変更されていないままにする必要があります。
Transport Class ID:
トランスポートクラスID：
This field is encoded in 4 octets.
このフィールドは4オクテットでエンコードされています。
This field contains the "Transport Class ID", which is an unsigned 32-bit integer.
このフィールドには、署名されていない32ビット整数である「トランスポートクラスID」が含まれています。
This document reserves the Transport Class ID value 0 to represent the "Best-Effort Transport Class ID".
このドキュメントは、「ベストエフォルトトランスポートクラスID」を表すために、トランスポートクラスID値0を留保します。
A Transport Class RT with TC ID 100 is denoted as "transport-target:0:100".
TC ID 100を持つトランスポートクラスRTは、「トランスポートターゲット：0：100」として示されます。
The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs (see [RFC4364]) and the Constrained Route Distribution mechanisms specified in Route Target Constraint (see [RFC4684]) are applied using the Route Target extended community. These mechanisms are applied to BGP CT routes (AFI/SAFI: 1/76 or 2/76) using the Transport Class RT".
BGP/MPLS IP VPN（[RFC4364]を参照）で指定されたVPNルートのインポート/エクスポートメカニズムと、ルートターゲット制約で指定された制約されたルート分布メカニズム（[RFC4684]を参照）は、ルートターゲット拡張コミュニティを使用して適用されます。これらのメカニズムは、輸送クラスRTを使用して、BGP CTルート（AFI/SAFI：1/76または2/76）に適用されます。
A BGP speaker that implements procedures described in this document and [RFC4684] MUST also apply the RTC procedures to the Transport Class RT carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). An RTC route is generated for each Route Target imported by locally provisioned Transport Classes.
このドキュメントと[RFC4684]で説明されている手順を実装するBGPスピーカーは、RTC手順をBGP CTルート（AFI/SAFI：1/76または2/76）で伝達されたトランスポートクラスRTに適用する必要があります。RTCルートは、ローカルでプロビジョニングされた輸送クラスによってインポートされた各ルートターゲットに対して生成されます。
Further, when processing RT membership NLRIs containing a Transport Class RT received from external BGP peers, it is necessary to consider multiple External BGP (EBGP) paths for a given RTC prefix for building the outbound route filter: not just the best path. An implementation MAY provide configuration to control how many EBGP RTC paths are considered.
さらに、外部BGPピアから受け取ったトランスポートクラスRTを含むRTメンバーシップNLRISを処理する場合、アウトバウンドルートフィルターを構築するための特定のRTCプレフィックスの複数の外部BGP（EBGP）パスを考慮する必要があります。実装により、EBGP RTCパスの数が考慮されるかを制御する構成が提供される場合があります。
The Transport Class RT is carried on BGP CT family routes and is used to associate them with appropriate TRDBs at receiving BGP speakers. The Transport Class RT is carried unaltered on the BGP CT route across BGP CT negotiated sessions except for scenarios described in Section 11.2.2. Implementations should provide policy mechanisms to perform match, strip, or rewrite operations on a Transport Class RT just like any other BGP community.
トランスポートクラスRTは、BGP CTファミリールートで運ばれ、BGPスピーカーを受信した適切なTRDBに関連付けるために使用されます。輸送クラスRTは、セクション11.2.2で説明されているシナリオを除き、BGP CTネゴシエートセッションを介してBGP CTルートで変更されていません。実装は、他のBGPコミュニティと同様に、トランスポートクラスRTで一致、ストリップ、または書き換えのためのポリシーメカニズムを提供する必要があります。
Defining a new type code for the Transport Class RT avoids conflicting with any VPN Route Target assignments already in use for service families.
トランスポートクラスRTの新しいタイプコードを定義することで、サービスファミリにすでに使用されているVPNルートターゲット割り当てと矛盾することがなくなります。
This document also reserves the non-transitive version of the Transport Class RT (see Section 13.2.1.1.2) for future use. The non-transitive Transport Class RT is not used. If received, it is considered equivalent in functionality to the transitive Transport Class RT, except for the difference in Transitive bit flag.
このドキュメントでは、将来の使用のために、トランスポートクラスRTの非転送バージョン（セクション13.2.1.1.2を参照）も留保します。非転倒輸送クラスRTは使用されていません。受け取った場合、推移的なビットフラグの違いを除いて、推移的輸送クラスRTとの機能に等しいと見なされます。
A Resolution Scheme is a construct that consists of a specific TRDB or an ordered set of TRDBs. An overlay route is associated with a Resolution Scheme during import processing based on the Mapping Community in the route.
解像度スキームは、特定のTRDBまたは順序付けられたTRDBで構成される構成要素です。オーバーレイルートは、ルート内のマッピングコミュニティに基づくインポート処理中の解像度スキームに関連付けられています。
Resolution Schemes enable a BGP speaker to resolve NH reachability for overlay routes over the appropriate underlay tunnels within the scope of the TRDBs. Longest Prefix Match (LPM) of the NH is performed within the identified TRDB.
解像度スキームにより、BGPスピーカーは、TRDBSの範囲内で適切なアンダーレイトンネル上のオーバーレイルートのNHリーチビリティを解決できます。NHの最長のプレフィックスマッチ（LPM）は、識別されたTRDB内で実行されます。
An implementation may provide an option for the overlay route to resolve over less-preferred Transport Classes, should the resolution over a primary Transport Class fail.
実装は、主要な輸送クラスの解決が失敗した場合に、より優れた輸送クラスを超えて解決するためのオーバーレイルートのオプションを提供する場合があります。
To accomplish this, the "Resolution Scheme" is configured with the primary Transport Class and an ordered list of fallback Transport Classes. Two Resolution Schemes are considered equivalent in Intent if they consist of the same ordered set of TRDBs.
これを達成するために、「解像度スキーム」は、プライマリトランスポートクラスとフォールバック輸送クラスの順序付けられたリストで構成されます。2つの解像度スキームは、同じ順序付けられたTRDBSセットで構成される場合、意図が同等であると見なされます。
Operators must ensure that Resolution Schemes for a Mapping Community are provisioned consistently on various nodes participating in a BGP CT network based on desired Intent and Transport Classes available in that domain.
オペレーターは、マッピングコミュニティの解像度スキームが、そのドメインで利用可能な目的の意図および輸送クラスに基づいてBGP CTネットワークに参加するさまざまなノードで一貫してプロビジョニングされることを確認する必要があります。
A "Mapping Community" is used to signal the desired Intent on an overlay route. At an ingress node receiving the route, it maps the overlay route to a "Resolution Scheme" used to resolve the route's NH.
「マッピングコミュニティ」は、オーバーレイルートの目的の意図を知らせるために使用されます。ルートを受信するイングレスノードでは、オーバーレイルートをマップして、ルートのNHを解決するために使用される「解像度スキーム」にマッピングします。
A Mapping Community is a "role" and not a new type of community; any BGP Community Carrying Attribute (e.g., Community or Extended Community) may play this role in addition to the other roles it may already be playing. For example, the Transport Class RT plays a dual role: as Route Target and a Mapping Community.
マッピングコミュニティは「役割」であり、新しいタイプのコミュニティではありません。属性を伝えるBGPコミュニティ（コミュニティや拡張コミュニティなど）は、すでにプレイしている他の役割に加えて、この役割を果たすことができます。たとえば、トランスポートクラスのRTは、ルートターゲットとマッピングコミュニティとして、二重の役割を果たします。
Operator provisioning ensures that the ingress and egress SNs agree on the BGP CCA and community namespace to use for the Mapping Community.
オペレーターのプロビジョニングにより、イングレスと出口のSNSが、マッピングコミュニティに使用するBGP CCAおよびコミュニティネームスペースに同意することを保証します。
A Mapping Community maps to exactly one Resolution Scheme at a receiving BGP speaker. An implementation SHOULD allow the association of multiple Mapping Communities to a Resolution Scheme. This helps with renumbering and migration scenarios.
マッピングコミュニティは、受信BGPスピーカーで正確に1つの解像度スキームにマッピングします。実装により、複数のマッピングコミュニティと解決スキームとの関連付けが可能になるはずです。これは、変更および移行シナリオに役立ちます。
An example of a Mapping Community is a Color extended community "color:0:100", described in [RFC9012], or the "transport-target:0:100" described in Section 4.3.
マッピングコミュニティの例は、[RFC9012]で説明されている色の拡張コミュニティ「色：0：100」、またはセクション4.3で説明されている「トランスポートターゲット：0：100」です。
The first community on the overlay route that matches a Mapping Community of a locally configured Resolution Scheme is considered the effective Mapping Community for the route. The Resolution Scheme thus found is used when resolving the route's PNH. If a route contains more than one Mapping Community, it indicates that the route considers these distinct Mapping Communities as equivalent in Intent.
ローカルで構成された解像度スキームのマッピングコミュニティに一致するオーバーレイルートの最初のコミュニティは、ルートの効果的なマッピングコミュニティと見なされます。このように見つかった解像度スキームは、ルートのPNHを解決するときに使用されます。ルートに複数のマッピングコミュニティが含まれている場合、ルートがこれらの異なるマッピングコミュニティを意図的に同等と見なしていることを示します。
On an overlay route, if more than one Mapping Community exists that map to distinct Resolution Schemes having dissimilar Intents at a receiving node, it is considered a configuration error.
オーバーレイルートでは、受信ノードで異なる意図を持つ明確な解像度スキームにマッピングする複数のマッピングコミュニティが存在する場合、構成エラーと見なされます。
Since a route can carry multiple communities, but only a single Resolution Scheme can be in effect for the route on any given router, it is incumbent on the operator to ensure that communities attached to a route will map to the desired Resolution Scheme at each point in the network.
ルートは複数のコミュニティを運ぶことができるため、特定のルーターのルートでは単一の解像度スキームのみが有効になるため、ルートに接続されたコミュニティがネットワーク内の各ポイントで希望の解像度スキームにマッピングされることを保証するのはオペレーターに義務付けられています。
It should be noted that the Mapping Community role does not require applying Route Target Constraint procedures specified in [RFC4684].
[RFC4684]で指定されたルートターゲット制約手順を適用する必要はないことに注意してください。
The BGP Classful Transport (BGP CT) family uses the existing Address Family Identifier (AFI) of IPv4 or IPv6 and a new SAFI 76 "Classful Transport" that applies to both IPv4 and IPv6 AFIs.
BGPクラスフルトランスポート（BGP CT）ファミリーは、IPv4またはIPv6の既存のアドレスファミリー識別子（AFI）と、IPv4とIPv6 AFIの両方に適用される新しいSAFI 76「クラスフルトランスポート」を使用します。
The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol Extensions capability described in Section 8 of [RFC4760] to be able to send and receive BGP CT routes for IPv4 endpoint prefixes.
AFI/SAFI 1/76は、IPv4エンドポイントプレフィックスのBGP CTルートを送信および受信できるように、[RFC4760]のセクション8で説明されているマルチプロトコル拡張機能に従って交渉する必要があります。
The AFI/SAFI 2/76 MUST be negotiated as per the Multiprotocol Extensions capability described in Section 8 of [RFC4760] to be able to send and receive BGP CT routes for IPv6 endpoint prefixes.
AFI/SAFI 2/76は、IPv6エンドポイントプレフィックスのBGP CTルートを送信および受信できるように、[RFC4760]のセクション8で説明されているマルチプロトコル拡張機能に従って交渉する必要があります。
The "Classful Transport" SAFI NLRI has the same encoding as specified in Section 2 of [RFC8277].
「クラスフルトランスポート」Safi NLRIは、[RFC8277]のセクション2で指定されたエンコードと同じエンコードを持っています。
When the AFI/SAFI is 1/76, the BGP CT NLRI Prefix consists of an 8-byte RD followed by an IPv4 prefix. When AFI/SAFI is 2/76, the BGP CT NLRI Prefix consists of an 8-byte RD followed by an IPv6 prefix.
AFI/SAFIが1/76の場合、BGP CT NLRIプレフィックスは8バイトRDで構成され、その後IPv4プレフィックスが続きます。AFI/SAFIが2/76の場合、BGP CT NLRIプレフィックスは8バイトRDで構成され、その後IPv6プレフィックスが続きます。
The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of [RFC8277] apply for AFI/SAFI 1/76 also. The procedures described for AFI/SAFIs 2/4 or 2/128 in Section 2 of [RFC8277] apply for AFI/SAFI 2/76 also.
[RFC8277]のセクション2のAFI/SAFIS 1/4または1/128について説明されている手順は、AFI/SAFI 1/76にも適用されます。[RFC8277]のセクション2のAFI/SAFIS 2/4または2/128について説明されている手順は、AFI/SAFI 2/76にも適用されます。
BGP CT routes MAY carry multiple labels in the NLRI by negotiating the Multiple Labels Capability as described in Section 2.1 of [RFC8277].
BGP CTルートは、[RFC8277]のセクション2.1で説明されているように、複数のラベル機能を交渉することにより、NLRIで複数のラベルを搭載する場合があります。
Properties received on a BGP CT route include the Transport Class RT, which is used to associate the route with the correct TRDBs on SNs and BNs in the network, and either an IPv4 or an IPv6 NH.
BGP CTルートで受信されたプロパティには、ネットワーク内のSNSおよびBNS上の正しいTRDBとルートを関連付けるために使用されるトランスポートクラスRT、およびIPv4またはIPv6 NHのいずれかが含まれます。
When the length of the Next hop Address field is 4, the next hop address is an IPv4 address.
次のホップアドレスフィールドの長さが4の場合、次のホップアドレスはIPv4アドレスです。
When the length of the Next hop Address field is 16 (or 32), the next hop address is an IPv6 address (potentially followed by the link-local IPv6 address of the next hop). This follows Section 3 of [RFC2545].
次のホップアドレスフィールドの長さが16（または32）の場合、次のホップアドレスはIPv6アドレスです（次に、次のホップのLink-Local IPv6アドレスが続く可能性があります）。これは、[RFC2545]のセクション3に続きます。
When the length of Next hop Address field is 24 (or 48), the next hop address is a VPN-IPv6 with an 8-octet RD set to zero (potentially followed by the link-local VPN-IPv6 address of the next hop with an 8-octet RD set to zero). This follows Section 3.2.1.1 of [RFC4659].
次のホップアドレスフィールドの長さが24（または48）の場合、次のホップアドレスは8-OCTET RDセットがゼロになるVPN-IPv6です（潜在的に8-OCTET RDがゼロに設定された次のホップのリンクローカルVPN-IPV6アドレスが続きます）。これは、[RFC4659]のセクション3.2.1.1に続きます。
When the length of the Next hop Address field is 12, the next hop address is a VPN-IPv4 with 8-octet RD set to zero.
次のホップアドレスフィールドの長さが12の場合、次のホップアドレスは8-OCTET RDがゼロに設定されたVPN-IPV4です。
If the length of the Next hop Address field contains any other values, it is considered an error and is handled via BGP session reset as per Section 7.11 of [RFC7606].
次のホップアドレスフィールドの長さに他の値が含まれている場合、それはエラーと見なされ、[RFC7606]のセクション7.11に従ってBGPセッションリセットを介して処理されます。
To ease interoperability between nodes supporting different forwarding technologies, a BGP CT route allows carrying multiple types of encapsulation information.
さまざまな転送技術をサポートするノード間の相互運用性を容易にするために、BGP CTルートにより、複数のタイプのカプセル化情報を運ぶことができます。
An MPLS label is carried using the encoding in [RFC8277]. A node that does not support MPLS forwarding advertises the special label 3 (Implicit NULL) in the MPLS label field (see [RFC8277]). The Implicit NULL label carried in BGP CT route indicates to a receiving node that it should not impose any BGP CT label for this route.
MPLSラベルは、[RFC8277]のエンコーディングを使用して運ばれます。MPLS転送をサポートしていないノードは、MPLSラベルフィールドに特別なラベル3（暗黙のヌル）を宣伝します（[RFC8277]を参照）。BGP CTルートで運ばれる暗黙のヌルラベルは、受信ノードに、このルートにBGP CTラベルを課さないことを示しています。
The SID information for SR with respect to the MPLS data plane is carried as specified in the Prefix-SID attribute defined as part of Section 3 of [RFC8669].
MPLSデータプレーンに関するSRのSID情報は、[RFC8669]のセクション3の一部として定義されたプレフィックス-SID属性で指定されているとおりに運ばれます。
The SID information for SR with respect to SRv6 data plane is carried as specified in Section 7.13.
SRV6データプレーンに関するSRのSID情報は、セクション7.13で指定されているように運ばれます。
UDP tunneling information is carried using the Tunnel Encapsulation Attribute as specified in [RFC9012].
UDPトンネル情報は、[RFC9012]で指定されているトンネルカプセル化属性を使用して運ばれます。
AFI/SAFI 1/128 (L3VPN) is a family encoded using [RFC8277] that carries service prefixes in the NLRI, where the prefixes come from the customer namespaces and are contextualized into separate user virtual service RIBs called VRFs as per [RFC4364].
AFI/SAFI 1/128（L3VPN）は、[RFC8277]を使用してエンコードされたファミリで、NLRIのサービスプレフィックスを搭載しています。プレフィックスは顧客ネームスペースから来ており、[RFC4364]に従ってVRFと呼ばれる個別のユーザー仮想サービスリブにコンテキスト化されます。
AFI/SAFI 1/4 (BGP LU) is a family encoded using [RFC8277] that carries transport prefixes in the NLRI, where the prefixes come from the provider namespace.
AFI/SAFI 1/4（BGP LU）は、[RFC8277]を使用してエンコードされたファミリで、NLRIの輸送プレフィックスを搭載しており、プレフィックスがプロバイダーの名前空間から供給されます。
AFI/SAFI 1/76 (BGP CT) is a family encoded using [RFC8277] that carries transport prefixes in the NLRI, where the prefixes come from the provider namespace and are contextualized into separate TRDB, following mechanisms similar to [RFC4364] procedures.
AFI/SAFI 1/76（BGP CT）は、[RFC8277]を使用してエンコードされたファミリです。これは、NLRIの輸送プレフィックスを搭載しており、プレフィックスはプロバイダーネームスペースから来て、[RFC4364]手順に似たメカニズムに従って別々のTRDBにコンテキスト化されます。
It is worth noting that AFI/SAFI 1/128 has been used to carry transport prefixes in "L3VPN inter-AS Carrier's carrier" scenario as defined in Section 10 of [RFC4364], where BGP LU/LDP prefixes in CsC VRF are advertised in AFI/SAFI 1/128 towards the remote-end client carrier.
AFI/SAFI 1/128は、[RFC4364]のセクション10で定義されている「L3VPN ASキャリアのキャリア」シナリオで輸送プレフィックスを運ぶために使用されていることに注意してください。
In this document, SAFI 76 (CT) is used instead of reusing SAFI 128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because it is operationally advantageous to segregate transport and service prefixes into separate address families. For example, such an approach allows operators to safely enable a "per-prefix" label-allocation scheme for BGP CT prefixes, typically with a number of routes in the hundreds of thousands or less, without affecting SAFI 128 service prefixes, which may represent millions of routes at the time of writing. The "per-prefix" label-allocation scheme localizes routing churn during topology changes.
このドキュメントでは、SAFI 76（CT）がAFI 1または2のSAFI 128（L3VPN）を再利用する代わりに使用して、輸送とサービスのプレフィックスを個別のアドレスファミリに分離するのに動作的に有利であるためです。たとえば、このようなアプローチにより、オペレーターは、BGP CTプレフィックスの「プレフィックスごとの」ラベルアロケーションスキームを安全に有効にすることができます。通常、執筆時点で数百万ルートを表す可能性のあるSAFI 128のサービスプレフィックスに影響を与えることなく、通常数十万以下のルートが多数あります。「Prefix」ラベルアロケーションスキームは、トポロジの変更中にルーティングチャーンをローカルします。
Service routes continue to be carried in their existing AFI/SAFIs without any change. For example, L3VPN (AFI/SAFI: 1/128 and 2/128), EVPN (AFI/SAFI: 25/70 ), Virtual Private LAN Service (VPLS) (AFI/ SAFI: 25/65), or Internet (AFI/SAFI: 1/1 or 2/1). These service routes can resolve over BGP CT (AFI/SAFI: 1/76 or 2/76) transport routes.
サービスルートは、変更せずに既存のAFI/SAFISで引き続き運ばれます。たとえば、L3VPN（AFI/SAFI：1/128および2/128）、EVPN（AFI/SAFI：25/70）、仮想プライベートLANサービス（VPLS）（AFI/SAFI：25/65）、またはインターネット（AFI/SAFI：1/1または2/1）。これらのサービスルートは、BGP CT（AFI/SAFI：1/76または2/76）輸送ルートを超えて解決できます。
A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a different distribution path of the transport family routes in a network than the service route distribution path. Service routes (SAFI 128) are exchanged over an EBGP multihop session between ASes with the NH unchanged; whereas BGP CT routes (SAFI 76) are advertised over EBGP single-hop sessions with a "NH self" rewrite over inter-AS links.
AFI 1とAFI 2の新しいSAFI 76は、サービスルート配布パスとはネットワーク内の輸送ファミリルートの異なる配信パスを持つことも容易にします。サービスルート（SAFI 128）は、ASES間のEBGPマルチホップセッションでNHを変更せずに交換されます。一方、BGP CTルート（SAFI 76）は、EBGPシングルホップセッションを介して「NH Self」を掲載して宣伝されています。
The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP LU SAFI 4 in that it carries transport prefixes. The only difference is that it also carries in a Route Target an indication of which Transport Class the transport prefix belongs to and uses the RD to disambiguate multiple instances of the same transport prefix in a BGP UPDATE message.
AFI 1および2のBGP CT SAFI 76は、輸送のプレフィックスを運ぶという点でBGP Lu Safi 4に概念的に類似しています。唯一の違いは、輸送クラスがどのトランスポートクラスに属し、RDを使用してBGPアップデートメッセージで同じトランスポートプレフィックスの複数のインスタンスを描写するかを示すルートターゲットにも運ばれることです。
This section summarizes the procedures followed by various nodes speaking BGP CT family.
このセクションでは、BGP CTファミリーを話すさまざまなノードが続く手順をまとめます。
It is the responsibility of the operators to decide the Transport Classes to enable and use in their network. They are also expected to allocate a Transport Class RT to identify each Transport Class.
ネットワークで有効化および使用するためのトランスポートクラスを決定することは、オペレーターの責任です。また、各輸送クラスを特定するために輸送クラスRTを割り当てることも期待されています。
Operators configure the Transport Classes on the SNs and BNs in the network with Transport Class RTs and appropriate Route Distinguishers.
オペレーターは、トランスポートクラスのRTと適切なルートの違いを備えたネットワーク内のSNSおよびBNS上のトランスポートクラスを構成します。
Implementations MAY provide automatic generation and assignment of RD, RT values. They MAY also provide a way to manually override the automatic mechanism in order to deal with any conflicts that may arise with existing RD, RT values in different network domains participating in the deployment.
実装は、RD、RT値の自動生成と割り当てを提供する場合があります。また、展開に参加するさまざまなネットワークドメインの既存のRD、RT値で生じる可能性のある競合に対処するために、自動メカニズムを手動でオーバーライドする方法を提供する場合があります。
BGP CT routes are sent only to BGP peers that have negotiated the Multiprotocol Extensions capability described in Section 8 of [RFC4760] to be able to send and receive BGP CT routes.
BGP CTルートは、[RFC4760]のセクション8で説明されているマルチプロトコル拡張機能を交渉したBGPピアにのみ送信され、BGP CTルートを送信および受信できます。
At the ingress node of the tunnel's home domain, the tunneling protocols install tunnel routes in the TRDB associated with the Transport Class to which the tunnel belongs.
トンネルのホームドメインのイングレスノードでは、トンネルプロトコルがトンネルが属する輸送クラスに関連付けられたTRDBにトンネルルートをインストールします。
The egress node of the tunnel, i.e., the tunnel endpoint (EP), originates the BGP CT route with RD:EP in the NLRI, a Transport Class RT, and the PNH as the EP. This BGP CT route will be resolved over the tunnel route in TRDB at the ingress node. When the tunnel is up, the Classful Transport BGP route will become usable and get readvertised by the ingress node to BGP peers in neighboring domains.
トンネルの出口ノード、つまりトンネルエンドポイント（EP）は、NLRIのRD：EP、トランスポートクラスRT、およびEPとしてのPNHを搭載したBGP CTルートを発信します。このBGP CTルートは、IngressノードのTRDBのトンネルルート上で解決されます。トンネルが上昇すると、クラスフルトランスポートBGPルートが使用可能になり、隣接するドメインのBGPピアにイングレスノードによって読み取りされます。
Alternatively, the ingress node of the tunnel, which is also an ASBR/ ABR in a tunnel's home domain, may originate the BGP CT route for the tunnel destination with RD:EP in the NLRI, attaching a Transport Class Route Target that identifies the Transport Class. This BGP CT route is advertised to EBGP peers and IBGP peers in neighboring domains.
あるいは、トンネルのホームドメインのASBR/ ABRでもあるトンネルの侵入ノードは、NLRIのRD：EPを備えたトンネル宛先のBGP CTルートを発生し、輸送クラスを識別する輸送クラスルートターゲットを取り付けます。このBGP CTルートは、近隣のドメインのEBGPピアとIBGPピアに宣伝されています。
This originated route SHOULD NOT be advertised to the IBGP core that contains the tunnel. This may be implemented by mechanisms such as policy configuration. The impact of not prohibiting such advertisements is outside the scope of this document.
この起源のルートは、トンネルを含むIBGPコアに宣伝されるべきではありません。これは、ポリシー構成などのメカニズムによって実装できます。このような広告を禁止しないことの影響は、このドキュメントの範囲外です。
A unique RD SHOULD be used by the originator of a BGP CT route to disambiguate the multiple BGP advertisements for a transport endpoint. An administrator may use duplicate RDs based on local choice, understanding the impact on path diversity and troubleshooting, as described in Section 10.2.
輸送エンドポイントの複数のBGP広告を明確にするために、BGP CTルートのオリジネーターが一意のRDを使用する必要があります。管理者は、セクション10.2で説明されているように、ローカルの選択に基づいて複製RDSを使用し、パスの多様性とトラブルシューティングへの影響を理解することができます。
Upon receipt of a BGP CT route with a PNH EP that is not directly connected (e.g., an IBGP-route), a Mapping Community (the Transport Class RT) on the route is used to decide to which Resolution Scheme this route is to be mapped.
直接接続されていないPNH EP（IBGP-routeなど）を備えたBGP CTルートを受け取ると、ルート上のマッピングコミュニティ（トランスポートクラスRT）を使用して、このルートをマッピングする解像度スキームを決定します。
The Resolution Scheme for a Transport Class RT with Transport Class ID "C1" contains the TRDB of a Transport Class with same ID. The administrator MAY customize the Resolution Scheme for Transport Class ID "C1" to map to a different ordered list of TRDBs. If the Resolution Scheme for TC ID "C1" is not found, the Resolution Scheme containing the Best-Effort TRDB is used.
トランスポートクラスID「C1」を使用したトランスポートクラスRTの解決スキームには、同じIDを持つトランスポートクラスのTRDBが含まれています。管理者は、トランスポートクラスID「C1」の解像度スキームをカスタマイズして、TRDBの別の順序付けられたリストにマッピングできます。TC ID "C1"の解像度スキームが見つからない場合、Best-Effort TRDBを含む解像度スキームが使用されます。
The routes in the TRDBs associated with a selected Resolution Scheme are used to resolve the received PNH EP. The order of TRDBs in the Resolution Scheme is followed when resolving the received PNH, such that a route in a backup TRDB is used only when a matching route was not found for EP in the primary TRDBs preceding it. This achieves the fallback desired by the Resolution Scheme.
選択された解像度スキームに関連付けられたTRDBのルートは、受信したPNH EPを解決するために使用されます。解像度スキームのTRDBの順序は、受信したPNHを解決するときに続きます。そのため、バックアップTRDBのルートが使用され、その前のプライマリTRDBのEPの一致ルートが見つからなかった場合にのみ使用されます。これにより、解像度スキームが望むフォールバックが実現されます。
If the resolution process does not find a matching route for the EP in any of the associated TRDBs, the received BGP CT route MUST be considered unresolvable. (See Section 9.1.2.1 of [RFC4271].)
解像度プロセスが関連するTRDBのいずれにおいてもEPのマッチングルートを見つけられない場合、受信したBGP CTルートは解決できないと見なされなければなりません。（[RFC4271]のセクション9.1.2.1を参照してください。）
The received BGP CT route MUST be added to the TRDB corresponding to the Transport Class ID "C1" if the TC is provisioned locally. This step applies only if the Transport Class RT is received on a BGP CT family route. The RD in the BGP CT NLRI prefix RD:EP is ignored when the BGP CT route for EP is added to the TRDB so that overlay routes can resolve over this BGP CT tunnel route by performing a lookup for the EP. Please note that a TRDB is a logical database of tunnel routes belonging to the same Transport Class ID; hence, it only uses the EP as the lookup key (without RD or TC ID).
受信したBGP CTルートは、TCがローカルでプロビジョニングされている場合、トランスポートクラスID「C1」に対応するTRDBに追加する必要があります。このステップは、輸送クラスRTがBGP CTファミリールートで受信された場合にのみ適用されます。BGP CT NLRIプレフィックスRD：EPのRDは、EPのBGP CTルートがTRDBに追加されると無視され、EPの検索を実行することによりオーバーレイルートがこのBGP CTトンネルルートを解決できるようにします。TRDBは、同じトランスポートクラスIDに属するトンネルルートの論理データベースであることに注意してください。したがって、EPをルックアップキーとしてのみ使用します（RDまたはTC IDなし）。
If no Mapping Community is found on a BGP CT route, the Best-Effort Resolution Scheme is used to resolve the route's next hop, and the BGP CT route is not added to any TRDB.
BGP CTルートでマッピングコミュニティが見つからない場合、最適な解像度スキームを使用してルートの次のホップを解決し、BGP CTルートはTRDBに追加されません。
This section describes the MPLS label handling when readvertising a BGP CT route with "NH self". When readvertising a BGP CT route with "NH self", a BN allocates an MPLS label to advertise upstream in the BGP CT NLRI. The BN also installs an MPLS route for that label that swaps the incoming label with the label received from the downstream BGP speaker (or pops the incoming label if the label received from the downstream BGP speaker was Implicit NULL). The MPLS route then pushes received traffic to the transport tunnel or direct interface that the BGP CT route's PNH resolved over.
このセクションでは、「NH Self」を使用してBGP CTルートを読み取るときのMPLSラベル処理について説明します。「NH Self」でBGP CTルートを読み取ると、BNはMPLSラベルを割り当ててBGP CT NLRIで上流を宣伝します。また、BNは、下流のBGPスピーカーから受信したラベルと受信ラベルと交換するラベルのMPLSルートをインストールします（または、下流のBGPスピーカーから受け取ったラベルが暗黙のヌルである場合、着信ラベルをポップします）。その後、MPLSルートは、BGP CTルートのPNHが解決した輸送トンネルまたは直接インターフェイスへの受信トラフィックをプッシュします。
The label SHOULD be allocated with "per-prefix" label-allocation semantics. The IP prefix in the TRDB context (Transport Class, IP prefix) is used as the key to "per-prefix" label allocation. This helps in avoiding BGP CT route churn throughout the CT network when an instability (e.g., link failure) is experienced in a domain. The failure is not propagated further than the BN closest to the failure. If a different label-allocation mode is used, the impact on end-to-end convergence should be considered.
ラベルには、「PER-PREFIX」ラベルアロケーションセマンティクスで割り当てる必要があります。TRDBコンテキスト（トランスポートクラス、IPプレフィックス）のIPプレフィックスは、「PREFIXごと」ラベル割り当てのキーとして使用されます。これは、ドメインで不安定性（リンク障害など）が経験される場合、CTネットワーク全体でBGP CTルートの解約を回避するのに役立ちます。障害は、障害に最も近いBNよりもさらに伝播されません。別のラベルアロケーションモードを使用する場合、エンドツーエンドの収束への影響を考慮する必要があります。
The value of the advertised MPLS label is locally significant and is dynamic by default. A BN may provide an option to allocate a value from a statically provisioned range. This can be achieved using a locally configured export policy or via mechanisms such as the ones described related to BGP Prefix-SID as described in BGP (see [RFC8669]).
広告されたMPLSラベルの値は局所的に重要であり、デフォルトでは動的です。BNは、静的なプロビジョニング範囲から値を割り当てるオプションを提供する場合があります。これは、ローカルで構成されたエクスポートポリシーを使用して、またはBGPで説明されているBGPプレフィックス-SIDに関連するようなメカニズムを介して実現できます（[RFC8669を参照]）。
If a route is received with a PNH that is known to be directly connected (for example, an EBGP single-hop neighbor address), the directly connected interface is checked for MPLS forwarding capability. No other next hop resolution process is performed since the inter-AS link can be used for any Transport Class.
直接接続されていることが知られているPNH（たとえば、EBGPシングルホップネイバーアドレス）でルートを受信した場合、直接接続されたインターフェイスには、MPLS転送機能がチェックされます。AS Inter-Asリンクを任意の輸送クラスに使用できるため、他の次のホップ解決プロセスは実行されません。
If the inter-AS links need to honor Transport Class, then the BN MUST follow the procedures of an ingress node (Section 7.3) and perform the next hop resolution process. In order to make the link Transport Class aware, the route to the directly connected PNH is installed in the TRDB belonging to the associated Transport Class.
Inter-ASリンクが輸送クラスを称える必要がある場合、BNは侵入ノード（セクション7.3）の手順に従い、次のホップ解像度プロセスを実行する必要があります。リンク輸送クラスを認識させるために、直接接続されたPNHへのルートは、関連する輸送クラスに属するTRDBにインストールされます。
When multiple instances of a given RD:EP exist with different forwarding characteristics, BGP ADD-PATH (see [RFC7911]) is helpful.
特定のRD：EPの複数のインスタンスが異なる転送特性を持つ場合、BGPアドパス（[RFC7911]を参照）が役立ちます。
When multiple BNs exist such that they advertise an "RD:EP" prefix to Route Reflectors (RRs), the RRs may hide all but one of the BNs, unless BGP ADD-PATH (see [RFC7911]) is used for the BGP CT family. This is similar to L3VPN inter-AS option B scenarios.
BGPアドパス（[RFC7911]を参照）をBGP CTファミリーに使用しない限り、「RD：EP」プレフィックス（RRS）を宣伝するように複数のBNが存在する場合、RRSはBNSの1つを除くすべてを非表示にすることがあります。これは、L3VPN Inter-ASオプションBシナリオに似ています。
Hence, BGP ADD-PATH (see [RFC7911]) SHOULD be used for the BGP CT family to avoid path hiding through RRs so that the RR sends multiple CT routes for RD:EP to its clients. This improves the convergence time when the path via one of the multiple BNs fails.
したがって、BGPアドパス（[RFC7911]を参照）をBGP CTファミリーに使用して、RRがRD：EP用の複数のCTルートをクライアントに送信できるように、RRを介してパスを隠すことを避ける必要があります。これにより、複数のBNの1つを介したパスが失敗する収束時間が改善されます。
A pair of redundant ABRs, each acting as an RR with the next hop set to itself, may choose each other as the best path instead of the upstream ASBR, causing a traffic-forwarding loop.
それぞれが次のホップセットを持つRRとして機能する一対の冗長ABRは、上流のASBRの代わりに互いを最適なパスとして選択し、交通に向かってループを引き起こす可能性があります。
This problem can happen for routes of any BGP address family, including BGP CT and BGP LU.
この問題は、BGP CTやBGP Luを含むBGPアドレスファミリのルートで発生する可能性があります。
Using one or more of the approaches described in [BGP-FWD-RR] lowers the possibility of such loops in a network with redundant ABRs.
[BGP-FWD-RR]で説明されている1つ以上のアプローチを使用すると、冗長ABRがあるネットワーク内のこのようなループの可能性が低下します。
Upon receipt of a BGP service route (for example, AFI/SAFI: 1/1, 2/1) with a PNH as the EP that is not directly connected (for example, an IBGP-route), a Mapping Community (for example, a Color Extended Community) on the route is used to decide to which Resolution Scheme this route is to be mapped.
BGPサービスルート（たとえば、AFI/SAFI：1/1、2/1）を受信すると、PNHを直接接続されていないEPとして（たとえば、IBGP-route）、マッピングコミュニティ（たとえば、色の拡張コミュニティ）をルートのマッピングコミュニティ（このルートの解像度スキームがマッピングするかどうかを決定するために使用されます。
The Resolution Scheme for a Color extended community with Color "C1" contains a TRDB for a Transport Class with same ID followed by the Best-Effort TRDB. The administrator MAY customize the Resolution Scheme to map to a different ordered list of TRDBs. If the Resolution Scheme for TC ID "C1" is not found, the Resolution Scheme containing the Best-Effort TRDB is used.
色「C1」を備えた色拡張コミュニティの解像度スキームには、同じIDを持つトランスポートクラスのTRDBが含まれています。管理者は、解決スキームをカスタマイズして、TRDBの別の順序付けられたリストにマッピングできます。TC ID "C1"の解像度スキームが見つからない場合、Best-Effort TRDBを含む解像度スキームが使用されます。
If no Mapping Community was found on the overlay route, the "Best Effort Resolution Scheme" is used for resolving the route's next hop. This behavior is backward compatible to behavior of an implementation that does not follow procedures described in this document.
オーバーレイルートでマッピングコミュニティが見つからなかった場合、「ベストエフェクション解決スキーム」がルートの次のホップを解決するために使用されます。この動作は、このドキュメントに記載されている手順に従わない実装の動作と後方互換性があります。
The routes in the TRDBs associated with the selected Resolution Scheme are used to resolve the received PNH EP. The order of TRDBs in a Resolution Scheme is followed when resolving the received PNH, such that a route in a backup TRDB is used only when a matching route was not found for the EP in the primary TRDBs preceding it. This achieves the fallback desired by the Resolution Scheme.
選択された解像度スキームに関連付けられたTRDBのルートは、受信したPNH EPを解決するために使用されます。解像度スキームのTRDBの順序は、受信したPNHを解決するときに続きます。そのため、バックアップTRDBのルートが使用され、その前のプライマリTRDBのEPの一致ルートが見つからなかった場合にのみ使用されます。これにより、解像度スキームが望むフォールバックが実現されます。
If the resolution process does not find a Tunnel Route for the EP in any of the Transport Route Databases, the service route MUST be considered unresolvable. (See Section 9.1.2.1 of [RFC4271]).
解像度プロセスが輸送ルートデータベースのいずれにおいてもEPのトンネルルートを見つけられない場合、サービスルートは解決できないと見なされる必要があります。（[RFC4271]のセクション9.1.2.1を参照）。
Note: For an illustration of above procedures in an MPLS network, refer to Section 8.
注：MPLSネットワークの上記の手順の図については、セクション8を参照してください。
It is also possible to represent a 'Best-Effort' SLA as a Transport Class. At the time of writing, BGP LU is used to extend the best-effort intra-domain tunnels to other domains.
また、輸送クラスとして「ベストエフォルト」SLAを表すことも可能です。執筆時点で、BGP Luは、最高のエフォルトドメイン内トンネルを他のドメインに拡張するために使用されます。
Alternatively, BGP CT may also be used to carry the best-effort tunnels. This document reserves the Transport Class ID value 0 to represent the "Best-Effort Transport Class ID". However, implementations SHOULD provide configuration to use a different value for this purpose. Procedures to manage differences in Transport Class ID namespaces between domains are provided in Section 11.2.2.
あるいは、BGP CTを使用して、最高のエフォルトトンネルを運ぶこともできます。このドキュメントは、「ベストエフォルトトランスポートクラスID」を表すために、トランスポートクラスID値0を留保します。ただし、実装は、この目的に異なる値を使用する構成を提供する必要があります。ドメイン間のトランスポートクラスID名空間の違いを管理する手順は、セクション11.2.2に記載されています。
The "Best-Effort Transport Class ID" value is used in the "Transport Class ID" field of the Transport Class RT that is attached to the BGP CT route that advertises a best-effort tunnel endpoint. Thus, the RT formed is called the "Best-Effort Transport Class RT".
「Best-Effort Transport Class ID」値は、ベストエフォルトトンネルエンドポイントを宣伝するBGP CTルートに接続されているトランスポートクラスRTの「トランスポートクラスID」フィールドで使用されます。したがって、形成されたRTは「Best-Effort Transport Class RT」と呼ばれます。
When a BN or SN receives a BGP CT route with Best-Effort Transport Class RT as the Mapping Community, the Best-Effort Resolution Scheme is used for resolving the BGP next hop, and the resultant route is installed in the best-effort transport route database. If no best-effort tunnel was found to resolve the BGP next hop, the BGP CT route MUST be considered unusable and not be propagated further.
BNまたはSNがベストエフォルトトランスポートクラスRTを備えたBGP CTルートをマッピングコミュニティとして受信すると、BGPの次のホップの解決に使用され、結果のルートはベストエフォルトトランスポートルートデータベースにインストールされます。BGPの次のホップを解決するために最良のエフォルトトンネルが見つからなかった場合、BGP CTルートは使用できないと見なされ、さらに伝播しないでください。
When a BGP speaker receives an overlay route without any explicit Mapping Community, and absent local policy, the Best-Effort Resolution Scheme is used for resolving the BGP next hop on the route. This behavior is backward compatible to behavior of an implementation that does not follow procedures described in this document.
BGPスピーカーが明示的なマッピングコミュニティなしでオーバーレイルートを受信し、ローカルポリシーがない場合、ルートのBGPの次のホップを解決するために最良の解像度スキームが使用されます。この動作は、このドキュメントに記載されている手順に従わない実装の動作と後方互換性があります。
Implementations MAY provide configuration to selectively install BGP CT routes to the Forwarding Information Base (FIB) to provide reachability for control-plane peering towards endpoints in other domains.
実装は、BGP CTルートを転送情報ベース（FIB）に選択的にインストールする構成を提供し、他のドメインのエンドポイントに向けてコントロールプレーンのピアリングのリーチ性を提供する場合があります。
The Tunnel Encapsulation Attribute, described in [RFC9012], can be used to request a specific type of tunnel encapsulation. This attribute may apply to BGP service routes or transport routes including BGP CT family routes.
[RFC9012]に記載されているトンネルカプセル化属性は、特定のタイプのトンネルカプセル化を要求するために使用できます。この属性は、BGP CTファミリールートを含むBGPサービスルートまたは輸送ルートに適用される場合があります。
It should be noted that in such cases "Transport Class ID/Color" can exist in multiple places on the same route, and a precedence order needs to be established to determine which Transport Class the route's next hop should resolve over. This document specifies the following order of precedence with more-specific scoping of Color preferred to less-specific scoping:
このような場合、「輸送クラスID/色」は同じルートの複数の場所に存在する可能性があり、ルートの次のホップが解決すべき輸送クラスを決定するために優先順位を確立する必要があることに注意してください。このドキュメントは、以下の優先順位を指定し、より特異的なスコープよりも優先される色のより特異的なスコーピングを指定します。
* Color sub-TLV in the Tunnel Encapsulation Attribute.
* トンネルカプセル化属性のカラーサブTLV。
* Transport Class RT on a BGP CT route.
* BGP CTルートでクラスRTを輸送します。
* Color extended community on a BGP service route.
* BGPサービスルートの拡張コミュニティ。
Color specified in the Color sub-TLV in a TEA is a more-specific indication of "Transport Class ID/Color" than Mapping Community (Transport Class RT) on a BGP CT transport route, which, in turn, is more specific than a service route scoped Mapping Community (Color extended community).
お茶のカラーサブTLVで指定された色は、BGP CTトランスポートルートのマッピングコミュニティ（トランスポートクラスRT）よりも「トランスポートクラスID/色」をより特異的に示しています。
Any BGP attributes or mechanisms defined in future that carry Transport Class ID/Color on the route are expected to specify the order of precedence relative to the above.
ルート上の輸送クラスID/色を運ぶ将来定義されているBGP属性またはメカニズムは、上記に比べて優先順位の順序を指定することが期待されます。
Flowspec routes using redirect-to-IP next hop are described in [FLOWSPEC-REDIR-IP].
Redirect-to-IP次のホップを使用したFlowsPecルートは、[FlowsPec-Redir-IP]で説明されています。
Such Flowspec BGP routes with redirect-to-IP next hop MAY be attached with a Mapping Community (e.g., color:0:100), which allows redirecting the flow traffic over a tunnel to the IP next hop satisfying the desired SLA (e.g., Transport Class color 100).
このようなFlowsPec BGPルートは、リダイレクトからIPへの次のホップを備えており、マッピングコミュニティ（例：Color：0：100）に接続できます。
The Flowspec BGP family acts as just another service that can make use of the BGP CT architecture to achieve flow-based forwarding with SLAs.
FlowsPec BGPファミリは、BGP CTアーキテクチャを利用してSLAを使用したフローベースの転送を実現できる別のサービスとして機能します。
BGP CT procedures apply equally to IPv4- and IPv6-enabled intra-AS or inter-AS option A, B, and C networks. This section describes the applicability of BGP CT to IPv6 at various layers.
BGP CT手順は、IPv4-およびIPv6対応のIntra-ASまたはASオプションA、B、およびCネットワークに等しく適用されます。このセクションでは、さまざまな層でのBGP CTのIPv6への適用性について説明します。
A network that is BGP CT enabled supports IPv6 service families (for example, AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols like SRTEv6, LDPv6, or RSVP-TEv6.
BGP CTが有効になっているネットワークは、IPv6サービスファミリ（AFI/SAFI 2/1または2/128）およびSRTEV6、LDPV6、またはRSVP-TEV6などのIPv6輸送シグナル伝達プロトコルをサポートします。
Procedures in this document also apply to a network with Pure IPv6 core, that uses MPLS forwarding for intra-domain tunnels and inter-AS links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry global IPv6 address tunnel endpoints in the NLRI. Service family routes (for example, AFI/SAFI: 1/1, 2/1, 1/128, and 2/128) are also advertised with those Global IPv6 addresses as next hop.
このドキュメントの手順は、ドメイン内トンネルおよびリンク間でMPLS転送を使用する純粋なIPv6コアを備えたネットワークにも適用されます。BGP CTV6ファミリー（AFI/SAFI：2/76）は、NLRIのグローバルIPv6アドレストンネルエンドポイントを運ぶために使用されます。サービスファミリルート（たとえば、AFI/SAFI：1/1、2/1、1/128、および2/128）も、次のホップとしてこれらのグローバルIPv6アドレスで宣伝されています。
Procedures in this document also apply to a 6PE network with an IPv4 core, which uses MPLS forwarding for intra-domain tunnels and inter-AS links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IPv4 Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service family routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised with those IPv4 Mapped IPv6 addresses as next hop.
このドキュメントの手順は、ドメイン内トンネルおよびASリンク間のMPLS転送を使用するIPv4コアを備えた6PEネットワークにも適用されます。BGP CTV6ファミリー（AFI/SAFI：2/76）は、NLRIのIPv4マッピングIPv6アドレストンネルエンドポイントを運ぶために使用されます。IPv6サービスファミリルート（たとえば、AFI/SAFI：2/1、2/128）も、次のホップとしてIPv4マッピングされたIPv6アドレスで宣伝されています。
The PE-CE attachment circuits may use IPv4 addresses only, IPv6 addresses only, or both IPv4 and IPv6 addresses.
PE-CEアタッチメントサーキットは、IPv4アドレスのみ、IPv6アドレスのみ、またはIPv4およびIPv6アドレスの両方を使用する場合があります。
The BGP CT family (AFI/SAFI 2/76) may be used to set up inter-domain tunnels of a certain Transport Class when using a Segment Routing over IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS tunneling mechanism.
BGP CTファミリー（AFI/SAFI 2/76）は、IPV6（SRV6）データプレーンを使用する場合、またはリンク内またはトンネリングメカニズム内で、特定の輸送クラスのドメイン間トンネルをセットアップするために使用できます。
Details of SRv6 Endpoint behaviors used by BGP CT and the procedures are specified and illustrated in a separate document (see [BGP-CT-SRv6]). As noted in that document, a BGP CT route update for SRv6 includes a BGP attribute containing SRv6 SID information (e.g., a BGP Prefix-SID [RFC9252]) with the Transposition Scheme disabled.
BGP CTおよび手順で使用されるSRV6エンドポイント動作の詳細は、別のドキュメントに指定および説明されています（[BGP-CT-SRV6]を参照）。そのドキュメントに記載されているように、SRV6のBGP CTルートアップデートには、転位スキームが無効になってSRV6 SID情報（例：BGPプレフィックス-SID [RFC9252]）を含むBGP属性が含まれています。
If a BGP speaker receives both transitive and non-transitive (see Section 13.2.1.1.1 and Section 13.2.1.1.2, respectively) versions of a Transport Class extended community on a route, only the transitive one is used.
BGPスピーカーが推移的および非透過性の両方を受信する場合（それぞれセクション13.2.1.1.1およびセクション13.2.1.1.2を参照）、ルート上の輸送クラス拡張コミュニティのバージョンは、推移的なコミュニティのみが使用されます。
If a BGP speaker considers a received "Transport Class" extended community (the transitive or non-transitive version) or any other part of a BGP CT route invalid for some reason, but is able to successfully parse the NLRI and attributes, the treat-as-withdraw approach from [RFC7606] is used. The route is kept as Unusable, with appropriate diagnostic information, to aid troubleshooting.
BGPスピーカーが受信した「輸送クラス」拡張コミュニティ（推移的または非繰り返しバージョン）またはBGP CTルートの他の部分が何らかの理由で無効であると考えるが、NLRIと属性をうまく解析できる場合、[RFC7606]からの扱いのwithdrawアプローチが使用されます。ルートは、トラブルシューティングを支援するために、適切な診断情報を使用して使用できないものとして保持されます。
This section illustrates BGP CT procedures in an inter-AS option C MPLS network.
このセクションでは、Option CMPLSネットワーク間のBGP CT手順を示します。
All illustrations in this document make use of IP address ranges as described in [RFC6890]. The range 192.0.2.0/24 is used to represent transport endpoints like loopback addresses. The range 203.0.113.0/24 is used to represent service route prefixes advertised in AFI/SAFIs: 1/1 or 1/128.
このドキュメントのすべての図は、[RFC6890]で説明されているように、IPアドレスの範囲を使用します。範囲192.0.2.0/24は、ループバックアドレスなどの輸送エンドポイントを表すために使用されます。範囲203.0.113.0/24は、AFI/SAFISで宣伝されているサービスルートプレフィックスを表すために使用されます：1/1または1/128。
Though this section illustrates the use of IPv4, as described in Section 7.12, these procedures work equally for IPv6 as well.
このセクションでは、セクション7.12で説明されているように、IPv4の使用を示していますが、これらの手順はIPv6でも同様に機能します。
[RR26] [RR27] [RR16]
| | |
| | |
| +--[ABR23]--+ | +--[ASBR21]-[ASBR13]--+ | +-[PE11]+
| | | | | \ / | | | |
[CE41]-[PE25]-[P28] [P29] \/ [P15] [CE31]
| | | /\ | | |
| | | / \ | | |
| | | / \ | | |
+--[ABR24]--+ +--[ASBR22]-[ASBR14]--+ +-[PE12]+
: AS2 : AS2 : :
AS4 : region-1 : region-2 : AS1 : AS3
: : : :
203.0.113.41 ---------- Traffic Direction ----------> 203.0.113.31
Figure 3: Multi-Domain BGP CT Network
図3：マルチドメインBGP CTネットワーク
This example shows a provider MPLS network that consists of two ASes, AS1 and AS2, that serve customers AS3 and AS4, respectively. The traffic direction being described is from CE41 to CE31. CE31 may request a specific SLA (mapped to Gold for this example), when traversing these provider networks.
この例は、それぞれAS3とAS4にサービスを提供するAS1とAS2の2つのASESで構成されるプロバイダーMPLSネットワークを示しています。記載されている交通方向は、CE41からCE31までです。CE31は、これらのプロバイダーネットワークを横断するときに、特定のSLA（この例ではゴールドにマッピングされた）を要求する場合があります。
AS2 is further divided into two regions. There are three tunnel domains in the provider's space:
AS2はさらに2つの領域に分割されます。プロバイダーのスペースには3つのトンネルドメインがあります。
* AS1 uses ISIS Flex-Algo (see[RFC9350]) intra-domain tunnels.
* AS1は、ISIS Flex-Algo（[RFC9350]を参照）を使用します。ドメイン内トンネル。
* AS2 uses RSVP-TE intra-domain tunnels.
* AS2はRSVP-TEイントラドメイントンネルを使用します。
MPLS forwarding is used within these domains and on inter-domain links.
MPLS転送は、これらのドメイン内およびドメイン間リンク内で使用されます。
The network exposes two Transport Classes: "Gold" with Transport Class ID 100 and "Bronze" with Transport Class ID 200. These Transport Classes are provisioned at the PEs and the Border nodes (ABRs and ASBRs) in the network.
ネットワークは、トランスポートクラスID 100を備えた「ゴールド」とトランスポートクラスID 200の「ブロンズ」の2つの輸送クラスを公開します。これらの輸送クラスは、ネットワーク内のPESおよび境界ノード（ABRとASBR）でプロビジョニングされます。
The following tunnels exist for the Gold Transport Class:
ゴールド輸送クラスには、次のトンネルが存在します。
* PE25_to_ABR23_gold - RSVP-TE tunnel
* PE25_TO_ABR23_GOLD -RSVP -TEトンネル
* PE25_to_ABR24_gold - RSVP-TE tunnel
* PE25_TO_ABR24_GOLD -RSVP -TEトンネル
* ABR23_to_ASBR22_gold - RSVP-TE tunnel
* ABR23_TO_ASBR22_GOLD -RSVP -TEトンネル
* ASBR13_to_PE11_gold - SRTE tunnel
* ASBR13_TO_PE11_GOLD -SRTEトンネル
* ASBR14_to_PE11_gold - SRTE tunnel
* ASBR14_TO_PE11_GOLD -SRTEトンネル
The following tunnels exist for Bronze Transport Class:
ブロンズ輸送クラスのために、次のトンネルが存在します。
* PE25_to_ABR23_bronze - RSVP-TE tunnel
* PE25_TO_ABR23_BRONZE -RSVP -TEトンネル
* ABR23_to_ASBR21_bronze - RSVP-TE tunnel
* ABR23_TO_ASBR21_BRONZE -RSVP -TEトンネル
* ABR23_to_ASBR22_bronze - RSVP-TE tunnel
* ABR23_TO_ASBR22_BRONZE -RSVP -TEトンネル
* ABR24_to_ASBR21_bronze - RSVP-TE tunnel
* ABR24_TO_ASBR21_BRONZE -RSVP -TEトンネル
* ASBR13_to_PE12_bronze - ISIS Flex-Algo tunnel
* ASBR13_TO_PE12_BRONZE -ISIS Flex -Algoトンネル
* ASBR14_to_PE11_bronze - ISIS Flex-Algo tunnel
* ASBR14_TO_PE11_BRONZE -ISIS Flex -Algoトンネル
These tunnels are either provisioned or autodiscovered to belong to Transport Class IDs 100 or 200.
これらのトンネルは、輸送クラスID 100または200に属するようにプロビジョニングまたは自動化されています。
Service nodes PE11 and PE12 negotiate service families (AFI/SAFIs: 1/1 and 1/128) on the BGP session with RR16. Service helpers RR16 and RR26 exchange these service routes with the next hop unchanged over a multihop EBGP session between the two ASes. PE25 negotiates service families (AFI/SAFIs: 1/1 and 1/128) with RR26.
RR16とのBGPセッションで、サービスノードPE11とPE12はサービスファミリ（AFI/SAFIS：1/1および1/128）をネゴシエートします。サービスヘルパーRR16とRR26は、これらのサービスルートを次のホップと交換し、2つのASEの間のマルチホップEBGPセッションで変わりません。PE25は、RR26でサービスファミリ（AFI/SAFIS：1/1および1/128）を交渉します。
The PEs see each other as the next hop in the BGP UPDATE message for the service family routes. BGP ADD-PATH send and receive are enabled on both directions on the EBGP multihop session between RR16 and RR26 for AFI/SAFIs: 1/1 and 1/128. BGP ADD-PATH send is negotiated in the RR to PE direction in each AS. This is to avoid the path-hiding service routes at the RR, i.e., AFI/SAFI 1/1 routes advertised by both PE11 and PE12 or AFI/SAFI 1/128 routes originated by both PE11 and PE12 using the same RD.
PESは、サービスファミリルートのBGPアップデートメッセージの次のホップと見なします。BGPアドパス送信と受信は、AFI/SAFISのRR16とRR26の間のEBGPマルチホップセッションの両方向で有効になります：1/1および1/128。BGPアドパス送信は、RRでそれぞれのPE方向から交渉されます。これは、RRでのパスハイディングサービスルート、つまりPE11とPE12またはAFI/SAFI 1/128ルートの両方で宣伝されたAFI/SAFI 1/1ルートを回避するためです。
Forwarding happens using service routes installed at service nodes PE25, PE11, and PE12 only. Service routes received from CEs are not present in any other nodes' FIB in the network.
転送は、サービスノードPE25、PE11、およびPE12のみにインストールされたサービスルートを使用して発生します。CESから受け取ったサービスルートは、ネットワーク内の他のノードのFIBには存在しません。
As an example, CE31 advertises a route for prefix 203.0.113.31 with the next hop as itself to PE11 and PE12. CE31 can attach a Mapping Community color:0:100 on this route to indicate its request for a Gold SLA. Or, PE11 can attach the same using locally configured policies.
例として、CE31はプレフィックス203.0.113.31のルートを宣伝し、次のホップはPE11とPE12にそれ自体が宣伝されています。CE31は、このルートでマッピングコミュニティの色：0：100を添付して、ゴールドSLAの要求を示すことができます。または、PE11は、ローカルで構成されたポリシーを使用して同じものを添付できます。
Consider CE31 getting VPN service from PE11. The RD1:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE11 with the next hop set to itself (192.0.2.11) and label V-L1 to RR16 with the Mapping Community color:0:100 attached. RR16 advertises this route with the BGP ADD-PATH ID set to RR26, which readvertises to PE25 with the next hop unchanged. Now, PE25 can resolve the PNH 192.0.2.11 using transport routes received in BGP CT or BGP LU.
CE31がPE11からVPNサービスを取得することを検討してください。RD1：203.0.113.31ルートは、次のホップセット（192.0.2.11）とマッピングコミュニティの色でV-L1からRR16にラベル：0：100にaf11によってAFI/SAFI 1/128で読み取りされます。RR16は、BGPアドパスIDセットをRR26に設定してこのルートを宣伝します。RR26は、次のホップが変更されていない状態でPE25にReadvertiseです。現在、PE25は、BGP CTまたはBGP Luで受け取った輸送ルートを使用してPNH 192.0.2.11を解決できます。
Using BGP ADD-PATH, service routes advertised by PE11 and PE12 for AFI/SAFIs: 1/1 and 1/128 reach PE25 via RR16, RR26 with the next hop unchanged, as PE11 or PE12.
BGPアドパスを使用して、AFI/SAFISでPE11とPE12によって宣伝されたサービスルート：1/1および1/128にRR16、RR26を介してPE25に到達し、次のホップはPE11またはPE12として変化しません。
The IP FIB at the PE25 VRF will have a route for 203.0.113.31 with a next hop when resolved that points to a Gold tunnel in the ingress domain.
PE25 VRFのIP FIBには、203.0.113.31のルートがあり、イングレスドメインの金トンネルを指すと解決すると、次のホップがあります。
Egress nodes PE11 and PE12 negotiate a BGP CT family with transport ASBRs ASBR13 and ASBR14. These egress nodes originate BGP CT routes for tunnel endpoint addresses that are advertised as a next hop in BGP service routes. In this example, both PEs participate in Transport Classes Gold and Bronze. The protocol procedures are explained using the Gold SLA transport plane; the Bronze SLA transport plane is used to highlight the path-hiding aspects.
出力ノードPE11とPE12は、輸送ASBRS ASBR13およびASBR14でBGP CTファミリーを交渉します。これらの出力ノードは、BGPサービスルートの次のホップとして宣伝されているトンネルエンドポイントアドレスのBGP CTルートを発生します。この例では、両方のPEが輸送クラスの金と青銅に参加しています。プロトコル手順は、金SLA輸送機を使用して説明されています。ブロンズSLA輸送機は、パスハイディングの側面を強調するために使用されます。
For Gold tunnels, PE11 is provisioned with Transport Class having TC ID 100, RD value 192.0.2.11:100, and a transport-target:0:100. For Bronze tunnels, PE11 is provisioned with Transport Class 200, RD value 192.0.2.11:200, and transport-target:0:200. Similarly, for Gold tunnels, PE12 is provisioned with Transport Class having TC ID 100, RD value 192.0.2.12:100, and a transport-target:0:100. For Bronze tunnels, PE12 is provisioned with Transport Class having TC ID 200, RD value 192.0.2.12:200, and transport-target:0:200. Note that, in this example, the BGP CT routes carry only the Transport Class RT and no IP address format route target.
金のトンネルの場合、PE11はTC ID 100、RD値192.0.2.11:100、および輸送標的：0：100を持つ輸送クラスでプロビジョニングされます。ブロンズトンネルの場合、PE11はトランスポートクラス200、RD値192.0.2.11:200、輸送標的でプロビジョニングされています：0：200。同様に、金のトンネルの場合、PE12はTC ID 100、RD値192.0.2.12:100、輸送標識：0：100を持つ輸送クラスでプロビジョニングされます。ブロンズトンネルの場合、PE12はTC ID 200、RD値192.0.2.12:200、輸送標的を備えた輸送クラスでプロビジョニングされています：0：200。この例では、BGP CTルートはトランスポートクラスRTのみを持ち、IPアドレス形式のルートターゲットはありません。
The RD value originated by an egress node is not modified by any BGP speakers when the route is readvertised to the ingress node. Thus, the RD can be used to identify the originator (unique RD provisioned) or set of originators (RD reused on multiple nodes).
出口ノードから発信されるRD値は、ルートがイングレスノードに読み込まれた場合、BGPスピーカーによって変更されません。したがって、RDを使用して、オリジネーター（一意のRDプロビジョニング）またはオリジネーターのセット（複数のノードで再利用）を識別できます。
Similarly, these Transport Classes are also configured on ASBRs, ABRs, and PEs with same Transport Class RT and unique RDs.
同様に、これらの輸送クラスは、同じ輸送クラスRTと一意のRDSを持つASBR、ABR、およびPESでも構成されています。
ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs ASBR21 and ASBR22 in neighboring ASes. ASBR21 and ASBR22 negotiate BGP CT family with RR27 in region 2, which reflects BGP CT routes to ABR23 and ABR24. ABR23 and ABR24 negotiate BGP CT family with ingress node PE25 in region 1. The BGP LU family is also negotiated on these sessions alongside the BGP CT family. The BGP LU family carries Best-Effort Transport Class routes; BGP CT carries Gold and Bronze Transport Class routes.
ASBR13およびASBR14は、隣接するASEで輸送ASBRS ASBR21およびASBR22とBGP CTファミリーを交渉します。ASBR21およびASBR22は、BGP CTルートをABR23およびABR24に反映しているRR27とBGP CTファミリーをRR27と交渉します。ABR23およびABR24は、BGP CTファミリーとリージョン1のイングレスノードPE25と交渉します。BGPLUファミリーは、BGP CTファミリーとともにこれらのセッションで交渉されます。BGP Luファミリーには、最高の輸送クラスルートがあります。BGP CTには、金と青銅の輸送クラスルートがあります。
PE11 is provisioned to originate a BGP CT route for endpoint PE11, with a Gold SLA. This route is sent with NLRI RD prefix 192.0.2.11:100:192.0.2.11, Label B-L0, next hop 192.0.2.11, and a Route Target extended community transport-target:0:100. Label B-L0 can either be Implicit NULL (Label 3) or a UHP label.
PE11は、ゴールドSLAを使用して、エンドポイントPE11のBGP CTルートを発信するようにプロビジョニングされています。このルートは、NLRI RDプレフィックス192.0.2.11:100:192.0.2.11、ラベルB-L0、次のホップ192.0.2.11、およびルートターゲットがコミュニティトランスポートターゲットを拡張しました：0：100で送信されます。ラベルB-L0は、暗黙のヌル（ラベル3）またはUHPラベルのいずれかです。
This route is received by ASBR13 and it resolves over the tunnel ASBR13_to_PE11_gold. The route is then readvertised by ASBR13 in BGP CT family to ASBRs ASBR21, ASBR22 according to export policy. This route is sent with same NLRI RD prefix 192.0.2.11:100:192.0.2.11, Label B-L1, the next hop set to itself, and transport-target:0:100. An MPLS swap route is installed at ASBR13 for B-L1 with a next hop pointing to ASBR13_to_PE11_gold tunnel.
このルートはASBR13によって受信され、トンネルASBR13_TO_PE11_GOLDで解決されます。その後、このルートは、BGP CTファミリーのASBR13によってASBRS ASBR21、ASBR22に輸出ポリシーに従って読み込まれます。このルートは、同じNLRI RDプレフィックス192.0.2.11:100:192.0.2.11、ラベルB-L1、次のホップセット自体、輸送標的：0：100で送信されます。MPLSスワップルートはASBR13にB-L1のためにインストールされ、次のホップがASBR13_TO_PE11_GOLDトンネルを指します。
Similarly, ASBR14 also receives a BGP CT route for 192.0.2.11:100:192.0.2.11 from PE11, and it resolves over the tunnel ASBR14_to_PE11_gold. The route is then readvertised by ASBR14 in the BGP CT family to ASBRs ASBR21 and ASBR22 according to export policy. This route is sent with the same NLRI RD prefix 192.0.2.11:100:192.0.2.11, Label B-L2, next hop set to itself, and transport-target:0:100. An MPLS swap route is installed at ASBR14 for B-L1 with a next hop pointing to ASBR14_to_PE11_gold tunnel.
同様に、ASBR14は、PE11から192.0.2.11:100:192.0.2.11のBGP CTルートも受け取り、トンネルASBR14_TO_PE11_GOLDで解決します。次に、輸出ポリシーに従って、BGP CTファミリーのASBR14によってASBRS ASBR21およびASBR22にASBR14によって読み込まれます。このルートは、同じNLRI RDプレフィックス192.0.2.11:100:192.0.2.11、ラベルB-L2、次のホップセット自体、輸送標的：0：100で送信されます。MPLSスワップルートはASBR14にB-L1のためにインストールされ、ASBR14_TO_PE11_GOLDトンネルを指す次のホップがあります。
In the Bronze plane, the BGP CT route with a Bronze SLA to endpoint PE11 is originated by PE11 with an NLRI containing RD prefix 192.0.2.11:200:192.0.2.11 and an appropriate label. The use of distinct RDs for Gold and Bronze allows both Gold and Bronze advertisements to traverse path-selection pinch points without any path hiding at RRs or ASBRs. And Route Target extended community transport-target:0:200 lets the route resolve over Bronze tunnels in the network, similar to the process being described for the Gold SLA path.
ブロンズ面では、ブロンズSLAからエンドポイントPE11を備えたBGP CTルートは、RDプレフィックス192.0.2.2.11:192.0.2.11と適切なラベルを含むNLRIを備えたPE11から発信されます。ゴールドとブロンズのために異なるRDSを使用すると、RRSやASBRに隠れていない状態で、金とブロンズの両方の広告がパス選択ピンチポイントを横断することができます。拡張されたコミュニティトランスポートターゲットを拡張するルート：0：200は、ゴールドSLAパスの記述されているプロセスと同様に、ネットワーク内のブロンズトンネル上でルートを解決します。
Moving back to the Gold plane, ASBR21 receives the Gold SLA BGP CT routes for NLRI RD prefix 192.0.2.11:100:192.0.2.11 over the single-hop EBGP sessions from ASBR13 and ASBR14 and can compute ECMP/FRR towards them. ASBR21 readvertises the BGP CT route for 192.0.2.11:100:192.0.2.11 with a next hop set to itself (loopback address 192.0.2.21) to RR27, advertising a new label: B-L3. An MPLS swap route is installed for label B-L3 at ASBR21 to swap to received labels B-L1 and B-L2 and forward to ASBR13 and ASBR14 respectively; this is an ECMP route. RR27 readvertises this BGP CT route to ABR23 and ABR24 with the label and next hop unchanged.
ASBR21は、ゴールドプレーンに戻ると、ASBR13およびASBR14からのシングルホップEBGPセッションでNLRI RDプレフィックスの金SLA BGP CTルートを受け取り、ECMP/FRRをそれらに向けて計算できます。ASBR21は、192.0.2.11:100:192.0.2.11のBGP CTルートを読み取ります。MPLSスワップルートは、ASBR21のラベルB-L3用にインストールされ、B-L1およびB-L2を受け取り、ASBR13とASBR14にそれぞれ転送します。これはECMPルートです。RR27は、このBGP CTルートをABR23およびABR24へのラベルと次のホップを変更せずに読み取ります。
Similarly, ASBR22 receives BGP CT route 192.0.2.11:100:192.0.2.11 over the single-hop EBGP sessions from ASBR13 and ASBR14, and it readvertises with the next hop set to itself (loopback address 192.0.2.22) to RR27, advertising a new label: B-L4. An MPLS swap route is installed for label B-L4 at ASBR22 to swap to received labels B-L1 and B-L2 and forward to ASBR13 and ASBR14, respectively. RR27 also readvertises this BGP CT route to ABR23 and ABR24 with the label and next hop unchanged.
同様に、ASBR22はBGP CTルート192.0.2.11:100:100:192.0.2.11を受け取り、ASBR13およびASBR14からのシングルホップEBGPセッションを受け取り、次のホップセット自体で読み取ります（ループバックアドレス192.0.2.222）、RR27へ、新しいラベルを広告します。MPLSスワップルートは、ASBR22のラベルB-L4用にインストールされ、B-L1およびB-L2を受信し、ASBR13とASBR14にそれぞれ転送します。RR27は、ラベルと次のホップを使用して、このBGP CTルートをABR23およびABR24へのこのBGP CTルートを変更しません。
BGP ADD-PATH is enabled for the BGP CT family on the sessions between RR27 and the ASBRs and ABRs such that routes for 192.0.2.11:100:192.0.2.11 with the next hops ASBR21 and ASBR22 are reflected to ABR23 and ABR24 without any path hiding. Thus, ABR23 is given visibility of both available next hops for the Gold SLA.
BGPアドパスは、RR27とASBRSとABRの間のセッションでBGP CTファミリーのために有効になり、次のホップASBR21およびASBR22で192.0.2.11:100:192.0.2.11のルートは、パスを隠すことなくABR23およびABR24に反映されます。したがって、ABR23には、ゴールドSLAの利用可能な次のホップの両方の可視性が与えられます。
ABR23 receives the route with next hop 192.0.2.21 and label B-L3 from RR27. The transport-target:0:100 on this route acts as the Mapping Community and instructs ABR23 to strictly resolve the next hop using routes in TC 100 TRDB only. ABR23 is unable to find a route for 192.0.2.21 in the TC 100 TRDB. Thus, it considers this route unusable and does not propagate it further. This prunes ASBR21 from the Gold SLA tunneled path.
ABR23は、RR27から次のホップ192.0.2.21とラベルB-L3でルートを受け取ります。このルートのトランスポートターゲット：0：100は、マッピングコミュニティとして機能し、ABR23にTC 100 TRDBのみのルートを使用して次のホップを厳密に解決するよう指示します。ABR23は、TC 100 TRDBで192.0.2.21のルートを見つけることができません。したがって、このルートは使用できないと考えており、さらに伝播しません。これは、金SLAトンネルパスからのASBR21をプルーンします。
ABR23 also receives the route with next hop 192.0.2.22 and label B-L4 from RR27. The transport-target:0:100 on this route acts as the Mapping Community and instructs ABR23 to strictly resolve the next hop using routes in TC 100 TRDB only. ABR23 successfully resolves the next hop to point to ABR23_to_ASBR22_gold tunnel. ABR23 readvertises this BGP CT route with the next hop set to itself (loopback address 192.0.2.23) and a new label B-L5 to PE25. A swap route for B-L5 is installed by ABR23 to swap to label B-L4 and forward into ABR23_to_ASBR22_gold tunnel.
ABR23は、RR27から次のホップ192.0.2.22とラベルB-L4でルートを受け取ります。このルートのトランスポートターゲット：0：100は、マッピングコミュニティとして機能し、ABR23にTC 100 TRDBのみのルートを使用して次のホップを厳密に解決するよう指示します。ABR23は次のホップを解決してABR23_TO_ASBR22_GOLDトンネルを指します。ABR23は、次のホップセット自体（ループバックアドレス192.0.2.23）と新しいラベルB-L5からPE25を使用して、このBGP CTルートを読み取ります。B-L5のスワップルートはABR23によってインストールされ、B-L4をラベル付けし、ABR23_TO_ASBR22_GOLD TUNNELに転向させます。
PE25 receives the BGP CT route for prefix 192.0.2.11:100:192.0.2.11 with label B-L5, next hop 192.0.2.23, and transport-target:0:100 from RR26. It similarly resolves the next hop 192.0.2.23 over transport class 100, pushing labels associated with PE25_to_ABR23_gold tunnel.
PE25は、ラベルB-L5、次のホップ192.0.2.23、および輸送標識：RR26からのプレフィックス192.0.2.11:100:100:192.0.2.11のBGP CTルートを受け取ります。同様に、PE25_TO_ABR23_GOLD TUNNELに関連するラベルをプッシュして、輸送クラス100で次のホップ192.0.2.23を解決します。
In this manner, the Gold transport LSP "ASBR13_to_PE11_gold" in the egress domain is extended by BGP CT until the ingress node PE25 in the ingress domain, to create an end-to-end Gold SLA path. MPLS swap routes are installed at ASBR13, ASBR22, and ABR23, when propagating the PE11 BGP CT Gold Transport Class route 192.0.2.11:100:192.0.2.11 with next hop set to itself towards PE25.
このように、出力ドメインの金輸送LSP「ASBR13_TO_PE11_GOLD」は、イングレスドメインのイングレスノードPE25までBGP CTによって拡張され、エンドツーエンドのゴールドSLAパスが作成されます。MPLSスワップルートは、ASBR13、ASBR22、およびABR23に設置されます。これは、PE11 BGP CT Gold Transport Classルート192.0.2.100:192.0.2.11を伝播すると、次のホップがPE25に向かって設定されています。
Thus formed, the BGP CT LSP originates in PE25 and terminates in ASBR13 (assuming PE11 advertised Implicit NULL), traversing over the Gold underlay LSPs in each domain. ASBR13 uses UHP to stitch the BGP CT LSP into the "ASBR13_to_PE11_gold" LSP to traverse the last domain, thus satisfying Gold SLA end-to-end.
このように形成されると、BGP CT LSPはPE25に由来し、ASBR13で終了し（PE11が暗黙のヌルを宣伝すると仮定）、各ドメインの金の下層LSPを横切って横断します。ASBR13はUHPを使用して、BGP CT LSPを「ASBR13_TO_PE11_GOLD」LSPにステッチして最後のドメインをトラバースし、ゴールドSLAエンドツーエンドを満たします。
When PE25 receives service routes from RR26 with next hop 192.0.2.11 and Mapping Community color:0:100, it resolves over this BGP CT route 192.0.2.11:100:192.0.2.11. Thus, pushing label B-L5 and pushing as the top label the labels associated with PE25_to_ABR23_gold tunnel.
PE25が次のホップ192.0.2.11でRR26からサービスルートを受け取り、コミュニティの色をマッピングすると、このBGP CTルート192.0.2.11:100:192.0.2.11で解決します。したがって、ラベルB-L5をプッシュし、PE25_TO_ABR23_GOLD TUNNELに関連するラベルをトップレーベルとして押します。
This section describes how the data plane looks in steady state.
このセクションでは、データプレーンが定常状態でどのように見えるかについて説明します。
CE41 transmits an IP packet with the destination 203.0.113.31. On receiving this packet, PE25 performs a lookup in the IP FIB associated with the CE41 interface. This lookup yields the service route that pushes the VPN service label V-L1, BGP CT label B-L5, and labels for PE25_to_ABR23_gold tunnel. Thus, PE25 encapsulates the IP packet in an MPLS packet with labels V-L1 (innermost), B-L5, and top label PE25_to_ABR23_gold tunnel. This MPLS packet is thus transmitted to ABR23 using the Gold SLA.
CE41は、宛先203.0.113.31にIPパケットを送信します。このパケットを受信すると、PE25はCE41インターフェイスに関連付けられたIP FIBのルックアップを実行します。このルックアップは、VPNサービスラベルV-L1、BGP CTラベルB-L5、およびPE25_TO_ABR23_GOLDトンネルのラベルをプッシュするサービスルートを生成します。したがって、PE25は、ラベルV-L1（最も内側）、B-L5、およびトップラベルPE25_TO_ABR23_GOLDトンネルを備えたMPLSパケットにIPパケットをカプセル化します。したがって、このMPLSパケットは、ゴールドSLAを使用してABR23に送信されます。
ABR23 decapsulates the packet received on PE25_to_ABR23_gold tunnel as required and finds the MPLS packet with label B-L5. It performs a lookup for label B-L5 in the global MPLS FIB. This yields the route that swaps label B-L5 with label B-L4 and pushes the top label provided by ABR23_to_ASBR22_gold tunnel. Thus, ABR23 transmits the MPLS packet with label B-L4 to ASBR22 on a tunnel that satisfies the Gold SLA.
ABR23は、必要に応じてPE25_TO_ABR23_GOLD TUNNELで受信したパケットを脱カプセル化し、ラベルB-L5のMPLSパケットを見つけます。グローバルMPLS FIBでラベルB-L5の検索を実行します。これにより、ラベルB-L5をラベルB-L4と交換し、ABR23_TO_ASBR22_GOLD TUNNELが提供するトップレーベルをプッシュするルートが生成されます。したがって、ABR23は、Gold SLAを満たすトンネルで、MPLSパケットをラベルB-L4とASBR22に送信します。
ASBR22 similarly performs a lookup for label B-L4 in the global MPLS FIB, finds the route that swaps label B-L4 with label B-L2, and forwards it to ASBR13 over the directly connected MPLS-enabled interface. This interface is a common resource not dedicated to any specific Transport Class, in this example.
ASBR22も同様に、グローバルMPLS FIBでラベルB-L4のルックアップを実行し、ラベルB-L4をラベルB-L2と交換するルートを見つけ、直接接続されたMPLS対応インターフェイス上でASBR13に転送します。このインターフェイスは、この例では、特定の輸送クラスに専念していない一般的なリソースです。
ASBR13 receives the MPLS packet with label B-L2 and performs a lookup in the MPLS FIB, finds the route that pops label B-L2, and pushes labels associated with ASBR13_to_PE11_gold tunnel. This transmits the MPLS packet with VPN label V-L1 to PE11 using a tunnel that preserves the Gold SLA in AS 1.
ASBR13は、ラベルB-L2を使用してMPLSパケットを受信し、MPLS FIBのルックアップを実行し、ラベルB-L2をポップするルートを見つけ、ASBR13_TO_PE11_GOLDトンネルに関連するラベルをプッシュします。これにより、MPLSパケットはVPNラベルV-L1を使用してPE11に送信され、ゴールドSLAをAS 1で保存します。
PE11 receives the MPLS packet with V-L1 and performs VPN forwarding, thus transmitting the original IP payload from CE41 to CE31. The payload has traversed path satisfying the Gold SLA end-to-end.
PE11は、V-L1でMPLSパケットを受信し、VPN転送を実行するため、CE41からCE31に元のIPペイロードを送信します。ペイロードは、ゴールドSLAエンドツーエンドを満たすパスを横断しています。
This section describes how the data plane at ASBR22 reacts when the link between ASBR22 and ASBR13 experiences a failure and an alternate path exists.
このセクションでは、ASBR22とASBR13のリンクが障害を経験し、代替パスが存在する場合、ASBR22のデータプレーンがどのように反応するかについて説明します。
Assuming the ASBR22_to_ASBR13 link goes down, traffic with a Gold SLA going to PE11 will need repair. ASBR22 has an alternate BGP CT route for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been preprogrammed in forwarding by ASBR22 as an FRR backup next hop for label B-L4. This allows the Gold SLA traffic to be locally repaired at ASBR22 without the failure event propagated in the BGP CT network. In this case, ingress node PE25 will not know there was a failure, and traffic restoration will be independent of prefix scale (PIC).
ASBR22_TO_ASBR13リンクがダウンすると仮定すると、Gold SLAがPE11に行くと交通が修理が必要です。ASBR22には、ASBR14から192.0.2.11:100:192.0.2.11の代替BGP CTルートがあります。これは、ASBR22によるFRRバックアップの次のLabel B-L4のホップとして転送で事前にプログラムされています。これにより、故障イベントがBGP CTネットワークに伝播することなく、ASBR22でゴールドSLAトラフィックをローカルに修理できます。この場合、イングレスノードPE25は障害があることを知りません。トラフィックの復元は、プレフィックススケール（PIC）とは無関係になります。
This section describes how the data plane reacts when a Gold path experiences a failure but no alternate path exists.
このセクションでは、ゴールドパスが障害を経験したが代替パスが存在しないときにデータプレーンがどのように反応するかについて説明します。
Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no end-to-end Gold path exists in the network. This makes the BGP CT route for RD prefix 192.0.2.11:100:192.0.2.11 unusable at ABR23. This makes ABR23 send a BGP withdrawal for 192.0.2.11:100:192.0.2.11 to PE25.
トンネルABR23_TO_ASBR22_GOLDがダウンしていると仮定して、ネットワークにエンドツーエンドのゴールドパスが存在しないようにします。これにより、RDプレフィックスのBGP CTルート192.0.2.11:100:192.0.2.11がABR23で使用できなくなります。これにより、ABR23は192.0.2.11:100:192.0.2.11のBGP撤退をPE25に送信します。
The withdrawal for 192.0.2.11:100:192.0.2.11 allows PE25 to react to the loss of the Gold path to 192.0.2.11. Assuming PE25 is provisioned to use a Best-Effort Transport Class as the backup path, this withdrawal of a BGP CT route allows PE25 to adjust the next hop of the VPN service route to push the labels provided by the BGP LU route. That repairs the traffic to go via the best-effort path. PE25 can also be provisioned to use the Bronze Transport Class as the backup path. The repair will happen in similar manner in that case as well.
192.0.2.11:100:192.0.2.11の撤退により、PE25は192.0.2.11への金の経路の損失に反応することができます。PE25がバックアップパスとして最適な輸送クラスを使用するようにプロビジョニングされていると仮定すると、このBGP CTルートのこの撤回により、PE25はVPNサービスルートの次のホップを調整して、BGP LUルートによって提供されるラベルをプッシュできます。それは、最高のエフォルトパスを介して通るトラフィックを修理します。PE25は、ブロンズトランスポートクラスをバックアップパスとして使用するようにプロビジョニングすることもできます。その場合、修理も同様の方法で発生します。
Traffic repair to absorb the failure happens at ingress node PE25 in a service prefix scale independent manner (PIC). The repair time will be proportional to time taken for withdrawing the BGP CT route.
障害を吸収するための交通修理は、イングレスノードPE25でサービスプレフィックススケール独立した方法（PIC）で発生します。修理時間は、BGP CTルートを引き出すためにかかる時間に比例します。
These examples demonstrate the various levels of fail-safe mechanisms available to protect traffic in a BGP CT network.
これらの例は、BGP CTネットワークのトラフィックを保護するために利用可能なさまざまなレベルのフェイルセーフメカニズムを示しています。
[RFC8212] suggests BGP speakers require explicit configuration of both BGP Import and Export Policies in order to receive or send routes over EBGP sessions.
[RFC8212]は、BGPスピーカーがEBGPセッションを介してルートを受信または送信するために、BGPインポートおよびエクスポートポリシーの両方の明示的な構成を必要とすることを示唆しています。
It is recommended to follow this for BGP CT routes. It will prohibit unintended advertisement of transport routes throughout the BGP CT transport domain, which may span across multiple AS domains. This will conserve usage resources for MPLS labels and next hops in the network. An ASBR of a domain can be provisioned to allow routes with only the Transport Class RTs that are required by SNs in the domain.
BGP CTルートの場合、これに従うことをお勧めします。BGP CTトランスポートドメイン全体の意図しない輸送ルートの広告を禁止します。これにより、MPLSラベルの使用リソースとネットワーク内の次のホップが節約されます。ドメインのASBRは、ドメイン内のSNSが必要とするトランスポートクラスRTのみを備えたルートを許可するようにプロビジョニングできます。
This section describes how the number of Protocol Next Hops (PNHs) advertised to an SN or BN can be constrained using BGP Classful Transport and RTC (see [RFC4684].
このセクションでは、SNまたはBNに宣伝されているプロトコルの次のホップ（PNHS）の数を、BGPクラスフルトランスポートとRTCを使用して制約する方法について説明します（[RFC4684]を参照してください。
An egress SN MAY advertise a BGP CT route for RD:eSN with two Route Targets: transport-target:0:<TC> and an RT carrying <eSN>:<TC>, where TC is the Transport Class identifier and eSN is the IP address used by the SN as BGP next hop in its service route advertisements.
出口SNは、RD：ESNのBGP CTルートを宣伝する場合があります。2つのルートターゲットを備えたESN：輸送標的：0：<TC>とRT <ESN>：<TC>を運ぶことができます。ここで、TCは輸送クラス識別子であり、ESNはSNがSNがBGP次のホップで使用するIPアドレスです。
Note that such use of the IP-address-specific route target <eSN>:<TC> is optional in a BGP CT network. It is required only if there is a requirement to prune the propagation of the transport route for an egress node eSN to only the set of ingress nodes that need it. When only the RT of transport-target:0:<TC> is used, the pruning happens in granularity of Transport Class ID (Color), not BGP next hop; a BGP CT route will only be advertised into a domain with at least one PE that imports its Transport Class.
IPアドレス固有のルートターゲット<ESN>：<TC>のこのような使用は、BGP CTネットワークでオプションであることに注意してください。出口ノードESNの輸送ルートの伝播を、それを必要とするイングレスノードのセットのみにプルネートする必要がある場合にのみ必要です。トランスポートターゲットのRTのみが使用される場合、剪定はBGP Next Hopではなく、輸送クラスID（色）の粒度で発生します。BGP CTルートは、輸送クラスをインポートする少なくとも1つのPEを持つドメインにのみ宣伝されます。
The transport-target:0:<TC> is the new type of route target (Transport Class RT) defined in this document. It is carried in the BGP extended community attribute (attribute code 16).
トランスポートターゲット：0：<TC>は、このドキュメントで定義されている新しいタイプのルートターゲット（トランスポートクラスRT）です。これは、BGP拡張コミュニティ属性（属性コード16）で運ばれます。
The RT carrying <eSN>:<TC> MAY be an IP-address-specific regular RT (attribute code 16), or IPv6-address specific RT (attribute code 25). It should be noted that the Local Administrator field of these RTs can only carry two octets of information; thus, the <TC> field in this approach is limited to a 2-octet value. Future protocol extension work is needed to define a BGP CCA that can accommodate an IPv4/IPv6 address along with a 4-octet Local Administrator field.
<ESN>：<TC>を伝えるRTは、IPアドレス固有の通常のRT（属性コード16）、またはIPv6-Address固有のRT（属性コード25）である場合があります。これらのRTのローカル管理者フィールドは、2オクテットの情報しか持ち運ぶことができないことに注意する必要があります。したがって、このアプローチの<TC>フィールドは2オクテット値に制限されます。4-OCTETローカル管理者フィールドとともに、IPv4/IPv6アドレスに対応できるBGP CCAを定義するには、将来のプロトコル拡張作業が必要です。
An ingress SN MAY import BGP CT routes with a Route Target carrying <eSN>:<TC>. The ingress SN may learn the eSN values by configuration or it may discover them from the BGP next hop field in the BGP VPN service routes received from the eSN. A BGP ingress SN receiving a BGP service route with a next hop of eSN generates an RTC route for Route Target prefix <Origin ASN>:<eSN>/[80|176] in order to learn BGP CT transport routes to reach eSN. This allows constrained distribution of the transport routes to the PNHs actually required by iSN.
イングレスSNは、<ESN>：<TC>を運ぶルートターゲットでBGP CTルートをインポートする場合があります。Ingress SNは、構成によってESN値を学習するか、ESNから受信したBGP VPNサービスルートのBGP Next Hopフィールドからそれらを発見する場合があります。次のESNの次のホップでBGPサービスルートを受信するBGPイングレスSNは、BGP CT輸送ルートをESNに到達するために、ルートターゲットのプレフィックス<Origin ASN>：<ESN>/[80 | 176]のRTCルートを生成します。これにより、実際にISNが必要とするPNHSへの輸送ルートの制約のある分布が可能になります。
When RTC is in use, as described here, BGP CT routes will be constrained to follow the same path of propagation as the RTC routes. Therefore, a BN would learn the RTC routes advertised by ingress SNs and propagate further. This will allow constraining distribution of BGP CT routes for a PNH to only the necessary BNs in the network, closer to the egress SN.
ここで説明するように、RTCが使用されている場合、BGP CTルートはRTCルートと同じ伝播パスに従うように制約されます。したがって、BNは、SNSのイングレスによって宣伝されているRTCルートを学習し、さらに伝播します。これにより、PNHのBGP CTルートの分布を、ネットワーク内の必要なBNのみに、出口SNに近いものに制限することができます。
When the path of route propagation of BGP CT routes is the same as the RTC routes, a BN would learn the RTC routes advertised by ingress SNs and propagate further. This will allow constraining distribution of BGP CT routes for a PNH to only the necessary BNs in the network, closer to the egress SN.
BGP CTルートのルート伝播の経路がRTCルートと同じ場合、BNはIngress SNSによって宣伝されているRTCルートを学習し、さらに伝播します。これにより、PNHのBGP CTルートの分布を、ネットワーク内の必要なBNのみに、出口SNに近いものに制限することができます。
This mechanism provides "On-Demand Next Hop" of BGP CT routes, which helps with the scaling of MPLS forwarding state at the SN and BN.
このメカニズムは、BGP CTルートの「オンデマンド次のホップ」を提供します。これは、SNおよびBNでのMPLS転送状態のスケーリングに役立ちます。
However, the amount of state carried in RTC family may become proportional to the number of PNHs in the network. To strike a balance, the RTC route advertisements for <Origin ASN>:<eSN>/[80|176] MAY be confined to the BNs in the home region of an ingress SN, or the BNs of a super core.
ただし、RTCファミリーで運ばれる州の量は、ネットワーク内のPNHの数に比例する可能性があります。バランスをとるために、<OriginAsn>：<ESN>/[80 | 176]のRTCルート広告は、侵入SNの故郷のBNSまたはスーパーコアのBNSに限定される場合があります。
Such a BN in the core of the network imports BGP CT routes with Transport-Target:0:<TC> and generates an RTC route for <Origin ASN>:0:<TC>/96, while not propagating the more specific RTC requests for specific PNHs. This lets the BN learn transport routes to all eSN nodes but confines their propagation to ingress SNs.
ネットワークのコアにあるこのようなBNは、輸送標的：0：<TC>でBGP CTルートをインポートし、<Origin ASN>：0：<TC>/96のRTCルートを生成しますが、特定のPNHSのより特定のRTC要求を伝播しません。これにより、BNはすべてのESNノードへの輸送ルートを学習できますが、SNSを侵入するための伝播を限定します。
It may be even more desirable to limit the number of PNHs that are globally visible in the network. This is possible using the mechanism described in Appendix D.
ネットワークでグローバルに見えるPNHの数を制限することがさらに望ましい場合があります。これは、付録Dで説明したメカニズムを使用して可能です。
Such that advertisement of PE loopback addresses as next hop in BGP service routes is confined to the region they belong to. An anycast IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts the SNs in a region from other regions in the network.
BGPサービスルートの次のホップとしてのPEループバックアドレスの広告は、属する地域に限定されます。「Context Protocol Nexthopアドレス」（CPNH）と呼ばれるAnycast IPアドレスは、ネットワーク内の他の地域の領域のSNSを抽象化します。
This provides much greater advantage in terms of scaling, convergence and security. Changes to implement this feature are required only on the local region's BNs and RRs, so legacy PE devices can also benefit from this approach.
これは、スケーリング、収束、セキュリティの点ではるかに大きな利点を提供します。この機能を実装するための変更は、ローカル地域のBNSおよびRRSでのみ必要であるため、レガシーPEデバイスもこのアプローチの恩恵を受けることができます。
MPLS Operations, Administration, and Maintenance (OAM) procedures specified in [RFC8029] also apply to BGP CT.
[RFC8029]で指定されたMPLS運用、管理、およびメンテナンス（OAM）手順もBGP CTに適用されます。
The Target FEC Stack sub-TLV for IPv4 BGP CT has a Sub-Type of 31744 and a length of 13. The Value field consists of the RD advertised with the BGP CT prefix, the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and a prefix length encoded as shown in Figure 4.
IPv4 BGP CTのターゲットFECスタックSub-TLVのサブタイプは31744、長さは13です。値フィールドは、BGP CTプレフィックス、IPv4プレフィックス（Trailing 0ビットを使用して32ビットをすべて作成する）で宣伝されたRDで構成され、図4に示すようにエンコードされたプレフィックスの長さで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BGP CT IPv4 FEC
図4：BGP CT IPv4 FEC
The Target FEC Stack sub-TLV for IPv6 BGP CT has a Sub-Type of 31745 and a length of 25. The Value field consists of the RD advertised with the BGP CT prefix, the IPv6 prefix (with trailing 0 bits to make 128 bits in all) and a prefix length encoded as shown in Figure 5.
IPv6 BGP CTのターゲットFECスタックSub-TLVのサブタイプは31745と25の長さです。値フィールドは、BGP CTプレフィックスで宣伝されたRD、IPv6プレフィックス（Trailing 0ビットで128ビットをすべて作成します）、および図5に示すようにエンコードされたプレフィックスの長さで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: BGP CT IPv6 FEC
図5：BGP CT IPv6 FEC
These prefix layouts are inherited from Sections 3.2.5 and 3.2.6 of [RFC8029].
これらのプレフィックスレイアウトは、[RFC8029]のセクション3.2.5および3.2.6から継承されます。
RDs aid in troubleshooting provider networks that deploy BGP CT, by uniquely identifying the originator of a route across an administrative domain that may either span multiple domains within a provider network or span closely coordinated provider networks.
RDSは、プロバイダーネットワーク内の複数のドメインにまたがるか、密接に調整されたプロバイダーネットワークにまたがる可能性のある管理ドメインを横切るルートのオリジネーターを一意に識別することにより、BGP CTを展開するトラブルシューティングプロバイダーネットワークを支援します。
The use of RDs also provides an option for signaling forwarding diversity within the same Transport Class. An SN can advertise an EP with the same Transport Class in multiple BGP CT routes with unique RDs.
RDSの使用は、同じ輸送クラス内の転送の多様性を信号するオプションも提供します。SNは、一意のRDSを備えた複数のBGP CTルートで同じトランスポートクラスを持つEPを宣伝できます。
For example, unique "RDx:EP1" prefixes can be advertised by an SN for an EP1 to different upstream BNs with unique forwarding-specific encapsulation (e.g., a Label) in order to collect traffic statistics at the SN for each BN. In the absence of an RD, duplicated Transport Class / Color values will be needed in the transport network to achieve such use cases.
たとえば、一意の「RDX：EP1」プレフィックスは、各BNのSNでトラフィック統計を収集するために、ユニークな転送固有のカプセル化（ラベルなど）を備えた異なる上流BNSのEP1のSNによって宣伝できます。RDがない場合、そのようなユースケースを達成するために、トランスポートネットワークで複製された輸送クラス /色の値が必要になります。
The allocation of RDs is done at the point of origin of the BGP CT route. This can be either an egress SN or a BN. The default RD allocation mode is to use a unique RD per originating node for an EP. This mode allows for the ingress to uniquely identify each originated path. Alternatively, the same RD may be provisioned for multiple originators of the same EP. This mode can be used when the ingress does not require full visibility of all nodes originating an EP.
RDSの割り当ては、BGP CTルートの原点で行われます。これは、出口SNまたはBNのいずれかです。デフォルトのRD割り当てモードは、EPの発信ノードごとに一意のRDを使用することです。このモードにより、イングレスは各起源のパスを一意に識別できます。あるいは、同じEPの複数のオリジネーターに同じRDがプロビジョニングされる場合があります。このモードは、侵入がEPを発信するすべてのノードの完全な可視性を必要としない場合に使用できます。
A label is allocated for a BGP CT route when it is advertised with the next hop set to itself by an SN or a BN. An implementation may use different label-allocation modes with BGP CT. Per-prefix is the recommended label-allocation mode as it provides better traffic convergence properties than a per-NH label-allocation mode. Furthermore, BGP CT offers two flavors for per-prefix label allocation:
BGP CTルートは、SNまたはBNによって次のホップセットで宣伝されると、BGP CTルートに割り当てられます。実装では、BGP CTを備えた異なるラベルアロケーションモードを使用する場合があります。PER-PREFIXは、NHパン配分モードよりも優れたトラフィック収束プロパティを提供するため、推奨されるラベルアロケーションモードです。さらに、BGP CTは、PREFIXごとのラベル割り当てに2つのフレーバーを提供します。
* The first flavor assigns a label for each unique "RD, EP".
* 最初のフレーバーは、それぞれのユニークな「RD、EP」にラベルを割り当てます。
* The second flavor assigns a label for each unique "Transport Class, EP" while ignoring the RD.
* 2番目のフレーバーは、RDを無視しながら、ユニークな「トランスポートクラス、EP」ごとにラベルを割り当てます。
In a BGP CT network, the number of routes at an ingress PE is a function of unique EPs multiplied by BNs in the ingress domain that have the next hop set to themselves. BGP CT provides flexible RD and label-allocation modes to address operational requirements in a multi-domain network. The impacts on the control plane and forwarding behavior for these modes are detailed with an example in Section 10.3.
BGP CTネットワークでは、Ingress PEのルート数は、次のホップセットを備えたイングレスドメインのBNSを掛けた一意のEPSの関数です。BGP CTは、マルチドメインネットワークの運用要件に対処するための柔軟なRDおよびラベルアロケーションモードを提供します。これらのモードのコントロールプレーンと転送動作への影響については、セクション10.3の例で詳しく説明します。
This section details the usage of BGP CT RD and label-allocation modes to calibrate the level of path visibility and the amount of route and label scale in a multi-domain network.
このセクションでは、BGP CT RDとラベルアロケーションモードの使用について、パスの可視性のレベルとマルチドメインネットワークのルートとラベルスケールの量を調整します。
Consider a multi-domain BGP CT network as illustrated in the following Figure 6:
次の図6に示すように、マルチドメインBGP CTネットワークを検討してください。
...................... .............................
: AS3 : : AS1 :
: : : :
: +----------ASBR11 +--PE11 (EP1) :
: | : : \ / :
: +----ASBR31 : : [P]----PE12 (EP2) :
: | | : : / | \ :
: | +----------ASBR12 | +--PE13 (EP3) :
: | : : | :
: | : : +-----PE14 (EP4) :
: PE31--[P] : : :
: | : : :
: | : : :
: | +----------ASBR21 +--PE21 (EP5) :
: | | : : \ / :
: +----ASBR32 : : [P]----PE22 (EP6) :
: | : : / | \ :
: +----------ASBR22 | +--PE22 (EP7) :
: : : | :
: : : +-----PE24 (EP8) :
...................... .............................
----------- Traffic Direction -------->
Figure 6: Managing Transport-Route Visibility in Multi-Domain Networks
図6：マルチドメインネットワークにおける輸送ルートの可視性の管理
The following table provides a comparison of the BGP CT route and label scale for varying endpoint-path visibility at ingress node PE31 for each TC. It analyzes scenarios where Unicast or Anycast EPs (EP-type) may be originated by different node roles (Origin), using different RD allocation modes (RD-Modes), and different Per-Prefix label-allocation modes (PP-Modes).
次の表は、各TCのイングレスノードPE31でのさまざまなエンドポイントパスの可視性のためのBGP CTルートとラベルスケールの比較を示します。ユニキャストまたはAnycast EPS（EPタイプ）が、異なるRDアロケーションモード（RDモード）を使用して異なるノードロール（Origin）から発信されるシナリオを分析し、異なるPrefixラベルアロケーションモード（PPモード）を使用します。
+--------+------+-------+-------+---------+---------+
|EP-type |Origin|RD-Mode|PP-Mode|CT Routes|CT Labels|
+--------+------+-------+-------+---------+---------+
|Unicast |SN |Unique |TC,EP | 8 | 8 |
|Unicast |SN |Unique |RD,EP | 8 | 8 |
|Unicast |BN |Unique |TC,EP | 16 | 8 |
|Unicast |BN |Unique |RD,EP | 16 | 16 |
|--------|------|-------|-------|---------|---------|
|Anycast |SN |Unique |TC,EP | 8 | 2 |
|Anycast |SN |Unique |RD,EP | 8 | 8 |
|Anycast |SN |Same |TC,EP | 2 | 2 |
|Anycast |SN |Same |RD,EP | 2 | 2 |
|Anycast |BN |Unique |TC,EP | 4 | 2 |
|Anycast |BN |Unique |RD,EP | 4 | 4 |
|Anycast |BN |Same |TC,EP | 2 | 2 |
|Anycast |BN |Same |RD,EP | 2 | 2 |
+--------+------+-------+-------+---------+---------+
Figure 7: Route and Path Visibility at Ingress Node
図7：Ingressノードのルートとパスの可視性
In Figure 7, route scale at ingress node PE31 is proportional to path diversity in the ingress domain (number of ASBRs) and point of origination of the BGP CT route. TE granularity at ingress node PE31 is proportional to the number of unique CT labels received, which depends on the PP-Mode and the path diversity in the ingress domain.
図7では、イングレスノードPE31のルートスケールは、イングレスドメイン（ASBRの数）の経路多様性とBGP CTルートの出発点に比例します。IngressノードPE31のTE粒度は、PPモードとIngressドメインのパス多様性に依存する一意のCTラベルの数に比例します。
Deploying unique RDs is strongly RECOMMENDED because it helps in troubleshooting by uniquely identifying the originator of a route and avoids path hiding.
一意のRDSを展開することは、ルートのオリジネーターを一意に識別し、パスの隠れを避けることでトラブルシューティングに役立つため、強くお勧めします。
In typical deployments, originating BGP CT routes at the egress node (SN) is recommended. In this model, using either an "RD, EP" or "TC, EP" Per-Prefix label-allocation mode repairs traffic locally at the nearest BN for any failures in the network because the label value does not change.
典型的な展開では、出口ノード（SN）でのBGP CTルートの発生をお勧めします。このモデルでは、「RD、EP」または「TC、EP」のいずれかを使用して、ラベル値が変わらないため、ネットワーク内の障害について、最寄りのBNでローカルにトラフィックを修理します。
Originating at BNs with unique RDs induces more routes than when originating at egress SNs. In this model, use of the "TC, EP" Per-Prefix label-allocation mode repairs traffic locally at the nearest BN for any failures in the network because the label value does not change.
一意のRDSでBNSで発生すると、出口SNSで発生する場合よりも多くのルートが誘導されます。このモデルでは、ラベル値が変わらないため、ネットワーク内の障害について、「TC、EP」ラベルアロケーションモードの使用をネットワーク内の障害に対してローカルで修理します。
Figure 7 demonstrates that BGP CT allows an operator to control how much path visibility and forwarding diversity is desired in the network for both Unicast and Anycast endpoints.
図7は、BGP CTにより、オペレーターがユニキャストエンドポイントとAnycastエンドポイントの両方に対して、ネットワークでどの程度のパスの可視性と転送の多様性が望まれるかを制御できることを示しています。
Cooperating inter-AS option C domains may sometimes not agree on RT, RD, Mapping Community, or Transport Class RT values because of differences in community namespaces (e.g., during network mergers or renumbering for expansion). Such deployments may deploy mechanisms to map and rewrite the Route Target values on domain boundaries using per-ASBR import policies. This is no different than any other BGP VPN family. Mechanisms used in inter-AS VPN deployments may be leveraged with the BGP CT family also.
AS Inter-AS Option Cドメインの協力は、コミュニティ名空間の違いのためにRT、RD、マッピングコミュニティ、または輸送クラスのRT値に同意しない場合があります（たとえば、ネットワーク合併中や拡張のための非難）。このような展開は、ASBRポリシーを使用して、ドメイン境界上のルートターゲット値をマッピングおよび書き換えるメカニズムを展開する場合があります。これは、他のBGP VPNファミリーと違いはありません。VPN展開間で使用されるメカニズムは、BGP CTファミリーとも活用される場合があります。
A Resolution Scheme allows association with multiple Mapping Communities. This minimizes service disruption during renumbering, network merger, or transition scenarios.
解決スキームにより、複数のマッピングコミュニティとの関連が可能になります。これにより、変更、ネットワークの合併、または移行シナリオ中のサービスの中断が最小限に抑えられます。
The Transport Class RT is useful to avoid collision with regular Route Target namespace used by service routes.
トランスポートクラスRTは、サービスルートで使用される通常のルートターゲットネームスペースとの衝突を避けるのに役立ちます。
Section 8 shows multiple domains that agree on a color namespace (Agreeing Color Domains) and contain tunnels with an equivalent set of colors (Homogenous Color Domains).
セクション8では、カラーネームスペース（カラードメインに同意する）に同意し、同等の色のセット（同種カラードメイン）のトンネルを含む複数のドメインを示しています。
However, in the real world, this may not always be guaranteed. Two domains may independently manage their color namespaces; these are known as Non-Agreeing Color Domains. Two domains may have tunnels with unequal sets of colors; these are known as Heterogeneous Color Domains.
ただし、現実の世界では、これが常に保証されるとは限りません。2つのドメインが独立してカラーネームスペースを管理できます。これらは、非積極的なカラードメインとして知られています。2つのドメインには、等しい色のセットがあるトンネルがあります。これらは不均一なカラードメインとして知られています。
This section describes how BGP CT is deployed in such scenarios to preserve end-to-end Intent. Examples described in this section use inter-AS option C domains. Similar mechanisms will work for inter-AS option A and inter-AS option B scenarios as well.
このセクションでは、エンドツーエンドの意図を維持するために、このようなシナリオにBGP CTがどのように展開されるかについて説明します。このセクションで説明する例は、Option C Domainsを使用します。同様のメカニズムは、オプションAおよびAS Inter-AsオプションBシナリオでも機能します。
At the service layer, it is recommended that a global color namespace be maintained across multiple cooperating domains. BGP CT allows indirection using Resolution Schemes to be able to maintain a global namespace in the service layer. This is possible even if each domain independently maintains its own local transport color namespace.
サービスレイヤーでは、複数の協力ドメインにわたってグローバルカラーネームスペースを維持することをお勧めします。BGP CTを使用すると、解像度スキームを使用して間接的にサービスレイヤーにグローバルネームスペースを維持できるようになります。これは、各ドメインが独自のローカルトランスポートカラーネームスペースを独立して維持している場合でも可能です。
As explained in Section 5, a Mapping Community carried on a service route maps to a Resolution Scheme. The Mapping Community values for the service route can be abstract and are not required to match the transport color namespace. This abstract Mapping Community value representing a global service layer Intent is mapped to a local transport layer Intent available in each domain.
セクション5で説明したように、マッピングコミュニティは、サービスルートマップで解像度スキームに移行しました。サービスルートのマッピングコミュニティ値は抽象的であり、トランスポートカラーネームスペースを一致させる必要はありません。グローバルサービスレイヤーの意図を表すこの抽象マッピングコミュニティ価値は、各ドメインで利用可能なローカルトランスポートレイヤーの意図にマッピングされます。
In this manner, it is recommended to keep color namespace management at the service layer and the transport layer decoupled from each other. In the following sections, the service layer agrees on a single global namespace.
このようにして、カラーネームスペース管理をサービスレイヤーに維持し、輸送層を互いに切り離すことをお勧めします。次のセクションでは、サービスレイヤーは単一のグローバルネームスペースで一致しています。
Non-Agreeing Color Domains require a Mapping Community rewrite on each domain boundary. This rewrite helps to map one domain's color namespace to another domain's color namespace.
非攻撃カラードメインでは、各ドメイン境界でマッピングコミュニティの書き換えが必要です。この書き換えは、あるドメインの色の名前空間を別のドメインのカラーネームスペースにマッピングするのに役立ちます。
The following example illustrates how traffic is stitched and SLA is preserved when domains don't use the same namespace at the transport layer. Each domain specifies the same SLA using different color values.
次の例は、ドメインが輸送層で同じ名前空間を使用しない場合、トラフィックがどのように縫い付けられ、SLAが保存されるかを示しています。各ドメインは、異なる色の値を使用して同じSLAを指定します。
..................... ....................... .....................
: Gold(100) : : Gold(300) : : Gold(500) :
: : : : : :
: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
: : : : : :
: AS1 : : AS2 : : AS3 :
: : : : : :
: Bronze(200) : : Bronze(400) : : Bronze(600) :
..................... ....................... .....................
----------- Traffic Direction -------->
Figure 8: Transport Layer with Non-agreeing Color Domains
図8：非攻撃カラードメインを備えた輸送層
In the topology shown in Figure 8, we have three Autonomous Systems. All the nodes in the topology support BGP CT.
図8に示すトポロジには、3つの自律システムがあります。トポロジのすべてのノードはBGP CTをサポートしています。
* In AS1, the Gold SLA is represented by color 100 and Bronze by 200.
* AS1では、金SLAはColor 100、Bronze 200で表されます。
* In AS2, the Gold SLA is represented by color 300 and Bronze by 400.
* AS2では、金SLAはColor 300、Bronze 400で表されます。
* In AS3, the Gold SLA is represented by color 500 and Bronze by 600.
* AS3では、金SLAはColor 500、Bronze 600で表されます。
Though the color values are different, they map to tunnels with sufficiently similar TE characteristics in each domain.
色の値は異なりますが、各ドメインで十分に類似したTE特性を持つトンネルにマッピングされます。
The service route carries an abstract Mapping Community that maps to the required SLA. For example, service routes that need to resolve over Gold transport tunnels carry a Mapping Community color:0:100500. In AS3, it maps to a Resolution Scheme containing TRDB with color 500; in AS2, it maps to TRDB with color 300; and in AS1, it maps to TRDB with color 100. Coordination is needed to provision the Resolution Schemes in each domain, as explained previously.
サービスルートには、必要なSLAにマッピングする抽象マッピングコミュニティが搭載されています。たとえば、ゴールドトランスポートトンネルを解決する必要があるサービスルートには、マッピングコミュニティの色があります：0：100500。AS3では、Color 500のTRDBを含む解像度スキームにマップします。AS2では、Color 300でTRDBにマップします。AS1では、Color 100でTRDBにマップします。前述のように、各ドメインの解像度スキームをプロビジョニングするには調整が必要です。
At the AS boundary, the Transport Class RT is rewritten for the BGP CT routes. In the previous topology, at ASBR31, the transport-target:0:500 for Gold tunnels is rewritten to transport-target:0:300 and then advertised to ASBR22. Similarly, the transport-target:0:300 for Gold tunnels are rewritten to transport-target:0:100 at ASBR21 before advertising to ASBR11. At PE11, the transport route received with transport-target:0:100 will be added to the color 100 TRDB. The service route received with Mapping Community color:0:100500 at PE1 maps to the Gold TRDB and resolves over this transport route.
AS境界では、BGP CTルートの輸送クラスRTが書き換えられます。以前のトポロジーでは、ASBR31では、輸送標的：金のトンネルの0：500が輸送標的に書き換えられ、ASBR22に宣伝されます。同様に、輸送標的：金のトンネルの0：300は、ASBR11に広告する前に、ASBR21で輸送標的：0：100に書き換えられます。PE11では、輸送標的で受信した輸送ルート：0：100がColor 100 TRDBに追加されます。マッピングコミュニティの色で受信されたサービスルート：0：100500は、Gold TRDBにマップし、この輸送ルートで解決します。
Inter-domain traffic forwarding in the previous topology works as explained in Section 8.
以前のトポロジーのドメイン間トラフィック転送は、セクション8で説明されているように機能します。
Transport Class RT rewrite requires coordination of color values between domains in the transport layer. This method avoids the need to rewrite service route mapping communities, keeping the service layer homogenous and simple to manage. Coordinating Transport Class RT between two adjacent color domains at a time is easier than coordinating service layer colors deployed in a global mesh of non-adjacent color domains. This basically allows localizing the problem to a pair of adjacent color domains and solving it.
トランスポートクラスのRT書き換えには、輸送層のドメイン間の色の値の調整が必要です。この方法は、サービス層を均質で簡単に管理できるようにするために、サービスルートマッピングコミュニティを書き直す必要性を回避します。一度に2つの隣接するカラードメイン間のトランスポートクラスRTを調整することは、非隣接カラードメインのグローバルメッシュに展開されたサービスレイヤーカラーを調整するよりも簡単です。これにより、基本的に問題を隣接するカラードメインのペアにローカライズして解決できます。
In a heterogeneous-domain scenario, it might not be possible to map a service layer Intent to the matching transport color, as the color might not be locally available in a domain.
不均一なドメインのシナリオでは、ドメインで色が局所的に利用できない可能性があるため、一致する輸送色にサービスレイヤーの意図をマッピングすることはできない場合があります。
The following example illustrates how traffic is stitched when a transit AS contains more shades for an SLA path compared to ingress and egress domains. This example shows how service routes can traverse through finer shades when available and take coarse shades otherwise.
次の例は、イングレスドメインや出口ドメインと比較して、SLAパスのより多くの色合いが含まれている場合の交通がどのように縫い付けられるかを示しています。この例は、サービスルートが利用可能なときにより細かい色合いを通過し、それ以外の場合は粗い色合いを取る方法を示しています。
..................... ....................... .....................
: : : Gold1(101) : : :
: Gold(100) : : Gold2(102) : : Gold(100) :
: : : : : :
: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
: : : : : :
: Metro Ingress : : Core : : Metro Egress :
: : : : : :
: AS1 : : AS2 : : AS3 :
..................... ....................... .....................
----------- Traffic Direction -------->
Figure 9: Transport Layer with Heterogeneous Color Domains
図9：不均一なカラードメインを備えた輸送層
In Figure 9, we have three Autonomous Systems. All the nodes in the topology support BGP CT.
図9には、3つの自律システムがあります。トポロジのすべてのノードはBGP CTをサポートしています。
* In AS1, the Gold SLA is represented by color 100.
* AS1では、金SLAは色100で表されます。
* In AS2, Gold has finer shades: Gold1 by color 101 and Gold2 by color 102.
* AS2では、金の色合いはより細かい色合いです：色101でGold1、Color 102でGold2。
* In AS3, the Gold SLA is represented by color 100.
* AS3では、金SLAは色100で表されます。
This problem can be solved by the two approaches described in Sections 11.2.3.1 and 11.2.3.2.
この問題は、セクション11.2.3.1および11.2.3.2で説明されている2つのアプローチによって解決できます。
In this approach, duplicate tunnels that satisfy the Gold SLA are configured in domains AS1 and AS3, but they are given fine-grained colors 101 and 102.
このアプローチでは、金SLAを満たす重複トンネルは、AS1およびAS3ドメインで構成されていますが、細粒の色101および102が与えられます。
These tunnels will be installed in TRDBs corresponding to transport classes of colors 101 and 102.
これらのトンネルは、色101および102の輸送クラスに対応するTRDBに設置されます。
Overlay routes received with a Mapping Community (e.g., transport-target or color community) can resolve over these tunnels in the TRDB with matching colors by using Resolution Schemes.
マッピングコミュニティ（たとえば、トランスポートターゲットやカラーコミュニティ）で受信したオーバーレイルートは、解像度スキームを使用してこれらのトンネルでTRDBの一致する色で解決できます。
This approach consumes more resources in the transport and forwarding layer because of the duplicate tunnels.
このアプローチは、トンネルが重複しているため、輸送層と転送層により多くのリソースを消費します。
In this approach, Resolution Schemes in domains AS1 and AS3 are customized to map the received Mapping Community (e.g., transport-target or color community) over available Gold SLA tunnels. This conserves resource usage with no additional state in the transport or forwarding planes.
このアプローチでは、ドメインAS1およびAS3の解像度スキームは、利用可能な金SLAトンネルを介して受信したマッピングコミュニティ（輸送ターゲットやカラーコミュニティなど）をマッピングするようにカスタマイズされています。これにより、輸送機や転送機に追加の状態がなく、リソースの使用が節約されます。
Service routes advertised by PE31 that need to resolve over Gold1 transport tunnels carry a Mapping Community color:0:101. In AS3 and AS1, where Gold1 is not available, it is mapped to color 100 TRDB using a customized Resolution Scheme. In AS2, Gold1 is available, and it maps to color 101 TRDB.
Gold1輸送トンネルを超えて解決する必要があるPE31によって宣伝されたサービスルートには、マッピングコミュニティの色があります：0：101。Gold1が使用できないAS3およびAS1では、カスタマイズされた解像度スキームを使用して100 TRDBを色付けするようにマッピングされます。AS2では、Gold1が利用可能で、101 TRDBを色付けするためにマップします。
Similarly, service routes advertised by PE31 that need to resolve over Gold2 transport tunnels carry a Mapping Community color:0:102. In AS3 and AS1, where Gold2 is not available, it is mapped to color 100 TRDB using a customized Resolution Scheme. In AS2, Gold2 is available, and it maps to color 102 TRDB.
同様に、Gold2輸送トンネルを介して解決する必要があるPE31が宣伝するサービスルートには、マッピングコミュニティの色があります：0：102。Gold2が使用できないAS3およびAS1では、カスタマイズされた解像度スキームを使用して100 TRDBを色付けするようにマッピングされます。AS2では、Gold2が利用可能で、102 TRDBを色付けするためにマップします。
To facilitate this, SNs/BNs in all three ASes provision the transport classes 100, 101, and 102. SNs and BNs in AS1 and AS3 are provisioned with customized Resolution Schemes that resolve routes with transport-target:0:101 or transport-target:0:102 using color 100 TRDB.
これを容易にするために、3つのASEすべてのSNS/BNSは、AS1およびAS3のトランスポートクラス100、101、および102。SNSとBNSをプロビジョニングします。AS1およびAS3は、輸送ターゲットを使用してルートを解決するカスタマイズされた解像度スキームでプロビジョニングされます。
PE31 is provisioned to originate BGP CT routes with color 101 for endpoint PE31. This route is sent with an NLRI RD prefix RD1:PE31 and Route Target extended community transport-target:0:101.
PE31は、エンドポイントPE31の色101でBGP CTルートを発信するようにプロビジョニングされます。このルートは、NLRI RDプレフィックスRD1：PE31およびルートターゲット拡張コミュニティトランスポートターゲット：0：101で送信されます。
Similarly, PE31 is provisioned to originate BGP CT routes with color 102 for endpoint PE31. This route is sent with an NLRI RD prefix RD2:PE31 and Route Target extended community transport-target:0:102.
同様に、PE31は、エンドポイントPE31の色102のBGP CTルートを発信するようにプロビジョニングされます。このルートは、NLRI RDプレフィックスRD2：PE31とルートターゲット拡張コミュニティトランスポートターゲット：0：102で送信されます。
The following description explains the remaining procedures with color 101 as an example.
次の説明では、例として色101の残りの手順を説明します。
At ASBR31, the Route Target role of transport-target:0:101 on this BGP CT route gives instruction to add the route to color 101 TRDB. ASBR31 is provisioned with a customized Resolution Scheme that resolves the routes carrying Mapping Community transport-target:0:101 to resolve using color 100 TRDB. This route is then readvertised from color 101 TRDB to ASBR22 with route-target:0:101.
ASBR31では、このBGP CTルートの輸送標的のルートターゲットロール：0：101は、101 TRDBにルートを追加する命令を提供します。ASBR31には、マッピングコミュニティトランスポートターゲットを運ぶルートを解決するカスタマイズされた解像度スキームでプロビジョニングされます：0：101 Color 100 TRDBを使用して解決します。このルートは、ルートターゲット：0：101で色101 TRDBからASBR22に読み取りされます。
At ASBR22, the BGP CT routes received with transport-target:0:101 will be added to color 101 TRDB and strictly resolve over tunnel routes in the same TRDB. This route is readvertised to ASBR21 with transport-target:0:101.
ASBR22では、トランスポートターゲット：0：101で受信されたBGP CTルートが101 TRDBの色に追加され、同じTRDBのトンネルルート上で厳密に解決されます。このルートは、トランスポートターゲット：0：101でASBR21に読み込まれます。
Similarly, at ASBR21, the BGP CT routes received with transport-target:0:101 will be added to color 101 TRDB and strictly resolve over tunnel routes in the same TRDB. This route is readvertised to ASBR11 with transport-target:0:101.
同様に、ASBR21では、トランスポートターゲットで受信されたBGP CTルート：0：101がColor 101 TRDBに追加され、同じTRDBのトンネルルートを厳密に解決します。このルートは、トランスポートターゲットでASBR11に読み込まれます：0：101。
At ASBR11, the Route Target role of transport-target:0:101 on this BGP CT route gives instruction to add the route to color 101 TRDB. ASBR11 is provisioned with a customized Resolution Scheme that resolves the routes carrying transport-target:0:101 to use color 100 TRDB. This route is then readvertised from color 101 TRDB to PE11 with transport-target:0:101.
ASBR11では、このBGP CTルートの輸送標的のルートターゲットロール：0：101は、101 TRDBにルートを追加する命令を提供します。ASBR11には、輸送ターゲットを運ぶルートを解決するカスタマイズされた解像度スキームがプロビジョニングされています：0：101 Color 100 TRDBを使用します。このルートは、トランスポートターゲットを使用して、Color 101 TRDBからPE11に読み取りされます：0：101。
At PE11, the Route Target role of transport-target:0:101 on this BGP CT route gives instruction to add the route to color 101 TRDB. PE11 is provisioned with a customized Resolution Scheme that resolves the routes carrying transport-target:0:101 to use color 100 TRDB.
PE11では、このBGP CTルートの輸送標的のルートターゲットロール：0：101は、101 TRDBにルートを追加する命令を提供します。PE11には、輸送標的を運ぶルートを解決するカスタマイズされた解像度スキームがプロビジョニングされます：0：101は、Color 100 TRDBを使用します。
When PE11 receives the service route with the Mapping Community color:0:101, it directly resolves over the BGP CT route in color 101 TRDB, which, in turn, resolves over tunnel routes in color 100 TRDB.
PE11がマッピングコミュニティの色でサービスルートを受信すると、0：101では、色101 TRDBのBGP CTルートを直接解決し、100 TRDBのトンネルルートを分解します。
Similar processing is done for color 102 routes also at ASBR31, ASBR22, ASBR21, ASBR11, and PE11.
同様の処理は、ASBR31、ASBR22、ASBR21、ASBR11、およびPE11でも色102ルートで行われます。
In doing so, PE11 can forward traffic via tunnels with color 101, color 102 in the core domain and color 100 in the metro domains.
そうすることで、PE11は、Color 101、Color 102、Core Domain、Color 100でTunnelsを介してトラフィックを転送できます。
This section explains how an end-to-end SLA can be achieved while transiting a domain that does not support BGP CT. BGP LU is used in such domains to connect the BGP CT islands.
このセクションでは、BGP CTをサポートしていないドメインを通過する際に、エンドツーエンドのSLAをどのように達成できるかについて説明します。BGP Luは、BGP CT島を接続するためにそのようなドメインで使用されます。
+----------EBGP Multihop CT-------------+
| |
AS3 | AS2 | AS1
[PE31-----ASBR31]--------[ASBR22---ASBR21]-------[ASBR11---PE11]
<--EBGP LU--> <--EBGP LU-->
<--IBGP CT--> <--IBGP LU--> <--IBGP CT-->
---------Traffic Direction--------->
Figure 10: BGP CT in AS1 and AS3 Connected by BGP LU in AS2
図10：AS1およびAS3のBGP CTは、BGP LUによってAS2で接続されています
In the preceding topology shown in Figure 10, there are three AS domains: AS1 and AS3 support BGP CT, while AS2 does not support BGP CT.
図10に示す前のトポロジには、AS1とAS3がBGP CTをサポートし、AS2はBGP CTをサポートしていない3つのドメインがあります。
Nodes in AS1, AS2, and AS3 negotiate BGP LU family on IBGP sessions within the domain. Nodes in AS1 and AS3 negotiate BGP CT family on IBGP sessions within the domain. ASBR11 and ASBR21 as well as ASBR22 and ASBR31 negotiate BGP LU family on the EBGP session over directly connected inter-domain links. ASBR11 and ASBR31 have reachability to each other's loopbacks through BGP LU. ASBR11 and ASBR31 negotiate BGP CT family over a multihop EBGP session formed using BGP LU reachability.
AS1、AS2、およびAS3のノードは、ドメイン内のIBGPセッションでBGP Luファミリーと交渉します。AS1およびAS3のノードは、ドメイン内のIBGPセッションでBGP CTファミリーを交渉します。ASBR11およびASBR21、およびASBR22およびASBR31は、直接接続されたドメイン間リンクでEBGPセッションでBGP Luファミリーを交渉します。ASBR11とASBR31は、BGP Luを介して互いのループバックに到達可能性を持っています。ASBR11およびASBR31は、BGP LUリーチビリティを使用して形成されたマルチホップEBGPセッションでBGP CTファミリーと交渉します。
The following tunnels exist for the Gold Transport Class
ゴールドトランスポートクラスには、次のトンネルが存在します
* PE11_to_ASBR11_gold - RSVP-TE tunnel
* PE11_TO_ASBR11_GOLD -RSVP -TEトンネル
* ASBR11_to_PE11_gold - RSVP-TE tunnel
* ASBR11_TO_PE11_GOLD -RSVP -TEトンネル
* PE31_to_ASBR31_gold - SRTE tunnel
* PE31_TO_ASBR31_GOLD -SRTEトンネル
* ASBR31_to_PE31_gold - SRTE tunnel
* ASBR31_TO_PE31_GOLD -SRTEトンネル
The following tunnels exist for the Bronze Transport Class
ブロンズ輸送クラスには、次のトンネルが存在します
* PE11_to_ASBR11_bronze - RSVP-TE tunnel
* PE11_TO_ASBR11_BRONZE -RSVP -TEトンネル
* ASBR11_to_PE11_bronze - RSVP-TE tunnel
* ASBR11_TO_PE11_BRONZE -RSVP -TEトンネル
* PE31_to_ASBR31_bronze - SRTE tunnel
* PE31_TO_ASBR31_BRONZE -SRTEトンネル
* ASBR31_to_PE31_bronze - SRTE tunnel
* ASBR31_TO_PE31_BRONZE -SRTEトンネル
These tunnels are provisioned to belong to Transport Classes Gold and Bronze, and they are advertised between ASBR31 and ASBR11 with the next hop set to themselves.
これらのトンネルは、輸送クラスの金と青銅に属するように提供され、ASBR31とASBR11の間で次のホップセットが設定されて宣伝されています。
In AS2, which does not support BGP CT, a separate loopback may be used on ASBR22 and ASBR21 to represent Gold and Bronze SLAs, namely ASBR22_lpbk_gold, ASBR22_lpbk_bronze, ASBR21_lpbk_gold, and ASBR21_lpbk_bronze.
BGP CTをサポートしていないAS2では、ASBR22およびASBR21で別のループバックを使用して金と青銅のSLA、つまりASBR22_LPBK_GOLD、ASBR22_LPBK_BRONZE、ASBR21_LPBK_GOLD、ASBR21_LPBK_BRONZE。
Furthermore, the following tunnels exist in AS2 to satisfy the different SLAs using per-SLA-loopback endpoints:
さらに、SLA-Loopbackごとのエンドポイントを使用して、さまざまなSLAを満たすために、次のトンネルがAS2に存在します。
* ASBR21_to_ASBR22_lpbk_gold - RSVP-TE tunnel
* ASBR21_TO_ASBR22_LPBK_GOLD -RSVP -TEトンネル
* ASBR22_to_ASBR21_lpbk_gold - RSVP-TE tunnel
* ASBR22_TO_ASBR21_LPBK_GOLD -RSVP -TEトンネル
* ASBR21_to_ASBR22_lpbk_bronze - RSVP-TE tunnel
* ASBR21_TO_ASBR22_LPBK_BRONZE -RSVP -TEトンネル
* ASBR22_to_ASBR21_lpbk_bronze - RSVP-TE tunnel
* ASBR22_TO_ASBR21_LPBK_BRONZE -RSVP -TEトンネル
The RD:PE11 BGP CT route is originated from PE11 towards ASBR11 with transport-target 'gold.' ASBR11 readvertises this route with the next hop set to ASBR11_lpbk_gold on the EBGP multihop session towards ASBR31. ASBR11 originates a BGP LU route for endpoint ASBR11_lpbk_gold on an EBGP session to ASBR21 with a 'gold SLA' community and a BGP LU route for ASBR11_lpbk_bronze with a 'bronze SLA' community. The SLA community is used by ASBR31 to publish the BGP LU routes in the corresponding BGP CT TRDBs.
RD：PE11 BGP CTルートは、PE11からASBR11に向かって輸送標的「ゴールド」で発信されます。ASBR11は、ASBR31に向かうEBGPマルチホップセッションでASBR11_LPBK_GOLDに次のホップセットでこのルートを読み取ります。ASBR11は、「Gold SLA」コミュニティとASBR11_LPBK_BRONZEのBGP LUルートでASBR21へのEBGPセッションで、エンドポイントASBR11_LPBK_GOLDのBGP LUルートを発信します。SLAコミュニティは、ASBR31が対応するBGP CT TRDBでBGP LUルートを公開するために使用されます。
ASBR21 readvertises the BGP LU route for endpoint ASBR11_lpbk_gold to ASBR22 with the next hop set by local policy config to the unique loopback ASBR21_lpbk_gold by matching the 'gold SLA' community received as part of BGP LU advertisement from ASBR11. ASBR22 receives this route and resolves the next hop over the ASBR22_to_ASBR21_lpbk_gold RSVP-TE tunnel. On successful resolution, ASBR22 readvertises this BGP LU route to ASBR31 with the next hop set to itself and a new label.
ASBR21は、ASBR11からのBGP LU広告の一環として受け取った「ゴールドSLA」コミュニティと一致することにより、ローカルポリシー構成によって次のホップセットを使用して、エンドポイントASBR11_LPBK_GOLDのBGP LUルートをASBR22にasbr22に読み取ります。ASBR22はこのルートを受け取り、ASBR22_TO_ASBR21_LPBK_GOLD RSVP-TEトンネルを介して次のホップを解決します。解像度が成功した場合、ASBR22は、次のホップセット自体と新しいラベルを使用して、このBGP LUルートをASBR31へのBGP LUルートをReadvertiseしています。
ASBR31 adds the ASBR11_lpbk_gold route received via EBGP LU from ASBR22 to a 'gold' TRDB based on the received 'gold SLA' community. ASBR31 uses this 'gold' TRDB route to resolve the next hop ASBR11_lpbk_gold received on the BGP CT route with transport-target 'gold,' for the prefix RD:PE11 received over the EBGP multihop CT session, thus preserving the end-to-end SLA. Now ASBR31 readvertises the BGP CT route for RD:PE11 with the next hop set to itself, thus stitching with the BGP LU LSP in AS2. Intra-domain traffic forwarding in AS1 and AS3 follows the procedures as explained in Section 8.
ASBR31は、ASBR22からASBR22から受信した「ゴールドSLA」コミュニティに基づいて「ゴールド」TRDBにeBGP LUを介して受信したASBR11_LPBK_GOLDルートを追加します。ASBR31は、この「ゴールド」TRDBルートを使用して、輸送標的「ゴールド」でBGP CTルートで受信した次のホップASBR11_LPBK_GOLDを解決します。PREIXRD：PE11はEBGPマルチホップCTセッションで受信し、終了SLAを保存します。現在、ASBR31は、次のホップセット自体を備えたRD：PE11のBGP CTルートを読み取り、AS2のBGP LU LSPでステッチします。AS1およびAS3のドメイン内トラフィック転送は、セクション8で説明されている手順に従います。
In cases where an SLA cannot be preserved in AS2 because SLA-specific tunnels and loopbacks don't exist in AS2, traffic can be carried over available SLAs (e.g., best-effort SLA) by rewriting the next hop to an ASBR21 loopback assigned to the available SLA. This eases migration in case of a heterogeneous color domain as well.
SLA固有のトンネルとループバックがAS2に存在しないため、SLAをAS2で保存できない場合、利用可能なSLAに割り当てられたASBR21ループバックに次のホップを書き直すことで、利用可能なSLA（ベストエフォートSLAなど）をトラフィックすることができます。これにより、異種の色ドメインの場合にも移行が容易になります。
This section describes how nodes supporting dissimilar encapsulation technologies can interoperate when using the BGP CT family.
このセクションでは、BGP CTファミリーを使用する際に、異なるカプセル化テクノロジーをサポートするノードがどのように相互運用できるかについて説明します。
BGP speakers may carry MPLS labels and SRv6 SIDs in BGP CT SAFI 76 for AFI 1 or 2 routes using protocol encoding as described in Section 6.3.
BGPスピーカーは、セクション6.3で説明されているように、プロトコルエンコードを使用して、AFI 1または2ルートのBGP CT SAFI 76のMPLSラベルとSRV6 SIDを搭載することができます。
MPLS labels are carried using the encoding described in [RFC8277], and SRv6 SIDs are carried using the Prefix-SID attribute as specified in Section 7.13.
MPLSラベルは[RFC8277]で説明されているエンコードを使用して運ばれ、SRV6 SIDSはセクション7.13で指定されているようにプレフィックス-SID属性を使用して運ばれます。
RR1---+
\ +-------R2 [MPLS + SRv6]
\ |
R1--------P-------R3 [MPLS only]
[MPLS + SRv6] |
+-------R4 [SRv6 only]
<---- Bidirectional Traffic ----->
Figure 11: BGP CT Interoperation Between MPLS and SRv6 Nodes
図11：MPLSとSRV6ノード間のBGP CT相互操作
This example shows a provider network with a mix of devices that have different forwarding capabilities. R1 and R2 support forwarding both MPLS and SRv6 packets. R3 supports forwarding MPLS packets only. R4 supports forwarding SRv6 packets only. All these nodes have a BGP session with Route Reflector RR1, which reflects routes between these nodes with the next hop unchanged. The BGP CT family is negotiated on these sessions.
この例は、転送機能が異なるデバイスが組み合わされたプロバイダーネットワークを示しています。R1とR2は、MPLSとSRV6パケットの両方の転送をサポートします。R3は、MPLSパケットの転送のみをサポートしています。R4は、SRV6パケットの転送のみをサポートしています。これらすべてのノードには、ルートリフレクターRR1を使用したBGPセッションがあります。これは、これらのノード間のルートを反映して、次のホップが変更されていません。BGP CTファミリーは、これらのセッションで交渉されています。
R1 and R2 send and receive both MPLS labels and SRv6 SIDs in the BGP CT control plane routes. This allows them to be ingress and egress for both MPLS and SRv6 data planes. The MPLS label is carried using the encoding described in [RFC8277], and an SRv6 SID is carried using the Prefix-SID attribute as specified in Section 7.13 without the Transposition Scheme. In this way, either MPLS or SRv6 forwarding can be used between R1 and R2.
R1とR2は、BGP CTコントロールプレーンルートでMPLSラベルとSRV6 SIDの両方を送信および受信します。これにより、MPLSとSRV6データプレーンの両方に侵入して脱出することができます。MPLSラベルは、[RFC8277]で説明されているエンコードを使用して運ばれ、SRV6 SIDは、転置スキームなしでセクション7.13で指定されているように、プレフィックス-SID属性を使用して運ばれます。このようにして、MPLSまたはSRV6転送のいずれかをR1とR2の間で使用できます。
R1 and R3 send and receive an MPLS label in the BGP CT control plane routes using the encoding described in [RFC8277]. This allows them to be ingress and egress for MPLS data plane. R1 will carry an SRv6 SID in the Prefix-SID attribute, which will not be used by R3. In order to interoperate with MPLS-only device R3, R1 MUST NOT use the SRv6 Transposition Scheme described in [RFC9252]. The encoding suggested in Section 7.13 is used by R1. MPLS forwarding will be used between R1 and R3.
R1とR3は、[RFC8277]で説明されているエンコードを使用して、BGP CTコントロールプレーンルートでMPLSラベルを送信および受信します。これにより、MPLSデータプレーンの侵入と出口になります。R1は、R3では使用されないプレフィックスシド属性にSRV6 SIDを搭載します。MPLSのみのデバイスR3と相互運用するために、R1は[RFC9252]で説明されているSRV6転置スキームを使用してはなりません。セクション7.13で提案されているエンコーディングは、R1で使用されます。MPLS転送は、R1とR3の間で使用されます。
R1 and R4 send and receive SRv6 SIDs in the BGP CT control plane routes using the BGP Prefix-SID attribute, without a Transposition Scheme. This allows them to be ingress and egress for the SRv6 data plane. R4 will carry the special MPLS label with a value of 3 (Implicit NULL) in the encoding described in [RFC8277], which tells R1 not to push any MPLS label for this BGP CT route towards R4. The MPLS label advertised by R1 in an NLRI as described in [RFC8277] will not be used by R4. SRv6 forwarding will be used between R1 and R4.
R1とR4は、転置スキームなしでBGPプレフィックス-SID属性を使用して、BGP CT制御プレーンルートでSRV6 SIDを送信および受信します。これにより、SRV6データプレーンに侵入して出口になります。R4は、[RFC8277]に記載されているエンコードに3（暗黙のヌル）の値を持つ特別なMPLSラベルを持ち、R1にこのBGP CTルートのMPLSラベルをR4に向けないように指示します。[RFC8277]で説明されているNLRIでR1によって宣伝されているMPLSラベルは、R4では使用されません。SRV6転送は、R1とR4の間で使用されます。
Note that, in this example, R3 and R4 cannot communicate directly with each other because they don't support a common forwarding technology. The BGP CT routes received at R3 and R4 from each other will remain unusable due to incompatible forwarding technology.
この例では、R3とR4は一般的な転送技術をサポートしていないため、互いに直接通信できないことに注意してください。互いにR3とR4で受信したBGP CTルートは、互換性のない転送技術のために使用できないままです。
This section describes how nodes supporting MPLS forwarding can interoperate with other nodes supporting UDP (or IP) tunneling when using BGP CT family.
このセクションでは、MPLS転送をサポートするノードが、BGP CTファミリーを使用する際にUDP（またはIP）トンネルをサポートする他のノードと相互運用する方法について説明します。
MPLS labels are carried using the encoding described in [RFC8277], and UDP (or IP) tunneling information is carried using the TEA attribute or the Encapsulation extended community as specified in [RFC9012].
MPLSラベルは、[RFC8277]で説明されているエンコードを使用して運ばれ、UDP（またはIP）トンネリング情報は、[RFC9012]で指定されているように、TEA属性またはカプセル化拡張コミュニティを使用して運ばれます。
RR1---+
\ +-------R2 [MPLS + UDP]
\ |
R1--------P-------R3 [MPLS only]
[MPLS + UDP] |
+-------R4 [UDP only]
<---- Bidirectional Traffic ----->
Figure 12: BGP CT Interop Between MPLS and UDP Tunneling Nodes
図12：MPLSとUDPトンネルノードの間のBGP CTイントロップ
In this example, R1 and R2 support forwarding both MPLS and UDP tunneled packets. R3 supports forwarding MPLS packets only. R4 supports forwarding UDP tunneled packets only. All these nodes have BGP session with Route Reflector RR1, which reflects routes between these nodes with the next hop unchanged. The BGP CT family is negotiated on these sessions.
この例では、R1とR2はMPLとUDPトンネルパケットの両方の転送をサポートしています。R3は、MPLSパケットの転送のみをサポートしています。R4は、UDPトンネルパケットの転送のみをサポートします。これらすべてのノードには、ルートリフレクターRR1を使用したBGPセッションがあります。これは、これらのノード間のルートを反映して、次のホップが変更されていません。BGP CTファミリーは、これらのセッションで交渉されています。
R1 and R2 send and receive both MPLS labels and UDP tunneling info in the BGP CT control plane routes. This allows them to be ingress and egress for both MPLS and UDP tunneling data planes. The MPLS label is carried using the encoding described in [RFC8277]. As specified in [RFC9012], UDP tunneling information is carried using the Tunnel Encapsulation Attribute (attribute code 23) or the "barebones" Tunnel TLV carried in Encapsulation extended community. Either MPLS or UDP tunnel forwarding can be used between R1 and R2.
R1とR2は、BGP CTコントロールプレーンルートでMPLSラベルとUDPトンネル情報の両方を送信および受信します。これにより、MPLSとUDPトンネルデータプレーンの両方に侵入して出口になります。MPLSラベルは、[RFC8277]で説明されているエンコードを使用して運ばれます。[RFC9012]で指定されているように、UDPトンネル情報は、トンネルカプセル化属性（属性コード23）またはカプセル化拡張コミュニティで運ばれる「ベアボーン」トンネルTLVを使用して運ばれます。MPLSまたはUDPトンネル転送のいずれかをR1とR2の間で使用できます。
R1 and R3 send and receive MPLS labels in the BGP CT control plane routes using the encoding described in [RFC8277]. This allows them to be ingress and egress for MPLS data plane. R1 will carry UDP tunneling info in the TEA, which will not be used by R3. MPLS forwarding will be used between R1 and R3.
R1およびR3は、[RFC8277]で説明されているエンコードを使用して、BGP CT制御プレーンルートでMPLSラベルを送信および受信します。これにより、MPLSデータプレーンの侵入と出口になります。R1は、R3では使用されない茶にUDPトンネル情報を運びます。MPLS転送は、R1とR3の間で使用されます。
R1 and R4 send and receive UDP tunneling info in the BGP CT control plane routes using the BGP TEA. This allows them to be ingress and egress for UDP tunneled data plane. R4 will carry MPLS special label 3 (Implicit NULL) in the encoding described in [RFC8277], which tells R1 not to push any MPLS label for this BGP CT route towards R4. The MPLS label advertised by R1 will not be used by R4. UDP tunneled forwarding will be used between R1 and R4.
R1とR4は、BGP茶を使用してBGP CTコントロールプレーンルートでUDPトンネル情報を送信および受け取ります。これにより、UDPトンネルデータプレーンの侵入と出口になります。R4は、[RFC8277]に記載されているエンコードにMPLS特別ラベル3（暗黙のヌル）を運びます。これは、このBGP CTルートのMPLSラベルをR4に向けてプッシュしないようにR1に指示します。R1によって宣伝されているMPLSラベルは、R4では使用されません。UDPトンネル転送は、R1とR4の間で使用されます。
Note that, in this example, R3 and R4 cannot communicate directly with each other because they don't support a common forwarding technology. The BGP CT routes received at R3 and R4 from each other will remain unusable due to incompatible forwarding technology.
この例では、R3とR4は一般的な転送技術をサポートしていないため、互いに直接通信できないことに注意してください。互いにR3とR4で受信したBGP CTルートは、互換性のない転送技術のために使用できないままです。
Operators should coordinate the MTU of the intra-domain tunnels used to prevent Path MTU discovery problems that could appear in deployments. The encapsulation overhead due to the MPLS label stack or equivalent tunnel header in different forwarding architecture should also be considered when determining the Path MTU of the end-to-end BGP CT tunnel.
オペレーターは、展開に表示される可能性のあるPATH MTU発見の問題を防ぐために使用されるドメイン内トンネルのMTUを調整する必要があります。MPLSラベルスタックまたは異なる転送アーキテクチャの同等のトンネルヘッダーによるカプセル化オーバーヘッドも、エンドツーエンドBGP CTトンネルのパスMTUを決定する際に考慮する必要があります。
[INTAREA-TUNNELS] discusses these considerations in more detail.
[Intarea-Tunnels]これらの考慮事項については、より詳細に説明します。
BGP CT specifies procedures for Intent-Driven Service Mapping in a service provider network and defines the 'Transport Class' construct to represent an Intent.
BGP CTは、サービスプロバイダーネットワークでの意図駆動型のサービスマッピングの手順を指定し、意図を表す「トランスポートクラス」構成を定義します。
It may be desirable to allow a CE device to indicate in the data packet it sends what treatment it desires (the Intent) when the packet is forwarded within the provider network.
CEデバイスがデータパケットで、パケットがプロバイダーネットワーク内で転送されたときに必要な（意図）を送信するデータパケットを示すことが望ましい場合があります。
Such an indication can be in the form of a DSCP (see [RFC2474]) in the IP header.
このような兆候は、IPヘッダーのDSCP（[rfc2474]を参照）の形式である可能性があります。
In [RFC2474], a Forwarding Class Selector maps to a PHB (Per-hop Behavior). The Transport Class construct is a PHB at the transport layer.
[RFC2474]では、転送クラスセレクターがPHBにマップします（ホップごとの動作）。輸送クラスの構造は、輸送層のPHBです。
----Gold----->
[CE1]-----[PE1]---[P]----[PE2]-----[CE2]
---Bronze---->
203.0.113.11 203.0.113.22
-----Traffic direction---->
Figure 13: Example Topology with DSCP on PE-CE Links
図13：PE-CEリンクのDSCPを使用したトポロジの例
Let PE1 be configured to map DSCP1 to the Gold TC and DSCP2 to the Bronze TC. Based on the DSCP received on the IP traffic from the CE device, PE1 forwards the IP packet over a Gold or Bronze TC tunnel. Thus, the forwarding is not based on just the destination IP address but also the DSCP. This is known as Class-Based Forwarding (CBF).
DSCP1を金TCにマッピングし、DSCP2をブロンズTCにマッピングするようにPE1を構成します。CEデバイスからIPトラフィックで受信したDSCPに基づいて、PE1は金またはブロンズTCトンネル上でIPパケットを転送します。したがって、転送は宛先IPアドレスのみに基づいているのではなく、DSCPにも基づいています。これは、クラスベースの転送（CBF）として知られています。
CBF is configured at the PE1 device, mapping the DSCP values to respective Transport Classes. This mapping (DSCP peering agreement) is communicated to CE devices by out-of-band mechanisms. This allows the administrator of CE1 to discover what Transport Classes exist in the provider network and which DSCP to encode so that traffic is forwarded using the desired Transport Class in the provided network. When the IP packet exits the provider network to CE2, PE2 resets the DSCP based on the DSCP peering agreement with CE2.
CBFはPE1デバイスで構成されており、DSCP値をそれぞれの輸送クラスにマッピングします。このマッピング（DSCPピアリング契約）は、バンド外のメカニズムによってCEデバイスに伝えられます。これにより、CE1の管理者は、プロバイダーネットワークにどの輸送クラスが存在するか、および提供されたネットワークの目的の輸送クラスを使用してトラフィックが転送されるようにエンコードするDSCPをエンコードすることができます。IPパケットがプロバイダーネットワークをCE2に終了すると、CE2とのDSCPピアリング契約に基づいてPE2がDSCPをリセットします。
In Network Slicing, the IETF Network Slice Controller (NSC) is responsible for customizing and setting up the underlying transport (e.g., RSVP-TE, SRTE tunnels with desired characteristics) and resources (e.g., policies/shapers) in a transport network to create an IETF Network Slice.
ネットワークスライスでは、IETFネットワークスライスコントローラー（NSC）は、IETFネットワークスライスを作成するためのトランスポートネットワークの輸送ネットワークの基礎となるトランスポート（例：RSVP-TE、SRTEトンネルなど）およびリソース（ポリシー/シェイパーなど）のカスタマイズとセットアップを担当します。
The Transport Class construct described in this document can be used to realize the "IETF Network Slice" described in Section 4 of [RFC9543].
このドキュメントで説明されているトランスポートクラスの構成は、[RFC9543]のセクション4で説明されている「IETFネットワークスライス」を実現するために使用できます。
The NSC can use the Transport Class Identifier (Color value) to provision a transport tunnel in a specific IETF Network Slice.
NSCは、トランスポートクラス識別子（色値）を使用して、特定のIETFネットワークスライスに輸送トンネルを提供できます。
Furthermore, the NSC can use the Mapping Community on the service route to map traffic to the desired IETF Network Slice.
さらに、NSCはサービスルートでマッピングコミュニティを使用して、目的のIETFネットワークスライスにトラフィックをマッピングできます。
IANA has assigned BGP SAFI code 76 for the "Classful Transport (CT)" SAFI.
IANAは、「クラスフルトランスポート（CT）」SAFIにBGP SAFIコード76を割り当てました。
Registry Group:
レジストリグループ：
Subsequent Address Family Identifiers (SAFI) Parameters
後続のアドレスファミリ識別子（SAFI）パラメーター
Registry Name:
レジストリ名：
SAFI Values
SAFI値
+=======+=========================+===========+
| Value | Description | Reference |
+=======+=========================+===========+
| 76 | Classful Transport (CT) | RFC 9832 |
+-------+-------------------------+-----------+
Table 1
This will be used to create new AFI/SAFI pairs for IPv4 and IPv6 BGP CT families, namely:
これは、IPv4およびIPv6 BGP CTファミリの新しいAFI/SAFIペアを作成するために使用されます。
* IPv4 BGP CT: AFI/SAFI = 1/76, for carrying IPv4 prefixes.
* IPv4 BGP CT：AFI/SAFI = 1/76、IPv4プレフィックスを運ぶため。
* IPv6 BGP CT: AFI/SAFI = 2/76, for carrying IPv6 prefixes.
* IPv6 BGP CT：AFI/SAFI = 2/76、IPv6プレフィックスを運ぶため。
IANA has assigned a Format type (Type high = 0xa) of Extended Community [RFC4360] for the Transport Class from the following registries in the "Border Gateway Protocol (BGP) Extended Communities" registry group:
IANAは、「Border Gateway Protocol（BGP）Extended Communities」レジストリグループの次のレジストリから輸送クラスに、拡張コミュニティ[RFC4360]のフォーマットタイプ（タイプハイ= 0xA）を割り当てました。
* the "BGP Transitive Extended Community Types" registry and
* 「BGP推移的拡張コミュニティタイプ」レジストリと
* the "BGP Non-Transitive Extended Community Types" registry.
* 「BGP非緊急拡張コミュニティタイプ」レジストリ。
The same low-order six bits have been assigned for both allocations.
両方の割り当てに同じ低次の6ビットが割り当てられています。
This document uses this new Format with subtype 0x2 (route target), as a transitive extended community. The Route Target thus formed is called "Transport Class Route Target extended community".
このドキュメントでは、この新しい形式では、サブタイプ0x2（ルートターゲット）を使用して、推移的な拡張コミュニティとして使用しています。このように形成されたルートターゲットは、「トランスポートクラスルートターゲット拡張コミュニティ」と呼ばれます。
The non-transitive Transport Class extended community with subtype 0x2 (route target) is called the "Non-Transitive Transport Class Route Target extended community".
サブタイプ0x2（ルートターゲット）を備えた非緊急輸送クラスの拡張コミュニティは、「非緊急輸送クラスルートターゲット拡張コミュニティ」と呼ばれます。
Following [RFC7153], assignments in the following subsections have been made.
[RFC7153]に続いて、次のサブセクションの割り当てが行われました。
This registry contains values of the high-order octet (the "Type" field) of a Transitive Extended Community.
このレジストリには、推移的な拡張コミュニティの高次オクテット（「タイプ」フィールド）の値が含まれています。
Registry Group:
レジストリグループ：
Border Gateway Protocol (BGP) Extended Communities
Border Gateway Protocol（BGP）拡張コミュニティ
Registry Name:
レジストリ名：
BGP Transitive Extended Community Types
BGP推移的な拡張コミュニティタイプ
+============+=================+
| Type Value | Name |
+============+=================+
| 0x0a | Transport Class |
+------------+-----------------+
Table 2
(Sub-Types are defined in the "Transitive Transport Class Extended Community Sub-Types" registry.)
（サブタイプは、「Transitive Transport Class Extended Community Sub-Types」レジストリで定義されています。）
This registry contains values of the high-order octet (the "Type" field) of a Non-Transitive Extended Community.
このレジストリには、非転換拡張コミュニティの高次オクテット（「タイプ」フィールド）の値が含まれています。
Registry Group:
レジストリグループ：
Border Gateway Protocol (BGP) Extended Communities
Border Gateway Protocol（BGP）拡張コミュニティ
Registry Name:
レジストリ名：
BGP Non-Transitive Extended Community Types
BGP非緊急拡張コミュニティタイプ
+============+================================+
| Type Value | Name |
+============+================================+
| 0x4a | Non-Transitive Transport Class |
+------------+--------------------------------+
Table 3
(Sub-Types are defined in the "Non-Transitive Transport Class Extended Community Sub-Types" registry.)
（サブタイプは、「非転換輸送クラス拡張コミュニティサブタイプ」レジストリで定義されます。）
IANA has added the following subregistry under the "Border Gateway Protocol (BGP) Extended Communities" registry group:
IANAは、「Border Gateway Protocol（BGP）拡張コミュニティ」レジストリグループの下に次のサブレジストリを追加しました。
Registry Group:
レジストリグループ：
Border Gateway Protocol (BGP) Extended Communities
Border Gateway Protocol（BGP）拡張コミュニティ
Registry Name:
レジストリ名：
Transitive Transport Class Extended Community Sub-Types
Transitive Transport Class拡張コミュニティサブタイプ
Note: This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x0a.
注：このレジストリには、最初のオクテット（「タイプ」フィールド）の値が0x0aの場合、拡張コミュニティの2番目のオクテット（「サブタイプ」フィールド）の値が含まれています。
+===========+=========================+
| Range | Registration Procedure |
+===========+=========================+
| 0x00-0xbf | First Come First Served |
+-----------+-------------------------+
| 0xc0-0xff | IETF Review |
+-----------+-------------------------+
Table 4
+================+==============+
| Sub-Type Value | Name |
+================+==============+
| 0x02 | Route Target |
+----------------+--------------+
Table 5
IANA has added the following subregistry under the "Border Gateway Protocol (BGP) Extended Communities" registry group:
IANAは、「Border Gateway Protocol（BGP）拡張コミュニティ」レジストリグループの下に次のサブレジストリを追加しました。
Registry Group:
レジストリグループ：
Border Gateway Protocol (BGP) Extended Communities
Border Gateway Protocol（BGP）拡張コミュニティ
Registry Name:
レジストリ名：
Non-Transitive Transport Class Extended Community Sub-Types
非緊急輸送クラス拡張コミュニティサブタイプ
Note: This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x4a.
注：このレジストリには、最初のオクテット（「タイプ」フィールド）の値が0x4aの場合、拡張コミュニティの2番目のオクテット（「サブタイプ」フィールド）の値が含まれています。
+===========+=========================+
| Range | Registration Procedure |
+===========+=========================+
| 0x00-0xbf | First Come First Served |
+-----------+-------------------------+
| 0xc0-0xff | IETF Review |
+-----------+-------------------------+
Table 6
+================+==============+
| Sub-Type Value | Name |
+================+==============+
| 0x02 | Route Target |
+----------------+--------------+
Table 7
The following two code points have been assigned for Target FEC Stack sub-TLVs:
ターゲットFECスタックサブTLVに次の2つのコードポイントが割り当てられています。
* IPv4 BGP Classful Transport
* IPv4 BGPクラスフルトランスポート
* IPv6 BGP Classful Transport
* IPv6 BGPクラスフルトランスポート
Registry Group:
レジストリグループ：
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters
マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）pingパラメーター
Registry Name:
レジストリ名：
Sub-TLVs for TLV Types 1, 16, and 21
TLVタイプ1、16、および21のサブTLV
+==========+=============================+
| Sub-Type | Name |
+==========+=============================+
| 31744 | IPv4 BGP Classful Transport |
+----------+-----------------------------+
| 31745 | IPv6 BGP Classful Transport |
+----------+-----------------------------+
Table 8
This RFC documents the "Transport Class ID" registry and its assigned values. The value ranges in this registry are either assigned by this document or reserved for Private Use. Because the registry is complete, it is being published in this RFC rather than as an IANA-maintained registry. However, note that IANA-related terminology [BCP26] is used here.
このRFCは、「トランスポートクラスID」レジストリとその割り当てされた値を文書化します。このレジストリの値の範囲は、このドキュメントによって割り当てられるか、個人用に予約されています。レジストリは完了しているため、IANAが維持したレジストリとしてではなく、このRFCで公開されています。ただし、ここではIANA関連の用語[BCP26]が使用されていることに注意してください。
Registry Name: Transport Class ID
レジストリ名：トランスポートクラスID
The Registration Procedures are as follows:
登録手順は次のとおりです。
+==============+========================+
| Value | Registration Procedure |
+==============+========================+
| 0 | IETF Review |
+--------------+------------------------+
| 1-4294967295 | Private Use |
+--------------+------------------------+
Table 9
As shown in the table below, the Transport Class ID value 0 is Reserved to represent the "Best-Effort Transport Class ID". This is used in the 'Transport Class ID' field of a Transport Class RT that represents the Best-Effort Transport Class.
以下の表に示すように、トランスポートクラスID値0は「ベストエフォルトトランスポートクラスID」を表すために予約されています。これは、最高のエフォルトトランスポートクラスを表すトランスポートクラスRTの「トランスポートクラスID」フィールドで使用されます。
+==============+================================+
| Value | Name |
+==============+================================+
| 0 | Best-Effort Transport Class ID |
+--------------+--------------------------------+
| 1-4294967295 | Private Use |
+--------------+--------------------------------+
Table 10
As noted in Sections 4 and 7.10, 'Transport Class ID' is interchangeable with 'Color'. For purposes of backward compatibility with usage of a 'Color' field in a Color extended community as specified in [RFC9012] and [RFC9256], the range 1-4294967295 uses 'Private Use' as the Registration Procedure.
セクション4および7.10で述べたように、「トランスポートクラスID」は「色」と交換可能です。[RFC9012]および[RFC9256]で指定されている色拡張コミュニティの「色」フィールドの使用との後方互換性の目的のために、範囲1-4294967295は登録手順として「プライベート使用」を使用します。
This document uses the mechanisms from [RFC4760] to define new BGP address families (AFI/SAFI : 1/76 and 2/76) that carry transport layer endpoints. These address families are explicitly configured and negotiated between BGP speakers, which confines the propagation scope of this reachability information. These routes stay in the part of network where the new address family is negotiated and don't leak out into the Internet.
このドキュメントでは、[RFC4760]のメカニズムを使用して、輸送層のエンドポイントを運ぶ新しいBGPアドレスファミリ（AFI/SAFI：1/76および2/76）を定義します。これらのアドレスファミリは、BGPスピーカー間で明示的に構成および交渉され、この到達可能性情報の伝播範囲を限定しています。これらのルートは、新しいアドレスファミリが交渉され、インターネットに漏れないネットワークの部分にとどまります。
Furthermore, procedures defined in Section 9.1 mitigate the risk of unintended propagation of BGP CT routes across inter-AS boundaries even when a BGP CT family is negotiated. BGP import and export policies are used to control the BGP CT reachability information exchanged across AS boundaries. This mitigates the risk of advertising internal loopback addresses outside the administrative control of the provider network.
さらに、セクション9.1で定義された手順は、BGP CTファミリーが交渉された場合でも、境界内でBGP CTルートの意図しない伝播のリスクを軽減します。BGPのインポートおよびエクスポートポリシーは、境界として交換されるBGP CT Reachability情報を制御するために使用されます。これにより、プロバイダーネットワークの管理制御外に内部ループバックアドレスを広告するリスクが軽減されます。
This document does not change the underlying security issues inherent in the existing BGP protocol, such as those described in [RFC4271] and [RFC4272].
このドキュメントは、[RFC4271]や[RFC4272]に記載されているものなど、既存のBGPプロトコルに固有の根本的なセキュリティ問題を変更しません。
Additionally, BGP sessions SHOULD be protected using the TCP Authentication Option [RFC5925] and the Generalized TTL Security Mechanism [RFC5082].
さらに、BGPセッションは、TCP認証オプション[RFC5925]および一般化されたTTLセキュリティメカニズム[RFC5082]を使用して保護する必要があります。
Using a separate BGP family and new RT (Transport Class RT) minimizes the possibility of these routes mixing with service routes.
別のBGPファミリと新しいRT（トランスポートクラスRT）を使用すると、これらのルートがサービスルートと混合される可能性が最小限に抑えられます。
If redistributing between SAFI 76 and SAFI 4 routes for AFIs 1 or 2, there is a possibility of SAFI 4 routes mixing with SAFI 1 service routes. To avoid such scenarios, it is RECOMMENDED that implementations support keeping SAFI 76 and SAFI 4 transport routes in separate transport RIBs, distinct from service RIB that contain SAFI 1 service routes.
AFI 1または2のSAFI 76とSAFI 4ルート間を再配布する場合、SAFI 4ルートとSAFI 1サービスルートと混合する可能性があります。このようなシナリオを回避するには、実装がSAFI 76とSAFI 4の輸送ルートを、SAFI 1のサービスルートを含むサービスリブとは異なる個別の輸送リブの輸送ルートを維持することをサポートすることをお勧めします。
BGP CT routes distribute label binding using [RFC8277] for the MPLS data plane; hence, its security considerations apply.
BGP CTルートは、MPLSデータプレーンの[RFC8277]を使用してラベルバインディングを配布します。したがって、そのセキュリティ上の考慮事項が適用されます。
BGP CT routes distribute SRv6 SIDs for SRv6 data planes; hence, the security considerations of Section 9.3 of [RFC9252] apply. Moreover, the SRv6 SID Transposition Scheme is disabled in BGP CT, as described in Section 7.13, to mitigate the risk of misinterpreting transposed SRv6 SID information as an MPLS label.
BGP CTルートは、SRV6データプレーンのSRV6 SIDSを配布します。したがって、[RFC9252]のセクション9.3のセキュリティ上の考慮事項が適用されます。さらに、セクション7.13で説明されているように、SRV6 SID転置スキームはBGP CTで無効になっています。
As [RFC4272] discusses, BGP is vulnerable to traffic-diversion attacks. This SAFI route adds a new means by which an attacker could cause the traffic to be diverted from its normal path. Potential consequences include "hijacking" of traffic (insertion of an undesired node in the path, which allows for inspection or modification of traffic, or avoidance of security controls) or denial of service (directing traffic to a node that doesn't desire to receive it).
[RFC4272]が議論するように、BGPは交通散乱攻撃に対して脆弱です。このSAFIルートは、攻撃者がトラフィックを通常のパスから転用する可能性がある新しい手段を追加します。潜在的な結果には、トラフィックの「ハイジャック」（パスに望ましくないノードの挿入、トラフィックの検査または変更、またはセキュリティ制御の回避を可能にする）またはサービス拒否（それを受け取りたくないノードにトラフィックを向ける）が含まれます。
In order to mitigate the risk of the diversion of traffic from its intended destination, BGPsec solutions ([RFC8205] and Origin Validation [RFC8210][RFC6811]) may be extended in future to work for non-Internet SAFIs (SAFIs other than 1).
意図した目的地からのトラフィックの転換のリスクを軽減するために、BGPSECソリューション（[RFC8205]および起源の検証[RFC8210] [RFC6811]）を将来拡張して、非インターネットSAFIS（1以外のSAFIS）に拡張することができます。
The restriction of the applicability of the BGP CT SAFI 76 to its intended well-defined scope and utilizing [RFC8212] limits the likelihood of traffic diversions.
BGP CT SAFI 76の適切に定義された範囲への適用性の制限と[RFC8212]を利用することで、交通迂回の可能性が制限されます。
[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>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>.
[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>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[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>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<https://www.rfc-editor.org/info/rfc4659>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[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>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC8212] Mauch, J., Snijders, J., and G. Hankins, "Default External
BGP (EBGP) Route Propagation Behavior without Policies",
RFC 8212, DOI 10.17487/RFC8212, July 2017,
<https://www.rfc-editor.org/info/rfc8212>.
[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>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in
BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
<https://www.rfc-editor.org/info/rfc9830>.
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[BGP-CT-SRv6]
Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP CT -
Adaptation to SRv6 dataplane", Work in Progress, Internet-
Draft, draft-ietf-idr-bgp-ct-srv6-07, 22 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ct-srv6-07>.
[BGP-FWD-RR]
Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP
Route Reflector with Next Hop Self", Work in Progress,
Internet-Draft, draft-ietf-idr-bgp-fwd-rr-04, 22 August
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
idr-bgp-fwd-rr-04>.
[BGP-LU-EPE]
Gredler, H., Ed., Vairavakkalai, K., Ed., R, C.,
Rajagopalan, B., Aries, E., and L. Fang, "Egress Peer
Engineering using BGP-LU", Work in Progress, Internet-
Draft, draft-gredler-idr-bgplu-epe-16, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-gredler-idr-
bgplu-epe-16>.
[FLOWSPEC-REDIR-IP]
Haas, J., Henderickx, W., and A. Simpson, "BGP Flow-Spec
Redirect-to-IP Action", Work in Progress, Internet-Draft,
draft-ietf-idr-flowspec-redirect-ip-04, 2 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
flowspec-redirect-ip-04>.
[INTAREA-TUNNELS]
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-15, 9 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-15>.
[Intent-Routing-Color]
Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L.
Jalil, "Problem statement for Inter-domain Intent-aware
Routing using Color", Work in Progress, Internet-Draft,
draft-hr-spring-intentaware-routing-using-color-04, 31
January 2025, <https://datatracker.ietf.org/doc/html/
draft-hr-spring-intentaware-routing-using-color-04>.
[MNH] Vairavakkalai, K., Ed., Jeganathan, J. M., Nanduri, M.,
and A. R. Lingala, "BGP MultiNexthop Attribute", Work in
Progress, Internet-Draft, draft-ietf-idr-multinexthop-
attribute-04, 25 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
multinexthop-attribute-04>.
[MPLS-NS] Vairavakkalai, K., Ed., Jeganathan, J. M., Ramadenu, P.,
and I. Means, "BGP Signaled MPLS Namespaces", Work in
Progress, Internet-Draft, draft-kaliraj-bess-bgp-mpls-
namespaces-01, 21 August 2025,
<https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-
bgp-mpls-namespaces-01>.
[PACKING-TEST]
"update-packing-test-results.txt", 1a75d4d, 25 June 2023,
<https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-
ct/blob/main/update-packing-test-results.txt>.
[PCEP-RSVP-COLOR]
Rajagopalan, B., Beeram, V. P., Peng, S., Koldychev, M.,
and G. S. Mishra, "Path Computation Element Protocol
(PCEP) Extension for Color", Work in Progress, Internet-
Draft, draft-ietf-pce-pcep-color-12, 26 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-color-12>.
[PCEP-SRPOLICY]
Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and H. Bidgoli, "Path Computation Element
Communication Protocol (PCEP) Extensions for Segment
Routing (SR) Policy Candidate Paths", Work in Progress,
Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-
27, 4 April 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-segment-routing-policy-cp-27>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/info/rfc8210>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, <https://www.rfc-editor.org/info/rfc9315>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
It may be desirable to allow a CE device to indicate in the data packet it sends what treatment it desires (the Intent) when the packet is forwarded within the provider network.
CEデバイスがデータパケットで、パケットがプロバイダーネットワーク内で転送されたときに必要な（意図）を送信するデータパケットを示すことが望ましい場合があります。
Appendix A.10 of [MNH] describes some mechanisms that enable such signaling.
[MNH]の付録A.10は、そのようなシグナル伝達を可能にするいくつかのメカニズムについて説明しています。
Mechanisms described in [BGP-LU-EPE] also apply to the BGP CT family.
[BGP-Lu-EPE]で説明されているメカニズムもBGP CTファミリーに適用されます。
The Peer/32 or Peer/128 EPE route MAY be originated in the BGP CT family with the appropriate Mapping Community (e.g., transport-target:0:100), thus allowing an EPE path to the peer that satisfies the desired SLA.
PEER/32またはPEER/128 EPEルートは、適切なマッピングコミュニティ（たとえば、トランスポートターゲット：0：100）を備えたBGP CTファミリーで発信される可能性があり、したがって、望ましいSLAを満たすピアへのEPEパスを可能にします。
As described in Section 10 of [RFC4364], in an option C network, service routes (VPN-IPv4) are neither maintained nor distributed by the ASBRs. Transport routes are maintained in the ASBRs and propagated in BGP LU or BGP CT.
[RFC4364]のセクション10で説明されているように、オプションCネットワークでは、サービスルート（VPN-IPV4）はASBRによって維持も分布もありません。輸送ルートはASBRで維持され、BGP LuまたはBGP CTで伝播されます。
Section 8 illustrates how constructs of BGP CT work in an inter-AS option C deployment. The BGP CT constructs: AFI/SAFI 1/76, Transport Class, and Resolution Scheme are used in an inter-AS option C deployment.
セクション8では、BGP CTの構成要素がオプション間の展開でどのように機能するかを示しています。BGP CTコンストラクト：AFI/SAFI 1/76、トランスポートクラス、および解像度スキームは、Option c Deploymentで使用されます。
In intra-AS and inter-AS option A and option B scenarios, AFI/SAFI 1/76 may not be used, but the Transport Class and Resolution Scheme mechanisms are used to provide service mapping.
AS Intra-ASおよびASオプションAおよびオプションBシナリオでは、AFI/SAFI 1/76は使用されない場合がありますが、輸送クラスおよび解像度スキームメカニズムを使用してサービスマッピングを提供します。
This section illustrates how BGP CT constructs work in intra-AS and inter-AS option A and option B deployment scenarios.
このセクションでは、BGP CT構築がAS Inter-ASおよびAS Option AおよびOption B展開シナリオでどのように機能するかを示します。
[RR11]
|
+
[CE21]---[PE11]-------[P1]------[PE12]------[CE31]
: :
AS2 : ...AS1... : AS3
: :
203.0.113.21 ---- Traffic Direction ----> 203.0.113.31
Figure 14: BGP CT Intra-AS
図14：BGP CT Intra-AS
Figure 14 shows a provider network Autonomous System, AS1. It serves customers AS2 and AS3. Traffic direction being described is CE21 to CE31. CE31 may request a specific SLA (e.g., Gold for this traffic) when traversing this provider network.
図14は、プロバイダーネットワークの自律システムAS1を示しています。AS2およびAS3に顧客にサービスを提供します。説明されている交通方向は、CE21からCE31です。CE31は、このプロバイダーネットワークを横断するときに、特定のSLA（このトラフィックのゴールドなど）を要求する場合があります。
AS1 uses RSVP-TE intra-domain tunnels between PE11 and PE12. And it uses LDP tunnels for best-effort traffic.
AS1は、PE11とPE12の間でRSVP-TEイントラドメイントンネルを使用します。また、最高のエフォルトトラフィックにLDPトンネルを使用しています。
The network has two TCs: Gold with TC ID 100 and Bronze with TC ID 200. These TCs are provisioned at the PEs. This creates the Resolution Schemes for these TCs at these PEs.
ネットワークには2つのTCSがあります。TCID100を備えた金とTC ID 200のブロンズ。これらのTCはPESでプロビジョニングされています。これにより、これらのPESでこれらのTCSの解像度スキームが作成されます。
The following tunnels exist for the Gold TC:
ゴールドTC用には、次のトンネルが存在します。
* PE11_to_PE12_gold - RSVP-TE tunnel
* PE11_TO_PE12_GOLD -RSVP -TEトンネル
* PE12_to_PE11_gold - RSVP-TE tunnel
* PE12_TO_PE11_GOLD -RSVP -TEトンネル
The following tunnels exist for Bronze TC:
ブロンズTCのためには、次のトンネルが存在します。
* PE11_to_PE12_bronze - RSVP-TE tunnel
* PE11_TO_PE12_BRONZE -RSVP -TEトンネル
* PE11_to_PE12_bronze - RSVP-TE tunnel
* PE11_TO_PE12_BRONZE -RSVP -TEトンネル
These tunnels are provisioned to belong to Transport Class 100 or 200.
これらのトンネルは、輸送クラス100または200に属するように提供されます。
Service nodes PE11 and PE12 negotiate service families (AFI/SAFI 1/128) on the BGP session with RR11. Service helper RR11 reflects service routes between the two PEs with the next hop unchanged. There are no tunnels for Transport Class 100 or 200 from RR11 to the PEs.
サービスノードPE11とPE12は、RR11とのBGPセッションでサービスファミリ（AFI/SAFI 1/128）を交渉します。サービスヘルパーRR11は、次のホップが変更されていない2つのPE間のサービスルートを反映しています。RR11からPESへの輸送クラス100または200のトンネルはありません。
Forwarding happens using service routes at service nodes PE11 and PE12. Routes received from CEs are not present in any other nodes' FIB in the provider network.
転送は、サービスノードPE11およびPE12でサービスルートを使用して行われます。CESから受け取ったルートは、プロバイダーネットワーク内の他のノードのFIBには存在しません。
CE31 advertises a route, for example, prefix 203.0.113.31 with the next hop set to itself to PE12. CE31 can attach a Mapping Community color:0:100 on this route to indicate its request for a Gold SLA. Or, PE12 can attach the same using locally configured policies.
CE31は、たとえば、次のホップがPE12に設定された状態で、プレフィックス203.0.113.31などのルートを宣伝しています。CE31は、このルートでマッピングコミュニティの色：0：100を添付して、ゴールドSLAの要求を示すことができます。または、PE12は、ローカルで構成されたポリシーを使用して同じものを添付できます。
Consider CE31 getting VPN service from PE12. The RD:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE12 with the next hop set to itself (192.0.2.12) and label V-L1 to RR11 with the Mapping Community color:0:100 attached. This AFI/SAFI 1/128 route reaches PE11 via RR11 with the next hop unchanged as PE12 and label V-L1. Now PE11 can resolve the PNH 192.0.2.12 using the PE11_to_PE12_gold RSVP TE LSP.
CE31がPE12からVPNサービスを取得することを検討してください。RD：203.0.113.31ルートは、次のホップセット（192.0.2.12）とマッピングコミュニティの色でV-L1にRR11にラベル付けされたAFI/SAFI 1/128でPE12によって読み取りされます。このAFI/SAFI 1/128ルートは、RR11を介してPE11に到達し、次のホップはPE12とラベルV-L1として変更されていません。これで、PE11はPE11_TO_PE12_GOLD RSVP TE LSPを使用してPNH 192.0.2.12を解決できます。
The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a next hop when resolved using the Resolution Scheme belonging to the Mapping Community color:0:100, points to a PE11_to_PE12_gold tunnel.
PE11 VRFのIP FIBには、マッピングコミュニティの色に属する解像度スキームを使用して解決された場合、次のホップで203.0.113.31のルートがあります：0：100、PE11_TO_PE12_GOLDトンネルを指します。
BGP CT AFI/SAFI 1/76 is not used in this intra-AS deployment. But the Transport Class and Resolution Scheme constructs are used to preserve end-to-end SLA.
BGP CT AFI/SAFI 1/76は、この展開内では使用されていません。ただし、輸送クラスおよび解像度スキーム構造は、エンドツーエンドのSLAを保存するために使用されます。
[RR11] [RR21]
| |
+ +
[CE31]---[PE11]---[P1]---[ASBR11]---[ASBR21]---[P2]---[PE21]---[CE41]
: : :
AS3 : ..AS1.. : ..AS2.. : AS4
: : :
203.0.113.31 -------Traffic Direction------> 203.0.113.41
Figure 15: BGP CT Inter-AS option A
図15：BGP CT Inter-ASオプションa
This example in Figure 15 shows two provider network Autonomous systems AS1, AS2. They serve L3VPN customers AS3, AS4 respectively. The ASBRs ASBR11 and ASBR21 have IP VRFs connected directly. The inter-AS link is IP enabled with no MPLS forwarding.
図15のこの例は、2つのプロバイダーネットワーク自律システムAS1、AS2を示しています。それらは、それぞれL3VPNの顧客AS3、AS4にサービスを提供しています。ASBRS ASBR11およびASBR21には、IP VRFが直接接続されています。Inter-ASリンクは、MPLS転送なしで有効になっています。
Traffic direction being described is CE31 to CE41. CE41 may request a specific SLA (e.g., Gold for this traffic), when traversing these provider core networks.
説明されている交通方向は、CE31からCE41です。CE41は、これらのプロバイダーコアネットワークを横断するときに、特定のSLA（このトラフィックのための金など）を要求する場合があります。
AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. And LDP tunnels for best-effort traffic. AS2 uses SRTE intra-domain tunnels between ASBR21 and PE21, and L-ISIS for best-effort tunnels.
AS1は、PE11とASBR11の間でRSVP-TEイントラドメイントンネルを使用します。最良のエフォルトトラフィックのためのLDPトンネル。AS2は、ASBR21とPE21の間にSRTEイントラドメイントンネルを使用し、Best-EffortトンネルにL-ISISを使用します。
The networks have two TCs: Gold with TC ID 100, Bronze with TC ID 200. These TCs are provisioned at the PEs and ASBRs. This creates the Resolution Schemes for these TCs at these PEs and ASBRs.
ネットワークには2つのTCSがあります。TCID100を備えた金、TC ID 200のブロンズ。これらのTCはPESおよびASBRSでプロビジョニングされます。これにより、これらのPEおよびASBRでこれらのTCSの解像度スキームが作成されます。
Following tunnels exist for Gold TC.
ゴールドTCには次のトンネルが存在します。
* PE11_to_ASBR11_gold - RSVP-TE tunnel
* PE11_TO_ASBR11_GOLD -RSVP -TEトンネル
* ASBR11_to_PE11_gold - RSVP-TE tunnel
* ASBR11_TO_PE11_GOLD -RSVP -TEトンネル
* PE21_to_ASBR21_gold - SRTE tunnel
* PE21_TO_ASBR21_GOLD -SRTEトンネル
* ASBR21_to_PE21_gold - SRTE tunnel
* ASBR21_TO_PE21_GOLD -SRTEトンネル
Following tunnels exist for Bronze TC.
ブロンズTCには次のトンネルが存在します。
* PE11_to_ASBR11_bronze - RSVP-TE tunnel
* PE11_TO_ASBR11_BRONZE -RSVP -TEトンネル
* ASBR11_to_PE11_bronze - RSVP-TE tunnel
* ASBR11_TO_PE11_BRONZE -RSVP -TEトンネル
* PE21_to_ASBR21_bronze - SRTE tunnel
* PE21_TO_ASBR21_BRONZE -SRTEトンネル
* ASBR21_to_PE21_bronze - SRTE tunnel
* ASBR21_TO_PE21_BRONZE -SRTEトンネル
These tunnels are provisioned to belong to TC 100 or 200.
これらのトンネルは、TC 100または200に属するように提供されます。
Service nodes PE11, ASBR11 negotiate service family (AFI/SAFI 1/128) on the BGP session with RR11. Service helper RR11 reflects service routes between the PE11 and ASBR11 with next hop unchanged.
サービスノードPE11、ASBR11は、RR11とのBGPセッションでサービスファミリー（AFI/SAFI 1/128）をネゴシエートします。サービスヘルパーRR11は、PE11とASBR11の間のサービスルートを反映しており、次のホップは変更されていません。
Similarly, in AS2 PE21, ASBR21 negotiate service family (AFI/SAFI 1/128) on the BGP session with RR21, which reflects service routes between the PE21 and ASBR21 with next hop unchanged.
同様に、AS2 PE21では、ASBR21はRR21とのBGPセッションでサービスファミリー（AFI/SAFI 1/128）を交渉します。これは、PE21とASBR21の間のサービスルートを、次のホップが変化しないことを反映しています。
CE41 advertises a route for example prefix 203.0.113.41 with next hop self to PE21 VRF. CE41 can attach a Mapping Community color:0:100 on this route, to indicate its request for Gold SLA. Or, PE21 can attach the same using locally configured policies.
CE41は、次のホップセルフからPE21 VRFを使用して、プレフィックス203.0.113.41などのルートを宣伝しています。CE41は、このルートでマッピングコミュニティの色：0：100を添付して、ゴールドSLAの要求を示すことができます。または、PE21は、ローカルで構成されたポリシーを使用して同じものを添付できます。
Consider, CE41 is getting VPN service from PE21. The RD:203.0.113.41 route is readvertised in AFI/SAFI 1/128 by PE21 with next hop self (203.0.113.21) and label V-L1 to RR21 with the Mapping Community color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via RR21 with the next hop unchanged as PE21 and label V-L1. Now ASBR21 can resolve the PNH 203.0.113.21 using ASBR21_to_PE21_gold SRTE LSP.
CE41はPE21からVPNサービスを取得していると考えてください。RD：203.0.113.41ルートは、次のホップセルフ（203.0.113.21）を備えたPE21によってAFI/SAFI 1/128で読み取りされ、マッピングコミュニティの色でV-L1からRR21にラベル：0：100が添付されています。このAFI/SAFI 1/128ルートは、RR21を介してASBR21に到達し、次のホップはPE21とラベルV-L1として変更されていません。ASBR21は、ASBR21_TO_PE21_GOLD SRTE LSPを使用してPNH 203.0.113.21を解決できます。
The IP FIB at ASBR21 VRF will have a route for 203.0.113.41 with a next hop resolved using Resolution Scheme associated with mapping community color:0:100, pointing to ASBR21_to_PE21_gold tunnel.
ASBR21 VRFのIP FIBには、203.0.113.41のルートがあり、マッピングコミュニティの色：0：100、ASBR21_TO_PE21_GOLD TUNNENを指す解像度スキームを使用して次のホップが解決されます。
This route is readvertised with the next hop set to itself by ASBR21 to ASBR11 on a BGP session in the VRF. The single-hop EBGP session endpoints are interface addresses. ASBR21 and ASBR11 act like a CE to each other. The previously mentioned process repeats in AS1 until the route reaches PE11 and resolves over the PE11_to_ASBR11_gold RSVP TE tunnel.
このルートは、VRFのBGPセッションでASBR21からASBR11に次のホップセットで読み取りされます。シングルホップEBGPセッションのエンドポイントは、インターフェイスアドレスです。ASBR21とASBR11は、互いにCEのように機能します。前述のプロセスは、ルートがPE11に到達し、PE11_TO_ASBR11_GOLD RSVP TEトンネルで解決するまでAS1で繰り返されます。
Traffic traverses as an unlabeled IP packet on the following legs: CE31-PE11, ASBR11-ASBR21, PE21-CE41. And it uses MPLS forwarding inside the AS1 and AS2 core.
トラフィックは、次の脚の非標識IPパケットとして横断します：CE31-PE11、ASBR11-ASBR21、PE21-CE41。また、AS1およびAS2コア内のMPLS転送を使用します。
BGP CT AFI/SAFI 1/76 is not used in this inter-AS option B deployment. But the Transport Class and Resolution Scheme constructs are used to preserve an end-to-end SLA.
BGP CT AFI/SAFI 1/76は、オプションBの展開では使用されていません。ただし、輸送クラスおよび解像度スキーム構造は、エンドツーエンドのSLAを保存するために使用されます。
[RR13] [RR23]
| |
+ +
[CE31]---[PE11]---[P1]---[ASBR12]---[ASBR21]---[P2]---[PE22]---[CE41]
: : :
AS3 : ..AS1.. : ..AS2.. : AS4
: : :
203.0.113.31 ---- Traffic Direction ----> 203.0.113.41
Figure 16: BGP CT Inter-AS option B
図16：BGP CT Inter-ASオプションb
Figure 16 shows two provider network Autonomous Systems: AS1 and AS2. They serve L3VPN customers AS3 and AS4, respectively. The ASBRs ASBR12 and ASBR21 don't have any IP VRFs. The inter-AS link is MPLS-forwarding enabled.
図16は、AS1とAS2の2つのプロバイダーネットワーク自律システムを示しています。それらは、それぞれL3VPNの顧客AS3とAS4にサービスを提供しています。ASBRS ASBR12およびASBR21にはIP VRFがありません。Inter-ASリンクはMPLS-Forwarding Enabadeです。
Traffic direction being described is CE31 to CE41. CE41 may request a specific SLA (e.g., Gold for this traffic) when traversing these provider core networks.
説明されている交通方向は、CE31からCE41です。CE41は、これらのプロバイダーコアネットワークを横断する際に、特定のSLA（このトラフィックの場合は金）を要求する場合があります。
AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR21 and LDP tunnels for best-effort traffic. AS2 uses SRTE intra-domain tunnels between ASBR21 and PE22 along with L-ISIS for best-effort tunnels.
AS1は、PE11とASBR21およびLDPトンネルの間にRSVP-TEイントラドメイントンネルを使用して、最高のエフォルトトラフィックを使用しています。AS2は、ASBR21とPE22の間のSRTEイントラドメイントンネルを使用し、最良のエフォルトトンネルにはL-ISISを使用します。
The networks have two TCs: Gold with TC ID 100 and Bronze with TC ID 200. These TCs are provisioned at the PEs and ASBRs. This creates the Resolution Schemes for these Transport Classes at these PEs and ASBRs.
ネットワークには2つのTCSがあります。TCID100を備えた金とTC ID 200のブロンズ。これらのTCはPESおよびASBRでプロビジョニングされます。これにより、これらのPESおよびASBRでこれらの輸送クラスの解像度スキームが作成されます。
The following tunnels exist for Gold TC:
ゴールドTC用に次のトンネルが存在します。
* PE11_to_ASBR12_gold - RSVP-TE tunnel
* PE11_TO_ASBR12_GOLD -RSVP -TEトンネル
* ASBR12_to_PE11_gold - RSVP-TE tunnel
* ASBR12_TO_PE11_GOLD -RSVP -TEトンネル
* PE22_to_ASBR21_gold - SRTE tunnel
* PE22_TO_ASBR21_GOLD -SRTEトンネル
* ASBR21_to_PE22_gold - SRTE tunnel
* ASBR21_TO_PE22_GOLD -SRTEトンネル
The following tunnels exist for Bronze TC:
ブロンズTCのためには、次のトンネルが存在します。
* PE11_to_ASBR12_bronze - RSVP-TE tunnel
* PE11_TO_ASBR12_BRONZE -RSVP -TEトンネル
* ASBR12_to_PE11_bronze - RSVP-TE tunnel
* ASBR12_TO_PE11_BRONZE -RSVP -TEトンネル
* PE22_to_ASBR21_bronze - SRTE tunnel
* PE22_TO_ASBR21_BRONZE -SRTEトンネル
* ASBR21_to_PE22_bronze - SRTE tunnel
* ASBR21_TO_PE22_BRONZE -SRTEトンネル
These tunnels are provisioned to belong to TC 100 or 200.
これらのトンネルは、TC 100または200に属するように提供されます。
Service nodes PE11 and ASBR12 negotiate service family (AFI/SAFI 1/128) on the BGP session with RR13. Service helper RR13 reflects service routes between the PE11 and ASBR12 with the next hop unchanged.
サービスノードPE11とASBR12は、RR13とのBGPセッションでサービスファミリー（AFI/SAFI 1/128）をネゴシエートします。サービスヘルパーRR13は、PE11とASBR12の間のサービスルートを反映し、次のホップは変更されていません。
Similarly, in AS2 PE22, ASBR21 negotiates service family (AFI/SAFI 1/128) on the BGP session with RR23, which reflects service routes between PE22 and ASBR21 with the next hop unchanged.
同様に、AS2 PE22では、ASBR21はRR23とのBGPセッションでサービスファミリー（AFI/SAFI 1/128）を交渉します。これは、PE22とASBR21の間のサービスルートを、次のホップが変化しないことを反映しています。
ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them and readvertise L3VPN routes with the next hop set to themselves, allocating new labels. The single-hop EBGP session endpoints are interface addresses.
ASBR21とASBR12は、それらの間でAFI/SAFI 1/128を交渉し、次のホップセットでL3VPNルートをReadVertiseで交渉し、新しいラベルを割り当てます。シングルホップEBGPセッションのエンドポイントは、インターフェイスアドレスです。
CE41 advertises a route, for example, prefix 203.0.113.41 with the next hop set to itself to PE22 VRF. CE41 can attach a Mapping Community color:0:100 on this route to indicate its request for the Gold SLA. Or, PE22 can attach the same using locally configured policies.
CE41は、たとえば、次のホップがPE22 VRFに設定された状態で、プレフィックス203.0.113.41などのルートを宣伝しています。CE41は、このルートでマッピングコミュニティの色：0：100を添付して、ゴールドSLAのリクエストを示すことができます。または、PE22は、ローカルで構成されたポリシーを使用して同じものを添付できます。
Consider CE41 getting VPN service from PE22. The RD:203.0.113.41 route is readvertised in AFI/SAFI 1/128 by PE22 with the next hop set to itself (192.0.2.22) and label V-L1 to RR23 with the Mapping Community color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via RR23 with the next hop unchanged as PE22 and label V-L1. Now ASBR21 can resolve the PNH 192.0.2.22 using ASBR21_to_PE22_gold SRTE LSP.
CE41がPE22からVPNサービスを取得することを検討してください。RD：203.0.113.41ルートは、AFI/SAFI 1/128でPE22によって読み取りされ、次のホップセット（192.0.2.22）、およびマッピングコミュニティの色でV-L1をRR23にラベル付けします。このAFI/SAFI 1/128ルートは、RR23を介してASBR21に到達し、次のホップはPE22とラベルV-L1として変更されていません。ASBR21は、ASBR21_TO_PE22_GOLD SRTE LSPを使用してPNH 192.0.2.22を解決できます。
Next, ASBR21 readvertises the RD:203.0.113.41 route with the next hop set to itself to ASBR12 with a newly allocated MPLS label V-L2. Forwarding for this label is installed to Swap V-L1, and Push labels for ASBR21_to_PE22_gold tunnel.
次に、ASBR21は、新しく割り当てられたMPLSラベルV-L2を使用して、次のホップがASBR12に設定されたRD：203.0.113.41ルートを読み取ります。このラベルの転送は、V-L1を交換し、ASBR21_TO_PE22_GOLDトンネルのラベルをプッシュするためにインストールされます。
ASBR12 further readvertises the RD:203.0.113.41 route via RR13 to PE11 with the next hop set to itself, 192.0.2.12. PE11 resolves the next hop 192.0.2.12 over PE11_to_ASBR12_gold RSVP TE tunnel.
ASBR12は、次のホップセット自体、192.0.2.12で、RR13を介してRR13を介してPE11を介してRD：203.0.113.41ルートをさらに読み取ります。PE11は、PE11_TO_ASBR12_GOLD RSVP TEトンネルを介して次のホップ192.0.2.12を解決します。
Traffic traverses as the IP packet on the following legs: CE31-PE11 and PE21-CE41. And it uses MPLS forwarding on the ASBR11-ASBR21 link and inside the AS1-AS2 core.
トラフィックは、次の脚のIPパケットとして横断します：CE31-PE11およびPE21-CE41。また、ASBR11-ASBR21リンクとAS1-AS2コア内でMPLS転送を使用します。
BGP CT AFI/SAFI 1/76 is not used in this inter-AS option B deployment. But the Transport Class and Resolution Scheme constructs are used to preserve an end-to-end SLA.
BGP CT AFI/SAFI 1/76は、オプションBの展開では使用されていません。ただし、輸送クラスおよび解像度スキーム構造は、エンドツーエンドのSLAを保存するために使用されます。
[RFC4364] is one of the key design patterns produced by the networking industry. It introduced virtualization and allowed sharing of resources in the service provider space with multiple tenant networks, providing isolated and secure Layer 3 VPN services. This design pattern has been reused since to provide other service layer virtualizations like Layer 2 virtualization (VPLS, L2VPN, EVPN), ISO virtualization, ATM virtualization, and Flowspec VPN.
[RFC4364]は、ネットワーク業界が生み出す重要な設計パターンの1つです。仮想化を導入し、複数のテナントネットワークを使用してサービスプロバイダースペースでリソースを共有し、孤立した安全なレイヤー3 VPNサービスを提供しました。この設計パターンは、レイヤー2仮想化（VPLS、L2VPN、EVPN）、ISO仮想化、ATM仮想化、FlowsPec VPNなどの他のサービスレイヤー仮想化を提供するために再利用されています。
It is to be noted that these services have different NLRI encodings. The L3VPN service family that binds the MPLS label to an IP prefix uses the encoding described in [RFC8277] and others define different NLRI encodings.
これらのサービスには異なるNLRIエンコーディングがあることに注意してください。MPLSラベルをIPプレフィックスに結合するL3VPNサービスファミリは、[RFC8277]で説明されているエンコードを使用し、その他は異なるNLRIエンコーディングを定義します。
BGP CT reuses the procedures described in [RFC4364] to slice a transport network into multiple transport planes that different service routes can bind to using color.
BGP CTは、[RFC4364]に記載されている手順を再利用して、異なるサービスルートが色の使用に結合できる複数の輸送機に輸送ネットワークをスライスします。
BGP CT reuses [RFC8277] because it precisely fits the purpose. That is, in an MPLS network, BGP CT needs to bind the MPLS label for transport endpoints, which are IPv4 or IPv6 endpoints, and disambiguate between multiple instances of those endpoints in multiple transport planes. Hence, use of the RD:IP_Prefix and carrying a Label for it as specified in [RFC8277] works well for this purpose.
BGP CTは[RFC8277]を再利用します。なぜなら、それは目的に正確に適合するからです。つまり、MPLSネットワークでは、BGP CTは、IPv4またはIPv6エンドポイントであるトランスポートエンドポイントのMPLSラベルをバインドし、複数のトランスポートプレーンのそれらのエンドポイントの複数のインスタンス間で微分する必要があります。したがって、RD：IP_Prefixの使用と[RFC8277]で指定されているように、そのラベルを携帯することは、この目的のためにうまく機能します。
Another advantage of using the precise encoding as defined in [RFC4364] and [RFC8277] is that it allows interoperation with BGP speakers that support SAFI 128 for AFIs 1 or 2. This can be useful during transition until all BGP speakers in the network support BGP CT.
[RFC4364]および[RFC8277]で定義されている正確なエンコードを使用するもう1つの利点は、AFI 1または2のSAFI 128をサポートするBGPスピーカーとの相互操作を可能にすることです。
In the future, if [RFC8277] evolves into a typed NLRI that does not carry Label in the NLRI, BGP CT will be compatible with that as well. In essence, BGP CT encoding is compatible with existing deployed technologies ([RFC4364] and [RFC8277]) and will adapt to any changes mechanisms from [RFC8277] undergo in future.
将来的には、[RFC8277]がNLRIでラベルを運ばないタイプ化されたNLRIに進化した場合、BGP CTも同様に互換性があります。本質的に、BGP CTエンコーディングは、既存の展開されたテクノロジー（[RFC4364]および[RFC8277]）と互換性があり、[RFC8277]からの変更メカニズムに将来的に適応します。
This approach leverages the benefits of time-tested design patterns proposed in [RFC4364] and [RFC8277]. Moreover, this approach greatly reduces operational training costs and protocol compatibility considerations as it complements and works well with existing protocol machinery: this problem does not need a brand new NLRI and procedures.
このアプローチは、[RFC4364]および[RFC8277]で提案されている実施された設計パターンの利点を活用しています。さらに、このアプローチは、既存のプロトコル機械を補完し、うまく機能するため、運用トレーニングコストとプロトコル互換性の考慮事項を大幅に削減します。この問題には、新しいNLRIと手順は必要ありません。
BGP CT design also avoids overloading the NLRI MPLS label field from [RFC8277] with information related to the non-MPLS data plane because it leads to backward-compatibility issues.
BGP CT Designは、[RFC8277]のNLRI MPLSラベルフィールドを、Non-MPLSデータプレーンに関連する情報を過負荷にすることも避けています。これは、後方互換性の問題につながるためです。
BGP CT carries Transport Class as an attribute. This means routes that don't share the same Transport Class cannot be packed into the same BGP UPDATE message. Update packing in BGP CT will be similar to family routes from [RFC8277] carrying attributes like communities or extended communities. Service families like AFI/SAFI 1/128 have considerably more scale than transport families like AFI/SAFI 1/4 or AFI/SAFI 1/76, which carry only loopbacks. Update packing mechanisms that scale for AFI/SAFI 1/128 routes will scale similarly for AFI/ SAFI 1/76 routes.
BGP CTは、トランスポートクラスを属性として運びます。これは、同じトランスポートクラスを共有しないルートを同じBGPアップデートメッセージに梱包できないことを意味します。BGP CTの更新梱包は、コミュニティや拡張コミュニティなどの属性を運ぶ[RFC8277]の家族経路に似ています。AFI/SAFI 1/128のようなサービスファミリは、ループバックのみを運ぶAFI/SAFI 1/4やAFI/SAFI 1/76のような輸送ファミリーよりもかなり多くのスケールを持っています。AFI/SAFI 1/128ルートのスケーリングの梱包メカニズムを更新すると、AFI/SAFI 1/76ルートの場合も同様にスケーリングされます。
Section 6.3.2.1 of [Intent-Routing-Color] suggests scaling numbers for a transport network where BGP CT can be deployed. Experiments were conducted with this scale to find the convergence time with BGP CT for those scaling numbers. Scenarios involving BGP CT carrying IPv4 and IPv6 endpoints with an MPLS label were tested. Tests with BGP CT IPv6 endpoints and SRv6 SID are planned.
[Intent-Routing-Color]のセクション6.3.2.1は、BGP CTを展開できる輸送ネットワークのスケーリング番号を提案しています。これらのスケーリング番号のBGP CTでの収束時間を見つけるために、このスケールで実験を実施しました。MPLSラベルを備えたIPv4およびIPv6エンドポイントを運ぶBGP CTを含むシナリオをテストしました。BGP CT IPv6エンドポイントとSRV6 SIDによるテストが計画されています。
Tests were conducted with a 1.9 million BGP CT route scale (387K endpoints in 5 TCs). Initial convergence time for all cases was less than 2 minutes, which compares favorably with user expectation for such a scale. This experiment proves that carrying Transport Class information as an attribute keeps BGP convergence within an acceptable range. Details of the experiment and test results are available in [PACKING-TEST].
テストは、190万bgp CTルートスケール（5 TCで387kのエンドポイント）で実施されました。すべてのケースの初期収束時間は2分未満であり、これはそのようなスケールに対するユーザーの期待と比較して比較されます。この実験は、輸送クラス情報を属性として運ぶことで、BGPの収束を許容範囲内に保持することを証明しています。実験結果とテスト結果の詳細は、[パッキングテスト]で入手できます。
Furthermore, even in today's BGP LU deployments, each egress node originates a BGP LU route for its loopback, with some attributes like community identifying the originating node or region and an AIGP attribute. These attributes may be unique per egress node; thus, they do not help with update packing in transport family routes.
さらに、今日のBGP LUの展開でさえ、各出口ノードは、そのループバックのBGP LUルートを発信し、コミュニティなどの属性が発生したノードまたは領域とAIGP属性を識別します。これらの属性は、出口ノードごとに一意である場合があります。したがって、彼らは輸送ファミリールートの梱包を更新するのに役立ちません。
This document considers the scaling scenario suggested in Section 6.3.2.1 of [Intent-Routing-Color] where 300K nodes exist in the network with 5 TCs.
このドキュメントでは、[インテントルーティング色]のセクション6.3.2.1で提案されているスケーリングシナリオを考慮します。ここでは、5つのTCを持つネットワークに300Kノードが存在します。
This may result in 1.5M transport layer routes and MPLS transit routes in all Border Nodes in the network, which may overwhelm the nodes' MPLS-forwarding resources.
これにより、ネットワーク内のすべての境界ノードで1.5mの輸送層ルートとMPLSトランジットルートが発生する可能性があり、これにより、ノードのMPLS-forwardingリソースが圧倒される場合があります。
Section 6.2 of [MPLS-NS] describes how MPLS Namespaces mechanism is used to scale such a network. This approach reduces the number of PNHs that are globally visible in the network, thus reducing forwarding resource usage network wide. Service route state is kept confined closer to network edge, and any churn is confined within the region containing the point of failure, which improves convergence also.
[MPLS-NS]のセクション6.2では、MPLSネームスペースのメカニズムがそのようなネットワークを拡大するためにどのように使用されるかについて説明します。このアプローチにより、ネットワーク内でグローバルに表示されるPNHの数が減り、リソース使用量が大きくなります。サービスルート状態はネットワークエッジの近くに限定されており、障害点を含む領域内にチャーンが限られているため、収束も改善されます。
The authors thank Jeff Haas, John Scudder, Susan Hares, Dongjie (Jimmy), Moses Nagarajah, Jeffrey (Zhaohui) Zhang, Joel Halpern, Jingrong Xie, Mohamed Boucadair, Greg Skinner, Simon Leinen, Navaneetha Krishnan, Ravi M R, Chandrasekar Ramachandran, Shradha Hegde, Colby Barth, Vishnu Pavan Beeram, Sunil Malali, William J Britto, R Shilpa, Ashish Kumar (FE), Sunil Kumar Rawat, Abhishek Chakraborty, Richard Roberts, Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Jim Uttaro, Luay Jalil, Keyur Patel, Ketan Talaulikar, Dhananjaya Rao, Swadesh Agarwal, Robert Raszuk, Ahmed Darwish, Aravind Srinivas Srinivasa Prabhakar, Moshiko Nayman, Chris Tripp, Gyan Mishra, Vijay Kestur, and Santosh Kolenchery for all the valuable discussions, constructive criticisms, and review comments.
著者は、ジェフ・ハース、ジョン・スカダー、スーザン・ハレス、ドンジー（ジミー）、モーゼス・ナガラジャ、ジェフリー（Zhaohui）Zhang、Joel Halpern、Jingrong Xie、Mohamed Boucadair、Greg Skinner、Simon Leinen、NavaNETHA KRISNAN、RAVINATHA KRISNAN、RAVINANA、RAVINATHAヘグデ、コルビー・バース、ヴィシュヌ・パバン・ビアラム、スニル・マラリ、ウィリアム・J・ブリット、R・シルパ、アシッシュ・クマール（FE）、スニル・クマール・ラワット、アビシェク・チャクラボルティ、リチャード・ロバーツ、クルツィシトフ・ザルコウィッツ、ジョン・エルケ、スリ・サンガリ、ヴァイ・ヴァイ・ヴァイ・ウタル・パタリケタン・タラリカー、ダナンジャヤ・ラオ、スワデシュ・アガルワル、ロバート・ラシュク、アーメド・ダーウィッシュ、アラヴィンド・スリニバス・スリニバサ・プラバカル、モシコ・ネイマン、クリス・トリップ、ギャン・ミシュラ、ヴィジェイ・ケストゥール、サントーシュの批評家のための批評家のための批評のために、
The decision to not reuse SAFI 128 and create a new address family to carry these transport routes was based on suggestion made by Richard Roberts and Krzysztof Szarkowicz.
SAFI 128を再利用しないという決定と、これらの輸送ルートを運ぶために新しい住所ファミリを作成する決定は、リチャードロバーツとクルツィシトフサルコウィッツの提案に基づいていました。
Thanks to John Scudder for showing us with example how the Figures can be enhanced using SVG format.
SVG形式を使用してフィギュアを強化する方法の例を示してくれたJohn Scudderに感謝します。
The following people contributed substantially to the content of this document and should be considered coauthors:
次の人々は、この文書の内容に大きく貢献し、共著者と見なされるべきです。
Reshma Das
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: dreshma@juniper.net
Israel Means
AT&T
2212 Avenida Mara
Chula Vista, California 91914
United States of America
Email: israel.means@att.com
Csaba Mate
KIFU, Hungarian NREN
Budapest
35 Vaci Street
1134
Hungary
Email: ietf@nop.hu
Deepak J Gowda
Extreme Networks
55 Commerce Valley Drive West, Suite 300
Thornhill, Toronto Ontario L3T 7V9
Canada
Email: dgowda@extremenetworks.com
We also acknowledge the contribution of the following individuals:
また、次の個人の貢献も認めます。
Balaji Rajagopalan
Juniper Networks, Inc.
Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road
Bangalore 560103
KA
India
Email: balajir@juniper.net
Rajesh M
Juniper Networks, Inc.
Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road
Bangalore 560103
KA
India
Email: mrajesh@juniper.net
Chaitanya Yadlapalli
AT&T
200 S Laurel Ave
Middletown, NJ 07748
United States of America
Email: cy098d@att.com
Mazen Khaddam
Cox Communications Inc.
Atlanta, GA
United States of America
Email: mazen.khaddam@cox.com
Rafal Jan Szarecki
Google
1160 N Mathilda Ave, Bldg 5
Sunnyvale, CA 94089
United States of America
Email: szarecki@google.com
Xiaohu Xu
China Mobile
Beijing
China
Email: xuxiaohu@cmss.chinamobile.com
Kaliraj Vairavakkalai (editor)
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: kaliraj@juniper.net
Natrajan Venkataraman (editor)
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: natv@juniper.net