IDR Working Group W. Jiang Internet-Draft Y. Liu Intended status: Standards Track China Mobile Expires: 22 February 2027 S. Zhuang Huawei Technologies G. Mishra Verizon Communications Inc. S. Chen Huawei Technologies 21 August 2026 Traffic Steering using BGP FlowSpec with SR Policy draft-ietf-idr-ts-flowspec-srv6-policy-14 Abstract BGP Flow Specification (FlowSpec) provides mechanisms to distribute traffic filtering and steering rules across BGP networks. This document specifies extensions to BGP Flow Specification (RFC 8955, RFC 8956) to steer matching traffic flows into Segment Routing (SR) Policies (RFC 9256). Specifically, it defines normative protocol procedures for combining FlowSpec Network Layer Reachability Information (NLRI) (RFC 8955, RFC 8956) with the BGP Prefix-SID Attribute (RFC 8669, RFC 9252) and specific BGP Extended Communities (RFC 9012) to signal SR-MPLS and SRv6 Policy steering pathways. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo 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/. Jiang, et al. Expires 22 February 2027 [Page 1] Internet-Draft FlowSpec with SR Policy August 2026 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 22 February 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 3. Protocol Procedures . . . . . . . . . . . . . . . . . . . . . 5 3.1. Operational Steering Modes . . . . . . . . . . . . . . . 5 3.1.1. Mode 1: Steering Without Egress Service Action (SR-MPLS / SRv6) . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Mode 2: Steering With Egress Service Action (SRv6-specific) . . . . . . . . . . . . . . . . . . . 6 3.2. Procedures for the Sending BGP Speaker / Controller . . . 6 3.3. Procedures for the Receiving BGP Speaker (Headend / Ingress PE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Interaction with Redirect-to-IP Extended Community . . . 10 3.5. Scope Exceptions and Explicit Constraints . . . . . . . . 11 3.5.1. Scope regarding Color-Only (CO) Steering . . . . . . 11 3.5.2. Scope regarding VPN FlowSpec and Redirect-to-VRF . . 11 3.6. BGP Prefix-SID Attribute Encoding Rules . . . . . . . . . 12 3.7. Steering Failure and Fallback Procedures . . . . . . . . 12 3.8. Load Balancing Considerations . . . . . . . . . . . . . . 13 3.9. Backward Compatibility and Coexistence with Base BGP FlowSpec . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Multi-Attribute Interworking and Steering Resolution . . . . 15 4.1. Policy-Based Steering Classification . . . . . . . . . . 15 4.2. Deterministic Interworking Matrix . . . . . . . . . . . . 16 4.3. Protection Against Silent SLA Violations . . . . . . . . 17 4.4. Backward Compatibility and Coexistence Behavior . . . . . 18 Jiang, et al. Expires 22 February 2027 [Page 2] Internet-Draft FlowSpec with SR Policy August 2026 5. Operational Considerations . . . . . . . . . . . . . . . . . 18 5.1. Forwarding Failure Monitoring and Management . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.1. Cross-VRF Traffic Injection and Service Hijacking . . . . 19 6.2. Scope and Validation Limits of BGP FlowSpec Attributes . 20 6.3. SR Domain Leakage and Boundary Security . . . . . . . . . 21 6.4. Traffic Amplification and Path Pinning . . . . . . . . . 21 7. Application Examples (Informative) . . . . . . . . . . . . . 22 7.1. SR-MPLS Application Examples (Mode 1) . . . . . . . . . . 22 7.2. SRv6 Application Examples . . . . . . . . . . . . . . . . 24 7.2.1. SRv6 Mode 2 Example: Transport Steering with Egress Service Action . . . . . . . . . . . . . . . . . . . 24 7.2.2. SRv6 Mode 1 Example: Transport Steering Only (USD-Flavored End SID) . . . . . . . . . . . . . . . 26 7.2.3. Deployment Considerations . . . . . . . . . . . . . . 27 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 8.1. Interop-test Status . . . . . . . . . . . . . . . . . . . 27 8.2. Deployment Status . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Segment Routing (SR) [RFC8402] leverages the source routing paradigm for both SR-MPLS [RFC8660] and SRv6 [RFC8754][RFC8986]. An SR Policy [RFC9256] defines an explicit ordering of segments to steer traffic through a network, where candidate paths may be signaled via protocols such as BGP [RFC9830] or PCEP [RFC9862], or instantiated locally. [RFC8955], [RFC8956] and [RFC9117] define the BGP [RFC4271] Flow Specification that allows conveying Flow Specifications and traffic Action/Rules associated (rate- limiting, redirect, remark ...). BGP Flow Specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. Rules (Actions associated) are encoded in Extended Community attributes [RFC4360]. The BGP Flow Specification function allows BGP Flow Specification routes that carry traffic policies to be transmitted to BGP Flow Specification peers to steer traffic. Jiang, et al. Expires 22 February 2027 [Page 3] Internet-Draft FlowSpec with SR Policy August 2026 This document specifies extensions to BGP Flow Specification (FlowSpec) [RFC8955][RFC8956] to steer matching traffic flows into a Segment Routing (SR) Policy [RFC9256]. This document does not modify the base Segment Routing architecture [RFC8402] or SR Policy constructs [RFC9256], but rather establishes the interworking protocol semantics between BGP FlowSpec controllers and SR Headends on the Standards Track. 2. Definitions and Acronyms * BGP FS: BGP Flow Specification [RFC8955] [RFC8956] * CO: Color-Only * FlowSpec: Flow Specification * NLRI: Network Layer Reachability Information. * PBR: Policy-Based Routing. * Redirect-to-IP: The FlowSpec action defined in [I-D.ietf-idr- flowspec-redirect-ip] * SR: Segment Routing * SR-MPLS: SR over the MPLS data plane * SRv6: SR over the IPv6 data plane * SID: Segment Identifier * SRH: Segment Routing Header * Transport Steering Only (Mode 1): A mode of FlowSpec steering operation where traffic is directed into an SR Policy (SR-MPLS or SRv6) toward a TailEnd endpoint solely for path/transport engineering, without imposing an explicit egress service action or carrying a BGP Prefix-SID Attribute. * Transport Steering with Egress Service Action (Mode 2): A mode of FlowSpec steering operation where traffic is directed into an SR Policy toward a TailEnd endpoint and additionally carries an explicit egress service function (e.g., SRv6 Service SID, End.DT4/ DT6) to specify the egress VRF or forwarding context at the TailEnd device. Jiang, et al. Expires 22 February 2027 [Page 4] Internet-Draft FlowSpec with SR Policy August 2026 * USD: Ultimate Segment Decapsulation 3. Protocol Procedures BGP FlowSpec NLRI [RFC8955][RFC8956] can be combined with BGP Extended Communities and, where applicable, the BGP Prefix-SID Attribute to steer matching traffic into a Segment Routing (SR) Policy [RFC9256] in either SR-MPLS or SRv6 data planes. This specification relies on a two-tier control plane architecture: * Transport Steering: The Color Extended Community [RFC9012] is combined with the FlowSpec Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip] to form an explicit (Color, Endpoint) tuple. This tuple binds the matching FlowSpec traffic to an SR Policy (SR-MPLS or SRv6) at the head-end router (Ingress PE) [RFC9256]. * Egress Service Action (SRv6-specific): For SRv6 scenarios requiring a specific egress service action (e.g., decapsulation and table/VRF lookup) at the tail-end router (Egress PE), the BGP Prefix-SID Attribute [RFC9252] MAY be attached to convey an SRv6 Service SID. The procedures in this document apply strictly to IPv4 and IPv6 FlowSpec address families in the global routing context (AFI=1/2, SAFI=133). 3.1. Operational Steering Modes The traffic steering mechanism specified in this document relies on BGP FlowSpec filtering rules to perform flow-based policy encapsulation into SR Policies [RFC9256]. Architecturally, FlowSpec-based steering corresponds strictly to Policy-Based Routing (PBR) steering as defined in Section 8.7 of [RFC9256]. It SHALL NOT be interpreted or implemented as per- destination steering (Section 8.4 of [RFC9256]). Implementations MUST NOT apply per-destination route-resolution mechanics, BGP multipath path resolution, or On-Demand BSID recursion [RFC9256] to FlowSpec route processing. When advertising a FlowSpec route to steer traffic into an SR Policy, the sender MUST construct the BGP UPDATE message according to one of the two deterministic operational modes specified below, based on the target data plane (SR-MPLS or SRv6) and egress service context requirements: Jiang, et al. Expires 22 February 2027 [Page 5] Internet-Draft FlowSpec with SR Policy August 2026 3.1.1. Mode 1: Steering Without Egress Service Action (SR-MPLS / SRv6) When matching traffic only needs to be steered into an SR Policy (SR- MPLS or SRv6) toward an Endpoint, and no specific VRF or table lookup action is required at the egress PE: * The sender MUST attach both a valid Color Extended Community [RFC9012] and a Redirect-to-IP (or Redirect-to-IPv6) Extended Community [I-D.ietf-idr-flowspec-redirect-ip]. * The sender SHALL NOT attach the BGP Prefix-SID Attribute. * Decapsulation or label popping at the egress PE relies entirely on the final segment's behavior of the target SR Policy (e.g., Implicit Null for SR-MPLS or End with USD flavor for SRv6). * At the ingress PE, the active encapsulation consists solely of the Segment List (MPLS Label Stack or SRH Segment List) of the selected SR Policy. 3.1.2. Mode 2: Steering With Egress Service Action (SRv6-specific) When matching traffic needs to be steered into an SRv6 Policy AND requires a specific service context or decapsulation behavior (e.g., table/VRF lookup) at the egress PE: * The sender MUST attach a valid Color Extended Community [RFC9012], a Redirect-to-IP (or Redirect-to-IPv6) Extended Community [I-D.ietf-idr-flowspec-redirect-ip], AND the BGP Prefix-SID Attribute [RFC9252]. * The BGP Prefix-SID Attribute carries the SRv6 Service SID representing the Egress Service Action, encoded according to Section 3.6. * At the ingress PE, the active Segment List encapsulated in the SRH is synthesized by stitching the SR Policy Segment List and the Egress SRv6 Service SID, strictly following Section 5 of [RFC9252] and [RFC8986]. 3.2. Procedures for the Sending BGP Speaker / Controller A BGP speaker or controller originating or re-advertising a FlowSpec route to steer traffic into an SR Policy MUST perform the following operations: Jiang, et al. Expires 22 February 2027 [Page 6] Internet-Draft FlowSpec with SR Policy August 2026 1. Determine the explicit (Color, Endpoint) tuple required for transport steering. Attach the corresponding Color Extended Community [RFC9012] and set the target IP address in the Redirect-to-IP (or Redirect-to-IPv6) Extended Community [I-D.ietf-idr-flowspec-redirect-ip] to match the SR Policy Endpoint. 2. Evaluate whether an egress service action is required: * If no egress service action is required (Mode 1, Section 3.1.1), the speaker MUST NOT attach the BGP Prefix-SID Attribute. * If an egress SRv6 service action is required (Mode 2, Section 3.1.2), the speaker MUST attach the BGP Prefix-SID Attribute containing the SRv6 Service SID, constructed strictly per Section 3.6. 3. If a BGP speaker receives a FlowSpec route containing a valid Color Extended Community and a Redirect-to-IP Extended Community and re-advertises it, it MUST preserve these attributes unchanged unless local policy explicitly modifies the steering intent. 3.3. Procedures for the Receiving BGP Speaker (Headend / Ingress PE) The validation and installation procedures specified in this section apply EXCLUSIVELY to BGP FlowSpec receivers acting as SR Headends (e.g., Ingress PEs) that process packet steering into SR Policies. Intermediate BGP Speakers, such as Route Reflectors (RRs), that do not participate in data-plane traffic steering MUST transparently reflect and propagate the FlowSpec routes along with their attached attributes (e.g., Color Extended Community, Redirect-to-IP, and BGP Prefix-SID Attribute) per standard BGP propagation rules [RFC8955], without attempting SR Policy binding or FIB installation. Upon receiving a FlowSpec route (AFI=1/2, SAFI=133), the receiving headend router MUST process the route in accordance with the following sequence: 1. Base NLRI & Attribute Syntactic Validation: * The receiver MUST validate the FlowSpec NLRI against the base rules defined in [RFC8955][RFC8956]. If NLRI validation fails, BGP error handling per [RFC8955][RFC8956] applies. Jiang, et al. Expires 22 February 2027 [Page 7] Internet-Draft FlowSpec with SR Policy August 2026 * Syntactic attribute errors (e.g., malformed BGP Prefix-SID Attribute or Extended Communities) MUST be handled according to BGP Error Handling rules [RFC7606] (e.g., Treat-as- Withdraw). 2. Steering Mode Determination and Attribute Interworking Validation: The headend MUST evaluate the co-existing steering attributes for correct interworking and mode determination: a. Mode 1 Validation: If a valid Color Extended Community and a valid Redirect-to-IP Extended Community are present, and the BGP Prefix-SID Attribute is ABSENT, the route is validated as Mode 1 (Transport Steering Only). b. Mode 2 Validation: If a valid Color Extended Community, a valid Redirect-to-IP Extended Community, AND a valid BGP Prefix-SID Attribute are present, the route is validated as Mode 2 (Transport Steering with Egress Service Action). The BGP Prefix-SID Attribute MUST contain a valid SRv6 L3 Service TLV (Type 5) and SRv6 SID Information Sub-TLV (Type 1) [RFC9252]. The carried SRv6 Endpoint Behavior MUST belong to the allowed Layer 3 behavior set specified in Section 3.6. If any required steering attribute is missing, or if the attributes fail the interworking validation above, the headend MUST NOT perform SR Policy steering via Modes 1 or 2, and SHALL handle the route according to the failure and matrix resolution procedures defined in Section 3.7 and Section 4. 3. Steering Parameter Extraction & SR Policy Lookup: * The headend MUST extract the Color value from the Color Extended Community and the target IP address from the Redirect-to-IP Extended Community. Together, these form the explicit (Color, Endpoint) tuple used as the binding key [RFC9256]. * The headend MUST perform a lookup in its local SR Policy database using the (Color, Endpoint) tuple strictly per Section 8.8.1 of [RFC9256] to resolve an active, valid SR Policy Candidate Path. Jiang, et al. Expires 22 February 2027 [Page 8] Internet-Draft FlowSpec with SR Policy August 2026 * The BGP Prefix-SID Attribute, if present (Mode 2), SHALL NOT be used as part of the SR Policy database lookup key. It is extracted exclusively to provide the egress service decapsulation context during segment list synthesis. 4. Forwarding Action Installation & Encapsulation Synthesis: If a matching active SR Policy candidate path is successfully resolved: a. The default Longest-Prefix-Match (LPM) lookup prescribed in [I-D.ietf-idr-flowspec-redirect-ip] SHALL NOT be performed. b. Mode 1: The headend MUST program its forwarding plane to encapsulate matching traffic using strictly the active Segment List of the resolved SR Policy. c. Mode 2: The headend MUST synthesize the active encapsulation segment list by stitching the resolved SR Policy Segment List and the Egress SRv6 Service SID, in strict adherence to Section 5 of [RFC9252]. Specifically: - When the headend device determines (with the help of the SRv6 SID Structure Sub-Sub-TLV [RFC9252]) that the Egress SRv6 Service SID belongs to the same SRv6 Locator as the last SRv6 SID of the tailend device in the resolved SRv6 Policy segment list, it MAY omit/ replace the Endpoint SID with the Egress Service SID when steering the service flow (e.g., replacing segment list with ). - Otherwise, the Egress SRv6 Service SID MUST be appended to the resolved SR Policy segment list (e.g., ). d. Coexisting FlowSpec Actions: Non-steering FlowSpec actions present in the same route (such as Traffic-Rate policing or drop per [RFC8955]) MUST be applied to matching traffic regardless of the steering resolution or programming state, unless local policy explicitly dictates otherwise. 5. Control Plane Route Retention and Propagation Rules: If a FlowSpec route carrying SR Policy attributes cannot be bound to an active, valid SR Policy in the local SR Database, or if its steering entry cannot be installed into the forwarding plane: Jiang, et al. Expires 22 February 2027 [Page 9] Internet-Draft FlowSpec with SR Policy August 2026 a. BGP Route Status: The receiving BGP speaker MUST NOT discard, withdraw, or mark the BGP FlowSpec route as BGP- Invalid solely due to the absence or uninstantiated state of a matching SR Policy or a forwarding programming failure. If the BGP UPDATE message and its attributes pass standard syntactic validation [RFC7606][RFC8955], the route SHALL be considered BGP-Valid and retained in the BGP Loc-RIB. b. Best-Path Selection: The route MUST remain eligible for the BGP best-path selection process per standard decision rules [RFC4271][RFC8955]. c. Propagation: If selected as the best path, the BGP speaker MUST propagate the FlowSpec route along with its attached steering attributes to other BGP peers according to local policy and standard BGP propagation rules. d. Data Plane Steering Failure Enforcement: The headend router MUST decouple control plane route propagation from data plane steering. While the route is safely retained and propagated in the control plane, the data plane traffic filtering actions for packets matching the FlowSpec NLRI SHALL be handled strictly according to the steering failure and fallback procedures defined in Section 3.7 and Section 4. 3.4. Interaction with Redirect-to-IP Extended Community When a FlowSpec route carries both a valid Color Extended Community [RFC9012] and a Redirect-to-IP (or Redirect-to-IPv6) Extended Community [I-D.ietf-idr-flowspec-redirect-ip]: * Syntactic Validation and Attribute Reuse: The receiving router MUST perform syntactic and structural validation of the Redirect- to-IP Extended Community according to [I-D.ietf-idr-flowspec-redirect-ip]. However, the target IP address in the Redirect-to-IP Extended Community SHALL be interpreted strictly as the Endpoint of the target SR Policy, forming the explicit (Color, Endpoint) tuple [RFC9256]. Jiang, et al. Expires 22 February 2027 [Page 10] Internet-Draft FlowSpec with SR Policy August 2026 * Precedence and Supersedence of Forwarding Behavior: In accordance with Section 2.2.2 of [I-D.ietf-idr-flowspec-redirect-ip], the SR Policy steering procedures defined in this specification take precedence over, and explicitly SUPERSEDE, the default forwarding behavior specified in Section 2.2 of [I-D.ietf-idr-flowspec-redirect-ip]. The standard Longest-Prefix- Match (LPM) lookup toward the target IP address SHALL NOT be performed. Instead, matching traffic MUST be steered into the SR Policy resolved by the (Color, Endpoint) tuple. If a FlowSpec route carries multiple Color Extended Communities, the preference rule among multiple colors, as well as the fallback mechanism to the next-highest numerical color value when the highest- color SR Policy is uninstantiated or inactive, follows the procedures specified in Section 8.4.1 of [RFC9256]. 3.5. Scope Exceptions and Explicit Constraints 3.5.1. Scope regarding Color-Only (CO) Steering Steering procedures based on Color-Only (CO) flags (as defined in [RFC9830] and Section 8.8.1 of [RFC9256]) are outside the scope of this document. The steering mechanism specified in this document strictly requires an explicit (Color, Endpoint) tuple. If a receiving router encounters a FlowSpec route with non-zero CO bits in the Color Extended Community, the receiver SHALL treat the Color Extended Community as if CO bits were zero (i.e., explicit Endpoint matching) and attempt to process the route using the explicit (Color, Endpoint) matching procedure. If no matching SR Policy exists for the specified (Color, Endpoint) tuple, the route SHALL be handled according to the steering failure procedures in Section 3.7. 3.5.2. Scope regarding VPN FlowSpec and Redirect-to-VRF BGP VPN FlowSpec address families (SAFI=134) and interaction with the Redirect-to-VRF Extended Community [RFC8955][RFC8956] are outside the scope of this specification. If a receiving router encounters a VPN FlowSpec route (SAFI=134) or a FlowSpec route containing a Redirect-to-VRF Extended Community for SR Policy steering, such routes MUST NOT be processed according to the procedures in this specification. Jiang, et al. Expires 22 February 2027 [Page 11] Internet-Draft FlowSpec with SR Policy August 2026 3.6. BGP Prefix-SID Attribute Encoding Rules The BGP Prefix-SID Attribute is used in this specification strictly for conveying SRv6 Service SIDs in SRv6 Mode 2 (Section 3.1.2). For SR-MPLS scenarios, the BGP Prefix-SID Attribute SHALL NOT be attached. When the BGP Prefix-SID Attribute is attached to a FlowSpec route in an SRv6 environment, the following encoding rules apply per [RFC9252] and [RFC8986]: * SRv6 Service TLVs: The SRv6 L3 Service TLV (Type 5) [RFC9252] SHALL be used to convey the egress service action. * Sub-TLVs: The SRv6 SID Information Sub-TLV (Type 1) SHALL be included within the SRv6 Service TLV. The SRv6 SID Structure Sub- Sub-TLV (Type 1) [RFC9252] MAY be included to specify the SRv6 Locator and SID structure [RFC8986]. * Supported Endpoint Behaviors: The SRv6 Service SID Endpoint Behavior codepoints supported for FlowSpec egress service steering are restricted to Layer 3 behaviors defined in [RFC8986], including End.DT4, End.DT6, End.DT46, End.DX4, and End.DX6. Layer 2 behaviors (e.g., End.DX2, End.DT2M) and transit/underlay behaviors (e.g., End, End.X) SHALL NOT be used for FlowSpec egress service steering under this specification. * Disallowance of Transposition Scheme: [RFC9252] Section 4 defines a Transposition Scheme where part of the SRv6 SID is transposed into the MPLS Label field of the BGP NLRI. Because FlowSpec NLRIs [RFC8955][RFC8956] do not carry an MPLS Label field, the Transposition Scheme SHALL NOT be used. The full SRv6 Service SID MUST be encoded entirely within the SRv6 SID Information Sub-TLV of the BGP Prefix-SID Attribute. 3.7. Steering Failure and Fallback Procedures If a receiving headend router cannot steer matching traffic into an SR Policy for a FlowSpec route carrying a Color Extended Community and a Redirect-to-IP Extended Community - due to any of the conditions defined in Section 4 (such as an uninstantiated matching SR Policy, an invalid Prefix-SID attribute per [RFC9252], or forwarding programming resource exhaustion) - the router MUST handle matching traffic according to local steering failure policies and Section 4.3. Standard fallback actions MAY include, in order of administrative preference: Jiang, et al. Expires 22 February 2027 [Page 12] Internet-Draft FlowSpec with SR Policy August 2026 1. Fallback Color Evaluation: If the FlowSpec route carries multiple Color Extended Communities, evaluate the remaining colors in descending numerical order per Section 8.4.1 of [RFC9256]. 2. Native/Default Path Forwarding: Forward matching traffic using the normal IP/MPLS routing table lookup toward the packet's original destination address. 3. Traffic Drop: Silently drop matching traffic if configured by policy for strict traffic isolation or anti-leak enforcement. 3.8. Load Balancing Considerations When traffic matching a BGP FlowSpec rule is steered into an SR Policy (under either Mode 1 or Mode 2), the target SR Policy may contain multiple active Segment Lists for multi-path load balancing (ECMP or UCMP) as specified in [RFC9256]. 1. Flow Spec to SR Policy Mapping: The FlowSpec rule classifies matching packets and directs them into the resolved SR Policy as a single aggregate traffic stream. The FlowSpec filtering actions MUST NOT alter or bypass the selection of Segment Lists within that SR Policy. 2. Multi-Path ECMP/UCMP Hashing: When the target SR Policy consists of multiple candidate Segment Lists with equal or unequal weights: - The headend router MUST distribute the matched FlowSpec traffic across all active Segment Lists according to their defined weights. - For both SR-MPLS and SRv6 data planes, the multipath hash calculation MUST be performed using the packet's inner header fields (e.g., 5-tuple) to ensure symmetric and fine- grained per-flow load balancing. 3. SRv6 Flow Label Generation (RFC 8754 Alignment): In SRv6 steering scenarios (including Mode 1 and Mode 2 with SID stitching): - The generation of the Flow Label field in the outer IPv6 header MUST NOT be affected or overwritten by the FlowSpec matching rule. Jiang, et al. Expires 22 February 2027 [Page 13] Internet-Draft FlowSpec with SR Policy August 2026 - The headend node MUST compute and assign the outer IPv6 Flow Label based on a hash of the inner packet header fields in full accordance with Section 5.1 of [RFC8754]. - Preserving independent, inner-flow-based IPv6 Flow Label generation is essential to prevent Hash Polarization and packet drops at downstream intermediate P routers performing ECMP over outer IPv6 headers. 3.9. Backward Compatibility and Coexistence with Base BGP FlowSpec This specification defines extensions to the processing of BGP FlowSpec routes when carrying a combination of the Color Extended Community [RFC9012], Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip], and the BGP Prefix-SID Attribute [RFC9252]. A BGP speaker receiving a FlowSpec route constructed under this specification MUST process and propagate the attributes according to its capability level as follows: 1. Local Behavior at a Non-Supporting Receiver: If a receiving headend router supports base BGP FlowSpec [RFC8955][RFC8956] and the Redirect-to-IP Extended Community, but does not support this specification or the BGP Prefix-SID Attribute in the context of FlowSpec, it MUST ignore the unrecognized BGP Prefix-SID Attribute. The receiver SHALL fall back to processing the Redirect-to-IP Extended Community according to standard procedures (e.g., performing a Longest- Prefix-Match lookup toward the target IP address per [I-D.ietf-idr-flowspec-redirect-ip]). 2. Attribute Propagation and Control Plane Filtering: In accordance with standard BGP Optional Transitive attribute handling rules [RFC4271], a BGP speaker that does not support the BGP Prefix-SID Attribute MUST propagate the attribute un- modified to other BGP peers, setting the Partial bit in the attribute flags. Furthermore, implementations supporting the signalling defined in this document MUST comply with the following operational control rules: Jiang, et al. Expires 22 February 2027 [Page 14] Internet-Draft FlowSpec with SR Policy August 2026 - Attribute Filtering: Attribute filtering and propagation policies for the BGP Prefix-SID Attribute MUST follow Section 5 of [RFC8669]. - Neighbor and Service Granularity Control: In strict adherence to Section 3.2.1 of [RFC9252], implementations MUST provide a control mechanism to enable or disable the advertisement of SRv6-based service steering attributes on a per-neighbor and per-service basis. 4. Multi-Attribute Interworking and Steering Resolution The steering mechanism defined in this document relies on the co- existence of up to three distinct BGP attributes attached to a BGP FlowSpec route [RFC8955][RFC8956]: 1. Color Extended Community [RFC9012] 2. Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip] 3. BGP Prefix-SID Attribute [RFC9252] To guarantee deterministic and interoperable behavior across implementations, the receiving headend router MUST evaluate all incoming combinations strictly according to the procedures defined in this section. 4.1. Policy-Based Steering Classification Architecturally, traffic steering resulting from the matching of a BGP FlowSpec route corresponds strictly to Policy-Based Routing (PBR) / Policy-Based Steering as defined in Section 8.7 of [RFC9256]. FlowSpec steering SHALL NOT be interpreted or implemented as per- destination steering (Section 8.4 of [RFC9256]). Implementations MUST NOT apply per-destination route-resolution mechanics, BGP multipath path resolution, or On-Demand BSID recursion [RFC9256] to BGP FlowSpec route processing. Jiang, et al. Expires 22 February 2027 [Page 15] Internet-Draft FlowSpec with SR Policy August 2026 4.2. Deterministic Interworking Matrix Upon receiving a BGP FlowSpec route, the headend router MUST evaluate the syntactic and semantic validity of the steering attributes and execute the corresponding steering outcome, non-steering action disposition, and diagnostic requirements defined in Table 1. Legend: Color = Color EC; ReIP = Redirect-to-IP EC; PSID = BGP Prefix-SID Attribute; V = Valid; I = Invalid; A = Absent; * = Any (V/I/A). V(L3) = Valid L3 Service SID (e.g., End.DT4/6/DX4/6/DT46); [flowspec-redirect] = [I-D.ietf-idr-flowspec-redirect-ip]. Table 1: Deterministic Multi-Attribute Interworking and Action Resolution Matrix +---+-------+------+-------+-------------------------+-------------+ |R# | Color | ReIP | PSID | Steering Action Outcome | Diagnostics | +---+-------+------+-------+-------------------------+-------------+ | 1 | V | V | A | Mode 1 SR Policy | None | | | | | | Steering (Sec 3.1.1) | | +---+-------+------+-------+-------------------------+-------------+ | 2 | V | V | V(L3) | Mode 2 SR Policy | None | | | | | | Steering (Sec 3.1.2) | | +---+-------+------+-------+-------------------------+-------------+ | 3 | V | V | I | Steering Failure: NO | Log: Invalid| | | | | | Policy & NO ReIP Fallbk | Service SID | +---+-------+------+-------+-------------------------+-------------+ | 4 | I | V | * | Steering Failure: Abort | Log: Invalid| | | | | | Steering Actions | Color EC | +---+-------+------+-------+-------------------------+-------------+ | 5 | V | I | * | Steering Failure: Abort | Log: Invalid| | | | | | Steering Actions | ReIP Target | +---+-------+------+-------+-------------------------+-------------+ | 6 | A | V | A/I | Base ReIP Forwarding | None | | | | | | per [flowspec-redirect] | | +---+-------+------+-------+-------------------------+-------------+ | 7 | A | A/I | * | NO Steering Action; | None | | | | | | Native Shortest Path | | +---+-------+------+-------+-------------------------+-------------+ Note: Non-steering actions (e.g., rate-limit, drop) attached to the route MUST be applied in all rows (Rows 1-7). Jiang, et al. Expires 22 February 2027 [Page 16] Internet-Draft FlowSpec with SR Policy August 2026 4.3. Protection Against Silent SLA Violations To prevent unintentional redirection and catastrophic SLA violations, implementations MUST strictly enforce the following operational rules: 1. Abortion of Redirection on Corrupted Intent (Table 1, Rows 3, 4, 5): If a FlowSpec route carries an explicit intent for SR Policy steering (indicated by the presence of a Color EC or Mode 2 Prefix-SID) but any required steering attribute is determined to be INVALID, the receiver MUST NOT perform default Redirect- to-IP forwarding. Silently falling back to shortest-path IP forwarding toward the target IP address is strictly PROHIBITED, as it violates explicit SLA steering policies. The matching traffic MUST be dropped or handled strictly according to local fallback policy (Section 3.7). 2. Enforcement of Coexisting Non-Steering Actions: In all failure or fallback cases (Table 1, Rows 3-7), other valid non- steering actions present in the same BGP FlowSpec route (such as Traffic- Rate/Drop [RFC8955], Rate-limiting, or DSCP remarking) MUST continue to be processed and enforced in the forwarding plane. 3. Multiple Redirect-to-IP Communities and Load-Sharing: When multiple valid Redirect-to-IP Extended Communities are attached to the same FlowSpec route alongside a valid Color Extended Community, the resolution and multi-path load-sharing across multiple target SR Policies (identified by their respective Endpoint IP addresses) MUST follow the EC-level load-sharing procedures defined in Section 2.2 of [I-D.ietf-idr-flowspec-redirect-ip]. 4. Logging and Diagnostics: Implementations SHOULD generate diagnostic log entries (as specified in Table 1) whenever an SR Policy steering route contains corrupted or invalid steering attributes to assist network operators in rapid fault isolation. Jiang, et al. Expires 22 February 2027 [Page 17] Internet-Draft FlowSpec with SR Policy August 2026 4.4. Backward Compatibility and Coexistence Behavior A BGP speaker receiving a FlowSpec route constructed under this specification MUST process and propagate the attributes according to its capability level: 1. Non-Supporting Headend Behavior: If a receiving headend router supports base BGP FlowSpec [RFC8955][RFC8956] and the Redirect-to-IP Extended Community, but does not support this specification or the BGP Prefix-SID Attribute in the context of FlowSpec, it MUST ignore the unrecognized BGP Prefix-SID Attribute. The receiver SHALL fall back to processing the Redirect-to-IP Extended Community according to standard procedures (e.g., performing a Longest- Prefix-Match lookup toward the target IP address per [I-D.ietf-idr-flowspec-redirect-ip]). 2. Attribute Propagation and Control Plane Filtering: In accordance with standard BGP Optional Transitive attribute handling rules [RFC4271], a BGP speaker that does not support the BGP Prefix-SID Attribute MUST propagate the attribute unmodified to other BGP peers, setting the Partial bit in the attribute flags. Furthermore, implementations supporting the signalling defined in this document MUST comply with the following operational control rules: - Attribute Filtering: Attribute filtering and propagation policies for the BGP Prefix-SID Attribute MUST follow Section 5 of [RFC8669]. - Neighbor and Service Granularity Control: In strict adherence to Section 3.2.1 of [RFC9252], implementations MUST provide a control mechanism to enable or disable the advertisement of SRv6-based service steering attributes on a per-neighbor and per-service basis. 5. Operational Considerations Jiang, et al. Expires 22 February 2027 [Page 18] Internet-Draft FlowSpec with SR Policy August 2026 5.1. Forwarding Failure Monitoring and Management When a headend router fails to program a FlowSpec SR Policy steering entry into the forwarding plane (Section 3.3), the implementation SHOULD make relevant diagnostic information available to network operators. * Logging and Notifications: The implementation SHOULD generate appropriate management notifications (e.g., Syslog messages, SNMP traps, or YANG notifications, if supported) detailing the uninstalled FlowSpec NLRI, the associated (Color, Endpoint) tuple, and the specific failure reason (e.g., resource exhaustion). * Resource Recovery and Re-programming: An implementation SHOULD monitor forwarding plane resource availability. When sufficient forwarding resources become available, the implementation SHOULD automatically re-attempt to program any previously uninstalled FlowSpec steering entries. Implementations SHOULD provide hardware or software counter metrics (e.g., byte/packet dropped counters) associated with uninstalled or failed FlowSpec steering entries for operational visibility. 6. Security Considerations The security considerations of the base BGP FlowSpec specifications [RFC8955] [RFC8956], BGP FlowSpec Redirect-to-IP [I-D.ietf-idr-flowspec-redirect-ip], BGP Prefix-SID [RFC8669], and the core Segment Routing architecture [RFC8402] apply to this document. Combining BGP FlowSpec redirection with SR Policy selection and SRv6 Service SID signaling introduces specific threat vectors that MUST be considered. Implementations and network operators MUST apply the mitigations described below. 6.1. Cross-VRF Traffic Injection and Service Hijacking Exposure: The BGP Prefix-SID Attribute carried in a FlowSpec route conveys an SRv6 Service SID (e.g., End.DT4, End.DT6, End.DT46, End.DX4, End.DX6) that determines the egress routing table, VRF, or interface context at the TailEnd PE. A malicious or misconfigured BGP FlowSpec Controller can utilize this mechanism to steer matched traffic into an arbitrary VRF or cross-connect interface at a remote PE, resulting in unauthorized cross-VRF data leakage or traffic interception. Jiang, et al. Expires 22 February 2027 [Page 19] Internet-Draft FlowSpec with SR Policy August 2026 Exploitation & Threat Actor: An attacker who compromises a BGP FlowSpec speaker or a misconfigured operator controller positioned within the control plane. Mitigations: * Strict Control Plane Filtering: PEs MUST validate that any SRv6 Service SID received in a BGP FlowSpec route belongs to an authorized Locator range allocated for the intended target VRF or service context. * Access Control: BGP FlowSpec peering sessions with controllers MUST be secured using TCP-AO [RFC5925] and restricted to trusted administrative entities. 6.2. Scope and Validation Limits of BGP FlowSpec Attributes Exposure: Standard BGP FlowSpec route validation mechanisms specified in [RFC8955][RFC8956][RFC9117] validate the FlowSpec NLRI and the Redirect-to-IP Extended Community against the originator of the destination prefix. However, these RFCs do not define validation rules for the Color Extended Community or the BGP Prefix-SID Attribute. Consequently, the two attributes that dictate the transport path selection and egress service context remain unvalidated by standard origin validation algorithms. Exploitation & Threat Actor: An internal or external entity capable of injecting or altering BGP attributes on BGP FlowSpec routes in transit. Mitigations: * Policy-based Validation: Headends MUST apply local policy checks to verify that the (Color, Endpoint) tuple resolves to a legitimately authorized SR Policy before binding FlowSpec traffic flows to it. * Attribute Filtering: Network operators MUST strip or reject unknown or unauthorized Color Extended Communities and BGP Prefix- SID Attributes on FlowSpec routes received from untrusted BGP peers. Jiang, et al. Expires 22 February 2027 [Page 20] Internet-Draft FlowSpec with SR Policy August 2026 6.3. SR Domain Leakage and Boundary Security Exposure: As detailed in [RFC8402] and [RFC8669], SRv6 SIDs and BGP Prefix-SID Attributes are intended for use strictly within a single trusted SR domain. If BGP FlowSpec routes carrying Prefix-SID Attributes propagate across administrative boundaries or untrusted EBGP peers without filtering, internal SRv6 Locator information and internal topology structures could leak, exposing the network to external steering attacks. Exploitation & Threat Actor: An external adversary on an adjacent untrusted AS or an insider exploiting missing boundary filters. Mitigations: * Border Filtering: Autonomous System Border Routers (ASBRs) MUST filter out or strip the BGP Prefix-SID Attribute and SRv6-related Extended Communities from BGP FlowSpec routes traversing administrative or trust boundaries, unless explicit inter-domain trust agreements and strict policy filters are enforced. 6.4. Traffic Amplification and Path Pinning Exposure: Per [RFC9117], a single BGP FlowSpec route can match high-volume distributed traffic flows across multiple Ingress PEs and redirect them to a single Redirect-to-IP destination (specifically via BGP FlowSpec Redirect-to-IP fan-in/fan-out aggregate behavior). Binding such redirected flows to an SR Policy does not mitigate this amplification and concentration effect; instead, it allows an attacker to pin the amplified traffic to a specific engineered transport path, potentially overloading transit nodes along the SR Policy path or target interfaces at the TailEnd device. Exploitation & Threat Actor: A compromised controller or malicious BGP speaker attempting a Denial of Service (DoS) attack against specific network links or egress PEs. Mitigations: Jiang, et al. Expires 22 February 2027 [Page 21] Internet-Draft FlowSpec with SR Policy August 2026 * Rate Limiting: Ingress PEs SHOULD combine FlowSpec redirect actions with Traffic Rate Extended Communities (Traffic-Policing) [RFC8955] to bound the maximum bandwidth redirected into an SR Policy. * Policy Monitoring: Operators SHOULD implement telemetry and path utilization monitoring on SR Policies used for FlowSpec traffic steering to dynamically detect and mitigate link congestion. 7. Application Examples (Informative) This section provides illustrative examples for steering BGP FlowSpec traffic into SR Policies in both SR-MPLS and SRv6 environments, following the normative procedures specified in Section 3 and Section 4. 7.1. SR-MPLS Application Examples (Mode 1) Figure 1 illustrates a scenario where a BGP FlowSpec Controller signals steering instructions for an SR-MPLS network to a Headend device (Ingress PE). In the following scenarios shown in Figure 1, BGP FlowSpec Controller signals the filter rules, the Flow-spec Redirect to IPv4/IPv6 action, and the policy color to the SR-MPLS HeadEnd device. +------------+ | BGP FS | | Controller | +------------+ | FlowSpec route to HeadEnd: | NLRI: Filter Rules | Redirect-to-IP Extended Community: TailEnd Address | Color Extended Community: C0 | (Prefix-SID Attribute: ABSENT) | .-----. | ( ) V .--( )--. +-------+ ( ) +-------+ | |_( SR-MPLS Network )_| | |HeadEnd| ( ================> ) |TailEnd| +-------+ (SR List) +-------+ '--( )--' ( ) '-----' Jiang, et al. Expires 22 February 2027 [Page 22] Internet-Draft FlowSpec with SR Policy August 2026 Figure 1: Steering Traffic into SR-MPLS Policy (Mode 1) In this Mode 1 scenario (Section 3.1.1): * Control Plane Signalling: The BGP FS Controller advertises a FlowSpec route carrying matching rules, Redirect-to-IP (TailEnd Address), and Color Extended Community C0. The BGP Prefix-SID Attribute is ABSENT. * Headend Processing: The Headend resolves the target SR-MPLS Policy matching the tuple (Endpoint: TailEnd, Color: C0). * Data Plane Encapsulation: Matching traffic flows are encapsulated strictly using the MPLS label stack corresponding to the resolved SR Policy segment list: +---------------------------------------------+ | Outer IP / Ethernet Header | +---------------------------------------------+ | MPLS Label S1 (Top) | | MPLS Label S2 | | MPLS Label S3 (Bottom with S=1) | +---------------------------------------------+ | Inner Payload (Original IPv4/IPv6 Packet) | +---------------------------------------------+ Decapsulation or label popping at the TailEnd device relies on standard MPLS segment behaviors (e.g., Penultimate Hop Popping or Implicit Null). When the SR-MPLS HeadEnd device (as a FlowSpec client) receives such instructions from BGP FS Controller, it will steer the traffic flows matching the criteria in the FlowSpec route into the SR-MPLS Policy matching the tuple (Endpoint: TailEnd's Address, Color: C0). And the packets of such traffic flows will be encapsulated with an MPLS stack using the SR List in the HeadEnd device, then send the packets to the TailEnd device along the path indicated by the SR list. Jiang, et al. Expires 22 February 2027 [Page 23] Internet-Draft FlowSpec with SR Policy August 2026 7.2. SRv6 Application Examples In SRv6 networks, FlowSpec traffic steering operates under either Mode 2 (Transport Steering with Egress Service Action) or Mode 1 (Transport Steering Only). 7.2.1. SRv6 Mode 2 Example: Transport Steering with Egress Service Action In the scenario shown in Figure 2, the BGP FlowSpec Controller signals filter rules, transport steering parameters, and an explicit egress service action to the Headend device. The `Egress_Service_SID` carried in the BGP Prefix-SID Attribute represents an SRv6 Endpoint Behavior instantiated and advertised by the TailEnd router (Egress PE) within its local SRv6 Locator block. Depending on the service context, `Egress_Service_SID` can be instantiated as End.DT4, End.DX4, End.DT6, End.DX6, or End.DT46 (Section 3.6). +------------+ | BGP FS | | Controller | +------------+ | FlowSpec route to HeadEnd: | NLRI: Filter Rules | Redirect-to-IPv6 Extended Community: TailEnd Address | Color Extended Community: C1 | Prefix-SID Attribute: Egress_Service_SID | .-----. | ( ) V .--( )--. +-------+ ( ) +-------+ | |_( SRv6 Core Network )_| | |HeadEnd| ( ================> ) |TailEnd| +-------+ (SR List) +-------+ '--( )--' SRv6 SID: Egress_Service_SID ( ) (e.g., End.DT4, End.DT6, etc.) '-----' Figure 2: Steering Traffic into SRv6 Policy with Egress Service Action (Mode 2) In this Mode 2 scenario (Section 3.1.2): * Control Plane Signalling & Resolution: Jiang, et al. Expires 22 February 2027 [Page 24] Internet-Draft FlowSpec with SR Policy August 2026 The FlowSpec route carries Color C1, Redirect-to-IPv6 (TailEnd Address), and the BGP Prefix-SID Attribute carrying `Egress_Service_SID`. The Headend resolves the target SRv6 Policy using the (Color C1, TailEnd Address) tuple, which yields candidate Segment List . * Segment List Synthesis & Encapsulation: Per Section 3.3 (Step 4.c), the Headend synthesizes the active segment list by inspecting the SRv6 SID Structure Sub-Sub-TLV [RFC9252]: o Scenario A (SID Replacement / Locator Match): When `Egress_Service_SID` belongs to the same SRv6 Locator as S3 (the last SID of the TailEnd in the policy), the Headend excludes S3 and replaces it with `Egress_Service_SID`. The synthesized segment list becomes . +---------------------------------------------------+ | Outer IPv6 Header (DA = S1) | +---------------------------------------------------+ | SRH (Segments Left = 2) | | Segment List: | +---------------------------------------------------+ | Inner Payload (Original IPv4/IPv6 Packet) | +---------------------------------------------------+ o Scenario B (SID Appending / No Locator Match): Otherwise, `Egress_Service_SID` is appended to the segment list, yielding . +---------------------------------------------------+ | Outer IPv6 Header (DA = S1) | +---------------------------------------------------+ | SRH (Segments Left = 3) | | Segment List: | +---------------------------------------------------+ | Inner Payload (Original IPv4/IPv6 Packet) | +---------------------------------------------------+ Upon reaching the TailEnd device, the packet is decapsulated and processed per the function denoted by `Egress_Service_SID` (e.g., VRF lookup for End.DT4). Jiang, et al. Expires 22 February 2027 [Page 25] Internet-Draft FlowSpec with SR Policy August 2026 7.2.2. SRv6 Mode 1 Example: Transport Steering Only (USD-Flavored End SID) When matching traffic requires steering into an SRv6 Policy toward a TailEnd, and the final SID (S3) configured on the TailEnd is USD- flavored, an explicit Egress Service SID is not required. Figure 3 illustrates this scenario. +------------+ | BGP FS | | Controller | +------------+ | FlowSpec route to HeadEnd: | NLRI: Filter Rules | Redirect-to-IPv6 Extended Community: TailEnd Address | Color Extended Community: C2 | (Prefix-SID Attribute: ABSENT) | .-----. | ( ) V .--( )--. +-------+ ( ) +-------+ | |_( SRv6 Core Network )_| | |HeadEnd| ( ================> ) |TailEnd| +-------+ (SR List) +-------+ '--( )--' ( ) '-----' Note: S3 is an SRv6 SID with USD flavor on the TailEnd. Figure 3: Steering Traffic into SRv6 Policy (Mode 1) In this Mode 1 scenario (Section 3.1.1): * Control Plane & Data Plane Processing: The BGP FS Controller advertises the FlowSpec route carrying Color C2 and Redirect-to-IPv6 (TailEnd Address) without attaching the BGP Prefix-SID Attribute. The Headend encapsulates matching traffic with an SRH using Segment List . * TailEnd Processing: As specified in Section 3.1.1, because S3 is an SRv6 SID with USD flavor [RFC8986], the TailEnd device executes the USD behavior upon packet arrival, pops the outer IPv6 header and SRH, and forwards the inner packet using normal table lookup. Jiang, et al. Expires 22 February 2027 [Page 26] Internet-Draft FlowSpec with SR Policy August 2026 7.2.3. Deployment Considerations The FlowSpec traffic steering mechanisms defined in this document apply within a single SR trusted domain (e.g., an intra-AS deployment under a single administrative control). In this deployment model, the Headend router resolves the explicit (Color, Endpoint) tuple provided by the FlowSpec route against a locally instantiated SR Policy (e.g., an SRv6 Policy with Segment List scoped within the domain). The propagation and handling of the BGP Prefix-SID Attribute and Extended Communities MUST adhere to the security and trust boundary guidelines specified in Section 6 (Security Considerations). 8. Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to [RFC7942]. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 8.1. Interop-test Status The Traffic Steering using BGP FlowSpec with SR-MPLS / SRv6 Policy mechanism has been implemented on the following hardware devices, Network Operating System software, and SDN controllers. They have also successfully participated in a series of joint interoperability testing events hosted by China Mobile from July 2021 to October 2021. The following hardware devices and Network Operating System software passed the interoperability testing (in alphabetical order). Jiang, et al. Expires 22 February 2027 [Page 27] Internet-Draft FlowSpec with SR Policy August 2026 Routers: +---------+---------------+--------------------------------+ | Vendors | Device Model | Version | +---------+---------------+--------------------------------+ | Huawei | NE40-X8A | NE40E V800R021C00SPC091T | +---------+---------------+--------------------------------+ | New H3C | CR16010H-FA | Version 7.1.075, ESS 8305 | +---------+---------------+--------------------------------+ | Ruijie | RG-N8010-R | N8000-R_RGOS 12.8(1)B08T1 | +---------+---------------+--------------------------------+ | ZTE | M6000-8S Plus | V5.00.10(5.60.5) | +---------+---------------+--------------------------------+ Controllers: +----------------+---------------+-------------------------+ | Vendors | Device Model | Version | +----------------+---------------+-------------------------+ | China Unitechs | I-T-E SC | V1.3.6P3 | +----------------+---------------+-------------------------+ | Huawei | NCE-IP | V100R021C00 | +----------------+---------------+-------------------------+ | Ruijie | RG-ONC-AIO-H | RG-ION-WAN-CLOUD_2.00T1 | +----------------+---------------+-------------------------+ | ZTE | ZENIC ONE | R22V16.21.20 | +----------------+---------------+-------------------------+ 8.2. Deployment Status As of August 2022, this feature has been deployed on the IP backbone network of China Mobile. China Mobile has fully transitioned to the SRv6 architecture, with no scenarios where SRv6 and SR-MPLS coexist. As a result, when utilizing Color C and IPv6 redirect addresses, traffic steering is executed exclusively via SRv6 policies. In scenarios where an operator supports the coexistence of SRv6 and SR-MPLS, it is recommended to adhere to [RFC9256] to govern policy selection for traffic steering based on Color C and IPv6 endpoints. 9. IANA Considerations This document requires no IANA actions. Jiang, et al. Expires 22 February 2027 [Page 28] Internet-Draft FlowSpec with SR Policy August 2026 10. Contributors The following people made significant contributions to this document: Yunan Gu Huawei Technologies Email: guyunan@huawei.com Haibo Wang Huawei Technologies Email: rainsword.wang@huawei.com Jie Dong Huawei Technologies Email: jie.dong@huawei.com Xue Yang China Mobile Email: yangxuewl@chinamobile.com 11. Acknowledgements The authors would like to express special thanks to: * Nat Kao for suggesting the inclusion of SR-MPLS use cases and providing detailed recommendations regarding failure and fallback procedures. * Ketan Talaulikar for his in-depth review and valuable input, which substantially enhanced the precision and overall quality of this document. * Donald E. Eastlake, 3rd for his thorough review and insightful suggestions. The authors also gratefully acknowledge the review, comments, and contributions from Jeffrey Haas, Susan Hares, Keyur Patel, Weiqiang Cheng, Kaliraj Vairavakkalai, Robin Li, Acee Lindem, Gunter Van De Velde, John Scudder, Rainbow Wu, Linda Dunbar, Gang Yan, Feng Yang, Wim Henderickx, Robert Raszuk, Changwang Lin, Aijun Wang, Hao Li, Huaimo Chen, Sheng Fang, Yuanxiang Qiu, Ran Chen, Cheng Li, Zheng Zhang, Xuewei Wang, Yanrong Liang, Xuhui Cai, Haojie Wang, Lili Wang, Nan Geng, Stephane Litkowski, Zhenqiang Li, Jinming Li, Shengnan Yue, and Ziqing Cao. 12. References Jiang, et al. Expires 22 February 2027 [Page 29] Internet-Draft FlowSpec with SR Policy August 2026 12.1. Normative References [I-D.ietf-idr-flowspec-redirect-ip] Haas, J., Henderickx, W., and A. Simpson, "BGP Flow-Spec Redirect-to-IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-16, 21 May 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . Jiang, et al. Expires 22 February 2027 [Page 30] Internet-Draft FlowSpec with SR Policy August 2026 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, . [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, . [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, . [RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2021, . [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . 12.2. Informative References [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . Jiang, et al. Expires 22 February 2027 [Page 31] Internet-Draft FlowSpec with SR Policy August 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025, . [RFC9862] Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", RFC 9862, DOI 10.17487/RFC9862, October 2025, . Authors' Addresses Wenying Jiang China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: jiangwenying@chinamobile.com Yisong Liu China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: liuyisong@chinamobile.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Jiang, et al. Expires 22 February 2027 [Page 32] Internet-Draft FlowSpec with SR Policy August 2026 Email: zhuangshunwan@huawei.com Gyan Mishra Verizon Communications Inc. 13101 Columbia Pike Silver Spring, MD 20904, United States of America Email: gyan.s.mishra@verizon.com Shuanglong Chen Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: chenshuanglong@huawei.com Jiang, et al. Expires 22 February 2027 [Page 33]