Network Working Group C. Huang Internet-Draft Z. Huang Updates: 9012 (if approved) China Telecom Intended status: Standards Track 15 September 2026 Expires: 15 March 2027 BGP Extension for Time-Scheduled Color based SR Policy Selection draft-huang-idr-color-time-schedule-00 Abstract Segment Routing (SR) Policy is identified by a tuple of Color and Endpoint. In BGP/MPLS IP VPN and EVPN services, the egress PE attaches a Color Extended Community to the advertised VPN route so that the ingress PE can steer the traffic into a corresponding SR Policy. In many deployment scenarios, the same customer may require different Service Level Agreements (SLAs) during different time periods of a day. For example, a customer may require a high- bandwidth SLA during the off-peak hours (e.g., 02:00-06:00) and a low-cost SLA during the daytime. Such time-variant SLA requirements imply that the ingress PE should select different SR Policies (i.e., different Colors) for the same VPN route at different times. This document defines a new BGP Extended Community, called the Schedule Extended Community, to be used together with the Color Extended Community. Two sub-types of the Schedule Extended Community are defined: a Daily Schedule sub-type for recurring time-of-day periods, and a Day Schedule sub-type for specific dates. The Schedule Extended Community carries the time period during which the associated Color is valid. Based on the current time and the received Schedule Extended Communities, the ingress PE can dynamically select the appropriate SR Policy for a VPN route, thereby realizing time-scheduled SLA switching. 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/. Huang & Huang Expires 15 March 2027 [Page 1] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 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. 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Schedule Extended Community . . . . . . . . . . . . . . . . . 5 4.1. Color Extended Community and Schedule ID . . . . . . . . 6 4.2. Daily Schedule Sub-Type . . . . . . . . . . . . . . . . . 7 4.3. Day Schedule Sub-Type . . . . . . . . . . . . . . . . . . 8 4.4. Combining Daily and Day Schedules . . . . . . . . . . . . 11 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. PE Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Schedule ID Scope and Propagation . . . . . . . . . . . . 13 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 7. Manageability Considerations . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Huang & Huang Expires 15 March 2027 [Page 2] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 1. Introduction Segment Routing (SR) Policy [RFC9256] enables instantiation of an ordered list of segments with a specific intent for traffic steering. An SR Policy is identified by a tuple of Color and Endpoint. The Color represents an intent (e.g., low latency, high bandwidth) and the Endpoint is the destination of the SR Policy. In BGP/MPLS IP VPN [RFC4364] and EVPN [RFC7432] services, the egress Provider Edge (PE) router advertises VPN routes with a Color Extended Community [RFC9012]. The ingress PE uses the Color value carried in the VPN route to select a matching SR Policy for traffic steering. This mechanism is well-defined in [RFC9256] and [RFC9012]. However, the current Color-based steering mechanism is static in nature: a VPN route is associated with a single Color value, and the ingress PE always selects the SR Policy corresponding to that Color regardless of the time of day. This cannot satisfy time- variant SLA requirements where the same VPN route needs to be steered into different SR Policies (i.e., different Colors) at different time periods. The overall framework for time-scheduled Color based SR Policy selection, including the problem statement, use cases, the limitation of existing mechanisms, and the solution overview, is described in [I-D.huang-spring-time-scheduled-color-framework]. This document specifies the BGP encoding extensions that realize the framework, namely a new Schedule Extended Community that works together with the Color Extended Community. The Schedule Extended Community indicates the time period during which the associated Color is valid. By advertising multiple Color Extended Communities, each accompanied by a corresponding Schedule Extended Community, the egress PE can express time-variant SLA requirements for a VPN route. The ingress PE then selects the currently valid Color and steers traffic into the corresponding SR Policy. This document updates [RFC9012] by defining the use of the Flags field in the Color Extended Community for a Schedule Identifier (Schedule ID). The Schedule ID is used to associate a Color Extended Community with its corresponding Schedule Extended Communities within the same BGP UPDATE message. Huang & Huang Expires 15 March 2027 [Page 3] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 2. Terminology 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. Color: A 4-octet value carried in the Color Extended Community that identifies the intent of an SR Policy, as defined in [RFC9012]. 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) pair. SR Policy: A set of Candidate Paths identified by a (Color, Endpoint) tuple, as defined in [RFC9256]. Schedule Extended Community: A BGP Extended Community defined in this document that carries the time period during which an associated Color is valid. Valid Color: A Color whose associated Schedule Extended Community indicates that the Color is active at the current time, as defined in this document. A Color without an associated Schedule Extended Community is always valid. 3. Use Case Consider a network operator that offers VPN services to a customer. The customer has different SLA requirements at different times of the day: * Nighttime (02:00-06:00): The customer requires a high- bandwidth, low-latency SLA (SLA A). * Daytime (06:00-02:00 next day): The customer requires a lower-cost SLA (SLA B) that tolerates higher latency but is cheaper. Huang & Huang Expires 15 March 2027 [Page 4] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 To satisfy these requirements, the operator deploys two SR Policies towards the same endpoint: * SR Policy P_A: Color = 100, providing SLA A. * SR Policy P_B: Color = 200, providing SLA B. The egress PE needs to advertise the customer's VPN routes such that the ingress PE steers traffic into P_A during nighttime and into P_B during daytime. The limitation of existing mechanisms in addressing this use case, the comparison with other approaches, and the detailed solution design are described in [I-D.huang-spring-time-scheduled-color-framework]. This document specifies only the BGP Extended Community encoding that enables time- scheduled Color selection. 4. Schedule Extended Community This document defines a new BGP Extended Community, the Schedule Extended Community. Two 8-octet sub-types are defined: * Daily Schedule (Section 4.2): An 8-octet Extended Community that expresses a time-of-day period (start time and duration) that recurs every day. This is the primary sub-type for the time- variant SLA use case. * Day Schedule (Section 4.3): An 8-octet Extended Community that expresses a date (year, month, day) on which the schedule applies. This supports one-time events (e.g., a maintenance window) and periodically recurring dates. Both sub-types use the standard 8-octet Extended Community format defined in [RFC4360]. All time values in the Schedule Extended Communities are expressed in Coordinated Universal Time (UTC). Time zone normalization is performed by the egress PE before encoding, as described in a separate companion document. The Schedule Extended Community is a Transitive Extended Community so that it can be propagated across AS boundaries in inter-AS VPN deployments. The High-order octet of the Type field is 0x03 (Transitive Opaque Extended Community). Huang & Huang Expires 15 March 2027 [Page 5] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 The association between a Schedule Extended Community and a Color Extended Community is established by a shared Schedule ID value carried in both communities. All Extended Communities carrying the same Schedule ID within a single BGP UPDATE message form a (Color, Schedule) pair. The order of appearance of Extended Communities in the UPDATE message has no significance for this association. The Schedule ID is a 1-octet value that is locally significant to a single BGP UPDATE message. The egress PE assigns a unique Schedule ID to each (Color, Schedule) pair within a given UPDATE. The same Schedule ID value MAY be reused in different UPDATE messages. A Color Extended Community without any associated Schedule Extended Community (i.e., no Schedule Extended Community carrying the same Schedule ID exists in the UPDATE) is always valid. 4.1. Color Extended Community and Schedule ID [RFC9012] defines the Color Extended Community as a Transitive Opaque Extended Community (Type 0x03, Sub-Type 0x0b) with a 2- octet Flags field followed by a 4-octet Color Value. [RFC9012] specifies that the Flags field MUST be set to 0. This document updates [RFC9012] by redefining the Flags field of the Color Extended Community to carry a Schedule Identifier (Schedule ID). The first octet of the Flags field carries the Schedule ID; the second octet is reserved and MUST be set to 0. The modified encoding is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x03) |Sub-Type(0x0b) | Schedule ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color Value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Color Extended Community Fields: Type: 0x03 (Transitive Opaque Extended Community). Sub-Type: 0x0b (Color Extended Community) [RFC9012]. Schedule ID (1 octet): Identifies the (Color, Schedule) pair. Huang & Huang Expires 15 March 2027 [Page 6] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 All Extended Communities carrying the same Schedule ID within a single BGP UPDATE message belong to the same pair. A Color Extended Community with a Schedule ID that has no associated Schedule Extended Community in the same UPDATE is always valid (backward compatible with [RFC9012]). Reserved (1 octet): MUST be set to 0 on transmission and MUST be ignored on receipt. Color Value (4 octets): The Color value as defined in [RFC9012]. 4.2. Daily Schedule Sub-Type The Daily Schedule Extended Community is an 8-octet Transitive Extended Community. The encoding is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x03) |Sub-Type (TBD1)| Schedule ID | Start Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time | Octet 5 | Duration | Octet 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Daily Schedule EC The Start Time and Duration fields are too large to fit in whole octets (each requires 17 bits to cover the range 0 to 86400). They are bit-packed into octets 3 through 7 as follows (bit 0 is the most significant bit of octet 3): * Octet 3: Start Time bits 16-9 (high 8 bits). * Octet 4: Start Time bits 8-1. * Octet 5: Start Time bit 0 (1 bit, MSB) followed by Duration bits 16-10 (7 bits). See Figure 2a. * Octet 6: Duration bits 9-2. * Octet 7: Duration bits 1-0 (2 bits, MSBs) followed by the Reserved field (6 bits). See Figure 2b. Huang & Huang Expires 15 March 2027 [Page 7] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |ST0| Duration | | Duration| Res | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Figure 3: Octet 5 layout Figure 2b: Octet 7 layout Fields: Type: 0x03 (Transitive Opaque Extended Community). Sub-Type: TBD1. To be assigned by IANA from the "BGP Extended Community Sub-Types" registry. Schedule ID (1 octet): Identifies the (Color, Schedule) pair. this Daily Schedule belongs to. It MUST match the Schedule ID carried in the associated Color Extended Community. Start Time (17 bits): The start time of the valid period, expressed as the number of seconds since 00:00 (midnight) UTC. The valid range is 0 to 86399. Values outside this range are invalid. Duration (17 bits): The duration of the valid period in seconds. The valid range is 1 to 86400 (inclusive). A Duration of 0 is invalid. A Duration of 86400 means the Color is valid for the entire day. Reserved (6 bits): MUST be set to 0 on transmission and MUST be ignored on receipt. If Start Time + Duration exceeds 86400 seconds, the valid period wraps around midnight. For example, Start Time = 72000 (20:00 UTC) and Duration = 28800 (8 hours) means the Color is valid from 20:00 UTC to 04:00 UTC the next day. 4.3. Day Schedule Sub-Type The Day Schedule Extended Community is an 8-octet Transitive Extended Community. It expresses the date(s) on which the schedule applies, supporting one-time and periodically recurring dates, including date ranges with a daily recurrence. The encoding is as follows: Huang & Huang Expires 15 March 2027 [Page 8] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x03) |Sub-Type(TBD2) | Schedule ID | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Year (2 octets) | Month | Day | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Day Schedule EC The Month, Day, and Count fields are packed into the last two octets of the Extended Community, with the following bit layout (bit 0 is the most significant bit): 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Month | Day | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 0x03 (Transitive Opaque Extended Community). Sub-Type: TBD2. To be assigned by IANA from the "BGP Extended Community Sub-Types" registry. Schedule ID (1 octet): Identifies the (Color, Schedule) pair. this Day Schedule belongs to. It MUST match the Schedule ID carried in the associated Color Extended Community. Flags (1 octet): The Flags field is formatted as follows, with bit 0 being the most significant bit: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | P | F | Reserved | +---+---+---+---+---+---+---+---+ P (Periodic) (1 bit): If set to 0, the schedule applies only once on the specified date. If set to 1, the schedule repeats according to the F (Frequency) field, for the number of occurrences specified by the Count field. Huang & Huang Expires 15 March 2027 [Page 9] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 F (Frequency) (2 bits): Specifies the recurrence unit. Valid only when P=1; ignored when P=0. 00: Yearly. The schedule repeats every year on the specified Month and Day. 01: Monthly. The schedule repeats every month on the specified Day. 10: Weekly. The schedule repeats every week on the weekday specified by the Day field. 11: Daily. The schedule repeats every day. Reserved (5 bits): MUST be set to 0 on transmission and MUST be ignored on receipt. Year (2 octets): The year (e.g., 2026). When P=1, this field MAY be set to 0 to indicate that the schedule is not constrained to a specific starting year (e.g., "every year on November 15"). Month (4 bits): The month (1 to 12). When P=1 and the recurrence is monthly or finer (F >= 01), this field MAY be set to 0 to indicate "any month". Day (5 bits): Interpretation depends on the F field: When P=0, or P=1 and F=00 (yearly) or F=01 (monthly): The day of the month (1 to 31). When P=1 and F=10 (weekly): The day of the week, where 1 = Monday, 2 = Tuesday, ..., 7 = Sunday. When P=1 and F=11 (daily): Reserved; MUST be set to 0 on transmission and ignored on receipt. Count (7 bits): The number of occurrences. When P=0 (one-time): This field MUST be set to 0 and is ignored on receipt. When P=1 (recurring): A value of 0 indicates an unlimited number Huang & Huang Expires 15 March 2027 [Page 10] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 of occurrences (the schedule repeats indefinitely). A non-zero value specifies the total number of occurrences, starting from the date specified by Year, Month, and Day. The maximum value is 127. Examples: o One-time on 2026-11-15: P=0, Year=2026, Month=11, Day=15, Count=0. o Every year on November 15 (indefinitely): P=1, F=00, Year=0, Month=11, Day=15, Count=0. o Every month on the 15th (indefinitely): P=1, F=01, Year=0, Month=0, Day=15, Count=0. o Every Tuesday (indefinitely): P=1, F=10, Day=2 (Tuesday), Count=0. o Every Tuesday for 4 weeks: P=1, F=10, Day=2 (Tuesday), Count=4. o Daily from 2026-10-01 through 2026-11-01 (32 days): P=1, F=11, Year=2026, Month=10, Day=1, Count=32. 4.4. Combining Daily and Day Schedules A Color Extended Community MAY be associated with a Daily Schedule, a Day Schedule, or both. The association is established by a shared Schedule ID. The validity of the Color is determined by the logical AND of all associated schedule constraints: * Daily Schedule only: The Color is valid at the specified time-of- day period every day. * Day Schedule only: The Color is valid for the entire day (all 24 hours) on the specified date(s). * Daily Schedule + Day Schedule: The Color is valid only at the specified time-of-day period on the specified date(s). When both sub-types are used for the same Color, the Daily Schedule and Day Schedule MUST carry the same Schedule ID as the associated Color Extended Community. The order of appearance of the Extended Communities in the UPDATE message has no significance. When a Daily Schedule and a Day Schedule are combined and the Daily Schedule's valid period wraps around midnight (i.e., Start Time + Duration > 86400, as described in Section 4.2), the Day Schedule Huang & Huang Expires 15 March 2027 [Page 11] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 matches only the start date of the Daily Schedule. The portion of the valid period that extends past midnight into the next day remains valid even if the next day does not satisfy the Day Schedule constraint. For example, a Daily Schedule of 20:00-04:00 (Start=72000, Duration=28800) combined with a Day Schedule of 2026-11-15 (one-time) makes the Color valid from 2026-11-15 20:00 UTC to 2026-11-16 04:00 UTC. The Day Schedule does not need to match 2026-11-16. 5. Operations This section provides a brief summary of the operations. The detailed behavioral specification, including the exact ingress PE selection algorithm, precedence rules, and edge-case handling, is described in separate companion documents. 5.1. PE Behavior At the egress PE, one or more (Color, Schedule) pairs are attached to the VPN route advertisement. Each pair consists of a Color Extended Community and one or more Schedule Extended Communities sharing the same Schedule ID. The egress PE assigns a unique Schedule ID to each pair within the BGP UPDATE message. Multiple pairs MAY carry the same Color value with different Schedule IDs to express a valid period longer than 24 hours; such pairs are combined with a logical OR at the ingress PE. At the ingress PE, the received Color and Schedule Extended Communities are grouped by Schedule ID. For each pair, the ingress PE evaluates whether the Color is currently valid based on the current UTC time and the associated Schedule Extended Communities. A Color without any associated Schedule Extended Community is always valid. The ingress PE selects one valid Color for traffic steering and steers traffic into the matching SR Policy. If no Color is valid, the ingress PE falls back to best-effort forwarding as defined in [RFC9256]. The ingress PE re-evaluates Color validity at schedule boundaries and uses a make-before-break mechanism when switching from one SR Policy to another. All PEs SHOULD be synchronized using NTP [RFC5905] or PTP [IEEE-1588]. All time values in Schedule Extended Communities are expressed in UTC. If a PE's clock is out of synchronization, the time-scheduled Color selection behavior is undefined and the PE SHOULD log an alarm. Huang & Huang Expires 15 March 2027 [Page 12] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 5.2. Schedule ID Scope and Propagation The Schedule ID is locally significant to a single BGP UPDATE message. Intermediate BGP speakers (e.g., Route Reflectors, ASBRs) forward the Extended Communities attribute transparently and do not need to preserve or interpret the Schedule ID. Route Aggregation: The association between a Color Extended Community and its Schedule Extended Communities is established by the Schedule ID within a single route. When BGP route aggregation merges multiple routes into one, the Extended Communities of the contributing routes are typically combined (e.g., via union). This mixes Schedule IDs that were locally significant to different routes, destroying the per-route (Color, Schedule) association and resulting in ambiguous or incorrect behavior at the ingress PE. In practice, route aggregation is most commonly applied to underlay routes (e.g., loopbacks and locators) for scaling purposes. VPN routes (SAFI 128) and EVPN routes are typically not aggregated due to their fine-grained prefix granularity and the use of per-route Route Distinguishers. However, aggregation of VPN routes may occur in certain scenarios (e.g., inter-AS gateway PE re-origination of Inter- Subnet Forwarding routes). Therefore, routes carrying Schedule Extended Communities MUST NOT be aggregated. If aggregation is unavoidable, all Schedule Extended Communities and the Schedule ID field in the associated Color Extended Communities MUST be removed before the aggregate route is advertised. This is consistent with the principle that the aggregation handling of a specific Extended Community type is governed by the specification of that type. Route Re-origination and Inter-Domain Forwarding: When a route carrying Schedule Extended Communities is re-originated (e.g., at a Gateway PE between different domains), the re-originating speaker MUST assign a new Schedule ID within the new UPDATE message and copy the schedule content (start time, duration, date, etc.) verbatim. The Color value MAY be translated according to local policy if the Color space differs between domains. Route Policy Modification: Local route policies that remove Extended Communities may leave a Schedule Extended Community without a matching Color Extended Community (or vice versa). Such orphan communities are ignored as described in Section 6. Operators SHOULD review route policies along the path to ensure they do not break (Color, Schedule) pairs. Huang & Huang Expires 15 March 2027 [Page 13] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 6. Error Handling The following conditions are considered malformed, and the associated Extended Community MUST be ignored: * 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. * A Color Extended Community has the Reserved octet (the second octet of the former Flags field, see Section 4.1) set to a non- zero value. * For the Daily Schedule sub-type: - The Start Time is greater than 86399. - The Duration is 0 or greater than 86400. - The Reserved bits are non-zero. * For the Day Schedule sub-type: - The Month field is greater than 12. - For F=00 (yearly): The Month field is 0. - For P=0, or F=00 (yearly) or F=01 (monthly): The Day field is 0 or greater than 31. - For F=10 (weekly): The Day field is 0 or greater than 7. - For F=11 (daily): The Day field is non-zero. - The Reserved bits in the Flags field are non-zero. - The Count field is non-zero when P=0. If a Schedule Extended Community is ignored due to being malformed, the associated Color Extended Community is treated as if it had no associated Schedule Extended Community (i.e., it is always valid). A Color Extended Community whose Schedule ID has no associated Schedule Extended Community is always valid. This is not an error condition. Huang & Huang Expires 15 March 2027 [Page 14] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 If all Schedule Extended Communities in a route are ignored, the route is processed using only the Color Extended Communities, with all Colors being always valid. 7. Manageability Considerations The mechanism defined in this document has the following manageability implications: * Operators need to be able to configure, on the egress PE, the mapping between Colors and their valid time periods. This can be achieved via CLI, NETCONF [RFC6241], or a controller. A YANG data model for this configuration is out of scope of this document and may be defined in a separate document. * The ingress PE SHOULD expose operational state indicating, for each VPN route, which Color is currently selected and which SR Policy is being used. This facilitates troubleshooting. * The ingress PE SHOULD provide counters or statistics for the number of times a Color switch occurs and the times at which switches happen. * Operators SHOULD be aware that time-scheduled Color selection introduces a time-dependent behavior into the forwarding plane. Debugging tools (e.g., traceroute, ping) may produce different results at different times of the day. 8. Security Considerations The TBD (this document) introduces a new BGP Extended Community. The security considerations of [RFC9012] and [RFC4271] apply. The following additional security considerations are specific to this mechanism: * A malicious or misconfigured egress PE could advertise Color/ Schedule pairs that cause the ingress PE to select an SR Policy that does not meet the intended SLA. The egress advertisement is the primary mechanism because the customer's SLA requirements are known at the egress PE and the same schedule needs to be applied consistently across all ingress PEs that serve the customer; configuring each ingress PE individually does not scale. As an additional safeguard, the ingress PE MAY apply local policy to validate or override the received schedules based on the VPN, the customer, or the endpoint. Huang & Huang Expires 15 March 2027 [Page 15] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 * The time-based selection behavior could be exploited to cause traffic to be steered into a less secure path at a specific time. Operators SHOULD ensure that all SR Policies that may be selected meet the required security level, or SHOULD use local policy to restrict which Colors can be selected. * Clock manipulation (e.g., through NTP spoofing) could alter the time-scheduled selection. Operators SHOULD use authenticated NTP (RFC 5905, Section 5.12.1.3) or PTP with security extensions. * The Schedule Extended Community is transitive and crosses AS boundaries in inter-domain scenarios. The schedule is interpreted in the same time zone (UTC by default) regardless of the AS in which the PEs reside. Even though the EC is transitive, the route carrying it MUST NOT be aggregated, as specified in Section 5.2. 9. IANA Considerations This document defines two new BGP Extended Community sub-types. IANA is requested to assign the following values from the "BGP Extended Community Sub-Types" registry: * TBD1: Schedule Extended Community - Daily Schedule sub-type. * TBD2: Schedule Extended Community - Day Schedule sub-type. The allocation policy for the registry is "First Come First Served" as defined in [RFC7120]. This document also updates [RFC9012] by redefining the Flags field of the Color Extended Community. IANA is requested to update the "Color Extended Community Flags" field definition in the "BGP Extended Community Sub-Types" registry (or the applicable registry) to reflect that the first octet of the Flags field carries the Schedule ID and the second octet is reserved. Because this modifies a Standards Track RFC, the allocation requires "Standards Action" as defined in [RFC8126]. 10. References 10.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, . Huang & Huang Expires 18 March 2027 [Page 16] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 [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, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [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, . 10.2. Informative References [I-D.huang-spring-time-scheduled-color-behavior] Huang, C. and W. Qu, "Headend Behavior for Time-Scheduled Color based SR Policy Selection", Work in Progress, Internet-Draft, draft-huang-spring-time-scheduled-color- behavior-08, 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-19, September 2026, . Huang & Huang Expires 18 March 2027 [Page 17] Internet-Draft BGP Extension for Time-Scheduled Color b September 2026 [IEEE-1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588-2019, November 2019. [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, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . Authors' Addresses Cancan Huang China Telecom China Email:huangcanc@chinatelecom.cn Zhuojun Huang China Telecom China Email:huangzhuoj@chinatelecom.cn Huang & Huang Expires 18 March 2027 [Page 18]