SPRING Working Group                                             Y. Liu
Internet Draft                                             China Mobile
Intended status: Standards Track                                 C. Lin
Expires: 15 June 2026                              New H3C Technologies
                                                                S. Peng
                                                    Huawei Technologies
                                                                R. Chen
                                                        ZTE Corporation
                                                                 Z. Ali
                                                    Cisco Systems, Inc.
                                                              G. Mishra
                                                           Verizon Inc.
                                                                 Y. Qiu
                                                   New H3C Technologies
                                                       15 December 2025


              Flexible Candidate Path Selection of SR Policy
           draft-liu-spring-sr-policy-flexible-path-selection-12


Abstract

   This document describes a flexible method for selecting candidate
   Segment Routing (SR) policy paths. Based on the real-time resource
   usage and forwarding quality of candidate paths, the head node can
   perform dynamic path switching between multiple candidate paths in
   the SR policy.

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 11 June 2026.

Copyright Notice

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

Liu, et al.               Expires June 2026                   [Page 1]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   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.

Table of Contents


   1. Introduction.....................................................2
   2. Terminology......................................................4
   3. Background Requirements..........................................4
   4. Flexible Candidate Path Selection Method.........................5
      4.1. Threshold Parameters of Candidate Paths.....................6
      4.2. Updated SR Policy Information Model.........................8
      4.3. Rules for Setting the Eligibility Attribute.................9
      4.4. Performance Measurement for SR Policy Forwarding Quality....9
      4.5. Flexible Candidate Path Selection Process..................11
      4.6. Delayed Recovery Switch for Candidate Path.................12
   5. Use Cases of Flexible Candidate Path Selection..................12
      5.1. Select the Best Path Based on End-to-End Delay.............13
      5.2. Select the Best Path Based on Available Bandwidth..........13
      5.3. Select the Best Path Based on Actual Bandwidth.............14
   6. IANA Considerations.............................................15
   7. Security Considerations.........................................15
   8. References......................................................15
      8.1. Normative References.......................................15
      8.2. Informative References.....................................16
   9. Acknowledgments.................................................18
   Authors' Addresses.................................................18

1. Introduction

   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 may have multiple candidate paths that are provisioned
   or signaled [RFC9830] [RFC8664] from one of more sources. The tie-
   breaking rules defined in [RFC9256] result in determination of a
   single "active path" in a formal definition.

   According to [RFC9256] the head node must use only the active
   candidate path for forwarding traffic that is being steered onto a
   specific policy, except for certain scenarios such as fast reroute
   where a backup candidate path may be used. A candidate path can be
Liu, et al.               Expires June 2026                   [Page 2]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   represented as a segment list or a set of segment lists. If a set of
   segment lists is associated with the active path of a policy, then
   the steering of traffic onto the different segment lists is per flow
   and is based on weighted-ECMP (W-ECMP) according to the relative
   weight of each segment list.

   According to the criteria for the validity of candidate paths
   described in Section 5 of [RFC9256], if there is a valid segment
   list in the active candidate path, the active candidate path is
   valid. When some segment lists of the active candidate path are not
   valid, the active candidate path may still be valid, but it might
   not continue to meet the actual forwarding requirements.

   [I-D.karboubi-spring-sr-policy-eligibility] introduces the concept
   of an eligibility attribute at the candidate path level, not only at
   the time of the path computation, but also through topology and
   network changes to ensure that user intentions are preserved while
   carrying service traffic.

   This document introduces the concept of eligibility refer to [I-
   D.karboubi-spring-sr-policy-eligibility] and specifies a
   comprehensive quality-driven candidate path switching mechanism. It
   primarily focuses on defining the precise conditions, operational
   rules, and dynamic procedures required for performance-driven
   management. The framework enables autonomous system behavior based
   on real-time quality assessments, ensuring reliable and adaptive
   network operations in response to fluctuating performance
   conditions.

   Based on real-time resource usage and the forwarding quality of
   candidate paths, the head node can dynamically adjust
   the eligibility attribute value, enabling it to dynamically switch
   traffic onto different paths among multiple candidate paths within
   the SR policy.

   [RFC2386] provides valuable background on QoS-based routing, details
   some issues and requirements associated with QoS-based routing, and
   describes a framework for employing QoS-based routing within the
   Internet. This document describes an SR Policy mechanism where the
   traffic is switched between paths based on the resource status of
   the traversed path. However, it does not address the challenges
   related to dynamic distributed scheduling or resource reservation
   along intermediate paths. The document specifies the capability to
   switch to alternative paths within a strategy when the current path
   fails to satisfy designated link quality criteria, such as
   bandwidth, delay, or packet loss. In instances where a controller
   issues an SR Policy encompassing multiple paths, should a path's
   link quality not meet the established requirements, a switch to a
   backup path for forwarding is executed.


