<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.7.0) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ccamp-bwa-topo-yang-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->
  <front>
    <title abbrev="BWA Topo YANG Model">A YANG Data Model for Bandwidth Availability Topology</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-bwa-topo-yang-01"/>
    <author fullname="Jonas Ahlberg">
      <organization>Ericsson AB</organization>
      <address>
        <postal>
          <street>Lindholmspiren 11</street>
          <city>Goteborg</city>
          <code>417 56</code>
          <country>Sweden</country>
        </postal>
        <email>jonas.ahlberg@ericsson.com</email>
      </address>
    </author>
    <author fullname="Scott Mansfield">
      <organization>Ericsson Inc</organization>
      <address>
        <email>scott.mansfield@ericsson.com</email>
      </address>
    </author>
    <author fullname="Min Ye">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No.1899, Xiyuan Avenue</street>
          <city>Chengdu</city>
          <code>611731</code>
          <country>China</country>
        </postal>
        <email>amy.yemin@huawei.com</email>
      </address>
    </author>
    <author fullname="Italo Busi">
      <organization>Huawei Technologies</organization>
      <address>
        <email>italo.busi@huawei.com</email>
      </address>
    </author>
    <author fullname="Xi Li">
      <organization>NEC Laboratories Europe</organization>
      <address>
        <postal>
          <street>Kurfursten-Anlage 36</street>
          <city>Heidelberg</city>
          <code>69115</code>
          <country>Germany</country>
        </postal>
        <email>Xi.Li@neclab.eu</email>
      </address>
    </author>
    <author fullname="Daniela Spreafico">
      <organization>Nokia - IT</organization>
      <address>
        <postal>
          <street>Via Energy Park, 14</street>
          <city>Vimercate (MI)</city>
          <code>20871</code>
          <country>Italy</country>
        </postal>
        <email>daniela.spreafico@nokia.com</email>
      </address>
    </author>
    <date year="2023" month="October" day="18"/>
    <area>Routing</area>
    <workgroup>CCAMP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 70?>
