要約

  • RFC 7570 の ERO Hop Attributes は任意のコンテナで、サブオブジェクト種別は 35。Hop Attributes TLV を一つ以上運べるが、その意味は「経路全体」ではなく配置されたホップに結び付く。
  • サブオブジェクトは、対象ホップを識別する ERO サブオブジェクト、またはそのホップに関連するラベル・サブオブジェクトの直後に置く。属性の適用範囲は直前の ERO サブオブジェクト、または直前の複数サブオブジェクトである。
  • R ビットは RFC 5420 の処理ルールを取り込む。セット時は required、クリア時は optional の規則で検査する。属性の実質的意味、許される順序や変更、報告義務は、属性を定義する文書とノードのローカル方針が決める。

どのホップか、誰が決めるのか

入口ノードは、すでに表現された ERO の経路段階の直後に Hop Attributes を配置し、対象ノードに処理を依頼する。これは「どこに要求するか」を限定する仕組みであり、他のホップまで操作する認可ではない。RFC 3209 は ERO を要求された抽象ノード列、RRO を収集された経路情報として扱う。RRO は認可チャネルではない。特定の中継段階での動作を必要とするサービスは、その段階だけに要求を向けられるが、同じ属性を全 LSP の全ノードに要求することにはならない。

種別 35 は可変長で、TLV の合計はサブオブジェクト長に制限される。ERO の処理中にこのサブオブジェクトに到達したノードが対応していなければ、Routing Error / Bad EXPLICIT_ROUTE PathErr を返し、ERO を問題のサブオブジェクトまで切り詰める。RFC 3209 は、通常処理で遭遇した未知の ERO サブオブジェクトについて Bad Explicit Route Object を返す一方、まだ遭遇していない未知のサブオブジェクトは転送する、と定める。したがって任意処理は、壊れた長さや形式を無条件に通すという意味ではない。

RFC 5420 の Attribute Flags TLV は ERO Hop Attributes 内に運べるが、その位置で有効と定義されたフラグだけが適用される。無効なフラグは黙って無視され、未知のフラグは Unknown Attributes Bit PathErr を起こすべきである。未知と無効、そして R ビットを、属性の業務的意味と混同してはならない。ノードは既存の RSVP policy-control または admission-control のエラーで拒否でき、属性定義の手続きが許せば要求値を変更できる。ホップの範囲を指定しても、入口に無制限の権限が生じるわけではない。

LSP 全体の報告とホップ証拠

LSP_ATTRIBUTES または LSP_REQUIRED_ATTRIBUTES で信号化した全 LSP 属性は、通常 RFC 5420 の RRO Attributes で報告する。ERO Hop Attributes だけで信号化した属性は、通常 RRO Hop Attributes で報告する。後者も種別 35 の任意サブオブジェクトで、処理済みまたは追加の Hop Attributes TLV を運べる。ただし、準拠を報告しなければならないかどうかは、各属性の定義文書が明記しなければならない。LSP が確立しただけでは、任意のホップ属性が要求どおり実行された証明にならない。

中継ノードは通常 RRO Hop Attributes を変更せず転送するが、ドメイン境界は機密性またはメッセージサイズの方針で情報を削除・変更できる。古い入口ノードは未知の RRO 情報を破棄する可能性もある。よって RRO Hop Attributes は条件付きで方針変更可能な証拠であり、絶対的な証明ではない。RFC 7571 の loopback は一つの限定された応用例である。特定ノードへ OAM loopback を向け、RRO Hop Attributes で状態を返すが、これは RFC 7570 の汎用コンテナの意味を定義し直すものではない。

パケットレベルの検証フィクスチャ

  1. 隣接性：IPv4-prefix(A) -> Label(A) -> Hop Attributes(type=35, R=clear, TLV=X) -> IPv4-prefix(B) を作り、X が A とラベルだけに結び付くこと、B や LSP 全体には広がらないことを確認する。
  2. **R ビット：**同じ合法 TLV を R=0 と R=1 で送る。結果を optional と required の処理として記録し、R の値から TLV の実質的意味を推測しない。
  3. **配置・順序：**属性定義文書が許していない直前サブオブジェクトの後ろに type 35 を置き、さらに順序依存の TLV を入れ替える。拒否または処理結果を記録し、RFC 7570 だけから個別属性の順序を決めない。
  4. **非対応：**対象ノードが到達済みの type 35 を理解しない状態で、Routing Error / Bad EXPLICIT_ROUTE PathErr と問題箇所までの ERO 切り詰めを検証する。未到達の未知 ERO サブオブジェクトが転送される場合とも比較する。
  5. **フラグ：**有効、無効、未知の Attribute Flags を別々に入れ、無効は無視され、未知は Unknown Attributes Bit PathErr となるかを記録する。
  6. **RRO：**全 LSP 属性とホップ専用属性を別々に送信し、前者が RFC 5420 RRO Attributes、後者が RRO Hop Attributes に現れるかを確認する。ただし報告を準拠証拠と呼べるのは属性定義が要求する場合だけである。境界で RRO を削除し、観測可能な記録が減ることも確認する。
  7. **反実仮想：**R をクリアし、属性定義の報告もない状態では、確立成功を処理の証明としない。R をセットし、非対応または不正なサブオブジェクトを送った場合は、確立拒否を予想する。

出典

資料からは、ベンダーや運用者の実装、導入普及率、失敗率、メッセージ増加量、顧客影響は分からない。保存された正誤表ページはスナップショットであり、訂正内容を主張するものではない。