要約

  • RFC 9514 は、SRv6 のノード能力、リンク、Locator、SID、動作、構造を BGP-LS の利用者へ運ぶ共通形式を定める。
  • SRv6 Locator TLV 1162 を持つ Prefix NLRI は、Prefix Metric TLV 1155 も存在するときだけ通常のプレフィックス到達性を表す。検証済み Errata 7737 は、原文の 1095 を訂正した。
  • 宣言、到達性の分類、SID の対応、計算、インストール、実パケットの結果を別々の証跡として扱う必要がある。

運用画面には整ったオブジェクトがある。BGP-LS の Prefix NLRI は構文上正しく、SRv6 Locator TLV 1162 と Algorithm、Metric を含んでいる。ノードも識別できる。ここで表示を緑に変えるのは簡単だ。

しかし RFC 9514 では、その Locator はノード上の SID 群を覆うプレフィックスである。Prefix NLRI が通常のルーティング到達性も表すのは、別の Prefix Metric TLV を伴う場合だけだ。それがなければ Locator の広告にとどまる。

誤った 1095 と、正しい 1155

公開 RFC は IGP Metric TLV 1095 と記したが、検証済みエラッタ 7737 は Prefix Metric TLV 1155 に訂正した。1095 は Link NLRI に対応し、Locator が載るのは Prefix NLRI だからである。

Locator TLV の内部にも Metric はある。これは IS-IS または OSPFv3 の Locator 情報から複写された、Locator 宣言側の値だ。通常到達性を成立させる 1155 の代用品ではない。同じ「Metric」という語が二つの値を同じ権限にしない。

旧番号を実装した消費者と訂正版を実装した消費者は、同じ有効な UPDATE から異なるグラフを作り得る。エラッタ適用版、受信した TLV、関連付けた NLRI を記録しなければ、後から「なぜルートだと判断したか」を再現できない。

大きな Node オブジェクトに SID を詰め込まない

RFC 9514 は情報をノード、リンク、プレフィックス、個別 SID に分ける。ノードには能力、Algorithm、MSD。リンクには End.X、LAN End.X とリンク制約。プレフィックスには Locator。そして type 6 の SRv6 SID NLRI が各 SID を独立して運ぶ。

この設計は更新範囲を小さくする。全 SID を Node 属性に入れると、一つの SID の変更でも大きな Node 更新が必要になる。個別 NLRI なら一つずつ変更・撤回できる。一方、利用者は SID と Local Node Descriptors、Protocol-ID、Identifier、Locator、Endpoint Behavior を同じ世代で結合しなければならない。Locator が残っていることは、撤回済み SID が残っている証拠ではない。

SID NLRI には Endpoint Behavior TLV が必須である。BGP EPE の PeerNode／PeerSet には peer context が加わり、任意の SID Structure TLV は locator block、locator node、function、argument の長さを示す。RFC 8986 は endpoint behavior を、RFC 8402 は Segment Routing の構造を定義する。コード値の受信は、機器上での実行結果ではない。

起点も一つではない。OSPFv3 の SRv6 拡張または IS-IS の SRv6 拡張から関連フィールドを複写する場合もあれば、BGP EPE や Direct としてローカルノードが自分の情報を出す場合もある。RFC 8814 は BGP-LS で MSD 制約を運ぶ。コントローラが一か所に保存しても、出所ごとの主張範囲は消えない。

意味の検査は消費者の責任

RFC 9514 は、TLV の内容や NLRI との関連が妥当かという意味検査を BGP ではなく消費者に残す。BGP は形式を扱えるが、Locator を到達可能と判断すべきか、SID が現在も instantiated か、Algorithm が現行ポリシーで許可されるか、計算パスが実ネットワークに適合するかまでは保証しない。

Manageability の記述は、誤った encode/decode によって SR PCE が情報を失うか、誤情報を受け取り、意図した最適化ができない、または予期しない不整合な動作になる可能性を示す。アプリケーション側の処理は実装依存であり範囲外だ。

RFC 9552 の現行 BGP-LS モデルでは、producer、propagator、consumer の責任を分けられる。producer は導出した投影、propagator は選択して送った情報、consumer は組み立てた snapshot と利用方法を証明する。有効な BGP 更新だけでは、FIB もパケットも証明しない。

「受信済み」から「配送済み」まで

記録には source protocol、producer、Protocol-ID、Identifier、Local Node Descriptors、正確な Prefix NLRI と topology epoch を含める。Locator TLV 1162、Algorithm、Locator 内 Metric と、Prefix Metric TLV 1155 の有無・重複・拒否を別欄にする。適用したエラッタ版も必要だ。

SID を使う場合は SID NLRI、Information TLV 518、Endpoint Behavior TLV 1250、EPE context、Structure、withdrawal を加える。PCE の入力 snapshot、制約、policy、候補、選択結果、時刻を固定する。その後に southbound 応答、SR Policy／RIB／FIB 読み戻し、packet canary を並べる。

一次資料は修正経緯も追える。RFC Editor の情報ページ、テキスト、XML、Datatracker の履歴、最終ドラフト、参照一覧、そして IANA BGP-LS レジストリは、標準語彙と訂正を示す。特定ネットワークの導入や成果は示さない。

編集上の視点には Heng Lu の動くコードを優先する議論、最小初期仕様と自発的採用、現実の層を分ける議論を用いた。いずれも IETF の要件ではない。ここでの役割は、標準記号、制御モデル、導入状態、観測結果を同一視しないことにある。