要約
- RFC 5305の最大予約可能帯域と未予約帯域は、オーバーサブスクリプションのため物理リンク帯域を上回り得る。未予約帯域はセットアップ優先度0〜7ごとに別の値を持つ。
- 広告の送信元と経過時間、属性の解釈、TEデータベース、経路計算、受付、予約、転送状態、パケット、サービス成果を一つの「利用可能」表示に畳み込んではならない。
数字が八つある理由
RFC 5305のサブTLV 11は、未予約帯域を一つの値として扱わない。32ビット浮動小数点数を八つ並べ、セットアップ優先度0から7までの予約可能量を示す。プリエンプションを扱う以上、要求が使える余地はその要求の優先度で変わる。
サブTLV 9は広告方向の最大リンク帯域を、サブTLV 10は最大予約可能帯域を示す。単位はビットではなくバイト毎秒である。さらにRFCは、オーバーサブスクリプションを目的として最大予約可能帯域がリンク帯域を上回ってよいと明記する。未予約帯域にも同じ許容がある。
したがって、大きい値は物理的な余白の測定結果とは限らない。統計的な同時利用の見込み、プリエンプション方針、事業上のリスク許容を織り込んだ管理値かもしれない。「最大」という語だけを取り出して保証値に変えることはできない。
更新の時間も同様に重要だ。RFCは安定性のため、未予約帯域の急速な変動でLSPを次々に生成すべきではないとする。これは正しい制御面保護だが、遠隔ノードのコピーがローカル状態より遅れる可能性を意図的に残す。正しく認証された最新受信LSPであっても、別の予約が直後に競合していないことまでは証明しない。
色はセンサー値ではない
管理グループは管理者が割り当てる32ビットのマスクである。色と呼ばれる各ビットは、障害ドメインや設備区分、回避方針などの分類に使える。しかし、リンクが自ら色を測定するわけではない。意味を定める組織と設定の判断が先にある。
TEデフォルトメトリックも管理値であり、通常のSPFとは異なる重みの地形をTE計算に見せられる。そのサブTLVがなければ通常のデフォルトメトリックへフォールバックする。同じ隣接集合でも、属性の有無によって最小コストの意味が変わる。
24ビットリンクメトリックの最大値は、さらに明瞭な境界を作る。そのリンクは通常SPFで考慮してはならないが、TEなど別の目的で広告し続けられる。データベースに存在することと、特定計算で候補になることは同じではない。
障害時に「IS-ISにはリンクが見えていた」とだけ報告しても、選択理由は再現できない。どのLSPシーケンス、どの色、どのメトリック、どのフォールバック、どの計算エンジンだったかが必要である。
参照用アドレスから転送経路を作らない
TEを実装するルータはインターフェースIPv4アドレスを広告し、ポイントツーポイント隣接では近隣IPv4アドレスも含める。一方でRFC 5305は、それらのサブTLVだけを根拠に/32プレフィックスをルーティング表や転送表へ注入してはならないとする。拡張を理解しない装置との相互作用でループを生み得るからだ。
TE Router IDも、起点ルータを安定して参照し、OSPFとIS-ISのトポロジーを対応付けるためのアドレスである。しかし、それだけで/32転送エントリを作ってはならない。
ここには優れた設計上の節度がある。名前は制御面の座標になれるが、到達性の証明ではない。隣接を記述できても経路が導入されたとは限らない。導入された経路も、パケット配送の実績ではない。
未知のサブTLVは無視して読み飛ばすという拡張規則も、同じ証拠分離を要求する。外側のTLVを受理した装置が、内側の全属性を理解したとは限らない。受信、解析、保存、計算での利用を別々に確認すべきである。
LSPフラッディングは二重販売を排除しない
リンクステート方式は情報を配布する。資源を全体でロックするものではない。二つのヘッドエンドが同じ未予約値を見て、ほぼ同時に「自分の要求は入る」と判断する場面を考える。それぞれの入力は正当でも、両方の要求を同時に満たせるとは限らない。
RFC 5305が定めるのは入力の表現である。競合を順序付け、予約をコミットし、失敗側へ返答するのは後段の受付・予約機構だ。コミット後の残量が再びLSPに反映されるまでにも時間がかかる。
認証はこの取引を代行しない。受信側方針に基づきLSPの由来と完全性を確かめても、管理値が物理状態に一致すること、現在の要求に十分新しいこと、予約が成立したことは別である。RFC 5303の三方向ハンドシェイクもポイントツーポイント隣接の証拠を強めるが、その後流れる全TE属性の正しさまでは保証しない。
分析の範囲
RFC 5305は2008年のStandards Track文書で、先行するRFC 3784の設計を標準化した。移行手順は扱わない。後続文書はGMPLS、AS間TE、性能指標、アプリケーション固有属性を拡張したが、それらもRFC 5305の広告を予約証明へ変換しない。
本稿は特定ネットワークが過剰予約をしている、値が古い、属性を誤読した、サービスに失敗したとは主張しない。その証明には設定、時刻とシーケンスを持つLSP、TEデータベース、受付ログ、予約状態、転送表、パケット観測、サービス測定が要る。
残る結論は限定的である。広告は洗練された提案になり得る。しかし、提案を採択した記録ではない。
出典
- RFC 5305:IS-IS Traffic Engineering拡張
- RFC 5305プレーンテキスト
- RFC EditorのRFC 5305情報
- IETF DatatrackerのRFC 5305
- RFC 5305の履歴
- RFC 5305の参照文書
- RFC 5305を引用する文書
- RFC 5305の正誤表
- RFC 1195:IP向けIS-IS
- RFC 3630:OSPF Traffic Engineering拡張
- RFC 4203:GMPLS対応OSPF拡張
- RFC 5303:IS-ISポイントツーポイント三方向ハンドシェイク
- RFC 5307:GMPLS対応IS-IS拡張
- RFC 5316:AS間MPLS/GMPLS TE対応IS-IS拡張
- RFC 7810:IS-IS TEメトリック拡張
- RFC 8570:IS-IS MPLS TE属性サブTLV
- IANA IS-IS TLV Codepoints
- Heng Lu:On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu:Running Code Primary
- Heng Lu:On the Agency Problem at the Core of Internet Governance
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
