要約

  • revision 13 は、ポリシーが選んだデータプレーンの forwarding database で next hop を解決し、同じプレーンの OAM 結果を候補資格に使えるよう提案する。
  • 一部の speaker だけが新しい条件を適用すると、同じ update を受けても候補集合、best path、外部への広告が異なる。
  • 導入前には shadow 判定、経路ごとの差分、ポリシーの同一性、回復時の再評価を記録し、ローカル判断がどこまで伝播するか検証しなければならない。

二台の PE は同じ二本の VPNv4 path を受け取っていた。属性も next hop も同じだった。PE-A は新しい data-plane check を有効にし、MPLS OAM の negative を理由に一方を候補から外した。PE-B は従来の RFC 4271 の解決だけを使い、その path を best とした。両者はそれぞれ自分の判断を CE へ広告した。

同じ control-plane input から、二つのネットワーク現実が生まれた。

draft-ietf-idr-bgp-bestpath-selection-criteria-13 は、この種の判断を標準化しようとする現行 Internet-Draft である。2026 年 9 月 14 日付の IDR Working Group 文書で、Proposed Standard を意図し、承認されれば RFC 4271 を更新する。まだ RFC ではない。Datatracker は専門 review の課題解決と改訂が必要な状態を示す。Routing review は Not ready、Operations と Security は Has issues、BGP review は On the right track だが進行には未成熟とする。

動機は明快だ。RFC 4271 の Route Resolvability Condition は best-path candidate になる前の入口を定める。しかし IP RIB に next hop があっても、実際に packet を運ぶ MPLS LSP が壊れていれば traffic は blackhole になる。revision 13 は、ポリシーが選ぶ特定 data plane の forwarding database で next-hop reachability を確認すべきだとし、さらに同じ plane の OAM による path availability check を任意で追加する。

問題は、二つの条件がいずれも局所的で任意性を含むことだ。第一条件は SHOULD、第二条件は MAY であり、plane の選択、OAM mechanism、失敗時の扱いは scope 外に置かれる。partial deployment では、speaker ごとに「解決可能」の意味が違っても不思議ではない。

候補集合の差は update に書かれない

BGP update は path attributes を運ぶが、受信側がどの forwarding table を見たか、どの OAM session を信頼したかまでは通常伝えない。一台が path を除外し、別の一台が残しても、その理由は隣接 speaker に見えない。外から観測できるのは best path や withdraw の違いだけである。

revision 13 は plane-selection policy を per-neighbor、per-SAFI、または両方に置く想定を示す。すると一台の中でも同じ next hop が、ある SAFI では eligible、別の SAFI では ineligible になり得る。設定の一行が candidate set の意味を変える。

段階導入で最初に比較すべきなのは「新機能が動くか」ではない。従来判定と新判定が、どの prefix、path、peer、AFI/SAFI、VRF で分岐するかである。差分には、選んだ data plane、table、policy version、forwarding generation、OAM method、result age、exclusion reason を付ける必要がある。

これらは revision 13 に列挙された管理要件ではない。現在の review が指摘する observability と migration の空白を埋めるための運用上の証拠である。差分を保存しなければ、導入後の route change が意図した保護なのか、implementation 解釈の差なのか判別できない。

部分導入は失敗時だけでなく回復時にも分岐する

PE-A が negative OAM を受け、path を外したとする。その後 LSP が回復しても、どの event が再評価を起動するかが曖昧なら、PE-A は古い候補集合を維持し得る。PE-B は最初から path を保持している。障害が消えた後にも二台の経路選択は揃わない。

Routing review は、check state の変更時に RFC 4271 decision process を再実行することを明記すべきだと指摘する。また、OAM が startup 時に未収束の場合、route を resolvable とするか否かも未定義だとする。導入のタイミング自体が経路意味を左右する。

三値状態が必要になる。positive は限定された証拠がある。negative は定義された失敗を観測した。indeterminate は未初期化、期限切れ、mechanism unavailable、table mismatch、または証拠矛盾を表す。indeterminate を negative と同一視すれば、新機能を先に起動した speaker ほど多くの route を捨てる可能性がある。

回復も明示的な transaction として扱うべきだ。policy を戻す、cache を無効化する、affected route を再評価する、best-path change を確認する、advertisement を確認する、traffic outcome を測る。この順序のどこかが欠ければ、feature flag は off でも判断の残骸が残る。

ローカルな probe は広域の routing event になり得る

一つの next hop に多数の route が依存する。OAM session が down へ変われば、それらが一斉に candidate から外れ、best path が変わり、withdraw や replacement が CE、場合によってはさらに先へ伝わる。session が flapping すれば control plane も揺れる。

Security review は、probe を drop、delay、spoof できる者がこの効果を利用できるとする。dual-homed case では一方の next hop だけを妨害し、traffic をもう一方へ steer することも可能になる。逆に spoofed positive は壊れた path を残す。RFC 5880 の BFD と RFC 8029 の LSP Ping は、false up/down、spoofing、replay、tampering といった固有の危険を扱う。revision 13 自体は mechanism を指定しない。

認証は必要な場合があるが、十分ではない。on-path actor は正しい probe を落とせる。probe だけ通して production data を落とすこともできる。success は next-hop liveness の bounded receipt であり、全 ECMP member、remote VRF、customer prefix、application transaction の成功証明ではない。

shadow mode は互換性試験である

安全な rollout では、まず新条件を計算するが route selection には適用しない。各 speaker は従来 candidate set と proposed candidate set を並べて出力する。運用者は同等 role の装置間で差を比較し、table selection、policy、OAM freshness、software behavior のどこから差が生じたか分類する。

次に少数の prefix または next hop に限定して enforcement する。radius は route count だけでなく、CE、VRF、customer service、backup path の有無で測る。正常時、MPLS failure、OAM-only failure、startup、recovery、policy rollback を試す。各段階で external advertisement と application result を確認する。

revision 13 の本文は、convergence への negative impact は implementation specifics を除けば想定しないとする。reviewers は、この主張を支える根拠がないと批判する。partial deployment はまさに implementation difference が network behavior へ変わる場所である。

この提案の価値は、IP reachability だけで実データプレーンを代表させない点にある。しかし、新 check を導入した speaker だけが別の現実を持つなら、保護は新たな不整合を生む。standard の役割は全装置を同じタイミングで変えることではない。違いが生じたとき、その理由、範囲、伝播、回復を誰でも検証できるようにすることだ。

出典