要約

  • RFC 9756はPCEPに実験用のエラータイプを確保するが、参加者が選んだ番号に恒久的な意味を与えるものではない。
  • 正式な割り当てへの移行では、装置だけでなく、診断辞書、過去の記録、切り戻し用の版も対象になる。
  • 試験の完了は「新しい版で動く」だけでは判断できない。残った仮の取り決めを誰が廃止できるかが問われる。

障害記録は、保存されていれば後から読めるとは限らない。数字が残っていても、その数字を当時どう解釈していたかが失われれば、記録の意味は変わりうる。

例えば、あるネットワーク試験で使っていたエラー番号を、正式に割り当てられた番号へ切り替えたとする。監視ツールも新しい辞書を読み込む。ところが、数週間後の振り返りで古い記録を開くと、現在の辞書に基づく説明が表示される。見た目は整っているが、それが試験時の装置の報告内容だったかは別問題だ。これは実在する製品の不具合報告ではなく、移行試験で検討すべき仮想例である。

この小さな不確かさは、ソフトウェア更新の範囲を広げる。送信側の定数を置き換えても、数字を読む側の時間軸までは自動的にそろわない。古い版への切り戻しを認めるなら、過去の取り決めが再び現れる可能性も考えなければならない。

番号の意味は二つの欄で決まる

PCEPの基本仕様であるRFC 5440では、エラーオブジェクトにError-TypeとError-valueがある。前者はエラーの種類を、後者はその詳細を表す。運用上の意味を持つのは組み合わせであり、片方の整数だけでは十分でない。PCEPは経路計算に関わるクライアントと計算要素などの通信に使われ、その異常を共有する語彙にも整合が必要になる。

2025年3月の RFC 9756は、Error-Typeの252〜255と、その配下のError-valueの0〜255を実験用に確保した。IANAのPCEP登録簿にもこの区分が反映されている。タイプ0〜251とその値にはIETF Reviewが適用される。

実験の参加者は、使用するタイプと値、そして意味を合意する。同じ実装で複数の実験を並行して行う場合は、組み合わせを衝突させない配慮が要る。また、通常のエラータイプの下に独自の実験値を置く余地はない。未割り当ての欄を見つけても、そこが自由な試験用領域になるわけではない。

したがって、参加範囲は技術条件の一部である。新しい相手が加わる、別の試験が同じ実装を使う、保守担当が替わる。こうした変更で、最初の合意が通用する範囲は変わりうる。「以前は接続できた」という記憶だけでは、現在の意味の共有を確認できない。

試験のための余白を占有権にしない

RFC 3692は、一時的に割り当てた番号の回収が難しくなる理由を説明している。連絡先が古くなる、試験が終わったか分からなくなる、製品に組み込まれた番号を再利用すると既存装置に影響するかもしれない。数字自体は小さくても、それに依存する環境は見えにくい。

実験用の範囲は、その問題に対する仕組みである。ただし、一般展開向けの恒久的な割り当てではない。製品での実験番号の認識は既定で無効とし、利用者が明示的に機能を有効化し、番号を設定する。製品によっては明示的な再プログラムで設定する場合もある。複数の事業者が合意しただけで、実験値が世界で一意になることもない。

ここから導かれる運用課題は、試験を避けることではない。誰がその取り決めの参加者で、誰が追加や変更を承認するかを追えるようにすることである。参加者一覧に責任者がいなければ、試験の境界は構成変更に置き去りにされる。

特別な仕組みを減らす改訂

PCEPには以前から実験用の場所があった。RFC 8356は、メッセージ、オブジェクト、TLVに実験用範囲を設けている。当時は、別の部分で新しい機能が必要なら、実験用オブジェクトやTLVに載せればよいという考え方だった。

RFC 9756はエラーについて、その回り道を見直した。任意の実験エラーを運ぶ専用オブジェクトを作るより、既存のエラー処理の仕組みを使う方が、不必要な実装の分岐を減らせる。成功した実験を標準化へ進めやすくするための、範囲を絞った改善である。

だが、処理の枠組みを再利用できることと、実験で選んだ数字をそのまま使い続けられることは違う。標準化過程のRFCとしての公開を目指すIETF作業へ進むなら、各組み合わせについてIANAの割り当てが必要になる。新しいタイプとその値を割り当てる場合も、既存タイプの下に新しい値を設ける場合もある。

仕様は実装内の変更を数値の置き換えとして説明する。それは変更箇所の単純さを示すが、運用環境全体の移行費用を示すものではない。旧版と新版の意味を自動交渉する共通手順も、あらゆる装置に使える切り替え順序も、このRFCは定めていない。

混在が必要なら、実装が何をサポートするかを確かめるべきである。安全に共存させられない場合は、試験を隔離するか、対象を定めて協調した切り替えを行う。受信側に文脈を推測させることを、互換性の代わりにしてはならない。

公開する名前と、残すべき証拠

RFC 9756は、実験で使う具体的な数値の組を公開文書に記載せず、必要なら文字や記号による名前で説明するよう勧める。一時的な選択が、文書の繰り返しを通じて永続的な約束になるのを避けるために有用な助言である。

一方、診断記録は実際に何を受け取ったかを説明できなければならない。生の数値、観測時刻、相手、実験の版、解釈に使った辞書の版などは、保存を検討する価値がある。これは記事としての運用提案であって、RFCが義務づけるログ形式ではない。実装が信頼して取得できる情報と、組織のアクセス管理に合わせる必要がある。

重要なのは、新しい辞書によって古い意味を上書きしないことだ。保存済みの試験記録を更新後に読み直す検査は、新しいトラフィックを発生させる検査と目的が異なる。過去の説明能力と現在の互換性は、それぞれ確認する必要がある。

受信結果から原因を決めつけない

既知の実験タイプの中に未知の値が来る理由として、RFC 9756は実装の不具合、値の取り決めの不一致、並行実験を挙げる。未知という観測だけで、どれが起きたかは確定しない。

同RFCはエラーの記録やセッションを閉じる可能性を説明するが、すべてのPCEPエラーで切断を義務づけてはいない。RFC 5440では、要求の取り消しなど、条件に応じて異なる処理が定められている。別セッションの確立を試みるケースでは、既存セッションを保持する規定もある。接続が続いたことも、切れたことも、それだけで意味の整合を証明しない。

もう一つの変更である登録方針も、同じ慎重さで読むべきだ。RFC 9756は列挙された登録簿をStandards ActionからIETF Reviewへ変更する。RFC 8126が説明する通り、対象となるIETF流のRFCの種類が広がる一方、IETFの合意に基づく審査は残る。先着順でも、あらゆる流のRFCを受け入れる方針でもない。

本稿の視点は、Lu Hengの現実の構造を報じるというBTWの原則に基づく。資料が示すのは仕組みと条件であり、特定事業者の障害、採用率、測定された移行費用ではない。その限界を守っても、試験終了の責任をどこに置くかという問いは十分に具体的になる。