Internet Engineering Task Force (IETF) D. Rao, Ed.
Request for Comments: 9871 S. Agrawal, Ed.
Category: Experimental Cisco Systems
ISSN: 2070-1721 November 2025
This document describes a BGP-based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR).
このドキュメントでは、マルチドメイン トランスポート ネットワーク全体でエンドツーエンドのインテントアウェア パスを確立するための BGP ベースのルーティング ソリューションについて説明します。トランスポート ネットワークは、複数のサービス プロバイダーと顧客のネットワーク ドメインにまたがることができます。BGP インテント認識パスを使用すると、特定のインテントを必要とするサービス ルートのトラフィック フローを制御できます。このソリューションは、BGP Color-Aware Routing (BGP CAR) と呼ばれます。
This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible Network Layer Reachability Information (NLRI) model for both SAFIs that allows multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV-based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types: Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for the MPLS label stack, SR-MPLS label index, and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). This solution also defines a new Local Color Mapping (LCM) Extended Community.
このドキュメントでは、BGP CAR ソリューションを使用してインテントアウェア ルーティングを可能にするルーティング フレームワークと BGP 拡張機能について説明します。このソリューションでは、IPv4 および IPv6 用の 2 つの新しい BGP SAFI (BGP CAR SAFI および BGP VPN CAR SAFI) を定義します。また、両方の SAFI の拡張可能なネットワーク層到達可能性情報 (NLRI) モデルも定義されており、これにより、さまざまな使用例に合わせて複数の NLRI タイプを定義できるようになります。NLRI の各タイプには、さまざまなプレフィックスごとの情報を効率的にエンコードするためのキー フィールドと TLV ベースの非キー フィールドが含まれています。この仕様では、カラー認識ルート NLRI と IP プレフィックス NLRI の 2 つの NLRI タイプを定義します。MPLS ラベル スタック、SR-MPLS ラベル インデックス、およびセグメント ルーティング オーバー IPv6 (SRv6) セグメント識別子 (SID) の非キー TLV タイプを定義します。このソリューションは、新しいローカル カラー マッピング (LCM) 拡張コミュニティも定義します。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書は Internet Standards Track 仕様ではありません。試験、実験実装、評価のために公開されています。
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.
この文書は、インターネット コミュニティ向けの実験プロトコルを定義します。このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9871.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9871 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
1.2. Illustration
1.3. Requirements Language
2. BGP CAR SAFI
2.1. Data Model
2.2. Extensible Encoding
2.3. BGP CAR Route Origination
2.4. BGP CAR Route Validation
2.5. BGP CAR Route Resolution
2.6. AIGP Metric Computation
2.7. Inherent Multipath Capability
2.8. BGP CAR Signaling Through Different Color Domains
2.9. Format and Encoding
2.9.1. BGP CAR SAFI NLRI Format
2.9.2. Type-Specific Non-Key TLV Format
2.9.3. Color-Aware Route (E, C) NLRI Type
2.9.4. IP Prefix (E) NLRI Type
2.9.5. Local Color Mapping (LCM) Extended Community
2.10. LCM-EC and BGP Color-EC Usage
2.11. Error Handling
3. Service Route Automated Steering on Color-Aware Paths
4. Filtering
5. Scaling
5.1. Ultra-Scale Reference Topology
5.2. Deployment Model
5.2.1. Flat
5.2.2. Hierarchical Design with Next-Hop-Self at Ingress
Domain BR
5.2.3. Hierarchical Design with Next-Hop-Unchanged at Ingress
Domain BR
5.3. Scale Analysis
5.4. Anycast SID
5.4.1. Anycast SID for Transit Inter-Domain Nodes
5.4.2. Anycast SID for Transport Color Endpoints
6. Routing Convergence
7. CAR SRv6
7.1. Overview
7.1.1. Routed Service SID
7.1.2. Non-Routed Service SID
7.2. Deployment Options for CAR SRv6 Locator Reachability
Distribution and Forwarding
7.2.1. Hop-by-Hop IPv6 Forwarding for BGP SRv6 Prefixes
7.2.2. Encapsulation Between BRs for BGP SRv6 Prefixes
7.3. Operational Benefits of Using CAR SAFI for SRv6 Locator
Prefix Distribution
8. CAR IP Prefix Route
9. VPN CAR
9.1. Format and Encoding
9.1.1. VPN CAR (E, C) NLRI Type
9.1.2. VPN CAR IP Prefix NLRI Type
10. IANA Considerations
10.1. BGP CAR SAFIs
10.2. "BGP CAR NLRI Types" Registry
10.3. "BGP CAR NLRI TLV" Registry
10.4. Guidance for Designated Experts
10.4.1. Additional Evaluation Criteria for the "BGP CAR NLRI
Types" Registry
10.4.2. Additional Evaluation Criteria for the "BGP CAR NLRI
TLV" Registry
10.5. "Border Gateway Protocol (BGP) Extended Communities"
Registry
11. Manageability and Operational Considerations
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Illustrations of Service Steering
A.1. E2E BGP Transport CAR Intent Realized Using IGP Flexible
Algorithm
A.2. E2E BGP Transport CAR Intent Realized Using SR Policy
A.3. BGP Transport CAR Intent Realized in a Section of the
Network
A.3.1. Provide Intent for Service Flows Only in Core Domain
Running IS-IS Flexible Algorithm
A.3.2. Provide Intent for Service Flows Only in Core Domain
over TE Tunnel Mesh
A.4. Transit Network Domains That Do Not Support CAR
A.5. Resource Avoidance Using BGP CAR and IGP Flexible Algorithm
A.6. Per-Flow Steering over CAR Routes
A.7. Advertising BGP CAR Routes for Shared IP Addresses
Appendix B. Color Mapping Illustrations
B.1. Single Color Domain Containing Network Domains with N:N
Color Distribution
B.2. Single Color Domain Containing Network Domains with N:M
Color Distribution
B.3. Multiple Color Domains
Appendix C. CAR SRv6 Illustrations
C.1. BGP CAR SRv6 Locator Reachability Hop-by-Hop Distribution
C.2. BGP CAR SRv6 Locator Reachability Distribution with
Encapsulation
C.3. BGP CAR (E, C) Route Distribution for Steering Non-Routed
Service SID
Appendix D. CAR SAFI NLRI Update Packing Efficiency Calculation
Acknowledgements
Contributors
Authors' Addresses
BGP Color-Aware Routing (CAR) is a BGP-based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. BGP CAR distributes distinct routes to a destination network endpoint, such as a Provider Edge (PE) router, for different intents or colors. Color is a non-zero 32-bit integer value associated with a network intent (such as low cost, low delay, avoid some resources, 5G network slice, etc.) as defined in Section 2.1 of [RFC9256].
BGP カラー認識ルーティング (CAR) は、マルチドメイン サービス プロバイダーのトランスポート ネットワーク全体にエンドツーエンドのインテント認識パスを確立するための BGP ベースのルーティング ソリューションです。BGP CAR は、さまざまなインテントまたはカラーに応じて、プロバイダー エッジ (PE) ルーターなどの宛先ネットワーク エンドポイントに個別のルートを配布します。カラーは、[RFC9256] のセクション 2.1 で定義されているネットワークの意図 (低コスト、低遅延、一部のリソースの回避、5G ネットワーク スライスなど) に関連付けられたゼロ以外の 32 ビット整数値です。
BGP CAR fulfills the transport and VPN problem statement and the requirements described in [INTENT-AWARE].
BGP CAR は、トランスポートと VPN の問題ステートメントと、[INTENT-AWARE] で説明されている要件を満たします。
For this purpose, this document specifies two new BGP SAFIs, called BGP CAR SAFI (83) and VPN CAR SAFI (84), that carry infrastructure routes to set up the transport paths. Both CAR SAFI and VPN CAR SAFI apply to IPv4 Unicast and IPv6 Unicast AFIs (AFI 1 and AFI 2). The use of these SAFIs with other AFIs are outside the scope of this document.
この目的のために、この文書では、トランスポート パスを設定するためのインフラストラクチャ ルートを伝送する、BGP CAR SAFI (83) および VPN CAR SAFI (84) と呼ばれる 2 つの新しい BGP SAFI を指定します。CAR SAFI と VPN CAR SAFI は両方とも、IPv4 ユニキャストおよび IPv6 ユニキャスト AFI (AFI 1 および AFI 2) に適用されます。これらの SAFI を他の AFI と組み合わせて使用することは、この文書の範囲外です。
BGP CAR SAFI can be enabled on transport devices in a provider network (underlay) to set up color-aware transport/infrastructure paths across provider networks. The multi-domain transport network may comprise of multiple BGP Autonomous Systems (ASes) as well as multiple IGP domains within a single BGP AS. BGP CAR SAFI can also be enabled within a VPN Routing and Forwarding (VRF) on a PE router towards a peering Customer Edge (CE) router, and on devices within a customer network. VPN CAR SAFI is used for the distribution of intent-aware routes from different customers received on a PE router across the provider networks, maintaining the separation of the customer address spaces that may overlap. The BGP CAR solution thus enables intent-aware transport paths to be set up across a multi-domain network that can span customer and provider network domains.
BGP CAR SAFI をプロバイダー ネットワーク (アンダーレイ) のトランスポート デバイスで有効にして、プロバイダー ネットワーク全体にカラー対応トランスポート/インフラストラクチャ パスを設定できます。マルチドメイン トランスポート ネットワークは、複数の BGP 自律システム (AS) と、単一の BGP AS 内の複数の IGP ドメインで構成される場合があります。BGP CAR SAFI は、ピアリング カスタマー エッジ（CE）ルータに向かう PE ルータ上の VPN ルーティングおよび転送（VRF）内、および顧客ネットワーク内のデバイス上でも有効にすることができます。VPN CAR SAFI は、PE ルーターで受信したさまざまな顧客からのインテントアウェア ルートをプロバイダー ネットワーク全体に分散するために使用され、重複する可能性のある顧客のアドレス スペースの分離を維持します。したがって、BGP CAR ソリューションにより、顧客とプロバイダーのネットワーク ドメインにまたがるマルチドメイン ネットワーク全体にインテントアウェア トランスポート パスを設定できるようになります。
This document also defines two BGP CAR route types for this purpose.
このドキュメントでは、この目的のために 2 つの BGP CAR ルート タイプも定義します。
The BGP CAR Type-1 NLRI (E, C) enables the generation and distribution of multiple color-aware routes to the same destination IP prefix for different colors. This case arises from situations where a transport node such as a PE has a common IP address (such as a loopback) to advertise for multiple intents. The operator intends to use the common IP address as both the BGP next hop for service routes and as the transport endpoint for the data plane path. Multiple routes are needed for this same address or prefix to set up a unique path for each intent. One example is setting up multiple Label Switched Paths (LSPs) for MPLS or Segment Routing over MPLS (SR-MPLS) to an egress PE, one per intent.
BGP CAR Type-1 NLRI (E、C) を使用すると、異なる色の同じ宛先 IP プレフィックスへの複数の色対応ルートの生成と配布が可能になります。このケースは、PE などのトランスポート ノードが複数のインテントをアドバタイズするために共通の IP アドレス (ループバックなど) を持っている状況から発生します。オペレータは、共通 IP アドレスをサービス ルートの BGP ネクスト ホップとして、またデータ プレーン パスのトランスポート エンドポイントとして使用する予定です。インテントごとに一意のパスを設定するには、この同じアドレスまたはプレフィックスに対して複数のルートが必要です。1 つの例として、出力 PE への MPLS またはセグメント ルーティング オーバー MPLS (SR-MPLS) の複数のラベル スイッチ パス (LSP) をインテントごとに 1 つ設定します。
The BGP CAR Type-2 NLRI (IP Prefix or E) enables the distribution of multiple color-aware routes to a transport node for the case where the operator specifies a unique network IP address block for a given intent, and the transport node gets assigned a unique IP prefix or address for each intent. An example use case is Segment Routing over IPv6 (SRv6) per-intent locators.
BGP CAR タイプ 2 NLRI (IP プレフィックスまたは E) を使用すると、オペレータが特定のインテントに対して一意のネットワーク IP アドレス ブロックを指定し、トランスポート ノードにインテントごとに一意の IP プレフィックスまたはアドレスが割り当てられる場合に、トランスポート ノードへの複数のカラー認識ルートの配布が可能になります。ユースケースの例は、IPv6 上のセグメント ルーティング (SRv6) のインテントごとのロケーターです。
These BGP CAR intent-aware paths are then used by an ingress node (such as a PE) to steer traffic flows for service routes that need the specific intents. Steering may be towards a destination for all or specific traffic flows.
これらの BGP CAR インテント認識パスは、特定のインテントを必要とするサービス ルートのトラフィック フローを制御するために、入力ノード (PE など) によって使用されます。ステアリングは、すべてのトラフィック フローまたは特定のトラフィック フローの目的地に向かう場合があります。
BGP CAR adheres to the flat routing model of BGP for IP routing (BGP-IP) [RFC4271] or BGP Labeled Unicast (BGP-LU) (SAFI 4 in [RFC8277]), and extends it to support intent awareness, thereby providing a consistent operational experience with those widely deployed transport routing technologies.
BGP CAR は、BGP for IP ルーティング (BGP-IP) [RFC4271] または BGP ラベル付きユニキャスト (BGP-LU) ([RFC8277] の SAFI 4) のフラット ルーティング モデルに準拠し、それを拡張してインテント認識をサポートすることで、広く導入されているトランスポート ルーティング テクノロジで一貫した運用エクスペリエンスを提供します。
Intent (in routing):
インテント (ルーティング内):
Any behaviors to influence routing or path selection, including any combination of the following behaviors:
ルーティングまたはパスの選択に影響を与える動作。次の動作の組み合わせが含まれます。
a. Topology path selection (e.g., minimize metric or avoid resource)
a. トポロジ パスの選択 (例: メトリックを最小化する、またはリソースを回避する)
b. Network Function Virtualization (NFV) service insertion (e.g., service chain steering)
b. ネットワーク機能仮想化 (NFV) サービスの挿入 (サービス チェーン ステアリングなど)
c. Per-hop behavior (e.g., a 5G slice)
c. ホップごとの動作 (5G スライスなど)
This is a more specific concept with respect to routing beyond best-effort, compared to intent as a declarative abstraction in [RFC9315].
これは、[RFC9315] の宣言的抽象化としてのインテントと比較して、ベストエフォートを超えるルーティングに関してより具体的な概念です。
Color:
色：
A non-zero 32-bit integer value associated with an intent (e.g., low cost, low delay, or avoid some resources) as defined in Section 2.1 of [RFC9256]. Color assignment is managed by the operator.
[RFC9256] のセクション 2.1 で定義されている、インテント (低コスト、低遅延、または一部のリソースの回避など) に関連付けられたゼロ以外の 32 ビット整数値。色の割り当てはオペレータによって管理されます。
Colored service route:
色付きの運行ルート:
An egress PE (e.g., E2) colors its BGP service (e.g., VPN) route (e.g., V/v) to indicate the intent that it requests for the traffic bound to V/v. The color is encoded as a BGP Color Extended Community [RFC9012], used as per [RFC9256], or represented by the locator part of SRv6 Service SID [RFC9252].
出口 PE (例: E2) は、BGP サービス (例: VPN) ルート (例: V/v) を色付けして、V/v にバインドされたトラフィックを要求する意図を示します。カラーは、BGP カラー拡張コミュニティ [RFC9012] としてエンコードされ、[RFC9256] に従って使用されるか、SRv6 サービス SID [RFC9252] のロケーター部分によって表されます。
Color-aware path to (E2, C):
(E2, C) への色認識パス:
A path to forward packets towards E2 that satisfies the intent associated with color C. Several technologies may provide a color-aware path to (E2, C), such as SR Policy [RFC9256], IGP Flexible Algorithm [RFC9350], and BGP CAR (as specified in this document).
カラー C に関連付けられた意図を満たす E2 に向けてパケットを転送するパス。SR ポリシー [RFC9256]、IGP フレキシブル アルゴリズム [RFC9350]、BGP CAR (この文書で指定されている) など、いくつかのテクノロジーが (E2, C) へのカラー認識パスを提供する場合があります。
Color-aware route (E2, C):
カラー認識ルート (E2、C):
A distributed or signaled route that builds a color-aware path to E2 for color C.
カラー C の E2 へのカラー認識パスを構築する分散ルートまたはシグナリング ルート。
Service route automated steering on color-aware path:
サービス ルートの色を認識したパスでの自動ステアリング:
An ingress PE (or ASBR) E1 automatically steers traffic for a C-colored service route V/v from E2 onto an (E2, C) color-aware path. If several such paths exist, a preference scheme is used to select the best path (for example, IGP Flexible Algorithm is preferred over SR Policy, and SR Policy is preferred over BGP CAR).
入力 PE (または ASBR) E1 は、C カラーのサービス ルート V/v のトラフィックを E2 から (E2, C) 色認識パスに自動的に誘導します。このようなパスが複数存在する場合、優先スキームを使用して最適なパスが選択されます（たとえば、IGP フレキシブル アルゴリズムが SR ポリシーより優先され、SR ポリシーが BGP CAR より優先されます）。
Color domain:
カラードメイン:
A set of nodes that share the same color-to-intent mapping, typically under single administration. This set can be organized into one or multiple network domains (IGP areas/instances within a single BGP AS, or multiple BGP ASes). Color-to-intent mapping on nodes is set by configuration. Color re-mapping and filtering may happen at color domain boundaries. Refer to [INTENT-AWARE].
同じ色とインテントのマッピングを共有するノードのセット。通常は単一の管理下にあります。このセットは、1 つまたは複数のネットワーク ドメイン (単一の BGP AS または複数の BGP AS 内の IGP エリア/インスタンス) に編成できます。ノード上の色とインテントのマッピングは構成によって設定されます。カラーの再マッピングとフィルタリングはカラー ドメインの境界で発生する場合があります。[インテントアウェア]を参照してください。
Resolution of a BGP CAR route (E, C):
BGP CAR ルートの解決 (E、C):
An inter-domain BGP CAR route (E, C) via N is resolved on an intra-domain color-aware path (N, C) where N is the next hop of the BGP CAR route.
N を経由するドメイン間 BGP CAR ルート (E、C) は、ドメイン内カラー認識パス (N、C) 上で解決されます。ここで、N は BGP CAR ルートのネクスト ホップです。
Resolution versus steering:
解像度とステアリング:
Consistent with the terminology used in the SR Policy document (Section 8 of [RFC9256]), in this document (service route) steering is used to describe the mapping of the traffic for a service route onto a BGP CAR path. In contrast, the term resolution is preserved for the mapping of an inter-domain BGP CAR route on an intra-domain color-aware path.
SR ポリシー文書 ([RFC9256] のセクション 8) で使用される用語と一致して、この文書 (サービス ルート) ステアリングは、サービス ルートのトラフィックの BGP CAR パスへのマッピングを記述するために使用されます。対照的に、解像度という用語は、ドメイン内カラー認識パス上のドメイン間 BGP CAR ルートのマッピングに対して保持されます。
Service steering:
サービスの運営:
Service route maps traffic to a BGP CAR path (or other color-aware path, e.g., SR Policy). If a color-aware path is not available, local policy may map to a color-unaware routing/TE path (e.g., BGP-LU, RSVP-TE, IGP/LDP). The service steering concept is agnostic to the transport technology used. Section 3 describes the specific service steering mechanisms leveraged for MPLS, SR-MPLS, and SRv6.
サービス ルートは、トラフィックを BGP CAR パス（または他の色認識パス、たとえば SR ポリシー）にマッピングします。カラー認識パスが利用できない場合、ローカル ポリシーはカラー非認識ルーティング/TE パス (BGP-LU、RSVP-TE、IGP/LDP など) にマッピングされる可能性があります。サービス ステアリングの概念は、使用されるトランスポート テクノロジに依存しません。セクション 3 では、MPLS、SR-MPLS、および SRv6 に利用される特定のサービス ステアリング メカニズムについて説明します。
Intra-domain resolution:
ドメイン内解決:
BGP CAR route maps to an intra-domain color-aware path (e.g., SR Policy, IGP Flexible Algorithm, BGP CAR) or a color-unaware routing/TE path (e.g., RSVP-TE, IGP/LDP, BGP-LU).
BGP CAR ルートは、ドメイン内のカラー認識パス (SR ポリシー、IGP フレキシブル アルゴリズム、BGP CAR など) またはカラー非認識ルーティング/TE パス (RSVP-TE、IGP/LDP、BGP-LU など) にマップします。
Transport network:
トランスポートネットワーク:
A network that comprises of multiple cooperating domains managed by one or more operators, and uses routing technologies such as IP, MPLS, and SR to forward packets for connectivity and other services. In an SR deployment, the transport network is within a trusted domain as per [RFC8402].
1 つ以上のオペレータによって管理される複数の連携ドメインで構成され、IP、MPLS、SR などのルーティング テクノロジを使用して接続やその他のサービス用のパケットを転送するネットワーク。SR 展開では、トランスポート ネットワークは [RFC8402] に従って信頼できるドメイン内にあります。
Transport layer:
トランスポート層:
Refers to an underlay network layer (e.g., MPLS LSPs between PEs) that gets used by an overlay or service layer (e.g., MPLS VPNs).
オーバーレイまたはサービス層 (MPLS VPN など) によって使用されるアンダーレイ ネットワーク層 (PE 間の MPLS LSP など) を指します。
Transport RR:
トランスポートRR:
A BGP Route Reflector (RR) used to distribute transport/underlay routes within a domain or across domains.
ドメイン内またはドメイン間でトランスポート/アンダーレイ ルートを分散するために使用される BGP ルート リフレクター (RR)。
Service RR:
サービスRR:
A BGP Route Reflector (RR) used to distribute service/overlay routes within a domain or across domains.
ドメイン内またはドメイン間でサービス/オーバーレイ ルートを配布するために使用される BGP ルート リフレクター (RR)。
Abbreviations:
略語:
ABR:
ABR:
Area Border Router
エリアボーダールーター
AFI:
AFI:
Address Family Identifier
アドレスファミリー識別子
AIGP:
AIGP:
Accumulated IGP Metric Attribute [RFC7311]
累積された IGP メトリック属性 [RFC7311]
ASBR:
ASBR:
Autonomous System Border Router
自律システム境界ルータ
BGP-LU:
BGP-LU:
BGP Labeled Unicast SAFI (SAFI value 4 as per [RFC8277])
BGP ラベル付きユニキャスト SAFI ([RFC8277] による SAFI 値 4)
BGP-IP:
BGP-IP:
BGP IPv4/IPv6 Unicast SAFI (SAFI value 1 as per [RFC4760] and [RFC4271])
BGP IPv4/IPv6 ユニキャスト SAFI ([RFC4760] および [RFC4271] による SAFI 値 1)
BR:
BR:
Border Router (either for an IGP area (an ABR) or a BGP autonomous system (an ASBR))
ボーダー ルーター (IGP エリア (ABR) または BGP 自律システム (ASBR) のいずれか用)
Color-EC:
カラーEC:
BGP Color Extended Community [RFC9012]
BGP カラー拡張コミュニティ [RFC9012]
E:
E:
Generic representation of a transport endpoint such as a PE, ABR, or ASBR
PE、ABR、ASBR などのトランスポート エンドポイントの汎用表現
LCM-EC:
LCM-EC:
BGP Local Color Mapping Extended Community
BGP ローカル カラー マッピング拡張コミュニティ
NLRI:
NLRI:
Network Layer Reachability Information [RFC4271]
ネットワーク層到達可能性情報 [RFC4271]
P node:
P ノード:
An intra-domain transport router
ドメイン内トランスポートルーター
RD:
RD:
Route Distinguisher
ルート識別子
RR:
RR:
Route Reflector
ルートリフレクター
T-RR:
T-RR:
Transport Route Reflector
輸送ルート反射板
S-RR:
S-RR:
Service Route Reflector
サービスルートリフレクター
SAFI:
サフィ:
Subsequent Address Family Identifier
後続のアドレスファミリー識別子
TEA:
TEA:
Tunnel Encapsulation Attribute [RFC9012]
トンネルカプセル化属性 [RFC9012]
V/v, W/w:
V/v、W/w:
Generic representations of a service route (indicating prefix/mask length), regardless of AFI/SAFI or actual NLRI encoding
AFI/SAFI または実際の NLRI エンコーディングに関係なく、サービス ルートの一般的な表現 (プレフィックス/マスクの長さを示す)
Here is a brief illustration of the salient properties of the BGP CAR solution.
ここでは、BGP CAR ソリューションの主要な特性を簡単に説明します。
+-------------+ +-------------+ +-------------+
| | | | | | V/v with C1
|----+ |------| |------| +----|/
| E1 | | | | | | E2 |\
|----+ | | | | +----| W/w with C2
| |------| |------| |
| Domain 1 | | Domain 2 | | Domain 3 |
+-------------+ +-------------+ +-------------+
Figure 1: BGP CAR Solution Illustration
図 1: BGP CAR ソリューションの図
All the nodes are part of an inter-domain network under a single authority and with a consistent color-to-intent mapping:
すべてのノードは、単一の権限の下にあるドメイン間ネットワークの一部であり、一貫した色からインテントへのマッピングが行われます。
* C1 is mapped to "low delay"
* C1 は「低遅延」にマッピングされます
- Flex-Algo 1 is mapped to "low delay", and hence to C1
- Flex-Algo 1 は「低遅延」にマッピングされているため、C1 にマッピングされています。
* C2 is mapped to "low delay and avoid resource R"
* C2 は「低遅延でリソース R を回避」にマップされます。
- Flex-Algo 2 is mapped to "low delay and avoid resource R", and hence to C2
- Flex-Algo 2 は「低遅延でリソース R を回避」するため、C2 にマッピングされます。
E1 receives two service routes from E2:
E1 は E2 から 2 つのサービス ルートを受信します。
* V/v with BGP Color-EC C1
* BGP Color-EC C1 を使用した V/v
* W/w with BGP Color-EC C2
* BGP Color-EC C2 との併用
E1 has the following color-aware paths:
E1 には次の色認識パスがあります。
* (E2, C1) provided by BGP CAR with the following per-domain support:
* (E2、C1) BGP CAR によって提供され、次のドメインごとのサポートが提供されます。
- Domain 1: over IGP FA1
- ドメイン 1: IGP FA1 経由
- Domain 2: over SR Policy bound to color C1
- ドメイン 2: カラー C1 にバインドされた SR ポリシー上
- Domain 3: over IGP FA1
- ドメイン 3: IGP FA1 経由
* (E2, C2) provided by SR Policy
* SR ポリシーによって提供される (E2、C2)
E1 automatically steers traffic for the received service routes as follows:
E1 は、受信したサービス ルートのトラフィックを次のように自動的に制御します。
* V/v via (E2, C1) provided by BGP CAR
* BGP CAR によって提供される (E2、C1) 経由の V/v
* W/w via (E2, C2) provided by SR Policy
* SR ポリシーによって提供される W/W via (E2、C2)
Illustrated properties:
図示されたプロパティ:
* Leverage of the BGP Color-EC
* BGP Color-EC の活用
- The service routes are colored with widely used BGP Color Extended Community [RFC9012] to request intent
- サービス ルートは、インテントをリクエストするために広く使用されている BGP Color Extended Community [RFC9012] で色分けされています。
* (E, C) automated steering
* (E、C) 自動ステアリング
- V/v and W/w are automatically steered on the appropriate color-aware path
- V/v と W/w は、適切な色認識パスに自動的に誘導されます。
* Seamless coexistence of BGP CAR and SR Policy
* BGP CAR と SR ポリシーのシームレスな共存
- V/v is steered on a color-aware path provided by BGP CAR
- V/v は、BGP CAR によって提供される色認識パス上でステアリングされます。
- W/w is steered on a color-aware path provided by SR Policy
- W/W は SR ポリシーによって提供される色認識パス上で操作されます
* Seamless interworking of BGP CAR and SR Policy
* BGP CAR と SR ポリシーのシームレスな相互作用
- V/v is steered on a BGP CAR path that is itself resolved within domain 2 onto an SR Policy bound to the color of V/v
- V/v は、ドメイン 2 内で V/v の色にバインドされた SR ポリシーに解決される BGP CAR パス上でステアリングされます。
Other properties:
その他のプロパティ:
* MPLS data plane: with 300k PEs and 5 colors, the BGP CAR solution ensures that no single node needs to support a data plane scaling in the order of Remote PE * C (Section 5). This would otherwise exceed the MPLS data plane.
* MPLS データ プレーン: 300k PE と 5 つのカラーを備えた BGP CAR ソリューションは、単一ノードがリモート PE * C のオーダーでデータ プレーン スケーリングをサポートする必要がないことを保証します (セクション 5)。そうしないと、これは MPLS データ プレーンを超えてしまいます。
* Control plane: a node should not install a (E, C) path if it's not participating in that color-aware path.
* コントロール プレーン: ノードは、色を認識するパスに参加していない場合、(E、C) パスをインストールすべきではありません。
* Incongruent color-intent mapping: the solution supports the signaling of a BGP CAR route across different color domains (Section 2.8).
* 不一致なカラー意図のマッピング: このソリューションは、異なるカラー ドメインにわたる BGP CAR ルートのシグナリングをサポートします (セクション 2.8)。
The key benefits of this model are:
このモデルの主な利点は次のとおりです。
* Leverage of the BGP Color-EC [RFC9012] to color service routes
* BGP Color-EC [RFC9012] を利用してサービス ルートをカラー化する
* The definition of the automated service steering: a C-colored service route V/v from E2 is steered onto a color-aware path (E2, C)
* 自動サービス ステアリングの定義: E2 からの C 色のサービス ルート V/v は、色を認識したパス (E2、C) にステアリングされます。
* The definition of the data model of a BGP CAR path: (E, C)
* BGP CAR パスのデータ モデルの定義: (E、C)
- Natural extension of BGP-IP/BGP-LU data model (E)
- BGP-IP/BGP-LU データモデルの自然拡張 (E)
- Consistent with SR Policy data model
- SRポリシーのデータモデルとの一貫性
* The definition of the recursive resolution of a BGP CAR route: a BGP CAR (E2, C) route via N is resolved onto the color-aware path (N, C), which may itself be provided by BGP CAR or via another color-aware routing solution (e.g., SR Policy, IGP Flexible Algorithm)
* BGP CAR ルートの再帰的解決の定義: N を介した BGP CAR (E2、C) ルートは、BGP CAR または別の色認識ルーティング ソリューション (例: SR ポリシー、IGP 柔軟なアルゴリズム) によって提供される色認識パス (N、C) 上に解決されます。
* Explicit definitions for multiple transport encapsulations (e.g., MPLS, SR, SRv6, IP)
* 複数のトランスポート カプセル化の明示的な定義 (MPLS、SR、SRv6、IP など)
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] で説明されているように解釈されます。
The BGP CAR data model is:
BGP CAR データ モデルは次のとおりです。
NLRI key:
NLRI キー:
Falls into two categories to accommodate the use cases described in the introduction:
はじめにで説明したユースケースに対応するために、次の 2 つのカテゴリに分類されます。
Type-1:
タイプ-1:
Key is IP Prefix and Color (E, C). Color in NLRI key distinguishes a color-aware route for a common IP prefix, one per intent. Color also indicates the intent associated with the route.
キーは IP プレフィックスとカラー (E、C) です。NLRI キーの色は、インテントごとに 1 つずつ、共通 IP プレフィックスの色認識ルートを区別します。色は、ルートに関連付けられた意図も示します。
Type-2:
タイプ-2:
Key is IP Prefix (E). The unique IP prefix assigned for an intent (i.e, IP Prefix == intent) distinguishes the color-aware route. Color is not needed in NLRI key as a distinguisher.
キーは IP プレフィックス (E) です。インテントに割り当てられた一意の IP プレフィックス (つまり、IP プレフィックス == インテント) により、色認識ルートが区別されます。NLRI キーでは識別子として色は必要ありません。
NLRI non-key encapsulation data:
NLRI 非キーカプセル化データ:
Data such as MPLS label stack, SR-MPLS label index, and SRv6 SID list associated with NLRI. Contained in TLVs as described in Section 2.9.2.
MPLS ラベル スタック、SR-MPLS ラベル インデックス、NLRI に関連付けられた SRv6 SID リストなどのデータ。セクション 2.9.2 で説明されているように、TLV に含まれます。
BGP next hop:
BGP ネクストホップ:
Next hop address associated with a particular NLRI key [RFC4760].
特定の NLRI キーに関連付けられたネクストホップ アドレス [RFC4760]。
AIGP metric [RFC7311]:
AIGP メトリック [RFC7311]:
Accumulates a metric value specific to color/ intent for a CAR route across multiple BGP hops.
複数の BGP ホップにわたる CAR ルートのカラー/インテントに固有のメトリック値を蓄積します。
Local Color Mapping Extended Community (LCM-EC):
ローカル カラー マッピング拡張コミュニティ (LCM-EC):
Optional non-zero 32-bit color value used to represent the intent associated with a CAR route:
CAR ルートに関連付けられたインテントを表すために使用される、オプションのゼロ以外の 32 ビット カラー値。
* when the CAR route propagates between different color domains.
* CAR ルートが異なるカラー ドメイン間で伝播する場合。
* when the CAR route has a unique IP prefix for an intent.
* CAR ルートにインテントの一意の IP プレフィックスがある場合。
BGP Color Extended Community (Color-EC) [RFC9012]:
BGP カラー拡張コミュニティ (Color-EC) [RFC9012]:
Optional non-zero 32-bit color value used to represent the intent associated with the BGP CAR next hop. It is used as per [RFC9256] for automated route resolution, when intent/color used for the next hop is different than the CAR route's intent/color.
BGP CAR ネクスト ホップに関連付けられたインテントを表すために使用される、オプションのゼロ以外の 32 ビット カラー値。これは、ネクストホップに使用されるインテント/カラーが CAR ルートのインテント/カラーと異なる場合に、自動ルート解決のために [RFC9256] に従って使用されます。
The sections below describe the data model in detail. The sections that describe the protocol processing for CAR SAFI generally apply consistently to both route types (for instance, any operation based on color). The examples use (E, C) for simplicity.
以下のセクションでは、データ モデルについて詳しく説明します。CAR SAFI のプロトコル処理について説明するセクションは、通常、両方のルート タイプ（たとえば、色に基づく操作）に一貫して適用されます。例では、簡単にするために (E、C) を使用します。
Extensible encoding is provided by:
拡張可能なエンコーディングは次によって提供されます。
NLRI Type field:
NLRI タイプフィールド:
This provides extensibility to add new NLRI formats for new route types.
これにより、新しいルート タイプに新しい NLRI 形式を追加する拡張性が提供されます。
NLRI (route) types other than Type-1 (E, C) and Type-2 (E) are outside the scope of this document.
Type-1 (E、C) および Type-2 (E) 以外の NLRI (ルート) タイプは、このドキュメントの範囲外です。
Key Length field:
キーの長さフィールド:
This specifies the key length. It allows new NLRI types to be handled opaquely, which permits transitivity of new route types through BGP speakers such as Route Reflectors (RRs).
キーの長さを指定します。これにより、新しい NLRI タイプを不透明に処理できるようになり、ルート リフレクタ (RR) などの BGP スピーカーを介した新しいルート タイプの推移性が可能になります。
TLV-based encoding of non-key part of NLRI:
NLRI の非キー部分の TLV ベースのエンコード:
This allows the inclusion of additional non-key fields for a prefix to support different types of transport simultaneously with efficient BGP update packing (Section 2.9).
これにより、プレフィックスに非キー フィールドを追加して、効率的な BGP アップデート パッキングと同時にさまざまなタイプのトランスポートをサポートできるようになります (セクション 2.9)。
AIGP attribute:
AIGP 属性:
This provides extensibility via TLVs, enabling definition of additional metric semantics for a color as needed for an intent.
これにより、TLV による拡張性が提供され、インテントの必要に応じて色の追加のメトリック セマンティクスを定義できるようになります。
A BGP CAR route may be originated locally (e.g., loopback) or through redistribution of an (E, C) color-aware path provided by another routing solution (e.g., SR Policy, IGP Flexible Algorithm, RSVP-TE, BGP-LU [RFC8277]).
BGP CAR ルートは、ローカル (ループバックなど) で発信されることも、別のルーティング ソリューション (SR ポリシー、IGP フレキシブル アルゴリズム、RSVP-TE、BGP-LU [RFC8277] など) によって提供される (E、C) カラー認識パスの再配布を通じて発信されることもあります。
A BGP CAR path (E, C) via next hop N with encapsulation T is valid if color-aware path (N, C) exists with encapsulation T available in data plane.
カプセル化 T を使用したネクスト ホップ N 経由の BGP CAR パス (E、C) は、データ プレーンで使用可能なカプセル化 T を持つカラー認識パス (N、C) が存在する場合に有効です。
A local policy may customize the validation process:
ローカル ポリシーは検証プロセスをカスタマイズできます。
* The color constraint in the first check may be relaxed. If N is reachable via alternate color(s) or in the default routing table, the route may be considered valid.
* 最初のチェックの色の制約は緩和される可能性があります。N が代替色を介して、またはデフォルトのルーティング テーブル内で到達可能な場合、ルートは有効であるとみなされる可能性があります。
* The data plane availability constraint of T may be relaxed to use an alternate encapsulation.
* T のデータ プレーン可用性の制約は、代替カプセル化を使用するために緩和される場合があります。
* A performance-measurement verification may be added to ensure that the intent associated with C is met (e.g., delay < bound).
* C に関連付けられた意図が満たされていることを確認するために、パフォーマンス測定の検証を追加できます (例: 遅延 < 限界)。
A path that is not valid MUST NOT be considered for BGP best path selection.
有効でないパスは、BGP の最適パスの選択に考慮されてはなりません (MUST NOT)。
A BGP color-aware route (E2, C1) with next hop N is automatically resolved over a color-aware route (N, C1) by default. The color-aware route (N, C1) is provided by color-aware mechanisms such as IGP Flexible Algorithm [RFC9350], SR Policy (Section 2.2 of [RFC9256]), or recursively by BGP CAR. When multiple producers of (N, C1) are available, the default preference is: IGP Flexible Algorithm, SR Policy, BGP CAR.
ネクストホップ N を持つ BGP カラー認識ルート (E2、C1) は、デフォルトでカラー認識ルート (N、C1) 上で自動的に解決されます。カラー認識ルート (N、C1) は、IGP フレキシブル アルゴリズム [RFC9350]、SR ポリシー ([RFC9256] のセクション 2.2) などのカラー認識メカニズムによって、または BGP CAR によって再帰的に提供されます。(N, C1) の複数のプロデューサーが使用可能な場合、デフォルトの優先設定は IGP 柔軟なアルゴリズム、SR ポリシー、BGP CAR です。
Local policy SHOULD provide additional control:
ローカル ポリシーは追加の制御を提供する必要があります。
* A BGP color-aware route (E2, C1) with next hop N may be resolved over a color-aware route (N, C2) (i.e., the local policy maps the resolution of C1 over a different color C2). Examples where such a resolution can occur are:
* ネクスト ホップ N を持つ BGP カラー認識ルート (E2、C1) は、カラー認識ルート (N、C2) 経由で解決できます (つまり、ローカル ポリシーは、C1 の解像度を異なるカラー C2 にマッピングします)。このような解決策が発生する可能性がある例は次のとおりです。
- In a domain where resource R is known to not be present, the inter-domain intent C1="low delay and avoid R" may be resolved over an intra-domain path of intent C2="low delay".
- リソース R が存在しないことがわかっているドメインでは、ドメイン間インテント C1="低遅延および R 回避" は、インテント C2"低遅延" のドメイン内パスを介して解決される可能性があります。
- In a domain where if no (N, C1) path is available, resolution may fallback to a C2 path if the user has permitted it.
- 使用可能な (N, C1) パスがないドメインでは、ユーザーが許可していれば解決が C2 パスにフォールバックする可能性があります。
* Route resolution may be driven by an egress node. In an SRv6 domain, an egress node selects and advertises an SRv6 SID from its locator for intent C1, with a BGP CAR route. In such a case, the ingress node resolves the received SRv6 SID over an IPv6 route for the intent-aware locator of the egress node for C1 or a summary route that covers the locator. This summary route may be provided by SRv6 Flexible Algorithm or BGP CAR IP Prefix route itself (e.g., Appendix C.2).
* ルート解決は出力ノードによって行われる場合があります。SRv6 ドメインでは、出力ノードは BGP CAR ルートを使用して、インテント C1 のロケーターから SRv6 SID を選択し、アドバタイズします。このような場合、入力ノードは、C1 の出力ノードのインテントアウェア ロケーターの IPv6 ルート、またはそのロケーターをカバーするサマリー ルートを介して、受信した SRv6 SID を解決します。この要約ルートは、SRv6 フレキシブル アルゴリズムまたは BGP CAR IP プレフィックス ルート自体によって提供される場合があります (付録 C.2 など)。
* Local policy may map the CAR route to mechanisms that are unaware of color or that provide best-effort, such as RSVP-TE, IGP/LDP, BGP-LU/BGP-IP (e.g., Appendix A.3.2) for brownfield scenarios.
* ローカル ポリシーは、カラーを認識しないメカニズム、またはブラウンフィールド シナリオの RSVP-TE、IGP/LDP、BGP-LU/BGP-IP（付録 A.3.2 など）などのベストエフォートを提供するメカニズムに CAR ルートをマッピングする場合があります。
Route resolution via a different color C2 can be automated by attaching BGP Color-EC C2 to CAR route (E2, C1), leveraging automated steering as described in Section 8.4 of "Segment Routing Policy Architecture" [RFC9256] for BGP CAR routes. This mechanism is illustrated in Appendix B.2. This mechanism SHOULD be supported.
異なるカラー C2 によるルート解決は、BGP CAR ルートの「セグメント ルーティング ポリシー アーキテクチャ」[RFC9256] のセクション 8.4 で説明されている自動ステアリングを利用して、BGP Color-EC C2 を CAR ルート (E2、C1) に接続することで自動化できます。このメカニズムは付録 B.2 に示されています。このメカニズムはサポートされるべきです(SHOULD)。
For CAR route resolution, if Color-EC color is present with the route, it takes precedence over the route's intent color. The route's intent color is the LCM-EC color if present (see Section 2.9.5), or else it is the NLRI color.
CAR ルート解決では、ルートに Color-EC カラーが存在する場合、ルートのインテント カラーよりも優先されます。ルートのインテント カラーは、存在する場合は LCM-EC カラーです (セクション 2.9.5 を参照)。それ以外の場合は NLRI カラーです。
Local policy takes precedence over the color-based automated resolution specified above.
ローカル ポリシーは、上で指定した色ベースの自動解像度より優先されます。
The color-aware route (N, C1) may be provided by BGP CAR itself in a hierarchical transport routing design. In such cases, based on the procedures described above, recursive resolution may occur over the same or different CAR route type. Section 7.1.2 describes a scenario where CAR (E, C) route resolves over CAR IP Prefix route.
カラー認識ルート (N、C1) は、階層トランスポート ルーティング設計の BGP CAR 自体によって提供される場合があります。このような場合、上記の手順に基づいて、同じまたは異なる CAR ルート タイプに対して再帰的解決が発生する可能性があります。セクション 7.1.2 では、CAR (E、C) ルートが CAR IP プレフィックス ルート上で解決されるシナリオについて説明します。
CAR IP Prefix route is allowed to be without color for best-effort. In this case, resolution is based on BGP next hop N, or when present, a best-effort SRv6 SID advertised by node N.
ベストエフォートのため、CAR IP プレフィックス ルートは色なしでも許可されます。この場合、解決は BGP ネクスト ホップ N、または存在する場合はノード N によってアドバタイズされるベストエフォート SRv6 SID に基づきます。
A BGP CAR route may recursively resolve over a BGP route that carries a TEA and follows Section 6 of [RFC9012] for validation. In this case, the procedures of Section 8 of [RFC9012] apply to BGP CAR routes, using color precedence as specified above for resolution.
BGP CAR ルートは、TEA を伝送し、検証のために [RFC9012] のセクション 6 に従う BGP ルート上で再帰的に解決できます。この場合、[RFC9012] のセクション 8 の手順が、解決のために上記で指定された色の優先順位を使用して、BGP CAR ルートに適用されます。
The procedures of [RFC9012], Section 6, also apply to BGP CAR routes (AFI/SAFI = 1/83 or 2/83). For instance, a BGP CAR BR may advertise a BGP CAR route to an ingress BR or PE with a specific BGP next hop per color, with a TEA or Tunnel Encapsulation EC, as per Section 6 of [RFC9012].
[RFC9012] セクション 6 の手順は、BGP CAR ルート (AFI/SAFI = 1/83 または 2/83) にも適用されます。たとえば、BGP CAR BR は、[RFC9012] のセクション 6 に従って、TEA またはトンネル カプセル化 EC を使用して、色ごとに特定の BGP ネクスト ホップを持つ入力 BR または PE に BGP CAR ルートをアドバタイズできます。
BGP CAR resolution in one network domain is independent of resolution in another domain.
あるネットワーク ドメインの BGP CAR 解決は、別のドメインの解決とは独立しています。
The Accumulated IGP (AIGP) Metric Attribute [RFC7311] is updated as the BGP CAR route propagates across the network.
Accumulated IGP (AIGP) メトリック属性 [RFC7311] は、BGP CAR ルートがネットワーク全体に伝播するにつれて更新されます。
The value that is set (or appropriately incremented) in the AIGP TLV corresponds to the metric associated with the underlying intent of the color. For example, when the color is associated with a low latency path, the metric value is set based on the delay metric.
AIGP TLV で設定された (または適切に増分された) 値は、色の根底にある意図に関連付けられたメトリックに対応します。たとえば、色が低遅延パスに関連付けられている場合、メトリック値は遅延メトリックに基づいて設定されます。
Information regarding the metric type used by the underlying intra-domain mechanism can also be used to set the metric value.
基礎となるドメイン内メカニズムで使用されるメトリック タイプに関する情報も、メトリック値の設定に使用できます。
If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, a penalty is added in the AIGP metric (value set by user policy). This could occur, for instance, when color C1 path is not available, and route resolves via color C2 path (see Appendix A.3 for an example).
BGP CAR ルートが特定のインテントのトランスポート パスの不連続点を横切る場合、AIGP メトリック (ユーザー ポリシーによって設定された値) にペナルティが追加されます。これは、たとえば、カラー C1 パスが利用できず、ルートがカラー C2 パス経由で解決される場合に発生する可能性があります (例については、付録 A.3 を参照)。
AIGP metric computation is recursive.
AIGP メトリックの計算は再帰的です。
To avoid continuous IGP metric changes causing end-to-end BGP CAR route churn, an implementation should provide thresholds to trigger AIGP updates.
継続的な IGP メトリックの変更がエンドツーエンドの BGP CAR ルート チャーンの原因となることを避けるために、実装では AIGP 更新をトリガーするしきい値を提供する必要があります。
Additional AIGP extensions may be defined to signal state for specific use cases such as Maximum SID Depth (MSD) along the BGP CAR route advertisement and minimum MTU along the BGP CAR route advertisement. This is out of scope for this document.
追加の AIGP 拡張機能を定義して、BGP CAR ルート アドバタイズメントに沿った最大 SID 深度 (MSD) や BGP CAR ルート アドバタイズメントに沿った最小 MTU などの特定のユース ケースの状態を通知することができます。これはこのドキュメントの範囲外です。
The (E, C) route definition inherently provides availability of redundant paths at every BGP hop identical to BGP-LU or BGP-IP. For instance, BGP CAR routes originated by two or more egress ABRs in a domain are advertised as multiple paths to ingress ABRs in the domain, where they become equal-cost or primary-backup paths. A failure of an egress ABR is detected and handled by ingress ABRs locally within the domain for faster convergence, without any necessity to propagate the event to upstream nodes for traffic restoration.
(E、C) ルート定義は、本質的に、BGP-LU または BGP-IP と同一のすべての BGP ホップで冗長パスの可用性を提供します。たとえば、ドメイン内の 2 つ以上の出力 ABR によって発信された BGP CAR ルートは、ドメイン内の入力 ABR への複数のパスとしてアドバタイズされ、それらは等コスト パスまたはプライマリ バックアップ パスになります。出力 ABR の障害は、ドメイン内の入力 ABR によってローカルに検出および処理され、より迅速な収束を実現します。トラフィック復元のためにイベントを上流ノードに伝播する必要はありません。
BGP ADD-PATH [RFC7911] SHOULD be enabled for BGP CAR to signal multiple next hops through a transport RR (T-RR).
BGP ADD-PATH [RFC7911] は、トランスポート RR (T-RR) を介して複数のネクストホップに信号を送るために、BGP CAR に対して有効にする必要があります (SHOULD)。
[Color Domain 1 A]-----[B Color Domain 2 E2]
[C1=low delay ] [C2=low delay ]
Let us assume a BGP CAR route (E2, C2) is signaled from B to A, two BRs of Domain 2 and Domain 1, respectively. Let us assume that these two domains do not share the same color-to-intent mapping (i.e., they belong to different color domains). Low delay in Domain 2 is color C2, while it is C1 in Domain 1 (C1 <> C2).
BGP CAR ルート (E2、C2) が B からドメイン 2 とドメイン 1 の 2 つの BR である A にそれぞれシグナリングされると仮定します。これら 2 つのドメインが同じカラーからインテントへのマッピングを共有していない (つまり、異なるカラー ドメインに属している) と仮定します。ドメイン 2 の低遅延はカラー C2 ですが、ドメイン 1 では C1 (C1 <> C2) です。
It is not expected to be a typical scenario to have an underlay transport path (e.g., an MPLS LSP) extend across different color domains. However, the BGP CAR solution seamlessly supports this rare scenario while maintaining the separation and independence of the administrative authority in different color domains.
アンダーレイ トランスポート パス (MPLS LSP など) が異なるカラー ドメインにまたがって拡張されることは、一般的なシナリオではないと考えられます。ただし、BGP CAR ソリューションは、さまざまなカラー ドメインにおける管理権限の分離と独立性を維持しながら、このまれなシナリオをシームレスにサポートします。
The solution works as described below:
このソリューションは以下のように機能します。
* Within Domain 2, the BGP CAR route is (E2, C2) via E2.
* ドメイン 2 内では、BGP CAR ルートは E2 経由の (E2, C2) です。
* B signals to A the BGP CAR route as (E2, C2) via B with Local Color Mapping Extended Community (LCM-EC) of color C2.
* B は、カラー C2 のローカル カラー マッピング拡張コミュニティ (LCM-EC) を使用して、B 経由で BGP CAR ルートを (E2, C2) として A に信号で送信します。
* A is aware of the intent-to-color mapping within Domain 2 ("low delay" in Domain 2 is C2), as per typical coordination that exists between operators of peering domains.
* A は、ピアリング ドメインのオペレータ間に存在する一般的な調整に従って、ドメイン 2 内のインテントとカラーのマッピングを認識しています (ドメイン 2 の「低遅延」は C2 です)。
* A maps C2 in LCM-EC to C1 and signals within Domain 1 the received BGP CAR route as (E2, C2) via A with LCM-EC (C1).
* A は、LCM-EC の C2 を C1 にマッピングし、ドメイン 1 内で、LCM-EC (C1) を使用して A を介して、受信した BGP CAR ルートを (E2, C2) としてシグナリングします。
* The nodes within the receiving Domain 1 use the local color encoded in the LCM-EC for next-hop resolution and service steering.
* 受信ドメイン 1 内のノードは、ネクストホップ解決とサービス ステアリングのために LCM-EC でエンコードされたローカル カラーを使用します。
The following procedures apply at a color domain boundary for BGP CAR routes, performed by route policy at the sending and receiving peer:
次の手順は、BGP CAR ルートのカラー ドメイン境界に適用され、送信ピアと受信ピアのルート ポリシーによって実行されます。
* Use local policy to control which routes are advertised to or accepted from a peer in a different color domain.
* ローカル ポリシーを使用して、異なるカラー ドメインのピアにどのルートをアドバタイズするか、ピアからどのルートを受け入れるかを制御します。
* Attach LCM-EC if not present with the route. If LCM-EC is present, then update the value to re-map the color as needed.
* ルートに LCM-EC が存在しない場合は、LCM-EC を接続します。LCM-EC が存在する場合は、必要に応じて値を更新して色を再マッピングします。
- This function may be done by the advertising BGP speaker or the receiving BGP speaker as determined by the operator peering agreement, and indicated by local policy on the BGP peers.
- この機能は、オペレータのピアリング契約によって決定され、BGP ピアのローカル ポリシーによって示されるように、アドバタイズ BGP スピーカーまたは受信 BGP スピーカーによって実行されます。
These procedures apply to both CAR route types, in addition to all procedures specified in earlier sections. LCM-EC is described in Section 2.9.5.
これらの手順は、前のセクションで指定したすべての手順に加えて、両方の CAR ルート タイプに適用されます。LCM-EC についてはセクション 2.9.5 で説明されています。
Salient properties:
顕著な特性:
* The NLRI never changes, even though the color-to-intent mapping changes.
* 色とインテントのマッピングが変化しても、NLRI は決して変化しません。
* E is globally unique, which makes E-C in that order unique.
* E はグローバルに一意であるため、E ～ C の順序は一意になります。
* In typical expected cases, the color of the NLRI is used for resolution and steering.
* 予想される一般的なケースでは、NLRI の色が解像度とステアリングに使用されます。
* In the rare case of color incongruence, the local color encoded in LCM-EC takes precedence.
* まれに色が一致しない場合は、LCM-EC でエンコードされたローカル カラーが優先されます。
Operational considerations are in Section 11. Further illustrations are provided in Appendix B.
運用上の考慮事項はセクション 11 に記載されています。詳細な図は付録 B に記載されています。
BGP CAR leverages BGP multiprotocol extensions [RFC4760] and uses the MP_REACH_NLRI and MP_UNREACH_NLRI attributes for route updates within SAFI value 83 along with AFI 1 for IPv4 prefixes and AFI 2 for IPv6 prefixes.
BGP CAR は、BGP マルチプロトコル拡張 [RFC4760] を活用し、SAFI 値 83 内のルート更新に MP_REACH_NLRI および MP_UNREACH_NLRI 属性を、IPv4 プレフィックスの AFI 1 および IPv6 プレフィックスの AFI 2 とともに使用します。
BGP speakers MUST use the BGP Capabilities Advertisement to ensure support for processing of BGP CAR updates. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP), with AFI 1 and 2 (as required) and SAFI 83.
BGP スピーカーは、BGP CAR アップデートの処理を確実にサポートするために、BGP 機能アドバタイズメントを使用しなければなりません。これは、[RFC4760] で指定されているように、機能コード 1 (マルチプロトコル BGP)、AFI 1 および 2 (必要に応じて) および SAFI 83 を使用して行われます。
The Next Hop network address field in the MP_REACH_NLRI may either be an IPv4 address or an IPv6 address, independent of AFI. If the next hop length is 4, then the next hop is an IPv4 address. The next hop length may be 16 or 32 for an IPv6 next hop address, set as per Section 3 of [RFC2545]. Processing of the Next Hop field is governed by standard BGP procedures as described in Section 3 of [RFC4760].
MP_REACH_NLRI のネクスト ホップ ネットワーク アドレス フィールドは、AFI とは無関係に、IPv4 アドレスまたは IPv6 アドレスのいずれかになります。ネクスト ホップの長さが 4 の場合、ネクスト ホップは IPv4 アドレスです。[RFC2545] のセクション 3 に従って設定される、IPv6 ネクスト ホップ アドレスのネクスト ホップの長さは 16 または 32 です。Next Hop フィールドの処理は、[RFC4760] のセクション 3 で説明されている標準 BGP 手順によって管理されます。
The sub-sections below specify the generic encoding of the BGP CAR NLRI and non-key TLV fields, followed by the encoding for specific NLRI types introduced in this document.
以下のサブセクションでは、BGP CAR NLRI および非キー TLV フィールドの汎用エンコーディングを指定し、その後にこのドキュメントで紹介されている特定の NLRI タイプのエンコーディングを指定します。
The generic format for the BGP CAR SAFI NLRI is shown below:
BGP CAR SAFI NLRI の一般的な形式を以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
| Type-Specific Key Fields //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-Specific Non-Key TLV Fields (if applicable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
NLRI Length:
NLRIの長さ:
1-octet field that indicates the length in octets of the NLRI excluding the NLRI Length field itself.
NLRI 長さフィールド自体を除く、NLRI の長さをオクテット単位で示す 1 オクテットのフィールド。
Key Length:
キーの長さ:
1-octet field that indicates the length in octets of the NLRI Type-Specific Key Fields. Key Length MUST be at least 2 less than the NLRI Length.
NLRI タイプ固有のキー フィールドの長さをオクテット単位で示す 1 オクテット フィールド。キーの長さは、NLRI 長より少なくとも 2 短くなければなりません。
NLRI Type:
NLRI タイプ:
1-octet field that indicates the type of the BGP CAR NLRI.
BGP CAR NLRI のタイプを示す 1 オクテットのフィールド。
Type-Specific Key Fields:
タイプ固有のキーフィールド:
The exact definition of these fields depends on the NLRI Type. They have length indicated by the Key Length.
これらのフィールドの正確な定義は、NLRI タイプによって異なります。キーの長さはキーの長さで示されます。
Type-Specific Non-Key TLV Fields:
タイプ固有の非キー TLV フィールド:
The fields are optional and can carry one or more non-key TLVs (of different types) depending on the NLRI Type. The NLRI definition allows for encoding of specific non-key information associated with the route as part of the NLRI for efficient packing of BGP updates.
フィールドはオプションであり、NLRI タイプに応じて 1 つ以上の非キー TLV (異なるタイプ) を伝送できます。NLRI 定義では、BGP アップデートを効率的にパッキングするために、ルートに関連付けられた特定の非キー情報を NLRI の一部としてエンコードできます。
The non-key TLVs portion of the NLRI MUST be omitted while carrying it within the MP_UNREACH_NLRI when withdrawing the route advertisement.
NLRI の非キー TLV 部分は、ルート アドバタイズメントを取り消すときに、MP_UNREACH_NLRI 内で運ぶときに省略しなければなりません (MUST)。
Error handling for CAR SAFI NLRI and non-key TLVs is described in Section 2.11.
CAR SAFI NLRI および非キー TLV のエラー処理については、セクション 2.11 で説明されています。
The benefits of CAR NLRI design are:
CAR NLRI 設計の利点は次のとおりです。
* The indication of the key length enables BGP speakers to determine the key portion of the NLRI and use it along with the NLRI Type field in an opaque manner for the handling of unknown or unsupported NLRI types. This can help deployed Route Reflectors (RR) to propagate NLRI types introduced in the future in a transparent manner.
* キーの長さの表示により、BGP スピーカーは NLRI のキー部分を決定し、それを NLRI タイプ フィールドとともに不透明な方法で使用して、未知またはサポートされていない NLRI タイプを処理できるようになります。これは、展開されたルート リフレクター (RR) が、将来導入される NLRI タイプを透過的な方法で伝播するのに役立ちます。
* The key length also helps error handling be more resilient and minimally disruptive. The use of key length in error handling is described in Section 2.11.
* キーの長さは、エラー処理の回復力を高め、中断を最小限に抑えるのにも役立ちます。エラー処理におけるキーの長さの使用については、セクション 2.11 で説明されています。
* The ability of a route (NLRI) to carry more than one non-key TLV (of different types) provides significant benefits such as signaling multiple encapsulations simultaneously for the same route, each with a different value (label/SID, etc.). This enables simpler and efficient migrations with low overhead:
* ルート (NLRI) が複数の非キー TLV (異なるタイプ) を伝送できることにより、同じルートに対して、それぞれ異なる値 (ラベル/SID など) を持つ複数のカプセル化を同時にシグナリングできるなど、大きな利点が得られます。これにより、オーバーヘッドが低く、よりシンプルかつ効率的な移行が可能になります。
- avoids the need for duplicate routes to signal different encapsulations
- 異なるカプセル化を通知するための重複したルートの必要性を回避します。
- avoids the need for separate control planes for distribution
- 配布用に個別のコントロール プレーンが必要なくなります
- preserves update packing (e.g., Appendix D)
- アップデートのパッキングを保存します (例: 付録 D)
The generic format for Non-Key TLVs is shown below:
非キー TLV の一般的な形式を以下に示します。
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 | Length | Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type:
タイプ：
1 octet that contains the type code and flags. It is encoded as shown below:
タイプコードとフラグを含む 1 オクテット。以下に示すようにエンコードされます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|T| Type code |
+-+-+-+-+-+-+-+-+
where:
ただし：
R:
R:
Bit is reserved and MUST be set to 0 and ignored on receive.
ビットは予約されており、0 に設定し、受信時に無視する必要があります。
T:
T:
Transitive bit, applicable to speakers that change the BGP CAR next hop.
推移ビット。BGP CAR ネクスト ホップを変更するスピーカーに適用されます。
* The T bit is set to indicate TLV is transitive. An unrecognized transitive TLV MUST be propagated by a speaker that changes the next hop.
* T ビットは、TLV が推移的であることを示すために設定されます。認識されない推移的 TLV は、ネクストホップを変更するスピーカーによって伝播されなければなりません (MUST)。
* The T bit is unset to indicate TLV is non-transitive. An unrecognized non-transitive TLV MUST NOT be propagated by a speaker that changes the next hop.
* T ビットは、TLV が非推移的であることを示すために設定されません。認識されない非推移的な TLV は、ネクストホップを変更するスピーカーによって伝播されてはなりません (MUST NOT)。
A speaker that does not change the next hop SHOULD propagate all received TLVs.
ネクストホップを変更しないスピーカーは、受信したすべての TLV を伝播すべきです (SHOULD)。
Type code:
タイプコード:
Remaining 6 bits contain the type of the TLV.
残りの 6 ビットには TLV のタイプが含まれます。
Length:
長さ：
1-octet field that contains the length of the value portion of the Non-Key TLV in terms of octets.
非キー TLV の値部分の長さをオクテット単位で含む 1 オクテットのフィールド。
Value:
値：
Variable-length field as indicated by the Length field and to be interpreted as per the Type field.
Length フィールドで示され、Type フィールドに従って解釈される可変長フィールド。
The following sub-sections specify non-key TLVs. Each NLRI Type MUST list the TLVs that can be associated with it.
次のサブセクションでは、非キー TLV を指定します。各 NLRI タイプには、関連付けることができる TLV をリストする必要があります。
The Label TLV is used for the advertisement of CAR routes along with their MPLS labels. It has the following format as per Section 2.9.2:
ラベル TLV は、MPLS ラベルとともに CAR ルートのアドバタイズメントに使用されます。セクション 2.9.2 に従って、次の形式になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is followed by one (or more) labels encoded as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type:
タイプ：
Type code is 1. The T bit MUST be unset.
タイプ コードは 1 です。T ビットは設定解除する必要があります。
Length:
長さ：
Length is in octets, variable, and MUST be a multiple of 3.
長さはオクテット単位で可変で、3 の倍数でなければなりません。
Label Information:
ラベル情報:
Multiples of 3-octet fields to convey the MPLS label(s) associated with the advertised CAR route. It is used for encoding a single label or a stack of labels for usage as described in [RFC8277]. The number of labels is derived from the Length field. The 3-bit Rsrv field and the 1-bit S field SHOULD be set to zero on transmission and MUST be ignored on reception.
アドバタイズされた CAR ルートに関連付けられた MPLS ラベルを伝達する 3 オクテット フィールドの倍数。[RFC8277] で説明されているように、単一のラベルまたはラベルのスタックをエンコードして使用するために使用されます。ラベルの数は長さフィールドから導出されます。3 ビットの Rsrv フィールドと 1 ビットの S フィールドは、送信時にゼロに設定される必要があり (SHOULD)、受信時に無視されなければなりません (MUST)。
If a BGP transport CAR speaker sets itself as the next hop while propagating a CAR route, it allocates a local label for the type-specific key, and updates the value in this TLV. It also MUST program a label cross-connect that would result in the label swap operation for the incoming label that it advertises with the label received from its best-path router(s).
BGP トランスポート CAR スピーカーが CAR ルートの伝播中に自身をネクスト ホップとして設定する場合、タイプ固有のキーにローカル ラベルを割り当て、この TLV の値を更新します。また、ベスト パス ルーターから受信したラベルを使用してアドバタイズする受信ラベルのラベル スワップ操作が行われるラベル クロスコネクトをプログラムしなければなりません (MUST)。
The Label-Index TLV is used for the advertisement of Segment Routing over MPLS (SR-MPLS) Segment Identifier (SID) [RFC8402] information associated with the labeled CAR routes. It has the following format as per Section 2.9.2:
Label-Index TLV は、ラベル付き CAR ルートに関連付けられたセグメント ルーティング オーバー MPLS (SR-MPLS) セグメント識別子 (SID) [RFC8402] 情報のアドバタイズメントに使用されます。セクション 2.9.2 に従って、次の形式になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | Reserved | Flags ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Label Index ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
where:
ただし：
Type:
タイプ：
Type code is 2. The T bit MUST be set.
タイプ コードは 2 です。T ビットを設定する必要があります。
Length:
長さ：
Length is in octets and is 7.
長さはオクテット単位で 7 です。
Reserved:
予約済み：
1-octet field that MUST be set to 0 and ignored on receipt.
1 オクテットのフィールド。0 に設定し、受信時に無視しなければなりません。
Flags:
フラグ:
2-octet field that's defined as per the Flags field of the Label-Index TLV of the BGP Prefix-SID attribute (Section 3.1 of [RFC8669]).
BGP Prefix-SID 属性の Label-Index TLV の Flags フィールドに従って定義される 2 オクテットのフィールド ([RFC8669] のセクション 3.1)。
Label Index:
ラベルインデックス:
4-octet field that's defined as per the Label Index field of the Label-Index TLV of the BGP Prefix-SID attribute (Section 3.1 of [RFC8669]).
BGP Prefix-SID 属性の Label-Index TLV の Label Index フィールドに従って定義される 4 オクテットのフィールド ([RFC8669] のセクション 3.1)。
This TLV provides the equivalent functionality as the Label-Index TLV of [RFC8669] for Transport CAR route in SR-MPLS deployments. When a speaker allocates a local label for a received CAR route as per Section 2.9.2.1, it SHOULD use the received Label Index as a hint using procedures as specified in [RFC8669], Section 4.
この TLV は、SR-MPLS 導入におけるトランスポート CAR ルートに対して [RFC8669] のラベルインデックス TLV と同等の機能を提供します。スピーカーがセクション 2.9.2.1 に従って受信した CAR ルートにローカル ラベルを割り当てるとき、[RFC8669] のセクション 4 で指定されている手順を使用して、受信したラベル インデックスをヒントとして使用する必要があります (SHOULD)。
The Label-Index TLV provides much better packing efficiency by carrying the Label Index in NLRI instead of in the BGP Prefix-SID attribute (Appendix D).
ラベル インデックス TLV は、ラベル インデックスを BGP プレフィックス SID 属性ではなく NLRI で伝送することにより、パッキング効率を大幅に向上させます (付録 D)。
The Label-Index TLV MUST NOT be carried in the Prefix-SID attribute for BGP CAR routes. If a speaker receives a CAR route with the Label-Index TLV in the Prefix-SID attribute, it SHOULD ignore it. The BGP Prefix-SID attribute SHOULD NOT be sent with the labeled CAR routes if the attribute is being used only to convey the Label-Index TLV.
Label-Index TLV は、BGP CAR ルートの Prefix-SID 属性で伝送されてはなりません (MUST NOT)。スピーカーが Prefix-SID 属性に Label-Index TLV を持つ CAR ルートを受信した場合、それを無視する必要があります (SHOULD)。BGP プレフィックス SID 属性は、ラベル インデックス TLV を伝達するためだけに使用される場合、ラベル付き CAR ルートと一緒に送信すべきではありません (SHOULD NOT)。
BGP Transport CAR can be also used to set up end-to-end color-aware connectivity using Segment Routing over IPv6 (SRv6) [RFC8402]. [RFC8986] specifies the SRv6 Endpoint behaviors (e.g., End Penultimate Segment Pop (PSP)), which can be leveraged for BGP CAR with SRv6. The SRv6 SID TLV is used for the advertisement of CAR routes along with their SRv6 SIDs. It has the following format as per Section 2.9.2:
BGP トランスポート CAR は、IPv6 経由のセグメント ルーティング (SRv6) [RFC8402] を使用してエンドツーエンドのカラー認識接続をセットアップするためにも使用できます。[RFC8986] は、SRv6 の BGP CAR に利用できる SRv6 エンドポイントの動作 (例: 最後から 2 番目のセグメント ポップ (PSP) など) を指定しています。SRv6 SID TLV は、SRv6 SID とともに CAR ルートのアドバタイズメントに使用されます。セクション 2.9.2 に従って、次の形式になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | SRv6 SID Info (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type:
タイプ：
Type code is 3. The T bit MUST be unset.
タイプ コードは 3 です。T ビットは設定解除する必要があります。
Length:
長さ：
Length is in octets, variable, and MUST be either less than or equal to 16, or be a multiple of 16.
長さはオクテット単位で可変で、16 以下、または 16 の倍数でなければなりません。
SRv6 SID Information:
SRv6 SID 情報:
Field of size as indicated by the length that either carries the SRv6 SID(s) for the advertised CAR route as one of the following:
次のいずれかとしてアドバタイズされた CAR ルートの SRv6 SID を伝送する長さで示されるサイズのフィールド。
* A single 128-bit SRv6 SID or an ordered list of 128-bit SRv6 SIDs.
* 単一の 128 ビット SRv6 SID、または 128 ビット SRv6 SID の順序付きリスト。
* A transposed portion (refer to [RFC9252]) of the SRv6 SID that MUST be of size in multiples of one octet and less than 16.
* SRv6 SID の転置部分 ([RFC9252] を参照)。サイズは 1 オクテットの倍数で 16 未満でなければなりません。
BGP CAR SRv6 SID TLV definitions provide the following benefits:
BGP CAR SRv6 SID TLV 定義には次の利点があります。
* The explicit encoding of SIDs avoids robustness issues caused by the overloading of MPLS label fields.
* SID の明示的なエンコードにより、MPLS ラベル フィールドの過負荷によって引き起こされる堅牢性の問題が回避されます。
* The encoding to include the entire 128 bits for unique SIDs (non-transposition) maintains BGP update prefix packing.
* 一意の SID の 128 ビット全体を含めるエンコード (非転置) により、BGP 更新プレフィックス パッキングが維持されます。
* The highly efficient transposition scheme (12-14 bytes saved per NLRI) also maintains BGP update prefix packing.
* 非常に効率的な転置スキーム (NLRI ごとに 12 ～ 14 バイトが節約される) により、BGP 更新プレフィックス パッキングも維持されます。
The BGP CAR route update for SRv6 encapsulation MUST include the BGP Prefix-SID attribute along with the SRv6 L3 Service TLV carrying the SRv6 SID information as specified in [RFC9252]. When using the transposition scheme of encoding for packing efficiency of BGP updates [RFC9252], the transposed part of the SID is carried in the SRv6 SID TLV and is not limited by MPLS label field size.
SRv6 カプセル化の BGP CAR ルート更新には、[RFC9252] で指定されている SRv6 SID 情報を運ぶ SRv6 L3 サービス TLV とともに BGP プレフィックス SID 属性が含まれなければなりません (MUST)。BGP アップデート [RFC9252] のパッキング効率のために符号化の転置スキームを使用する場合、SID の転置部分は SRv6 SID TLV で伝送され、MPLS ラベル フィールド サイズによって制限されません。
If a BGP transport CAR speaker sets itself as the next hop while propagating a CAR route and allocates an SRv6 SID that maps to the received SRv6 SID, it updates the value in this TLV.
BGP トランスポート CAR スピーカーが CAR ルートの伝播中に自身をネクスト ホップとして設定し、受信した SRv6 SID にマップする SRv6 SID を割り当てる場合、この TLV の値を更新します。
Received MPLS information can map to SRv6 and vice versa.
受信した MPLS 情報は SRv6 にマッピングでき、その逆も可能です。
[SRv6-INTERWORK] describes MPLS and SRv6 interworking procedures and their applicability to BGP CAR routes.
[SRv6-INTERWORK] では、MPLS と SRv6 のインターワーキング手順と、BGP CAR ルートへの適用性について説明します。
The Color-Aware Route NLRI Type is used for the advertisement of BGP CAR color-aware routes (E, C). It has the following format:
カラー認識ルート NLRI タイプは、BGP CAR カラー認識ルート (E、C) のアドバタイズに使用されます。次の形式になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is followed by optional Non-Key TLVs encoded as per Section 2.9.2.
これに、セクション 2.9.2 に従ってエンコードされたオプションの非キー TLV が続きます。
Where:
ただし：
NLRI Length:
NLRIの長さ:
Variable.
変数。
Key Length:
キーの長さ:
Variable. It indicates the total length comprised of the Prefix Length field, IP Prefix field, and the Color field, as described below. For IPv4 (AFI=1), the minimum length is 5 and the maximum length is 9. For IPv6 (AFI=2), the minimum length is 5 and the maximum length is 21.
変数。これは、以下で説明するように、プレフィックス長フィールド、IP プレフィックス フィールド、およびカラー フィールドで構成される合計の長さを示します。IPv4 (AFI=1) の場合、最小長は 5、最大長は 9 です。IPv6 (AFI=2) の場合、最小長は 5、最大長は 21 です。
NLRI Type:
NLRI タイプ:
1.
1.
Type-Specific Key Fields:
タイプ固有のキーフィールド:
These are as seen below:
これらは以下に示すとおりです。
Prefix Length:
プレフィックスの長さ:
1-octet field that carries the length of prefix in bits. Length MUST be less than or equal to 32 for IPv4 (AFI=1) and less than or equal to 128 for IPv6 (AFI=2).
プレフィックスの長さをビット単位で伝える 1 オクテットのフィールド。長さは、IPv4 (AFI=1) の場合は 32 以下、IPv6 (AFI=2) の場合は 128 以下でなければなりません。
IP Prefix:
IPプレフィックス:
IPv4 or IPv6 prefix (based on the AFI). A variable-size field that contains the most significant octets of the prefix. The format of this field for an IPv4 prefix is:
IPv4 または IPv6 プレフィックス (AFI に基づく)。プレフィックスの最上位オクテットを含む可変サイズのフィールド。IPv4 プレフィックスのこのフィールドの形式は次のとおりです。
* 0 octet for prefix length 0
* プレフィックス長 0 の場合は 0 オクテット
* 1 octet for prefix length 1 to 8
* プレフィックス長 1 ～ 8 の場合は 1 オクテット
* 2 octets for prefix length 9 to 16
* プレフィックス長 9 ～ 16 の場合は 2 オクテット
* 3 octets for prefix length 17 up to 24
* プレフィックス長 17 ～ 24 の場合は 3 オクテット
* 4 octets for prefix length 25 up to 32
* プレフィックス長 25 ～ 32 の場合は 4 オクテット
The format for this field for an IPv6 address follows the same pattern for prefix lengths of 1-128 (octets 1-16).
IPv6 アドレスのこのフィールドの形式は、1 ～ 128 (オクテット 1 ～ 16) のプレフィックス長と同じパターンに従います。
The last octet has enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of the trailing bits MUST be set to zero. The size of the field MUST be less than or equal to 4 for IPv4 (AFI=1) and less than or equal to 16 for IPv6 (AFI=2).
最後のオクテットには、フィールドの終わりがオクテット境界に収まるのに十分な後続ビットがあります。後続ビットの値はゼロに設定しなければならないことに注意してください。フィールドのサイズは、IPv4 (AFI=1) の場合は 4 以下、IPv6 (AFI=2) の場合は 16 以下でなければなりません。
Color:
色：
4 octets that contain non-zero color value associated with the prefix.
プレフィックスに関連付けられたゼロ以外のカラー値を含む 4 オクテット。
Type-Specific Non-Key TLVs:
タイプ固有の非キー TLV:
The Label TLV, Label-Index TLV, and SRv6 SID TLV (Section 2.9.2) may be associated with the color-aware route NLRI type.
Label TLV、Label-Index TLV、および SRv6 SID TLV (セクション 2.9.2) は、カラー対応ルート NLRI タイプに関連付けられている場合があります。
The prefix is unique across the administrative domains where BGP transport CAR is deployed. It is possible that the same prefix is originated by multiple BGP CAR speakers in the case of anycast addressing or multihoming.
プレフィックスは、BGP トランスポート CAR が展開されている管理ドメイン全体で一意です。エニーキャスト アドレッシングまたはマルチホーミングの場合、複数の BGP CAR スピーカによって同じプレフィックスが発信される可能性があります。
The Color is introduced to enable multiple route advertisements for the same prefix. The color is associated with an intent (e.g., low latency) in originator color domain.
Color は、同じプレフィックスに対する複数のルート アドバタイズメントを有効にするために導入されました。色は、発信元のカラー ドメインの意図 (低遅延など) に関連付けられます。
The IP Prefix Route NLRI Type is used for the advertisement of BGP CAR IP Prefix routes (E). It has the following format:
IP プレフィックス ルート NLRI タイプは、BGP CAR IP プレフィックス ルート (E) のアドバタイズメントに使用されます。次の形式になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is followed by optional Non-Key TLVs encoded as per Section 2.9.2.
これに、セクション 2.9.2 に従ってエンコードされたオプションの非キー TLV が続きます。
Where:
ただし：
NLRI Length:
NLRIの長さ:
Variable.
変数。
Key Length:
キーの長さ:
Variable. It indicates the total length comprised of the Prefix Length field and IP Prefix field as described below. For IPv4 (AFI=1), the minimum length is 1 and the maximum length is 5. For IPv6 (AFI=2), the minimum length is 1 and the maximum length is 17.
変数。以下に説明するように、プレフィックス長フィールドと IP プレフィックス フィールドの合計の長さを示します。IPv4 (AFI=1) の場合、最小長は 1、最大長は 5 です。IPv6 (AFI=2) の場合、最小長は 1、最大長は 17 です。
NLRI Type:
NLRI タイプ:
2.
2.
Type-Specific Key Fields:
タイプ固有のキーフィールド:
These are as seen below:
これらは以下に示すとおりです。
Prefix Length:
プレフィックスの長さ:
1-octet field that carries the length of prefix in bits. Length MUST be less than or equal to 32 for IPv4 (AFI=1) and less than or equal to 128 for IPv6 (AFI=2).
プレフィックスの長さをビット単位で伝える 1 オクテットのフィールド。長さは、IPv4 (AFI=1) の場合は 32 以下、IPv6 (AFI=2) の場合は 128 以下でなければなりません。
IP Prefix:
IPプレフィックス:
IPv4 or IPv6 prefix (based on the AFI). A variable-size field that contains the most significant octets of the prefix. The format of this field for an IPv4 prefix is:
IPv4 または IPv6 プレフィックス (AFI に基づく)。プレフィックスの最上位オクテットを含む可変サイズのフィールド。IPv4 プレフィックスのこのフィールドの形式は次のとおりです。
* 0 octet for prefix length 0
* プレフィックス長 0 の場合は 0 オクテット
* 1 octet for prefix length 1 to 8
* プレフィックス長 1 ～ 8 の場合は 1 オクテット
* 2 octets for prefix length 9 to 16
* プレフィックス長 9 ～ 16 の場合は 2 オクテット
* 3 octets for prefix length 17 up to 24
* プレフィックス長 17 ～ 24 の場合は 3 オクテット
* 4 octets for prefix length 25 up to 32
* プレフィックス長 25 ～ 32 の場合は 4 オクテット
The format for this field for an IPv6 address follows the same pattern for prefix lengths of 1-128 (octets 1-16).
IPv6 アドレスのこのフィールドの形式は、1 ～ 128 (オクテット 1 ～ 16) のプレフィックス長と同じパターンに従います。
The last octet has enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of the trailing bits MUST be set to zero. The size of the field MUST be less than or equal to 4 for IPv4 (AFI=1) and less than or equal to 16 for IPv6 (AFI=2).
最後のオクテットには、フィールドの終わりがオクテット境界に収まるのに十分な後続ビットがあります。後続ビットの値はゼロに設定しなければならないことに注意してください。フィールドのサイズは、IPv4 (AFI=1) の場合は 4 以下、IPv6 (AFI=2) の場合は 16 以下でなければなりません。
Type-Specific Non-Key TLVs:
タイプ固有の非キー TLV:
The Label TLV, Label-Index TLV, and SRv6 SID TLV (Section 2.9.2) may be associated with the IP Prefix NLRI Type.
ラベル TLV、ラベル インデックス TLV、および SRv6 SID TLV (セクション 2.9.2) は、IP プレフィックス NLRI タイプに関連付けられている場合があります。
This document defines a new BGP Extended Community called "LCM". The LCM is a Transitive Opaque Extended Community with the following encoding:
この文書では、「LCM」と呼ばれる新しい BGP 拡張コミュニティを定義します。LCM は、次のエンコーディングを持つ推移的不透明拡張コミュニティです。
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=0x3 | Sub-Type=0x1b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type:
タイプ：
0x3.
0x3。
Sub-Type:
サブタイプ:
0x1b.
0x1b。
Reserved:
予約済み：
2-octet reserved field that MUST be set to zero on transmission and ignored on reception.
2 オクテットの予約フィールド。送信時にはゼロに設定し、受信時には無視しなければなりません。
Color:
色：
4-octet field that carries the non-zero 32-bit color value.
ゼロ以外の 32 ビット カラー値を伝送する 4 オクテット フィールド。
When a CAR route crosses the originator's color domain boundary, LCM-EC is added or updated, as specified in Section 2.8. LCM-EC conveys the local color mapping for the intent (e.g., low latency) in other (transit or destination) color domains.
CAR ルートが発信者のカラー ドメイン境界を越える場合、セクション 2.8 で指定されているように、LCM-EC が追加または更新されます。LCM-EC は、他の (トランジットまたは宛先) カラー ドメインの目的 (低遅延など) のローカル カラー マッピングを伝達します。
For CAR IP Prefix routes, LCM-EC may also be added in the originator color domain to indicate the color associated with the IP prefix.
CAR IP プレフィックス ルートの場合、IP プレフィックスに関連付けられた色を示すために、発信元カラー ドメインに LCM-EC を追加することもできます。
An implementation SHOULD NOT send more than one instance of the LCM-EC. However, if more than one instance is received, an implementation MUST disregard all instances other than the one with the numerically highest value.
実装は、LCM-EC の複数のインスタンスを送信してはなりません (SHOULD NOT)。ただし、複数のインスタンスを受信した場合、実装は数値的に最も高い値を持つインスタンス以外のすべてのインスタンスを無視しなければなりません (MUST)。
If a node receives multiple BGP CAR routes (paths) for a given destination endpoint and color that have different LCM values, it is a misconfiguration in color re-mapping for one of the routes.
ノードが、異なる LCM 値を持つ、特定の宛先エンドポイントおよびカラーに対する複数の BGP CAR ルート (パス) を受信した場合、ルートの 1 つに対するカラー再マッピングの設定ミスとなります。
In this case, the LCM from the selected BGP best path SHOULD be chosen to be installed into the routing table.
この場合、選択した BGP ベスト パスからの LCM をルーティング テーブルにインストールするように選択する必要があります (SHOULD)。
A warning message SHOULD also be logged for further operator intervention.
さらなるオペレータ介入のために、警告メッセージも記録されるべきです(SHOULD)。
If present, LCM-EC contains the intent of a BGP CAR route. LCM-EC Color is used instead of the Color in CAR route NLRI for procedures described in earlier sections such as route validation (Section 2.4), route resolution (Section 2.5), AIGP calculation (Section 2.6) and steering (Section 3).
LCM-EC が存在する場合、LCM-EC には BGP CAR ルートの意図が含まれます。LCM-EC カラーは、ルート検証 (セクション 2.4)、ルート解決 (セクション 2.5)、AIGP 計算 (セクション 2.6)、ステアリング (セクション 3) など、前のセクションで説明した手順で CAR ルート NLRI のカラーの代わりに使用されます。
The LCM-EC MAY be used for filtering of BGP CAR routes and/or for applying routing policies on the intent, when present.
LCM-EC は、BGP CAR ルートのフィルタリング、および/またはインテントにルーティング ポリシーを適用するために使用できます (存在する場合)。
There are 2 distinct requirements to be supported as stated in [INTENT-AWARE]:
[INTENT-AWARE] に記載されているように、サポートされる必要がある 2 つの異なる要件があります。
1. Domains with different intent granularity (Section 6.3.1.9 of [INTENT-AWARE])
1. 異なるインテント粒度を持つドメイン ([INTENT-AWARE] のセクション 6.3.1.9)
2. Network domains under different administration (i.e., color domains; see Section 6.3.1.10 of [INTENT-AWARE])
2. 異なる管理下にあるネットワーク ドメイン (つまり、カラー ドメイン。[INTENT-AWARE] のセクション 6.3.1.10 を参照)
Requirement 1 is the case where within the same administrative or color domain, BGP CAR routes for N end-to-end intents may need to traverse across an intermediate transit domain where only M intents are available, N >= M. For example, consider a multi-domain network is designed as Access-Core-Access. The core may have the most granular N intents, whereas the access only has fewer M intents. Therefore, the BGP next-hop resolution for a CAR route in the access domain must be via a color-aware path for one of these M intents. As the procedures in Section 2.5 describe, and the example in Appendix B.2 illustrates, BGP Color-EC is used to automate the CAR route resolution in this case.
要件 1 は、同じ管理ドメインまたはカラー ドメイン内で、N 個のエンドツーエンド インテントの BGP CAR ルートが、M 個のインテントのみが利用可能な中間トランジット ドメイン (N >= M) を通過する必要がある場合です。たとえば、マルチドメイン ネットワークがアクセス-コア-アクセスとして設計されていると考えてください。コアには最も粒度の細かい N インテントが含まれる可能性がありますが、アクセスにはより少ない M インテントしか含まれません。したがって、アクセス ドメイン内の CAR ルートの BGP ネクストホップ解決は、これらの M インテントのいずれかに対するカラー認識パスを経由する必要があります。セクション 2.5 の手順で説明され、付録 B.2 の例で示されているように、この場合、CAR ルート解決を自動化するために BGP Color-EC が使用されます。
For requirement 2, where CAR routes traverse across different color domains, LCM-EC is used to carry the local color mapping for the NLRI color in other color domains. The related procedures are described in Section 2.8, and an example is given in Appendix B.3.
要件 2 では、CAR ルートが異なるカラー ドメインを横断する場合、LCM-EC を使用して、他のカラー ドメインの NLRI カラーのローカル カラー マッピングを伝送します。関連する手順はセクション 2.8 で説明されており、例は付録 B.3 に示されています。
Both LCM-EC and BGP Color-EC may be present at the same time with a BGP CAR route. For example, a BGP CAR route (E, C1) from color domain D1, with LCM-EC C2 in color domain D2, may also carry Color-EC C3 and next hop N in a transit network domain within D2 where C2 is being resolved via an available intra-domain intent C3 (see the detailed example in the combination of Appendices B.2 and B.3).
LCM-EC と BGP Color-EC の両方が BGP CAR ルートと同時に存在する場合があります。たとえば、カラー ドメイン D2 の LCM-EC C2 を伴うカラー ドメイン D1 からの BGP CAR ルート (E、C1) は、D2 内のトランジット ネットワーク ドメインで Color-EC C3 とネクスト ホップ N を伝送することもできます。この場合、C2 は利用可能なドメイン内インテント C3 を介して解決されます (付録 B.2 と B.3 の組み合わせの詳細な例を参照)。
In this case, as described in Section 2.5, the default order of processing for resolution in the presence of LCM-EC is local policy, then BGP Color-EC color, and finally LCM-EC color.
この場合、セクション 2.5 で説明したように、LCM-EC が存在する場合の解決のデフォルトの処理順序は、ローカル ポリシー、次に BGP カラー EC カラー、最後に LCM-EC カラーです。
The error handling actions as described in [RFC7606] are applicable for the handling of BGP update messages for BGP CAR SAFI. In general, as indicated in [RFC7606], the goal is to minimize the disruption of a session reset or 'AFI/SAFI disable' to the extent possible.
[RFC7606] で説明されているエラー処理アクションは、BGP CAR SAFI の BGP 更新メッセージの処理に適用できます。一般に、[RFC7606] に示されているように、目標は、セッションのリセットまたは「AFI/SAFI の無効化」による中断を可能な限り最小限に抑えることです。
When the error determined allows for the router to skip the malformed NLRI(s) and continue processing of the rest of the update message, then it MUST handle such malformed NLRIs as 'treat-as-withdraw'. In other cases, where the error in the NLRI encoding results in the inability to process the BGP update message, then the router SHOULD handle such malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides BGP CAR are being advertised over the same session. Alternately, the router MUST perform 'session reset' when the session is only being used for BGP CAR SAFI.
判定されたエラーにより、ルータが不正な形式の NLRI をスキップして更新メッセージの残りの処理を続行できる場合、ルーターはそのような不正な NLRI を「取り消しとして扱う」として処理しなければなりません(MUST)。NLRI エンコーディングのエラーにより BGP 更新メッセージを処理できなくなる他のケースでは、BGP CAR 以外の他の AFI/SAFI が同じセッション上でアドバタイズされている場合、ルータはそのような不正な NLRI を「AFI/SAFI 無効」として処理する必要があります (SHOULD)。あるいは、セッションが BGP CAR SAFI にのみ使用されている場合、ルータは「セッション リセット」を実行しなければなりません。
The CAR NLRI definition encodes NLRI length and key length explicitly. The NLRI length MUST be relied upon to enable the beginning of the next NLRI field to be located. Key length MUST be relied upon to extract the key and perform 'treat-as-withdraw' for malformed information.
CAR NLRI 定義は、NLRI 長とキーの長さを明示的にエンコードします。次の NLRI フィールドの先頭を特定できるようにするには、NLRI の長さに依存しなければなりません (MUST)。キーを抽出し、不正な形式の情報に対して「引き出しとして扱う」を実行するには、キーの長さに依存しなければなりません (MUST)。
A sender MUST ensure that the NLRI and key lengths are the number of actual bytes encoded in the NLRI and key fields, respectively, regardless of content being encoded.
送信者は、エンコードされているコンテンツに関係なく、NLRI とキーの長さが、それぞれ NLRI とキー フィールドでエンコードされた実際のバイト数であることを保証しなければなりません (MUST)。
Given the NLRI length and Key length MUST be valid, failures in the following checks result in 'AFI/SAFI disable' or 'session reset':
NLRI の長さとキーの長さが有効である必要がある場合、次のチェックに失敗すると、「AFI/SAFI の無効化」または「セッションのリセット」が発生します。
* The minimum NLRI Length MUST be at least 2, as Key Length and NLRI Type are required fields.
* キーの長さと NLRI タイプは必須フィールドであるため、最小の NLRI 長は少なくとも 2 でなければなりません。
* The Key Length MUST be at least 2 less than NLRI Length.
* キーの長さは、NLRI の長さより少なくとも 2 短くなければなりません。
NLRI type-specific error handling:
NLRI タイプ固有のエラー処理:
* By default, a speaker SHOULD discard an unrecognized or unsupported NLRI type and move to the next NLRI.
* デフォルトでは、話者は認識されない、またはサポートされていない NLRI タイプを破棄し、次の NLRI に移動する必要があります (SHOULD)。
* Key length and key errors of a known NLRI type SHOULD result in the discard of NLRI similar to an unrecognized NLRI type. (This MUST be logged for trouble shooting.)
* 既知の NLRI タイプの鍵長と鍵エラーは、認識されていない NLRI タイプと同様に NLRI を破棄する必要があります (SHOULD)。(トラブルシューティングのためにこれを記録する必要があります。)
Transparent propagation of unrecognized NLRI type:
認識されない NLRI タイプの透過的な伝播:
* Key length allows unrecognized route types to transit through the RR transparently without a software upgrade. The RR receiving unrecognized route types does not need to interpret the key portion of an NLRI and handles the NLRI as an opaque value of a specific length. An implementation SHOULD provide configuration that controls the RR unrecognized route type propagation behavior, possibly at the granularity of route type values allowed. This configuration option gives the operator the ability to allow specific route types to be transparently passed through RRs based on client speaker support.
* キーの長さにより、認識されないルート タイプがソフトウェアをアップグレードせずに RR を透過的に通過できます。認識できないルート タイプを受信する RR は、NLRI のキー部分を解釈する必要がなく、NLRI を特定の長さの不透明な値として処理します。実装は、おそらく許可されるルート タイプ値の粒度で、RR が認識されないルート タイプの伝播動作を制御する設定を提供する必要があります (SHOULD)。この設定オプションにより、オペレータは、クライアント スピーカーのサポートに基づいて、特定のルート タイプが RR を透過的に通過できるようになります。
* In such a case, the RRs may reflect NLRIs with NLRI type-specific key length and field errors. Clients of such an RR that consume the route for installation will perform the key error handling of known NLRI type or discard the unrecognized type. This prevents propagation of routes with NLRI errors any further in network.
* このような場合、RR は、NLRI タイプ固有のキー長とフィールド エラーを持つ NLRI を反映する可能性があります。インストールのためにルートを消費するこのような RR のクライアントは、既知の NLRI タイプの主要なエラー処理を実行するか、認識されないタイプを破棄します。これにより、NLRI エラーのあるルートがネットワーク内でそれ以上伝播するのを防ぎます。
Type-specific Non-Key TLV handling:
タイプ固有の非キー TLV 処理:
* Either the length of a TLV would cause the NLRI length to be exceeded when parsing the TLV, or fewer than 2 bytes remain when beginning to parse the TLV. In either of these cases, an error condition exists, and the 'treat-as-withdraw' approach MUST be used.
* TLV の長さが原因で、TLV の解析時に NLRI 長を超過するか、TLV の解析開始時に残っているバイト数が 2 バイト未満になります。これらのいずれの場合でも、エラー状態が存在するため、「撤退として扱う」アプローチを使用しなければなりません。
* Type-specific length constraints should be verified. The TLV MUST be discarded if there is an error. When discarded, an error may be logged for further analysis.
* タイプ固有の長さの制約を確認する必要があります。エラーがある場合、TLV は破棄されなければなりません (MUST)。破棄すると、さらなる分析のためにエラーが記録される場合があります。
* If multiple instances of same type are encountered, all but the first instance MUST be discarded. When discarded, an error may be logged for further analysis.
* 同じタイプの複数のインスタンスが見つかった場合は、最初のインスタンスを除くすべてを破棄しなければなりません(MUST)。破棄すると、さらなる分析のためにエラーが記録される場合があります。
* If a speaker that performs encapsulation to the BGP next hop does not receive at least one recognized forwarding information TLV with the T bit unset (such as label or SRv6 SID), such NLRI is considered invalid and not eligible for best path selection. 'Treat-as-withdraw' may be used, though it is recommended to keep the NLRI for debugging purposes.
* BGP ネクスト ホップへのカプセル化を実行するスピーカーが、T ビットが設定されていない認識された転送情報 TLV (ラベルや SRv6 SID など) を少なくとも 1 つ受信しない場合、そのような NLRI は無効とみなされ、最適なパスの選択の対象にはなりません。「Treat-as-withdraw」を使用することもできますが、デバッグ目的で NLRI を保持することをお勧めします。
An ingress PE (or ASBR) E1 automatically steers a C-colored service route V/v from E2 onto an (E2, C) color-aware path, as illustrated in Section 1.2. If several such paths exist, a preference scheme is used to select the best path. The default preference scheme is IGP Flexible Algorithm first, then SR Policy, followed by BGP CAR. A configuration option may be used to adjust the default preference scheme.
セクション 1.2 で説明されているように、入力 PE (または ASBR) E1 は、C カラーのサービス ルート V/v を E2 から (E2, C) カラー認識パスに自動的に誘導します。このようなパスが複数存在する場合は、優先スキームを使用して最適なパスが選択されます。デフォルトの優先スキームは、最初に IGP フレキシブル アルゴリズム、次に SR ポリシー、次に BGP CAR です。構成オプションを使用して、デフォルトの設定スキームを調整できます。
An egress PE may express its intent that traffic should be steered a certain way through the transport layer by including the BGP Color-EC [RFC9012] with the relevant service routes. An ingress PE steers service traffic over a CAR (E, C) route using the service route's next hop and BGP Color-EC.
出力 PE は、関連するサービス ルートに BGP Color-EC [RFC9012] を含めることによって、トラフィックがトランスポート層を介して特定の方向に誘導される必要があるという意図を表現できます。入力 PE は、サービス ルートのネクスト ホップと BGP Color-EC を使用して、CAR (E、C) ルート上でサービス トラフィックを誘導します。
This is consistent with the automated service route steering on SR Policy (a routing solution providing color-aware paths) defined in [RFC9256]. All the steering variations described in [RFC9256] are applicable to BGP CAR paths: on-demand steering, per-destination steering, per-flow steering, and color-only steering. For brevity, please refer to Section 8 of [RFC9256].
これは、[RFC9256] で定義されている SR ポリシー (色認識パスを提供するルーティング ソリューション) での自動サービス ルート ステアリングと一致しています。[RFC9256] で説明されているすべてのステアリング バリエーション (オンデマンド ステアリング、宛先ごとのステアリング、フローごとのステアリング、およびカラーのみのステアリング) は、BGP CAR パスに適用できます。簡潔さについては、[RFC9256] のセクション 8 を参照してください。
Appendix A provides illustrations of service route automated steering over BGP CAR (E, C) routes.
付録 A では、BGP CAR (E、C) ルート上のサービス ルート自動ステアリングの図を示します。
An egress PE may express its intent that traffic should be steered a certain way through the transport layer by allocating the SRv6 Service SID from a routed intent-aware locator prefix (Section 3.3 of [RFC8986]). Steering at an ingress PE is via resolution of the Service SID over a CAR Type-2 IP Prefix route. Service steering over BGP CAR SRv6 transport is described in Section 7.
出力 PE は、ルーティングされたインテント認識ロケーター プレフィックスから SRv6 サービス SID を割り当てることによって、トラフィックがトランスポート層を介して特定の方向に誘導されるべきであるという意図を表現できます ([RFC8986] のセクション 3.3)。入力 PE でのステアリングは、CAR タイプ 2 IP プレフィックス ルート上のサービス SID の解決によって行われます。BGP CAR SRv6 トランスポートを介したサービス ステアリングについては、セクション 7 で説明します。
Service steering via BGP CAR routes is applicable to any BGP SAFI, including SAFIs for IPv4/IPv6 (SAFI 1), L3VPN (SAFI 128), pseudowire (PW), EVPN (SAFI 70), FlowSpec, and BGP-LU (SAFI 4).
BGP CAR ルート経由のサービス ステアリングは、IPv4/IPv6 (SAFI 1)、L3VPN (SAFI 128)、擬似回線 (PW)、EVPN (SAFI 70)、FlowSpec、および BGP-LU (SAFI 4) の SAFI を含む、あらゆる BGP SAFI に適用できます。
PEs and BRs may support filtering of CAR routes. For instance, the filtering may only accept routes of locally configured colors.
PE および BR は、CAR ルートのフィルタリングをサポートする場合があります。たとえば、フィルタリングはローカルに設定された色のルートのみを受け入れる場合があります。
Techniques such as RT Constrain [RFC4684] may also be applied to the CAR SAFI, where Route Target (RT) Extended Communities [RFC4360] can be used to constrain distribution and automate filtering of CAR routes. RT assignment may be via user policy; for example, an RT value can be assigned to all routes of a specific color.
RT Constrain [RFC4684] などの技術を CAR SAFI に適用することもでき、ルート ターゲット (RT) 拡張コミュニティ [RFC4360] を使用して、CAR ルートの配布を制限し、フィルタリングを自動化できます。RT の割り当てはユーザー ポリシーによって行われる場合があります。たとえば、RT 値を特定の色のすべてのルートに割り当てることができます。
A PE may support on-demand installation of a CAR route based on the presence of a service route whose next hop resolves via the CAR route.
PE は、ネクスト ホップが CAR ルートを介して解決されるサービス ルートの存在に基づいて、CAR ルートのオンデマンド インストールをサポートする場合があります。
Similarly, a PE may dynamically subscribe to receive individual CAR routes from upstream routers or Route Reflectors (RRs) to limit the routes that it needs to learn. On-demand subscription and automated filtering procedures for individual CAR routes are outside the scope of this document.
同様に、PE は、学習する必要があるルートを制限するために、上流のルータまたはルート リフレクタ（RR）から個々の CAR ルートを受信するように動的にサブスクライブできます。個々の CAR ルートのオンデマンド サブスクリプションと自動フィルタリング手順は、このドキュメントの範囲外です。
This section analyzes the key scale requirement of [INTENT-AWARE], specifically:
このセクションでは、[INTENT-AWARE] の鍵スケール要件、具体的には次のように分析します。
* No intermediate node data plane should need to scale to (Colors * PEs).
* 中間ノードのデータ プレーンを (カラー * PE) にスケールする必要はありません。
* No node should learn and install a BGP CAR route to (E, C) if it does not install a colored service route to E.
* E への色付きサービス ルートをインストールしないノードは、BGP CAR ルートを学習して (E、C) にインストールする必要はありません。
While the requirements and design principles generally apply to any transport, the logical analysis based on the network design in this section focuses on MPLS/SR-MPLS transport since the scaling constraints are specifically relevant to these technologies. BGP CAR SAFI is used here, but the considerations can apply to [RFC8277] or [RFC8669] used with MPLS/SR-MPLS.
要件と設計原則は一般にあらゆるトランスポートに適用されますが、スケーリング制約は特にこれらのテクノロジに関連するため、このセクションのネットワーク設計に基づく論理分析では MPLS/SR-MPLS トランスポートに焦点を当てます。ここでは BGP CAR SAFI が使用されていますが、この考慮事項は MPLS/SR-MPLS で使用される [RFC8277] または [RFC8669] にも適用できます。
Two key principles used to address the scaling requirements are a hierarchical network and routing design, and on-demand route subscription and filtering.
スケーリング要件に対処するために使用される 2 つの重要な原則は、階層ネットワークとルーティングの設計、およびオンデマンドのルート サブスクリプションとフィルタリングです。
Figure 2 in Section 5.1 provides an ultra-scale reference topology. Section 5.1 describes this topology. Section 5.2 presents three design models to deploy BGP CAR in the reference topology, including hierarchical options. Section 5.3 analyzes the logical scaling properties of each model.
セクション 5.1 の図 2 は、超大規模なリファレンス トポロジを示しています。セクション 5.1 では、このトポロジについて説明します。セクション 5.2 では、階層オプションを含む、BGP CAR を参照トポロジに導入するための 3 つの設計モデルを示します。セクション 5.3 では、各モデルの論理スケーリング特性を分析します。
Filtering techniques described in the previous section allow a PE to limit the CAR routes that it needs to learn or install. Scaling benefits of on-demand BGP subscription and filtering will be described in a separate document.
前のセクションで説明したフィルタリング手法を使用すると、PE は学習またはインストールする必要がある CAR ルートを制限できます。オンデマンド BGP サブスクリプションとフィルタリングのスケーリング上の利点については、別のドキュメントで説明します。
RD:V/v via E2
+-----+ +-----+ vpn label:30030 +-----+
....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <......
: +-----+ +-----+ Color C1 +-----+ :
: :
: :
: :
+:------------+--------------+--------------+--------------+--------:-+
|: | | | | : |
|: | | | | : |
|: +---+ +---+ +---+ +---+ : |
|: |121| |231| |341| |451| : |
|: +---+ +---+ +---+ +---+ : |
|---+ | | | | +---|
| E1| | | | | | E2|
|---+ | | | | +---|
| +---+ +---+ +---+ +---+ |
| |122| |232| |342| |452| |
| +---+ +---+ +---+ +---+ |
| Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE
Figure 2: Ultra-Scale Reference Topology
図 2: 超スケールのリファレンス トポロジ
The following description applies to the reference topology above:
次の説明は、上記の参照トポロジに適用されます。
* Independent IS-IS/OSPF SR instance in each domain.
* 各ドメインの独立した IS-IS/OSPF SR インスタンス。
* Each domain has Flex-Algo 128. Prefix-SID for a node is Segment Routing Global Block (SRGB) 168000 plus node number.
* 各ドメインには Flex-Algo 128 があります。ノードのプレフィックス SID は、セグメント ルーティング グローバル ブロック (SRGB) 168000 にノード番号を加えたものです。
* A BGP CAR route (E2, C1) is advertised by egress BRM node 451. The route is sourced locally from redistribution from IGP Flex-Algo 128.
* BGP CAR ルート (E2、C1) は、出力 BRM ノード 451 によってアドバタイズされます。ルートは、IGP Flex-Algo 128 からの再配布によってローカルに供給されます。
* Not shown for simplicity, node 452 will also advertise (E2, C1).
* 簡単にするために示されていませんが、ノード 452 もアドバタイズします (E2、C1)。
* When a transport RR (T-RR) is used within the domain or across domains, ADD-PATH is enabled to advertise paths from both egress BRs to its clients.
* トランスポート RR (T-RR) がドメイン内またはドメイン間で使用される場合、ADD-PATH が有効になり、両方の出力 BR からそのクライアントにパスをアドバタイズします。
* Egress PE E2 advertises a VPN route RD:V/v with BGP Color-EC C1 that propagates via service RRs to ingress PE E1.
* 出力 PE E2 は、サービス RR を介して入力 PE E1 に伝播する、BGP Color-EC C1 を使用して VPN ルート RD:V/v をアドバタイズします。
* E1 steers V/v prefix via color-aware path (E2, C1) and VPN label 30030.
* E1 は、色認識パス (E2、C1) および VPN ラベル 30030 を介して V/v プレフィックスを制御します。
RD:V/v via E2
+-----+ +-----+ vpn label:30030 +-----+
....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <......
: +-----+ +-----+ Color C1 +-----+ :
: :
: :
: :
+:------------+--------------+--------------+--------------+--------:-+
|: | | | | : |
|: | (E2,C1) | (E2,C1) | (E2,C1) | : |
|: +---+ via 231 +---+ via 341 +---+ via 451 +---+ : |
|:(E2,C1) |121|<---------|231|<---------|341|<---------|451| : |
|: via 121 /+---+ L=168002 +---+ L=168002 +---+ L=168002 +---+ : |
|---+ / | | | | +---|
| E1| <--/ | | | | | E2|
|---+ L=168002| | | | +---|
| +---+ +---+ +---+ +---+ |
| |122| |232| |342| |452| |
| +---+ +---+ +---+ +---+ |
| Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE
168121 168231 168341 168451
168002 168002 168002 168002 168002
30030 30030 30030 30030 30030 30030
Figure 3: Flat Transport Network Design
図 3: フラットなトランスポート ネットワーク設計
* Node 451 advertises BGP CAR route (E2, C1) to 341, from which it goes to 231, then to 121, and finally to E1.
* ノード 451 は、BGP CAR ルート (E2、C1) を 341 にアドバタイズし、そこから 231、次に 121、最後に E1 に進みます。
* Each BGP hop allocates local label and programs swap entry in forwarding for (E2, C1).
* 各 BGP ホップはローカル ラベルを割り当て、(E2、C1) の転送でスワップ エントリをプログラムします。
* E1 receives BGP CAR route (E2, C1) via 121 with label 168002.
* E1 は、121 経由でラベル 168002 の BGP CAR ルート (E2、C1) を受信します。
- Let's assume E1 selects that path.
- E1 がそのパスを選択すると仮定します。
* E1 resolves BGP CAR route (E2, C1) via 121 on color-aware path (121, C1).
* E1 は、色認識パス (121、C1) 上の 121 を介して BGP CAR ルート (E2、C1) を解決します。
- Color-aware path (121, C1) is Flex-Algo 128 path to 121 (label 168121).
- カラー認識パス (121、C1) は、121 への Flex-Algo 128 パス (ラベル 168121) です。
* E1's imposition color-aware label stack for V/v is thus:
* E1 の V/v 用の面付けカラー認識ラベル スタックは次のようになります。
- 30030 <=> V/v
- 30030 <=> V/v
- 168002 <=> (E2, C1)
- 168002 <=> (E2、C1)
- 168121 <=> (121, C1)
- 168121 <=> (121、C1)
* Each BGP hop performs swap operation on 168002 bound to color-aware path (E2, C1).
* 各 BGP ホップは、カラー対応パス (E2、C1) にバインドされた 168002 でスワップ操作を実行します。
(E2,C1)
+-----+ via 451 +-----+
|T-RR1| <-------------- |T-RR2|
/ +-----+ L=168002 +-----+\
/ \
+-------------+---/----------+--------------+-----------\--+----------+
| | / | | \ | |
| (E2,C1) | / (451,C1) | (451,C1) | \| |
| via 121 +---+ via 231 +---+ via 341 +---+ +---+ |
| L=168002 |121| <======= |231| <========|341| <======= |451| |
| / +---+ L=168451 +---+ L=168451 +---+ +---+ |
|---+ / | | | | +---|
| E1|<--/ | | | | | E2|
|---+ | | | | +---|
| +---+ +---+ +---+ +---+ |
| |122| |232| |342| |452| |
| +---+ +---+ +---+ +---+ |
| Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE
168231 168341
168121 168451 168451 168451
168002 168002 168002 168002 168002
30030 30030 30030 30030 30030 30030
Figure 4: Hierarchical BGP Transport CAR, Next-Hop-Self (NHS) at iBR
図 4: iBR での階層型 BGP トランスポート CAR、ネクストホップセルフ (NHS)
* Node 451 advertises BGP CAR route (451, C1) to 341, from which it goes to 231, and finally to 121.
* ノード 451 は、BGP CAR ルート (451、C1) を 341 にアドバタイズし、そこから 231 に進み、最後に 121 に進みます。
* Each BGP hop allocates local label and programs swap entry in forwarding for (451, C1).
* 各 BGP ホップはローカル ラベルを割り当て、(451、C1) の転送でスワップ エントリをプログラムします。
* 121 resolves received BGP CAR route (451, C1) via 231 (label 168451) on color-aware path (231, C1).
* 121 は、色認識パス (231、C1) 上の 231 (ラベル 168451) を介して、受信した BGP CAR ルート (451、C1) を解決します。
- Color-aware path (231, C1) is Flex-Algo 128 path to 231 (label 168231).
- カラー認識パス (231、C1) は、231 への Flex-Algo 128 パス (ラベル 168231) です。
* 451 advertises BGP CAR route (E2, C1) via 451 to T-RR2, which reflects it to T-RR1, which reflects it to 121.
* 451 は、451 経由で BGP CAR ルート (E2、C1) を T-RR2 にアドバタイズし、T-RR2 がそれを T-RR1 に反映し、T-RR1 が 121 に反映します。
* 121 receives BGP CAR route (E2, C1) via 451 with label 168002.
* 121 は、ラベル 168002 を持つ 451 経由で BGP CAR ルート (E2、C1) を受信します。
- Let's assume 121 selects that path.
- 121 がそのパスを選択すると仮定します。
* 121 resolves BGP CAR route (E2, C1) via 451 on color-aware path (451, C1).
* 121 は、カラー対応パス (451、C1) 上の 451 を介して BGP CAR ルート (E2、C1) を解決します。
- Color-aware path (451, C1) is BGP CAR path to 451 (label 168451).
- カラー対応パス (451、C1) は、451 (ラベル 168451) への BGP CAR パスです。
* 121 imposition of color-aware label stack for (E2, C1) is thus:
* したがって、(E2、C1) の色認識ラベル スタックの 121 の面付けは次のようになります。
- 168002 <=> (E2, C1)
- 168002 <=> (E2、C1)
- 168451 <=> (451, C1)
- 168451 <=> (451、C1)
- 168231 <=> (231, C1)
- 168231 <=> (231、C1)
* 121 advertises (E2, C1) to E1 with next-hop-self (121) and label 168002.
* 121 は、next-hop-self (121) およびラベル 168002 を使用して (E2、C1) を E1 にアドバタイズします。
* E1 constructs same imposition color-aware label stack for V/v via (E2, C1) as in the flat model:
* E1 は、フラット モデルと同じように、(E2、C1) を介して V/v の面付けカラー対応ラベル スタックを構築します。
- 30030 <=> V/v
- 30030 <=> V/v
- 168002 <=> (E2, C1)
- 168002 <=> (E2、C1)
- 168121 <=> (121, C1)
- 168121 <=> (121、C1)
* 121 performs swap operation on 168002 with hierarchical color-aware label stack for (E2, C1) via 451 from step 7.
* 121 は、ステップ 7 の 451 を介して、(E2, C1) の階層型色認識ラベル スタックを使用して 168002 に対してスワップ操作を実行します。
* Nodes 231 and 341 perform swap operation on 168451 bound to color-aware path (451, C1).
* ノード 231 と 341 は、色対応パス (451、C1) にバインドされた 168451 に対してスワップ操作を実行します。
* 451 performs swap operation on 168002 bound to color-aware path (E2, C1).
* 451 は、色対応パス (E2、C1) にバインドされた 168002 に対してスワップ操作を実行します。
Note: E1 does not need the BGP CAR route (451, C1) in this design.
注: この設計では、E1 に BGP CAR ルート (451、C1) は必要ありません。
(E2,C1)
+-----+ via 451 +-----+
|T-RR1| <-------------- |T-RR2|
/ +-----+ L=168002 +-----+\
/ \
+-------------+---/----------+--------------+-----------\--+----------+
| | / | | \ | |
| (E2,C1) | / (451,C1) | (451,C1) | \| |
| via 451 +---+ via 231 +---+ via 341 +---+ +---+ |
| L=168002/|121| <======= |231| <========|341| <======= |451| |
| / +---+ L=168451 +---+ L=168451 +---+ +---+ |
|---+ <--/ //| | | | +---|
| E1| // | | | | | E2|
|---+ <===// | | | | +---|
| (451,C1) +---+ +---+ +---+ +---+ |
| via 121 |122| |232| |342| |452| |
| L=168451 +---+ +---+ +---+ +---+ |
| | | | | |
| Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE
168121 168231 168341
168451 168451 168451 168451
168002 168002 168002 168002 168002
30030 30030 30030 30030 30030 30030
Figure 5: Hierarchical BGP Transport CAR, Next-Hop-Unchanged (NHU) at iBR
図 5: iBR での階層型 BGP トランスポート CAR、Next-Hop-Unchanged (NHU)
* Nodes 341, 231, and 121 receive and resolve BGP CAR route (451, C1) the same as in the previous model.
* ノード 341、231、および 121 は、以前のモデルと同様に BGP CAR ルート (451、C1) を受信して解決します。
* Node 121 allocates local label and programs swap entry in forwarding for (451, C1).
* ノード 121 は、ローカル ラベルを割り当て、(451、C1) の転送でスワップ エントリをプログラムします。
* 451 advertises BGP CAR route (E2, C1) to T-RR2, which reflects it to T-RR1, which reflects it to 121.
* 451 は BGP CAR ルート (E2、C1) を T-RR2 にアドバタイズし、T-RR2 はそれを T-RR1 に反映し、T-RR1 はそれを 121 に反映します。
* Node 121 advertises (E2, C1) to E1 with next hop as 451 (i.e., next-hop-unchanged).
* ノード 121 は、ネクスト ホップ 451 (つまり、ネクスト ホップ変更なし) で (E2, C1) を E1 にアドバタイズします。
* 121 also advertises (451, C1) to E1 with next-hop-self (121) and label 168451.
* 121 はまた、next-hop-self (121) とラベル 168451 を使用して (451, C1) を E1 にアドバタイズします。
* E1 resolves BGP CAR route (451, C1) via 121 on color-aware path (121, C1).
* E1 は、色認識パス (121、C1) 上の 121 を介して BGP CAR ルート (451、C1) を解決します。
- Color-aware path (121, C1) is Flex-Algo 128 path to 121 (label 168121).
- カラー認識パス (121、C1) は、121 への Flex-Algo 128 パスです (ラベル 168121)。
* E1 receives BGP CAR route (E2, C1) via 451 with label 168002.
* E1 は、ラベル 168002 の 451 経由で BGP CAR ルート (E2、C1) を受信します。
- Let's assume E1 selects that path.
- E1 がそのパスを選択すると仮定します。
* E1 resolves BGP CAR route (E2, C1) via 451 on color-aware path (451, C1).
* E1 は、色認識パス (451、C1) 上の 451 を介して BGP CAR ルート (E2、C1) を解決します。
- Color-aware path (451, C1) is BGP CAR path to 451 (label 168451).
- カラー対応パス (451、C1) は、451 (ラベル 168451) への BGP CAR パスです。
* E1's imposition color-aware label stack for V/v is thus:
* E1 の V/v 用の面付けカラー認識ラベル スタックは次のようになります。
- 30030 <=> V/v
- 30030 <=> V/v
- 168002 <=> (E2, C1)
- 168002 <=> (E2、C1)
- 168451 <=> (451, C1)
- 168451 <=> (451、C1)
- 168121 <=> (121, C1)
- 168121 <=> (121、C1)
* Nodes 121, 231, and 341 perform swap operation on 168451 bound to (451, C1).
* ノード 121、231、および 341 は、(451, C1) にバインドされた 168451 に対してスワップ操作を実行します。
* 451 performs swap operation on 168002 bound to color-aware path (E2, C1).
* 451 は、色対応パス (E2、C1) にバインドされた 168002 に対してスワップ操作を実行します。
The following two tables summarize the logically analyzed scaling of the control plane and data plane for the previous three models:
次の 2 つの表は、前の 3 つのモデルのコントロール プレーンとデータ プレーンの論理的に分析されたスケーリングをまとめたものです。
+=======+=====================+=====================+=============+
| | E1 | 121 | 231 |
+=======+=====================+=====================+=============+
| FLAT | (E2,C) via (121,C) | (E2,C) via (231,C) | (E2,C) via |
| | | | (341,C) |
+=======+---------------------+---------------------+-------------+
| H.NHS | (E2,C) via (121,C) | (E2,C) via (451,C) | (451,C) via |
| | | (451,C) via (231,C) | (341,C) |
+=======+---------------------+---------------------+-------------+
| H.NHU | (E2,C) via (451,C) | (451,C) via (231,C) | (451,C) via |
| | (451,C) via (121,C) | | (341,C) |
+=======+---------------------+---------------------+-------------+
Table 1
+=======+============+==================+==================+
| | E1 | 121 | 231 |
+=======+============+==================+==================+
| FLAT | V -> 30030 | 168002 -> 168002 | 168002 -> 168002 |
| | 168002 | 168231 | 168341 |
| | 168121 | | |
+=======+------------+------------------+------------------+
| H.NHS | V -> 30030 | 168002 -> 168002 | 168451 -> 168451 |
| | 168002 | 168451 | 168341 |
| | 168121 | 168231 | |
+=======+------------+------------------+------------------+
| H.NHU | V -> 30030 | 168451 -> 168451 | 168451 -> 168451 |
| | 168002 | 168231 | 168341 |
| | 168451 | | |
| | 168121 | | |
+=======+------------+------------------+------------------+
Table 2
* The flat model is the simplest design, with a single BGP transport level. It results in the minimum label/SID stack at each BGP hop. However, it significantly increases the scale impact on the core BRs (e.g., 341), whose FIB capacity and even MPLS label space may be exceeded.
* フラット モデルは、単一の BGP トランスポート レベルを備えた最も単純な設計です。これにより、各 BGP ホップでの最小ラベル/SID スタックが得られます。ただし、FIB 容量や MPLS ラベル スペースさえも超過する可能性がある、コア BR (例: 341) への規模への影響が大幅に増加します。
- 341's data plane scales with (E2, C) where there may be 300k Es and 5 Cs, hence 1.5M entries > 1M MPLS data plane.
- 341 のデータ プレーンは (E2, C) でスケールされます。この場合、300k の Es と 5 つの C が存在する可能性があるため、1.5M エントリ > 1M MPLS データ プレーンとなります。
* The hierarchical models avoid the need for core BRs to learn routes and install label forwarding entries for (E, C) routes.
* 階層モデルにより、コア BR がルートを学習し、(E、C) ルートのラベル転送エントリをインストールする必要がなくなります。
- Whether next hop is set to self or left unchanged at 121, 341's data plane scales with (451, C) where there may be thousands of 451s and 5 Cs. Therefore, this scaling is well under the 1 million MPLS labels data plane limit.
- ネクスト ホップが self に設定されるか、121 で変更されないままにされるかにかかわらず、341 のデータ プレーンは (451, C) に合わせて調整されます。この場合、数千の 451 と 5 C が存在する可能性があります。したがって、このスケーリングは 100 万 MPLS ラベルのデータ プレーン制限を大幅に下回ります。
- They also aid faster convergence by allowing the PE routes to be distributed via out-of-band RRs that can be scaled independent of the transport BRs.
- また、トランスポート BR から独立して拡張できる帯域外 RR を介して PE ルートを分散できるため、コンバージェンスの高速化にも役立ちます。
* The next-hop-self option at ingress BRM (e.g., 121) hides the hierarchical design from the ingress PE, keeping its outgoing label programming as simple as the flat model. However, the ingress BRM requires an additional BGP transport level recursion, which coupled with load-balancing adds data plane complexity. It needs to support a swap and push operation. It also needs to install label forwarding entries for the egress PEs that are of interest to its local ingress PEs.
* 入力 BRM の next-hop-self オプション (例: 121) は、階層設計を入力 PE から隠し、発信ラベル プログラミングをフラット モデルと同じくらい単純に保ちます。ただし、入力 BRM には追加の BGP トランスポート レベルの再帰が必要であり、ロード バランシングと組み合わせるとデータ プレーンの複雑さが増加します。スワップおよびプッシュ操作をサポートする必要があります。また、ローカル入力 PE にとって関係のある出力 PE のラベル転送エントリをインストールする必要もあります。
* With the next-hop-unchanged option at ingress BRM (e.g., 121), only an ingress PE needs to learn and install output label entries for egress (E, C) routes. The ingress BRM only installs label forwarding entries for the egress ABR (e.g., 451). However, the ingress PE needs an additional BGP transport level recursion and pushes a BGP VPN label and two BGP transport labels. It may also need to handle load-balancing for the egress ABRs. This is the most complex data plane option for the ingress PE.
* 入力 BRM (例: 121) でネクストホップ不変更オプションを使用すると、入力 PE のみが出力 (E、C) ルートの出力ラベル エントリを学習してインストールする必要があります。入力 BRM は、出力 ABR (例: 451) のラベル転送エントリのみをインストールします。ただし、入力 PE は追加の BGP トランスポート レベルの再帰を必要とし、BGP VPN ラベルと 2 つの BGP トランスポート ラベルをプッシュします。また、出力 ABR の負荷分散を処理する必要がある場合もあります。これは、入力 PE の最も複雑なデータ プレーン オプションです。
This section describes how Anycast SID complements and improves the scaling designs above.
このセクションでは、エニーキャスト SID が上記のスケーリング設計をどのように補完および改善するかについて説明します。
* Redundant BRs (e.g., two egress BRMs, 451 and 452) advertise BGP CAR routes for a local PE (e.g., E2) with the same SID (based on label index). Such egress BRMs may be assigned a common Anycast SID, so that the BGP next hops for these routes will also resolve via a color-aware path to the Anycast SID.
* 冗長 BR (例: 2 つの出力 BRM、451 および 452) は、同じ SID (ラベル インデックスに基づく) を持つローカル PE (例: E2) の BGP CAR ルートをアドバタイズします。このような出力 BRM には共通のエニーキャスト SID が割り当てられるため、これらのルートの BGP ネクスト ホップもエニーキャスト SID への色認識パス経由で解決されます。
* The use of Anycast SID naturally provides fast local convergence upon failure of an egress BRM node. In addition, it decreases the recursive resolution and load-balancing complexity at an ingress BRM or PE in the hierarchical designs above.
* エニーキャスト SID を使用すると、出力 BRM ノードの障害時に高速なローカル コンバージェンスが自然に提供されます。さらに、上記の階層設計における入力 BRM または PE での再帰的解決とロード バランシングの複雑さが軽減されます。
The common Anycast SID technique may also be used for a redundant pair of PEs that share an identical set of service (VPN) attachments.
共通のエニーキャスト SID 技術は、同一のサービス (VPN) アタッチメントのセットを共有する PE の冗長ペアにも使用できます。
* For example, assume a node E2' is paired with E2 above (e.g., Figure 5). Both PEs should be configured with the same static label/SID for the services (e.g., per-VRF VPN label/SID), and will advertise associated service routes with the Anycast IP as BGP next hop.
* たとえば、ノード E2' が上記の E2 とペアになっていると仮定します (たとえば、図 5)。両方の PE は、サービスに対して同じ静的ラベル/SID（VRF ごとの VPN ラベル/SID など）を使用して設定する必要があり、BGP ネクスト ホップとしてエニーキャスト IP を使用して関連するサービス ルートをアドバタイズします。
* This design provides a convergence and recursive resolution benefit on an ingress PE or ABR similar to the egress ABR case in Section 5.4.1. However, its applicability is limited to cases where the above constraints can be met.
* この設計は、セクション 5.4.1 の出力 ABR の場合と同様に、入力 PE または ABR でのコンバージェンスと再帰的解決の利点を提供します。ただし、その適用は上記の制約を満たす場合に限定されます。
BGP CAR leverages existing well-known design techniques to provide fast convergence.
BGP CAR は、既存のよく知られた設計手法を活用して、高速コンバージェンスを提供します。
Section 2.7 describes how BGP CAR provides localized convergence within a domain for BR failures, including originating BRs, without propagating failure churn into other domains.
セクション 2.7 では、BGP CAR が、障害チャーンを他のドメインに伝播させることなく、発信元の BR を含む BR 障害に対してドメイン内で局所的なコンバージェンスを提供する方法について説明します。
Anycast SID techniques described in Section 5.4 can provide further convergence optimizations for BR and PE failures deployed in redundant designs.
セクション 5.4 で説明するエニーキャスト SID 技術は、冗長設計に導入された BR および PE の障害に対するさらなるコンバージェンスの最適化を提供できます。
Steering services over SRv6-based intent-aware multi-domain transport paths may be categorized into two distinct cases that are described in Section 5 of [RFC9252]. Both cases are supported by BGP CAR, as described below.
SRv6 ベースのインテントアウェア マルチドメイン トランスポート パスを介したステアリング サービスは、[RFC9252] のセクション 5 で説明されている 2 つの異なるケースに分類できます。以下で説明するように、両方のケースが BGP CAR によってサポートされます。
The SRv6 Service SID that is advertised with a service route is allocated by an egress PE from a routed intent-aware locator prefix (Section 3.3 of [RFC8986]). Service steering at an ingress PE is via resolution of the Service SID signaled with the service route as described in [RFC9252].
サービス ルートでアドバタイズされる SRv6 サービス SID は、ルーティングされたインテントアウェア ロケータ プレフィックスから出力 PE によって割り当てられます ([RFC8986] のセクション 3.3)。入口 PE でのサービス ステアリングは、[RFC9252] で説明されているように、サービス ルートで通知されるサービス SID の解決を介して行われます。
The intent-aware transport path to the SRv6 locator of the egress PE is provided by underlay IP routing. Underlay IP routing can include IGP Flexible Algorithm [RFC9350] within a domain, and BGP CAR (as defined in this document) across multiple IGP domains or BGP ASes.
出力 PE の SRv6 ロケーターへのインテントアウェア トランスポート パスは、アンダーレイ IP ルーティングによって提供されます。アンダーレイ IP ルーティングには、ドメイン内の IGP フレキシブル アルゴリズム [RFC9350]、および複数の IGP ドメインまたは BGP AS にわたる BGP CAR (この文書で定義されている) を含めることができます。
An SRv6 locator prefix is assigned for a given intent or color. The SRv6 locator may be shared with an IGP Flexible Algorithm, or it may be assigned specific to BGP CAR for a given intent.
SRv6 ロケーター プレフィックスは、特定のインテントまたはカラーに割り当てられます。SRv6 ロケータは、IGP フレキシブル アルゴリズムと共有することも、特定のインテントに対して BGP CAR に固有に割り当てることもできます。
Distribution of SRv6 locators in BGP CAR SAFI:
BGP CAR SAFI における SRv6 ロケーターの配布:
* In a multi-domain network, the SRv6 locator prefix is distributed using BGP CAR SAFI to ingress PEs and ASBRs in a remote domain. The SRv6 locator prefix may be advertised in the BGP CAR SAFI from an egress PE, or redistributed into BGP CAR from an IGP Flex-Algo at a BR. The locator prefix may also be summarized on a border node along the path and a summary route distributed to ingress PEs.
* マルチドメイン ネットワークでは、SRv6 ロケータ プレフィックスは BGP CAR SAFI を使用して配布され、リモート ドメインの PE および ASBR に入力されます。SRv6 ロケータ プレフィックスは、出力 PE から BGP CAR SAFI でアドバタイズされるか、BR の IGP Flex-Algo から BGP CAR に再配布される場合があります。ロケータ プレフィックスは、パスに沿った境界ノード上で集約され、集約ルートが入力 PE に配布されることもあります。
* An IP Prefix CAR route (Type-2) is defined to distribute SRv6 locator prefixes and described in Sections 2.9.4 and 8.
* IP プレフィックス CAR ルート (タイプ 2) は、SRv6 ロケーター プレフィックスを配布するために定義されており、セクション 2.9.4 および 8 で説明されています。
* A BGP CAR advertised SRv6 locator prefix may also be used for resolution of the SRv6 Service SID advertised for best-effort connectivity.
* BGP CAR でアドバタイズされる SRv6 ロケーター プレフィックスは、ベスト エフォート接続用にアドバタイズされる SRv6 サービス SID の解決にも使用できます。
Appendices C.1 and C.2 illustrate the control, and forwarding behaviors for routed SRv6 Service SIDs.
付録 C.1 および C.2 は、ルーティングされた SRv6 サービス SID の制御および転送動作を示しています。
Section 7.2 describes the deployment options.
セクション 7.2 では、展開オプションについて説明します。
Section 7.3 describes operational considerations of using BGP CAR SAFI versus BGP IPv6 SAFI for inter-domain route distribution of SRv6 locators.
セクション 7.3 では、SRv6 ロケーターのドメイン間ルート分散に BGP CAR SAFI を使用する場合と BGP IPv6 SAFI を使用する場合の運用上の考慮事項について説明します。
The SRv6 Service SID allocated by an egress PE is not routed. The service route carrying the non-routed SRv6 Service SID is advertised by the egress PE with a Color-EC C ([RFC9252], Section 5). An ingress PE in a remote domain steers traffic for the received service route with Color-EC C and this SRv6 Service SID as described below.
出力 PE によって割り当てられた SRv6 サービス SID はルーティングされません。非ルーティング SRv6 サービス SID を運ぶサービス ルートは、出力 PE によって Color-EC C ([RFC9252]、セクション 5) でアドバタイズされます。リモート ドメインの入力 PE は、以下で説明するように、Color-EC C とこの SRv6 サービス SID を使用して、受信したサービス ルートのトラフィックを制御します。
BGP CAR distribution of (E, C) underlay route:
(E、C) アンダーレイ ルートの BGP CAR 配布:
* The intent-aware path to the egress PE within the egress domain is provided by an SR-TE or similar policy (E, C) [RFC9256]. This (E, C) policy is distributed into the multi-domain network from egress BRs using a BGP CAR (E, C) route towards ingress PEs in other domains. This signaling is the same as for SR-MPLS as described in earlier sections.
* 出力ドメイン内の出力 PE へのインテントアウェア パスは、SR-TE または同様のポリシー (E、C) [RFC9256] によって提供されます。この (E、C) ポリシーは、BGP CAR (E、C) ルートを使用して、他のドメインの入力 PE に向かう出力 BR からマルチドメイン ネットワークに配布されます。このシグナリングは、前のセクションで説明した SR-MPLS の場合と同じです。
* The (E, C) BGP CAR Type-1 route is advertised from a BR with an SRv6 transport SID allocated from an SRv6 locator assigned for the intent C. An SR-PCE or local configuration may ensure multiple BRs in the egress domain that originate the (E, C) route advertise the same SRv6 transport SID.
* (E、C) BGP CAR タイプ 1 ルートは、インテント C に割り当てられた SRv6 ロケーターから割り当てられた SRv6 トランスポート SID を持つ BR からアドバタイズされます。 SR-PCE またはローカル設定により、(E、C) ルートを発信する出力ドメイン内の複数の BR が同じ SRv6 トランスポート SID をアドバタイズすることが保証される場合があります。
BGP CAR distribution of SRv6 locator underlay route:
SRv6 ロケーター アンダーレイ ルートの BGP CAR 配布:
* BGP CAR MAY also provide the underlay intent-aware inter-domain route to resolve the intent-aware SRv6 transport SID advertised with the (E, C) BGP CAR route as follows:
* BGP CAR は、次のように、(E、C) BGP CAR ルートでアドバタイズされたインテントアウェア SRv6 トランスポート SID を解決するために、アンダーレイ インテントアウェア ドメイン間ルートを提供してもよい(MAY)。
- An egress domain BR has an SRv6 locator prefix that covers the SRv6 transport SID allocated by the egress BR for the (E, C) BGP CAR route.
- 出力ドメイン BR には、(E, C) BGP CAR ルートの出力 BR によって割り当てられた SRv6 トランスポート SID をカバーする SRv6 ロケーター プレフィックスがあります。
- The egress domain BR advertises an IP Prefix Type-2 CAR route for the SRv6 locator prefix, and the route is distributed across BGP hops in the underlay towards ingress PEs. This distribution is the same as the previous case in Section 7.1.1. The route may also be summarized in another CAR Type-2 route prefix.
- 出力ドメイン BR は、SRv6 ロケーター プレフィックスの IP プレフィックス タイプ 2 CAR ルートをアドバタイズし、ルートは入力 PE に向けてアンダーレイ内の BGP ホップ全体に分散されます。この分布は、セクション 7.1.1 の前のケースと同じです。ルートは、別の CAR Type-2 ルート プレフィックスに要約される場合もあります。
Service traffic steering and SRv6 transport SID resolution at ingress PE:
入力 PE でのサービス トラフィック ステアリングと SRv6 トランスポート SID 解決:
* An ingress PE in a remote domain resolves the received service route with color C via the (E, C) BGP CAR route above, as described in Section 3.
* リモート ドメインの入力 PE は、セクション 3 で説明されているように、上記の (E, C) BGP CAR ルートを介して色 C で受信したサービス ルートを解決します。
* Additionally, the ingress PE resolves the SRv6 transport SID received in the BGP CAR (E, C) route via the BGP CAR IP Prefix route, similar to the SRv6 Routed Service SID resolution in Section 7.1.1.
* さらに、入力 PE は、セクション 7.1.1 の SRv6 ルーテッド サービス SID 解決と同様に、BGP CAR IP プレフィックス ルートを介して、BGP CAR (E、C) ルートで受信した SRv6 トランスポート SID を解決します。
- Multiple (E, C) routes may resolve via a single IP Prefix CAR route.
- 複数の (E、C) ルートは、単一の IP プレフィックス CAR ルートを介して解決される場合があります。
o Resolution of (E, C) routes over IP Prefix CAR routes is the typical resolution order as the IP Prefix route provides intent-aware reachability to the BRs that advertise the (E, C) specific routes for each egress PE. However, there can be use cases where an IP Prefix CAR route may resolve via a (E, C) route.
o IP プレフィックス ルートは、各出力 PE の (E、C) 特定のルートをアドバタイズする BR にインテントアウェアな到達可能性を提供するため、IP プレフィックス CAR ルートを介した (E、C) ルートの解決は一般的な解決順序です。ただし、IP プレフィックス CAR ルートが (E, C) ルート経由で解決されるユースケースが存在する可能性があります。
* The ingress PE via the recursive resolution above builds the packet encapsulation that contains the SRv6 Service SID and the received (E, C) route's SRv6 transport SID in the SID list.
* 入力 PE は、上記の再帰的解決を介して、SRv6 サービス SID と受信した (E、C) ルートの SRv6 トランスポート SID を SID リストに含むパケット カプセル化を構築します。
Appendix C.3 contains an example that illustrates the control plane distribution, recursive resolution and forwarding behaviors described above.
付録 C.3 には、上記のコントロール プレーンの配布、再帰的解決、および転送動作を示す例が含まれています。
Note: An SR Policy may also be defined for multi-domain end to end [RFC9256], independent of BGP CAR. In that case, both BGP CAR and SR-TE inter-domain paths may be available at an ingress PE for an (E, C) route (Section 1.2).
注: SR ポリシーは、BGP CAR とは独立して、マルチドメインのエンドツーエンド [RFC9256] に対して定義することもできます。その場合、BGP CAR と SR-TE の両方のドメイン間パスが、(E, C) ルートの入力 PE で利用可能になる可能性があります (セクション 1.2)。
Since an SRv6 locator (or summary) is an IPv6 prefix, it will be installed into the IPv6 forwarding table on a BGP router (e.g., ABR or ASBR) for packet forwarding. With the use of IPv6 locator prefixes, there is no need to allocate and install per-PE SIDs on each BGP hop to forward packets.
SRv6 ロケーター (またはサマリー) は IPv6 プレフィックスであるため、パケット転送のために BGP ルーター (ABR または ASBR など) 上の IPv6 転送テーブルにインストールされます。IPv6 ロケーター プレフィックスを使用すると、パケットを転送するために各 BGP ホップに PE ごとの SID を割り当ててインストールする必要がなくなります。
A few options to forward packets for BGP SRv6 prefixes described in [SRv6-INTERWORK] also apply to BGP CAR. These options are described in Sections 7.2.1 and 7.2.2.
[SRv6-INTERWORK] で説明されている BGP SRv6 プレフィックスのパケットを転送するためのいくつかのオプションは、BGP CAR にも適用されます。これらのオプションについては、セクション 7.2.1 および 7.2.2 で説明します。
This option employs hop-by-hop IPv6 lookup and forwarding on both BRs and P nodes in a domain along the path of propagation of BGP CAR routes. This option's procedures include the following:
このオプションでは、BGP CAR ルートの伝播パスに沿ったドメイン内の BR ノードと P ノードの両方でホップバイホップの IPv6 ルックアップと転送が使用されます。このオプションの手順には次のものが含まれます。
* In addition to BRs, P nodes within a domain also learn BGP CAR IP Prefix routes (for SRv6) and install them into the forwarding table.
* BR に加えて、ドメイン内の P ノードも BGP CAR IP プレフィックス ルート (SRv6 の場合) を学習し、それらを転送テーブルにインストールします。
* BGP routing is enabled on all internal nodes (iBGP) using full-mesh or an RR.
* BGP ルーティングは、フルメッシュまたは RR を使用してすべての内部ノード (iBGP) で有効になります。
* BRs distribute external BGP SRv6 routes to internal peers including P routers, with the following conditions:
* BR は、次の条件で、外部 BGP SRv6 ルートを P ルーターを含む内部ピアに配布します。
- the external BGP next hop is advertised unchanged to the internal peers;
- 外部 BGP ネクスト ホップは変更されずに内部ピアにアドバタイズされます。
- internal nodes use recursive resolution via IGP at each hop to forward IPv6 packets towards the external BGP next hop; and
- 内部ノードは、各ホップで IGP 経由の再帰的解決を使用して、IPv6 パケットを外部 BGP ネクスト ホップに転送します。そして
- resolution is per intent/color (e.g., via IGP IPv6 Flex-Algo).
- 解像度はインテント/カラーごとです (例: IGP IPv6 Flex-Algo 経由)。
This design is illustrated with an example in Appendix C.1.
この設計は、付録 C.1 の例で説明されています。
The benefits of this scheme are:
このスキームの利点は次のとおりです。
* A simpler design, as no tunnel encapsulation is required between BRs in a domain.
* ドメイン内の BR 間でトンネルのカプセル化が必要ないため、設計がシンプルになります。
* No per-PE SID allocation and installation on any BGP hop.
* PE ごとの SID の割り当てや BGP ホップへのインストールは必要ありません。
* This design is similar to the well-known Internet / BGP hop-by-hop IP routing model and can support large-scale route distribution.
* この設計は、よく知られているインターネット/BGP ホップバイホップ IP ルーティング モデルに似ており、大規模なルート分散をサポートできます。
* In addition, since SRv6 locator prefixes can be summarized, this minimizes the number of routes, and hence the scale requirements on P routers.
* さらに、SRv6 ロケーター プレフィックスを要約できるため、ルートの数が最小限に抑えられ、P ルーターのスケール要件が最小限に抑えられます。
In this design, IPv6 lookup and forwarding for BGP SRv6 prefixes are only done on BGP BRs. This option includes the following procedures:
この設計では、BGP SRv6 プレフィックスの IPv6 ルックアップと転送は BGP BR でのみ行われます。このオプションには次の手順が含まれます。
* These nodes use SRv6 (or other) encapsulations to reach the BGP SRv6 next hop.
* これらのノードは、SRv6 (または他の) カプセル化を使用して、BGP SRv6 ネクスト ホップに到達します。
- SRv6 outer encapsulation may be H.Encaps.Red.
- SRv6 の外部カプセル化は H.Encaps.Red である可能性があります。
- Encapsulation is not needed for directly connected next hops, such as with eBGP single-hop sessions.
- eBGP シングルホップ セッションなど、直接接続されたネクスト ホップにはカプセル化は必要ありません。
* BGP route distribution is enabled between BRs via RRs, or directly if single-hop BGP.
* BGP ルート配布は、RR 経由で BR 間で有効になります。シングルホップ BGP の場合は直接的に有効になります。
* An egress BR sets itself as BGP next hop, and selects and advertises an appropriate encapsulation towards itself.
* 出力 BR は、自身を BGP ネクスト ホップとして設定し、自身に向けた適切なカプセル化を選択してアドバタイズします。
- If SRv6 encapsulation, then the SRv6 SID advertised from egress BR is from an SRv6 locator for the specific intent within the domain. Multiple BGP SRv6 prefixes may share a common SID, avoiding per-PE SID allocation and installation on any BGP hop.
- SRv6 カプセル化の場合、出力 BR からアドバタイズされる SRv6 SID は、ドメイン内の特定のインテントの SRv6 ロケーターからのものです。複数の BGP SRv6 プレフィックスは共通の SID を共有することができ、PE ごとの SID の割り当てや BGP ホップへのインストールを回避できます。
- If MPLS/SR-MPLS transport, the route will carry the label/ Prefix-SID allocated by the next hop. The label/SID may be shared among multiple routes.
- MPLS/SR-MPLS トランスポートの場合、ルートはネクスト ホップによって割り当てられたラベル/プレフィックス SID を伝送します。ラベル/SID は複数のルート間で共有される場合があります。
* An ingress BR encapsulates SRv6 egress PE destined packets with encapsulation to BGP next hop (i.e., the egress BR).
* 入力 BR は、BGP ネクスト ホップ (つまり、出力 BR) へのカプセル化を使用して、SRv6 出力 PE 宛てのパケットをカプセル化します。
The benefits of this scheme are:
このスキームの利点は次のとおりです。
* P nodes do not need to learn or install BGP SRv6 prefixes in this (BGP-free core) design.
* P ノードは、この (BGP フリー コア) 設計では BGP SRv6 プレフィックスを学習またはインストールする必要はありません。
* No per-PE SID allocation and installation on any BGP hop.
* PE ごとの SID の割り当てや BGP ホップへのインストールは必要ありません。
This design is illustrated in Appendix C.2.
この設計は付録 C.2 に示されています。
When reachability to an SRv6 SID is provided by distribution of a locator prefix via underlay routing, BGP IPv6 SAFI (AFI/SAFI=2/1) may also be used for inter-domain distribution of these IPv6 prefixes as described in Section 7.1.2 of [SRv6-INTERWORK] or [RFC9723].
SRv6 SID への到達可能性がアンダーレイ ルーティングを介したロケータ プレフィックスの配布によって提供される場合、[SRv6-INTERWORK] または [RFC9723] のセクション 7.1.2 で説明されているように、これらの IPv6 プレフィックスのドメイン間配布に BGP IPv6 SAFI (AFI/SAFI=2/1) も使用できます。
Using the BGP CAR SAFI provides the following operational benefits:
BGP CAR SAFI を使用すると、次の運用上の利点が得られます。
* CAR SAFI is a separate BGP SAFI used for underlay transport intent-aware routing. It avoids overloading of BGP IPv6 SAFI, which also carries Internet (service) prefixes. Using CAR SAFI provides:
* CAR SAFI は、アンダーレイ トランスポートのインテントアウェア ルーティングに使用される別個の BGP SAFI です。これにより、インターネット (サービス) プレフィックスも伝送する BGP IPv6 SAFI の過負荷が回避されます。CAR SAFI を使用すると、次のことが可能になります。
- Automatic separation of SRv6 locator (transport) routes from Internet (service) routes,
- SRv6 ロケーター (トランスポート) ルートとインターネット (サービス) ルートの自動分離、
o preventing inadvertent leaking of routes, and
o 不注意によるルートの漏洩を防止し、
o avoiding the need to configure specific route filters for locator routes.
o ロケーター ルートに特定のルート フィルターを設定する必要がなくなります。
- Priority handling of infrastructure routes over service (Internet) routes.
- サービス (インターネット) 経路よりもインフラストラクチャー経路を優先して処理します。
* CAR SAFI also supports inter-domain distribution of (E, C) routes sourced from SR Policy, in addition to SRv6 locator IPv6 prefixes.
* CAR SAFI は、SRv6 ロケータ IPv6 プレフィックスに加えて、SR ポリシーをソースとする (E、C) ルートのドメイン間配布もサポートします。
* CAR SAFI may also be used for best-effort routes in addition to intent-aware routes as described in the next section.
* CAR SAFI は、次のセクションで説明するように、インテントアウェア ルートに加えて、ベストエフォート ルートにも使用できます。
Note: If infrastructure routes such as SRv6 locator routes are carried in both BGP-IP [RFC4271] / BGP-LU [RFC8277] [RFC4798], and BGP CAR, Section 8 describes the path selection preference between them.
注: SRv6 ロケーター ルートなどのインフラストラクチャ ルートが BGP-IP [RFC4271] / BGP-LU [RFC8277] [RFC4798] と BGP CAR の両方で伝送される場合、セクション 8 ではそれらの間のパス選択の優先順位について説明します。
An IP Prefix CAR route is a route type (Type-2) that carries a routable IP prefix whose processing follows the semantics of [RFC4271] and [RFC2545]. IP Prefix CAR routes are installed in the default routing and forwarding table and provide longest-prefix-match forwarding. This is unlike Type-1 (E, C) routes, where it is the signaled forwarding data such as labels/SIDs that are installed in the forwarding table to create end-to-end paths.
IP プレフィックス CAR ルートは、ルーティング可能な IP プレフィックスを伝送するルート タイプ (タイプ 2) であり、その処理は [RFC4271] および [RFC2545] のセマンティクスに従います。IP プレフィックス CAR ルートはデフォルトのルーティングおよび転送テーブルにインストールされ、最長プレフィックス一致転送を提供します。これは、エンドツーエンド パスを作成するために転送テーブルにインストールされるラベル/SID などのシグナリングされた転送データであるタイプ 1 (E、C) ルートとは異なります。
IP Prefix CAR routes may be originated into BGP CAR SAFI either from an egress PE or from a BR in a domain. Type-2 routes carry infrastructure routes for both IPv4 and IPv6.
IP プレフィックス CAR ルートは、ドメイン内の出力 PE または BR から BGP CAR SAFI に発信される場合があります。タイプ 2 ルートは、IPv4 と IPv6 の両方のインフラストラクチャ ルートを伝送します。
As described in Section 2.1, it is used for cases where a unique routable IP prefix is assigned for a given intent or color. It may also be used for routes providing best-effort connectivity.
セクション 2.1 で説明したように、これは、特定のインテントまたはカラーに一意のルーティング可能な IP プレフィックスが割り当てられる場合に使用されます。ベストエフォート接続を提供するルートにも使用できます。
A few applicable example use cases:
適用可能なユースケースの例をいくつか示します。
* SRv6 locator prefix with color for specific intents.
* 特定のインテントの色を含む SRv6 ロケーター プレフィックス。
* SRv6 locator prefix without color for best-effort.
* ベストエフォートのための色のない SRv6 ロケーター プレフィックス。
* Best-effort transport reachability to a PE/BR without color.
* カラーなしの PE/BR へのベストエフォート型トランスポート到達可能性。
For specific intents, color may be signaled with the IP Prefix CAR route for purposes such as intent-aware SRv6 SID or BGP next hop selection at each transit BR, color-based routing policies and filtering, and intent-aware next-hop resolution (Section 2.5). These purposes are the same as with (E, C) routes. For such purposes, color associated with the CAR IP Prefix route is signaled using LCM-EC.
特定のインテントについては、各トランジット BR でのインテントアウェア SRv6 SID または BGP ネクスト ホップ選択、カラーベースのルーティング ポリシーとフィルタリング、インテントアウェア ネクストホップ解決などの目的で、IP プレフィックス CAR ルートで色が通知される場合があります (セクション 2.5)。これらの目的は (E、C) ルートと同じです。このような目的のために、CAR IP プレフィックス ルートに関連付けられた色は、LCM-EC を使用して通知されます。
Reminder: LCM-EC conveys end-to-end intent/color associated with route/NLRI. When traversing network domain(s) where a different intent/color is used for next-hop resolution, BGP Color-EC may additionally be used as in Section 2.10.
注意: LCM-EC は、ルート/NLRI に関連付けられたエンドツーエンドの意図/カラーを伝達します。ネクストホップ解決に異なるインテント/カラーが使用されるネットワーク ドメインを通過する場合、セクション 2.10 のように BGP Color-EC が追加で使用される場合があります。
A special case of intent is best-effort, which may be represented by a color and follow the above procedures. However, to be compatible with existing operational usage, the CAR IP Prefix route is allowed to be without color for best-effort. In this case, the routes will not carry an LCM-EC. Resolution is described in Section 2.5.
意図の特別なケースはベストエフォートであり、これは色で表され、上記の手順に従うことができます。ただし、既存の運用上の使用法と互換性を持たせるために、CAR IP プレフィックス ルートはベストエフォートでカラーなしにすることが許可されています。この場合、ルートは LCM-EC を伝送しません。解決策についてはセクション 2.5 で説明します。
As described in Section 7.3, infrastructure prefixes are intended to be carried in CAR SAFI instead of SAFIs that also carry service routes such as BGP-IP (SAFI 1, [RFC4271]) and BGP-LU (SAFI 4, [RFC4798]). However, if such infrastructure routes are also distributed in these SAFIs, a router may receive both BGP CAR SAFI paths and IP/LU SAFI paths. By default, the CAR SAFI transport path is preferred over the BGP-IP or BGP-LU SAFI path.
セクション 7.3 で説明されているように、インフラストラクチャ プレフィックスは、BGP-IP (SAFI 1、[RFC4271]) や BGP-LU (SAFI 4、[RFC4798]) などのサービス ルートも伝送する SAFI ではなく、CAR SAFI で伝送されることを目的としています。ただし、そのようなインフラストラクチャ ルートがこれらの SAFI にも分散されている場合、ルータは BGP CAR SAFI パスと IP/LU SAFI パスの両方を受信する可能性があります。デフォルトでは、CAR SAFI トランスポート パスが BGP-IP または BGP-LU SAFI パスよりも優先されます。
A BGP transport CAR speaker that supports packet forwarding lookup based on the IPv6 prefix route (such as a BR) will set itself as next hop while advertising the route to peers. It will also install the IPv6 route into forwarding with the received next hop and/or encapsulation. If such a transit router does not support this route type, it will not install this route and will not set itself as next hop; hence, it will not propagate the route any further.
IPv6 プレフィックス ルート（BR など）に基づくパケット転送ルックアップをサポートする BGP トランスポート CAR スピーカーは、ルートをピアにアドバタイズする際に、自身をネクスト ホップとして設定します。また、受信したネクスト ホップやカプセル化を使用して、IPv6 ルートを転送にインストールします。このような中継ルーターがこのルート タイプをサポートしていない場合、このルートはインストールされず、自身をネクスト ホップとして設定しません。したがって、ルートはそれ以上伝播しません。
This section illustrates the extension of BGP CAR to address the VPN intent-aware routing requirement stated in Section 6.1.2 of [INTENT-AWARE]. The examples use MPLS, but other transport types can also be used (e.g., SRv6).
このセクションでは、[INTENT-AWARE] のセクション 6.1.2 に記載されている VPN インテントアウェア ルーティング要件に対処するための BGP CAR の拡張について説明します。この例では MPLS を使用していますが、他のトランスポート タイプ (SRv6 など) も使用できます。
CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V
* BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions.
* BGP CAR SAFI は、CE1-PE1 および PE2-CE2 セッションで有効になります。
* BGP VPN CAR SAFI is enabled between PE1 and PE2.
* BGP VPN CAR SAFI は PE1 と PE2 の間で有効になります。
* Provider publishes to customer that intent "low delay" is mapped to color CP ("Provider Color") on its inbound peering links.
* プロバイダーは、インテント「低遅延」が受信ピアリング リンク上のカラー CP (「プロバイダー カラー」) にマッピングされていることを顧客に公開します。
* Within its infrastructure, provider maps intent "low delay" to color CPT ("Provider Transport Color").
* プロバイダーはそのインフラストラクチャ内で、インテントの「低遅延」をカラー CPT (「プロバイダー トランスポート カラー」) にマッピングします。
* On CE1 and CE2, intent "low delay" is mapped to CC ("Customer Color").
* CE1 および CE2 では、インテント「低遅延」は CC (「顧客の色」) にマッピングされます。
(V, CC) is a color-aware route originated by CE2.
(V、CC) は、CE2 によって生成されたカラー認識ルートです。
1. CE2 sends to PE2:
1. CE2 は PE2 に送信します。
[(V, CC), label L1] via CE2 with LCM-EC (CP) as per peering agreement.
[(V, CC)、ラベル L1] ピアリング契約に従って、LCM-EC (CP) を使用して CE2 経由。
2. PE2 installs in VRF A:
2. PE2 は VRF A にインストールされます。
[(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected Outgoing Interface (OIF).
[(V, CC), L1] CE2 経由。(CE2, CP) または接続された送信インターフェイス (OIF) で解決されます。
3. PE2 allocates VPN label L2 and programs swap entry for (V, CC).
3. PE2 は VPN ラベル L2 を割り当て、(V, CC) のエントリをスワップします。
4. PE2 sends to PE1:
4. PE2 は PE1 に送信します。
[(RD, V, CC), L2] via PE2, LCM-EC (CP) with regular Color-EC (CPT).
[(RD、V、CC)、L2] PE2、LCM-EC (CP) と通常の Color-EC (CPT) 経由。
5. PE1 installs in VRF A:
5. PE1 は VRF A にインストールされます。
[(V, CC), L2] via (PE2, CPT) steered on (PE2, CPT).
[(V, CC), L2] (PE2, CPT) 経由で (PE2, CPT) に誘導されます。
6. PE1 allocates label L3 and programs swap entry for (V, CC).
6. PE1 はラベル L3 を割り当て、(V, CC) のスワップ エントリをプログラムします。
7. PE1 sends to CE1:
7. PE1 は CE1 に送信します。
[(V, CC), L3] via PE1 after removing LCM-EC through route policy.
[(V, CC), L3] ルート ポリシーを通じて LCM-EC を削除した後、PE1 経由。
8. CE1 installs:
8. CE1 は以下をインストールします。
[(V, CC), L3] via PE1, which resolves on (PE1, CC) or connected OIF.
[(V, CC), L3] PE1 経由。(PE1, CC) または接続された OIF で解決されます。
9. Label L3 is installed as the imposition label for (V, CC).
9. （V、CC）の面付けラベルとしてラベルL3が装着されています。
VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows the same VPN semantics as defined in [RFC4364] and also supports the distribution of routes with the CAR NLRI and associated non-key TLVs defined in Section 2.9 of this document.
(RD、V、CC) の VPN CAR 配布には、[RFC4364] で定義されているのと同じ VPN セマンティクスに従う新しい SAFI が必要であり、CAR NLRI およびこの文書のセクション 2.9 で定義されている関連する非キー TLV を使用したルートの配布もサポートしています。
Procedures defined in [RFC4364] and [RFC4659] apply to VPN CAR SAFI. Further, all CAR SAFI procedures described in Section 2 above apply to CAR SAFI enabled within a VRF. Since CE and PE are typically in different administrative domains, LCM-EC is attached to CAR routes.
[RFC4364] および [RFC4659] で定義された手順が VPN CAR SAFI に適用されます。さらに、上記のセクション 2 で説明されているすべての CAR SAFI 手順は、VRF 内で有効になっている CAR SAFI に適用されます。CE と PE は通常、異なる管理ドメインにあるため、LCM-EC は CAR ルートに接続されます。
VPN CAR SAFI routes follow color-based steering techniques as described in Section 3 and illustrated in the example above.
VPN CAR SAFI ルートは、セクション 3 で説明し、上記の例で示した色ベースのステアリング技術に従います。
VPN CAR SAFI routes may also be advertised with a specific BGP next hop per color, with a TEA or Tunnel Encapsulation EC, and follow the procedures of Section 6 of [RFC9012].
VPN CAR SAFI ルートは、色ごとの特定の BGP ネクスト ホップ、TEA またはトンネル カプセル化 EC を使用してアドバタイズすることもでき、[RFC9012] のセクション 6 の手順に従います。
CAR routes distributed in VPN CAR SAFI are infrastructure routes advertised by CEs in different customer VRFs on a PE. Example use cases are intent-aware L3VPN Carriers' Carriers (Section 9 of [RFC4364]) and SRv6 over a provider network. The VPN RD distinguishes CAR routes of different customers being advertised by the PE.
VPN CAR SAFI で分散される CAR ルートは、PE 上のさまざまなカスタマー VRF の CE によってアドバタイズされるインフラストラクチャ ルートです。ユースケースの例としては、インテントアウェア L3VPN キャリアのキャリア ([RFC4364] のセクション 9) およびプロバイダー ネットワーク上の SRv6 があります。VPN RD は、PE によってアドバタイズされているさまざまな顧客の CAR ルートを区別します。
BGP VPN CAR SAFI leverages BGP multiprotocol extensions [RFC4760] and uses the MP_REACH_NLRI and MP_UNREACH_NLRI attributes for route updates within SAFI value 84 along with AFI 1 for IPv4 VPN CAR prefixes and AFI 2 for IPv6 VPN CAR prefixes.
BGP VPN CAR SAFI は、BGP マルチプロトコル拡張 [RFC4760] を活用し、SAFI 値 84 内のルート更新に MP_REACH_NLRI および MP_UNREACH_NLRI 属性を、IPv4 VPN CAR プレフィックスの AFI 1 および IPv6 VPN CAR プレフィックスの AFI 2 とともに使用します。
BGP speakers MUST use the BGP Capabilities Advertisement to ensure support for processing of BGP VPN CAR updates. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP), with AFI 1 and 2 (as required) and SAFI 84.
BGP スピーカーは、BGP VPN CAR アップデートの処理を確実にサポートするために、BGP 機能アドバタイズメントを使用する必要があります。これは、[RFC4760] で指定されているように、機能コード 1 (マルチプロトコル BGP)、AFI 1 および 2 (必要に応じて) および SAFI 84 を使用して行われます。
The Next Hop network address field in the MP_REACH_NLRI may contain either a VPN-IPv4 or a VPN-IPv6 address with 8-octet RD set to zero, independent of AFI. If the next hop length is 12, then the next hop is a VPN-IPv4 address with an RD of 0 constructed as per [RFC4364]. If the next hop length is 24 or 48, then the next hop is a VPN-IPv6 address constructed as per Section 3.2.1.1 of [RFC4659].
MP_REACH_NLRI のネクスト ホップ ネットワーク アドレス フィールドには、AFI とは関係なく、8 オクテット RD がゼロに設定された VPN-IPv4 または VPN-IPv6 アドレスが含まれる場合があります。ネクスト ホップの長さが 12 の場合、ネクスト ホップは [RFC4364] に従って構築された RD が 0 の VPN-IPv4 アドレスになります。ネクストホップの長さが 24 または 48 の場合、ネクストホップは [RFC4659] のセクション 3.2.1.1 に従って構築された VPN-IPv6 アドレスです。
VPN CAR Type-1 (E, C) NLRI with RD has the format shown below:
RD を使用した VPN CAR タイプ 1 (E、C) NLRI の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is followed by optional Non-Key TLVs encoded as per Section 2.9.2.
これに、セクション 2.9.2 に従ってエンコードされたオプションの非キー TLV が続きます。
where:
ただし：
all fields are encoded as per Section 2.9.3 with the following changes:
すべてのフィールドはセクション 2.9.3 に従ってエンコードされますが、次の変更が加えられます。
Key Length:
キーの長さ:
This length indicates the total length comprised of the RD, Prefix Length field, IP Prefix field, and the Color field.
この長さは、RD、Prefix Length フィールド、IP Prefix フィールド、および Color フィールドから構成される合計の長さを示します。
Route Distinguisher:
ルート識別子:
An 8-octet field encoded according to [RFC4364].
[RFC4364]に従ってエンコードされた8オクテットのフィールド。
Type-Specific Non-Key TLVs:
タイプ固有の非キー TLV:
The Label TLV, Label-Index TLV, and SRv6 SID TLV (Section 2.9.2) may be associated with the VPN CAR (E, C) NLRI Type.
ラベル TLV、ラベル インデックス TLV、および SRv6 SID TLV (セクション 2.9.2) は、VPN CAR (E、C) NLRI タイプに関連付けられている場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is followed by optional Non-Key TLVs encoded as per Section 2.9.2.
これに、セクション 2.9.2 に従ってエンコードされたオプションの非キー TLV が続きます。
where:
ただし：
all fields are encoded as per Section 2.9.4 with the following changes:
すべてのフィールドはセクション 2.9.4 に従ってエンコードされますが、次の変更が加えられます。
Key Length:
キーの長さ:
This length indicates the total length comprised of the RD, Prefix Length field, and IP Prefix field.
この長さは、RD、Prefix Length フィールド、および IP Prefix フィールドから構成される合計の長さを示します。
Route Distinguisher:
ルート識別子:
An 8-octet field encoded according to [RFC4364].
[RFC4364]に従ってエンコードされた8オクテットのフィールド。
Type-Specific Non-Key TLVs:
タイプ固有の非キー TLV:
The Label TLV, Label-Index TLV, and SRv6 SID TLV (Section 2.9.2) may be associated with the VPN CAR IP Prefix NLRI Type.
ラベル TLV、ラベル インデックス TLV、および SRv6 SID TLV (セクション 2.9.2) は、VPN CAR IP プレフィックス NLRI タイプに関連付けられている場合があります。
The error handling specified in Section 2.11 also applies to VPN CAR SAFI.
セクション 2.11 で指定されているエラー処理は、VPN CAR SAFI にも適用されます。
IANA has assigned SAFI value 83 (BGP CAR) and SAFI value 84 (BGP VPN CAR) from the "SAFI Values" registry in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry group with this document as a reference.
IANA は、このドキュメントを参考にして、「Subsequent Address Family Identifiers (SAFI) Parameters」レジストリ グループの「SAFI Values」レジストリから SAFI 値 83 (BGP CAR) と SAFI 値 84 (BGP VPN CAR) を割り当てました。
IANA has created a "BGP CAR NLRI Types" registry in the "Border Gateway Protocol (BGP) Parameters" registry group with this document as a reference. The registry is for assignment of the 1-octet code points for BGP CAR NLRI types and is populated with the values shown below:
IANA は、このドキュメントを参考にして、「Border Gateway Protocol (BGP) Parameters」レジストリ グループに「BGP CAR NLRI Types」レジストリを作成しました。レジストリは、BGP CAR NLRI タイプの 1 オクテット コード ポイントを割り当てるためのもので、以下に示す値が入力されます。
+=======+===================+===========+
| Type | NLRI Type | Reference |
+=======+===================+===========+
| 0 | Reserved | RFC 9871 |
+-------+-------------------+-----------+
| 1 | Color-Aware Route | RFC 9871 |
+-------+-------------------+-----------+
| 2 | IP Prefix | RFC 9871 |
+-------+-------------------+-----------+
| 3-255 | Unassigned |
+-------+-------------------------------+
Table 3
Allocations within the registry are to be made with the "Specification Required" policy as specified in [RFC8126] and in Section 10.4.
レジストリ内の割り当ては、[RFC8126] およびセクション 10.4 に規定されている「要求仕様」ポリシーに従って行われます。
IANA has created a "BGP CAR NLRI TLV Types" registry in the "Border Gateway Protocol (BGP) Parameters" registry group with this document as a reference. The registry is for assignment of the 6-bit code points for BGP CAR NLRI non-key TLV types and is populated with the values shown below:
IANA は、このドキュメントを参考にして、「Border Gateway Protocol (BGP) Parameters」レジストリ グループに「BGP CAR NLRI TLV Types」レジストリを作成しました。レジストリは、BGP CAR NLRI 非キー TLV タイプの 6 ビット コード ポイントを割り当てるためのもので、以下に示す値が入力されます。
+======+===============+===========+
| Type | NLRI TLV Type | Reference |
+======+===============+===========+
| 0 | Reserved | RFC 9871 |
+------+---------------+-----------+
| 1 | Label | RFC 9871 |
+------+---------------+-----------+
| 2 | Label-Index | RFC 9871 |
+------+---------------+-----------+
| 3 | SRv6 SID | RFC 9871 |
+------+---------------+-----------+
| 4-64 | Unassigned |
+------+---------------------------+
Table 4
Allocations within the registry are to be made with the "Specification Required" policy as specified in [RFC8126] and in Section 10.4.
レジストリ内の割り当ては、[RFC8126] およびセクション 10.4 に規定されている「要求仕様」ポリシーに従って行われます。
For a new TLV to be used with existing NLRI types, documentation of the NLRI types must be updated.
新しい TLV を既存の NLRI タイプで使用するには、NLRI タイプのドキュメントを更新する必要があります。
In all cases of review by the Designated Expert (DE) described here, the DE is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] for the "BGP CAR NLRI Types" registry and the "BGP CAR NLRI TLV" registry.
ここで説明する指定専門家 (DE) によるレビューのすべてのケースにおいて、DE は、[RFC8126] に記載されている「BGP CAR NLRI Types」レジストリおよび「BGP CAR NLRI TLV」レジストリに関する適切な文書 (仕様) の存在を確認することが期待されます。
The DE is also expected to check the clarity of purpose and use of the requested code points. Additionally, the DE must verify that any request for one of these code points has been made available for review and comment within the IETF: the DE will post the request to the IDR Working Group mailing list (or a successor mailing list designated by the IESG). The DE must ensure that any request for a code point does not conflict with work that is active or already published within the IETF.
DE は、要求されたコード ポイントの目的と用途の明確性をチェックすることも期待されています。さらに、DE は、これらのコード ポイントの 1 つに対するリクエストが IETF 内でレビューおよびコメントできるようにされていることを確認する必要があります。DE は、そのリクエストを IDR Working Group メーリング リスト (または IESG が指定する後継のメーリング リスト) に投稿します。DE は、コード ポイントに対するリクエストが、IETF 内でアクティブな作業または既に公開されている作業と競合しないことを確認する必要があります。
The DE is expected to confirm that the specification satisfies the requirements for the "Specification Required" policy (Section 4.6 of [RFC8126]). In particular, as a reminder, the specification is required to be "permanent and readily available". The DE may assume that any document in the Internet-Draft or RFC repository satisfies the requirement for permanence and availability. In other cases, and in particular for any document not hosted by another standards development organization, the burden of proof of permanence falls on the applicant.
DE は、仕様が「要求される仕様」ポリシー ([RFC8126] のセクション 4.6) の要件を満たしていることを確認することが期待されます。特に、仕様は「永続的であり、すぐに利用できる」必要があることに注意してください。DE は、Internet-Draft または RFC リポジトリ内の文書が永続性と可用性の要件を満たしていると想定する場合があります。他の場合、特に他の標準開発組織がホストしていない文書の場合、永続性を証明する責任は申請者にあります。
* Check the interoperability between the new NLRI type and current NLRI types specified in this document for BGP CAR SAFIs (BGP CAR SAFI and VPN CAR SAFI), and any updates to this document.
* BGP CAR SAFI (BGP CAR SAFI および VPN CAR SAFI) についてこのドキュメントで指定されている新しい NLRI タイプと現在の NLRI タイプの間の相互運用性、およびこのドキュメントの更新を確認してください。
* Check if the specification indicates which non-key TLVs are applicable for the new NLRI type.
* どの非キー TLV が新しい NLRI タイプに適用できるかが仕様に示されているかどうかを確認してください。
* Check the applicability of the new TLV for the BGP CAR NLRI types defined.
* 定義されている BGP CAR NLRI タイプに対する新しい TLV の適用性を確認します。
* Check the T bit setting for the new TLV.
* 新しい TLV の T ビット設定を確認します。
IANA has assigned the sub-type 0x1b for "Local Color Mapping (LCM)" in the "Transitive Opaque Extended Community Sub-Types" registry in the "Border Gateway Protocol (BGP) Extended Communities" registry group.
IANA は、「ボーダー ゲートウェイ プロトコル (BGP) 拡張コミュニティ」レジストリ グループの「推移的不透明拡張コミュニティ サブタイプ」レジストリの「ローカル カラー マッピング (LCM)」にサブタイプ 0x1b を割り当てました。
Color assignments in a multi-domain network operating under a common or cooperating administrative control (i.e., a color domain) should be managed similar to transport layer IP addresses, and ensure a unique and non-conflicting color allocation across the different network domains in that color domain. This is a logical best practice in a single color or administrative domain, which is the most typical deployment scenario.
共通または協調的な管理制御下で動作するマルチドメイン ネットワーク (つまり、カラー ドメイン) での色の割り当ては、トランスポート層 IP アドレスと同様に管理され、そのカラー ドメイン内のさまざまなネットワーク ドメイン間で固有で競合のない色の割り当てが保証される必要があります。これは、最も一般的な展開シナリオである単一色または管理ドメインにおける論理的なベスト プラクティスです。
When color-aware routes propagate across a color domain boundary, there is typically no need for color assignments to be identical in both color domains, since the IP prefix is unique in the inter-domain transport network. This unique IP prefix provides a unique and non-conflicting scope for the color in an (E, C) route. Coordination between the operators of the color domains is needed only to enable the color to be re-mapped into a local color (carried in the LCM-EC) assigned for the same intent in the receiving color domain.
カラー認識ルートがカラー ドメイン境界を越えて伝播する場合、IP プレフィックスはドメイン間トランスポート ネットワーク内で一意であるため、通常、両方のカラー ドメインでカラー割り当てを同一にする必要はありません。この一意の IP プレフィックスは、(E, C) ルート内のカラーに一意で競合しないスコープを提供します。カラー ドメインのオペレータ間の調整は、受信カラー ドメインで同じ目的に割り当てられたローカル カラー (LCM-EC で伝送される) にカラーを再マッピングできるようにする場合にのみ必要です。
However, if networks under different administrative control establish a shared transport service between them, where the same transport service IP address is coordinated and shared among two (or more) color domain networks, then the color assignments associated with that shared IP address should also be coordinated to avoid any conflicts in either network (Appendix A.7).
ただし、異なる管理制御下にあるネットワークがネットワーク間で共有トランスポート サービスを確立し、同じトランスポート サービス IP アドレスが 2 つ (またはそれ以上) のカラー ドメイン ネットワーク間で調整および共有される場合、どちらのネットワークでも競合が発生しないように、その共有 IP アドレスに関連付けられた色の割り当ても調整する必要があります (付録 A.7)。
It should be noted that the color assignments coordination is only necessary for routes specific to the shared service IP. Colors used for intra-domain or for inter-domain intents associated with unique IP addresses do not need any coordination.
色の割り当ての調整は、共有サービス IP に固有のルートにのみ必要であることに注意してください。一意の IP アドレスに関連付けられたドメイン内またはドメイン間のインテントに使用される色を調整する必要はありません。
Extended communities (LCM-EC/Color-EC) carried in BGP CAR and service routes MUST NOT be filtered, otherwise the desired intent will not be achieved.
BGP CAR およびサービス ルートで伝送される拡張コミュニティ (LCM-EC/Color-EC) はフィルタリングしてはなりません (MUST NOT)。フィルタリングしないと、目的の目的が達成されません。
This document does not change the underlying security considerations and issues inherent in the existing BGP protocol, such as those described in [RFC4271] and [RFC4272].
この文書は、[RFC4271] や [RFC4272] で説明されているような、既存の BGP プロトコルに固有の根本的なセキュリティ上の考慮事項や問題を変更するものではありません。
This document defines a new BGP SAFI and related extensions to carry color-aware routes and their associated attributes. The separate SAFI is expected to be explicitly configured by an operator. It is also expected that the necessary BGP route policy filtering is configured on this new SAFI to filter routing information distributed by the routers participating in this network, at appropriate points within and at the boundaries of this network.
この文書では、色認識ルートとそれに関連する属性を伝送するための新しい BGP SAFI と関連拡張機能を定義します。別個の SAFI は、オペレータによって明示的に設定されることが期待されます。また、このネットワークに参加しているルータによって配信されるルーティング情報を、このネットワーク内および境界の適切なポイントでフィルタリングするために、必要な BGP ルート ポリシー フィルタリングがこの新しい SAFI 上に設定されることも期待されます。
Also, given that this SAFI and these mechanisms can only be enabled through configuration of routers within an operator's network, standard security measures should be taken to restrict access to the management interface(s) of routers that implement these mechanisms.
また、この SAFI とこれらのメカニズムは、事業者のネットワーク内のルーターの構成によってのみ有効にできることを考慮すると、これらのメカニズムを実装するルーターの管理インターフェイスへのアクセスを制限するための標準的なセキュリティ対策を講じる必要があります。
Additionally, BGP sessions SHOULD be protected using the TCP Authentication Option [RFC5925] and the Generalized TTL Security Mechanism [RFC5082]. BGP origin validation [RFC6811] and BGPsec [RFC8205] could also be used with this SAFI.
さらに、BGP セッションは、TCP 認証オプション [RFC5925] および一般化 TTL セキュリティ メカニズム [RFC5082] を使用して保護されるべきです (SHOULD)。BGP 起点検証 [RFC6811] および BGPsec [RFC8205] もこの SAFI で使用できます。
Since CAR SAFI is a separate BGP SAFI that carries transport or infrastructure routes for routers in the operator network, it provides automatic separation of infrastructure routes and the service routes that are carried in existing BGP SAFIs such as BGP IPv4/IPv6 (SAFI=1), and BGP-LU (SAFI=4) (e.g., 6PE [RFC4798]). Using CAR SAFI thus provides better security (such as protection against route leaking) than would be obtained by distributing the infrastructure routes in existing SAFIs that also carry service routes.
CAR SAFI は、オペレータ ネットワーク内のルータのトランスポート ルートまたはインフラストラクチャ ルートを伝送する別個の BGP SAFI であるため、インフラストラクチャ ルートと、BGP IPv4/IPv6 (SAFI=1) や BGP-LU (SAFI=4) (例: 6PE [RFC4798]) などの既存の BGP SAFI で伝送されるサービス ルートの自動分離を提供します。したがって、CAR SAFI を使用すると、サービス ルートも伝送する既存の SAFI にインフラストラクチャ ルートを分散する場合よりも優れたセキュリティ（ルート漏洩に対する保護など）が提供されます。
BGP CAR distributes label binding similar to [RFC8277]; hence, its security considerations apply.
BGP CAR は、[RFC8277] と同様にラベル バインディングを配布します。したがって、セキュリティに関する考慮事項が適用されます。
In SR deployments, BGP CAR distributes infrastructure prefixes along with their SID information for both SR-MPLS and SRv6. These deployments are within an SR domain [RFC8402] and the security considerations of [RFC8402] apply. Additionally, security considerations related to SRv6 deployments that are discussed in Section 9.3 of [RFC9252] also apply.
SR 導入では、BGP CAR は SR-MPLS と SRv6 の両方の SID 情報とともにインフラストラクチャ プレフィックスを配布します。これらの展開は SR ドメイン [RFC8402] 内にあり、[RFC8402] のセキュリティに関する考慮事項が適用されます。さらに、[RFC9252] のセクション 9.3 で説明されている SRv6 展開に関連するセキュリティ上の考慮事項も適用されます。
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 ルートは、攻撃者がトラフィックを通常のパスから迂回させる新しい手段を追加します。潜在的な結果としては、トラフィックの「ハイジャック」（トラフィックの検査や変更、セキュリティ制御の回避を可能にするパス内への望ましくないノードの挿入）、またはサービス拒否（トラフィックの受信を望まないノードへのトラフィックの誘導）が含まれます。
The restriction of the applicability of this SAFI to its intended well-defined scope and the use of techniques described above limit the likelihood of traffic diversions.
この SAFI の適用範囲を意図した明確に定義された範囲に制限することと、上記の技術を使用することにより、トラフィックの迂回の可能性が制限されます。
[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>.
[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>.
[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>.
[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>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
DOI 10.17487/RFC7311, August 2014,
<https://www.rfc-editor.org/info/rfc7311>.
[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>.
[RFC8126] 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>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[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>.
[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>.
[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>.
[INTENT-AWARE]
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>.
[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>.
[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>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798,
DOI 10.17487/RFC4798, February 2007,
<https://www.rfc-editor.org/info/rfc4798>.
[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>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[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>.
[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>.
[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>.
[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>.
[RFC9723] Wang, H., Dong, J., Talaulikar, K., Han, T., and R. Chen,
"BGP Colored Prefix Routing (CPR) for Services Based on
Segment Routing over IPv6 (SRv6)", RFC 9723,
DOI 10.17487/RFC9723, May 2025,
<https://www.rfc-editor.org/info/rfc9723>.
[SRv6-INTERWORK]
Agrawal, S., Filsfils, C., Voyer, D., Dawra, G., Li, Z.,
and S. Hegde, "SRv6 and MPLS interworking", Work in
Progress, Internet-Draft, draft-ietf-spring-srv6-mpls-
interworking-01, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-mpls-interworking-01>.
The following sub-sections illustrate example scenarios of colored service route steering over end-to-end (E2E) BGP CAR paths, resolving over different intra-domain mechanisms.
次のサブセクションでは、さまざまなドメイン内メカニズムを解決して、エンドツーエンド（E2E）BGP CAR パスを介したカラー サービス ルート ステアリングのシナリオ例を示します。
The examples in this section use MPLS/SR for the transport data plane. Scenarios related to SRv6 encapsulation are in a section below.
このセクションの例では、トランスポート データ プレーンに MPLS/SR を使用します。SRv6 カプセル化に関連するシナリオは、以下のセクションにあります。
RD:V/v via E2
+-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ :
: :
: :
: :
+-:-----------------------+----------------------+------------------:--+
| : | | : |
| : | | : |
| : (E2,C1) via 121 | (E2,C1) via 231 | (E2,C1)via E2 : |
| : L=168002,AIGP=110 +---+ L=168002,AIGP=10 +---+ L=0x3,LI=8002 : |
| : |-------------------|121|<-----------------|231|<-------------| : |
| : V LI=8002 +---+ LI=8002 +---+ | : |
|----+ | | +-----|
| E1 | | | | E2 |
|----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1)via E2+-----|
| ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3 | |
| |---------------- |122|<-----------------|232|<-------------| |
| LI=8002 +---+ LI=8002 +---+ LI=8002 |
| | | |
| IS-IS SR | IS-IS SR | IS-IS SR |
| FA128 | FA128 | FA128 |
+-------------------------+----------------------+---------------------+
iPE iABR eABR ePE
---------direction of traffic-------->
+------+ +------+
|168121| |168231|
+------+ +------+
+------+ +------+ +------+
|168002| |168002| |168002|
+------+ +------+ +------+
+------+ +------+ +------+
|30030 | |30030 | |30030 |
+------+ +------+ +------+
Figure 6: BGP Flexible Algorithm Aware Transport CAR Path
図 6: BGP 柔軟なアルゴリズム対応トランスポート CAR パス
Use case: Provide end-to-end intent for service flows.
ユースケース: サービス フローにエンドツーエンドのインテントを提供します。
* The following description applies to the reference topology above:
* 次の説明は、上記の参照トポロジに適用されます。
- IGP Flex-Algo 128 is running in each domain, and mapped to color C1.
- IGP Flex-Algo 128 は各ドメインで実行されており、カラー C1 にマッピングされています。
- Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1 to steer traffic to BGP transport CAR (E2, C1). VPN route propagates via service RRs to ingress PE E1.
- 出力 PE E2 は、Color-EC C1 で色付けされた VPN ルート RD:V/v をアドバタイズし、トラフィックを BGP トランスポート CAR (E2、C1) に誘導します。VPN ルートはサービス RR を介して入力 PE E1 に伝播します。
- BGP CAR route (E2, C1) with next hop, label index, and label as shown above are advertised through BRs in each domain. When an RR is used in the domain, ADD-PATH is enabled to advertise multiple available paths.
- 上記のネクスト ホップ、ラベル インデックス、およびラベルを持つ BGP CAR ルート (E2、C1) は、各ドメインの BR を通じてアドバタイズされます。RR がドメインで使用されている場合、ADD-PATH が有効になり、複数の使用可能なパスをアドバタイズできます。
- On each BGP hop, the (E2, C1) route's next hop is resolved over IGP Flex-Algo 128 of the domain. The AIGP attribute influences the BGP CAR route best path decision as per [RFC7311]. The BGP CAR label swap entry is installed that goes over Flex-Algo 128 LSP to next hop providing intent in each IGP domain. The AIGP metric should be updated to reflect Flex-Algo 128 metric to next hop.
- 各 BGP ホップで、(E2、C1) ルートのネクスト ホップはドメインの IGP Flex-Algo 128 経由で解決されます。AIGP 属性は、[RFC7311] に従って、BGP CAR ルートの最適パスの決定に影響を与えます。BGP CAR ラベル スワップ エントリがインストールされており、Flex-Algo 128 LSP を介してネクスト ホップに到達し、各 IGP ドメインにインテントを提供します。AIGP メトリックは、Flex-Algo 128 メトリックをネクスト ホップに反映するように更新する必要があります。
- Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN route RD:V/v into (E2, C1).
- 入力 PE E1 は CAR ルート (E2、C1) を学習します。色付きの VPN ルート RD:V/v を (E2、C1) に誘導します。
* Important:
* 重要：
- IGP Flex-Algo 128 top label provides intent within each domain.
- IGP Flex-Algo 128 のトップ ラベルは、各ドメイン内のインテントを提供します。
- BGP CAR label (e.g., 168002) carries end-to-end intent. Thus, it stitches intent over intra-domain Flex-Algo 128.
- BGP CAR ラベル (例: 168002) はエンドツーエンドの意図を伝えます。したがって、ドメイン内の Flex-Algo 128 に意図をつなぎ合わせます。
RD:1/8 via E2
+-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <......
: +-----+ Color C1 +-----+ :
: :
: :
: :
+-:-----------------------+----------------------+------------------:-+
| : | | : |
| : | | : |
| : <-(E2,C1) via 121 | <-(E2,C1) via 231 | <-(E2,C1)via E2 : |
| : +---+ +---+ : |
| : ------------------>|121|----------------->|231|--------------| : |
| : | SR Policy(C1,121) +---+ SR Policy(C1,231)+---+ SR Policy v : |
|----+ | | (C1,E2) +---|
| E1 | | | |E2 |
|----+ <-(E2,C1) via 122 | (E2,C1) via 232 | <-(E2,C1)via E2+---|
| | +---+ +---+ ^ |
| ------------------>|122|----------------->|232|---------------| |
| SR Policy(C1,122) +---+ SR Policy(C1,232)+---+ SR Policy(C1,E2) |
| | | |
| | | |
| IS-IS SR | IS-IS SR | IS-IS SR |
+-------------------------+----------------------+--------------------+
iPE iABR eABR ePE
---------direction of traffic-------->
+------+ +------+
| S1 | | S2 |
+------+ +------+
+------+ +------+ +------+
|160121| |160231| | S3 |
+------+ +------+ +------+
+------+ +------+ +------+
|168002| |168002| |168002|
+------+ +------+ +------+
+------+ +------+ +------+
|30030 | |30030 | |30030 |
+------+ +------+ +------+
Figure 7: BGP SR Policy Aware Transport CAR Path
図 7: BGP SR ポリシー対応トランスポート CAR パス
Use case: Provide end-to-end intent for service flows.
ユースケース: サービス フローにエンドツーエンドのインテントを提供します。
* The following description applies to the reference topology above:
* 次の説明は、上記の参照トポロジに適用されます。
- An SR Policy provides intra-domain intent. The following are the example SID lists that are realized from SR policies in each domain and correspond to the label stack shown in Figure 7:
- SR ポリシーはドメイン内のインテントを提供します。以下は、各ドメインの SR ポリシーから実現され、図 7 に示すラベル スタックに対応する SID リストの例です。
o SR Policy (C1, 121) segments <S1, 121>,
o SR ポリシー (C1、121) セグメント <S1、121>、
o SR Policy (C1, 231) segments <S2, 231>, and
o SR ポリシー (C1、231) セグメント <S2、231>、および
o SR Policy (C1, E2) segments <S3, E2>.
o SR ポリシー (C1、E2) セグメント <S3、E2>。
- Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1 to steer traffic to BGP transport CAR (E2, C1). VPN route propagates via service RRs to ingress PE E1.
- 出力 PE E2 は、Color-EC C1 で色付けされた VPN ルート RD:V/v をアドバタイズし、トラフィックを BGP トランスポート CAR (E2、C1) に誘導します。VPN ルートはサービス RR を介して入力 PE E1 に伝播します。
- BGP CAR route (E2, C1) with next hop, label index, and label as shown above are advertised through BRs in each domain. When an RR is used in the domain, ADD-PATH is enabled to advertise multiple available paths.
- 上記のネクスト ホップ、ラベル インデックス、およびラベルを持つ BGP CAR ルート (E2、C1) は、各ドメインの BR を通じてアドバタイズされます。RR がドメインで使用されている場合、ADD-PATH が有効になり、複数の使用可能なパスをアドバタイズできます。
- On each BGP hop, the CAR route (E2, C1) next hop is resolved over an SR Policy (C1, next hop). The BGP CAR label swap entry is installed that goes over SR Policy segment list.
- 各 BGP ホップでは、CAR ルート (E2、C1) のネクスト ホップが SR ポリシー (C1、ネクスト ホップ) 上で解決されます。SR ポリシー セグメント リストを対象とする BGP CAR ラベル スワップ エントリがインストールされます。
- Ingress PE E1 learns CAR route (E2, C1). It steers colored VPN route RD:V/v into (E2, C1).
- 入力 PE E1 は CAR ルート (E2、C1) を学習します。色付きの VPN ルート RD:V/v を (E2、C1) に誘導します。
* Important:
* 重要：
- SR Policy provides intent within each domain.
- SR ポリシーは、各ドメイン内のインテントを提供します。
- BGP CAR label (e.g., 168002) carries end-to-end intent. Thus, it stitches intent over intra-domain SR policies.
- BGP CAR ラベル (例: 168002) はエンドツーエンドの意図を伝えます。したがって、ドメイン内の SR ポリシーに意図をつなぎ合わせます。
RD:1/8 via E2
+-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ :
: :
: :
: :
+-:-----------------------+----------------------+------------------:--+
| : | | : |
| : | | : |
| : (E2,C1) via 121 | (E2,C1) via 231 | (E2,C1) via E2 : |
| : L=168002,AIGP=1110+---+L=168002,AIGP=1010+---+ L=0x3 : |
| : |-------------------|121|<-----------------|231|<-------------| : |
| : V LI=8002 +---+ LI=8002 +---+ | : |
|----+ | | +-----|
| E1 | | | | E2 |
|----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1) via E2+-----|
| ^ L=168002,AIGP=1210+---+L=168002,AIGP=1020+---+ L=0x3 | |
| |---------------- |122|<-----------------|232|<-------------| |
| LI=8002 +---+ LI=8002 +---+ |
| | | |
| IS-IS SR | IS-IS SR | IS-IS SR |
| Algo 0 | Flex-Algo 128 | Algo 0 |
| Access | Core | Access |
+-------------------------+----------------------+---------------------+
iPE iABR eABR ePE
---------direction of traffic-------->
+------+ +------+
|160121| |168231|
+------+ +------+
+------+ +------+ +------+
|168002| |168002| |160002|
+------+ +------+ +------+
+------+ +------+ +------+
|30030 | |30030 | |30030 |
+------+ +------+ +------+
Figure 8: BGP Hybrid Flexible Algorithm Aware Transport CAR Path
図 8: BGP ハイブリッド柔軟なアルゴリズム対応トランスポート CAR パス
* The following description applies to the reference topology above:
* 次の説明は、上記の参照トポロジに適用されます。
- IGP Flex-Algo 128 is only enabled in core (e.g., WAN network), mapped to C1. Access network domain only has Base Algo 0.
- IGP Flex-Algo 128 は、C1 にマッピングされたコア (WAN ネットワークなど) でのみ有効になります。アクセス ネットワーク ドメインには Base Algo 0 のみがあります。
- Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1 to steer traffic via BGP transport CAR (E2, C1). VPN route propagates via service RRs to ingress PE E1.
- 出力 PE E2 は、BGP トランスポート CAR (E2、C1) 経由でトラフィックを誘導するために、Color-EC C1 で色付けされた VPN ルート RD:V/v をアドバタイズします。VPN ルートはサービス RR を介して入力 PE E1 に伝播します。
- BGP CAR route (E2, C1) with next hop, label index, and label as shown above are advertised through BRs in each domain. When an RR is used in the domain, ADD-PATH is enabled to advertise multiple available paths.
- 上記のネクスト ホップ、ラベル インデックス、およびラベルを持つ BGP CAR ルート (E2、C1) は、各ドメインの BR を通じてアドバタイズされます。RR がドメインで使用されている場合、ADD-PATH が有効になり、複数の使用可能なパスをアドバタイズできます。
- Local policy on 231 and 232 maps intent C1 to resolve CAR route next hop over IGP Base Algo 0 in right access domain. The BGP CAR label swap entry is installed that goes over Base Algo 0 LSP to next hop. AIGP metric is updated to reflect Base Algo 0 metric to next hop with an additional penalty (+1000).
- 231 および 232 のローカル ポリシーは、適切なアクセス ドメインの IGP Base Algo 0 を介して CAR ルートのネクスト ホップを解決するために、インテント C1 をマップします。Base Algo 0 LSP を介してネクスト ホップに移動する BGP CAR ラベル スワップ エントリがインストールされます。AIGP メトリックは、ベース アルゴ 0 メトリックを追加のペナルティ (+1000) とともにネクスト ホップに反映するように更新されます。
- On 121 and 122, CAR route (E2, C1) next hop learnt from Core domain is resolved over IGP Flex-Algo 128. The BGP CAR label swap entry is installed that goes over Flex-Algo 128 LSP to next hop providing intent in Core IGP domain.
- 121 および 122 では、コア ドメインから学習された CAR ルート (E2、C1) ネクスト ホップは、IGP Flex-Algo 128 経由で解決されます。BGP CAR ラベル スワップ エントリは、Flex-Algo 128 LSP を経由して、コア IGP ドメインでインテントを提供するネクスト ホップにインストールされます。
- Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to resolve CAR route next hop over IGP Base Algo 0. It steers colored VPN route RD:V/v via (E2, C1).
- 入力 PE E1 は CAR ルート (E2、C1) を学習します。これは、IGP Base Algo 0 を介して CAR ルートのネクスト ホップを解決するためにインテント C1 をマッピングします。これは、(E2、C1) を介してカラーの VPN ルート RD:V/v を操作します。
* Important:
* 重要：
- IGP Flex-Algo 128 top label provides intent in Core domain.
- IGP Flex-Algo 128 のトップ ラベルは、コア ドメインにインテントを提供します。
- BGP CAR label (e.g., 168002) carries intent from PEs, which is realized in Core domain.
- BGP CAR ラベル (例: 168002) は PE からのインテントを伝送し、コア ドメインで実現されます。
RD:1/8 via E2
+-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ :
: :
: :
: :
+-:-----------------------+----------------------+-----------------:-+
| : | | : |
| : | | : |
| : (E2,C1) via 121 | (E2,C1) via 231 | (E2,C1) via E2 : |
| : L=242003,AIGP=1110+---+L=242002,AIGP=1010+---+ L=0x3 : |
| : |-------------------|121|<-----------------|231|<-------------|: |
| : V +---+ TE tunnel(231) +---+ |: |
|----+ | | +---|
| E1 | | | |E2 |
|----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1) via E2+---|
| ^ L=242004,AIGP=1210+---+L=242001,AIGP=1020+---+ L=0x3 | |
| |---------------- |122|<-----------------|232|<-------------| |
| +---+ TE tunnel(232) +---+ |
| | | |
| | | |
| IS-IS/LDP | IS-IS/RSVP-TE | IS-IS/LDP |
| Access 0 | Core | Access 1 |
+-------------------------+----------------------+-------------------+
iPE iABR eABR ePE
---------direction of traffic-------->
+------+ +------+
|240121| |241231|
+------+ +------+
+------+ +------+ +------+
|242003| |242002| |240002|
+------+ +------+ +------+
+------+ +------+ +------+
|30030 | |30030 | |30030 |
+------+ +------+ +------+
Figure 9: BGP CAR over TE Tunnel Mesh in Core Network
図 9: コア ネットワークの TE トンネル メッシュ上の BGP CAR
* The following description applies to the reference topology above:
* 次の説明は、上記の参照トポロジに適用されます。
- RSVP-TE MPLS tunnel mesh is configured only in core (e.g., WAN network). Access only has IS-IS/LDP. (The figure does not show all TE tunnels.)
- RSVP-TE MPLS トンネル メッシュは、コア (WAN ネットワークなど) でのみ設定されます。Access は IS-IS/LDP のみです。(この図にはすべての TE トンネルが示されているわけではありません。)
- Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1 to steer traffic via BGP transport CAR (E2, C1). VPN route propagates via service RRs to ingress PE E1.
- 出力 PE E2 は、BGP トランスポート CAR (E2、C1) 経由でトラフィックを誘導するために、Color-EC C1 で色付けされた VPN ルート RD:V/v をアドバタイズします。VPN ルートはサービス RR を介して入力 PE E1 に伝播します。
- BGP CAR route (E2, C1) with next hops and labels as shown above is advertised through BRs in each domain. When an RR is used in the domain, ADD-PATH is enabled to advertise multiple available paths.
- 上記のネクスト ホップとラベルを持つ BGP CAR ルート (E2、C1) は、各ドメインの BR を通じてアドバタイズされます。RR がドメインで使用されている場合、ADD-PATH が有効になり、複数の使用可能なパスをアドバタイズできます。
- Local policy on 231 and 232 maps intent C1 to resolve CAR route next hop over best-effort LDP LSP in access domain 1. The BGP CAR label swap entry is installed that goes over LDP LSP to next hop. AIGP metric is updated to reflect best-effort metric to next hop with an additional penalty (+1000).
- 231 および 232 のローカル ポリシーは、アクセス ドメイン 1 のベストエフォートのLDP LSP を介して CAR ルートのネクスト ホップを解決するために、意図 C1 をマップします。LDP LSP を介してネクスト ホップに移行する BGP CAR ラベル スワップ エントリがインストールされています。AIGP メトリックは、追加のペナルティ (+1000) を伴うネクスト ホップへのベスト エフォート メトリックを反映するように更新されます。
- Local policy on 121 and 122 maps intent C1 to resolve CAR route next hop in Core domain over RSVP-TE tunnels. The BGP CAR label swap entry is installed that goes over a TE tunnel to next hop providing intent in Core domain. AIGP metric is updated to reflect TE tunnel metric.
- 121 および 122 のローカル ポリシーは、RSVP-TE トンネルを介してコア ドメインの CAR ルート ネクスト ホップを解決するためにインテント C1 をマップします。BGP CAR ラベル スワップ エントリがインストールされ、TE トンネルを経由してネクスト ホップに到達し、コア ドメインにインテントを提供します。AIGP メトリックは、TE トンネル メトリックを反映するように更新されます。
- Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to resolve CAR route's next hop over best-effort LDP LSP in access domain 0. It steers colored VPN route RD:V/v via (E2, C1).
- 入力 PE E1 は CAR ルート (E2、C1) を学習します。インテント C1 をマップして、アクセス ドメイン 0 のベストエフォート型LDP LSP 上で CAR ルートのネクスト ホップを解決します。カラー VPN ルート RD:V/v を (E2、C1) 経由で操作します。
* Important:
* 重要：
- RSVP-TE tunnel LSP provides intent in Core domain.
- RSVP-TE トンネル LSP は、コア ドメインにインテントを提供します。
- Dynamic BGP CAR label carries intent from PEs, which is realized in Core domain by resolution via RSVP-TE tunnel.
- 動的 BGP CAR ラベルは PE からのインテントを伝送し、RSVP-TE トンネルを介した解決によってコア ドメインで実現されます。
* In a brownfield deployment, color-aware paths between two PEs may need to go through a transit domain that does not support CAR. Examples of such a brownfield network include an MPLS LDP network with IGP best-effort, or a multi-domain network based on BGP-LU. An MPLS LDP network with best-effort IGP can adopt the above scheme in Appendix A.3. Below is the example scenario for BGP-LU.
* ブラウンフィールド展開では、2 つの PE 間のカラー対応パスは、CAR をサポートしていないトランジット ドメインを経由する必要がある場合があります。このようなブラウンフィールド ネットワークの例には、IGP ベストエフォートを備えた MPLSLDP ネットワーク、または BGP-LU に基づくマルチドメイン ネットワークが含まれます。ベストエフォート IGP を備えた MPLSLDP ネットワークは、付録 A.3 の上記の方式を採用できます。以下は、BGP-LU のシナリオ例です。
* Reference topology:
* 参照トポロジ:
E1 --- BR1 --- BR2 ......... BR3 ---- BR4 --- E2
Ci <----LU----> Ci
Figure 10: BGP CAR Not Supported in Transit Domain
図 10: BGP CAR はトランジット ドメインではサポートされない
- Network between BR2 and BR3 comprises of multiple BGP-LU hops (over IGP-LDP domains).
- BR2 と BR3 の間のネットワークは、複数の BGP-LU ホップ (IGP-LDP ドメイン経由) で構成されます。
- E1, BR1, BR4, and E2 are enabled for BGP CAR, with Ci colors.
- BGP CAR では E1、BR1、BR4、および E2 が Ci カラーで有効になります。
- BR1 and BR2 are directly connected; BR3 and BR4 are directly connected.
- BR1 と BR2 は直接接続されています。BR3とBR4は直結されています。
* BR1 and BR4 form an over-the-top peering (via RRs as needed) to exchange BGP CAR routes.
* BR1 と BR4 は、BGP CAR ルートを交換するために（必要に応じて RR を介して）オーバーザトップ ピアリングを形成します。
* BR1 and BR4 also form direct BGP-LU sessions to BR2 and BR3, respectively, to establish labeled paths between each other through the BGP-LU network. The sessions may be eBGP or iBGP.
* また、BR1 と BR4 は、それぞれ BR2 と BR3 への直接 BGP-LU セッションを形成し、BGP-LU ネットワークを介して相互間にラベル付きパスを確立します。セッションは eBGP または iBGP の場合があります。
* BR1 recursively resolves the BGP CAR next hop for CAR routes learnt from BR4 via the BGP-LU path to BR4.
* BR1 は、BR4 への BGP-LU パスを介して BR4 から学習した CAR ルートの BGP CAR ネクスト ホップを再帰的に解決します。
* BR1 signals the transport discontinuity to E1 via the AIGP TLV, so that E1 can prefer other paths if available.
* BR1 は、AIGP TLV 経由でトランスポートの不連続性を E1 に通知するため、E1 は利用可能な場合は他のパスを優先できます。
* BR4 does the same in the reverse direction.
* BR4 は逆方向に同じことを行います。
* Thus, the color awareness of the routes, and hence the paths in the data plane, are maintained between E1 and E2, even if the intent is not available within the BGP-LU island.
* したがって、BGP-LU アイランド内でインテントが利用できない場合でも、ルートのカラー認識、つまりデータ プレーン内のパスは E1 と E2 の間で維持されます。
* A similar design can be used for going over network islands of other types.
* 同様の設計を、他のタイプのネットワーク アイランドを経由するために使用できます。
This example illustrates a case of resource avoidance within a domain for a multi-domain color-aware path.
この例は、マルチドメインの色認識パスのドメイン内でのリソース回避のケースを示しています。
+-------------+ +-------------+
| | | | V/v with C1
|----+ |------| +----|/
| E1 | | | | E2 |\
|----+ | | +----| W/w with C2
| |------| IGP FA128 |
| IGP FA128 | | IGP FA129 |
| Domain 1 | | Domain 2 |
+-------------+ +-------------+
Figure 11: BGP CAR Resolution over IGP Flexible Algorithm for Resource Avoidance in a Domain
図 11: ドメイン内のリソース回避のための IGP 柔軟なアルゴリズムを介した BGP CAR 解決
* C1 and C2 represent the following two unique intents in the multi-domain network:
* C1 と C2 は、マルチドメイン ネットワークにおける次の 2 つの固有のインテントを表します。
- C1 is mapped to "minimize IGP metric", and
- C1 は「IGP メトリックを最小化」するようにマッピングされており、
- C2 is mapped to "minimize IGP metric and avoid resource R".
- C2 は、「IGP メトリックを最小化し、リソース R を回避する」ようにマッピングされます。
* Resource R represents link(s) or node(s) to be avoided.
* リソース R は、回避すべきリンクまたはノードを表します。
* Flex-Algo 128 in Domain 2 is mapped to "minimize IGP metric", and hence to C1.
* ドメイン 2 の Flex-Algo 128 は、「IGP メトリックを最小化」するようにマッピングされているため、C1 にマッピングされています。
* Flex-Algo 129 in Domain 2 is mapped to "minimize IGP metric and avoid resource R", and hence to C2.
* ドメイン 2 の Flex-Algo 129 は、「IGP メトリックを最小化し、リソース R を回避する」ためにマッピングされ、したがって C2 にマッピングされます。
* Flex-Algo 128 in Domain 1 is mapped to "minimize IGP metric" (i.e., there is no resource R to be avoided in Domain 1, hence both C1 and C2 are mapped to Flex-Algo 128).
* ドメイン 1 の Flex-Algo 128 は、「IGP メトリックを最小化する」ためにマッピングされます (つまり、ドメイン 1 には回避すべきリソース R がないため、C1 と C2 の両方が Flex-Algo 128 にマッピングされます)。
* E1 receives the following two service routes from E2:
* E1 は、E2 から次の 2 つのサービス ルートを受信します。
- V/v with BGP Color-EC C1, and
- BGP Color-EC C1 を使用した V/v、および
- W/w with BGP Color-EC C2.
- BGP Color-EC C2 との併用。
* E1 has the following color-aware paths:
* E1 には次の色認識パスがあります。
- (E2, C1) provided by BGP CAR with the following per-domain resolution:
- (E2、C1) BGP CAR によって提供され、次のドメインごとの解像度が使用されます。
o Domain 1: over IGP Flex-Algo 128, and
o ドメイン 1: IGP Flex-Algo 128 経由、および
o Domain 2: over IGP Flex-Algo 128.
o ドメイン 2: IGP Flex-Algo 128 経由。
- (E2, C2) provided by BGP CAR with the following per-domain resolution:
- (E2、C2) BGP CAR によって提供され、次のドメインごとの解像度が使用されます。
o Domain 1: over IGP Flex-Algo 128, and
o ドメイン 1: IGP Flex-Algo 128 経由、および
o Domain 2: over IGP Flex-Algo 129 (avoiding resource R).
o ドメイン 2: IGP Flex-Algo 129 経由 (リソース R を回避)。
* E1 automatically steers the received service routes as follows:
* E1 は、受信したサービス ルートを次のように自動的に制御します。
- V/v via (E2, C1) provided by BGP CAR.
- BGP CAR によって提供される (E2、C1) 経由の V/v。
- W/w via (E2, C2) provided by BGP CAR.
- BGP CAR によって提供される (E2、C2) 経由の W/W。
Observations:
所見:
* C1 and C2 are realized over a common intra-domain intent (Flex-Algo 128) in one domain and distinct intents in another domain as required.
* C1 と C2 は、1 つのドメインでは共通のドメイン内インテント (Flex-Algo 128) を介して実現され、必要に応じて別のドメインでは個別のインテントが実現されます。
* 32-bit Color space provides flexibility in defining a large number of intents in a multi-domain network. They may be efficiently realized by mapping to a smaller number of intra-domain intents in different domains.
* 32 ビット カラー スペースにより、マルチドメイン ネットワークで多数のインテントを柔軟に定義できます。これらは、異なるドメイン内の少数のドメイン内インテントにマッピングすることで効率的に実現できます。
This section provides an example of ingress PE per-flow steering as defined in Section 8.6 of [RFC9256] onto BGP CAR routes.
このセクションでは、[RFC9256] のセクション 8.6 で定義されている BGP CAR ルートへの入力 PE フローごとのステアリングの例を示します。
The following description applies to the reference topology in Figure 6:
次の説明は、図 6 の参照トポロジに適用されます。
* Ingress PE E1 learns best-effort BGP-LU route E2.
* 入力 PE E1 はベストエフォート BGP-LU ルート E2 を学習します。
* Ingress PE E1 learns CAR route (E2, C1), C1 is mapped to "low delay".
* 入力 PE E1 は CAR ルート (E2、C1) を学習し、C1 は「低遅延」にマッピングされます。
* Ingress PE E1 learns CAR route (E2, C2), C2 is mapped to "low delay and avoid resource R".
* 入力 PE E1 は CAR ルート (E2、C2) を学習し、C2 は「低遅延でリソース R を回避」にマッピングされます。
* Ingress PE E1 is configured to instantiate an array of paths to E2 where entry 0 is the BGP-LU path to next hop, color C1 is the first entry, and color C2 is the second entry. The index into the array is called a Forwarding Class (FC). The index can have values 0 to 7, especially when derived from the MPLS TC bits [RFC5462].
* 入力 PE E1 は、E2 へのパスの配列をインスタンス化するように構成されています。ここで、エントリ 0 はネクスト ホップへの BGP-LU パス、カラー C1 が最初のエントリ、カラー C2 が 2 番目のエントリです。配列へのインデックスは、転送クラス (FC) と呼ばれます。インデックスは、特に MPLS TC ビット [RFC5462] から派生した場合、値 0 ～ 7 を持つことができます。
* E1 is configured to match flows in its ingress interfaces (upon any field such as Ethernet destination/source/VLAN/TOS or IP destination/source/DSCP or transport ports, etc.) and color them with an internal per-packet FC variable (0, 1, or 2 in this example).
* E1 は、入力インターフェイス（イーサネット宛先/送信元/VLAN/TOS、IP 宛先/送信元/DSCP、トランスポート ポートなどの任意のフィールド）でフローを照合し、パケットごとの内部 FC 変数（この例では 0、1、または 2）で色を付けるように設定されています。
* This array is presented as a composite candidate path of SR Policy (E2, C100) and acts as a container for grouping constituent paths of different colors/best-effort. This representation provides automated steering for services colored with Color-EC C100 via paths of different colors. Note that Color-EC C100 is used as indirection to the composite policy configured on ingress PE.
* この配列は、SR ポリシー (E2、C100) の複合候補パスとして提示され、異なる色/ベストエフォートの構成パスをグループ化するためのコンテナとして機能します。この表現は、異なる色のパスを介して、Color-EC C100 で色分けされたサービスの自動ステアリングを提供します。Color-EC C100 は、入力 PE で設定された複合ポリシーへの間接として使用されることに注意してください。
* Egress PE E2 advertises a VPN route RD:V/v with Color-EC C100 to steer traffic via composite SR Policy (E2, C100) (i.e., FC array of paths).
* 出力 PE E2 は、複合 SR ポリシー (E2、C100) (つまり、パスの FC アレイ) を介してトラフィックを誘導するために、Color-EC C100 を使用して VPN ルート RD:V/v をアドバタイズします。
E1 receives three packets K, K1, and K2 on its incoming interface. These three packets match on the VPN route that recurses on E2. E1 colors these 3 packets with forwarding class 0, 1, and 2, respectively.
E1 は、受信インターフェイスで 3 つのパケット K、K1、および K2 を受信します。これら 3 つのパケットは、E2 で再帰する VPN ルートで一致します。E1 は、これら 3 つのパケットをそれぞれ転送クラス 0、1、および 2 で色付けします。
As a result:
結果として：
* E1 forwards K along the best-effort path to E2 (i.e., for the MPLS data plane, it pushes the best-effort label of E2).
* E1 は、ベストエフォート パスに沿って K を E2 に転送します (つまり、MPLS データ プレーンの場合、E2 のベストエフォート ラベルをプッシュします)。
* E1 forwards K1 along the (E2, C1) BGP CAR route.
* E1 は、(E2, C1) BGP CAR ルートに沿って K1 を転送します。
* E1 forwards K2 along the (E2, C2) BGP CAR route.
* E1 は、(E2, C2) BGP CAR ルートに沿って K2 を転送します。
+-------------+ +--------------+
| | | +----|
| |------| | E2 |(IP1)
|----+ | | +----|
| E1 | | | Domain 2 |
|----+ | +--------------+
| | +--------------+
| | | +----|
| Domain 1 |------| | E3 |(IP1)
+-------------+ | +----|
| Domain 3 |
+--------------+
Figure 12: BGP CAR Advertisements for Shared IP Addresses
図 12: 共有 IP アドレスの BGP CAR アドバタイズメント
This example describes a case where a route for the same transport IP address is originated from multiple nodes in different network domains.
この例では、同じトランスポート IP アドレスのルートが異なるネットワーク ドメインの複数のノードから発信されるケースについて説明します。
One use of this scenario is an anycast transport service, where packet encapsulation (e.g., LSP) may terminate on any one among a set of nodes. All the nodes are capable of forwarding the inner payload, typically via an IP lookup in the global table for Internet routes.
このシナリオの 1 つの用途は、パケットのカプセル化 (LSP など) がノードのセットの中の任意の 1 つで終了する可能性があるエニーキャスト トランスポート サービスです。すべてのノードは、通常、インターネット ルートのグローバル テーブル内の IP ルックアップを介して、内部ペイロードを転送できます。
A couple of variations of the use case are described in the example below.
ユースケースのいくつかのバリエーションを以下の例で説明します。
One node is shown in each domain, but there will be multiple nodes in practice for redundancy.
各ドメインに 1 つのノードが示されていますが、実際には冗長性を確保するために複数のノードが存在します。
Example 1: Anycast with forwarding to nearest egress:
例 1: 最も近い出力への転送を伴うエニーキャスト:
* Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise Anycast (shared) IP (IP1, C1) with same label L1.
* E2 (出力ドメイン 2) と E3 (出力ドメイン 3) は両方とも、同じラベル L1 でエニーキャスト (共有) IP (IP1、C1) をアドバタイズします。
* An ingress PE E1 receives by default the best path(s) for (IP1, C1) propagated through BGP hops across the network.
* 入力 PE E1 は、デフォルトで、ネットワーク全体の BGP ホップを通じて伝播された (IP1、C1) の最適なパスを受信します。
* The paths to (IP1, C1) from E2 and E3 may merge at a common node along the path to E1, forming equal cost multipaths or active-backup paths at that node.
* E2 および E3 から (IP1、C1) へのパスは、E1 へのパスに沿った共通ノードで合流し、そのノードで等コスト マルチパスまたはアクティブ バックアップ パスを形成する場合があります。
* Service route V/v is advertised from egress domains D2 and D3 with color C1 and next hop IP1.
* サービス ルート V/v は、カラー C1 およびネクスト ホップ IP1 で出力ドメイン D2 および D3 からアドバタイズされます。
* Traffic for V/v steered at E1 via (IP1, C1) is forwarded to either E2 or E3 (or both) as determined by routing along the network (nodes in the path).
* (IP1、C1) を介して E1 でステアリングされる V/v のトラフィックは、ネットワーク (パス内のノード) に沿ったルーティングによって決定されるように、E2 または E3 (または両方) に転送されます。
Example 2: Anycast with egress domain visibility at ingress PE:
例 2: 入力 PE で出力ドメインの可視性を備えたエニーキャスト:
* E2 advertises (IP1, C1) and E3 advertises (IP1, C2) CAR routes for the Anycast IP IP1. C1 and C2 are colors assigned to distinguish the egress domains originating the routes to IP1.
* E2 はエニーキャスト IP IP1 の CAR ルート (IP1、C1) をアドバタイズし、E3 は (IP1、C2) CAR ルートをアドバタイズします。C1 と C2 は、IP1 へのルートを発信する出力ドメインを区別するために割り当てられた色です。
* An ingress PE E1 receives the best path(s) propagated through BGP hops across the network for both (IP1, C1) and (IP1, C2).
* 入力 PE E1 は、(IP1、C1) と (IP1、C2) の両方について、BGP ホップを通じてネットワーク全体に伝播された最適なパスを受信します。
* The CAR routes (IP1, C1) and (IP1, C2) do not get merged at any intermediate node, providing E1 control over path selection and load-balancing of traffic across these two routes. Each route may itself provide multipathing or anycast to a set of egress nodes.
* CAR ルート（IP1、C1）と（IP1、C2）は中間ノードでマージされず、これら 2 つのルートにわたるパス選択とトラフィックのロード バランシングに対する E1 制御が提供されます。各ルート自体は、一連の出力ノードにマルチパスまたはエニーキャストを提供できます。
* Service route V/v advertised from egress domains D2 and D3 with colors C1 and C2, respectively, but with same next hop IP1.
* サービス ルート V/v は、出力ドメイン D2 と D3 からそれぞれ色 C1 と C2 でアドバタイズされますが、ネクスト ホップ IP1 は同じです。
* E1 will resolve and steer V/v path from D2 via (IP1, C1) and path from D3 via (IP2, C2). E1 will load-balance traffic to V/v across the two paths as determined by a local load-balancing policy.
* E1 は、(IP1、C1) を介して D2 からの V/v パスと、(IP2、C2) を介して D3 からの V/v パスを解決してステアリングします。E1 は、ローカルのロード バランシング ポリシーによって決定されたとおり、2 つのパス全体で V/v へのトラフィックのロード バランシングを行います。
* Traffic for colored service routes steered at E1 is forwarded to either E2 or E3 (or load-balanced across both) as determined by E1.
* E1 で誘導される色付きサービス ルートのトラフィックは、E1 の決定に従って E2 または E3 (または両方で負荷分散) に転送されます。
In above example, D2 and D3 belonged to the same color or administrative domain. If D2 and D3 belong to different color domains, the domains will coordinate the assignment of colors with shared IP IP1 so that they do not cause conflicts. For instance, in Example 1:
上の例では、D2 と D3 は同じ色または管理ドメインに属していました。D2 と D3 が異なるカラー ドメインに属している場合、ドメインは競合が発生しないように、共有 IP IP1 を使用して色の割り当てを調整します。たとえば、例 1 では次のようになります。
* D2 and D3 may both use C1 for the same intent when they originate CAR route for IP1.
* D2 と D3 は両方とも、IP1 の CAR ルートを開始するときに、同じ目的で C1 を使用できます。
- In this case, neither D2 nor D3 will reuse C1 for some other intent.
- この場合、D2 も D3 も、他のインテントのために C1 を再利用しません。
* Alternatively, D2 may use C2 and D3 may use C3 for originating a CAR route for IP1 for the same intent.
* あるいは、同じ目的で IP1 の CAR ルートを発信するために、D2 が C2 を使用し、D3 が C3 を使用することもできます。
- In this case, D2 will not use C3 for originating CAR route for IP1 for some other intent. Similarly, D3 will not use C2 for originating CAR route for IP1 for some other intent.
- この場合、D2 は、他の目的で IP1 の発信元 CAR ルートに C3 を使用しません。同様に、D3 は、他のインテントの IP1 の発信元 CAR ルートに C2 を使用しません。
There are a variety of deployment scenarios that arise when different color mappings are used in an inter-domain environment. This section attempts to enumerate them and provide clarity into the usage of the color-related protocol constructs.
ドメイン間環境で異なるカラー マッピングが使用される場合、さまざまな展開シナリオが発生します。このセクションでは、それらを列挙し、色関連のプロトコル構成の使用法を明確に説明します。
* All network domains (ingress, egress, and all transit domains) are enabled for the same N colors.
* すべてのネットワーク ドメイン (入力、出力、およびすべてのトランジット ドメイン) が同じ N 色に対して有効になります。
- A color may of course be realized by different technologies in different domains as described above.
- もちろん、色は、上述したように、異なる領域の異なる技術によって実現されてもよい。
* The N intents are both signaled end-to-end via BGP CAR routes, as well as realized in the data plane.
* N 個のインテントは、BGP CAR ルートを介してエンドツーエンドで通知されるだけでなく、データ プレーンでも実現されます。
* Appendix A.1 is an example of this case.
* 付録 A.1 はこのケースの例です。
* Certain network domains may not be enabled for some of the colors used for end-to-end intents, but may still be required to provide transit for routes of those colors.
* 特定のネットワーク ドメインは、エンドツーエンド インテントに使用される一部の色に対して有効になっていない場合がありますが、それらの色のルートにトランジットを提供する必要がある場合があります。
* When a (E, C1) route traverses a domain where color C1 is not available, the operator may decide to use a different intent of color C2 that is available in that domain to resolve the next hop and establish a path through the domain.
* (E, C1) ルートがカラー C1 が利用できないドメインを通過する場合、オペレータは、そのドメインで利用可能な別のインテントのカラー C2 を使用して、ネクスト ホップを解決し、ドメインを経由するパスを確立することを決定する場合があります。
- The next-hop resolution may occur via paths of any intra-domain protocol or even via paths provided by BGP CAR.
- ネクストホップ解決は、任意のドメイン内プロトコルのパスを介して、または BGP CAR によって提供されるパスを介して発生する場合もあります。
- The next-hop resolution color C2 may be defined as a local policy at ingress or transit nodes of the domain.
- ネクストホップ解像度カラー C2 は、ドメインの入口ノードまたは通過ノードでローカル ポリシーとして定義できます。
- It may also be automatically signaled from egress border nodes by attaching a Color-EC with value C2 to the BGP CAR routes.
- また、値 C2 を持つ Color-EC を BGP CAR ルートに接続することにより、出力境界ノードから自動的に信号を送信することもできます。
* Hence, routes of N end-to-end colors may be resolved over paths from a smaller set of M colors in a transit domain, while preserving the original color awareness end-to-end.
* したがって、N 色のエンドツーエンド色のルートは、元の色認識をエンドツーエンドで維持しながら、トランジット ドメイン内の小さな M 色のセットからのパスを介して解決できます。
* Any ingress PE that installs a service (VPN) route with a color C1 must have C1 enabled locally to install IP routes to (E, C1) and resolve the service route's next hop.
* C1 の色でサービス (VPN) ルートをインストールする入力 PE では、(E、C1) への IP ルートをインストールし、サービス ルートのネクスト ホップを解決するには、C1 をローカルで有効にする必要があります。
* A degenerate variation of this scenario is where a transit domain does not support any color. Appendix A.3 describes an example of this case.
* このシナリオの退化バリエーションとして、トランジット ドメインがカラーをサポートしない場合があります。付録 A.3 では、このケースの例について説明します。
Illustration for N end-to-end intents over fewer M intra-domain intents:
少数の M 個のドメイン内インテントに対する N 個のエンドツーエンド インテントの図:
RD:V/v via E2 Color-EC: 100
RD:W/w via E2 Color-EC: 200
+-----+ RD:X/x via E2 Color-EC: 300 +-----+
...... |S-RR1| <..................................|S-RR2| <........
: +-----+ RD:Y/y via E2 Color-EC: 400 +-----+ :
: :
: :
: :
+-:---------------------+---------------------+----------------------:-+
| : | | : |
| | | |
| (E2,100) via 121 | (E2,100) via 231 | (E2,100) via E2 |
| Color-EC: 1,10 | Color-EC: 1,10 | Color-EC: 1,10 |
| | | |
| (E2,200) via 121 | (E2,200) via 231 | (E2,200) via E2 |
| Color-EC: 1,20 | Color-EC: 1,20 | Color-EC: 1,20 |
| <--- <---- |
| (E2,300) via 121 | (E2,300) via 231 | (E2,300) via E2 |
| Color-EC: 2,30 | Color-EC: 2,30 | Color-EC: 2,30 |
| | | |
| (E2,400) via 121 | (E2,400) via 231 | (E2,400) via E2 |
| Color-EC: 2,40 | Color-EC: 2,40 | Color-EC: 2,40 |
| | | |
| +===+ +===+ |
|====+ | |-------C10-------| | +=====|
| |-------C1-------| |-------C20-------| |-------C1-------| |
| E1 | |121| |231| | E2 |
| |-------C2-------| |-------C30-------| |-------C2-------| |
|====+ | |-------C40-------| | +=====|
| +===+ +===+ |
| C1=FA132 | C10=FA128 | C1=FA132 |
| C2=FA133 | C20=FA129 | C2=FA133 |
| | C30=FA130 | |
| | C40=FA131 | |
| | | |
| IS-IS SR | IS-IS SR | IS-IS SR |
| ACCESS | CORE | ACCESS |
+-----------------------+---------------------+------------------------+
iPE iABR eABR ePE
Figure 13: N:M Illustration
図 13: N:M の図
* The following description applies to the reference topology above:
* 次の説明は、上記の参照トポロジに適用されます。
- Core domain provides 4 intra-domain intents as described below:
- コア ドメインは、次に説明する 4 つのドメイン内インテントを提供します。
o FA128 mapped to C10,
o FA128 は C10 にマッピングされ、
o FA129 mapped to C20,
o FA129 は C20 にマッピングされ、
o FA130 mapped to C30, and
o FA130 は C30 にマッピングされ、
o FA131 mapped to C40.
o FA131 は C40 にマッピングされます。
- Access domain provides the following 2 intra-domain intents:
- アクセス ドメインは、次の 2 つのドメイン内インテントを提供します。
o FA132 mapped to C1, and
o FA132 は C1 にマッピングされ、
o FA133 mapped to C2.
o FA133 は C2 にマッピングされます。
- Operator defines the following 4 BGP CAR end-to-end intents as below:
- オペレーターは、次の 4 つの BGP CAR エンドツーエンド インテントを定義します。
o CAR color C100 that resolves on C1 in access and C10 in Core domain,
o アクセスの C1 とコア ドメインの C10 で解決される CAR カラー C100、
o CAR color C200 that resolves on C1 in access and C20 in Core domain,
o アクセスの C1 とコア ドメインの C20 で解決される CAR カラー C200、
o CAR color C300 that resolves on C2 in access and C30 in Core domain, and
o アクセスでは C2、コア ドメインでは C30 で解決される CAR カラー C300、および
o CAR color C400 that resolves on C2 in access and C40 in Core domain.
o アクセスでは C2、コア ドメインでは C40 で解決される CAR カラー C400。
- E2 may originate BGP CAR routes with multiple BGP Color-ECs as shown above. At each hop, CAR route's next hop is resolved over the available intra-domain color. For example (E2, C100) with BGP Color-ECs C1, C10 resolves over C1 at ABR 231, C10 at ABR 121, and C1 at E1.
- E2 は、上に示したように、複数の BGP Color-EC を使用して BGP CAR ルートを開始する場合があります。各ホップで、CAR ルートの次のホップは、利用可能なドメイン内カラーで解決されます。たとえば、BGP Color-EC C1、C10 の (E2、C100) は、ABR 231 の C1、ABR 121 の C10、および E1 の C1 で解決されます。
- Egress PE E2 advertises a VPN route RD:V/v colored with BGP Color-EC C100 to steer traffic through Flex-Algo 132 in access and Flex-Algo 128 in core. It also advertises another VPN route RD:W/w colored with BGP Color-EC C200 to steer traffic through Flex-Algo 132 in access and Flex-Algo 129 in core.
- 出力 PE E2 は、BGP Color-EC C100 でカラー化された VPN ルート RD:V/v をアドバタイズし、アクセスでは Flex-Algo 132、コアでは Flex-Algo 128 を介してトラフィックを誘導します。また、BGP Color-EC C200 でカラーリングされた別の VPN ルート RD:W/w をアドバタイズし、アクセスでは Flex-Algo 132、コアでは Flex-Algo 129 を介してトラフィックを誘導します。
* Important:
* 重要：
- End-to-end (BGP CAR) colors can be decoupled from intra-domain transport colors.
- エンドツーエンド (BGP CAR) カラーは、ドメイン内のトランスポート カラーから分離できます。
- Each end-to-end BGP CAR color is a combination of various intra-domain colors or intents.
- エンドツーエンドの BGP CAR の各色は、さまざまなドメイン内の色またはインテントの組み合わせです。
- Combination can be expressed by local policy at ABRs or by attaching multiple BGP Color-ECs at origination point of BGP CAR route.
- 組み合わせは、ABR でのローカル ポリシーによって、または BGP CAR ルートの開始点で複数の BGP Color-EC を接続することによって表現できます。
- Service traffic is steered into suitable CAR color to use the most granular intent in a domain multiple hops away from ingress PE.
- サービス トラフィックは、入力 PE から複数ホップ離れたドメイン内で最も詳細なインテントを使用するために、適切な CAR カラーに誘導されます。
- Consistent reuse of standard color-based resolution mechanism at both service and transport layers.
- サービス層とトランスポート層の両方で、標準のカラーベースの解決メカニズムを一貫して再利用します。
When the routes are distributed between domains with different color-to-intent mapping schemes, both N:N and N:M cases are possible. Although an N:M mapping is more likely to occur.
異なる色からインテントへのマッピング スキームを使用してルートがドメイン間で分散されている場合、N:N と N:M の両方のケースが考えられます。ただし、N:M マッピングが発生する可能性が高くなります。
Reference topology:
参照トポロジ:
D1 ----- D2 ----- D3
C1 C2 C3
Figure 14: Multiple Color Domains
図 14: 複数のカラー ドメイン
* C1 in D1 maps to C2 in D2 and to C3 in D3.
* D1 の C1 は D2 の C2 に、D3 の C3 にマッピングされます。
* BGP CAR is enabled in all three color domains.
* BGP CAR は 3 つのカラー ドメインすべてで有効になります。
The reference topology above is used to elaborate on the design described in Section 2.8
上記の参照トポロジは、セクション 2.8 で説明されている設計を詳しく説明するために使用されます。
When the route originates in color domain D1 and gets advertised to a different color domain D2, the following procedures apply:
ルートがカラー ドメイン D1 から発信され、別のカラー ドメイン D2 にアドバタイズされる場合、次の手順が適用されます。
* The NLRI of the BGP CAR route is preserved end to end (i.e., route is (E, C1)).
* BGP CAR ルートの NLRI はエンドツーエンドで保存されます (つまり、ルートは (E, C1))。
* A BR of D1 attaches LCM-EC with value C1 when advertising to a BR in D2.
* D1 の BR は、D2 の BR にアドバタイズするときに、値 C1 を持つ LCM-EC を付加します。
* A BR in D2 receiving (E, C1) maps C1 in received LCM-EC to local color, say C2.
* D2 受信 (E, C1) の BR は、受信した LCM-EC の C1 をローカル カラー、たとえば C2 にマッピングします。
- A BR in D2 may receive (E, C1) from multiple D1 BRs, which provide equal cost or primary/backup paths.
- D2 の BR は、等しいコストまたはプライマリ/バックアップ パスを提供する複数の D1 BR から (E, C1) を受信できます。
* Within D2, this LCM-EC value of C2 is used instead of the Color in CAR route NLRI (E, C1). This applies to all procedures described in the earlier section for a single color domain, such as next-hop resolution and service steering.
* D2 内では、C2 のこの LCM-EC 値が、CAR ルート NLRI (E、C1) のカラーの代わりに使用されます。これは、ネクストホップ解像度やサービスステアリングなど、単一カラードメインについて前のセクションで説明したすべての手順に当てはまります。
* A colored service route V/v originated in color domain D1 with next hop E and Color-EC C1 will also have its Color-EC value re-mapped to C2, typically at a service RR.
* カラー ドメイン D1 で発信され、ネクスト ホップ E および Color-EC C1 を持つカラー サービス ルート V/v も、通常はサービス RR でその Color-EC 値が C2 に再マッピングされます。
* On an ingress PE in D2, V/v will resolve via C2.
* D2 の入力 PE では、V/v は C2 経由で解決されます。
* When a BR in D2 advertises the route to a BR in D3, the same process repeats.
* D2 の BR が D3 の BR にルートをアドバタイズすると、同じプロセスが繰り返されます。
RD:V/v via E2
+-----+ SRv6SID=B:C11:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <.....
: +-----+ +-----+ :
: :
: :
: AS2 AS1 :
+-:------------------------------------+ +--------------:--+
| : | | : |
| : B:C11::/32 via IP1 | | : |
| : +-----+ LCM=C1, AIGP=10 | | : |
| : |T-RR |<.............. | | : |
| : +-----+<.......... : | | : |
| : : B:C11::/32 : : | | : |
| : : via IP2 : : | | : |
| : : LCM=C1,AIGP=10: : | | : |
| : ......... : : : | B:C11::/32 | : |
| : : : : : | via 231 | +-----|
| : : : : : | LCM=C1 | | E2 |
: : +---+ : +---+ : : | AIGP=10 | +-----|
| : : |P11|<.:..>|P13| : +----+ +---+ : |
| : : +---+ : +---+ : | 121|-----IP1|231| : |
| V V : : +----+ eBGP +---+ : |
|----+ : : | | +-----|
| E1 | +---+ : +---+ : | | | En |
|----+ |P12|<.:..>|P14| : | | +-----|
| +---+ +---+ : +----+ eBGP +---+ |
| IPv6 FIB: ...| 122|-----IP2|232| |
| B:C11::/32 via IP1 +----+ +---+ |
| via IP2 | B:C11::/32 | |
| | via 232 | |
| | LCM=C1 | |
| | AIGP=10 | |
| IS-ISv6 | | IS-ISv6 |
| FA128 (B:C12::/32) | |FA128(B:C11::/32)|
| FA0 (B:02::/32) | |FA0 (B:01::/32) |
+--------------------------------------+ +-----------------+
iPE ASBR ASBR ePE
Figure 15
The topology above is an example to illustrate the BGP CAR SRv6 locator prefix route-based design (Section 7.1.1) with hop-by-hop IPv6 routing within and between domains.
上記のトポロジは、ドメイン内およびドメイン間のホップバイホップ IPv6 ルーティングを使用した BGP CAR SRv6 ロケータ プレフィックス ルートベースの設計 (セクション 7.1.1) を示す例です。
* Multi-AS network with eBGP CAR session between ASBRs.
* ASBR 間の eBGP CAR セッションを使用したマルチ AS ネットワーク。
* Transport RR (T-RR) peers with P, BR, and PE clients within an AS to propagate CAR prefixes. ADD-PATH is enabled to propagate multiple paths.
* AS 内の P、BR、および PE クライアントとトランスポート RR (T-RR) ピアを接続して、CAR プレフィックスを伝播します。ADD-PATH は複数のパスを伝播するために有効です。
* IS-IS (IGP) Flex-Algo 128 for SRv6 is running in each AS (AS may consist of multiple IGP domains), where the following steps apply:
* SRv6 用の IS-IS (IGP) Flex-Algo 128 は各 AS (AS は複数の IGP ドメインで構成されている場合があります) で実行されており、次の手順が適用されます。
- Prefix B:C11::/32 summarizes Flex-Algo 128 block in AS1 for the given intent. Node locators in the egress domain are sub-allocated from the block for the given intent.
- プレフィックス B:C11::/32 は、特定のインテントに対する AS1 の Flex-Algo 128 ブロックを要約します。出口ドメインのノード ロケーターは、特定のインテントのブロックからサブ割り当てされます。
- Similarly, Prefix B:C12::/32 summarizes Flex-Algo 128 block in AS2.
- 同様に、プレフィックス B:C12::/32 は、AS2 の Flex-Algo 128 ブロックを要約します。
- Per Flex-Algo external subnets for eBGP next hops IP1 and IP2 are distributed in IS-IS within AS2.
- eBGP ネクスト ホップの Flex-Algo ごとの外部サブネット IP1 および IP2 は、AS2 内の IS-IS に分散されます。
* BGP CAR prefix route B:C11::/32 with LCM C1 is originated by AS1 BRs 231 and 232 on eBGP sessions to AS2 BRs 121 and 122.
* LCM C1 を使用した BGP CAR プレフィックス ルート B:C11::/32 は、AS2 BR 121 および 122 への eBGP セッション上の AS1 BR 231 および 232 によって発信されます。
* ASBR 121 and 122 propagate the route in AS2 to all the P, ABRs, and PEs through T-RR.
* ASBR 121 および 122 は、AS2 内のルートを T-RR を介してすべての P、ABR、および PE に伝播します。
* Every router in AS2 resolves BGP CAR prefix B:C11::/32 next hops IP1 and IP2 in IS-ISv6 Flex-Algo 128 and programs B:C11::/32 prefix in global IPv6 forwarding table.
* AS2 のすべてのルーターは、IS-ISv6 Flex-Algo 128 で BGP CAR プレフィックス B:C11::/32 ネクスト ホップ IP1 および IP2 を解決し、グローバル IPv6 転送テーブルで B:C11::/32 プレフィックスをプログラムします。
* AIGP attribute influences BGP CAR route best path decision.
* AIGP 属性は、BGP CAR ルートの最適パスの決定に影響します。
* Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service SID B:C11:2:DT4::. Service SID is allocated by E2 from its locator of color C1 intent.
* 出力 PE E2 は、SRv6 サービス SID B:C11:2:DT4:: を持つ VPN ルート RD:V/v をアドバタイズします。サービス SID は、カラー C1 インテントのロケーターから E2 によって割り当てられます。
* Ingress PE E1 learns (via service RRs S-RR1 and S-RR2) VPN route RD:V/v with SRv6 SID B:C11:2:DT4::.
* 入力 PE E1 は、(サービス RR S-RR1 および S-RR2 を介して) SRv6 SID B:C11:2:DT4:: の VPN ルート RD:V/v を学習します。
* Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is inherently steered hop by hop along IPv6 routed path to B:C11::/32 provided by BGP CAR in AS2.
* SRv6 サービス SID B:C11:2:DT4:: でカプセル化されたサービス トラフィックは、本質的に、AS2 の BGP CAR によって提供される B:C11::/32 への IPv6 ルーティング パスに沿ってホップごとに誘導されます。
* Encapsulated service traffic is inherently steered along IPv6 routed path to B:C11::/32 provided by IS-ISv6 Flex-Algo 128 in AS1.
* カプセル化されたサービス トラフィックは、本質的に、AS1 の IS-ISv6 Flex-Algo 128 によって提供される B:C11::/32 への IPv6 ルーティング パスに沿って誘導されます。
* Design applies to multiple ASNs. BGP next hop is rewritten across an eBGP hop.
* 設計は複数の ASN に適用されます。BGP ネクスト ホップは eBGP ホップ全体で書き換えられます。
Important:
重要：
* No tunneling/encapsulation on ingress PE and BRs for BGP CAR provided transport.
* BGP CAR が提供するトランスポートの入力 PE および BR にはトンネリング/カプセル化はありません。
* Uses longest prefix match of SRv6 Service SID to BGP CAR IP prefix. No mapping to labels/SIDs, instead use of simple IP-based forwarding.
* SRv6 サービス SID と BGP CAR IP プレフィックスの最長プレフィックス マッチを使用します。ラベル/SID へのマッピングは行わず、代わりに単純な IP ベースの転送を使用します。
Packet forwarding:
パケット転送:
@E1: IPv4 VRF V/v => H.Encaps.red <B:C11:2:DT4::> => Forward based
on B:C11::/32
@P*: IPv6 table: B:C11::/32 => Forward to interface, NH
@121: IPv6 Table: B:C11::/32 => Forward to interface, NH
@231: IPv6 table: B:C11:2::/48 :: => Forward via IS-ISv6 Flex-Algo
path to E2
@231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 Flex-Algo
path to E2
@E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
the inner DA in the VRF
RD:V/v via E2
+-----+ SRv6SID=B:C11:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ +-----+ :
: :
: :
: :
+-:-----------------------+----------------------+------------------:--+
| : | | : |
| : | | : |
| : B:C11::/32 via 121 | B:C11::/32 via 231 | : |
| : SID=B:C13:121:END:: | SID=B:C12:231:END:: | : |
| : LCM=C1,AIGP=110 +---+LCM=C1 AIGP=10 +---+ : |
| : |-------------------|121|<-----------------|231|<-------------| : |
| : V +---+ +---+ | : |
|----+ | | +-----|
| E1 | | | | E2 |
|----+ | | +-----|
| ^ | | : |
| | | | : |
| | | | +-----|
| | | | | En |
| | | | +-----|
| | +---+ +---+ | |
| |---------------- |122|<-----------------|232|<-------------| |
| +---+ +---+ |
| B:C11::/32 via 122 | B:C11::/32 via 232 | |
| SID=B:C13:122:END:: | SID=B:C12:232:END:: | |
| LCM=C1 AIGP=120 | LCM=C1 AIGP=20 | |
| | | |
| IS-ISv6 | IS-ISv6 | IS-ISv6 |
| FA128 (B:C13::/32) | FA128 (B:C12::/32) | FA128 (B:C11::/32) |
| FA0 (B:03::/32) | FA0 (B:02::/32) | FA0 (B:01::/32) |
+-------------------------+----------------------+---------------------+
iPE iABR eABR ePE
Figure 16
The topology above is an example to illustrate the BGP CAR SRv6 locator prefix route-based design (Section 7.1.1) with intra-domain encapsulation. The example shown is iBGP, but also applies to eBGP (multi-AS).
上記のトポロジは、ドメイン内カプセル化を使用した BGP CAR SRv6 ロケータ プレフィックス ルートベースの設計 (セクション 7.1.1) を示す例です。示されている例は iBGP ですが、eBGP (マルチ AS) にも当てはまります。
* IGP Flex-Algo 128 is running in each domain, where:
* IGP Flex-Algo 128 は各ドメインで実行されており、次のとおりです。
- Prefix B:C11::/32 summarizes Flex-Algo 128 block in egress domain for the given intent. Node locators in the egress domain are sub-allocated from the block.
- プレフィックス B:C11::/32 は、特定のインテントの出力ドメインの Flex-Algo 128 ブロックを要約します。出力ドメイン内のノード ロケーターは、ブロックからサブ割り当てされます。
- Prefix B:C12::/32 summarizes Flex-Algo 128 block in transit domain.
- プレフィックス B:C12::/32 は、トランジット ドメインの Flex-Algo 128 ブロックを要約します。
- Prefix B:C13::/32 summarizes Flex-Algo 128 block in ingress domain.
- プレフィックス B:C13::/32 は、イングレス ドメインの Flex-Algo 128 ブロックを要約します。
* BGP CAR route B:C11::/32 is originated by ABRs 231 and 232 with LCM C1. Along the propagation path, BRs set next-hop-self and appropriately update the intra-domain encapsulation information for the C1 intent. For example, 231 and 121 signal SRv6 SID of End behavior [RFC8986] allocated from their respective locators for the C1 intent. (Note: IGP Flexible Algorithm is shown for intra-domain path, but SR Policy may also provide the path as shown in Appendix C.3.)
* BGP CAR ルート B:C11::/32 は、LCM C1 を持つ ABR 231 および 232 によって発信されます。伝播パスに沿って、BR は next-hop-self を設定し、C1 インテントのドメイン内カプセル化情報を適切に更新します。たとえば、231 と 121 は、C1 インテントのそれぞれのロケーターから割り当てられた終了動作 [RFC8986] の SRv6 SID をシグナルします。(注: IGP フレキシブル アルゴリズムはドメイン内パスに示されていますが、付録 C.3 に示されているように SR ポリシーでもパスが提供される場合があります。)
* AIGP attribute influences BGP CAR route best path decision.
* AIGP 属性は、BGP CAR ルートの最適パスの決定に影響します。
* Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service SID B:C11:2:DT4::. Service SID is allocated by E2 from its locator of color C1 intent.
* 出力 PE E2 は、SRv6 サービス SID B:C11:2:DT4:: を持つ VPN ルート RD:V/v をアドバタイズします。サービス SID は、カラー C1 インテントのロケーターから E2 によって割り当てられます。
* Ingress PE E1 learns CAR route B:C11::/32 and VPN route RD:V/v with SRv6 SID B:C11:2:DT4::.
* 入力 PE E1 は、SRv6 SID B:C11:2:DT4:: を使用して CAR ルート B:C11::/32 および VPN ルート RD:V/v を学習します。
* Traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is steered along IPv6 routed path provided by BGP CAR IP Prefix route to locator B:C11::/32.
* SRv6 サービス SID B:C11:2:DT4:: でカプセル化されたトラフィックは、BGP CAR IP プレフィックス ルートによって提供される IPv6 ルーティング パスに沿ってロケーター B:C11::/32 に誘導されます。
Important:
重要：
* Uses longest prefix match of SRv6 Service SID to BGP CAR prefix. There is no mapping labels/SIDs; there is simple IP-based forwarding instead.
* SRv6 サービス SID と BGP CAR プレフィックスの最長プレフィックス マッチを使用します。マッピング ラベル/SID はありません。代わりに、単純な IP ベースの転送があります。
* Originating domain PE locators of the given intent can be summarized on transit BGP hops eliminating per PE state on BRs.
* 特定のインテントの発信元ドメイン PE ロケータは、BR 上の PE 状態ごとに排除されるトランジット BGP ホップで要約できます。
Packet forwarding:
パケット転送:
@E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red <B:C12:231:END::>
@231: My SID table: B:C12:231:END:: => Remove IPv6 header;
Inner DA B:C11:2:DT4::
@231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 Flex-Algo
path to E2
@E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
the inner DA in the VRF
RD:V/v via E2
+-----+ SRv6SID: B:01:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C2 +-----+ :
: :
: +-----+ (E2,C2) via 231 :
: -----------------|T-RR |-------------------| :
:| +-----+ SID=B:C21:2:B6:: | :
+-:|---------------------+---------------------|+------------------:--+
| :| | || : |
| :| | || : |
| :| B:C21::/32 via 121 | B:C21::/32 via 231 ||SR Policy(E2,C2) : |
| :| LCM=C2,AIGP=110 | LCM=C2 AIGP=10 ||BSID=B:C21:2:B6:: : |
| :| +---+ +---+ : |
| :|-------------------|121|<-----------------|231|<-------------| : |
| :V SR Policy(121,C2) +---+SR Policy(231,C2) +---+ | : |
|----+ | | +-----|
| E1 | | | | E2 |
|----+ | | +-----|
| ^ SR Policy(122,C2) +---+SR Policy(232,C2) +---+ | |
| |---------------- |122|<-----------------|232|<-------------| |
| B:C21::/32 via 121+---+B:C21::/32 via 232+---+ SR Policy(E2,C2) |
| LCM=C2,AIGP=120 | LCM=C2 AIGP=20 | BSID=B:C21:2:B6:: |
| | | |
| IS-ISv6 | IS-ISv6 | IS-ISv6 |
| FA0 (B:03::/32) | FA0 (B:02::/32) | FA0(B:01::/32) |
+------------------------+----------------------+---------------------+
iPE iABR eABR ePE
Figure 17
The topology above is an example to illustrate the BGP CAR (E, C) route-based design (Section 7.1.2). The example is iBGP, but the design also applies to eBGP (multi-AS).
上記のトポロジは、BGP CAR (E、C) ルートベースの設計 (セクション 7.1.2) を説明するための例です。この例は iBGP ですが、この設計は eBGP (マルチ AS) にも適用されます。
* SR Policy (E2, C2) provides given intent in egress domain.
* SR ポリシー (E2、C2) は、出力ドメインで特定のインテントを提供します。
- SR Policy (E2, C2) with segments <B:01:z:END::, B:01:2:END::>, where z is the node id in egress domain.
- セグメント <B:01:z:END::, B:01:2:END::> を持つ SR ポリシー (E2、C2)。z は出力ドメインのノード ID です。
* Egress ABRs 231 and 232 redistribute SR Policy into BGP CAR Type-1 NLRI (E2, C2) to other domains, with SRv6 SID of End.B6 behavior. This route is propagated to ingress PEs through T-RR or inline through BRs (121 and 122) with next-hop-unchanged.
* 出力 ABR 231 および 232 は、End.B6 動作の SRv6 SID を使用して、SR ポリシーを BGP CAR タイプ 1 NLRI (E2、C2) の他のドメインに再配布します。このルートは、T-RR を介して入力 PE に伝播されるか、ネクスト ホップが変更されない BR (121 および 122) を介してインラインで伝播されます。
* The ABRs also advertise BGP CAR prefix route (B:C21::/32) summarizing locator part of SRv6 SIDs for SR policies of given intent to different PEs in egress domain. BGP CAR prefix route propagates through BRs. At each BGP hop, BGP CAR prefix next-hop resolution triggers intra-domain transit SR Policy (C2, CAR next hop). For example:
* また、ABR は、特定のインテントの SR ポリシーの SRv6 SID のロケーター部分を要約する BGP CAR プレフィックス ルート (B:C21::/32) を出力ドメインのさまざまな PE にアドバタイズします。BGP CAR プレフィックス ルートは BR を介して伝播します。各 BGP ホップで、BGP CAR プレフィックス ネクスト ホップ解決により、ドメイン内トランジット SR ポリシー (C2、CAR ネクスト ホップ) がトリガーされます。例えば：
- SR Policy (231, C2) with segments <B:02:y:END::, B:02:231:END::>, and
- セグメント <B:02:y:END::, B:02:231:END::> を含む SR ポリシー (231、C2)、および
- SR Policy (121, C2) with segments <B:03:x:END::, B:03:121:END::>,
- セグメント <B:03:x:END::, B:03:121:END::> を含む SR ポリシー (121、C2)、
- where x and y are node ids within the respective domains.
- ここで、x と y はそれぞれのドメイン内のノード ID です。
* Egress PE E2 advertises a VPN route RD:V/v with Color-EC C2.
* 出力 PE E2 は、Color-EC C2 を使用して VPN ルート RD:V/v をアドバタイズします。
* Ingress PE E1 steers VPN route from E2 onto BGP CAR route (E2, C2) that results in H.Encaps.red of SRv6 transport SID B:C21:2:B6:: and SRv6 Service SID as last segment in IPv6 header.
* 入力 PE E1 は、VPN ルートを E2 から BGP CAR ルート (E2、C2) に誘導します。その結果、SRv6 トランスポート SID B:C21:2:B6:: の H.Encaps.red と、IPv6 ヘッダーの最後のセグメントとして SRv6 サービス SID が得られます。
* IPv6 destination B:C21:2:B6:: match on CAR prefix B:C21::/32 that steers the packet into intra-domain (intent-aware) SR Policy on ingress PE E1 and ABR 121.
* IPv6 宛先 B:C21:2:B6:: CAR プレフィックス B:C21::/32 と一致し、パケットを入力 PE E1 および ABR 121 のドメイン内（インテントアウェア）SR ポリシーに誘導します。
* IPv6 packet destination B:C21:2:B6:: lookup in mySID table on ABR 231 or 232 results in END.B6 behavior (i.e., push of policy segments to E2).
* ABR 231 または 232 の mySID テーブルでの IPv6 パケット宛先 B:C21:2:B6:: のルックアップは、END.B6 動作 (つまり、ポリシー セグメントの E2 へのプッシュ) になります。
Important:
重要：
* Ingress PE steers services via (E, C) CAR route as per [RFC9256].
* Ingress PE は、[RFC9256] に従って (E、C) CAR ルートを介してサービスを操作します。
* In data plane (E, C), resolution results in IPv6 header destination being SRv6 SID of END.B6 behavior whose locator is of given intent on originating ABRs.
* データ プレーン (E、C) では、解決の結果、IPv6 ヘッダーの宛先は END.B6 動作の SRv6 SID になり、そのロケーターは発信元 ABR に対する特定の意図を持ちます。
* CAR IP Prefix route along the transit path provides simple Longest Prefix Match (LPM) IPv6 forwarding along the transit BGP hops.
* トランジット パスに沿った CAR IP プレフィックス ルートは、トランジット BGP ホップに沿ったシンプルな Longest Prefix Match（LPM）IPv6 転送を提供します。
* CAR NLRI Type-2 prefix summarizes binding SIDs of all SR policies on originating ABR of a given intent to different PEs in egress domain. This eliminates per PE state on transit routers.
* CAR NLRI タイプ 2 プレフィックスは、出力ドメイン内の異なる PE に対する特定のインテントの発信元 ABR 上のすべての SR ポリシーのバインディング SID を要約します。これにより、中継ルーター上の PE ごとの状態が排除されます。
Packet forwarding:
パケット転送:
@E1: IPv4 VRF V/v => H.Encaps.red <B:C21:2:B6::, B:0:E2:DT4::>
H.Encaps.red <SR Policy (C2,121) sid list>
@121: My SID table: B:03:121:END:: => Remove outer IPv6 header;
Inner DA B:C21:2:B6::
@121: IPv6 Table: B:C21::/32 => H.Encaps.red <SR Policy (C2,231) sid
list>
@231: My SID table: B:02:231:END:: => Remove outer IPv6 header;
Inner DA B:C21:2:B6::
@231: MySIDtable B:C21:2:B6:: => H.Encaps.red <SR Policy (C2,E2) sid
list>
@E2: IPv6 Table B:0:2:DT4:: => Pop the outer header and look up the
inner DA in the VRF
CAR SAFI NLRI encoding is optimized for update packing. It allows per-route information (for example, label, label index, and SRv6 SID encapsulation data) to be carried in the non-key TLV part of NLRI. This allows multiple NLRIs to be packed in a single update message when other attributes (including LCM-EC, when present) are shared. The table below shows a theoretical analysis calculated from observed BGP update message size in operational networks. It compares total BGP data on the wire for CAR SAFI against encoding as specified in [RFC8277] in the following cases: an MPLS label (CASE A), an SR extension with MPLS (per-prefix label index in Prefix-SID attribute; see [RFC8669]) (CASE B), and an SRv6 SID (CASE C). The packing scenarios considered are as follows:
CAR SAFI NLRI エンコーディングは、アップデート パッキング用に最適化されています。これにより、ルートごとの情報 (ラベル、ラベル インデックス、SRv6 SID カプセル化データなど) を NLRI の非キー TLV 部分で伝送できるようになります。これにより、他の属性 (存在する場合は LCM-EC を含む) が共有される場合に、複数の NLRI を 1 つの更新メッセージにパックすることができます。以下の表は、運用ネットワークで観測された BGP 更新メッセージ サイズから計算された理論的分析を示しています。MPLS ラベル（ケース A）、MPLS による SR 拡張（プレフィックス SID 属性のプレフィックスごとのラベル インデックス、[RFC8669] を参照）（ケース B）、および SRv6 SID（ケース C）の場合に、CAR SAFI の回線上の合計 BGP データを [RFC8277] で指定されているエンコーディングと比較します。考慮される梱包シナリオは次のとおりです。
* the ideal case (where the maximum number of routes are packed to the update message limit of 4k bytes),
* 理想的なケース (ルートの最大数が 4k バイトの更新メッセージ制限に詰め込まれている場合)、
* the practical case of average packing (where 5 routes share a set of BGP path attributes, and hence are packed in a single update message), and
* 平均パッキングの実際のケース (5 つのルートが一連の BGP パス属性を共有するため、単一の更新メッセージにパッキングされる)、および
* the worst case of no packing (where each route is in a separate update message).
* パッキングがない最悪のケース (各ルートが個別の更新メッセージ内にある場合)。
+=============+=========+===========+==============================+
| Encoding | BGP CAR | NLRI as | Result |
| | NLRI | per | |
| | | [RFC8277] | |
+=============+=========+===========+==============================+
| CASE A: Label |
+=============+=========+===========+==============================+
| (Ideal) | 27.5 MB | 26 MB | No degradation compared to |
| | | | encoding as specified in |
| | | | [RFC8277]. |
+-------------+---------+-----------+ |
| (Practical) | 86 MB | 84 MB | |
+-------------+---------+-----------+ |
| (Worst; no | 325 MB | 324 MB | |
| packing) | | | |
+=============+=========+===========+==============================+
| CASE B: Label & Label-Index |
+=============+=========+===========+==============================+
| (Ideal) | 42 MB | 339 MB | CAR SAFI encoding is more |
| | | Packing | efficient by 88% in the best |
| | | not | case and 71% in the average |
| | | possible | case over the encoding as |
| | | | specified in [RFC8277] |
| | | | (which precludes packing). |
+-------------+---------+-----------+ |
| (Practical) | 99 MB | 339 MB | |
| | | Packing | |
| | | not | |
| | | possible | |
+-------------+---------+-----------+ |
| (Worst; no | 339 MB | 339 MB | |
| packing) | | | |
+=============+=========+===========+==============================+
| CASE C: SRv6 SID |
+=============+=========+===========+==============================+
| (Ideal) | 49 MB | 378 MB | Results are similar to the |
| | | Packing | SR-MPLS case. Transposition |
| | | not | provides a further 20% |
| | | possible | reduction in BGP data. |
+-------------+---------+-----------+ |
| (Practical) | 115 MB | 378 MB | |
| | | Packing | |
| | | not | |
| | | possible | |
+-------------+---------+-----------+ |
| (Worst; no | 378 MB | 378 MB | |
| packing) | | | |
+-------------+---------+-----------+------------------------------+
Table 5: Summary of the Ideal, Practical, and Worst Cases of Packing BGP Data
表 5: BGP データのパッキングの理想的なケース、実際的なケース、および最悪のケースのまとめ
This analysis considers 1.5 million routes (5 colors across 300k endpoints).
この分析では、150 万のルート (30 万のエンドポイントにわたる 5 色) が考慮されます。
CASE A: BGP data exchanged for MPLS (non-SR):
ケース A: MPLS 用に交換される BGP データ (非 SR):
Consider 200 bytes of shared attributes
CAR SAFI signals label in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 5(label) = 17 bytes
Ideal packing:
Number of NLRIs in 4k update size = 223 (4k-200/17)
Number of update messages of 4k size = 1.5 million/223 = 6726
Total BGP data on wire = 6726 * 4k = ~27.5 MB
Practical packing (5 routes in update message):
Size of update message = (17 * 5) + 200 = 285
Total BGP data on wire = 285 * 300k = ~86 MB
No-packing case (1 route per update message):
Size of update message = 17 + 200 = 217
Total BGP data on wire = 217 * 1.5 million = ~325 MB
SAFI 128 using encoding specified in RFC 8277 with label in NLRI
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing:
Number of NLRIs in 4k update size = 237 (4k-200/16)
Number of update messages of 4k size = 1.5 million/237 = ~6330
Total BGP data on wire = 6330 * 4k = ~25.9 MB
Practical packing (5 routes in update message):
Size of update message = (16 * 5) + 200 = 280
Total BGP data on wire = 280 * 300k = ~84 MB
No-packing case (1 route per update message):
Size of update message = 16 + 200 = 216
Total BGP data on wire = 216 * 1.5 million = ~324 MB
CASE B: BGP data exchanged for SR-MPLS label index:
ケース B: SR-MPLS ラベル インデックスのために交換される BGP データ:
Consider 200 bytes of shared attributes
CAR SAFI signals label index in non-key TLV part of NLRI
Each NLRI size for AFI 1
= 12(key) + 5(label) + 9(Index) = 26 bytes
Ideal packing:
Number of NLRIs in 4k update size = 146 (4k-200/26)
Number of update messages of 4k size = 1.5 million/146 = 6726
Total BGP data on wire = 10274 * 4k = ~42 MB
Practical packing (5 routes in update message)
Size of update message = (26 * 5) + 200 = 330
Total BGP data on wire = 330 * 300k = ~99 MB
No-packing case (1 route per update message)
Size of update message = 26 + 200 = 226
Total BGP data on wire = 226 * 1.5 million = ~339 MB
SAFI 128 using encoding specified in RFC 8277 with label in NLRI
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing:
Not supported as label index is encoded in Prefix-SID
attribute
Practical packing (5 routes in update message):
Not supported as label index is encoded in Prefix-SID
attribute
No-packing case (1 route per update message):
Size of update message = 16 + 210 = 226
Total BGP data on wire = 216 * 1.5 million = ~339 MB
CASE C: BGP data exchanged with 128 bit single SRv6 SID:
ケース C: 128 ビットの単一 SRv6 SID で交換される BGP データ:
Consider 200 bytes of shared attributes
CAR SAFI signals SRv6 SID in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 18(SRv6 SID) = 30 bytes
Ideal packing:
Number of NLRIs in 4k update size = 126 (4k-200/30)
Number of update messages of 4k size = 1.5 million/126 = ~12k
Total BGP data on wire = 12k * 4k = ~49 MB
Practical packing (5 routes in update message):
Size of update message
= (30 * 5) + 236 (including Prefix-SID) = 386
Total BGP data on wire = 386 * 300k = ~115 MB
No-packing case (1 route per update message):
Size of update message = 12 + 236 (SID in Prefix-SID) = 252
Total BGP data on wire = 252 * 1.5 million = ~378 MB
SAFI 128 using encoding specified in RFC 8277 with label in NLRI
(No transposition)
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing:
Not supported as SRv6 SID is encoded in Prefix-SID
attribute
Practical packing (5 routes in update message):
Not supported as SRv6 SID is encoded in Prefix-SID
attribute
No-packing case (1 route per update message):
Size of update message = 16 + 236 = 252
Total BGP data on wire = 252 * 1.5 million = ~378 MB
BGP data exchanged with transposition of 4 bytes from SRv6 SID into SRv6 SID TLV:
SRv6 SID から SRv6 SID TLV に 4 バイトを転置して交換される BGP データ:
Consider 200 bytes of shared attributes
CAR SAFI signals SRv6 SID in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 6(SRv6 SID) = 18 bytes
Ideal packing:
Number of NLRIs in 4k update size = 211 (4k-200/18)
Number of update messages of 4k size = 1.5 million/211 = ~7110
Total BGP data on wire = 7110 * 4k = ~29 MB
Practical packing (5 routes in update message):
Size of update message
= (18 * 5) + 236 (including Prefix-SID) = 326
Total BGP data on wire = 326 * 300k = ~98 MB
No-packing case (1 route per update message):
Size of update message
= 12 + 236 (SID in Prefix-SID attribute) = 252
Total BGP data on wire = 252 * 1.5 million = ~378 MB
The authors would like to acknowledge the invaluable contributions of many collaborators towards the BGP CAR solution and this document in providing input about use cases, participating in brainstorming and mailing list discussions and in reviews of the solution and draft revisions. In addition to the contributors listed in the Contributors section, the authors would like to thank Robert Raszuk, Bin Wen, Chaitanya Yadlapalli, Satoru Matsushima, Moses Nagarajah, Gyan Mishra, Jorge Rabadan, Daniel Voyer, Stephane Litkowski, Hannes Gredler, Jose Liste, Jakub Horn, Brent Foster, Dave Smith, Jiri Chaloupka, Miya Kohno, Kamran Raza, Zafar Ali, Xing Jiang, Oleksander Nestorov, Peter Psenak, Kaliraj Vairavakkalai, Natrajan Venkataraman, Srihari Sangli, Ran Chen, and Jingrong Xie.
著者らは、BGP CAR ソリューションとこのドキュメントに対する多くの協力者の、ユースケースに関する意見の提供、ブレーンストーミングやメーリング リストのディスカッションへの参加、ソリューションと改訂草案のレビューなどの貴重な貢献に感謝したいと思います。「寄稿者」セクションに記載されている寄稿者に加えて、著者は Robert Raszuk、Bin Wen、Chaitanya Yadlapalli、松島悟、Moses Nagarajah、Gyan Mishra、Jorge Rabadan、Daniel Voyer、Stephane Litkowski、Hannes Gredler、Jose Liste、Jakub Horn、Brent Foster、Dave Smith、Jiri Chaloupka、河野美也、カムラン・ラザ、ザファル・アリ、シン・ジャン、オレクサンダー・ネストロフ、ピーター・プセナク、カリラージ・ヴァイラヴァッカライ、ナトラジャン・ヴェンカタラマン、シュリハリ・サンリ、ラン・チェン、ジンロン・シェ。
The authors also appreciate the detailed reviews and astute suggestions provided by Sue Hares (as document shepherd), Jeff Haas, Yingzhen Qu, and John Scudder that have greatly improved the document.
著者らはまた、文書を大幅に改善した Sue Hares (文書の保護者として)、Jeff Haas、Yingzhen Qu、および John Scudder によって提供された詳細なレビューと鋭い提案にも感謝しています。
The following people gave substantial contributions to the content of this document and should be considered as coauthors:
次の人々はこの文書の内容に多大な貢献をしたので、共著者として考慮する必要があります。
Clarence Filsfils
Cisco Systems
Belgium
Email: cfilsfil@cisco.com
Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
Luay Jalil
Verizon
United States of America
Email: luay.jalil@verizon.com
Yuanchao Su
Alibaba, Inc
Email: yitai.syc@alibaba-inc.com
Jim Uttaro
Individual
United States of America
Email: juttaro@ieee.org
Jim Guichard
Futurewei
United States of America
Email: james.n.guichard@futurewei.com
Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
Keyur Patel
Arrcus, Inc
United States of America
Email: keyur@arrcus.com
Haibo Wang
Huawei Technologies
China
Email: rainsword.wang@huawei.com
Jie Dong
Huawei Technologies
China
Email: jie.dong@huawei.com
Additional contributors:
追加の貢献者:
Dirk Steinberg
Lapishills Consulting Limited
Germany
Email: dirk@lapishills.com
Israel Means
AT&T
United States of America
Email: im8327@att.com
Reza Rokui
Ciena
United States of America
Email: rrokui@ciena.com
Dhananjaya Rao (editor)
Cisco Systems
United States of America
Email: dhrao@cisco.com
Swadesh Agrawal (editor)
Cisco Systems
United States of America
Email: swaagraw@cisco.com