Clarence Filsfils と SRv6 ネットワークプログラミングの運用境界

要約

• RFC 8402、8754、8986、9256は、Clarence Filsfils を、Segment Routing の命令モデル、IPv6 上のセグメント列、SRv6 のローカルな振る舞い、SR Policy の候補経路選択という連続した技術課題に結び付けている。
• これらはすべて複数著者による IETF の成果であり、単独発明、特定事業者での導入、性能結果、顧客成果、企業内部の判断を証明するものではない。確認できるのは、公開された共同執筆と仕様の技術的境界である。
• ネットワークのプログラム可能性は境界を消さない。識別子の範囲、能力の版管理、候補経路の出所と有効性、転送面の観測、ロールバック可能性を、実際の動作と記録によって照合する必要を強める。

技術者の経歴ではなく、公開された接点を読む

IETF Datatracker の Clarence Filsfils のページは、本人の名前と多数のルーティング文書の間に検証可能な接点を提供する。本稿では、その中から四つを扱う。RFC 8402は Segment Routing アーキテクチャ、RFC 8754は IPv6 Segment Routing Header、RFC 8986は SRv6 Network Programming の振る舞いモデル、RFC 9256は SR Policy の識別と候補経路選択を記述している。

この連続性は、Filsfils を SRv6 の運用境界を考えるうえで適切な人物にする。一方で、技術全体を一人の物語に還元する根拠にはならない。RFC 8402は Clarence Filsfils と Stefano Previdi を編集者として挙げ、Les Ginsberg、Bruno Decraene、Stephane Litkowski、Rob Shakir も著者として記録する。RFC 8754は Filsfils、Darren Dukes、Previdi、John Leddy、Satoru Matsushima、Daniel Voyer の共同著作である。RFC 8986は Filsfils、Pablo Camarillo、Leddy、Voyer、Matsushima、Zafar Ali を、RFC 9256は Filsfils、Praveen Talaulikar、Ketan Talaulikar を著者として挙げる。

共同著者の境界を正確に残すことは、単なる礼儀ではない。インターネット技術では、著者が意味論を定義し、ワーキンググループが限界を検討し、実装者がコードに落とし、装置ベンダーが能力を決め、運用者がポリシーを設定する。どの層も他の層を自動的に代表しない。

したがって、公開記録から導けるのは、技術文書への継続した貢献と、その文書が作る検証可能な境界である。個人的動機、雇用主の非公開判断、特定ネットワークの成果を推測する必要はない。人物は文書をたどる軸であり、ネットワークの現実は実装、設定、転送表、パケットに残る。

RFC 8402では命令より先にスコープがある

RFC 8402は、ソースまたはヘッドエンドがセグメントと呼ばれる順序付き命令の列によってパケットを導くアーキテクチャを示す。セグメントはノード、隣接、サービス、または定義済みの処理を表し得る。列は経路意図を表現するが、その意図を実行する能力や権限を自動的には作らない。

ここでいうソースは、世界中の転送を支配する主体ではない。ヘッドエンドは、自らが持つトポロジー情報、管理ポリシー、信頼領域の中で判断する。経路上の装置がセグメントの意味を理解し、必要な資源を持ち、処理が許可されていることが前提になる。

Segment Routing は複数のデータプレーンで実現できる。SR-MPLS ではラベルが使われ、SRv6 では IPv6 アドレスを基礎にした識別子が振る舞いと結び付く。共通の抽象があっても、スタック深度、カプセル化、MTU、ハードウェア処理、セキュリティ、観測方法の差は残る。「Segment Routing 対応」という一語だけでは、実際に使える機能を判断できない。

運用の最初の仕事は、採用範囲を広げることではなく、スコープを書くことである。どのシステムが列を作れるのか、識別子空間を誰が管理するのか、どのノードが必要な能力を持つのか、信頼境界を越えたパケットをどう扱うのかを明示する。

仕様は相互運用のための意味論を提供する。仕様が存在することは、他のネットワークに処理を強制する許可ではない。実行するかどうかの権限は、設定とポリシーを持つ運用主体に残る。

短いセグメント列が長い依存関係を圧縮する

画面上のセグメント列は短く見えても、各要素は多くの前提を圧縮している。識別子の意味が現在も有効であること、計算に使ったトポロジーが新しいこと、各ノードに必要な能力があること、セキュリティポリシーが処理を認めること、パケットサイズが経路に収まることが必要になる。

