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/