SPRING Working Group Y. Liu Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: March 14, 2024 New H3C Technologies S. Peng Huawei Technologies Y. Qiu New H3C Technologies September 11, 2023 Flexible Candidate Path Selection of SR Policy draft-liu-spring-sr-policy-flexible-path-selection-02 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 14 2024. Copyright Notice Copyright (c) 2021 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Liu, et al. Expire March, 2024 [Page 1] Internet-Draft SR Policy Flexible Path Selection September 2023 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Background of requirements.....................................3 4. Flexible Candidate Path Selection Method.......................5 4.1. Threshold Parameters of Candidate Paths...................5 4.2. Rules for Selecting the Best Path.........................6 4.3. Flexible Candidate Path Selection Process.................7 5. Examples of Flexible Candidate Path Selection..................8 5.1. Select the Best Path Based on Available Bandwidth.........8 5.2. Select the Best Path Based on End-to-End Delay............9 5.3. Select the Best Path Based on Ratio of Valid Segment Lists in Candidate Path.............................................10 6. IANA Considerations...........................................10 7. Security Considerations.......................................10 8. References....................................................10 8.1. Normative References.....................................10 8.2. Informative References...................................11 9. Acknowledgments...............................................11 Authors' Addresses...............................................12 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 [I-D.ietf-idr-segment-routing-te-policy] [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. Liu, et al. Expires March, 2024 [Page 2] Internet-Draft SR Policy Flexible Path Selection September 2023 Refer to [RFC9256] only the active candidate path MUST be used for forwarding traffic that is being steered onto that policy except for certain scenarios such as fast reroute where a backup candidate path may be used. A candidate path can be represented as a segment list or a set of segment lists. If a set of segment lists is associated with the active path of the policy, then the steering is per flow and weighted-ECMP (W-ECMP) based according to the relative weight of each valid segment list. According to the criteria for the validity of candidate paths described in Section 5 of [RFC9256], as long as there is a valid segment list in the active candidate path, the active candidate path is still valid. When some segment lists of the active candidate path are invalid, the active candidate path may still be valid, but it may not continue to meet the actual forwarding requirements. This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. 2. Terminology The definitions of the basic terms are identical to those found in Segment Routing Policy Architecture [RFC9256]. 3. Background of requirements When some segment lists of the active candidate path are invalid, according to [RFC9256], as long as 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 along the original active candidate path. Take the following SR Policy as an example to explain in detail the problems existing in the current candidate path selection process. SR Policy POL1 Candidate Path CP1 Preference 200 Segment List 1 , Weight 1 Segment List 2 , Weight 1 Segment List 3 , Weight 1 Candidate Path CP2 Liu, et al. Expires March, 2024 [Page 3] Internet-Draft SR Policy Flexible Path Selection September 2023 Preference 100 Segment List 4 , Weight 1 Segment List 5 , Weight 1 Segment List 6 , Weight 1 There are two candidate paths CP1 and CP2 in SR policy POL1. CP1 has a higher preference. Both candidate paths are composed of three segment lists with the same weight. The path indicated by each segment list can carry traffic of 100M bandwidth. When the Segment Lists are valid, the candidate path can carry traffic with bandwidth less than 300M. The bandwidth of the actual traffic forwarded by the SR policy is between 100M and 150M. Because the traffic forwarded on the candidate path will share the load on the three segment list paths according to the weight value. Therefore, normally, the candidate path can meet the forwarding requirements. The traffic is forwarded on the three segment lists of the high preference candidate paths of the SR policy. When the segment list 1 and 2 in the high-preference candidate path CP1 are invalid, according to the candidate path validity criteria described in [RFC9256] Section 5, because the segment list 3 in CP1 is still valid, the active candidate path CP1 is still valid. All traffic of SR policy POL1 will continue to be forwarded based on the path of CP1. However, because segment list 3 can only forward 100M 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 switching. When the quality of high preference candidate paths deteriorates, such as insufficient available bandwidth, increased end-to-end transmission delay, and available segment lists that cannot meet service requirements, the same requirement exists. We hope to switch traffic to other candidate paths in the SR policy that better meet the forwarding quality requirements. To solve this problem, this document proposes a new candidate path selection rule, which sets resource thresholds and forwarding quality requirements for candidate path. This candidate path can only be selected if the current path can meet the preset requirements. Liu, et al. Expires March, 2024 [Page 4] Internet-Draft SR Policy Flexible Path Selection September 2023 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. In the case of multiple valid candidate paths of the same Preference, the tie-breaking rules are evaluated on the identification tuple in the following order until only one valid best path is selected: 1. The higher value of Protocol-Origin is selected. 2. If specified by configuration, prefer the existing installed path. 3. The lower value of the Originator is selected. 4. Finally, the higher value of the Discriminator is selected. This document proposes to take the forwarding quality requirements and resource requirements of candidate paths as the selection criteria of candidate paths. Set the threshold parameters of forwarding quality and resources for candidate paths. First, find the paths that meet the threshold from the candidate paths of SR policy, and then select the best path as the active path according to the rules in the above standards. 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 If there are multiple segment lists in the candidate path, as long as the delay, jitter or packet loss rate parameters of any valid segment list in the candidate path fail to meet the specified threshold requirements, it is considered that the candidate path does not meet the threshold requirements. * Available bandwidth Liu, et al. Expires March, 2024 [Page 5] Internet-Draft SR Policy Flexible Path Selection September 2023 If there are multiple segment lists in the candidate path, the available bandwidth is the sum of all valid segment lists in the candidate path, or the cumulative value calculated based on the weight and bandwidth of each segment list. * Bandwidth utilization * Current flow rate * Ratio of valid segment lists in candidate path This parameter reflects the failure ratio of the segment list in the candidate path. The higher ratio of valid segment lists, the candidate path is more robust. If the weight of the segment list is different, a threshold for each segment list separately can be specified. The threshold of the candidate path is the sum of the thresholds of the segment list calculated based on the weight. When multiple threshold parameters are specified on the candidate path at the same time, the candidate path is considered to meet the threshold requirements only if all the threshold requirements are met. 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. 4.2. Rules for Selecting the Best Path When the current forwarding quality and hardware resources of a candidate path meet the specified threshold requirements, it only means that this candidate path could forward traffic. If there are multiple candidate paths in the SR policy that meet the forwarding requirements at the same time, the candidate paths need to be sorted to select the best one. Under the condition that multiple valid candidate paths meet the threshold requirements, evaluate the tie breaking rules in the following order until only one valid best path is selected: Liu, et al. Expires March, 2024 [Page 6] Internet-Draft SR Policy Flexible Path Selection September 2023 1. If the quality requirements of the candidate path are specified, it is necessary to check whether the path meets the quality requirements. Only the valid path that meets the quality requirements can be selected as the active path. If only one path in the SR policy meets the quality requirements, the path is selected. If multiple candidate paths meet the quality requirements at the same time, or if all candidate paths fail to meet the requirements, then select the following second step according to the Preference. 2. The higher value of the Preference is selected. 3. The higher value of Protocol-Origin is selected. 4. If specified by configuration, prefer the existing installed path. 5. The lower value of the Originator is selected. 6. Finally, the higher value of the Discriminator is selected. 4.3. Flexible Candidate Path Selection Process The process of selecting the best path for SR policy through the threshold parameter of the path is as follows. 1. Configure the threshold parameters on the candidate path of the head node through static manual configuration or controlled distribution. 2. The head node monitors whether the available resources and forwarding quality of the SR policy candidate path exceed the thresholds. The forwarding quality of path can be obtained through active or passive performance measurement methods, such as iOAM, STAMP, TWAMP, etc. The real-time quality data can be calculated by the controller and distributed to the head node, or calculated by the head node according to the network measurement data. The measurement method and quality data acquisition method are beyond the scope of this document. 3. According to the rules described in Section 4.2, when the available resources are less than the threshold, or the Liu, et al. Expires March, 2024 [Page 7] Internet-Draft SR Policy Flexible Path Selection September 2023 forwarding quality cannot meet the threshold requirements, select a new active candidate path. 4. After the old active candidate path eliminates the fault or improves the forwarding quality, whether to recover can be specified by the configuration. If fault recovery is required, start a wait timer for delay recovery. If the timer expires and the old candidate path still meets the threshold requirements, the traffic will be switched to the old higher preference candidate path. For avoiding path switching frequently, both over-threshold switching and fault recovery should be delayed. The interval of delay waiting can be adjusted by configuration. In order to distribute the threshold parameters of SR Policy to the head node, it may be necessary to extend the control plane, such as NetConf, PCEP and BGP. This document does not limit the specific distribution method. The specific control plane extension will be described in other documents. 5. Examples of Flexible Candidate Path Selection The SR policy in Section 3 is still used to illustrate how the flexible candidate path selection method switches candidate paths. 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 Available Bandwidth The path indicated by each segment list can carry traffic of 100M bandwidth. When the Segment Lists are valid, the candidate path can carry traffic with bandwidth less than 300M. The bandwidth of the actual traffic forwarded by the SR policy is between 100M and 150M. SR Policy POL1 Candidate Path CP1 Preference 200 Available bandwidth ratio 50 Segment List 1 , Weight 1 Segment List 2 , Weight 1 Segment List 3 , Weight 1 Candidate Path CP2 Preference 100 Available bandwidth ratio 50 Segment List 4 , Weight 1 Liu, et al. Expires March, 2024 [Page 8] Internet-Draft SR Policy Flexible Path Selection September 2023 Segment List 5 , Weight 1 Segment List 6 , Weight 1 First, take the available bandwidth as the threshold parameter of POL1. The threshold for configuring the ratio of available bandwidth is 50%. When the available bandwidth of the candidate path is less than 50%, path switching is performed. Normally, the three segment lists of CP1 and CP2 are valid. The available bandwidth of CP1 is 300M, and the ratio of available bandwidth is 100%, which can meet the threshold requirements of the path. So CP1 is selected as the active candidate path according to the Preference. If the paths indicated by Segment 1 and 2 fail, Segment List 1 and 2 become invalid, and the available bandwidth of CP1 becomes 100M. The ratio of available bandwidth becomes 33.3% (i.e. 100/300). Because the ratio of available bandwidth of CP1 is lower than the specified threshold, CP1 has failed to meet the forwarding quality requirements. 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 is selected as the new active candidate path of POL1. The traffic forwarded by POL1 is switched to the path of CP2 for forwarding. 5.2. 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. If the delay detected on any Segment List of CP1 does not meet the requirements, CP2 is selected as the new active candidate path of POL1. The traffic forwarded by POL1 is switched to the path of CP2 for forwarding. SR Policy POL1 Candidate Path CP1 Preference 200 Delay threshold 200 //Delay<=200ms Segment List 1 , Weight 1 //Delay>1s Segment List 2 , Weight 1 //Delay>2s Segment List 3 , Weight 1 //Delay<100ms Candidate Path CP2 Preference 100 Delay threshold 200 //Delay<=200ms Segment List 4 , Weight 1 //Delay<100ms Segment List 5 , Weight 1 //Delay<100ms Liu, et al. Expires March, 2024 [Page 9] Internet-Draft SR Policy Flexible Path Selection September 2023 Segment List 6 , Weight 1 //Delay<100ms 5.3. Select the Best Path Based on Ratio of Valid Segment Lists in Candidate Path Per Section 2.2 of [RFC9256] a segment list represents a specific source-routed path to send traffic from the headend to the endpoint of the corresponding SR Policy. If a candidate path is associated with a set of segment lists, each segment list is associated with weight for weighted load balancing. The ratio of the valid number of segment lists within the candidate path to the total number represents the health level of the candidate path. The higher ratio of valid segment lists, the candidate path is more robust. When the ratio of valid segment list of POL1 falls below the specified threshold, switch the traffic to POL2 with a higher valid segment list ratio. SR Policy POL1 Candidate Path CP1 Preference 200 Valid segment list ratio 70% Segment List 1 , Weight 1 Segment List 2 , Weight 1 Segment List 3 , Weight 1 Candidate Path CP2 Preference 100 Valid segment list ratio 70% Segment List 4 , Weight 1 Segment List 5 , Weight 1 Segment List 6 , Weight 1 6. IANA Considerations This document has no IANA actions. 7. Security Considerations This document does not introduce any security considerations. 8. References 8.1. Normative References [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf- idr-segment-routing-te-policy-23 (work in progress), July 2023. Liu, et al. Expires March, 2024 [Page 10] Internet-Draft SR Policy Flexible Path Selection September 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . 8.2. Informative References TBD 9. Acknowledgments The authors would like to thank the following for their valuable contributions of this document: TBD Liu, et al. Expires March, 2024 [Page 11] Internet-Draft SR Policy Flexible Path Selection September 2023 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 Yuanxiang Qiu New H3C Technologies Beijing China Email: qiuyuanxiang@h3c.com Liu, et al. Expires March, 2024 [Page 12]