<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-ietf-i2rs-yang-l3-topology-14.txt"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc compact="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="draft-ietf-i2rs-yang-l3-topology-14.txt">A YANG Data Model for
    Layer 3 Topologies</title>

    <author fullname="Alexander Clemm" initials="A." surname="Clemm">
      <organization>Huawei</organization>

      <address>
        <email>ludwig@clemm.org</email>
      </address>
    </author>

    <author fullname="Jan Medved" initials="J." surname="Medved">
      <organization>Cisco</organization>

      <address>
        <email>jmedved@cisco.com</email>
      </address>
    </author>

    <author fullname="Robert Varga" initials="R." surname="Varga">
      <organization>Pantheon Technologies SRO</organization>

      <address>
        <email>robert.varga@pantheon.tech</email>
      </address>
    </author>

    <author fullname="Xufeng Liu" initials="X." surname="Liu">
      <organization>Jabil</organization>

      <address>
        <email>Xufeng_Liu@jabil.com</email>
      </address>
    </author>

    <author fullname="Hariharan Ananthakrishnan" initials="H."
            surname="Ananthakrishnan">
      <organization>Packet Design</organization>

      <address>
        <email>hari@packetdesign.com</email>
      </address>
    </author>

    <author fullname="Nitin Bahadur" initials="N." surname="Bahadur">
      <organization>Bracket Computing</organization>

      <address>
        <email>nitin_bahadur@yahoo.com</email>
      </address>
    </author>

    <date day="13" month="December" year="2017"/>

    <abstract>
      <t>This document defines a YANG data model for layer 3 network
      topologies.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document introduces a YANG <xref target="RFC7950"/> <xref
      target="RFC6991"/>
      data model for Layer 3 network topologies, specifically Layer 3 Unicast. 
      The model
      allows an application to have a holistic view of the topology of a Layer
      3 network, all contained in a single conceptual YANG datastore. 
      The data
      model builds on top of, and augments, the data model for network
      topologies defined in 
      <xref target="I-D.draft-ietf-i2rs-yang-network-topo"/>.</t>

      <t>This document also shows how the  model 
      can be further refined to cover different 
      Layer 3 Unicast topology types.  For this purpose, an example model is
      introduced that covers OSPF <xref
      target="RFC2328"/>.  This example is intended purely for illustrative purpose;
      we expect that a complete OSPF model will be more comprehensive
      and refined than the example shown here. </t>

      <t>There are multiple applications for a topology data model.  
      A number of 
      use cases have been defined in section 6 of
      <xref target="I-D.draft-ietf-i2rs-usecase-reqs-summary"/>.
      For example,
      nodes within the network can use the data model to capture their
      understanding of the overall network topology and expose it to a network
      controller. A network controller can then use the instantiated topology
      data to compare and reconcile its own view of the network topology with
      that of the network elements that it controls. Alternatively, nodes
      within the network could propagate this understanding to compare and
      reconcile this understanding either amongst themselves or with help of a
      controller. Beyond the network element itself, a network controller
      might even use the data model to represent its view of the topology that
      it controls and expose it to applications north of itself.
      </t>

      <t>The data model for Layer 3 Unicast topologies 
      defined in this document 
      is specified  
      in a YANG module "ietf-l3-unicast-topology".   
      To do so, it augments the general network
          topology model defined in 
          <xref target="I-D.draft-ietf-i2rs-yang-network-topo"/> with
          information specific to Layer 3 Unicast. This way, the general 
          topology model is extended to be able to meet the needs
          of Layer 3 Unicast topologies.</t>

        <t>Information that is kept in the 
        Traffic Engineering Database (TED) will be 
        specified in a separate model 
        <xref target="I-D.draft-ietf-teas-yang-te-topo"/> 
        and outside the scope of this 
        specification.</t>
    </section>

   <section title="Key Words">
   <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 title="Definitions and Acronyms">
    
      <t>As this document defines a YANG data model, in this document many 
      terms are used that have been defined in conjunction 
      with YANG <xref target="RFC7950"/> 
      and NETCONF <xref target="RFC6241"/>.  Some terms, such as
      datastore and data tree, are repeated here for clarity and to 
      put them in context.</t>
      
      <t>Datastore: A conceptual place to store and access information.  A
      datastore might be implemented, for example, using files, a
      database, flash memory locations, or combinations thereof.  A
      datastore maps to an instantiated YANG data tree. (Definition adopted from <xref target="I-D.draft-ietf-netmod-revised-datastores"/>)</t>

      <t>Data subtree: An instantiated data node and the data nodes that are
      hierarchically contained within it.</t>

      <t>IGP: Interior Gateway Protocol</t>

      <t>IS-IS: Intermediate System to Intermediate System protocol</t>

      <t>LSP: Label Switched Path</t>

      <t>NETCONF: Network Configuration Protocol</t>
      
      <t>NMDA: Network Management Datastore Architecture</t>

      <t>OSPF: Open Shortest Path First, a link state routing protocol</t>

      <t>URI: Uniform Resource Identifier</t>

      <t>SRLG: Shared Risk Link Group</t>

      <t>TED: Traffic Engineering Database</t>

      <t>YANG: YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network
management protocols <xref target="RFC7950"/>
</t>
    </section>

      <section anchor="model-structure-overview" title="Model Structure">
        <t>The Layer 3 Unicast topology model is defined by YANG module
        "l3-unicast-topology".  The relationship of this module with 
        other YANG modules is roughly depicted in the figure below.  
        </t>
        
        <figure align="center" anchor="model-structure"
                title="Overall model structure">
          <artwork align="left">

        +-----------------------------+
        |  +-----------------------+  |
        |  |      ietf-network     |  |
        |  +----------^------------+  |
        |             |               |
        |  +-----------------------+  |
        |  | ietf-network-topology |  |
        |  +----------+------------+  |
        +-------------^---------------+
                      |
                      |
          +-----------^-------------+
          |   L3-UNICAST-TOPOLOGY   |
          +----+------^--------+----+
                      |
                      |
              +-------^-------+
              | ospf-topology |
              +---------------+
            </artwork>
        </figure>

        <t>YANG modules "ietf-network" and "ietf-network-topology" 
        collectively define the basic network topology
        model. YANG module "ietf-l3-unicast-topology" augments those models 
        with additional definitions needed to represent Layer 3 Unicast
        topologies. This module in turn can be augmented by YANG modules with
        additional definitions  for specific types of Layer 3 Unicast topologies, 
        such as OSPF and for IS-IS topologies.  </t>
        <t>
        The YANG modules ietf-network and ietf-network-topology are designed to be used 
        in conjunction with implementations that support the Network Management 
        Datastore Architecture (NMDA) defined in <xref target="I-D.draft-ietf-netmod-revised-datastores"/>.  
        Accordingly, the same is true for the  YANG modules that augment it. 
        In order to allow implementations to use the model even in cases when NMDA is not 
        supported, companion YANG modules (that SHOULD NOT be supported by implementations 
        that support NMDA) are defined in an Appendix, see <xref target="yang-state-models"/>.         
        </t>
        
        </section>
        <section title="Layer 3 Unicast Topology Model Overview">
        <t>The Layer 3 Unicast topology model is defined by YANG module
        "ietf-l3-unicast-topology".  Its structure is depicted in the following
        diagram. The notation syntax 
        follows <xref target="I-D.draft-ietf-netmod-yang-tree-diagrams"/>.  For purposes of brevity, notifications are not depicted.  
        </t>
        <figure align="center">
          <artwork align="left"> 
