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 . 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 ; 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: 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 , 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 tuple. The resulting Candidate Path is then offered to the SRPM along with locally configured and PCEP-signaled Candidate Paths for the same 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 . 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, . [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, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . [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, . [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, . 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, . [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, . [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, . [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, . [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, . [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, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [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, . 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, . [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, . [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, . [RFC9494] Uttaro, J., Chen, E., Decraene, B., and J. Scudder, "Long- Lived Graceful Restart for BGP", RFC 9494, DOI 10.17487/RFC9494, November 2023, . [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, . [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, . 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]