Signaling Composite Candidate Path of SR Policy using BGP-LS
Hao Li
New H3C Technologies
lihao@h3c.com
Mengxiao Chen
New H3C Technologies
chen.mengxiao@h3c.com
Changwang Lin
New H3C Technologies
linchangwang.04414@h3c.com
Wenying Jiang
China Mobile
jiangwenying@chinamobile.com
Weiqiang Cheng
China Mobile
chengweiqiang@chinamobile.com
30 August 2022
General
Network Working Group
Segment Routing
SR Policy
BGP-LS
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy.

Introduction
As described in [RFC7752], BGP Link State (BGP-LS) provides a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol.
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in [RFC9256].
An SR Policy is associated with one or more candidate paths. A composite candidate path acts as a container for grouping of SR Policies. As described in section 2.2 in [RFC9256], the composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for a load-balanced steering of packet flows over its constituent SR Policies.
[I-D.draft-jiang-spring-parent-sr-policy-use-cases] describes some use cases for SR policy group composite candidate path.
[I-D.ietf-idr-te-lsp-distribution] describes a mechanism to collect the SR policy information that is locally available in a node and advertise it into BGP-LS updates. This document extends it to provide some extra information to carry composite candidate path information in the BGP-LS advertisement.

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

BGP-LS Extensions for Composite Candidate Path
[RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a Node Attribute, a Link Attribute or a Prefix Attribute. [I-D.ietf-idr-te-lsp-distribution] describes a mechanism to collect the SR Policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. This section defines a new sub-TLV which is carried in the optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in [RFC7752].

Constituent SR Policy 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 Constituent SR Policy TLV is used to report the constituent SR policy(s) of a composite candidate path. 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: no sub-TLV is currently defined.

Operations
The document does not bring new operation beyond the description of operations defined in [RFC7752] and [I-D.ietf-idr-te-lsp-distribution]. The existing operations defined in [RFC7752] and [I-D.ietf-idr-te-lsp-distribution] can apply to this document directly.
Typically but not limit to, the BGP-LS messages carring composite candidate path information along with the SR policy are distributed to a controller.
After configuration, the composite candidate path information will be advertised by BGP update messages. The operation of advertisement is the same as defined in [RFC7752] and [I-D.ietf-idr-te-lsp-distribution], as well as the receiption.

Security Considerations
Procedures and protocol extensions defined in this document do not affect the security considerations discussed in [I-D.ietf-idr-te-lsp-distribution].

IANA Considerations
This document defines a new TLV in the BGP-LS Link Descriptor and Attribute TLVs:
Value | Description | Reference
TBA | Constituent SR Policy TLV | This document

Normative References
[I-D.ietf-idr-te-lsp-distribution]

Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
Stefano Previdi
Ketan Talaulikar
Jie Dong
Mach Chen
Hannes Gredler
Jeff Tantsura
22 August 2022
Internet-Draft draft-ietf-idr-te-lsp-distribution-18
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8402]

Segment Routing Architecture
C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir
July 2018
RFC 8402
DOI 10.17487/RFC8402

Informative References
[RFC9256]

Segment Routing Policy Architecture
Clarence Filsfils
Ketan Talaulikar
Daniel Voyer
Alex Bogdanov
Paul Mattes
July 2022
RFC 9256
DOI 10.17487/RFC9256
[RFC7752]

North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
H. Gredler, Ed.
J. Medved
S. Previdi
A. Farrel
S. Ray
March 2016
RFC 7752
DOI 10.17487/RFC7752
[I-D.draft-jiang-spring-parent-sr-policy-use-cases]

Use Cases for Parent SR Policy
Wenying Jiang
Weiqiang Cheng
Changwang Lin
Yuanxiang Qiu
7 March 2022
Internet-Draft draft-jiang-spring-parent-sr-policy-use-cases-00