China Mobile

No.32 XuanWuMen West Street Beijing 100053 China jiangwenying@chinamobile.com

China Mobile

No.32 XuanWuMen West Street Beijing 100053 China liuyisong@chinamobile.com

Huawei Technologies

Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China zhuangshunwan@huawei.com

Verizon Communications Inc.

13101 Columbia Pike Silver Spring, MD 20904 United States of America hayabusagsm@gmail.com

Huawei Technologies

Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China chenshuanglong@huawei.com

Routing IDR Working Group BGP FlowSpec SR Policy SRv6 SR-MPLS Segment Routing BGP Flow Specification (FlowSpec) provides mechanisms to distribute traffic filtering and steering rules across BGP networks. This document specifies BGP FlowSpec procedures to steer matching traffic flows into Segment Routing (SR) Policies. It defines two modes of operation: transport steering into an SR Policy ("Mode 1"), in SR-MPLS and SRv6 networks, using BGP Extended Communities; and, in SRv6 networks, transport steering combined with an egress service action at the egress node ("Mode 2"), signaled with the BGP Prefix-SID Attribute.

Introduction 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, which may be instantiated locally or signaled via BGP SR Policy or the Path Computation Element Protocol (PCEP) for SR Policy . BGP Flow Specification (FlowSpec) enables the dissemination of traffic filtering rules and associated actions using MP_REACH_NLRI / MP_UNREACH_NLRI and Extended Community attributes . This document specifies BGP FlowSpec mechanisms to steer matching traffic flows into an SR Policy . It defines two operational modes:

• Transport Steering Only (Mode 1): Steers traffic into a transport SR Policy toward a target Endpoint.
• Steering with Egress Service Action (Mode 2): Steers traffic into an SRv6 Policy while conveying an Egress Service SID for egress service action processing (e.g., decapsulation and routing table lookup in a specific Virtual Routing and Forwarding (VRF) table or the global table, or L3 interface cross-connect, as defined in and signaled via ).

Mode 2 is needed where the matching traffic is to be delivered into a specific routing table (for example, a VRF) or onto a specific interface at the egress Provider Edge (PE), which transport steering alone cannot express. This document does not modify the base Segment Routing architecture or SR Policy constructs , but establishes the BGP FlowSpec interworking semantics for SR Policy steering.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definitions and Acronyms

Terminology

• Mode 1 (Transport Steering Only): Steering traffic into an SR Policy (SR-MPLS or SRv6) toward a target Endpoint solely for transport path selection.
• Mode 2 (Steering with Egress Service Action): Steering traffic into an SRv6 Policy toward a target Endpoint while executing an Egress Service SID function (e.g., decapsulation followed by routing table lookup via End.DT4/DT6/DT46, or L3 interface cross-connect via End.DX4/DX6 ) at the egress PE.
• Redirect-to-IP: The FlowSpec Redirect-to-IP Extended Community defined in .
• Egress Service SID: An SRv6 Service SID that is signaled in the BGP Prefix-SID Attribute of a FlowSpec route and executed at the egress node of the SR Policy into which the matching traffic is steered.

Acronyms BGP: Border Gateway Protocol BGP FS: BGP Flow Specification EC: Extended Community ECMP: Equal Cost Multi-Path LPM: Longest Prefix Match NLRI: Network Layer Reachability Information PBR: Policy-Based Routing PCEP: Path Computation Element Protocol PE: Provider Edge SID: Segment Identifier SR-MPLS: Segment Routing over MPLS data plane SRH: Segment Routing Header SRv6: Segment Routing over IPv6 data plane UCMP: Unequal Cost Multi-Path USD: Ultimate Segment Decapsulation (Flavor defined in ) VRF: Virtual Routing and Forwarding

Protocol Procedures 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 headend (Ingress PE) .
• Egress Service Action (SRv6-specific): For SRv6 scenarios requiring a specific egress service action (e.g., decapsulation and routing table lookup in a VRF or the global table, or L3 interface cross-connect, as defined in and ) at the tailend 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).

Relationship to Other Specifications This document specifies, for the address families above:

• the use of the Color Extended Community , including the Color-Only bits defined in Section 3 of , which does not cover the use of the community in other address families.
• the use of the BGP Prefix-SID Attribute . Section 1 of leaves the use of the attribute in other AFI/SAFI combinations to future specifications; this document is such a specification. The SRv6 Service TLV encodings of are used as specified in ; the processing and error-handling procedures of are written for address families in which the Service SID is required for forwarding and do not apply here.
• steering into SR Policies as PBR steering (Section 8.7 of ). The BGP destination-steering procedures of Sections 8.4, 8.5 and 8.8 of derive the Endpoint from a BGP next hop, which a FlowSpec route does not carry (Section 4 of ), and do not apply; the Endpoint is the target IP address of the Redirect-to-IP Extended Community.

This document reuses the encodings defined by the referenced specifications (, , , , , and ). For IPv4 and IPv6 FlowSpec routes within the scope of , it defines the steering, validation, and failure procedures specified below. These procedures do not alter the behavior of the referenced specifications for routes outside that scope.

