Summary

  • On 21 September, the IESG approved draft-ietf-bier-ping-29 as a Proposed Standard for BIER data-plane fault detection and isolation; it has not yet appeared as an RFC.
  • The draft makes the monitored flow's BIFT-id, bitstring length, entropy and DSCP part of a meaningful probe. Its traceroute mode is limited here to BIER over MPLS, while ping is not.
  • At the reporting cut, Datatracker shows IANA work in progress and the RFC Editor queue blocked for author input. The public implementation statement covers only unspecified parts of the mechanism.

An approved diagnostic is not yet a shared operational fact. A router may answer a probe, but the answer has to refer to the path the operator intended to test. In multicast forwarding, that question is sharper than in an ordinary single-destination ping: one ingress packet may be replicated toward several egress routers, and one healthy branch does not describe every receiver.

On 21 September the Internet Engineering Steering Group approved Bit Index Explicit Replication (BIER) Ping and Trace, version -29, for the Proposed Standard track. BIER's bitstring identifies the egress routers to which a packet should be delivered without requiring transit routers to keep multicast state for every flow. The new draft gives operators a BIER-native echo request and reply for detecting and isolating faults in that data plane. It is the approval of a specification, not the publication of an RFC.

The difference matters because the protocol is an agreement about what a test means. The draft says the Echo Request for a monitored flow uses the same BIFT-id, BSL, Entropy and DSCP values as that flow. Those are not decorative fields. They help place the test in the same forwarding context as the traffic under investigation. Change the forwarding-table identifier, bitstring size, load-balancing entropy or treatment class, and a green answer could belong to a different path.

Two instruments, unequal reach

The title joins ping and trace, but the draft does not give them identical reach. It says its traceroute mode is scoped to BIER over MPLS; ping has no such restriction. A procurement sheet that advertises “BIER Ping and Trace” without naming encapsulation and implemented functions would erase that distinction. The practical test is a matrix: which request format was sent, which bit positions and egress routers were targeted, which encapsulation carried it, which reply mode was used, and what the receiving equipment returned.

That matrix also keeps diagnostic evidence from quietly becoming service evidence. A successful echo may show that a particular BIER OAM packet traversed a particular forwarding context and elicited a reply. It does not, by itself, measure application delivery, loss or delay for every multicast receiver. Conversely, a timeout could reflect a reply path, a rate limit, an unsupported function or a forwarding fault. Operators need to preserve the distinction in incident records and dashboards rather than turn one result into a verdict on the whole service.

The specification requests a UDP port for IP/UDP-encapsulated Echo Reply and creates BIER OAM code-point and registry work. IANA's expert comments clarify a potentially consequential misunderstanding: the requested port is for unicast reply packets in a controlled environment, not a general port for multicast payloads. That boundary affects firewall rules, exposure assumptions and implementer expectations. The draft still carries placeholders for assignments; no final port number should be inferred from approval.

The queue after the vote

At the 24 September reporting cut, the Datatracker lists the IESG state as RFC Editor queue, the IANA action as in progress, and the RFC Editor status as blocked for author input. The IESG notice specifically says the working-group authors need to respond to IANA review questions. Such queue states can change. They are not a reversal of approval, but they show why an approved draft should not be cited as a finished RFC or deployed against guessed numbers.

The implementation evidence is narrower still. The IESG announcement says “some part” has been implemented by vendors that support BIER in some form. It names no tested combination of senders, receivers, reply modes or encapsulations. An operator choosing a tool should ask for that combination, not accept the sentence as proof of full interoperability.

The important governance act is therefore not only the IESG decision. It is the handoff from a consensus-approved packet format to assigned identifiers, publication-ready text and observable router behavior. Lu Heng's running-code principle is useful as an editorial test here: process earns technical authority when an operator can reproduce and interpret what the equipment actually did. The approval opens that test; it does not substitute for it.

Sources