BGP Link-State Extensions for BGP-only Networks

BGP Link-State Extensions for BGP-only Networks Cisco Systems

India ketant.ietf@gmail.com

Cisco Systems

India aramahen@cisco.com

Cisco Systems

Brussels Belgium cfilsfil@cisco.com

Cisco Systems

San Jose USA kriswamy@cisco.com

USA szandi@linkedin.com

USA gdawra.ietf@gmail.com

Equinix

USA mdurrani@equinix.com

Routing Inter-Domain Routing BGP Segment Routing SRv6 BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed topology view similar to one available when using link state routing protocols. This document defines extensions to the BGP Link-state (BGP-LS) address-family and the procedures for advertisement of topology information in a BGP-only network. Discussion Venues Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (idr@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Network operators are adopting BGP as the sole routing protocol for certain networks like Massively Scaled Data Centers (MSDCs). describes the requirement, design and operational aspects for use of BGP as the only routing protocol in MSDCs. The underlying link and topology information between BGP routers is abstracted in this design for improving scalability and stability in a large scale network. As a result, a detailed topology view consisting of nodes, links and prefixes that is available when operating link-state routing protocols is not available in these BGP-only networks. BGP Link-State (BGP-LS) enables advertisement of a link state topology from link-state IGP protocols via BGP that can be consumed by a controller or in general any software component to get a complete topology view of the network. BGP-LS extensions for advertisement of certain aspects of a BGP topology for the Egress Peer Engineering (EPE) use-case are specified in . This document leverages the BGP-LS extensions that were defined for EPE and other BGP-LS features. The document specifies the procedures for advertising the underlying topology in a BGP-only network.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

BGP Routing in the Fabric The applicability of this specification is limited to those deployments where BGP is used as hop-by-hop routing protocol between directly connected nodes in the fabric. While a data-center design is used as a reference, the topology advertisement and its use for computation may also apply to other networks with BGP-only fabric or to BGP-only portions of a larger network topology. BGP hop-by-hop routing can be set up using EBGP single-hop sessions over individual links between directly connected routers using their link addresses for peering as described in . In such a design, the neighbors' link addresses may be provisioned for peering and the EBGP session operating directly over the link performs the monitoring of the neighbor on that link. A variation of this design would be that the EBGP session is set up between directly connected routers using their loopback IP addresses. The mechanisms for discovery of the neighbor's link addresses and their monitoring on a per link basis are outside the scope of this document. Though this document uses the EBGP based design as a reference, it does not preclude other alternate designs using IBGP. This document does not change base BGP routing protocol operations in the BGP-only network fabric that provides routing using the BGP best path selection process .

Topology Collection Mechanism To provide a topological view in networks where BGP is the only routing protocol, each BGP router advertises information about its local node, links, and prefixes. describes a typical deployment scenario. Every BGP router in the network is enabled for BGP-LS and forms BGP-LS sessions with one or more centralized BGP-LS speakers over which it sends its local topology information. Each BGP router may also receive the topology information from all other BGP routers via these centralized BGP-LS speakers. This way, any BGP router (as also the centralized BGP-LS speakers) may obtain aggregated Link-State information for the BGP network. An external component (e.g. a controller) can obtain this information from the centralized BGP-LS speakers or directly by doing BGP-LS peering to the BGP routers. An internal software component on any of the BGP routers (e.g. TE module) can also receive the entire BGP network topology information from its local BGP process.

Peering Models The peering model described above relies on the base BGP IPv4 or IPv6 routing underlay (e.g. as described in ) or any other mechanism for reachability for the BGP-LS session establishment with the centralized BGP speakers. A variation of this model would be to set up reachability to the centralized BGP speakers (or controller) over the out of band management network and for each BGP router in the fabric to use this management network for the BGP-LS session establishment with the centralized BGP speakers. This variation removes the dependency between the topology learning via BGP-LS from the reachability over the BGP routing in the fabric. Another alternate design would be to enable the BGP-LS address-family as well on the hop-by-hop EBGP sessions in the underlay described in . This approach results in the topology information being flooded via BGP-LS hop-by-hop along the BGP routers in the network. Other peering designs for BGP-LS sessions may also be possible and they are not precluded by this document.

Advertising BGP-only Network Topology BGP-LS defines the BGP-LS NLRI types (i.e. Node NLRI, Link NLRI and Prefix NLRI) along with their corresponding BGP-LS Attribute (i.e. Node Attribute, Link Attribute or Prefix Attribute) and the TLVs that map to the respective NLRI and Attribute for each type. specifies the BGP Protocol-ID value 7 to be used for signaling BGP EPE information. The same Protocol-ID value (7) is used for advertising topology information in a BGP-only network as specified in this document. The 64-bit Identifier field in the BGP-LS NLRI SHOULD be set to 0, consistent with the procedures defined in . defines the BGP-LS NLRI that can be used to advertise Segment Routing for IPv6 (SRv6) Segment Identifier (SID) information instantiated on a BGP Router. defines the BGP-LS NLRIs that can be used to advertise information about Segment Routing (SR) Policies instantiated on a BGP Router headend. The following sub-sections specify the use of these encodings by a router running BGP protocol.

Node Advertisements defines Node NLRI Type and the Node Descriptor TLVs as follows: introduces additional Node Descriptor TLVs for BGP protocol that are required to be used. The following Node Descriptors TLVs MUST appear in the Node NLRI as Local Node Descriptors:

Autonomous System Number (TLV 512), which contains the advertising router ASN.
BGP Router-ID (TLV 516), which contains the BGP Identifier of the originating BGP router.

The BGP-LS Attribute associated with the Node NLRI SHOULD include the Node Name TLV and MAY include the TE Router-ID TLVs (to indicate a unique reachable IP address for that node) to signal the router properties ( defines the procedures for their advertisements): Node Attribute TLVs

TLV Code Point	Description	Reference Document
1026	Node Name
1028	IPv4 TE Router-ID
1029	IPv6 TE Router-ID

The above list of TLVs is not exhaustive and other BGP-LS TLVs related to the advertisement of the node properties MAY be included depending on the desired use case.

Link Advertisements defines Link NLRI Type and its Node and Link Descriptor TLVs as follows: The following Node Descriptors TLVs MUST appear in the Link NLRI as Local Node Descriptors:

Autonomous System Number (TLV 512), which contains the advertising router ASN.
BGP Router-ID (TLV 516), which contains the BGP Identifier of the originating BGP router.

The following Node Descriptors TLVs MUST appear in the Link NLRI as Remote Node Descriptors:

Autonomous System Number (TLV 512), which contains the peer ASN.
BGP Router-ID (TLV 516), which contains the BGP Identifier of the peer BGP router.

The following Link Descriptors TLVs MUST appear in the Link NLRI as Link Descriptors:

Link Local/Remote Identifiers (TLV 258) containing the 4-octet Link Local Identifier followed by the 4-octet Link Remote Identifier. The value 0 MUST be used for the Link Remote Identifier when the value is unknown.

In addition, the following Link Descriptors TLVs SHOULD appear in the Link NLRI as Link Descriptors based on the address family of the addresses configured on the links for BGP peering:

IPv4 Interface Address (TLV 259) contains the address of the local interface through which the BGP session is established using IPv4 address.
IPv4 Neighbor Address (TLV 260) contains the IPv4 address of the peer interface used by the BGP session establishment using IPv4 address.
IPv6 Interface Address (TLV 261) contains the address of the local interface through which the BGP session is established using IPv6 address.
IPv6 Neighbor Address (TLV 262) contains the IPv6 address of the peer interface used by the BGP session establishment using IPv6 address.

The BGP-LS Attribute associated with the Link NLRI SHOULD include the Link Name and Maximum Link Bandwidth TLVs to signal the link properties ( defines the procedures for their advertisements): Link Attribute TLVs

TLV Code Point	Description	Reference Document
1089	Maximum link bandwidth
1098	Link Name

The above list of TLVs is not exhaustive and other BGP-LS TLVs related to the advertisement of the link properties MAY be included depending on the desired use case.

Prefix Advertisements defines Prefix NLRI Type and its Node and Prefix Descriptor TLVs as follows: The following Node Descriptors TLVs MUST appear in the Prefix NLRI as Local Node Descriptors:

Autonomous System Number (TLV 512), which contains the advertising router ASN.
BGP Router-ID (TLV 516), which contains the BGP Identifier of the originating BGP router.

The Prefix Descriptor MUST contain the IP Reachability Information TLV (TLV 265) to identify the prefix. This document defines a new BGP Route Type TLV that MUST be included in the Prefix Descriptor when the BGP node advertises the Prefix NLRI. The format of this TLV is as follows: Where:

Type:: 2-octet field with value TBD.
Length:: 2-octet field with value set to 1.
Route Type:: 1-octet with the following values defined:

BGP Route Types

Value	Type	Description
1	Local	Local interface prefix e.g. Loopback
2	Attached	Directly attached node's prefix e.g. host
3	External BGP	Prefix learnt via EBGP
4	Internal BGP	Prefix learnt via IBGP
5	Redistributed	Prefix redistributed into BGP

The BGP-LS Attribute associated with the Prefix NLRI SHOULD include the Prefix Metric TLV to signal the prefix properties and capabilities ( defines the procedures for their advertisements): Prefix Attribute TLVs

TLV Code Point	Description	Reference Document
1155	Prefix Metric

The above list of TLVs is not exhaustive and other BGP-LS TLVs related to the advertisement of the prefix properties MAY be included depending on the desired use case.

SR Policy and SRv6 SID Advertisements In deployments where Segment Routing (SR) is deployed in the BGP network and the use case requires information about SR Policies or SRv6 SIDs instantiated on the routers, the following BGP-LS extensions MAY also be advertised. defines the BGP-LS NLRI that can be used to advertise Segment Routing for IPv6 (SRv6) Segment Identifier (SID) information instantiated on a BGP Router. The Local Node Descriptors TLVs are the same as specified in and the rest of the procedures are the same as specified in . defines the BGP-LS NLRIs that can be used to advertise information about SR Policies instantiated on a BGP Router headend. The Headend Node Descriptors TLVs are the same as specified in and the rest of the procedures are the same as specified in .

Procedures In a network where BGP is the only routing protocol, the BGP-LS session is used to advertise the necessary information about the local node properties, its local links' properties and where necessary the prefixes owned by the node. SR Policies, that are instantiated on the local node (i.e. when it is the head-end for the policy), along with their properties may also be advertised via the BGP-LS session. This information, once collected across all BGP routers in the network, provides a complete topology view of the network. Many of these attributes are not part of the base BGP protocol operations and are either configured or provided by other components on the router. This information needs to be collected from within the node and advertised out via BGP-LS. The following sections describe the procedures for the propagation of the BGP-LS NLRIs on a BGP router into the BGP-LS session. These procedures for propagation of BGP topology information via BGP-LS SHOULD be applied only in deployments and use-cases where necessary and SHOULD NOT be applied in every BGP deployment when BGP-LS is enabled. Implementations MAY provide a configuration option to enable these procedures in required deployments.

Advertisement of Router's Node Attributes Advertisement of the Node NLRI via BGP-LS by each BGP router in a BGP-only network enables the discovery of all the router nodes in the topology. The Node NLRI MUST be generated by a BGP router only for itself and even when there are no attributes to be advertised along with it. The Node Name Attribute SHOULD be advertised when available. The TE Router-ID, normally provisioned with a unique address associated with a loopback interface on the router, SHOULD be advertised to enable TE use-cases for both IPv4 and IPv6. The BGP Router-ID along with the ASN also provides the capability for uniquely identifying a BGP router in the network. Other Node Attributes applicable to a BGP Router may also be included and this document does not describe the exhaustive list.

Advertisement of Router's Local Links Attributes Each BGP router in a BGP-only network also advertises its local links using the Link NLRIs via BGP-LS. The Link NLRI for a given link between two BGP routers is advertised as uni-directional logical "half-link" and its link descriptors allow the correlation between the two NLRIs "half-links" originated by the peering routers to describe the bi-directional logical link and its attributes on both routers. The discovery of all the links and their local and remote identifiers in a BGP-only network relies on the design that uses EBGP sessions over each interconnecting link using the link IP addresses (refer ). In this case, a Link NLRI MUST be generated by a BGP router for each of its local link regardless of whether it has any link attributes to be advertised for it. When doing EBGP multi-hop sessions between directly connected BGP routers, the underlying link information would need to be learned by some discovery protocol or provisioning entity. The mechanisms to learn the underlying link information for BGP-LS advertisements are outside the scope of this document. However, to provide a true link topology picture, the advertisement of underlying links is RECOMMENDED for most use-cases instead of a single EBGP peering representation of a link between the routers using their loopback addresses. The Link NLRI represents an adjacency between BGP routers and its association with the underlying Layer 3 link. When the underlying Layer 3 link or the BGP session on top of it goes down, the Link NLRI MUST be withdrawn by the BGP router. The monitoring of links, detecting of their failures and notification to BGP may be performed using mechanisms like BFD. This enables faster detection of failures and verification of the underlying links. Advertisement of the Link NLRIs via BGP-LS by each BGP router in a BGP-only network enables the discovery of all the active links in the topology. TE attributes for links have been traditionally associated with Link State Routing protocols. However, with the ability to discover the link topology via BGP-LS as specified in this document, the TE attributes and their principles can also be applied to a network running BGP alone. Additional link attribute TLVs related to TE (e.g., TE Default Metric, Administrative Group, SRLG) as defined in MAY be included in the Link NLRI when TE use-cases are enabled. Layer 3 bundle links comprising multiple Layer 2 member links are often used in BGP networks. When BGP session is configured over such a layer 3 link, the link attributes of the underlying layer 2 links MAY be advertised individually using the L2 Bundle Member TLV. The applicable attributes for the L2 links are described in . The Link Name Attribute MAY be advertised when available. Other Link Attributes applicable to a BGP Router may also be included and this document does not describe the exhaustive list.

Advertisement of Router's Prefix Attributes Advertisement of the Prefix NLRI via BGP-LS may be required only in specific use-cases. Since the base BGP protocol along with its extensions already signals Prefix reachability via different NLRIs, there is no necessity to duplicate the information via BGP-LS session. Advertisement of the Prefix NLRI via BGP-LS MUST be done for its locally configured prefixes (e.g. its loopback interface address). The advertisement of the Prefix NLRI via BGP-LS for other prefixes learnt by the router MAY be done based on the specific use-case requirement and the BGP Route Type as described in indicates the type of route being advertised. Other Prefix Attributes applicable may also be included and this document does not describe the exhaustive list.

Usage of BGP Topology This section describes the key use cases for the BGP topology information collected as specified in this document: topology visibility for network monitoring, IP Fast Reroute (IPFRR) and protection, and Segment Routing Traffic Engineering (SR-TE) in BGP-only networks. The specific algorithms and mechanisms for each use case are outside the scope of this document.

Topology View for Monitoring The BGP-LS advertisement of the BGP topology as specified in this document provides a live topology view of the BGP network for an application or controller that is monitoring the network. The topology view is from the BGP protocol perspective and includes the underlying links as well that aids in network monitoring as well as diagnostics use-cases. BGP-LS is the de-facto protocol for northbound propagation of network topology related information for most IGP networks and extending this capability for BGP-only networks allows existing controllers and applications to consume the information with some incremental BGP protocol awareness.

IP Fast Reroute and Protection in BGP-only Networks AI and Machine Learning (AI/ML) data center fabrics commonly employ BGP-only multi-tier Clos topologies in which training workloads are highly synchronized, bandwidth-saturating, and extremely sensitive to packet loss. These characteristics impose stringent convergence time requirements. The requirements and their implications for IP Fast Reroute (IPFRR) in such fabrics are described in . Traditional IPFRR deployments rely upon a link-state IGP to supply the complete topology database from which repair paths are computed. BGP-only networks lack an equivalent topology database. The BGP-LS topology collection specified in this document addresses this limitation by providing complete topology visibility, enabling IPFRR computations using LFA and TI-LFA techniques. The problem statement and solution framework for IPFRR in BGP-only networks using BGP-LS as the topology source are defined in . For scenarios where ECMP and TI-LFA protection are insufficient -- particularly on downward paths in Clos topologies where hairpin reroutes would consume bandwidth on already-loaded uplinks -- Efficient Remote Protection (ERP) provides a pre-computed, hairpin-free backup path mechanism. The Node and Link NLRIs collected via BGP-LS provide the topology input required to compute such protection paths at any node within the BGP-only fabric.

SR-TE in BGP Networks SR Traffic Engineering (SR-TE) for BGP provides underlay paths through the network for overlay routes and services with specific requirements such as multi-plane redundancy in Clos topologies where independent parallel fabric planes provide path diversity and fault isolation. specifies the SR Policy architecture. and describe the extensions to BGP for signaling of SR Policies from a controller to the SR-TE headend BGP router. enables the advertisement of SR Policy state from the headend to controllers via BGP-LS. This document completes the picture by providing the BGP topology information from all the routers to a controller as well as the local SR-TE process on each router for path computation. The topology collected via BGP-LS in a BGP-only fabric provides the node, link, and prefix properties along with SR SIDs that enable a computation entity to build SR Policies for traffic engineering objectives. The topology may be advertised to a centralized controller for use-cases requiring centralized computation, or distributed to any node in the BGP fabric for use by its local SR-TE process. Two deployment scenarios that leverage SRv6 TE in BGP-only data center fabrics are described below. describes an SRv6 end-to-end architecture that unifies the data center frontend and WAN under a single SRv6 domain, eliminating the need for protocol translation at DCI gateways. In this deployment, SR Policies are used to steer traffic end-to-end across the DC and WAN and to enable stateless service insertion (e.g., directing traffic through firewall services via SRv6 SIDs). The BGP-LS topology collection specified in this document provides the node and link information within the BGP-only DC fabric that is required by a controller or local SR-TE process to compute such SR Policies. describes the use of SRv6 to enable deterministic path placement for GPU-to-GPU traffic in AI/ML backend fabrics. In this deployment, an AI scheduler computes optimal paths through the Clos fabric to achieve homogeneous link utilization and avoid congestion for large, predictable training flows. The paths are encoded as SRv6 network programs at the source NIC without requiring per-flow state on intermediate fabric nodes. The BGP-LS topology collection specified in this document provides the fabric-wide node and link information that is required by the AI scheduler or controller to compute these deterministic paths. The actual SR-TE path computation and algorithms are outside the scope of this document.

IANA Considerations This document requests IANA to allocate code points from the "BGP-LS NLRI and Attribute TLVs" sub-registry of the "Border Gateway Protocol - Link-State (BGP-LS) Parameters" registry group. This document requests the allocation following TLV codepoints:

TLV Code Point	Description	Reference
TBD	BGP Route Type	this document

Security Considerations Procedures and protocol extensions defined in this document do not affect the BGP security model. See the 'Security Considerations' section of for a discussion of BGP security. Also refer to and for analysis of security issues for BGP. defines BGP-LS NLRI to which the extensions defined in this document apply. Section 10 of also applies to these extensions. The procedures defined in this document, by themselves, do not affect the BGP-LS security model discussed in . The BGP-LS extensions specified in this document enable topology visibility and traffic engineering use-cases within a BGP-only fabric as described in this document. BGP-LS operates within a trusted domain and its security considerations apply to BGP sessions when carrying topology information. The topology information distributed by BGP-LS is expected to be used entirely within this trusted domain which comprises a single AS or multiple ASes/domains within a single provider network. Therefore, precaution is necessary to ensure that the topology information advertised via BGP-LS sessions is limited to nodes in a secure manner within this trusted domain. Additionally, it should be considered that the export of detailed topology information, as described in this document, constitutes a risk to confidentiality of mission-critical or commercially sensitive information about the network. BGP-LS peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted nodes (that include both routers and controller applications) within the trusted domain are configured to receive such information.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Border Gateway Protocol 4 (BGP-4) This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Distribution of Link-State and Traffic Engineering Information Using BGP In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies. This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3. This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. Advertisement of Segment Routing Policies Using BGP - Link State This document describes a mechanism used to collect Segment Routing (SR) Policy information that is locally available in a node and advertise it into BGP - Link State (BGP-LS) updates. Such information can be used by external components for path computation, reoptimization, service placement, network visualization, etc. Informative References Segment Routing Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Segment Routing Centralized BGP Egress Peer Engineering Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Advertising Segment Routing Policies in BGP A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP. This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs. Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy. Segment Type Extensions for BGP Segment Routing (SR) Policy This document specifies the signaling of additional Segment Routing (SR) Segment Types for SR Policies in BGP using the SR Policy Subsequent Address Family Identifier (SAFI). Use of BGP for Routing in Large-Scale Data Centers Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry. BGP Security Vulnerabilities Analysis Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community. Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518. IP Fast Reroute Framework This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes. IP Fast Reroute for BGP-Only Networks Cisco Systems, Inc. Cisco Systems, Inc. Alibaba Cloud Alibaba Cloud 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. IP Fast Reroute for AI/ML Fabrics Cisco Systems, Inc. Cisco Systems, Inc. Alibaba Alibaba This document describes the requirements and mechanisms for achieving sub-100 microsecond convergence in Artificial Intelligence (AI) Data Center (DC) fabrics and Data Center Interconnect (DCI) environments. It explores the limitations of current IP Fast Reroute (RFC 5714) capabilities, such as ECMP, LFA, and TI-LFA, particularly in the context of large-scale, multi-tier Clos topologies and BGP-only fabrics. The draft highlights the requirements for hardware- accelerated network notification mechanisms and congestion-aware remote protection strategies to address the stringent performance demands of AI workloads. Efficient Remote Protection Cisco Systems, Inc. Cisco Systems, Inc. Alibaba Alibaba This document specifies Efficient Remote Protection (ERP), a mechanism for IP Fast Reroute (IP-FRR) that utilizes network notifications to activate pre-computed backup paths at nodes multiple hops upstream of a failure. ERP addresses scenarios where local protection mechanisms, such as Loop-Free Alternates (LFA) or Topology-Independent LFA (TI-LFA), result in suboptimal paths, specifically traffic hairpinning. By activating protection at strategically selected upstream nodes rather than at the node immediately adjacent to the failure, ERP preserves routing optimality and prevents bandwidth waste. ERP applies to both complete link/node failures and performance degradations such as congestion or reduced link capacity. This makes ERP particularly beneficial in networks with high link utilization, such as AI data centers and Data Center Interconnect (DCI) networks. SRv6 End-to-End DC Frontend and WAN Cisco Systems Cisco Systems Cisco Systems Nebius Deutsche Telekom The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through different network domains in a unified and stateless manner, without requiring intermediate network devices to maintain per-flow information. This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). It describes a unified IPv6 data plane from tenant workloads through the DC frontend to Internet peering, replacing designs that stitch separate overlay protocols at the Data Center Interconnect (DCI). The solution enhances scalability and enables flexible stateless service insertion by unifying underlay, overlay, and service steering under SRv6. SRv6 for Deterministic Path Placement in AI Backends Cisco Systems Cisco Systems Microsoft Oracle Oracle Oracle IBM Cisco Systems NVIDIA Arrcus, Inc. This document describes how SRv6 uSID (NEXT-CSID) enables deterministic path placement in AI backend fabrics through L3-L4 integration: the transport stack on the NIC encodes each path as an ordered list of segments (a uSID network program) in the packet header, while the fabric forwards statelessly. It explains operational benefits including deterministic probing and alignment with hyperscale production deployments.

Acknowledgments The authors would like to thank Bruno Decraene for his review and comments on this document.