そのため、構文上は正しい列が運用上は誤っている場合がある。隣接が既に失われ、識別子が再割り当てされ、ソフトウェア上の機能がハードウェアの高速経路では使えず、列の深度が上限を超え、制御装置のトポロジーが現実より古いかもしれない。

インストール前の確認では依存関係を再構成する必要がある。どの要求がポリシーを生み、どのトポロジー版を使い、能力情報はどこから来て、誰が各セグメントの利用を承認し、装置は何をインストールしたのかを結び付ける。

インストール後も同じ関連付けが要る。宛先に到達した事実だけでは、想定した候補経路を通ったことも、各振る舞いが意図どおりだったことも分からない。カウンター、ログ、転送表、パケット観測が一つのポリシー識別子へ戻れる必要がある。

撤回も依存関係に沿って行う。候補経路を無効にする前に利用中のポリシーを把握し、識別子を解放する前に活動中の参照を探す。関係を失ったロールバックは、孤立状態を残したり、未評価の代替経路へトラフィックを移したりする。

セグメント識別子はローカルな運用台帳を必要とする

セグメント識別子のすべてが世界的なレジストリから割り当てられるわけではない。IGP ドメイン、事業者のラベル空間、ローカルに設定された SRv6 振る舞いの範囲で管理されるものも多い。ローカルであることは記録を不要にせず、誰が記録責任を持つかを明確にする。

有用な台帳は、識別子を振る舞い、スコープ、所有者、対応プラットフォーム、作成日、版、状態に結び付ける。変更と廃止も保存し、古いポリシーやキャッシュが残る間に同じ値を別の意味で再利用する事故を防ぐ。

一意性だけでは十分ではない。異なる値でも互換性のない振る舞いを指し得る。一意な値であっても、誰が承認したか不明なら安全ではない。運用上の正確さには、一意性、意味、出所、鮮度、責任者が含まれる。

この点は番号資源の運用と似ている。台帳の目的は記録そのものを主権者にすることではなく、複数の実行系が値の意味と変更履歴について一致できるようにすることである。最終的な判断は、コードと転送面が記録どおり動いたかにある。

定期的な照合では、台帳と装置を比較する。記録にあるのに装置にない振る舞い、装置にあるのに現在の記録がない振る舞いは、ともに差異である。差異には修復、記録更新、撤去、新規参照の停止という明確な処置が必要になる。

RFC 8754は意図を実行境界まで運ぶ

RFC 8754は IPv6 Segment Routing Header、すなわち SRH を定義する。SRH はセグメント列と処理状態をパケットに格納し、どのセグメントが現在有効かを示す。仕様は同時に、その利用を SR ドメインの範囲で扱う。

パケットは制御面と転送面の境界を具体化する。制御面が列を選び、パケットがそれを運び、受信ノードがローカルな実装、設定、ポリシーに基づいて処理する。形式が標準化されても、無関係なノードに任意の機能を実行させる権利は生まれない。

IPv6 アドレスが世界的に到達可能であることと、SRv6 の実行環境が開かれていることは別である。運用者は、どの送信元が、どのインターフェースから、どの振る舞いを、どの深度まで要求できるかを制御する必要がある。

SRH はパケットサイズにも影響する。長い列と追加情報はバイト数を増やす。影響は MTU、カプセル化、中間装置、ハードウェアの解析能力によって変わる。最小構成だけの試験では、実際の最大構成を証明できない。

観測系は処理の違いを示すべきである。受理、拒否、形式不正、権限不足を区別し、現在のセグメントと列を生成したポリシーを関連付ける。バイト列を見るだけでは、なぜそのパケットがリンクに現れたかを説明できない。

ドメイン境界は拒否試験によって証明する

技術デモは成功するパケットを見せることが多い。運用試験では、失敗すべきパケットを同じ重みで扱う。許可されていない送信元、過剰な深度、矛盾したフィールド、未知の振る舞い、許容されない遷移が予測可能な結果を生む必要がある。

拒否試験には二つの目的がある。設定したセキュリティ意図が実行されていることを確認し、失敗がどのように通知されるかを確認する。正しく破棄しても信号が残らない装置もあれば、例外処理を汎用 CPU へ送り容量リスクを作る装置もある。

安定状態だけでなく変化も試す。ポリシーが参照中の振る舞いを撤去した場合、制御装置が再接続して古い状態を再送した場合、ソフトウェア更新や装置交換で能力が変化した場合を含める。現実の障害は正しい二状態の間で起きやすい。

