SPRING Working Group C. Huang Internet-Draft K. Ruan China Telecom Intended status: Informational September 15, 2026 Expires: March 15, 2027 Framework for Time-Scheduled Color based SR Policy Selection draft-huang-spring-time-scheduled-color-framework-00 Abstract In Segment Routing (SR) based VPN services, the BGP Color Extended Community is used by the egress Provider Edge (PE) router to steer VPN traffic into an SR Policy at the ingress PE. In many deployment scenarios, a customer requires different Service Level Agreements (SLAs) during different time periods of a day. For example, during business hours (e.g., 06:00 to 02:00 the next day) a best-effort, lower-cost SLA is sufficient for normal office traffic, while during the early morning hours (e.g., 02:00 to 06:00) a high-bandwidth, low-latency SLA is required for massive data transmission such as scientific computing. This document presents a framework for time-scheduled Color based SR Policy selection. The mechanism allows the egress PE to advertise multiple (Color, Color Schedule) pairs for the same VPN routes, enabling the ingress PE to select the appropriate SR Policy based on the current time. The time-to-Color mapping is configured per VPN instance (VRF/VSI), so each customer can have an independent time-varying SLA policy. This document is an Informational framework that describes the problem and the overall architecture. The advantages of the proposed mechanism and the comparison with alternative approaches are provided in Appendix A. The normative specifications of the protocol extensions, data models, and other components are described in Appendix B. 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 March 15, 2027. Huang Expires March 15, 2027 [Page 1] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Egress PE Behavior . . . . . . . . . . . . . . . . . . . 5 4.3. Ingress PE (Headend) Behavior . . . . . . . . . . . . . 6 5. Operational Considerations . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Advantages and Comparison with Alternative Approaches . . . . . . . . . . . . . . . . . . . 8 A.1. Comparison with Potential Alternative Approaches . . . . . . . . . . . . . . . . . . . . . . . . . 8 A.1.1. Ingress-Side Approaches . . . . . . . . . . . . . . 9 A.1.1.1. SR Policy Group with Time-Scheduled Constituents . . . . . . . . . . . . . . . . . . . . . . 9 A.1.1.2. Route-Policy Provisioning on Ingress PE . . . . 10 A.1.2. Egress-Side Realtime Color Reconfiguration . . . . . . . . . . . . . . . . . . . . . . 11 A.2. Advantages of the Proposed Approach . . . . . . . . . . . 12 Appendix B. Component Documents . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In Segment Routing (SR) based Layer 3 VPN (L3VPN) and Layer 2 VPN (L2VPN) services, the BGP Color Extended Community [RFC9012] is used by the egress Provider Edge (PE) router to associate an intent with the advertised VPN routes. The ingress PE (headend) uses this Color value to select an SR Policy [RFC9256] for traffic steering. An SR Policy is identified by the (Color, Endpoint) tuple, where Color represents the SLA intent (e.g., low latency, high bandwidth) and Endpoint is the egress PE. In many deployment scenarios, a customer's service requirement Huang Expires March 15, 2027 [Page 2] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 varies over time. For example, during business hours (e.g., 06:00 to 02:00 the next day) a customer may require a high-bandwidth, low-latency SLA for massive data transmission such as scientific computing, while during the early morning hours (e.g., 02:00 to 06:00) a best-effort, lower-cost SLA is sufficient. More generally, different customers may have completely different time-varying SLA requirements. This document presents a framework for time-scheduled Color based SR Policy selection. The mechanism allows the egress PE to advertise multiple (Color, Color Schedule) pairs for the same VPN routes. The ingress PE evaluates the Color Schedule associated with each Color based on the current time and selects the SR Policy corresponding to the currently valid Color. The time-to-Color mapping is configured per VPN instance (VRF for L3VPN, VSI/EVPN instance for L2VPN) at the egress PE. This per-VPN granularity allows each customer to have an independent time-varying SLA policy, and different VPNs may reuse the same Color value with different schedules. This document is an Informational framework. It describes the problem and the overall architecture. The advantages of the proposed mechanism and the comparison with alternative approaches are provided in Appendix A. The normative specifications of the protocol extensions, data models, and other components are described in Appendix B. 1.1. 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. 2. Terminology This document uses the terms defined in [RFC9256], [RFC9012], and [RFC9830]. o Color: A 32-bit value carried in the Color Extended Community [RFC9012] that identifies an SR Policy intent. o SR Policy: A set of Candidate Paths, each consisting of one or more Segment Lists, that steers traffic into an ordered list of segments [RFC9256]. o Egress PE: The PE router that originates VPN routes and attaches the Color Extended Community. o Ingress PE (Headend): The PE router that receives VPN routes and selects an SR Policy based on the Color value. o Color Schedule: A time period during which a particular Color is valid. In the remainder of this document, "Color Schedule" is abbreviated as "Schedule" when the context is unambiguous. o (Color, Schedule) Pair: A Color value together with an associated Color Schedule that defines when the Color is valid. Huang Expires March 15, 2027 [Page 3] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 3. Problem Statement The SR Policy architecture [RFC9256] associates a single Color with each VPN route. Once the egress PE attaches a Color to a VPN route, the ingress PE always selects the same SR Policy for that route, regardless of the time of day. This static mapping cannot satisfy time-varying SLA requirements. For example, a customer may want: o 06:00 to 02:00 (next day): best-effort, lower-cost SLA for normal office traffic. o 02:00 to 06:00: high-bandwidth, low-latency SLA for massive data transmission such as scientific computing. To support such requirements, the egress PE needs to associate different Colors with the same VPN routes during different time periods. Several existing or proposed mechanisms address related but different problems, and none of them fully satisfy the per-VPN time- varying SLA requirement. These alternative approaches and their limitations are discussed in detail in Appendix A. The proposed framework addresses these limitations by carrying time- scheduled Colors directly on each VPN route, with per-VPN configuration granularity. 4. Solution Overview 4.1. Architecture The overall architecture is shown below: +-------------+ | Controller | | / NMS | +------+------+ | NETCONF (YANG: color-schedules per VRF/VSI, | or route-policy with time-schedule match) v +-------------------+ BGP UPDATE (VPN route + | Egress PE | Color EC + Schedule EC) | |----------------------------+ | VRF/VSI: | | | color 100: | v | schedule A | +-------------------+ | color 200: | | Ingress PE | | schedule B | | (Headend) | +-------------------+ | | Huang Expires March 15, 2027 [Page 4] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 | Parse (Color, | | Schedule) pairs | | Select valid | | Color by time | | -> SR Policy | +-------------------+ The key components and the overall process are: 1. Configuration: The controller provisions the egress PE with a list of (Color, Schedule) entries per VPN instance (VRF or VSI) using a YANG data model or a route-policy with time-schedule match. The architecture shown above assumes the YANG data model approach, in which all candidate (Color, Schedule) pairs are advertised in a single BGP UPDATE. 2. Encoding: The egress PE translates each (Color, Schedule) entry into a Color Extended Community [RFC9012] and a Schedule Extended Community, and attaches them to the advertised VPN routes. 3. Selection: The ingress PE receives the VPN routes with multiple (Color, Schedule) pairs. Based on the current time, it determines which Color(s) are currently valid, selects one, and steers the traffic into the corresponding SR Policy. The end-to-end process flow is: the controller configures (Color, Schedule) entries on the egress PE; the egress PE encodes them into BGP Extended Communities and advertises them on the VPN routes; the ingress PE parses and stores the (Color, Schedule) pairs, evaluates them against the current time, selects the valid Color, looks up the corresponding SR Policy, and installs the forwarding entry into the VRF FIB. At each schedule boundary, the ingress PE re-evaluates the selected Color and updates the FIB entry locally. 4.2. Egress PE Behavior The egress PE maintains a per-VPN-instance list of (Color, Schedule) entries configured by the controller. When advertising VPN routes for that VPN instance, the egress PE attaches, for each entry: o A Color Extended Community carrying the Color value. o Optionally, a Schedule Extended Community describing when that Color is valid. If an entry has no associated schedule, the Color is always valid (preserving backward compatibility with the existing static Color behavior). The egress PE advertises all (Color, Schedule) pairs in a single BGP Huang Expires March 15, 2027 [Page 5] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 UPDATE message for each VPN route. This avoids the need to re- advertise routes at each time boundary. 4.3. Ingress PE (Headend) Behavior The ingress PE receives VPN routes carrying one or more (Color, Schedule) pairs. When processing these routes, the ingress PE stores the (Color, Schedule) pairs in both the BGP VPNv4/VPNv6 global routing table and the per-VRF routing table, alongside the existing route attributes (RD, RT, next hop, VPN label/SID, etc.). This extends the existing route storage without changing the fundamental table structure. For each route, the ingress PE: 1. Parses all Color Extended Communities and their associated Schedule Extended Communities from the BGP UPDATE. 2. Stores all (Color, Schedule) pairs with the route entry in the VPNv4/VPNv6 routing table and the VRF routing table. 3. Evaluates each schedule against the current time to determine which Colors are currently valid. 4. Selects one valid Color (the selection rule is defined in the companion headend behavior specification). 5. Looks up the SR Policy identified by (selected Color, Endpoint). 6. Installs the forwarding entry for the route into the VRF forwarding table (FIB), pointing to the selected SR Policy. The VRF routing table is the control-plane table from which the VRF FIB (the data-plane table used for actual packet forwarding) is derived; installing the selected SR Policy into the FIB completes the control-to-data-plane handoff. To handle time-based switchover, the ingress PE sets a timer for the next schedule boundary (i.e., the earliest time at which the set of valid Colors changes). When the timer expires, the ingress PE re-evaluates which Color is valid, selects the new Color, and updates the VRF FIB to point to the corresponding SR Policy. This timer-based approach avoids continuous polling. The switchover is performed locally without any control-plane churn, and a make-before- break mechanism is used to avoid traffic loss. 5. Operational Considerations This section describes operational aspects of the time-scheduled Color mechanism. Huang Expires March 15, 2027 [Page 6] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 o Schedule configuration management: The (Color, Schedule) entries are configured per VPN instance on the egress PE. Operators SHOULD ensure that schedules do not leave gaps (time periods during which no Color is valid) unless a fallback behavior is explicitly desired. Overlapping schedules are resolved by the selection rule defined in the companion headend behavior specification. o Monitoring: Operators may wish to monitor the currently active Color per VRF and receive notifications of time-based switchover events. A BGP-LS extension for reporting the time-scheduled Color switchover state to the controller is described in Appendix B. o Backward compatibility: A Color without an associated Schedule is always valid, preserving the existing static Color behavior. Ingress PEs that do not support the Schedule Extended Community ignore it and use the first Color (or any Color) as in the existing behavior. o Make-before-break: The time-based switchover at the ingress PE SHOULD use a make-before-break mechanism to install the new SR Policy before removing the old one, avoiding traffic loss during the transition. o Interaction with other headend functions: The time-scheduled Color selection MUST NOT conflict with other headend operations such as NR-proxy, parent-and-child SR Policies, and Layer 2 service handling. The precedence and interaction rules that guarantee this are designed and specified in the headend behavior document (see Appendix B). 6. Security Considerations This framework document does not introduce new security considerations beyond those already applicable to BGP, SR Policy, and VPN services. The Schedule Extended Community is carried in BGP UPDATE messages and is subject to the same security mechanisms (e.g., BGPsec, TCP-AO) as other BGP attributes. The YANG data model is accessed via NETCONF/RESTCONF and is subject to standard access control [RFC8341]. 7. IANA Considerations This document has no IANA actions. IANA considerations for the Schedule Extended Community and the YANG modules are addressed in the respective component documents. 8. References 8.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. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC9012] Patel, G., Sajassi, A., Aggarwal, R., Bitar, N., and Huang Expires March 15, 2027 [Page 7] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 J. Uttaro, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021. [RFC9256] Filsfils, C., Talaulikar, K., Ed., Dukes, D., previdi, s., Matsushima, S., and Z. Zhang, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022. [RFC9830] Patel, G., Sajassi, A., Swallow, G., Drake, J., and J. Tantsura, "Advertising Segment Routing Policies in BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025. 8.2. Informative References [RFC8341] Bierman, A., Bjorklund, M., and K. Watsen, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018. [I-D.ietf-spring-sr-policy-group] Cheng, W., Li, C., Peng, S., and J. Tantsura, "Segment Routing Policy Group", Work in Progress, Internet-Draft draft-ietf-spring-sr-policy-group, 2026. [I-D.zzd-idr-sr-policy-scheduling] Zhang, L., Zhou, T., Dong, J., Wang, M., and N. Nzima, "BGP SR Policy Extensions for Path Scheduling", Work in Progress, Internet-Draft draft-zzd-idr-sr-policy- scheduling, 2026. Appendix A. Advantages and Comparison with Alternative Approaches This appendix discusses alternative approaches that could address time-varying SLA requirements and explains their limitations relative to the proposed mechanism, followed by a description of the advantages of the proposed approach. A.1. Comparison with Potential Alternative Approaches The alternative approaches can be broadly classified into two categories: Huang Expires March 15, 2027 [Page 8] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 o Ingress-side approaches: the time-based scheduling is implemented at the ingress PE (headend), either by extending the SR Policy with time information or by provisioning (Color, Schedule) mappings directly on the ingress PE. o Egress-side realtime Color reconfiguration: the Color value on the egress PE is changed in real time at each time boundary by the controller reconfiguring the egress PE. A.1.1. Ingress-Side Approaches Ingress-side approaches keep the Color value static on the egress PE and perform the time-based scheduling at the ingress PE (headend). Two sub-categories are discussed below. A.1.1.1. SR Policy Group with Time-Scheduled Constituents This sub-category uses time-based scheduling within the SR Policy framework at the headend. The SR Policy Group mechanism [I-D.ietf-spring-sr-policy-group] enables a parent SR Policy to steer traffic into a set of constituent SR Policies based on the packet's Forwarding Class (e.g., DSCP). Adding time-based scheduling to this mechanism is a potential alternative approach. This approach has the following limitations relative to the proposed egress-advertised (Color, Schedule) mechanism: o FIB update trigger outside the standard routing pipeline: In this approach the time schedule is stored in the SR Policy database (or the Group's Forwarding-Class-to-Color mapping table), not in the VPN routing table. At a time boundary the Color carried by the VPN route does not change, so the standard route-to-FIB update pipeline is not triggered. The SR Policy subsystem would need to implement a new timer-based mechanism to recompute the active constituent mapping and actively push FIB updates to all affected VRF entries. In the proposed approach, a time boundary changes the selected Color as a routing event, which reuses the standard route-to-FIB update pipeline. o Time-schedule granularity vs. SR Policy DB indexing: The SR Policy database is indexed by (Color, Endpoint), and the Group configuration is a headend-local construct. The (Forwarding Class, time period) to constituent-Color mapping rule is the same for all endpoints within a Group. If this mapping rule is carried in the composite candidate path of each parent SR Policy, it is duplicated across every endpoint of the Group. o SLA intent source deviates from the RFC 9012 producer/consumer model: In this approach the time-to-SLA mapping is configured by the controller and distributed to the headend via the BGP SR Huang Expires March 15, 2027 [Page 9] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 Policy SAFI. The egress PE no longer expresses the customer's time-varying SLA intent. o Controller-centric provisioning and propagation: The time-to- constituent mapping must be provisioned by the controller and pushed to every headend. When a new ingress PE joins the network, the controller must explicitly push the relevant Group configuration and time schedule to it. In the proposed approach, the schedule is carried by the VPN route and is automatically propagated to all ingress PEs via BGP. A.1.1.2. Route-Policy Provisioning on Ingress PE An alternative approach is for the controller to directly provision (Color, Schedule) entries on the ingress PE via a route-policy or management interface. In this approach, the controller configures the ingress PE with route-policy rules that match VPN routes (e.g., by Route Target) and set the corresponding (Color, Schedule) pairs. The ingress PE stores this information in the VPNv4/VPNv6 routing table and the VRF routing table and performs time-based Color selection locally. This approach shares several fundamental limitations with the SR Policy Group approach discussed in A.1.1.1, including deviation from the RFC 9012 Color producer/consumer model and controller- centric provisioning. The detailed analysis of these shared limitations can be found in Section A.1.1.1. In addition, the route-policy approach has the following limitations that are specific to its local-configuration nature: o Multi-ingress configuration replication: A route-policy is local to the device on which it is configured and is not propagated by BGP. Therefore, the controller must configure the (Color, Schedule) route-policy on every ingress PE that receives the VPN routes. As the number of ingress PEs grows, the configuration footprint grows proportionally (O(ingress PEs x VPNs)). In contrast, the proposed mechanism requires the (Color, Schedule) pairs to be configured only once on the egress PE; BGP then propagates them automatically to every ingress PE that receives the routes (O(egress PEs x VRFs)). o Difficulty distinguishing routes from multiple egress PEs: An ingress PE may receive routes with the same Route Target from multiple egress PEs (e.g., in multi-homing scenarios). If different egress PEs require different (Color, Schedule) mappings for the same Route Target, the ingress route-policy must match on additional attributes (e.g., next-hop), increasing complexity. In the proposed mechanism, each egress PE attaches its own (Color, Schedule) pairs to its routes, so the mapping is Huang Expires March 15, 2027 [Page 10] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 naturally scoped per egress. For these reasons, the proposed mechanism carries the (Color, Schedule) pairs from the egress PE to the ingress PE via BGP Extended Communities, preserving the RFC 9012 Color model, scaling naturally across multiple ingress PEs, and keeping the schedule semantics close to the customer at the egress. A.1.2. Egress-Side Realtime Color Reconfiguration This approach changes the Color value on the egress PE in real time at each time boundary. The controller maintains a time-to-Color mapping for each VPN instance and reconfigures the egress PE with the new Color value via NETCONF at each time boundary. Since the Color is carried in the BGP Extended Communities attribute, any Color change requires the egress PE to re-advertise all VPN routes in the affected VRF with updated path attributes. This approach has the following fundamental limitations, which arise from the need to change the Color value at every time boundary: o Control-plane churn: Each time boundary requires the egress PE to re-advertise all VPN routes in the VRF with updated path attributes (the Color Extended Community). The egress PE generates a BGP UPDATE for each route carrying the new Color value, and these updates propagate to all ingress PEs that import the VRF. For a VRF with hundreds to thousands of routes, and with multiple ingress PEs, this generates significant control-plane load and prolongs convergence across the network. The churn repeats at every time boundary (e.g., twice a day for a day/night schedule), multiplied by the number of VRFs on different schedules. o Traffic disruption: The Color change involves a multi-step convergence process (attribute update on the egress PE -> BGP propagation -> ingress PE update) that introduces a convergence window during which traffic may be steered to the wrong SLA or temporarily dropped. o Re-origination overhead: The egress PE must re-originate all VPN routes at each time boundary, which is expensive in terms of CPU and memory. o Controller dependency: The switchover requires the controller to be online and the NETCONF session to all egress PEs to be healthy at every time boundary. A controller or session failure leaves the service stuck at the old SLA indefinitely. Huang Expires March 15, 2027 [Page 11] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 o Poor scalability: With many VRFs on different schedules, the controller must manage many independent timers and trigger many concurrent NETCONF transactions and VPN route re-advertisements. In contrast, the proposed (Color, Schedule) approach advertises all candidate Colors with their schedules in a single BGP UPDATE. The ingress PE performs the time-based selection locally, eliminating control-plane churn, minimizing switchover latency, and removing the dependency on controller availability at switchover time. A.2. Advantages of the Proposed Approach The proposed (Color, Schedule) approach has the following advantages: o Per-VPN granularity: The (Color, Schedule) mapping is configured per VPN instance. Each customer can have an independent time- varying SLA policy. Different VPNs may reuse the same Color value with different schedules. o No control-plane churn: All (Color, Schedule) pairs are advertised in a single BGP UPDATE. Time-based selection is performed locally at the ingress PE without any re-advertisement of VPN routes. o Low switchover latency: The ingress PE switches the selected Color when a local schedule-boundary timer expires, with no multi-step convergence process. Switchover latency is bounded by the timer granularity and FIB update time, which is on the order of milliseconds, compared to seconds or minutes for controller-based or route-policy-based approaches. o No traffic loss: A make-before-break mechanism ensures that the new SR Policy is installed before the old one is removed, avoiding packet loss during switchover. o No controller dependency at switchover: Once the BGP UPDATE carrying the (Color, Schedule) pairs has reached the ingress PE, the time-based selection is fully autonomous. The controller does not need to be online at the time of switchover. o Scalability: The mechanism scales well with the number of VPN instances and routes, since each route carries its own (Color, Schedule) pairs and selection is local to the ingress PE. o Backward compatibility: A Color without a Schedule Extended Community is always valid, preserving the existing static Color behavior. Ingress PEs that do not support the Schedule Extended Community ignore it and use the first Color (or any Color) as in the existing behavior. Huang Expires March 15, 2027 [Page 12] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 o Complementarity with existing mechanisms: The proposed mechanism complements candidate-path level scheduling [I-D.zzd-idr-sr-policy-scheduling] and SR Policy Group [I-D.ietf-spring-sr-policy-group]. It can be combined with both: time-based Color selection at the route level, time-based candidate-path selection within a Policy, and FC-based child selection within a Group. o Clean layering with existing headend behaviors: The time-based Color selection operates as the first step in the SR Policy selection chain at the headend. It is orthogonal to and does not conflict with other headend functions such as encapsulation behaviors (H.Encaps, H.Encaps.L2), Network Resource Partition (NRP), and Binding SID. The detailed interaction and precedence analysis is specified in the companion headend behavior specification. Appendix B. Component Documents This framework is accompanied by Standards Track documents that specify the normative details and supporting mechanisms. The following components require normative specification: o Headend behavior: The normative behavior of the ingress PE (headend) for time-based Color and SR Policy selection, including the schedule evaluation, Color selection rule, FIB update, switchover, and interaction with other headend mechanisms. (SPRING WG, Standards Track) o BGP encoding: The Schedule Extended Community encoding for BGP, including the daily schedule and absolute schedule sub-types and the ordering convention that associates a Schedule with the immediately preceding Color. (IDR WG, Standards Track) o YANG data model: The YANG data model for configuring (Color, Schedule) entries on the egress PE by augmenting the L3NM and L2NM service models. (OPSAWG WG, Standards Track) o Route-policy extension: A route-policy extension for expressing the (Color, Color Schedule) mapping, allowing the Color of VPN routes to be set based on scheduled time periods. This provides an alternative configuration paradigm to the YANG data model above. (RTGWG WG, Standards Track) o BGP-LS reporting: A BGP-LS extension for the ingress PE to report the time-scheduled Color switchover state (e.g., the currently active Color per VRF, switchover events, and statistics) to the controller for monitoring and OAM purposes. (IDR WG, Standards Track) Authors' Addresses Huang Expires March 15, 2027 [Page 13] Internet-Draft Time-Scheduled Color SR Policy Framework September 2026 Cancan Huang China Telecom Email: huangcanc@chinatelecom.cn Ke Ruan China Telecom Email: ruanke@chinatelecom.cn