IP Fast Reroute for BGP-Only Networks

Introduction IP Fast Reroute (IPFRR) is widely deployed in IP networks to provide protection against failures by invoking locally determined repair paths. In Data Center (DC) networks with extensive Equal-Cost Multi-Path (ECMP), operators often rely on local fast ECMP re-hashing to protect against failures of ECMP members. However, some failures are not addressed by this ECMP re-hashing and require additional fast reroute solutions for comprehensive protection. The requirements and mechanisms for IPFRR in Artificial Intelligence (AI) DC networks and DCI environments are described in . Deploying IPFRR in networks traditionally requires running a link-state IGP. This document describes an FRR solution for BGP-only networks where no IGP is present, like Massively Scalable Data Centers (MSDCs), AI DCs, and DCI networks.

Problem Statement specifies the IPFRR framework assuming link-state IGP deployment. This framework relies on two fundamental capabilities: Complete topology visibility through Link-State Databases (LSDBs) Infrastructure to compute paths using the LSDB and install repair paths in the forwarding table BGP-only networks face the following challenges in deploying IPFRR: Lack of Topology Information: As a path-vector protocol, BGP advertises reachability information without topology details. BGP routers maintain no equivalent to an IGP LSDB. No Native Topology-Based Computation: BGP's best-path selection process operates on path attributes, not topology. BGP has no inherent mechanism to compute paths based on network topology. Policy Complexity: Unlike IGPs where forwarding follows shortest paths, BGP policies at intermediate hops can alter forwarding decisions, complicating repair path computation. See for more details. These limitations prevent direct application of IPFRR techniques in BGP-only environments.

IPFRR for BGP-only networks This document describes a solution that enables IPFRR computation and installation of repair paths in BGP-only networks by leveraging topology information obtained via BGP-LS. The solution does not modify base BGP routing protocol operations in the BGP-only network fabric, which continues to provide routing using the BGP best path selection process .

Topology Collection defines a solution for obtaining a detailed topology view, similar to that available when using link-state routing protocols, in networks where BGP is used as the only routing protocol. It specifies extensions to the BGP Link-State (BGP-LS) address family and procedures for advertising topology information in BGP-only networks. With this topology information, IPFRR computations can be performed on the BGP-only network, using the same principles as in link-state IGPs (OSPF, IS-IS). The primary difference lies in how the topology database is populated. The extensions in have been implemented and available as open-source in the FRR Routing Stack .

The IPFRR Agent The solution introduces an independent logical entity, referred to as the "IPFRR Agent" which is responsible for IPFRR computation and programming of repair paths on behalf of BGP routers that have registered to it. Depending on the deployment model, an IPFRR Agent may service one or multiple BGP routers. The IPFRR Agent is an application that can be located within a network node, on an out-of-network server, within a controller, or elsewhere. The IPFRR Agent continuously collects the real time network topology information from a centralized BGP-LS speaker. On behalf of each of the BGP router that has registered to it, the agent runs the IPFRR computations, and programs the resulting repair paths on the corresponding BGP router. The workflow to deploy IPFRR in a BGP-only network via the IPFRR Agent involves the following steps: Topology collection: All BGP routers report their local topology view to one or multiple centralized BGP-LS speakers. BGP Route Reflectors (RRs) are typically used here to scale the distribution of this information. Topology consolidation: The centralized BGP-LS speakers consolidate the BGP-LS topology information received from all BGP routers to build a database representing the full network topology. Topology retrieval: The IPFRR Agent retrieves the full real time network topology view from the centralized BGP-LS speaker. The IPFRR Agent updates its topology database upon receiving BGP-LS advertisements. The IPFRR Agent may be co-located with or external to the centralized BGP-LS speaker. IPFRR computation: The IPFRR Agent computes the IPFRR repair paths for each of its registered BGP routers, using its topology database. Programming: The IPFRR Agent installs the computed IPFRR repair paths on the corresponding registered BGP router using a standard or well-known southbound API (e.g., NETCONF, RESTCONF, gRPC, or local APIs). The details of the IPFRR computation algorithm are outside the scope of this document.

Considerations for BGP Policies In link-state IGP networks, IPFRR computation relies solely on the network topology, as forwarding decisions are determined by the shortest path algorithm without local policy modifications. However, in eBGP hop-by-hop environments, BGP policies applied on intermediate nodes may affect forwarding decisions, and therefore IPFRR computation outcomes. These policies MUST be accounted for during IPFRR computation to ensure repair paths are viable and loop-free.

Security Considerations The solution relies on BGP-LS for topology population. Standard BGP-LS security considerations apply. Additional care must be taken to secure the interface between the IPFRR Agent and BGP speakers or controllers, especially when using external southbound APIs.