要約

  • RFC 9863 は、PCEP 話者が色能力を知らせ、LSP オブジェクトに一つの 32 ビット色値を載せる条件を定める。
  • その値はパス属性の記録になり得るが、サービスへの割当て、性能、認可、配送結果の証明にはならない。

「low latency」という例があるため、色に性能保証の意味を読み込みたくなる。しかし RFC 9863 が相互運用のために決めるのは、TE トンネルまたは SR ポリシーに関連付ける数値の運び方である。値は unsigned integer であり、測定値でも、契約条項でも、経路を実際に通ったトラフィックの証跡でもない。共通に解釈できるのは、まずそのフィールドがどの条件で現れたかまでである。

開始点は能力交渉である。STATEFUL-PCE-CAPABILITY TLV の C-bit、すなわち bit 20 により、PCE または PCC は RFC 9863 の色能力を広告する。相手がその能力を広告していなければ、COLOR TLV を送ってはならない。同じ LSP オブジェクトに複数の COLOR TLV があれば最初だけが処理される。この連鎖は機能対応とメッセージ規律について明確な事実を作る。一方で、どのサービスをどの経路へ置くかは作らない。

RFC 9862 との関係は、どこまでを共通層が決めるかをよく示す。SR Policy Association を使う SR パスでは、色は Association にすでに符号化され、LSP オブジェクトの COLOR TLV は使わない。両者が現れれば Association の色が優先される。これは二つの表現の競合を解く規則である。サービスクラスの意味、ヘッドエンドの選択、フローの実際のステアリングを決める規則ではない。

拒否通知にも同じ節度が必要だ。PCC が受け取った色を honor できなければ Invalid Color を返さなければならない。保護関連グループ内の色が矛盾すれば Inconsistent Color で拒否する。ここから分かるのは、制御メッセージが特定の条件に合わなかったことである。受理された場合も、証明されるのは反対向きの限定された事実、すなわちその入力が PCEP の受理面を通ったことだけだ。パス構成、局所ポリシー、サービス対応、転送、測定は後続する別の証拠である。

RFC 9863 はその残余を隠さない。色付きパスへサービスを対応付ける仕組みは scope 外であり、色の使い方は PCC の local policy に委ねられる。実装は能力の有効化と色割当てを設定できるべきで、運用者は意図した色を確認するために状態を取得できる。だが、新しい liveness 検出は要求せず、運用への影響は deployment に依存すると明記する。表示された色を見ても、観測されたサービス品質を見たことにはならない。

この差は、運用会議で特に重要になる。色を見て「優先」「低遅延」「保証済み」と発言するなら、少なくともその用語を定義したローカルポリシー、選択されたパス、サービスへの対応付け、データプレーンの確認、測定期間を別に提出すべきである。RFC はラベルを運ぶ。ラベルを使った主張の責任までは運ばない。

Heng Lu の枠組みでは、公開された仕様は coordination artifact であって、未採用の未来を命令するものではない。PCEP の色も同じである。仕様と IANA の番号は共通の最低限を作る。後から何を意味させ、どの参加者が実装し、どの相手が結果を受け入れるかは、実行中のコードとローカルな決定に残る。この区別を保つことが、フィールドを有用な証拠のままにする。

情報源