summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8346.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8346.txt')
-rw-r--r--doc/rfc/rfc8346.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc8346.txt b/doc/rfc/rfc8346.txt
new file mode 100644
index 0000000..ce6db97
--- /dev/null
+++ b/doc/rfc/rfc8346.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+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]
+