module: ietf-l3-unicast-topology
  augment /nw:networks/nw:network/nw:network-types:
    +--rw l3-unicast-topology!
  augment /nw:networks/nw:network:
    +--rw l3-topology-attributes
       +--rw name?   string
       +--rw flag*   l3-flag-type
  augment /nw:networks/nw:network/nw:node:
    +--rw l3-node-attributes
       +--rw name?        inet:domain-name
       +--rw flag*        node-flag-type
       +--rw router-id*   inet:ip-address
       +--rw prefix* [prefix]
          +--rw prefix    inet:ip-prefix
          +--rw metric?   uint32
          +--rw flag*     prefix-flag-type
  augment /nw:networks/nw:network/nt:link:
    +--rw l3-link-attributes
       +--rw name?      string
       +--rw flag*      link-flag-type
       +--rw metric1?   uint64
       +--rw metric2?   uint64
  augment /nw:networks/nw:network/nw:node/nt:termination-point:
    +--rw l3-termination-point-attributes
       +--rw (termination-point-type)?
          +--:(ip)
          |  +--rw ip-address*       inet:ip-address
          +--:(unnumbered)
          |  +--rw unnumbered-id?    uint32
          +--:(interface-name)
             +--rw interface-name?   string
          </artwork>
        </figure>

        <t>The module augments the original ietf-network and 
        ietf-network-topology modules as
        follows: <list style="symbols">
            <t>A new network topology type is introduced,
            l3-unicast-topology.  The corresponding container 
            augments the network-types of the ietf-network module. </t>

            <t>Additional topology attributes are introduced, defined in a
            grouping, which augments the "network" list of the network
            module. The attributes include a name for the topology, as well as a
            set of flags (represented through a leaf-list). Each type of flag
            is represented by a separate identity. This allows to introduce
            additional flags in augmenting modules using additional identities 
            without needing to revise this module.</t>

            <t>Additional data objects for nodes are introduced by augmenting
            the "node" list of the network module. New objects
            include again a set of flags, as well as a list of prefixes. Each
            prefix in turn includes an ip prefix, a metric, and a
            prefix-specific set of flags.</t>

            <t>Links (in the ietf-network-topology module) are augmented 
            with a set of parameters as well, allowing
            to associate a link with a link name, another set of flags, and a
            link metric.</t>

            <t>Termination points (in the ietf-network-topology module as well) 
            are augmented with a choice of IP address, 
            identifier, or name.</t>
          </list></t>

        <t>In addition, the module defines a set of notifications to alert
        clients of any events concerning links, nodes, prefixes, and
        termination points. Each notification includes an indication of the
        type of event, the topology from which it originated, and the affected
        node, or link, or prefix, or termination point. In addition, as a
        convenience to applications, additional data of the affected node, or
        link, or termination point (respectively) is included. While this
        makes notifications larger in volume than they would need to be, it
        avoids the need for subsequent retrieval of context information, which
        also might have changed in the meantime.</t>
      </section>

    <section title="Layer 3 Unicast Topology YANG Module">
      <t><figure>
          <artwork>