<t>This document defines a YANG data model to describe bandwidth availability for a link in a network topology.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-ccamp-bwa-topo-yang/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        CCAMP Working Group mailing list (<eref target="mailto:ccamp@ietf.org"/>),
        which is archived at <eref target="https://datatracker.ietf.org/wg/ccamp/about/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ccamp/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang"/>.</t>
    </note>
  </front>
  <middle>
    <?line 73?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document defines a YANG data model to describe bandwidth availability for a link.  It is an important characteristic of links with variable bandwidth, where each level of bandwidth can be associated with a certain level of availability.  An example of such a link is microwave radio link, where the bandwidth can be dynamically adapted to changing signal conditions, impacted by interference &amp; fading, in order to guarantee the required quality of the link at every single moment.  <xref target="RFC8330"/> defines a mechanism to report bandwidth-availability information through OSPF-TE, but it could also be useful for a controller to access such bandwidth-availability information as part of the topology model when performing a path/route computation.  The model augments "YANG Data Model for Traffic Engineering (TE) Topologies" defined in <xref target="RFC8795"/>, which is based on "A YANG Data Model for Network Topologies" defined in <xref target="RFC8345"/>.</t>
      <t>The bandwidth availability model is expected to be used between a Provisioning Network Controller (PNC) and a Multi Domain Service Coordinator(MDSC) <xref target="RFC8453"/>.  Examples of use cases that can be supported are:</t>
      <ol spacing="normal" type="1"><li>
          <t>Propagation of relevant characteristics of a link, including bandwidth availability, to higher topology layers, where it e.g. could be used as a criterion when configuring and optimizing a path for a connection/service through the network end to end.</t>
        </li>
        <li>
          <t>A link could dynamically adjust its bandwidth according to changes in the signal conditions. <xref target="RFC8330"/> defines a mechanism to report bandwidth-availability information through OSPF-TE, but it could also be useful for a controller to access such bandwidth-availability information as part of the topology model when performing a path/route computation.</t>
        </li>
      </ol>
      <section anchor="terminology-and-definitions">
        <name>Terminology and Definitions</name>
        <t>The following acronyms are used in this document:</t>
        <t>PNC Provisioning Network Controller</t>
        <t>MDSC Multi Domain Service Coordinator</t>
      </section>
      <section anchor="tree-structure">
        <name>Tree Structure</name>
        <t>A simplified graphical representation of the data model is used in chapter 3.1 of this document.  The meaning of the symbols in these diagrams is defined in <xref target="RFC8340"/>.</t>
      </section>
    </section>
    <section anchor="requirements-language">
      <name>Requirements Language</name>
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="bandwidth-availability-topology-yang-data-model">
      <name>Bandwidth Availability Topology YANG Data Model</name>
      <section anchor="yang-tree">
        <name>YANG Tree</name>
        <sourcecode type="yangtree" name="bw.tree"><![CDATA[
module: ietf-bandwidth-availability-topology

  augment /nw:networks/nw:network/nt:link/tet:te
            /tet:te-link-attributes:
    +---u link-bw-availability-table
]]></sourcecode>
      </section>
      <section anchor="bandwidth-availability-topology-yang-data-module">
        <name>Bandwidth Availability Topology YANG Data Module</name>
        <sourcecode type="yang" markers="true" name="ietf-bandwidth-availability-topology.yang"><![CDATA[
module ietf-bandwidth-availability-topology {
   yang-version "1.1";
   namespace
  "urn:ietf:params:xml:ns:yang:ietf-bandwidth-availability-topology";
   prefix "bwatopo";

   import ietf-yang-types {
     prefix yang;
     reference
       "RFC 6991";
   }

   import ietf-network {
     prefix "nw";
     reference "RFC 8345: A YANG Data Model for Network Topologies";
   }

   import ietf-network-topology {
     prefix "nt";
     reference "RFC 8345: A YANG Data Model for Network Topologies";
   }

   import ietf-te-topology {
     prefix "tet";
     reference "RFC 8795: YANG Data Model for Traffic Engineering
                (TE) Topologies";
   }

   organization
     "Internet Engineering Task Force (IETF) CCAMP WG";
   contact
     "WG List: <mailto:ccamp@ietf.org>

      Editor: Jonas Ahlberg
              <mailto:jonas.ahlberg@ericsson.com>
      Editor: Scott Mansfield
              <mailto:scott.mansfield@ericsson.com>
      Editor: Min Ye
              <mailto:amy.yemin@huawei.com>
      Editor: Italo Busi
              <mailto:Italo.Busi@huawei.com>
      Editor: Xi Li
              <mailto:Xi.Li@neclab.eu>
      Editor: Daniela Spreafico
              <mailto:daniela.spreafico@nokia.com>
     ";

   description
     "This is a module for defining bandwidth availability matrix,
      for links in a topology. It is intended to be used in
      conjunction with an instance of ietf-network-topology and its

      augmentations.
      Example use cases include:
      - Defining bandwidth availability matrix for a microwave link
      - Defining bandwidth availability matrix for a LAG link
        comprising of two or more member links

     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://tools.ietf.org/html/rfcXXXX); see the RFC itself for
     full legal notices.";

   revision 2023-02-15 {
     description
     "First rough draft.";
     reference "";
   }

   /*
    * Groupings
    */
   grouping link-bw-availability-table {

     description "Grouping used for bandwidth availability.";

     list link-availability{
       key "availability";
       description
         "Table describing the bandwidths available at corresponding
          availability level for a link.";

       leaf availability {
         type decimal64 {
           fraction-digits 4;
           range "0..99.9999";
         }
         description "Availability level";
       }

       leaf link-bandwidth {
         type uint64;
         units "Kbps";

         description
           "The link bandwidth corresponding to the availability
            level";
       }
     }
     leaf actual-bandwidth{
       type yang:gauge64;
       units "bits/second";
       config false;
       description
         "An estimate of the link's current bandwidth in bits per
          second. Related to the data node speed in RFC 8343.";
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
   }

   /*
    * Data nodes
    */

   augment "/nw:networks/nw:network/nt:link/tet:te/"
           + "tet:te-link-attributes" {
     description
       "Augmenting link with link bandwidth availability matrix.";
     uses link-bw-availability-table;
   }
 }
]]></sourcecode>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The YANG module specified in this document defines schemas for data
   that is designed to be accessed via network management protocols such
   as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) <xref target="RFC6242"/>.  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   <xref target="RFC8446"/>.</t>
      <t>The NETCONF access control model <xref target="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.</t>
      <t>The YANG module specified in this document imports and augments the
   ietf-network and ietf-network-topology models defined in <xref target="RFC8345"/>.
   The security considerations from <xref target="RFC8345"/> are applicable to the
   module in this document.</t>
      <t>There are a several data nodes defined in this 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.  These are the data nodes and their
   sensitivity/vulnerability:</t>
      <t>In the "ietf-bandwidth-availability-topology" module:</t>
      <ul spacing="normal">
        <li>
          <t>availability: A malicious client could attempt to modify the
 availability level which could modify the intended behavior.</t>
        </li>
        <li>
          <t>link-bandwidth: A malicious client could attempt to modify the
 link bandwidth which could either provide more or less link
 bandwidth at the indicated availability level, changing the
 resource allocation in unintended ways.</t>
        </li>
      </ul>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is asked to assign a new URI from the "IETF XML Registry"
   <xref target="RFC3688"/> as follows:</t>
      <artwork><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-bandwidth-availability-topology
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
]]></artwork>
      <t>It is proposed that IANA should record YANG module names in the "YANG
   Module Names" registry <xref target="RFC6020"/> as follows:</t>
      <artwork><![CDATA[
    Name: ietf-bandwidth-availability-topology
    Maintained by IANA?: N
    Namespace:
    urn:ietf:params:xml:ns:yang:ietf-bandwidth-availability-topology
    Prefix: bwavtopo
    Reference: RFC XXXX
]]></artwork>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8795">
          <front>
            <title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
            <author fullname="V. Beeram" initials="V." surname="Beeram"/>
            <author fullname="T. Saad" initials="T." surname="Saad"/>
            <author fullname="H. Shah" initials="H." surname="Shah"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <date month="August" year="2020"/>
            <abstract>
              <t>This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8795"/>
          <seriesInfo name="DOI" value="10.17487/RFC8795"/>
        </reference>
        <reference anchor="RFC8345">
          <front>
            <title>A YANG Data Model for Network Topologies</title>
            <author fullname="A. Clemm" initials="A." surname="Clemm"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <author fullname="N. Bahadur" initials="N." surname="Bahadur"/>
            <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8345"/>
          <seriesInfo name="DOI" value="10.17487/RFC8345"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC6242">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6242"/>
          <seriesInfo name="DOI" value="10.17487/RFC6242"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC8330">
          <front>
            <title>OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth</title>
            <author fullname="H. Long" initials="H." surname="Long"/>
            <author fullname="M. Ye" initials="M." surname="Ye"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="A. D'Alessandro" initials="A." surname="D'Alessandro"/>
            <author fullname="H. Shah" initials="H." surname="Shah"/>
            <date month="February" year="2018"/>
            <abstract>
              <t>A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word "availability" is typically used to describe such links during network planning. This document defines a new type of Generalized Switching Capability-Specific Information (SCSI) TLV to extend the Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8330"/>
          <seriesInfo name="DOI" value="10.17487/RFC8330"/>
        </reference>
        <reference anchor="RFC8453">
          <front>
            <title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
            <author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</t>
              <t>Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</t>
              <t>This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8453"/>
          <seriesInfo name="DOI" value="10.17487/RFC8453"/>
        </reference>
        <reference anchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
      </references>
    </references>
    <?line 306?>