Liu, et al.               Expires June 2026                   [Page 3]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


2. Terminology

   The definitions of the basic terms are identical to those found in
   Segment Routing Policy Architecture [RFC9256].

3. Background Requirements

   When some segment lists of the active candidate path are not valid,
   according to [RFC9256], if there is a valid segment list in the
   active candidate path, the active candidate path is still valid. But
   the paths of remaining segment lists may not meet the SR policy
   forwarding performance requirements, such as insufficient path
   bandwidth. Even if there are other candidate paths with lower
   preference that can meet the forwarding performance requirements in
   the SR policy, the traffic will continue to be forwarded via the
   original active candidate path.

   As an example, consider the following SR Policy to illustrate the
   issues present in the current candidate path selection process in
   detail.

      SR Policy POL1
         Candidate Path CP1
            Preference 200
            Segment List 1 <SID11...SID1i>, Weight 1
            Segment List 2 <SID21...SID2j>, Weight 1
            Segment List 3 <SID31...SID3k>, Weight 1
         Candidate Path CP2
          Preference 100
            Segment List 4 <SID41...SID4i>, Weight 1
            Segment List 5 <SID51...SID5j>, Weight 1
            Segment List 6 <SID61...SID6k>, Weight 1

   There are two static candidate paths CP1 and CP2 in SR policy POL1.
   CP1 has a higher preference. Both candidate paths are composed of
   three static segment lists with the same weight. The path indicated
   by each segment list can carry traffic of 100Mbps bandwidth. When
   all Segment Lists in CP1 are valid, the effective bandwidth of the
   candidate path is 300Mbps.

   Suppose the bandwidth of the actual traffic forwarded by the SR
   policy is between 100Mbps and 150Mbps. Because the traffic forwarded
   on the candidate path will share the load on the three segment list
   paths according to the weight value, the candidate path can meet the
   forwarding requirements. The traffic is forwarded on the three
   segment lists of the higher preference candidate paths of the SR
   policy.

   When segment lists 1 and 2 in the high-preference candidate path CP1
   are not valid, according to the candidate path validity criteria
   described in [RFC9256] Section 5, because segment list 3 in CP1 is
Liu, et al.               Expires June 2026                   [Page 4]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   still valid, the active candidate path CP1 is still valid. All
   traffic of SR policy POL1 will continue to be forwarded through the
   path of CP1. However, because segment list 3 can only forward
   100Mbps traffic, over-bandwidth traffic will be discarded.

   Of course, when the Segment List path fault is detected, the network
   device can report the detected fault information to the controller.
   The controller optimizes the forwarding path after receiving the
   message. However, this interaction process is relatively long, and
   it is difficult to meet the requirement for fast switch-over.

   The same need arises when the quality of the high-preference
   candidate paths deteriorates, due to issues such as insufficient
   available bandwidth, increased end-to-end transmission delay, or
   segment lists failing to meet service requirements. The goal is to
   switch traffic to other lower preference candidate paths within the
   SR policy that better satisfy the forwarding quality requirements.

   To address this issue, this document proposes a new candidate path
   selection rule that defines resource thresholds and forwarding
   quality requirements for candidate paths.

   If a candidate path does not satisfy the forwarding quality
   requirements, its eligibility attribute MUST be set to false. During
   the active candidate path(CP) selection process, the head node SHALL
   use this eligibility attribute as an additional mandatory criterion,
   in conjunction with the rules defined in [RFC9256], Section 2.9.
   When a CP's eligibility attribute is false, it indicates that the
   path cannot forward traffic meeting the specified quality
   requirements and therefore MUST NOT be considered for active CP
   selection.

