要約

  • IETFは2026年9月5日、Traffic Steering using BGP FlowSpec with SR Policy 第18版を公開した。調査時点の状態は AD Evaluation::External Party であり、承認済みRFCではない。
  • 第17版は、Redirect-to-IPの宛先がありながら有効なColorがない指示を通常のIPリダイレクトへ戻していた。第18版は明示的なSR意図が不完全な場合、そのフォールバックを禁じ、廃棄またはローカル障害方針を求める。
  • SR PolicyがDown、解決不能、またはFIB/TCAMへ入らない場合でも、有効なFlowSpecルートはLoc-RIBに保持され、下流へ広告される。制御面の受領はパケット処理の証明にならない。
  • 現行草案は同時に、非対応ヘッドエンドがPrefix-SIDを無視し、通常のRedirect-to-IPへ戻ることを説明する。混在環境では、一つの更新が一方で廃棄、他方で転送になり得る。
  • 以前のWorking Group Last Callは第13版に対するものだった。第17版の後、Area DirectorはIDR議長に再度の合意確認を求めた。次の判断は対象版と障害時の分岐を明示しなければならない。

「足りない」の扱いが反転した

FlowSpecは、パケットを選ぶ条件と、そのパケットに行う動作をBGPで配る。今回の草案はRedirect-to-IPの宛先とColor Extended Communityを組み合わせ、SR Policyを選ぶ (Endpoint, Color) として扱う。SRv6向けの第二モードでは、BGP Prefix-SID属性に出口サービスSIDを載せ、終端で特定のテーブル検索やクロスコネクトを実行できる。

ここでは似た三つの状態を分ける必要がある。SR固有の属性を伴わないRedirect-to-IPは従来のIPリダイレクトである。宛先と有効なColorがそろえばSR Policy steeringになる。宛先とPrefix-SIDがあるのにColorが有効でなければ、SRを使おうとした痕跡はあるが、どのpolicyかを決められない。

第17版は最後の状態を通常のRedirect-to-IPへ戻し、Prefix-SIDを無視するよう求めていた。第18版は逆である。対応headendはデフォルトやnull-colorのpolicyを探してはならず、サービス属性も利用できず、通常のリダイレクトへ読み替えることもできない。該当トラフィックは廃棄するか、事前に定めたローカル障害方針で処理する。

したがって「Colorがなければすべて廃棄」という変更ではない。純粋なRedirect-to-IPはそのまま残る。止められたのは、不完全なSR命令を別の命令へ静かに変換する行為だ。経路制約を破って到達させるより、明示的な失敗を選ぶ設計であり、運用者にとっては別種類の損失になる。

RIBの成功とパケットの成功を分ける

第18版では、対応するSR PolicyがDownでも、解決できなくても、転送面へ設定できなくても、BGPとして有効なFlowSpecルートをLoc-RIBから消さない。通常の経路選択と広告を続ける。下位のtransportやpolicyの障害だけを理由に、命令そのものを無効化しないためである。

一方、SR steeringのFIB/TCAMエントリーは未設定またはInactiveでなければならない。policyが動いていても、出口サービスSIDがローカルのRIB/FIBで到達不能なら、最短IP経路への暗黙フォールバックは禁止される。デフォルトのローカル動作には廃棄が推奨されるが、最終的な障害方針は運用者が持つ。rate制御など有効な非steering動作は残る。

この分離は復旧には有利だ。policyが戻れば、BGPルートを再取得せずに転送動作を再試行できる。しかし、監視画面の「受信済み」はもはや合格表示ではない。Loc-RIB、下流広告、FIB設定、テストパケットの結果を別々に残す必要がある。

草案は失敗理由を含む通知とdrop counterを求める。大量エラーや資源枯渇時には、個別ログのrate-limit、集約、一時抑止も認める。制御面を守るには必要な例外だが、ログがないことを成功と読めなくなる。抑止中かどうかと集約カウンターが、アラーム件数と同じ証拠になる。

非対応headendには別の意味が見える

この拡張を知らないheadendでも、基本FlowSpecとRedirect-to-IPを実装していることはある。Prefix-SIDはoptional transitive属性であるため、その装置は理解せずに次へ渡し、自身の転送では無視できる。その結果、既知のRedirect-to-IP動作へ戻る。

第18版対応機は、不完全なSR意図を認識してフォールバックを拒む。非対応機にはその概念がなく、正当なリダイレクトに見える。同一のBGPセッション、同一の更新、同一の宛先でも、対応境界だけでパケットの行方が分かれる。

