要約

  • draft-ietf-pce-flexible-grid-17は2026年9月13日に公開された。文書はProposed Standardを目指してIESG Evaluation中で、9月17日の電話会議議題に残っていた。
  • 第16版は、PCEPのError-Type 24をRouting Problemと呼び、未対応の対称性と周波数スロット割当方式に2つの値を追加しようとした。しかしIANAの現行レジストリで24はLSP instantiation errorである。
  • Area DirectorのDISCUSSは、PathErrやError CodeがRSVP-TEの語彙でありPCEPではないと指摘した。第17版は2つの応答規則とIANA登録要求を削除し、RSA計算自体が未対応の場合の新しい別タイプは残した。
  • 衝突の除去はレジストリを直す一方、観測できる応答も減らす。実装者は追加だけでなく削除を、版・条件・パケットと結び付けて管理する必要がある。

配線図と警報盤の番号

制御室の警報盤で「24」が点灯しても、意味を決めるのは数字だけではない。どの装置から、どのメッセージで、どの版の配線図に従って届いたかが必要だ。古い配線は「LSPのインスタンス化」と読み、新しい説明書だけが「ルーティング問題」と読めば、対処は分岐する。

第16版の PCEP Extension for Flexible Grid Networks にあったのは、この種の不一致だった。草案は、Path Computation Client（PCC）がPath Computation Element（PCE）へ、柔軟グリッド光ネットワークの経路と周波数スロットを要求するためのオブジェクトやTLVを定義する。要求側は双方向で同じスロットを使うか、First-FitやRandomのどの方式を望むかを示せる。

第16版は、PCEが対称性または割当方式を扱えないとき、Error Code 24 Routing Problemと新しいサブコードを持つPathErrを返すよう求めた。さらに9.9節で、この2値をPCEPの既存Error-Type 24へ登録するようIANAに依頼していた。

ところがIANAのPCEPレジストリでError-Type 24は、RFC 8281によるLSP instantiation errorである。PCEPの基礎仕様RFC 5440は、エラーメッセージをPCErr、フィールドをError-TypeとError-valueと呼ぶ。PathErr、Error Code、Routing ProblemはRSVP-TE側の用語だ。表記揺れではなく、一方のプロトコルの意味を他方の使用済み番号へ差し込む設計になっていた。

9月9日、Routing Area DirectorのGunter Van de Veldeが正式なDISCUSSとしてこの問題を記録した。Datatrackerの履歴には、Spectrum Allocation TLVの形式・格納先・配置、さらに新規エラータイプの値0と将来の割当方針に関する指摘も残る。Mohamed Boucadairの別のDISCUSSは、ポリシー例外、固定長、リンク識別子の解析、能力発見、IANA方針を問うた。DISCUSSは解決を求める手続きであり、不採択の予告ではない。

第17版は番号を替えず、規則を消した

第17版は、未対応の対称性と方式に対する2つのPathErr規則を段落ごと削除した。9.9節と登録表もなくなった。公式差分を見る限り、代替番号への移設ではない。現在の版では、この2つの専用応答そのものが定義面から外れた。

すべての失敗信号が消えたわけではない。草案は、番号未定の新しいFlexi-Grid RSA Errorを引き続き求め、そのError-value 1をRSA computation not supportedとする。第17版は値0をUnassignedとして追加した。またNO-PATH-VECTORには、光スペクトル制約をすべて満たす経路がなかったことを示す別のビットがある。RSA能力がない、能力はあるが経路がない、要求属性だけを扱えない、という三つは同じ事象ではない。

修正はほかにもある。Frequency Slot Selection TLVの長さは4と明記された。周波数の添字nは正・負・ゼロを取れる。Label Setの返却義務には、ポリシーまたは検証エラーがない場合という条件が加わった。Inclusive Rangeはリンク識別子レコード2件と説明される。RFC 7570の正式名称ERO Hop Attributes subobjectが使われ、TLSの安全性参照にはRFC 9916が加わった。

ただし、新版の存在は全指摘の解消証明ではない。TLVについては有効な配置、順序、関連付け、変更規則、サイズ上限まで問われていた。格納先の名称を一箇所直したことと、要求全体を満たしたことは別である。締切時点で確認できるのは、24の衝突要求が削除され、IANA ReviewがIANA OK - Actions NeededからVersion Changed - Review Neededへ戻ったことだ。

9月17日の結論はまだ存在しない

Datatrackerの文書ページでは、PCE Working Group文書としてProposed Standardを目指し、IESGへ提出済みである。文書APIは第17版を9月13日09:57:08 UTCと記録する。状態はIESG Evaluation、電話会議は9月17日の予定だ。版の更新は、DISCUSSの自動解除、IESG承認、IANA再審査の完了、番号割当のいずれでもない。

IANAの状態が戻ったことも拒否を意味しない。変更された要求を現行レジストリと再照合する必要が生じた、という証拠である。RFC 8126はIETF ReviewやFirst Come First Servedなどの登録方針を定義するが、新設範囲にどの方針を採るかはなお標準化過程の判断事項だ。

能力発見の文章も変わった。第16版は、新しいPCEP OPEN能力広告を置かずエラー方式を採ると説明しつつ、RFC 5088とRFC 5089のOSPF/IS-IS発見機構にも言及していた。第17版はエラー方式の正当化を削り、発見でFlexi-Grid RSA能力を広告できるという記述を残した。これは文書上の整理であり、運用網の挙動調査ではない。

IETF Last CallはIPR disclosure 3053も関連情報として挙げた。これは手続き上の通知であって、特許の有効性、必須性、侵害、ライセンス要否、価格、実施自由に関する本稿の判断ではない。

登録表とワイヤを一枚の受領票にする

診断を追加・移動・削除するときは、旧版の「プロトコル、メッセージ、Error-Type、Error-value、発生条件」を保存し、当時のレジストリ行、レビュー指摘、新しい組または明示的な削除へ結び付けるべきだ。草案のハッシュ、実装版、パケット単位の試験結果、IANAとballotの状態、運用開始時刻まであれば、数字だけが独り歩きしない。

これは私の提案で、IETFやIANAの要件ではない。Heng LuのPolicy Mirrorが示すように、実効的な統制面は現行ルール、配布されたコピー、実行経路の組合せにある。Minimum Initial Specificationとして受領票だけを共通化すれば、各運用者のポリシーまで中央化せずに済む。Reality, Not Advocacyの原則は、文書修正を未確認の障害事例に膨らませないための境界になる。

公開された相互運用障害や、削除済みエラーを実際に送ったパケットの証拠はない。確認できるニュースは、標準承認前のレビューが番号衝突を見つけ、提案されたワイヤ上の契約が変更されたことである。

情報源