<?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.6.26 (Ruby 2.7.0) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ccamp-bwa-topo-yang-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <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-00"/>
    <author initials="J." surname="Ahlberg" fullname="Jonas Ahlberg">
      <organization>Ericsson</organization>
      <address>
        <email>jonas.ahlberg@ericsson.com</email>
      </address>
    </author>
    <author initials="S." surname="Mansfield" fullname="Scott Mansfield">
      <organization>Ericsson</organization>
      <address>
        <email>scott.mansfield@ericsson.com</email>
      </address>
    </author>
    <author initials="M." surname="Ye" fullname="Min Ye">
      <organization>Huawei Technologies</organization>
      <address>
        <email>amy.yemin@huawei.com</email>
      </address>
    </author>
    <author initials="I." surname="Busi" fullname="Italo Busi">
      <organization>Huawei Technologies</organization>
      <address>
        <email>italo.busi@huawei.com</email>
      </address>
    </author>
    <author initials="X." surname="Li" fullname="Xi Li">
      <organization>NEC Laboratories Europe</organization>
      <address>
        <email>xi.li@neclab.eu</email>
      </address>
    </author>
    <author initials="D." surname="Spreafico" fullname="Daniela Spreafico">
      <organization>Nokia - IT</organization>
      <address>
        <email>daniela.spreafico@nokia.com</email>
      </address>
    </author>
    <date year="2023" month="March" day="06"/>
    <area>Routing</area>
    <workgroup>ccamp</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <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>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang"/>.</t>
    </note>
  </front>
  <middle>
    <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>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.</li>
        <li>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.</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>availability: A malicious client could attempt to modify the
 availability level which could modify the intended behavior.</li>
        <li>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.</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>
        <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">
              <organization/>
            </author>
            <author fullname="I. Bryskin" initials="I." surname="Bryskin">
              <organization/>
            </author>
            <author fullname="V. Beeram" initials="V." surname="Beeram">
              <organization/>
            </author>
            <author fullname="T. Saad" initials="T." surname="Saad">
              <organization/>
            </author>
            <author fullname="H. Shah" initials="H." surname="Shah">
              <organization/>
            </author>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <author fullname="J. Medved" initials="J." surname="Medved">
              <organization/>
            </author>
            <author fullname="R. Varga" initials="R." surname="Varga">
              <organization/>
            </author>
            <author fullname="N. Bahadur" initials="N." surname="Bahadur">
              <organization/>
            </author>
            <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan">
              <organization/>
            </author>
            <author fullname="X. Liu" initials="X." surname="Liu">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund">
              <organization/>
            </author>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder">
              <organization/>
            </author>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
              <organization/>
            </author>
            <author fullname="K. Watsen" initials="K." surname="Watsen">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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>
        <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">
              <organization/>
            </author>
            <author fullname="M. Ye" initials="M." surname="Ye">
              <organization/>
            </author>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky">
              <organization/>
            </author>
            <author fullname="A. D'Alessandro" initials="A." surname="D'Alessandro">
              <organization/>
            </author>
            <author fullname="H. Shah" initials="H." surname="Shah">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger">
              <organization/>
            </author>
            <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>
    <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+1aa3Pbxrn+zl+xRWZ6pFSErnEjum1MS7KtHEnWEZWJM5nM
