要約

  • MPLS作業部会の新しいInternet-Draftは、RSVP-TE LSPの入口が各PLRに対し、予備LSPの最適化目標と厳格なメトリック上限を要求できるようにする。要求を満たしたPLRはFRR_EXT protectionを立て、満たせない時はフラグを立てずにローカル方針へ戻ることができる。
  • フラグは有用な最小応答だが、意思決定の来歴ではない。要求の実体、PLRの対応能力、フォールバック理由、方針版、測定時刻、トポロジー世代、計算結果、後日の有効性確認をPLRごとに残す必要がある。

一つだけ戻らない印

四つのPoint of Local Repair（PLR）を通る保護対象LSPを考える。入口は、予備経路について平均遅延を最小化し、経路全体の遅延を一定値以下に抑え、遅延変動が大きいリンクを候補から外すよう求める。Resvが戻ると、三つのPLRには新しい印があり、残る一つにはない。

運用画面がこの差を赤と緑だけで表示すれば、最後のPLRは「保護なし」に見える。しかし仕様案からはそう断定できない。古い実装が拡張オブジェクトを理解せず、互換動作として無視したのかもしれない。対応実装が全制約を満たす経路を発見できず、ローカル方針で別の予備を計算した可能性もある。そもそも入口が拡張条件を明示せず、最初からPLRに委ねたこともあり得る。

いずれの場合も予備経路は存在し得る。違うのは、誰の規則が何を根拠に選んだかである。未設定の一ビットを一つの障害理由へ翻訳すると、その違いは消える。逆に「何か予備があるからよい」と扱えば、入口が示した制約の意味が消える。

必要なのはフラグを長い報告書に変えることではない。プロトコル上の短い応答と、組織内の詳しい証拠記録を分けて設計することだ。

作業部会文書になったばかりの提案

draft-ietf-mpls-frr-ext-00は2026年8月23日付のSignaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnelsである。DatatrackerではMPLS作業部会の現行文書、IESG状態はI-D Existsとされる。本文のヘッダーはStandards Trackを掲げ、有効期限は2027年2月24日だ。RFCでもIESG承認済み文書でもなく、実装・導入の実績を示すものでもない。

前身はdraft-deshmukh-mpls-frr-ext-02である。MPLS議長は8月18日に作業部会採択を記録し、draft-ietf名での再発行を求めた。23日のI-D通知は、00版が作業部会の作業項目になったことを確認している。採択は共同作業の主体を決める段階であり、規格内容の最終確定ではない。

基礎にあるRFC 4090は、RSVP-TE LSPのローカル修復とFAST_REROUTEオブジェクトを定める。そこには優先度、アフィニティ、ホップ上限、帯域などの条件が入る。新しい案は、最適化目標と有界メトリックを運ぶTLV型のFAST_REROUTE_EXTを追加する。

入口は、保護対象LSPと同じ目標・上限を予備に継承させるか、異なる値を与えられる。明示設定がなければ、PLRのローカル方針が目標と上限を決める。入口は意図を示すが、各修復点の計算権限を消すわけではない。

最適化は順位、上限は資格を決める

最適化対象にはIGPメトリック、TEメトリック、未予約帯域、最小・平均・最大遅延がある。コストと遅延は小さい方を、未予約帯域は大きい方を選ぶ。複数の異なる目標を入れることもでき、その場合は正規化用の重みを使う。

有界メトリックは候補の資格を決める。PLRは受信した上限をハード制約として扱い、満たさない経路を除外してから最適なものを選ぶ。上限は経路全体にも個別リンクにも適用できるが、遅延変動しきい値はリンク単位だけである。同じメトリックに経路上限とリンク上限を一つずつ置ける。

同じ種類・同じ範囲の上限TLVが重複すると、最初だけを処理し、それ以降は無視する。この規則は受信処理を決定的にする一方、運用記録には実際に届いた順序を含む要求の正確な指紋が必要だと示している。

どの目標を選ぶか、なぜその数値を境界にするかは仕様案の範囲外である。複数単位の正規化方法も重みだけでは説明されない。共通の形式はできても、数字に権限を与えた業務判断までは共通化されない。

ローカル方針に至る道は同じではない

明示要求がなければ、ローカル方針が最初から正規の決定者である。これはフォールバックではなく委任だ。

PLRがFAST_REROUTE_EXTを理解しない場合、そのオブジェクトを無視し、変更せずに転送しなければならない。混在環境を止めないための互換性であり、ローカル方針が計算を担う。この結果を解釈するには、当時の機能・ソフトウェア版が分かる台帳が要る。

拡張を理解するPLRは、有界メトリックを厳格な条件として処理する。要求を満たせなければ、ローカル方針の目標・上限へ戻ることができ、その場合はResvの対応RROサブオブジェクトにFRR_EXT protectionを立ててはならない。ここでは、中央の要求とローカルの代替判断が両方とも監査対象になる。

