Internet-Draft Time Variant Link Availability YANG July 2023
Kinzie & Fedyk Expires 11 January 2024 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Standards Track
Expires:
Authors:
E. Kinzie
LabN Consulting, L.L.C.
D. Fedyk
LabN Consulting, L.L.C.

A YANG Data Model for Time Variant Link Availability

Abstract

This document defines a YANG data model that describes the times at which network links are available for use. The model is intended for use in networks where links can be predictably lost and re-established, and neighbors may change as a function of time. The intent is for this information to be used by a Time-Variant Routing (TVR) system which may route network traffic based on mobility, energy costs or expected user data volumes, and handle such predictable changes in a non-disruptive manner.

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 11 January 2024.

1. Terminology & Concepts

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Introduction

For some networks, the times at which one router will be able to establish a link with another router can be predicted. Links can be predictably lost and re-established, and neighbors may change as a function of time. For examples of such networks see, TVR (Time-Variant Routing) Use Cases [I-D.ietf-tvr-use-cases].

This document defines a YANG data model [RFC6020] that describes the times at which network links are available for use. The contents of this module are intended to be flexible enough to describe an entire network when required, but can also be used to focus on a single node's view.

The defined YANG model can be used to support Network topology data that is augmented to include links that are expected, but not yet present. Time-based link availability has utility in areas such as resource planning for energy conservation, resource allocation for scheduled bulk data transfers, and avoiding service disruption through make-before-break strategies. Data presented with this module could be used as a source of information for time-variant IGP extensions currently being developed in [I-D.zw-tvr-igp-extensions]. One example of where such information is applicable is a constellation of satellites. Since orbits are known, satellites' positions relative to one another, positions relative to ground stations, and many sources of interference can be calculated days in advance.

For the purpose of describing link properties, the defined YANG module reuses attributes defined in [RFC5305], [RFC3630], [RFC8776], [RFC9129], and [RFC9130].

The link-availability container describes the times at which one or more links are available. Links are modeled as unidirectional. Any one link supports unidirectional traffic flow, from the source node to the destination node. The bidirectional traffic between a pair of network nodes requires at least two links. A Link is considered to be available at the time it is first able to support delivery of packets until the time at which it becomes unable to do so. Valid until times may be set to a time when the link will last support the advertised characteristics. Routers and/or controllers can choose to move traffic prior to the valid-until time when trying to minimize disruption. Available times do not take into account, for example, the time required for carrier to be detected after the interfaces at either end have been powered on; the interfaces in this example would be powered on some time before availability starts.

Link availabilities obtained from data represented by this module are considered "current" until the time specified in the next-update time. Any availability received by a network management client after the specified next-update time has passed SHOULD be discarded.

Link availability is described from the viewpoint of a particular source node (the transmitting node) and beginning at a particular time.

3.2.1. Availability Times

Each link in the list contains the range of times during which it is available. In the event that a link formed by a given combination of source node, source-link identifier, and destination node is available at multiple times, each occurrence is a separate entry in the list and can be distinguished by the avail-from value. Availability time ranges for the same source node, source-link identifier, and destination node MUST NOT overlap. However, note that the time ranges are specified such that avail-from is inclusive and avail-until is exclusive. That is, the avail-until time in one link availability MAY be the same as the avail-from in a subsequent availability for the same combination of endpoints. This can happen if one or more link attributes change over the life of a link.

A list element MUST NOT have an avail-from that occurs after its avail-until.

The avail-until value is optional. If avail-until is absent from a list element, the link is considered to be available until the time of the next expected update (next-update). Should the next update not arrive at or before the expected time, an entry without an avail-until time is considered to be no longer available. An entry with an unexpired avail-until time remains available until the specified time, even if the next update does not arrive when expected.

An avail-from value indicating a time prior to when the link availability data was received implies that the link is immediately available.

A list entry with an avail-until time that has already passed can be ignored.

A list entry MAY have an avail-from time after the time of the next expected update.

List elements can be added and removed by the source of information at any time. This may result in a link availability being removed before its previously specified avail-until time. Such a list element that is removed implies that the link is no longer available.

The availability times in a list element do not "change"; a list element may be deleted and another list element with the same endpoints may be inserted with different available times.

3.2.2. Source and Destination Nodes

Any string may be used to identify a node in the source-node and destination-node elements. It is expected, but not required, that a node string will refer to data described by another YANG module.

Any string may be used to identify a link as viewed from the source-node. It is expected, but not required, that the value of a source-link-id leaf will refer to data described by another YANG module.

3.2.4. Bandwidth, Delay and Default Metrics

These are predicted link attributes. Bandwidth specifies the total link bandwidth and does not take into account resource reservations that may utilize a link. If the observed bandwidth negotiated for a link is greater than the predicted value, the predicted value SHOULD be used for the purposes of routing decisions. Otherwise, if the observed bandwidth is less, the observed value SHOULD be used. Delay is the link propagation time and does not include queuing delays. If no measured delay is available or if the measured value is less than the predicted delay, the predicted value SHOULD be used for routing decisions. Otherwise, the observed value SHOULD be used. A number of time variant metrics and attributes may be included. The Interior Gateway Protocol (IGMP) link metric is an optional value for the predicted OSPF or IS-IS link metric. The default TE metric specifies the link metric for route and/or path computation purposes.

Generic link affinities and Shared links resource groups may be specified as list of strings. This can be used for predicting traffic engineering usage.

4. YANG Management

4.1. YANG Tree

The following is the YANG tree diagram [RFC8340] for the link-availability container.

module: ietf-link-availability
  +--ro link-availability
     +--ro next-update?   yang:date-and-time
     +--ro link* [avail-from source-node source-link-id]
        +--ro avail-from             yang:date-and-time
        +--ro source-node            string
        +--ro source-link-id         string
        +--ro destination-node?      string
        +--ro avail-until?           yang:date-and-time
        +--ro bandwidth?             te-types:te-bandwidth
        +--ro delay?                 uint32
        +--ro igp-link-metric?       uint32
        +--ro te-default-metric?     uint32
        +--ro link-affinity-names
        |  +--ro link-affinity-name* [usage]
        |     +--ro usage            identityref
        |     +--ro affinity-name* [name]
        |        +--ro name    string
        +--ro link-srlgs-names
           +--ro link-srlgs-name* [usage]
              +--ro usage    identityref
              +--ro names*   string

4.2. YANG Module

The following is the YANG module for reporting link availabilities.

<CODE BEGINS> file "ietf-link-availability@2023-06-15.yang"
module ietf-link-availability {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-link-availability";
  prefix ln-avail;

  import ietf-yang-types {
    prefix yang;
  }

  import ietf-te-types {
    prefix te-types;
  }

  organization
    "IETF Time-Variant Routing Working Group";

  contact
    "WG Web:   <https://datatracker.ietf.org/wg/tvr/>
     WG List:  <mailto:tvr@ietf.org>

     Editors:  Eric Kinzie
               <mailto:ekinzie@labn.net>
               Don Fedyk
               <mailto:dfedyk@labn.net>";

  description
    "This YANG module contains YANG definitions for describing
    network links with an time-variant availability schedule.

    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.";

  revision 2023-06-15 {
    description
      "Initial revision";
    reference
      "RFC XXXX A YANG Data Model for Time Variant Link
      Availability";
  }

