draft-ietf-i2rs-yang-network-topo-02.txt   draft-ietf-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: Standards Track R. Varga Intended status: Standards Track R. Varga
Expires: June 10, 2016 T. Tkacik Expires: December 11, 2016 T. Tkacik
Cisco Cisco
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
December 8, 2015 X. Liu
Kuatro Technologies
June 9, 2016
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-02.txt draft-ietf-i2rs-yang-network-topo-03.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 39 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 June 10, 2016. This Internet-Draft will expire on December 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
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 43 skipping to change at page 2, line 45
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. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. Supporting client as well as server provided network 3.5.1. Supporting client as well as server provided network
topology . . . . . . . . . . . . . . . . . . . . . . 16 topology . . . . . . . . . . . . . . . . . . . . . . 16
3.5.2. Identifiers of string or URI type . . . . . . . . . . 16 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 21 4.2. Creating Abstract Network Topology: network-topology.yang 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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
information to describe topology information. Specifically, it adds information to describe topology information. Specifically, it adds
skipping to change at page 8, line 16 skipping to change at page 8, line 16
+--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] | +--rw supporting-network* [network-ref]
| | +--rw network-ref -> /networks/network/network-id | | +--rw network-ref -> /networks/network/network-id
| +--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 -> ../../../supporting-network/+ | +--rw network-ref -> ../../../supporting-network/+
| | network-ref | | network-ref
| +--rw node-ref -> /networks/network/node/node-id | +--rw node-ref -> /networks/network/node/node-id
+--ro networks-state +--ro networks-state
+--ro network* [network-ref] +--ro network* [network-ref]
+--ro network-ref -> /networks/network/network-id +--ro network-ref -> /networks/network/network-id
+--ro server-provided? boolean +--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, and a
container with a list of network state. container with a list of network state.
skipping to change at page 10, line 33 skipping to change at page 10, line 33
+--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[nd:network-id=+ +--rw link-ref -> /nd:networks/network[nd:network-id=+
current()/../network-ref]/link/link-id current()/../network-ref]/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
Figure 5: The structure of the abstract (base) network topology model Figure 5: The structure of the abstract (base) network topology model
A node has a list of termination points that are used to terminate A node has a list of termination points that are used to terminate
links. An example of a termination point might be a physical or links. An example of a termination point might be a physical or
logical port or, more generally, an interface. logical port or, more generally, an interface.
Like a node, a termination point can in turn be supported by an Like a node, a termination point can in turn be supported by an
underlying termination point, contained in the supporting node of the underlying termination point, contained in the supporting node of the
underlay network. underlay network.
skipping to change at page 16, line 19 skipping to change at page 16, line 19
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 that indicates for
each network whether it is populated by the server or by a client each network whether it is populated by the server or by a client
application. (The drawback of this solution is that it stretches its application. The drawback of this solution is that it stretches its
use of the configuration concept. Configuration information is use of the configuration concept. Configuration information in
subject to backup and restore, which is not applicable to server- general is subject to backup and restore, which is not applicable to
provided information. Perhaps more serious is the ability of a server-provided information. Perhaps more serious is the ability of
client to lock a configuration and thus prevent changes to server- a client to lock a configuration and thus prevent changes to server-
provided network topology while the lock is in effect. Preventing provided network topology while the lock is in effect. Preventing
this requires special treatment of network topology related this requires special treatment of network topology related
configuration information.) configuration information.
In another alternative, all information about network topology that In another alternative, all information about network topology that
is in effect is represented as network state, i.e. as read-only is in effect is represented as network state, i.e. as read-only
information, regardless of how it came into being. For cases where information, regardless of how it came into being. For cases where
network topology needs to be configured, a second branch for network topology needs to be configured, a second branch for
configurable topology information is introduced. Any network configurable topology information is introduced. Any network
topology configuration is mirrored by network state information. A topology configuration is mirrored by network state information. A
configurable network will thus be represented twice: once in the configurable network will thus be represented twice: once in the
read-only list of all networks, a second time in a configuration read-only list of all networks, a second time in a configuration
sandbox. (The drawback of this solution is slightly increased sandbox. The drawback of this solution is increased complexity of
complexity of augmentations due to two target branches. augmentations due to two target branches.
A third alternative would make use of YANG metadata
[I-D.draft-ietf-netmod-yang-metadata]. Topology information
represents configuration data. In addition, a new metadata tag is
introduced to be able to tag data populated by the server as server-
provided. This could be a boolean, or even a type "empty". The
semantics of the tag is that it is applied to any topology data that
comes into being (respectively is configured) by an embedded
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.5.2. 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
skipping to change at page 17, line 15 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@2015-12-08.yang" <CODE BEGINS> file "ietf-network@2016-06-09.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
"IETF I2RS (Interface to the Routing System) Working Group"; "IETF I2RS (Interface to the Routing System) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares WG Chair: Susan Hares
<mailto:shares@ndzh.com> <mailto:shares@ndzh.com>
WG Chair: Jeffrey Haas WG Chair: Russ White
<mailto:jhaas@pfrc.org> <mailto:russ@riw.us>
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:ttkacik@cisco.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
<mailto:xliu@kuatrotech.com>";
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 are further used of nodes in a network. Node definitions are further used
in network topologies and inventories. in network topologies and inventories.
Copyright (c) 2015 IETF Trust and the persons identified as Copyright (c) 2016 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-02; draft-ietf-i2rs-yang-network-topo-03;
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-02 with RFC draft-ietf-i2rs-yang-network-topo-03 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2015-12-08 { revision 2016-06-09 {
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-02 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-03";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node."; "Identifier for a node.";
} }
typedef network-id { typedef network-id {
type inet:uri; type inet:uri;
skipping to change at page 21, line 37 skipping to change at page 22, line 4
leaf server-provided { leaf server-provided {
type boolean; type boolean;
description description
"Indicates whether the information concerning this "Indicates whether the information concerning this
particular network is populated by the server particular network is populated by the server
(server-provided true, the general case for network (server-provided true, the general case for network
information discovered from the server), information discovered from the server),
or whether it is configured by a client or whether it is configured by a client
(server-provided true, possible e.g. for (server-provided true, possible e.g. for
service overlays managed through a controller)."; 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@2015-12-08.yang" <CODE BEGINS> file "ietf-network-topology@2016-06-09.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 22, line 20 skipping to change at page 22, line 37
organization organization
"IETF I2RS (Interface to the Routing System) Working Group"; "IETF I2RS (Interface to the Routing System) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares WG Chair: Susan Hares
<mailto:shares@ndzh.com> <mailto:shares@ndzh.com>
WG Chair: Jeffrey Haas WG Chair: Russ White
<mailto:jhaas@pfrc.org> <mailto:russ@riw.us>
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:ttkacik@cisco.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
<mailto:xliu@kuatrotech.com>";
description description
"This module defines a common base model for network topology, "This module defines a common base model for network topology,
augmenting the base network model with links to connect nodes, augmenting the base network model with links to connect nodes,
as well as termination points to terminate links on nodes. as well as termination points to terminate links on nodes.
Copyright (c) 2015 IETF Trust and the persons identified as Copyright (c) 2016 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-02; draft-ietf-i2rs-yang-network-topo-03;
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-02 with RFC draft-ietf-i2rs-yang-network-topo-03 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2015-12-08 { revision 2016-06-09 {
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-02 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-02.";
} }
typedef link-id { typedef link-id {
skipping to change at page 29, line 22 skipping to change at page 29, line 43
[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.
[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., and A. Gonzalez Prieto, "Subscribing Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
to YANG datastore push updates", I-D draft-ietf-netconf- and E. Nilsen-Nygaard, "Subscribing to YANG datastore push
yang-push-00, October 2015. updates", I-D draft-ietf-netconf-yang-push-02, March 2016.
[I-D.draft-ietf-netmod-yang-metadata]
Lhotka, L., "Defining and Using Metadata with YANG", I-D
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-08, October 2015. draft-ietf-netmod-rfc6020bis-12, April 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 line 1382 skipping to change at page 31, line 4
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
Kuatro Technologies
EMail: xliu@kuatrotech.com
 End of changes. 34 change blocks. 
45 lines changed or deleted 69 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/