要約

  • RFC 9752はVendor InformationオブジェクトをPCRpt、PCUpd、PCInitiateで利用できるようにし、Enterprise NumberをIANAのPrivate Enterprise Numbersレジストリへ明確に結び付けた。
  • PENが正しくても、私有仕様の発行者、版、受信側対応、変更権限、装置適用、転送状態、サービス結果までは証明しない。
  • 運用証跡は生のバイトとdecoderから、能力合意、ローカル認可、SRP/PLSP相関、PCE/PCC再照合、装置、パケット、rollback、cross-vendor fallbackまで段階別に残す必要がある。

障害解析で最も厄介なのは、完全に壊れたメッセージではない。形式が正しく、既知のPENを持ち、PCCからPCRptまで返ったメッセージである。画面上は成功に見えるため、誰が私有仕様を発行したのか、どの版で解釈されたのか、実際にFIBへ反映されたのかという問いが後回しになる。

RFC 9752は2025年4月のIETF Proposed Standardであり、RFC Editorの記録とDatatrackerはRFC 7470を更新したことを示す。新しく共通化されたのはstatefulメッセージにおける運搬場所であって、企業固有データの意味ではない。

Report、Update、Initiateを同じ成功にまとめない

RFC 7470のVENDOR-INFORMATIONはObject-Class 34、Type 1、TLVはType 7である。Enterprise Numberの後ろには企業固有情報が続き、その形式と解釈は番号が示す企業の管理に委ねられる。Informational RFCや商用文書で公開できるが、その文書の識別子やhashはwire formatに含まれない。

RFC 9752では、PCCがLSP状態を報告するPCRpt、PCEが属性更新を求めるPCUpd、LSPの生成や削除を開始するPCInitiateにオブジェクトを置ける。拡張grammarでは生成側にvendor listが現れる。VENDOR-INFORMATION-TLVは、TLVを許すSRPやLSPなどのstateful objectですでに使用可能だった。

この三つは作用が異なる。Report内の値は観測の付加情報かもしれず、Update内の値はprivate constraintかもしれない。Initiate内なら資源生成に影響し得る。同じPCRptに異なるPENの複数オブジェクトも置けるが、RFC 9752は相互の優先順位や標準objectとの競合解決を定めない。位置は文脈であり、因果や優先権ではない。

PENレコードとpayloadの来歴

RFC 9752はEnterprise Numberの参照先をIANAのPrivate Enterprise NumbersとRFC 9371に修正した。レジストリの正確さは向上するが、payload認証が追加されたわけではない。

RFC 9371によれば、PENはFirst Come First Servedで割り当てられ、レコード変更にはassigneeの代表者による認可が必要になる。一方、誰も第三者が他者のPENをデータ内で使うことを防げない。したがって、番号はadministrative namespaceの所在を示すだけで、そのパケットを現在の権利者が作ったという署名にはならない。

別のprovenance bundleが必要だ。発行主体、semantic version、文書hash、decoder build、適用可能なmessage/object、廃止日時、support policyを結び付ける。企業買収、製品移管、community fork、保守終了の局面では、PENの登録名と実際の意味の管理者がずれる可能性を前提にする。

Capabilityは一つのbitでは足りない

実装がVendor Information objectを理解しても、そのEnterprise Numberをsupportしない場合、RFC 9752は継承規則に従って無視するよう求める。また受信者がsupportしないと考えるなら送信すべきではない。しかしRFC 7470はsupport PENのadvertisementやdiscoveryを範囲外とし、機能的なcross-vendor相互運用には協力合意が必要だと述べる。

少なくとも、object classをparseできる、PENを認識する、特定版の意味を実装する、そのpeer・message・LSPでローカルpolicyが有効化する、という四状態がある。最初の状態を最後の状態として扱えば、無視されたprivate fieldによって期待効果だけが消える。反対にdecode成功を権限と見なせば、禁止すべき操作が実行される。

版合意には両端のidentity、version、許可operation、期限、downgrade、fallbackを明記する。private fieldを除いた試験と別vendorでの試験も必要である。標準objectの意味が拡張の有無で暗黙に変わるなら、それはinteroperabilityではなく切替困難な依存である。

PCCのlocal policyが最後の許可を持つ

RFC 9752はRFC 8253による認証・暗号化sessionを推奨する。TLSは接続と転送中のbytesを守るが、private documentの著者や個別LSPへの操作権を決めない。

RFC 8231では、PCCはnetwork managerのlocal policyが許したLSP Update Requestだけに作用する。実行したrequestはLSP setupを生み、その結果をstate reportで返す。delegationは取消可能で、権限のないupdateにはerrorがある。RFC 8281ではPCE-initiated capabilityを双方が示し、拒否可能なparameter、internal error、signaling errorを分ける。

session認証、delegation、local authorization、parser処理、semantic validation、PCRptは別々のreceiptsである。SRP-IDとPLSP-IDで要求と応答を結べても、PCRptはPCCによる報告だ。RIB、FIB、label state、packet pathを直接観測したものではない。

Epochをまたいで照合する

保存単位は、raw object/TLV、PEN、message type、object position、peer、session epochから始まる。そこへ署名済み仕様、decoder hash、capability合意、parse disposition、semantic checks、隣接する標準object、採用した競合規則、local authorizationを足す。さらにSRP-ID、PLSP-ID、delegationでPCUpd/PCInitiateとPCRpt/PCErrを結ぶ。

PCEPの外ではdevice transaction、適用config、programmed route/label、traffic probe、service observation、rollbackが続く。再起動やresynchronization後には同じ意味・権限・状態が維持されたかを再検証する。ある時刻のFIB読取は恒久的deliveryを、単発probeはSLAを保証しない。

RFC 9752は新しいliveness検出もoperation verificationも他protocolへの要求も追加しない。標準YANGはVendor InformationとPENの使用を示せても、private detailは含めない。さらにこの領域がcovert channelになり得るため、operatorはdecoderを把握し内容を検査すべきだとする。presence counterだけでは監視にならない。

IANA PCEPレジストリはcodepointを確認する。各RFCはmechanismを証明するが、特定製品の実装、障害、攻撃、性能向上、service結果を証明しない。Heng LuのRunning-Code Primacy、Minimum Initial Specification、Reality Layersは、共通carrierと実行事実を混同しないための明示的な編集上の枠組みであり、IETF要件ではない。