<section anchor="examples">
      <name>Examples of the application of the Bandwidth Availability Topology Model</name>
      <t>This appendix provides some examples and illustrations of how the
   Bandwidth Availability Topology Model can be used.  There is one
   extended tree to illustrate the model and a JSON based instantiation
   for a small network example.</t>
      <section anchor="a-tree-for-a-the-bandwidth-availability-topology-model">
        <name>A tree for a the Bandwidth Availability Topology Model</name>
        <t>The tree below shows the leafs for the Bandwidth Availability Model
   including the augmented Network Topology Model defined in
   <xref target="RFC8345"/> and Traffic Engineering (TE) Topologies model defined
   in <xref target="RFC8795"/>.</t>
        <sourcecode type="yangtree" name="full-bw.tree"><![CDATA[
module: ietf-network
  +--rw networks
     +--rw network* [network-id]
        +--rw network-id                network-id
        +--rw nt:link* [link-id]
           +--rw nt:link-id               link-id
           +--rw tet:te!
              +--rw tet:te-link-attributes
                 +--rw bwatopo:link-availability* [availability]
                 |  +--rw bwatopo:availability      decimal64
                 |  +--rw bwatopo:link-bandwidth?   uint64
                 +--ro bwatopo:actual-bandwidth?    yang:gauge64
]]></sourcecode>
      </section>
      <section anchor="a-json-example">
        <name>A JSON example</name>
        <sourcecode type="json" name="exampleBwa.json" markers="false"><![CDATA[
{
  "ietf-network:networks": {
    "network": [
      {
        "network-id": "Generic-network",
        "network-types": {
          "ietf-te-topology:te-topology": {
            "ietf-eth-te-topology:eth-tran-topology": {}
          }
        },
        "node": [
          {
            "node-id": "Generic-N1",
            "ietf-network-topology:termination-point": [
              {
                "tp-id": "Generic-N1-TP1"
              }
            ]
          },
          {
            "node-id": "Generic-N2",
            "ietf-network-topology:termination-point": [
              {
                "tp-id": "Generic-N2-TP2"
              }
            ]
          }
        ],
        "ietf-network-topology:link": [
          {
            "link-id": "Generic-N1-N2",
            "source": {
              "source-node": "Generic-N1",
              "source-tp": "Generic-N1-TP1"
            },
            "destination": {
              "dest-node": "Generic-N2",
              "dest-tp": "Generic-N2-TP2"
            },
            "ietf-te-topology:te": {
              "te-link-attributes": {
      "ietf-bandwidth-availability-topology:link-availability": [
                  {
                    "availability": "0.999",
                    "link-bandwidth": "20000000"
                  }
                ]
              }
            }
          }
        ]
      }
    ]
  }
}
]]></sourcecode>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document was prepared using kramdown</t>
      <t>The authors would like to thank ...</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1aa3fbxpn+jl8xZc7ZlVIRFCX5InrbmJZkW60ka02lcU5O
