GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8346

Internet Engineering Task Force (IETF) A. Clemm Request for Comments: 8346 Huawei Category: Standards Track J. Medved ISSN: 2070-1721 Cisco

                                                              R. Varga
                                             Pantheon Technologies SRO
                                                                X. Liu
                                                                 Jabil
                                                    H. Ananthakrishnan
                                                         Packet Design
                                                            N. Bahadur
                                                     Bracket Computing
                                                            March 2018
              A YANG Data Model for Layer 3 Topologies

Abstract

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

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8346.

Clemm, et al. Standards Track [Page 1] RFC 8346 YANG Data Model for L3 Topologies March 2018

Copyright Notice

 Copyright (c) 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 ....................................................3
 2. Key Words .......................................................3
 3. Definitions and Acronyms ........................................4
 4. Model Structure .................................................5
 5. Layer 3 Unicast Topology Model Overview .........................6
 6. Layer 3 Unicast Topology YANG Module ............................7
 7. Interactions with Other YANG Modules ...........................15
 8. IANA Considerations ............................................15
 9. Security Considerations ........................................16
 10. References ....................................................17
    10.1. Normative References .....................................17
    10.2. Informative References ...................................19
 Appendix A.  Companion YANG Data Model for Implementations Not
              Compliant with NMDA ..................................20
 Appendix B.  Extending the Model ..................................24
   B.1.  Example OSPF Topology .....................................24
     B.1.1.  Model Overview ........................................24
     B.1.2.  OSPF Topology YANG Module .............................26
 Appendix C.  An Example ...........................................29
 Acknowledgments ...................................................34
 Contributors ......................................................34
 Authors' Addresses ................................................35

Clemm, et al. Standards Track [Page 2] RFC 8346 YANG Data Model for L3 Topologies March 2018

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 [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 in this document.
 There are multiple applications for a topology data model.  A number
 of use cases have been defined in Section 6 of [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 the YANG module "ietf-l3-unicast-topology".
 This YANG module augments the general network topology model defined
 in [RFC8345] with information specific to Layer 3 Unicast.  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 [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.

Clemm, et al. Standards Track [Page 3] RFC 8346 YANG Data Model for L3 Topologies March 2018

3. Definitions and Acronyms

 This document defines a YANG data model and thus uses many terms
 defined in YANG [RFC7950] and NETCONF [RFC6241].  Some terms, such as
 "datastore" and "data tree", are repeated here for clarity and
 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
    adopted from [RFC8342]).
 Data subtree:  An instantiated data node and the data nodes that are
    hierarchically contained within it.
 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 routing protocol)
 URI:  Uniform Resource Identifier
 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].

Clemm, et al. Standards Track [Page 4] RFC 8346 YANG Data Model for L3 Topologies March 2018

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
 YANG modules "ietf-network" and "ietf-network-topology" collectively
 define the basic network topology model [RFC8345].  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 IS-IS topologies.
 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
 [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 Appendix A.

Clemm, et al. Standards Track [Page 5] RFC 8346 YANG Data Model for L3 Topologies March 2018

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 [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" and "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" module.

Clemm, et al. Standards Track [Page 6] RFC 8346 YANG Data Model for L3 Topologies March 2018

 o  Additional topology attributes are introduced, defined in a
    grouping that augments the "network" list of the network module.
    The attributes include a name for the topology and a set of flags
    (represented by a leaf-list).  Each type of flag is represented by
    a separate identity.  This allows 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 a set of
    flags and a list of prefixes.  Each prefix includes an IP prefix,
    a metric, and a prefix-specific set of flags.
 o  Links (in the "ietf-network-topology" module) are augmented with a
    set of parameters 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) 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, link, prefix, or termination point.  Also, as a
 convenience to applications, additional data of the affected node,
 link, prefix, or termination point is included.  While this makes
 notifications larger in volume than they need to be, it avoids the
 need for subsequent retrieval of context 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@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";
   }

