要約

  • RFC 8379 は、OSPF のリンク保守にある方向性の盲点を扱う。一方のルーターがメトリックを最大化しても、対向側が別に生成する逆方向の経路情報までは変わらない。
  • ゼロ長の Graceful-Link-Shutdown マーカーは保守意図を共有し、対向リンクを識別して各主体が局所的に応答するきっかけを与える。ただし、完了を証明するのは両端の状態、双方向のトラフィック、そして復旧後の一致である。

分析

物理回線は一本でも、広告は二方向に分かれる

保守担当者の目には、対象は一本の回線として映る。回線番号も作業票も一つであり、停止する装置も明確だ。ところが OSPF では、A が B へ向かうリンクコストを A が広告し、B から A へのコストは B が広告する。片側の設定変更は、もう片側の発言を書き換えない。

2018 年 5 月に Standards Track として公開された RFC 8379 は、このずれを出発点とする。著者は Shraddha Hegde、Pushpasis Sarkar、Hannes Gredler、Mohan Nanduri、Liliya Jalil である。目的はリンクを即座に消すことではない。双方向のトラフィックを代替経路へ移しつつ、ほかに道がなければ最後の手段として利用可能な状態を残すことにある。

IETF Datatracker の Hannes Gredler の記録は、彼がこの標準化に参加したことを裏づける。一方で、個人による単独発明や、特定ベンダーの実装、実ネットワークでの成功まで証明するものではない。RFC は共著者、ワーキンググループ、実装者、運用者を経て意味を持つ集合的な成果である。

片方向だけのドレインは、見た目だけ整った危険な状態を作る。発側のルーティング表示では迂回が完了していても、戻りのパケットは作業対象の回線へ流れ続けるかもしれない。制御プレーンに矛盾がなくても、保守目的は半分しか達成されていない。

ゼロ長のマーカーがメトリック変更の理由を示す

RFC 8379 は Graceful-Link-Shutdown sub-TLV を定義する。OSPFv2 では area scope の Extended Link Opaque LSA に Type 7、Length 0 として載り、OSPFv3 では E-Router-LSA に Type 8、Length 0 として載る。外部の経路計算主体に属性を伝える BGP-LS では、Type 1121、Length 0 の TLV が使われる。

値が空であることには意味がある。マーカーは作業票、時刻、期間、承認、トラフィック量を運ばない。特定されたリンクについて、広告元が優雅な停止を意図していることだけを伝える。メトリック上昇は障害や別のポリシーでも起こり得るため、明示マーカーによって対向側やコントローラーは保守という文脈を区別できる。

開始側はマーカーを広告し、関係する LSA を再生成する。通常のリンクメトリックは MaxLinkMetric の 0xffff にし、該当する場合は TE メトリックも 0xffffffff にすることが望まれる。これはリンクを削除する値ではなく、選ばれにくくする値だ。代替経路がなければ使われ得る点が、到達性を直ちに断つ操作との違いになる。

共通シグナルは遠隔命令ではない。開始側は自分の広告を変更し、対向側は自分の逆方向状態を変更する。TE のヘッドエンドやコントローラーは各自の制約に従う。標準がそろえるのは意図の表現であって、判断権の集中ではない。

対向側が同じリンクを見つけられるか

ポイントツーポイントでは、対応する対向ルーターは受信したマーカーから自分側の同一リンクを特定し、メトリックを MaxLinkMetric にして Router-LSA を再生成する。マルチトポロジー構成なら、そのリンクを含む各トポロジーの逆方向メトリックも対象になる。両方向の状態は、二つの局所的な操作が正しく対応して初めてそろう。

二台の間に並行リンクがあると、相手のルーター名だけでは足りない。番号付きリンクでは Remote IPv4 Address sub-TLV、番号なしリンクでは Local/Remote Interface IDs が、どのインターフェース同士なのかを識別する。対応を誤れば、別の健全なリンクを高コストにし、作業対象にはトラフィックを残すという逆効果が起きる。

ブロードキャストや NBMA では、単純に一つの遠端メトリックを上げると他の隣接関係に影響し得るため、二部分のメトリック手順が必要になる。ポイントツーマルチポイントやハイブリッドでは、関係する各リモートノードが該当隣接を見つけ、自ら状態を再広告する。共通の保守意図があっても、トポロジー形状の違いは消えない。

したがって運用画面に必要なのは「隣接をドレイン中」という一行ではない。開始インターフェース、Remote IPv4 Address または Interface IDs、対象トポロジー、両端の実広告を保持しなければ、作業票の回線と制御プレーンのエッジが一致したか判断できない。

後方互換性は接続を守っても、目的を保証しない

未対応の古いルーターは未知の sub-TLV を無視できる。新機能を理解しないというだけで隣接を壊す必要はない。この性質は、同期アップグレードを強制しないために重要である。

しかし、隣接が生きていることと双方向ドレインは別だ。対向側が通常の逆方向メトリックを維持すれば、開始側だけが経路を避け、相手側はそのままパケットを送り続ける。互換性が障害を避けた一方で、保守リスクも残る。

よって「RFC 8379 対応」という製品情報だけでは足りない。対象リンクにマーカーが出たか、意図した隣接が同一エッジを識別したか、逆方向コストが変わったか、全トポロジーが整合したか、BGP-LS の利用時に外部主体が何を受け取ったか、そして双方向のカウンターが基準以下になったかを確認すべきだ。構文上の互換性と、運用上の完了は異なる。

RFC 6987 は違いを理解する対照になる。こちらは MaxLinkMetric を使い、ルーター全体を経由するトランジットを避けながら、そのルーター自体への到達性を残す。RFC 8379 は一つのリンクという、より狭い属性を扱う。数値が同じでも、対象と保守意図は同じではない。

復旧もまた分散した状態遷移である

開始側がマーカーを取り下げるか LSA を purge すると、対応する対向側は元のメトリックを復元し、必要な LSA を再生成する。開始側、対向側、各トポロジー、TE 消費者、実トラフィックが、期待された通常状態へ戻る必要がある。

復旧にはドレイン時と同じ証拠が要る。最大メトリックが残れば、作業後もトラフィックが遠回りする。マーカーが残れば、コントローラーが保守ポリシーを継続するかもしれない。片側だけを戻せば、最初とは逆向きの非対称性が生じる。作業票のクローズは、状態復元の証明にはならない。

RFC は実装普及率、収束時間、パケットロス、個別ネットワークの成功結果を示していない。示すのは期待される相互運用動作である。仕様から実績を推測せず、仕様が列挙する観測点を現場で確かめる必要がある。

最小限の合意と、局所判断と、実動作の証拠

Lu Heng の Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption は、Sofia Ren がこの仕組みを読むための後年の視点を与える。共通層はリンク識別と保守意図の表現に絞られる。両端は自らのメトリックを制御し、コントローラーは制約を選び、運用者は作業時刻、代替容量、残余リスクを判断する。

これは 2026 年の編集上の解釈であり、RFC 著者の思想を代弁するものではない。規範的な根拠は RFC と IETF の合意形成にある。

Running-Code Primacy の観点では、機械可読なマーカーは口頭連絡より強いが、転送実績よりは弱い。信頼できる順序は、宣言、リンク照合、各端の応答、経路収束、双方向の流量確認、そして完全な復元である。

Hannes Gredler が残した公開記録から見えるのは、中央の命令装置ではない。小さな共通シグナルを置き、各主体の責任境界を残し、最後はネットワーク自身に結果を語らせる設計である。

出典