Supplement of BGP-LS Distribution for SR Policies and State

Introduction SR Policy architecture details are specified in . An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active. Each CP in turn may have one or more SID-List of which one or more may be active; when multiple are active then traffic is load balanced over them. 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. Various TLVs are defined to enable the headend to report the state at the candidate path level and the segment list level. Currently, the following segment-list-related information is not yet included in :

Whether the segment list is in administrative shut state. For the candidate path, there's already an S-Flag in the SR Candidate Path State TLV in indicating the CP is in an administrative shut state. In some usecases, the segment list may also be shut by an administrator for traffic engineering or power saving purpose, e.g, the network administrator may shut certain segment list when the load on the SR Policy is light. This information may also be needed and reported via BGP-LS.
The 32-bit MPLS LSE information, especially, the MPLS Network Actions (MNA) sub-stack. Traditional MPLS LSE consists of 20-bit MPLS label, 3-bit TC, 1-bit S(bottom of stack indication) and 8-bit TTL. Accordingly, SR Segment List TLV only supports carrying MPLS labels with the TC, S and TTL fields set to 0 in SR Segment Sub-TLV. However, defines the MPLS Network Actions sub-stack (NAS) solution for carrying Network Actions and Ancillary Data in the MPLS label stack, unlike traditional MPLS LSE, some LSEs defined for MNA repurposed the TC and TTL field to carry additional information. MNA such as Network Resource Partition (NRP) , IOAM may be inserted in the SID list in the format of LSEs. The contents of the LSEs inserted in the SID-lists may be required by the controller when the headend reports the state of SR Policies via BGP-LS.

This document supplements some additional information of the segment list state as mentioned above in the BGP-LS advertisement for SR Policy state information.

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

BGP-LS Extensions for Distributing Segment List States

New Flag in SR Segment List TLV SR Segment List TLV is defined in to report the SID-List(s) of a candidate path. As show in Figure 1,this document introduces a new flag in the flag field of SR Segment List TLV, where,

New Flags in the Flag Field of SR Segment List TLV

S-Flag: Indicates the segment list is in administrative shut state when set. The segment list may be shut by the administrator via CLI or other methods, and it is out of the scope of this document.

MNA Sub-Stack Sub-TLV The MNA Sub-Stack Sub-TLV is defined in this section to carry the MNA Sub-Stack information.

MNA Sub-Stack Sub-TLV

Type: TBA
Length: Variable, the total length (in octets) of MNA Sub-Stack portion in octets, MUST be the multiple of 4. The value indicates the number of the LSEs in this sub-TLV.
MNA Sub-Stack: one or more 4-octet-field carrying the MNA Sub-Stack defined in

The MNA Sub-Stack is an optional sub-TLV of SR Segment List TLV, and can appear more than once in the SR Segment List TLV. It may be used as the sub-TLV of other TLVs, for the latter case, the detailed usage is out of the scope of this document.

IANA Considerations This document requests bit 9 in the flag field of "SR Segment List TLV" under the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This document requests a new type sub-TLV of "SR Segment List TLV" under the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry.

Manageability Considerations The considerations as specified in apply to this document. In general, unknown and unsupported types MUST be preserved and propagated within both the NLRI and the BGP-LS Attribute. The presence of unknown or unexpected TLVs MUST NOT result in the NLRI or the BGP-LS Attribute being considered malformed. If the receiver doesn't recognize the new sub-TLV type defined in this document, it SHOULD skip it and process the remaining part in the SR Segment List TLV normally.

Security Considerations Procedures and protocol extensions defined in this document do not affect the security considerations discussed in .