draft-ietf-i2rs-yang-network-topo-03.txt   draft-ietf-i2rs-yang-network-topo-04.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft J. Medved Internet-Draft J. Medved
Intended status: Standards Track R. Varga Intended status: Standards Track R. Varga
Expires: December 11, 2016 T. Tkacik Expires: January 9, 2017 T. Tkacik
Cisco Cisco
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Kuatro Technologies Ericsson
June 9, 2016 July 8, 2016
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-03.txt draft-ietf-i2rs-yang-network-topo-04.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 model serves as a network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in base model which is augmented with technology-specific details in
other, more specific topology and inventory models. other, more specific topology and inventory models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 11, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.4. Discussion and selected design decisions . . . . . . . . 12 3.4. Discussion and selected design decisions . . . . . . . . 12
3.4.1. Container structure . . . . . . . . . . . . . . . . . 12 3.4.1. Container structure . . . . . . . . . . . . . . . . . 12
3.4.2. Underlay hierarchies and mappings . . . . . . . . . . 12 3.4.2. Underlay hierarchies and mappings . . . . . . . . . . 12
3.4.3. Dealing with changes in underlay networks . . . . . . 13 3.4.3. Dealing with changes in underlay networks . . . . . . 13
3.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13 3.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13
3.4.5. Cardinality and directionality of links . . . . . . . 13 3.4.5. Cardinality and directionality of links . . . . . . . 13
3.4.6. Multihoming and link aggregation . . . . . . . . . . 14 3.4.6. Multihoming and link aggregation . . . . . . . . . . 14
3.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14 3.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14
3.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.9. Representing the same device in multiple networks . . 14 3.4.9. Representing the same device in multiple networks . . 14
3.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Supporting client as well as server provided network
3.5.1. Supporting client as well as server provided network topology . . . . . . . . . . . . . . . . . . . . . . . . 15
topology . . . . . . . . . . . . . . . . . . . . . . 16 3.6. Identifiers of string or URI type . . . . . . . . . . . . 17
3.5.2. Identifiers of string or URI type . . . . . . . . . . 17
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Defining the Abstract Network: network.yang . . . . . . . 17 4.1. Defining the Abstract Network: network.yang . . . . . . . 17
4.2. Creating Abstract Network Topology: network-topology.yang 22 4.2. Creating Abstract Network Topology: network-topology.yang 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document introduces an abstract (base) YANG [RFC6020] [RFC6021] This document introduces an abstract (base) YANG [RFC6020] [RFC6021]
data model to represent networks and topologies. The data model is data model to represent networks and topologies. The data model is
divided into two parts. The first part of the model defines a divided into two parts. The first part of the model defines a
network model that allows to define network hierarchies (i.e. network network model that allows to define network hierarchies (i.e. network
stacks) and to maintain an inventory of nodes contained in a network. stacks) and to maintain an inventory of nodes contained in a network.
The second part of the model augments the basic network model with The second part of the model augments the basic network model with
skipping to change at page 8, line 5 skipping to change at page 8, line 5
3. Model Structure Details 3. Model Structure Details
3.1. Base Network Model 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. A "+" operational state data, and "?" designates optional nodes. A "+"
indicates a line break. indicates a line break.
module: ietf-network module: ietf-network
+--rw networks +--rw networks
| +--rw network* [network-id] +--rw network* [network-id]
| +--rw network-types +--rw network-types
| +--rw network-id network-id +--rw network-id network-id
| +--rw supporting-network* [network-ref] +--ro server-provided? boolean
| | +--rw network-ref -> /networks/network/network-id +--rw supporting-network* [network-ref]
| +--rw node* [node-id] | +--rw network-ref -> /networks/network/network-id
| +--rw node-id node-id +--rw node* [node-id]
| +--rw supporting-node* [network-ref node-ref] +--rw node-id node-id
| +--rw network-ref -> ../../../supporting-network/+ +--rw supporting-node* [network-ref node-ref]
| | network-ref +--rw network-ref -> ../../../supporting-network/ +
| +--rw node-ref -> /networks/network/node/node-id | network-ref
+--ro networks-state +--rw node-ref -> /networks/network/node/node-id
+--ro network* [network-ref]
+--ro network-ref -> /networks/network/network-id
+--ro server-provided? boolean
Figure 4: The structure of the abstract (base) network model Figure 4: The structure of the abstract (base) network model
The model contains a container with a list of networks, and a The model contains a container with a list of networks. Each network
container with a list of network state. is captured in its own list entry, distinguished via a network-id.
Container "networks" contains a list of networks. Each network is
captured in its own list entry, distinguished via a network-id.
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
skipping to change at page 9, line 37 skipping to change at page 9, line 32
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 to represent device stacks, where a node at one 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 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 example, a "router" node might be supported by a node representing a
route processor and separate nodes for various line cards and service route processor and separate nodes for various line cards and service
modules, a virtual router might be supported or hosted on a physical modules, a virtual router might be supported or hosted on a physical
device represented by a separate node, and so on. device represented by a separate node, and so on.
Container "networks-state" contains data about the network state. It Finally, there is an object "server-provided". This object is state
contains a list of networks, mirroring the corresponding list under that indicates how the network came into being. Network data can
the "networks" container and containing in each data node state come into being in one of two ways. In one way, network data is
information for the corresponding network. Currently, each list configured by client applications, for example in case of overlay
element contains a single state, "server-provided". This state networks that are configured by an SDN Controller application. In
indicates how the network came into being. If false, the network was annother way, it is populated by the server, in case of networks that
configured by a client application, for example in the case of an can be discovered.
overlay network that is configured by a controller application. If
true, the network was populated by the server itself, respectively an
application on the server that is able to discover the network.
Network data can come into being in one of two ways. In one way, If server-provided is set to false, the network was configured by a
network data is configured by client applications, for example in client application, for example in the case of an overlay network
case of overlay networks that are configured by an SDN Controller that is configured by a controller application. If server-provided
application. In annother way, it is populated by the server, in case is set to true, the network was populated by the server itself,
of networks that can be discovered. Client applications SHOULD NOT respectively an application on the server that is able to discover
modify configurations of networks for which "server-provided" is the network. Client applications SHOULD NOT modify configurations of
true. (Please note this is an open issue for further discussion, see networks for which "server-provided" is true. When they do, they
section Section 3.5.) need to be aware that any modifications they make are subject to be
reverted by the server. For servers that support NACM (Netconf
Access Control Model), data node rules should ideally prevent write
access by other clients to network instances for which server-
provided is set to true.
3.2. Base Network Topology Model 3.2. Base Network Topology Model
The abstract (base) network topology model is defined in the The abstract (base) network topology model is defined in the
"network-topology.yang" module. It builds on the network model "network-topology.yang" module. It builds on the network model
defined in the "network.yang" module, augmenting it with links defined in the "network.yang" module, augmenting it with links
(defining how nodes are connected) and termination-points (which (defining how nodes are connected) and termination-points (which
anchor the links and are contained in nodes). The structure of the anchor the links and are contained in nodes). The structure of the
network topology module is shown in the following figure. Brackets network topology module 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
skipping to change at page 10, line 33 skipping to change at page 10, line 30
+--rw source +--rw source
| +--rw source-node -> ../../../nd:node/node-id | +--rw source-node -> ../../../nd:node/node-id
| +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+ | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+
| ../source-node]/termination-point/tp-id | ../source-node]/termination-point/tp-id
+--rw destination +--rw destination
| +--rw dest-node -> ../../../nd:node/node-id | +--rw dest-node -> ../../../nd:node/node-id
| +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+
| ../dest-node]/termination-point/tp-id | ../dest-node]/termination-point/tp-id
+--rw link-id link-id +--rw link-id link-id
+--rw supporting-link* [network-ref link-ref] +--rw supporting-link* [network-ref link-ref]
+--rw network-ref -> ../../../nd:supporting-network/+ +--rw network-ref -> ../../../nd:supporting-network/network-ref
| network-ref +--rw link-ref -> /nd:networks/network+
+--rw link-ref -> /nd:networks/network[nd:network-id=+ [nd:network-id=current()/../network-ref]/+
current()/../network-ref]/link/link-id link/link-id
augment /nd:networks/nd:network/nd:node: augment /nd:networks/nd:network/nd:node:
+--rw termination-point* [tp-id] +--rw termination-point* [tp-id]
+--rw tp-id tp-id +--rw tp-id tp-id
+--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw supporting-termination-point* [network-ref node-ref tp-ref]
+--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw network-ref -> ../../../nd:supporting-node/network-ref
+--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref
+--rw tp-ref -> /nd:networks/network[nd:network-id=+ +--rw tp-ref -> /nd:networks/network[nd:network-id=+
current()/../network-ref]/node+ current()/../network-ref]/node+
[nd:node-id=current()/../node-ref]/+ [nd:node-id=current()/../node-ref]/+
termination-point/tp-id termination-point/tp-id
skipping to change at page 15, line 45 skipping to change at page 15, line 43
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 model for a physical network-type, also conceivable to augment the model for a physical network-type,
defining augmentations that have nodes reference system information defining augmentations that have nodes reference system information
and termination points reference physical interfaces, in order to and termination points reference physical interfaces, in order to
provide a bridge between network and device models. provide a bridge between network and device models.
3.5. Open Issues 3.5. Supporting client as well as server provided network topology
3.5.1. Supporting client as well as server provided network topology
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
network information, including vertical cross-network dependencies, network information, including vertical cross-network dependencies,
captured in one coherent model. In most cases network topology captured in one coherent model. In most cases network topology
information is discovered about a network; the topology is considered information is discovered about a network; the topology is considered
a property of the network that is reflected in the model. That said, a property of the network that is reflected in the model. That said,
it is 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 network topology alternative chosen in this draft does not restrict network topology
information as read-only, but includes a state that indicates for information as read-only, but includes a state "server-provided" that
each network whether it is populated by the server or by a client indicates for each network whether it is populated by the server or
application. The drawback of this solution is that it stretches its by a client application. Client applications that do attempt to
use of the configuration concept. Configuration information in modify network topology may simply see their actions reverted, not
general is subject to backup and restore, which is not applicable to unlike any other client applications that competes with another
server-provided information. Perhaps more serious is the ability of application wanting to "own" the same data. When Netconf Access
a client to lock a configuration and thus prevent changes to server- Control Model [RFC6536] is supported, node access rules can be
provided network topology while the lock is in effect. Preventing automatically maintained to deny client write access to network and
this requires special treatment of network topology related topology instances for which "server-provided" is true. It should be
configuration information. noted that this solution stretches its use of the configuration
concept slightly. Configuration information in general is subject to
backup and restore, which is not applicable to server-provided
information. Perhaps more noteworthy is the potential ability of a
client to lock a configuration and thus prevent changes to server-
provided network topology while the lock is in effect. As a result
it would potentially incur a time lag until topology changes that
occur in the meantime are reflected, unless implementations choose to
provide special treatment for network topology information.
In another alternative, all information about network topology that Other alternatives had been considered. In one alternative, all
is in effect is represented as network state, i.e. as read-only information about network topology is in effect is represented as
information, regardless of how it came into being. For cases where network state, i.e. as read-only information, regardless of how it
network topology needs to be configured, a second branch for came into being. For cases where network topology needs to be
configurable topology information is introduced. Any network configured, a second branch for configurable topology information is
topology configuration is mirrored by network state information. A introduced. Any network topology configuration is mirrored by
configurable network will thus be represented twice: once in the network state information. A configurable network will thus be
read-only list of all networks, a second time in a configuration represented twice: once in the read-only list of all networks, a
sandbox. The drawback of this solution is increased complexity of second time in a configuration sandbox. One implication of this
augmentations due to two target branches. solution would have been significantly increased complexity of
augmentations due to multiple target branches.
A third alternative would make use of YANG metadata Another alternative would make use of a YANG extension to tag
[I-D.draft-ietf-netmod-yang-metadata]. Topology information specific network instances as "server-provided" instead of defining a
represents configuration data. In addition, a new metadata tag is leaf object, or rely on the concept of YANG metadata
introduced to be able to tag data populated by the server as server- [I-D.draft-ietf-netmod-yang-metadata] for the same effect. The tag
provided. This could be a boolean, or even a type "empty". The would be automatically applied to any topology data that comes into
semantics of the tag is that it is applied to any topology data that being (respectively is configured) by an embedded application on the
comes into being (respectively is configured) by an embedded network, as opposed to e.g. a controller application.
application on the network, as opposed to e.g. a controller
application. The metadata will be set automatically by the server as
applicable.
3.5.2. Identifiers of string or URI type 3.6. Identifiers of string or URI type
The current model defines identifiers of nodes, networks, links, and The current model defines identifiers of nodes, networks, links, and
termination points as URIs. An alternative would define them as termination points as URIs. An alternative would define them as
string. string.
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 (a string is a string is a string),
skipping to change at page 17, line 29 skipping to change at page 17, line 29
data. A URI makes the structure explicit and also attaches data. A URI makes the structure explicit and also attaches
additional semantics: the URI, unlike a free-form string, can be fed additional semantics: the URI, unlike a free-form string, can be fed
into a URI resolver, which can point to additional resources into a URI resolver, which can point to additional resources
associated with the URI. This property is important when the associated with the URI. This property is important when the
topology data is integrated into a larger, more complex system. topology data is integrated into a larger, more complex system.
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 "ietf-network@2016-06-09.yang" <CODE BEGINS> file "ietf-network@2016-07-08.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 nd; prefix nd;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
skipping to change at page 18, line 40 skipping to change at page 18, 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-03; draft-ietf-i2rs-yang-network-topo-04;
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-03 with RFC draft-ietf-i2rs-yang-network-topo-04 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2016-06-09 { revision 2016-07-08 {
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-02 with to draft-ietf-i2rs-yang-network-topo-04 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-03"; "draft-ietf-i2rs-yang-network-topo-04";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node."; "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be
identified through the same identifier, even if the model is
instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier, for example to
indicate the type of node.";
} }
typedef network-id { typedef network-id {
type inet:uri; type inet:uri;
description description
"Identifier for a network."; "Identifier for a network. The precise structure of the
network-id will be up to an implementation.
The identifier SHOULD be chosen such that the same network
will always be identified through the same identifier,
even if the model is instantiated in separate datastores.
An implementation MAY choose to capture semantics in the
identifier, for example to indicate the type of network.";
} }
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 "/nd:networks/nd:network/nd:network-id"; path "/nd:networks/nd:network/nd:network-id";
require-instance false; require-instance false;
skipping to change at page 20, line 26 skipping to change at page 20, line 41
description description
"Serves as an augmentation target. "Serves as an augmentation target.
The network type is indicated through corresponding The network type is indicated through corresponding
presence containers augmented into this container."; presence containers augmented into this container.";
} }
leaf network-id { leaf network-id {
type network-id; type network-id;
description description
"Identifies a network."; "Identifies a network.";
} }
leaf server-provided {
type boolean;
config false;
description
"Indicates whether the information concerning this
particular network is populated by the server
(server-provided true, the general case for network
information discovered from the server),
or whether it is configured by a client
(server-provided true, possible e.g. for
service overlays managed through a controller).
Clients should not attempt to make modifications
to network instances with server-provided set to
true; when they do, they need to be aware that
any modifications they make are subject to be
reverted by the server.
For servers that support NACM (Netconf Access Control
Model), data node rules should ideally prevent
write access by other clients to the network instance
when server-provided is set to true.";
}
list supporting-network { list supporting-network {
key "network-ref"; key "network-ref";
description description
"An underlay network, used to represent layered network "An underlay network, used to represent layered network
topologies."; topologies.";
leaf network-ref { leaf network-ref {
type leafref { type leafref {
path "/networks/network/network-id"; path "/networks/network/network-id";
require-instance false; require-instance false;
} }
skipping to change at page 21, line 29 skipping to change at page 22, line 18
path "/networks/network/node/node-id"; path "/networks/network/node/node-id";
require-instance false; require-instance false;
} }
description description
"References the underlay node itself."; "References the underlay node itself.";
} }
} }
} }
} }
} }
container networks-state {
config false;
description
"Serves as top-level container for a list of state information
for networks";
list network {
key "network-ref";
description
"Data nodes representing operational data and state of
networks.
An instance is automatically created for every network
in the corresponding list under the networks container.";
uses network-ref;
leaf server-provided {
type boolean;
description
"Indicates whether the information concerning this
particular network is populated by the server
(server-provided true, the general case for network
information discovered from the server),
or whether it is configured by a client
(server-provided true, possible e.g. for
service overlays managed through a controller).";
}
}
}
} }
<CODE ENDS> <CODE ENDS>
4.2. Creating Abstract Network Topology: network-topology.yang 4.2. Creating Abstract Network Topology: network-topology.yang
<CODE BEGINS> file "ietf-network-topology@2016-06-09.yang" <CODE BEGINS> file "ietf-network-topology@2016-07-08.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 lnk; prefix lnk;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-network { import ietf-network {
prefix nd; prefix nd;
skipping to change at page 23, line 28 skipping to change at page 23, line 39
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-03; draft-ietf-i2rs-yang-network-topo-04;
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-03 with RFC draft-ietf-i2rs-yang-network-topo-04 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2016-06-09 { revision 2016-07-08 {
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-02 with to draft-ietf-i2rs-yang-network-topo-04 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-02."; "draft-ietf-i2rs-yang-network-topo-04";
} }
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
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
same identifier, even if the model is instantiated in same identifier, even if the model is instantiated in
separate datastores. An implementation MAY choose to capture separate datastores. An implementation MAY choose to capture
semantics in the identifier, for example to indicate the type semantics in the identifier, for example to indicate the type
of link and/or the type of topology that the link is a part of link and/or the type of topology that the link is a part
of."; of.";
} }
typedef tp-id { typedef tp-id {
type inet:uri; type inet:uri;
description description
"An identifier for termination points on a node. "An identifier for termination points (TPs) on a node.
The identifier SHOULD be chosen such that the same TP in a The precise structure of the tp-id
real network topology will always be identified through the will be up to the implementation.
same identifier, even if the model is instantiated in The identifier SHOULD be chosen such that the same termination
separate datastores. An implementation MAY choose to capture point in a real network topology will always be identified
semantics in the identifier, for example to indicate the type through the same identifier, even if the model is instantiated
of TP and/or the type of node and topology that the TP is a in separate datastores. An implementation MAY choose to
part of."; capture semantics in the identifier, for example to indicate
the type of termination point and/or the type of node
that contains the termination point.";
} }
grouping link-ref { grouping link-ref {
description description
"References a link in a specific network."; "References a link in a specific network.";
leaf link-ref { leaf link-ref {
type leafref { type leafref {
path "/nd:networks/nd:network[nd:network-id=current()/../"+ path "/nd:networks/nd:network[nd:network-id=current()/../"+
"network-ref]/lnk:link/lnk:link-id"; "network-ref]/lnk:link/lnk:link-id";
require-instance false; require-instance false;
skipping to change at page 25, line 17 skipping to change at page 25, line 31
} }
uses nd:node-ref; uses nd:node-ref;
} }
augment "/nd:networks/nd:network" { augment "/nd:networks/nd:network" {
description description
"Add links to the network model."; "Add links to the network model.";
list link { list link {
key "link-id"; key "link-id";
description description
"A Network Link connects a by Local (Source) node and "A network link connects a local (source) node and
a Remote (Destination) Network Nodes via a set of the a remote (destination) node via a set of
nodes' termination points. the respective node's termination points.
As it is possible to have several links between the same It is possible to have several links between the same
source and destination nodes, and as a link could source and destination nodes. Likewise, a link could
potentially be re-homed between termination points, to potentially be re-homed between termination points.
ensure that we would always know to distinguish between Therefore, in order to ensure that we would always know
links, every link is identified by a dedicated link to distinguish between links, every link is identified by
identifier. a dedicated link identifier. Note that a link models a
Note that a link models a point-to-point link, not a point-to-point link, not a multipoint link.
multipoint link.
Layering dependencies on links in underlay topologies are Layering dependencies on links in underlay topologies are
not represented as the layering information of nodes and of not represented, as the layering information of nodes and of
termination points is sufficient."; termination points is sufficient.";
container source { container source {
description description
"This container holds the logical source of a particular "This container holds the logical source of a particular
link."; link.";
leaf source-node { leaf source-node {
type leafref { type leafref {
path "../../../nd:node/nd:node-id"; path "../../../nd:node/nd:node-id";
require-instance false;
} }
mandatory true; mandatory true;
description description
"Source node identifier, must be in same topology."; "Source node identifier, must be in same topology.";
} }
leaf source-tp { leaf source-tp {
type leafref { type leafref {
path "../../../nd:node[nd:node-id=current()/../"+ path "../../../nd:node[nd:node-id=current()/../"+
"source-node]/termination-point/tp-id"; "source-node]/termination-point/tp-id";
require-instance false;
} }
description description
"Termination point within source node that terminates "Termination point within source node that terminates
the link."; the link.";
} }
} }
container destination { container destination {
description description
"This container holds the logical destination of a "This container holds the logical destination of a
particular link."; particular link.";
leaf dest-node { leaf dest-node {
type leafref { type leafref {
path "../../../nd:node/nd:node-id"; path "../../../nd:node/nd:node-id";
require-instance false;
} }
mandatory true; mandatory true;
description description
"Destination node identifier, must be in the same "Destination node identifier, must be in the same
network."; network.";
} }
leaf dest-tp { leaf dest-tp {
type leafref { type leafref {
path "../../../nd:node[nd:node-id=current()/../"+ path "../../../nd:node[nd:node-id=current()/../"+
"dest-node]/termination-point/tp-id"; "dest-node]/termination-point/tp-id";
require-instance false;
} }
description description
"Termination point within destination node that "Termination point within destination node that
terminates the link."; terminates the link.";
} }
} }
leaf link-id { leaf link-id {
type link-id; type link-id;
description description
"The identifier of a link in the topology. "The identifier of a link in the topology.
skipping to change at page 26, line 45 skipping to change at page 27, line 14
description description
"Identifies the link, or links, that this link "Identifies the link, or links, that this link
is dependent on."; is dependent on.";
leaf network-ref { leaf network-ref {
type leafref { type leafref {
path "../../../nd:supporting-network/nd:network-ref"; path "../../../nd:supporting-network/nd:network-ref";
require-instance false; require-instance false;
} }
description description
"This leaf identifies in which underlay topology "This leaf identifies in which underlay topology
supporting link is present."; the supporting link is present.";
} }
leaf link-ref { leaf link-ref {
type leafref { type leafref {
path "/nd:networks/nd:network[nd:network-id=current()/"+ path "/nd:networks/nd:network[nd:network-id=current()/"+
"../network-ref]/link/link-id"; "../network-ref]/link/link-id";
require-instance false; require-instance false;
} }
description description
"This leaf identifies a link which is a part "This leaf identifies a link which is a part
of this link's underlay. Reference loops, in which of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either a link identifies itself as its underlay, either
directly or transitively, are not allowed."; directly or transitively, are not allowed.";
} }
} }
} }
} }
augment "/nd:networks/nd:network/nd:node" { augment "/nd:networks/nd:network/nd:node" {
description description
"Augment termination points which terminate links. "Augment termination points which terminate links.
Termination points can ultimately be mapped to interfaces."; Termination points can ultimately be mapped to interfaces.";
skipping to change at page 27, line 33 skipping to change at page 27, line 49
Depending on the type of topology, a termination point Depending on the type of topology, a termination point
could, for example, refer to a port or an interface."; could, for example, refer to a port or an interface.";
leaf tp-id { leaf tp-id {
type tp-id; type tp-id;
description description
"Termination point identifier."; "Termination point identifier.";
} }
list supporting-termination-point { list supporting-termination-point {
key "network-ref node-ref tp-ref"; key "network-ref node-ref tp-ref";
description description
"The leaf list identifies any termination points that "This list identifies any termination points that
the termination point is dependent on, or maps onto. the termination point is dependent on, or maps onto.
Those termination points will themselves be contained Those termination points will themselves be contained
in a supporting node. in a supporting node.
This dependency information can be inferred from This dependency information can be inferred from
the dependencies between links. For this reason, the dependencies between links. For this reason,
this item is not separately configurable. Hence no this item is not separately configurable. Hence no
corresponding constraint needs to be articulated. corresponding constraint needs to be articulated.
The corresponding information is simply provided by the The corresponding information is simply provided by the
implementing system."; implementing system.";
leaf network-ref { leaf network-ref {
skipping to change at page 29, line 8 skipping to change at page 29, line 22
o Xufeng Liu, Ericsson o Xufeng Liu, Ericsson
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 Alia Atlas, Vishna Pavan Beeram, suggestions that were received from Alia Atlas, Vishnu Pavan Beeram,
Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan
Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, and Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent
Xian Zhang. Watsen, and Xian Zhang.
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", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
skipping to change at page 29, line 37 skipping to change at page 30, line 5
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)", Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011. RFC 6241, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
[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.
8.2. Informative References 8.2. Informative References
[I-D.draft-ietf-netconf-yang-push] [I-D.draft-ietf-netconf-yang-push]
Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
and E. Nilsen-Nygaard, "Subscribing to YANG datastore push and E. Nilsen-Nygaard, "Subscribing to YANG datastore push
updates", I-D draft-ietf-netconf-yang-push-02, March 2016. updates", I-D draft-ietf-netconf-yang-push-03, June 2016.
[I-D.draft-ietf-netmod-yang-metadata] [I-D.draft-ietf-netmod-yang-metadata]
Lhotka, L., "Defining and Using Metadata with YANG", I-D Lhotka, L., "Defining and Using Metadata with YANG", I-D
draft-ietf-netmod-yang-metadata-07, March 2016. draft-ietf-netmod-yang-metadata-07, March 2016.
[I.D.draft-ietf-netmod-rfc6020bis] [I.D.draft-ietf-netmod-rfc6020bis]
Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D
draft-ietf-netmod-rfc6020bis-12, April 2016. draft-ietf-netmod-rfc6020bis-14, June 2016.
[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.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Cisco Cisco
skipping to change at page 31, line 4 skipping to change at page 31, line 18
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: hari@packetdesign.com EMail: hari@packetdesign.com
Xufeng Liu Xufeng Liu
Kuatro Technologies Ericsson
EMail: xliu@kuatrotech.com EMail: xliu@kuatrotech.com
 End of changes. 53 change blocks. 
158 lines changed or deleted 177 lines changed or added

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