一方、対応PLRが基礎のFAST_REROUTEなしで拡張だけを受け取ると、Policy Control FailureでPathを拒否しなければならない。これは互換処理ではなく構造エラーである。

委任、非対応、制約不成立、構造エラーを同じチケットに入れれば、修正先を誤る。方針を見直すのか、アップグレードするのか、データや境界を直すのか、送信側を修正するのかは、それぞれ違う。

フラグが立っていても、将来まで予約したわけではない

PLRが要求された目標と上限を満たした場合、新フラグをRROへ設定する。入口は経路上のPLRを個別に確認できる。単にRSVP予約が成立したことから全PLRの遵守を推定するより、はるかに良い。

ただし、その証明範囲は「その信令時点に、PLRが要求を満たす予備を計算したと報告した」までである。TEデータベースの世代、測定値の鮮度、アルゴリズム版、除外候補、正規化手順はフラグに入らない。負荷やトポロジーが変わっても、フラグは継続的な性能保証にはならない。

これは切替実績でもない。RFC 4090は障害後の転送を速めるため、あらかじめローカル予備を準備する。設定時の成功は、検出器が適切に反応すること、転送状態が残っていること、主系と予備が物理的な共通障害を避けること、障害時に容量があること、利用者の通信が端末間の目標を満たすことを証明しない。

RSVPの暗号認証はメッセージの完全性を守り得る。だが、正しく認証されたメッセージが古い測定値を参照することはある。署名された結果と、説明可能な判断は同義ではない。

メトリックにも採取時刻がある

RFC 7471とRFC 7810は、OSPFとIS-ISで遅延などのTE性能属性を扱う枠組みを示す。PLRはそれらから構成されたTEデータベース、静的値、あるいは別のローカル情報源を使うかもしれない。FRR拡張は全ネットワークに一つの情報源を強制しない。

直近の測定平均と数か月前に設定された設計値は、どちらも同じ数値フィールドに入る。未予約帯域もクラス、予約状態、更新頻度に左右される。複数目標を組み合わせる時は異なる単位を比較可能にする正規化が判断の一部になるが、重みの一バイトだけでは方法全体を再現できない。

「上限は20で、フラグは0だった」だけでは、後日の説明にならない。どの情報源をいつ読み、どのトポロジー世代と計算版で処理し、どの方針が最終的に勝ったかが必要である。

PLRごとの制約来歴記録

Daniel Kadeが提案するのは、保護対象LSPとPLRの組ごとに、制約の来歴を運用側で保存することだ。これはInternet-Draftに付け加える規範ではない。

まず、セッション、入口、PLR、保護資源、マージ点を特定する。受信したFAST_REROUTEとFAST_REROUTE_EXTの指紋、全メトリック、重み、上限、値、経路/リンク範囲を残す。PLRが対応していたか、解析したか、基礎オブジェクトがあったか、どのResv/RROを返したかも記録する。

フラグがない時は、ビットから原因を推測しない。明示要求なし、拡張非対応、ハード制約不成立、その他の確認済み状態を記す。実際に適用したローカル方針と版、例外の承認者、有効期限、見直し条件を付ける。

次に計算の足場を固定する。メトリックの情報源、単位、観測時刻、トポロジーまたはTEデータベース世代、鮮度限界、正規化方法、計算実装版、生成された予備経路を残す。障害ドメイン分離を判断したなら、その時に調べた共有リスク情報を記録し、論理経路の違いを物理的独立性と取り違えない。

信令更新、訓練、実障害は別の証拠層として結び付ける。更新は設定上の主張がいつ新しくなったかを示す。訓練は転送切替を試す。実障害は実際の影響を示す。後の証拠で最初の判断履歴を上書きしてはならない。

この台帳を公開する必要はない。機微なトポロジーを権限内に保ちつつ、ローカルな自由を説明可能にすることが目的である。

共通化するのは最小限でよい

新フラグは、中央要求と各PLRの回答を結ぶ最小共通仕様として価値がある。全修復点へ同じアルゴリズムを強制せずに、要求が満たされたかを同じ位置で読める。

しかし最小仕様は、組織が保存する情報の上限ではない。設定済みフラグは一時点の遵守を表し、未設定フラグは複数のローカル経路を一つに圧縮する。方針の版、データの時刻、判断者、期限、戻り方を残して初めて、分散制御は責任あるものになる。

中央統制かローカル裁量か、という二者択一ではない。不透明な裁量か、追跡可能な裁量かが問われている。可用性のためにフォールバックを許し、その代わり、どの規則がなぜ採用され、いつ再評価されるかを忘れないことが実務上の答えだ。

情報源