Summary

  • 6月11日の第15版は Standards Track、11月2日の第16版は Experimental を意図する。新版は既知の実装がないと明記した。
  • 三台以上の PCE が同期セッションを失うと、どの相手に到達できるかについて一時的に異なる見方をし、関連する経路の計算担当が割れる可能性がある。

経路計算クライアントの PCC は、RFC 8231に従い経路状態を有状態 PCE へ報告し、一つのラベル交換経路の制御を一台へ委ねられる。今回の草案は PCE 同士にも状態を渡す。別々の PCE に委ねられた関連経路をまとめて計算し、PCC と PCE の接続が落ちたときの冗長性を高める狙いだ。参加する PCE 間の同期セッションには完全メッシュが必要になる。

ただし、各 PCE が直接見られるのは自分の接続先だ。第16版によれば、ほかの二台の間のセッションまでは見えない。二台構成なら接続の見方が一致するが、三台以上では障害時に到達可能な相手の一覧が一時的に食い違う。どの PCE が計算するかを決める優先度は運用者が各装置に設定し、PCEP 上では通知されない。関連グループの経路が異なる PCE に計算されれば、まとまりとしての最適性が下がる。転送規則と一回限りの再委任は計算ループを防ぐ。

前版の表紙から Standards Track が消えた理由はここにある。第16版は、二台を超える構成で現行の優先度運用が十分か、優先度の通知と明示的な役割交代が必要かを実験で確かめたいと述べる。第6節には既知の実装がない。4日に確認したIETF の文書ページは、第16版を示しながら目標状態に Proposed Standard、IESG 状態に AD Evaluation::Revised I-D Needed を掲げていた。

三台構成で同期断を起こし、関連経路の計算先と実際の経路変更まで追った公開記録が必要だ。