< draft-clemm-i2rs-yang-network-topo-02.txt   draft-clemm-i2rs-yang-network-topo-03.txt >
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft J. Medved Internet-Draft J. Medved
Intended status: Experimental R. Varga Intended status: Experimental R. Varga
Expires: June 18, 2015 T. Tkacik Expires: September 6, 2015 T. Tkacik
Cisco Cisco
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
December 15, 2014 March 5, 2015
A Data Model for Network Topologies A Data Model for Network Topologies
draft-clemm-i2rs-yang-network-topo-02.txt draft-clemm-i2rs-yang-network-topo-03.txt
Abstract Abstract
This document defines a YANG data model for network and service This document defines an abstract (generic) YANG data model for
topologies. network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in
other, more specific topology and inventory models.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 June 18, 2015. This Internet-Draft will expire on September 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 22 skipping to change at page 2, line 24
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7
3. Model Structure Details . . . . . . . . . . . . . . . . . . . 6 3. Model Structure Details . . . . . . . . . . . . . . . . . . . 7
3.1. Main building blocks . . . . . . . . . . . . . . . . . . 7 3.1. Base Network Model . . . . . . . . . . . . . . . . . . . 7
3.2. Discussion and selected design decisions . . . . . . . . 8 3.2. Base Network Topology Model . . . . . . . . . . . . . . . 9
3.3. Open issues and items for further discussion . . . . . . 10 3.3. Discussion and selected design decisions . . . . . . . . 11
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Container structure . . . . . . . . . . . . . . . . . 11
4.1. Defining the Abstract Network: network.yang . . . . . . . 10 3.3.2. Underlay hierarchies and mappings . . . . . . . . . . 11
4.2. Creating Abstract Network Topology: network-topology.yang 13 3.3.3. Use of groupings . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 3.3.4. Cardinality and directionality of links . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3.5. Multihoming and link aggregation . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 3.3.6. Mapping redundancy . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3.7. Typing . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 3.3.8. Representing the same device in multiple networks . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 19 3.4. Items for further discussion . . . . . . . . . . . . . . 14
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Defining the Abstract Network: network.yang . . . . . . . 14
4.2. Creating Abstract Network Topology: network-topology.yang 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document introduces an abstract (base) network YANG [RFC6020] This document introduces an abstract (base) YANG [RFC6020] [RFC6021]
[RFC6021] model that can be augmented to cover both network data model to represent networks and topologies. The data model is
inventories and network/service topologies. Moreover, the document divided into two parts. The first part of the model defines a
also introduces an abstract (basic) topology model that augments the network model that allows to define network hierarchies (i.e. network
basic network model and can in turn be augmented to describe many stacks) and to maintain an inventory of nodes contained in a network.
different network and service topologies. Applications can operate The second part of the model augments the basic network model with
on any inventory or topology at a generic level, where specifics of information to describe topology information. Specifically, it adds
particular inventory/topology types are not required; applications the concepts of links and termination points to describe how nodes in
can also operate with intentory-specific data or or data specific to a network are connected to each other. Moreover the model introduces
a particular topology level when those specifics come into play. vertical layering relationships between networks that can be
Examples of specific topology types include Layer 2 topology, Layer 3 augmented to cover both network inventories and network/service
topologies such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], topologies.
traffic engineering (TE) data [RFC3209], or any of the variety of
transport and service topologies. Information specific to such a
particular network topology types will be captured in separate,
technology-specific models. The basic data models introduced in this
document is generic in nature and can be applied to many network
topologies and inventories.
The abstract (base) network YANG module introduced in this document The model can be augmented to describe specifics of particular types
contains a list of abstract network nodes and defines the concept of of networks and topologies. For example, an augmenting model can
network hierarchy (network stack). The abstract network node can be provide network node information with attributes that are specific to
augmented in inventory and topology models with inventory and a particular network type. Examples of augmenting models include
topology specific attributes. Network hierarchy (stack) allows any models for Layer 2 network topologies, Layer 3 network topologies,
given network to have one or more "supporting networks". The such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], traffic
relationship of the base network model, the inventory models and the engineering (TE) data [RFC3209], or any of the variety of transport
topology models is shown in the following figure (dotted lines in the and service topologies. Information specific to particular network
figure denote possible augmentations to models defined in this types will be captured in separate, technology-specific models.
document).
The basic data models introduced in this document are generic in
nature and can be applied to many network and service topologies and
inventories. The models allow applications to operate on an
inventory or topology of any network at a generic level, where
specifics of particular inventory/topology types are not required.
At the same time, where data specific to a network type does comes
into play and the model is augmented, the instantiated data still
adheres to the same structure and is represented in consistent
fashion. This also facilitates the representation of network
hierarchies and dependencies between different network components and
network types.
The abstract (base) network YANG module introduced in this document,
entitled "network.yang", contains a list of abstract network nodes
and defines the concept of network hierarchy (network stack). The
abstract network node can be augmented in inventory and topology
models with inventory and topology specific attributes. Network
hierarchy (stack) allows any given network to have one or more
"supporting networks". The relationship of the base network model,
the inventory models and the topology models is shown in the
following figure (dotted lines in the figure denote possible
augmentations to models defined in this document).
+------------------------+ +------------------------+
| | | |
| Abstract Network Model | | Abstract Network Model |
| | | |
+------------------------+ +------------------------+
| |
+-------+-------+ +-------+-------+
| | | |
V V V V
+------------+ .............. +------------+ ..............
| Abstract | : Inventory : | Abstract | : Inventory :
| Topology | : Model : | Topology | : Model(s) :
| Model | : : | Model | : :
+------------+ '''''''''''''' +------------+ ''''''''''''''
| |
+-------------+-------------+ +-------------+-------------+
| | | | | |
V V V V V V
............ ............ ............ ............ ............ ............
: L2 : : L3 : : Service : : L2 : : L3 : : Service :
: Topology : : Topology : : Topology : : Topology : : Topology : : Topology :
: Model : : Model : : Model : : Model : : Model : : Model :
'''''''''''' '''''''''''' '''''''''''' '''''''''''' '''''''''''' ''''''''''''
Figure 1: The network models structure Figure 1: The network model structure
The network-topology YANG module introduced in this document defines The network-topology YANG module introduced in this document,
a generic topology model at its most general level of abstraction. entitled "network-topology.yang", defines a generic topology model at
The module defines a topology graph and components from which it is its most general level of abstraction. The module defines a topology
composed: nodes, edges and termination points. Nodes represent graph graph and components from which it is composed: nodes, edges and
vertices and links represent graph edges. Nodes contain termination termination points. Nodes (from the network.yang module) represent
points that anchor the links. A network can contain multiple graph vertices and links represent graph edges. Nodes also contain
topologies, for example topologies at different layers and overlay termination points that anchor the links. A network can contain
topologies. The model therefore allows to capture relationships multiple topologies, for example topologies at different layers and
between topologies, as well as dependencies between nodes and overlay topologies. The model therefore allows to capture
termination points across topologies. An example of a topology stack relationships between topologies, as well as dependencies between
is shown in the following figure. nodes and termination points across topologies. An example of a
topology stack is shown in the following figure.
+---------------------------------------+ +---------------------------------------+
/ _[X1]_ "Service" / / _[X1]_ "Service" /
/ _/ : \_ / / _/ : \_ /
/ _/ : \_ / / _/ : \_ /
/ _/ : \_ / / _/ : \_ /
/ / : \ / / / : \ /
/ [X1]__________________[X3] / / [X2]__________________[X3] /
+---------:--------------:------:-------+ +---------:--------------:------:-------+
: : : : : :
+----:--------------:----:--------------+ +----:--------------:----:--------------+
/ : : : "L3" / / : : : "L3" /
/ : : : / / : : : /
/ : : : / / : : : /
/ [Y1]_____________[Y2] / / [Y1]_____________[Y2] /
/ * * * / / * * * /
/ * * * / / * * * /
+--------------*-------------*--*-------+ +--------------*-------------*--*-------+
skipping to change at page 5, line 8 skipping to change at page 5, line 49
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 X2 - mapping onto a
single L3 network element; this could happen, for example, if two single L3 network element; this could happen, for example, if two
service functions reside in the same VM (or server) and share the 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 mapped onto multiple "Optical" network elements.
This could happen, for example, if a single IP router attaches to This could happen, for example, if a single IP router attaches to
multiple ROADMs in the optical domain. multiple ROADMs in the optical domain.
Another example of a service topology stack is shown in the following
figure.
VPN1 VPN2
+---------------------+ +---------------------+
/ [Y5]... / / [Z5]______[Z3] /
/ / \ : / / : \_ / : /
/ / \ : / / : \_ / : /
/ / \ : / / : \ / : /
/ [Y4]____[Y1] : / / : [Z2] : /
+------:-------:---:--+ +---:---------:-----:-+
: : : : : :
: : : : : :
: +-------:---:-----:------------:-----:-----+
: / [X1]__:___:___________[X2] : /
:/ / \_ : : _____/ / : /
: / \_ : _____/ / : /
/: / \: / / : /
/ : / [X5] / : /
/ : / __/ \__ / : /
/ : / ___/ \__ / : /
/ : / ___/ \ / : /
/ [X4]__________________[X3]..: /
+------------------------------------------+
L3 Topology
Figure 3: Topology hierarchy (stack) example
The figure shows two VPN service topologies (VPN1 and VPN2)
instantiated over a common L3 topology. Each VPN service topology is
mapped onto a subset of nodes from the common L3 topology.
There are multiple applications for such a data model. For example, There are multiple applications for such a data model. For example,
within the context of I2RS, nodes within the network can use the data within the context of I2RS, nodes within the network can use the data
model to capture their understanding of the overall network topology model to capture their understanding of the overall network topology
and expose it to a network controller. A network controller can then and expose it to a network controller. A network controller can then
use the instantiated topology data to compare and reconcile its own use the instantiated topology data to compare and reconcile its own
view of the network topology with that of the network elements that view of the network topology with that of the network elements that
it controls. Alternatively, nodes within the network could propagate it 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
among themselves or with help of a controller. Beyond the network among themselves or with help of a controller. Beyond the network
element and the immediate context of I2RS itself, a network element and the immediate context of I2RS itself, a network
skipping to change at page 6, line 7 skipping to change at page 7, line 33
URI: Uniform Resource Identifier URI: Uniform Resource Identifier
ReST: Representational State Transfer, a style of stateless interface ReST: Representational State Transfer, a style of stateless interface
and protocol that is generally carried over HTTP and protocol that is generally carried over HTTP
YANG: A data definition language for NETCONF YANG: A data definition language for NETCONF
3. Model Structure Details 3. Model Structure Details
3.1. Base Network Model
The abstract (base) network model is defined in the network.yang The abstract (base) network model is defined in the network.yang
module. Its structure is shown in the following figure. Brackets module. Its structure is shown in the following figure. Brackets
enclose list keys, "rw" means configuration data, "ro" means enclose list keys, "rw" means configuration data, "ro" means
operational state data, and "?" designates optional nodes. operational state data, and "?" designates optional nodes.
module: network module: network
+--rw network* [network-id] +--rw network* [network-id]
+--rw network-id network-id +--rw network-id network-id
+--ro server-provided? boolean +--ro server-provided? boolean
+--rw network-types +--rw network-types
+--rw supporting-network* [network-ref] +--rw supporting-network* [network-ref]
| +--rw network-ref leafref | +--rw network-ref leafref
+--rw node* [node-id] +--rw node* [node-id]
+--rw node-id node-id +--rw node-id node-id
+--rw supporting-node* [network-ref node-ref] +--rw supporting-node* [network-ref node-ref]
+--rw network-ref leafref +--rw network-ref leafref
+--rw node-ref leafref +--rw node-ref leafref
Figure 3: The structure of the abstract (base) network model Figure 4: The structure of the abstract (base) network model
The abstract (base) network topology model is defined by augmenting The model contains a list of networks, contained underneath a root
the network model defined in the network.yang module with link data container for this module, "network". Each network is captured in
defined in the network-topology.yang module. Effectively, both the its own list entry, distinguished via a network-id.
network.yang module and the network-topology.yang module are used to
define the abstract (base) network topology. The network- A network has a certain type, such as L2, L3, OSPF or IS-IS. A
topology.yang module augments 'node' with 'termination points' and network can even have multiple types simultaneously. The type, or
'network' with 'links'. The structure of the network topology module types, are captured underneath the container "network-types". In
is shown in the following figure. Brackets enclose list keys, "rw" this module it serves merely as an augmentation target; network-
means configuration data, "ro" means operational state data, and "?" specific modules will later introduce new data nodes to represent new
designates optional nodes. network types below this target, i.e. insert them below "network-
types" by ways of yang augmentation.
When a network is of a certain type, it will contain a corresponding
data node. Network types SHOULD always be represented using presence
containers, not leafs of empty type. This allows to represent
hierarchies of network subtypes within the instance information. For
example, an instance of an OSPF network (which, at the same time, is
a layer 3 unicast IGP network) would contain underneath "network-
types" another container "l3-unicast-igp-network", which in turn
would contain a container "ospf-network".
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
"supporting-network". A supporting network is in effect an underlay
network.
Furthermore, a network contains an inventory of nodes that are part
of the network. The nodes of a network are captured in their own
list. Each node is identified relative to its containing network by
a node-id.
It should be noted that a node does not exist independently of a
network; instead it is a part of the network that it is contained in.
In cases where the same entity takes part in multiple networks, or at
multiple layers of a networking stack, the same entity will be
represented by multiple nodes, one for each network. In other words,
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
same device is part of multiple topologies or networks, it is
possible to create one "physical" network with a list of nodes for
each of the devices or entities. This (physical) network,
respectively the (entities) nodes in that network, can then be
referred to as underlay network and nodes from the other (logical)
networks and nodes, respectively. Note that the model allows to
define more than one underlay network (and node), allowing for
simultaneous representation of layered network- and service
topologies and physical instantiation.
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
captured in the list "supporting-node". The resulting hierarchy of
nodes allows also to represent device stacks, where a node at one
level is supported by a set of nodes at an underlying level. For
example, a "router" node might be supported by a node representing a
route processor and separate nodes for various line cards and service
modules, a virtual router might be supported or hosted on a physical
device represented by a separate node, and so on.
3.2. Base Network Topology Model
The abstract (base) network topology model is defined in the
"network-topology.yang" module. It builds on the network model
defined in the "network.yang" module, augmenting it with links
(defining how nodes are connected) and termination-points (which
anchor the links and are contained in nodes). The structure of the
network topology module is shown in the following figure. Brackets
enclose list keys, "rw" means configuration data, "ro" means
operational state data, and "?" designates optional nodes.
module: network module: network
+--rw network* [network-id] +--rw network* [network-id]
+--rw network-id network-id +--rw network-id network-id
+--ro server-provided? boolean +--ro server-provided? boolean
+--rw network-types +--rw network-types
+--rw supporting-network* [network-ref] +--rw supporting-network* [network-ref]
| +--rw network-ref leafref | +--rw network-ref leafref
+--rw node* [node-id] +--rw node* [node-id]
| +--rw node-id node-id | +--rw node-id node-id
skipping to change at page 7, line 36 skipping to change at page 10, line 36
+--rw lnk:source +--rw lnk:source
| +--rw lnk:source-node leafref | +--rw lnk:source-node leafref
| +--rw lnk:source-tp? leafref | +--rw lnk:source-tp? leafref
+--rw lnk:destination +--rw lnk:destination
| +--rw lnk:dest-node leafref | +--rw lnk:dest-node leafref
| +--rw lnk:dest-tp? leafref | +--rw lnk:dest-tp? leafref
+--rw lnk:supporting-link* [network-ref link-ref] +--rw lnk:supporting-link* [network-ref link-ref]
+--rw lnk:network-ref leafref +--rw lnk:network-ref leafref
+--rw lnk:link-ref leafref +--rw lnk:link-ref leafref
Figure 4: The structure of the abstract (base) network topology model Figure 5: The structure of the abstract (base) network topology model
3.1. Main building blocks
A network can contain multiple topologies. Each topology is captured
in its own list entry, distinguished via a topology-id. This is
captured by list "topology", contained underneath the root container
for this module, "network-topology".
A topology has a certain type, such as L2, L3, OSPF or IS-IS. A
topology can even have multiple types simultaneously. The type, or
types, are captured underneath the container "topology-types". This
container serves as container for data nodes that represent specific
topology types. In this module it serves merely as an augmentation
target; topology-specific modules will later introduce new data nodes
to represent new topology types below this target, i.e. insert them
below "topology-types" by ways of yang augmentation.
Topology types SHOULD always be represented using presence
containers, not leafs of empty type. This allows to represent
hierarchies of topology subtypes within the instance information.
For example, an instance of an OSPF topology (which, at the same
time, is a layer 3 unicast IGP topology) would contain underneath
"topology-types" another container "l3-unicast-igp-topology", which
in turn would contain a container "ospf-topology".
A topology can in turn be part of a hierarchy of topologies, building
on top of other topologies. Any such topologies are captured in the
list "underlay-topology".
Furthermore, a topology contains nodes and links, each captured in A node has a list of termination points that are used to terminate
their own list. links. An example of a termination point might be a physical or
logical port or, more generally, an interface.
A node has a node-id that distinguishes the node from other nodes in Like a node, a termination point can in turn be supported by an
the list. In addition, a node has a list of termination points that underlying termination point, contained in the supporting node of the
are used to terminate links. An example of a termination point might underlay network.
be a physical or logical port or, more generally, an interface.
Also, a node can map onto one or more other nodes in an underlay
topology. This is captured in the list "supporting-node".
A link is identified by a link-id that uniquely identifies the link A link is identified by a link-id that uniquely identifies the link
within a given topology. Links are point-to-point and within a given topology. Links are point-to-point and
unidirectional. Accordingly, a link contains a source and a unidirectional. Accordingly, a link contains a source and a
destination. Both source and destination reference a corresponding destination. Both source and destination reference a corresponding
node, as well as a termination point on that node. Similar to a node, as well as a termination point on that node. Similar to a
node, a link can map onto one or more links in an underlay topology. node, a link can map onto one or more links in an underlay topology
This is captured in the list "supporting-link". (which are terminated by the corresponding underlay termination
points). This is captured in the list "supporting-link".
3.2. Discussion and selected design decisions 3.3. Discussion and selected design decisions
3.3.1. Container structure
Rather than maintaining lists in separate containers, the model is Rather than maintaining lists in separate containers, the model is
kept relatively flat in terms of its containment structure. kept relatively flat in terms of its containment structure. Lists of
Therefore, path specifiers used to refer to specific nodes, be it in nodes, links, termination-points, and supporting-nodes, supporting-
management operations or in specifications of constraints, can remain links, and supporting-termination-points are not kept in separate
relatively compact. Of course, this means there is no separate containers. Therefore, path specifiers used to refer to specific
structure in instance information that separates elements of nodes, be it in management operations or in specifications of
different lists from one another. Such structure is semantically not constraints, can remain relatively compact. Of course, this means
required, although it might enhance human readability in some cases. there is no separate structure in instance information that separates
elements of different lists from one another. Such structure is
semantically not required, although it might enhance human
readability in some cases.
To minimize assumptions of what a topology might actually represent, 3.3.2. Underlay hierarchies and mappings
mappings between topologies, nodes, links, and termination points are
kept strictly generic. For example, no assumptions are made whether To minimize assumptions of what a particular entity might actually
a termination point actually refers to an interface, or whether a represent, mappings between networks, nodes, links, and termination
node refers to a specific "system" or device; the model at this points are kept strictly generic. For example, no assumptions are
generic level makes no provisions for that. Any greater specifics made whether a termination point actually refers to an interface, or
about mappings between upper and lower layers can be captured in whether a node refers to a specific "system" or device; the model at
augmenting modules. For example, if a termination point maps to an this generic level makes no provisions for that.
interface, an augmenting module can augment the termination point
with a leaf that references the corresponding interface [if-config]. Where additional specifics about mappings between upper and lower
If a node maps to a particular device or network element, an layers are required, those can be captured in augmenting modules.
augmenting module can augment node with a leaf that references the For example, to express that a termination point in a particular
network element. network type maps to an interface, an augmenting module can introduce
an augmentation to the termination point which introduces a leaf of
type ifref that references the corresponding interface [RFC7223].
Similarly, if a node maps to a particular device or network element,
an augmenting module can augment the node data with a leaf that
references the network element.
3.3.3. Use of groupings
The model makes use of groupings, instead of simply defining data The model makes use of groupings, instead of simply defining data
nodes "in-line". This allows to more easily include the nodes "in-line". This allows to more easily 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 specified in such a way that the navigate "down" statements need to specified in such a way that they navigate "down"
first and select entire sets of nodes, as opposed to being able to first and select entire sets of nodes, as opposed to being able to
simply specify them against individual data nodes. simply specify them against individual data nodes.
3.3.4. Cardinality and directionality of links
The topology model includes links that are point-to-point and The topology model includes links that are point-to-point and
unidirectional. It does not directly support multipoint and unidirectional. It does not directly support multipoint and
bidirectional links. While this may appear as a limitation, it does bidirectional links. While this may appear as a limitation, it does
keep the model simple, generic, and allows it to very easily be keep the model simple, generic, and allows it to very easily be
subjected applications that make use of graph algorithms. Bi- subjected to applications that make use of graph algorithms. Bi-
directional connections can be represented through pairs of directional connections can be represented through pairs of
unidirectional links. Multipoint networks can be represented through unidirectional links. Multipoint networks can be represented through
pseudo-nodes (similar to IS-IS, for example). By introducing pseudo-nodes (similar to IS-IS, for example). By introducing
hierarchies of nodes, with nodes at one level mapping onto a set of hierarchies of nodes, with nodes at one level mapping onto a set of
other nodes at another level, and the introducing new links for nodes other nodes at another level, and introducing new links for nodes at
at that level, topologies with connections representing non-point-to- that level, topologies with connections representing non-point-to-
point communication patterns can be represented. point communication patterns can be represented.
3.3.5. Multihoming and link aggregation
Links are terminated by a single termination point, not sets of Links are terminated by a single termination point, not sets of
termination points. Connections involving multihoming or link termination points. Connections involving multihoming or link
aggregation schemes need to be represented using multiple point-to- aggregation schemes need to be represented using multiple point-to-
point links, then defining a link at a higher layer that is supported point links, then defining a link at a higher layer that is supported
by those individual links. by those individual links.
In a hierarchy of topologies, there are nodes mapping to nodes, links 3.3.6. Mapping redundancy
In a hierarchy of networks, there are nodes mapping to nodes, links
mapping to links, and termination points mapping to termination mapping to links, and termination points mapping to termination
points. Some of this information is redundant. Specifically, with points. Some of this information is redundant. Specifically, if the
the link-to-links mapping known, and the termination points of each link-to-links mapping known, and the termination points of each link
link known, maintaining separate termination point mapping known, termination point mapping information can be derived via
information is not needed but can be derived via transitive closure. transitive closure and does not have to be explicitly configured.
The model does provide for the option to include this information Nonetheless, in order to not constrain applications regarding which
explicitly, but does not allow for it to be configured to avoid the mappings they want to configure and which should be derived, the
potential to introduce (and having to validate) corresponding model does provide for the option to configure this information
integrity issues. explicitly. The model includes integrity constraints to allow for
validating for consistency.
A topology's topology types are represented using a container which 3.3.7. Typing
contains a data node for each of its topology types. A topology can
encompass several types of topology simultaneously, hence a container A network's network types are represented using a container which
is used instead of a case construct, with each topology type in turn contains a data node for each of its network types. A network can
encompass several types of network simultaneously, hence a container
is used instead of a case construct, with each network type in turn
represented by a dedicated presence container itself. The reason for represented by a dedicated presence container itself. The reason for
not simply using an empty leaf, or even simpler, do away even with not simply using an empty leaf, or even simpler, do away even with
the topology container and just use a leaf-list of topology-type the network container and just use a leaf-list of network-type
instead, is to be able to represent "class hierarchies" of topology instead, is to be able to represent "class hierarchies" of network
types, with one topology type refining the other. Topology-type types, with one network type refining the other. Network-type
specific containers are to be defined in the topology-specific specific containers are to be defined in the network-specific
modules, augmenting the topology-types container. modules, augmenting the network-types container.
3.3. Open issues and items for further discussion 3.3.8. Representing the same device in multiple networks
One common requirement concerns the ability to represent that the
same device can be part of multiple networks and topologies.
However, the model defines a node as relative to the network that it
is contained in. The same node cannot be part of multiple
topologies. In many cases, a node will be the abstraction of a
particular device in a network. To reflect that the same device is
part of multiple topologies, the following approach might be chosen:
A "physical" (or "device") network is introduced, with nodes
representing devices. This network forms an underlay network for
logical networks above it, with nodes of the logical network mapping
onto nodes in the physical network.
This scenario is depicted in the following figure. It depicts three
networks with two nodes each. A physical network P consists of an
inventory of two nodes, D1 and D2, each representing a device. A
second network, X, has a third network, Y, as its underlay. Both X
and Y also have the physical network P as underlay. X1 has both Y1
and D1 as underlay nodes, while Y1 has D1 as underlay node.
Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as
underlay node. The fact that X1 and Y1 are both instantiated on the
same physical node D1 can be easily derived.
+---------------------+
/ [X1]____[X2] / X(Service Overlay)
+----:--:----:--------+
..: :..: :
........: ....: : :....
+-----:-------------:--+ : :...
/ [Y1]____[Y2]....: / :.. :
+------|-------|-------+ :.. :...
Y(L3) | +---------------------:-----+ :
| +----:----|-:----------+
+------------------------/---[D1] [D2] /
+----------------------+
P (Physical network)
Figure 6: Topology hierarchy example - multiple underlays
3.4. Items for further discussion
YANG requires data needs to be designated as either configuration or YANG requires data needs to be designated as either configuration or
operational data, but not both, yet it is important to have all operational data, but not both, yet it is important to have all
topology information, including vertical cross-topology dependencies, network information, including vertical cross-network dependencies,
captured in one coherent model. In most cases topology information captured in one coherent model. In most cases network topology
is discovered about a network; the topology is considered a property information is discovered about a network; the topology is considered
of the network that is reflected in the model. That said, it is a property of the network that is reflected in the model. That said,
conceivable that certain types of topology need to also be it is conceivable that certain types of topology need to also be
configurable by an application. configurable by an application.
There are several alternatives in which this can be addressed. The There are several alternatives in which this can be addressed. The
alternative chosen in this draft does not restrict topology alternative chosen in this draft does not restrict network topology
information as read-only, but includes a flag that indicates for each information as read-only, but includes a flag that indicates for each
topology whether it should be considered as read-only or configurable network whether it should be considered as read-only or configurable
by applications. by applications.
An alternative would be to designate topology list elements as read An alternative would be to designate network list elements as read
only. The read-only topology list includes each topology; it is the only. The read-only network list includes each network; it is the
complete reference. In parallel a second topology list is complete reference. In parallel a second network list is introduced.
introduced. This list serves the purpose of being able to configure This list serves the purpose of being able to configure networks
topologies which are then mirrored in the read-only list. The which are then mirrored in the read-only list. The configurable
configurable topology list adheres to the same structure and uses the network list adheres to the same structure and uses the same
same groupings as its read-only counterpart. As most data is defined groupings as its read-only counterpart. As most data is defined in
in those groupings, the amount of additional definitions required those groupings, the amount of additional definitions required will
will be limited. A configurable topology will thus be represented be limited. A configurable network will thus be represented twice:
twice: once in the read-only list of all topologies, a second time in once in the read-only list of all networks, a second time in a
a configuration sandbox. configuration sandbox.
Similar considerations apply to scenarios in which data is subject to
configuration, but implementations want to be smart enough require
only some mapping information, such as which link is supported by
which other links, while automatically deriving other mapping
information where possible, such as which termination points are
supported by which underlay termination points. To accommodate such
cases, separate provision may again be made by including another
"server-provided" option.
4. YANG Modules 4. YANG Modules
4.1. Defining the Abstract Network: network.yang 4.1. Defining the Abstract Network: network.yang
<CODE BEGINS> file "network.yang" <CODE BEGINS> file "network.yang"
module network { module network {
yang-version 1; yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:nodes"; namespace "urn:TBD:params:xml:ns:yang:nodes";
prefix nd; prefix nd;
skipping to change at page 11, line 6 skipping to change at page 15, line 4
4. YANG Modules 4. YANG Modules
4.1. Defining the Abstract Network: network.yang 4.1. Defining the Abstract Network: network.yang
<CODE BEGINS> file "network.yang" <CODE BEGINS> file "network.yang"
module network { module network {
yang-version 1; yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:nodes"; namespace "urn:TBD:params:xml:ns:yang:nodes";
prefix nd; prefix nd;
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
organization "TBD"; organization "TBD";
contact contact
"WILL-BE-DEFINED-LATER"; "WILL-BE-DEFINED-LATER";
description description
"This module defines a common base model for a collection "This module defines a common base model for a collection
of nodes in a network. Node definitions s are further used of nodes in a network. Node definitions s are further used
in network topologies and inventories."; in network topologies and inventories.";
revision 2014-12-11 { revision 2014-3-5 {
description description
"Initial revision."; "Initial revision.";
reference "draft-clemm-i2rs-yang-network-topo-01"; reference "draft-clemm-i2rs-yang-network-topo-03";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
} }
typedef network-id { typedef network-id {
type inet:uri; type inet:uri;
} }
skipping to change at page 13, line 23 skipping to change at page 17, line 17
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import nodes { prefix nd; } import nodes { prefix nd; }
organization "TBD"; organization "TBD";
contact contact
"WILL-BE-DEFINED-LATER"; "WILL-BE-DEFINED-LATER";
description description
"This module defines a common base model for a collection of links "This module defines a common base model for a collection of links
connecting nodes."; connecting nodes.";
revision 2014-12-11 { revision 2014-3-5 {
description description
"Initial revision."; "Initial revision.";
reference "draft-clemm-i2rs-yang-network-topo-01"; reference "draft-clemm-i2rs-yang-network-topo-03";
} }
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 identifier may be opaque. The identifier may be opaque.
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
same identifier, even if the model is instantiated in separate same identifier, even if the model is instantiated in separate
skipping to change at page 18, line 26 skipping to change at page 22, line 20
o Ken Gray, Cisco Systems o Ken Gray, Cisco Systems
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Aleksandr Zhdankin, Cisco o Aleksandr Zhdankin, Cisco
7. Acknowledgements 7. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Martin Bjorklund, Ladislav suggestions that were received from Alia Atlas, Vishna Pavan Beeram,
Lhotka, Andy Bierman, Carlos Pignataro, Juergen Schoenwaelder, Alia Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan
Atlas and Benoit Claise. Hares, Xufeng Liu, Ladislav Lhotka, Carlos Pignataro, and Juergen
Schoenwaelder.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
skipping to change at page 19, line 5 skipping to change at page 22, line 49
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
8.2. Informative References [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014.
[if-config] 8.2. Informative References
Bjorklund, M., "A YANG Data Model for Interface
Management", I-D draft-ietf-netmod-interfaces-cfg-16, July
2013.
[restconf] [restconf]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
"RESTCONF Protocol", I-D draft-bierman-netconf-restconf- Protocol", I-D draft-ietf-netconf-restconf-04, January
04, February 2014. 2015.
[topology-use-cases] [topology-use-cases]
Medved, J., Previdi, S., Lopez, V., and S. Amante, Medved, J., Previdi, S., Lopez, V., and S. Amante,
"Topology API Use Cases", I-D draft-amante-i2rs-topology- "Topology API Use Cases", I-D draft-amante-i2rs-topology-
use-cases-01, October 2013. use-cases-01, October 2013.
[yang-json] [yang-json]
Lhotka, L., "Modeling JSON Text with YANG", I-D draft- Lhotka, L., "JSON Encoding of Data Modeled with YANG", I-D
lhotka-etmod-yang-json-02, September 2013. draft-ietf-netmod-yang-json-03, February 2015.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Cisco Cisco
EMail: alex@cisco.com EMail: alex@cisco.com
Jan Medved Jan Medved
Cisco Cisco
skipping to change at page 20, line 4 skipping to change at page 23, line 42
Robert Varga Robert Varga
Cisco Cisco
EMail: rovarga@cisco.com EMail: rovarga@cisco.com
Tony Tkacik Tony Tkacik
Cisco Cisco
EMail: ttkacik@cisco.com EMail: ttkacik@cisco.com
Nitin Bahadur Nitin Bahadur
Bracket Computing Bracket Computing
EMail: nitin_bahadur@yahoo.com EMail: nitin_bahadur@yahoo.com
Hariharan Ananthakrishnan Hariharan Ananthakrishnan
Packet Design Packet Design
EMail: hanantha@juniper.net EMail: hari@packetdesign.com
 End of changes. 51 change blocks. 
195 lines changed or deleted 356 lines changed or added

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