]> New H3C Technologies

China linchangwang.04414@h3c.com

Routing IDR Working Group EBGP, BGP, enhancement, Parallel, extension, ECMP This document proposes extensions to BGP to apply the RFC 5004 route persistence algorithm across parallel EBGP sessions and to suppress unnecessary advertisements between EBGP peers in the same AS. This document updates RFC 5004.

Introduction In Spine-Leaf topologies of data center or AI network, devices frequently establish multiple parallel EBGP sessions to build Equal-Cost Multi-Path (ECMP) for redundancy and increased capacity, as shown in . In , Spine belongs to AS 100; Leaf1 through Leaf8 belong to AS 1 through 8 respectively. Spine has multiple parallel links with Leaf1 through Leaf8, and establishes multiple parallel EBGP sessions with each of Leaf1 through Leaf8. External path (a) is sent to Leaf1 through Leaf8 respectively.

Spine-Leaf Network with Multiple Parallel EBGP Sessions

defines a mechanism to retain the current best path when a route is re-advertised by another EBGP peer without changes, thus improving the overall network stability. However, this mechanism does not apply across parallel sessions, which can lead to frequent best path oscillations in data center or AI network environments. Additionally, in such multiple-session configurations, a prefix received from one EBGP peer may be re-advertised to another EBGP peer in the same AS. This is unnecessary and increases network load. This document specifies an extension to to apply route persistence algorithm cross parallel EBGP sessions, and a new advertisement rule to prevent sending a prefix to an EBGP peer if that prefix was originally received from another EBGP peer in the same AS.

Terminology 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.

Problem Statement

Best Path Persistence Across Parallel EBGP Sessions In a Spine-Leaf network using parallel EBGP sessions, Spine devices receive the same prefix from multiple Leaf peers through different BGP sessions. Since the path persistence algorithm defined in does not apply to scenarios with identical BGP identifiers (i.e., parallel sessions), the best path will be reselected based on the comparison of peer addresses when the same route is received from another parallel peer. This can lead to unnecessary best path churn and may cause persistent routing oscillations.

Redundant Advertisement to Same-AS EBGP Peers When a BGP speaker receives a prefix from an EBGP peer and then re-advertises it to another EBGP peer in the same AS, it creates unnecessary advertisement and overhead due to the AS_PATH loop detection. In multiple EBGP sessions topologies, this can occur frequently and SHOULD be avoided.

Proposed Solutions

Route Selection Extension for Parallel EBGP Sessions To address unnecessary best path churn, the BGP speaker SHOULD maintain best path persistence state for each prefix across all parallel EBGP sessions to the same peer AS. When a new UPDATE for the same prefix is received from any parallel EBGP peer, the speaker SHOULD compare it with the current best path using the extended algorithm:

• If the new route remains equivalent to the current best path before BGP identifier comparison, and both routes are received from peers that are identified as belonging to the same set of parallel EBGP sessions, the current best path SHOULD be retained, regardless of which parallel EBGP peer advertised it.
• This persistence state SHOULD be reset only if the route selection attributes change or the route is withdrawn.

This mechanism requires the BGP speaker to be able to identify parallel EBGP sessions. Such identification MAY be based on explicit configuration or MAY be derived automatically by detecting that multiple EBGP peers share the same BGP Identifier.

Suppression of Redundant Advertisement to Same-AS EBGP Peers Before advertising a prefix to an EBGP peer, the BGP speaker SHOULD check the AS_PATH of the prefix as stored in its Adj-RIB-In. If the first AS in the AS_PATH matches the peer's AS (indicating the prefix was originally received from that AS via another EBGP session), the speaker SHOULD NOT advertise the prefix to that peer. This check prevents unnecessary propagation of the prefix back into the same AS via a different EBGP session.

Protocol Changes

BGP Path Selection Modification Base on the best path persistence algorithm defined in , a new step is also added before BGP identifier comparison (Section 9.1.2.2 of ) of the best path selection process:

Advertisement Filtering Rule During the process of route advertisement, prior to transmitting an UPDATE message to a peer, a BGP speaker SHOULD apply the following rule: When advertising a prefix to an EBGP peer, if the first AS in the prefix's AS_PATH equals the peer's own AS number, the BGP speaker SHOULD NOT advertise that prefix to the peer.

Implementation Considerations Implementations SHOULD provide a configuration option to enable/disable:

• Route Selection Extension for Parallel EBGP Sessions.
• Same-AS EBGP advertisement suppression.

Defaults MAY be vendor-specific but SHOULD favor enabling these features in network with multiple Parallel EBGP sessions.

Security Considerations These extensions defined in this document affect route stability and advertisement scope but do not introduce new security threats beyond those inherent in BGP. Operators SHOULD ensure that parallel session detection is correctly configured to avoid incorrect route persistence.

IANA Considerations This document has no IANA requirements.

Normative References 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. 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] In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK] 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.