BGP Extensions for SRv6 Per-Flow Traffic Engineering: Composite Candidate Path and Forwarding-Class Signaling

Introduction Segment Routing (SR) allows a headend node to steer packet flows along any explicitly specified path. The headend instantiates an SR Policy 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.

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.

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

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 and is out of scope. This document covers similar ground to other individual Internet-Drafts addressing BGP distribution of Composite Candidate Paths (e.g., ). The authors encourage coordination and possible consolidation with such efforts during IDR WG discussion.

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

Terminology This document uses terms defined in and . Additional terms used are:

SR Policy:: Identified by <Headend, Color, Endpoint>; a source-routing policy defined by an ordered list of segments .
Candidate Path (CP):: The unit of signaling for an SR Policy. May be explicit, dynamic, or composite .
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 .
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 .
BFD:: Bidirectional Forwarding Detection .
DSCP:: Differentiated Services Code Point .
ENLP:: Explicit NULL Label Policy sub-TLV .
EVPN:: Ethernet Virtual Private Network .
IGP:: Interior Gateway Protocol.
PCE:: Path Computation Element.
PCEP:: Path Computation Element Communication Protocol.
QoS:: Quality of Service.
ROV:: Route Origin Validation .
SAFI:: Subsequent Address Family Identifier.
VPN:: Virtual Private Network.

Problem Statement

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.

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:

The controller computes constituent SR Policies (e.g., color 100 for high-priority traffic, color 200 for best-effort).
The controller computes the parent per-flow SR Policy (e.g., color 300) with the FC mapping.
The controller distributes constituent policies (colors 100 and 200) via RFC 9830. This works today.
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.

Interaction with the Color Extended Community The Color Extended Community 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.

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.

BGP SR Policy Encoding Extensions

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. 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 (, 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 . The composite encoding does not alter the preference-based ordering.

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: 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 (, 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 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 (, Condition 9) and MUST NOT equal the Color of the parent SR Policy in the NLRI (, Condition 7). All Constituent SR Policy sub-TLVs within a single SR Policy encoding MUST carry distinct Color values (, 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 . 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 (, 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 .
sub-TLVs:: Variable-length field containing zero or one Per-Flow FC sub-TLV () 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. 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 (, Condition 6).

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: 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: 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 ().
Length:: 1 octet. MUST be 2. A value other than 2 is a malformed condition (, Condition 5).
D (Default-Drop flag, bit 0):: When set to 1, if the constituent SR 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 (, Condition 2).

Nested-registry Length convention. All sub-TLVs registered in the "Constituent SR Policy Sub-TLV Types" registry () -- 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.

Encoding Example The following example encodes the parent per-flow SR Policy from (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 (). SR Policy SAFI NLRI: BGP Tunnel Encapsulation Attribute (Type 23, Tunnel Type 15): 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) ]]> 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 2001:db8:100::1	IGP (D=0)
2	SR Policy color 200 -- SID 2001:db8:200::1	IGP (D=0)
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)	--

Procedures

Origination An SR Policy Controller or BGP egress router originating a Composite or per-flow SR Policy CP MUST:

Set the SR Policy SAFI NLRI to represent the parent SR Policy (e.g., color 300, endpoint 2001:db8::1).
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.
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).
MUST NOT include a Segment List sub-TLV (Type 128) in the same encoding as any Constituent SR Policy sub-TLV.
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.
Distribute constituent (child) SR Policies before the parent Composite CP. While the SRPM tolerates transient inversion by treating unknown constituents as invalid (), controllers SHOULD sequence updates in child-then-parent order to minimize disruption during initial convergence.

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 ; the BGP best-path output is one input to that selection, not the final outcome. The SRPM SHALL:

Recognize the CP as a Composite CP type per RFC 9256, Section 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>.
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.
Install the FC-indexed steering array per semantics.
The SRPM SHOULD install the FC array atomically with respect to packet classification to avoid transient mis-steering during Composite CP changes.
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.

Route Reflector Transparency Route Reflectors (RRs) 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 , as applied by .

Graceful Restart During BGP Graceful Restart and Long-Lived Graceful Restart , 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.

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 (). 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 for companion YANG status) or BGP-LS state collection () may be used to confirm support; absent such telemetry, operators may rely on vendor release notes or controlled-rollout testing.

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.

Error Handling Error handling for BGP UPDATE messages follows the "treat-as-withdraw" strategy of and RFC 9830, Section 5. Each of the following conditions constitutes a malformed SR Policy NLRI; the treat-as-withdraw procedure MUST be applied:

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

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 (). The nested type space () 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.

Relationship to Other Documents

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 () 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 are consistent with any future SPRING work on the default-action choice.

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.

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.

PCEP Per-Flow Encoding PCEP-based distribution of SR Policy Candidate Paths is defined in . Composite and per-flow extensions to PCEP are being defined separately in the PCE Working Group (). 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.

YANG Data Model The SPRING WG YANG data model for SR Policy () 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 collection of Composite CP state () is recommended.

Operations

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 . Headends MUST tolerate transient inversions gracefully per , applying IGP or drop fallback for unresolved constituents until convergence completes.

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.

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

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 combined with a Composite CP companion as outlined in . The SRPM SHOULD expose Composite CP state in the operational data model (see for YANG companion status).

Security Considerations The security considerations of BGP , BGP SR Policy , and SR Policy Architecture 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 ; (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 protects AS_PATH integrity and does not protect the Tunnel Encapsulation Attribute carrying SR Policy contents; RPKI/ROV 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 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 . 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 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 and .

IANA Considerations

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

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

The Constituent SR Policy sub-TLV uses a 1-octet Length field (). 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.

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

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

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.