要約

  • RFC 9862は、SRポリシーをPCEP Association、各候補パスをその中のLSPとして表す。PCEPが送る単位は候補パスでも、判断に必要な単位はポリシー全体になり得る。
  • INVALIDATION TLVの設定Dは候補パスに記録されるが、どれか一つにDがあればDrop-Upon-InvalidはSRポリシー全体で有効になる。実際の破棄は全候補パスが無効になった後に始まる。
  • 能力交渉、全メンバー、設定Dと運用D、全パス無効の時点、選ばれた破棄担当、実際のパケット結果を結ぶポリシー単位の破棄レシートが必要だ。これはDaniel Kadeの編集提案であり、RFCやIETFの要件ではない。

運用画面の一行に赤い印が付くと、その一行だけの問題に見える。印は一つのLSPオブジェクトに入り、一つの候補パス識別子に結び付く。データモデルがそれを候補パスの属性として保存するのも自然である。ところがRFC 9862のDrop-Upon-Invalidでは、保存場所を影響範囲と読み替えると因果関係を取り違える。

設定Dは「この候補パスだけを破棄状態にする」という意味ではない。どれか一つの候補パスで有効なら、SRポリシー全体がこの機能を持つ。ただし、その瞬間から通信を捨てるわけでもない。全ての候補パスが無効になった時点で初めて、ポリシーはdrop stateへ入り、Dを持つ候補のうち最もPreferenceが高いものを選ぶ。本来なら別のLSPやIGPへ流れ得た通信を引き寄せ続け、ヘッドエンドで破棄する。

設定を運んだオブジェクト、閾値を越えた集合、状態を変えたポリシー、損失を受けたパケットは、それぞれ別の対象である。「Dが1だった」という記録だけでは、どれも完全には説明できない。

PCEPの文法と運用上の責任範囲

SRポリシーは複数の候補パスを持てる。RFC 9862が導入するSR Policy Association（SRPA）はその集合を表し、配下のLSPが各候補パスに対応する。この設計はPCEPの文法に沿っている。PCEPで状態を通知し、更新し、報告する基本単位がLSPだからだ。

一方、証拠の組み立てはLSP一件では終わらない。SRポリシーに関する情報は候補パスのレベルに載るため、集合としての意味を知るにはSRPAを用いて全メンバーを再構成しなければならない。会話の再確立、経路の追加や削除、テレメトリーの間引きが起きた後では、最後に警告を出したLSPだけが残り、決定時の集合が消えることがある。

色とエンドポイントはポリシーを、originatorとdiscriminatorは候補パスを区別する。一つの候補パスが複数のSRPAに入ることはできず、識別子はPCEPセッション中に安定し、同一ポリシー内の重複も認められない。これらは照合のための良い鍵である。しかし、鍵があることと、時系列付きの照合結果が保存されていることは同じではない。

能力交渉にも限界がある。両端はSRPA利用前に対応を広告し、対応を広告した送信側はSR Policy LSPにAssociationを付ける必要がある。SRPOLICY-CAPABILITY TLVでは、計算優先度、Explicit NULL、invalidation、stateless operationへの対応も分かる。必要な能力なしにSRPAを受け取ればエラーとなり、セッションは閉じられる。これで「同じ語彙を使える」ことは分かるが、「全候補が無効だった」「パケットが破棄された」ことまでは分からない。

同じDでも、設定と運用は別の証拠

INVALIDATION TLVにはConfigとOperの二つのフラグ領域がある。ConfigのDは候補パスでDrop-Upon-Invalidを有効にする設定、OperのDはLSPが現在その結果として通信を破棄している状態を示す。同じ文字を使うため画面設計では混ざりやすいが、前者は意図、後者は状態報告である。

メッセージの方向も重要だ。PCEからPCCへ送るときは設定を指示する。PCCからPCEへ返すときは、現在の設定と実際にdrop stateかどうかを報告する。送信者、方向、時刻、セッションを落として「最新D」だけ保存すると、指示が確認に、希望が結果に化ける。

