Summary

  • RFC 9933は、SIDに対応するSR-Algorithmや計算上の制約をPCEPで表現する。128〜255のFlexible Algorithmでは、番号から勝者となるFlexible Algorithm Definitionを解決し、そのメトリック、制約、参加ノード、リンク属性を使わなければならない。したがって、番号の一致だけではポリシーの継続性を証明できない。
  • 監査に必要なのは巨大なネットワーク情報を公開することではない。番号を、その時点の勝者FAD、選出根拠、スコープ、ローカルなメトリック辞書、目的関数、無視された制約、枝刈り規則、TEDのダイジェスト、変更承認に結びつける「ポリシー解決レシート」である。

運用記録には、短い値ほど長く残るものがある。SR-Algorithm 130もその一つになり得る。サービス台帳、障害チケット、経路レポートのどれを見ても130と書かれている。担当者は、同じ番号である以上、同じポリシーが続いていたと考える。

ところが、ある時点で優先度の高いFAD広告が現れていたらどうだろう。新しい定義は遅延ではなくローカルな費用メトリックを使い、逆方向の属性を除外し、未対応のノードを参加対象から外していた。それでも、要求に現れる番号は130のままでよい。

番号は正しい。そこから導かれた「ポリシーは不変だった」という結論が正しくない。

RFC 9933は、Segment Routingで使われるアルゴリズムをPCEPの経路表現と制約に載せるための標準である。機能ネゴシエーション、エラー、計算手順、運用可視性を丁寧に定めている。一方、Flexible Algorithmの実体は、要求メッセージの外で学習・選択される定義とネットワーク状態に依存する。

これは欠陥ではなく分業である。プロトコルは意図を効率よく運ぶ。組織は、その意図がどの規則へ解決されたかを後から説明できるようにする。両者を一つの証拠だと思い込むと、安定した識別子が政策変更を覆い隠す。

RFC 9933が保証する範囲

RFC 9933は2026年7月にIETF Standards Trackとして公開され、SR-MPLSとSRv6のPCEP拡張を更新した。SR-ERO、SR-RROおよびSRv6版のサブオブジェクトにAlgorithmフィールドを追加し、LSPAオブジェクト内のSR-Algorithm TLVによって特定アルゴリズムを制約として要求できるようにする。最小遅延、帯域幅、ユーザー定義メトリックのPCEP表現も加わった。

拡張は、双方が対応能力を広告した場合にだけ利用できる。未広告の能力を使おうとすればInvalid Operationとなり、形式が不正ならオブジェクト全体が無効になる。SIDを解決できない場合にも定義済みのエラーがある。制約の組み合わせを満たす経路がなければ、空のEROまたはNO-PATHを返す必要がある。

つまり、相手が機能を理解していること、メッセージが妥当であること、失敗を成功に見せないことについて強い証拠が残る。しかし、その時点でアルゴリズム番号に結びついていた運用ポリシーの履歴までは含まれない。

値0と1はIANAでSPFとStrict-SPFとして定義されている。2〜127は標準化用の範囲であり、128〜255はFlexible Algorithmsである。後者は、運用者が設定した定義との対応によって初めて意味を得る。

「SR-Algorithm: 130」という表示は、宛先を示す索引として十分でも、内容証明としては足りない。索引が同じでも、参照先の版は変わる。

勝者FADを選ぶ処理はポリシー解決そのもの

RFC 9350では、計算タイプ、メトリックタイプ、制約集合をFlexible Algorithm Definition、FADと呼ぶ。128〜255の番号は設定によってその組に関連付けられる。

同じ番号について複数の広告が存在する場合、参加する各ルーターは同じ順序でFADを選ぶ。まず数値上もっとも高いPriorityを選び、同点ならIS-ISのSystem-IDまたはOSPFのRouter IDが数値上もっとも大きい広告を選ぶ。これがwinning FAD、すなわち勝者FADである。

分散したノードが同じ定義を使うためには不可欠な仕組みだ。しかし監査の観点では、番号の意味が候補広告、優先度、広告元、タイブレークに依存することを示す。130を変更しなくても、より高い優先度の広告一つで勝者は入れ替わる。

