rift Y. Zhou, Ed. Internet-Draft L. Zhu, Ed. Intended status: Standards Track C. Wen, Ed. Expires: 29 August 2026 China Unicom 25 February 2026 Bidirectional Forwarding Detection (BFD) for Routing in Fat Trees (RIFT) draft-zhou-rift-bfd-00 Abstract This document specifies the use of Bidirectional Forwarding Detection (BFD) for fast failure detection of Routing in Fat Trees (RIFT) adjacencies. RIFT is specified in RFC 9692. While RFC 9692 describes interactions with BFD, it does not define normative behavior. This document specifies the use of single-hop BFD, as defined in RFC 5881, for RIFT adjacencies, including behavior for parallel links and multiple RIFT instances. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 29 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Zhou, et al. Expires 29 August 2026 [Page 1] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 2. Overview of BFD Usage in RIFT . . . . . . . . . . . . . . . . 3 3. BFD Session Establishment . . . . . . . . . . . . . . . . . . 3 3.1. Parallel Link Considerations . . . . . . . . . . . . . . 4 3.2. BFD Parameters . . . . . . . . . . . . . . . . . . . . . 4 4. Interaction with the RIFT . . . . . . . . . . . . . . . . . . 4 5. Multi-Instance Considerations . . . . . . . . . . . . . . . . 5 5.1. Shared BFD Model . . . . . . . . . . . . . . . . . . . . 5 5.2. Per-Instance Model . . . . . . . . . . . . . . . . . . . 6 5.3. Restart Behavior . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction With large-scale AI and model-training workloads becoming commonplace in data center networks, transient network failures (e.g., link flaps, port flapping, and optical module/cabling anomalies) can create short-lived blackholes and introduce reroute latency. In practice, such impairments are amplified into application-level tail latency, job retries, and even reduced aggregate training throughput. As a result, the control plane of a fat-tree fabric is expected to provide sub-second and often millisecond-scale failure detection and convergence. RIFT's keepalive mechanism, centered around a seconds- scale holdtime, is inherently oriented toward stability and scalable adjacency maintenance, and is therefore not well suited to serve as the primary trigger for sub-second fast convergence. Consequently, it is necessary to introduce and standardize the use of Bidirectional Forwarding Detection (BFD) in RIFT-based fat-tree deployments in order to meet the fast failure-convergence requirements of training and similar latency-sensitive workloads. Zhou, et al. Expires 29 August 2026 [Page 2] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 This document specifies the use of single-hop BFD, as defined in [RFC5881], for failure detection of RIFT adjacencies. It defines BFD session establishment, interaction with the RIFT adjacency state machine, and behavior for parallel links and multiple RIFT instances. 1.1. Terminology This document uses the acronyms defined in [RFC9692] along with the following: RIFT instance: A logical instance of the RIFT protocol running on a node. BFD session: A BFD control session as defined in [RFC5881]. 1.2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Overview of BFD Usage in RIFT Implementations of RIFT using BFD as specified in this document MUST use single-hop BFD as defined in [RFC5881]. BFD is used for rapid detection of failures that affect RIFT adjacencies. BFD operation is independent of RIFT ThreeWay hello and holddown timer. 3. BFD Session Establishment RIFT advertises BFD capability on a per-link basis. In [RFC9692], support for BFD is indicated via the LinkCapabilities field carried in LIE messages. Based on this capability advertisement, an implementation MAY enable BFD to accelerate RIFT adjacency state updates and achieve faster routing convergence. A BFD session SHOULD be started after the corresponding RIFT adjacency has reached ThreeWay state. If link identifiers or BFD capabilities change, both the LIE and any BFD sessions SHOULD be brought down and back up again. In case only the advertised capabilities change, the node MAY choose to persist the BFD session. Zhou, et al. Expires 29 August 2026 [Page 3] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 3.1. Parallel Link Considerations Sharing a single BFD session across multiple parallel links may lead to incorrect liveness inference for individual links (e.g., partial link failures becoming invisible to the control plane, or being amplified into a full adjacency failure). Therefore, for parallel links between the same pair of RIFT nodes, each link is RECOMMENDED to have an independent BFD session. With per-link BFD sessions, each parallel link can fail independently. When one or more (but not all) parallel links experience a BFD Down condition, the advertising node SHOULD update its Node TIE to reflect the affected link(s), for example by adjusting the corresponding link_ids and bandwidth attributes, without unnecessarily treating the entire adjacency as unreachable. In deployments where precise per-link failure information is not required, implementations MAY share a single BFD session across multiple parallel links. However, this document does not specify procedures or interoperability requirements for shared-session operation. 3.2. BFD Parameters After RIFT ThreeWay hello adjacency convergence, a BFD session MAY be formed automatically between the RIFT endpoints without further configuration using the exchanged discriminators that are equal to the local_id in the LIEPacket. BFD sessions for RIFT MUST follow the encapsulation and demultiplexing rules defined in RFC 5881. To ensure that BFD provides meaningful acceleration of failure detection relative to the RIFT LIE keepalive mechanism, the negotiated BFD parameters (e.g., Desired Min TX Interval, Required Min RX Interval, and Detect Mult) SHOULD result in a BFD Detection Time that is significantly smaller than the LIE holdtime advertised on the adjacency (the default LIE FSM holdtime is 3 seconds in [RFC9719]). 4. Interaction with the RIFT A BFD session transition to Down on a RIFT-enabled link can result in the following actions within the local RIFT instance: 1. The corresponding RIFT adjacency SHOULD be re-initialized (i.e., the LIE FSM is reset and restarted from its initial state), and any adjacency-related state and timers (e.g., holddown timer) are cleared as appropriate. Zhou, et al. Expires 29 August 2026 [Page 4] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 2. The node SHOULD update the neighbor information advertised in its Node TIE to reflect the loss of the affected adjacency/link(s). 3. The updated TIE information SHOULD be flooded according to the RIFT flooding procedures (e.g., via TIE/TIDE/TIRE exchanges). 4. Nodes receiving the updated topology information SHOULD perform reachability recomputation (e.g., N-SPF and/or S-SPF) as required. 5. If the resulting topology change satisfies the conditions for disaggregation, disaggregation procedures MAY be triggered (in particular for multi-plane "fallen leaf" scenarios). Besides, in case an established BFD session goes Down after it was Up, RIFT adjacency SHOULD be re-initialized and subsequently started from Init after it receives a consecutive BFD Up. 5. Multi-Instance Considerations In RIFT, a node may be configured with multiple RIFT instances. Such instances can be deployed over distinct interfaces, or, subject to local configuration, over the same physical, sub-, or logical interface. Each RIFT instance maintains its own adjacency state and control-plane state independent of other instances. 5.1. Shared BFD Model A BFD session is associated with a specific point-to-point link, and its state transitions can be used as an input signal for any RIFT instance running over that link. Therefore, to reduce the total number of BFD sessions, implementations MAY share a single BFD session across multiple RIFT instances on the same interface (i.e., between the same pair of nodes over the same link). If a shared BFD session transitions to Down, all adjacencies of the associated RIFT instances that depend on that link MUST treat the link as failed (e.g., the adjacencies MUST be re-initialized or brought down, consistent with the implementation's adjacency handling procedures). When the shared-BFD model is used, all associated RIFT instances on the same interface MUST use compatible BFD parameters such that a single BFD session can be established and maintained. If incompatible requirements are configured (e.g., conflicting BFD interval and detection parameters that cannot be satisfied by one session), the implementation MUST either: a. fall back to the per-instance BFD model, or Zhou, et al. Expires 29 August 2026 [Page 5] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 b. reject the configuration. 5.2. Per-Instance Model Different RIFT instances on the same node may have different operational requirements for BFD (e.g., different failure-detection targets or stability thresholds). In such cases, the shared-BFD model cannot be used. A separate BFD session MUST be established for each RIFT instance adjacency. In the per-instance BFD model, each BFD session is uniquely associated (by local demultiplexing policy) with: * the underlying point-to-point link; and * a specific RIFT instance adjacency on that link. To establish multiple BFD sessions over the same interface, an implementation MAY use one or more of the following demultiplexing mechanisms: a. distinct UDP source ports; b. distinct discriminators. In this case, the discriminator allocation MUST NOT rely solely on the per-link identifier described in Section 3.2; instead, discriminators MUST be allocated such that they uniquely identify the combination of a RIFT instance and a link. If a per-instance BFD session transitions to the Down state, only the corresponding RIFT instance adjacency MUST be treated as failed (e.g., brought down or re-initialized), and other RIFT instances on the same interface MUST NOT be affected. 5.3. Restart Behavior When a RIFT instance is restarted or reconfigured, only the BFD sessions associated with that instance MUST be affected in the per- instance model. In the shared model, a restart of a single RIFT instance MUST NOT reset the shared BFD session unless all associated instances are removed. 6. Security Considerations This document does not introduce new protocol mechanisms beyond those defined in [RFC5880], [RFC5881], and [RFC9692]. The security considerations described in those documents apply to the mechanisms specified here. Zhou, et al. Expires 29 August 2026 [Page 6] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 In particular, the security properties of BFD, including optional authentication, as described in [RFC5880], remain applicable. The single-hop protection mechanisms described in [RFC5881], such as the use of a TTL or Hop Limit of 255, also apply. In the shared BFD session model, a failure, misconfiguration, or attack that causes the shared BFD session to transition to the Down state may result in the simultaneous loss of multiple RIFT adjacencies across different RIFT instances. Such correlated adjacency failures may lead to transient routing instability or increased convergence events within the affected topology. Operators SHOULD carefully evaluate the use of the shared BFD session model, taking into account scaling requirements and the potential impact of larger failure domains. Where strict failure isolation between RIFT instances is required, the per-instance BFD model defined in this document SHOULD be used. 7. IANA Considerations TBD. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9692] Przygienda, T., Ed., Head, J., Ed., Sharma, A., Thubert, P., Rijsman, B., and D. Afanasiev, "RIFT: Routing in Fat Trees", RFC 9692, DOI 10.17487/RFC9692, April 2025, . Zhou, et al. Expires 29 August 2026 [Page 7] Internet-Draft Bidirectional Forwarding Detection (BFD) February 2026 [RFC9719] Zhang, Z., Wei, Y., Ma, S., Liu, X., and B. Rijsman, "YANG Data Model for Routing in Fat Trees (RIFT)", RFC 9719, DOI 10.17487/RFC9719, April 2025, . Authors' Addresses Yu Zhou (editor) China Unicom Beijing China Email: zhouy739@chinaunicom.cn Lin Zhu (editor) China Unicom Beijing China Email: zhul14@chinaunicom.cn Chenyang Wen (editor) China Unicom Beijing China Email: wency15@chinaunicom.cn Zhou, et al. Expires 29 August 2026 [Page 8]