Summary

  • RFC 9974 sets functional requirements for BIER OAM and explicitly offers them as a gap-analysis tool; it is not a live attestation about a network.
  • Its same-treatment requirement, reverse-path qualification and replicated-probe safeguards show why a diagnostic needs its own scoped evidence before it can support an action.

In RFC 9974, the IETF puts a useful list on the table: what an Operations, Administration, and Maintenance solution for the Bit Index Explicit Replication layer must be able to support. There must be sessions initiated from a router and from a controller; proactive and on-demand work; active and passive measurement; egress-availability monitoring; continuity checks; performance measures; fault notification; and survivability methods. The document says why the list exists. It is for gap analysis—finding whether the available OAM tools need enhancement or whether new tools are needed for monitoring and service validation.

That is a design instrument, not a deployment certificate. The distinction matters because BIER is deliberately a fan-out architecture. Under RFC 8279, an ingress router selects egress routers by setting their bits in a BIER header, while intermediate nodes need not retain per-flow state. A sentence saying that a solution must support downstream continuity tells an implementer what problem not to leave unresolved. It does not prove that a particular domain has that solution installed, that a controller is authorized to start a session, or that a selected bit string matched a customer-bearing flow.

The measurement boundary is in the RFC itself

RFC 9974 requires downstream OAM packets to traverse the same nodes and links and receive the same forwarding treatment, including QoS, as the monitored BIER flow. That requirement is a reminder that a convenient probe may not represent the thing it is meant to speak for. The text even recognizes a composite flow whose sub-flows have different classes of service: an operator may check continuity at the highest class rather than at every class.

The next requirement adds another limit. A bidirectional method must meet that condition downstream, but on the return direction packets may take a different path or receive different forwarding treatment. Therefore a round-trip result does not erase the distinction between forward evidence and reverse evidence. Nor do example names erase it. RFC 9974 names P2MP BFD with active tail, BFD, STAMP and Alternate-Marking as examples that may address various requirements. They are not an assertion that any one of them is running in any BIER domain.

Loss, delay and delay variation become meaningful only when the operator records what was measured, over which path and interval, with what packet treatment, and against which baseline. A metric label is not a cause. A defect indication is not a root-cause analysis. A controller that can launch a session is not, merely by that fact, entitled to alter forwarding, QoS or a customer service.

Active tests also create a control question

The RFC's security section is unusually practical. In multicast, a specially formed active test packet can be replicated; an echo request can lead to multiple replies returning to its sender. RFC 9974 consequently requires control of the echo-request rate and of the number of BIER OAM messages reaching the control plane. This is not an implementation detail to be assumed away. It means the diagnostic path itself has an operating envelope and a potential cost.

Heng Lu's distinction helps frame the governance point without becoming an IETF claim: a common coordination artifact should remain a common artifact until participants adopt and operate it. A requirements document can make a missing capability legible. It cannot silently move the risk decision from the operator who bears the consequence to the document that named the capability.