Signaling Composite Candidate Path of SR Policy using BGP-LS

3.1. Composite Candidate Path TLV

Segment Routing Policy (SR Policy) architecture is specified in [RFC9256]. A SR Policy can comprise of one or more candidate paths, and each candidate path is either dynamic, explicit or composite. A composite candidate path can comprise of one or more constituent SR policies. The endpoints of the constituent SR Policies and the parent SR Policy MUST be identical, and the colors of each of the constituent SR Policies and the parent SR Policy MUST be different.¶

The Composite Candidate Path TLV is used to report the constituent SR policy(s) of a composite candidate path. It is carried in the optional non-transitive BGP- LS Attribute defined in [RFC9552] and is associated with the SR Policy Candidate Path NLRI type. Only a single instance of this TLV is advertised for a given candidate path. If multiple instances are present, then the first valid (i.e., not determined to be malformed as per section 8.2.2 of [RFC9552]) one is used and the rest are ignored.The TLV has following 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)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

• Type: to be assigned by IANA.¶

• Length: the total length of the value field not including Type and Length fields.¶

• Reserved: 32 bits reserved and MUST be set to 0 on transmission and MUST be ignored on receipt.¶

• Color: 4 octets that indicates the color of the constituent SR Policy.¶

• Weight: 4 octet field that indicates the weight associated with the SID-List for weighted load-balancing. Refer Section 2.2 and 2.11 of [RFC9256].¶

• Sub-TLVs: variable and contains any other optional attributes associated with the Composite Candidate Path. Currently, the sub-TLV only defines the Per-Flow Forwarding Class TLV.¶

3.2. Per-Flow Forwarding Class TLV

Per-Flow Candidate Path builds on top of the concept of the Composite Candidate Path. Each Path in a Per-Flow Candidate Path is assigned a 3-bit forward class value, which allows Quality of Service (QoS) classified traffic to be steered depending on the forward class. The Per-Flow Forwarding Class TLV is an optional sub-TLV of the Composite Candidate Path TLV.Only a single instance of this sub-TLV is advertised for a given candidate path. If multiple instances are present, then the first valid (i.e., not determined to be malformed as per section 8.2.2 of [RFC9552]) one is used and the rest are ignored.¶

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                       | FC  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

• Type (16 bits): TBD1 for "PER-FLOW-FORWARD-CLASS" TLV.¶

• Length (16 bits): 4.¶

• Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt.¶

• FC (3 bits): Forward class value that is given by the QoS classifier to traffic entering the given Candidate Path. Different classes of traffic that enter the given Candidate Path can be differentially steered into different Colors.¶

7.1. Normative References

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

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

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

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

7.2. Informative References

[I-D.ietf-pce-multipath]

Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., Bidgoli, H., Yadav, B., Peng, S., Mishra, G. S., and S. Sidor, "Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information", Work in Progress, Internet-Draft, draft-ietf-pce-multipath-16, 17 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-16>.

[I-D.jiang-idr-sr-policy-composite-path]

Wenying, J., 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-03, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-jiang-idr-sr-policy-composite-path-03>.

[RFC9552]

Talaulikar, K., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, January 2024, <https://www.rfc-editor.org/info/rfc9552>.