要約

  • RFC 8362のExtended LSAはUビットを立てるため、機能コードを知らないルーターでも、符号化されたスコープに従ってLSAを保存し、フラッディングできる。LSDBにあるという事実は、意味の理解、機能の有効化、SPFでの利用、RIB/FIBへの反映を証明しない。
  • 未知だが正しい形式の情報と、不正な符号化は区別される。前者は不透明なまま運ばれ得るが、長さの矛盾などを含むExtended LSAは、インストールも確認応答もフラッディングもしてはならず、計数・記録されるべきである。

読めないものを正しく渡す

一つのOSPFv3エリアに3台のルーターがあるとする。最初のルーターが新しい拡張情報を含むExtended Router-LSAを生成し、最後のルーターはその拡張に対応している。しかし間のルーターは古く、機能コードを知らない。それでも広告は最後まで届く。

鍵はLS Typeにある。RFC 5340では、LS Typeに機能コードだけでなくUビットとフラッディング・スコープのビットを持たせている。未知の機能に対してU=0ならリンクローカル相当として扱う。U=1なら、タイプに記されたスコープに従って保存し、フラッディングする。RFC 8362は主要LSAのExtended版に、元の機能コードへ10進数32、つまり0x20を加えたコードを割り当て、Uビットを必須とした。

中継ルーターは単なる空洞ではない。受信した構造が受け入れ可能かを確認し、LSDBでインスタンスを管理し、信頼性のあるフラッディングに参加する。ただし、その権限は保管までである。LSDB上の行から「このルーターは拡張を実装している」「有効化している」「計算に使った」と結論することはできない。

運用上は、少なくとも四つの段階を分ける必要がある。第一に、バイトが到着し、正しい形式のLSAがLSDBへ入ったこと。第二に、ソフトウェアがLSAやTLVの文法を認識したこと。第三に、機能が設定され、その情報を判断に使ったこと。第四に、判断がRIB、FIB、パケットへ届いたことだ。RFC 8362は第一だけが成立する状態を、互換性のために残している。

意味より長く生きる入れ物

従来のOSPFv3 LSAには固定された本文形式がある。将来の情報を固定形式へ足し続けるのは難しい。RFC 8362のExtended LSAは、可変情報をTLV、必要ならsub-TLVに収める。新しい入れ物を機能コードで識別し、Uビットによって、その意味をまだ知らないノードも通過できるようにした。

ただし、これは部分導入の成功を自動的に保証する仕組みではない。RFC 8362は、新しいTLVやsub-TLVを定義する各仕様に対し、一部のルーターだけが対応する場合の動作を明示するよう求める。対応端点だけで成立する機能もあれば、連続した対応トポロジーや完全な属性集合を必要とする機能もある。フラッディングの成功と機能成立は別の判定である。

既知のExtended LSAに未知のTLVやsub-TLVが入っている場合、それらは解析・処理時に無視される。「無視」は「消去」でも「対応」でもない。外側のLSAを保存して運びながら、内部要素には意味を与えないという選択である。RFC 9492が扱うアプリケーション固有リンク属性でも、アプリケーション向け属性の広告と、そのアプリケーションをリンクで有効にすることは区別されている。

未知と破損の境界

前方互換性が必要とするのは、新しくても正しい意味を受け入れる余地であり、壊れた構造を流すことではない。RFC 8362は、長さ情報の不整合など符号化エラーのあるExtended LSAについて、LSDBへインストールせず、確認応答せず、フラッディングしないよう定める。実装はそのエラーを数え、ログに残すことが望ましい。

したがって、監視画面には三つの状態が要る。

  1. 既知で有効: 定義された構造を解析し、仕様と設定が許す範囲だけで使用する。
  2. 未知だが有効: 不透明な情報として保管し、Uビットとスコープの規則に従って運ぶが、意味の理解は主張しない。
  3. 不正: LSDBとフラッディングから排除し、拒否した証拠を残す。

後ろ二つを一つの「未対応」にまとめると、逆方向の事故を招く。未知をすべて捨てれば、新旧機器の間の互換経路を壊す。不正な構造まで未知として運べば、障害範囲を広げる。必要なのは、「知らないが形式は正しい」と「形式そのものが誤っている」を分けられるパーサーとテレメトリーである。

