BGP-LS Extension for SR Policy Packet Spray State

Introduction Segment Routing (SR) architecture provides flexible traffic engineering forwarding mechanisms through SR Policy . An SR Policy consists of one or more candidate paths, and each candidate path may contain one or more segment lists. As in , only one candidate path is selected as the active path for each SR Policy, and traffic is load-balanced across the multiple segment lists of the active candidate path based on their respective weights. defines the mechanism for advertising SR Policies via BGP-LS, in which the SR Candidate Path State TLV is used to report the operational status and attributes at the candidate path level. Based on local policy, a headend node may decide to enable packet spraying across the multiple segment lists of an active candidate path. External controllers may need to be aware of this operational state for path optimization, troubleshooting or other purposes. This document extends the SR Candidate Path State TLV by allocating a new PS-Flag (Packet Spray Flag). This flag is used by the headend to report whether the candidate path is being used for packet spraying.

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.

BGP-LS Extensions This document allocates 1 bit from the reserved bits of the Flags field in the SR Candidate Path State TLV (Type 1202) as the PS-Flag (Packet Spray Flag).

When the PS-Flag is set to 1, it indicates that the candidate path is currently being used for packet spraying. The headend has decided, based on local policy, to perform packet spraying across the multiple segment lists of this candidate path.
When the PS-Flag is set to 0, it indicates that the candidate path is currently not being used for packet spraying, or the headend does not support this extension.

How the headend decides whether to enable packet spraying on a candidate path is out of the scope of this document.

Headend Advertisement Rules When advertising SR Policy state via BGP-LS, the headend node SHOULD set the PS-Flag according to the following rules:

Active candidate path only: The PS-Flag is meaningful only when the candidate path is currently the active candidate path (i.e., the A-Flag is set). For non-active candidate paths, the PS-Flag SHOULD be set to 0.
Multiple segment lists only: If the active candidate path contains only one segment list, packet spraying is not possible, and the PS-Flag SHOULD be set to 0.
If the active candidate path contains multiple segment lists and the headend has enabled packet spraying, the PS-Flag SHOULD be set to 1.

Receiver Processing Rules Upon receiving a BGP-LS UPDATE containing an SR Candidate Path State TLV, the receiver (e.g., a controller) SHOULD process the PS-Flag according to the following rules:

Validity check -- A-Flag: The receiver SHOULD first check the A-Flag of the candidate path. If the A-Flag is 0 (i.e., the candidate path is not active), the receiver SHOULD ignore the PS-Flag.
Validity check -- segment list count: If the number of segment lists is less than 2, the receiver SHOULD ignore the PS-Flag.
If the receiver finds that the PS-Flag is set to 1 but the candidate path's A-Flag is 0 or the segment list count is less than 2, the receiver MAY log the event for trouble shooting purpose.

If a headend's spraying state flaps frequently, the PS-Flag will cause corresponding BGP-LS updates to be generated. Implementations SHOULD apply update throttling or dampening mechanisms to avoid excessive BGP-LS update churn.

IANA Considerations This document requests a bit in the flag field of "SR Candidate Path State TLV" under the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. New Flag Allocation for SR Candidate Path State TLV

Bit	Description	Reference
TBA	PS-Flag: The CP is being used for packet spraying	This document

Security Considerations Procedures and protocol extensions defined in this document do not affect the security considerations discussed in . The setting of the PS-Flag may indirectly expose the headend node's local policy information (e.g., whether spraying is enabled). Operators SHOULD assess the risk of such information disclosure according to their own security policies and use appropriate measures to protect such information.