要約

  • draft-ietf-bier-bfd-12 は BIER 上の P2MP BFD と unsolicited notification を規定する。BFER は BFIR からの連続性消失を検出し、multicast tree と disjoint でなければならない IP/UDP unicast 経路で報告する。
  • BFIR の Final は通知を session に対応づけて受領した証拠であり、故障箇所、全 tail の状態、ツリー復旧、application delivery の証拠ではない。

ある BFER だけで heartbeat が途絶えた。BFER は Down を宣言し、UDP 4784 で BFIR に通知する。BFIR は Final を返す。ここで確認されたのはアラームの往復であって、途絶えた BIER の転送ではない。

2026 年 9 月 29 日付の BIER BFD revision 12 は、この二つの方向を分離する。BIER WG の active な Standards Track Internet-Draft であり、期限は 2027 年 4 月 2 日。RFC、IETF の最終判断、IANA 割り当て、実装、導入報告のいずれでもない。提案中の値は TBD1、TBD2、TBD3 のままである。

tail が知るのは head から自分までの断

BFIR は MultipointHead として BFD Control packet を BIER に格納し、選んだ BFER 集合へ送る。各 tail は head から来る packet の連続性を監視し、detection time が切れれば loss を宣言できる。

その観測は方向を持つ。「この session で、この BFIR から期待した packet が、この BFER に届かなかった」という意味である。壊れた link や中継 node を特定せず、別の BFER の状態も表さない。枝の一つが沈黙しても、ツリー全体が停止したとは限らない。

session の bootstrap は BIER Ping、BGP、static configuration のいずれでもよい。BIER Ping では Target SI-BitString が BFER 集合を示し、提案 TLV が My Discriminator を運ぶ。discriminator が変われば bootstrap をやり直す必要がある。しかし設定が配布されたことと、全 tail が正しく導入したこと、継続する probe が意図した経路を通ったことは別である。

discriminator だけでは session を識別できない

通常の BFD では受信側が Your Discriminator を用いて session を選ぶ。P2MP tail は同じ形で remote discriminator を割り当てず、MultipointHead の My Discriminator を受け取る。

この値の一意性は head の範囲内に限られる。BIER header の BFIR-id が origin の文脈を補うため、revision 12 は tail の key を (BFIR-id, My Discriminator) と定める。

運用記録が四 octet の値だけを残せば、別の BFIR の session と混同しうる。sub-domain、target set、local BFER、bootstrap の方法、変更履歴も一緒に保持すべきである。複合 identity は診断前に必要な安全条件である。

アラームは監視対象とは別の fate を使う

failure を検出した BFER は Poll を立て、State を Down、Diagnostic を Control Detection Time Expired にする。Your Discriminator には失敗した session の My Discriminator を入れ、BFIR 宛てに IP/UDP unicast、destination port 4784 で送る。

この return path は multicast distribution tree と disjoint でなければならない。同じ failure が tree とアラームを同時に飲み込めば、head は silence の理由を得られない。別経路は故障の fate の外から witness を届ける。

ただし通知受領が証明するのは、その一つの unicast packet が BFER から BFIR に到達したことだけである。正方向のどの区間が壊れたかは分からない。BIER session の expiry と unicast route の provenance を別々に残す必要がある。

論理的な別経路でも、line card、duct、power、control-plane queue を共有することがある。仕様は disjoint を要求するが、現実の failure domain を監査するのは operator の責任である。

Final は incident close ではない

BFER は有効な Final を受け取るか defect が消えるまで、毎秒一回通知する。さらに delivery probability を高めるため、一秒内に pseudo-random interval で三 packet を送るべきだとしている。

BFIR は Your Discriminator で session を合わせ、Final bit を立てた unicast BFD packet を返す。tail は report が head に認識されたと分かり、再送を止められる。

しかし Final は修復 receipt ではない。tree の回復、route change、fault localization、application への multicast delivery を示さない。再送停止も Final だけが理由ではなく、local defect clear の可能性がある。終了理由を記録しなければならない。

automation は acknowledgement と remediation authority を分離すべきである。valid alarm には直ちに応答できるが、topology、blast radius、policy の独立証拠なしに recovery と扱ってはいけない。

report がない tail を healthy と決められない

一つの tree failure が多数の BFER に影響すれば、通知が一つの BFIR へ集中する。draft は control plane に渡す BFD notification 数を implementation が制御するよう求める。

防御は必要だが、観測を落とすこともある。silent tail は healthy かもしれず、forward と return の双方を失ったかもしれず、session 未導入かもしれず、processing 前に rate limit されたかもしれない。一件の alarm から残りを分類できない。

expected active tails、導入済み tuple、Down report、ingress drop、processing admission、session match、Final、後の continuity recovery を照合する必要がある。limiter counter は単なる性能値ではなく、monitoring が何を見落としうるかを示す evidence である。

証拠 chain は、正確な revision、bootstrap authority、複合 identity、最後の valid packet、expiry、notification construction、return-path custody、head match、Final または defect clear、tail population reconciliation、diagnosis、repair、BFD recovery、application observation の順になる。前段は次段を証明しない。

Heng Lu の minimum initial specification は、この境界に適合する。共通層は identity、failure signal、retry、acknowledgement だけを相互運用可能にする。active tail の選択、物理的 diversity、control-plane protection、診断、修復は local authority に残す。draft publication は adoption ではない。running code、packet、counter、結果がそれを示す。

情報源