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/