&lt;CODE BEGINS&gt; file "ietf-l3-unicast-topology@2017-12-13.yang"
module ietf-l3-unicast-topology {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology";
  prefix "l3t";
  import ietf-network {
    prefix "nw";
  }
  import ietf-network-topology {
    prefix "nt";
  }
  import ietf-inet-types {
    prefix "inet";
  }
  organization
    "IETF I2RS (Interface to the Routing System) Working Group";
  contact
    "WG Web:    &lt;http://tools.ietf.org/wg/i2rs/&gt;
     WG List:   &lt;mailto:i2rs@ietf.org&gt;
     Editor:    Alexander Clemm
                &lt;mailto:ludwig@clemm.org&gt;
     Editor:    Jan Medved
                &lt;mailto:jmedved@cisco.com&gt;
     Editor:    Robert Varga
                &lt;mailto:robert.varga@pantheon.tech&gt;
     Editor:    Xufeng Liu
                &lt;mailto:xliu@kuatrotech.com&gt;
     Editor:    Nitin Bahadur
                &lt;mailto:nitin_bahadur@yahoo.com&gt;
     Editor:    Hariharan Ananthakrishnan
                &lt;mailto:hari@packetdesign.com&gt;";
  description
    "This module defines a model for Layer 3 Unicast 
     topologies.
     Copyright (c) 2017 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 Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).
     This version of this YANG module is part of
     draft-ietf-i2rs-yang-l3-topology-14;
     see the RFC itself for full legal notices.
     NOTE TO RFC EDITOR: Please replace above reference to
     draft-ietf-i2rs-yang-l3-topology-14 with RFC
     number when published (i.e. RFC xxxx).";
  revision "2017-12-13" {
    description
      "Initial revision.
       NOTE TO RFC EDITOR: Please replace the following reference
       to draft-ietf-i2rs-yang-l3-topology-14 with
       RFC number when published (i.e. RFC xxxx).";
    reference
      "draft-ietf-i2rs-yang-l3-topology-14";
  }
  
  identity flag-identity {
    description "Base type for flags";
  }
  
  typedef l3-event-type {
    type enumeration {
      enum "add" {
        description
          "An Layer 3 node or link or prefix or termination-point has
          been added";
      }
      enum "remove" {
        description
          "An Layer 3 node or link or prefix or termination-point has
          been removed";
      }
      enum "update" {
        description
          "An Layer 3 node or link or prefix or termination-point has
          been updated";
      }
    }
    description "Layer 3 Event type for notifications";
  } 

  typedef prefix-flag-type {
    type identityref {
      base "flag-identity";
    }
    description "Prefix flag attributes";
  }

  typedef node-flag-type {
    type identityref {
      base "flag-identity";
    }
    description "Node flag attributes";
  }

  typedef link-flag-type {
    type identityref {
      base "flag-identity";
    }
    description "Link flag attributes";
  }

  typedef l3-flag-type {
    type identityref {
      base "flag-identity";
    }
    description "L3 flag attributes";
  }

  grouping l3-prefix-attributes {
    description
      "L3 prefix attributes";
    leaf prefix {
      type inet:ip-prefix;
      description
        "IP prefix value";
    }
    leaf metric {
      type uint32;
      description
        "Prefix metric";
    }
    leaf-list flag {
      type prefix-flag-type;
      description
        "Prefix flags";
    }
  }
  grouping l3-unicast-topology-type {
    description "Identify the topology type to be L3 unicast.";
    container l3-unicast-topology {
      presence "indicates L3 Unicast Topology";
      description
        "The presence of the container node indicates L3 Unicast
        Topology";
    }
  }
  grouping l3-topology-attributes {
    description "Topology scope attributes";
    container l3-topology-attributes {
      description "Containing topology attributes";
      leaf name {
        type string;
        description
          "Name of the topology";
      }
      leaf-list flag {
        type l3-flag-type;
        description
          "Topology flags";
      }
    }
  }
  grouping l3-node-attributes {
    description "L3 node scope attributes";
    container l3-node-attributes {
      description
        "Containing node attributes";
      leaf name {
        type inet:domain-name;
        description
          "Node name";
      }
      leaf-list flag {
        type node-flag-type;
        description
          "Node flags";
      }
      leaf-list router-id {
        type inet:ip-address;
        description
          "Router-id for the node";
      }
      list prefix {
        key "prefix";
        description
          "A list of prefixes along with their attributes";
        uses l3-prefix-attributes;
      }
    }
  }
  grouping l3-link-attributes {
    description
      "L3 link scope attributes";
    container l3-link-attributes {
      description
        "Containing link attributes";
      leaf name {
        type string;
        description
          "Link Name";
      }
      leaf-list flag {
        type link-flag-type;
        description
          "Link flags";
      }
      leaf metric1 {
        type uint64;
        description
            "Link Metric 1";
      }
      leaf metric2 {
        type uint64;
        description
            "Link Metric 2";
      }
    }
  }
  grouping l3-termination-point-attributes {
    description "L3 termination point scope attributes";
    container l3-termination-point-attributes {
      description
        "Containing termination point attributes";
      choice termination-point-type {
        description
          "Indicates the termination point type";
        case ip {
          leaf-list ip-address {
            type inet:ip-address;
            description
              "IPv4 or IPv6 address.";
          }
        }
        case unnumbered {
          leaf unnumbered-id {
            type uint32;
            description
              "Unnumbered interface identifier.  
               The identifier will correspond to the ifIndex value 
               of the interface, i.e. the ifIndex value of the 
               ifEntry that represents the interface in 
               implementations where the Interfaces Group MIB 
               (RFC 2863) is supported."; 
            reference 
              "RFC 2863: The Interfaces Group MIB";
          }
        }
        case interface-name {
          leaf interface-name {
            type string;
            description 
              "A name of the interface.  The name can (but does not 
               have to) correspond to an interface reference of a 
               containing node's interface, i.e. the path name of a
               corresponding interface data node on the containing 
               node reminiscent of data type if-ref defined in 
               RFC 7223. It should be noted that data type if-ref of 
               RFC 7223 cannot be used directly, as this data type 
               is used to reference an interface in a datastore of 
               a single node in the network, not to uniquely 
               reference interfaces across a network.";
          }
        }
      }
    }
  } 
  augment "/nw:networks/nw:network/nw:network-types" {
    description
      "Introduce new network type for L3 unicast topology";
    uses l3-unicast-topology-type;
  }
  augment "/nw:networks/nw:network" {
    when "nw:network-types/l3t:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description
        "L3 unicast for the network as a whole";
    uses l3-topology-attributes;
  }
  augment "/nw:networks/nw:network/nw:node" {
    when "../nw:network-types/l3t:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description
        "L3 unicast node level attributes ";
    uses l3-node-attributes;
  }
  augment "/nw:networks/nw:network/nt:link" {
    when "../nw:network-types/l3t:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description
      "Augment topology link attributes";
    uses l3-link-attributes;
  }
  augment "/nw:networks/nw:network/nw:node/"
         +"nt:termination-point" {
    when "../../nw:network-types/l3t:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description "Augment topology termination point configuration";
    uses l3-termination-point-attributes;
  }
  notification l3-node-event {
    description
      "Notification event for L3 node";
    leaf l3-event-type {
      type l3-event-type;
      description
        "Event type";
    }
    uses nw:node-ref;
    uses l3-unicast-topology-type;
    uses l3-node-attributes;
  }
  notification l3-link-event {
    description
      "Notification event for L3 link";
    leaf l3-event-type {
      type l3-event-type;
      description
        "Event type";
    }
    uses nt:link-ref;
    uses l3-unicast-topology-type;
    uses l3-link-attributes;
  }
  notification l3-prefix-event {
    description
      "Notification event for L3 prefix";
    leaf l3-event-type {
      type l3-event-type;
      description
        "Event type";
    }
    uses nw:node-ref;
    uses l3-unicast-topology-type;
    container prefix {
      description
        "Containing L3 prefix attributes";
      uses l3-prefix-attributes;
    }
  }
  notification termination-point-event {
    description
      "Notification event for L3 termination point";
    leaf l3-event-type {
      type l3-event-type;
      description
        "Event type";
    }
    uses nt:tp-ref;
    uses l3-unicast-topology-type;
    uses l3-termination-point-attributes;
  }
}

