要約

  • RFC 9857 では、SR Policy の headend 自身だけでなく、headend の代わりに PCE が BGP-LS Producer となり、candidate path の状態を配布できる。
  • NLRI の Local Node Descriptors はいずれの構成でも headend を示す。Protocol-Origin は candidate を生成した仕組みを示すが、観測時刻や報告経路全体を示すものではない。
  • 安全な自動判断には、受信時刻と producer/session 世代、headend の SRPM 状態、独立した FIB receipt、対象トラフィック、同じ時間窓のサービス測定が必要になる。

受信テーブルの「最新」は、意思決定の「現在」と同じではない

BGP-LS consumer に一つの candidate path が現れたとする。headend、Color、Endpoint、Originator、Discriminator は期待値と一致し、Candidate Path State TLV では評価済み、有効、active と報告されている。Binding SID と SID list も見える。レコードとしては非常に有用である。

しかし、その表示だけでサービス配置を変更するには情報が足りない。足りないのは candidate の定義ではなく、その観測がどの時点に属し、誰が直接知っていたかという接続情報である。

RFC 9857 は、ノード内にある SR Policy 情報を path computation、reoptimization、service placement、network visualization などに利用できるよう、BGP-LS で外部へ公開する。これは RFC 9830 の逆向きの役割を補完する。RFC 9830 は controller から headend へ candidate path を届ける。RFC 9857 は運用状態を headend 側から controller へ戻す。本稿が扱うのは、BGP の受理後に SRPM が何を選ぶかではなく、戻ってきた状態の由来と鮮度である。

記述対象と報告者を同じ欄に入れてはいけない

RFC 9857 の BGP-LS Producer には二つの形がある。第一は SR Policy headend が自ら生成する形。第二は PCE が PCC から PCEP で状態を受け取り、複数の headend を代表して生成する形である。

ここで NLRI の Local Node Descriptors TLV は、どちらの場合も SR Policy の headend を特定する。PCE が producer の場合、PCE 自身の識別子を NLRI の Node Descriptor に入れてはならない。PCE の BGP Router-ID、AS、confederation member は BGP-LS Attribute に含めることができる。また Protocol-Origin には、PCEP 内または PCE producer の場合を区別する値が定義されている。

したがって、NLRI に headend が書かれていることは「その headend がいま直接この報告を送った」という証明ではない。Protocol-Origin も candidate path のインスタンス化主体を表すフィールドであり、完全な producer provenance ではない。RFC 8231 が定義する PCC から PCE への LSP State Report と同期状態が前段に存在し得る。

consumer が保存すべきなのは、対象の identity と報告の identity の両方である。対象は headend と candidate path。報告側は authenticated BGP peer、実際の BGP-LS Producer、direct-headend か PCE proxy か、さらに proxy なら元の PCC/PCEP report である。この二つを一つの「source」に縮めると、規格が与えていない直接性を後から作ってしまう。

状態 bit は強いが、無限の意味を持たない

SR Candidate Path State TLV は priority、preference と複数の flag を持つ。管理 shutdown、active、backup、validity evaluation、valid SID list、PCE delegation、PCE provisioning、transit eligibility、Drop-Upon-Invalid が区別される。E が clear なら V を完了した validity 判定として使えない。

A flag の意味は弱くない。RFC 9256 を参照し、forwarding plane に provision された active candidate path を報告する。単なる controller 内部の優先候補ではない。

一方で、同じ producer が出した protocol claim と、転送装置から独立に得た receipt は別物である。Binding SID TLV は allocation、unavailable、fallback を、Segment List TLV は computation、verification、resolution、algorithm/topology、monitoring による forwarding removal を報告できる。これらは障害理由を詳細にするが、ASIC が exact object を受理した証拠、counter が動いた証拠、アプリケーションが成功した証拠には自動的にならない。

RFC 9857 の価値は、すべてを一つの緑ランプにすることではなく、candidate-level の状態を限定された意味で明示する点にある。

epoch は受信側が構築する

RFC 9857 の candidate path NLRI/TLV には、producer の observation timestamp、単調増加する report generation、SRPM transaction ID、FIB installation acknowledgement が定義されていない。BGP-LS Instance Identifier は routing instance を識別するもので、時間の epoch ではない。

さらに基礎仕様 RFC 9552 では、BGP-LS の配布は policy control の対象であり、情報量を抑えるために speaker が consumer への update 時点を制御できる。よって consumer table に存在する最新 route が、service placement の許容時間内に観測されたとは限らない。

受信時刻、BGP session generation、reset と resynchronization、replacement と withdrawal、action ごとの maximum age を consumer 側で記録する必要がある。PCE producer なら、その前段にある PCC report の時刻と識別も必要である。「current」は table presence ではなく、宣言された時間窓と報告経路の中で定義されなければならない。

五つの receipt を混ぜない

第一は BGP-LS receipt である。candidate identity、flag、attribute、producer、receive epoch を固定する。

第二は headend の SR Policy Manager から得る。同じ candidate identity、evaluation、validity、active selection、BSID、SID list generation が一致するか確認する。

第三は FIB または hardware programming の receipt である。対象装置、install generation、exact BSID と treatment、accept/reject を記録する。RFC 9857 の A は期待を表し、この receipt は別経路でその期待を照合する。

第四は traffic observation である。対象 flow が実際にその treatment を使ったかを、reset provenance と denominator を持つ counter や scoped probe で確認する。

第五は service outcome である。delay、loss、availability、application success を、対象 population と時間窓に対して測る。path metric や active label を結果の代わりにしてはならない。

RFC 8402 と RFC 9857 の security boundary は、SR Policy 情報を trusted SR domain の認可された node/application に限定する。信頼済みであることは発言権を与えるが、直接観測と伝聞、現在と過去の区別を消さない。

registry と errata の範囲

IANA BGP-LS Parameters は NLRI type 5、Protocol-ID 9、RFC 9857 の TLV code point を登録している。Datatracker は標準化の履歴を示す。どちらも vendor support や production deployment の証明ではない。

RFC Editor の errata には verified EID 8709 があり、Section 5.1 の “SR Binding SID sub-TLV” 三か所を “SR Binding SID TLV” に訂正する。これは用語上の editorial correction であり、producer role、state flag、freshness の境界を変更しない。

Heng Lu のRunning-Code Primacy は、publication や registration だけでは operational reality が成立しないという判断基準を示す。RFC 9857 の報告は、その現実を知る重要な入口である。入口を結果と呼ばないことが、規格を正しく使う条件である。

情報源