要約

  • draft-ietf-bier-source-protection-11 は、予備 BFIR から選択済み BFIR への監視経路だけが切れ、選択済み BFIR から BFER への転送経路が生きている場合を明記する。このとき交代すれば不要な二重送信が生じる。
  • 逆向き Ping も順方向の multicast を自動的には表さない。共通経路を保証できなければ、Ping が失敗しても業務は動き、Ping が成功しても業務経路は壊れ得る。
  • 観測経路、検出結果、standby mode、切替権限、損失・重複、受信側の継続、アプリケーション結果には別々の receipt が要る。revision 11 は Informational の Internet-Draft であり、導入実績ではない。

予備系の BFD は Down になった。タイマーも仕様どおり満了した。ここまでの記録は正しい。問題は、その一行が「主系ノードは停止した」「全受信側への経路も停止した」「予備系が今すぐ全フローを奪うべきだ」という三つの結論に膨らんだことだった。

実際に切れていたのは、二つの入口ルータの間にある監視経路だけだった。主系から受信側へ向かう三本の経路は生きていた。予備系が送信を開始すると、可用性機構そのものが duplicate flow を作った。

BIER Redundant Ingress Router Failover revision 11 が示す核心は、故障検出方式の比較ではない。観測した面と、変更を許された面を混同してはならないという統治上の境界である。

一つの図に三つの向きがある

RFC 8279 の BIER では、BFIR がパケットをドメインへ入れ、BFER が受け取る。中間 BFR はパケット中の BitString に従い、フローごとの multicast state を持たない。一方、各 BFER はフローごとに upstream multicast hop を選ぶ。overlay が選択情報を運び、BIER transport がデータを運ぶ。

草案は選択された入口を S-BFIR、代替を B-BFIR と呼ぶ。同じフローでも BFER ごとに選択が異なり得る。したがって「主系」という語は、最初からスコープを伴わなければならない。

少なくとも次の三経路を区別する必要がある。

  1. B-BFIR から S-BFIR へ向かう監視経路。
  2. S-BFIR から各 BFER へ向かう業務の順方向経路。
  3. BFER から S-BFIR へ向かう Ping request の逆方向経路。

第一の経路が切れたとき、予備系が知るのは「この経路では主系を観測できない」ということだけだ。ノード自体の停止も、第二の経路の停止もまだ証明されていない。

草案の warm standby 例では、BFIR2 と BFIR1 の間が切れる。BFIR2 は BFIR1 が down だと解釈し S-BFIR の役割を取る。しかし BFIR1 から全部または一部の BFER への経路は正常であり、切替は不要だった。結果はネットワーク内と BFER での packet duplication である。

逆の見落としもある。入口間の経路が健全でも、特定 BFER への業務経路は壊れ得る。監視が Up であることは、受信者が Up であることではない。

Down には必ず主語を残す

RFC 5880 の BFD は特定の forwarding path を監視する。RFC 8562 は multipoint へ拡張する。BIER BFD revision 12 は BIER の bootstrap と active-tail notification を定義する。高速であることと、全経路を知っていることは別である。

観測値 言えること 言えないこと
B-BFIR/S-BFIR BFD Down その session が閾値を越えた 全 S-BFIR–BFER 経路が壊れた
逆向き Ping 応答なし その probe が完了しなかった 順方向 multicast が停止した
tail の Detection Time 満了 その tail で control packet が欠けた 全受信者がフローを失った
新 UMH の選択 その BFER とフローの選択が変わった アプリケーションが復旧した
予備 BFIR が送信開始 第二の送信源が現れた duplicate がすべて除去された

receipt には方向、端点、subdomain、entropy や path-selection input、packet treatment、discriminator、interval、threshold、traffic class を残す。Down だけでは後からどの現実を観測したのか復元できない。

逆向き Ping は成功時にも失敗時にも誤る

BFER は BFIR1 へ Ping を送り、一定期間返答がなければ BFIR1 を failed UMH と判断できる。しかし保護対象の multicast は BFIR1 から BFER へ流れ、request は反対向きに進む。

非対称 routing では両者は別のリンクを通る。草案は二つの false result を明示する。Ping が失敗しても multicast path と flow は正常であり得る。逆に multicast path が壊れていても Ping は成功し得る。そのため request を監視対象の順方向経路と co-route し、一致度を高める必要がある。

co-route は application delivery の証明ではない。network-level observation を対象へ近づけるだけで、完全性、順序、duplicate suppression、利用者が見た結果は別に測る必要がある。

Cold、warm、hot は責任の置き場所である

Multicast Redundant Ingress Router Failover revision 10 の三 mode は単なる速度比較ではない。

Cold standby では BFER が failure を判断してから予備へ要求する。平常時の duplicate は抑えられるが、signaling と convergence 中に loss が起こり得る。

Warm standby では主・予備とも受信需要を知り、通常は主だけが送る。予備は速く起動できる一方、受信経路を直接見ないまま主の failure を宣言する権限を持ち得る。

Hot standby では両方が送信し、BFER が非選択側を捨てる。切替 loss は小さくできるが、duplicate bandwidth と受信側の選別処理を常時負担する。

どれが「上位」なのではない。loss、bandwidth、state synchronization、failure authority、duplicate filtering を誰に負わせるかが違う。要求書に fast failover しか書かれていなければ、制御系の設計は未完である。

受信側ごとに異なる現在があり得る

BFER は同じ S-BFIR を選ぶ必要がなく、timeout も異なり得る。一台は BFIR2 へ切り替え、別の一台は BFIR1 を継続し、三台目はまだ Detection Time の途中かもしれない。

したがって最小 event key は、flow、BFER または集合、selected BFIR、observation path、detector、threshold、state version を含むべきだ。単一の primary_failed は、正当な局所判断と危険な dual-primary を区別できない。

切替後は control receipt と effect receipt を分ける。前者は誰がどのルールで UMH を変えたかを示す。後者は BFIR2 の実送信開始、BFIR1 の停止、loss/duplicate/reorder、各 BFER の受理元、application continuity を示す。

BFIR2 由来の一パケットが届いたという事実は、復旧の始まりであって完了ではない。

草案が証明する範囲

revision 11 は 2026 年 10 月 1 日付の BIER WG Internet-Draft で、Intended status は Informational である。RFC ではなく、IANA allocation も求めない。Security Considerations は RFC 8279、RFC 8562、RFC 9026、BIER Ping、BIER BFD に依存する。

よって、この文書は observation-path mismatch と unnecessary takeover が設計上認識されている証拠になる。vendor implementation、deployment、interoperability、実障害からの service recovery の証拠にはならない。

Lu Heng の Reality Layers は、検出器の symbolic state を実際に測った physical surface へ結び戻す。Policy Mirror は、その state を topology change へ変換できる actor、rule、scope、consequence を問う。

Failover receipt

flow identity、S-BFIR/B-BFIR、対象 BFER、standby mode、overlay と従来 selection、detector/session、方向付き observation path、probe と protected flow の treatment equivalence、timer/threshold/missed packet、切替 authority、各 BFER の旧新 UMH、両入口の実送信開始・停止、loss/duplicate/reorder counter、receiver acceptance、application outcome を保存する。

co-route を証明できなければ path_equivalence_unverified、予備から受信経路が見えなければ receiver_path_unknown と書く。不明を埋めるために「保護」という名前を使ってはならない。

Sources