]> China Mobile

lijinming@chinamobile.com

China Mobile

liuyisong@chinamobile.com

ZTE Corporation

chen.ran@zte.com.cn

Huawei Technologies

rainsword.wang@huawei.com

Routing IDR Working Group BGP FlowSpec RDMA Queue Pair RoCEv2 BGP Flowspec mechanism (BGP-FS) propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type named Destination-QP (Destination Queue Pair) to support filtering by Destination-QP.

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.

Introduction BGP Flowspec mechanism (BGP-FS) propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. In modern AI training clusters, especially those based on RoCEv2 and RDMA for high-performance inter-GPU communication, traffic exhibits distinct characteristics that differ significantly from traditional Internet flows. AI training communication typically consists of long-lived, high-throughput, and delay-sensitive and jitter-sensitive flows, such as those generated by collective communication operations like AllReduce. These flows are often bound to long-term Queue Pair (QP) instances, with relatively stable five-tuple fields, making them prone to path polarization and uneven link utilization when scheduled solely by five-tuple-based hashing. Such static mapping fails to adapt to the dynamic communication patterns and strict performance requirements of AI workloads, leading to localized congestion, degraded training throughput, and reduced cluster efficiency. For these reasons, five-tuple-only flow scheduling is no longer sufficient for AI-oriented lossless networks. Instead, scheduling mechanisms based on a combination of five-tuple and QP information have become necessary. By introducing QP-level identification into the flow distribution logic, networks can achieve finer-grained traffic steering, better load balancing across equal-cost multi-path (ECMP) groups, and improved isolation between communication streams. As shown in , the controller uses BGP Flow-Spec to distribute QP routes to the Ingress PE according to QP. Based on the QP value, traffic is redirected to different forwarding paths. Methods for redirecting traffic to different paths can include redirection to IP or redirection to SRv6 , among others. Specific methods are beyond the scope of this document. At the forwarding level, when the DC sends packets, it carries the corresponding QP for traffic belonging to the same task. The Ingress PE looks up the QP routes distributed via BGP Flow-Spec based on the QP of the traffic and forwards the packets according to the QP routes.

This document specifies a new BGP-FS component type named Destination-QP (Destination Queue Pair) to support filtering by Destination-QP.

Terminology

FS

Flow Specification

QP

Queue Pair

FlowSpec Filtered by Destination-QP defines the Components in the IP Basic TLV. This document proposes a new Component for Destination-QP information. The following new component type is defined: Destination-QP Type TBD - Destination-QP Length: variable Component Value format: [numeric_op, value]+ Each Destination-QP value is 4 octets. Per section 10 of , if a receiving BGP speaker cannot support this new Flow Specification component type, it MUST discard the NLRI value field that contains such unknown components. Since the NLRI field encoding (Section 4 of ) is defined in the form of a 2-tuple <length, NLRI value>, message decoding can skip over the unknown NLRI value and continue with subsequent remaining NLRI.

Use Case The BGP agent specifies the traditional 5-tuple and newly defined Destination-QP as matching criteria. As shown in , for traffic with a Destination-QP value of 1001, redirect it to Path1; for traffic with a Destination-QP value of 2001, redirect it to Path2. BGP-FS Route 1: FS Filters: Destination: 203.0.113.0/24 Source address: 198.51.100.0/24 Protocol: UDP Destination port: 4791 (RoCEv2 protocol) Source port: 10001 Destination-QP value: 1001 (the newly defined in this document) FS Action: Redirect Flow to Path1 (The specific format is not discussed in this document.) BGP-FS Route 2: FS Filters: Destination: 203.0.113.0/24 Source address: 198.51.100.0/24 Protocol: UDP Destination port: 4791 (RoCEv2 protocol) Source port: 10001 Destination-QP value: 2001 (the newly defined in this document) FS Action: Redirect Flow to Path2 (The specific format is not discussed in this document.)

The Ingress PE receives the Flow-Spec route and installs it into the forwarding plane. Upon receiving AI data traffic, it redirects the traffic to the corresponding Path for forwarding based on the traffic 5-tuple and Destination-QP parameters. In this document, the example uses QP, destination address, and source address as filtering criteria for flow-spec to redirect traffic to different paths. Destination QP Dest Prefix Source Prefix Redirect 1001 203.0.113.0/24 198.51.100.0/24 Path1 2001 203.0.113.0/24 198.51.100.0/24 Path2

Security Considerations No new security issues are introduced to the BGP protocol by this specification.

IANA Considerations defines the Types for IP Filters. This document requested to assign a new type code point from “Non-IP Types for IP Filters” registry for Destination-QP. Type Definition 64 Parts of SID 65 MPLS Match 1: Label in Label stack 66 MPLS Match 2: EXP bits in top Label TBD Destination-QP (This document) 67-249 Unassigned (reserved for now) 250 Filter Error handling 251-255 Reserved

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. 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. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. Hickory Hill Consulting Futurewei Technologies ATT Verizon BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. HPE Nokia Nokia Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard, RFC 8955, defines a redirect-to-VRF (Virtual Routing and Forwarding) action for policy- based forwarding. This mechanism can be difficult to use, particularly in networks without Layer 3 VPN infrastructure. This document defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities [RFC4360]. InfiniBand Trade Association

Acknowledgements {#sec-ack .unnumbered} The authors would like to thank the contributors for their valuable feedback and contributions.

Document History {#sec-history .unnumbered} -00 Initial version.