要約

  • 255オクテットを超える一つのIS-ISオブジェクトは、同じ型と同じキーを持つ複数のTLVで表せる。ただし各部は単独で解析可能でなければならず、受信側は順序やLSPフラグメントの位置に左右されず全情報を統合する。
  • Type 30の能力サブTLVは情報提供専用で、コードポイント別の内訳を持たない。通知の有無を理由に送受信処理を変えてはならない。
  • 有効化には、全受信実装について対象コードポイントを検証した外部台帳、段階的な試験、明示された停止条件とロールバックが必要になる。

境界ルーター一台だけが、二つ目のTLVを読まなかったとする。隣接関係は維持され、監視画面も緑のままかもしれない。しかし、その装置だけは他のルーターと異なる属性集合で経路を計算する。問題が見えるのは、プロトコル入力ではなく転送結果の段階になってからだ。

RFC 9885 が扱うのは、この静かな不一致である。IS-IS の Type-Length-Value では Type と Length がそれぞれ1オクテットなので、一つの Value は最大255オクテットに制限される。ネットワーク規模とトラフィックエンジニアリング属性が増え、一つの論理オブジェクトが収まらなくなった。そこで、従来仕様が別方式を定めていない場合、同じTLVを複数回出現させる方法を標準の拡張手段として明文化した。

これは任意位置でのバイト分割ではない。同じ型と、該当する場合は同じオブジェクトキーを持つ出現だけが、一つのMP-TLVを構成する。キーの意味は元のTLV仕様が決める。各部は他の部分なしでも解析できなければならず、一個のサブTLVやデータ単位を境界で切ることはできない。切れば無効な符号化になる。

並び順を捨てても、対象の同一性は捨てない

対応する受信機は、すべての部分に含まれる情報を受け入れる。どの部分が先に届くか、一つのLSP内にあるか複数のフラグメントに分かれるか、IIHのどこに置かれるかは意味を変えない。繰り返されたキーは同じ対象を指し、内容は論理的に連結して処理される。

ただし、矛盾まで消えるわけではない。到達性TLVのメトリックのように、固定部にあってもキーではない値が部分間で異なればエラーである。一度だけ現れるべきサブTLVに競合値があっても同じだ。元仕様に処理規則がなければ、番号が最も小さいLSPで最初に現れた値を採用する。IIHでは最初の出現を使う。

受信側の許容範囲と送信側の節度も分けられている。100バイトの二つの部分が一つに収まったはずだという理由だけで、受信側は拒否できない。一方、送信側は対象コードポイントでMP-TLVが適用可能で、情報が実際に255オクテットを超えるまで複数化すべきではない。現在のLSPに空きがないだけなら、完全なTLVを別のLSPへ移す方がよい。

この非対称性は相互運用の余白である。受信側は妥当だが冗長な表現に耐え、送信側は互換性リスクを必要以上に増やさない。「受信成功」だけでは、送信判断が適切だったかは記録されない。

Type 30 が示すのは調査の入口

従来仕様が複数出現を明示していなかったコードポイントでは、部分導入が特に危険になる。未対応ルーターは一つの出現だけを選び、残りを無視し得る。欠落したリンク属性が制約付き経路計算に使われるなら、計算結果が分岐し、ループやパケット廃棄につながり得るとRFCは警告する。これは実事故の報告ではなく、展開時に閉じるべき条件である。

診断を助けるため、Router CAPABILITY TLVにType 30、Length 0のサブTLVが登録された。暗黙的にMP-TLVが適用されるコードポイントへの対応を知らせ、スコープはIS-ISレベルごとになる。

しかし規範文は、その信号に権限を与えなかった。通知は情報提供だけを目的とし、実装はそれに基づいて送信内容や受信処理を変えてはならない。交渉でも同意でもなく、自動的な安全装置でもない。

さらにType 30には、対応コードポイントを列挙する構文がない。仕様は関連コードポイント全般への対応を想定しつつ、現実の実装が導入要件に応じて一部だけを実装し得ることを認める。単一ビットのように見える表示の背後に、機種、版、役割、コードポイントから成る未記入の表が残る。

IANAのMP欄が答えるのも別の問いだ。Yは、そのコードポイントにMP手続きが適用できるという標準上の属性である。搭載ソフトの対応、設定、送信実績、エリア内の受信一貫性を示すテレメトリではない。

実行許可は運用者の記録に置く

RFCは、MP-TLVを生成する実装にコードポイント単位の有効・無効制御を推奨する。無効化を実装する場合、無効中にMP-TLVを受信した時と、ローカルLSP生成にMP-TLVが必要になった時の両方を記録しなければならない。このログは必要性と曝露を示すが、設定変更を承認しない。

運用者は、対象となる全受信実装が各部を正しく解釈できると確認するまで有効化すべきではない。必要なのはレベル、受信役割、プラットフォーム、導入済みイメージ、コードポイント、テスト入力、解析結果、経路計算、FIB、ロールバックを結ぶ台帳だ。IS-IS認証が正しくても、認証済み情報を古い受信機が完全に理解するとは限らない。出所の完全性と意味の実装能力は別の証拠である。

稼働コードの優先とは、ここでは非常に具体的だ。標準表は適用可能性を、Type 30は概括的な自己申告を示す。実際に経路を計算し転送表へ入れる正確なバイナリの挙動だけが、導入判断に必要な現実を示す。

出典