Session Date/Time: 20 Jul 2026 09:30

BFD

Summary

The BFD Working Group met at IETF 126 to discuss the status of the working group's charter, progress on transitioning core BFD specifications to full Internet Standards, and updates to several key active documents.

The core focus of the meeting was the advancement of RFC 5880, RFC 5881, RFC 5882, RFC 5883, and RFC 5884 to full Internet Standards. This process requires folding in outstanding errata, removing unused or unimplemented features, and gathering implementation reports proving at least two independent interoperating implementations for all supported features.

Key Discussion Points

Working Group Status and Chairs' Update

• Presenters: Jeff Haas and Reshad Rahman
• Slides: Chairs slides
• Discussion:
• The working group has recently rechartered and completed its lingering milestones (including unsolicited BFD, unaffiliated BFD echo, meticulous authentication, and BFD for large packets).
• The chairs noted that BFD continues to serve as an active consulting group for BFD extensions being developed across other IETF working groups (such as BGP strict mode and various EVPN/VXLAN extensions).
• Future work may intersect with AI networking and data center congestion protocols, which could overlap BFD with the new FANN (Fast Network Notification) working group.
• To advance core specifications to Internet Standard under RFC 2026, the working group needs to submit implementation reports detailing two independent interoperating implementations for each feature. Features with only one implementation must either be removed or the documents must handle them specially.
• In the chat, John Scudder and Ketan Talaulikar discussed the "one implementation" scenario. John suggested that local features (like demand mode) might not require far-end cooperation and could be retained, while Ketan noted that if a feature does not meet the interoperability threshold, it could remain as a Proposed Standard (PS) and be reclassified as an Internet Standard later when a second implementation becomes available.

RFC 5880-bis & RFC 5881-bis Update

• Presenter: Reshad Rahman (on behalf of Alvaro Retana)
• Slides: rfc5880bis Update (BFD) / rfc5881bis Update (BFD for IPv4 and IPv6 (Single Hop))
• Drafts: draft-ietf-bfd-rfc5880bis and draft-ietf-bfd-rfc5881bis
• Discussion:
• Both documents copy the base RFCs, update references to XML v3, fold in verified/held-for-update errata, and add an implementation status section per RFC 7942.
• draft-ietf-bfd-rfc5880bis: Three implementation reports have been received so far. Alvaro Retana prefers reports to be submitted via GitHub Pull Requests or email.
  • For "Demand Mode," Cisco supports this in three distinct codebases, which might satisfy the requirement of independent implementations.
  • Matthew Bocci asked about the timeline and preservation of implementation reports. Jeff Haas clarified that the goal is to get reports in before the next IETF meeting. The reports are currently included in the draft's appendix, but could also be preserved on the BFD Wiki.
  • Jeff Tantsura (NVIDIA) requested a central place (like the Wiki) to track published reports. Jeff Haas confirmed they are in the draft appendices.
  • Jeff Haas noted traditional hurdles with IESG reviews: Transport ADs historically worry about BFD packet rates (congestion control), Security considerations, and operational considerations. The current RFC 5706-bis work might be impactful.
  • Ketan Talaulikar suggested the working group consider writing a separate BCP/Informational document for BFD operational considerations so as not to stall the progress of the base standard.
• draft-ietf-bfd-rfc5881bis: No implementation reports have been received yet. The chairs urged the working group to submit reports so this document can advance.

RFC 5882-bis & RFC 5883-bis Update

• Presenter: Xiao Min
• Slides: rfc5882-bis and rfc5883-bis
• Drafts: draft-ietf-bfd-rfc5882-bis and draft-ietf-bfd-rfc5883-bis
• Discussion:
• draft-ietf-bfd-rfc5882-bis: Includes four verified editorial errata, adds an IANA section (noting no actions), and adds an implementation status section. ZTE provided an implementation report.
  • ZTE's report noted several unimplemented "SHOULD" level features, including Session State, Admin Down state (for static routes), BGP strict mode (only OSPF/ISIS are supported), and Graceful Restart interaction.
  • Jeff Haas noted that other implementations (such as HPE/Juniper) do support Admin Down and Graceful Restart, which should cover the interoperability requirement for those features.
