メインコンテンツまでスキップ

2. BGP CAR SAFI

2.1. Data Model (データモデル)​

BGP CARデータモデルは以下の通りです:

NLRI key (NLRIキー): はじめにで説明したユースケースに対応するため、2つのカテゴリに分類されます:

Type-1 (タイプ1): キーはIPプレフィックスとカラー (E, C) です。NLRIキー内のカラーは、共通のIPプレフィックスに対するカラー感知ルートを区別し、インテントごとに1つです。カラーは、ルートに関連付けられたインテントも示します。

Type-2 (タイプ2): キーはIPプレフィックス (E) です。インテントに割り当てられた一意のIPプレフィックス（すなわち、IPプレフィックス == インテント）がカラー感知ルートを区別します。カラーは区別子としてNLRIキーに含める必要はありません。

NLRI non-key encapsulation data (NLRI非キーカプセル化データ): NLRIに関連付けられたデータ。MPLSラベルスタック、SR-MPLSラベルインデックス、SRv6 SIDリストなど。セクション2.9.2で説明するTLVに含まれます。

BGP next hop (BGPネクストホップ): 特定のNLRIキーに関連付けられたネクストホップアドレス [RFC4760]。

AIGP metric [RFC7311] (AIGPメトリック): 複数のBGPホップにわたってカラー/インテント固有のCARルートメトリック値を累積します。

Local Color Mapping Extended Community (LCM-EC) (ローカルカラーマッピング拡張コミュニティ): CARルートに関連付けられたインテントを表すオプションの非ゼロ32ビットカラー値:

  • CARルートが異なるカラードメイン間で伝播される場合
  • CARルートがインテント用の一意のIPプレフィックスを持つ場合

BGP Color Extended Community (Color-EC) [RFC9012] (BGPカラー拡張コミュニティ): BGP CARネクストホップに関連付けられたインテントを表すオプションの非ゼロ32ビットカラー値。ネクストホップのインテント/カラーがCARルートのインテント/カラーと異なる場合の自動ルート解決に [RFC9256] に従って使用されます。

以下のセクションでは、データモデルを詳細に説明します。CAR SAFIプロトコル処理を説明するセクションは、一般的に両方のルートタイプに一貫して適用されます（例：カラーベースの操作）。例では簡単のため (E, C) を使用します。

2.2. Extensible Encoding (拡張可能なエンコーディング)​

拡張可能なエンコーディングは以下を通じて提供されます:

NLRI Type field (NLRIタイプフィールド): これは、新しいルートタイプをサポートするために新しいNLRI形式を追加する拡張性を提供します。

Type-1 (E, C) およびType-2 (E) 以外のNLRI（ルート）タイプは、本文書の範囲外です。

Key Length field (キー長フィールド): これはキー長を指定します。新しいNLRIタイプの不透明な処理を可能にし、新しいルートタイプがBGPスピーカー（ルートリフレクター（RR）など）を通過できるようにします。

TLV-based encoding of non-key part of NLRI (NLRIの非キー部分のTLVベースのエンコーディング): これにより、プレフィックスに追加の非キーフィールドを含めることができ、異なるタイプのトランスポートを同時にサポートし、効率的なBGP更新パッキングが可能になります（セクション2.9）。

AIGP attribute (AIGP属性): これはTLVを通じて拡張性を提供し、インテントに応じて必要に応じてカラーに追加のメトリックセマンティクスを定義できるようにします。

2.3. BGP CAR Route Origination (BGP CARルート生成)​

BGP CARルートは、ローカルで生成される（例：ループバック）か、または別のルーティングソリューション（例：SRポリシー、IGPフレキシブルアルゴリズム、RSVP-TE、BGP-LU [RFC8277]）によって提供される (E, C) カラー感知パスの再配布によって生成されます。

2.4. BGP CAR Route Validation (BGP CARルート検証)​

ネクストホップNおよびカプセル化Tを介したBGP CARパス (E, C) は、カラー感知パス (N, C) が存在し、カプセル化Tがデータプレーンで利用可能である場合に有効です。

ローカルポリシーは検証プロセスをカスタマイズできます:

  • 最初のチェックでのカラー制約を緩和できます。Nが代替カラーまたはデフォルトルーティングテーブルで到達可能な場合、ルートは有効と見なされる場合があります。

  • Tのデータプレーン可用性制約を緩和して、代替カプセル化を使用できます。

  • パフォーマンス測定検証を追加して、Cに関連付けられたインテントが満たされていることを確認できます（例：遅延 < しきい値）。

無効なパスは、BGPベストパス選択で考慮してはなりません（MUST NOT）。