PgyBITkWCKAYQDTran/7Pu9cgAFIyUpzup+Wx4lIzMx7vw/6/X4QZbFM5yNW
lbP+yyAoZZmIEeuN2c/jq3fslJecXWaxSNgsK9gbnsYrGZcLNr7jMuFTmchy
zW6yPEuy+boX8Om0EHc4/+ansX5swGgIvSDipZhnxXrEVBkHcRalfAlkccFn
ZV8KUBBFfJn3pyveL3G4v+bpvJ/glCoDmRcjVhaVKg/294/3DwJVTZdSKZml
5ToHmPOzm7cBcB8GvBB8xD5mVQnWglVW3M6LrMpH7ORkfHnNfsIDLLB39DC4
FWvsiHE+LUWRirJ/SvQEdyKtxChgjPmH6bdB14aCx0tIZMQ0B6+JmTAr5vSc
F9FixBZlmavRYBBDomXBo1tRhG7XYDUf6HMDPgXRA41Ulotq2pwzv8MoWw48
SeHghvSWq0Z4BMnI73dDyuWI/VJm0R5TWVEWYqbwbb2kL78GAa/KRVZAXH1C
KYwsPmcpVyFfJFNRzF+LQkZKZSlhpk2zKkmMAfyF9rGx2UdLkAlP5T94CeWO
2Jk9yMZvaFEBuQA/FzKNF1myVLksRMqGQ1qMYI8j9i4rxdSKHwYOFEfDF+zZ
c/O7SkuywclKxCJ9Irn9NsWTKCtLdslTNZMiiR+h+TyNPBSKzoVLd+5xJJcy
ZT+LTdjvK74Skt2IaJGS30mhfLlcZeHw5fHxHvsk1xWH1LQlN8I5WYh0HleN
bJ4Phy8Ohy3ZnCxkyj26+XIdrsVSpq8XGvlWes9LnmTsTaXkk2m24CWdDKc4
+Rj8TxI63wR9dXbCLuA4BS+zAnDZWVVkufBF8teqmFWFKkXaH6cJnwt2+LwR
yHshEZ6c7VmZHA+Hz1oieScK6G3tUf1JhhfydSoiBMJQVBv0noJIkXA2yRGP
ZjLKttCe3UrO+uz8xif3b3h2loKeNbvmxe0eGx411P5NLkVBkZTtXJ7vNhQf
7L980VYi6cOnNzb0hMrR8zol9FrWQZqBvVLeIeQFMp15v/r9PuNTRUGrDG4W
UjFE7mop0pLFYiZTSJybME+xjS11tigzLKqokFPBpnXW4H7WoITCWSLTWwZD
5wyhl0I1K202CQ3qpYzjRATBdxSgiyyuIhJd8O+hJGSQGgNg+I1c5gh0HMCj
BSfm4ayqlBHLZnqvYitEUnbHC8mniQd8j60WohBM8GjBEnEHInCkwR0BOIjh
cPxIQpGxAcRZJIAPsqjP+FSCtHHKxBcEZiDDoqqiRS1ABTlFRbbid4IVPJaZ
fu4oKRdiE3+8hpnKiCfJmvGY50QIhAVm0zklNiXnKU9gTmksSeSI9xAJySFm
0zV0BoHMAD2NBPsPNuNUR+yRKpFNRUGg5hXkhm2GgEL8vUKkjtnfK67FDh7o
uWaAlwxMF2tgTefgb5mRWsHz168/fHx78vLwcP/+3tPyUhCdUi0JTyFIUw2H
/ZZ2a2tGNC4XyNbzBfswuX7bvznbY9MK6i7JZ5KY8URlJJlKCXixNQvwD7NL
EsMSjyKhlJH9E/AhreUcpFlWnWlb04RyUpZDithPEufYXC4GIBHeDa/Mq1KD
gRhuFsIe4tWcRKNYb1uFdoMcDtdG+IAOBSwWYHduznZdjYb42LNijElXX7/+
gcT74vjZ/T1ZiwRfMKYpV1gHAw8UglfWVx+HengEqCG56oOuZ3gCRvElF5E1
QaMCWBmwCEGx4brI7iSVesSPQ37SaGbn+upkF04LHbLLKiklO82W5EoTUdxJ
GOhJBqtETkOK2Lk8nWCzNayjZ4egkbEz41iKVAXkcBKFH+UChmn9RVU5mRno
Qn2JuDgMiaycz42qca4Q8NzNgKFhcuuQMo2SilzlAYnskQAWcr7Q9mbNJeFr
USjnzbBXEc5Da7ROWJzcAmGOsIIcbVuw3ZmcV9oKSDhZXsql/Edja42NI40R
GwNlBeY8hczWRWaRavXgTxgchGxsXNeQ0Y4mn1Gmg07lMxlFWgXzOshAvjLV
CDZCTfj/fk9+j6z3HWom2mXOkxJPSRhGTNqzZiAyW2k4yADpeqnIQI1RaPl6
eRJmC0/5ljsFAbnINx3JUIeShU3Ql0VlVYhgDF3CjyTK2xiNE88XZBOkqUIo
EFD7ConFy9Kg0REMBSMXFewwHJqNHv0uEgquSbdw0IZMs8RZE5w3lhy4IQg6
6oclY1NH+zosfcc+mpRk4ukFTLJCbaiFiq6QUVuIMHv54+Smt2f+sqsP+vvH
s//+8fzj2Sl9n7wfX1zUX9yOyfsPP16cNt+akycfLi/Prk7NYTxlnUeX45/x
hzTd+3B9c/7hanzR21CkVrEJlToRQ7ylCQKu2NEcvzm5RvFo4/HBcHgMZ7LB
efjiCD/IFA2yLIXnmp8QIkwtzwUvdGmWwDV5TkU6YhBQqEW2ShnFIi3Fb0wF
uglEm41+RrYT/A8+jDpMKn4DWENFAwjdhW53tL7zpgC1rc2GbJCuRjZMKe/7
ACZPQWpQoq4udU9Qf+yzPq33eVlCaPA/pVt+9keUnpWOb/3pqoOeqj1NdvAV
nVGhEfWp5P9Tb7oKiY3evWbyNwmmSjxZWDk8SQzsK1GsRyWooMirWW8YDnuv
6DGRpVC0Eeu9qkhHBHGE2ATvGH1ZJqNUjejo6CmYDEiY2kx+YeCV0wIe0lNT
LRuCNS00JVGGtvoMLbwyT/DA1I5OJz0YJdquY0v4/QZUl4XaIHvpqtcFaWBR
+TFiT65fHsfakbaHvvy3ood9PoQZ5vsQapRzo62It5SHLZ+gT7dc9Cjzm1dz
ruemZq2K84arW/Y2K0DQDo3ldt3k7Z2BRrmVukkD4qd36OtpQvVf1KeW2ag9
Q/tzYEk8Q3GQFVvGRd7HgXh4lvPnDrQto5wt8B4b3HQhNnObLYC2TVK6ANqD
lC1A9IbwTXte0oVSj0u2AOiMLrpHt04utoB5ZKJgQdroYJJS7tmNbt+lLulM
qCPz1Ln64dqYoboq5Jc9Sw2dMI24nh/UcwPbwlNeTON2RyEterLAz1WqS17b
faPhTxXa/Ug319t9n/IkqlpnkDb5cFOyOhnaDr1pIkzJb2bJ+PRtBfctNm0d
2vT1xOu/BuNi/M4/zXSRiebE1VCrDK4NRRRUWi3hMkauls+TLF8X6EhKthPt
soP9g0M9a0cwoSqfZEJFGOpZ+AO4jSESU/9xFVg50XBYuXKN5lU0zUBZocEq
RrVhcSfQVpgDH0WMgKATsq6mgYLECTWrrKKoQk+mqEILPbxZUmtESkRNqs/T
DxTTZFqgJNIK2iObyKmWLqlSyqtCVdSrlZmpf1Q1/YweCL8NDDOaiEQKxAhx
KCZ11LK1pC6SQCfKaPx+MzmFr5m9Sti4BsJAki6djZ0dhZETQSO//0ThKeYo
keuaXDkZJLy07ZLefmpLP7u+4+b5+k5EiOY2wVLdp4Zk14lU+5urD1xZrVOE
KzWaloVyyCd8uogyFNkNmkW5TAbFLKKdu6/Atxnz0GH4iEhmJAErigq6TjSb
aYaOWKjQBoZCGKa1WfX3D/rDZy7PbcaMt7KAwZlOTl9WhFsSoJ+vBt/r5e/N
JQ2EaWT3/aC+1iEBP1zlgZQNWljPATMhhTxsuw86HhkwgG5TZ3rrX507UrPR
81ccW1uEYIKnJs5W+tpG/AmLclRgD40vsgL+lVNv3cr2rXBhRo7eILSmHdQj
trd3f23AUJkHSiK55MnzI38FaqchCCjvx3JOw4CjV/5qQSMA1tsPw+Nj/Ds+
7nnL983XluzHG0Q3p+7bFBu11prp0lwhPzz3KapSorH312muPOYfUIHOYHZ2
6U1WfVGT45JefMm18ugG+f4fI3Q01TxpmKh50Bzoun2OJCQ8PiwXU/x/oARN
VBoMZhzEZujjxDcsjEbNqoRSS+HPaRGtogo8pt7UhUIcoaPg6vFnkIcmjpks
XPf8KTIAU7kwTaqtlg/DhtKN7oDVRfXhQ0W1rkRnaHWomEMfT7HSQbzfEhNO
HSV1UKC/rqHsPa2jHPR8lf5RV+Vbmsreg0GNZG1QulBkUlnHsrbk9lpcFRUZ
DwcxGw/xz/WsJolSGu4veXGLpPCnHrKI6PkrpqF9SlsYkiHqlpdSXVUQiSfI
Y6gEClMbacmSv/gJB/qPTJ2wMdxw8z4VLcQStb6uDaEuAqNHsnquQ1PDurwz
Azr8vJPNVdKyNgR0TVmZRTQlohme1rRiV2c3Jx+u3tqRyPODo+H9PVVCH88m
/sLLfT0xMiwk2QqeUR/Vo1ndtSkziyIJIBMiuindxukNe3WZBJJiGp6R+Po0
KjPkmWOav/okIE4MtMlCIIHuTCbvdxtaD7ok1VT7NL2/ubmePBF9G/fNxYRg
WBEcHT3XQzOrSMe+nYvaYakd5tXjfxJnTnVNLIx0aHCnbImFSAkzRsVlYZCS
qQKRUZXwosbgqwOWXig9jrWDCDfgFrp+Q+mlR+2QVZMBt8FxxqB72txZqRYS
cUKDxt9qsqZpNzDqKxqwrNXgjy90D7G1u9DCUw/fo1iClPOxqOVjyLbZsnVC
zwh5nqMe1JIwEZjAuJKvw0TNNJ2j/4ALJSOqtjpqt8jbqCG1b3JjxyvQSGgH
EXpD8w3sCVNX7chQhHsuIVHs8S6fLJFAxKuk3DVGroRPxJKvyemdBEj9KHkl
3ViTou+qJAXdNKcj8VPbsPSvMe5kkaVaRQD+E92Z+GawQ7creww9SNk3FOpr
diO+Nh2u0cjpjYNC25Ut9unSaEFdG0Wjub5LJyBiNqMmAxscNQ3imlFur2w9
RNZ/pXZrxyuMYOBY1SF5pBV4bi5VnhS7e1Z15mS/lWco0aKqk5HMKrh4IsnO
7Y0JeqhlTs2S6bHWTmlsa11pVGuONvubDn0qICqZFaGlol26/Yt0dDKoT4OA
2oy6KDSZxpeGCRSGvD7ZS7+lJTimbpJa2w0m95qb84YGxDjbsCZJZvpQMkcU
aY71FV8rPUU/H1+Nt6VN/ZwGJerWJDuuKPFpu1qxHz+eG8fXGtd94qfLCxRd
c2qg170mgh8+f/mSYoKyF0YKKtcFAUCM2O8dDQcWI3XUJ2a6N9LR6vxs8i4A
SSN2NRi/ql8EQOwHN0S9edmCiK5n1aEhTHOvUxG5V0bJXQcYLRG10JqkFFDE
rSCkwbibRX1JToDMhJ1d0WIPx4x8XDbdP9jfKhvS4ZV+medJQqDtl1y6McF0
rWn9AbzXkDSDZhT0u2VOQK71NHjEpit+Rwv64UdXPo+aXt6IlN6omfLolizO
v/LWjYpJFf4N3bduMEz1/fU7+1qKurcZhJSa57Bw+aUpAHQQdjtNHkySiozG
xF3gXGQr5z1PQ23v5qkTD13qAvIsNdH2ixsB0i0lfKdGaAKsfaNCvzbwl8mH
K/vegxkElrKec5u+WC2psqiziGHE3NGODQaz78mCq2sMfXgqYHn6bs3UStQB
mqroEYAGjk5y7r0CrUpTgYCXzlWDk1uTxb0az1YNEMcTXiOxwrOAbJ71XycJ
g8fu9qwYA33VVqycWO1wq/Xse/aLq5Vk/Gvdb7X2YIV1Ps1K94jp4ABW5xkf
ZnfPJlj7dPOEafz+0JmU+2vdprCztd5tL9ZGGwMjUOz//HUTwD+7MFp5Sn/q
Wc0TTrfz8A/YYqYm2ynPGqyduQWdbI0rHrg+pTlhv32HOjaOab3NWNRnBbek
hrrnm1LdrfdGttvu2Sd48IsluZkC9Rr7wHrvnUjpTscB6+1tbtQ3mjVwu9i9
pRt53zt73W6BgO6f0L+ROVvnvAGYNwy798mC/3mctbmrd3TYuxp6nDUkdXuR
UalfOtEBsJ9nUHoH0yY2DazMN/D1b66Hvc7O+9Zv347v934bOwf/x+wcgJ2D
38BO/f1XT3PbaSRne1yfNvZ05LspA1NzblhfvdK3pvOwVTRby/xb6rzvYI9p
cGhkvY0EWt4koMuD29hBv0X8XfRbHHIbGVtmdM2uJ7VOm/F5i1HRZ9OwNI7O
yd4+DcE3xGA3tyMxbT/YN5+uMWqZbDzr5or2ju3Bxp0xT+jXfXD/QOS28fnN
iocUnRG8H5gz6uHzlkHjJgCCkFZ0Gylid+4eZes4uk2zVSLieX0b1n4XfEVv
3xUCVbWge0OqXW5RYMfZKq0rLncludJdRCJv7XiEo2cMwzD4X+BDz3kbNQAA

-->

</rfc>
