Network Working Group
Internet Engineering Task Force (IETF)                          A. Clemm
Internet-Draft
Request for Comments: 8346                                        Huawei USA
Intended status:
Category: Standards Track                                      J. Medved
Expires: June 19, 2018
ISSN: 2070-1721                                                    Cisco
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                                  X. Liu
                                                                   Jabil
                                                      H. Ananthakrishnan
                                                           Packet Design
                                                              N. Bahadur
                                                       Bracket Computing
                                                       December 16, 2017
                                                              March 2018

                A YANG Data Model for Layer 3 Topologies
                draft-ietf-i2rs-yang-l3-topology-16.txt

Abstract

   This document defines a YANG data model for layer Layer 3 network
   topologies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 19, 2018.
   https://www.rfc-editor.org/info/rfc8346.

Copyright Notice

   Copyright (c) 2017 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2 ....................................................3
   2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . .   3 .......................................................3
   3. Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   3 ........................................4
   4. Model Structure . . . . . . . . . . . . . . . . . . . . . . .   4 .................................................5
   5. Layer 3 Unicast Topology Model Overview . . . . . . . . . . .   5 .........................6
   6. Layer 3 Unicast Topology YANG Module  . . . . . . . . . . . .   7 ............................7
   7. Interactions with Other YANG Modules  . . . . . . . . . . . .  15 ...........................15
   8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15 ............................................15
   9. Security Considerations . . . . . . . . . . . . . . . . . . .  16 ........................................16
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     12.1. ....................................................17
      10.1. Normative References . . . . . . . . . . . . . . . . . .  17
     12.2. .....................................17
      10.2. Informative References . . . . . . . . . . . . . . . . .  19 ...................................19
   Appendix A.  Companion YANG model Data Model for non-NMDA compliant
                implementations  . . . . . . . . . . . . . . . . . .  20 Implementations Not
                Compliant with NMDA ..................................20
   Appendix B.  Extending the Model  . . . . . . . . . . . . . . . .  24 ..................................24
     B.1.  Example OSPF Topology . . . . . . . . . . . . . . . . . .  24 .....................................24
       B.1.1.  Model Overview  . . . . . . . . . . . . . . . . . . .  24 ........................................24
       B.1.2.  OSPF Topology YANG Module . . . . . . . . . . . . . .  26 .............................26
   Appendix C.  An Example . . . . . . . . . . . . . . . . . . . . .  29 ...........................................29
   Acknowledgments ...................................................34
   Contributors ......................................................34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34 ................................................35

1.  Introduction

   This document introduces a YANG [RFC7950] [RFC6991] data model for
   Layer 3 (L3) 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
   [I-D.draft-ietf-i2rs-yang-network-topo]. [RFC8345].

   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 [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. in this document.

   There are multiple applications for a topology data model.  A number
   of use cases have been defined in section Section 6 of
   [I-D.draft-ietf-i2rs-usecase-reqs-summary]. [USECASE-REQS].  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.

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

   Information that is kept in the Traffic Engineering Database (TED)
   will be specified in a separate model
   [I-D.draft-ietf-teas-yang-te-topo] [YANG-TE] and is outside the
   scope of this specification.

2.  Key Words

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

3.  Definitions and Acronyms

   As this

   This document defines a YANG data model, in this document model and thus uses many terms are used that have been
   defined in conjunction with YANG [RFC7950] and NETCONF [RFC6241].  Some terms, such as datastore
   "datastore" and
   data tree, "data tree", are repeated here for clarity and to put them in
   context.

   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 tree (definition
      adopted from
   [I-D.draft-ietf-netmod-revised-datastores]) [RFC8342]).

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

   IGP: Interior Gateway Protocol

   IS-IS:  Intermediate System to Intermediate System protocol

   LSP:  Label Switched Path

   NETCONF:  Network Configuration Protocol

   NMDA:  Network Management Datastore Architecture

   OSPF:  Open Shortest Path First, a link state First (a link-state routing protocol protocol)

   URI:  Uniform Resource Identifier

   SRLG: Shared Risk Link Group

   TED:  Traffic Engineering Database

   YANG:  YANG is a data modeling language used to model configuration
      data, state data, Remote Procedure Calls, and notifications for
      network management protocols [RFC7950] [RFC7950].

