BGP Extensions for SRv6 Per-Flow Traffic Engineering: Composite Candidate Path and Forwarding-Class Signaling
draft-ramasamy-idr-sr-policy-composite-perflow-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Selvamani Ramasamy , Manoharan Sundaramoorthy , Shyam Sethuram , Venkit Kasiviswanathan | ||
| Last updated | 2026-05-31 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ramasamy-idr-sr-policy-composite-perflow-00
Inter-Domain Routing S. Ramasamy, Ed.
Internet-Draft M. Sundaramoorthy
Intended status: Standards Track S. Sethuram
Expires: 30 November 2026 V. Kasiviswanathan
Nexthop AI
29 May 2026
BGP Extensions for SRv6 Per-Flow Traffic Engineering: Composite
Candidate Path and Forwarding-Class Signaling
draft-ramasamy-idr-sr-policy-composite-perflow-00
Abstract
The Segment Routing Policy Architecture (RFC 9256) defines the
concept of a Composite Candidate Path, which enables a parent SR
Policy to recursively steer traffic into a set of constituent SR
Policies. Section 8.6 of RFC 9256 further defines per-flow steering,
in which packets are classified into a Forwarding Class value by a
Quality-of-Service classifier at the headend, and that Forwarding
Class value selects a specific constituent SR Policy, identified by
its color, for forwarding.
RFC 9830 specifies how BGP distributes SR Policy Candidate Paths but
explicitly excludes composite Candidate Paths from its scope.
Consequently, no standard BGP mechanism currently exists to
distribute a parent per-flow SR Policy -- including its Forwarding-
Class-to-color mapping table -- to headend nodes. This document
defines two new sub-TLVs for the BGP Tunnel Encapsulation Attribute
(SR Policy type, Tunnel Type 15): the Constituent SR Policy sub-TLV
and the nested Per-Flow Forwarding Class sub-TLV. Together, these
extensions allow a controller to distribute a fully specified
composite or per-flow Candidate Path to headend routers via BGP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
Ramasamy, et al. Expires 30 November 2026 [Page 1]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
This Internet-Draft will expire on 30 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Per-Flow Traffic Engineering . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Composite CPs Are Outside RFC 9830 Scope . . . . . . . . 7
3.2. Controller-to-Headend Signaling Gap . . . . . . . . . . . 7
3.3. Interaction with the Color Extended Community . . . . . . 7
4. BGP SR Policy Encoding Extensions . . . . . . . . . . . . . . 8
4.1. Extended SR Policy Encoding Structure . . . . . . . . . . 8
4.2. Constituent SR Policy Sub-TLV . . . . . . . . . . . . . . 9
4.3. Per-Flow Forwarding Class (FC) Sub-TLV . . . . . . . . . 11
5. Encoding Example . . . . . . . . . . . . . . . . . . . . . . 13
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Origination . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Reception and SRPM Processing . . . . . . . . . . . . . . 15
6.3. Route Reflector Transparency . . . . . . . . . . . . . . 16
6.4. Graceful Restart . . . . . . . . . . . . . . . . . . . . 16
6.5. Capability Advertisement . . . . . . . . . . . . . . . . 16
6.6. Backward Compatibility . . . . . . . . . . . . . . . . . 17
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 17
8. Relationship to Other Documents . . . . . . . . . . . . . . . 19
8.1. RFC 9256 -- SR Policy Architecture . . . . . . . . . . . 19
8.2. RFC 9830 -- Advertising SR Policies in BGP . . . . . . . 20
8.3. BGP-LS Northbound Collection . . . . . . . . . . . . . . 20
8.4. PCEP Per-Flow Encoding . . . . . . . . . . . . . . . . . 20
8.5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . 20
9. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Distribution Ordering . . . . . . . . . . . . . . . . . . 21
Ramasamy, et al. Expires 30 November 2026 [Page 2]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
9.2. Per-Peer State Limits . . . . . . . . . . . . . . . . . . 21
9.3. Convergence and Reconvergence . . . . . . . . . . . . . . 21
9.4. Observability . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. BGP Tunnel Encapsulation Attribute Sub-TLVs Registry . . 23
11.2. Constituent SR Policy Sub-TLV Types Registry . . . . . . 24
12. Normative References . . . . . . . . . . . . . . . . . . . . 24
13. Informative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
Segment Routing (SR) [RFC8402] allows a headend node to steer packet
flows along any explicitly specified path. The headend instantiates
an SR Policy [RFC9256] identified by the tuple <Headend, Color,
Endpoint>. A Candidate Path (CP) is the unit of signaling, and RFC
9830 specifies how BGP distributes these CPs to headends using a
dedicated SR Policy SAFI (SAFI 73) with Tunnel Encapsulation
Attribute sub-TLVs.
RFC 9256 Section 2.2 defines three types of Candidate Paths:
* *Explicit:* A specific set of Segment Lists.
* *Dynamic:* An optimization objective and constraints.
* *Composite:* A container grouping multiple constituent SR Policies
for combined steering.
The Composite CP enables the construction of a parent SR Policy that
distributes traffic across multiple constituent SR Policies, each
identified by a distinct color and sharing the same headend and
endpoint as the parent.
1.1. Per-Flow Traffic Engineering
Section 8.6 of RFC 9256 specifies per-flow steering. A headend
maintains a forwarding array indexed by a Forwarding Class (FC)
value. Each index maps to either:
* The IGP (Interior Gateway Protocol) shortest path to the endpoint
(the default), or
* A constituent SR Policy identified by its color.
Ramasamy, et al. Expires 30 November 2026 [Page 3]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
A Quality-of-Service (QoS) classifier on ingress assigns each packet
an FC value derived from DSCP (Differentiated Services Code Point)
markings, 802.1p bits, or other local policy. The headend then
steers the packet into the SR Policy (or IGP path) corresponding to
that FC.
The FC field width and value range are encoding choices of this
document. This document encodes FC as a 3-bit value (range 0-7); see
Section 4.3. Implementations that natively classify traffic into
more than 8 forwarding classes are responsible for mapping their
internal classes onto the 0-7 range before BGP signaling.
The configuration model below illustrates this construct
(illustrative, implementation-agnostic syntax):
! Segment lists for constituent policies
segment-list SL_GOLD
index 10 srv6-sid 2001:db8:100::1
segment-list SL_SILVER
index 10 srv6-sid 2001:db8:200::1
! Child SR Policy: color 100, endpoint 2001:db8::1
policy color 100 endpoint 2001:db8::1
candidate-path preference 100 name p100 explicit
segment-list SL_GOLD
! Child SR Policy: color 200, same endpoint
policy color 200 endpoint 2001:db8::1
candidate-path preference 100 name p200 explicit
segment-list SL_SILVER
! Parent per-flow SR Policy: color 300, endpoint 2001:db8::1
! FC 1 -> color 100 (high-priority path)
! FC 2 -> color 200 (best-effort path)
! FC 0,3-7 -> IGP (default)
policy color 300 endpoint 2001:db8::1
candidate-path preference 70 name pf300 per-flow
forwarding-class 1 color 100
forwarding-class 2 color 200
forwarding-class default action igp
In a controller-driven deployment, the controller must distribute
this parent policy -- including the FC-to-color mapping -- to the
headend via BGP. RFC 9830 provides no mechanism to do so. This
document fills that gap.
Ramasamy, et al. Expires 30 November 2026 [Page 4]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
1.2. Scope
This document:
* Defines the *Constituent SR Policy sub-TLV* as a new optional sub-
TLV within the BGP Tunnel Encapsulation Attribute SR Policy type
(Tunnel Type 15).
* Defines the *Per-Flow Forwarding Class (FC) sub-TLV* as a nested
optional sub-TLV within the Constituent SR Policy sub-TLV.
* Specifies procedures for origination, advertisement, reception,
and SR Policy Module (SRPM) processing of composite and per-flow
Candidate Paths distributed via BGP.
* Specifies error handling for malformed sub-TLVs.
* Requests IANA allocations for the new sub-TLV code points.
This document does not modify any sub-TLV defined in RFC 9830 or RFC
9012. The SR Policy BGP SAFI (Subsequent Address Family Identifier),
NLRI format, RR propagation rules, and best-path selection procedures
of RFC 9830 remain unchanged. Inter-AS distribution of Composite
Candidate Paths is out of scope; the same operational caveats as RFC
9830 Section 8 apply. PCEP (Path Computation Element Communication
Protocol)-based composite CP distribution is addressed by
[I-D.ietf-pce-multipath] and is out of scope.
This document covers similar ground to other individual Internet-
Drafts addressing BGP distribution of Composite Candidate Paths
(e.g., [I-D.jiang-idr-sr-policy-composite-path]). The authors
encourage coordination and possible consolidation with such efforts
during IDR WG discussion.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
This document uses terms defined in [RFC9256] and [RFC9830].
Additional terms used are:
SR Policy: Identified by <Headend, Color, Endpoint>; a source-
Ramasamy, et al. Expires 30 November 2026 [Page 5]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
routing policy defined by an ordered list of segments [RFC9256].
Candidate Path (CP): The unit of signaling for an SR Policy. May be
explicit, dynamic, or composite [RFC9256].
Composite CP: A CP that groups constituent SR Policies for combined
or per-flow steering (RFC 9256, Section 2.2).
Constituent SR Policy: A child SR Policy forming part of a Composite
CP; referenced solely by color (RFC 9256, Section 2.2).
FC (Forwarding Class): A value assigned to a packet by an ingress
QoS classifier and used to select a per-flow forwarding entry,
consistent with the Forwarding Class concept of RFC 9256,
Section 8.6. This document encodes FC as a 3-bit value (range
0-7); see Section 4.3.
Per-Flow Steering: A mode where each FC maps to a constituent SR
Policy or the IGP path, consistent with RFC 9256, Section 8.6.
Parent SR Policy: The SR Policy whose active CP is a Composite CP.
Has its own distinct color.
SRPM: SR Policy Module -- the headend block that processes SR Policy
information and installs it in the forwarding plane [RFC9830].
BFD: Bidirectional Forwarding Detection [RFC5880].
DSCP: Differentiated Services Code Point [RFC2474].
ENLP: Explicit NULL Label Policy sub-TLV [RFC9830].
EVPN: Ethernet Virtual Private Network [RFC7432].
IGP: Interior Gateway Protocol.
PCE: Path Computation Element.
PCEP: Path Computation Element Communication Protocol.
QoS: Quality of Service.
ROV: Route Origin Validation [RFC6811].
SAFI: Subsequent Address Family Identifier.
VPN: Virtual Private Network.
Ramasamy, et al. Expires 30 November 2026 [Page 6]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
3. Problem Statement
3.1. Composite CPs Are Outside RFC 9830 Scope
RFC 9830 Section 1 explicitly states: _"The signaling of Dynamic and
Composite CPs (Sections 5.2 and 5.3, respectively, of [RFC9256]) is
outside the scope of this document."_ As a consequence, RFC 9830
defines no sub-TLV encoding for: the list of constituent SR Policies
forming a Composite CP; the FC-to-color mapping enabling per-flow
steering; or the default action for unmatched FC values.
3.2. Controller-to-Headend Signaling Gap
In a controller-driven SRv6 TE deployment, an SR Policy Controller
distributes SR Policies to headends via BGP SAFI 73. For per-flow
TE:
1. The controller computes constituent SR Policies (e.g., color 100
for high-priority traffic, color 200 for best-effort).
2. The controller computes the parent per-flow SR Policy (e.g.,
color 300) with the FC mapping.
3. The controller distributes constituent policies (colors 100 and
200) via RFC 9830. This works today.
4. The controller distributes the parent per-flow policy (color 300)
via BGP. This fails -- no composite/FC encoding exists in RFC
9830.
Step 4 forces operators to configure the parent policy via CLI or
NETCONF on every headend, defeating controller-driven automation.
This document addresses that gap.
3.3. Interaction with the Color Extended Community
The Color Extended Community [RFC9012] enables BGP service routes
(unicast, VPN, EVPN) to be steered into SR Policies at the headend by
matching the community color to the SR Policy color. For per-flow
TE:
* Service routes carry the color of the *parent* SR Policy (e.g.,
color 300).
* The headend steers matching traffic into the parent policy.
* The parent policy's per-flow Composite CP steers each packet to a
constituent SR Policy based on its FC value.
Ramasamy, et al. Expires 30 November 2026 [Page 7]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
The Color Extended Community mechanism requires no change. The
extensions defined in this document operate entirely at the SR Policy
SAFI layer and do not affect service route processing.
4. BGP SR Policy Encoding Extensions
4.1. Extended SR Policy Encoding Structure
RFC 9830 defines the SR Policy encoding using the BGP Tunnel
Encapsulation Attribute (Attribute Type 23, Tunnel Type 15). This
document extends that structure with the Constituent SR Policy sub-
TLV as a new optional sub-TLV within Tunnel Type 15.
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encapsulation Attribute (Type 23)
Tunnel Type: SR Policy (15)
Binding SID sub-TLV [optional, RFC 9830]
SRv6 Binding SID sub-TLV [optional, RFC 9830]
Preference sub-TLV [optional, RFC 9830]
Priority sub-TLV [optional, RFC 9830]
SR Policy Name sub-TLV [optional, RFC 9830]
SR Policy CP Name sub-TLV [optional, RFC 9830]
ENLP sub-TLV [optional, RFC 9830]
Constituent SR Policy sub-TLV [optional, THIS DOCUMENT]
RESERVED (2 octets)
Color (4 octets)
Weight (4 octets)
Per-Flow FC sub-TLV [optional, THIS DOCUMENT]
Constituent SR Policy sub-TLV [optional, MAY repeat]
...
*Mutual Exclusion:* A Constituent SR Policy sub-TLV and a Segment
List sub-TLV (Type 128, RFC 9830) MUST NOT appear in the same SR
Policy Tunnel Type encoding. A Candidate Path is either composite
(uses Constituent SR Policy sub-TLVs) or explicit/dynamic (uses
Segment List sub-TLVs). Presence of both is a malformed condition
(Section 7, Condition 1).
*Candidate-path selection:* When both Composite and explicit/dynamic
Candidate Paths are advertised for the same <Headend, Color,
Endpoint>, Candidate Path selection follows Section 2.9 of [RFC9256].
The composite encoding does not alter the preference-based ordering.
Ramasamy, et al. Expires 30 November 2026 [Page 8]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
4.2. Constituent SR Policy Sub-TLV
The Constituent SR Policy sub-TLV is a new optional sub-TLV of the
BGP Tunnel Encapsulation Attribute SR Policy Tunnel Type. It encodes
a single constituent SR Policy within a Composite CP. Multiple
occurrences MAY appear in the same SR Policy encoding, each
representing one constituent SR Policy. The ordering of occurrences
is not significant.
*Wire Format:*
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (variable length, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*Fields:*
Type: To be assigned by IANA from the "BGP Tunnel Encapsulation
Attribute Sub-TLVs" registry under the Standards Action policy.
Length: 1-octet unsigned integer. Total length in octets of all
fields following the Length field (RESERVED + Color + Weight +
sub-TLVs). The minimum value is *10* (2 octets RESERVED + 4
octets Color + 4 octets Weight). A Length value less than 10 is a
malformed condition (Section 7, Condition 8).
RESERVED: 2 octets. MUST be set to zero on transmission and MUST be
ignored on receipt. The 2-octet RESERVED field preserves 32-bit
word alignment for the Color and Weight fields.
The 1-octet Length field limits the total nested sub-TLV content
per Constituent SR Policy sub-TLV to 245 octets (255 minus the 10
bytes of fixed fields). Future nested sub-TLVs requiring more
than 245 octets of combined content will require a separate 2-
octet-Length Constituent sub-TLV code point to be defined at that
time.
Color: 4-octet unsigned non-zero integer. Identifies the
Ramasamy, et al. Expires 30 November 2026 [Page 9]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
constituent SR Policy. Constituent SR Policies share the headend
and endpoint of the parent SR Policy; they are uniquely identified
by this Color within the context of the parent. The Color MUST
NOT equal zero (Section 7, Condition 9) and MUST NOT equal the
Color of the parent SR Policy in the NLRI (Section 7, Condition
7). All Constituent SR Policy sub-TLVs within a single SR Policy
encoding MUST carry distinct Color values (Section 7, Condition
10).
Weight: 4-octet unsigned integer. Specifies the weight of this
constituent SR Policy for weighted load-balancing, consistent with
Section 2.11 of [RFC9256]. The Weight field is always present on
the wire as a fixed 4-octet field; there is no implicit/absent
default on receipt. On origination, controllers SHOULD encode
Weight=1 when no explicit weight policy is configured.
In *weighted load-balancing mode* (no Per-Flow FC sub-TLV present
in any Constituent SR Policy sub-TLV in the encoding), a Weight
value of zero marks that constituent as receiving no traffic; this
is a constituent-level validity outcome, not a treat-as-withdraw
condition. If the Weight values of _all_ constituents in the
encoding are zero, the Composite CP carries no traffic and is
treated as malformed (Section 7, Condition 3).
In *per-flow steering mode* (every Constituent SR Policy sub-TLV
carries a Per-Flow FC sub-TLV), the Weight field has no load-
balancing effect between FC-mapped constituents (per-flow steering
directs each classified packet to a single constituent) and MUST
be ignored on receipt. Originators MAY encode any value; the
value is not interpreted. Weighted load balancing within the
active CP of the constituent SR Policy itself remains governed by
Section 2.11 of [RFC9256].
sub-TLVs: Variable-length field containing zero or one Per-Flow FC
sub-TLV (Section 4.3) and optionally other sub-TLVs defined in the
future.
*Semantics -- Weighted Load Balancing Mode:* When no Per-Flow FC sub-
TLV is present in a Constituent SR Policy sub-TLV, the constituent
participates in weighted load balancing over all traffic steered into
the parent policy. The traffic fraction steered to this constituent
is w_i / sum_j(w_j), where w_i is this Weight and the sum is over all
valid constituents in the Composite CP.
*Semantics -- Per-Flow Steering Mode:* When a Per-Flow FC sub-TLV is
present, the constituent receives only traffic classified to the
specified FC value.
Ramasamy, et al. Expires 30 November 2026 [Page 10]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
*Mixed encoding* is not permitted: all Constituent SR Policy sub-TLVs
in a single encoding MUST either all include a Per-Flow FC sub-TLV or
all omit it. The rationale is that mixing FC-classified and
weighted-LB traffic in one Composite CP would require defining a
residual-traffic policy for unclassified FC values in the presence of
weighted constituents, which is not specified and creates ambiguous
behavior. A mixed encoding is a malformed condition (Section 7,
Condition 6).
4.3. Per-Flow Forwarding Class (FC) Sub-TLV
The Per-Flow FC sub-TLV is a nested optional sub-TLV within the
Constituent SR Policy sub-TLV. It assigns a 3-bit FC value to the
containing constituent SR Policy, enabling QoS-based per-flow
steering.
*Wire Format:*
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length(=2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| RESERVED | FC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-TLV is 4 octets total: 1-octet Type + 1-octet Length + 2
octets of value content.
The 2-octet value field is laid out as follows, where bit 0 is the
most significant bit of the first value octet:
Bit 0 : D (Default-Drop flag)
Bits 1-12 : RESERVED (12 bits)
Bits 13-15 : FC (3 bits; LSBs of the second value octet)
All 16 bits of the value field are accounted for: 1 (D) + 12
(RESERVED) + 3 (FC) = 16 bits.
*Fields:*
Type: To be assigned by IANA from the new "Constituent SR Policy
Sub-TLV Types" registry (Section 11.2).
Length: 1 octet. MUST be 2. A value other than 2 is a malformed
condition (Section 7, Condition 5).
D (Default-Drop flag, bit 0): When set to 1, if the constituent SR
Ramasamy, et al. Expires 30 November 2026 [Page 11]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
Policy referenced by this sub-TLV becomes invalid, traffic for
this FC entry MUST be dropped rather than forwarded via the IGP
path. When set to 0 (default), traffic falls back to the IGP
shortest path to the endpoint. This flag provides an extension
point for the default-action choice described in RFC 9256,
Section 8.6; absent this flag the per-flow default action is
resolved via local policy per that section.
RESERVED (bits 1-12, 12 bits): MUST be set to zero on transmission
and MUST be ignored on receipt.
FC (bits 13-15, 3 bits): The Forwarding Class value for this
constituent SR Policy. Valid range: 0-7. Different Constituent
SR Policy sub-TLVs within the same SR Policy encoding MUST carry
distinct FC values (Section 7, Condition 2).
*Nested-registry Length convention.* All sub-TLVs registered in the
"Constituent SR Policy Sub-TLV Types" registry (Section 11.2) --
across both the Standards Action range (1-127) and the Expert Review
range (128-254) -- use a *1-octet Length field*, regardless of Type
value. This nested registry does not follow the RFC 9012, Section 2
high-bit Type / Length-width rule used for the parent BGP Tunnel
Encapsulation Attribute Sub-TLVs registry. The 1-octet Length field
bounds any single nested sub-TLV's value content to 255 octets, which
is sufficient for the per-Constituent extension points anticipated by
this document. Definitions of future nested sub-TLVs in this
registry MUST conform to this convention.
*Semantics:* Upon receiving a Composite CP with Per-Flow FC sub-TLVs,
the SRPM builds an FC-indexed steering array as follows:
* All eight FC entries (0-7) are initialized to the IGP shortest
path to the endpoint (the default action, consistent with RFC
9256, Section 8.6).
* For each Constituent SR Policy sub-TLV carrying a Per-Flow FC sub-
TLV, the array entry at index FC is set to the constituent SR
Policy identified by Color.
* If the constituent SR Policy for a given FC entry becomes invalid,
the SRPM reverts that entry to the IGP shortest path (D=0) or
drops traffic (D=1), consistent with RFC 9256, Section 8.6.
* FC values not mapped by any Constituent SR Policy sub-TLV retain
the default IGP action throughout the lifetime of the Composite
CP.
Ramasamy, et al. Expires 30 November 2026 [Page 12]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
5. Encoding Example
The following example encodes the parent per-flow SR Policy from
Section 1.1 (color 300, endpoint 2001:db8::1, preference 70, CP name
"pf300"). FC 1 maps to color 100 and FC 2 maps to color 200. All
other FCs default to IGP (D=0 for both).
The Weight value of 1 shown in each Constituent SR Policy sub-TLV
below is illustrative; because every constituent carries a Per-Flow
FC sub-TLV, this is per-flow steering mode and the Weight field is
ignored on receipt (Section 4.2).
*SR Policy SAFI NLRI:*
Distinguisher : 1
Color : 300
Endpoint : 2001:db8::1 (AFI=2, SAFI=73)
*BGP Tunnel Encapsulation Attribute (Type 23, Tunnel Type 15):*
Preference sub-TLV (Type 12):
Preference: 70
SR Policy CP Name sub-TLV (Type 129):
Name: "pf300"
Constituent SR Policy sub-TLV (Type TBA1):
Length: 14 (2 RESERVED + 4 Color + 4 Weight + 4 FC sub-TLV)
RESERVED: 0x0000
Color: 100
Weight: 1
Per-Flow FC sub-TLV (Type TBA2):
Length: 2
Value octet 0: 0x00 (D=0, RESERVED bits 1-7 = 0)
Value octet 1: 0x01 (bits 8-12 = 0; FC bits 13-15 = 001 = 1)
Decoded: D=0, RESERVED=0, FC=1 (FC 1 -> color 100)
Constituent SR Policy sub-TLV (Type TBA1):
Length: 14
RESERVED: 0x0000
Color: 200
Weight: 1
Per-Flow FC sub-TLV (Type TBA2):
Length: 2
Value octet 0: 0x00 (D=0, RESERVED bits 1-7 = 0)
Value octet 1: 0x02 (bits 8-12 = 0; FC bits 13-15 = 010 = 2)
Decoded: D=0, RESERVED=0, FC=2 (FC 2 -> color 200)
Ramasamy, et al. Expires 30 November 2026 [Page 13]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
The SRPM on the receiving headend installs the following FC steering
array for SR Policy (color 300, endpoint 2001:db8::1):
+====+==============================+=====================+
| FC | Forwarding Action | Fallback on Invalid |
+====+==============================+=====================+
| 0 | IGP to 2001:db8::1 (default) | -- |
+----+------------------------------+---------------------+
| 1 | SR Policy color 100 -- SID | IGP (D=0) |
| | 2001:db8:100::1 | |
+----+------------------------------+---------------------+
| 2 | SR Policy color 200 -- SID | IGP (D=0) |
| | 2001:db8:200::1 | |
+----+------------------------------+---------------------+
| 3 | IGP to 2001:db8::1 (default) | -- |
+----+------------------------------+---------------------+
| 4 | IGP to 2001:db8::1 (default) | -- |
+----+------------------------------+---------------------+
| 5 | IGP to 2001:db8::1 (default) | -- |
+----+------------------------------+---------------------+
| 6 | IGP to 2001:db8::1 (default) | -- |
+----+------------------------------+---------------------+
| 7 | IGP to 2001:db8::1 (default) | -- |
+----+------------------------------+---------------------+
Table 1
6. Procedures
6.1. Origination
An SR Policy Controller or BGP egress router originating a Composite
or per-flow SR Policy CP MUST:
1. Set the SR Policy SAFI NLRI to represent the *parent* SR Policy
(e.g., color 300, endpoint 2001:db8::1).
2. Include one Constituent SR Policy sub-TLV per constituent SR
Policy. Each MUST carry a non-zero Color field that does not
equal the parent policy's color or the color of any other
Constituent SR Policy sub-TLV in the same encoding.
3. For per-flow steering, include a Per-Flow FC sub-TLV within each
applicable Constituent SR Policy sub-TLV. All constituents MUST
include the FC sub-TLV (no mixed encoding).
4. MUST NOT include a Segment List sub-TLV (Type 128) in the same
encoding as any Constituent SR Policy sub-TLV.
Ramasamy, et al. Expires 30 November 2026 [Page 14]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
5. Originate separate BGP SR Policy SAFI updates for each
constituent (child) SR Policy using standard RFC 9830 Segment
List sub-TLVs, as these are distinct NLRIs.
6. Distribute constituent (child) SR Policies *before* the parent
Composite CP. While the SRPM tolerates transient inversion by
treating unknown constituents as invalid (Section 6.2),
controllers SHOULD sequence updates in child-then-parent order to
minimize disruption during initial convergence.
6.2. Reception and SRPM Processing
Upon receiving a BGP UPDATE carrying an SR Policy SAFI NLRI with one
or more Constituent SR Policy sub-TLVs, the BGP speaker applies
standard BGP best-path selection per RFC 9830 to choose the best-path
NLRI for the <Distinguisher, Color, Endpoint> tuple. The resulting
Candidate Path is then offered to the SRPM along with locally
configured and PCEP-signaled Candidate Paths for the same <Headend,
Color, Endpoint> SR Policy. The SRPM performs its own Candidate Path
selection across all sources per Section 2.9 of [RFC9256]; the BGP
best-path output is one input to that selection, not the final
outcome.
The SRPM SHALL:
1. Recognize the CP as a *Composite CP* type per RFC 9256,
Section 2.2.
2. For each Constituent SR Policy sub-TLV, identify the
corresponding child SR Policy at the local headend by matching
<Headend, Color=sub-TLV Color, Endpoint>.
3. If a referenced constituent SR Policy is not locally known or has
no valid CP, treat that constituent as *invalid*. The Composite
CP remains valid as long as at least one constituent is valid,
consistent with RFC 9256, Section 5.3. If all constituents are
invalid, the Composite CP is invalid. If no other CP exists for
the parent SR Policy, the parent SR Policy is invalid, and
service routes steered by the Color Extended Community fall back
to their unsteered BGP next hop.
4. Install the FC-indexed steering array per Section 4.3 semantics.
5. The SRPM SHOULD install the FC array *atomically* with respect to
packet classification to avoid transient mis-steering during
Composite CP changes.
Ramasamy, et al. Expires 30 November 2026 [Page 15]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
6. Monitor liveness of constituent SR Policies. If a constituent
transitions from valid to invalid, the SRPM MUST update the
corresponding FC entry to the appropriate fallback (IGP path or
drop per D flag) without waiting for a BGP update.
*Convergence behavior:* If the parent Composite CP arrives before one
or more constituent SR Policies have been installed by BGP, the SRPM
MUST treat those missing constituents as invalid (applying IGP or
drop fallback for their FC entries) and MUST update the FC array when
the constituent later becomes valid. Liveness monitoring (step 6)
handles the transition once convergence completes.
6.3. Route Reflector Transparency
Route Reflectors (RRs) [RFC4456] that do not implement the sub-TLVs
defined in this document MUST propagate the Constituent SR Policy
sub-TLV and its nested Per-Flow FC sub-TLV unchanged, consistent with
the handling of unknown sub-TLVs specified in Section 2 of [RFC9012],
as applied by [RFC9830].
6.4. Graceful Restart
During BGP Graceful Restart [RFC4724] and Long-Lived Graceful Restart
[RFC9494], stale Composite CP routes remain installed at the SRPM for
the duration of the stale-routes timer. Constituent SR Policy
liveness is handled independently per RFC 4724 / RFC 9494 for those
NLRIs. The Composite CP need not be re-validated against constituent
liveness during the stale interval, to avoid blackholing traffic
during BGP session restart.
6.5. Capability Advertisement
A BGP speaker indicates support for Composite CP processing
implicitly by advertising SR Policy SAFI (SAFI 73) capability in the
BGP OPEN message. A headend that supports SAFI 73 but does not
implement this document's extensions will ignore the Constituent SR
Policy sub-TLV as an unknown sub-TLV per RFC 9830, rendering the
parent CP invalid (Section 6.6). This is a safe failure mode. No
separate capability code is defined.
Operators SHOULD verify that headend software supports Composite CP
processing before distributing parent per-flow policy advertisements.
Where available, the headend's YANG operational state model (see
Section 8.5 for companion YANG status) or BGP-LS state collection
(Section 8.3) may be used to confirm support; absent such telemetry,
operators may rely on vendor release notes or controlled-rollout
testing.
Ramasamy, et al. Expires 30 November 2026 [Page 16]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
6.6. Backward Compatibility
BGP speakers that do not implement this document will encounter an
unknown sub-TLV type in the SR Policy Tunnel Encapsulation. Per RFC
9830, unknown sub-TLVs are ignored. The SRPM will see no Segment
List sub-TLVs and no Constituent SR Policy sub-TLVs, treating the
Candidate Path as having no valid forwarding information and marking
it invalid. No incorrect forwarding state is installed. This is a
safe failure mode.
7. Error Handling
Error handling for BGP UPDATE messages follows the "treat-as-
withdraw" strategy of [RFC7606] and RFC 9830, Section 5. Each of the
following conditions constitutes a malformed SR Policy NLRI; the
treat-as-withdraw procedure MUST be applied:
Ramasamy, et al. Expires 30 November 2026 [Page 17]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
+====+==============================================================+
| # | Malformed Condition |
+====+==============================================================+
| 1 | A Segment List sub-TLV (Type 128) and one or more |
| | Constituent SR Policy sub-TLVs co-exist in the same |
| | SR Policy encoding. |
+----+--------------------------------------------------------------+
| 2 | Two or more Constituent SR Policy sub-TLVs carry Per- |
| | Flow FC sub-TLVs with duplicate FC values. |
+----+--------------------------------------------------------------+
| 3 | In weighted load-balancing mode, the Weight values of |
| | ALL Constituent SR Policy sub-TLVs in the encoding |
| | are zero (so no traffic can be steered into any |
| | constituent). (Per-constituent Weight=0 is a |
| | constituent-level validity outcome -- see Section 4.2 |
| | -- and is not by itself a malformed NLRI. In per- |
| | flow steering mode, Weight is ignored entirely.) |
+----+--------------------------------------------------------------+
| 4 | A Per-Flow FC sub-TLV appears more than once within a |
| | single Constituent SR Policy sub-TLV. |
+----+--------------------------------------------------------------+
| 5 | A Per-Flow FC sub-TLV has a Length value other than |
| | 2. |
+----+--------------------------------------------------------------+
| 6 | Mixed encoding: some Constituent SR Policy sub-TLVs |
| | carry a Per-Flow FC sub-TLV and others do not. |
+----+--------------------------------------------------------------+
| 7 | A Constituent SR Policy sub-TLV carries a Color value |
| | equal to the parent SR Policy's Color in the NLRI. |
+----+--------------------------------------------------------------+
| 8 | A Constituent SR Policy sub-TLV carries a Length |
| | value less than 10. |
+----+--------------------------------------------------------------+
| 9 | A Constituent SR Policy sub-TLV carries a Color value |
| | of zero. |
+----+--------------------------------------------------------------+
| 10 | Two or more Constituent SR Policy sub-TLVs within the |
| | same SR Policy encoding carry identical Color values. |
+----+--------------------------------------------------------------+
| 11 | An SR Policy Tunnel Type encoding contains neither a |
| | Segment List sub-TLV nor any Constituent SR Policy |
| | sub-TLV (i.e., an empty Candidate Path with no |
| | forwarding contents). |
+----+--------------------------------------------------------------+
Table 2
Ramasamy, et al. Expires 30 November 2026 [Page 18]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
*Cycle detection.* Constituent SR Policies SHOULD reference non-
composite SR Policies (i.e., the active CP of each constituent SHOULD
itself be an explicit or dynamic CP, not a Composite CP). If
transitive composition is permitted by local policy, the SRPM MUST
bound recursion to a configurable maximum depth (default 2) and treat
references that exceed that depth, or that form a transitive
reference cycle, as *invalid at the constituent level*: the affected
constituent entry is marked invalid, the Composite CP remains valid
if at least one other constituent is valid, and standard treat-as-
withdraw does not apply. A directly self-referential Color (Color
equals the parent Color in the NLRI) is already a malformed NLRI per
Condition 7.
A Per-Flow FC sub-TLV is defined only inside a Constituent SR Policy
sub-TLV (Section 4.3). The nested type space (Section 11.2) is
independent of the top-level BGP Tunnel Encapsulation Attribute Sub-
TLVs registry; a top-level Type value is always interpreted per the
top-level registry, so an "FC sub-TLV at the top level" is not a
detectable error condition and is therefore not enumerated here.
8. Relationship to Other Documents
8.1. RFC 9256 -- SR Policy Architecture
RFC 9256 is the architectural authority. Sections 2.2 and 8.6 define
Composite CPs and per-flow steering respectively. This document
implements the BGP signaling plane for those constructs. One gap
remains in RFC 9256: the default action drop behavior is mentioned in
some implementations but not normatively defined in RFC 9256,
Section 8.6. The D flag in the Per-Flow FC sub-TLV (Section 4.3)
provides a forward-compatible extension point for this choice.
*SPRING WG coordination required.* The normative semantics of the
per-flow default-action -- and any future widening of the Forwarding
Class field beyond 3 bits -- are architectural decisions that belong
to the SPRING WG (responsible for RFC 9256). Adoption and
progression of this document by the IDR WG SHOULD include explicit
confirmation from the SPRING WG that (a) the 3-bit FC encoding
adopted here is compatible with the RFC 9256 architecture, and (b)
the D-flag semantics described in Section 4.3 are consistent with any
future SPRING work on the default-action choice.
Ramasamy, et al. Expires 30 November 2026 [Page 19]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
8.2. RFC 9830 -- Advertising SR Policies in BGP
RFC 9830 is the parent document extended here. All SAFI 73
operational procedures remain unchanged. This document does not
carry an Updates: RFC 9830 header because it adds new optional sub-
TLVs within the extensibility model that RFC 9830 already provides
and does not modify any existing RFC 9830 normative behavior.
*Note for Last Call review.* RFC 9830, Section 1 explicitly scopes
Composite Candidate Path signaling out of that document. A reviewer
may argue that bringing Composite CPs into scope warrants an Updates:
clause. The authors take the position that scope is set per-document
and does not constrain extensibility, and that adding new sub-TLVs
through RFC 9830's pre-existing extensibility model does not require
an Updates: header. The shepherd writeup should record this position
so the IESG/IDR review can resolve it explicitly rather than re-
litigating it on the list.
8.3. BGP-LS Northbound Collection
A companion BGP-LS mechanism is expected to extend RFC 9857 with TLVs
corresponding to the Constituent SR Policy and Per-Flow FC sub-TLVs
defined here, enabling northbound collection of Composite CP state
from headends to a controller. Implementations SHOULD support both
southbound signaling (this document) and northbound state collection
for full controller visibility.
8.4. PCEP Per-Flow Encoding
PCEP-based distribution of SR Policy Candidate Paths is defined in
[RFC9862]. Composite and per-flow extensions to PCEP are being
defined separately in the PCE Working Group
([I-D.ietf-pce-multipath]). The exact TLV names and object placement
in that draft should be cross-checked against its latest revision
before publication; this document does not normatively depend on
those names. The BGP encoding in this document and the PCEP encoding
are complementary; SRPM behavior on receipt is identical regardless
of the signaling protocol used.
8.5. YANG Data Model
The SPRING WG YANG data model for SR Policy
([I-D.ietf-spring-sr-policy-yang]) currently excludes Composite CP
modeling. A companion contribution to that draft is expected to add
a composite CP type container, a constituent-sr-policy list (color,
weight, fc-value, default-drop), and a per-flow-forwarding-class
leaf-list. For current observability, BGP-LS [RFC9857] collection of
Composite CP state (Section 8.3) is recommended.
Ramasamy, et al. Expires 30 November 2026 [Page 20]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
9. Operations
9.1. Distribution Ordering
BGP provides no atomicity guarantee across separate NLRI updates.
Controllers SHOULD distribute constituent (child) SR Policy CPs
before the parent Composite CP, as specified in Section 6.1.
Headends MUST tolerate transient inversions gracefully per
Section 6.2, applying IGP or drop fallback for unresolved
constituents until convergence completes.
9.2. Per-Peer State Limits
A controller advertising large numbers of Composite CPs referencing
nonexistent or invalid constituents will cause the SRPM to maintain
per-constituent invalid state and IGP-fallback entries.
Implementations SHOULD enforce configurable per-peer limits on the
number of Composite CP NLRIs and the number of Constituent SR Policy
sub-TLVs per CP. Note that per-flow steering naturally caps the per-
CP constituent count at 8 (one per FC value), but weighted load-
balancing mode does not impose a comparable cap and is therefore the
primary state-amplification surface. Exceeding configured limits
SHOULD be logged and MAY result in treat-as-withdraw of excess NLRIs
per RFC 7606. Operators SHOULD restrict SR Policy SAFI sessions to
trusted controllers to limit the blast radius of misconfiguration.
9.3. Convergence and Reconvergence
When a constituent SR Policy transitions from valid to invalid (e.g.,
due to a link failure or BFD session down), the SRPM updates the
affected FC entries per Section 6.2 without waiting for a BGP update.
The headend need not withdraw and re-advertise the parent Composite
CP; liveness is handled locally. When the constituent recovers, the
SRPM re-installs the original FC-to-color mapping.
9.4. Observability
For operational visibility into installed Composite CP state --
including constituent validity and FC-array contents -- operators are
RECOMMENDED to use the BGP-LS SR Policy distribution mechanism
[RFC9857] combined with a Composite CP companion as outlined in
Section 8.3. The SRPM SHOULD expose Composite CP state in the
operational data model (see Section 8.5 for YANG companion status).
Ramasamy, et al. Expires 30 November 2026 [Page 21]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
10. Security Considerations
The security considerations of BGP [RFC4271], BGP SR Policy
[RFC9830], and SR Policy Architecture [RFC9256] apply in full to this
document.
*Unauthorized policy injection.* As with all SR Policy BGP updates,
unauthorized injection of Composite CP advertisements could redirect
traffic across unintended paths. Mitigations: (a) BGP session
integrity via TCP-AO [RFC5925]; (b) Route Target communities to
restrict SR Policy SAFI propagation to intended headends; (c)
operational policies restricting SR Policy SAFI peering to trusted
controllers. Note that BGPsec [RFC8205] protects AS_PATH integrity
and does not protect the Tunnel Encapsulation Attribute carrying SR
Policy contents; RPKI/ROV [RFC6811] validates origin AS, not policy
contents. These tools are useful complements but not direct
mitigations for attribute-level injection.
*FC value manipulation.* An adversary able to inject or modify SR
Policy SAFI BGP updates could alter FC-to-color mappings, steering
specific traffic classes onto unintended paths. BGP session
integrity per TCP-AO [RFC5925] is the primary mitigation.
*Constituent reference amplification.* A malicious or misconfigured
controller can advertise large numbers of Composite CPs referencing
nonexistent constituents, causing SRPM state consumption and IGP-
fallback installation for each invalid constituent entry. Operators
MUST apply per-peer SR Policy SAFI session limits and per-peer CP
count limits as discussed in Section 9.2.
*Privacy.* SR Policy content reveals traffic engineering intent and
topology preferences. Composite CP advertisements expose QoS class
mappings (FC-to-color) and the SRv6 SID structure of constituent
paths. This content MUST NOT be distributed via untrusted BGP peers.
Route Target communities and peer access policies SHOULD be
configured to prevent leakage beyond intended headend sets.
TCP-AO [RFC5925] provides integrity and authentication for the BGP
session but does not provide confidentiality; an on-path observer can
still read SR Policy contents in transit. Where confidentiality of
TE intent is required, operators SHOULD additionally rely on
physical/link-layer protection of BGP-carrying links, or carry BGP
over an authenticated and encrypted transport (e.g., IPsec) between
trusted peers.
*No data-plane security changes.* This document does not alter SRv6
data-plane forwarding or SID processing. Data-plane security is
governed by [RFC8754] and [RFC8986].
Ramasamy, et al. Expires 30 November 2026 [Page 22]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
11. IANA Considerations
11.1. BGP Tunnel Encapsulation Attribute Sub-TLVs Registry
IANA is requested to allocate one value from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for the Constituent SR
Policy Sub-TLV defined in this document:
+=======+===============================+===============+
| Value | Description | Reference |
+=======+===============================+===============+
| TBA1 | Constituent SR Policy Sub-TLV | This document |
+-------+-------------------------------+---------------+
Table 3
Per the registration procedures of that registry (RFC 9012,
Section 13.1; Length-field width per RFC 9012, Section 2), the
registry is partitioned by Type value range, with each range carrying
both a Length-field width and a registration policy:
+=========+==============+=========================+
| Range | Length field | Registration policy |
+=========+==============+=========================+
| 1-63 | 1 octet | Standards Action |
+---------+--------------+-------------------------+
| 64-125 | 1 octet | First Come First Served |
+---------+--------------+-------------------------+
| 126-127 | 1 octet | Experimental Use |
+---------+--------------+-------------------------+
| 128-191 | 2 octets | Standards Action |
+---------+--------------+-------------------------+
| 192-252 | 2 octets | First Come First Served |
+---------+--------------+-------------------------+
| 253-254 | 2 octets | Experimental Use |
+---------+--------------+-------------------------+
| 0, 255 | -- | Reserved |
+---------+--------------+-------------------------+
Table 4
The Constituent SR Policy sub-TLV uses a 1-octet Length field
(Section 4.2). TBA1 MUST therefore be assigned from the range *1-63*
(Standards Action, 1-octet Length). The draft does not prescribe a
specific numeric value within that range.
Ramasamy, et al. Expires 30 November 2026 [Page 23]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
11.2. Constituent SR Policy Sub-TLV Types Registry
IANA is requested to create a new sub-registry titled *"Constituent
SR Policy Sub-TLV Types"* under the "Border Gateway Protocol (BGP)
Tunnel Encapsulation" registry group. Registration policies:
+=========+==================+
| Range | Policy |
+=========+==================+
| 0 | Reserved |
+---------+------------------+
| 1-127 | Standards Action |
+---------+------------------+
| 128-254 | Expert Review |
+---------+------------------+
| 255 | Reserved |
+---------+------------------+
Table 5
Initial assignments:
+===========================+=====================+===============+
| Value | Description | Reference |
+===========================+=====================+===============+
| 0 | Reserved | This document |
+---------------------------+---------------------+---------------+
| TBA2 | Per-Flow FC Sub-TLV | This document |
+---------------------------+---------------------+---------------+
| Remaining values in 1-127 | Unassigned | |
| | (Standards Action) | |
+---------------------------+---------------------+---------------+
| 128-254 | Unassigned (Expert | |
| | Review) | |
+---------------------------+---------------------+---------------+
| 255 | Reserved | This document |
+---------------------------+---------------------+---------------+
Table 6
TBA2 is to be assigned by IANA from the range 1-127 (Standards
Action) of this new sub-registry. All values in 1-127 other than
TBA2 remain unassigned and subject to Standards Action. The Expert
Review range (128-254) allows vendors to register experimental or
vendor-specific nested sub-TLVs without requiring a Standards Track
document, mirroring RFC 9012 practice.
12. Normative References
Ramasamy, et al. Expires 30 November 2026 [Page 24]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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>.
[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>.
[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>.
[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>.
[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>.
13. Informative References
[I-D.ietf-pce-multipath]
Koldychev, M., "PCEP Extensions for Signaling Multipath
Information", Work in Progress, Internet-Draft, draft-
Ramasamy, et al. Expires 30 November 2026 [Page 25]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
ietf-pce-multipath,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
multipath>.
[I-D.ietf-spring-sr-policy-yang]
SPRING Working Group, "YANG Data Model for Segment Routing
Policy", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-policy-yang,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang>.
[I-D.jiang-idr-sr-policy-composite-path]
Jiang, W., Lin, C., and R. Chen, "BGP Extensions of SR
Policy for Composite Candidate Path", Work in Progress,
Internet-Draft, draft-jiang-idr-sr-policy-composite-path,
<https://datatracker.ietf.org/doc/html/draft-jiang-idr-sr-
policy-composite-path>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007,
<https://www.rfc-editor.org/info/rfc4724>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
Ramasamy, et al. Expires 30 November 2026 [Page 26]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[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>.
[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>.
[RFC9494] Uttaro, J., Chen, E., Decraene, B., and J. Scudder, "Long-
Lived Graceful Restart for BGP", RFC 9494,
DOI 10.17487/RFC9494, November 2023,
<https://www.rfc-editor.org/info/rfc9494>.
[RFC9857] Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H.,
and J. Tantsura, "Advertisement of Segment Routing
Policies Using BGP - Link State", RFC 9857,
DOI 10.17487/RFC9857, October 2025,
<https://www.rfc-editor.org/info/rfc9857>.
[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>.
Authors' Addresses
Selvamani Ramasamy (editor)
Nexthop AI
United States of America
Email: selva@nexthop.ai
Manoharan Sundaramoorthy
Nexthop AI
India
Email: manoharan@nexthop.ai
Ramasamy, et al. Expires 30 November 2026 [Page 27]
Internet-Draft BGP Composite CP and Per-Flow FC May 2026
Shyam Sethuram
Nexthop AI
India
Email: shyam@nexthop.ai
Venkitraman Kasiviswanathan
Nexthop AI
United States of America
Email: venkit@nexthop.ai
Ramasamy, et al. Expires 30 November 2026 [Page 28]