Clemm, et al. Standards Track [Page 7] RFC 8346 YANG Data Model for L3 Topologies March 2018

   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:    <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: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) 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
      (https://trustee.ietf.org/license-info).
      This version of this YANG module is part of
      RFC 8346; see the RFC itself for full legal notices.";
   revision "2018-02-26" {
     description
       "Initial revision.";
     reference
       "RFC 8346: A YANG Data Model for Layer 3 Topologies";
   }
   identity flag-identity {
     description "Base type for flags";

Clemm, et al. Standards Track [Page 8] RFC 8346 YANG Data Model for L3 Topologies March 2018

   }
   typedef l3-event-type {
     type enumeration {
       enum "add" {
         description
           "A Layer 3 node, link, prefix, or termination point has
           been added";
       }
       enum "remove" {
         description
           "A Layer 3 node, link, prefix, or termination point has
           been removed";
       }
       enum "update" {
         description
           "A Layer 3 node, link, 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";
     }

Clemm, et al. Standards Track [Page 9] RFC 8346 YANG Data Model for L3 Topologies March 2018

     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 "Identifies 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 "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 {

Clemm, et al. Standards Track [Page 10] RFC 8346 YANG Data Model for L3 Topologies March 2018

     description "L3 node scope attributes";
     container l3-node-attributes {
       description
         "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
         "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";
       }

Clemm, et al. Standards Track [Page 11] RFC 8346 YANG Data Model for L3 Topologies March 2018

       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
         "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., 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
               "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 interface-ref defined
                in RFC 8343. It should be noted that data type
                interface-ref of RFC 8343 cannot be used directly,

Clemm, et al. Standards Track [Page 12] RFC 8346 YANG Data Model for L3 Topologies March 2018

                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
       "Introduces 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
       "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" {

Clemm, et al. Standards Track [Page 13] RFC 8346 YANG Data Model for L3 Topologies March 2018

       description
         "Augmentation parameters apply only for networks with
         L3 Unicast topology";
     }
     description "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
         "Contains L3 prefix attributes";
       uses l3-prefix-attributes;
     }
   }
   notification termination-point-event {

Clemm, et al. Standards Track [Page 14] RFC 8346 YANG Data Model for L3 Topologies March 2018

     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 4, the model defined in this document builds
 on top of, and augments, the YANG modules defined in [RFC8345].
 Specifically, the "ietf-l3-unicast-topology" module augments the
 "ietf-network" and "ietf-network-topology" modules.  In addition, the
 model makes use of data types defined in [RFC6991].
 The model defined in this document is 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, e.g., "ietf-routing" [RFC8022] and
 "ietf-rib-extension" [YANG-RIB].  That said, the model does import a
 type definition from model "ietf-routing-types" [RFC8294].
 The model complies with the requirements for the ephemeral state
 found in [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.

Clemm, et al. Standards Track [Page 15] RFC 8346 YANG Data Model for L3 Topologies March 2018

 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: RFC 8346
 Name: ietf-l3-unicast-topology-state
 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
 Prefix: l3t-s
 Reference: RFC 8346

9. Security Considerations

 The YANG 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 [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-compliant server,
 they are only part of <operational>, which provides read-only access
 to clients, so they are less vulnerable.  That said, the YANG modules
 do in principle allow information to be configurable.
 There are a number of data nodes defined in these YANG 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-l3-unicast-topology"
 module:
 o  l3-topology-attributes: A malicious client could attempt to
    sabotage the configuration of any of the contained attributes,
    i.e., the name or the flag data nodes.

Clemm, et al. Standards Track [Page 16] RFC 8346 YANG Data Model for L3 Topologies March 2018

 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.
 o  l3-termination-point-attributes: A malicious client could attempt
    to sabotage the configuration information of a termination point,
    such as the termination point's IP address and interface name.

10. References

10.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
            DOI 10.17487/RFC2328, April 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,
            <https://www.rfc-editor.org/info/rfc2863>.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            DOI 10.17487/RFC3688, January 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,
            <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,
            <https://www.rfc-editor.org/info/rfc6020>.
 [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
            and A. Bierman, Ed., "Network Configuration Protocol
            (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
            <https://www.rfc-editor.org/info/rfc6241>.

Clemm, et al. Standards Track [Page 17] RFC 8346 YANG Data Model for L3 Topologies March 2018

 [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
            Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
            <https://www.rfc-editor.org/info/rfc6242>.
 [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
            RFC 6991, DOI 10.17487/RFC6991, July 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,
            <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,
            <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 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, "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", RFC 8345, DOI 10.17487/RFC8345, March
            2018, <https://www.rfc-editor.org/info/rfc8345>.

Clemm, et al. Standards Track [Page 18] RFC 8346 YANG Data Model for L3 Topologies March 2018

10.2. Informative References

 [RFC8022]  Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
            Management", RFC 8022, DOI 10.17487/RFC8022, November
            2016, <https://www.rfc-editor.org/info/rfc8022>.
 [RFC8242]  Haas, J. and S. Hares, "Interface to the Routing System
            (I2RS) Ephemeral State Requirements", RFC 8242,
            DOI 10.17487/RFC8242, September 2017,
            <https://www.rfc-editor.org/info/rfc8242>.
 [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
            BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
            <https://www.rfc-editor.org/info/rfc8340>.
 [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", Work in Progress, draft-ietf-i2rs-usecase-
            reqs-summary-03, November 2016.
 [YANG-RIB] Lindem, A. and Y. Qu, "RIB YANG Data 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 Dios, "YANG Data Model for Traffic
            Engineering (TE) Topologies", Work in Progress,
            draft-ietf-teas-yang-te-topo-15, February 2018.

Clemm, et al. Standards Track [Page 19] RFC 8346 YANG Data Model for L3 Topologies March 2018

Appendix A. Companion YANG Data Model for Implementations Not Compliant

           with NMDA
 The YANG module "ietf-l3-unicast-topology" defined in this document
 augments two modules defined in [RFC8345]: "ietf-network" and
 "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 [RFC8342].  In
 order to allow implementations to use the model in cases when NMDA is
 not supported, [RFC8345] defines two companion modules,
 "ietf-network- state" and "ietf-network-topology-state", that
 represent state models of networks and network topologies,
 respectively.
 In order to be able to use the model for Layer 3 topologies defined
 in this document in conjunction with implementations not compliant
 with NMDA, 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.
 Similar considerations apply to any module that augments "ietf-l3-
 unicast-topology", such as the example module defined in Appendix B
 (i.e., example-ospf-topology).  For implementations that are not
 compliant with NMDA, companion modules that represent state
 information and that are non-configurable will need to be introduced.
 These modules augment "ietf-l3-unicast-topology-state" instead of
 "ietf-l3-unicast-topology".  Companion modules for the example module
 defined in Appendix B are not provided (since it is just an example).
 Like "ietf-network-state" and "ietf-network-topology-state",
 "ietf-l3-unicast-topology" SHOULD NOT be supported by implementations
 that support NMDA.  The module is therefore defined in 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@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";

Clemm, et al. Standards Track [Page 20] RFC 8346 YANG Data Model for L3 Topologies March 2018

   }
   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:    <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: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 either is learned or
      results from applying topology that has been configured per
      the 'ietf-l3-unicast-topology' model, mirroring the
      corresponding data nodes in this model.
      This 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) 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
      (https://trustee.ietf.org/license-info).
      This version of this YANG module is part of RFC 8346;
      see the RFC itself for full legal notices.";

Clemm, et al. Standards Track [Page 21] RFC 8346 YANG Data Model for L3 Topologies March 2018

   revision "2018-02-26" {
     description
       "Initial revision.";
     reference
       "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 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
       "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 topology";
     }

Clemm, et al. Standards Track [Page 22] RFC 8346 YANG Data Model for L3 Topologies March 2018

     description "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
         "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;

Clemm, et al. Standards Track [Page 23] RFC 8346 YANG Data Model for L3 Topologies March 2018

       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.  This appendix introduces
 a YANG module that 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, 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, to cover 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 [RFC8340].
 Note that one of the lines has been wrapped to adhere to the
 72-character line limitation of RFCs.

Clemm, et al. Standards Track [Page 24] RFC 8346 YANG Data Model for L3 Topologies March 2018

 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
 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 that
    augments l3-topology-attributes of the "ietf-l3-unicast-topology"
    module.  The attributes include an OSPF area-id identifying the
    OSPF area.

Clemm, et al. Standards Track [Page 25] RFC 8346 YANG Data Model for L3 Topologies March 2018

 o  Additional data objects for nodes are introduced by augmenting the
    l3-node-attributes of the "ietf-l3-unicast-topology" module.  New
    objects include router-type and dr-interface-id for pseudonodes.
 o  Links are augmented with 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 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 OSPF topologies, but it is not
 normative.  Accordingly, the module is not delimited with
 <CODE BEGINS> and <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
        OSPF topologies.";
    typedef area-id-type {
        type yang:dotted-quad;
        description
            "Area ID type.";
    }
    grouping ospf-topology-type {

Clemm, et al. Standards Track [Page 26] RFC 8346 YANG Data Model for L3 Topologies March 2018

        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
                "Augments only for OSPF topology";
            }
        description
            "Augments topology configuration";
        container ospf-topology-attributes {
            description
                "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
                "Augments only for OSPF topology";
        }
        description
            "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
                "Augments only for OSPF topology";
        }

Clemm, et al. Standards Track [Page 27] RFC 8346 YANG Data Model for L3 Topologies March 2018

        description
            "Augments link configuration";
        uses ospf-link-attributes;
    }
    grouping ospf-node-attributes {
        description
            "OSPF node scope attributes";
        container ospf-node-attributes {
            description
                "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;

Clemm, et al. Standards Track [Page 28] RFC 8346 YANG Data Model for L3 Topologies March 2018

                default "0";
                description
                    "For pseudonodes, DR interface-id";
            }
        }
    }
    grouping ospf-link-attributes {
        description
            "OSPF link scope attributes";
        container ospf-link-attributes {
            description
                "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" 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.

Clemm, et al. Standards Track [Page 29] RFC 8346 YANG Data Model for L3 Topologies March 2018

              +------------+                   +------------+
              |     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
 The corresponding instance data tree is depicted 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": {
                   "unnumbered-id:": 101
                 }
               },
               {
                 "tp-id": "1-2-1",

Clemm, et al. Standards Track [Page 30] RFC 8346 YANG Data Model for L3 Topologies March 2018

                 "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",

Clemm, et al. Standards Track [Page 31] RFC 8346 YANG Data Model for L3 Topologies March 2018

             "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",
             "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",
             "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"

Clemm, et al. Standards Track [Page 32] RFC 8346 YANG Data Model for L3 Topologies March 2018

             }
           },
           {
             "link-id": "D1,1-3-1,D3,3-1-1",
             "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",
             "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",
             "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",
             "source": {
               "source-node": "D3",

Clemm, et al. Standards Track [Page 33] RFC 8346 YANG Data Model for L3 Topologies March 2018

               "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

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.

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

Clemm, et al. Standards Track [Page 34] RFC 8346 YANG Data Model for L3 Topologies March 2018

Authors' Addresses

 Alexander Clemm
 Huawei USA - Futurewei Technologies Inc.
 Santa Clara, CA
 United States of America
 Email: ludwig@clemm.org, alexander.clemm@huawei.com
 Jan Medved
 Cisco
 Email: jmedved@cisco.com
 Robert Varga
 Pantheon Technologies SRO
 Email: robert.varga@pantheon.tech
 Xufeng Liu
 Jabil
 Email: xufeng.liu.ietf@gmail.com
 Hariharan Ananthakrishnan
 Packet Design
 Email: hari@packetdesign.com
 Nitin Bahadur
 Bracket Computing
 Email: nitin_bahadur@yahoo.com

Clemm, et al. Standards Track [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8346.txt · Last modified: 2018/03/16 21:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki