要約

  • XRO（Exclude Route Object）は経路全体を対象にし、EXRS（Explicit Exclusion Route Subobject）は ERO 内の特定区間を対象にする。
  • XRO の L ビットがクリアなら MUST exclude、セットなら SHOULD avoid。後者はローカルな経路選択方針によって通過が残り得る。
  • 多様性はシグナルに載る旗の約束ではなく、計算結果と実経路で確認すべき結果である。

除外が与える権限

RFC 3209 の ERO は RSVP-TE の Path に抽象ノードを含める仕組みである。RFC 4874 は、入口で完全な経路を計算しなくても、使ってはならない資源を伝えられるよう XRO を追加した。XRO は IPv4/IPv6 プレフィックス、番号のないインターフェース、自律システム、Shared Risk Link Group を識別でき、プレフィックスとインターフェースの形式はインターフェース、ノード、SRLG の属性を区別できる。XRO は全経路を拘束する。一方、EXRS は ERO に入れられ、明示経路の区間にだけ適用される。この範囲の違いは、経路全体の禁止と一部分の禁止を混同しないために重要である。

ノードが次のホップを選ぶ、または loose な明示経路を展開するとき、必須除外の対象資源を導入してはならない。避けるだけの資源については、その利用を最小化すべきである。必須 XRO と ERO の包含が矛盾するなら、XRO の必須除外が優先し、Path メッセージは拒否され、定義された Routing Problem エラーが返される。これは XRO が代替経路を選ぶという意味ではない。候補集合から資源を消すだけである。除外後に転送の選択肢が残らない場合、ノードは Exclude Route によって経路が遮断されたことを示す PathErr を返すべきである。

実装限界と境界

実装またはポリシー上 XRO が複雑すぎる場合も、特定の PathErr によって拒否され得る。XRO を知らないノードは、XRO のクラス番号により内容を検査せず転送できる。未対応のサブオブジェクトや属性が無視される可能性もある。したがって、メッセージが先へ進んだことは、制約が実行されたことを意味しない。計算ノードは Record Route で違反を観測し、再計算を試みられる。Record Route は検証手段であって、処理能力の代替ではない。

計算ドメインをまたぐと、除外は追加・削除され、あるいはドメイン内で解決されたり範囲が変わったりして無関係になることがある。RFC 8390 は XRO と EXRS に多様性サブオブジェクトを加え、クライアント、PCE、ネットワークが割り当てた参照 LSP または経路の識別子を使えるようにした。要求元が参照経路の詳細な資源をすべて知る必要はない。RFC 8390 は必須多様性と助言的多様性を区別し、不整合または未対応の識別子に対するエラーを定める。また、通常の ERO 情報がセキュリティ方針で除去される場合でも、指定された多様性サブオブジェクトは境界を越えて保持されなければならない。これはトポロジー開示を減らし得るという Elias Ward 分析を支えるが、実運用の効果を証明しない。

RFC 6001 は RFC 4874 を多層・多地域 GMPLS に更新し、交換能力とラベルの除外を追加した。必須除外と回避推奨の区別は維持される。多層経路の意味は細かくなる一方、処理能力、境界保持、互換性のコストも増える。凍結された RFC Editor の RFC 4874 errata ページは現行の記録として扱うだけであり、この文書はその記録を超える訂正を主張しない。

利益、コスト、反実仮想

要求元は指定資源に対する拒否権を持つ。経路計算ノードは残った候補から経路を選ぶか、選べないと報告する。下流実装とドメイン境界は、サブオブジェクトの解釈、保持、検証を左右する。リンク、ノード、SRLG、参照経路の分離を必要とするサービスが潜在的な受益者だが、RFC は実際の物理分離を保証しない。

Elias Ward 分析：必須除外は選好を fail-closed の制約へ変え、実行可能集合を狭め、設定失敗の可能性を高める。SHOULD avoid は可用性を残す代わりに、ローカル方針が対象資源の通過を許す余地を残す。無制約なら不要な資源を再利用し得る。助言だけならその資源を通過し得る。過剰な必須除外なら適合経路が存在し得ない。これらはプロトコルから導ける反実仮想であり、特定トポロジーの結果ではない。

検証フィクスチャと運用判断

次のフィクスチャは、現行ネットワークの事実ではなく、実験・監査で確認すべき項目である。

  1. インターフェース：L ビットをクリアした XRO で番号なしインターフェースを除外し、次ホップと Record Route に出現しないことを確認する。
  2. ノードと SRLG：IPv4/IPv6 プレフィックスでノードを、別の指定で SRLG と自律システムを除外し、候補、PathErr、ドメイン通過後の状態を比較する。
  3. 矛盾：ERO が XRO の必須除外資源を含む Path を送り、Routing Problem による拒否を確認する。
  4. 空集合：すべての次ホップを除外し、Exclude Route による遮断を示す PathErr を確認する。
  5. 助言：L ビットをセットした SHOULD avoid を送り、ローカル方針が対象資源を選ぶ可能性を MUST exclude と別に記録する。
  6. 能力：複雑すぎる XRO、未知のサブオブジェクト、RFC 6001 の交換能力・ラベル除外、RFC 8390 の不整合・未対応識別子を送り、拒否、無視、透過を記録する。
  7. 境界：セキュリティ方針で普通の ERO が除去される経路を通し、RFC 8390 の多様性サブオブジェクトの保持と Record Route の実経路を確認する。

運用者はまず全経路か区間かを確定し、MUST exclude と SHOULD avoid を選ぶ。次に PCE、対向ノード、境界の対応状況、候補集合、トポロジー開示を確認し、フィクスチャを実行する。最後に PathErr、Record Route、参照経路の解決、資源の実際の重複を照合する。多様性のシグナルは結果の証明ではない。未知なのはライブトポロジー、経路実現可能性、ベンダーの動作、導入状況、設定時間、失敗率、顧客影響である。

出典