要約

  • RFC 9830 では BGP が SR Policy Candidate Path を生成・伝播するが、実際にその情報を消費し active candidate と data plane を決めるのは SRPM である。
  • Distinguisher は同じ Color／Endpoint の広告を別 NLRI として残すための値であり、規格は意味を持たないと明記している。
  • 受信、BGP best、Route Target import、SRPM validation、active candidate、Binding SID、FIB、実パケットを一つの状態に圧縮してはならない。

best という語の主語を確認する

冒頭の A と B は検証用の場面であり、実在する製品や障害を指していない。二つの結果が同時に正しい理由は単純だ。BGP と SRPM は違う集合を比較している。

BGP は、ある NLRI について到着した BGP path の中から best を選ぶ。RFC 9830 の SR Policy NLRI が BGP table に入ると、その Candidate Path 情報が headend の SR Policy Module に渡される。SRPM は BGP だけでなく、PCEP、NETCONF、CLI、local configuration などから得た candidate も持ち得る。

SRPM はその集合について semantic validation を行い、RFC 9256 の規則と local policy に従って active candidate を選ぶ。さらに Binding SID を関連付け、選ばれた segment list を forwarding plane に導入する。RFC 9830 は、BGP 自体は SR Policy Candidate Path を data plane に install しないと明言する。

したがって、BGP best は SRPM の投票所へ届く資格であり、最終当選ではない。監視画面が両方を “best” と呼ぶなら、少なくとも bgp_best_for_nlri と srpm_active_for_policy に分ける必要がある。主語を失った緑色は証拠ではない。

Distinguisher は順番でも世代でもない

NLRI は Distinguisher、Color、Endpoint から成る。Color と Endpoint は SR Policy を識別する。Distinguisher は、同じ policy に複数の candidate を広告するとき、または同じ Color／Endpoint を異なる headend 向けに運ぶときに NLRI を区別する。

ここで規格は「semantic value を持たない」と釘を刺す。数値の大小は Preference ではない。連続性は revision を意味しない。一致は同じ計算結果を保証しない。Distinguisher は BGP が別の箱として扱うための札であり、箱の中身を評価しない。

この札を業務上の識別子に流用すると、後から意味が逆流する。運用者が 100 を「本番」、200 を「予備」と決めても、その意味は local convention であり RFC の性質ではない。広告を受け取る別組織や将来の装置が同じ解釈を共有する証拠にはならない。

identity は階層で保存すべきだ。Color／Endpoint が policy、Distinguisher が BGP NLRI、Protocol-Origin／Discriminator が candidate、originator 情報が protocol source、change approval が human authority を表す。symbolic name は表示補助にすぎず、長い名前は signalling 時に truncate され得る。

BGP は構造を裁き、SRPM は実行可能性を裁く

役割分担は validation にも現れる。RFC 9830 は SAFI 73、対応 AFI、NLRI length、Tunnel Encapsulation Attribute、Tunnel Type 15、TLV の個数と配置を定める。利用不能な構造は treat-as-withdraw によってその route だけを撤回扱いにできる。

この error handling は重要だ。壊れた update 一件のために session 全体を失う必要がない。一方、構造を通過したことは segment の正しさを意味しない。

個々の SR Policy field の semantic verification は SRPM が担当する。BGP implementation はその意味を検査して update を無効扱いしてはならない。SID verification、segment type の整合、Binding SID の利用可能性、SRv6 behavior などは headend 側の判断である。

したがって reason code は層を含まなければならない。BGP malformed、treat-as-withdraw、unknown field ignored、Route Target not imported、SRPM invalid、eligible but inactive、active but FIB missing は別事件である。単一の invalid カウンターは原因を消す。

拡張性のための ignore も記録差を生む。reserved bit は受信時に無視される。適用が定義されていない sub-TLV は無視され、伝播中に除去されることがある。single-instance field が複数ある場合、最初だけを使用する規則もある。originator、reflector、headend が見た byte set を同一と仮定してはならない。

Preference は BGP path selection に参加しない

SR Policy の Preference sub-TLV は SRPM が candidate を選ぶ材料である。BGP best-path algorithm の入力ではない。異なる Distinguisher を持つ二つの NLRI がとも BGP table に残り、それぞれの candidate が SRPM で Preference を比較されることもある。