試験表には送信元、インターフェース、深度、振る舞い、版、期待結果を並べ、カウンター、ログ、パケットで確認する。証拠は特定の設定と版に結び付け、「SRH は安全である」という無期限の宣言にはしない。

結論の範囲を限定することは弱さではない。あるプラットフォームの特定版で特定ケースが通ったなら、証明されたのはその組み合わせである。範囲を残すことで、後の変更に対して結果を正しく再利用できる。

データサイズと装置能力は実際の意味論に含まれる

RFC は形式と振る舞いを定義するが、装置は有限資源でそれらを実行する。処理できる列の深度、インストール可能なポリシー数、利用できるカウンター、例外時の経路が、現実のアーキテクチャを決める。

能力情報には版が必要である。ソフトウェア更新は機能を増やす一方、上限変更や回帰も起こし得る。古い静的表を読む制御装置は、現在の装置に収まらない列を提案し続ける可能性がある。

状態は「設定を受け取った」「ポリシーが有効」「転送項目をインストールした」「振る舞いを観測した」に分ける。一つが失敗したとき、前段の成功を最終成功として表示してはならない。

能力の精度は投資判断にも関係する。必要な深度や振る舞いが現装置で使えないなら、更新、範囲限定、別技術を比較する。標準が存在することは、費用と代替案の比較を不要にしない。

測定された限界は継続性を守る。業務が存在しない能力に依存する前に拒否でき、少数の経路だけのために全体を更新することも避けられる。図面ではなく実行能力が境界を決める。

RFC 8986ではプログラムは定義済みの振る舞いを呼ぶ

RFC 8986は SRv6 Network Programming を、セグメントに結び付いた振る舞いとして記述する。パケットが任意のプログラムを運ぶのではない。識別子がローカルに設定された機能を指し、ノードがその実装と許可条件を保持する。

振る舞いには次のセグメントへ進むもの、特定の表を参照するもの、隣接を使うもの、デカプセル化するもの、サービスの文脈へ接続するものがある。各機能は異なる依存関係を持つ。表参照は表の内容に、隣接はリンクに、デカプセル化は外側と内側の境界ポリシーに依存する。

共通名称は制御装置とノードが同じ機能を話すための語彙を作るが、ノードの自律性を奪わない。どの振る舞いを有効にし、どこに置き、誰に利用させ、どう観測するかは運用者が決める。

カタログにある機能をすべて有効にする必要はない。目的、限界、試験、所有者、撤回方法が明確な小さな集合の方が、観測できない大きな集合より信頼できる場合がある。

Filsfils への帰属も文書の範囲に置く。彼は共同著者の一人として振る舞いモデルの定義に関与した。RFC は特定装置の性能、特定サービスの簡単さ、特定事業者での利用を証明しない。

振る舞いごとに証明すべき内容が変わる

似た形式のセグメントでも結果は異なる。単純な転送は次ホップの確認を必要とし、ローカル表を使う振る舞いは表と文脈の正しさを必要とする。デカプセル化は内外パケットの境界を、隣接型は変化するリンク状態を必要とする。

したがって「SRv6 が動く」という一つの試験では足りない。各振る舞いに前提条件、期待動作、事後条件を定義する。前提は能力、設定、権限、資源状態を含み、事後条件はカウンター、転送表、パケット、サービス結果を含む。

この粒度は診断を改善する。ポリシーが有効なのに振る舞いカウンターがゼロならステアリングを疑う。カウンターが増えてサービスが失敗するならローカル処理や後続経路を見る。ポリシーが無効なら候補の出所や制約へ戻る。

ロールバックも同じ単位で行う。問題の振る舞いを列から外し、候補を無効にし、特定サービスだけをポリシーから外すことができる。単一機能の障害で全ドメインを止めると影響を広げる。

変更要求、ポリシー、候補、列、振る舞い、観測結果を一つの安定した識別子でつなぐことも重要である。共通識別子がなければ、各チームが正しい断片を持っていても経路全体を再構成できない。

能力を版管理し、自動化が過去を設定しないようにする

自動化はデータで判断する。データが以前の装置版を表していれば、速度は誤りを早めるだけである。SRv6 能力台帳は、ノードをハードウェア、ソフトウェア、振る舞い、深度、資源、制約に結び付ける必要がある。

能力には取得時刻と出所も必要である。装置から直接読んだ値と手作業の表では信頼度が異なる。ラボ結果が本番装置をそのまま表すとも限らない。出所は、いつ再確認すべきかを判断する材料になる。