4.  Model Structure

   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.

                      +-----------------------------+
                      |  +-----------------------+  |
                      |  |      ietf-network     |  |
                      |  +----------^------------+  |
                      |             |               |
                      |  +-----------------------+  |
                      |  | ietf-network-topology |  |
                      |  +----------+------------+  |
                      +-------------^---------------+
                                    |
                                    |
                       +------------^-------------+
                       | ietf-l3-unicast-topology |
                       +------------^-------------+
                                    |
                                    |
                        +-----------^-----------+
                        | example-ospf-topology |
                        +-----------------------+

                     Figure 1: Overall model structure Model Structure

   YANG modules "ietf-network" and "ietf-network-topology" collectively
   define the basic network topology model
   [I-D.draft-ietf-i2rs-yang-network-topo]. [RFC8345].  YANG module "ietf-l3-
   unicast-topology"
   "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.

   The YANG modules ietf-network "ietf-network" and ietf-network-topology "ietf-network-topology" are
   designed to be used in conjunction with implementations that support
   the Network Management Datastore Architecture (NMDA) defined in
   [I-D.draft-ietf-netmod-revised-datastores].
   [RFC8342].  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 Appendix A.

5.  Layer 3 Unicast Topology Model Overview

   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
   [I-D.draft-ietf-netmod-yang-tree-diagrams]. [RFC8340].  For purposes of
   brevity, notifications are not depicted.

   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*   rt-types:router-id
          +--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

   The module augments the original ietf-network "ietf-network" and ietf-network-
   topology "ietf-network-
   topology" modules as follows:

   o  A new network topology type is introduced, l3-unicast-topology.
      The corresponding container augments the network-types of the
      ietf-network
      "ietf-network" module.

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

   o  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
      flags and a list of prefixes.  Each prefix in turn includes an ip IP prefix,
      a metric, and a prefix-specific set of flags.

   o  Links (in the ietf-network-topology "ietf-network-topology" module) are augmented with a
      set of parameters as well, allowing to associate that allow a link to be associated with a link
      name, another set of flags, and a link metric.

   o  Termination points (in the ietf-network-topology module as well) "ietf-network-topology" module) are
      augmented with a choice of IP address, identifier, or name.

   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,  Also, as a
   convenience to applications, additional data of the affected node, or
   link, prefix, 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 information that might have
   changed in the meantime.