Priority は別の軸だ。topology change 後に複数 policy を再計算する順番を示す。candidate の優先順位ではない。Segment List の Weight は active candidate 内の有効な複数 list に traffic を配るための値である。

三つを「優先度」という一列に入れると、変更の意味が失われる。Preference の変更は active candidate を変え得る。Priority の変更は convergence の順番を変え得る。Weight の変更は path identity を変えずに traffic share を変え得る。

Binding SID にも local authority が残る。originator が値と flag を伝えても、headend は data-plane type と local resource に照らして verify、allocate、accept、reject を行う。SRv6 Endpoint Behavior が opaque なら、その選択は headend に委ねられる。

TC と TTL は originator が推奨できるが、receiver が local policy で override できる。ENLP がなければ Explicit NULL の扱いは local configuration で決まり、広告された場合にも deployment requirement に基づく override が許される。標準化された proposal は、命令書ではない。

Route Target は届け先の候補を作る

controller と headend の direct session なら配送経路は短い。しかし多数の headend を扱う場合、route reflector や一つの trusted SR domain 内の複数 AS を通して広告することがある。Route Target は、その広告を意図した headend を示す。

Route Target import は audience gate である。通過すれば SRPM に提示される可能性が生まれるだけで、semantic eligibility も active selection も保証しない。受信 neighbor、RT import、SRPM input は三つの別 receipt である。

この audience gate は confidentiality control でもある。SR Policy 広告は endpoint、node address、SID、経路設計を露出し得る。これらは mission-critical または commercially sensitive である可能性がある。BGP session が設定済みだからといって、全 peer に SAFI 73 を開く権限が生まれるわけではない。

承認記録には trusted domain、peer role、AFI/SAFI、Route Target、export policy を含めるべきだ。route reflection を使う場合は、直接 neighbor と元の originator を両方残す。隣の reflector は配達者であって、candidate の目的を決めた主体ではない。

withdraw が消すのは一つの source である

BGP withdraw を受けると、SRPM へ供給される一つの contribution が消える。しかし別 Distinguisher の BGP candidate、PCEP candidate、local candidate、backup candidate が残る場合がある。active policy が変わらないことも、別 candidate に切り替わることも、完全に invalid になることもある。

逆に新しい BGP best が届いても、forwarding が変わるとは限らない。Preference で敗れる、segment verification に失敗する、BSID を確保できない、local rule に拒否される、といった結果がある。UPDATE rate は forwarding change rate ではない。

再現可能な ledger は raw UPDATE と hash、BGP structural result、NLRI best、RT import、originator derivation、SRPM validation、candidate-set snapshot、active decision、Binding SID、segment list と weight、RIB/FIB readback、packet observation を順に結ぶ。各段階に timestamp、device、software version、reason を付ける。

この連鎖を保存しなければ、withdraw 後も traffic が残った理由を説明できない。より深刻なのは、自動化が controller の送信成功だけで change ticket を閉じ、実行側の receipt を最初から採取しないことである。

標準の節度が headend の責任を守る

RFC 9830 は小さな仕様ではない。SAFI、NLRI、Tunnel Encapsulation Attribute、多数の sub-TLV、propagation、error handling を共通化する。しかし共通化の対象を candidate の配送に留め、active selection と installation を headend に残した。

Heng Lu の Minimum Initial Specification は、この境界を制度として読む手掛かりになる。共通仕様は interoperability に必要な最小の不変部分を定める。local decision は、その結果を負う operator の近くに置く。Running-Code Primacy は、RFC や BGP table ではなく実際の SRPM と FIB に最終確認を求める。Reality Layers は proposal、decision、execution、outcome を分離する。

試験では、同じ Color／Endpoint に異なる Distinguisher の BGP candidate を二つ入れ、さらに高 Preference の PCEP candidate を加える。それぞれの BGP best、SRPM input、active candidate、BSID、FIB、packet counter を観測し、source を一つずつ withdraw する。この過程を一つの「policy status」でしか表せないなら、運用システムは RFC が守った二重選択を消している。

出典