&lt;CODE ENDS&gt; 
        </artwork>
        </figure></t>
    </section>


    <section title="Interactions with Other YANG Modules">
    <t>
    As described in section <xref target="model-structure-overview"/>, 
    the model builds on top of, and augments, the YANG modules defined in 
    <xref target="I-D.draft-ietf-i2rs-yang-network-topo"/>.  Specifically, 
    module ietf-l3-unicast-topology augments modules "ietf-network" and 
    "ietf-network-topology".  In addition, the model makes use of data types 
    that have been defined in <xref target="RFC6991"/>.  
    </t>
    <t>
    The model defines a protocol independent YANG data model with 
    layer 3 topology information.  
    It is separate from and not linked with data models that are used to 
    configure routing protocols or routing information.  
    This includes e.g. model "ietf-routing" <xref target="RFC8022"/> 
    and model "ietf-fb-rib" <xref target="I-D.draft-acee-rtgwg-yang-rib-extend"/>. 
     </t>
    <t>
     The model obeys the requirements for the ephemeral state found in the document 
     <xref target="RFC8242"/>.  
     For ephemeral topology data that is server provided, 
     the process tasked with maintaining topology information will load information from the routing process 
     (such as OSPF) into the data model without relying on a configuration datastore.  
    </t>
    </section>
    
    <section title="IANA Considerations">
    <t>
    This document registers the following namespace URIs in the "IETF XML
    Registry" <xref target="RFC3688"/>:
    </t>
   <t>
   URI:  urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
   <vspace/>
   Registrant Contact: The IESG.
   <vspace/>
   XML: N/A; the requested URI is an XML namespace.
   </t>
   <t>
   URI:  urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
   <vspace/>
   Registrant Contact: The IESG.
   <vspace/>
   XML: N/A; the requested URI is an XML namespace.
   </t>
   <t>
   This document registers the following YANG modules in the "YANG
   Module Names" registry <xref target="RFC6020"/>:
   </t>
   <t>
   Name:         ietf-l3-unicast-topology
   <vspace/>
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology 
   <vspace/>
   Prefix:       l3t
   <vspace/>
   Reference:    draft-ietf-i2rs-yang-l3-topology-14.txt (RFC form) 
   </t>
   <t>
   Name:         ietf-l3-unicast-topology-state
   <vspace/>
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state 
   <vspace/>
   Prefix:       l3t-s
   <vspace/>
   Reference:    draft-ietf-i2rs-yang-l3-topology-14.txt (RFC form) 
   </t>
   </section>
   
    <section title="Security Considerations">
      <t>
                The YANG module defined in this document 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="RFC5246"/>.
      </t>
      <t>
    The NETCONF access control model <xref target="RFC6536"/> 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>
      In general, Layer 3 Unicast topologies are system-controlled and provide ephemeral 
      topology information.  In an NMDA-complient server, they are only part of &lt;operational&gt; which provides read-only access to clients, they are less 
      vulnerable.  That said, the YANG module does in principle allow information to be configurable.  
      </t>
      <t>
      There are a number of 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 subtrees and data nodes and their sensitivity/vulnerability in the ietf-network module:
      <list>
      <t>l3-topology-attributes: A malicious client could attempt to sabotage the configuration of any of the ctonained attributes, i.e. the name or the flag data nodes. </t>
      <t>l3-node-attributes: A malicious client could attempt to sabotage the configuration of important node attributes, such as the router-id or node prefix. </t>
      <t>l3-link-attributes: A malicious client could attempt to sabotage the configuration of important link attributes, such as name, flag, and metrics of the link respectively corresponding data nodes.</t>
      <t>l3-termination-point-attributes: A malicious client could attempt to sabotage the configuration information of a termination point, such as its ip-address and interface name, respectively the corresponding data nodes.  </t>
      </list>
      </t>
    </section>

    <section title="Contributors">
      <t>The model presented in this document was contributed to by more people
      than can be listed on the author list. Additional contributors include:
      <list style="symbols">
          <t>Vishnu Pavan Beeram, Juniper</t>
          
          <t>Igor Bryskin, Huawei</t>
          
          <t>Ken Gray, Cisco</t>
          
          <t>Aihua Guo, Huawei</t>

          <t>Tom Nadeau, Brocade</t>
          
          <t>Tony Tkacik</t>

          <t>Aleksandr Zhdankin, Cisco</t>
        </list></t>
    </section>

    <section title="Acknowledgements">
      <t>We wish to acknowledge the helpful contributions, comments, and
      suggestions that were received from Alia
      Atlas, Andy Bierman, Benoit Claise, Joel Halpern, Susan Hares, Ladislav Lhotka, 
      Carl Moberg, Carlos Pignataro, Juergen Schoenwaelder, Michal Vasco, and Kent Watsen. </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC1195">
        <front>
          <title>Use of OSI IS-IS for Routing in TCP/IP and Dual
          Environments</title>

          <author fullname="R. Callon" initials="R." surname="Callon">
            <organization/>
          </author>

          <date month="December" year="1990"/>
        </front>

        <seriesInfo name="RFC" value="1195"/>
      </reference>

      <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to indicate requirement levels</title>
            <author initials='S.' surname='Bradner' fullname='S. Bradner'>
                <organization />
            </author>
            <date month='March' year='1997' />
        </front>
        <seriesInfo name='RFC' value='2119' />
      </reference>
      
      <reference anchor="RFC2328">
        <front>
          <title>OSPF Version 2</title>

          <author fullname="J. Moy" initials="J." surname="Moy">
            <organization/>
          </author>

          <date month="April" year="1998"/>
        </front>

        <seriesInfo name="RFC" value="2328"/>
      </reference>
      <reference anchor="RFC2863">
          <front>
            <title>The Interfaces Group MIB</title>
            <author initials='K.' surname='McCloghrie' fullname='K. McCloghrie'>
                <organization />
            </author>
            <author initials='F.' surname='Kastenholz' fullname='F. Kastenholz'>
                <organization />
            </author>
            <date month='June' year='2000' />
        </front>
        <seriesInfo name='RFC' value='2863' />
      </reference>
      <reference anchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author initials='M.' surname='Mealling' fullname='M. Mealling'>
                <organization />
            </author>
            <date month='January' year='2004' />
        </front>
        <seriesInfo name='RFC' value='3688' />
      </reference>
      <reference anchor="RFC5246">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>

          <author fullname="T. Dierks" initials="T." surname="Dierks">
            <organization/>
          </author>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization/>
          </author>
          <date month="August" year="2008"/>
        </front>

        <seriesInfo name='RFC' value='5246'/>
      </reference>
      <reference anchor="RFC6020">
        <front>
          <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>

          <author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>

          <date month="October" year="2010"/>
        </front>

        <seriesInfo name='RFC' value='6020'/>
      </reference>
      
      <reference anchor="RFC6241">
        <front>
          <title>Network Configuration Protocol (NETCONF)</title>

          <author fullname="R. Enns" initials="R." surname="Enns">
            <organization/>
          </author>

          <author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>

          <author fullname="J. Schoenwaelder" initials="J."
                  surname="Schoenwaelder">
            <organization/>
          </author>

          <author fullname="A. Bierman" initials="A." surname="Bierman">
            <organization/>
          </author>

          <date month="June" year="2011"/>
        </front>

        <seriesInfo name="RFC" value="6241"/>
      </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"/>
        </front>

        <seriesInfo name='RFC' value='6242'/>
      </reference>
      
      <reference anchor="RFC6536">
        <front>
            <title>Network Configuration Protocol (NETCONF) Access Control Model</title>
            <author initials='A.' surname='Bierman' fullname='A. Bierman'>
                <organization />
            </author>            
            <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'>
                <organization />
            </author>
            <date month='March' year='2012' />
        </front>
        <seriesInfo name='RFC' value='6536' />
      </reference>
      
      <reference anchor="RFC6991">
        <front>
          <title>Common YANG Data Types</title>

          <author fullname="J. Schoenwaelder" initials="J."
                  surname="Schoenwaelder">
            <organization/>
          </author>

          <date month="July" year="2013"/>
        </front>

        <seriesInfo name="RFC" value="6991"/>
      </reference>

       <reference anchor="RFC7950">
        <front>
          <title>The YANG 1.1 Data Modeling Language</title>

          <author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>

          <date month="August" year="2016"/>
        </front>

        <seriesInfo name='RFC' value='7950'/>
      </reference>
      
            
      <reference anchor="RFC7951">
          <front>
          <title>JSON Encoding of Data Modeled with YANG</title>

          <author fullname="L. Lhotka" initials="L." surname="Lhotka">
            <organization/>
          </author>

          <date month='August' year='2016'/>
        </front>

        <seriesInfo name='RFC' value='7951'/>
      </reference>
     
     
      
      <reference anchor="I-D.draft-ietf-i2rs-yang-network-topo">
        <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="December" year="2017"/>
        </front>

        <seriesInfo name="I-D" value="draft-ietf-i2rs-yang-network-topo-19"/>
      </reference>
      <reference anchor="I-D.draft-ietf-netmod-revised-datastores">
        <front>
          <title>A Revised Conceptual Model for YANG Datastores</title>

          <author fullname="Martin Bjorklund" initials="M" surname="Bjorklund">
            <organization/>
          </author>

          <author fullname="Juergen Schoenwaelder" initials="J" surname="Schoenwaelder">
            <organization/>
          </author>

          <author fullname="Phil Shafer" initials="P" surname="Shafer">
            <organization/>
          </author>

          <author fullname="Kent Watsen" initials="K" surname="Watsen">
            <organization/>
          </author>

          <author fullname="Rob Wilton" initials="R" surname="Wilton">
            <organization/>
          </author>
          <date day="30" month="October" year="2017"/>
        </front>
        <seriesInfo name="I-D" value="draft-ietf-netmod-revised-datastores-06"/>
      </reference>
    </references>

    <references title="Informative References">

    <reference anchor="RFC7223">
        <front>
            <title>A YANG Data Model for Routing Management</title>
            <author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'>
                <organization />
            </author>
            <date month='May' year='2014'/>
        </front>
        <seriesInfo name='RFC' value='7223'/>
      </reference>
      

    <reference anchor="RFC8022">
        <front>
            <title>A YANG Data Model for Routing Management</title>
            <author initials='L.' surname='Lhotka' fullname='L. Lhotka'>
                <organization />
            </author>
            <author initials='A.' surname='Lindem' fullname='A. Lindem'>
                <organization />
            </author>
            <date month='November' year='2016'/>
        </front>
        <seriesInfo name='RFC' value='8022'/>
      </reference>
      
      <reference anchor="RFC8040">
        <front>
          <title>RESTCONF Protocol</title>

          <author fullname="Andy Bierman" initials="A." surname="Bierman">
            <organization/>
          </author>
          <author fullname="Martin Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>          
          <author fullname="Kent Watsen" initials="K." surname="Watsen">
            <organization/>
          </author>
          <date month="January" year="2017"/>
        </front>
        <seriesInfo name='RFC' value='8040'/>
      </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"/>
        </front>

        
        <seriesInfo name='RFC' value='8174'/>
      </reference>
      
            
      <reference anchor="RFC8242">
        <front>
          <title>I2RS Ephemeral State Requirements</title>

          <author fullname="Jeff Haas" initials="J" surname="Haas">
            <organization/>
          </author>

          <author fullname="Susan Hares" initials="S" surname="Hares">
            <organization/>
          </author>

          <date month="September" year="2017"/>
        </front>
        <seriesInfo name="RFC" value="8242"/>
      </reference>
      
      <reference anchor="I-D.draft-ietf-i2rs-usecase-reqs-summary">
        <front>
          <title>Summary of I2RS Use Case Requirements</title>

          <author fullname="S. Hares" initials="S." surname="Hares">
            <organization/>
          </author>

          <author fullname="M. Chen" initials="M." surname="Chen">
            <organization/>
          </author>

          <date month="November" year="2016"/>
        </front>

        <seriesInfo name="I-D" value="draft-ietf-i2rs-usecase-reqs-summary-03"/>
      </reference>
      
      <reference anchor="I-D.draft-acee-rtgwg-yang-rib-extend">
        <front>
          <title>YANG Data Model for RIB Extensions</title>

          <author fullname="Acee Lindem" initials="A" surname="Lindem">
            <organization/>
          </author>

          <author fullname="Yingzhen Qu" initials="Y" surname="Qu">
            <organization/>
          </author>

          <date day="16" month="October" year="2017"/>
        </front>
        <seriesInfo name="I-D" value="draft-acee-rtgwg-yang-rib-extend-05"/>
      </reference>

      <reference anchor="I-D.draft-ietf-teas-yang-te-topo">
        <front>
          <title>YANG Data Model for TE Topologies</title>

          <author fullname="Xufen Liu" initials="X" surname="Liu">
            <organization/>
          </author>

          <author fullname="Igor Bryskin" initials="I" surname="Bryskin">
            <organization/>
          </author>
          <author fullname="Vishnu Pavan Beeram" initials="V" surname="Beeram">
            <organization/>
          </author>
          <author fullname="Tarek Saad" initials="T" surname="Saad">
            <organization/>
          </author>
           <author fullname="Himanshu Shah" initials="H" surname="Shah">
            <organization/>
          </author>  
          <author fullname="Oscar Gonzalez De Dios" initials="O" surname="Gonzalez De Dios">
            <organization/>
          </author>          
          <date day="29" month="October" year="2017"/>
        </front>
        <seriesInfo name="I-D" value="draft-ietf-teas-yang-te-topo-13"/>
      </reference>      
     
      <reference anchor="I-D.draft-ietf-netmod-yang-tree-diagrams">
        <front>
          <title>YANG Tree Diagrams</title>

          <author fullname="Martin Bjorklund" initials="M" surname="Bjorklund">
            <organization/>
          </author>

          <author fullname="Lou Berger" initials="L" surname="Berger">
            <organization/>
          </author>

          <date day="25" month="October" year="2017"/>
        </front>
        <seriesInfo name="I-D" value="draft-ietf-netmod-yang-tree-diagrams"/>
      </reference>
    </references>
    <section anchor="yang-state-models" title="Companion YANG model for non-NMDA compliant implementations">
    <t>
    The YANG module ietf-l3-unicast-topology defined in this document 
    augments two modules, ietf-network 
    and ietf-network-topology, that are designed 
    to be used in conjunction with implementations that support the Network Management
     Datastore Architecture (NMDA) defined in
     <xref target="I-D.draft-ietf-netmod-revised-datastores"/>.  
     In order to allow implementations to use the model even in cases 
     when NMDA is not supported, a set of companion modules have been defined 
     that represent a state model of networks and network topologies, 
     ietf-network-state and ietf-network-topology-state, respectively.
    </t>
    <t> In order to be able to use the model for layer 3 topologies defined in this  
    in this document in conjunction with non-NMDA compliant implementations, 
    a corresponding companion module needs to be introduced as well.  
    This companion module, ietf-l3-unicast-topology-state, 
    mirrors ietf-l3-unicast-topology.  However, 
    the module augments ietf-network-state and ietf-network-topology-state 
    (instead of ietf-network and ietf-network-topology) and all 
    of its data nodes are non-configurable.
    </t>
    <t> 
    Similar considerations apply for any modules that augment ietf-l3-unicast-topology, 
    such as the example modules defined in see <xref target="ospf-topology-model"/>, example-ospf-topology.
    For non-NMDA compliant implementations, companion
    modules will need to be introduced that represent state information and are 
    non-configurable, augmenting ietf-l3-unicast-topology-state instead of 
    ietf-l3-unicast-topology.  Because they served as examples only, companion modules 
    for those examples are not given.  
    </t>
    <t>    
     Like ietf-network-state and ietf-network-topology-state, ietf-l3-unicast-topology 
     SHOULD NOT be supported by implementations
     that support NMDA.  It is for this reason that the module is defined in the Appendix.  
     </t>
     <t>
     The definition of the module follows below.  As the structure of the module mirrors that of its underlying
     module, the YANG tree is not depicted separately.  
     </t>
     <t>
