Summary

  • The IESG approved draft-ietf-bier-ping as a Proposed Standard on 21 September 2026. Revision 29 is in the RFC Editor queue; this article does not assume a final RFC number or port assignment.
  • A Packet-Forward-Success return code is a typed result from the BFER that answered. In a request targeting several BFR-IDs, it is not a receipt proving that the complete recipient set answered.
  • A trustworthy run record must reconcile the immutable original BitString with each targeted BFER, reply or timeout, return code, downstream mapping, entropy class and reply mode, then keep production delivery as a separate observation.

The dark bit behind a bright reply

BIER is unusual in making the intended multicast recipient set visible in the packet. RFC 8279 assigns each Bit-Forwarding Egress Router, or BFER, a bit position. A BitString can therefore name several destinations without building a per-flow multicast tree in the core. BIER Ping turns that forwarding vocabulary into an active measurement exchange.

The approval is a meaningful standards event. It is not deployment evidence. The IESG decisions record shows approval on 21 September; the Datatracker shows revision 29, dated 19 September, in the RFC Editor queue. Until editing and registry work finish, a final RFC number and final well-known UDP port should not be invented.

The operational trap begins when a console compresses a request to one green result. A responder can legitimately return Packet-Forward-Success after its local lookup and processing succeed. That tells the operator something valuable about that BFER and that probe. It says nothing by itself about a second bit whose BFER never answered.

Revision 29 states the problem directly: when the request includes more than one BFR-ID, detecting the absence of one BFR-ID is difficult. Diagnosis may require a further request that includes the non-responding BFER. The protocol therefore supplies ingredients for a completeness test, but it does not turn one affirmative response into set completeness.

Completeness lives across a sequence

The draft distinguishes the Original SI-BitString from the Target SI-BitString used to select responders. As replies arrive, an initiator can clear a replying BFER's bit in later requests. That is a stateful process. The relevant evidence is not a screenshot of the last reply; it is the sequence that begins with an immutable target set and ends only when every required bit has a reply or an explicit timeout.

This changes the unit of success. If the service objective covers six BFERs, five successes and one unexamined silence are not a successful run. The unanswered bit needs a single-target probe. If that probe also produces silence, the record must still avoid premature attribution: the forward path, target selection, local parser, control-plane punt, reply construction, return path or rate limiter may each explain the absence.

Reply mode helps narrow the claim. An IP/UDP reply proves that an answer came back over an IP path; it does not demonstrate a BIER return path. A BIER reply can exercise BIER in the reverse direction. Neither mode proves that a production multicast application decoded the payload. The return transport belongs in the manifest because otherwise two materially different tests can be reported as the same “ping”.

Return codes are local claims with different consequences

The return-code vocabulary becomes useful when it stays attached to the responder and its forwarding evidence.

Packet-Forward-Success records successful processing for the responding path. No matching entry in the forwarding table exposes a local lookup failure. Set-Identifier Mismatch can indicate that the Set Identifier carried by the encapsulation and the receiving context do not agree, a synchronization fault with the potential to move traffic across the wrong sub-domain boundary. DDMAP Mismatch says the downstream mapping observed in forwarding differs from the expected mapping; loops or duplication become plausible consequences rather than generic packet loss.

Those distinctions disappear if an automation stores only pass, fail and latency. Preserve the return code, responder BFR-ID, incoming and outgoing BitStrings, downstream interface, DDMAP and relevant label or SI context. A typed claim can then be compared with control-plane state and production counters. A colour on a dashboard cannot.

ECMP turns one target into several test obligations

The draft's multipath procedure is deliberately narrower than a broad multicast sweep. For BIER over MPLS, a multipath entropy request identifies one specific BFER and returns a bit mask describing downstream entropy choices. A request that names more than one BFER is invalid for this purpose.

That constraint contains a governance lesson. “The egress replied” and “all relevant paths to the egress were exercised” are different assertions. A run must enumerate the required entropy classes for one BFER, execute them, and store which class reached which downstream path. Repeating that work for every critical egress may be expensive, but omitting the matrix does not make the unseen branches healthy.

Probe comparability is equally conditional. The draft discusses the BFIR identity, BitString, BIFT-id, BitString length, Set Identifier, entropy and DSCP because those fields can affect forwarding. If the monitored flow uses one treatment and the probe another, successful OAM can coexist with failed production traffic. RFC 10014's active-OAM methodology and RFC 9974's BIER OAM requirements both support disciplined measurement; neither licenses a jump from a constructed probe to application outcome.

Rate protection can look like loss

BIER Ping reaches control-plane processing, so the security section recommends rate limiting traffic to the control plane and the protocol's port. That protection is necessary. It also creates another reason why silence is not self-explanatory.

A useful run records offered probe rate, device punt and policer counters, parser errors and responder load around the test window. Without them, an operator may “fix” forwarding that was working while overlooking a measurement stream rejected by protection. More dangerously, a team may raise limits blindly and turn active OAM into a control-plane exhaustion channel.

Heng Lu's distinction between symbolic descriptions, configured artefacts and observed running systems is especially sharp here. Approval is a process fact. The draft and its registries define symbols. A configured implementation exposes capability. A run manifest records observed behaviour. Production multicast and application receipt occupy still another layer. Keeping those layers separate makes BIER Ping stronger, not weaker: the tool can make a precise local claim without being asked to certify the entire service.

Sources