Summary

  • Revision 02 of draft-ietf-bfd-rfc5883-bis replaces the blanket ban on using BFD Echo over multiple hops with a conditional rule: it remains prohibited where an intermediate return is possible and may be used only where the environment prevents one.
  • The file is an active working-group Internet-Draft, not an approved replacement for RFC 5883. Its new HPE implementation table is an unverified contributor report and does not prove the revised Echo condition is deployed or interoperable.

A successful Echo reply can still be the wrong answer. If an intermediate router returns the packet before it traverses the intended multihop path, the sender sees life without having tested the complete route.

That failure mode is why RFC 5883, published in 2010, states that the Bidirectional Forwarding Detection Echo function must not be used over multiple hops. Revision 01 of the proposed replacement preserved that unconditional prohibition. Revision 02, made available on 19 August, changes it.

The new text keeps a prohibition, but defines it by the forwarding environment. Echo must not be used when packet encapsulation or forwarding could cause an intermediate node to return the packet towards the sender. It may be used only when the environment can ensure that intermediate nodes will not do so. Source-routed encapsulation is offered as one example of how the premature return could be avoided.

This is a narrower change than permission to turn on multihop Echo generally. The control question is no longer just the number of hops. It is whether the operator can demonstrate that the Echo packet crossed the complete intended path before coming back.

A structure-aware comparison with revision 01 identifies this paragraph as the only normative change in the document body. Revision 02 also adds an implementation-status contribution from HPE, alongside an existing ZTE entry. Those additions provide review material, but they do not establish what the new rule does in production.

The HPE entry calls a proprietary Junos OS BFD Implementation mature and reports support for arbitrary paths, encapsulation and authentication. It marks out-of-band discriminator signalling and unidirectional links as only partially implemented, limited to MPLS LSPs, and supplies no implementation experience. The document itself says the IETF has not verified contributor-supplied information, that a listing is not an endorsement and that the section is not a catalogue.

The qualification matters because the earlier draft already contained a ZTE report describing an unaffiliated BFD Echo implementation that placed packets inside a Segment Routing Header and said Echo could then be used over multiple hops. At the time, the normative text still banned the practice without exception. The new revision brings the rule closer to an environment-dependent model, but the available sources do not say the ZTE report caused the change.

The companion generic BFD application draft moved to revision 02 shortly before the multihop draft. Its substantive addition is another HPE/Junos implementation table. That table reports broad coverage but says OSPF Virtual Links are not implemented and again provides no implementation experience. It helps reviewers compare generic BFD client behaviour with multihop claims; it is not an interoperability test.

Both documents remain active BFD Working Group Internet-Drafts. Their front matter says they would obsolete RFC 5882 and RFC 5883 only if approved. The Datatracker pages for the multihop and generic drafts show the IESG state I-D Exists, not publication as standards.

The unchanged operating constraints are as important as the new exception. BFD is network operations, administration and maintenance machinery, not a general application-to-application health check across the Internet. Packet rates must be provisioned so that congestion does not create false failure indications. A multihop session also exposes a wider spoofing surface as hop count rises, so the drafts encourage strong cryptographic authentication.

No official source in this revision set shows the conditional Echo rule enabled in a product, tested between independent implementations or measured on a production path. None defines a universal safe encapsulation. The draft has changed the standardisation question; operators still need packet-level evidence that a chosen environment actually enforces the condition.

The first useful test is deliberately simple: trace one Echo packet through every intended hop and prove that no intermediate device can return it. Then repeat under rerouting, encapsulation changes, partial failures and policy updates. A reply is evidence of full-path reachability only if the mechanism that excludes an early return survives those changes.

Sources