要約

  • RFC 9504 の能力通知、状態同期、更新、開始要求は、それぞれ異なる範囲を持つプロトコル上の事実である。
  • 委任は特定 LSP の属性更新を許すが、状態の所有、ローカル方針、委任を引き戻す権利は PCC に残る。

委任という語は、運用文書ではしばしば大きく見え過ぎる。画面に delegated の表示があり、PCE が LSP の状態を受け、更新要求を出した。そこで「ネットワークは PCE に任された」と言いたくなる。しかし、この一文はプロトコルが意図して分けている責任を一つに潰してしまう。

RFC 9504 は、GMPLS 制御ネットワークで状態保持型 PCEP を利用するための拡張である。PCE と PCC は能力を知らせ、LSP 状態を同期し、属性変更を依頼し、LSP の設定を促すことができる。この仕組みは、どの当事者が何を報告し、何を依頼したかを追えるようにする。その有用性は、記録の意味が狭く定義されていることから来る。

まず能力通知は、運用の完了ではない。GMPLS に関する報告、更新、開始の機能は、PCC と PCE の双方がサポートし、許可して初めて使える。これは会話の資格を示す。空き資源が確保されたこと、装置が設定を受理したこと、保守上の判断が済んだことを示すものではない。IANA の PCEP 番号登録も、識別子の管理であって、ある実装が採用され動作している証拠ではない。

次に状態の所有権がある。RFC 8231 では、状態保持型 PCE は計算や属性更新の前に PCC の LSP 状態を学ぶ必要がある。State Report は状態変化を報告し、Update Request は変更を依頼する。委任によって PCE は指定された LSP の属性を更新できるが、PCC は状態の所有者のままである。属性には PCC のローカル方針が適用され、PCC はいつでも委任を撤回できる。委任は、状態の所有権を渡さない。

PCInitiate についても同じである。RFC 8281 の PCE initiated LSP は、PCE の要求を受けてインスタンス化される LSP を指す。端点に設定を促す要求は、受理された設定、資源の予約、クロスコネクト、実際の転送面を一括して証明しない。RFC 9504 の報告に意図した経路と実際の経路に関する情報があっても、それは報告主体と対象の範囲で読むべきである。トラフィックが通ったか、保護が働いたか、顧客にどんな結果が出たかは、別の観測問題である。

健全な運用では、記録を一つの結論に圧縮しない。能力の許可、同期された状態、範囲の限られた委任、要求、PCC の方針判断、資源と装置の行為、設置済み状態、そして独立したトラフィックまたはサービス観測を分ける。前の段階は次の段階を問いにできるが、次の段階の答えを代入することはできない。

ここで Heng Lu の最小初期仕様という考え方が役立つ。共有される仕組みは最小限の相互運用事実を扱い、採用と結果責任を伴う判断はローカルに残すべきだという考え方である。動いているコードは重要だが、それだけで権限の範囲を拡張することはない。動作の証拠と、結果を引き受けた主体の証拠は別である。

したがって問うべきことは、「PCE はネットワークを支配しているか」ではない。どの PCC の、どの LSP 属性が、どの条件で委任され、ローカル判断と実際の状態にどの証拠がつながっているかである。その問いは自動化を遅らせず、むしろ後から検証できるものにする。

出典