4. Flexible Candidate Path Selection Method

   As described in [RFC9256], the candidate path selection process
   operates primarily on the candidate path Preference. A candidate
   path is selected when it is valid and it has the highest Preference
   value among all the valid candidate paths of the SR Policy.

   [I-D.karboubi-spring-sr-policy-eligibility] introduces a new
   attribute at the candidate path level called Eligibility. Only
   candidate paths with Eligibility as true are considered as part of
   the active candidate path selection defined in [RFC9256].

   This document describes using forwarding quality
   requirements and resource requirements of candidate paths
   as eligibility criteria for path selection.

   A head node may be informed about the forwarding quality
   requirements of a candidate path for an SR Policy <Color, Endpoint>
   through various means, including configuration, PCEP, or BGP. The
Liu, et al.               Expires June 2026                   [Page 5]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   extensions of BGP and PCEP are described in [I-D.liu-idr-bgp-sr-
   policy-cp-threshold] and [I-D.liu-pce-sr-policy-cp-threshold].

   When a candidate path fails to meet forwarding quality requirements,
   its Eligibility attribute SHOULD be set to false, thereby excluding
   it from active candidate path selection.

   For candidate paths containing multiple segment lists:

   - If a segment list fails to meet forwarding quality requirements,
      it SHOULD be excluded from forwarding operations.

   - When all segment lists under a candidate path fail to meet
      forwarding quality requirements, the path's Eligibility attribute
      SHOULD be set to false, disqualifying it from active candidate
      path selection.

4.1. Threshold Parameters of Candidate Paths

   The threshold parameters of candidate paths can include, but are not
   limited to, the following:

   *  Jitter

   *  Latency

   *  Packet loss

      When the jitter, delay, or packet loss of a valid segment list
      does not meet the specified threshold requirements, the segment
      list SHALL be considered invalid and will no longer participate in
      load sharing traffic.

   *  Available bandwidth

      CP available bandwidth = CP preset bandwidth * (Sum of weights of
      Segment Lists in Up state / Sum of all Segment List weights)

   *  Actual bandwidth

      The actual bandwidth refers to the sum of the actual available
      remaining bandwidth of each valid segment list in the candidate
      path.

      Due to the different congestion conditions of each node on the
      forwarding path, the actual bandwidth that can forward service
      packets may differ from the preset bandwidth. Using appropriate
      measurement methods, the actual minimum available bandwidth and
      actual minimum remaining bandwidth along the path can be
      determined. The specific measurement mechanism is out of the scope
      of this document.
Liu, et al.               Expires June 2026                   [Page 6]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   *  Precision Availability Metrics (PAM)

      Consider a candidate path of SR policy as a Service Level
      Objective (SLO) [RFC9543], based on the Precision Availability
      Metrics (PAM) defined in [RFC9544], determine whether the
      candidate path meets the forwarding requirements.

   If one or more segment lists in the candidate path fail to meet the
   thresholds, this indicates that these segment lists cannot provide
   forwarding capabilities that meet the Service Level Agreement
   (SLA)requirements. These segment lists will be marked as unavailable
   and will no longer participate in packet forwarding. After excluding
   these segment lists, the candidate path should be re-verified to
   determine whether it still meets the forwarding quality
   requirements. If it does, traffic can continue to be forwarded along
   that candidate path.

   For example, two threshold parameters, delay and available
   bandwidth, are specified for the candidate path with multiple
   segment lists. When the delay of a segment list exceeds the
   threshold, the following processing is performed:

   1) Remove the segment list from the forwarding path.

   2) Calculate the current available bandwidth of the CP based on the
      weight ratio of the remaining effective segment lists and the
      bandwidth of the CP.

   3) Check whether the current available bandwidth of the CP still
      meets the bandwidth threshold requirements.

      *  If the available bandwidth still meets the requirements, the
         candidate path still meets the forwarding quality

         requirements, and the traffic is still forwarded along this
         candidate path.

      *  Otherwise, set the Eligibility attribute of this CP to false.
         The system will then consider switching service traffic to
         another active candidate path with better forwarding quality.

   If the candidate path does not specify any threshold parameters,
   select the primary candidate path according to the selection method
   defined in [RFC9256].

   By default, there is no threshold parameter specified on the
   candidate path.



