要約

  • RFC 9689の移行例では、旧ノードはLDPやRSVP-TEを維持し、新ノードはPCECCから直接命令を受ける。PCECCは境界でプロキシになれる。
  • 連続したLSPは、統一された制御トランザクションを意味しない。識別子の対応、各ノードの応答、入口切替、孤児状態、旧状態の削除を別々に証明する必要がある。

RFC 9689の附属書A.1は、全ルータを一斉に置き換えない移行を描く。Node1からNode3までは従来のローカルラベルとシグナリングを使い、Node3が代理できる。PCECCはNode3の出力セグメント、Node4の入力・出力セグメント、Node5の入力セグメントをプログラムする。

パケットにとっては一つの道でも、運用証拠はそこで分かれる。旧側はLDP隣接、RSVP-TE予約、メッセージとローカル表で説明される。新側はPCEPセッション、Central Controller Instruction、CC-ID、PCRptで説明される。プロキシは対応を作るが、二種類の状態を同じ事実にはしない。

なお、この例は導入実績ではない。RFC 9689はInformationalであり、附属書のユースケースは発行時に活発な開発対象ではなかった。特定の実装、事業者、障害、成功率を示す資料として扱ってはならない。

境界には翻訳台帳が要る

RFC 9050では、CC-IDは一つのPCEPセッション内で一意であり、PLSP-IDと送信元を含むLSP識別情報が各ノードの命令を関連付ける。しかし、その識別子は旧側のLDPやRSVP-TEの状態を自動的に指すわけではない。

台帳には、変更要求、サービス、旧LSP、境界ノードとインターフェース、プロキシが受け取った状態、変換規則、出力、PCE、PCEPセッション、PLSP-ID、全CC-ID、ラベル方向、変更世代と復旧世代を結ぶ必要がある。入力と出力だけでなく、どの判断で結んだかも保存する。

この対応がなければ、「ラベル値は正しい」という観測しか残らない。PCCが割り当てたラベル、PCEが指定したラベル、期限待ちの旧予約が同時に存在しても、単一の緑色表示は誰が削除できるのかを教えない。

応答はノードごとの証言である

RFC 9050は各PCCにPCInitiateを送り、各PCCがPCRptを返す手順を定める。予約範囲外のラベルやインストール失敗には明示的なエラーがある。これは有用だが、応答は一つのノード、一つのセッション、一つの命令についての証言である。

PCEは同じ世代の入口・中継・出口の応答がそろったことを確認し、旧側の状態も同時点で確認しなければならない。二台が成功し、一台が不明なら、それは部分的な導入であって多数決の成功ではない。

更新順序も段階を分ける。新命令を先に入れ、入口を新経路へ切り替え、入口の報告後に旧命令を消す。切替前の新状態は資源を使っても通信を運ばない。切替後・削除前は二世代が共存する。PCECC側の削除が終わっても、旧側の予約やプロキシ対応が残る可能性がある。

したがってロールバックは段階別である。切替前なら不完全な新世代だけを除去する。切替後なら、まず正当な転送先を回復してから新状態を消す。旧状態を既に撤去したなら、復帰はスイッチ操作ではなく再構築になる。

孤児命令には新しい責任者が必要だ

PCE障害時、RFC 9050はCCIを即座に消さず、State Timeout Intervalまで残せる。別のPCEは孤児になった命令を引き継げる。RFC 8283も、複数コントローラの同期ではネットワーク変更を失わないことが難しいと説明する。

この仕組みは継続性を守る一方、動作中の状態と現在の所有者を分離する。代替PCEがPCCへ接続できても、元の移行世代、未処理の削除、旧側との対応、切替承認まで復元したとは限らない。

復旧記録には、最後に完成した世代、応答済み・未応答ノード、入口、旧シグナリング、削除待ち、期限、孤児の引継ぎと次の操作を許した規則が必要である。状態同期はラベル差分を見つけられるが、失われた意思決定を作り直すことはできない。

移行完了の条件は、コントローラ画面への全ノード表示ではない。同一世代の各応答がそろい、入口切替が別途承認され、旧側とプロキシの残存状態が削除され、孤児引継ぎが試験され、データプレーン観測が制御記録と矛盾しないことだ。プロキシは段階的採用を可能にする。その価値を守るには、縫い目を見えなくしてはいけない。

参照資料