さらに、FADを広告するルーター自身がそのアルゴリズムへ参加している必要はない。受信側は、非参加ノードからの広告も選択対象にする。定義する権限と転送する役割は分離できる。中央でのポリシー管理には有用だが、誰が広告し、誰が優先度を上げ、誰が変更を承認するのかは別途管理しなければならない。

選ばれた定義に対応できないノードは、参加をやめ、関連する転送状態を削除する。FAD変更はネットワーク全体の再計算と再収束を引き起こす場合がある。RFC 9350は変更後の一貫性を守るが、変更を正当化した人間の判断を保存するものではない。

現在の勝者を見られることと、過去の勝者を証明できることは異なる。後者には、当時の候補、選出根拠、有効期間、緊急変更の期限が要る。

数値の意味にはエリアが含まれる

FADの選択スコープはエリアである。RFC 9350は、同じFlexible Algorithmについて全エリアが同じFADを持つ必要はないと明記する。あるエリアでは遅延を最小化し、別のエリアでは帯域幅を重視することもできる。

この柔軟性は、現場の要件を一つの全社ポリシーへ無理に押し込めないために役立つ。同時に、「130」をグローバルな一語として扱う監視画面を危険にする。

同じ条文番号でも法域が違えば意味が違う。同じ金額でも通貨がなければ比較できない。同様に、Flexible Algorithmの値には、エリア、IS-ISレベルまたはOSPFスコープ、ポリシーの有効時期が必要である。

RFC 9933は、一つのエンドツーエンド計算の部分ごとに異なるSR-Algorithm制約を使うことや、同じ番号で異なる勝者FADのメトリックや制約を使うことを対象外としている。境界をまたぐ運用では、各スコープの解決結果を別々に残すべきだ。一本の線と一つの番号へ潰してはいけない。

ローカルな違いをなくす必要はない。必要なのは、その違いを普遍的な同一性として報告しないことである。

要求メッセージだけを再送しても再現にはならない

Flexible Algorithmの場合、RFC 9933はPCEがTraffic Engineering Databaseを使って計算すると定める。TEDには、FAD、ノード参加情報、アプリケーション固有のリンク属性が必要であり、IGP拡張やRFC 9552のBGP-LSなどを通じて得られる。

計算結果は要求とTEDの両方から生まれる。要求を保存しても、判断材料の半分しか保存していない。

最適化メトリックの扱いはさらに明確だ。Flexible AlgorithmではFADに記載されたメトリックタイプを使わなければならず、PCCがPCEPメッセージへ入れた最適化メトリックは無視される。PCEはFADの制約とPCCから直接届いた制約を組み合わせるが、PCCはFAD自身の制約を要求へ重ねてはならない。

これは重複と不整合を避ける適切な設計である。その反面、古い要求を新しい環境で再実行しても、当時の判断を再生したことにはならない。勝者FAD、リンク属性、参加ノード、評価規則が変われば、別の経路を返す方が正しい場合もある。

通信として完全な記録と、意思決定として完全な記録は異なる。後者には、要求が参照した外部状態の版が必要だ。

ローカルメトリックは組織の判断を数値化する

RFC 9843は、帯域幅と遅延の制約、帯域幅メトリックの自動計算、汎用メトリックをFlexible Algorithmへ追加する。メトリックタイプ128〜255は、運用者がローカル用途に割り当てられる。

標準化されていない意味を扱える点は重要である。金銭コスト、ジッター、電力条件、契約上のリスクなどをネットワークごとに表現できる。しかし「user-defined metric 130」だけでは単位も式も分からない。RFC 9843も、エリアやレベルをまたいで使うなら同じタイプに同じ意味を割り当てるべきだとしている。

標準の帯域幅メトリックでも、値の作り方にはポリシーがある。リンクが明示的に値を広告していれば、自動導出より優先される。明示値がなければ、勝者FADにある基準帯域幅や閾値から計算できる。基準値を中央で変更すれば、アルゴリズム番号を維持したまま、多数のリンクコストを変えられる。

何を測るかは資源配分の選択である。遅延を優先するのか、容量を残すのか、支出を抑えるのか。その選択は、トラフィックと障害時の余裕をどこへ置くかを決める。

監査記録には、ローカルメトリックの所有者、単位、正規化方法、版、適用範囲が必要だ。自動導出なら、方式、閾値、基準値、入力データの優先順位も要る。数値だけを再現しても、その数値が表した価値判断までは再現できない。

