SRops F. Yang Internet-Draft China Mobile Intended status: Informational C. Lin Expires: 13 August 2026 New H3C Technologies 9 February 2026 SR Policy Selector draft-yang-srv6ops-policy-selector-02 Abstract Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes a policy selection mechanism among the candidate SR Policies based on network quality. 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 13 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Yang & Lin Expires 13 August 2026 [Page 1] Internet-Draft SR Policy Selector February 2026 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem and Requirements . . . . . . . . . . . . . . . . . . 3 5. SR Policy Selector . . . . . . . . . . . . . . . . . . . . . 5 5.1. Processing Model . . . . . . . . . . . . . . . . . . . . 5 5.2. Flow Classification . . . . . . . . . . . . . . . . . . . 6 5.3. SR Policy Selector . . . . . . . . . . . . . . . . . . . 6 5.4. Network Quality Measurement . . . . . . . . . . . . . . . 7 5.5. Flow Forwarding . . . . . . . . . . . . . . . . . . . . . 8 6. Examples of SR Policy Selector . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. The [I-D.ietf-idr-performance-routing] specification defines a mechanism for disseminating path delay information across multiple Autonomous Systems (ASes). This information is used for BGP route computation. An SR Policy is associated with one or more candidate paths. A composite candidate path acts as a container for grouping SR Policies. As described in section 2.2 in [RFC9256], the composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for Yang & Lin Expires 13 August 2026 [Page 2] Internet-Draft SR Policy Selector February 2026 load-balanced steering of packet flows over its constituent SR Policies. For convenience, the composite candidate path formed by the combination of SR Policies is called parent SR Policy in [I-D.ietf-spring-sr-policy-group]. Different enterprise applications have varying network performance requirements. For instance, conference is highly sensitive to packet loss and jitter, while CRM applications are not highly demanding in terms of latency and packet loss. This document describes a policy selection mechanism among the candidate SR Policies based on network quality in IPv6 environments. 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. 3. Terminology The definitions of the basic terms are identical to those found in Segment Routing Policy Architecture [RFC9256]. CRM: Customer Relationship Management is a critical application that requires low bandwidth and low latency network connection. Parent SR Policy: Refer to [I-D.ietf-spring-sr-policy-group]. A Parent SR Policy is the composite candidate path that acts as a container for grouping SR Policies which meet different service optimization objectives and constraints and have the same destination endpoint. 4. Problem and Requirements Take the network shown in Figure 1 below as an example to illustrate the current problems. Yang & Lin Expires 13 August 2026 [Page 3] Internet-Draft SR Policy Selector February 2026 CE1 and CE2 are the two access endpoints of the IP telecom network. There are many service flows between CE1 and CE2 that have different requirements for forwarding quality. E.g. CRM and conference traffic have different SLA requirement, and expected be carried by different SR Policies. Generally, from CE1 to CE2, conference services with low latency requirements are forwarded along SR Policy PE1->P1->P2->PE2 and PE1->P3->P4->PE2. The CRM traffic is forwarded along the other SR Policy PE1->P5->P6->PE2. When failure or degradation happened in CRM SR Policy, it should be possible to switchover CRM traffic to conference SR Policy. +---------------+ | Controller | +---------------+ +------+ +------+ +-----+ P1 +----+ P2 +-------+ | +------+ +------+ | | | | +------+ +------+ | +-----+ P3 +----+ P4 +-------+ | +------+ +------+ | | | +-----+ +---+--+ +---+--+ +-----+ | CE1 +---+ PE1 | | PE2 +---+ CE2 | +-----+ +---+--+ +---+--+ +-----+ | | | +------+ +------+ | +-----+ P5 +----+ P6 +-------+ +------+ +------+ Figure 1 Based on such scenario, the following requirements should be met: 1. Maximize failure/degradation protection In case of failure or degradation detected on one SR Policy, it should be possible to do inter-policy protection. 2. Minimal impact after taking repairing action Repair action can be done on flow level to minimize the ripple effect cause by forwarding path switchover. 3. Maximize bandwidth efficiency Yang & Lin Expires 13 August 2026 [Page 4] Internet-Draft SR Policy Selector February 2026 For some critical applications, it should be possible to forward the traffic over lower class policy in case of higher class SR Policy degradation. Refer to [I-D.ietf-spring-sr-policy-group], the services with different forwarding quality requirements to the same destination endpoint can be implemented through parent SR Policy. This document proposes an SR Policy selector for parent SR Policy based on network quality requirement. The head end node of parent SR Policy selects the best constituent SR Policy for the application according to the quality of the constituent SR Policy. Take Figure 1 as an example, there is a parent SR Policy between PE1 to PE2, which has multiple constituent SR Policies. An SR Policy selection mechanism is needed, which should select best constituent SR Policy in the parent SR Policy. When the head node detects the quality degradation of the active constituent SR Policy, it will select another one in the parent SR Policy. 5. SR Policy Selector 5.1. Processing Model A new priority and a new quality threshold is created for the parent SR Policy. The lower the priority number, the higher the priority. That means active constituent SR Policy will be the one with higher priority and meeting the quality threshold. When the network quality degradation is happened on the active constituent SR Policy, such as the packet loss rate exceeds the threshold, switch to the next high priority constituent SR Policy which can meet the threshold value. If the quality of the high priority constituent SR Policy is restored and the specified quality threshold is met, the traffic will be switched back after a period of wait-to-restore time. According to the processing logic, the SR Policy Selector model can be divided into five units, including Flow Classification, Flow Steering, SR Policy Selector, Flow Forwarding, and Network Quality Measurement, as shown in Figure 2 below. Yang & Lin Expires 13 August 2026 [Page 5] Internet-Draft SR Policy Selector February 2026 +----------------------+ +----------------+ | Parent SR Policy | +------------+ | Flow +---->| +--->| Flow | | Classification | | SR Policy Selector | | Forwarding | +----------------+ +----------------------+ +------------+ ^ | +---------+-------+ | Network Quality | | Measurement | +-----------------+ Figure 2 The functions of each unit are described below. 5.2. Flow Classification After receiving the traffic, the head node first needs to label the traffic with application type according to classification configuration. 5.3. SR Policy Selector SR Policy Selector obtains the current quality of each constituent SR Policy from the Network Quality Measurement unit. Based on the quality threshold and the priority, SR Policy Selector selects the active constituent SR Policy. Yang & Lin Expires 13 August 2026 [Page 6] Internet-Draft SR Policy Selector February 2026 +--------------------------------------------------+ | Parent SR Policy | | +-------------+ | | +------------------------------+ |+-----------+| | | | SR Policy Selector | || SR Policy || | +-----------+ | | +-|-|+ (Color X) || | | Classified| | | +-----------+ +------+ / | |+-----------+| | | +--|-|-+ Threshold +--+ Prio +--+ | | | | | Traffic | | | +-----+-----+ +--+---+ | |+-----------+| | +-----------+ | | ^ ^ +-|-|+ SR Policy || | | | | | | || (Color Y) || | | +-------|-----------|----------+ |+------+----+| | | | | +-------|-----+ | | | | Prio Configuration | | | | \--------------------+ | +---------|--------------------------------|-------+ | | +---------+--------------+ Quality data | | Network Quality +<----------------/ | Measurement Function | +------------------------+ Figure 3 Each parent SR Policy contains multiple constituent SR Policies. Each constituent SR Policy will include two new configuration parameters, "priority" and "threshold" in this proposal. The constituent SR Policy with the highest priority and qualified threshold will be selected to carry the traffic. To avoid frequent path switching when the network quality is unstable, a wait-to-restore timer is required. Only after automatic restore is allowed and the wait-to-restore timer is timeout, the forwarding path switch from the current constituent SR Policy to the one with higher priority. 5.4. Network Quality Measurement The Network Quality Measurement unit regularly monitors the quality of all effective forwarding paths according to the measurement cycle, records the current performance measurement data of the path, and reports it to the SR Policy Selector unit, which decides whether to switch paths. The following network quality parameters can be used: * Jitter Yang & Lin Expires 13 August 2026 [Page 7] Internet-Draft SR Policy Selector February 2026 * Latency * Packet loss * Available bandwidth * Bandwidth utilization * Current traffic statistics * Other forwarding performance parameters The quality parameters can be obtained through active or passive performance measurement methods, such as STAMP, TWAMP, SR bandwidth measurement, etc. The network quality parameters can be calculated by the controller and distributed to the head end node, or calculated by the head end node according to the network measurement data. The measurement method and quality parameter acquisition method are beyond the scope of this document. 5.5. Flow Forwarding The service flow is forwarded according to the path determined by the SR Policy Selector unit. When there are multiple paths with the same priority, the traffic will share the load among these SR Policy paths with the same priority according to the weight value. 6. Examples of SR Policy Selector The application of SR Policy Selector is described in detail in L3VPN over TE scenario. Take the example shown in Figure 1. There are two services between CE1 and CE2: conference and CRM. The traffic from CE1 to CE2 can be forwarded through two paths: Path1 (PE1->P1->P2->PE2 and PE1->P3->P4->PE2) and Path2 (PE1->P5->P6->PE2). The conference service traffic will be forwarded through Path1 first. The CRM service traffic will be forwarded through Path2 first. When the transmission delay of Path1 exceeds the threshold value and Path2 can meet the delay requirements, switch the conference service to Path2. When the remaining bandwidth of Path2 is less than the bandwidth guarantee threshold, if Path1 still has enough remaining bandwidth, the CRM traffic exceeding the bandwidth will be directed to Path1. Yang & Lin Expires 13 August 2026 [Page 8] Internet-Draft SR Policy Selector February 2026 The configuration on the head node PE1 includes the following three parts. These configurations can be directly configured on the node or distributed through the controller. 1. Configure the parent SR Policy. parent-sr-policy sr-policy-1(color 10, PE2_SID) service conference use routing-policy-selector irp1 service crm use routing-policy-selector irp2 2. Configure constituent SR Policy. sr-policy path1 (color 100, PE2_SID) segment-list segment-list sr-policy path2 (color 200, PE2_SID) segment-list 3. Define three SR Policy Selector policies, and specify the threshold of network quality, priority. routing-policy-selector irp1 traffic-delay threshold 1000ms priority 1 mapping-to color 100 priority default mapping-to color 200 routing-policy-selector irp2 remaining-bandwidth threshold 50M priority 1 mapping-to color 200 priority default mapping-to color 100 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations This document does not introduce any security considerations. 9. References 9.1. Normative References [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, . Yang & Lin Expires 13 August 2026 [Page 9] Internet-Draft SR Policy Selector February 2026 [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, . [RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025, . [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, . 9.2. Informative References [I-D.ietf-idr-performance-routing] Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., Jacquenet, C., and J. Dong, "BGP Performance-aware Routing Mechanism", Work in Progress, Internet-Draft, draft-ietf- idr-performance-routing-05, 5 July 2025, . [I-D.ietf-spring-sr-policy-group] Cheng, W., Wenying, J., Lin, C., Chen, R., and Y. Zhang, "SR Policy Group", Work in Progress, Internet-Draft, draft-ietf-spring-sr-policy-group-00, 13 January 2026, . Acknowledgements The authors would like to thank the following for their valuable contributions of this document. TBD. Authors' Addresses Yang & Lin Expires 13 August 2026 [Page 10] Internet-Draft SR Policy Selector February 2026 Feng Yang China Mobile Beijing China Email: yangfeng@chinamobile.com Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Yang & Lin Expires 13 August 2026 [Page 11]