<figure>
          <artwork>
&lt;CODE BEGINS&gt; file "ietf-l3-unicast-topology-state@2017-12-13.yang"
module ietf-l3-unicast-topology-state {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state";
  prefix "l3t-s";
  import ietf-network-state {
    prefix "nw-s";
  }
  import ietf-network-topology-state {
    prefix "nt-s";
  }
  import ietf-l3-unicast-topology {
    prefix "l3t";
  }
  organization
    "IETF I2RS (Interface to the Routing System) Working Group";
  contact
    "WG Web:    &lt;http://tools.ietf.org/wg/i2rs/&gt;
     WG List:   &lt;mailto:i2rs@ietf.org&gt;
     Editor:    Alexander Clemm
                &lt;mailto:ludwig@clemm.org&gt;
     Editor:    Jan Medved
                &lt;mailto:jmedved@cisco.com&gt;
     Editor:    Robert Varga
                &lt;mailto:robert.varga@pantheon.tech&gt;
     Editor:    Xufeng Liu
                &lt;mailto:xliu@kuatrotech.com&gt;
     Editor:    Nitin Bahadur
                &lt;mailto:nitin_bahadur@yahoo.com&gt;
     Editor:    Hariharan Ananthakrishnan
                &lt;mailto:hari@packetdesign.com&gt;";
  description
    "This module defines a model for Layer 3 Unicast topology 
     state, representing topology that is either learned, or topology 
     that results from applying topology that has been configured per 
     the ietf-l3-unicast-topology model, mirroring the corresponding 
     data nodes in this model. 
     
