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 with BFD or the newly proposed FAN (Flexible Address Network) 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.

rfc5880bis & rfc5881bis 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 and can also be preserved on the BFD Wiki.
  - Jeffrey Zhang (NVIDIA) requested a central place (like the Wiki) to track published reports. Jeff Haas confirmed they are in the draft appendix.
  - Jeff Haas noted potential hurdles with IESG reviews: transport ADs historically worry about BFD packet rates (congestion control), security considerations (Chris Patton is the new security AD), and operational considerations (under RFC 5706bis).
  - 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.

rfc5882-bis & rfc5883-bis Update

Presenter: Xiaomin Hu
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.
  - Xiaomin Hu 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: Prasad Miriyala
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 were 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 Miriyala 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.

Automatic IETF Minutes

BFD