BGP-LS Extension for SR Policy Packet Spray State

Internet-Draft	BGP-LS SR Policy Spray Flag	August 2026
Liu	Expires 6 February 2027	[Page]

Abstract

This document proposes an extension to BGP-LS that allows a headend node, when reporting SR Policy state information via BGP-LS, to carry a new state flag at the candidate path level. This flag indicates whether the candidate path is currently being used for packet spraying. The information can be consumed by external controllers for path optimization, operations management or other purposes.¶

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."¶

This Internet-Draft will expire on 6 February 2027.¶

Copyright Notice

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

1. Introduction

Segment Routing (SR) architecture provides flexible traffic engineering forwarding mechanisms through SR Policy [RFC9256]. An SR Policy consists of one or more candidate paths, and each candidate path may contain one or more segment lists. As in [RFC9256], 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.¶

[RFC9857] 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 [RFC9857] 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.¶

3. 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.¶

3.1. 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.¶

3.2. 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.¶

Table 1: 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

5. Security Considerations

Procedures and protocol extensions defined in this document do not affect the security considerations discussed in [RFC9857].¶

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

6. References

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

6.2. Informative References

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