PCEPのS-BFD停止指示は、ルーターの状態をまだ決めきれない

要約

PCE作業部会の草案第03版は、PCEPのOPENでS-BFD設定能力を交渉し、LSPごとの要求をLSPAで運ぶ方式を提案する。PCEが初期化・更新を送り、PCCが状態を報告する。
有効化のB=1にはリモート・ディスクリミネーターが必要だ。停止のB=0ではパラメータの扱いが節によって異なり、TLVの不在を削除指示にする案も編集者注に残る。

中央の命令と、現場の機械

Path Computation Element（PCE）は経路を計算し、その経路についてPath Computation Client（PCC）とPCEPでやり取りする。今回の草案は、ラベルスイッチドパス（LSP）に付けるSeamless Bidirectional Forwarding Detection（S-BFD）の設定も、この会話に載せようとする。計算する側に設定要求を集める発想は分かりやすい。しかしS-BFDを動かす機械はPCC側にある。PCEの送信記録だけで「検知が始まった」と書けば、制御境界を一つ飛び越える。

まず会話の資格を決める。草案の第4.1節は、セッション確立時のOPENオブジェクトにLSP-S-BFD-Capability TLVを入れる。そこでB=1を受け取れば、相手は新しいS-BFDのTLVを送受信できる。能力TLVがない、またはOPEN側のB=0なら、その相手に向けてLSPA内のS-BFD TLVを送ってはならない。能力で列挙するPath Setup Typeも、PCEPセッションがサポートする一覧の中に収まる必要がある。外れた型を載せれば、エラー種別21・値2のPCErrを返してセッションを閉じる。双方で共通のS-BFD対象型がなければ、PCEPによる新しいLSPのS-BFD設定はできない。

ここで閉じるのは遠隔設定の入口だ。草案はPCCがローカルな方針でS-BFDを設定する余地を残す。OPENで能力が一致しても、その時点で個々のLSPに検知器が付くわけではない。逆にPCEPで共通の対象型がなければ、装置のローカルな判断まで消えるわけでもない。「対応あり」という一つの欄に両方を入れると、管理表は短くなり、障害調査は長くなる。

LSP単位の要求は別のTLVを使う。PCEはPCInitまたはPCUpdでLSP-S-BFD TLVを送り、PCCはPCRptで報告する。どれもLSPAに載る。OPENのBは相手との会話が可能かを示し、LSPのBはその経路にS-BFDを適用するかを示す。同じ一文字でも、置かれた場所で責任の範囲が変わる。送信した更新、PCCが返した報告、装置に残る設定、実際のS-BFDセッションは、同じ画面に並べても別々の列でなければならない。

有効化には値が要る。停止には文章の決着が要る

LSP側のB=1はS-BFD適用の指示だ。この場合、草案はリモート・ディスクリミネーターのサブTLVを必須とし、欠ければエラーを提案する。任意のパラメータ用サブTLVには最小送信間隔と1から255の乗数が入る。ボタンが「オン」でも、相手を識別する必須値が空なら要求は揃っていない。何を送ったかを記録する際、Bだけを抜き出しては検査に必要な中身を捨てることになる。

B=0の基本線は第4.3.2.1節にある。PCEからの更新ではS-BFDを取り外し、PCEが新規に始めるLSPには適用しない。第4.2節は、そもそもS-BFDが付いていないLSPにPCCがB=0のPCUpdを受けた場合、TLVを無視すると書く。PCCが始めたLSPについてPCEが同じ状態を受けた場合も、無視してよい。存在しない設定を削除できないのは当然だ。だが操作の記録では「停止を送った」と「動いていた検知器を取り外した」を同じ完了印にしてはいけない。

問題はB=0にパラメータが付いている場合だ。第4.2節は、そのサブTLVを無視してもよいとし、無視するか設定を保存するかは実装の決定だと述べる。第4.3.2.2節では無視しなければならないに変わる。動詞が揃っていない上に、編集者注はさらに別の手を提示する。LSP-S-BFD TLVが届かなかったこと自体を、既存のS-BFDを取り外す合図にする案だ。これは採用済みの規則ではなく編集上の代案である。明示的なB=0とTLVの不在は、回線上では違う出来事だ。無言を命令に変えるなら、その境界を草案が決める必要がある。

エラーを返す道筋もある。能力を交渉していない相手からS-BFD TLVを受けた話者は、内容を無視してエラー種別19のPCErrを返す。乗数が範囲外なら種別23を返す。新しいエラー値とTLVの番号は、草案のIANA節ではまだTBDだ。何が拒否されたかを分類することはできる。割り当て前の番号を実際のレジストリー値として掲げることはできない。

第6節の関連付けグループにも、中央とローカルの食い違いが見える。一部の実装では、同じグループのLSPが同じS-BFDパラメータを持たなければならない。送信間隔、乗数、リモート・ディスクリミネーターが異なる場合、話者は種別26の関連付けエラーを返すべきだとする。「一部の実装」を落として全装置共通の義務にすれば、PCEは存在しない標準上の制約を勝手に売り込むことになる。逆に制約のあるPCCが拒否した時には、能力交渉の失敗と装置固有の制約を区別できる報告が必要だ。

RFC 7880はS-BFD自体の動作を定める。RFC 8231とRFC 8281は状態を持つPCEPとPCE起点のLSPに背景を与え、草案はRFC 9050の中央制御アーキテクチャにも触れる。これらは新しいTLVの動作試験ではない。第02版と第03版を比べると、実質的な制御規則はそのままで日付と有効期限などが更新された。版数が一つ進んでも、「オフ」の二つの動詞は残った。

実装を確かめるなら、一つのLSPについて順番に記録を集める。OPENの能力、共通のPath Setup Type、PCEのPCInitかPCUpd、PCCのPCRpt、有効なローカル設定、S-BFDセッションの状態だ。最初の二つは会話の条件を示す。次は要求と報告を示す。最後の二つが機械の実行を示す。経路が本当に健全だったかは、さらに別の観測が要る。中央のボタンに全ての意味を押し込むほど、後の障害説明から主語が消える。

今回の公式資料には、この新しい拡張を使った特定のPCCについて、B=0またはB=1と報告・実効設定・セッションを結ぶ相互接続試験がない。その一続きのトレースが出れば、その実装で何が起きたかを判断できる。草案の次の仕事も明確だ。停止時のパラメータを無視できるのか、必ず無視するのか。TLVを省くことは命令なのか、単に何も送っていないだけなのか。