通常、LSPが無効ならそのLSPは通信を引き寄せなくなり、別のLSPやIGPへ転送される。Drop-Upon-Invalidは意図的に逆を選ぶ。通信を引き寄せたまま、ヘッドエンドで捨てる。予期しない代替経路へ逃がすより遮断した方が安全なサービスでは合理的な選択になり得る。しかし、古い設定や誤った対象範囲なら、復旧可能な障害を意図的な停止へ変えてしまう。RFCが定めるのは相互運用可能な挙動であり、個々のサービスに対する価値判断ではない。

最後の有効パスが消えた瞬間を保存する

RFC 9256では、全候補パスが無効なときSRポリシーが無効になる。これは集合に対する条件である。一つ目の無効化は冗長性を減らし、次の無効化は選択順位を変えるかもしれない。最後の有効パスが無効になった時だけ、ポリシー全体の条件が成立する。

その時点でDを設定した候補パスが一つでもあれば、ポリシーはdrop stateへ入る。Dを持つ候補の中から最もPreferenceが高いものが「有効化」され、PCEには一つの候補パスだけを運用D付きで報告すればよい。効率的な報告である一方、原因の完全な履歴ではない。

たとえば三つの候補パスがあり、古い低PreferenceのパスだけにDが残っていたとする。上位二つが無効になっても最後の一つが生きていれば破棄は始まらない。最後の一つが落ちた瞬間、古い設定によってポリシー全体がdrop stateになる。運用Dが付いた一件からは「今どのLSPが破棄担当か」は分かっても、設定を承認した人、残存理由、全体条件を成立させた最後の変化は分からない。

Preferenceとcomputation priorityも混同してはいけない。候補パスのPreferenceは大きい値を優先し、RFC 9256の既定値は100である。RFC 9862の計算優先度はトポロジー変化後の再計算順を決め、小さい値ほど先で、条件付きの既定値は128である。両方を単に「優先度」として一列に格納すれば、もっともらしい逆向きの説明ができてしまう。

値がないことにも出所がある

RFC 9862には意図された既定動作がある。対応能力があるのに計算優先度TLVがなければ128を使う。Explicit NULLのTLVがなければローカル設定が決める。この設定はSR-MPLS向けでSRv6では無視され、未知の値も無視され、受信した値を運用者のローカル設定が上書きすることもできる。

したがって、空欄を「方針なし」と読んではいけない。既定値の適用、ローカルへの委任、データプレーン上の非適用、上位設定による上書きは異なる。障害分析に必要なのは受信値だけでなく、最終的に有効になった値、その出所、優先順位、解釈したソフトウェアとPCEPセッションである。

RFC 9862は、運用者がSRPAに広告されたポリシーIDと候補パスIDを閲覧できることを必須とし、各ピアの能力や特定ポリシーに関連するLSPを見られることも推奨する。これは良い出発点だ。スコープを越える決定を説明するには、それらを一つの遷移として残す必要がある。

ポリシー単位の破棄レシート

ここで提案するポリシー単位の破棄レシートは、色、エンドポイント、SRPA、双方が見たセッションと能力から始める。決定時に使われた全候補パスを固定し、各originator、discriminator、Preference、設定D、有効性を並べる。

次に時系列を残す。各パスはいつ、どの観測元で無効になったか。最後の有効パスが消えた時刻はいつか。その時にDを持っていた候補はどれか。どの候補が最高Preferenceの破棄担当に選ばれ、どの方向の報告で運用Dが確認されたか。PCEの意図とPCCの報告に差はなかったか。

最後にデータプレーンへ接続する。通信は引き寄せられ続けたか。ヘッドエンドの破棄カウンターは増えたか。最初と最後の破棄はいつか。復旧は候補パスの有効化、設定変更、メンバー変更、ポリシー撤去のどれによるものか。設定の所有者、対象サービス、例外理由、見直し期限、ロールバックも記録する。

これは中央集約の要求ではない。SRPAや関連TLVはポリシー情報を余分に露出し得るため、RFC 9862は同じ管理権限に属するPCE/PCC間で認証・暗号化したTLSセッションを使う勧告を引き継ぐ。レシートもローカルに、アクセス制御の下で、判断を説明する最小限に保つべきだ。

RFCが新たなレシートを要求しているわけでもない。これは、ビットの符号化位置と意思決定の作用範囲を取り違えないための編集上の道具である。

Sources