draft-ietf-i2rs-yang-network-topo-04.txt   draft-ietf-i2rs-yang-network-topo-05.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: January 9, 2017 T. Tkacik Expires: January 30, 2017 Cisco
Cisco T. Tkacik
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Ericsson Ericsson
July 8, 2016 July 29, 2016
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-04.txt draft-ietf-i2rs-yang-network-topo-05.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 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 January 9, 2017. This Internet-Draft will expire on January 30, 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 45
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. Supporting client as well as server provided network 3.5. Supporting client-configured and server-provided network
topology . . . . . . . . . . . . . . . . . . . . . . . . 15 topology . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6. Identifiers of string or URI type . . . . . . . . . . . . 17 3.6. 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 . . . . . . . . . . . . . . . . . . . . . . . . 29 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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
The model contains a container with a list of networks. Each network The model contains a container with a list of networks. Each network
is captured in its own list entry, distinguished via a network-id. 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
data node. Network types SHOULD always be represented using presence data node. Network types SHOULD always be represented using presence
containers, not leafs of empty type. This allows to represent containers, not leafs of empty type. This allows to represent
hierarchies of network subtypes within the instance information. For hierarchies of network subtypes within the instance information. For
example, an instance of an OSPF network (which, at the same time, is example, an instance of an OSPF network (which, at the same time, is
a layer 3 unicast IGP network) would contain underneath "network- a layer 3 unicast IGP network) would contain underneath "network-
types" another container "l3-unicast-igp-network", which in turn types" another container "l3-unicast-igp-network", which in turn
would contain a container "ospf-network". would contain a container "ospf-network".
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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
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-topology module: ietf-network-topology
augment /nd:networks/nd:network: augment /nd:networks/nd:network:
+--rw link* [link-id] +--rw link* [link-id]
+--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/network-ref +--rw network-ref -> ../../../nd:supporting-network/network-ref
+--rw link-ref -> /nd:networks/network+ +--rw link-ref -> /nd:networks/network+
[nd:network-id=current()/../network-ref]/+ [nd:network-id=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]
skipping to change at page 11, line 22 skipping to change at page 11, line 22
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
(which are terminated by the corresponding underlay termination (which are terminated by the corresponding underlay termination
points). This is captured in the list "supporting-link". points). This is captured in the list "supporting-link".
3.3. Extending the model 3.3. Extending the model
In order to derive a model for a specific type of network, the base In order to derive a model for a specific type of network, the base
model can be extended. This can be done roughly as follows: for the model can be extended. This can be done roughly as follows: for the
new network type, a new YANG module is introduced. In this module a new network type, a new YANG module is introduced. In this module, a
number of augmentations are defined against the network and network- number of augmentations are defined against the network and network-
topology YANG modules. topology YANG modules.
We start with augmentations against the network.yang module. First, We start with augmentations against the network.yang module. First,
a new network type needs to be defined. For this, a presence a new network type needs to be defined. For this, a presence
container that resembles the new network type is defined. It is container that resembles the new network type is defined. It is
inserted by means of augmentation below the network-types container. inserted by means of augmentation below the network-types container.
Subsequently, data nodes for any network-type specific node Subsequently, data nodes for any network-type specific node
parameters are defined and augmented into the node list. The new parameters are defined and augmented into the node list. The new
data nodes can be defined as conditional ("when") on the presence of data nodes can be defined as conditional ("when") on the presence of
skipping to change at page 15, line 43 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. Supporting client as well as server provided network topology 3.5. Supporting client-configured and server-provided network topology
YANG requires data needs to be designated as either configuration or YANG requires data nodes 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. The model needs to support both
cases.
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 "server-provided" that information as read-only, but includes a state "server-provided" that
indicates for each network whether it is populated by the server or indicates for each network whether it is populated by the server or
by a client application. Client applications that do attempt to by a client application. Client applications that do attempt to
modify network topology may simply see their actions reverted, not modify network topology may simply see their actions reverted, not
unlike any other client applications that competes with another unlike other client applications that compete with one another, each
application wanting to "own" the same data. When Netconf Access wanting to "own" the same data. When Netconf Access Control Model
Control Model [RFC6536] is supported, node access rules can be [RFC6536] is supported, node access rules SHOULD be automatically
automatically maintained to deny client write access to network and maintained by a server to deny client write access to network and
topology instances for which "server-provided" is true. It should be topology instances for which "server-provided" is true.
noted that this solution stretches its use of the configuration
concept slightly. Configuration information in general is subject to It should be noted that this solution stretches its use of the
backup and restore, which is not applicable to server-provided configuration concept slightly. Configuration information in general
information. Perhaps more noteworthy is the potential ability of a is subject to backup and restore, which is not applicable to server-
client to lock a configuration and thus prevent changes to server- provided information. Perhaps more noteworthy is the potential
provided network topology while the lock is in effect. As a result ability of a client to lock a configuration and thus prevent changes
it would potentially incur a time lag until topology changes that to server-provided network topology while the lock is in effect. As
occur in the meantime are reflected, unless implementations choose to a result it would potentially incur a time lag until topology changes
provide special treatment for network topology information. that occur in the meantime are reflected, unless implementations
choose to provide special treatment for network topology information.
Other alternatives had been considered. In one alternative, all Other alternatives had been considered. In one alternative, all
information about network topology is in effect is represented as information about network topology is in effect is represented as
network state, i.e. as read-only information, regardless of how it network state, i.e. as read-only information, regardless of how it
came into being. For cases where network topology needs to be came into being. For cases where network topology needs to be
configured, a second branch for configurable topology information is configured, a second branch for configurable topology information is
introduced. Any network topology configuration is mirrored by introduced. Any network topology configuration is mirrored by
network state information. A configurable network will thus be network state information. A configurable network will thus be
represented twice: once in the read-only list of all networks, a represented twice: once in the read-only list of all networks, a
second time in a configuration sandbox. One implication of this second time in a configuration sandbox. One implication of this
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-07-08.yang" <CODE BEGINS> file "ietf-network@2016-07-29.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 13 skipping to change at page 18, line 13
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:alex@cisco.com> <mailto:alex@cisco.com>
Editor: Jan Medved Editor: Jan Medved
<mailto:jmedved@cisco.com> <mailto:jmedved@cisco.com>
Editor: Robert Varga Editor: Robert Varga
<mailto:rovarga@cisco.com> <mailto:rovarga@cisco.com>
Editor: Tony Tkacik Editor: Tony Tkacik
<mailto:ttkacik@cisco.com> <mailto:tony.tkacik@gmail.com>
Editor: Nitin Bahadur Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com> <mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com> <mailto:hari@packetdesign.com>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com>"; <mailto:xliu@kuatrotech.com>";
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-04; draft-ietf-i2rs-yang-network-topo-05;
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-04 with RFC draft-ietf-i2rs-yang-network-topo-05 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2016-07-08 { revision 2016-07-29 {
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-04 with to draft-ietf-i2rs-yang-network-topo-05 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-04"; "draft-ietf-i2rs-yang-network-topo-05";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node. The precise structure of the node-id "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be the same node in a real network topology will always be
skipping to change at page 22, line 24 skipping to change at page 22, line 24
} }
} }
} }
} }
} }
<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-07-08.yang" <CODE BEGINS> file "ietf-network-topology@2016-07-29.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 12 skipping to change at page 23, line 12
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:alex@cisco.com> <mailto:alex@cisco.com>
Editor: Jan Medved Editor: Jan Medved
<mailto:jmedved@cisco.com> <mailto:jmedved@cisco.com>
Editor: Robert Varga Editor: Robert Varga
<mailto:rovarga@cisco.com> <mailto:rovarga@cisco.com>
Editor: Tony Tkacik Editor: Tony Tkacik
<mailto:ttkacik@cisco.com> <mailto:tony.tkacik@gmail.com>
Editor: Nitin Bahadur Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com> <mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com> <mailto:hari@packetdesign.com>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com>"; <mailto:xliu@kuatrotech.com>";
skipping to change at page 23, line 39 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-04; draft-ietf-i2rs-yang-network-topo-05;
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-04 with RFC draft-ietf-i2rs-yang-network-topo-05 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2016-07-08 { revision 2016-07-29 {
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-04 with to draft-ietf-i2rs-yang-network-topo-05 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-04"; "draft-ietf-i2rs-yang-network-topo-05";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The precise structure of the link-id The precise structure of the link-id
will be up to the implementation. will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
skipping to change at page 26, line 4 skipping to change at page 26, line 4
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; require-instance false;
} }
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; require-instance false;
} }
description description
skipping to change at page 26, line 28 skipping to change at page 26, line 27
} }
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; require-instance false;
} }
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; require-instance false;
} }
skipping to change at page 29, line 13 skipping to change at page 29, line 13
by itself does not create any security implications. by itself does not create any security implications.
6. Contributors 6. Contributors
The model presented in this paper was contributed to by more people The model presented in this paper was contributed to by more people
than can be listed on the author list. Additional contributors than can be listed on the author list. Additional contributors
include: include:
o Ken Gray, Cisco Systems o Ken Gray, Cisco Systems
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, Vishnu 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, Kent Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent
Watsen, and Xian Zhang. Watsen, and Xian Zhang.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I.D.draft-ietf-netmod-rfc6020bis]
Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D
draft-ietf-netmod-rfc6020bis-14, June 2016.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990. Dual Environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
skipping to change at page 30, line 23 skipping to change at page 30, line 23
[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-03, June 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]
Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D
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 30, line 44
Jan Medved Jan Medved
Cisco Cisco
EMail: jmedved@cisco.com EMail: jmedved@cisco.com
Robert Varga Robert Varga
Cisco Cisco
EMail: rovarga@cisco.com EMail: rovarga@cisco.com
Tony Tkacik
Cisco
EMail: ttkacik@cisco.com Tony Tkacik
EMail: tony.tkacik@gmail.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: hari@packetdesign.com EMail: hari@packetdesign.com
 End of changes. 36 change blocks. 
53 lines changed or deleted 51 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/