要約

  • draft-ietf-idr-fsv2-ip-basic-08はUser Order、必須／任意コンポーネント、Dependent Filters Chainを導入するが、判定は各ノードのローカル処理であり、ネットワーク全体の実装確認ではない。
  • 対象ごとに、受信したNLRI、対応能力、検証、実効順序、省略項目、ソフトウェア／ハードウェア表、カウンター、撤去、パケット結果を別々に記録する必要がある。

伝播は一つ、実効ポリシーは複数

コントローラーが緊急フィルターを広告し、route reflectorが全ピアへ運ぶ。BGPセッションは正常で、受信ログも揃う。制御面だけを見れば完了である。

しかし一台目は全条件と全actionを実装し、二台目は必須コンポーネントを扱えず依存グループごと無効にする。三台目は任意コンポーネントを落として残りを実装する。古いノードは新しいaction communityの意味を知らないまま、それを下流へ伝播する。

同じ制御オブジェクトから異なるパケット処理が生まれる。2026年9月28日付のrevision 08自身が、この境界を示している。文書はBGPにaction-reply機能がないと明記する。

UPDATEの到達は配送証明であって、実行証明ではない。

現行Internet-Draftを導入済み仕様と読まない

Datatracker上のrevision 08はIDR WGのActive Internet-Draftで、状態はI-D Existsである。本文はStandards Trackと記すが、メタデータの予定RFC statusは空欄で、AFI/SAFIや型値にはTBDが残る。複数actionの完全な扱いも後続文書へ委ねられている。

したがって、この文書は設計課題と提案を示す一次資料ではあるが、製品対応、運用者導入、相互運用、事故を証明しない。

FSv1の基礎はRFC 8955、RFC 8956、RFC 9117にある。FSv2は別AFI/SAFIを使い、両版がships-in-the-nightとして共存できる。移行中の網には両対応、片方だけ、どちらも非対応のピアが混在する。

プロトコルの航路は分かれていても、各装置上でパケットが通る実効ルール列は一つしかない。

User Orderは命令であって結果ではない

各FSv2 NLRIは32 bitのUser Orderを持ち、小さい値ほど高い優先度になる。既定の並びで意図を表せないとき、運用者は順序を指定できる。

狭いpermitと広いdropは、順番が逆になるだけで結果が変わる。草案はFSv2をFSv1より前へ置き、共通データベースで管理する方法を示す。

だが受信装置は、ローカルルールとの統合、同順位の解決、matchとactionの検証、装置表現への変換、ハードウェア書き込みを行う。BGPは最終的な実効順序をoriginatorへ返さない。広告順と実装順は別のreceiptである。

DFCが共有するのはローカルな失敗

Dependent Filters Chainは部分実装の危険を抑える。草案の例では、よりspecificなSMTP permit＋DSCPルールと、より広いdropルールが依存する。DSCP非対応で前者だけ実装できず、後者だけ残れば正当な通信を落とす。

非zero DFCを共有するルールは、一つがローカルでinvalidなら同じ装置上で全てinvalidになり、実装されない。これは有用なfail-closedである。

しかしdistributed transactionではない。別ノードは同じ群をvalidと判断でき、reflectorはsyntaxだけを確認できる。DFCは全装置の結果を集約せず、originatorへ成功を返さず、他所で実装済みの群をrollbackしない。

ローカルなeligibilityを束ねる値であって、全網commitではない。

任意項目を外したルールは同じルールではない

未対応の必須match componentはルールをinvalidにする。任意なら、そのcomponentを外して残りをvalidとして実装できる。

段階導入には便利だが、match集合を変える。宛先prefixに新しい限定条件を足して対象を絞っても、古い装置でその条件が消えれば、残ったactionはより広いトラフィックに及ぶ。

省略は観測すべきイベントである。何が消え、残余matchが何を覆い、誰がその差を承認したかをreceiptへ残す必要がある。

actionを実装できない場合も、valid／invalidは実装既定値や設定に依存し得る。revision 08はordered actionとvalidityの高度な仕組みを将来課題とする。混在機器に同じ結論を期待してはならない。

意味を知らない装置もbyteを運べる

actionはExtended Communityでフィルターに結び付く。RFC 4360のtransitivityにより、未知のactionでも伝播し得る。古い実装はactionが要求されたこと自体を認識せず、既知のものだけをbest effortで実行する。

BGPオブジェクトの保存とローカル意味の保存は別である。mark、sample、redirectを組み合わせた意図が、一部ノードでは部分集合になる。複数actionの完全解は後続container作業に依存するため、communityの存在をdataplane実装証明にはできない。

valid、eligible、installedを分ける

FSv2はNLRI構造、route property、actionを検証する。既定のfeasibilityは宛先prefixとunicast routeに結び付くが、明示設定で一部を緩和できる。

境界回復不能なmalformed NLRIはsession resetを求め、他の検出可能な誤りはRFC 7606のtreat-as-withdrawを使う。以前validだったNLRIのwithdrawが壊れているとstuck routeが残り得るため、operator notificationも必要とされる。

広告が消えたことはfilterが消えた証拠ではない。RIB、policy store、software classifier、hardware table、packet behaviorまで撤去を観測しなければならない。

高速配布には低速な証明を接続する

RFC 4760のmultiprotocol BGPとroute reflectorは大規模配布に向く。BGPが各装置のhardware programmingを待たないからこそ速い。

草案はNETCONFやRESTCONFで実装報告を求める組み合わせを提案する。RFC 6241とRFC 8040はrequest/responseを提供するが、共通のFSv2 receiptを自動生成しない。応答が示すのは要求受理、datastore更新、software表、hardware commitのどこまでかを定義する必要がある。

有効な運用は二速度である。BGPで範囲と期限を持つ介入を開始し、別ループで各対象の正確なルール、counter、packet outcome、撤去を確認する。

必要なreceipt

仕様版と識別子、発行権限と対象一覧、NLRI・User Order・DFC・flag、全action community、validation入力と緩和、peerごとの時刻、対応能力、未知／未対応／省略項目、DFC判定、FSv1/FSv2実効順序、software／hardware entry identity、counterとsample、expiry、withdrawと実撤去、継続・縮小・rollback判断を一つの証拠鎖にする。

受信は運搬を、validationは規則適合を、表entryはprogrammingを、counterはtraffic encounterを示す。どれも次の段階を代用しない。

running codeを優先するとは、標準を軽視することではなく、特定装置が実際に作った状態で判断することである。

出典