  container link-availability {
    config false;

    leaf next-update {
      type yang:date-and-time;
      description
        "This data is current until the specified time.";
    }

    list link {
      key "avail-from source-node source-link-id";
      leaf avail-from {
        type yang:date-and-time;
        description
          "The time at which this link becomes available.";
      }
      leaf source-node {
        type string;
        description
          "A name that refers to the source (transmitting)
           node of the link.";
      }
      leaf source-link-id {
        type string;
        description
          "A name, as known to the source node, that refers to
          this link.";
      }
      leaf destination-node {
        type string;
        description
          "A name that refers to the destination (receiving) node
          of the link.";
      }
      leaf avail-until {
        type yang:date-and-time;
        description
          "The time at which this link is no longer available.";
      }
      leaf bandwidth {
        type te-types:te-bandwidth;
        description
          "The predicted link capacity specified in a generic
          format. If the value measured by the system is less than
          this value, the system value is used.  If the value
          measured by the system is greater than this value the
          predicted value SHOULD be used.";
        reference
          "RFC 8776: Common YANG Data Types for Traffic Engineering";
      }
      leaf delay {
        type uint32 {
          range "0..16777215";
        }
        description
          "The one-way delay or latency in microseconds. If the
          value measured by the system is less than this value
          the predicted value SHOULD be used.";
        reference
          "RFC 8776: Common YANG Data Types for Traffic Engineering";
      }
      leaf igp-link-metric {
        type uint32;
        description
          "OSPF or IS-IS link metric.  If this metric is supplied
           it is the predicted metric that is used by the system.
           The system may adjust operational metric as needed.";
        reference
          "RFC 9129: YANG Data Model for the OSPF Protocol
           RFC 9130: YANG Data Model for the IS-IS Protocol";
      }
      leaf te-default-metric {
        type uint32;
        description
          "The Traffic Engineering metric. The system may adjust this
           value on the operational link.";
        reference
          "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
          Version 2
           RFC 5305: IS-IS Extensions for Traffic Engineering";
      }
      container link-affinity-names {
        description
          "Link affinities represented as names.";
        list link-affinity-name {
          key "usage";
          description
            "An optional list of named affinity constraints.";
          leaf usage {
            type identityref {
              base te-types:resource-affinities-type;
            }
            description
              "Identifies an entry in the list of named affinity
               constraints.";
          }
          list affinity-name {
            key "name";
            leaf name {
              type string;
              description
                "Identifies a named affinity entry.";
            }
            description
              "List of named affinities.";
            reference
              "RFC 8776: Common YANG Data Types for Traffic
               Engineering";
          }
        }
      }
      container link-srlgs-names {
        description
          "Container for the list of named SRLGs.";
        list link-srlgs-name {
          key "usage";
          description
            "List of named SRLGs to be included or excluded.";
          leaf usage {
            type identityref {
              base te-types:route-usage-type;
            }
            description
              "Identifies an entry in a list of named SRLGs to either
               include or exclude.";
          }
          leaf-list names {
            type string;
            description
              "List of named SRLGs.";
            reference
              "RFC 8776: Common YANG Data Types for Traffic
               Engineering";
          }
        }
      }
      description
        "This list represents a set of links each which has
         time variant link attributes.";
    }
    description
      "A container with a list links with time variant link
       availabilities.";
  }
}
<CODE ENDS>

5. Open Issues

The contents of source-node and destination node are not well defined.

6. IANA Considerations

It is requested that the following URI be added to the "ns" subregistry within the "IETF XML Registry" [RFC3688].

It is requested that the following YANG module be added to the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.

7. Security Considerations

The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].

The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5305]
Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <https://www.rfc-editor.org/info/rfc5305>.
[RFC3630]
Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, , <https://www.rfc-editor.org/info/rfc3630>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020]
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242]
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, , <https://www.rfc-editor.org/info/rfc6242>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340]
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341]
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
[RFC8776]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", RFC 8776, DOI 10.17487/RFC8776, , <https://www.rfc-editor.org/info/rfc8776>.
[RFC9129]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for the OSPF Protocol", RFC 9129, DOI 10.17487/RFC9129, , <https://www.rfc-editor.org/info/rfc9129>.
[RFC9130]
Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for the IS-IS Protocol", RFC 9130, DOI 10.17487/RFC9130, , <https://www.rfc-editor.org/info/rfc9130>.

9. Informative References

[I-D.ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., and Y. Qu, "TVR (Time-Variant Routing) Use Cases", Work in Progress, Internet-Draft, draft-ietf-tvr-use-cases-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-cases-01>.
[I-D.zw-tvr-igp-extensions]
Zhang, Z. and H. Wu, "IS-IS and OSPF extensions for TVR (Time-Variant Routing)", Work in Progress, Internet-Draft, draft-zw-tvr-igp-extensions-01, , <https://datatracker.ietf.org/doc/html/draft-zw-tvr-igp-extensions-01>.

Appendix A. Acknowledgements

The authors would like to thank Acee Lindem and Lou Berger for their reviews and suggested improvements.

Authors' Addresses

Eric Kinzie
LabN Consulting, L.L.C.
Don Fedyk
LabN Consulting, L.L.C.