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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/