]> YANG Model for Scheduled Attributes Futurewei
2330 Central Expressway Santa Clara CA 95050 USA yingzhen.qu@futurewei.com
LabN Consulting LLC
301 Midenhall Way Cary, NC 27513 acee.ietf@gmail.com
Viagenie
marc.blanchet@viagenie.ca
General Internet The YANG model in this document specifies a recurring schedule for changing the attributes of resources that are defined in other YANG data models. An example use case augmentation is also included, i.e., using the schedule to change the OSPF interface metric.
YANG is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF . YANG is proving relevant beyond its initial confines, as bindings to other interfaces (e.g., ReST) and encodings other than XML (e.g., JSON) are being defined. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic APIs. The YANG model in this document specifies a recurring schedule for changing the attributes of resources that are defined in other YANG YANG data models. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) .
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 .
This document uses the graphical representation of data models defined in .
The grouping "schedule" is defined in this model, which can be used to augment other models with time variant attributes. The grouping "schedule-lifetime" is to define the life time of the "schedule". It has a "schedule-start-time" using "date-and-time", and the "schedule-end-time" can be an option of infinite, duration or date time. The "schedule-lifetime" can also be set to "always", which means the schedule is always valid and will be effective right away after the configuration. If the "schedule-start-time" is set to a time in the past when a configuration is done, the schedule is effective right away. The leaf "recurrence" specifies the repetition pattern of the "base-schedule", such as daily or weekly. The "base-schedule", which is the basic unit of this schedule, consists a list of "intervals". These intervals specify the attribute values during the "base-schedule". The "recurrence" defines the duration of each "base-schedule", so the configured "intervals" should be within this duration. For example, if the "recurrence" is configured as daily, the last "end-time" in the list should not be larger than 24 hours, which is 8640000 in timeticks. Also each "end-time" must be greater than the "start-time" in the same interval. The "timeticks" defined in is used to specify the relative "start-time" and "end-time" in each recurrence. The "value" leaf is defined as a union, allowing it to be a simple boolean value, an integer represented as a string, or a value function expressed as a string. For instance, the string can represent a value that dynamically changes over time using a function such as "2*t+10". The "value-default" leaf defines the attribute's value when it's not covered by the intervals. When a schedule starts in the middle of an recurrence, for example, the recurrence is set to "daily", and the "schedule-start-time" is 8:00AM, when the schedule starts, the "value" should be the 8:00AM value defined by the "base-schedule". When an attribute's schedule ends, the "value-default" SHOULD be used. The following figure provides an illustration of two attributes and their scheduled value changes. The attributes A1 and A2 take on different values at different times. The attribute A1 will take on the value v1 from the time t0 until t1, the value v2 from t1 until t2, and v3 from t2 until t3. The attribute A2 will take on the value vv1 from time t0 until t1 and vv2 from v1 until v3.
Time Varying Properties Attributes +-------------------+----------+------+ A1 | v1 | v2 | v3 | +-------------------+----------+------+ A2 | vv1 | vv2 | +-------------------+-----------------+ t0 t1 t2 t3 Time
The following is the tree diagram of the grouping "schedule".
Tree diagram of the schedule +--rw (schedule-lifetime)? | +--:(always) | | +--rw always? empty | +--:(start-end-time) | +--rw start-date-time? yang:date-and-time | +--rw (end-time)? | +--:(infinite) | | +--rw no-end-time? empty | +--:(duration) | | +--rw duration? uint32 | +--:(end-date-time) | +--rw end-date-time? yang:date-and-time +--rw recurrence? recurrence-type +--rw value-default? union +--rw base-schedule +--rw intervals* [start-time] +--rw start-time yang:timeticks +--rw end-time? yang:timeticks +--rw value? union
Grouping "schedule" can be used to augment other YANG data models with an attribute that changes its value based on a predefined schedule. In this document, the IETF logical network element model is augmented with a scheduled power shutdown using the grouping "schedule". The interfaces defined in the ietf-interface model is augmented with a scheduled interface up and down. More use cases can be found in .
The following figure shows the tree diagram of the interface augmentation and LNE augmentation. module: ietf-tvr-schedule augment /if:interfaces/if:interface: +--rw scheduled-up-down +--rw (schedule-lifetime)? | +--:(always) | | +--rw always? empty | +--:(start-end-time) | +--rw start-date-time? yang:date-and-time | +--rw (end-time)? | +--:(infinite) | | +--rw no-end-time? empty | +--:(duration) | | +--rw duration? uint32 | +--:(end-date-time) | +--rw end-date-time? yang:date-and-time +--rw recurrence? recurrence-type +--rw value-default? union +--rw base-schedule +--rw intervals* [start-time] +--rw start-time yang:timeticks +--rw end-time? yang:timeticks +--rw value? union augment /lne:logical-network-elements/lne:logical-network-element: +--rw scheduled-power +--rw (schedule-lifetime)? | +--:(always) | | +--rw always? empty | +--:(start-end-time) | +--rw start-date-time? yang:date-and-time | +--rw (end-time)? | +--:(infinite) | | +--rw no-end-time? empty | +--:(duration) | | +--rw duration? uint32 | +--:(end-date-time) | +--rw end-date-time? yang:date-and-time +--rw recurrence? recurrence-type +--rw value-default? union +--rw base-schedule +--rw intervals* [start-time] +--rw start-time yang:timeticks +--rw end-time? yang:timeticks +--rw value? union
The following RFCs are referenced in the "ietf-tvr-schedule" YANG module: , and . file "ietf-tvr-schedule@2023-07-05.yang" module ietf-tvr-schedule { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tvr-schedule"; prefix tvr-schedule; import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management (NMDA Version)"; } import ietf-logical-network-element { prefix "lne"; reference "RFC 8530: YANG Model for Logical Network Elements"; } organization "IETF TVR - Time Variant Routing Working Group"; contact "WG Web: WG List: Author: Yingzhen Qu Author: Acee Lindem Author: Marc Blanchet "; description "The YANG module defines a schedule for changing attributes. It can be used to augment existing models. This YANG model conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; reference "RFC XXXX: YANG Data Model for Scheduled Attributes"; revision 2023-07-05 { description "Initial Version"; reference "RFC XXXX: YANG Data Model for Scheduled Attributes."; } typedef recurrence-type { type enumeration { enum once { description "Repeat the scheduled action or attribute modificaton only once"; } enum hourly { description "Repeat the scheduled action or attribute modificaiton once per hour."; } enum daily { description "Repeat the scheduled action or attribute modificaiton once per day."; } enum weekly { description "Repeat the scheduled action or attribute modificaiton once per week."; } enum monthly { description "Repeat the scheduled action or attribute modificaiton once per week."; } enum yearly { description "Repeat the scheduled action or attribute modificaiton once per year."; } } description "Types of recurrence"; } grouping schedule-lifetime { description "Schedule lifetime specification."; choice schedule-lifetime { default "always"; description "Options for specifying schedule lifetimes"; case always { leaf always { type empty; description "Indicates schedule is always valid, and the schedule will be effective right away after the configuration."; } } case start-end-time { leaf start-date-time { type yang:date-and-time; description "Start time of the schedule."; } choice end-time { default "infinite"; description "End-time setting."; case infinite { leaf no-end-time { type empty; description "Indicates schedule lifetime end-time is infinite."; } } case duration { leaf duration { type uint32 { range "1..2147483646"; } units "seconds"; description "Schedule lifetime duration, in seconds"; } } case end-date-time { leaf end-date-time { type yang:date-and-time; description "End time."; } } } } } } grouping schedule { uses schedule-lifetime; leaf recurrence { type recurrence-type; must "(current() != 'once') or ../start-date-time" { error-message "A single occurrence requires a start-time"; description "With single recurrence of a schedule, a start-time is required."; } description "Type of recurrence"; } leaf value-default { type union { type boolean; type string; } description "Attribute default value. This value is used when the value is not covered by the intervals, as well as when the schedule ends."; } container base-schedule { list intervals { key "start-time"; leaf start-time { type yang:timeticks; must "((../../../recurrence != 'hourly') or " + "(current() < 360000)) and " + "((../../../recurrence != 'daily') or " + "(current() < 8640000)) and " + "((../../../recurrence != 'monthly') or " + "(current() < 267840000)) and " + "((../../../recurrence != 'yearly') or " + "(current() < 3162240000))" { error-message "The start-time must not exceed the recurrence interval"; description "The start-time must not exceed the recurrrence interval. For example, for a 'monthy' recurrence, the start-time must not exceed 31 days."; } description "Start time of the scheduled value within one recurrence. The calculation of the real start time is to use the basestarting time defined by schedule-lifetime, recurrence, and the timeticks. For example, if a schedule starts at 2001/1/1 8:00AM with an hourly recurrence, and the timeticks is 180,000 (30 mins), the start-time will be every 30 mins pass an hour after 2001/1/1."; } leaf end-time { type yang:timeticks; must "(current() > ../start-time) and " + "((../../../recurrence != 'hourly') or " + "(current() < 360000)) and " + "((../../../recurrence != 'daily') or " + "(current() < 8640000)) and " + "((../../../recurrence != 'monthly') or " + "(current() < 267840000)) and " + "((../../../recurrence != 'yearly') or " + "(current() < 3162240000))" { error-message "The end-time must be greater than the end time and must not exceed the recurrrence interval."; description "The end-time must be greater than the end time and must not exceed the recurrrence interval. For example, for a 'daily' recurrence, the time-tick offset must not exceed 24 hours."; } description "End time of the scheduled change. The calculation of the end-time is the same as the start-time."; } leaf value { type union { type boolean; type string; } description "Value for the scheduled attribute during the specified time period. When type string is used, it can be a simple value such as an int, or a string representing a value that changes its value based on a function."; } description "List of intervals for action or attribute modification. The intervals should be contained within each recurrence. For example, when the recurrence is set to daily, the list of intervals should be within this daily range, e.g., the last end-time can't be larger than 8640000 (24hours)."; } description "The recurring base-schedule of the action or attribute modification"; } description "Complete schedule for a action or attribute modification."; } augment "/if:interfaces/if:interface" { description "Augments interface with scheduled attribute."; container scheduled-up-down { description "Scheduled interface up and down. This is to work with the leaf 'enabled' for the configured state of the interface."; uses schedule; } } augment "/lne:logical-network-elements" + "/lne:logical-network-element" { description "Augments logical network elements with scheduled power shutdown."; container scheduled-power { description "Scheduled power up and down."; uses schedule; } } } ]]>
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in ietf-tvr-schedule.yang module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. There are the subtrees and data nodes and their sensitivity/vulnerability:
  • /if:interfaces/if:interface/scheduled-attributes
  • /lne:logical-network-elements/lne:logical-network-element/scheduled-attribute Modifications to these scheduled attributes may result in a denial of service.
