要約

  • RFC 9753 は RELAX を双方でネゴシエートし、既存の P/I オブジェクトヘッダーフラグをステートフル PCEP で使う。P が 0 の未知オブジェクトは無視され、残りのメッセージ処理は続行できる。
  • 継続、I の報告、PCRpt の成功はいずれも限定されたプロトコル上の受領記録である。制約の維持、経路の同等性、装置への反映、パケットの安全な通過は別に確かめなければならない。

警報が出ない変更ほど、意味を失いやすい。PCC が複数の意図属性を含む LSP 状態を報告する。その一つは新しい制約を表すが、相手はそのオブジェクトを知らない。送信側のローカルポリシーは P を 0 にしていた。受信側はオブジェクトを飛ばし、残りを処理してセッションを維持する。必須オブジェクトの欠落も形式エラーもない。RFC 9753 が認めた通りに交換は成功した。

しかし、保存されたのはメッセージの流れであり、メッセージが担っていた意味のすべてではない。

RFC 9753 は 2025 年 4 月に IETF Standards Track で発行され、RFC 8231 を更新した。RFC Editor の記録と Datatracker が文書の身元と状態を示す。目的は PCRpt、PCUpd、PCInitiate の一部オブジェクトを任意処理にし、能力差のたびに交換全体を失敗させないことである。

RELAX が共有するのは文法であって判断ではない

RFC 5440 の基本 PCEP では、P は処理規則、I は任意オブジェクトを無視したという表示である。RFC 8231 はステートフルオブジェクトの P/I を送信時 0、受信時無視としていた。RFC 9753 は STATEFUL-PCE-CAPABILITY TLV に R、すなわち RELAX を追加した。IANA PCEP レジストリでは bit 17 である。

PCE と PCC の双方が R を設定しなければ P/I 処理は有効にならない。R を設定しなかった話者は、設定された P/I を受けても従来通り無視する。双方の R が証明するのは、そのセッションで同じ処理文法を使う意思だけだ。任意にできるオブジェクトの一覧、ポリシー版、遅延・帯域・アフィニティ・保護に対する意味まで共有したとはいえない。

RFC は P=1 を既定として推奨する。P を 0 にする根拠は、制約を任意と認めるローカル設定・ポリシー、または安全に無視できる情報オブジェクトである。プロトコルが無害性を発見するのではない。運用主体がリスクを引き受ける。

P/I の単位はオブジェクト全体

P と I は、オブジェクト内部の未知の任意 TLV だけに適用できない。PCEP オブジェクト全体が対象になる。このため、監査記録にはオブジェクトクラスとタイプ、メッセージ、方向、SRP または要求 ID、LSP、ポリシー版、元バイトのハッシュが必要だ。未知の飾りだけを捨てたつもりでも、実際には制約を運ぶ容器全体を判断から外した可能性がある。

必須オブジェクトは任意にならない。PCRpt では LSP と意図された ERO、PCUpd と RFC 8281 の PCInitiate では SRP、LSP、ERO が例示される。これらで P が誤って 0 なら、Error-Type 10、Error-value 1 の PCErr が必要だ。

非必須オブジェクトでは分岐する。P=1 のオブジェクトを理解できない、または処理しない場合、ステートフルメッセージ全体を Unknown Object または Not supported object で拒否する。P=0 なら無視して継続できる。したがって「エラーなし」には、全てを理解した場合と、未知オブジェクトを正しく捨てた場合が含まれる。成功件数だけでは判別できない。

委任は P を変更する権限も動かす

PCRpt の P は、状態維持・計算・再最適化で PCE が考慮すべき対象を示す。PCUpd と PCInitiate の P は、経路設定で PCC が考慮すべき対象を示す。RFC 8051 は適用文脈を説明し、RFC 8231 は LSP 状態の所有を PCC に残し、PCE からの属性を PCC のローカルポリシーに従わせる。

ただし委任中、RFC 9753 は PCE に処理区分の変更を認める。PCC が P を設定していたオブジェクトを無視扱いにし、逆に設定していなかったものを必須扱いにもできる。PCC は PCRpt で期待を確認し、受け入れられなければ不受理更新の手順に進む。

最終状態の P だけでは、誰がいつ何を変えたか分からない。委任者、セッション世代、SRP/要求、オブジェクト、変更前後の値、認可したポリシー、PCC の応答を一続きに残す必要がある。

I は処理報告であり、制約達成報告ではない

PCE は PCUpd に無視した任意オブジェクトを再掲して I を設定できる。PCC も PCUpd または PCInitiate への応答 PCRpt で同様にできる。I=0 は処理したとの表示である。ただし、応答を結び付ける SRP がない PCRpt では I に意味がなく、PCInitiate では I は常に 0 でなければならない。

正しい文脈でも「処理」は「満足」ではない。パーサーが認識し、ポリシーモジュールが読んでも、別の条件が経路を決めることがある。PCC が状態を報告しても、それは転送ハードウェアの独立観測ではない。

RFC 9753 の例では、PCRpt が意図属性と実属性のリストを運ぶ。意図側の METRIC オブジェクトは RFC 8233 の Path Delay Variation に上限を設けられる。満たす経路がないとき任意化する判断はあり得る。しかし、その後の成功は元の上限の存続を意味しない。上限値と単位、無視判断、再計算、実経路を残し、実トラフィックで変動を測るべきだ。

状態の一致は転送の直前で止まる

RFC 8231 は初期同期を、PCC の LSP 状態をある時点で PCE に複製するものと説明する。PCRpt は経路、帯域、運用・管理状態を伝えられる。そこからパケットまでには、ローカルポリシー、シグナリング、資源許可、RIB やラベル表の選択、ネクストホップ解決、ハードウェア書込みが残る。

この論点は RFC 9757 の Native IP 中央命令とは異なる。RFC 9753 が扱うのは、より前段のオブジェクト意味の分岐である。RFC 9826 の YANG 管理投影も有用だが、完全なデータツリーが転送の独立証人になるわけではない。

RFC 9753 は、同一の管理権限に属する PCE/PCC 間で、認証・暗号化されたセッションだけに拡張を有効化することを推奨する。RFC 8253 の PCEPS と RFC 9325 の TLS 指針が参照される。安全なチャネルは相手と通信を守るが、P を 0 にする判断の意味や正しさまでは認証しない。

実装は RELAX と任意制約を設定可能・可視にすべきともされる。一方で新しい生存監視や動作検証要件は追加されない。これは標準化範囲の限界であり、外部確認が不要という意味ではない。

Heng Lu の「Reality Layers」を明示的な編集上の視点とすると、交渉した記号、受理した処理、コントローラーの状態、装置実装、観測結果は別々の事実である。信頼できる台帳は、相手とセッション、双方の R、メッセージとオブジェクト、送信ポリシー、パーサー結果、無視/エラー判断、失われた意味、再計算、PCE/PCC 照合、装置状態、パケットとロールバックを結ぶ。

情報源

技術資料は RFC 9753、RFC Editor 情報、Datatracker、IANA PCEP、RFC 5440、RFC 8231、RFC 8281、RFC 8051、RFC 8233、RFC 8253、RFC 9325、境界確認用の RFC 9757 と RFC 9826 である。特定の実装、ベンダー、運用者、事故、相互接続試験、普及率は主張しない。