6.  Layer 3 Unicast Topology YANG Module

   This YANG module makes reference to the following documents:
   [RFC2863] and [RFC8343].

   <CODE BEGINS> file "ietf-l3-unicast-topology@2017-12-16.yang" "ietf-l3-unicast-topology@2018-02-26.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";
     }
     import ietf-routing-types {
       prefix "rt-types";
     }
     organization
       "IETF I2RS (Interface to the Routing System) Working Group";
     contact
       "WG Web:    <http://tools.ietf.org/wg/i2rs/>    <https://datatracker.ietf.org/wg/i2rs/>
        WG List:   <mailto:i2rs@ietf.org>
        Editor:    Alexander Clemm
                   <mailto:ludwig@clemm.org>
        Editor:    Jan Medved
                   <mailto:jmedved@cisco.com>
        Editor:    Robert Varga
                   <mailto:robert.varga@pantheon.tech>
        Editor:    Xufeng Liu
                   <mailto:xliu@kuatrotech.com>
                   <mailto:xufeng.liu.ietf@gmail.com>
        Editor:    Nitin Bahadur
                   <mailto:nitin_bahadur@yahoo.com>
        Editor:    Hariharan Ananthakrishnan
                   <mailto:hari@packetdesign.com>";
     description
       "This module defines a model for Layer 3 Unicast
        topologies.

        Copyright (c) 2017 2018 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).
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of
        draft-ietf-i2rs-yang-l3-topology-16;
        RFC 8346; see the RFC itself for full legal notices.
        NOTE TO RFC EDITOR: Please replace above reference to
        draft-ietf-i2rs-yang-l3-topology-16 with RFC
        number when published (i.e. RFC xxxx)."; notices.";
     revision "2017-12-16" "2018-02-26" {
       description
         "Initial revision.
          NOTE TO RFC EDITOR: Please replace the following revision.";
       reference
          to draft-ietf-i2rs-yang-l3-topology-16 with
          RFC number when published (i.e. RFC xxxx).";
       reference
         "draft-ietf-i2rs-yang-l3-topology-16";
         "RFC 8346: A YANG Data Model for Layer 3 Topologies";
     }

     identity flag-identity {
       description "Base type for flags";
     }

     typedef l3-event-type {
       type enumeration {
         enum "add" {
           description
             "An
             "A Layer 3 node or link or prefix node, link, prefix, or termination-point termination point has
             been added";
         }
         enum "remove" {
           description
             "An
             "A Layer 3 node or link or prefix node, link, prefix, or termination-point termination point has
             been removed";
         }
         enum "update" {
           description
             "An
             "A Layer 3 node or link or prefix node, link, prefix, or termination-point termination point has
             been updated";
         }
       }
       description "Layer 3 Event 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 "Identifies the topology type to be L3 unicast."; Unicast.";
       container l3-unicast-topology {
         presence "indicates L3 Unicast Topology"; topology";
         description
           "The presence of the container node indicates L3 Unicast
           Topology";
           topology";
       }
     }
     grouping l3-topology-attributes {
       description "Topology scope attributes";
       container l3-topology-attributes {
         description "Containing "Contains 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
           "Contains 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 rt-types:router-id;
           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
           "Contains 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
           "Contains 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. 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
                 "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. i.e., the path name of a
                  corresponding interface data node on the containing
                  node reminiscent of data type if-ref interface-ref defined
                  in RFC 7223. 8343. It should be noted that data type if-ref
                  interface-ref of RFC 7223 8343 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.";
               reference
                 "RFC 8343: A YANG Data Model for Interface Management";
             }
           }
         }
       }
     }
     augment "/nw:networks/nw:network/nw:network-types" {
       description
         "Introduce
         "Introduces new network type for L3 unicast 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 Unicast topology";
       }
       description
           "L3 unicast 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 Unicast topology";
       }
       description
           "L3 unicast node level 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 Unicast topology";
       }
       description
         "Augment
         "Augments 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 Unicast topology";
       }
       description "Augment "Augments 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
           "Contains 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;
     }
   }

   <CODE ENDS>

