Summary

  • draft-ietf-bier-bfd-12 specifies P2MP BFD over BIER and an unsolicited active-tail alarm. A BFER detects loss from the BFIR, then reports over a unicast IP/UDP path that must be disjoint from the multicast distribution tree.
  • The BFIR's Final response acknowledges a matched notification, not a repaired tree. The operational record must preserve session identity, both path directions, silent tails, control-plane drops and a separate post-repair outcome.

The multicast tree has gone quiet at one egress. That egress does not wait for the ingress to poll it. It sends a Down notification back to the head over unicast, repeats until the head replies with Final, and then stops. The alarm exchange is successful. The multicast path can still be broken.

That apparent contradiction is the useful design boundary in revision 12 of BIER BFD, posted on 29 September 2026. The BIER Working Group draft applies point-to-multipoint BFD to a BIER domain and borrows RFC 9780's unsolicited active-tail procedure. It deliberately uses two different paths for two different claims: BIER packets test continuity from head to tail; a disjoint unicast path carries the tail's defect report back.

Revision 12 is an active Standards Track Internet-Draft that expires on 2 April 2027. It is not an RFC, a completed IETF decision, an implementation or a deployment report. Its requested BIER OAM message type, discriminator TLV and BGP mode remain TBD1, TBD2 and TBD3.

The monitored direction ends at the tail

The BFIR acts as the MultipointHead. It sends BFD Control packets over BIER to a selected set of BFERs. Each tail watches the incoming stream and can declare that continuity from the head has failed when the negotiated detection time expires.

That observation has direction. It says the tail did not receive the expected control traffic from this head under this session's rules. It does not identify which link, node, forwarding entry or replication step failed. It does not even prove that the complete BIER tree is down: another BFER may still receive every packet.

The draft provides several ways to establish the session. BIER Ping can carry a Target SI-BitString and a proposed discriminator TLV; BGP can distribute a mode; an operator can configure the session statically. Bootstrap has to name the multipoint root and My Discriminator, and it must repeat if that discriminator changes. Those facts establish configuration context. They do not form a continuing receipt that every intended tail installed the session or every probe traversed the expected path.

This is where the new work differs from the existing BIER Ping evidence problem. Ping asks which named targets answered a constructed probe and how their replies should be reconciled. BIER BFD establishes a continuing tail-local loss detector and an asynchronous failure alarm. The target set still matters, but the owned question is now who detected which directional loss and how that claim returned.

A discriminator needs its head

Ordinary BFD receivers can use Your Discriminator to select a session. A P2MP BFD tail does not allocate a discriminator in that way. It receives the MultipointHead's My Discriminator and must use additional context.

Revision 12 makes that context explicit for BIER. My Discriminator is unique only within the head's scope, not across every head visible to a tail. The BIER header supplies BFIR-id; the tail must demultiplex on the tuple (BFIR-id, My Discriminator).

An operations database that stores only the four-octet discriminator has discarded part of the identity before diagnosis begins. The same numeric value can belong to another BFIR. A defensible record retains the BFIR, sub-domain and target set, discriminator, local tail identity, installation source and change history. When the discriminator changes, the new bootstrap must not be silently joined to the old observation stream.

Composite identity is not bureaucratic detail. It is what keeps an alarm from one root from being attributed to another multicast session.

The alarm returns outside the thing it measures

After a tail detects failure, it builds a specific BFD Control packet. Poll is set. State is Down. Diagnostic is Control Detection Time Expired. Your Discriminator carries the failed session's My Discriminator. The packet is sent to the BFIR by unicast IP/UDP on destination port 4784.

Most importantly, that unicast message must travel on a path disjoint from the multicast distribution tree. If the failure that silenced the BIER path also swallowed its alarm, the head would learn nothing from the absence. Separating the return path creates a chance to observe the defect from outside its fate.

It also prevents a seductive inference. Receipt of the alarm proves that the unicast route from this BFER to the BFIR worked for that packet. It does not show which component of the forward multicast path failed. A healthy return route is not a loopback test of the tree. The evidence record therefore needs both provenances: the BIER session whose packets expired at the tail, and the unicast route, interfaces and security context that carried the report back.

“Disjoint” deserves physical scrutiny. Two routes may be logically distinct while sharing a line card, conduit, power domain or control-plane bottleneck. The draft states the path requirement; it does not provide a topology audit. Operators must decide what failure domains matter and preserve enough route evidence to test the claim.

Final closes the alarm exchange, not the incident

The affected BFER sends one notification per second until either the defect clears or it receives a valid Final-bit packet for that BFD session from the BFIR. It should also send three notifications at pseudo-random intervals within one second to improve the likelihood of delivery.

At the head, Your Discriminator selects the session. Once the packet is matched, the BFIR returns a unicast BFD Control packet with Final set. That response is valuable: it tells the tail that the head received and associated the alarm, allowing repetition to end.

Final is not a repair receipt. It does not say the BIER tree is healthy, the fault was localized, a route changed, a failed component returned or an application received multicast data. Nor does the end of repetition always prove Final arrived: the tail can stop because the defect cleared. The record must retain the actual terminating condition.

That distinction matters to automation. A controller may acknowledge the observation immediately while withholding remediation until topology, blast radius and policy are known. Conflating acknowledgement with clearance can turn a reliable alarm protocol into a false recovery signal.

Silence has several causes

One tree failure may affect many BFERs simultaneously. Active tails can then converge on one BFIR with a burst of Down notifications. Revision 12 requires implementations to control the number of BFD notification packets passed to the control plane.

That protection is necessary, but it creates another evidence boundary. A silent tail may be healthy. It may have lost forward continuity but lack a working disjoint return path. Its session may not be installed. Its notification may have been dropped before reaching the control plane. Or it may be waiting behind a limiter. One received alarm cannot classify the rest.

Leadership should demand population accounting around the protocol: expected active tails, installed session tuples, tails reporting Down, notifications rejected at ingress, packets admitted for processing, matched sessions, Final replies and later continuity recovery. Control-plane counters are not merely performance telemetry here. They explain which negative observations the monitoring system was structurally able to see.

The evidence chain is therefore longer than the handshake: exact draft and allocation state; authorized bootstrap; (BFIR-id, My Discriminator) at each tail; last accepted head packet; detection expiry; constructed Down notification; proven return-path custody; head match; Final receipt or defect-clear termination; expected-versus-reporting tail reconciliation; diagnosis; repair receipt; renewed BFD; and application observation. No stage lends its proof to the next.

Heng Lu's minimum-initial-specification doctrine fits that separation. The shared layer can define the smallest interoperable identity, failure signal, retry and acknowledgement. Operators retain authority over active-tail selection, return-path diversity, control-plane protection, diagnosis and remediation. A working-group draft does not establish adoption. Running implementations, captured packets, limiter counters and observed outcomes do.

The draft gives the head something it did not have before: an unsolicited report from a tail that stopped hearing it. Its discipline lies in what that report does not become. An alarm that returns by another road can confirm the witness. It cannot, by itself, reconstruct the road that failed.

Sources