| Internet-Draft | Flow-Spec Redirect to SR Segment List | February 2026 |
| Liu & Lin | Expires 17 August 2026 | [Page] |
BGP Flow Specification (Flow-spec) provides a mechanism for distributing traffic filtering and policy-based forwarding rules. Existing works enables traffic steering into an SR Policy. However, in Artificial Intelligence (AI) network scenarios, "elephant flows" may require deterministic forwarding over specific segment lists within an SR Policy candidate path.¶
This document specifies a new BGP Flow-spec Redirect action that identifies a specific segment list within an SR Policy.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
BGP Flow Specification (Flow-spec) [RFC8955] [RFC8956] is an extension to BGP that allows for the dissemination of traffic flow specification rules. BGP Flow-spec Version 2 (FSv2) is defined in [I-D.ietf-idr-flowspec-v2].¶
[RFC9256] details the concepts of Segment Routing (SR) Policy and steering into an SR Policy. An SR Policy consists of one or more candidate paths, each comprising one or more segment lists. As specified in [RFC9256], if a set of segment lists is associated with the active path of the policy, then the steering is per flow and weighted-ECMP (W-ECMP) based according to the relative weight of each segment list.¶
Traffic generated by AI training and sample transmission exhibits elephant flow characteristics. Compared to ordinary traffic, elephant flows are characterized by high per-flow bandwidth, and long duration. When the traffic carried by an SR Policy contains elephant flows, distributing traffic across segment lists randomly based on weights may cause elephant flows to be assigned to inappropriate segment lists, leading to network load imbalance, e.g., collocation with other large flows on shared links.¶
Currently BGP-FS supports steering traffic into an SR Policy. [I-D.ietf-idr-ts-flowspec-srv6-policy] enables steering into an SR Policy using the address in the Redirect-to-IP action [I-D.ietf-idr-flowspec-redirect-ip] as the endpoint and the color in the Color Extended Community [RFC9012] as the color of the target SR Policy. [I-D.ietf0-idr-srv6-flowspec-path-redirect] proposes a scheme that steers traffic into an SR Policy through a Binding SID. [I-D.li-idr-flowspec-sr-policy] defines a FSv2 Redirect to SR Policy action directly using Policy Color and endpoint as the identifier.¶
This document extends BGP-FS to allow traffic to be redirected to a specific segment list within an SR Policy candidate path.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses terminology from [RFC8955], [RFC9256], and [RFC9857].¶
This action instructs the headend to redirect matching traffic into a specific segment list of a specific candidate path of an SR Policy.¶
This action is encoded as a Flow Specification v2 (FSv2) Action SubTLV carried in a Wide Community container [I-D.ietf-idr-wide-bgp-communities].¶
The Redirect to Segment List action is encoded as a single FSv2 Action SubTLV.¶
Sub-Type: TBD1 (2 octets)
Length: 2 octets, indicating the total number of octets of the
Value field.
Value: Variable, formatted as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Endpoint (4 or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-Origin (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator( 20octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Flags field is 1 octet and defined as follows:¶
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|R| Reserved |
+-+-+-+-+-+-+-+-+
F (Fallback Enabled - 1 bit):
When set (1), the headend MUST perform the fallback procedure
described in Section 3.2 if the designated segment list or
candidate path becomes invalid or ceases to be the active
candidate path. When clear (0), the headend MUST NOT fall back.¶
R (Recovery - 1 bit):
When set (1), indicates that if the designated segment list
later recovers, the headend SHOULD revert to pinning the traffic
flow onto it. When clear (0), the headend SHOULD NOT
automatically revert.¶
Reserved (6 bits):
MUST be set to 0 on transmission and ignored on receipt.¶
Color (4 octets):
The Color value of the target SR Policy, an unsigned non-zero
32-bit integer.¶
AFI (2 octets):
Address Family Identifier of the Endpoint. Values are taken from
IANA's "Address Family Numbers" registry. This field determines
the length of the Endpoint field:
- 1 (IPv4): Endpoint = 4 octets
- 2 (IPv6): Endpoint = 16 octets
Other AFI values are reserved and MUST NOT be sent; if received,
the entire Action SubTLV MUST be treated as malformed
(Section 4).¶
Endpoint (variable):
The endpoint address of the SR Policy, encoded according to the
AFI field.¶
Protocol-Origin (4 octets):
The Protocol-Origin value of the candidate path.
(See [RFC9256] Section 2.3.)¶
Originator (20 octets):
The Originator of the candidate path as specified in
[RFC9256] Section 2.4.¶
Discriminator (4 octets):
The Discriminator of the candidate path, as defined in
[RFC9256] Section 2.5.¶
Segment List ID (4 octets):
The identifier of the segment list within the candidate path.
The value zero is reserved and MUST NOT be used; if received,
the Action SubTLV MUST be treated as malformed.¶
Upon receipt of a Flow Specification route containing this Action SubTLV, the headend MUST perform the following steps in order:¶
If any of these steps fail, the Action SubTLV is considered invalid, and the Flow Specification rule continues to be processed as if this Action SubTLV were not present. An implementation SHOULD log the validation failure.¶
If all steps succeed, the headend installs a forwarding rule that redirects matching traffic exclusively to the designated segment list. Traffic SHOULD NOT be load-balanced to other segment lists within the same candidate path.¶
After successful installation, if the F-Flag is set and any of the following events occur:¶
Then the headend MUST revert to ordinary SR Policy forwarding behavior as defined in [RFC9256].¶
An implementation SHOULD generate an alert to indicate that explicit path pinning is no longer in effect and the reason for fallback.¶
If the R-Flag is set and the designated segment list later recovers (becomes valid again) while the designated candidate path remains active, the headend SHOULD revert to pinning the traffic flow onto the recovered segment list.¶
An implementation MAY apply a configurable revert timer to avoid flapping. During the reversion process, traffic MUST NOT be dropped. The transition MAY be performed via make-before-break.¶
If the R-Flag is clear, the headend SHOULD NOT automatically revert. A controller MAY withdraw and re-advertise the Flow Specification route to re-establish pinning.¶
A Redirect to SR Policy Segment List SubTLV is considered malformed if:¶
Malformed SubTLVs MUST be handled according to [RFC7606] as treat-as-withdraw. The implementation SHOULD log the error.¶
IANA is requested to assign a new Action Sub-Type value from the "BGP FSv2 Action types" registry (established by [I-D.ietf-idr-flowspec-v2]) for the action defined in this document.¶
Sub-Type Name Reference
--------------------------------------------------------
TBD1 Redirect to SR Policy Segment List [this document]
¶
The security considerations of [RFC8955], [RFC9256], and [I-D.ietf-idr-flowspec-v2] apply.¶
The ability to pin traffic to a specific candidate path and segment list introduces additional risk. A malicious controller could direct all elephant flows to a single segment list, causing link overload and congestion collapse. Operators SHOULD:¶