更新前後には比較可能な記録を取る。更新前にポリシー、振る舞い、カウンター、重要サービスを保存し、更新後に能力とインストールを再確認する。機能が消えたなら、それに依存する候補はトラフィックを受ける前に無効化する。

失敗は意思決定層へ伝わらなければならない。人向けの警報だけでは、制御装置が候補を有効と扱い続けるかもしれない。ただし、ローカル障害を理由に未評価の代替経路を自動採用することも避ける。

版管理は費用の説明にも役立つ。必要な機能を持たないノードだけを特定でき、利益が不足するなら利用範囲を制限できる。ネットワークを図面に合わせるのではなく、図面を現実の能力へ合わせる。

RFC 9256はポリシーに識別と出所を与える

RFC 9256は SR Policy のアーキテクチャを定義する。ポリシーはヘッドエンド、カラーまたは意図、エンドポイントによって識別され、複数の候補経路を持ち得る。候補には出所、優先度、有効性、一つ以上のセグメントリストがある。

識別は似た判断の混同を防ぐ。同じエンドポイントへの二つのポリシーが異なるサービスや制約を表す場合がある。カラーは意図を分け、ヘッドエンドは判断場所を示し、エンドポイントはルーティング目標を限定する。

候補の出所も重要である。ローカル計算、外部制御装置、手動設定は交換可能ではなく、信頼度、寿命、撤去手順が異なる。出所がない優先度の数値は、なぜその候補を有効にすべきか説明できない。

優先度は有効な候補の間でのみ働く。高い値でもトポロジーが古く、能力が不足し、制約を満たさない候補は選ぶべきではない。存在、能力、制約、鮮度を先に確認する。

ポリシー台帳は履歴を残す。どの候補が有効だったか、なぜ置き換わったか、どのトラフィックが利用したかを追えることで、障害調査と撤回確認が可能になる。

優先度より先に有効性を判定する

優先度は複雑な選択を順序へ縮約するが、有効性の代わりにはならない。候補はトポロジー変化、能力喪失、管理制約、リスト欠落、出所消失によって無効になり得る。

作成時の一回だけ確認しても不十分である。トポロジーは変わり、装置は更新され、情報源は切断される。各候補に無効条件と再評価方法が必要であり、更新が来ないことを有効性の証明として扱わない。

現在候補が無効になった場合の遷移も事前に定義する。別の有効候補を選ぶ、ポリシーを撤去する、通常ルーティングへ戻すなど、サービスごとに適切な方法は異なる。障害中に初めて決めるべきではない。

中間状態を見えるようにする。候補はあるが有効候補がない、候補を選んだがリストをインストールできない、リストはあるがトラフィックが関連付いていない、といった状態を一つの「稼働中」にまとめない。

無効性の検出、伝搬、照合にかかる時間を測ると、どの層が古い状態を保持したか分かる。抽象的な収束時間より、サービスが遷移中にも説明可能な経路を持ったかという事実が重要である。

ステアリングがリスクを負うトラフィックを決める

ポリシーをインストールしただけでは、パケットに影響しない場合がある。ステアリングは宛先、サービス、カラーなどの条件に基づいてトラフィックをポリシーへ結び付ける。これは独立した意思決定であり、独立した所有者を必要とする。

インストールとステアリングの分離は段階導入に役立つ。最初にポリシーを置いて観測し、テストトラフィックを流し、限定サービスへ広げ、通常ルーティングへの出口を維持できる。

一方で、分離は新たな差異を生む。ポリシーが変わってもステアリングが残り、規則が想定以上のトラフィックを覆い、候補撤去後に未試験の代替結果へ流れる可能性がある。レビューは両方のオブジェクトを比較する必要がある。

指標は、各ポリシーのトラフィック量、現在候補、サービス結果を示すべきである。文脈のないポリシーカウンターでは影響が分からず、ポリシー識別のないサービス指標では原因を説明できない。

撤回にはステアリングも含める。リストだけ削除して関連規則を残すと暗黙の動作を呼び出す。終了時にポリシー、候補、インストール、関連付け、サービスを再確認する。

トポロジーからパケットまで証拠を連結する

四つの RFC は一つの約束の連鎖として読める。Segment Routing アーキテクチャが命令を定義し、SRH が列を IPv6 で運び、SRv6 振る舞いがローカル機能を実行し、SR Policy が候補を選び、ステアリングがトラフィックを渡す。

