Traffic Steering using BGP FlowSpec with SR Policy

2.1. 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 [RFC8986][RFC9252]) at the egress PE.¶

• Redirect-to-IP: The FlowSpec Redirect-to-IP Extended Community defined in [I-D.ietf-idr-flowspec-redirect-ip].¶

• Egress Service SID: An SRv6 Service SID [RFC9252] 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.¶

2.2. Acronyms

• BGP FS: BGP Flow Specification [RFC8955][RFC8956][RFC9117]¶

• EC: Extended Community [RFC4360]¶

• LPM: Longest Prefix Match¶

• NLRI: Network Layer Reachability Information [RFC4271]¶

• SID: Segment Identifier [RFC8402]¶

• SR-MPLS: Segment Routing over MPLS data plane [RFC8660]¶

• SRH: Segment Routing Header [RFC8754]¶

• SRv6: Segment Routing over IPv6 data plane [RFC8754][RFC8986]¶

• USD: Ultimate Segment Decapsulation (Flavor defined in [RFC8986])¶

3.1. Relationship to Other Specifications

This document specifies, for the address families above:¶

• the use of the Color Extended Community [RFC9012], including the Color-Only bits defined in Section 3 of [RFC9830], which does not cover the use of the community in other address families.¶

• the use of the BGP Prefix-SID Attribute [RFC8669]. Section 1 of [RFC8669] 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 [RFC9252] are used as specified in Section 3.7; the processing and error-handling procedures of [RFC9252] are written for address families in which the Service SID is required for forwarding and do not apply here.¶

• steering into SR Policies [RFC9256] as policy-based steering (Section 8.7 of [RFC9256]). The BGP destination-steering procedures of Sections 8.4, 8.5 and 8.8 of [RFC9256] derive the Endpoint from a BGP next hop, which a FlowSpec route does not carry (Section 4 of [RFC8955]), and do not apply; the Endpoint is the target IP address of the Redirect-to-IP Extended Community.¶

Nothing in [RFC9012], [RFC9830], [RFC8669], [RFC9252], [RFC9256] or [I-D.ietf-idr-flowspec-redirect-ip] is changed by this document.¶

3.2. Scope

A FlowSpec route is within the scope of this document if it carries both a Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip] and a Color Extended Community [RFC9012], 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 [I-D.ietf-idr-flowspec-redirect-ip], [RFC8955] and [RFC8956]; a BGP Prefix-SID Attribute on such a route is ignored.¶

A route that carries a Redirect-to-VRF Extended Community ([RFC8955], Section 7.4; [RFC8956], 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 [I-D.ietf-idr-flowspec-redirect-ip]. VPN FlowSpec address families (SAFI=134) are outside the scope of this document.¶

Color-Only steering (Section 8.8 of [RFC9256]) is outside the scope of this document. If the Color Extended Community carries a Color-Only Type other than Type 0 (Specific Endpoint Match) [RFC9830], the receiver MUST treat it as Type 0.¶

For a route within scope, the procedures of this document apply in place of those of [I-D.ietf-idr-flowspec-redirect-ip]; the two are not combined. The target IP address is the SR Policy Endpoint (Section 3.6) and not a forwarding target, so the reachability condition of Section 2.2 of [I-D.ietf-idr-flowspec-redirect-ip] does not apply to it. Section 8.1 of [RFC9256] specifies the default behavior for traffic on an SR Policy that becomes invalid; for a route within this scope, Section 3.8 specifies a different behavior.¶

3.3. Operational Steering Modes

Traffic steering specified in this document leverages BGP FlowSpec filtering rules to steer flows into SR Policies [RFC9256].¶

FlowSpec-based steering corresponds to Policy-Based Routing (PBR) steering per Section 8.7 of [RFC9256] and does not perform per- destination steering (Section 8.4 of [RFC9256]). Implementations MUST NOT apply per-destination route resolution, BGP multipath path selection, or On-Demand BSID recursion [RFC9256] 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).¶

3.4. 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 [RFC9012] and setting the target IP address in the Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip].¶

2. Where an egress service action is intended at headends that resolve an SRv6 Policy (Mode 2, Section 3.3.2), attach the BGP Prefix-SID Attribute carrying the SRv6 Service SID constructed per Section 3.7. A headend that resolves the (Color, Endpoint) tuple to an SR-MPLS Policy ignores the attribute (Section 4.1, Step 3).¶

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, other than as Section 3.7 specifies for a discarded attribute. The next-hop-dependent procedures of Section 2 of [RFC9252] do not apply. An operator MAY configure policy that removes these attributes at an administrative boundary (Section 6.3).¶

3.5. 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 Section 3.4.¶

Upon receiving a FlowSpec route, the headend performs evaluation and forwarding programming strictly per the sequential logic in Section 4.1:¶

1. Validation and Mode Determination: The FlowSpec route is validated as specified in [RFC8955], [RFC8956] and [RFC9117], and malformed attributes are handled per [RFC7606]. The validation procedure of Section 2.1 of [I-D.ietf-idr-flowspec-redirect-ip] 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 Section 4.1.¶

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 [RFC9256]). Matching traffic is steered into that SR Policy by policy-based steering (Section 8.7 of [RFC9256]).¶

   • 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 (Section 3.7) as follows:¶

     • The headend MUST append the Egress Service SID as the final segment (innermost SID) of the Segment List, except as permitted by the next rule.¶

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

• When an SR Policy is resolved, longest-prefix-match redirection toward the target IP address is not performed (see Section 3.2). 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 Policy-Based Routing entry) MUST NOT be activated in the forwarding plane, or MUST be marked as inactive. Matching traffic is handled as specified in Section 3.8.2.¶

3.6. Interaction with Redirect-to-IP Extended Community

When a FlowSpec route carries both a Color Extended Community [RFC9012] and a Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip], the target IP address MUST be interpreted as the target SR Policy Endpoint to form the explicit (Color, Endpoint) tuple [RFC9256].¶

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, Section 3.8.2 applies. This follows the preference order of Section 8.4.1 of [RFC9256]; the per-destination steering procedures of Section 8.4 of [RFC9256] are not used.¶

3.7. BGP Prefix-SID Attribute Encoding Rules

The BGP Prefix-SID Attribute [RFC8669] is used strictly for conveying SRv6 Service SIDs in SRv6 Mode 2 (Section 3.3.2) and MUST NOT be attached for SR-MPLS. The SRv6 Service TLV encodings of [RFC9252] and the SRv6 SID encodings of [RFC8986] are used as follows:¶

• SRv6 Service TLVs: The SRv6 L3 Service TLV (Type 5) MUST be used, containing an SRv6 SID Information Sub-TLV (Type 1). 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: Supported codepoints are restricted to Layer 3 behaviors (End.DT4, End.DT6, End.DT46, End.DX4, End.DX6) [RFC8986]. Layer 2 and transit behaviors MUST NOT be used.¶

• Disallowance of Transposition: Transposition Schemes [RFC9252] 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 BGP Prefix-SID Attribute received on a FlowSpec route is malformed, or does not contain a usable SRv6 SID Information Sub-TLV within an SRv6 L3 Service TLV, the headend MUST ignore the attribute, process the route as Mode 1 (Section 3.5), and SHOULD generate a diagnostic log entry. This is the "attribute discard" action of [RFC7606], consistent with Section 6 of [RFC8669]; the discarded attribute is not re-advertised.¶

3.8. Steering Failure and Fallback Procedures

Section 3.8.1 states how a route without a Color Extended Community is handled. Section 3.8.2 specifies the handling of a route within the scope of this document whose SR Policy or Egress Service SID cannot be resolved.¶

3.9. Handling of the Redirect-to-IP C-bit

The Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip] 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 Section 3.3.¶

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 Section 3.8 and Section 4.3 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.¶

3.10. Load Balancing Considerations

When matching traffic is steered into an SR Policy with multiple active Segment Lists [RFC9256], 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 [RFC8754], which also provides the entropy used for multipath hashing by transit nodes. This document imposes no additional requirement and grants no exception.¶

3.11. Backward Compatibility and Coexistence

A BGP speaker that implements base FlowSpec [RFC8955][RFC8956] 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 [RFC8669]. A speaker that does not recognize it propagates it with the Partial bit set [RFC4271].¶

• Forwarding on non-supporting headends: A non-supporting headend processes the route as specified in [I-D.ietf-idr-flowspec-redirect-ip].¶

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

4.1. Sequential Resolution Logic

The headend evaluates received attribute containers step-by-step:¶

Step 1: Redirect-to-IP Extended Community¶

• Absent: Procedures in this document do not apply. Process route per standard BGP FlowSpec [RFC8955][RFC8956].¶

• Present: Extract target IP as SR Policy Endpoint, process C-bit (Section 3.9), and proceed to Step 2.¶

Step 2: Color Extended Community¶

• Absent: The route is outside the scope of this document and is processed as specified in Section 3.8.1.¶

• Present: Extract Color value C to form the (Endpoint, Color) tuple, and proceed to Step 3.¶

Step 3: BGP Prefix-SID Attribute (PSID)¶

• Note: This step applies when steering into an SRv6 Policy (regardless of whether the Endpoint is encoded as an IPv4 or IPv6 address [RFC9256]).¶

• Absent (Mode 1): Resolve and steer traffic into the SR Policy corresponding to (Endpoint, Color) per Section 3.5.¶

• Present (Mode 2):¶

  • For SRv6 Steering: Extract the Egress Service SID from the PSID, resolve the SR Policy via (Endpoint, Color), and synthesize the active segment list per Section 3.5 and Section 3.7.¶

  • For SR-MPLS Steering: In accordance with Section 3.7, the BGP Prefix-SID Attribute MUST NOT be used for SR-MPLS steering. If the resolved (Endpoint, Color) tuple maps to an SR-MPLS Policy, the headend MUST ignore the BGP Prefix-SID Attribute, process the route as Mode 1 (Section 3.5), and SHOULD generate a diagnostic log entry.¶

4.2. Valid Attribute Combinations Summary

Table 1 summarizes all possible attribute combinations and their corresponding resolution modes after applying the sequential logic above.¶

Table 1: FlowSpec to SR Policy Steering Resolution

+-------------+----------+-----------+------------------------------+
| Redirect-   | Color EC | Prefix-SID| Steering Resolution Mode     |
| to-IP       |          |           |                              |
+-------------+----------+-----------+------------------------------+
| Present     | Present  | Absent    | Mode 1: Transport Steering   |
|             |          |           | (SR-MPLS / SRv6 USD)         |
+-------------+----------+-----------+------------------------------+
| Present     | Present  | Present   | Mode 2: Transport Steering + |
|             |          |           | Egress Service Action (SRv6) |
+-------------+----------+-----------+------------------------------+
| Present     | Absent   | Any       | Out of Scope for SR Policy   |
|             |          |           | (Standard Redirect-to-IP;    |
|             |          |           | Prefix-SID ignored)          |
+-------------+----------+-----------+------------------------------+
| Absent      | Ignored  | Ignored   | Out of Scope for SR Policy   |
|             |          |           | (Standard FlowSpec)          |
+-------------+----------+-----------+------------------------------+

4.3. 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 Section 3.8.2 apply; matching traffic is not forwarded by standard IP or Redirect-to-IP forwarding toward the target IP address.¶

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 [RFC8955], DSCP remarking) MUST continue to be enforced in the forwarding plane.¶

3. Multiple Redirect-to-IP Communities: When multiple valid Redirect-to-IP Extended Communities are attached alongside a Color Extended Community, load-sharing across the resulting target SR Policies MUST follow EC-level load-sharing defined in Section 2.2 of [I-D.ietf-idr-flowspec-redirect-ip].¶

4. 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 requirement 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.¶

6.1. 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 [RFC8986][RFC9252]) 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. BGP sessions with FlowSpec controllers MUST be secured using TCP-AO [RFC5925] and restricted to trusted entities.¶

6.2. Scope and Validation Limits of BGP FlowSpec Attributes

Standard BGP FlowSpec validation [RFC8955][RFC8956][RFC9117] validates the NLRI and Redirect-to-IP Extended Community against the origin of the destination prefix, but does not define validation for the Color Extended Community or BGP Prefix-SID Attribute. These unvalidated attributes dictate path selection and service contexts.¶

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 (Section 3.8.1): the traffic is then redirected as specified in [I-D.ietf-idr-flowspec-redirect-ip], 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 boundaries is specified in Section 6.3. Implementations SHOULD generate log messages or management alarms when unexpected attribute stripping is detected.¶

6.3. SR Domain Leakage and Boundary Security

SRv6 SIDs and BGP Prefix-SID Attributes are intended strictly for use within a trusted SR domain [RFC8402][RFC8754][RFC8986][RFC9252]. Propagation across untrusted EBGP boundaries leaks internal SRv6 Locators and topology, exposing the domain to external steering attacks.¶

BGP speakers at the boundary of the SR domain MUST remove the BGP Prefix-SID Attribute and the Color Extended Community from BGP FlowSpec routes advertised outside the domain (see also Section 5 of [RFC8669]). Where multiple ASes are under a single administrative control with explicit inter-domain trust, this filtering MAY instead be applied at the edge of that administrative domain.¶

6.4. 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 [RFC9117]. 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 [RFC8955] 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.¶

7.1. 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:
+---------+---------------+--------------------------------+
| Vendor  | Device Model  | Version                        |
+---------+---------------+--------------------------------+
| Huawei  | NE40E-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:
+----------------+---------------+-------------------------+
| Vendor         | System Name   | 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            |
+----------------+---------------+-------------------------+

7.2. 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 seamlessly 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 [RFC9256].¶

11.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, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-16>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[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, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4360]

Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[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, <https://www.rfc-editor.org/info/rfc7606>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[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, <https://www.rfc-editor.org/info/rfc8402>.

[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, <https://www.rfc-editor.org/info/rfc8660>.

[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, <https://www.rfc-editor.org/info/rfc8669>.

[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, <https://www.rfc-editor.org/info/rfc8754>.

[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, <https://www.rfc-editor.org/info/rfc8955>.

[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, <https://www.rfc-editor.org/info/rfc8956>.

[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, <https://www.rfc-editor.org/info/rfc8986>.

[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, <https://www.rfc-editor.org/info/rfc9012>.

[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, <https://www.rfc-editor.org/info/rfc9117>.

[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, <https://www.rfc-editor.org/info/rfc9252>.

[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, <https://www.rfc-editor.org/info/rfc9256>.

[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, <https://www.rfc-editor.org/info/rfc9830>.

11.2. Informative References

[RFC3411]

Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.

[RFC5424]

Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.

[RFC5925]

Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[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, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8639]

Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.

[RFC9800]

Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, <https://www.rfc-editor.org/info/rfc9800>.

[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, <https://www.rfc-editor.org/info/rfc9862>.

A.1. SR-MPLS Steering Example (Mode 1)

Figure 1 illustrates steering FlowSpec traffic into an SR-MPLS Policy without egress service actions (Section 3.3.1).¶

   +------------+
   |  BGP FS    |
   | Controller |
   +------------+
      | FlowSpec Route:
      |   NLRI: Filter Rules
      |   Redirect-to-IP: Endpoint Address
      |   Color EC: C0
      |   (Prefix-SID: Absent)
      |          .-----.
      |         (       )
      V     .--(         )--.
+-------+  (                 )  +-------+
|       |_(  SR-MPLS Network  )_|       |
|Headend| ( ================> ) |Tailend|
+-------+  (SR List<S1,S2,S3>)  +-------+
            '--(         )--'
                (       )
                 '-----'

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:¶

+---------------------------------------------+
| Outer IP / Ethernet Header                  |
+---------------------------------------------+
| MPLS Label S1 (Top)                         |
| MPLS Label S2                               |
| MPLS Label S3 (Bottom with S=1)             |
+---------------------------------------------+
| Inner Payload (Original IPv4/IPv6 Packet)   |
+---------------------------------------------+

A.2. 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).¶

   +------------+
   |  BGP FS    |
   | Controller |
   +------------+
      | FlowSpec Route:
      |   NLRI: Filter Rules
      |   Redirect-to-IPv6: Endpoint Address
      |   Color EC: C1
      |   Prefix-SID: Egress_Service_SID
      |          .-----.
      |         (       )
      V     .--(         )--.
+-------+  (                 )  +-------+
|       |_( SRv6 Core Network )_|       |
|Headend| ( ================> ) |Tailend|
+-------+  (SR List<S1,S2,S3>)  +-------+
            '--(         )--'   SRv6 SID: Egress_Service_SID
                (       )       (e.g., End.DT4, End.DT6, etc.)
                 '-----'

+-----------------------------------------------------+
| Outer IPv6 Header (DA = S1)                         |
+-----------------------------------------------------+
| SRH (Segments Left = 2 for Scenario A,              |
|      Segments Left = 3 for Scenario B)              |
|   Segment List: <S1, S2, Egress_Service_SID> (A)    |
|             OR: <S1, S2, S3, Egress_Service_SID> (B)|
+-----------------------------------------------------+
| Inner Payload (Original IPv4/IPv6 Packet)           |
+-----------------------------------------------------+

   +------------+
   |  BGP FS    |
   | Controller |
   +------------+
      | FlowSpec Route:
      |   NLRI: Filter Rules
      |   Redirect-to-IPv6: Endpoint Address
      |   Color EC: C2
      |   (Prefix-SID: Absent)
      |          .-----.
      |         (       )
      V     .--(         )--.
+-------+  (                 )  +-------+
|       |_( SRv6 Core Network )_|       |
|Headend| ( ================> ) |Tailend|
+-------+  (SR List<S1,S2,S3>)  +-------+
            '--(         )--'
                (       )
                 '-----'
Note: S3 is an SRv6 SID with USD flavor on the tailend.