草案は、neighborとserviceごとにSRv6 service-steering属性の広告を制御し、管理境界でfilterするよう求める。ただしfilterは受信機の実装版を自動判定しない。送信側には対応版と有効機能の台帳が必要で、異なるグループへ同じ属性を配るなら結果の違いを明示的に承認しなければならない。

試験は正常系より欠落系が重要になる。純粋なRedirect-to-IP、有効なMode 1とMode 2、Color欠落・破損、policy停止、SID到達不能、FIB資源不足を、対応機と非対応機へ送る。それぞれについてRIB、再広告、FIB、drop/redirect counter、観測パケット、通知、抑止、回復を一行に結び付けるべきだ。

第13版の合意は第18版へ自動継承されない

shepherd write-upによれば、以前のWGLCは第13版を対象とした一週間の短いもので、肯定的な支持を得た。その後のAD reviewで、二つのモード、属性を順番に解く手順、より広いservice action、障害処理、互換性、運用とsecurityの規定が加わった。

第17版が出た後の8月26日、担当Area Directorは、文書を先へ進める前にIDR議長がWorking Groupをpollし、変更後も合意があるか確認するよう求めた。Datatrackerは状態を External Party にした。9月5日の第18版は、不完全意図の通常転送を廃止し、到達不能なservice SIDやsegment list合成、境界と可視性の扱いをさらに書き換えた。

再確認は飾りではない。仕組みの目的には賛成でも、fail-openとfail-closedの選択には反対できる。あるサービスは制約外の迂回を最大の損失と考え、別のサービスは避けられる停止を重く見る。rough consensusは技術的反対を理解し処理したという判断であり、逆の結果を定めていた旧版から借りるものではない。

pollは「この作業を支持するか」では足りない。第18版の、不完全SR意図、Loc-RIB保持、policy/SID障害、ローカル方針、非対応機のfallbackを明記すべきだ。議長の結論には、賛否の数だけでなく、反対理由をどう扱ったかを残す必要がある。

2021年の試験に2026年の項目は足せない

Implementation Statusは、China Mobileが2021年7月から10月に実施した共同interopに参加したルーター4製品とcontroller 4製品を挙げる。さらに、2022年8月からChina Mobileのbackboneでproduction利用されていると報告する。同じ節の注意書きは、情報が寄稿者から供給され、独立検証されず、IETFのendorsementでもないと明示している。

古い運用経験には価値がある。ただし、確認した資料は、その試験が第18版のfailure matrix、到達不能なservice SID、SIDのreplace/append、対応・非対応headendの混在を試したとは示していない。後から追加された文言は、過去の試験項目を増やさない。

必要なのは「実績あり／なし」の二値ではなく、版を持つ実績だ。ソフトウェアbuild、草案版、機能、属性組合せ、負の試験、peer能力、観測パケットを記録する。現在の再試験を別行として加えれば、古い成果を捨てずに証明範囲を守れる。

合意と展開を同じ版へ結ぶreceipt

最初の欄には第18版のsource hash、poll期間、質問、回答archive、重要な反対、議長判断を置く。次に同じ版で、通常redirect、Mode 1/2、Color不正、policy停止、SID到達不能、FIB失敗を並べる。

各行は対応機と非対応機を分け、route accepted、advertised、forwarding installed、packet outcomeを独立に示す。drop、redirect、rateのcounterと、通知が抑止されたかも必要だ。

展開欄には送信者、受信グループ、能力版、境界filter、許可SID範囲、ローカル障害方針、retry、canary、rollback条件を書く。機密アドレスは仮名化できるが、版と結果は隠せない。再試験で成功しても、最初の失敗は訂正履歴として残す。

Heng Luのminimum specificationは、ここでは編集上の検査軸に限る。共通部分は小さく、決定的で、検証可能であるべきだ。ローカルな損失判断は運用者に残せるが、誰が決め、何が起きたかは記録する。標準の名前とローカル裁量のどちらも、見えない能力差を正当化しない。

第18版の選択が第17版より安全である可能性はある。だからこそ、現在の選択に合意し、新旧headendの結果を確かめてから進める必要がある。古い合意と古いrunning codeだけでは、今日のdropを承認したことにはならない。

情報源

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — 第18版本文
  3. IETF — 第17版本文
  4. IETF Author Tools — 第17版と第18版の比較
  5. IETF Datatracker — 文書履歴
  6. IDR list — 変更後の合意確認要請
  7. IETF — document shepherd write-up
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification