Headend Behavior for Time-Scheduled Color based SR Policy Selection
draft-huang-spring-time-scheduled-color-behavior-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Cancan Huang , Wenkuan Qu | ||
| Last updated | 2026-09-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huang-spring-time-scheduled-color-behavior-00
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,
<https://datatracker.ietf.org/doc/html/draft-huang-idr-
color-time-schedule>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc9012>.
[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,
<https://www.rfc-editor.org/info/rfc9256>.
[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,
<https://www.rfc-editor.org/info/rfc9830>.
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,
<https://datatracker.ietf.org/doc/html/draft-huang-opsawg-
vpn-color-schedule-yang>.
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,
<https://datatracker.ietf.org/doc/html/draft-huang-spring-
time-scheduled-color-framework>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-group>.
[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, <https://datatracker.ietf.org/doc/html/
draft-zzd-idr-sr-policy-scheduling>.
[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,
<https://www.rfc-editor.org/info/rfc5905>.
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]