Internet DRAFT - draft-ietf-i2rs-yang-l3-topology
draft-ietf-i2rs-yang-l3-topology
Network Working Group A. Clemm
Internet-Draft Huawei USA
Intended status: Standards Track J. Medved
Expires: June 19, 2018 Cisco
R. Varga
Pantheon Technologies SRO
X. Liu
Jabil
H. Ananthakrishnan
Packet Design
N. Bahadur
Bracket Computing
December 16, 2017
A YANG Data Model for Layer 3 Topologies
draft-ietf-i2rs-yang-l3-topology-16.txt
Abstract
This document defines a YANG data model for layer 3 network
topologies.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 19, 2018.
Copyright Notice
Copyright (c) 2017 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
Clemm, et al. Expires June 19, 2018 [Page 1]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
4. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4
5. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5
6. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7
7. Interactions with Other YANG Modules . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Companion YANG model for non-NMDA compliant
implementations . . . . . . . . . . . . . . . . . . 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
This document introduces a YANG [RFC7950] [RFC6991] data model for
Layer 3 network topologies, specifically Layer 3 Unicast. The model
allows an application to have a holistic view of the topology of a
Layer 3 network, all contained in a single conceptual YANG datastore.
The data model builds on top of, and augments, the data model for
network topologies defined in
[I-D.draft-ietf-i2rs-yang-network-topo].
This document also shows how the model can be further refined to
cover different Layer 3 Unicast topology types. For this purpose, an
example model is introduced that covers OSPF [RFC2328]. This example
is intended purely for illustrative purpose; we expect that a
complete OSPF model will be more comprehensive and refined than the
example shown here.
Clemm, et al. Expires June 19, 2018 [Page 2]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
There are multiple applications for a topology data model. A number
of use cases have been defined in section 6 of
[I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes
within the network can use the data model to capture their
understanding of the overall network topology and expose it to a
network controller. A network controller can then use the
instantiated topology data to compare and reconcile its own view of
the network topology with that of the network elements that it
controls. Alternatively, nodes within the network could propagate
this understanding to compare and reconcile this understanding either
amongst themselves or with help of a controller. Beyond the network
element itself, a network controller might even use the data model to
represent its view of the topology that it controls and expose it to
applications north of itself.
The data model for Layer 3 Unicast topologies defined in this
document is specified in a YANG module "ietf-l3-unicast-topology".
To do so, it augments the general network topology model defined in
[I-D.draft-ietf-i2rs-yang-network-topo] with information specific to
Layer 3 Unicast. This way, the general topology model is extended to
be able to meet the needs of Layer 3 Unicast topologies.
Information that is kept in the Traffic Engineering Database (TED)
will be specified in a separate model
[I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this
specification.
2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definitions and Acronyms
As this document defines a YANG data model, in this document many
terms are used that have been defined in conjunction with YANG
[RFC7950] and NETCONF [RFC6241]. Some terms, such as datastore and
data tree, are repeated here for clarity and to put them in context.
Datastore: A conceptual place to store and access information. A
datastore might be implemented, for example, using files, a database,
flash memory locations, or combinations thereof. A datastore maps to
an instantiated YANG data tree. (Definition adopted from
[I-D.draft-ietf-netmod-revised-datastores])
Clemm, et al. Expires June 19, 2018 [Page 3]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
Data subtree: An instantiated data node and the data nodes that are
hierarchically contained within it.
IGP: Interior Gateway Protocol
IS-IS: Intermediate System to Intermediate System protocol
LSP: Label Switched Path
NETCONF: Network Configuration Protocol
NMDA: Network Management Datastore Architecture
OSPF: Open Shortest Path First, a link state routing protocol
URI: Uniform Resource Identifier
SRLG: Shared Risk Link Group
TED: Traffic Engineering Database
YANG: YANG is a data modeling language used to model configuration
data, state data, Remote Procedure Calls, and notifications for
network management protocols [RFC7950]
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.
Clemm, et al. Expires June 19, 2018 [Page 4]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
+-----------------------------+
| +-----------------------+ |
| | 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
[I-D.draft-ietf-i2rs-yang-network-topo]. YANG module "ietf-l3-
unicast-topology" augments those models with additional definitions
needed to represent Layer 3 Unicast topologies. This module in turn
can be augmented by YANG modules with additional definitions for
specific types of Layer 3 Unicast topologies, such as OSPF and for
IS-IS topologies.
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
[I-D.draft-ietf-netmod-revised-datastores]. Accordingly, the same is
true for the YANG modules that augment it. In order to allow
implementations to use the model even in cases when NMDA is not
supported, companion YANG modules (that SHOULD NOT be supported by
implementations that support NMDA) are defined in an Appendix, see
Appendix A.
5. Layer 3 Unicast Topology Model Overview
The Layer 3 Unicast topology model is defined by YANG module "ietf-
l3-unicast-topology". Its structure is depicted in the following
diagram. The notation syntax follows
[I-D.draft-ietf-netmod-yang-tree-diagrams]. For purposes of brevity,
notifications are not depicted.
Clemm, et al. Expires June 19, 2018 [Page 5]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
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.
o Additional topology attributes are introduced, defined in a
grouping, which augments the "network" list of the network module.
The attributes include a name for the topology, as well as a set
of flags (represented through a leaf-list). Each type of flag is
represented by a separate identity. This allows to introduce
additional flags in augmenting modules using additional identities
without needing to revise this module.
Clemm, et al. Expires June 19, 2018 [Page 6]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
o Additional data objects for nodes are introduced by augmenting the
"node" list of the network module. New objects include again a
set of flags, as well as a list of prefixes. Each prefix in turn
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 as well, allowing to associate a link with a
link name, another set of flags, and a link metric.
o Termination points (in the ietf-network-topology module as well)
are augmented with a choice of IP address, identifier, or name.
In addition, the module defines a set of notifications to alert
clients of any events concerning links, nodes, prefixes, and
termination points. Each notification includes an indication of the
type of event, the topology from which it originated, and the
affected node, or link, or prefix, or termination point. In
addition, as a convenience to applications, additional data of the
affected node, or link, or termination point (respectively) is
included. While this makes notifications larger in volume than they
would need to be, it avoids the need for subsequent retrieval of
context information, which also might have changed in the meantime.
6. Layer 3 Unicast Topology YANG Module
<CODE BEGINS> file "ietf-l3-unicast-topology@2017-12-16.yang"
module ietf-l3-unicast-topology {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology";
prefix "l3t";
import ietf-network {
prefix "nw";
}
import ietf-network-topology {
prefix "nt";
}
import ietf-inet-types {
prefix "inet";
}
import ietf-routing-types {
prefix "rt-types";
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/>
Clemm, et al. Expires June 19, 2018 [Page 7]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>";
description
"This module defines a model for Layer 3 Unicast
topologies.
Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of
draft-ietf-i2rs-yang-l3-topology-16;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-l3-topology-16 with RFC
number when published (i.e. RFC xxxx).";
revision "2017-12-16" {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-l3-topology-16 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-l3-topology-16";
}
identity flag-identity {
description "Base type for flags";
}
typedef l3-event-type {
type enumeration {
enum "add" {
description
Clemm, et al. Expires June 19, 2018 [Page 8]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
"An Layer 3 node or link or prefix or termination-point has
been added";
}
enum "remove" {
description
"An Layer 3 node or link or prefix or termination-point has
been removed";
}
enum "update" {
description
"An Layer 3 node or link or prefix or termination-point has
been updated";
}
}
description "Layer 3 Event type for notifications";
}
typedef prefix-flag-type {
type identityref {
base "flag-identity";
}
description "Prefix flag attributes";
}
typedef node-flag-type {
type identityref {
base "flag-identity";
}
description "Node flag attributes";
}
typedef link-flag-type {
type identityref {
base "flag-identity";
}
description "Link flag attributes";
}
typedef l3-flag-type {
type identityref {
base "flag-identity";
}
description "L3 flag attributes";
}
grouping l3-prefix-attributes {
description
"L3 prefix attributes";
Clemm, et al. Expires June 19, 2018 [Page 9]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
leaf prefix {
type inet:ip-prefix;
description
"IP prefix value";
}
leaf metric {
type uint32;
description
"Prefix metric";
}
leaf-list flag {
type prefix-flag-type;
description
"Prefix flags";
}
}
grouping l3-unicast-topology-type {
description "Identify the topology type to be L3 unicast.";
container l3-unicast-topology {
presence "indicates L3 Unicast Topology";
description
"The presence of the container node indicates L3 Unicast
Topology";
}
}
grouping l3-topology-attributes {
description "Topology scope attributes";
container l3-topology-attributes {
description "Containing topology attributes";
leaf name {
type string;
description
"Name of the topology";
}
leaf-list flag {
type l3-flag-type;
description
"Topology flags";
}
}
}
grouping l3-node-attributes {
description "L3 node scope attributes";
container l3-node-attributes {
description
"Containing node attributes";
leaf name {
type inet:domain-name;
Clemm, et al. Expires June 19, 2018 [Page 10]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
description
"Node name";
}
leaf-list flag {
type node-flag-type;
description
"Node flags";
}
leaf-list router-id {
type rt-types:router-id;
description
"Router-id for the node";
}
list prefix {
key "prefix";
description
"A list of prefixes along with their attributes";
uses l3-prefix-attributes;
}
}
}
grouping l3-link-attributes {
description
"L3 link scope attributes";
container l3-link-attributes {
description
"Containing link attributes";
leaf name {
type string;
description
"Link Name";
}
leaf-list flag {
type link-flag-type;
description
"Link flags";
}
leaf metric1 {
type uint64;
description
"Link Metric 1";
}
leaf metric2 {
type uint64;
description
"Link Metric 2";
}
}
Clemm, et al. Expires June 19, 2018 [Page 11]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
}
grouping l3-termination-point-attributes {
description "L3 termination point scope attributes";
container l3-termination-point-attributes {
description
"Containing termination point attributes";
choice termination-point-type {
description
"Indicates the termination point type";
case ip {
leaf-list ip-address {
type inet:ip-address;
description
"IPv4 or IPv6 address.";
}
}
case unnumbered {
leaf unnumbered-id {
type uint32;
description
"Unnumbered interface identifier.
The identifier will correspond to the ifIndex value
of the interface, i.e. the ifIndex value of the
ifEntry that represents the interface in
implementations where the Interfaces Group MIB
(RFC 2863) is supported.";
reference
"RFC 2863: The Interfaces Group MIB";
}
}
case interface-name {
leaf interface-name {
type string;
description
"A name of the interface. The name can (but does not
have to) correspond to an interface reference of a
containing node's interface, i.e. the path name of a
corresponding interface data node on the containing
node reminiscent of data type if-ref defined in
RFC 7223. It should be noted that data type if-ref of
RFC 7223 cannot be used directly, as this data type
is used to reference an interface in a datastore of
a single node in the network, not to uniquely
reference interfaces across a network.";
}
}
}
}
Clemm, et al. Expires June 19, 2018 [Page 12]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
}
augment "/nw:networks/nw:network/nw:network-types" {
description
"Introduce new network type for L3 unicast topology";
uses l3-unicast-topology-type;
}
augment "/nw:networks/nw:network" {
when "nw:network-types/l3t:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description
"L3 unicast for the network as a whole";
uses l3-topology-attributes;
}
augment "/nw:networks/nw:network/nw:node" {
when "../nw:network-types/l3t:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description
"L3 unicast node level attributes ";
uses l3-node-attributes;
}
augment "/nw:networks/nw:network/nt:link" {
when "../nw:network-types/l3t:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description
"Augment topology link attributes";
uses l3-link-attributes;
}
augment "/nw:networks/nw:network/nw:node/"
+"nt:termination-point" {
when "../../nw:network-types/l3t:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description "Augment topology termination point configuration";
uses l3-termination-point-attributes;
}
notification l3-node-event {
description
Clemm, et al. Expires June 19, 2018 [Page 13]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
"Notification event for L3 node";
leaf l3-event-type {
type l3-event-type;
description
"Event type";
}
uses nw:node-ref;
uses l3-unicast-topology-type;
uses l3-node-attributes;
}
notification l3-link-event {
description
"Notification event for L3 link";
leaf l3-event-type {
type l3-event-type;
description
"Event type";
}
uses nt:link-ref;
uses l3-unicast-topology-type;
uses l3-link-attributes;
}
notification l3-prefix-event {
description
"Notification event for L3 prefix";
leaf l3-event-type {
type l3-event-type;
description
"Event type";
}
uses nw:node-ref;
uses l3-unicast-topology-type;
container prefix {
description
"Containing L3 prefix attributes";
uses l3-prefix-attributes;
}
}
notification termination-point-event {
description
"Notification event for L3 termination point";
leaf l3-event-type {
type l3-event-type;
description
"Event type";
}
uses nt:tp-ref;
uses l3-unicast-topology-type;
Clemm, et al. Expires June 19, 2018 [Page 14]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
uses l3-termination-point-attributes;
}
}
<CODE ENDS>
7. Interactions with Other YANG Modules
As described in section Section 4, the model builds on top of, and
augments, the YANG modules defined in
[I-D.draft-ietf-i2rs-yang-network-topo]. Specifically, module ietf-
l3-unicast-topology augments modules "ietf-network" and "ietf-
network-topology". In addition, the model makes use of data types
that have been defined in [RFC6991].
The model defines a protocol independent YANG data model with layer 3
topology information. It is separate from and not linked with data
models that are used to configure routing protocols or routing
information. This includes e.g. model "ietf-routing" [RFC8022] and
model "ietf-fb-rib" [I-D.draft-acee-rtgwg-yang-rib-extend]. That
said, the model does import a type definition from model "ietf-
routing-types" [RFC8294].
The model obeys the requirements for the ephemeral state found in the
document [RFC8242]. For ephemeral topology data that is server
provided, the process tasked with maintaining topology information
will load information from the routing process (such as OSPF) into
the data model without relying on a configuration datastore.
8. IANA Considerations
This document registers the following namespace URIs in the "IETF XML
Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]:
Name: ietf-l3-unicast-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Prefix: l3t
Clemm, et al. Expires June 19, 2018 [Page 15]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
Reference: draft-ietf-i2rs-yang-l3-topology-16.txt (RFC form)
Name: ietf-l3-unicast-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Prefix: l3t-s
Reference: draft-ietf-i2rs-yang-l3-topology-16.txt (RFC form)
9. Security Considerations
The YANG module defined in this document is designed to be accessed
via network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS [RFC5246].
The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
In general, Layer 3 Unicast topologies are system-controlled and
provide ephemeral topology information. In an NMDA-complient server,
they are only part of <operational> which provides read-only access
to clients, they are less vulnerable. That said, the YANG module
does in principle allow information to be configurable.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability in the ietf-network module:
l3-topology-attributes: A malicious client could attempt to
sabotage the configuration of any of the ctonained attributes,
i.e. the name or the flag data nodes.
l3-node-attributes: A malicious client could attempt to sabotage
the configuration of important node attributes, such as the
router-id or node prefix.
l3-link-attributes: A malicious client could attempt to sabotage
the configuration of important link attributes, such as name,
flag, and metrics of the link respectively corresponding data
nodes.
Clemm, et al. Expires June 19, 2018 [Page 16]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
l3-termination-point-attributes: A malicious client could attempt
to sabotage the configuration information of a termination point,
such as its ip-address and interface name, respectively the
corresponding data nodes.
10. Contributors
The model presented in this document was contributed to by more
people than can be listed on the author list. Additional
contributors include:
o Vishnu Pavan Beeram, Juniper
o Igor Bryskin, Huawei
o Ken Gray, Cisco
o Aihua Guo, Huawei
o Tom Nadeau, Brocade
o Tony Tkacik
o Aleksandr Zhdankin, Cisco
11. Acknowledgements
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.
12. References
12.1. Normative References
[I-D.draft-ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", I-D draft-ietf-i2rs-yang-network-
topo-19, December 2017.
[I-D.draft-ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG
Datastores", I-D draft-ietf-netmod-revised-datastores-06,
October 2017.
Clemm, et al. Expires June 19, 2018 [Page 17]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, August 2016.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
December 2014.
Clemm, et al. Expires June 19, 2018 [Page 18]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
12.2. Informative References
[I-D.draft-acee-rtgwg-yang-rib-extend]
Lindem, A. and Y. Qu, "YANG Data Model for RIB
Extensions", I-D draft-acee-rtgwg-yang-rib-extend-05,
October 2017.
[I-D.draft-ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary-
03, November 2016.
[I-D.draft-ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", I-D
draft-ietf-netmod-yang-tree-diagrams, October 2017.
[I-D.draft-ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez De Dios, "YANG Data Model for TE Topologies",
I-D draft-ietf-teas-yang-te-topo-13, October 2017.
[RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management",
RFC 7223, May 2014.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, November 2016.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[RFC8242] Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", RFC 8242, September 2017.
Clemm, et al. Expires June 19, 2018 [Page 19]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
Appendix A. Companion YANG model for non-NMDA compliant implementations
The YANG module ietf-l3-unicast-topology defined in this document
augments two modules, ietf-network and ietf-network-topology, that
are designed to be used in conjunction with implementations that
support the Network Management Datastore Architecture (NMDA) defined
in [I-D.draft-ietf-netmod-revised-datastores]. In order to allow
implementations to use the model even in cases when NMDA is not
supported, a set of companion modules have been defined that
represent a state model of networks and network topologies, ietf-
network-state and ietf-network-topology-state, respectively.
In order to be able to use the model for layer 3 topologies defined
in this in this document in conjunction with non-NMDA compliant
implementations, a corresponding companion module needs to be
introduced as well. This companion module, ietf-l3-unicast-topology-
state, mirrors ietf-l3-unicast-topology. However, the module
augments ietf-network-state and ietf-network-topology-state (instead
of ietf-network and ietf-network-topology) and all of its data nodes
are non-configurable.
Similar considerations apply for any modules that augment ietf-l3-
unicast-topology, such as the example modules defined in see
Appendix B, example-ospf-topology. For non-NMDA compliant
implementations, companion modules will need to be introduced that
represent state information and are non-configurable, augmenting
ietf-l3-unicast-topology-state instead of ietf-l3-unicast-topology.
Because they served as examples only, companion modules for those
examples are not given.
Like ietf-network-state and ietf-network-topology-state, ietf-l3-
unicast-topology SHOULD NOT be supported by implementations that
support NMDA. It is for this reason that the module is defined in
the Appendix.
The definition of the module follows below. As the structure of the
module mirrors that of its underlying module, the YANG tree is not
depicted separately.
<CODE BEGINS> file "ietf-l3-unicast-topology-state@2017-12-16.yang"
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. Expires June 19, 2018 [Page 20]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
import ietf-network-topology-state {
prefix "nt-s";
}
import ietf-l3-unicast-topology {
prefix "l3t";
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>";
description
"This module defines a model for Layer 3 Unicast topology
state, representing topology that is either learned, or topology
that results from applying topology that has been configured per
the ietf-l3-unicast-topology model, mirroring the corresponding
data nodes in this model.
The model mirrors ietf-l3-unicast-topology, but contains only
read-only state data. The model is not needed when the
underlying implementation infrastructure supports the Network
Management Datastore Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of
draft-ietf-i2rs-yang-l3-topology-16;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-l3-topology-16 with RFC
Clemm, et al. Expires June 19, 2018 [Page 21]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
number when published (i.e. RFC xxxx).";
revision "2017-12-16" {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-l3-topology-16 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-l3-topology-16";
}
augment "/nw-s:networks/nw-s:network/nw-s:network-types" {
description
"Introduce new network type for L3 unicast topology";
uses l3t:l3-unicast-topology-type;
}
augment "/nw-s:networks/nw-s:network" {
when "nw-s:network-types/l3t-s:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description
"L3 unicast for the network as a whole";
uses l3t:l3-topology-attributes;
}
augment "/nw-s:networks/nw-s:network/nw-s:node" {
when "../nw-s:network-types/l3t-s:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description
"L3 unicast node level attributes ";
uses l3t:l3-node-attributes;
}
augment "/nw-s:networks/nw-s:network/nt-s:link" {
when "../nw-s:network-types/l3t-s:l3-unicast-topology" {
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description
"Augment topology link attributes";
uses l3t:l3-link-attributes;
}
augment "/nw-s:networks/nw-s:network/nw-s:node/"
+"nt-s:termination-point" {
when "../../nw-s:network-types/l3t-s:l3-unicast-topology" {
Clemm, et al. Expires June 19, 2018 [Page 22]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
description
"Augmentation parameters apply only for networks with
L3 unicast topology";
}
description "Augment topology termination point configuration";
uses l3t:l3-termination-point-attributes;
}
notification l3-node-event {
description
"Notification event for L3 node";
leaf l3-event-type {
type l3t:l3-event-type;
description
"Event type";
}
uses nw-s:node-ref;
uses l3t:l3-unicast-topology-type;
uses l3t:l3-node-attributes;
}
notification l3-link-event {
description
"Notification event for L3 link";
leaf l3-event-type {
type l3t:l3-event-type;
description
"Event type";
}
uses nt-s:link-ref;
uses l3t:l3-unicast-topology-type;
uses l3t:l3-link-attributes;
}
notification l3-prefix-event {
description
"Notification event for L3 prefix";
leaf l3-event-type {
type l3t:l3-event-type;
description
"Event type";
}
uses nw-s:node-ref;
uses l3t:l3-unicast-topology-type;
container prefix {
description
"Containing L3 prefix attributes";
uses l3t:l3-prefix-attributes;
}
}
notification termination-point-event {
Clemm, et al. Expires June 19, 2018 [Page 23]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
description
"Notification event for L3 termination point";
leaf l3-event-type {
type l3t:l3-event-type;
description
"Event type";
}
uses nt-s:tp-ref;
uses l3t:l3-unicast-topology-type;
uses l3t:l3-termination-point-attributes;
}
}
<CODE ENDS>
Appendix B. Extending the Model
The model can be extended for specific Layer 3 Unicast types.
Examples include OSPF and IS-IS topologies. In the following, one
additional YANG module is introduced that define simple topology
model for OSPF. This module is intended to serve as an example that
illustrates how the general topology model can be refined across
multiple levels. It does not constitute full-fledged OSPF topology
model which may be more comprehensive and refined than the model that
is described here.
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 OSFP topologies. For this
purpose, a set of augmentations are introduced in a separate YANG
module, "example-ospf-topology", whose structure is depicted in the
following diagram. As before, the notation syntax follows
[I-D.draft-ietf-netmod-yang-tree-diagrams].
Clemm, et al. Expires June 19, 2018 [Page 24]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
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 which
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. Expires June 19, 2018 [Page 25]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
o Additional data objects for nodes are introduced by augmenting the
l3-node-attributes of the l3-unicast-topology module. New objects
include router-type and dr-interface-id for pseudonodes.
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 OSFP 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
OSFP topologies.";
typedef area-id-type {
type yang:dotted-quad;
description
"Area ID type.";
}
grouping ospf-topology-type {
Clemm, et al. Expires June 19, 2018 [Page 26]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
description
"Identifies the OSPF topology type.";
container ospf {
presence "indicates OSPF Topology";
description
"Its presence identifies the OSPF topology type.";
}
}
augment "/nw:networks/nw:network/nw:network-types/"
+ "l3t:l3-unicast-topology" {
description
"Defines the OSPF topology type.";
uses ospf-topology-type;
}
augment "/nw:networks/nw:network/l3t:l3-topology-attributes" {
when "../nw:network-types/l3t:l3-unicast-topology/" +
"ex-ospft:ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment topology configuration";
container ospf-topology-attributes {
description
"Containing topology attributes";
leaf area-id {
type area-id-type;
description
"OSPF area ID";
}
}
}
augment "/nw:networks/nw:network/nw:node/l3t:l3-node-attributes" {
when "../../nw:network-types/l3t:l3-unicast-topology/" +
"ex-ospft:ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment node configuration";
uses ospf-node-attributes;
}
augment "/nw:networks/nw:network/nt:link/l3t:l3-link-attributes" {
when "../../nw:network-types/l3t:l3-unicast-topology/" +
"ex-ospft:ospf" {
description
"Augment only for OSPF topology";
}
Clemm, et al. Expires June 19, 2018 [Page 27]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
description
"Augment link configuration";
uses ospf-link-attributes;
}
grouping ospf-node-attributes {
description
"OSPF node scope attributes";
container ospf-node-attributes {
description
"Containing node attributes";
choice router-type {
description
"Indicates router type";
case abr {
leaf abr {
type empty;
description
"The node is ABR";
}
}
case asbr {
leaf asbr {
type empty;
description
"The node is ASBR";
}
}
case internal {
leaf internal {
type empty;
description
"The node is internal";
}
}
case pseudonode {
leaf pseudonode {
type empty;
description
"The node is pseudonode";
}
}
}
leaf dr-interface-id {
when "../pseudonode" {
description
"Valid only for pseudonode";
}
type uint32;
Clemm, et al. Expires June 19, 2018 [Page 28]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
default "0";
description
"For pseudonodes, DR interface-id";
}
}
}
grouping ospf-link-attributes {
description
"OSPF link scope attributes";
container ospf-link-attributes {
description
"Containing OSPF link attributes";
}
} // ospf-link-attributes
augment "/l3t:l3-node-event" {
description
"OSPF node event";
uses ospf-topology-type;
uses ospf-node-attributes;
}
augment "/l3t:l3-link-event" {
description
"OSPF link event";
uses ospf-topology-type;
uses ospf-link-attributes;
}
}
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. Expires June 19, 2018 [Page 29]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
+------------+ +------------+
| 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:
{
"ietf-network:networks": {
"network": [
{
"network-types": {
"ietf-l3-unicast-topology:l3-unicast-topology": {}
},
"network-id": "l3-topo-example",
"node": [
{
"node-id": "D1",
"termination-point": [
{
"tp-id": "1-0-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 101
}
},
{
"tp-id": "1-2-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 121
Clemm, et al. Expires June 19, 2018 [Page 30]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
}
},
{
"tp-id": "1-3-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 131
}
}
],
"ietf-l3-unicast-topology:l3-node-attributes": {
"router-id": ["203.0.113.1"]
}
},
{
"node-id": "D2",
"termination-point": [
{
"tp-id": "2-0-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 201
}
},
{
"tp-id": "2-1-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 211
}
},
{
"tp-id": "2-3-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 231
}
}
],
"ietf-l3-unicast-topology:l3-node-attributes": {
"router-id": ["203.0.113.2"]
}
},
{
"node-id": "D3",
"termination-point": [
{
"tp-id": "3-1-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 311
}
},
Clemm, et al. Expires June 19, 2018 [Page 31]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
{
"tp-id": "3-2-1",
"ietf-l3-unicast-topology:l3-termination-point-attributes": {
"unnumbered-id:": 321
}
}
],
"ietf-l3-unicast-topology:l3-node-attributes": {
"router-id": ["203.0.113.3"]
}
}
],
"ietf-network-topology:link": [
{
"link-id": "D1,1-2-1,D2,2-1-1",
"destination": {
"source-node": "D1",
"source-tp": "1-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-1-1"
},
"ietf-l3-unicast-topology:l3-link-attributes": {
"metric1": "100"
}
},
{
"link-id": "D2,2-1-1,D1,1-2-1",
"destination": {
"source-node": "D2",
"source-tp": "2-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-2-1"
},
"ietf-l3-unicast-topology:l3-link-attributes": {
"metric1": "100"
}
},
{
"link-id": "D1,1-3-1,D3,3-1-1",
"destination": {
"source-node": "D1",
"source-tp": "1-3-1"
}
"destination": {
Clemm, et al. Expires June 19, 2018 [Page 32]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
"dest-node": "D3",
"dest-tp": "3-1-1"
},
"ietf-l3-unicast-topology:l3-link-attributes": {
"metric1": "100"
}
},
{
"link-id": "D3,3-1-1,D1,1-3-1",
"destination": {
"source-node": "D3",
"source-tp": "3-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-3-1"
},
"ietf-l3-unicast-topology:l3-link-attributes": {
"metric1": "100"
}
},
{
"link-id": "D2,2-3-1,D3,3-2-1",
"destination": {
"source-node": "D2",
"source-tp": "2-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-2-1"
},
"ietf-l3-unicast-topology:l3-link-attributes": {
"metric1": "100"
}
},
{
"link-id": "D3,3-2-1,D2,2-3-1",
"destination": {
"source-node": "D3",
"source-tp": "3-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-3-1"
},
"ietf-l3-unicast-topology:l3-link-attributes": {
"metric1": "100"
}
Clemm, et al. Expires June 19, 2018 [Page 33]
Internet-Draft draft-ietf-i2rs-yang-l3-topology-16.txt December 2017
}
]
}
]
}
}
Figure 3: Instance data tree
Authors' Addresses
Alexander Clemm
Huawei USA
EMail: ludwig@clemm.org
Jan Medved
Cisco
EMail: jmedved@cisco.com
Robert Varga
Pantheon Technologies SRO
EMail: robert.varga@pantheon.tech
Xufeng Liu
Jabil
EMail: Xufeng_Liu@jabil.com
Hariharan Ananthakrishnan
Packet Design
EMail: hari@packetdesign.com
Nitin Bahadur
Bracket Computing
EMail: nitin_bahadur@yahoo.com
Clemm, et al. Expires June 19, 2018 [Page 34]
