要約

  • IESGが承認した拡張により、BGP SR Policyの候補パスは、想定するNetwork Resource Partitionに対応する制御プレーンのNRP IDを運べる。
  • その番号はドメイン内の関連を表すだけで、資源の割り当て、データプレーンの対応付け、容量、分離、サービス結果を保証しない。

同じ宛先でも、資源の意図は二つ

同じカラーとエンドポイントを持つ二つの候補パスをheadendが学習したとする。一方のNRP IDは17、もう一方は29だ。制御プレーン上では、それぞれを別のアンダーレイ資源区画へ結び付けるための違いになる。

しかし更新には、利用可能帯域、キューの状態、インターフェース設定、分離の測定値は入っていない。headendが候補を選んだか、セグメントリストをインストールしたか、番号を正しいデータプレーンセレクターに変換したかも分からない。

これは報告済み障害ではなく、権限の境界を示す例である。フィールドは「どの区画を使うべきか」を伝えられるが、資源を生み出したり、パケットの結果を確定したりはしない。

2026年8月25日18時03分（UTC）、IETFは「BGP SR Policy Extensions for Network Resource Partition」第13版をProposed Standardとして進めるIESG承認を発表した。承認は重要な状態変化だが、最終RFCの発行や運用網への導入とは別の事実である。

標準化の状態にも未完了の段階がある

文書はInter-Domain Routingワーキンググループの成果である。発表はTEASおよびSPRING文書への依存を巡る議論と、前進させるためのおおむねの合意を記している。規範参照の依存関係はRFC Editorのキューで解決する判断だった。

8月28日の証拠固定時点で、Datatrackerは第13版をActive Internet-Draftと表示していた。RFC Editorは参照未着のためblocked、IANAは版変更につき再レビューが必要で、処理は進行中だった。したがって最終RFC番号やレジストリ完了を先取りしてはならない。

発表は二つの実装を報告する。公開IDR資料にはHuawei VRPとH3C Comwareの対象が挙がる一方、旧版に基づく記述やTBDの機能欄が残る。実装作業と実現可能性の証拠にはなるが、第13版の全面準拠、大規模相互接続、広範な有効化の証明ではない。

NRPは番号ではなく、資源と方針の組である

RFC 9543はNetwork Resource Partitionを、アンダーレイ資源の部分集合と、それを一つ以上のネットワークスライスサービスに使う関連方針として定義する。RFC 9732は、拡張VPNの枠組みで接続構造をNRPへ対応付ける考え方を示す。

実体を作るのは運用である。容量と転送処理を用意し、方針で使い方を決め、サービスのトラフィックを誘導し、測定によって結果を確認する。NRP IDだけでは、このどれも完了しない。

第13版のNRP IDはドメイン内で一意な32ビットの制御プレーン識別子だ。ドメイン固有の設定と実装が、その値をデータプレーンのNRP Selector IDへ結び付ける。世界共通の資源宣言ではない。

対象も限定されている。文書が扱うのは、専用でドメイン全体に通用するセレクターをデータプレーンで用いる設計だ。他のNRP選択方式はSR Policyで明示的なID通知を必要としない場合があり、本拡張の範囲外になる。

六オクテットが保証するのは構造である

拡張は、トンネル種別がSR PolicyのBGP Tunnel Encapsulation Attribute内にNRP ID sub-TLVを定義する。第13版のタイプは123、長さは必ず六オクテットで、フラグ一つ、予約領域一つ、NRP ID四つから成る。

フラグと予約ビットは送信時にゼロとし、受信時には無視する。NRP ID 0は予約値であり、送信側は使用せず、受信側はゼロを含むsub-TLVを無視する。sub-TLVは任意だが、一つの候補パスに二つ以上置けない。

長さが六でない場合や重複した場合、SR Policy NLRIに伴うNRP情報は不正形式となり、RFC 7606のトリート・アズ・ウィズドロー処理を適用する。複数の構造的主張が同じ候補パスで競合することを防ぐ規則である。

ただし、形式が正しい非ゼロ値を誤ったローカルセレクターへ対応付けた場合は見抜けない。ワイヤ上の一貫性と、資源上の正しさは別の検証対象だ。

BGPの受理後に、実行の境界が続く

専用セレクター方式のドメインで候補パスをNRP内に生成する場合、発信元はNRP ID sub-TLVを含める。受信BGP speakerはRFC 9830の妥当性・利用可能性規則を適用し、通常のBGPベストルート選択を行う。アルゴリズムそのものは変わらない。

SR Policy SAFIで選ばれたベストルートは、その後SR Policy Moduleへ渡される。受理されたルートがアクティブ候補になるとは限らず、SRPMが受け取ってもインストールに失敗し得る。インストール後も、ローカル対応付けがずれていれば誤ったセレクターを使う。

証明に必要なのは、候補選択、セグメントリスト、NRP IDとセレクターの対応版、パケットへの付与、サービス誘導、キューやリンクの設定、そして実測された遅延・損失・スループット・分離までをつなぐ記録だ。広告成功は、既知のセッション条件で関連が送受信されたことしか示さない。

フェイルオーバーで意味を変えない

第13版は、一つのSR Policy内で候補パスごとに異なるNRPを関連付ける構成を有効とする。ただし推奨はせず、通常は全候補で同じNRP関連を保つべきだとしている。

優先度変更や障害時には、サービスから見えるポリシーキーを保ったまま別候補がアクティブになる。そこで資源区画まで変われば、容量、分離、コスト、機微な意図の露出も同時に変化しかねない。

全headendで同じ整数を設定するだけでも足りない。値の解釈、データプレーンセレクター、実際に用意されたアンダーレイ資源が一致する必要がある。同じ番号と異なるローカル対応付けは、構文だけが揃った状態である。

増える状態は主に制御側とheadendが負う

草案は、NRP数の増加に伴ってSR Policyと候補パスも増え、コントローラーとheadend間の情報量が比例して増え得ると説明する。

SR Policyの広告手順やBGPベストパスは変わらない。該当するheadendだけが候補パスをインストールするため、同じ追加状態を中継ノードへ負わせるわけではない。これは明確なスコープ境界だが、無コストという意味ではない。

コントローラーには生成と整合、headendには受信、検証、引き渡し、インストールが残る。広告数、受理数、ベストルート数、SRPM候補数、アクティブ数、インストール数を分けなければ、制御側の正常表示がheadendの限界を隠す。

信頼された相手でも意味を誤る

セキュリティ節はBGP、SR Policy、NRPの保護を継承しつつ、誤った関連がトラフィック分離と資源保証を損なう危険を明記する。

認証済みコントローラーが誤ったIDを送ることはある。信頼されたheadendが正しいIDを誤ったセレクターへ対応付けることもある。正しいセレクターの先に古い資源設定が残る場合もある。構成要素の身元確認は、組み合わせた結果の正当性を証明しない。

NRP関連そのものが、重要任務や商業上重要なネットワーク構造を漏らす可能性もある。送受信者を信頼済みルーターと制御アプリケーションに限定し、関連の正しさを別途確認する責任は運用者にある。

一つの事象について、コントローラーとpeerの身元、NLRIキー、候補の起点と優先度、sub-TLV生バイト、検証とベストルート判断、SRPMの受領・選択、インストール済みセグメントリスト、対応付けと版、資源設定、サービス誘導、観測されたパケットセレクター、キュー・損失・遅延・分離、撤回とロールバック、各段階の時刻を保存すべきである。

情報源