要約

  • RFC 9502 のプレフィックス広告は、ある IP Flex-Algorithm の下で計算できる到達性を表す。実際にどのパケットがどこを通ったかまでは表さない。
  • 変更の証拠は、FAD、IPv4/IPv6 別の参加、計算結果、FIB、実測を混ぜずに保存して初めて再検証できる。

「Flex-Algorithm 128 を有効化した」という変更票は、運用上は便利な短縮形である。しかし、その短縮形が担当範囲を越えて使われ始めると危険になる。設計者にとってはアルゴリズムの定義を配ったこと、オペレーターにとっては特定ノードに経路が載ったこと、サービス責任者にとっては顧客通信が保護されたことを意味し得る。三つは同じ文で語れても、同じ事実ではない。

RFC 9502 は、この差を偶然に残したのではない。IGP Flexible Algorithm が IPv4/IPv6 の IP Prefix Reachability を扱う方法を定め、アルゴリズムの制約に従う経路計算を可能にする。一方で、全ノードが参加する、必ず経路が選ばれる、端末まで届く、という約束はしない。仕様にない保証を「有効化」という語に足すのは、技術の単純化ではなく、責任境界の消失である。

出発点は FAD、Flexible Algorithm Definition だ。RFC 9350 によれば、同じアルゴリズム番号を用いるノードは定義に合意する必要がある。定義が無効、不一致、または未対応なら、ノードはそのアルゴリズムへの参加を止める。ここで「同じ番号、別の作用」という事態が起きる。番号が見えていることは、そのノードがその定義を受理したことの証拠ではない。ましてネットワーク全体の受理を証明しない。

次に、参加は IP データプレーン単位で読む必要がある。IPv4 と IPv6 は一つのラベルの下で自動的に同じ運用へ収束しない。IPv4 用の条件は満たしていても IPv6 用の条件、能力、広告、局所方針が満たされないことはあり得る。従って「アルゴリズム 128 は導入済み」という一行は、二つのデータプレーンに関する異なる状態を隠せる。変更審査で必要なのは番号ではなく、ノードとアドレス族を持つ参加表である。

参加した先にも、計算がある。プレフィックスの情報は、制約を伴うアルゴリズム固有の経路計算に入る。トポロジー、メトリック、リンク属性、除外条件、局所の方針が結果を作る。広告されたプレフィックスは到達可能とは限らない。到達可能でも最良とは限らない。最良候補でも FIB に残るとは限らない。RFC 9502 が非参加ノードを計算から pruned すると述べるのは、未参加を単なる監視の空欄として扱わないためだ。経路の数学から取り除かれた状態である。

この点は障害解析で特に重要になる。同一プレフィックスと異なるアルゴリズムに関する矛盾した情報がある場合、RFC 9502 はそれを無視し、対応する経路を導入してはならないとしている。FIB にないことは、テレメトリー不足のために緑へ補正すべき欠損ではない。保護的な不導入という、説明されるべき結果であり得る。運用室がこの結果を「未計測」とだけ分類すると、仕様が防いだ事故を、成功の説明にすり替えてしまう。

FIB は強い証拠だが、範囲のある証拠でもある。RFC 9502 は参加するノードがアルゴリズムに従う経路を FIB に導入するとしつつ、同じ IP データプレーンでは同一プレフィックスに複数アルゴリズムの経路を同時に使えないとする。これは“二つのアルゴリズムを表示したので、二重に保護されている”という読み方を退ける。あるルーター、ある表、ある時点には、実際の転送選択がある。そこを示さずに冗長性を主張することはできない。

安全な変更では、証拠を五つの帳簿に分ける。第一は FAD の帳簿で、識別子、制約、版、合意の状態を記す。第二は参加帳簿で、各ノードについて IPv4 と IPv6 を独立に記す。第三は計算帳簿で、宛先、時刻、候補、除外理由を記す。第四は FIB 帳簿で、実装された next hop と表を記す。第五は通信観測帳簿で、プローブ、フロー、カウンター、測定窓を記す。サービス可用性を述べるなら、さらに利用者側の SLO が必要になる。前の帳簿だけから次の帳簿の結論を出さないことが要点である。

この分離は、Heng Lu が最小初期仕様について述べたこととも響き合う。将来の判断を局所化する仕組みは、将来の判断そのものを代行しない。FAD は何を満たせば計算できるかを局所化する。個々の実装が受理するか、各データプレーンが参加するか、各ノードが導入するかを代行しない。設計が局所性を残したのなら、ガバナンスがそれを一つの中央的成功に圧縮してはならない。

running code に関する論考も同じ警戒を促す。稼働しているコードがあることは、別の主体が合意した結果を保証しない。FIB のエントリは局所の転送決定を強く示すが、顧客のアプリケーション体験、域外の連続性、契約上の成果を観測してはいない。証拠の射程を主張の射程に合わせることは、曖昧な統治を避ける最小条件である。

IANA の IGP Parameters は Flex-Algorithm 用の 128–255 を含む識別子空間を公開している。これは相互運用のための座標であって、実装の状態データベースではない。登録簿にある番号は、定義の合意も、IPv6 の参加も、利用者の到達性も確認してくれない。公開の名前と、局所の状態を同じ台帳に載せない理由がここにある。

規範語を読む際にも同じ節度がいる。RFC 8174 は MUST や SHOULD の読み方を定める。MUST NOT install は安全な非導入を支持するが、観測していない成功を想像する根拠にはならない。役員向けの報告は、技術用語を減らすことで明快になるのではない。何が定義、何が参加、何が計算、何が FIB、何が観測かを省かないことで明快になる。

変更凍結やロールバックの場面では、この区別がさらに実務的になる。FAD の変更を戻せても、すでに各ノードがどう参加し FIB をどう更新したかが分からなければ、復旧の完了を判断できない。そこで復旧基準を「元の番号に戻った」ではなく、「対象ノード・対象アドレス族で期待した計算と FIB が再現され、探針で確認された」と書く。番号は導入のきっかけであって、完了条件ではない。