TVR L. M. Contreras Internet-Draft Telefonica Intended status: Informational 23 June 2026 Expires: 25 December 2026 Lifecycle and State Extensions for TVR Schedule YANG Model draft-contreras-tvr-schedule-lifecycle-yang-00 Abstract The Time-Variant Routing (TVR) YANG data model [I-D.ietf-tvr-schedule-yang] defines a mechanism to describe scheduled changes in network resources (such as nodes and topology) as a function of time. However, the base model does not provide explicit lifecycle management semantics for the schedules, such as activation, suspension, or deprecation. This document defines an optional augmentation of the base YANG model to introduce lifecycle and administrative state control, enabling more flexible operational handling of schedules without modifying the base model semantics. 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 25 December 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. Contreras Expires 25 December 2026 [Page 1] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Operational Situations for Lifecycle Control: . . . . . . 3 3.2. Aligment with the TVR YANG Model . . . . . . . . . . . . 4 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Administrative states . . . . . . . . . . . . . . . . . . 5 4.2. Additional parameters . . . . . . . . . . . . . . . . . . 6 4.3. Applicability of the schedule . . . . . . . . . . . . . . 6 5. YANG Model for Lifecycle Management of TVR Schedules . . . . 7 5.1. YANG tree schema . . . . . . . . . . . . . . . . . . . . 7 5.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 7 6. Operational Considerations . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The TVR schedule model [I-D.ietf-tvr-schedule-yang] focuses on describing the temporal validity of network attributes. In the current specification, schedule applicability is implicitly determined by time intervals. However, operational deployments can require additional control mechanisms to manage schedules throughout their lifecycle, including temporary deactivation, staged deployment, rollback, and conflict resolution. The absence of explicit lifecycle management mechanisms may lead to ambiguities in operational environments where schedules are dynamically provisioned, updated, or superseded. [RFC9657] describes a number of TVR use cases. While some use cases (e.g., mobile satellites) are deterministic in the sense of describing a continuous variance of the routing along time, some others (e.g., energy efficiency) are based on assumptions about future behavior that could be altered by events or operational circunstances (e.g., change on the traffic with respecto to the initial forecast, failures or unplanned changes in the network, etc) Contreras Expires 25 December 2026 [Page 2] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 that could motivate the need of revoking the originally intended schedule. Similarly [I-D.ietf-tvr-off-path-exposure] describes a use case of planned network maintenance (e.g., software upgrade, line card replacement, etc) where having administrative control of the schedules is necessary because the intervention can be impacted by unforeseen situations at the time fo defining the schedule. This extension is intended to complement the TVR scheduling model by introducing an optional augmentation to the TVR schedule model in order to provide a mechanism for explicit lifecycle control, preserving compatibility with implementations of the base model, introducing administrative control attributes that enable explicit management of schedule applicability without altering their temporal definition. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174]. In addition, the terms defined in [I-D.ietf-tvr-requirements] are also used in this document. 3. Motivation TVR enables the possibility of advertised predictable changes in network resources (nodes and/or topology). This means that future changes are predicted to happen in a given point of time under current assumptions and circumstances. However, it could be the case that such assumptions and circumstances are not longer valid from the time of definition of the schedule for the changes up to the realization of those predicted changes. Then there is a need for defining administrative control for planned changes in network resources so that schedules defined in some point of time can be modified to adjust the changes planned in the past to new operational situations. 3.1. Operational Situations for Lifecycle Control: A number of operational situations can require lifecycle control. * Temporary suspension of schedules due to unexpected events or maintenance operations (e.g., indicated with other schedules). Contreras Expires 25 December 2026 [Page 3] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 * Controlled activation after validation or staging, enabling the schedules to be provisioned and validated in advance, and then activated in a controlled manner when required. * Coexistence of multiple schedule versions, enabling selection of the appropriate one without removing others (e.g., for traceability). * Conflict resolution between overlapping schedules, enabling explicit prioritization and selection according to predifined rules. * Rollback to previously defined schedules, allowing schedules to be reactivated without redefining their temporal parameters. 3.2. Aligment with the TVR YANG Model The TVR requirements document [I-D.ietf-tvr-requirements] defines the functional expectations for systems performing Time-Variant Routing (TVR), including the modeling of time-dependent properties and the computation of routes as a function of time. The base YANG data model for scheduled attributes [I-D.ietf-tvr-schedule-yang] fulfills these requirements by providing a mechanism to represent time-based variations of network properties. This document introduces an optional augmentation that provides administrative control over schedules. This control operates orthogonally to the temporal dimension of the model. In particular, this document addresses operational gaps that arise when deploying TVR systems in practice, including: * The ability to distinguish between defined schedules and those actively enforced in the network. * The capability to administratively activate, suspend, or deprecate schedules without modifying their temporal contents. * Support for controlled deployment workflows, including staging and rollback of schedules. * Resolution of conflicts between multiple overlapping schedules by means of administrative prioritization. These capabilities enable more robust operational handling of time- variant data, particularly in architectures involving multiple components such as schedule generators, controllers, and managed devices. The introduction of an administrative state does not change the interpretation of time-variant properties. A schedule remains Contreras Expires 25 December 2026 [Page 4] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 temporally valid according to its defined intervals, while its applicability is additionally conditioned by its administrative state. This extension is proposed as optional to be used in the TVR use cases that benefit from the management of the lifecycle of the schedules. 4. Design Overview The base TVR schedule model defines schedule validity based on time. This document introduces an additional optional layer of administrative control. As a result, a schedule is considered applicable if both time-based and administrative conditions are satisfied. 4.1. Administrative states The following administrative states are considered: * Active, when the schedule is administratively enabled and MUST be considered for application when its temporal conditions are satisfied. * Inactive, if the schedule is administratively disabled and MUST NOT be applied, regardless of its temporal validity. * Deprecated, representing that the schedule is marked as no longer recommended for use and SHOULD NOT be applied. (Note: for discussion to define what to do if no alternative active schedules are available). * Pending, when the schedule has been provisioned but is not yet active and MUST NOT be applied until its administrative state is changed to "active". (Note: to be discussed if additional states can be requires, e.g., removed, etc) Figure 1 details the transition among states. Contreras Expires 25 December 2026 [Page 5] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 +----------+ +----------+ +----------+ | | | |----->| | | Pending |----->| Active | | Inactive | | | | |<-----| | +----------+ +----------+ +----------+ | | v +----------+ | | |Deprecated| | | +----------+ Figure 1. Administrative states transition. 4.2. Additional parameters In order to allow finer control of the schedules, the model includes additional parameters, as follows: * Version, to allow keeping track of schedule modifications along time. * Priority, in order to signal the priority of a specific schedule in case of conflict (i.e., overlapping) with some other predifined schedule. * Origin, to identify the responsible for the definition of a given schedule. 4.3. Applicability of the schedule A schedule MUST be considered applicable only if both of the following conditions are satisfied: * The current time is within the defined schedule interval. * The administrative state of the schedule is set to "active". If the administrative state is not "active", the schedule MUST NOT be applied, regardless of its temporal validity. This approach preserves the semantics of the base model while enabling enhanced operational control. Moreover, in scenarios where multiple schedules overlap in time, implementations MUST determine the applicable schedule based on administrative state and priority. Thus, only schedules with admin- Contreras Expires 25 December 2026 [Page 6] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 status set to "active" MUST be considered to be applied. Among those, the schedule with the highest priority value SHOULD be selected. In case of equal priority, the selection is implementation-specific, for instance, based on the originator of the schedule. 5. YANG Model for Lifecycle Management of TVR Schedules 5.1. YANG tree schema The following tree diagram illustrates the structure of the lifecycle augmentation applied to the TVR schedule model: module: ietf-tvr-schedule-lifecycle augment /tvr-schd:schedules: +--rw admin-status? enumeration | +-- active | +-- inactive | +-- deprecated | +-- pending | +--rw version? string | +--rw priority? uint8 | +--rw last-modified? yang:date-and-time | +--rw origin? string (optional) 5.2. YANG module The YANG module is described as follows. module ietf-tvr-schedule-lifecycle { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tvr-schedule-lifecycle"; prefix tvr-schd-lc; import ietf-tvr-schedule { prefix tvr-schd; } import ietf-yang-types { prefix yang; } Contreras Expires 25 December 2026 [Page 7] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 organization "IETF TVR Working Group"; contact "WG Web: WG List: "; Author: Luis M. Contreras description "This module augments the TVR schedule model with lifecycle and administrative control state."; revision 2026-06-20 { description "Initial version."; } grouping schedule-lifecycle { description "Lifecycle attributes for TVR schedules."; leaf admin-status { type enumeration { enum active { description "Schedule is active and applied."; } enum inactive { description "Schedule is administratively disabled."; } enum deprecated { description "Schedule is no longer recommended."; } enum pending { description "Schedule defined but not yet active."; } } default "active"; description "Administrative state of the schedule."; } leaf version { type string; description "Version identifier of the schedule."; } Contreras Expires 25 December 2026 [Page 8] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 leaf priority { type uint8{ range "0..255"; } description "Priority used to resolve conflicts between schedules. Higher values indicate higher priority."; } leaf last-modified { type yang:date-and-time; description "Timestamp of the last modification of the schedule lifecycle attributes."; } leaf origin { type string; description "Identifier of the entity that provisioned the schedule."; } } augment "/tvr-schd:schedules" { description "Augment schedules with lifecycle control."; uses schedule-lifecycle; } } 6. Operational Considerations The operational considerations described in [I-D.ietf-tvr-schedule-yang] apply to this document. Further operational considerations are related to the lifecycle management of the schedules and the usage of the parameters considered in the model. The following is a list of operational situations that require attention. * Since the extension here defined is optional, backward compatibility SHOULD be guaranteed with devices and/or components not supporting this model. That is, this extension SHOULD NOT be used in case the devices and/or control components not support this model. Contreras Expires 25 December 2026 [Page 9] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 * When this augmentation is supported, implementations MUST evaluate schedule applicability taking into account both temporal validity and administrative state. * When multiple schedules overlap, implementations SHOULD consider both administrative state and priority when selecting the active schedule. * Implementations SHOULD ensure consistency between the intended datastore and operational datastore when lifecycle attributes are modified. Furthermore, consistent interpretation of the administrative state across components and devices. 7. Security Considerations The security considerations described in [I-D.ietf-tvr-schedule-yang] and [I-D.ietf-tvr-requirements] also apply to this document. Additional security considerations apply to the lifecycle model. The following list describes considerations to take into account. * The ability to activate or deactivate schedules introduces control risks. The frequency of changes can be a vector of attacks. * Unauthorized modifications of lifecycle attributes may result in unexpected activation or deactivation of schedules, potentially impacting routing behavior. Thus authentication and secure transport mechanisms SHOULD be used. 8. References 8.1. Normative References [I-D.ietf-tvr-schedule-yang] Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. Blanchet, "A YANG Data Model for Scheduled Attributes", Work in Progress, Internet-Draft, draft-ietf-tvr-schedule- yang-12, 10 June 2026, . 8.2. Informative References [I-D.ietf-tvr-off-path-exposure] Contreras, L. M., "Using off-path mechanisms for exposing Time-Variant Routing information", Work in Progress, Contreras Expires 25 December 2026 [Page 10] Internet-Draft Lifecycle and State Extensions for TVR S June 2026 Internet-Draft, draft-ietf-tvr-off-path-exposure-02, 20 April 2026, . [I-D.ietf-tvr-requirements] King, D., Contreras, L. M., Sipos, B., and L. Zhang, "Time-Variant Routing (TVR) Requirements", Work in Progress, Internet-Draft, draft-ietf-tvr-requirements-09, 12 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9657] Birrane, III, E., Kuhn, N., Qu, Y., Taylor, R., and L. Zhang, "Time-Variant Routing (TVR) Use Cases", RFC 9657, DOI 10.17487/RFC9657, October 2024, . Author's Address Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com Contreras Expires 25 December 2026 [Page 11]