• draft-ietf-bfd-rfc5883-bis: Includes an implementation status section. ZTE reported implementing unaffiliated BFD echo over SRH (Segment Routing Header), but not affiliated BFD echo.
  • The working group discussed the rules for "echo function" over multiple hops. Reshad Rahman proposed text modifying the strict "must not use over multiple hops" rule to allow it in environments where packet encapsulation/forwarding behavior does not risk intermediate nodes looping the packet back to the sender.
  • Xiao Min added "In other words..." explanatory text to clarify the encapsulation scenarios.
  • Jeff Haas noted that the original multi-hop restriction was pushed by transport ADs due to DDoS attack concerns. However, when multi-hop is encapsulated (e.g., in SRv6 or tunnels), it is logically single-hop to the outer tunnel endpoint.
  • John Scudder commented that while the "In other words" clarification repeats the concept, he has no strong objection to keeping it. Maria Matejka strongly supported keeping the explanatory text as a useful checkpoint for first-time readers.

RFC 5884-bis Update

• Presenter: Vengada Prasad Govindan
• Slides: RFC 5884-bis
• Draft: draft-ietf-bfd-rfc5884-bis
• Discussion:
• This draft merges RFC 5884 and RFC 7726 (which clarified ECMP and multiple BFD sessions for MPLS LSPs). Unnecessary background and redundant text from RFC 7726 was stripped to maintain document flow. Three verified errata were integrated.
• Greg Mirsky highlighted areas for refinement: Section 8 still contains legacy text referring to the original RFC 5884 and needs cleanup. He also questioned what a peer should do when receiving an LSP echo reply with a mismatching BFD discriminator after BFD control packets have already been received.
• Matthew Bocci suggested that the implementation report template explicitly ask how implementations handle this discriminator mismatch gap, rather than just asking if they comply with specific sections. Prasad agreed to add this question to the template.
• IPv6 Loopback Address Issue:
  • Prasad and Greg Mirsky discussed the outstanding issue regarding loopback addresses used in BFD over IPv6. In IPv4, BFD packets use the 127/8 range to prevent off-link forwarding. In IPv6, using IPv4-mapped loopback addresses is not natively supported or clean.
  • John Scudder recounted that during the original advancement of the RFC, the IESG pointed out that mapped loopbacks were illegal in native IPv6. The WG adjusted the text but did not fully resolve the operational impacts.
  • Jeff Haas detailed conversations with Eric Vyncke (Internet AD) and Jen Linkova regarding RFC 9780 (which defines the 100::/64 loopback prefix for BFD/LSP ping). Under IPv6 architecture, mapped addresses are treated as unicast, which causes issues. However, the new 100:: network lacks widespread implementation in shipping code.
  • If the document is updated to mandate the new 100:: space, it might fail the "two interoperable implementations" requirement for Internet Standard. Eric Vyncke indicated that the IESG might allow leaving the legacy behavior as-is to preserve existing implementations, though this remains a potential point of tension.
• Author Limit: Merging RFC 5884 and RFC 7726 may cause the draft to exceed the IESG's 5-author limit. Jeff Haas stated that the IESG is generally happy to waive this limit for merged "bis" documents.

Decisions and Action Items

• Action Item: Implementers are requested to submit BFD implementation reports (especially for draft-ietf-bfd-rfc5881bis which has received none so far).
• Action Item (draft-ietf-bfd-rfc5884-bis): Prasad to update the implementation report template to explicitly ask how implementations handle discriminator mismatches in LSP echo replies.

Next Steps

• The chairs aim to collect all remaining implementation reports within the next month.
• The working group intends to resolve the remaining technical and editorial issues on draft-ietf-bfd-rfc5884-bis and draft-ietf-bfd-rfc5883-bis shortly.
• The goal is to initiate Working Group Last Call (WGLC) for the entire "bis" document series prior to the next IETF meeting in San Francisco, targeting full Internet Standard publication by the end of the year.