Traffic Steering using BGP FlowSpec with SR Policy

Segment Routing (SR) leverages the source routing paradigm for both SR-MPLS and SRv6 . An SR Policy defines an explicit ordering of segments to steer traffic through a network, where candidate paths may be signaled via protocols such as BGP or PCEP , or instantiated locally. , and define the BGP 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 . Rules (Actions associated) are encoded in Extended Community attributes . 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. This document specifies extensions to BGP Flow Specification (FlowSpec) to steer matching traffic flows into a Segment Routing (SR) Policy . This document does not modify the base Segment Routing architecture or SR Policy constructs , but rather establishes the interworking protocol semantics between BGP FlowSpec controllers and SR Headends on the Standards Track.

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. USD: Ultimate Segment Decapsulation

BGP FlowSpec NLRI 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 in either SR-MPLS or SRv6 data planes. This specification relies on a two-tier control plane architecture: Transport Steering: The Color Extended Community is combined with the FlowSpec Redirect-to-IP Extended Community 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) . 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 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).

The traffic steering mechanism specified in this document relies on BGP FlowSpec filtering rules to perform flow-based policy encapsulation into SR Policies . Architecturally, FlowSpec-based steering corresponds strictly to Policy-Based Routing (PBR) steering as defined in Section 8.7 of . It SHALL NOT be interpreted or implemented as per-destination steering (Section 8.4 of ). Implementations MUST NOT apply per-destination route-resolution mechanics, BGP multipath path resolution, or On-Demand BSID recursion 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:

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 and a Redirect-to-IP (or Redirect-to-IPv6) Extended Community . 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.

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 , a Redirect-to-IP (or Redirect-to-IPv6) Extended Community , AND the BGP Prefix-SID Attribute . 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 and .

A BGP speaker or controller originating or re-advertising a FlowSpec route to steer traffic into an SR Policy MUST perform the following operations: Determine the explicit (Color, Endpoint) tuple required for transport steering. Attach the corresponding Color Extended Community and set the target IP address in the Redirect-to-IP (or Redirect-to-IPv6) Extended Community to match the SR Policy Endpoint. 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. 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.

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 , 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: Base NLRI & Attribute Syntactic Validation: The receiver MUST validate the FlowSpec NLRI against the base rules defined in . If NLRI validation fails, BGP error handling per applies. Syntactic attribute errors (e.g., malformed BGP Prefix-SID Attribute or Extended Communities) MUST be handled according to BGP Error Handling rules (e.g., Treat-as-Withdraw). Steering Mode Determination and Attribute Interworking Validation: The headend MUST evaluate the co-existing steering attributes for correct interworking and mode determination: 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). 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) . 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. 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 . The headend MUST perform a lookup in its local SR Policy database using the (Color, Endpoint) tuple strictly per Section 8.8.1 of to resolve an active, valid SR Policy Candidate Path. 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. Forwarding Action Installation & Encapsulation Synthesis: If a matching active SR Policy candidate path is successfully resolved: The default Longest-Prefix-Match (LPM) lookup prescribed in SHALL NOT be performed. Mode 1: The headend MUST program its forwarding plane to encapsulate matching traffic using strictly the active Segment List of the resolved SR Policy. 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 . Specifically: When the headend device determines (with the help of the SRv6 SID Structure Sub-Sub-TLV ) 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 <S1, S2, S3> with <S1, S2, Egress_Service_SID>). Otherwise, the Egress SRv6 Service SID MUST be appended to the resolved SR Policy segment list (e.g., <S1, S2, S3, Egress_Service_SID>). Coexisting FlowSpec Actions: Non-steering FlowSpec actions present in the same route (such as Traffic-Rate policing or drop per ) MUST be applied to matching traffic regardless of the steering resolution or programming state, unless local policy explicitly dictates otherwise. 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: 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 , the route SHALL be considered BGP-Valid and retained in the BGP Loc-RIB. Best-Path Selection: The route MUST remain eligible for the BGP best-path selection process per standard decision rules . 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. 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.

When a FlowSpec route carries both a valid Color Extended Community and a Redirect-to-IP (or Redirect-to-IPv6) Extended Community : Syntactic Validation and Attribute Reuse: The receiving router MUST perform syntactic and structural validation of the Redirect-to-IP Extended Community according to . 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 . Precedence and Supersedence of Forwarding Behavior: In accordance with Section 2.2.2 of , 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 . 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 .

Steering procedures based on Color-Only (CO) flags (as defined in and Section 8.8.1 of ) 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.