7.  Interactions with Other YANG Modules

   As described in section Section 4, the model defined in this document builds
   on top of, and augments, the YANG modules defined in
   [I-D.draft-ietf-i2rs-yang-network-topo]. [RFC8345].
   Specifically, the "ietf-l3-unicast-topology" module ietf-
   l3-unicast-topology augments modules the
   "ietf-network" and "ietf-
   network-topology". "ietf-network-topology" modules.  In addition, the
   model makes use of data types
   that have been defined in [RFC6991].

   The model defines defined in this document is a protocol independent protocol-independent YANG
   data model with layer 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 information, e.g., "ietf-routing" [RFC8022] and
   model "ietf-fb-rib" [I-D.draft-acee-rtgwg-yang-rib-extend].
   "ietf-rib-extension" [YANG-RIB].  That said, the model does import a
   type definition from model "ietf-
   routing-types" "ietf-routing-types" [RFC8294].

   The model obeys complies with the requirements for the ephemeral state
   found in the
   document [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.

8.  IANA Considerations

   This document registers the following namespace URIs in the "IETF XML
   Registry" [RFC3688]:

   URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.

   This document registers the following YANG modules in the "YANG
   Module Names" registry [RFC6020]:

   Name: ietf-l3-unicast-topology
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
   Prefix: l3t
   Reference: draft-ietf-i2rs-yang-l3-topology-16.txt (RFC form) RFC 8346

   Name: ietf-l3-unicast-topology-state
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
   Prefix: l3t-s
   Reference: draft-ietf-i2rs-yang-l3-topology-16.txt (RFC form) RFC 8346

9.  Security Considerations

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

   The NETCONF access control model [RFC6536] [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.

   In general, Layer 3 Unicast topologies are system-controlled and
   provide ephemeral topology information.  In an NMDA-complient NMDA-compliant server,
   they are only part of <operational> <operational>, which provides read-only access
   to clients, so they are less vulnerable.  That said, the YANG module
   does modules
   do in principle allow information to be configurable.

   There are a number of data nodes defined in this these YANG module modules 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 "ietf-l3-unicast-topology"
   module:

   o  l3-topology-attributes: A malicious client could attempt to
      sabotage the configuration of any of the ctonained contained attributes,
      i.e.
      i.e., the name or the flag data nodes.

   o  l3-node-attributes: A malicious client could attempt to sabotage
      the configuration of important node attributes, such as the
      router-id or node prefix.

   o  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. link.

   o  l3-termination-point-attributes: A malicious client could attempt
      to sabotage the configuration information of a termination point,
      such as its ip-address the termination point's IP address and interface name, respectively the
      corresponding data nodes.

12. name.

10.  References

12.1.

10.1.  Normative References
   [RFC1195]  Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
              Dual Environments", RFC 1195, December 1990.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to indicate
              requirement levels", Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998. 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000. 2000,
              <https://www.rfc-editor.org/info/rfc2863>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January
              2004. 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008. 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010. 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012. 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013. 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016. 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016. 2016,
              <https://www.rfc-editor.org/info/rfc7951>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8294]  Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
              "Common YANG Data Types for the Routing Area", RFC 8294,
              DOI 10.17487/RFC8294, December 2014.

   [I-D.draft-ietf-netmod-revised-datastores] 2017,
              <https://www.rfc-editor.org/info/rfc8294>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "A Revised Conceptual Model for YANG
              Datastores", I-D draft-ietf-netmod-revised-datastores-06,
              October 2017.

   [I-D.draft-ietf-i2rs-yang-network-topo] "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

   [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
              Network Topologies", I-D draft-ietf-i2rs-yang-network-
              topo-19, December 2017.

12.2. RFC 8345, DOI 10.17487/RFC8345, March
              2018, <https://www.rfc-editor.org/info/rfc8345>.

10.2.  Informative References

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Routing Management",
              RFC 7223, May 2014.

   [RFC8022]  Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", RFC 8022, DOI 10.17487/RFC8022, November 2016.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, January 2017.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, May 2017.
              2016, <https://www.rfc-editor.org/info/rfc8022>.

   [RFC8242]  Haas, J. and S. Hares, "I2RS "Interface to the Routing System
              (I2RS) Ephemeral State Requirements", RFC 8242,
              DOI 10.17487/RFC8242, September 2017.

   [I-D.draft-ietf-netmod-yang-tree-diagrams] 2017,
              <https://www.rfc-editor.org/info/rfc8242>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", I-D
              draft-ietf-netmod-yang-tree-diagrams, October 2017.

   [I-D.draft-ietf-i2rs-usecase-reqs-summary]
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [USECASE-REQS]
              Hares, S. and M. Chen, "Summary of I2RS Use Case
              Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary-
              03, Work in Progress, draft-ietf-i2rs-usecase-
              reqs-summary-03, November 2016.

   [I-D.draft-acee-rtgwg-yang-rib-extend]

   [YANG-RIB] Lindem, A. and Y. Qu, "YANG "RIB YANG Data Model for RIB
              Extensions", I-D draft-acee-rtgwg-yang-rib-extend-05,
              October 2017.

   [I-D.draft-ietf-teas-yang-te-topo] Model", Work in
              Progress, draft-acee-rtgwg-yang-rib-extend-06, January
              2018.

   [YANG-TE]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
              O. Gonzalez De de Dios, "YANG Data Model for TE Traffic
              Engineering (TE) Topologies",
              I-D draft-ietf-teas-yang-te-topo-13, October 2017. Work in Progress,
              draft-ietf-teas-yang-te-topo-15, February 2018.

Appendix A.  Companion YANG model Data Model for non-NMDA compliant implementations Implementations Not Compliant
             with NMDA

   The YANG module ietf-l3-unicast-topology "ietf-l3-unicast-topology" defined in this document
   augments two modules, ietf-network modules defined in [RFC8345]: "ietf-network" and ietf-network-topology, that
   are "ietf-
   network-topology".  These two modules were designed to be used in
   conjunction with implementations that support the Network Management
   Datastore Architecture (NMDA) defined in [I-D.draft-ietf-netmod-revised-datastores]. [RFC8342].  In order to
   allow implementations to use the model even in cases when NMDA is not
   supported, a set of [RFC8345] defines two companion modules have been defined modules, "ietf-network-
   state" and "ietf-network-topology-state", that represent a state model models
   of networks and network topologies, ietf-
   network-state and ietf-network-topology-state, respectively.

   In order to be able to use the model for layer Layer 3 topologies defined
   in this in this document in conjunction with non-NMDA implementations not compliant
   implementations,
   with NMDA, a corresponding companion module needs to be introduced as
   well.  This companion module, ietf-l3-unicast-topology-
   state, "ietf-l3-unicast-topology-state",
   mirrors ietf-l3-unicast-topology. "ietf-l3-unicast-topology".  However, the module augments ietf-network-state
   "ietf-network-state" and ietf-network-topology-state "ietf-network-topology-state" (instead of ietf-network
   "ietf-network" and ietf-network-topology) "ietf-network-topology"), and all of its data
   nodes are non-configurable.

   Similar considerations apply for to any modules module that augment ietf-l3-
   unicast-topology, augments "ietf-l3-
   unicast-topology", such as the example modules module defined in see Appendix B, example-ospf-topology. B
   (i.e., example-ospf-topology).  For non-NMDA implementations that are not
   compliant
   implementations, with NMDA, companion modules will need to be introduced that represent state
   information and that are non-configurable, augmenting
   ietf-l3-unicast-topology-state non-configurable will need to be introduced.
   These modules augment "ietf-l3-unicast-topology-state" instead of ietf-l3-unicast-topology.
   Because they served as examples only, companion
   "ietf-l3-unicast-topology".  Companion modules for those
   examples the example module
   defined in Appendix B are not given. provided (since it is just an example).

   Like ietf-network-state "ietf-network-state" and ietf-network-topology-state, ietf-l3-
   unicast-topology "ietf-network-topology-state", "ietf-
   l3-unicast-topology" SHOULD NOT be supported by implementations that
   support NMDA.  It is for this reason that the  The module is therefore defined in
   the Appendix. an appendix.

   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.

   <CODE BEGINS> file "ietf-l3-unicast-topology-state@2017-12-16.yang" "ietf-l3-unicast-topology-state@2018-02-26.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:    <http://tools.ietf.org/wg/i2rs/>    <https://datatracker.ietf.org/wg/i2rs/>
        WG List:   <mailto:i2rs@ietf.org>
        Editor:    Alexander Clemm
                   <mailto:ludwig@clemm.org>
        Editor:    Jan Medved
                   <mailto:jmedved@cisco.com>
        Editor:    Robert Varga
                   <mailto:robert.varga@pantheon.tech>
        Editor:    Xufeng Liu
                   <mailto:xliu@kuatrotech.com>
                   <mailto:xufeng.liu.ietf@gmail.com>
        Editor:    Nitin Bahadur
                   <mailto:nitin_bahadur@yahoo.com>
        Editor:    Hariharan Ananthakrishnan
                   <mailto:hari@packetdesign.com>";
     description
       "This module defines a model for Layer 3 Unicast topology
        state, representing topology that is either learned, is learned or topology
        that
        results from applying topology that has been configured per
        the ietf-l3-unicast-topology 'ietf-l3-unicast-topology' model, mirroring the
        corresponding data nodes in this model.

        The

        This model mirrors ietf-l3-unicast-topology, '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 2018 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).
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of
        draft-ietf-i2rs-yang-l3-topology-16; RFC 8346;
        see the RFC itself for full legal notices.
        NOTE TO RFC EDITOR: Please replace above reference to
        draft-ietf-i2rs-yang-l3-topology-16 with RFC
        number when published (i.e. RFC xxxx)."; notices.";
     revision "2017-12-16" "2018-02-26" {
       description
         "Initial revision.
          NOTE TO RFC EDITOR: Please replace the following reference
          to draft-ietf-i2rs-yang-l3-topology-16 with
          RFC number when published (i.e. RFC xxxx)."; revision.";
       reference
         "draft-ietf-i2rs-yang-l3-topology-16";
         "RFC 8346: A YANG Data Model for Layer 3 Topologies";
     }
     augment "/nw-s:networks/nw-s:network/nw-s:network-types" {
       description
         "Introduce new network type for L3 unicast 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 Unicast topology";
       }
       description
           "L3 unicast 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 Unicast topology";
       }
       description
           "L3 unicast node level 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 Unicast topology";
       }
       description
         "Augment
         "Augments 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 Unicast topology";
       }
       description "Augment "Augments 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
           "Contains 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;
     }
   }

   <CODE ENDS>

Appendix B.  Extending the Model

   The model can be extended for specific Layer 3 Unicast types.
   Examples include OSPF and IS-IS topologies.  In the following, one
   additional  This appendix introduces
   a YANG module is introduced that define defines a 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 a full-fledged OSPF topology
   model model, which may be
   more comprehensive and refined than the model that is described here.

B.1.  Example OSPF Topology

B.1.1.  Model Overview

   The following model shows how the Layer 3 Unicast topology model can
   be extended, in this case case, to cover OSFP OSPF 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
   [I-D.draft-ietf-netmod-yang-tree-diagrams]. [RFC8340].
   Note that one of the lines has been wrapped to adhere to the
   72-character line limitation of RFCs.

   module: example-ospf-topology
   augment /nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology: /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

   The module augments "ietf-l3-unicast-topology" as follows:

   o  A new topology type for an OSPF topology is introduced.

   o  Additional topology attributes are defined in a new grouping which that
      augments l3-topology-attributes of the ietf-l3-unicast-topology "ietf-l3-unicast-topology"
      module.  The attributes include an OSPF area-id identifying the
      OSPF area.

   o  Additional data objects for nodes are introduced by augmenting the
      l3-node-attributes of the l3-unicast-topology "ietf-l3-unicast-topology" module.  New
      objects include router-type and dr-interface-id for pseudonodes.

   o  Links are augmented with ospf OSPF link attributes.

   In addition, the module extends notifications for events concerning
   Layer 3 nodes and links with OSPF attributes.

   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.

