要約

  • RFC 9831 の Type I、J、K では、SID 欄を含めながら値をゼロにし、具体的な SID を指定せずに望ましい endpoint behavior や SID structure を伝えられる。
  • S フラグが証明するのは欄の存在までである。ヘッドエンドはノードや隣接の記述をローカルな SR 情報で解決し、値の不在や不一致を理由付きで判定する。
  • 運用記録はフラグ、受信値、解決に使った文脈、得られた SID、検証、候補選択、転送面、パケット観測を別々に保存しなければならない。

:: は空欄ではなく、役割の指定である

ゼロという値は、しばしば欠落と同一視される。RFC 9831 の SRv6 用セグメントでは、その扱いが危険になる。Type I、J、K の SID 欄は 16 octet であり、S フラグがその存在を示す。コントローラはこの欄をすべてゼロにして、SID 自体を指定せず、望む behavior や structure を示すことができる。

ここには三つの状態がある。SID 欄がない状態、SID 欄があり値がゼロの状態、非ゼロ SID が入る状態である。最初の状態では behavior/structure も含められない。二番目では具体値を受信側へ委ねつつ、追加の意味を伝えられる。三番目では送信側が候補値を示し、受信側が文脈との整合を確認できる。

三状態を一つの「値なし」に畳めば、委任の意思が消える。反対に「SID 欄あり」を「SID 受領済み」と表示すれば、存在しない実行値を作ってしまう。記録すべきなのは S と B、128 bit の原値、セグメント種別、ノードまたは隣接を表す周辺情報である。

この区別は細かい符号化上の趣味ではない。どちらの装置が最終値を決めたか、どの時点のネットワーク情報に依存したか、失敗を誰が戻すべきかを決める。

経路は明示的でも、SID は参照から得られる

Segment List sub-TLV は endpoint までの一つの explicit path を表し、各 Segment sub-TLV はその要素になる。ただし「明示的」を「そのまま転送面へ書ける値の列」と読むべきではない。

Type C と D は SR-MPLS のノードを IPv4/IPv6 address で表せる。E から H は node address、link address、interface identifier の組み合わせで隣接を表す。I から K は SRv6 の node や adjacency を同様に記述する。RFC 9256 では、ヘッドエンドがその記述を MPLS label または SRv6 SID に解決する。

つまり明示されているのは、通るべき意味上の要素と順序である。実行表現は、どのノードが prefix を生成したか、どの interface が link を指すか、どの local/remote pair が adjacency か、現在どの SID が対応するかという受信側の知識に依存し得る。

この間接性には価値がある。コントローラが各ドメインの割当を毎回固定せず、ローカル変更をヘッドエンドで吸収できるからだ。同時に、同じ広告が二台で同じ結果になる保証は失われる。片方の SR 情報が新しく、もう片方が古ければ、同じ Type I が一方では解決し、他方では拒否される。

受信した広告だけを保存しても、この差は説明できない。解決に使った情報源、version、時刻、結果を一緒に残す必要がある。

A、S、B、V は同じ合否判定ではない

A フラグは、適用対象のセグメントで SR Algorithm 欄に意味があることを示す。A が立たないとき、送信側はその欄をゼロにし、受信側は無視する。このゼロは「アルゴリズムをローカルで選べ」という積極的委任ではなく、アルゴリズムの主張がないことを示す。

S は SID 欄の存在を示す。ゼロか非ゼロか、見つかるか、ノード記述と一致するかは答えない。

B は Type B、I、J、K で endpoint behavior と SID structure の block があることを示す。この block は SID 欄なしでは置けないが、SID 欄がゼロでも置ける。したがって B は、まだ受信側が特定すべき値に対する期待を表し得る。

V は SRPM に SID verification を行わせる指示である。V が一であることと検証成功を同じ状態にしてはならない。前者は要求、後者は受信側が返す結果だ。

四つを一つの「valid」ランプへ集約すると、送信意図、欄の有無、追加制約、検証結果の境界が消える。フラグは短いから単純なのではなく、短い中で権限を分けている。

解決失敗にも身元がある

RFC 9256 の SR-DB は、計算や検証に用いる情報を概念的にまとめたものだ。実装がその名の新しいデータベースを作る義務はない。重要なのは、ヘッドエンドが node、link、interface と SID の関係を判断できるローカルな根拠を持つことである。

検証失敗は少なくとも三種類に分かれる。提示された SID が SR 情報に見つからない。Type C–K の文脈から解決した SID と提示値が一致しない。あるいは非先頭セグメントを label/SID へ解決できない。どれも候補を無効にし得るが、意味は違う。

一番目は受信側の情報欠落や到達可能性に関わる。二番目は送受信の文脈が分岐した証拠である。三番目は ordered path の途中に未解決要素が残る。単一の “invalid” counter だけでは、コントローラ、トポロジ情報、ローカル resolver のどこへ戻すべきか決められない。

複数ドメインでは知識の限界が明文化される。ヘッドエンドが遠隔ドメインの SID reachability を検証できない場合、その SID には直接値を表す Type A または B を使う必要があり、先頭 SID は常に到達可能でなければならない。規格はローカル知識を全知とせず、検証できない場所で表現方法を変える。

正しい長さは、意味の一部しか確定しない

各 Type には、optional SID や behavior/structure の有無に応じた長さが定められる。長さとフラグの整合は、境界を誤って読み、次の bytes を別の欄として扱うことを防ぐ。これは不可欠だが、実行可能性の証明ではない。

parser は構造を確認できる。type は node、adjacency、label、SRv6 SID のどれを記述するかを決める。SRPM はローカル文脈で値を解決し、segment list 全体を評価する。RFC 9256 により SR-MPLS と SRv6 を一つの list に混ぜれば無効になるため、各要素が単独で読めても全体は成立しない。

RFC 9830 は explicit path の意味検証を BGP の外側に置く。RFC 9831 は、この追加 Type が既存の operations や fault management を変えないと述べる。前の RFC 9830 記事は BGP table と転送権限を分けた。本稿が扱うのはさらに手前だ。候補選択の前から、受信済みの欄は完成した命令ではなく、ローカル解決の入力になり得る。

IANA の割当は、現物の SID を生まない

IANA は Type C–H と I–K の sub-TLV code point、A と S の flag bit を記録している。この共通表により、異なる実装が同じ番号を別の形で読む衝突を避けられる。

しかし code point は、特定ルータが全 Type を実装したこと、SR 情報が新しいこと、interface identifier が今も同じ link を指すこと、解決値が転送面へ入ったことを証明しない。Experimental RFC の公開も、実装と評価の対象があることを示すだけで、普及率や成功率ではない。

“support” は parser が Type J を知るだけかもしれない。“resolved” は local context から SID が得られた状態、“verified” は提示値と文脈が一致した状態、“active” は候補が選ばれた状態、“installed” は forwarding plane が受け入れた状態、“observed” は試験 packet が期待効果を示した状態である。この語彙を分けることが、誤った成功報告を防ぐ。

元のゼロを消さない運用記録

コントローラ側では、policy、segment order、type、node/adjacency context、A/S/B/V、length、raw value、設定 version と送信時刻を残す。「非ゼロ SID を提示」「ゼロで解決を委任」「欄を省略」を明記する。

ヘッドエンド側では、解決に使った SR 情報源と version、得られた label/SID、曖昧性、検証理由を加える。その後に candidate validity、active selection、forwarding installation、packet observation、service result が続く。後段が成功しても、前段の誰が値を決めたかは上書きしない。

この分離によって、ゼロ委任後の mapping 不足を「コントローラが不正 SID を送った」と誤認せず、非ゼロ値の mismatch を単なる route down へ薄めず、正しく解決した後の installation failure を resolver の責任にしないで済む。

情報源