RFC 9573：共通ラベルは共通の意味の証明ではない

要約

従来の上流割当ラベルは、数値だけでは解釈できない。受信 PE は、どの入口 PE がそのラベルを付けたかというコンテキストで意味を決める。入口ごとの名前空間が、同じ数字の衝突を隔離していた。

RFC 9573 の例では、1,001 台の PE がそれぞれ 1,000 個の VPN または BD を持つと、各出口は 1,000 の空間にまたがる 100 万の意味を扱う。共通ラベルなら、同じサービスに同じ数値を与え、必要な状態をサービス数の合計へ近づけられる。

ただし隔離の根拠も変わる。入口 ID による明示的な分離を捨て、全参加ノードに配布された設定の一致へ依存する。削減されたのは意味の数ではなく、意味を保持する場所である。

RFC は、方式を使うなら全 PE と全セグメンテーション点が対応しなければならないと定める。一方、その状態をどう保証するかは範囲外と明記する。VPN、BD、ES の割当と、そのメンバーへの周知も外部の方法で行われる。

ここを BGP の成功で埋めてはいけない。DCB フラグは「この経路は共通ブロックのラベルを宣言する」という証拠であり、全装置が同じブロックを予約した証拠ではない。まして同じ構成世代を FIB に書いた証拠でもない。

運用契約では、ドメインのメンバー、機能対応、予約範囲、割当台帳、配布世代、実装結果を列挙する必要がある。設計上の円で囲まれた「domain」だけでは対象を監査できない。

十分な大きさの DCB を全 PE に確保できない場合、小さな DCB ラベルで共有コンテキスト空間を選べる。内側のサービスラベルはその表で解釈される。受信 PE は、選択ラベルを既定 MPLS 表に、サービスラベルを選ばれた表に実装する。

二段階化は資源制約を緩和するが、二つの対応関係を生む。外側の表選択が正しくても、内側の 2088 が古い VPN を指していれば誤配送になる。Context-Specific Label Space ID EC は表の座標を示すだけで、その表が正しい内容になった経緯を伝えない。

したがって検証対象は制御プレーンの受信だけでは足りない。既定表、コンテキスト表、ハードウェア世代、対象サービスの canary、隣接サービスでの不在まで連結する。

リージョン A で同じ選択トンネルを通る二つのフローが、リージョン B では別々のトンネルへ分かれることがある。境界ノードは、上流では同居していたフローを識別して T2 と T3 に振り分けなければならない。

RFC 9573 は、共有コンテキスト空間の中で PE ごとに重ならないブロックを与え、各 PE が動的な segmented PMSI 用ラベルを割り当てる方式を示す。中央が全ラベルを決めなくてもよい代わりに、ブロック所有権と再利用の整合が新たな境界となる。

VRF でフロー検索を行う代替案もある。これはラベル数の問題を (C-S,C-G) ルート数へ移す。状態を消すのではなく、ラベル転送表と VRF のどちらに置くかを選んでいる。

DCB フラグとコンテキスト空間 ID EC は同時に付けられない。両方を持つ経路は withdrawn として扱う。どちらもなければ、従来どおり送信元 PE の上流割当空間で解釈する。

同じトンネルを共有する x-PMSI/IMET 経路群も、解釈方式を統一しなければならない。方式が混在すれば、トンネル直下のラベルをどの表で読むか確定できず、受信 PE は経路を撤回扱いにする。

この規則は推測を拒否する。しかし撤回メッセージは、古い FIB が消えた証明でも、飛行中のパケットが尽きた証明でもない。再利用の前にデータプレーンの静止を確認する必要がある。

DCB bit、Extended Community の subtype、Label Space ID Type の registry は相互運用の文法を固定する。実装、設定、普及、正しいサービス対応を示すものではない。

RFC は既存方式に比べて新たな security concern を導入しないとも述べる。したがって、ここで扱う整合性の条件を、根拠のない侵害事例へ拡大してはならない。言えるのは、共通ラベルの意味が外部の運用状態に依存するということだ。