要約

  • Jeffrey Haasが議長を務めるIETF BFDワーキンググループは、RFC 5880〜5883を改訂し、2026年12月にInternet Standardへの進級を目標に掲げている。
  • RFC 9384は、BFD検出によるBGPセッション切断を「Cease」コードのサブコード10「BFD Down」として観測可能にしたが、その実装適合性はベンダー自己報告のみが根拠である。
  • RFC 9978（BFD Stability）は実験的トラックに置かれ、公表時に既知の実装が存在しないことをRFC自身が明記している。
  • 証拠階層の各層は異なる事実しか証明しない。現時点のBFD/BGP障害シグナリング修復は「仕様済み、部分実装済み」であり、「持続的に検証済み」ではない。

インターネットの経路制御において、リンク障害を数ミリ秒で検出するBFDと、セッション確立を司るBGPの接合部は、障害通知が正しく伝わるか否かで運用現場の復旧時間が変わる場所である。この接合部の仕様は長年にわたり文書上の欠陥を抱えてきた。RFC 5880のエラータ5205は、AdminDown通知の後に一方向障害が発生した場合、タイムアウト表示が抑制される欠陥を記録している。RFC 5882の本文には、エラータ8921でIESG（Ketan Talaulikar）が検証したSection 3.2→4.2の参照誤りが残っていた。

修復の中心にあるのはRFC 9384である。著者のJeffrey Haas（Juniper Networks）は、BFDセッションDownによる切断をBGPのNOTIFICATIONに「BFD Down」サブコードとして載せることを定め、受信側がBFD起因の切断とBGP側の問題を区別できるようにした。しかし、この標準の適合性を示す一次証拠は、Juniper（22.3R1、担当Haas）とArista（4.29.0、担当Bill Fenner）の自己申告適合報告であり、独立した試験方法論は示されていない。

セッション確立面の修復は、draft-ietf-idr-bgp-bfd-strict-mode（2026年8月26日のrevision 19）が担う。BFD Strict-Mode Capabilityをネゴシエートし、BFDセッションが確立するまでBGPセッションをEstablishedに進めない方式で、フラップ抑制のためにhold-downとdampeningを併設する。IETF 118のIDRセッションでは、JunosとNokia SRoS間の相互接続成功が報告された一方、動的シグナリングを備えず静的設定とBFD UpをTCP三方向ハンドシェイク前に要求する独自実装が「展開を複雑化する」例として記録された。

出荷済み実装の文書も層をなす。Junos OSの文書は、許容待機区間内にBFDがUpしなければBGPセッションをリセットしサブコード「BFD Down」を通知すると説明し、FRRもstrict modeを実装している。ただし双方ともベンダー文書であり、規格適合の独立検証ではない。

Haas自身が報告したRFC 5880エラータ7240は、逆説的な教訓を与える。仕様本文は「正しく完全」とされながら、複数実装がセッションUp時にbfd.LocalDiagをゼロへ戻す逸脱を示す。つまり仕様の正しさは運用の一致を保証しない。

出典