SPRING Working Group C. Huang Internet-Draft W. Qu Updates: 9256 (if approved) China Telecom Intended status: Standards Track 15 September 2026 Expires: 15 March 2027 Headend Behavior for Time-Scheduled Color based SR Policy Selection draft-huang-spring-time-scheduled-color-behavior-00 Abstract This document specifies the normative behavior of the ingress Provider Edge (PE) router (headend) when selecting a Segment Routing (SR) Policy for VPN traffic based on time-scheduled Color values. In the time-scheduled Color mechanism, the egress PE advertises multiple (Color, Schedule) groups for the same VPN routes. The headend evaluates the schedule associated with each Color based on the current time, selects a currently valid Color, and steers the traffic into the corresponding SR Policy. This document defines the requirements for parsing the Color and Schedule Extended Communities, evaluating schedule validity, selecting among multiple valid Colors, performing schedule-boundary timer-based re-evaluation, handling switchover with make-before- break, and falling back when no Color is valid. This document updates RFC 9256 by replacing the multiple-Color selection rule specified in Section 8.4.1 with a Schedule-based selection rule. 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 18 March 2027. Huang & Qu Expires 15 March 2027 [Page 1] Internet-Draft Time-Scheduled Color Headend Behavior 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the Time-Scheduled Color Mechanism . . . . . . . 5 4. Headend Behavioral Requirements . . . . . . . . . . . . . . . 5 4.1. Parsing Color and Schedule Extended Communities . . . . . 5 4.2. Associating Schedule with Color . . . . . . . . . . . . . 6 4.3. Evaluating Schedule Validity . . . . . . . . . . . . . . 7 4.4. Selecting Among Multiple Valid Colors . . . . . . . . . . 8 4.5. SR Policy Lookup and Steering . . . . . . . . . . . . . . 9 4.6. Schedule-Boundary Timer and Re-Evaluation . . . . . . . . 9 4.7. Switchover with Make-Before-Break . . . . . . . . . . . . 10 4.8. Fallback When No Color Is Valid . . . . . . . . . . . . . 11 4.9. Backward Compatibility . . . . . . . . . . . . . . . . . 11 5. Time Source and Synchronization . . . . . . . . . . . . . . . 12 6. Operational Considerations . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Interaction with Other Mechanisms . . . . . . . . . 15 A.1. Interaction with Candidate-Path Level Scheduling . . . . 16 A.2. Interaction with SR Policy Group . . . . . . . . . . . . 16 A.3. Interaction with Other Headend Functions . . . . . . . . 17 A.4. Color Assignment Precedence Across Layers . . . . . . . . 17 A.5. Identifiers and Metrics: Orthogonality . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Huang & Qu Expires 15 March 2027 [Page 2] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 1. Introduction In Segment Routing (SR) based VPN services, the egress Provider Edge (PE) router attaches a BGP Color Extended Community [RFC9012] to advertised VPN routes. The ingress PE (headend) uses the Color value to select an SR Policy [RFC9256] for traffic steering. The framework for time-scheduled Color based SR Policy selection is described in [I-D.huang-spring-time-scheduled-color-framework]. In this mechanism, the egress PE advertises multiple (Color, Schedule) groups for the same VPN routes, allowing the headend to select different SR Policies (and thus different SLA intents) at different times. This document specifies the normative behavior of the headend when processing time-scheduled Colors. It covers: * Parsing the Color and Schedule Extended Communities. * Associating each Color with its corresponding Schedule. * Evaluating whether a Color is valid at the current time. * Selecting among multiple currently valid Colors. * Looking up the corresponding SR Policy and steering traffic. * Re-evaluating schedules on a schedule-boundary timer and switching the selected Color. * Handling switchover with make-before-break to avoid traffic loss. * Falling back when no Color is currently valid. * Maintaining backward compatibility with the existing static Color behavior. The encoding of the Schedule Extended Community and the YANG data model for configuring (Color, Schedule) entries on the egress PE are specified in separate companion documents. This document updates [RFC9256]. Section 8.4.1 of [RFC9256] specifies that when a BGP route carries multiple Color Extended Communities, the headend selects the SR Policy corresponding to the Color with the highest numerical value. This document replaces that selection rule with a Schedule-based selection: when multiple Color Extended Communities are each associated with a Schedule Extended Huang & Qu Expires 15 March 2027 [Page 3] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 Community, the headend selects the Color whose Schedule is valid at the current time. When a route carries a single Color Extended Community (with no associated Schedule), the behavior is unchanged from [RFC9256]. 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 * Color: A 32-bit value carried in the Color Extended Community [RFC9012] that identifies an SR Policy intent. * Schedule ID: A 1-octet identifier carried in the Color Extended Community and its associated Schedule Extended Communities, as defined in this document. Extended Communities sharing the same Schedule ID within a single BGP UPDATE message form a (Color, Schedule) group. The Schedule ID is locally significant to a single BGP UPDATE message. * 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]. * Schedule Extended Community: A BGP Extended Community defined in this document that describes the time period during which an associated Color is valid. * (Color, Schedule) Group: A Color Extended Community and its associated Schedule Extended Communities (Daily and/or Day) that share the same Schedule ID within a single BGP UPDATE message, as defined in this document. * Valid Color: A Color whose associated Schedule indicates that the Color is active at the current time, as defined in this document. A Color without an associated Schedule is always valid. * Headend: The ingress PE that receives VPN routes and selects an SR Policy based on the Color value, as defined in this document. Huang & Qu Expires 15 March 2027 [Page 4] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 3. Overview of the Time-Scheduled Color Mechanism In the time-scheduled Color mechanism, a VPN route may carry multiple Color Extended Communities, each associated with zero or more Schedule Extended Communities. The association between a Color Extended Community and its Schedule Extended Communities is established by a shared Schedule ID value. Each (Color, Schedule) group represents a candidate SR Policy that is valid during a specific time period. The headend processes the route as follows: 1. Parses all Color Extended Communities and Schedule Extended Communities from the BGP UPDATE and groups them by Schedule ID. 2. For each group, determines whether the Color is currently valid based on its associated Schedules (or always valid if no Schedule is present). 3. Selects one valid Color according to the selection rule defined in Section 4.4. 4. Looks up the SR Policy identified by (selected Color, Endpoint) and steers the traffic into it. 5. Sets a timer for the next schedule boundary and, when the timer fires, re-evaluates the validity of all Colors and switches the selected Color if it has changed. The following sections define each of these steps normatively. 4. Headend Behavioral Requirements 4.1. Parsing Color and Schedule Extended Communities The headend MUST parse all Extended Communities in the received BGP UPDATE. It MUST identify all Color Extended Communities (sub-type 0x0b of the Transitive Opaque Extended Community, as defined in [RFC9012]) and all Schedule Extended Communities (as defined in [I-D.huang-idr-color-time-schedule]). Huang & Qu Expires 15 March 2027 [Page 5] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 For each Color Extended Community and each Schedule Extended Community, the headend MUST extract the Schedule ID field. The Schedule ID is carried in the first octet of the former Flags field of the Color Extended Community and in the Schedule ID octet of each Schedule Extended Community, as defined in [I-D.huang-idr-color-time-schedule]. The headend MUST be able to handle a VPN route that carries: * Zero Color Extended Communities (no SR Policy steering; existing behavior). * One Color Extended Community with no associated Schedule (always valid; existing behavior). * One Color Extended Community with an associated Schedule (time- limited validity). * Multiple Color Extended Communities, each with an optional associated Schedule (time-based selection among multiple SR Policies). The headend MUST treat a malformed Schedule Extended Community as an absent Schedule. That is, the associated Color is considered always valid. The headend SHOULD log a warning when a malformed Schedule Extended Community is encountered. 4.2. Associating Schedule with Color The headend MUST associate each Schedule Extended Community with the Color Extended Community that carries the same Schedule ID within the same BGP UPDATE message. All Extended Communities sharing the same Schedule ID form a (Color, Schedule) group. If a Schedule Extended Community carries a Schedule ID for which no Color Extended Community with the same Schedule ID exists in the same UPDATE message, the headend MUST ignore the orphan Schedule Extended Community and SHOULD log a warning. If a Color Extended Community has no associated Schedule Extended Community (i.e., no Schedule Extended Community carries the same Schedule ID), the Color is always valid (no time restriction). The egress PE is responsible for assigning a unique Schedule ID to each (Color, Schedule) group within a given UPDATE, as specified in [I-D.huang-idr-color-time-schedule]. Huang & Qu Expires 15 March 2027 [Page 6] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 Multiple (Color, Schedule) groups MAY carry the same Color value but different Schedule IDs. In that case, the groups represent different valid time periods for the same Color (and thus the same SR Policy). The headend MUST treat such groups as a single logical Color entry: the Color is valid if ANY of the groups is currently valid (logical OR). Groups carrying the same Color value have equal priority; the selection rule in Section 4.4 operates on distinct Color values, not on groups. 4.3. Evaluating Schedule Validity For each (Color, Schedule) group, the headend MUST evaluate whether the Color is valid at the current time. The Schedule Extended Community encoding (defined in [I-D.huang-idr-color-time-schedule]) supports two sub-types: * Daily Schedule: A recurring daily time period defined by a start time (seconds since midnight) and a duration. The Color is valid during [start, start + duration) every day. If start + duration exceeds 86400 (the number of seconds in a day), the period wraps around midnight. * Day Schedule: A date (year, month, day) on which the schedule applies, with optional periodic recurrence (yearly, monthly, weekly, or daily). The Color is valid on the specified date(s). Optional recurrence may be specified. The headend MUST use the following rules to determine validity: 1. If the Color has no associated Schedule, the Color is always valid. 2. For a Daily Schedule, the headend MUST convert the current time (in UTC) to the number of seconds since midnight and check whether it falls within the interval [start, start + duration), with wrap-around at 86400. 3. For a Day Schedule without recurrence (P=0), the headend MUST check whether the current date (in UTC) matches the specified Year, Month, and Day. 4. For a Day Schedule with recurrence (P=1), the headend MUST check whether the current date matches any recurrence instance according to the F (Frequency) field and the Count field. Huang & Qu Expires 15 March 2027 [Page 7] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 5. If both a Daily Schedule and a Day Schedule are associated with the same Color, the Color is valid only when BOTH schedules are satisfied (logical AND). 6. If multiple (Color, Schedule) groups carry the same Color value, the Color is valid if ANY of those groups is currently valid (logical OR across groups). This allows time periods longer than 24 hours to be expressed by splitting them across multiple groups with the same Color value but non-overlapping schedules. All time and date values in the Schedule Extended Communities are expressed in UTC. The headend MUST use UTC when evaluating schedule validity. 4.4. Selecting Among Multiple Valid Colors If multiple Colors are currently valid, the headend MUST select one according to the following priority rule (from highest to lowest priority): 1. A Color without an associated Schedule (always valid) has the LOWEST priority. Such a Color acts as a default fallback. 2. Among Colors with associated Schedules that are currently valid, the headend MUST select the one whose Schedule has the highest "specificity". Specificity is defined as follows: a. A Day Schedule is more specific than a Daily Schedule. b. Among Day Schedules, a one-time schedule (P=0) is more specific than a recurring schedule (P=1); among recurring schedules, one with a smaller Count (fewer occurrences) is more specific. c. Among Daily Schedules, a schedule with a shorter duration is more specific. 3. If two valid Colors have Schedules of equal specificity, the headend MUST select the one with the numerically smaller Color value. The rationale for this priority rule is: * Always-valid Colors act as defaults and should only be used when no scheduled Color is valid. Huang & Qu Expires 15 March 2027 [Page 8] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 * More specific (narrower) schedules take precedence over broader ones, so that a special-case schedule (e.g., a holiday) overrides a general daily schedule. * The Color value tie-breaker ensures deterministic behavior. If a specific selection priority is desired (e.g., based on SLA priority rather than schedule specificity), the operator MAY configure an explicit Color priority on the headend. In that case, the configured priority takes precedence over the default rule above. 4.5. SR Policy Lookup and Steering After selecting a valid Color, the headend MUST look up the SR Policy identified by (selected Color, Endpoint), where Endpoint is the BGP next hop of the VPN route (or the egress PE address). If the SR Policy identified by (selected Color, Endpoint) exists and has a valid active candidate path, the headend MUST install a forwarding entry for the VPN route into the VRF forwarding table (FIB), pointing to that SR Policy. The VRF routing table is the control-plane table from which the VRF FIB (the data-plane table used for packet forwarding) is derived. The headend MUST steer the VPN traffic into that SR Policy via the installed FIB entry. If no SR Policy exists for (selected Color, Endpoint), the headend MUST apply the fallback behavior defined in Section 4.8. The headend MUST NOT install a FIB entry pointing to an SR Policy whose Color is not currently valid. 4.6. Schedule-Boundary Timer and Re-Evaluation To avoid the overhead of continuous polling, the headend MUST use a timer-driven approach to detect schedule boundaries. For each VPN route, the headend MUST compute the earliest future time at which the set of valid Colors for that route could change (i.e., the next schedule boundary across all (Color, Schedule) groups carried by the route). The headend MUST set a timer to fire at that time. When the timer fires, the headend MUST: 1. Re-evaluate the validity of all Colors for the route to determine the currently valid set. Huang & Qu Expires 15 March 2027 [Page 9] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 2. Apply the selection rule in Section 4.4 to determine the currently selected Color. 3. If the selected Color has changed, perform a switchover as described in Section 4.7. 4. Recompute the next schedule boundary and re-arm the timer. When a VPN route is updated (e.g., a BGP UPDATE carrying new or changed (Color, Schedule) groups is received), the headend MUST recompute the next schedule boundary and reset the timer for that route. The timer-driven re-evaluation is purely local to the headend and does not involve any BGP UPDATE exchange. Therefore, it does not cause any control-plane churn. As a safety net against timer drift or missed events (e.g., due to a transient time-source anomaly), the headend MAY also perform a periodic catch-up re-evaluation at a long interval (e.g., several minutes). This catch-up re-evaluation is OPTIONAL and MUST NOT be used as a substitute for the schedule-boundary timer. When used, its interval SHOULD be configurable. 4.7. Switchover with Make-Before-Break When the selected Color changes from Color_old to Color_new, the headend MUST perform a make-before-break switchover: 1. Ensure that the SR Policy for (Color_new, Endpoint) is instantiated and has a valid active candidate path. If the SR Policy is not yet instantiated, the headend MUST instantiate it before proceeding (e.g., by waiting for the controller to advertise it via BGP SR Policy SAFI [RFC9830] or PCEP, or by using a locally configured policy). 2. Once the SR Policy for (Color_new, Endpoint) is ready, update the VRF FIB entry for the route to point to the new SR Policy, so that new traffic is steered into the new SR Policy. 3. Allow in-flight traffic that was steered into the old SR Policy (Color_old) to drain naturally. The headend SHOULD keep the old SR Policy active for a configurable drain period (default: 10 seconds) before tearing it down. Huang & Qu Expires 15 March 2027 [Page 10] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 4. After the drain period, if the old SR Policy is no longer needed (i.e., no other VPN routes are using it), the headend MAY tear it down. The make-before-break mechanism ensures that there is no traffic loss during the switchover. The headend MUST NOT remove the old SR Policy before the new one is active and the drain period has elapsed. If the SR Policy for (Color_new, Endpoint) cannot be instantiated within a configurable timeout (default: 30 seconds), the headend MUST continue using the old SR Policy and SHOULD log an error. The headend SHOULD retry instantiating the new SR Policy periodically. 4.8. Fallback When No Color Is Valid If no Color is currently valid for a VPN route, the headend MUST apply one of the following fallback behaviors, in priority order: 1. If a Color without an associated Schedule exists among the (Color, Schedule) groups, the headend MUST use that Color. (This is the always-valid default Color.) 2. If no always-valid Color exists, the headend SHOULD use the last selected Color (the Color that was valid before the current gap). This is RECOMMENDED to avoid traffic loss. 3. If no last selected Color is available (e.g., the route was just received and no Color has ever been valid), the headend MUST drop the traffic for this route and SHOULD log a warning. The headend MUST set a timer for the next time at which a Color becomes valid and resume normal operation when the timer fires. 4.9. Backward Compatibility The time-scheduled Color mechanism is designed to be backward compatible: * If a VPN route carries a single Color Extended Community with no Schedule Extended Community, the headend MUST treat it exactly as in the existing behavior [RFC9012]: the Color is always valid and the headend selects the corresponding SR Policy. Huang & Qu Expires 15 March 2027 [Page 11] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 * If a headend does not support the Schedule Extended Community, it MUST ignore the Schedule Extended Communities and process the Color Extended Communities as in the existing behavior. In this case, if multiple Color Extended Communities are present, the headend MAY select any one of them (e.g., the first one). * An egress PE that does not support the time-scheduled Color mechanism simply does not attach Schedule Extended Communities, and the existing behavior is preserved. 5. Time Source and Synchronization The headend relies on an accurate time source to evaluate schedule validity. The headend MUST use a synchronized time source, such as NTP [RFC5905] or PTP [IEEE1588], with a maximum offset of 1 second from UTC. If the headend's time source is not synchronized (e.g., the NTP server is unreachable), the headend SHOULD continue operating using the local clock and SHOULD log a warning. The headend MUST NOT disable time-based Color selection solely due to loss of time synchronization. All time and date values in the Schedule Extended Communities are expressed in UTC. The headend MUST use UTC when evaluating schedule validity. 6. Operational Considerations * Catch-up re-evaluation interval: If the optional periodic catch- up re-evaluation is enabled (see Section 4.6), its interval SHOULD be set long enough to avoid unnecessary CPU usage (e.g., several minutes). The catch-up re-evaluation is a safety net only and does not affect the precision of switchover timing, which is governed by the schedule-boundary timer. * Drain period: The drain period for make-before-break (default 10 seconds) SHOULD be set based on the maximum expected in-flight packet lifetime. A value that is too short may cause packet loss; a value that is too long may delay resource reclamation. * Time synchronization: All PEs in the network SHOULD be time- synchronized to within 1 second to ensure consistent schedule evaluation across the network. Huang & Qu Expires 15 March 2027 [Page 12] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 * Schedule overlap: Operators SHOULD avoid configuring overlapping schedules with different Colors unless they intentionally want the specificity-based selection rule to apply. Overlapping schedules may lead to unexpected Color selection. * Color allocation: Operators SHOULD allocate Color values consistently across the network. The same Color value SHOULD represent the same SLA intent everywhere. * Monitoring: The headend SHOULD provide management visibility into the currently selected Color per VPN route, the validity status of each Color, and the switchover history. This facilitates troubleshooting and SLA verification. 7. Security Considerations The time-scheduled Color mechanism does not introduce new security vulnerabilities beyond those already present in 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. An attacker who can forge or modify Schedule Extended Communities could cause the headend to select an incorrect SR Policy, leading to SLA violations. This is mitigated by BGP session security mechanisms and route validation (e.g., RPKI, BGPsec). A denial-of-service attack involving many (Color, Schedule) groups on a single route could increase the headend's processing load. The headend SHOULD implement rate limiting and resource limits on the number of (Color, Schedule) groups per route and the total number of VPN routes. 8. IANA Considerations This document has no IANA actions. IANA considerations for the Schedule Extended Community are addressed in [I-D.huang-idr-color-time-schedule]. IANA considerations for the YANG modules are addressed in [I-D.huang-opsawg-vpn-color-schedule-yang]. 9. References 9.1. Normative References Huang & Qu Expires 15 March 2027 [Page 13] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 [I-D.huang-idr-color-time-schedule] Huang, C., "BGP Extension for Time-Scheduled Color based SR Policy Selection", Work in Progress, Internet-Draft, draft-huang-idr-color-time-schedule, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [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, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, . [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, . 9.2. Informative References [I-D.huang-opsawg-vpn-color-schedule-yang] Huang, C., "YANG Data Model for Time-Scheduled Color in LxVPN", Work in Progress, Internet-Draft, draft-huang- opsawg-vpn-color-schedule-yang, 2026, . Huang & Qu Expires 18 March 2027 [Page 14] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 [I-D.huang-spring-time-scheduled-color-framework] Huang, C., "Framework for Time-Scheduled Color based SR Policy Selection", Work in Progress, Internet-Draft, draft-huang-spring-time-scheduled-color-framework, 2026, . [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, . [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588-2008, 2008. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . Appendix A. Interaction with Other Mechanisms The time-scheduled Color mechanism operates at the headend as the first step in the SR Policy selection chain. This appendix describes its interaction with other headend mechanisms and addresses the concerns about headend behavior ordering and precedence raised in the SPRING WG (e.g., the IDR chair's questions at IETF 125 regarding interactions between identifiers, metrics, Color assignment layers, and header functions such as NRP and encapsulation behaviors). The overall ordering of headend functions is: 1. Time-based Color selection (this document): select the SR Policy identified by (Color, Endpoint). 2. SR Policy Group child selection [I-D.ietf-spring-sr-policy-group] (if applicable): select a child SR Policy within the Group. Huang & Qu Expires 18 March 2027 [Page 15] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 3. Candidate-path level scheduling [I-D.zzd-idr-sr-policy- scheduling] (if applicable): select the active candidate path within the SR Policy. 4. Encapsulation and other header functions (H.Encaps, H.Encaps.L2, NRP, etc.): apply to the selected SR Policy. Each step consumes the output of the previous step, so there is no competition or conflict between them. A.1. Interaction with Candidate-Path Level Scheduling The candidate-path and segment-list level scheduling defined in [I- D.zzd-idr-sr-policy-scheduling] operates within a single SR Policy. The time-scheduled Color mechanism operates at the Color (SR Policy) level. The two mechanisms are independent and can be combined: 1. The headend first applies the time-scheduled Color mechanism to select the SR Policy (Color) based on the current time. 2. Within the selected SR Policy, the headend then applies the candidate-path level scheduling [I-D.zzd-idr-sr-policy- scheduling] to select the active candidate path or segment list based on the current time. The headend MUST NOT let the candidate-path level scheduling affect the Color selection. The Color selection (this document) and the candidate-path selection [I-D.zzd-idr-sr-policy-scheduling] are independent steps. A.2. Interaction with SR Policy Group The SR Policy Group mechanism [I-D.ietf-spring-sr-policy-group] allows a parent SR Policy to contain multiple child SR Policies. The time-scheduled Color mechanism and SR Policy Group are independent and can be combined: 1. The headend first applies the time-scheduled Color mechanism to select the parent SR Policy (Color) based on the current time. 2. Within the selected SR Policy Group, the headend then applies the SR Policy Group's child selection mechanism (e.g., based on Forwarding Class) to select a child SR Policy. The headend MUST NOT let the SR Policy Group's child selection affect the Color selection. The Color selection (this document) and the child selection [I-D.ietf-spring-sr-policy-group] are independent steps. Huang & Qu Expires 18 March 2027 [Page 16] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 A.3. Interaction with Other Headend Functions The time-scheduled Color mechanism is orthogonal to the following headend functions, which operate on the SR Policy selected by the Color mechanism: * Encapsulation behaviors (H.Encaps, H.Encaps.Red): These determine how the headend encapsulates packets into the selected SR Policy. The Color mechanism selects WHICH SR Policy to use; the encapsulation behavior is then applied to that policy. The two are independent and do not interact. * L2 encapsulation behaviors (H.Encaps.L2, H.Encaps.L2.Red): Same as above for L2VPN services. The Color mechanism applies uniformly to L3VPN and L2VPN; the encapsulation type is a property of the selected SR Policy, not of the Color selection. * Network Resource Partition (NRP): NRP is a property of the SR Policy or its segment lists. Once the Color mechanism selects an SR Policy, the NRP associated with that policy applies. The Color mechanism does not modify or override NRP. * Binding SID: The Binding SID of the selected SR Policy is used for steering. The Color mechanism does not affect Binding SID assignment or resolution. In all cases, the time-scheduled Color mechanism operates at a higher layer (SR Policy selection) and does not interfere with the lower- layer functions that operate on the selected SR Policy. A.4. Color Assignment Precedence Across Layers The Color value can appear at multiple layers in the BGP SR Policy ecosystem: * Color Extended Community [RFC9012]: carried on the VPN route, expressing the egress-side SLA intent. The headend uses this Color to select an SR Policy. * Policy-Color field in the BGP SR Policy SAFI NLRI [RFC9830]: carried in the SR Policy advertisement, identifying the SR Policy being distributed. * Color in candidate-path or segment-list sub-structures: optional finer-grained identification within an SR Policy. Huang & Qu Expires 18 March 2027 [Page 17] Internet-Draft Time-Scheduled Color Headend Behavior September 2026 In the time-scheduled Color mechanism, the Color Extended Community on the VPN route is the SELECTOR: the headend looks up the SR Policy whose Policy-Color field matches the selected Color Extended Community value. There is no precedence competition between these layers because they serve different roles: the Color Extended Community selects, and the Policy-Color field identifies. When a VPN route carries multiple Color Extended Communities (each with an optional Schedule), the headend applies the selection rule in Section 4.4 to choose one Color. This selection rule operates ONLY among the Color Extended Communities on the same route and does not affect the Policy-Color field of any SR Policy. Therefore, there is no cross-layer Color precedence conflict. The only precedence rule introduced by this document is among multiple Color Extended Communities on the same VPN route, as defined in Section 4.4. A.5. Identifiers and Metrics: Orthogonality The time-scheduled Color mechanism does not introduce new segment list identifiers or metrics. * Identifiers: Segment list identifiers (e.g., Binding SID, Path Segment Identifier) are properties of the SR Policy's candidate paths and segment lists, managed by [RFC9256]. The Color mechanism selects an SR Policy and does not create or modify segment list identifiers. The only identifier-level precedence introduced by this document is among multiple Color Extended Communities on the same route (Section 4.4). * Metrics: TE metrics, IGP metrics, and other path metrics are used by the SR Policy candidate path selection process [RFC9256]. The Color mechanism selects the SR Policy based on time, and the metric-based candidate path selection then operates within the selected policy. The two are independent: the Color mechanism does not read or modify any metric. Authors' Addresses Cancan Huang China Telecom Email: huangcanc@chinatelecom.cn Wenkuan Qu China Telecom Email: quwk@chinatelecom.cn Huang & Qu Expires 18 March 2027 [Page 18]