| Internet-Draft | IPFRR in BGP-Only Networks | March 2026 |
| Abdelsalam, et al. | Expires 3 September 2026 | [Page] |
IP Fast Reroute (IPFRR) [RFC5714] is widely deployed in IP networks to provide protection against failures by invoking locally determined repair paths. Traditional IPFRR deployments require the use of a link-state IGP to provide locally computed repair paths. This document provides the problem statement and outlines a solution to enable IPFRR computation and deployment in BGP-only networks. The solution maintains standard BGP routing operations while providing fast reroute capabilities comparable to IGP-based deployments.¶
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 3 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
IP Fast Reroute (IPFRR) [RFC5714] 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 [I-D.draft-clad-rtgwg-ipfrr-aiml].¶
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.¶
[RFC5714] 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 [RFC4271] 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 Section 4 for more details.¶
These limitations prevent direct application of IPFRR techniques in BGP-only environments.¶
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 [RFC4271].¶
[I-D.ietf-idr-bgp-ls-bgp-only-fabric] 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 [I-D.ietf-idr-bgp-ls-bgp-only-fabric] have been implemented and available as open-source in the FRR Routing Stack [FRRouting].¶
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.¶
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.¶
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.¶