B.1.2.  OSPF Topology YANG Module

   The OSPF Topology YANG Module 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 OSPF topologies, but it is not
   normative.  Accordingly, the module is not delimited with CODE BEGINS
   <CODE BEGINS> and CODE ENDS <CODE ENDS> tags.

  file "example-ospf-topology@2017-12-16.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
          OSPF 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
                  "Augments only for OSPF topology";
              }
          description
              "Augment
              "Augments topology configuration";
          container ospf-topology-attributes {
              description
                  "Containing
                  "Contains 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
                  "Augments only for OSPF topology";
          }
          description
              "Augment
              "Augments 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
                  "Augments only for OSPF topology";
          }
          description
              "Augment
              "Augments link configuration";
          uses ospf-link-attributes;
      }
      grouping ospf-node-attributes {
          description
              "OSPF node scope attributes";
          container ospf-node-attributes {
              description
                  "Containing
                  "Contains 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
                  "Contains 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;
      }
  }

Appendix C.  An Example

   This section contains an example of an instance data tree in JSON
   encoding [RFC7951].  The example instantiates ietf-l3-unicast-
   topology "ietf-l3-unicast-
   topology" for the topology that is depicted in the following diagram.
   There are three nodes, nodes: D1, D2, and D3.  D1 has three termination
   points,
   points: 1-0-1, 1-2-1, and 1-3-1.  D2 has three termination points as
   well,
   well: 2-1-1, 2-0-1, and 2-3-1.  D3 has two termination points, points: 3-1-1
   and 3-2-1.  In addition addition, there are six links, two between each pair
   of
   nodes nodes, with one going in each direction.

                +------------+                   +------------+
                |     D1     |                   |     D2     |
               /-\          /-\                 /-\          /-\
               | | 1-0-1    | |---------------->| | 2-1-1    | |
               | |    1-2-1 | |<----------------| |    2-0-1 | |
               \-/  1-3-1   \-/                 \-/  2-3-1   \-/
                |   /----\   |                   |   /----\   |
                +---|    |---+                   +---|    |---+
                    \----/                           \----/
                     A  |                             A  |
                     |  |                             |  |
                     |  |                             |  |
                     |  |       +------------+        |  |
                     |  |       |     D3     |        |  |
                     |  |      /-\          /-\       |  |
                     |  +----->| | 3-1-1    | |-------+  |
                     +---------| |    3-2-1 | |<---------+
                               \-/          \-/
                                |            |
                                +------------+

                   Figure 2: A network topology example Network Topology Example

   The corresponding instance data tree is depicted below: below.  Note that
   some lines have been wrapped to adhere to the 72-character line
   limitation of RFCs.

   {
     "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":
                   "ietf-l3-unicast-topology:
                     l3-termination-point-attributes": {
                     "unnumbered-id:": 101
                   }
                 },
                 {
                   "tp-id": "1-2-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes":
                   "ietf-l3-unicast-topology:
                     l3-termination-point-attributes": {
                     "unnumbered-id:": 121
                   }
                 },
                 {
                   "tp-id": "1-3-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes":
                   "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":
                   "ietf-l3-unicast-topology:
                     l3-termination-point-attributes": {
                     "unnumbered-id:": 201
                   }
                 },
                 {
                   "tp-id": "2-1-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes":
                   "ietf-l3-unicast-topology:
                     l3-termination-point-attributes": {
                     "unnumbered-id:": 211
                   }
                 },
                 {
                   "tp-id": "2-3-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes":
                   "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":
                   "ietf-l3-unicast-topology:
                     l3-termination-point-attributes": {
                     "unnumbered-id:": 311
                   }
                 },
                 {
                   "tp-id": "3-2-1",
                "ietf-l3-unicast-topology:l3-termination-point-attributes":
                   "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": {
                 "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": {
                 "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": {
                 "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": {
                 "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": {
                 "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": {
                 "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"
               }
             }
           ]
         }
       ]
     }
   }

                       Figure 3: Instance data tree