     The model mirrors ietf-l3-unicast-topology, but contains only 
     read-only state data.  The model is not needed when the 
     underlying implementation infrastructure supports the Network 
     Management Datastore Architecture (NMDA).  
     
     Copyright (c) 2017 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 Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).
     This version of this YANG module is part of
     draft-ietf-i2rs-yang-l3-topology-14;
     see the RFC itself for full legal notices.
     NOTE TO RFC EDITOR: Please replace above reference to
     draft-ietf-i2rs-yang-l3-topology-14 with RFC
     number when published (i.e. RFC xxxx).";
  revision "2017-12-13" {
    description
      "Initial revision.
       NOTE TO RFC EDITOR: Please replace the following reference
       to draft-ietf-i2rs-yang-l3-topology-14 with
       RFC number when published (i.e. RFC xxxx).";
    reference
      "draft-ietf-i2rs-yang-l3-topology-14";
  }
  augment "/nw-s:networks/nw-s:network/nw-s:network-types" {
    description
      "Introduce new network type for L3 unicast topology";
    uses l3t:l3-unicast-topology-type;
  }
  augment "/nw-s:networks/nw-s:network" {
    when "nw-s:network-types/l3t-s:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description
        "L3 unicast for the network as a whole";
    uses l3t:l3-topology-attributes;
  }
  augment "/nw-s:networks/nw-s:network/nw-s:node" {
    when "../nw-s:network-types/l3t-s:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description
        "L3 unicast node level attributes ";
    uses l3t:l3-node-attributes;
  }
  augment "/nw-s:networks/nw-s:network/nt-s:link" {
    when "../nw-s:network-types/l3t-s:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description
      "Augment topology link attributes";
    uses l3t:l3-link-attributes;
  }
  augment "/nw-s:networks/nw-s:network/nw-s:node/"
         +"nt-s:termination-point" {
    when "../../nw-s:network-types/l3t-s:l3-unicast-topology" {
      description
        "Augmentation parameters apply only for networks with
        L3 unicast topology";
    }
    description "Augment topology termination point configuration";
    uses l3t:l3-termination-point-attributes;
  }
  notification l3-node-event {
    description
      "Notification event for L3 node";
    leaf l3-event-type {
      type l3t:l3-event-type;
      description
        "Event type";
    }
    uses nw-s:node-ref;
    uses l3t:l3-unicast-topology-type;
    uses l3t:l3-node-attributes;
  }
  notification l3-link-event {
    description
      "Notification event for L3 link";
    leaf l3-event-type {
      type l3t:l3-event-type;
      description
        "Event type";
    }
    uses nt-s:link-ref;
    uses l3t:l3-unicast-topology-type;
    uses l3t:l3-link-attributes;
  }
  notification l3-prefix-event {
    description
      "Notification event for L3 prefix";
    leaf l3-event-type {
      type l3t:l3-event-type;
      description
        "Event type";
    }
    uses nw-s:node-ref;
    uses l3t:l3-unicast-topology-type;
    container prefix {
      description
        "Containing L3 prefix attributes";
      uses l3t:l3-prefix-attributes;
    }
  }
  notification termination-point-event {
    description
      "Notification event for L3 termination point";
    leaf l3-event-type {
      type l3t:l3-event-type;
      description
        "Event type";
    }
    uses nt-s:tp-ref;
    uses l3t:l3-unicast-topology-type;
    uses l3t:l3-termination-point-attributes;
  }
}
  