Liu, et al.               Expires June 2026                   [Page 7]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


4.2. Updated SR Policy Information Model

   This document defines a quality-driven information model for Segment
   Routing (SR) Policy. Specifically, it introduces threshold-based
   performance parameters for forwarding quality under each Candidate
   Path. When a Candidate Path fails to meet the specified quality
   thresholds, its Eligibility attribute SHOULD be set to false,
   thereby excluding it from being selected as the active path.

   In summary, the information model enables dynamic and performance-
   aware SR Policy enforcement, ensuring that only qualified paths are
   used based on real-time forwarding quality.

   SR Policy POL1: <Headend = H1, Color = 1, Endpoint = E1>
         Candidate Path CP1 <Protocol-Origin, Originator,Discriminator>
                 Binding SID
                 Preference
                 Priority
                 Threshold parameters of forwarding quality
                      Jitter 1
                      Latency 1
                      Available Bandwidth 1
                      Actual Bandwidth 1
                 Segment List 1
                      Weight W1
                      Segments <SID11...SID1i>
                 Segment List 2
                      Weight W2
                      Segments <SID21...SID2i>
         Candidate Path CP2 <Protocol-Origin, Originator,Discriminator>
                 Binding SID
                 Preference
                 Priority
                 Threshold parameters of forwarding quality
                      Jitter 2
                      Latency 2
                      Available Bandwidth 2
                      Actual Bandwidth 2
                 Segment List 3
                      Weight W3
                      Segments <SID31...SID3i>
                 Segment List 4
                      Weight W4
                      Segments <SID41...SID4i>
                 ...
     Figure 1: Information Model of SR Policy with forwarding quality
Liu, et al.               Expires June 2026                   [Page 8]

Internet-Draft    SR Policy Flexible Path Selection       December 2025




4.3. Rules for Setting the Eligibility Attribute

   When a candidate path's current forwarding quality meets the
   specified threshold requirements, its Eligibility attribute MUST be
   set to true, indicating this path is valid for:

      *  Traffic forwarding operations.

      *  Active candidate path selection (per [RFC9256] selection
         methodology)

   Conversely, when a candidate path fails to meet quality
   requirements, its eligibility attribute MUST be set to false.

   For candidate paths containing multiple segment lists:

   - If a segment list fails to meet forwarding quality requirements,
      it SHOULD be excluded from forwarding operations.

   - When all segment lists under a candidate path fail to meet
      forwarding quality requirements, the path's Eligibility attribute
      SHOULD be set to false, disqualifying it from active candidate
      path selection.

   For candidate paths without defined threshold parameters:

      *  The eligibility attribute MUST default to true.

      *  Primary path selection follows [RFC9256] procedures.

   When multiple eligible candidate paths coexist in an SR policy:

      *  Paths with Eligibility=false MUST NIOT participate in active

         path selection.

      *  Detailed behavior is specified in

         [I-D.karboubi-spring-sr-policy-eligibility].

4.4. Performance Measurement for SR Policy Forwarding Quality

   A comprehensive SR Performance Measurement toolset is an essential
   requirement for measuring network performance to provide Service
   Level Agreements (SLAs). The following lists several measurement
   methods for reference; detailed measurement methods are beyond the
   scope of this document.

   *  jitter, delay, or packet loss
Liu, et al.               Expires June 2026                   [Page 9]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   To measure performance metrics such as jitter, latency, and packet
   loss for an SR policy candidate path, the Simple Two-Way Active
   Measurement Protocol (STAMP) can be used. [I-D.ietf-spring-stamp-
   srpm] outlines the performance measurement procedures in Segment
   Routing networks based on STAMP as defined in [RFC8762], with
   optional extensions from [RFC8972] and [RFC9503]. In particular,
   [RFC9503] defines an extended TLV capability capable of carrying SR
   path information to ensure that both the forward and return
   detection packets follow the same SR path during measurement. To
   achieve path symmetry, a return-path SID identifying the specific
   path segment may be included within Sub-TLVs. This allows the
   reflector to utilize the return-path SID for constructing the SID
   list of the return detection packet. Specifically, [RFC9503]
   specifies that the Return Path SRv6 Segment List Sub-TLV may include
   an identifier for the return path segment list of an SRv6 Path
   Segment.

   *  Available bandwidth

   The Available Bandwidth of a Candidate Path refers to the bandwidth
   allocated to the Candidate Path during SR Policy path computation
   based on user requirements. The Segment List weight ratio represents
   the load sharing proportion of each Segment List under the Candidate
   Path. The product of the Candidate Path bandwidth and the effective
   Segment List weight indicates the Available Bandwidth that the
   Candidate Path can currently carry relative to the user's bandwidth
   requirements.

   Candidate Path Available Bandwidth = Candidate Path Bandwidth * (Sum
   of UP Segment List Weights / Total Segment List Weights).

   If the Available Bandwidth of the currently active Candidate Path
   cannot meet the requirements, the SR Policy can switchover to a
   backup Candidate Path that satisfies the bandwidth requirements.

   *  Actual bandwidth

   By employing appropriate measurement methods, the actual minimum
   available bandwidth and the actual minimum remaining bandwidth of
   all nodes along the path can be determined. The ingress node sends
   STAMP detection packets with a DOH header appended outside the SRH
   to record the path's minimum bandwidth. At each hop, the real-time
   bandwidth of the egress interface is compared with the minimum value
   currently recorded in the DOH header. If the interface bandwidth is
   higher, the DOH field remains unchanged; if it is lower, the DOH
   field is updated accordingly. Finally, the egress node extracts the
   final minimum bandwidth from the DOH header and reports it back to
   the ingress node via an extended TLV carried in the STAMP reply
   packet. It should be emphasized that the specific measurement
   mechanism itself is out the scope of this document.

Liu, et al.               Expires June 2026                  [Page 10]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


4.5. Flexible Candidate Path Selection Process

   The process of selecting the best candidate path for SR policy
   through the threshold parameter of the candidate path is as follows.

   1) Configure the threshold parameters on the candidate path of the
      head node through manual configuration or controller
      distribution.

   2) The head node monitors whether the available resources and
      forwarding quality of an SR policy candidate path meet the
      specified thresholds. The forwarding quality of the path can be
      obtained through active or passive performance measurement
      methods, and the relevant considerations are described in Section
      4.4, such as In-situ OAM [RFC9378], STAMP [I-D.ietf-spring-stamp-
      srpm] and TWAMP [RFC5375], etc. Real-time quality data may be
      calculated by a controller and distributed to the head node, or
      computed locally by the head node based on collected network
      measurement data. The selection of measurement methods and the
      detailed mechanisms for quality data acquisition are out of the
      scope of this document.

   3) According to the rules described in Section 4.3, if the available
      resources of the active candidate path fall below the required
      threshold, or if its forwarding quality fails to meet the
      specified performance threshold, the head node shall select a new
      active candidate path. For a candidate path consisting of
      multiple segment lists, if one or more segment lists do not
      satisfy the forwarding quality requirements, only the eligibility
      attribute of those particular segment lists SHOULD be set to
      false. If the remaining segment lists still meet the forwarding
      quality requirements, traffic for this candidate path shall be
      redistributed accordingly through load balancing among them.
      However, if all segment lists of a candidate path fail to satisfy
      the forwarding quality requirements, the eligibility attribute of
      the entire candidate path MUST be set to false, thereby excluding
      it from selection as the active candidate path.

   4) After the fault on the old active candidate path is repaired or
      the forwarding quality improves, whether to revert to the
      previous active candidate path can be specified by the
      configuration. If fault recovery is required, start a wait timer
      for delayed recovery. When the timer expires and if the old
      active candidate path still meets the threshold requirements, the
      traffic will be switched back to the old higher preference
      candidate path.





Liu, et al.               Expires June 2026                  [Page 11]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


4.6. Delayed Recovery Switch for Candidate Path

   To avoid frequent path switching (flapping), both over-threshold
   switching and fault recovery should be delayed. The delay interval
   can be adjusted through configuration.

   When the quality of service (QoS) of a candidate-path degrades and
   fails to meet the threshold requirement, the eligibility attribute
   of the candidate-path will be set to false and it will not carry
   traffic.

   When the QoS of a candidate-path recovers and meets the threshold
   requirement, it will wait for the Wait-to-Restore (WTR) period. If
   the QoS does not degrade during this time, the candidate-path will
   resume carrying traffic. Otherwise, its eligibility attribute will
   be set to false again.

   Taking the WTR of 30 seconds as an example, the explanation is as
   follows:

   0(x) 10(WTR)  35(x) 40(WTR) 70(Recovery) 90(x) 95(WTR)125(Recovery)

   |     |        |    |           |          |     |          |
   --------------------------------------------------------------------
   
   At 0s:   the candidate-path degraded and its eligibility attribute
   was set to false;
   At 10s:  the candidate-path recovered, and the WTR timer was
   started, waiting for 30 seconds;
   At 35s:  the candidate-path degraded again, and the waiting timer
   was canceled;
   At 40s:  the candidate-path recovered, and the WTR waiting timer was
   started, waiting for 30 seconds;
   At 70s:  during the wait-to-restore period, the candidate-path did
   not degrade, thus the WTR wait ended and its eligibility attribute
   was restored to ture;
   At 90s:  the candidate-path degraded again and its eligibility
   attribute was set to false;
   At 95s:  the candidate-path recovered, and the WTR waiting timer was
   started, waiting for 30 seconds;
   At 125s: during the wait-to-restore period, the candidate-path did
   not degrade, thus the WTR wait ended and its eligibility attribute
   was restored to true.

5. Use Cases of Flexible Candidate Path Selection

   The example SR policy described in Section 3 is used in the sections
   that follow to illustrate how the flexible candidate path selection
   method switches between candidate paths.

Liu, et al.               Expires June 2026                  [Page 12]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   SR policy POL1 has two candidate paths CP1 and CP2. The Preference
   of CP1 is 200, and the Preference of CP2 is 100. Both candidate
   paths are composed of three segment lists with the same weight.

5.1. Select the Best Path Based on End-to-End Delay

   The quality requirement for the services carried on the SR policy is
   that the transmission delay must be less than 200ms. The bandwidth
   of the actual traffic forwarded by the SR policy is between 100Mbps
   and 150Mbps.

   When the delay of Segment List 1 does not meet the requirements, the
   head node continues to check the available bandwidth of CP1. Due to
   segment list 2 only having 100Mbps bandwidth, it cannot meet the
   actual traffic forwarding requirements. CP1's Eligibility attribute
   is set to false, triggering the selection of CP2 as POL1's new
   active candidate path. The traffic forwarded by POL1 is switched to
   the path of CP2 for forwarding.

      SR Policy POL1
        Candidate Path CP1
           Preference 200
           Delay threshold 200ms //Delay<=200ms
           Segment List 1 <SID11...SID1i>, Weight 1 //100M, Delay>1s
           Segment List 2 <SID21...SID2i>, Weight 1 //100M, Delay<100ms
        Candidate Path CP2
           Preference 100
           Delay threshold 200ms  //Delay<=200ms
           Segment List 3 <SID31...SID3i>, Weight 1 //100M, Delay<100ms
           Segment List 4 <SID41...SID4i>, Weight 1 //100M, Delay<100ms

5.2. Select the Best Path Based on Available Bandwidth

   The preset bandwidth for both CP1 and CP2 is 300Mbps. Each segment
   list can carry a maximum of 100Mbps traffic. The quality requirement
   for service traffic is that the available bandwidth of the
   forwarding path must not be less than 150Mbps.

      SR Policy POL1
         Candidate Path CP1
            Preference 200
            Preset bandwidth 300Mbps
            Available bandwidth threshold 150Mbps
            Segment List 1 <SID11...SID1i>, Weight 1
            Segment List 2 <SID21...SID2j>, Weight 1
            Segment List 3 <SID31...SID3k>, Weight 1
         Candidate Path CP2
          Preference 100
            Preset bandwidth 300Mbps
          Available bandwidth threshold 150Mbps
            Segment List 4 <SID41...SID4i>, Weight 1
            Segment List 5 <SID51...SID5j>, Weight 1
Liu, et al.               Expires June 2026                  [Page 13]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


            Segment List 6 <SID61...SID6k>, Weight 1

   First, take the available bandwidth as the threshold parameter of
   POL1. The threshold for configuring the available bandwidth is
   150Mbps. When the available bandwidth of the candidate path is less
   than 150Mbps, perform path switching.

   Normally, the three segment lists of CP1 and CP2 are valid. The
   available bandwidth of CP1 is 300Mbps, and the available bandwidth
   can meet the threshold requirements. CP1's Eligibility attribute is
   set to true, CP1 is selected as the active candidate path according
   to the Preference.

   If the paths indicated by Segment List 1 and 2 fail, Segment List 1
   and 2 become not valid, and the available bandwidth of CP1 becomes
   100Mbps. Because the available bandwidth of CP1 is lower than the
   specified threshold, CP1 has failed to meet the forwarding quality
   requirements. CP1's Eligibility attribute is set to false. There is
   a need to reselect the active candidate path for POL1.

   The three segment lists of the low-preference candidate path CP2 of
   POL1 are valid, and the available bandwidth can meet the threshold
   requirements. CP2's Eligibility attribute is set to true. CP2 is
   selected as the new active candidate path of POL1. The traffic
   forwarded by POL1 will be switched to the path of CP2 for
   forwarding.

5.3. Select the Best Path Based on Actual Bandwidth

   In scenarios involving the actual available bandwidth measurement
   method for SRv6, as described in

   [I-D.liu-ippm-srv6-bandwidth-measurement], the quality requirement
   for the services carried on the SR policy mandates that the actual
   available bandwidth of the forwarding path must exceed 80 Mbps. If
   traffic congestion occurs on a node in Segment List 1, resulting in
   a maximum forwarding capacity of only 50 Mbps for service traffic,
   and if Segment List 2 is either in a down state or has exceeded the
   delay threshold, Segment List 2 will not participate in load sharing
   traffic.

   When the aggregate available bandwidth of CP1 falls below 80 Mbps:

      *  CP1's eligibility attribute is set to false.

      *  CP2's eligibility attribute is set to true (provided it meets
         forwarding requirements).

      *  CP2 SHALL become POL1's new active candidate path.

      SR Policy POL1
Liu, et al.               Expires June 2026                  [Page 14]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


        Candidate Path CP1
           Preference 200
            Preset bandwidth 200Mbps
           Actual available bandwidth threshold 80Mbps
            Segment List 1 <SID11...SID1i>, Weight 1
               (Actual available bandwidth is only 50Mbps.)
            Segment List 2 <SID21...SID2j>, Weight 1
               (In Down state, or the delay has exceeded the threshold.)
        Candidate Path CP2
           Preference 100
           Preset bandwidth 300Mbps
           Actual available bandwidth threshold 80Mbps
            Segment List 3 <SID41...SID4i>, Weight 1 (100Mbps)
            Segment List 4 <SID51...SID5j>, Weight 1 (100Mbps)
            Segment List 5 <SID61...SID6k>, Weight 1 (100Mbps)

   The traffic forwarded by POL1 will switch to the path of CP2 for
   forwarding.

6. IANA Considerations

   This document has no IANA actions.

7. Security Considerations

   [RFC8754] defines the notion of an SR domain and use of SRH within
   the SR domain.  Procedures for securing an SR domain are defined the
   section 5.1 and section 7 of [RFC8754].  This document does not
   introduce any additional security considerations beyond those
   described in [RFC8754], [RFC8679] and [RFC8986].

   The traffic switchover mechanism defined in this document, such as
   the ability to forcibly switch traffic from one control plane to
   another, may redirect traffic to an attacker's preset path.
   Additionally, switching traffic to another CP could overload network
   resources, leading to service unavailability or operational
   failures. Similarly, frequent flapping during switchovers may
   compromise network stability. Therefore, it is essential to ensure
   that this SR network operates within a trusted security domain while
   implementing safeguards like proper configuration and delayed
   switchback mechanisms to maintain secure SR Policy operation.

8. References

8.1. Normative References

   [I-D.karboubi-spring-sr-policy-eligibility] Karboubi, A., Shah, H.,
             Stone, A., Schmutzer, C. and Maheshwari, P., "Eligibility
             Concept in Segment Routing Policies", draft-karboubi-
             spring-sr-policy-eligibility-04 (work in progress),
             November 2025.