同じLSAを追跡するための手掛かり

RFC 5340では、LS Type、Link State ID、Advertising Routerの組でLSAを識別する。シーケンス番号、チェックサム、LS ageはインスタンスの新旧を判断する材料になる。チェックサムはLS ageを対象に含めず、ageは保存・伝搬の途中で変化する。従って、各ホップで完全に同じバイト列が保存されると表現するのは正確ではない。

運搬の受領記録には、タイプとスコープ、広告元、Link State ID、シーケンス番号、チェックサム、観測したエリアまたはインターフェース、時刻を残す。その上で、認識能力を示すソフトウェア情報、機能設定、SPFやアプリケーションの出力、RIB/FIB、パケット観測を別々に結ぶ。LS ageは経路の説明には使えるが、不変の本文として扱わない。

管理データも無条件に完全ではない。ポーリング間隔は一時的な拒否を見落とし、収集装置はスコープ・ビットを正規化し、データベースは機能停止後も古いLSAを保持する可能性がある。収集時刻、取得元ルーター、モデルのパスを一緒に保つ必要がある。

「見えた」では終われない二つの移行

RFC 8362は、完全移行の方法として、従来LSAとExtended LSAを別々のOSPFv3インスタンスで動かす手順を示す。最初はExtended側の管理距離を高くして優先度を下げ、両者のRIBを比較する。差分を説明してから優先度を切り替え、もう一度確認し、最後に従来側を外す。Extended LSAが届いたことではなく、ルート結果の比較がゲートになる。

スパース・モードでは、通常のSPFは従来LSAで続け、新機能に必要な情報だけをExtended LSAで運ぶ。二つの完全なインスタンスを避けられる反面、どのノードが対応必須か、必要なTLVが揃っているか、部分対応時にどう動くかを把握しなければならない。数個のExtended LSAが見えただけでは足りない。

RFC 9587のOSPF YANGモデルは、この境界を運用面に持ち込む。Extended LSA対応の既定値はfalseで、未知のTLVとsub-TLVをタイプ、長さ、16進値として表示できる。不透明な情報を観測可能にしつつ、理解済みとは扱わない設計である。管理モデルの存在も、SPFや転送効果の証明にはならない。

Acee Lindemに帰属できること

RFC 8362は2018年4月、Acee Lindem、Abhay Roy、Dirk Goethals、Veerendranatha Reddy Vallem、Fred Bakerの共同名義で公開され、RFC 5340とRFC 5838を更新した。現在のIETF Link State RoutingワーキンググループのページはLindemを共同議長の一人として掲載している。これは時点を伴う役割であり、標準や実装を所有する権限ではない。

資料から言えるのは、Lindemが、理解能力の異なる実装の間で拡張可能なOSPFv3状態を運べるようにする共同作業へ参加し、後にRFC 9587の運用モデルにも共同で関わった、ということまでである。Extended LSAを一人で発明した、後続TLVをすべて設計した、あるいは各社の実装を支配したとは言えない。

この限定された帰属は、プロトコルの権限分担とよく似ている。発信者は広告内容を決め、プロトコルは有効な入れ物の運び方を決め、実装は認識能力を決め、設定は使用の可否を決める。ルーティングと転送が結果を作り、運用者が証拠を残す。一つのLSDB行が全てを代表することはない。

運搬証明から意味の証明へ

説明可能な記録は七つの要素をつなぐ。LSAの識別とスコープ、各バージョンの認識能力、機能の有効状態、SPFやアプリケーションの判断、RIB/FIBへの反映、同じ変更に結び付いたトラフィック影響、そして不正な入力を拒否したカウンターとログである。

最初の要素は最後の要素の弱い代用品ではなく、別の事実だ。理解できない情報に対し、正しく次へ渡すことが最善の役割になる場合がある。RFC 8362が示す運用上の節度とは、その保管・運搬を正当に評価しながら、証拠の届かない意味まで付け足さないことにある。

出典