mSWwJNcCARQLiGZVnt9+nncvwAIkbbmd9lM5TkRid9/7fdHv93ulLBMxYMGQ
/TK8ecvOecnZdRaLhE2ygr3mabyQcTljw0cuEz6WiSyX7D7LsySbLoMeH48L
8Yjzr38e6scGjIYQ9OIsSvkc4OOCT8q+FOWkH0V8nvfHC94vsb2/5Om0n/BS
qLIX4c80K5YDpsq4J/NiwMqiUuXRwcHpwVGPF4IP2F1WlTKd9hZZ8TAtsiof
MA2y9yCWeBYP2GVaiiIVZf+csPZUCSb+lydZCkKWQvVyOWC/llm0x1RWlIWY
KHxbzunLb70oS5VIVaU0btHr8aqcZcWgx/o9xphMsfBjyIazZCyKKT0yHP6Y
pVz5j7NiylP5N17KLB2wi0JGSmUprYg5RDlgH+lEyM2JV8JuCKNs7uMaheya
p2oiRRI32EZRVpbthS/iU3QmnLszWzFeh+wX0aC6lqn93cbwruILIdm9iGYp
GYOEZBtkfL4Ml2Iu01czva+L5DJkryslGzSXJTRUP/saVJJOhmOc3ILrQ8iu
PEwfpP3ZRnJzccau+DgreJkVwMAuqiLLhYfokwwT+SoVEfwgFJWP4jxkoxzm
OZFR1mA6B3iR8PZSB2v2IDnrs8t7D1FszoXKnXuV0jbNVy/NijkOP4pBryfT
ifer3+8zPlZlwaOydz+TisH/qrlISxaLiUzBEzfuGZOXz7WXlxkWVVTIsWDj
2tu57+0UCDhLZPoAZvENrkXOx0obBUKDei7jOIHDfEMOWGRxFRGLvX8NJSGD
xTAA5imT8xx+zAE8mnFiHpatShmxbKL3KraQgPTIC8nHiQd8jy1mohBM8GjG
EvEIInCkwR0BOIjh8JJIIjbFBhBnkQA+yKI+41MJ0oYpE58Qk4AMi6qKZrUA
FeQUFdmCPwpW8Fhm+rmjpJyJdfzxEuYkI54kS8ZjnhMhEBaYTaeIhEzJacoT
hsgVSxI5whlEQnKI2XgJnUEgE0BPI8F+zyZAmk73SJWIlqIgUNMKcsM2Q0Ah
/lrJAof/WnEtdvBAzzUDvGRgulgCazoFf/OM1Aqen55+uHtz9v3x8cFq5Wl5
LohOqeaEpxCkqYbDfku7tTVnKfAhtE9n7P3o9k3//mKPjSuoGxrOqiRmPFEZ
SaZSYlIl1izAP8wuSQxLPIqEUkb2z8CH2J1zkGZZdaZtTRPKSVkOKWI/SZxj
cznbB4mlAN55XpUaDMRwPxP2EK+mJBrFgk2Z9R65Ca7NLkiHAhYLsDv3F7su
tyICBVaMMenq6el3JN4/nn63WpG1SPAFYxpzhXUwsCWB31hf/TzU4xNADclV
t7qe4QkYxadcRNYEjQpgZcAiBMWG2yJ7lAqiIH4c8rNGMzu3N2e7cFrokF1X
SSnZeTYnVxqJ4lHCQM8yWKVMKQjvXJ+PsNka1sl3x6CRsQvjWIpUBeRwEoUf
5QyGaf1FVTmZGehCxYC4eBgSWTmfGlXjXCHguesBQ8Pk1iFlGiUVucoWieyR
AGZyOtP2Zs0l4UtRKOfNsFcRTkNrtE5YnNwCYY6wghxtW7DdiZxW2gpIOFle
yrn8W2NrjY0j/xAb+8oKzHkKma2LzCLV6sGfsHeEYsW4riGjHU0+orwCncpn
Moq0CqZ1kIF8ZaoRrIWa8D9+T36PrPcN6hPaZc6TEs9JGEZM2rMmIDJbaDjI
AOlyrshAjVFo+Xp5EmYLT/mSO/V65CJfdCRDXYHwPkJNG5VVIXpD6BJ+JFEL
xmxa8HxGNkGaKgQK4LL2FRKLl6VBoyMYCkYuKthxeGg2evS7SCi4Jt3CQZU9
zhJnTXDeWHLghiDoqB+WjE2dHOiw9A27MynJxNMrmGTFp0ILFVU/o7IfYfb6
p9F9sGf+spv3+vvdxf/8dHl3cU7fR++GV1f1F7dj9O79T1fnzbfm5Nn76+uL
m3NzGE9Z59H18Bf8IU0H72/vL9/fDK+CNUVqFZtQqRMxxFuaIOCKHc3x67Nb
dnhi4/HR4eEpnMkG58M/nuAHmaJBlqXwXPMTQoSp5bnghS7NErgmz6kgRgwC
CjXLFimjWKSl+IVurptAtNnoZ2Q7vf/Dh1G7VtIvWENFjaPu6TY7Wt95Uw+1
rc2GbD9dDGyYUt73fZg8Ban9UpSDUlfd9cc+69N6n5clhAb/UwO96Q8oPSsd
39BTdtBTtafJ7j2hIyk0oj6V5n8OxouQ2AhWmsmvEkyVeLKwcniWGNgTUawb
XlRQ5NUsOAwPg5euY1Ao2oj1oCrSAUEcIDbBOwaf5skAbQYdHTwHkwEJU5vI
Twy8clrAQ92v6GrZEKxpKZc5IvaTEbk9QwsvzRM8MLWj00kAo2QvTk8t4as1
qC4LtUEG6SLogjSwqPwYsGfXL5/H2pG2h778l6KHfW7DDPPdhhrl3GAj4g3l
Ycsn6NMtFz3K/CbTnAvcVKRVcd5z9cDeZAUI2rm8uH+zy87Ohte37Oe3Bhrl
VuomDYif36JzVuWA/Yn61DIb6MHLK+I/BMa/9CyJFygOsmLDTMT7OBDbpyB/
6UDbMPPYAO9zU44uxGa0sQHQpglGF0B7aLEBiN4Qvm7PJrpQ6oHEBgAfZHjl
zRy6RzdOGDaA+cxEwYK00cEkpdyzG92+S13SmVBH5qlz9fbamKG6KuSnPUsN
nTCNuJ4f1HMD28JTXkzjdkchLXqywI9Vqkte232nNHJBux/p5nqz71OeRFXr
DNImH25KVidD26E3TYQp+cXAbujbCu5LbNo6tOnridd/DMbV8K1/mukiE82J
q6EWGVwbiiiotJrDZYxcLZ9nWb4s0JGUbCfaZUcHR8eMnBrBhKp8kgkVYahn
4Q/gNoZITP3HVc/KiWadypVrEcIRTTNQVmiwilFtWDwKtBXmwJ2IERB0QtbV
NFCQOKFmlVUUVejJGFVooYc3c2qNSImoSfV5+oFimkwLlERaQXtkEznV0iVV
SnlVqIp6tTIz9Y+qxh/RA+G3gWFGE5FIgRghDsWkjlq2ltRFEuhEGY3fr0fn
8DWzVwkb10AYSNKls7GzkzByImjk918oPMUUJXJdkysng4SXtl3S289t6WfX
d2ZlmavB/r6eZQsRuni5b6nuU0Oy60Sq/c3VB66s1inClRpNy0I55AM+XUQZ
iuwGzaycJ/vFJKKduy/Btxnz0GH4iEgmJAErigq6TjSbaYaOWKjQBoZCGKa1
WfUPjvqH37k8tx4z3sgCBmc6OT36DzckQD9f7X+rl79lb2miD2Ea2X27T3+m
9tlnqjyQskYLCxwwE1LIwzb7oOORAQPoNnWmt/7k3JGajcBfcWxtEIIJnpo4
W+lrG/EnLMpRgT00vsgK+FdOvXUr27fChRk5eoPQmnZQj9je3v3UgKEyD5RE
cs6TFyf+CtROQxBQ3o/llIYBJy/91YJGACw4CMPTU/w7PQ285VXztSX74RrR
zalVm2Kj1lozXZor5IcXPkVVSjQG/z3Olcf8FhXoDGZnl95k1Rc1OS7pxZdc
K4+uke//MUJHU82ThomaB82BrtunSELC48NyMcb/95WgiUqDwYyD2AR9nPiC
hdGoWZVQain8OS2iVVSBx9SbulCII3QUXD3+DPLQxDGTheueP0UGYCoXpkm1
1fJx2FC61h2wuqg+3lZU60p0glaHijn08RQrHcTVhphw7iipgwL9dQ1l8LyO
cj/wVfoHXZVvaCqDrUGNZG1QulBkUlnHsjbk9lpcFRUZ24OYjYf453pWk0Qp
DffnvHhAUvhzQLeSgb9iGtrntIUhGaJueSnVVQWReIY8hkqgMLWRliz5i59w
oP/I1Alrww0371PRTMxR6+vaEOoiMHokq+c6NDWsyzszoMPPR9lcJc1rQ0DX
lJVZRFMimuFpTSt2c3F/9v7mjR2JvDg6OVytqBK6uxj5C98f6ImRYSHJFvCM
+qgezequTZlZFEkAmRDRTek2Tm/Yq8skkBTT8IzE16dRmSHPHNP81ScBcWSg
jWYCCXRnNHq329B61CWpptqn6d39/e3omejbuO+vRgTDiuDk5IUemllFOvbt
XNQOS+0wrx7/kzhzqmtiYaRDgztlSyxESpgxKi4Lg5RMFYiMqoQXNQZfHbD0
QulxrB1EuAG30PUbSi89aoesmgy4CY4zBt3T5s5KtZCIExo0fq3JmqbdwKiv
aMCyVoM/vtA9xMbuQgtPbb9HsQQp52NRy8eQbbN564SeEfI8Rz2oJWEiMIFx
JV+HiZppOkf/ARdKRlRtddRukbdWQ2rf5MaOF6CR0O5H6A3NN7AnTF21I0MR
7rmERLHHu3yyRAIRr5Jy1xi5Ej4Rc74kp3cSIPWj5JV0Y02KfqySFHTTnI7E
T23D3L/GeJRFlmoVAfjPdGfim8EO3a7sMfQgZd9QuKsdM3PT5YYO12jkdKdf
aLuyxT5dGs2oa6NoNNV36QRETCbUZGCDo6ZBXDPK7ZWth8j6r9Ru7XiFEew7
VnVIHmgFXppLlWfF7sCqzpzst/IMJVpUdTKSWQUXTyTZub0xQQ81z6lZMj3W
0imNbawrjWrN0WZ/06GPBUQlsyK0VLRLt3+Qjk4G9WkQUJtRF4Um0/jSMIHC
kNcne+m3tATH1E1Sa7vG5F5zc97QgBhnG9YkyUwfSuaIIs2xvuBLpafol8Ob
4aa0qZ/ToEQ9mGTHFSU+bVcL9tPdpXF8rXHdJ364vkLRNaUGehk0Efz4xfff
U0xQ9sJIQeW6IACIAftnR8M9i5E66jMz3RvoaHV5MXrbA0kDdrM/fFm/CIDY
D26IevOyBRFdz6pDQ5jmXqcicq+MkrsOMFoiaqY1SSmgiFtBSINxN4v6kpwA
mQk7u6HFAMeMfFw2PTg62Cgb0uGNfunmWUKg7ddcujHBeKlp/QG815A0g2YU
9E/LnIDc6mnwgI0X/JEW9MM7Vz4Pml7eiJTeqBnz6IEszr/y1o2KSRX+Dd2X
bjBM9f30jX0tRa1sBiGl5jksXH5qCgAdhN1OkweTpCKjMXEXOGfZwnnP81Db
u3nqxEOXuoA8S020/eRGgHRLCd+pEZoAa9+o0K8N/Dh6f2PfezCDwFLWc27T
F6s5VRZ1FjGMmDvaocFg9j1bcHWNoQ+PBSxP362ZWok6QFMVfQaggaOTnHuv
QKvSVCDgpXPV4OTWZHGvxrNVA8TxjNdIrPAsIJtn/ddJwt7n7vasGHv6qq1Y
OLHa4Vbr2bfsV1cryfi3ut9q7cEK63yale4R08EBrM4zPszunnWw9un6CdP4
/a4zKffXuk1hZ2u9216sDdYGRqDY//nbOoC/d2G08pT+1LOaZ5xu5+EfsMVM
TTZTnjVYO3MLOtkaV2y5PqU5Yb99hzo0jmm9zVjUR3oDlRrqwDelulsPBrbb
DuwTPPjVktxMgYLGPrAevBUp3ek4YMHe+kZ9o1kDt4vdW7qB972z1+0WCOj+
Cf0bmbN1zhuAecOwlU8W/M/jrM1dvaPD3s2hx1lDUrcXGZT6pRMdAPt5BqV3
MK1j08DKfA1f//72MOjsXLV++3a82vs6do7+zewcgZ2jr2Cn/v6bp7nNNJKz
fV6fNvZ05LsuA1NzrllfvdK3prPdKpqtZf4lda462GMaHBpZbyKBltcJ6PLg
NnbQbxB/F/0Gh9xExoYZXbPrWa3TenzeYFT0WTcsjaNzMjigIfiaGOzmdiSm
7UcH5tM1Ri2TtWfdXNHesTnYuDPmCf1a9VZbIreNz68XPKTojOC9Zc6oh88b
Bo3rAAhCWtFtpIjduRXK1mH0kGaLRMTT+jas/S74gt6+KwSqakH3hlS7PKDA
jrNFWldc7kpyobuIRD7Y8QhHzxiGYe//AaxUQUDEMgAA

-->

</rfc>