Liu, et al.               Expires June 2026                  [Page 15]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


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

   [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
             Decraene, B., Litkowski, S., and R. Shakir, "Segment
             Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,July
             2018, <https://www.rfc-editor.org/info/rfc8402>.

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

   [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
             Hardwick, J., "Path Computation Element Communication
             Protocol (PCEP) Extensions for Segment Routing", RFC8664,
             DOI 10.17487/RFC8664, December 2019, <https://www.rfc-
             editor.org/info/rfc8664>.

   [RFC9256] Filsfils, C., Talaulikar, K., 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>.

   [RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
             D. Jain, "Advertising Segment Routing Policies in BGP",
             RFC 9830, DOI 10.17487/RFC9830, September 2025,
             <https://www.rfc-editor.org/info/rfc9830>.

8.2. Informative References

   [I-D.liu-idr-bgp-sr-policy-cp-threshold] Liu, Y., Lin, C., Qiu,
             Y., " BGP Extension for Distributing CP Threshold
             Constraints of SR Policy", draft-liu-idr-bgp-sr-policy-cp-
             threshold-02 (expired), November 2024.

   [I-D.liu-pce-sr-policy-cp-threshold] Liu, Y., Lin, C., Qiu, Y., "
             PCEP Extension to Support Signaling Candidate Path
             Threshold Constraints of SR Policy", draft-liu-pce-sr-
             policy-cp-threshold-03 (expired), February 2025.

   [I-D.liu-ippm-srv6-bandwidth-measurement] Liu, Y., Lin, C., Qiu, Y.,
             Liu, Y., Liang, Y., " Measurement Method for Bandwidth of
             SRv6 Forwarding Path", draft-liu-ippm-srv6-bandwidth-
             measurement-00 (expired), November 2024.





Liu, et al.               Expires June 2026                  [Page 16]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


   [I-D.ietf-spring-stamp-srpm] Gandhi, R., Filsfils, C., Janssens, B.,
             Chen, M., and R.F. Foote, "Performance Measurement Using
             Simple Two-Way Active Measurement Protocol (STAMP) for
             Segment Routing Networks", Work in Progress, Internet-
             Draft, draft-ietf-spring-stamp-srpm-19, 20 June 2025,
             <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
             stamp-srpm-19>.

   [RFC2386] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A
             Framework for QoS-based Routing in the Internet", RFC
             2386, August 1998.

   [RFC5375] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., Babiarz,
             J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC
             5375, DOI 10.17487/RFC5375, October 2008,
             <https://www.rfc-editor.org/info/rfc5375>.

   [RFC9378] Brockners, F., Bhandari, S., Bernier, D., Mizrahi, T., "In
             Situ Operations, Administration, and Maintenance (IOAM)
             Deployment", RFC 9378, DOI 10.17487/RFC9378, April 2023,
             <https://www.rfc-editor.org/info/rfc9378>.

   [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
             Makhijani, K., Contreras, L., and J. Tantsura, "A
             Framework for Network Slices in Networks Built from IETF
             Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
             <https://www.rfc-editor.org/rfc/rfc9543>.

   [RFC9544] Mirsky, G., Halpern, J., Min, X., Clemm, A., Strassner,
             J., Francois, J., "Precision Availability Metrics for
             Services Governed by Service Level Objectives (SLOs)", RFC
             9544, DOI 10.17487/RFC9544, March 2024, <https://www.rfc-
             editor.org/info/rfc9544>.

















Liu, et al.               Expires June 2026                  [Page 17]

Internet-Draft    SR Policy Flexible Path Selection       December 2025


9. Acknowledgments

   The authors would like to thank the following for their valuable
   contributions of this document:

   TBD

Authors' Addresses

   Yisong Liu
   China Mobile
   Beijing
   China

   Email: liuyisong@chinamobile.com

   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com

   Shuping Peng
   Huawei Technologies
   Beijing
   China
   Email: pengshuping@huawei.com

   Ran Chen
   ZTE Corporation
   Nanjing
   China
   Email: chen.ran@zte.com.cn

   Zafar Ali
   Cisco Systems, Inc.
    Email: zali@cisco.com

   Gyan S. Mishra
   Verizon Inc.
   Email: gyan.s.mishra@verizon.com

   Yuanxiang Qiu
   New H3C Technologies
   Beijing
   China

   Email: qiuyuanxiang@h3c.com


Liu, et al.               Expires June 2026                  [Page 18] 