BGP VPN FlowSpec address families (SAFI=134) and interaction with the Redirect-to-VRF Extended Community 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.

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 and : SRv6 Service TLVs: The SRv6 L3 Service TLV (Type 5) 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) MAY be included to specify the SRv6 Locator and SID structure . Supported Endpoint Behaviors: The SRv6 Service SID Endpoint Behavior codepoints supported for FlowSpec egress service steering are restricted to Layer 3 behaviors defined in , 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: 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 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.

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 , 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: 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 . Native/Default Path Forwarding: Forward matching traffic using the normal IP/MPLS routing table lookup toward the packet's original destination address. Traffic Drop: Silently drop matching traffic if configured by policy for strict traffic isolation or anti-leak enforcement.

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

This specification defines extensions to the processing of BGP FlowSpec routes when carrying a combination of the Color Extended Community , Redirect-to-IP Extended Community , and the BGP Prefix-SID Attribute . A BGP speaker receiving a FlowSpec route constructed under this specification MUST process and propagate the attributes according to its capability level as follows: Local Behavior at a Non-Supporting Receiver: If a receiving headend router supports base BGP FlowSpec 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 ). Attribute Propagation and Control Plane Filtering: In accordance with standard BGP Optional Transitive attribute handling rules , 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: Attribute Filtering: Attribute filtering and propagation policies for the BGP Prefix-SID Attribute MUST follow Section 5 of . Neighbor and Service Granularity Control: In strict adherence to Section 3.2.1 of , 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.

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 : Color Extended Community Redirect-to-IP Extended Community BGP Prefix-SID Attribute 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.

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 . FlowSpec steering SHALL NOT be interpreted or implemented as per-destination steering (Section 8.4 of ). Implementations MUST NOT apply per-destination route-resolution mechanics, BGP multipath path resolution, or On-Demand BSID recursion to BGP FlowSpec route processing.

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.

To prevent unintentional redirection and catastrophic SLA violations, implementations MUST strictly enforce the following operational rules: 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). 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 , Rate-limiting, or DSCP remarking) MUST continue to be processed and enforced in the forwarding plane. 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 . 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.

A BGP speaker receiving a FlowSpec route constructed under this specification MUST process and propagate the attributes according to its capability level: 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 ). Attribute Propagation and Control Plane Filtering: In accordance with standard BGP Optional Transitive attribute handling rules , 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 . Neighbor and Service Granularity Control: In strict adherence to Section 3.2.1 of , 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.

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.

The security considerations of the base BGP FlowSpec specifications [RFC8955] [RFC8956], BGP FlowSpec Redirect-to-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.

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. 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 and restricted to trusted administrative entities.

Exposure: Standard BGP FlowSpec route validation mechanisms specified in 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.

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.

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: Rate Limiting: Ingress PEs SHOULD combine FlowSpec redirect actions with Traffic Rate Extended Communities (Traffic-Policing) 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.

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.

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

) |TailEnd| +-------+ (SR List) +-------+ '--( )--' ( ) '-----' ]]> 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:

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 <S1, S2, S3> in the HeadEnd device, then send the packets to the TailEnd device along the path indicated by the SR list.

In SRv6 networks, FlowSpec traffic steering operates under either Mode 2 (Transport Steering with Egress Service Action) or Mode 1 (Transport Steering Only).

In the scenario shown in , 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).

) |TailEnd| +-------+ (SR List) +-------+ '--( )--' SRv6 SID: Egress_Service_SID ( ) (e.g., End.DT4, End.DT6, etc.) '-----' ]]> In this Mode 2 scenario (Section 3.1.2): Control Plane Signalling & Resolution: 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 <S1, S2, S3>. 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 : 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 <S1, S2, Egress_Service_SID>.

| +---------------------------------------------------+ | Inner Payload (Original IPv4/IPv6 Packet) | +---------------------------------------------------+ ]]> Scenario B (SID Appending / No Locator Match): Otherwise, `Egress_Service_SID` is appended to the segment list, yielding <S1, S2, S3, Egress_Service_SID>.

| +---------------------------------------------------+ | 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).

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. illustrates this scenario.

) |TailEnd| +-------+ (SR List) +-------+ '--( )--' ( ) '-----' Note: S3 is an SRv6 SID with USD flavor on the TailEnd. ]]> 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 <S1, S2, S3>. TailEnd Processing: As specified in Section 3.1.1, because S3 is an SRv6 SID with USD flavor , 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.

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

[Note to the RFC Editor - remove this section before publication, as well as remove the reference to . 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 . 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 , "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".

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

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 to govern policy selection for traffic steering based on Color C and IPv6 endpoints.

This document requires no IANA actions.

The following people made significant contributions to this document:

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.