draft-ietf-i2rs-yang-network-topo-17.txt   draft-ietf-i2rs-yang-network-topo-18.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: April 25, 2018 Cisco Expires: May 19, 2018 Cisco
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Jabil Jabil
October 22, 2017 November 15, 2017
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-17.txt draft-ietf-i2rs-yang-network-topo-18.txt
Abstract Abstract
This document defines an abstract (generic) YANG data model for This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The data model serves as network/service topologies and inventories. The data model serves as
a base model which is augmented with technology-specific details in a base model which is augmented with technology-specific details in
other, more specific topology and inventory data models. other, more specific topology and inventory data models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2018. This Internet-Draft will expire on May 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
6.1. Defining the Abstract Network: ietf-network.yang . . . . 18 6.1. Defining the Abstract Network: ietf-network.yang . . . . 18
6.2. Creating Abstract Network Topology: ietf-network- 6.2. Creating Abstract Network Topology: ietf-network-
topology.yang . . . . . . . . . . . . . . . . . . . . . . 23 topology.yang . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 35 Appendix A. Model Use Cases . . . . . . . . . . . . . . . . . . 35
A.1. Fetching Topology from a Network Element . . . . . . . . 35 A.1. Fetching Topology from a Network Element . . . . . . . . 35
A.2. Modifying TE Topology Imported from an Optical Controller 35 A.2. Modifying TE Topology Imported from an Optical Controller 35
A.3. Annotating Topology for Local Computation . . . . . . . . 36 A.3. Annotating Topology for Local Computation . . . . . . . . 36
A.4. SDN Controller-Based Configuration of Overlays on Top of A.4. SDN Controller-Based Configuration of Overlays on Top of
Underlays . . . . . . . . . . . . . . . . . . . . . . . . 36 Underlays . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Appendix: Companion YANG models for non-NMDA Appendix B. Companion YANG models for non-NMDA compliant
compliant implementations . . . . . . . . . . . . . 36 implementations . . . . . . . . . . . . . . . . . . 36
B.1. YANG Model for Network State . . . . . . . . . . . . . . 37 B.1. YANG Model for Network State . . . . . . . . . . . . . . 37
B.2. YANG Data Model for Network Topology State . . . . . . . 41 B.2. YANG Data Model for Network Topology State . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix C. An Example . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document introduces an abstract (base) YANG [RFC7950] data model This document introduces an abstract (base) YANG [RFC7950] data model
to represent networks and topologies. The data model is divided into [RFC3444] to represent networks and topologies. The data model is
two parts. The first part of the data model defines a network data divided into two parts. The first part of the data model defines a
model that enables the definition of network hierarchies (i.e. network data model that enables the definition of network hierarchies
network stacks) and to maintain an inventory of nodes contained in a (i.e. network stacks of networks that are layered on top of each
network. The second part of the data model augments the basic other) and to maintain an inventory of nodes contained in a network.
network data model with information to describe topology information. The second part of the data model augments the basic network data
model with information to describe topology information.
Specifically, it adds the concepts of links and termination points to Specifically, it adds the concepts of links and termination points to
describe how nodes in a network are connected to each other. describe how nodes in a network are connected to each other.
Moreover the data model introduces vertical layering relationships Moreover the data model introduces vertical layering relationships
between networks that can be augmented to cover both network between networks that can be augmented to cover both network
inventories and network/service topologies. inventories and network/service topologies.
While it would be possible to combine both parts into a single data While it would be possible to combine both parts into a single data
model, the separation facilitates integration of network topology and model, the separation facilitates integration of network topology and
network inventory data models, by allowing to augment network network inventory data models, because it allows to augment network
inventory information separately and without concern for topology inventory information separately and without concern for topology
into the network data model. into the network data model.
The data model can be augmented to describe specifics of particular The data model can be augmented to describe the specifics of
types of networks and topologies. For example, an augmenting data particular types of networks and topologies. For example, an
model can provide network node information with attributes that are augmenting data model can provide network node information with
specific to a particular network type. Examples of augmenting models attributes that are specific to a particular network type. Examples
include data models for Layer 2 network topologies, Layer 3 network of augmenting models include data models for Layer 2 network
topologies, such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], topologies, Layer 3 network topologies, such as Unicast IGP, IS-IS
traffic engineering (TE) data [RFC3209], or any of the variety of [RFC1195] and OSPF [RFC2328], traffic engineering (TE) data
transport and service topologies. Information specific to particular [RFC3209], or any of the variety of transport and service topologies.
network types will be captured in separate, technology-specific data Information specific to particular network types will be captured in
models. separate, technology-specific data models.
The basic data models introduced in this document are generic in The basic data models introduced in this document are generic in
nature and can be applied to many network and service topologies and nature and can be applied to many network and service topologies and
inventories. The data models allow applications to operate on an inventories. The data models allow applications to operate on an
inventory or topology of any network at a generic level, where inventory or topology of any network at a generic level, where the
specifics of particular inventory/topology types are not required. specifics of particular inventory/topology types are not required.
At the same time, where data specific to a network type does comes At the same time, where data specific to a network type does comes
into play and the data model is augmented, the instantiated data into play and the data model is augmented, the instantiated data
still adheres to the same structure and is represented in consistent still adheres to the same structure and is represented in a
fashion. This also facilitates the representation of network consistent fashion. This also facilitates the representation of
hierarchies and dependencies between different network components and network hierarchies and dependencies between different network
network types. components and network types.
The abstract (base) network YANG module introduced in this document, The abstract (base) network YANG module introduced in this document,
entitled "ietf-network.yang", contains a list of abstract network entitled "ietf-network.yang", contains a list of abstract network
nodes and defines the concept of network hierarchy (network stack). nodes and defines the concept of network hierarchy (network stack).
The abstract network node can be augmented in inventory and topology The abstract network node can be augmented in inventory and topology
data models with inventory and topology specific attributes. Network data models with inventory and topology specific attributes. Network
hierarchy (stack) allows any given network to have one or more hierarchy (stack) allows any given network to have one or more
"supporting networks". The relationship of the base network data "supporting networks". The relationship of the base network data
model, the inventory data models and the topology data models is model, the inventory data models and the topology data models is
shown in the following figure (dotted lines in the figure denote shown in the following figure (dotted lines in the figure denote
skipping to change at page 5, line 47 skipping to change at page 5, line 49
Figure 2: Topology hierarchy (stack) example Figure 2: Topology hierarchy (stack) example
The figure shows three topology levels. At top, the "Service" The figure shows three topology levels. At top, the "Service"
topology shows relationships between service entities, such as topology shows relationships between service entities, such as
service functions in a service chain. The "L3" topology shows service functions in a service chain. The "L3" topology shows
network elements at Layer 3 (IP) and the "Optical" topology shows network elements at Layer 3 (IP) and the "Optical" topology shows
network elements at Layer 1. Service functions in the "Service" network elements at Layer 1. Service functions in the "Service"
topology are mapped onto network elements in the "L3" topology, which topology are mapped onto network elements in the "L3" topology, which
in turn are mapped onto network elements in the "Optical" topology. in turn are mapped onto network elements in the "Optical" topology.
The figure shows two Service Functions (X1 and X2) mapping onto a The figure shows two Service Functions (X1 and X3) mapping onto a
single L3 network element (Y2); this could happen, for example, if single L3 network element (Y2); this could happen, for example, if
two service functions reside in the same VM (or server) and share the two service functions reside in the same VM (or server) and share the
same set of network interfaces. The figure shows a single "L3" same set of network interfaces. The figure shows a single "L3"
network element mapped onto multiple "Optical" network elements. network element (Y2) mapped onto multiple "Optical" network elements
(Z and Z1). This could happen, for example, if a single IP router
This could happen, for example, if a single IP router attaches to attaches to multiple Reconfigurable Optical Add/Drop Multiplexers
multiple ROADMs in the optical domain. (ROADMs) in the optical domain.
Another example of a service topology stack is shown in the following Another example of a service topology stack is shown in the following
figure. figure.
VPN1 VPN2 VPN1 VPN2
+---------------------+ +---------------------+ +---------------------+ +---------------------+
/ [Y5]... / / [Z5]______[Z3] / / [Y5]... / / [Z5]______[Z3] /
/ / \ : / / : \_ / : / / / \ : / / : \_ / : /
/ / \ : / / : \_ / : / / / \ : / / : \_ / : /
/ / \ : / / : \ / : / / / \ : / / : \ / : /
skipping to change at page 7, line 47 skipping to change at page 7, line 49
"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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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
Datastore: A conceptual place to store and access information. A Datastore: A conceptual place to store and access information. A
datastore might be implemented, for example, using files, a database, datastore might be implemented, for example, using files, a database,
flash memory locations, or combinations thereof. A datastore maps to flash memory locations, or combinations thereof. A datastore maps to
an instantiated YANG data tree. 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 Data subtree: An instantiated data node and the data nodes that are
hierarchically contained within it. hierarchically contained within it.
HTTP: Hyper-Text Transfer Protocol
IGP: Interior Gateway Protocol IGP: Interior Gateway Protocol
IS-IS: Intermediate System to Intermediate System protocol IS-IS: Intermediate System to Intermediate System protocol
OSPF: Open Shortest Path First, a link state routing protocol OSPF: Open Shortest Path First, a link state routing protocol
URI: Uniform Resource Identifier URI: Uniform Resource Identifier
ReST: Representational State Transfer, a style of stateless interface
and protocol that is generally carried over HTTP
4. Model Structure Details 4. Model Structure Details
4.1. Base Network Model 4.1. Base Network Model
The abstract (base) network data model is defined in the ietf- The abstract (base) network data model is defined in the ietf-
network.yang module. Its structure is shown in the following figure. network.yang module. Its structure is shown in the following figure.
The notation syntax follows The notation syntax follows
[I-D.draft-ietf-netmod-yang-tree-diagrams]. [I-D.draft-ietf-netmod-yang-tree-diagrams].
module: ietf-network module: ietf-network
skipping to change at page 9, line 10 skipping to change at page 9, line 9
A network has a certain type, such as L2, L3, OSPF or IS-IS. A A network has a certain type, such as L2, L3, OSPF or IS-IS. A
network can even have multiple types simultaneously. The type, or network can even have multiple types simultaneously. The type, or
types, are captured underneath the container "network-types". In types, are captured underneath the container "network-types". In
this module it serves merely as an augmentation target; network- this module it serves merely as an augmentation target; network-
specific modules will later introduce new data nodes to represent new specific modules will later introduce new data nodes to represent new
network types below this target, i.e. insert them below "network- network types below this target, i.e. insert them below "network-
types" by ways of YANG augmentation. types" by ways of YANG augmentation.
When a network is of a certain type, it will contain a corresponding When a network is of a certain type, it will contain a corresponding
data node. Network types SHOULD always be represented using presence data node. Network types SHOULD always be represented using presence
containers, not leafs of empty type. This allows representation of containers, not leafs of empty type. This allows the representation
hierarchies of network subtypes within the instance information. For of hierarchies of network subtypes within the instance information.
example, an instance of an OSPF network (which, at the same time, is For example, an instance of an OSPF network (which, at the same time,
a layer 3 unicast IGP network) would contain underneath "network- is a layer 3 unicast IGP network) would contain underneath "network-
types" another presence container "l3-unicast-igp-network", which in types" another presence container "l3-unicast-igp-network", which in
turn would contain a presence container "ospf-network". Actual turn would contain a presence container "ospf-network". Actual
examples of this pattern can be found in examples of this pattern can be found in
[I-D.draft-ietf-i2rs-yang-l3-topology]. [I-D.draft-ietf-i2rs-yang-l3-topology].
A network can in turn be part of a hierarchy of networks, building on A network can in turn be part of a hierarchy of networks, building on
top of other networks. Any such networks are captured in the list top of other networks. Any such networks are captured in the list
"supporting-network". A supporting network is in effect an underlay "supporting-network". A supporting network is in effect an underlay
network. network.
skipping to change at page 9, line 42 skipping to change at page 9, line 41
multiple layers of a networking stack, the same entity will be multiple layers of a networking stack, the same entity will be
represented by multiple nodes, one for each network. In other words, represented by multiple nodes, one for each network. In other words,
the node represents an abstraction of the device for the particular the node represents an abstraction of the device for the particular
network that it a is part of. To represent that the same entity or network that it a is part of. To represent that the same entity or
same device is part of multiple topologies or networks, it is same device is part of multiple topologies or networks, it is
possible to create one "physical" network with a list of nodes for possible to create one "physical" network with a list of nodes for
each of the devices or entities. This (physical) network, each of the devices or entities. This (physical) network,
respectively the (entities) nodes in that network, can then be respectively the (entities) nodes in that network, can then be
referred to as underlay network and nodes from the other (logical) referred to as underlay network and nodes from the other (logical)
networks and nodes, respectively. Note that the data model allows networks and nodes, respectively. Note that the data model allows
definition of more than one underlay network (and node), allowing for for the definition of more than one underlay network (and node),
simultaneous representation of layered network- and service allowing for simultaneous representation of layered network and
topologies and physical instantiation. service topologies and their physical instantiation.
Similar to a network, a node can be supported by other nodes, and map Similar to a network, a node can be supported by other nodes, and map
onto one or more other nodes in an underlay network. This is onto one or more other nodes in an underlay network. This is
captured in the list "supporting-node". The resulting hierarchy of captured in the list "supporting-node". The resulting hierarchy of
nodes allows also representation of device stacks, where a node at nodes allows also for the representation of device stacks, where a
one level is supported by a set of nodes at an underlying level. For node at one level is supported by a set of nodes at an underlying
example, a "router" node might be supported by a node representing a level. For example, a "router" node might be supported by a node
route processor and separate nodes for various line cards and service representing a route processor and separate nodes for various line
modules, a virtual router might be supported or hosted on a physical cards and service modules, a virtual router might be supported or
device represented by a separate node, and so on. hosted on a physical device represented by a separate node, and so
on.
Network data of a network at a particular layer can come into being Network data of a network at a particular layer can come into being
in one of two ways. In one way, network data is configured by client in one of two ways. In one way, network data is configured by client
applications, for example in case of overlay networks that are applications, for example in case of overlay networks that are
configured by an SDN Controller application. In another way, it is configured by an SDN Controller application. In another way, it is
automatically populated by the server, in case of networks that can automatically controlled by the system, in case of networks that can
be discovered. It is possible for a configured (overlay) network to be discovered. It is possible for a configured (overlay) network to
refer to a (discovered) underlay network. refer to a (discovered) underlay network.
The revised datastore architecture The revised datastore architecture
[I-D.draft-ietf-netmod-revised-datastores] is used to account for [I-D.draft-ietf-netmod-revised-datastores] is used to account for
those possibilities. Specifically, for each network, the origin of those possibilities. Specifically, for each network, the origin of
its data is indicated per the "origin" metadata annotation - its data is indicated per the "origin" metadata annotation -
"intended" for data that was configured by a client application, "intended" for data that was configured by a client application,
"learned" for data that is discovered. Network data that is "learned" for data that is discovered. Network data that is
discovered is automatically populated as part of the operational discovered is automatically populated as part of the operational
skipping to change at page 14, line 26 skipping to change at page 14, line 26
existence SHOULD be rejected. It is the responsibility of the existence SHOULD be rejected. It is the responsibility of the
application to update the overlay when a supporting node/link/tp is application to update the overlay when a supporting node/link/tp is
deleted at a later point in time. For this purpose, an application deleted at a later point in time. For this purpose, an application
might subscribe to updates when changes to the underlay occur, for might subscribe to updates when changes to the underlay occur, for
example using mechanisms defined in example using mechanisms defined in
[I-D.draft-ietf-netconf-yang-push]. [I-D.draft-ietf-netconf-yang-push].
4.4.4. Use of groupings 4.4.4. Use of groupings
The data model makes use of groupings, instead of simply defining The data model makes use of groupings, instead of simply defining
data nodes "in-line". This allows to more easily include the data nodes "in-line". This makes it easier to include the
corresponding data nodes in notifications, which then do not need to corresponding data nodes in notifications, which then do not need to
respecify each data node that is to be included. The tradeoff for respecify each data node that is to be included. The tradeoff for
this is that it makes the specification of constraints more complex, this is that it makes the specification of constraints more complex,
because constraints involving data nodes outside the grouping need to because constraints involving data nodes outside the grouping need to
be specified in conjunction with a "uses" statement where the be specified in conjunction with a "uses" statement where the
grouping is applied. This also means that constraints and XPath- grouping is applied. This also means that constraints and XPath-
statements need to be specified in such a way that they navigate statements need to be specified in such a way that they navigate
"down" first and select entire sets of nodes, as opposed to being "down" first and select entire sets of nodes, as opposed to being
able to simply specify them against individual data nodes. able to simply specify them against individual data nodes.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
Y(L3) | +---------------------:-----+ : Y(L3) | +---------------------:-----+ :
| +----:----|-:----------+ | +----:----|-:----------+
+------------------------/---[D1] [D2] / +------------------------/---[D1] [D2] /
+----------------------+ +----------------------+
P (Physical network) P (Physical network)
Figure 6: Topology hierarchy example - multiple underlays Figure 6: Topology hierarchy example - multiple underlays
In the case of a physical network, nodes represent physical devices In the case of a physical network, nodes represent physical devices
and termination points physical ports. It should be noted that it is and termination points physical ports. It should be noted that it is
also conceivable to augment the data model for a physical network- also possible to augment the data model for a physical network-type,
type, defining augmentations that have nodes reference system defining augmentations that have nodes reference system information
information and termination points reference physical interfaces, in and termination points reference physical interfaces, in order to
order to provide a bridge between network and device models. provide a bridge between network and device models.
4.4.10. Supporting client-configured and system-controlled network 4.4.10. Supporting client-configured and system-controlled network
topology topology
YANG requires data nodes to be designated as either configuration YANG requires data nodes to be designated as either configuration
("config true") or operational data ("config false"), but not both, ("config true") or operational data ("config false"), but not both,
yet it is important to have all network information, including yet it is important to have all network information, including
vertical cross-network dependencies, captured in one coherent data vertical cross-network dependencies, captured in one coherent data
model. In most cases, network topology information is discovered model. In most cases, network topology information is discovered
about a network; the topology is considered a property of the network about a network; the topology is considered a property of the network
skipping to change at page 17, line 44 skipping to change at page 17, line 44
For each network, the origin of its data is indicated per the For each network, the origin of its data is indicated per the
"origin" metadata [RFC7952] annotation defined in "origin" metadata [RFC7952] annotation defined in
[I-D.draft-ietf-netmod-revised-datastores]. In general, the origin [I-D.draft-ietf-netmod-revised-datastores]. In general, the origin
of discovered network data is "learned"; the origin of configured of discovered network data is "learned"; the origin of configured
network data is "intended". network data is "intended".
4.4.11. Identifiers of string or URI type 4.4.11. Identifiers of string or URI type
The current data model defines identifiers of nodes, networks, links, The current data model defines identifiers of nodes, networks, links,
and termination points as URIs. An alternative would define them as and termination points as URIs. An alternative would define them as
string. strings.
The case for strings is that they will be easier to implement. The The case for strings is that they will be easier to implement. The
reason for choosing URIs is that the topology/node/tp exists in a reason for choosing URIs is that the topology/node/tp exists in a
larger context, hence it is useful to be able to correlate larger context, hence it is useful to be able to correlate
identifiers across systems. While strings, being the universal data identifiers across systems. While strings, being the universal data
type, are easier for human beings (a string is a string is a string), type, are easier for human beings, they also muddle things. What
they also muddle things. What typically happens is that strings have typically happens is that strings have some structure which is
some structure which is magically assigned and the knowledge of this magically assigned and the knowledge of this structure has to be
structure has to be communicated to each system working with the communicated to each system working with the data. A URI makes the
data. A URI makes the structure explicit and also attaches structure explicit and also attaches additional semantics: the URI,
additional semantics: the URI, unlike a free-form string, can be fed unlike a free-form string, can be fed into a URI resolver, which can
into a URI resolver, which can point to additional resources point to additional resources associated with the URI. This property
associated with the URI. This property is important when the is important when the topology data is integrated into a larger, more
topology data is integrated into a larger, more complex system. complex system.
5. Interactions with Other YANG Modules 5. Interactions with Other YANG Modules
The data model makes use of data types that have been defined in The data model makes use of data types that have been defined in
[RFC6991]. [RFC6991].
This is a protocol independent YANG data model with topology This is a protocol independent YANG data model with topology
information. It is separate from and not linked with data models information. It is separate from and not linked with data models
that are used to configure routing protocols or routing information. that are used to configure routing protocols or routing information.
This includes e.g. data model "ietf-routing" [RFC8022]. This includes e.g. data model "ietf-routing" [RFC8022].
skipping to change at page 18, line 36 skipping to change at page 18, line 36
routing process (such as OSPF) into the <operational> without relying routing process (such as OSPF) into the <operational> without relying
on a configuration datastore. on a configuration datastore.
6. YANG Modules 6. YANG Modules
6.1. Defining the Abstract Network: ietf-network.yang 6.1. Defining the Abstract Network: ietf-network.yang
NOTE TO RFC EDITOR: Please change the date in the file name after the NOTE TO RFC EDITOR: Please change the date in the file name after the
CODE BEGINS statement to the date of publication when published. CODE BEGINS statement to the date of publication when published.
<CODE BEGINS> file "ietf-network@2017-10-22.yang" <CODE BEGINS> file "ietf-network@2017-11-15.yang"
module ietf-network { module ietf-network {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network"; namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nw; prefix nw;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "RFC 6991"; reference "RFC 6991";
} }
skipping to change at page 19, line 40 skipping to change at page 19, line 40
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). (http://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-network-topo-17; draft-ietf-i2rs-yang-network-topo-18;
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 NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-10-22 { revision 2017-11-15 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: NOTE TO RFC EDITOR:
(1) Please replace the following reference (1) Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-17 with to draft-ietf-i2rs-yang-network-topo-18 with
RFC number when published (i.e. RFC xxxx). RFC number when published (i.e. RFC xxxx).
(2) Please replace the date in the revision statement with the (2) Please replace the date in the revision statement with the
date of publication when published. "; date of publication when published. ";
reference reference
"draft-ietf-i2rs-yang-network-topo-17"; "draft-ietf-i2rs-yang-network-topo-18";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node. The precise structure of the node-id "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be the same node in a real network topology will always be
skipping to change at page 23, line 10 skipping to change at page 23, line 10
} }
} }
<CODE ENDS> <CODE ENDS>
6.2. Creating Abstract Network Topology: ietf-network-topology.yang 6.2. Creating Abstract Network Topology: ietf-network-topology.yang
NOTE TO RFC EDITOR: Please change the date in the file name after the NOTE TO RFC EDITOR: Please change the date in the file name after the
CODE BEGINS statement to the date of publication when published. CODE BEGINS statement to the date of publication when published.
<CODE BEGINS> file "ietf-network-topology@2017-10-22.yang" <CODE BEGINS> file "ietf-network-topology@2017-11-15.yang"
module ietf-network-topology { module ietf-network-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix nt; prefix nt;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991"; "RFC 6991";
} }
import ietf-network { import ietf-network {
prefix nw; prefix nw;
reference reference
"draft-ietf-i2rs-yang-network-topo-17 "draft-ietf-i2rs-yang-network-topo-18
NOTE TO RFC EDITOR: NOTE TO RFC EDITOR:
(1) Please replace above reference to (1) Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx). number when published (i.e. RFC xxxx).
(2) Please replace the date in the revision statement with the (2) Please replace the date in the revision statement with the
date of publication when published."; date of publication when published.";
} }
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: <http://tools.ietf.org/wg/i2rs/>
skipping to change at page 24, line 25 skipping to change at page 24, line 25
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). (http://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-network-topo-17; draft-ietf-i2rs-yang-network-topo-18;
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 NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-10-22 { revision 2017-11-15 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-17 with to draft-ietf-i2rs-yang-network-topo-18 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-17"; "draft-ietf-i2rs-yang-network-topo-18";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The precise structure of the link-id The precise structure of the link-id
will be up to the implementation. will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
skipping to change at page 30, line 11 skipping to change at page 30, line 11
URI:urn:ietf:params:xml:ns:yang:ietf-network-topology-state URI:urn:ietf:params:xml:ns:yang:ietf-network-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]:
NOTE TO THE RFC EDITOR: In the list below, please replace references NOTE TO THE RFC EDITOR: In the list below, please replace references
to "draft-ietf-i2rs-yang-network-topo-17 (RFC form)" with RFC number to "draft-ietf-i2rs-yang-network-topo-18 (RFC form)" with RFC number
when published (i.e. RFC xxxx). when published (i.e. RFC xxxx).
Name: ietf-network Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nw Prefix: nw
Reference: draft-ietf-i2rs-yang-network-topo-17.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form)
Name: ietf-network-topology Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: nt Prefix: nt
Reference: draft-ietf-i2rs-yang-network-topo-17.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form)
Name: ietf-network-state Name: ietf-network-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state
Prefix: nw-s Prefix: nw-s
Reference: draft-ietf-i2rs-yang-network-topo-17.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form)
Name: ietf-network-topology-state Name: ietf-network-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
Prefix: nt-s Prefix: nt-s
Reference: draft-ietf-i2rs-yang-network-topo-17.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form)
8. Security Considerations 8. Security Considerations
The YANG modules defined in this document are designed to be accessed The YANG modules defined in this document are designed to be accessed
via network management protocols such as NETCONF [RFC6241] or via network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS [RFC5246]. mandatory-to-implement secure transport is TLS [RFC5246].
skipping to change at page 34, line 30 skipping to change at page 34, line 30
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990. Dual Environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January
2003.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014. Management", RFC 7223, May 2014.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, August 2016.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
RFC 7952, August 2016. RFC 7952, August 2016.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, November 2016. Management", RFC 8022, November 2016.
Appendix A. Appendix: Model Use Cases Appendix A. Model Use Cases
A.1. Fetching Topology from a Network Element A.1. Fetching Topology from a Network Element
In its simplest form, topology is learned by a network element (e.g., In its simplest form, topology is learned by a network element (e.g.,
a router) through its participation in peering protocols (IS-IS, BGP, a router) through its participation in peering protocols (IS-IS, BGP,
etc.). This learned topology can then be exported (e.g., to an NMS) etc.). This learned topology can then be exported (e.g., to a
for external utilization. Typically, any network element in a domain Network Management System) for external utilization. Typically, any
can be queried for its topology and expected to return the same network element in a domain can be queried for its topology and
result. expected to return the same result.
In a slightly more complex form, the network element may be a In a slightly more complex form, the network element may be a
controller, either by nature of it having satellite or subtended controller, either by nature of it having satellite or subtended
devices hanging off of it, or in the more classical sense, such as devices hanging off of it, or in the more classical sense, such as
special device designated to orchestrate the activities of a number special device designated to orchestrate the activities of a number
of other devices (e.g., an optical controller). In this case, the of other devices (e.g., an optical controller). In this case, the
controller device is logically a singleton and must be queried controller device is logically a singleton and must be queried
distinctly. distinctly.
It is worth noting that controllers can be built on top of It is worth noting that controllers can be built on top of
skipping to change at page 35, line 44 skipping to change at page 35, line 44
A.2. Modifying TE Topology Imported from an Optical Controller A.2. Modifying TE Topology Imported from an Optical Controller
Consider a scenario where an Optical Transport Controller presents Consider a scenario where an Optical Transport Controller presents
its topology in abstract TE Terms to a Client Packet Controller. its topology in abstract TE Terms to a Client Packet Controller.
This Customized Topology (that gets merged into the Client's native This Customized Topology (that gets merged into the Client's native
topology) contains sufficient information for the path computing topology) contains sufficient information for the path computing
client to select paths across the optical domain according to its client to select paths across the optical domain according to its
policies. If the Client determines (at any given point in time) that policies. If the Client determines (at any given point in time) that
this imported topology does not exactly cater to its requirements, it this imported topology does not exactly cater to its requirements, it
may decide to request modifications to the topology. Such may decide to request modifications to the topology. Such
customization requests may include addition or deletion of topoogical customization requests may include addition or deletion of
elements or modification of attributes associated with existing topological elements or modification of attributes associated with
topological elements. From the perspective of the Optical existing topological elements. From the perspective of the Optical
Controller, these requests translate into configuration changes to Controller, these requests translate into configuration changes to
the exported abstract topology. the exported abstract topology.
A.3. Annotating Topology for Local Computation A.3. Annotating Topology for Local Computation
In certain scenarios, the topology learned by a controller needs to In certain scenarios, the topology learned by a controller needs to
be augmented with additional attributes before running a computation be augmented with additional attributes before running a computation
algorithm on it. Consider the case where a path-computation algorithm on it. Consider the case where a path-computation
application on the controller needs to take the geographic application on the controller needs to take the geographic
coordinates of the nodes into account while computing paths on the coordinates of the nodes into account while computing paths on the
skipping to change at page 36, line 32 skipping to change at page 36, line 32
maintains an overlay topology. maintains an overlay topology.
The SDN Controller thus maintains two roles: The SDN Controller thus maintains two roles:
o It is a client to the network. o It is a client to the network.
o It is a server to its own northbound applications and clients, o It is a server to its own northbound applications and clients,
e.g. an OSS. e.g. an OSS.
In other words, one system's client (or controller, in this case) may In other words, one system's client (or controller, in this case) may
be another system's server (or "uber-network device"). be another system's server (or managed system).
In this scenario, the SDN controller maintains a consolidated data In this scenario, the SDN controller maintains a consolidated data
model of multiple layers of topology. This includes the lower layers model of multiple layers of topology. This includes the lower layers
of the network topology, built from information that is discovered of the network topology, built from information that is discovered
from the network. It also includes upper layers of topology overlay, from the network. It also includes upper layers of topology overlay,
configurable by the controller's client, i.e. the OSS. To the OSS, configurable by the controller's client, i.e. the OSS. To the OSS,
the lower topology layers constitute "read-only" information. The the lower topology layers constitute "read-only" information. The
upper topology layers need to be read-writable. upper topology layers need to be read-writable.
Appendix B. Appendix: Companion YANG models for non-NMDA compliant Appendix B. Companion YANG models for non-NMDA compliant
implementations implementations
The YANG modules defined in this document are designed to be used in The YANG modules defined in this document are designed to be used in
conjunction with implementations that support the Network Management conjunction with implementations that support the Network Management
Datastore Architecture (NMDA) defined in Datastore Architecture (NMDA) defined in
[I-D.draft-ietf-netmod-revised-datastores]. In order to allow [I-D.draft-ietf-netmod-revised-datastores]. In order to allow
implementations to use the data model even in cases when NMDA is not implementations to use the data model even in cases when NMDA is not
supported, in the following two companion modules are defined that supported, in the following two companion modules are defined that
represent the operational state of networks and network topologies. represent the operational state of networks and network topologies.
The modules, ietf-network-state and ietf-network-topology-state, The modules, ietf-network-state and ietf-network-topology-state,
skipping to change at page 37, line 23 skipping to change at page 37, line 23
defined in an appendix. defined in an appendix.
As the structure of both modules mirrors that of their underlying As the structure of both modules mirrors that of their underlying
modules, the YANG tree is not depicted separately. modules, the YANG tree is not depicted separately.
B.1. YANG Model for Network State B.1. YANG Model for Network State
NOTE TO RFC EDITOR: Please change the date in the file name after the NOTE TO RFC EDITOR: Please change the date in the file name after the
CODE BEGINS statement to the date of the publication when published. CODE BEGINS statement to the date of the publication when published.
<CODE BEGINS> file "ietf-network-state@2017-10-22.yang" <CODE BEGINS> file "ietf-network-state@2017-11-15.yang"
module ietf-network-state { module ietf-network-state {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-state"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
prefix nw-s; prefix nw-s;
import ietf-network { import ietf-network {
prefix nw; prefix nw;
reference reference
"draft-ietf-i2rs-yang-network-topo-17 "draft-ietf-i2rs-yang-network-topo-18
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
} }
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: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
skipping to change at page 38, line 40 skipping to change at page 38, line 40
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). (http://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-network-topo-17; draft-ietf-i2rs-yang-network-topo-18;
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 NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-10-22 { revision 2017-11-15 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: NOTE TO RFC EDITOR:
(1) Please replace the following reference (1) Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-17 with to draft-ietf-i2rs-yang-network-topo-18 with
RFC number when published (i.e. RFC xxxx). RFC number when published (i.e. RFC xxxx).
(2) Please replace the date in the revision statement with the (2) Please replace the date in the revision statement with the
date of the publication when published."; date of the publication when published.";
reference reference
"draft-ietf-i2rs-yang-network-topo-17"; "draft-ietf-i2rs-yang-network-topo-18";
} }
grouping network-ref { grouping network-ref {
description description
"Contains the information necessary to reference a network, "Contains the information necessary to reference a network,
for example an underlay network."; for example an underlay network.";
leaf network-ref { leaf network-ref {
type leafref { type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id"; path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false; require-instance false;
skipping to change at page 41, line 31 skipping to change at page 41, line 31
} }
} }
} }
<CODE ENDS> <CODE ENDS>
B.2. YANG Data Model for Network Topology State B.2. YANG Data Model for Network Topology State
NOTE TO RFC EDITOR: Please change the date in the file name after the NOTE TO RFC EDITOR: Please change the date in the file name after the
CODE BEGINS statement to the date of the publication when published. CODE BEGINS statement to the date of the publication when published.
<CODE BEGINS> file "ietf-network-topology-state@2017-10-22.yang" <CODE BEGINS> file "ietf-network-topology-state@2017-11-15.yang"
module ietf-network-topology-state { module ietf-network-topology-state {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
prefix nt-s; prefix nt-s;
import ietf-network-state { import ietf-network-state {
prefix nw-s; prefix nw-s;
reference reference
"draft-ietf-i2rs-yang-network-topo-17 "draft-ietf-i2rs-yang-network-topo-18
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
} }
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
"draft-ietf-i2rs-yang-network-topo-17 "draft-ietf-i2rs-yang-network-topo-18
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
} }
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: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm Editor: Alexander Clemm
skipping to change at page 43, line 5 skipping to change at page 43, line 5
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 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). (http://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-network-topo-17; draft-ietf-i2rs-yang-network-topo-18;
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 NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-17 with RFC draft-ietf-i2rs-yang-network-topo-18 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-10-22 { revision 2017-11-15 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: NOTE TO RFC EDITOR:
(1) Please replace the following reference (1) Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-17 with to draft-ietf-i2rs-yang-network-topo-18 with
RFC number when published (i.e. RFC xxxx). RFC number when published (i.e. RFC xxxx).
(2) Please replace the date in the revision statement with the (2) Please replace the date in the revision statement with the
date of publication when published."; date of publication when published.";
reference reference
"draft-ietf-i2rs-yang-network-topo-17"; "draft-ietf-i2rs-yang-network-topo-18";
} }
grouping link-ref { grouping link-ref {
description description
"References a link in a specific network. While this grouping "References a link in a specific network. While this grouping
is not used in this module, it is defined here for the is not used in this module, it is defined here for the
convenience of augmenting modules."; convenience of augmenting modules.";
leaf link-ref { leaf link-ref {
type leafref { type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+ path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
skipping to change at page 47, line 34 skipping to change at page 47, line 34
"Reference to the underlay node, must be in a "Reference to the underlay node, must be in a
different topology"; different topology";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix C. An Example
This section contains an example of an instance data tree in JSON
encoding [RFC7951]. The example instantiates ietf-network-topology
(and ietf-network, which ietf-network-topology augments) 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.
+------------+ +------------+
| 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 7: A network topology example
The corresponding instance data tree is depicted below:
{
"ietf-network:networks": {
"network": [
{
"network-types": {
},
"network-id": "otn-hc",
"node": [
{
"node-id": "D1",
"termination-point": [
{
"tp-id": "1-0-1"
},
{
"tp-id": "1-2-1"
},
{
"tp-id": "1-3-1"
}
]
},
{
"node-id": "D2",
"termination-point": [
{
"tp-id": "2-0-1"
},
{
"tp-id": "2-1-1"
},
{
"tp-id": "2-3-1"
}
]
},
{
"node-id": "D3",
"termination-point": [
{
"tp-id": "3-1-1"
},
{
"tp-id": "3-2-1"
}
]
}
],
"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"
}
},
{
"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"
}
},
{
"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"
}
},
{
"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"
}
},
{
"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"
}
},
{
"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"
}
}
]
}
]
}
}
Figure 8: Instance data tree
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Huawei Huawei
EMail: ludwig@clemm.org EMail: ludwig@clemm.org
Jan Medved Jan Medved
Cisco Cisco
 End of changes. 70 change blocks. 
118 lines changed or deleted 285 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/