一つの層は次の層を自動的に証明しない。形式が正しい列は SRH 受理を証明せず、受理された SRH は振る舞いの存在を証明せず、振る舞いの存在はポリシー有効性を証明せず、有効なポリシーはトラフィック利用やサービス成功を証明しない。

証拠を層ごとに進める。トポロジーと能力が候補を支え、ポリシー状態が選択を示し、転送表がインストールを示し、カウンターが処理を示し、パケットが実際のフィールドを示し、サービス測定が結果を示す。

障害調査は逆向きに進める。サービスが失敗したとき、どのトラフィックが関連付けられ、どの候補、列、振る舞い、リンクを使ったかを確認する。抽象的な「制御装置」や「ネットワーク」を責めるのではなく、契約が崩れた境界を探す。

変更要求、ポリシー、候補、設定、観測には共通識別子が必要である。識別がなければ、証拠が正しくても別の時刻やサービスのものかもしれない。

各層が持つ実権に応じて責任を分ける

プログラマブルなネットワークでは、アーキテクチャ、基盤、自動化、運用、セキュリティに判断が分散する。統制が機能するのは、それぞれが実際に行使する力へ責任を持つときである。アーキテクチャはドメインと承認済みカタログを、基盤は能力を、自動化は計算とインストールを、運用は観測と復旧を、セキュリティは出所と境界を担当する。

分担に空白を残してはならない。制御装置が候補を出すならデータ出所の所有者が必要であり、装置が振る舞いを置くなら能力台帳の所有者が必要であり、ステアリングを有効にするならサービス所有者が影響を受け入れる必要がある。

権限も分担に従う。候補計算ができるシステムに、ローカル振る舞いや境界フィルターの変更権限まで与える必要はない。ステアリング担当者に全体カタログの管理権限を与える必要もない。

調整は会議だけでなく共通オブジェクトで行う。変更識別子とポリシー識別子がシステム間の判断を結び、能力、出所、有効性、ロールバックの存在を自動的に確認できる。

説明責任は全権限の集中を意味しない。複数の所有者がいても、境界と記録が接続され、「別の層が確認したはず」という仮定の中に重要判断が隠れなければよい。

段階導入は選択肢を残す

導入は独立した合格条件を持つ段階へ分けられる。まずノード能力を確認し、基本到達性を試験し、限定された振る舞いを導入する。ポリシーはステアリングなしでインストールでき、後から小規模トラフィックを関連付けられる。

各段階に進む証拠と戻る動作を定義する。十分なカウンターがないインストールは本番トラフィックを受けず、拒否経路を試していない振る舞いは送信元を広げない。大量の手作業が必要な撤回は、まだ信頼できる出口ではない。

段階化は混在状態が見える場合に有効である。移行中には SRv6 を使うノードやサービスと通常経路を使うものが共存する。全体を一つの「移行済み」表示にすると、診断に必要な差が消える。

拡大は日程ではなく証拠に従う。ある段階で差異が見つかれば、その範囲で修復する。未解明のまま広げれば、局所的な不確実性がシステム債務になる。

通常ルーティング、別候補、以前のポリシーなど代替も維持する。ただし代替も試験する必要がある。一度も実行していない出口は、設計図上の仮説にすぎない。

仕様に準拠して見えるシステムでも失敗する

すべての設定を受理しても運用上失敗する場合がある。制御装置が古い能力を使い、識別子が以前の意味を残し、列がハードウェア上限を超え、振る舞いが低速処理へ移り、未モデル化の境界で SRH が拒否されることがある。

有効性にも固有の問題がある。候補の情報源が失われても状態が撤去されず、優先度が制約を満たさない候補を残し、リストをインストールできないのにポリシーが有効表示される可能性がある。

ステアリングでは、規則が想定以上のトラフィックを選び、ポリシー撤去後も残ることがある。サービスが未評価の代替へ移り、集約カウンターが少量の重大影響を総量の中へ隠す場合もある。

観測画面も単純化によって誤る。プロセスが応答することと転送項目が存在することは別であり、「ポリシー稼働中」と表示しても候補選択、リスト導入、トラフィック関連付けを区別していないかもしれない。

形式準拠、能力、インストール、処理、サービス結果は別の判断である。すべてを一つの健全性指標へまとめると、どの境界が壊れたか分からなくなる。

有効化と同じ粒度で撤回する

可逆性は導入後の追加機能ではなく、設計条件である。数秒でポリシーを有効にできても、撤去に長い手作業が必要なら、自動化はライフサイクルの半分しか扱っていない。