Scope A FlowSpec route is within the scope of this document if it carries both a Redirect-to-IP Extended Community and a Color Extended Community , and carries no Redirect-to-VRF Extended Community. Any other FlowSpec route is outside the scope of this document and is processed as specified in , and ; a BGP Prefix-SID Attribute on such a route is ignored. A route that carries a Redirect-to-VRF Extended Community (, Section 7.4; , Section 6.1) is outside the scope of this document irrespective of the other communities it carries, and is processed as specified in Section 2.2.1 of . This exclusion reflects the distinct nature of the two redirection mechanisms: the Redirect-to-VRF Extended Community performs a local redirection (the receiving headend immediately looks up and forwards matching traffic in the target VRF, with no tunnel), whereas the mechanisms of this document perform a remote redirection (matching traffic is carried through the SR Policy selected by the (Endpoint, Color) tuple toward the remote egress, where the egress service action, if any, is executed). As a FlowSpec rule can direct its matching traffic to only one destination, the two mechanisms MUST NOT be combined on the same FlowSpec route. VPN FlowSpec address families (SAFI=134) are outside the scope of this document. Color-Only steering (Section 8.8 of ) is outside the scope of this document. If the Color Extended Community carries a Color-Only Type other than Type 0 (Specific Endpoint Match) , the receiver MUST treat it as Type 0. For a route within scope, the procedures of this document apply in place of those of ; the two are not combined. The target IP address is the SR Policy Endpoint () and not a forwarding target, so the reachability condition of Section 2.2 of does not apply to it. Section 8.1 of specifies the default behavior for traffic on an SR Policy that becomes invalid; for a route within this scope, specifies a different behavior.

Operational Steering Modes Traffic steering specified in this document leverages BGP FlowSpec filtering rules to steer flows into SR Policies . FlowSpec-based steering corresponds to Policy-Based Routing (PBR) steering per Section 8.7 of and does not perform per-destination steering (Section 8.4 of ). Implementations MUST NOT apply per-destination route resolution, BGP multipath path selection, or On-Demand BSID recursion to FlowSpec routes. A BGP FlowSpec sender MUST construct the BGP UPDATE message using one of two operational modes: Mode 1 (Transport Steering Only) or Mode 2 (Steering with Egress Service Action).

Mode 1: Steering Without Egress Service Action (SR-MPLS / SRv6) When matching traffic requires steering into an SR Policy (SR-MPLS or SRv6) toward an Endpoint without a specific egress service action, Mode 1 steering applies:

• Sender Behavior: The sender MUST attach a Redirect-to-IP Extended Community and a Color Extended Community , and MUST NOT attach the BGP Prefix-SID Attribute (see for attribute validation).
• Ingress Behavior: Upon resolving the (Endpoint, Color) tuple per , the headend steers matching traffic into the resolved SR Policy by encapsulating it solely with the policy's segment list (MPLS label stack or SRH).
• Egress Behavior: Decapsulation or label popping at the egress PE relies on the final segment behavior of the target SR Policy (e.g., Implicit Null for SR-MPLS or End function with Ultimate Segment Decapsulation (USD) flavor for SRv6).

Mode 2: Steering With Egress Service Action (SRv6-specific) When matching traffic requires steering into an SRv6 Policy and a specific service context or decapsulation behavior at the egress PE, Mode 2 steering applies:

• Sender Behavior: The sender MUST attach a Redirect-to-IP Extended Community, a Color Extended Community , and the BGP Prefix-SID Attribute carrying the Egress Service SID (encoded per ).
• Ingress Behavior: The headend resolves the target SRv6 Policy using the (Endpoint, Color) tuple per , and synthesizes the active segment list in the SRH by combining the SR Policy segment list with the Egress Service SID per .
• Egress Behavior: Upon receiving the packet, the egress PE executes the behavior bound to the Egress Service SID. The supported DT/DX behaviors remove the outer IPv6 header and its extension headers before performing the specified routing-table lookup or L3 cross-connect (, ).

Data-Plane Encapsulation Considerations When matching traffic is successfully resolved and steered into an SR Policy or Segment Routing path, the headend encapsulates the packet with an outer header (e.g., an outer IPv6 header with an SRH for SRv6) as specified in and . For SRv6, the headend MAY omit the SRH only when the applicable requirements of Section 4.1 of and Section 5 of are met. When SID compression is used, the headend MUST also satisfy the requirements of Section 6 of , including its restrictions on SRH omission.

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:

1. Construct the explicit (Color, Endpoint) tuple by attaching the Color Extended Community and setting the target IP address in the Redirect-to-IP Extended Community .
2. If and only if every headend expected to receive the route resolves the (Endpoint, Color) tuple to an SRv6 Policy, and an egress service action is intended (Mode 2, ), attach the BGP Prefix-SID Attribute carrying the SRv6 Service SID constructed per . A route carrying the BGP Prefix-SID Attribute is unusable at a headend that resolves the (Endpoint, Color) tuple to an SR-MPLS Policy: such a headend MUST NOT forward matching traffic using Mode 1 and MUST apply the failure procedures of , per , Step 3. Operators SHOULD NOT advertise Mode 2 routes to speakers whose data-plane resolution for the (Endpoint, Color) tuple is not known to be SRv6.

A BGP speaker that re-advertises a FlowSpec route within the scope of this document does not modify the Color Extended Community, the Redirect-to-IP Extended Community or the BGP Prefix-SID Attribute it carries, except as specified in for a malformed BGP Prefix-SID Attribute. The next-hop-dependent procedures of Section 2 of do not apply. An operator MAY configure policy that removes the whole route at an administrative domain boundary (see ).

Procedures for the Receiving BGP Speaker (Headend / Ingress PE) The procedures specified in this section apply to BGP FlowSpec receivers acting as SR headends. A BGP speaker that is not acting as an SR headend for a FlowSpec route performs no SR Policy binding and propagates the route as specified in . Upon receiving a FlowSpec route, the headend performs evaluation and forwarding programming per the sequence specified in . The procedures below expand on the operations referenced by the steps of that sequence:

1. Validation and Mode Determination: The FlowSpec route is validated as specified in , and , and malformed attributes are handled per . The validation procedure of Section 2.1 of does not apply to a route within the scope of this document, whose target IP address is an SR Policy Endpoint. The steering attributes determine whether the route is Mode 1 or Mode 2 per .
2. SR Policy Binding & Synthesis: The headend uses the extracted (Color, Endpoint) tuple to select the SR Policy with that Color and Endpoint and its active Candidate Path (Sections 2.9 and 5 of ). Matching traffic is steered into that SR Policy by PBR (Section 8.7 of ).
   • For Mode 1, traffic is encapsulated using the active Segment List.
   • For Mode 2, the headend MUST synthesize the effective Segment List with the Egress Service SID () as follows:
     • Appending: The headend MUST append the Egress Service SID as the final segment (innermost SID) of the Segment List, provided that the final segment of the resolved path is a forwarding or transit behavior. However, the headend MUST NOT append a Service SID after a behavior (such as End.DT4, End.DT6, End.DT46, End.DX4, or End.DX6) that requires the SID to be in the final position of the list (see , Sections 4.4-4.8).
     • Replacing: Alternatively, if the final segment of the resolved Segment List is known to the headend to be replaceable by the Egress Service SID, the headend MAY replace that final segment with the Egress Service SID. Replacement MUST NOT be performed where it would discard a forwarding constraint expressed by the segment it replaces (for example, an End.X SID). The means by which a headend determines that a segment is replaceable are outside the scope of this document.
     • Eligibility and Feasibility Check: Before using a synthesized Segment List (including lists used for weighted load sharing), the headend MUST verify that the resulting list preserves the transport constraints of the resolved SR Policy, is valid for the endpoint behaviors involved, and can be programmed in the forwarding plane. If SRv6 SID compression is used, the resulting sequence MUST be encoded in accordance with Section 6 of .
     • Handling of Unusable Segment Lists: If neither appending nor permitted replacement produces a usable and valid list due to endpoint constraint violations, that specific Segment List is considered unusable. When an individual Segment List within a multi-path or weighted load-sharing SR Policy is deemed unusable, it MUST be excluded from the active set, and the traffic load MUST be distributed across the remaining usable Segment Lists with adjusted weights (consistent with the behavior defined in ). If all candidate Segment Lists for the steering binding are unusable, the failure procedures in apply.
   When an SR Policy is resolved, LPM redirection toward the target IP address is not performed (see ). Non-steering FlowSpec actions in the same route remain applicable.
3. Control Plane Retention & Decoupling: If a matching active SR Policy cannot be resolved for a received FlowSpec route carrying an explicit steering intent, or if the resolved SR Policy subsequently transitions to Down state:
   • Control Plane: The FlowSpec route MUST be retained in the BGP Loc-RIB as a valid route (unless rendered invalid by standard BGP path validation rules) and MUST continue to be advertised to downstream BGP peers according to standard BGP path selection and propagation rules. The headend MUST NOT implicitly invalidate or withdraw the BGP FlowSpec route solely due to underlay transport-layer resolution or SR Policy failures.
   • Forwarding Plane: The associated SR steering forwarding state (e.g., a PBR entry) MUST NOT be activated in the forwarding plane, or MUST be marked as inactive. Matching traffic is handled as specified in .

Interaction with Redirect-to-IP Extended Community When a FlowSpec route carries both a Color Extended Community and a Redirect-to-IP Extended Community , the target IP address MUST be interpreted as the target SR Policy Endpoint to form the explicit (Color, Endpoint) tuple .

• Single Redirect-to-IP Enforcement: A sender using the procedures of this document MUST attach exactly one Redirect-to-IP Extended Community. Multiple Redirect-to-IP Extended Communities are not supported by this document: a FlowSpec route within the scope of this document that carries multiple Redirect-to-IP Extended Communities MUST be handled with the "treat-as-withdraw" action of (i.e., the FlowSpec rule ceases to exist locally and is not re-advertised), and the headend SHOULD generate a diagnostic log entry.
• Color Selection: If multiple Color Extended Communities are present, the headend selects the SR Policy using the Color with the highest numerical value for which an SR Policy to the target Endpoint is valid; if no Color yields a valid SR Policy, applies. This follows the preference order of Section 8.4.1 of ; the per-destination steering procedures of Section 8.4 of are not used.

BGP Prefix-SID Attribute Encoding and Validation Rules The BGP Prefix-SID Attribute is used strictly for conveying SRv6 Service SIDs in SRv6 Mode 2 () and MUST NOT be attached for SR-MPLS. The SRv6 Service TLV encodings of and the SRv6 SID encodings of are used as follows:

• SRv6 Service TLVs and Selection Rules: The SRv6 L3 Service TLV (Type 5) MUST be used, containing an SRv6 SID Information Sub-TLV (Type 1). A sender MUST include exactly one SRv6 L3 Service TLV containing exactly one SRv6 SID Information Sub-TLV. If multiple SRv6 L3 Service TLVs are received, all but the first MUST be ignored. Within the selected TLV, the receiver MUST use the first SRv6 SID Information Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV (Type 1) MAY be included. SRv6 L2 Service TLVs (e.g., Type 6) MUST NOT be included for Layer 3 FlowSpec (SAFI 133) and MUST be ignored if received, treating the route as lacking an Egress Service SID.
• Endpoint Behaviors and AFI Matching: Supported codepoints are restricted to Layer 3 behaviors (). Layer 2 and transit behaviors MUST NOT be used. Furthermore, the selected SRv6 Endpoint Behavior MUST match the respective FlowSpec AFI/SAFI:
  • For IPv4 FlowSpec, the behavior MUST be End.DT4, End.DX4, or End.DT46.
  • For IPv6 FlowSpec, the behavior MUST be End.DT6, End.DX6, or End.DT46. (An IPv4 payload MUST NOT be delivered through End.DT6 or End.DX6, and an IPv6 payload MUST NOT be delivered through End.DT4 or End.DX4).
• Disallowance of Transposition and Structure Constraints: Transposition Schemes () MUST NOT be used because FlowSpec NLRIs lack an MPLS Label field. The full SRv6 Service SID MUST be encoded entirely within the SRv6 SID Information Sub-TLV. If the SRv6 SID Structure Sub-Sub-TLV is present, its Transposition Length, Transposition Offset, and Argument Length fields MUST all be zero. The SID and, when present, its structure MUST satisfy the applicable requirements of , as updated by . For the behaviors supported by this document, all bits following the function portion of the SID MUST be zero.

Two classes of BGP Prefix-SID Attribute failure are distinguished:

• Malformed attribute: A BGP Prefix-SID Attribute that cannot be parsed per and (e.g., undecodable TLVs, invalid encoding). A headend that receives such an attribute on an in-scope FlowSpec route SHOULD treat the route per the "treat-as-withdraw" action of , and MUST NOT re-advertise the route as a Mode 1 route, so that the service intent is not silently removed for downstream speakers. The headend SHOULD generate a diagnostic log entry.
• Semantic, matching or authorization failure: An attribute that is well-formed but whose SRv6 SID Information Sub-TLV does not contain a usable Egress Service SID, or that violates any of the validation and matching rules specified above (e.g., wrong behavior for the AFI, unauthorized SID). The headend MUST ignore the attribute for local forwarding decisions, MUST NOT forward matching traffic using Mode 1 as a result of a missing, malformed, unsupported, unauthorized, or otherwise unusable Egress Service SID, and MUST apply the failure procedures of . The headend SHOULD generate a diagnostic log entry. The attribute MUST be propagated unmodified to downstream BGP speakers per standard BGP propagation: authorization is a local decision, and one headend's local policy MUST NOT strip the service intent from the route for other speakers. For C-bit = 1, this failure affects only the copied stream, as specified in .

Steering Failure and Fallback Procedures states how a route without a Color Extended Community is handled. specifies the handling of a route within the scope of this document whose SR Policy or Egress Service SID cannot be resolved.

Routes Without a Color Extended Community A FlowSpec route that carries a Redirect-to-IP Extended Community but no Color Extended Community is outside the scope of this document (see ). It is processed as specified in , and a BGP Prefix-SID Attribute on it is ignored.

Policy and SID Resolution Failures (Forwarding Plane Failure) This section applies to FlowSpec routes whose steering attributes are syntactically valid but whose intended SR Policy steering cannot be achieved. Handling of malformed attributes (e.g., a malformed BGP Prefix-SID Attribute per , or multiple Redirect-to-IP Extended Communities per ) is governed by and results in the route being treated as withdrawn — i.e., the FlowSpec rule ceases to exist locally, and matching traffic is not subject to this section's failure handling. If a FlowSpec route contains both a valid Redirect-to-IP Extended Community and a Color Extended Community (expressing explicit SR steering intent), but:

• The corresponding (Endpoint, Color) SR Policy is Down, unresolvable, or not programmed in the forwarding plane; or
• The target SR Policy is active, but the headend cannot construct and program an eligible effective Segment List containing the authorized Egress Service SID; or
• The headend resolves the (Endpoint, Color) tuple to an SR-MPLS Policy for a Mode 2 route;

Then, to prevent silent SLA violations and unexpected path leakage, the headend MUST NOT fall back to shortest-path IP forwarding, or to Redirect-to-IP forwarding, toward the target IP address. Matching traffic MUST be processed according to local administrative failure policy, subject to where the C-bit is set. The local failure policy MUST be one of:

• Drop the matching traffic (Drop-on-Failure). This is the default action.
• Forward the matching traffic by the normal destination-based forwarding lookup, ignoring the FlowSpec steering action.

Under no circumstance MUST the traffic be forwarded by IP or LPM redirection toward the target IP address of the Redirect-to-IP Extended Community. Other non-steering FlowSpec actions present in the same route (e.g., Traffic-Rate, DSCP remarking) MUST continue to be enforced. These procedures apply irrespective of whether the target IP address in the Redirect-to-IP Extended Community is reachable in the headend's routing table: within the scope of this document that address identifies an SR Policy Endpoint, not a forwarding target.

Diagnostics and Recovery A headend that is unable to program the forwarding plane for a FlowSpec route within the scope of this document SHOULD generate a diagnostic notification identifying the route and the reason (for example, a YANG notification , a Syslog message or an SNMP notification ). A headend that was unable to program the forwarding plane owing to a transient resource constraint SHOULD re-attempt programming when resources become available, without requiring the route to be re-advertised. This SHOULD may be bypassed when the resource constraint is not expected to clear (e.g., persistent hardware table exhaustion), or when the route has since been updated or withdrawn; the consequence of bypassing it is that the affected FlowSpec route remains without forwarding state (and its matching traffic continues to be handled per ) until resources become available or the route is re-advertised. A headend should maintain a counter, per FlowSpec route, of packets discarded under , so that an operator can distinguish traffic dropped by steering failure from traffic dropped by an explicit FlowSpec action.

Handling of the Redirect-to-IP C-bit The Redirect-to-IP Extended Community includes a C-bit (Copy Bit) in its Local Administrator field:

• C-bit = 0 (Direct Redirection): Matching packets MUST be encapsulated and steered into the resolved SR Policy, bypassing normal IP routing.
• C-bit = 1 (Traffic Copying): The headend MUST duplicate matching packets. The original packet continues along normal IP routing without encapsulation, while the copy is encapsulated and steered into the resolved SR Policy per .

Setting C-bit = 1 does not alter SR Policy resolution logic; (Endpoint, Color) resolution and BGP Prefix-SID Attribute processing remain unchanged for the copied stream. The failure procedures of and apply only to the copied stream: on steering failure, the copy MUST be discarded, and the original stream MUST continue to be forwarded by normal IP routing, unaffected by the steering failure.

Load Balancing Considerations When matching traffic is steered into an SR Policy with multiple active Segment Lists , the headend MUST distribute traffic across active Segment Lists according to their defined weights (ECMP/UCMP). FlowSpec filtering actions direct traffic into the policy as a single aggregate stream and MUST NOT alter Segment List selection. The headend acts as an SR source node for the traffic it steers. For SRv6, the outer IPv6 Flow Label is computed from the inner packet as specified in Section 5.5 of , which also provides the entropy used for multipath hashing by transit nodes. This document imposes no additional requirement and grants no exception.

Backward Compatibility and Coexistence A BGP speaker that implements base FlowSpec and Redirect-to-IP, but not this specification, processes such routes under the rules of those specifications:

• Attribute Propagation: The BGP Prefix-SID Attribute is an optional transitive attribute . A speaker that does not recognize it propagates it with the Partial bit set .
• Forwarding on non-supporting headends: A non-supporting headend processes the route as specified in , which may result in LPM redirection toward the target IP address. Such forwarding is outside the forwarding paths defined in this document.

Implementations MUST support administrative controls to enable or disable advertisement of SRv6 service steering attributes per neighbor and per service . Filtering at domain boundaries is specified in ; an operator who requires that these attributes not leave a domain configures it rather than relying on non-support.

Multi-Attribute Interworking and Steering Resolution When a router receives a BGP FlowSpec route carrying a combination of the Redirect-to-IP Extended Community, the Color Extended Community, and the BGP Prefix-SID Attribute, it MUST evaluate these attributes in a sequential pipeline to resolve the steering action.

Sequential Resolution Logic The headend evaluates received attribute containers step-by-step. The steps below form the authoritative processing sequence; expands on the operations referenced by each step. Before Step 1, the headend applies the scope determination of : a route carrying a Redirect-to-VRF Extended Community is outside the scope of this document irrespective of the other attributes it carries, and a route carrying neither a Redirect-to-IP Extended Community nor a Color Extended Community is outside the scope of this document. Such routes are not evaluated by the steps below and are processed as specified in . The data-plane outcome of the sequence (SR-MPLS versus SRv6) is not itself a sequence step: it is a property of how the headend resolves the (Endpoint, Color) tuple, determined by the upper-layer control plane from the information carried in the attributes and in the local SR Policy state (e.g., a headend whose transport for the tuple is SR-MPLS can determine, prior to tuple resolution, that a Mode 2 route will fail-closed per ). Step 1: Redirect-to-IP Extended Community

• Absent: Procedures in this document do not apply. Process route per standard BGP FlowSpec .
• Present, exactly one: Extract target IP as SR Policy Endpoint, process C-bit (), and proceed to Step 2.
• Present, more than one: Not a supported combination; handle per the "treat-as-withdraw" action of (). The sequence terminates; the FlowSpec rule ceases to exist locally.

Step 2: Color Extended Community

• Absent: The route is outside the scope of this document and is processed as specified in .
• Present: Extract Color value C to form the (Endpoint, Color) tuple. If multiple Color Extended Communities are present, the headend selects the Color per (abnormal-case handling). Proceed to Step 3.

Step 3: BGP Prefix-SID Attribute (PSID) - Mode Determination

• Note: This step is a pure attribute-layer determination of Mode 1 versus Mode 2. Data-plane matching is not performed in this step; whether the resolved SR Policy is SR-MPLS or SRv6 is an outcome of the (Endpoint, Color) tuple resolution in .
• Absent (Mode 1): Resolve and steer traffic into the SR Policy corresponding to (Endpoint, Color) per . For SR-MPLS and SRv6 data planes alike, this includes both the SR-MPLS and the SRv6 USD-flavored cases of Table 1. If no valid SR Policy can be resolved, applies.
• Present (Mode 2): Validate the attribute per . If the attribute is malformed, handle per the "treat-as-withdraw" action of ; the sequence terminates and the FlowSpec rule ceases to exist locally. Otherwise, extract the Egress Service SID, resolve the SR Policy via (Endpoint, Color), and synthesize the active segment list per and . If the (Endpoint, Color) tuple resolves to an SR-MPLS Policy, or if no usable Egress Service SID can be determined, the BGP Prefix-SID Attribute MUST NOT be used for SR-MPLS steering, the headend MUST NOT forward matching traffic using Mode 1, and the failure procedures of apply, with a diagnostic log entry generated.

Valid Attribute Combinations Summary Table 1 summarizes all possible attribute combinations and their corresponding resolution modes after applying the sequential logic above. Notes:

• A route whose attributes fall in the third or fourth row of Table 1 is outside the scope of this document: a route in the third row is processed as specified in (per , with a BGP Prefix-SID Attribute, if present, ignored), and a route in the fourth row is processed per standard BGP FlowSpec .
• A route carrying a Redirect-to-VRF Extended Community is outside the scope of this document irrespective of the other attributes it carries (i.e., irrespective of which row its other attributes would otherwise match): it is processed as a local redirection to the target VRF per , and the procedures of this document do not apply to it.
• The "(SR-MPLS / SRv6 USD)" annotation of the first row denotes the two data-plane forms of Mode 1, not two distinct modes: for SR-MPLS, decapsulation relies on the implicit label-popping behavior of the final label; for SRv6, it relies on the final segment of the resolved SR Policy supporting the USD flavor (see ). In both cases the (Endpoint, Color) tuple selects the SR Policy.

Protection Against Silent SLA Violations To prevent unintentional redirection and SLA violations, implementations MUST strictly enforce the following rules:

1. Steering Failure: For a route within the scope of this document, the procedures of apply; matching traffic is not forwarded by standard IP or Redirect-to-IP forwarding toward the target IP address, and is handled according to the local administrative failure policy of , which defaults to discarding the traffic.
2. Enforcement of Non-Steering Actions: In all failure cases, other valid non-steering actions present in the FlowSpec route (e.g., Traffic-Rate/Drop , DSCP remarking) MUST continue to be enforced in the forwarding plane.
3. Logging and Diagnostics: Implementations should generate diagnostic log entries whenever an SR Policy steering route contains corrupted or invalid steering attributes. An exception to this "should" occurs during high-volume error events or flood conditions (e.g., malformed route injection attacks), where strict per-route logging could exhaust control plane CPU or storage resources. In such scenarios, implementations MAY rate-limit, aggregate, or temporarily suppress individual diagnostic log entries, provided that summary metrics or counter-based telemetry remain available to operators.

Operational Considerations FlowSpec provides a control-plane mechanism for distributing traffic matches and their SR Policy bindings. Operators need to account for classifier capacity, the number of policy bindings and synthesized encapsulations, and the effect of policy changes on forwarding-state programming. The mechanisms defined in this document are intended for deployment within an SR domain under a single administrative control, which may span multiple ASes. specifies the filtering of these routes and attributes at the boundaries of that domain. The selection of Mode 1 or Mode 2 for a given FlowSpec route is determined by the attributes the sender attaches, per Table 1: a sender that attaches only the Redirect-to-IP and Color Extended Communities requests Mode 1; a sender that additionally attaches the BGP Prefix-SID Attribute requests Mode 2. Advertisement of these attributes is a configurable behavior (see the per-neighbor and per-service administrative controls in ). A receiver does not need to be configured to distinguish the modes: the sequential logic of derives the mode from the received attributes. In deployments mixing headends that support this specification with headends that do not, or mixing SR-MPLS and SRv6 resolution for the same (Endpoint, Color) tuple, the same FlowSpec route can be processed differently on different headends: a supporting SRv6 headend steers per this document, a supporting SR-MPLS headend fails closed for a Mode 2 route per , and a non-supporting headend processes the route per (see ). There is no in-band signal distinguishing these outcomes. Operators therefore SHOULD scope the advertisement of in-scope FlowSpec routes, and in particular of Mode 2 routes, to BGP speakers that are known to support this specification and to resolve the (Endpoint, Color) tuple to the intended data plane. For concrete application scenarios, detailed flow steering sequences, and an overall operational workflow summary, readers should refer to (with a high-level summary provided in ). specifies the notifications, re-attempts and counters a headend provides when steering fails; operators can use the counters to distinguish steering failures from deliberate discards.

Security Considerations The security considerations of BGP FlowSpec , Redirect-to-IP , BGP Prefix-SID , and core Segment Routing apply to this document. Combining FlowSpec redirection with SR Policy selection and SRv6 Service SIDs introduces specific threat vectors that need to be mitigated, as described in the subsections below.

Cross-Table/VRF Traffic Injection and Service Hijacking The BGP Prefix-SID Attribute in a FlowSpec route conveys an SRv6 Service SID (e.g., End.DT4/DT6/DT46, End.DX4/DX6 ) that determines the egress routing table (e.g., a specific VRF or the global table) or specific egress interface at the egress PE. A malicious or compromised speaker could steer traffic into an arbitrary remote VRF, the global routing context, or an unauthorized interface, causing unauthorized traffic injection, cross-table/VRF data leakage, or traffic interception. To mitigate this, receiving PEs MUST validate that any SRv6 Service SID belongs to an authorized Locator range allocated for the target VRF, global table, or service context. The mapping of authorized Locator ranges to VRFs and service contexts is derived from local device configuration or controller provisioning, since the ingress PE cannot otherwise determine the locator assignments of a remote egress PE. BGP sessions with FlowSpec controllers MUST be secured using TCP-AO and restricted to trusted entities.

Scope and Validation Limits of BGP FlowSpec Attributes The validation procedures of , , and validate FlowSpec routes against unicast routing information. The additional Redirect-to-IP validation procedure in does not apply to routes within the scope of this document, as specified in . These checks do not authorize the Color Extended Community or the service context conveyed by the BGP Prefix-SID Attribute; those require the local authorization checks specified in this section and . An attacker could alter or strip these attributes. Injecting an unauthorized Color EC could hijack traffic onto unintended SR paths. Conversely, stripping the Color EC from a route takes it out of the scope of this document (): the traffic is then redirected as specified in , bypassing the SR Policy and, for Mode 2, the Egress Service SID. Headends MUST apply local policy checks to verify that the (Color, Endpoint) tuple resolves to an authorized SR Policy before binding traffic. Filtering of these attributes at administrative domain boundaries is specified in . Implementations SHOULD generate log messages or management alarms when unexpected attribute stripping is detected.

SR Domain Leakage and Boundary Security SRv6 SIDs and BGP Prefix-SID Attributes are intended strictly for use within a trusted SR domain . Propagation across untrusted EBGP boundaries leaks internal SRv6 Locators and topology, exposing the domain to external steering attacks. FlowSpec routes within the scope of this document, including their Redirect-to-IP, Color and, where present, BGP Prefix-SID attributes, are scoped to a single administrative domain. BGP speakers at the boundary of the administrative domain MUST NOT advertise in-scope FlowSpec routes, or the steering attributes they carry, to BGP peers outside that domain. Where multiple ASes are under a single administrative control with explicit inter-domain trust, filtering is applied at the edge of that administrative domain instead. Removing the BGP Prefix-SID Attribute or the Color Extended Community while still advertising the route outside the domain is NOT RECOMMENDED, as the residual Redirect-to-IP Extended Community would redirect external matching traffic toward an internal SR Policy Endpoint by LPM resolution (see also Section 5 of ).

Traffic Amplification and Path Pinning A single FlowSpec route can match high-volume distributed flows across multiple Ingress PEs and redirect them to a single destination . Binding redirected flows to an SR Policy allows an attacker to pin amplified traffic to a specific engineered path, potentially overloading transit nodes or egress interfaces. Ingress PEs SHOULD combine FlowSpec redirect actions with Traffic Rate Extended Communities to bound redirected bandwidth. An exception to this SHOULD requirement occurs when a FlowSpec route is deployed for legitimate traffic steering and rate limiting would cause unwanted packet drops, where adequate capacity planning guarantees sufficient bandwidth along the candidate path. Implementations SHOULD monitor path utilization on SR Policies used for FlowSpec steering to detect and mitigate link congestion dynamically. An exception to this SHOULD requirement occurs in centralized control plane architectures where automated Controller-based TE or PCE monitoring dynamically adjusts policy pathing and prevents link congestion automatically.

