Internet DRAFT - draft-kinzie-tvr-link-availability
draft-kinzie-tvr-link-availability
Network Working Group E. Kinzie
Internet-Draft D. Fedyk
Intended status: Standards Track LabN Consulting, L.L.C.
Expires: 11 January 2024 10 July 2023
A YANG Data Model for Time Variant Link Availability
draft-kinzie-tvr-link-availability-00
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.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kinzie & Fedyk Expires 11 January 2024 [Page 1]
Internet-Draft Time Variant Link Availability YANG July 2023
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. Terminology & Concepts . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Link Availability . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Useful Life of Link Availability Data . . . . . . . . . . 3
3.2. Link Availabilities List . . . . . . . . . . . . . . . . 4
3.2.1. Availability Times . . . . . . . . . . . . . . . . . 4
3.2.2. Source and Destination Nodes . . . . . . . . . . . . 5
3.2.3. Source Link Identifier . . . . . . . . . . . . . . . 5
3.2.4. Bandwidth, Delay and Default Metrics . . . . . . . . 5
4. YANG Management . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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].
Kinzie & Fedyk Expires 11 January 2024 [Page 2]
Internet-Draft Time Variant Link Availability YANG July 2023
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].
3. Link Availability
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.
3.1. Useful Life of Link Availability Data
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.
Kinzie & Fedyk Expires 11 January 2024 [Page 3]
Internet-Draft Time Variant Link Availability YANG July 2023
3.2. Link Availabilities List
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.
Kinzie & Fedyk Expires 11 January 2024 [Page 4]
Internet-Draft Time Variant Link Availability YANG July 2023
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.
3.2.3. Source Link Identifier
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.
Kinzie & Fedyk Expires 11 January 2024 [Page 5]
Internet-Draft Time Variant Link Availability YANG July 2023
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>
Kinzie & Fedyk Expires 11 January 2024 [Page 6]
Internet-Draft Time Variant Link Availability YANG July 2023
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 {
Kinzie & Fedyk Expires 11 January 2024 [Page 7]
Internet-Draft Time Variant Link Availability YANG July 2023
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";
Kinzie & Fedyk Expires 11 January 2024 [Page 8]
Internet-Draft Time Variant Link Availability YANG July 2023
}
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";
Kinzie & Fedyk Expires 11 January 2024 [Page 9]
Internet-Draft Time Variant Link Availability YANG July 2023
}
}
}
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].
Kinzie & Fedyk Expires 11 January 2024 [Page 10]
Internet-Draft Time Variant Link Availability YANG July 2023
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, March 1997,
<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, October
2008, <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, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<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, October 2010,
<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, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
Kinzie & Fedyk Expires 11 January 2024 [Page 11]
Internet-Draft Time Variant Link Availability YANG July 2023
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<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,
May 2017, <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, March 2018,
<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, March 2018,
<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, August 2018,
<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, June 2020,
<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, October 2022,
<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, October 2022,
<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, 3 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-
cases-01>.
Kinzie & Fedyk Expires 11 January 2024 [Page 12]
Internet-Draft Time Variant Link Availability YANG July 2023
[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, 12 March 2023,
<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.
Email: ekinzie@labn.net
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
Kinzie & Fedyk Expires 11 January 2024 [Page 13]
