要約

  • BIER作業部会のInternet-Draft第12版は、障害を見つけた末端が入口へ自発的に知らせる仕組みについて、RFC 9780に基づく手順とパケットの条件をより明示した。前版にも自発的通知の節があるため、新機能の初登場という説明は正確ではない。
  • 通知はマルチキャスト配信木から分離したユニキャスト経路を使い、失敗したP2MP BFDセッションの識別子を載せる。入口からのFinal応答は通知のやり取りに関する確認であり、配信経路の復旧判定ではない。

障害対応の画面で、入口ルーターから見える警報がゼロだったとする。それだけで全受信点が正常とは言えない。BIERの配信木では、入口のBFIRがBFD制御パケットを送り、末端のBFERが到着の継続を監視する。片方のBFERが受信を失ったとき、最初の観測者はそのBFERだ。入口がその観測を知るには、別の通信が要る。

この差を扱うのが、9月29日付の draft-ietf-bier-bfd-12 である。IETF Datatrackerでの状態はBIER作業部会のLast Call、IESG側は I-D Exists。標準化を終えたRFCでも、現場の停止報告でもない。読めるのは提案中の手順であり、実装が既に普及したという結論ではない。

RFC 8562による点対多点BFDは、入口から各末端へ向かう継続性を確認する。末端で失敗が分かっても、その仕組みだけでは入口に個々の異常を伝えられない。第12版の第6節は、BIERでのactive tailをRFC 9780の自発的な通知方式に基づけ、RFC 8563の照会に応じる方式とは区別する。一方、前の第11版にも自発的な通知を述べる節があり、RFC 8563に自発的パケットへの言及が全くないわけでもない。変更の核心は参照する仕組みと、通知の成立条件の書き込み方だ。

BFERが障害を検出すると、通知用BFD制御パケットにはPollビットを立て、状態をDown、診断をControl Detection Time Expiredとする。Your Discriminator には失敗したP2MPセッションの My Discriminator を入れる。宛先はBFIRのIPアドレス、UDPの宛先ポートは4784。故障した可能性のあるBIER配信木を逆向きに使うのではなく、ユニキャストの帰路はその木と分離されなければならない。

草案は、有効なFinalビット付き応答をそのセッションで受けるか、障害が解消するまで、毎秒一つの通知を送ることを要求する。届く確率を高めるため、一秒以内に疑似乱数的な間隔で三つ送ることも推奨する。BFIRは受け取った Your Discriminator から該当セッションを選び、合致した場合にFinalを立てたユニキャストBFDパケットを返す。末端側が正向きのパケットを識別する際には、BFIR-idと入口の My Discriminator の組を用いる。両方向で識別子の役割を取り違えないことが、記録を読み解く前提になる。

ただし、帰路に応答があった事実と、元の配信方向が回復した事実は別だ。多くの末端が同時に異常を見れば、制御面に通知が集中する可能性も草案は挙げ、レート制限を論じている。入口に警報がない場合の原因として、帰路の障害や制御面の容量不足を検討すべきだというのは、ここから導く運用上の推論であって、実測された発生率ではない。先行するBIER Pingの記事が診断試験と標準化上の承認を扱ったのに対し、今回の焦点は常時監視の結果を誰が受け取ったかにある。

出典