枝刈り規則にも時点がある

経路計算では、メトリックで順位付けする前に、条件に合わないリンクを候補から取り除く。RFC 9917は、IANAに「IGP Flex-Algorithm Path Computation Rules」という順序付きレジストリを設けた。

IANAのIGP Parametersには現在、除外Admin Group、SRLG、include-any、include-all、メトリック欠落、帯域幅・遅延の条件、逆方向のAdmin Groupを扱う十個の規則が並ぶ。Expert Reviewで追加でき、上限数は決められていない。

つまり、評価器の文脈も将来変わる。古いPCEと新しいPCEが同じFADを見ても、対応する制約や規則が異なる可能性がある。RFC 9933は未対応の組み合わせで計算を失敗させるため、静かに条件を落とす危険を抑えている。それでも、NO-PATHだけでは、どの規則がどのリンクを取り除いたかは説明できない。

自動判断の監査では、入力と出力だけを残し、評価器を忘れがちだ。必要なのは、事実、ポリシー、評価器の三点セットである。実装版と規則集合がなければ、再現テストは別の判断機に同じ資料を渡しているにすぎない。

目的関数とアルゴリズムは別の層にある

RFC 5541は、PCEPで目的関数を指定する方法を定める。PCCは必須として要求することも、希望として示すこともできる。希望にとどまる場合、PCEはローカル能力やポリシーに基づいて別の関数を選べる。

RFC 9933は、SR-Algorithmが目的関数を置き換えるものではないと明記する。メトリックタイプもまた別である。番号だけの画面は、FADが候補範囲をどう作り、どのメトリックがリンクへ値を与え、どの目的関数が候補から最善を選んだかを区別できない。

RFC 9753は、stateful PCEPで一部オブジェクトをオプション扱いできる手順を追加する。双方が対応していれば、PCEはオブジェクトを無視でき、その事実を伝える。すべての条件を満たした経路と、オプション制約を外して得た経路は同じ説明責任を持たない。各オブジェクトの処理結果を保存すべきである。

RFC 9826のYANGモデルは、PCEPエンティティ、ピア、セッション、通知、統計を管理可能にする。RFC 9933も機能、FAD、参加ノードを運用者が閲覧できるよう勧告する。見えることは記録の前提だが、履歴を残すことそのものではない。

TLSは意味の版を固定しない

RFC 9933はPCEPセッションをTLSで保護することを推奨し、RFC 9916は現代的なTLS利用へPCEPSを更新する。メッセージ改ざんやピアのなりすましを防ぐために欠かせない。

しかし、認証済みの正規ピアは、変更直後の正規FADに対して要求を実行できる。TLSが証明するのは送信者と通信中の完全性であり、FAD変更の承認者、緊急設定の期限、ローカルメトリックの意味ではない。

安全な封筒は中身を守るが、受取人がどの規則で判断したかを記録しない。暗号学的な完全性とポリシーの来歴は、互いに代替できない証拠である。

ポリシー解決レシートの最小構成

PCEPメッセージへ全トポロジーや承認書を詰め込む必要はない。ネットワーク構造、費用、リスクグループは機密性が高い。プロトコルの効率も守るべきだ。別の証拠層で、公開可能なコミットメントと保護された原資料を結びつければよい。

レシートには、要求ID、PCE/PCCの識別、時刻、スコープ、SR-Algorithm値とその出現位置、正規化した勝者FADとダイジェスト、広告元・優先度・タイブレーク、メトリック辞書または導出パラメータ、目的関数と必須性、直接制約と無視されたオブジェクト、順序付き枝刈り規則と実装版、TED・参加集合・能力除外のダイジェスト、EROまたはNO-PATHと理由、変更チケット・承認役割・有効期間・ロールバック条件を残す。

一般向け、あるいは部門間の記録はハッシュ、版、理由分類、保管責任だけでもよい。権限を持つ監査者が保護された証拠と照合する。レビュー可能性は、無制限な公開と同義ではない。

さらに、レシートがポリシーとトポロジーを別々に版管理すれば、障害による経路変更と、人間のルール変更による経路変更を区別できる。ネットワークの自然現象に見えるものが、実は統治上の選択だったという誤認を防げる。

Sources