Some of the readable data nodes in the ietf-tvr-schedule.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes.
This document registers a URI in the IETF XML registry . Following the format in , the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-tvr-schedule Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry . name: ietf-tvr-schedule namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-schedule prefix: tvr-schedule reference: RFC XXXX
The YANG model was developed using the suite of YANG tools written and maintained by numerous authors.
&RFC2119; &RFC3688; &RFC6020; &RFC6241; &RFC6242; &RFC6991; &RFC7950; &RFC8040; &RFC8174; &RFC8341; &RFC8342; &RFC8343; &RFC8446; &RFC8530; &RFC8340; &I-D.ietf-tvr-use-cases;
Example: Add a scheduled cost to OSPF interface In OSPF (Open Shortest Path First), the interface cost is a metric used to determine the preference or desirability of a particular link or interface. By default, the OSPF interface cost is calculated based on the bandwidth of the interface, and it is also configurable. This example demonstrates how an OSPF interface can be extended with a cost that changes with a schedule.
Example: LNE scheduled power configuration In this configuration example, LNE power is scheduled between 2023/8/12 0:00 UTC to the end of 2023/08/13 with a daily schedule. In each day, the router is scheduled to be off between 1:00 to 5:00 and 20:00 to 23:00. The two intervals and the corresponding value are defined, the "value-default" is to define the value that's not covered by the intervals. THe following figure shows the intended power schedule. The following XML demonstrate the configuration. "Router ABC" 2023-08-12T00:00:00.00Z 2023-08-13T24:00:00.00Z daily 1 360000 1800000 0 7200000 8280000 0 ]]>