RIFT

Summary

The RIFT Working Group met at IETF 125 to discuss protocol extensions for specific topologies, failure detection mechanisms, and strategies for broader industry adoption. The session included technical presentations on using RIFT in Dragonfly topologies and integrating Bidirectional Forwarding Detection (BFD). A significant portion of the meeting was dedicated to an open discussion regarding the barriers to RIFT adoption, the need for a second commercial implementation, and the prioritization of multicast support as a key differentiator for AI data center workloads.

Key Discussion Points

Working Group Status and Administration

Jeferson Lima provided updates on active drafts:
- draft-ietf-rift-kv-tie is in the RFC Editor queue.
- draft-ietf-rift-sr was recently updated.
- draft-ietf-rift-auto-evpn is nearing Working Group Last Call (WGLC); authors need to refresh the draft.
- draft-ietf-rift-dragonfly has expired and requires an update from Tony Przygienda.

RIFT in Dragonfly Topology

Sandy Zhang presented rift-df-topo, focusing on applying RIFT to Dragonfly topologies commonly used in AI computing.
The proposal involves using the leaf-only and leaf-to-leaf procedures from RFC 9692 and introducing mechanisms to prevent duplicate flooding and routing loops by limiting hop counts in non-shortest paths.
Tony Przygienda observed that the proposal for a "clique" based dragonfly is a good addition. He suggested that standard SPF on a horizontal ring could work without complex new flags.
There was a consensus that Dragonfly is primarily relevant within the data center (DC) rather than for Data Center Interconnect (DCI) due to latency and congestion control requirements.

Bidirectional Forwarding Detection (BFD) for RIFT

Chenyang Wen presented Bidirectional Forwarding Detection (BFD) for Routing in Fat Trees (RIFT) based on draft-wen-rift-bfd.
The presentation covered session establishment, interaction with the RIFT Finite State Machine (FSM), and multi-instance considerations (shared vs. per-instance models).
Jeferson Lima and Christian Hopps argued strongly against "shared BFD" for parallel links, stating it provides an inaccurate representation of link state. They recommended sticking to per-link BFD sessions.
Tony Przygienda noted that the base RIFT specification (RFC 9692) already contains BFD guidance. He suggested the draft should focus on missing operational details, such as admin-down behavior, rather than repeating or contradicting the base spec.

Barriers to Adoption and Multicast Support

Christian Hopps initiated a discussion on why RIFT has not seen wider deployment despite its technical advantages.
Jeferson Lima identified the "Juniper-only" perception as a major hurdle and emphasized the need for a second commercially viable (non-open source) implementation to prove market interest.
Tony Przygienda discussed the "free lunch" problem, where operators prefer hacking BGP (despite high OPEX) because it is perceived as a commodity. He noted that RIFT’s Zero Touch Provisioning (ZTP) and Auto-EVPN features offer significant OPEX savings that are currently undervalued by the market.
The group identified multicast as a potential "killer feature" for AI workloads. Jeferson Lima and Tony Przygienda agreed to revisit expired multicast work to provide a built-in alternative to PIM, which is often avoided in data center environments.

Decisions and Action Items

Dragonfly Collaboration: Sandy Zhang and Tony Przygienda will merge their efforts into a single draft to avoid architectural replication.
BFD Draft Revision: Chenyang Wen will update draft-wen-rift-bfd to:
- Remove the "shared BFD" model for parallel links.
- Ensure alignment with RFC 9692 and focus on admin-down semantics.
BGP Dragonfly Informational: Roman (participant) and Jeferson Lima will collaborate on an informational draft describing existing BGP-based Dragonfly deployments to provide a comparison point for the RIFT work.

Next Steps

Authors of draft-ietf-rift-auto-evpn to refresh the draft for WGLC.
The Working Group will prioritize multicast support for the next session to address AI DC requirements.
Potential for an interim meeting to discuss multicast technical details (specifically "joining the tree" problems) was noted.

Automatic IETF Minutes