&lt;CODE ENDS&gt; 
        </artwork>
        </figure>   
     </t>
    </section>
    <section anchor="ospf-topology-model" title="Extending the Model">
        <t>
            The model can be extended for specific Layer 3 Unicast types.
            Examples include OSPF and IS-IS topologies.
            In the following, one additional YANG module is introduced
            that define simple
            topology model for OSPF.
            This module is intended to serve as an example that illustrates
            how the general topology model can be refined across multiple levels. 
            It does not constitute full-fledged OSPF topology model
            which may be more comprehensive and refined than the model
            that is described here.</t>
        
        <section title="Example OSPF Topology">
            <section title="Model Overview">
                <t>The following model shows how the Layer 3 Unicast topology model can be
                    extended to cover OSFP topologies.
                    For this purpose, a set of augmentations are introduced
                    in a separate YANG module, "example-ospf-topology", whose structure is depicted
                    in the following diagram.
                    As before, the notation syntax 
                    follows <xref target="I-D.draft-ietf-netmod-yang-tree-diagrams"/>.
                </t>
                
                <figure align="center">
                    <artwork align="left">
  module: example-ospf-topology
  augment /nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology:
    +--rw ospf!
  augment /nw:networks/nw:network/l3t:l3-topology-attributes:
    +--rw ospf-topology-attributes
       +--rw area-id?   area-id-type
  augment /nw:networks/nw:network/nw:node/l3t:l3-node-attributes:
    +--rw ospf-node-attributes
       +--rw (router-type)?
       |  +--:(abr)
       |  |  +--rw abr?               empty
       |  +--:(asbr)
       |  |  +--rw asbr?              empty
       |  +--:(internal)
       |  |  +--rw internal?          empty
       |  +--:(pseudonode)
       |     +--rw pseudonode?        empty
       +--rw dr-interface-id?   uint32
  augment /nw:networks/nw:network/nt:link/l3t:l3-link-attributes:
    +--rw ospf-link-attributes
  augment /l3t:l3-node-event:
    +---- ospf!
    +---- ospf-node-attributes
       +---- (router-type)?
       |  +--:(abr)
       |  |  +---- abr?               empty
       |  +--:(asbr)
       |  |  +---- asbr?              empty
       |  +--:(internal)
       |  |  +---- internal?          empty
       |  +--:(pseudonode)
       |     +---- pseudonode?        empty
       +---- dr-interface-id?   uint32
  augment /l3t:l3-link-event:
    +---- ospf!
    +---- ospf-link-attributes
                    </artwork>
                </figure>
                
                <t>The module augments "ietf-l3-unicast-topology" as follows: <list
                    style="symbols">
                    <t>A new topology type for an OSPF topology is introduced.</t>
                    
                    <t>Additional topology attributes are defined in a new grouping
                        which augments l3-topology-attributes of the
                        ietf-l3-unicast-topology module. The attributes include an OSPF
                        area-id identifying the OSPF area.</t>
                    
                    <t>Additional data objects for nodes are introduced by augmenting
                        the l3-node-attributes of the l3-unicast-topology module. New
                        objects include router-type and dr-interface-id for pseudonodes.
                        </t>
                    
                    <t>Links are augmented with ospf link attributes.</t>
                    
                </list> In addition, the module extends notifications for events
                concerning Layer 3
                nodes and links with OSPF attributes.</t>
                <t>
                    It should be noted that the model defined here
                    represents topology and is intended as an example.
                    It does not define how to configure
                    OSPF routers or interfaces.
                </t>
            </section>
            <section title="OSPF Topology YANG Module">
                <t>
                    The OSPF Topology YANG Module is specified below.
                    As mentioned, the module is intended as an example for how
                    the Layer 3 Unicast topology model can be
                    extended to cover OSFP topologies,
                    but it is not normative.  Accordingly, the module is not delimited
                    with CODE BEGINS and CODE ENDS tags.
                </t>
                <t>
                    <figure>
                        <artwork>
file "example-ospf-topology@2017-12-13.yang"
module example-ospf-topology {
    yang-version 1.1;
    namespace "urn:example:example-ospf-topology";
    prefix "ex-ospft";
    import ietf-yang-types {
        prefix "yang";
    }
    import ietf-network {
        prefix "nw";
    }
    import ietf-network-topology {
        prefix "nt";
    }
    import ietf-l3-unicast-topology {
        prefix "l3t";
    }
    description
       "This module is intended as an example for how the
        Layer 3 Unicast topology model can be extended to cover
        OSFP topologies.";
    typedef area-id-type {
        type yang:dotted-quad;
        description
            "Area ID type.";
    }
    grouping ospf-topology-type {
        description
            "Identifies the OSPF topology type.";
        container ospf {
            presence "indicates OSPF Topology";
            description
                "Its presence identifies the OSPF topology type.";
        }
    }
    augment "/nw:networks/nw:network/nw:network-types/"
    + "l3t:l3-unicast-topology" {
        description
            "Defines the OSPF topology type.";
        uses ospf-topology-type;
    }
    augment "/nw:networks/nw:network/l3t:l3-topology-attributes" {
        when "../nw:network-types/l3t:l3-unicast-topology/" + 
            "ex-ospft:ospf" {
            description
                "Augment only for OSPF topology";
            }
        description
            "Augment topology configuration";
        container ospf-topology-attributes {
            description
                "Containing topology attributes";
            leaf area-id {
                type area-id-type;
                description
                    "OSPF area ID";
            }
        }
    }
    augment "/nw:networks/nw:network/nw:node/l3t:l3-node-attributes" {
        when "../../nw:network-types/l3t:l3-unicast-topology/" + 
            "ex-ospft:ospf" {
            description
                "Augment only for OSPF topology";
        }
        description
            "Augment node configuration";
        uses ospf-node-attributes;
    }
    augment "/nw:networks/nw:network/nt:link/l3t:l3-link-attributes" {
        when "../../nw:network-types/l3t:l3-unicast-topology/" + 
            "ex-ospft:ospf" {
            description
                "Augment only for OSPF topology";
        }
        description
            "Augment link configuration";
        uses ospf-link-attributes;
    }
    grouping ospf-node-attributes {
        description
            "OSPF node scope attributes";
        container ospf-node-attributes {
            description
                "Containing node attributes";
            choice router-type {
                description
                    "Indicates router type";
                case abr {
                    leaf abr {
                        type empty;
                        description
                            "The node is ABR";
                    }
                }
                case asbr {
                    leaf asbr {
                        type empty;
                        description
                            "The node is ASBR";
                    }
                }
                case internal {
                    leaf internal {
                        type empty;
                        description
                            "The node is internal";
                    }
                }
                case pseudonode {
                    leaf pseudonode {
                        type empty;
                        description
                            "The node is pseudonode";
                    }
                }
            }
            leaf dr-interface-id {
                when "../pseudonode" {
                    description
                        "Valid only for pseudonode";
                }
                type uint32;
                default "0";
                description
                    "For pseudonodes, DR interface-id";
            }
        }
    }
    grouping ospf-link-attributes {
        description
            "OSPF link scope attributes";
        container ospf-link-attributes {
            description
                "Containing OSPF link attributes";
        }
    } // ospf-link-attributes
    augment "/l3t:l3-node-event" {
        description
            "OSPF node event";
        uses ospf-topology-type;
        uses ospf-node-attributes;
    }
    augment "/l3t:l3-link-event" {
        description
            "OSPF link event";
        uses ospf-topology-type;
        uses ospf-link-attributes;
    }
}                  
                        </artwork>
                    </figure></t>
            </section>
        </section>
        
        
    </section>
       <section title="An Example">  
   <t> This section contains an example of an instance data tree in JSON
   encoding <xref target="RFC7951"/>.  The example instantiates ietf-l3-unicast-topology for the topology that is depicted in the following diagram.
   There are three nodes, D1, D2, and D3.  D1 has three termination points, 1-0-1, 1-2-1, and 1-3-1.  D2 has three termination points as well, 2-1-1, 2-0-1, and 2-3-1.  D3 has two termination points, 3-1-1 and 3-2-1.  In addition there are six links, two between each pair of nodes with one going in each direction.  
   </t>

   <figure align="center" anchor="example-topology"
           title="A network topology example">
     <artwork align="left">
   
   
             +------------+                   +------------+
             |     D1     |                   |     D2     |
            /-\          /-\                 /-\          /-\
            | | 1-0-1    | |---------------->| | 2-1-1    | |
            | |    1-2-1 | |&lt;----------------| |    2-0-1 | |
            \-/  1-3-1   \-/                 \-/  2-3-1   \-/
             |   /----\   |                   |   /----\   |
             +---|    |---+                   +---|    |---+
                 \----/	                          \----/
                  A  |	                           A  |
                  |  |                             |  |	      
                  |  |                             |  |
                  |  |       +------------+        |  |
                  |  |       |     D3     |        |  |
                  |  |      /-\          /-\ 	   |  |
                  |  +----->| | 3-1-1    | |-------+  |
                  +---------| |    3-2-1 | |&lt;---------+
                            \-/          \-/
                             |            |
                             +------------+
						   
     </artwork>
   </figure>
    <t>
    The corresponding instance data tree is depicted below:
    </t>
       <figure align="center" anchor="instance-data-tree-example"
           title="Instance data tree">
        <artwork align="left">
{
  "ietf-network:networks": {
    "network": [
      {
        "network-types": {
          "ietf-l3-unicast-topology:l3-unicast-topology": {}
        },
        "network-id": "l3-topo-example",
        "node": [
          {
            "node-id": "D1",
            "termination-point": [
              {
                "tp-id": "1-0-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 101
                }
              },
              {
                "tp-id": "1-2-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 121
                }
              },
              {
                "tp-id": "1-3-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 131
                }
              }
            ],
            "ietf-l3-unicast-topology:l3-node-attributes": {
              "router-id": ["203.0.113.1"]
            }
          },
          {
            "node-id": "D2",
            "termination-point": [
              {
                "tp-id": "2-0-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 201
                }
              },
              {
                "tp-id": "2-1-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 211
                }
              },
              {
                "tp-id": "2-3-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 231
                }
              }
            ],
            "ietf-l3-unicast-topology:l3-node-attributes": {
              "router-id": ["203.0.113.2"]
            }
          },
          {
            "node-id": "D3",
            "termination-point": [
              {
                "tp-id": "3-1-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 311
                }
              },
              {
                "tp-id": "3-2-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes": {
                  "unnumbered-id:": 321
                }
              }
            ],
            "ietf-l3-unicast-topology:l3-node-attributes": {
              "router-id": ["203.0.113.3"]
            }
          }
        ],
        "ietf-network-topology:link": [
          {
            "link-id": "D1,1-2-1,D2,2-1-1",
            "destination": {
              "source-node": "D1",
              "source-tp": "1-2-1"
            }
            "destination": {
              "dest-node": "D2",
              "dest-tp": "2-1-1"
            },
            "ietf-l3-unicast-topology:l3-link-attributes": {
              "metric1": "100"
            }
          },
          {
            "link-id": "D2,2-1-1,D1,1-2-1",
            "destination": {
              "source-node": "D2",
              "source-tp": "2-1-1"
            }
            "destination": {
              "dest-node": "D1",
              "dest-tp": "1-2-1"
            },
            "ietf-l3-unicast-topology:l3-link-attributes": {
              "metric1": "100"
            }
          },
          {
            "link-id": "D1,1-3-1,D3,3-1-1",
            "destination": {
              "source-node": "D1",
              "source-tp": "1-3-1"
            }
            "destination": {
              "dest-node": "D3",
              "dest-tp": "3-1-1"
            },
            "ietf-l3-unicast-topology:l3-link-attributes": {
              "metric1": "100"
            }
          },
          {
            "link-id": "D3,3-1-1,D1,1-3-1",
            "destination": {
              "source-node": "D3",
              "source-tp": "3-1-1"
            }
            "destination": {
              "dest-node": "D1",
              "dest-tp": "1-3-1"
            },
            "ietf-l3-unicast-topology:l3-link-attributes": {
              "metric1": "100"
            }
          },
          {
            "link-id": "D2,2-3-1,D3,3-2-1",
            "destination": {
              "source-node": "D2",
              "source-tp": "2-3-1"
            }
            "destination": {
              "dest-node": "D3",
              "dest-tp": "3-2-1"
            },
            "ietf-l3-unicast-topology:l3-link-attributes": {
              "metric1": "100"
            }
          },
          {
            "link-id": "D3,3-2-1,D2,2-3-1",
            "destination": {
              "source-node": "D3",
              "source-tp": "3-2-1"
            }
            "destination": {
              "dest-node": "D2",
              "dest-tp": "2-3-1"
            },
            "ietf-l3-unicast-topology:l3-link-attributes": {
              "metric1": "100"
            }
          }
        ]
      }
    ]
  }
}

         </artwork>
      </figure>
    </section>
  </back>
</rfc>
