要約

  • RFC 9826 は PCEP の entity、peer、session、notification、RPC、統計を ietf-pcep と ietf-pcep-stats に整理する。
  • NMDA の origin、読取時刻、counter の discontinuity、管理権限がなければ、値の意味と鮮度を判断できない。
  • datastore の先には、PCEP の相手確認、セッション、controller の判断、PCC の受領、装置適用、forwarding、実トラフィックという別々の受領証が残る。

障害会議で最初に共有されるのは、しばしば整然とした JSON やツリー表示である。peer が並び、session は up、LSP-DB には項目があり、counter は増えている。この画面は調査を早める。しかし、同じ画面が「経路制御は正しい」という結論まで引き受けると、観測点が権限を越える。

RFC 9826 は YANG 1.1 による共通 PCEP 管理モデルを定める。ietf-pcep はローカル entity、peer、session、notification、操作を扱い、ietf-pcep-stats は応答時間やメッセージ数を加える。RFC Editor の記録、Datatracker、errata 検索、IANA YANG 登録は文書と module の同一性を確定するが、製品実装や運用採用は証明しない。

origin は来歴であって本人確認ではない

entity の admin-status は望ましい状態、oper-status はそこへ到達しようとする現在の状態である。前者が true でも entity は停止中、起動中、失敗中になり得る。意図と実現を同じ緑色に塗ってはいけない。

NMDA の <operational> は config false だけではなく、実際に適用された意図、dynamic、learned、system、default の設定と system state を含む。origin annotation は値の発生源を示す。遠隔 peer を認証せず、プロトコル交換の時刻を保証せず、packet を観測しない。YANG 1.1 は形を定め、NACM は管理 client の操作・内容・notification へのアクセスを制御する。正しい形と正しい権限は別の審査である。

session は恒久的な関係ではない

peer list は IP address を key にする。住所としては有用だが、組織や人物の永続的 identity ではない。RFC 5440 では双方が Keepalive を受信して初めて session が成立する。接続衝突時には local initiator と remote initiator の二つが一時共存できるため、RFC 9826 は initiator で session を区別し、一方が確立すると他方を捨てる。

従って session-up は読取時刻、state-last-change、transport connection、peer authentication と組にする必要がある。session ID はトラブルシューティング用であり、世界的な本人証明ではない。notification も完全ではない。NACM が購読者への通知を落とす場合があり、collector の再接続中にも穴が生まれる。無通知は無事件を意味しない。

counter には寿命がある

統計 module は PCReq、PCRep、PCErr、PCNtf、Keepalive、stateful update や initiate の件数、応答時間を公開する。同時に discontinuity-time を持ち、current session の統計は session down で失われる。container 単位の reset と全 peer/session の global reset も定義される。

数値だけを時系列へ置くと、reset を改善と誤認できる。reset-at と reset-finished-at も区別すべきである。PCUpd が数えられたことは、PCC の受理、正しい経路、装置への適用を示さない。

trigger-resync は特定 PCC との state resynchronization を PCE に要求する。RPC の受理は開始の受領証であり、完了や一致の証明ではない。RFC 9826 は、無権限の resync が session を継続同期へ追い込み、無権限の global reset が監視を傷つけると警告する。management channel の相互認証、NACM 判定、RPC、PCEP の結果を連結しつつ混同してはならない。

LSP-DB と FIB の間

stateful PCE の operational datastore は PLSP-ID、PCC address、LSP-ID を key とする LSP-DB を持てる。RFC 8231 が synchronization、delegation、PCRpt、PCUpd の意味を定める。controller database の項目は重要だが、line card や FIB の読み取りではない。

周辺の規格はそれぞれ独立した機構を持つ。RFC 9504 は GMPLS delegation、RFC 9830 は BGP による SR Policy candidate path、RFC 9863 は PCEP Color、RFC 9916 は PCEPS の TLS version と early data を扱う。RFC 9826 に関連 leaf があることは、これらの結果が成立した証拠ではない。

旧来の PCEP MIB との対応表は移行を助ける。ただし YANG と MIB が同じ内部 counter を読むなら、一致は独立した裏付けにならない。

Running-Code Primacy は共通文書より稼働事実を優先する。Minimum Initial Specification は共通規則と現場判断を分ける。Reality, Not Advocacy は証拠の空白を願望で埋めない。この三点は本稿の編集原則であり、IETF の意図を追加するものではない。

必要な chain は module/feature、datastore、origin、time/epoch、管理 identity と authorization、PCEP transport と peer、session、controller request、PCC response、device apply、forwarding、service outcome である。RFC 9826 は入口を標準化した。出口までの事実は、各現場が記録し続けなければならない。