2.5. BGP CAR Route Resolution (BGP CARルート解決)​

ネクストホップNを持つBGPカラー感知ルート (E2, C1) は、デフォルトでカラー感知ルート (N, C1) 上で自動的に解決されます。カラー感知ルート (N, C1) は、IGPフレキシブルアルゴリズム [RFC9350]、SRポリシー（[RFC9256] のセクション2.2）、またはBGP CARによって再帰的に提供されます。複数の (N, C1) プロバイダーが利用可能な場合、デフォルトの優先順位は次のとおりです: IGPフレキシブルアルゴリズム、SRポリシー、BGP CAR。

ローカルポリシーは追加の制御を提供すべきです（SHOULD）:

  • ネクストホップNを持つBGPカラー感知ルート (E2, C1) は、カラー感知ルート (N, C2) 上で解決できます（すなわち、ローカルポリシーはC1の解決を異なるカラーC2にマッピングします）。このような解決が発生する可能性がある例には、次のものが含まれます:

    • リソースRが存在しないことがわかっているドメインでは、ドメイン間インテントC1="低遅延およびRの回避"は、インテントC2="低遅延"のドメイン内パス上で解決できます。

    • ドメインで (N, C1) パスが利用できない場合、ユーザーが許可すれば、解決はC2パスにフォールバックできます。

  • ルート解決は出口ノードによって駆動できます。SRv6ドメインでは、出口ノードはインテントC1のためにそのロケーターからSRv6 SIDを選択し、BGP CARルートとともにアドバタイズします。この場合、入口ノードは、C1の出口ノードのインテント感知ロケーターのIPv6ルート、またはロケーターをカバーする集約ルート上で受信したSRv6 SIDを解決します。この集約ルートは、SRv6フレキシブルアルゴリズムまたはBGP CAR IPプレフィックスルート自体によって提供できます（例：付録C.2）。

  • ローカルポリシーは、CARルートをカラー非感知またはベストエフォートメカニズム（RSVP-TE、IGP/LDP、BGP-LU/BGP-IPなど）にマッピングできます（例：付録A.3.2）、ブラウンフィールドシナリオ用。

異なるカラーC2を介したルート解決は、CARルート (E2, C1) にBGP Color-EC C2を添付することで自動化でき、「セグメントルーティングポリシーアーキテクチャ」[RFC9256] のセクション8.4で説明されているBGP CARルートの自動ステアリングを活用します。このメカニズムは付録B.2で説明されています。このメカニズムはサポートされるべきです（SHOULD）。

CARルート解決の場合、ルートにColor-ECカラーが存在する場合、それはルートのインテントカラーよりも優先されます。ルートのインテントカラーは、存在する場合はLCM-ECカラーです（セクション2.9.5を参照）。そうでない場合はNLRIカラーです。

ローカルポリシーは、上記で指定されたカラーベースの自動解決よりも優先されます。

カラー感知ルート (N, C1) は、階層的トランスポートルーティング設計でBGP CAR自体によって提供できます。この場合、上記で説明したプロセスに基づいて、同じまたは異なるCARルートタイプで再帰的解決が発生する可能性があります。セクション7.1.2では、CAR (E, C) ルートがCAR IPプレフィックスルート上で解決されるシナリオについて説明します。

CAR IPプレフィックスルートは、ベストエフォート用にカラーなしを許可します。この場合、解決はBGPネクストホップN、または存在する場合はノードNがアドバタイズするベストエフォートSRv6 SIDに基づきます。

BGP CARルートは、TEAを運ぶBGPルート上で再帰的に解決でき、[RFC9012] のセクション6に従って検証します。この場合、[RFC9012] のセクション8の手順がBGP CARルートに適用され、解決には上記で指定されたカラー優先順位を使用します。

[RFC9012] のセクション6の手順は、BGP CARルート（AFI/SAFI = 1/83 または 2/83）にも適用されます。例えば、BGP CAR BRは、[RFC9012] のセクション6で説明されているように、TEAまたはトンネルカプセル化ECを使用して、カラーごとに特定のBGPネクストホップで入口BRまたはPEにBGP CARルートをアドバタイズできます。

1つのネットワークドメインでのBGP CAR解決は、別のドメインでの解決とは独立しています。

2.6. AIGP Metric Computation (AIGPメトリック計算)​

累積IGP（AIGP）メトリック属性 [RFC7311] は、BGP CARルートがネットワークを介して伝播されるにつれて更新されます。

AIGP TLVで設定（または適切に増分）される値は、カラーの基礎となるインテントに関連するメトリックに対応します。例えば、カラーが低遅延パスに関連付けられている場合、メトリック値は遅延メトリックに基づいて設定されます。