11.  Acknowledgements Data Tree

Acknowledgments

   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.

10.

Contributors

   The model presented in this document was contributed to by more
   people than can be listed on the author list.  Additional
   contributors include:

   o  Vishnu Pavan Beeram, Juniper

   o  Igor Bryskin, Huawei

   o  Ken Gray, Cisco

   o  Aihua Guo, Huawei

   o  Tom Nadeau, Brocade

   o  Tony Tkacik

   o  Aleksandr Zhdankin, Cisco

Authors' Addresses

   Alexander Clemm
   Huawei USA

   EMail: ludwig@clemm.org - Futurewei Technologies Inc.
   Santa Clara, CA
   United States of America

   Email: ludwig@clemm.org, alexander.clemm@huawei.com

   Jan Medved
   Cisco

   EMail:

   Email: jmedved@cisco.com

   Robert Varga
   Pantheon Technologies SRO

   EMail:

   Email: robert.varga@pantheon.tech

   Xufeng Liu
   Jabil

   EMail: Xufeng_Liu@jabil.com

   Email: xufeng.liu.ietf@gmail.com

   Hariharan Ananthakrishnan
   Packet Design

   EMail:

   Email: hari@packetdesign.com

   Nitin Bahadur
   Bracket Computing

   EMail:

   Email: nitin_bahadur@yahoo.com