Summary

  • The BIER working group's BFD Internet-Draft, revision 12, specifies an unsolicited failure notice from a BIER egress router to the ingress router. Its Section 6 now points to RFC 9780's unsolicited active-tail mechanism rather than RFC 8563's solicited procedure; the prior draft already discussed unsolicited notification, so this is a clarification and tightening, not the invention of the alarm.
  • The receiver sends a unicast BFD packet on a path disjoint from the multicast tree, identifies the failed P2MP session in Your Discriminator, and repeats the notice until a valid Final reply or defect clearance. A receiver's detection, a head's acknowledgment, and restoration of the original data path are three different states.

Imagine an ingress router sending BFD control packets across a BIER distribution tree. One egress stops receiving them. The egress has evidence of lost continuity, but the ingress does not automatically acquire that evidence merely because the fault was detected at the edge. That gap—between the witness and the place where an operator might correlate alarms—is the useful news in revision 12 of draft-ietf-bier-bfd.

The Datatracker lists the 29 September text as an active BIER working-group Internet-Draft in working-group Last Call, with IESG state I-D Exists. It is not an RFC, an account of a live outage, or evidence that vendors have deployed the procedure. The draft adapts point-to-multipoint BFD to BIER: the ingress, or BFIR, transmits toward egress routers, or BFERs; each tail monitors continuity. RFC 8562 already explains why this one-way observation alone does not inform the head which tail has lost the path.

Revision 12 sharpens the return leg. Section 6 explicitly chooses the unsolicited active-tail mechanism described in RFC 9780 for this BIER application, contrasting it with RFC 8563's solicited notification methods. This distinction must be read carefully: revision 11 already contained an unsolicited-head-notification section, and RFC 8563 itself mentions unsolicited packets. The change is the clearer normative dependency and the more exact packet and response procedure in the new draft, not a claim that no earlier text could report a failure.

When a BFER detects failure, its notice must set the Poll bit, Status Down, and Diagnostic Control Detection Time Expired. Your Discriminator must carry the failed P2MP session's My Discriminator. The packet is IP/UDP unicast to the BFIR, destination port 4784, not a message carried back along the broken BIER multicast tree. The draft says the unicast route must be disjoint from that tree. It requires a rate of one notification per second until the egress receives a valid Final packet for that session or the defect clears, while recommending three packets at pseudo-random intervals within a one-second interval to improve the chance of notification.

At the ingress, the discriminator is not decorative metadata. The BFIR uses Your Discriminator to select the session and returns a unicast BFD packet with Final set after a match. At the egress, the forward direction uses a different context: the tuple of BFIR-id and the head's My Discriminator identifies the P2MP session. Keeping these roles separate matters when interpreting an alarm record. A Final response establishes that the notice reached a matching head-side session and received a protocol reply; it does not, by itself, show that the multicast path has recovered.

The draft also recognizes that many receivers affected together can generate a burst of notifications toward the control plane and discusses rate limits. This makes silence in the head's logs an ambiguous signal: a return-route fault, lost notification, or control-plane pressure can obscure a tail-side observation. That is an operational inference from the specified paths and rate behavior, not a measured failure rate. The corresponding earlier BIER Ping story concerned approval and diagnostic test fidelity; this draft concerns a continuously monitored tail's failure report and its separate delivery contract.

Sources