基礎となるドメイン内メカニズムで使用されるメトリックタイプに関する情報も、メトリック値の設定に使用できます。

BGP CARルートが特定のインテントのトランスポートパスで不連続性を横断する場合、AIGPメトリックにペナルティ（ユーザーポリシーによって設定された値）が追加されます。例えば、これはカラーC1パスが利用できず、ルートがカラーC2パスを介して解決される場合に発生する可能性があります（例については付録A.3を参照）。

AIGPメトリック計算は再帰的です。

継続的なIGPメトリック変更がエンドツーエンドBGP CARルートチャーンを引き起こすのを避けるため、実装はAIGP更新をトリガーするためのしきい値を提供すべきです。

特定のユースケースのためにシグナリングするための追加のAIGP拡張を定義できます。例えば、BGP CARルートに沿ってアドバタイズされる最大SID深度（MSD）やBGP CARルートに沿ってアドバタイズされる最小MTUなど。これは本文書の範囲外です。

2.7. Inherent Multipath Capability (固有のマルチパス機能)​

(E, C) ルート定義は、BGP-LUまたはBGP-IPと同様に、各BGPホップで冗長パスの可用性を本質的に提供します。例えば、ドメイン内の2つ以上の出口ABRによって生成されたBGP CARルートは、ドメイン内の入口ABRに複数のパスとしてアドバタイズされ、そこで等価コストまたはプライマリバックアップパスになります。出口ABRの障害は、トラフィック回復のために上流ノードにイベントを伝播する必要なく、より高速な収束のためにドメイン内の入口ABRによってローカルに検出および処理されます。

BGP ADD-PATH [RFC7911] は、トランスポートRR（T-RR）を介して複数のネクストホップをシグナリングするためにBGP CARで有効にすべきです（SHOULD）。

2.8. BGP CAR Signaling Through Different Color Domains (異なるカラードメイン間のBGP CARシグナリング)​

[Color Domain 1   A]-----[B     Color Domain 2     E2]
[C1=low delay      ]     [C2=low delay               ]

BGP CARルート (E2, C2) がBからAにシグナリングされると仮定します。それぞれドメイン2とドメイン1の2つのBRです。これら2つのドメインは同じカラーからインテントへのマッピングを共有していないと仮定します（すなわち、異なるカラードメインに属します）。ドメイン2の低遅延はカラーC2ですが、ドメイン1ではC1です（C1 <> C2）。

異なるカラードメイン間で基礎となるトランスポートパス（例：MPLS LSP）を拡張することは、典型的なシナリオではないと予想されます。ただし、BGP CARソリューションは、異なるカラードメインでの管理権限の分離と独立性を維持しながら、このまれなシナリオをシームレスにサポートします。

ソリューションは以下のように説明されます:

  • ドメイン2内では、BGP CARルートはE2を介した (E2, C2) です。

  • BはBGP CARルートをAにBを介した (E2, C2) としてシグナリングし、カラーC2のローカルカラーマッピング拡張コミュニティ（LCM-EC）を使用します。

  • Aはドメイン2内のインテントからカラーへのマッピング（ドメイン2の「低遅延」はC2）を知っており、ピアリングドメインのオペレーター間の典型的な調整が存在します。

  • AはLCM-EC内のC2をC1にマッピングし、受信したBGP CARルートをドメイン1内でAを介した (E2, C2) としてシグナリングし、LCM-EC(C1) を使用します。

  • ドメイン1内の受信ノードは、LCM-ECにエンコードされたローカルカラーをネクストホップ解決とサービスステアリングに使用します。

以下の手順は、送信ピアと受信ピアのルーティングポリシーによって実行される、BGP CARルートのカラードメイン境界に適用されます:

  • ローカルポリシーを使用して、異なるカラードメインのピアにアドバタイズされる、または受け入れられるルートを制御します。

  • ルートにLCM-ECが存在しない場合は、LCM-ECを添付します。LCM-ECが存在する場合は、カラーを再マッピングするために必要に応じて値を更新します。

    • この機能は、オペレーターピアリングプロトコルによって決定され、BGPピア上のローカルポリシーによって示されるように、アドバタイジングBGPスピーカーまたは受信BGPスピーカーのいずれかによって実行できます。

これらの手順は、前のセクションで指定されたすべての手順とともに、両方のCARルートタイプに適用されます。LCM-ECはセクション2.9.5で説明されています。

注: この文書はRFC 9871に基づいています。詳細なプロトコルエンコーディング形式と追加セクションを含む完全な公式仕様については、https://www.rfc-editor.org/rfc/rfc9871.html を参照してください。

に最終更新