]> ZTE Corporation

xiong.quan@zte.com.cn

China Mobile

lijinming@chinamobile.com

idr In AI/ML compute fabrics and data center interconnects, collective communication patterns (e.g., All-Reduce, All-to-All) generate microbursts that can saturate queuing buffers before reactive congestion control mechanisms take effect. This document specifies a BGP SR Policy extension to carry Path Rate information (e.g., Path Committed Rate and Path Maximum Rate), enabling a central controller to compute and distribute per-segment-list rate limits along with the SR Policy Candidate Path. The headend enforces these rate limits on traffic steered to the corresponding segment list, thereby proactively preventing the microburst-induced congestion before traffic enters the network.

Introduction Segment Routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in . In order to distribute SR policies to the headend, specifies a BGP mechanism to pass SR Policies and Candidate Paths (CPs) in BGP UPDATE messages. In AI/ML compute fabrics and data center interconnects, collective communication patterns such as All-Reduce and All-to-All generate microbursts that can saturate queuing buffers before reactive congestion-control mechanisms take effect. This causes incast congestion, packet drops, and GPU starvation. Conventional congestion control mechanisms (e.g., PFC, ECN/DCQCN, HPCC) rely on the feedback loops and therefore typically cannot adjust the sending rate in a timely manner to prevent the burst from impacting the network. In such deployments, it is useful to associate a rate limit with each segment list of an SR Policy Candidate Path, so the headend can enforce it on the steered traffic. When a controller computes a rate limit for a segment list, it advertises or updates the corresponding SR Policy CP via BGP. The receiving headend applies the rate limit to traffic steered to that segment list. This document defines the control-plane mechanism to distribute path rate information to the headend via BGP SR Policy.

Conventions Used in This Document

Abbreviations This document uses the following abbreviations: CIR: Committed Information Rate PIR: Peak Information Rate SID: Segment Identifier SRv6: Segment Routing over IPv6

Terminology This document defines the following terminologies:

• Path Committed Rate : the target sustainable rate (CIR-like) that the network gurrantees on a path. It is expressed in bytes per second.
• Path Maximum Rate: the peak rate (PIR-like) that a path can sustain, computed by the controller based on the network information collected via Telemetry. It is expressed in bytes per second. The Path Maximum Rate MUST be greater than or equal to Path Committed Rate.
• Path Rate: the transmission rate that the headend enforced for traffic steered to a path. It is operated within the range from the Path Committed Rate to the Path Maximum Rate.

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.

SR Policy for Path Rate As defined in , an SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend receives SR Policy CPs via BGP and selects the active CP according to . The SR Policy for Path Rate is as shown in Figure 1. Each segment list of an SR Policy CP has an associated Path Rate, which is used for rate enforcement that the headend applies to traffic steered to that segment list. The Path Rate is expressed as a tuple (Path Committed Rate, Path Maximum Rate). The controller computes the Path Maximum Rate from the collected network information (e.g., buffer occupancy, RTT) via Telemetry according to the computation procedure specified in .

BGP SR Policy for Path Rate As defined in , the SR policy encoding structure is as follows: Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID Preference Priority Policy Name Explicit NULL Label Policy (ENLP) Segment List Weight Segment Segment ... ... ]]> As introduced in Section 1, each segment list has an associated Path Rate. The SR Policy encoding with Path Rate information is expressed as below:: Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID Preference Priority Policy Name Explicit NULL Label Policy (ENLP) Segment List Weight Path Rate Segment Segment ... ... ]]>

Path Rate Sub-TLV The Path Rate sub-TLV is an optional sub-TLV of the Segment List sub- TLV. It MUST NOT appear more than once within a single Segment List sub-TLV. If multiple Path Rate sub-TLVs are present, only the first occurrence is processed; subsequent occurrences MUST be ignored and MUST NOT be considered malformed. The Path Rate sub-TLV has the following format: Where:

• Type: TBD1 (to be assigned by IANA from the "SR Policy Segment List Sub-TLVs" registry ).
• Length: 8.
• Path Committed Rate: A 4-octet field specifying the sustainable rate that the network guarantees for the path. The value is encoded as an IEEE 754 single-precision floating-point value, in units of bytes per second.
• Path Maximum Rate: A 4-octet field specifying the peak rate that the path can sustain. The value is encoded as an IEEE 754 single-precision floating-point value, in units of bytes per second. Path Maximum Rate MUST be greater than or equal to Committed Rate; otherwise, the sub-TLV is malformed (see Section 6).

Operations This document does not introduce new BGP processing procedures beyond those defined in . The existing procedures for advertisement, reception, and error handling of BGP SR Policy NLRIs in apply directly to this document. The error handling rules specified in Section 5 of and govern the processing of malformed Path Rate sub-TLVs. Typically, but not limited to, the SR Policies carrying Path Rate information are configured by a central controller. After configuration, the SR Policies carrying Path Rate information are advertised by BGP UPDATE messages using the same procedures as defined in . Upon receiving a valid Path Rate sub-TLV within a Segment List sub-TLV, the SRPM (SR Policy Module) as per at the headend programs a per-segment-list rate limiter (shaper or policer) with the specified Committed Rate and Maximum Rate. The headend SHOULD enforce the following semantics:

• Sustained traffic rate SHOULD NOT exceed the Path Maximum Rate.
• The headend SHOULD aim to meet the Path Committed Rate as a long-term average for traffic steered to the segment list.
• Short-term bursts up to Path Maximum Rate are permitted; the burst size is governed by the headend's shaper implementation and local policy.

If a Path Rate sub-TLV is absent from a Segment List sub-TLV, the headend MUST NOT apply any rate limiting specific to this document for that segment list and SHOULD revert to the default behavior as defined by . Whenever the Path Committed Rate or the Path Maximum Rate of a segment list is changed, the controller MUST advertise a new BGP UPDATE message containing the updated Path Rate sub-TLV. The headend processes the update according to the rules in . When a new SR Policy CP with an updated Path Rate becomes the active CP, the SRPM SHOULD perform an update of the per-segment-list rate limiter. The update SHOULD NOT cause packet loss, forwarding pause, or throughput degradation to traffic already steered to that segment list.

Security Considerations This document extends the BGP SR Policy encoding defined in with a Path Rate sub-TLV. The security considerations described in and are applicable to this document.

IANA Considerations This document defines a new Sub-TLV in registries "SR Policy Segment List Sub-TLVs" :

References 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. According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. 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. 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. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. 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. 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. 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. 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 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] This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]