粒度を合わせれば影響を限定できる。候補が問題なら別候補を選び、振る舞いが問題ならリストから避け、サービスが問題ならそのステアリングだけを外す。一機能の障害でドメイン全体を停止すると無関係なサービスまで失う。

撤去は参照を追う。識別子や振る舞いを削除する前に利用ポリシーを確認し、ポリシーを削除する前にステアリングを確認する。変更後に転送表、カウンター、サービス結果を再比較する。

撤去したものも記録する。履歴は値をすぐ再利用できない理由を示し、障害の再構成を助ける。設定が消えただけでは終了せず、実状態の照合と依存関係の閉鎖が必要である。

これは運用継続性の具体的な表現である。障害ゼロを約束せず、差異を見つけ、影響を限定し、説明可能な経路へ戻る能力を維持する。

公開資料が証明できる範囲

参照した資料は、Clarence Filsfils が RFC 8402、8754、8986、9256に著者または編集者として記録されていることを示す。共同著者、公開時期、文書の技術内容も確認できる。したがって、彼の公開上の技術軌跡を Segment Routing、SRH、SRv6 振る舞い、SR Policy へ結び付けることができる。

資料は単独発明を証明しない。RFC 8402は六人、RFC 8754は六人、RFC 8986は六人、RFC 9256は三人を署名者として記録する。ワーキンググループ、査読者、実装者、運用者も技術結果に関わる。

どのネットワークが各機能を使うか、雇用主が何を決めたか、どの顧客が成果を得たか、どの装置がどの性能を示したかも、これらの資料だけでは分からない。その空白を推測で埋める必要はない。

正確な境界は人物と読者の双方を守る。私的な動機や未測定の成果を帰属させず、検証できる共同貢献を認識できる。

その結果、記事は評判づくりではなく工学分析になる。人物名は文書の連続性を追う軸であり、システムの現実は実装と運用に残る。

この軌跡がプログラマブルネットワークに重要な理由

プログラマブルネットワークの議論は速度や柔軟性から始まりがちである。Filsfils に結び付く文書群は、行為を説明し撤回するにはどのオブジェクトが必要か、という別の出発点を与える。セグメント、SRH、振る舞い、候補、ポリシー、ステアリングが順に現れる。

各オブジェクトは能力と義務を同時に増やす。セグメントは命令を表すがスコープが要る。SRH は列を運ぶが境界が要る。振る舞いは機能を実行するが能力が要る。候補は経路を提案するが出所と有効性が要る。ステアリングはトラフィックを渡すが所有者と出口が要る。

自動化は高速にオブジェクトを動かせるが、その意味を支える証拠を置き換えられない。識別、版、観測が欠ければ、速度は未照合状態を増やす。

仕様の価値は検証可能な層を分けることにある。運用者は制御と診断を設計し、欠けた証拠を具体的に指摘できる。抽象的な「ネットワーク障害」にすべてを押し込めずに済む。

成熟の尺度は、発行できる命令数ではない。命令がそれを囲む境界より小さく保たれ、図面より実際の振る舞いが優先されることである。

結論：プログラムするとは説明し、取り消せること

四つの RFC を連続して読むと、限定された約束のアーキテクチャが見える。命令には識別とスコープがあり、ヘッダーには処理規則とドメインがあり、振る舞いにはローカルな意味と能力があり、ポリシーには候補、出所、優先度、有効性があり、トラフィックはステアリングで参加する。

信頼は約束と証拠を接続して生まれる。能力台帳が装置条件を確認し、記録が識別と変更を保存し、転送表がインストールを示し、カウンターが処理を示し、サービス測定が結果を示す。

同じ連鎖が撤回を支える。参照を見つけ、候補を無効にし、トラフィックを外し、既知の範囲で振る舞いを停止できる。ロールバックは失敗への譲歩ではなく、安全に変更する前提である。

公開記録は、Clarence Filsfils をこの連鎖を整理する複数著者の仕様へ結び付ける。単独発明や導入保証へ拡張することはできない。各主張に固有のスコープを保つこと自体が、ここで扱った設計原則に沿う。

信頼できるネットワークプログラミングは、命令を何個発行できるかではなく、何個を説明し、観測し、撤回できるかで測られる。それがこの文書群に共通する運用境界である。

参考資料

IETF Datatracker の Clarence Filsfils プロフィール

RFC 8402：Segment Routing Architecture

RFC 8754：IPv6 Segment Routing Header

RFC 8986：SRv6 Network Programming

RFC 9256：Segment Routing Policy Architecture