Implementation Status [Note to the RFC Editor: Please 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".

Interop-test Status The traffic steering mechanism using BGP FlowSpec with SR-MPLS and SRv6 Policies described in this specification has been implemented by multiple major networking vendors across hardware platforms, router operating systems, and SDN controllers. These implementations successfully participated in multi-vendor joint interoperability testing events organized by China Mobile between July 2021 and October 2021. The following hardware devices, software versions, and controllers passed the interoperability suite (listed in alphabetical order by vendor): Routers: Controllers:

Deployment Status The mechanisms specified in this document have been natively deployed and in active production use on large-scale IP backbone networks, including China Mobile's production network, since August 2022. In production deployments featuring pure SRv6 architectures, traffic steering driven by FlowSpec routes with Color Extended Communities and IPv6 Redirect addresses operates over SRv6 Policies. In hybrid or multi-AS network environments where SR-MPLS and SRv6 coexist, policy selection for FlowSpec traffic steering adheres strictly to the steering framework defined in .

IANA Considerations This document requires no IANA actions.

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

Acknowledgements The authors would like to thank:

• 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 reviews, 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 (Sandy), Xuewei Wang, Yanrong Liang, Xuhui Cai, Haojie Wang, Lili Wang, Nan Geng, Stephane Litkowski, Zhenqiang Li, Jinming Li, Shengnan Yue, Yao Liu, Yujia Gao, Zhiyuan Wang, Guanming Zeng, Jianwei Mao, Xiaoming He, Ziqing Cao and Giuseppe Fioccola.

References Normative References Informative References

Application Examples (Informative) This appendix provides illustrative examples for steering BGP FlowSpec traffic into SR Policies in SR-MPLS and SRv6 networks per and .

SR-MPLS Steering Example (Mode 1) Figure 1 illustrates steering FlowSpec traffic into an SR-MPLS Policy without egress service actions ().

Steering Traffic into SR-MPLS Policy (Mode 1) ) |Tailend| +-------+ (SR List) +-------+ '--( )--' ( ) '-----' ]]>

Control Plane: The BGP FS Controller advertises a FlowSpec route with matching rules, Redirect-to-IP (Endpoint Address), and Color C0. The BGP Prefix-SID Attribute is omitted. Headend Resolution: The headend resolves the SR-MPLS Policy matching the tuple (Endpoint: Tailend, Color: C0). Encapsulation: Matching traffic is encapsulated into the policy's MPLS label stack:

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

SRv6 Mode 2: Transport Steering with Egress Service Action Figure 2 illustrates signaling an explicit egress service action (Egress_Service_SID) alongside transport steering ().

Steering Traffic into SRv6 Policy with Egress Service Action (Mode 2) ) |Tailend| +-------+ (SR List) +-------+ '--( )--' SRv6 SID: Egress_Service_SID ( ) (e.g., End.DT4, End.DT6, etc.) '-----' ]]>

Control Plane & Resolution: The route carries Color C1, Redirect-to-IPv6 (Endpoint Address), and a BGP Prefix-SID Attribute carrying Egress_Service_SID. The headend resolves the SRv6 Policy matching (Endpoint: Tailend, Color: C1), yielding candidate Segment List <S1, S2, S3>. Segment List Synthesis ():

• Scenario A (Replacing, conditional): If the headend knows that S3 can be replaced by Egress_Service_SID (e.g., S3 is an End SID of the tailend and expresses no path constraint), S3 MAY be replaced, yielding the synthesized Segment List <S1, S2, Egress_Service_SID>.
• Scenario B (Appending, default): Otherwise, Egress_Service_SID is appended, yielding the synthesized Segment List <S1, S2, S3, Egress_Service_SID>.

Packet Encapsulation Format: At the headend, matching traffic is encapsulated into an outer IPv6 header and SRH with the corresponding synthesized Segment List: (A) | | OR: (B)| +-----------------------------------------------------+ | 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., routing table lookup in a specific VRF or the global table, such as End.DT4/DT6 ).

SRv6 Mode 1: Transport Steering Only (USD-Flavored End SID) When the final SID S3 instantiated on the tailend supports the Ultimate Segment Decapsulation (USD) flavor , an explicit Egress Service SID MAY be omitted from the FlowSpec route.

Steering Traffic into SRv6 Policy (Mode 1) ) |Tailend| +-------+ (SR List) +-------+ '--( )--' ( ) '-----' Note: S3 is an SRv6 SID with USD flavor on the tailend. ]]>

The controller advertises the route with Color C2 and Redirect-to-IPv6 without a BGP Prefix-SID. The headend encapsulates traffic using Segment List <S1, S2, S3>. Upon arrival, the tailend executes USD behavior, pops the outer IPv6 header/SRH, and performs standard table lookup on the inner packet in the default/global routing context.

Summary of Operational Workflow In typical network operations:

1. The Centralized Controller maintains full visibility of topology and SR Policies across the network domain.
2. When dynamic traffic steering or mitigation is triggered, the Controller advertises a FlowSpec route combining packet matching criteria with explicit steering attributes (Color EC, Redirect-to-IP, and optional BGP Prefix-SID Attribute).
3. Ingress PEs parse these received attributes, resolve and bind the matching traffic to the designated SR Policies, and synthesize the encapsulation headers dynamically without requiring manual per-flow provisioning across distributed nodes.