BGP-LS Extension for SR Policy Packet Spray State
draft-liu-idr-bgp-ls-sr-policy-spray-state-00

IDR                                                               Y. Liu
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                           5 August 2026
Expires: 6 February 2027

           BGP-LS Extension for SR Policy Packet Spray State
             draft-liu-idr-bgp-ls-sr-policy-spray-state-00

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

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  BGP-LS Extensions . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Headend Advertisement Rules . . . . . . . . . . . . . . .   3
     3.2.  Receiver Processing Rules . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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.

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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

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.

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

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

4.  IANA Considerations

   This document requests a bit in the flag field of "SR Candidate Path
   State TLV" [RFC9857] under the "BGP-LS Node Descriptor, Link
   Descriptor, Prefix Descriptor, and Attribute TLVs" registry.

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

                   Table 1: New Flag Allocation for SR
                         Candidate Path State TLV

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

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

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

Author's Address

   Yao Liu
   ZTE Corporation
   Email: liu.yao71@zte.com.cn

Liu                      Expires 6 February 2027                [Page 5]