rfc8345.txt		test8345.v2v3.txt
	skipping to change at page 2, line 12 ¶		skipping to change at line 46 ¶
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc8345.		https://www.rfc-editor.org/info/rfc8345.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction ....................................................4		1. Introduction
	2. Key Words .......................................................8		2. Key Words
	3. Definitions and Abbreviations ...................................9		3. Definitions and Abbreviations
	4. Model Structure Details .........................................9		4. Model Structure Details
	4.1. Base Network Model .........................................9		4.1. Base Network Model
	4.2. Base Network Topology Data Model ..........................12		4.2. Base Network Topology Data Model
	4.3. Extending the Data Model ..................................13		4.3. Extending the Data Model
	4.4. Discussion and Selected Design Decisions ..................14		4.4. Discussion and Selected Design Decisions
	4.4.1. Container Structure ................................14		4.4.1. Container Structure
	4.4.2. Underlay Hierarchies and Mappings ..................14		4.4.2. Underlay Hierarchies and Mappings
	4.4.3. Dealing with Changes in Underlay Networks ..........15		4.4.3. Dealing with Changes in Underlay Networks
	4.4.4. Use of Groupings ...................................15		4.4.4. Use of Groupings
	4.4.5. Cardinality and Directionality of Links ............16		4.4.5. Cardinality and Directionality of Links
	4.4.6. Multihoming and Link Aggregation ...................16		4.4.6. Multihoming and Link Aggregation
	4.4.7. Mapping Redundancy .................................16		4.4.7. Mapping Redundancy
	4.4.8. Typing .............................................17		4.4.8. Typing
	4.4.9. Representing the Same Device in Multiple Networks ..17		4.4.9. Representing the Same Device in Multiple
	4.4.10. Supporting Client-Configured and		Networks
	System-Controlled Network Topologies ..............18		4.4.10. Supporting Client-Configured and System-
	4.4.11. Identifiers of String or URI Type .................19		Controlled Network Topologies
	5. Interactions with Other YANG Modules ...........................19		4.4.11. Identifiers of String or URI Type
	6. YANG Modules ...................................................20		5. Interactions with Other YANG Modules
	6.1. Defining the Abstract Network: ietf-network ...............20		6. YANG Modules
	6.2. Creating Abstract Network Topology:		6.1. Defining the Abstract Network: ietf-network
	ietf-network-topology .....................................25		6.2. Creating Abstract Network Topology:
	7. IANA Considerations ............................................32		ietf-network-topology
	8. Security Considerations ........................................33		7. IANA Considerations
	9. References .....................................................35		8. Security Considerations
	9.1. Normative References ......................................35		9. References
	9.2. Informative References ....................................36		9.1. Normative References
	Appendix A. Model Use Cases .......................................38		9.2. Informative References
	A.1. Fetching Topology from a Network Element ...................38		Appendix A. Model Use Cases
	A.2. Modifying TE Topology Imported from an Optical Controller ..38		A.1. Fetching Topology from a Network Element
	A.3. Annotating Topology for Local Computation ..................39		A.2. Modifying TE Topology Imported from an Optical
	A.4. SDN Controller-Based Configuration of Overlays on Top of		Controller
	Underlays ..................................................39		A.3. Annotating Topology for Local Computation
	Appendix B. Companion YANG Data Models for Implementations Not		A.4. SDN Controller-Based Configuration of Overlays on Top
	Compliant with NMDA ...................................39		of Underlays
	B.1. YANG Module for Network State ..............................40		Appendix B. Companion YANG Data Models for Implementations Not
	B.2. YANG Module for Network Topology State .....................45		Compliant with NMDA
	Appendix C. An Example ............................................52		B.1. YANG Module for Network State
	Acknowledgments ...................................................56		B.2. YANG Module for Network Topology State
	Contributors ......................................................56		Appendix C. An Example
	Authors' Addresses ................................................57		Acknowledgments
			Contributors
			Authors' Addresses
	1. Introduction		1. Introduction
	This document introduces an abstract (base) YANG [RFC7950] data model		This document introduces an abstract (base) YANG [RFC7950] data model
	[RFC3444] to represent networks and topologies. The data model is		[RFC3444] to represent networks and topologies. The data model is
	divided into two parts: The first part of the data model defines a		divided into two parts: The first part of the data model defines a
	network data model that enables the definition of network		network data model that enables the definition of network
	hierarchies, or network stacks (i.e., networks that are layered on		hierarchies, or network stacks (i.e., networks that are layered on
	top of each other) and maintenance of an inventory of nodes contained		top of each other) and maintenance of an inventory of nodes contained
	in a network. The second part of the data model augments the basic		in a network. The second part of the data model augments the basic
	skipping to change at page 5, line 36 ¶		skipping to change at line 183 ¶
	|		|
	+-------------+-------------+-------------+		+-------------+-------------+-------------+
	| | | |		| | | |
	V V V V		V V V V
	............ ............ ............ ............		............ ............ ............ ............
	: L1 : : L2 : : L3 : : Service :		: L1 : : L2 : : L3 : : Service :
	: Topology : : Topology : : Topology : : Topology :		: Topology : : Topology : : Topology : : Topology :
	: Model : : Model : : Model : : Model :		: Model : : Model : : Model : : Model :
	'''''''''''' '''''''''''' '''''''''''' ''''''''''''		'''''''''''' '''''''''''' '''''''''''' ''''''''''''
	Figure 1: The Network Data Model Structure		Figure 1: The Network Data Model Structure
	The network-topology YANG module introduced in this document,		The network-topology YANG module introduced in this document,
	entitled "ietf-network-topology" (Section 6.2), defines a generic		entitled "ietf-network-topology" (Section 6.2), defines a generic
	topology data model at its most general level of abstraction. The		topology data model at its most general level of abstraction. The
	module defines a topology graph and components from which it is		module defines a topology graph and components from which it is
	composed: nodes, edges, and termination points. Nodes (from the		composed: nodes, edges, and termination points. Nodes (from the
	"ietf-network" module) represent graph vertices and links represent		"ietf-network" module) represent graph vertices and links represent
	graph edges. Nodes also contain termination points that anchor the		graph edges. Nodes also contain termination points that anchor the
	links. A network can contain multiple topologies -- for example,		links. A network can contain multiple topologies -- for example,
	topologies at different layers and overlay topologies. The data		topologies at different layers and overlay topologies. The data
	skipping to change at page 6, line 32 ¶		skipping to change at line 225 ¶
	* * *		* * *
	+--------*----------*----*--------------+		+--------*----------*----*--------------+
	/ [Z1]_______________[Z2] "Optical" /		/ [Z1]_______________[Z2] "Optical" /
	/ \_ * _/ /		/ \_ * _/ /
	/ \_ * _/ /		/ \_ * _/ /
	/ \_ * _/ /		/ \_ * _/ /
	/ \ * / /		/ \ * / /
	/ [Z] /		/ [Z] /
	+---------------------------------------+		+---------------------------------------+
	Figure 2: Topology Hierarchy (Stack) Example		Figure 2: Topology Hierarchy (Stack) Example
	Figure 2 shows three topology levels. At the top, the "Service"		Figure 2 shows three topology levels. At the top, the "Service"
	topology shows relationships between service entities, such as		topology shows relationships between service entities, such as
	service functions in a service chain. The "L3" topology shows		service functions in a service chain. The "L3" topology shows
	network elements at Layer 3 (IP), and the "Optical" topology shows		network elements at Layer 3 (IP), and the "Optical" topology shows
	network elements at Layer 1. Service functions in the "Service"		network elements at Layer 1. Service functions in the "Service"
	topology are mapped onto network elements in the "L3" topology, which		topology are mapped onto network elements in the "L3" topology, which
	in turn are mapped onto network elements in the "Optical" topology.		in turn are mapped onto network elements in the "Optical" topology.
	Two service functions (X1 and X3) are mapped onto a single L3 network		Two service functions (X1 and X3) are mapped onto a single L3 network
	element (Y2); this could happen, for example, if two service		element (Y2); this could happen, for example, if two service
	skipping to change at page 7, line 30 ¶		skipping to change at line 268 ¶
	: / \_ : _____/ / : /		: / \_ : _____/ / : /
	/: / \: / / : /		/: / \: / / : /
	/ : / [X5] / : /		/ : / [X5] / : /
	/ : / __/ \__ / : /		/ : / __/ \__ / : /
	/ : / ___/ \__ / : /		/ : / ___/ \__ / : /
	/ : / ___/ \ / : /		/ : / ___/ \ / : /
	/ [X4]__________________[X3]..: /		/ [X4]__________________[X3]..: /
	+------------------------------------------+		+------------------------------------------+
	L3 Topology		L3 Topology
	Figure 3: Topology Hierarchy (Stack) Example		Figure 3: Topology Hierarchy (Stack) Example
	Figure 3 shows two VPN service topologies (VPN1 and VPN2)		Figure 3 shows two VPN service topologies (VPN1 and VPN2)
	instantiated over a common L3 topology. Each VPN service topology is		instantiated over a common L3 topology. Each VPN service topology is
	mapped onto a subset of nodes from the common L3 topology.		mapped onto a subset of nodes from the common L3 topology.
	There are multiple applications for such a data model. For example,		There are multiple applications for such a data model. For example,
	within the context of Interface to the Routing System (I2RS), nodes		within the context of Interface to the Routing System (I2RS), nodes
	within the network can use the data model to capture their		within the network can use the data model to capture their
	understanding of the overall network topology and expose it to a		understanding of the overall network topology and expose it to a
	network controller. A network controller can then use the		network controller. A network controller can then use the
	skipping to change at page 9, line 7 ¶		skipping to change at line 325 ¶
	2. Key Words		2. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Definitions and Abbreviations		3. Definitions and Abbreviations
	Datastore: A conceptual place to store and access information. A		Datastore: A conceptual place to store and access information. A
	datastore might be implemented, for example, using files, a		datastore might be implemented, for example, using
	database, flash memory locations, or combinations thereof. A		files, a database, flash memory locations, or
	datastore maps to an instantiated YANG data tree (definition from		combinations thereof. A datastore maps to an
	[RFC8342]).		instantiated YANG data tree (definition from
			[RFC8342]).
	Data subtree: An instantiated data node and the data nodes that are		Data subtree: An instantiated data node and the data nodes that are
	hierarchically contained within it.		hierarchically contained within it.
	IGP: Interior Gateway Protocol.		IGP: Interior Gateway Protocol.
	IS-IS: Intermediate System to Intermediate System.		IS-IS: Intermediate System to Intermediate System.
	OSPF: Open Shortest Path First (a link-state routing protocol).		OSPF: Open Shortest Path First (a link-state routing
			protocol).
	SDN: Software-Defined Networking.		SDN: Software-Defined Networking.
	URI: Uniform Resource Identifier.		URI: Uniform Resource Identifier.
	VM: Virtual Machine.		VM: Virtual Machine.
	4. Model Structure Details		4. Model Structure Details
	4.1. Base Network Model		4.1. Base Network Model
	The abstract (base) network data model is defined in the		The abstract (base) network data model is defined in the
	"ietf-network" module. Its structure is shown in Figure 4. The		"ietf-network" module. Its structure is shown in Figure 4. The
	notation syntax follows the syntax used in [RFC8340].		notation syntax follows the syntax used in [RFC8340].
	module: ietf-network		module: ietf-network
	skipping to change at page 11, line 15 ¶		skipping to change at line 429 ¶
	node), allowing for simultaneous representation of layered network		node), allowing for simultaneous representation of layered network
	topologies and service topologies, and their physical instantiation.		topologies and service topologies, and their physical instantiation.
	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 also allows for the representation of device stacks, where a		nodes also allows for the representation of device stacks, where a
	node at one level is supported by a set of nodes at an underlying		node at one level is supported by a set of nodes at an underlying
	level. For example:		level. For example:
	o a "router" node might be supported by a node representing a route		* a "router" node might be supported by a node representing a route
	processor and separate nodes for various line cards and service		processor and separate nodes for various line cards and service
	modules,		modules,
	o a virtual router might be supported or hosted on a physical device		* a virtual router might be supported or hosted on a physical device
	represented by a separate node,		represented by a separate node,
	and so on.		and so on.
	Network data of a network at a particular layer can come into being		Network data of a network at a particular layer can come into being
	in one of two ways: (1) the network data is configured by client		in one of two ways: (1) the network data is configured by client
	applications -- for example, in the case of overlay networks that are		applications -- for example, in the case of overlay networks that are
	configured by an SDN Controller application, or (2) the network data		configured by an SDN Controller application, or (2) the network data
	is automatically controlled by the system, in the case of networks		is automatically controlled by the system, in the case of networks
	that can be discovered. It is possible for a configured (overlay)		that can be discovered. It is possible for a configured (overlay)
	skipping to change at page 12, line 41 ¶		skipping to change at line 501 ¶
	+--rw tp-id tp-id		+--rw tp-id tp-id
	+--rw supporting-termination-point*		+--rw supporting-termination-point*
	[network-ref node-ref tp-ref]		[network-ref node-ref tp-ref]
	+--rw network-ref		+--rw network-ref
	| -> ../../../nw:supporting-node/network-ref		| -> ../../../nw:supporting-node/network-ref
	+--rw node-ref		+--rw node-ref
	| -> ../../../nw:supporting-node/node-ref		| -> ../../../nw:supporting-node/node-ref
	+--rw tp-ref leafref		+--rw tp-ref leafref
	Figure 5: The Structure of the Abstract (Base) Network Topology		Figure 5: The Structure of the Abstract (Base) Network Topology
	Data Model		Data 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.
	A link is identified by a link-id that uniquely identifies the link		A link is identified by a link-id that uniquely identifies the link
	skipping to change at page 18, line 28 ¶		skipping to change at line 753 ¶
	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 represent physical ports. It should be noted		and termination points represent physical ports. It should be noted
	that it is also possible to augment the data model for a physical		that it is also possible to augment the data model for a physical
	network type, defining augmentations that have nodes reference system		network type, defining augmentations that have nodes reference system
	information and termination points reference physical interfaces, in		information and termination points reference physical interfaces, in
	order to provide a bridge between network and device models.		order to provide a bridge between network and device models.
	4.4.10. Supporting Client-Configured and System-Controlled Network		4.4.10. Supporting Client-Configured and System-Controlled Network Topologies
	Topologies
	YANG requires data nodes to be designated as either configuration		YANG requires data nodes to be designated as either configuration
	data ("config true") or operational data ("config false"), but not		data ("config true") or operational data ("config false"), but not
	both, yet it is important to have all network information, including		both, yet it is important to have all network information, including
	vertical cross-network dependencies, captured in one coherent data		vertical cross-network dependencies, captured in one coherent data
	model. In most cases, network topology information about a network		model. In most cases, network topology information about a network
	is discovered; the topology is considered a property of the network		is discovered; the topology is considered a property of the network
	that is reflected in the data model. That said, certain types of		that is reflected in the data model. That said, certain types of
	topologies need to also be configurable by an application, e.g., in		topologies need to also be configurable by an application, e.g., in
	the case of overlay topologies.		the case of overlay topologies.
	skipping to change at page 34, line 10 ¶		skipping to change at line 1425 ¶
	There are a number of data nodes defined in these YANG modules that		There are a number of data nodes defined in these YANG modules that
	are writable/creatable/deletable (i.e., config true, which is the		are writable/creatable/deletable (i.e., config true, which is the
	default). These data nodes may be considered sensitive or vulnerable		default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations (e.g., edit-config)		in some network environments. Write operations (e.g., edit-config)
	to these data nodes without proper protection can have a negative		to these data nodes without proper protection can have a negative
	effect on network operations. These are the subtrees and data nodes		effect on network operations. These are the subtrees and data nodes
	and their sensitivity/vulnerability:		and their sensitivity/vulnerability:
	In the "ietf-network" module:		In the "ietf-network" module:
	o network: A malicious client could attempt to remove or add a		* network: A malicious client could attempt to remove or add a
	network in an effort to remove an overlay topology or to create an		network in an effort to remove an overlay topology or to create an
	unauthorized overlay.		unauthorized overlay.
	o supporting network: A malicious client could attempt to disrupt		* supporting network: A malicious client could attempt to disrupt
	the logical structure of the model, resulting in a lack of overall		the logical structure of the model, resulting in a lack of overall
	data integrity and making it more difficult to, for example,		data integrity and making it more difficult to, for example,
	troubleshoot problems rooted in the layering of network		troubleshoot problems rooted in the layering of network
	topologies.		topologies.
	o node: A malicious client could attempt to remove or add a node		* node: A malicious client could attempt to remove or add a node
	from the network -- for example, in order to sabotage the topology		from the network -- for example, in order to sabotage the topology
	of a network overlay.		of a network overlay.
	o supporting node: A malicious client could attempt to change the		* supporting node: A malicious client could attempt to change the
	supporting node in order to sabotage the layering of an overlay.		supporting node in order to sabotage the layering of an overlay.
	In the "ietf-network-topology" module:		In the "ietf-network-topology" module:
	o link: A malicious client could attempt to remove a link from a		* link: A malicious client could attempt to remove a link from a
	topology, add a new link, manipulate the way the link is layered		topology, add a new link, manipulate the way the link is layered
	over supporting links, or modify the source or destination of the		over supporting links, or modify the source or destination of the
	link. In each case, the structure of the topology would be		link. In each case, the structure of the topology would be
	sabotaged, and this scenario could, for example, result in an		sabotaged, and this scenario could, for example, result in an
	overlay topology that is less than optimal.		overlay topology that is less than optimal.
	o termination point: A malicious client could attempt to remove		* termination point: A malicious client could attempt to remove
	termination points from a node, add "phantom" termination points		termination points from a node, add "phantom" termination points
	to a node, or change the layering dependencies of termination		to a node, or change the layering dependencies of termination
	points, again in an effort to sabotage the integrity of a topology		points, again in an effort to sabotage the integrity of a topology
	and potentially disrupt orderly operations of an overlay.		and potentially disrupt orderly operations of an overlay.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 35, line 49 ¶		skipping to change at line 1501 ¶
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	RFC 2119 Key Words", BCP 14, RFC 8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	DOI 10.17487/RFC8174, May 2017,		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	<https://www.rfc-editor.org/info/rfc8174>.
	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
	Access Control Model", STD 91, RFC 8341,		Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018,		DOI 10.17487/RFC8341, March 2018,
	<https://www.rfc-editor.org/info/rfc8341>.		<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture		and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,		(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
	9.2. Informative References		9.2. Informative References
	[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[RFC1195] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, DOI 10.17487/RFC1195,		dual environments", RFC 1195, DOI 10.17487/RFC1195,
	December 1990, <https://www.rfc-editor.org/info/rfc1195>.		December 1990, <https://www.rfc-editor.org/info/rfc1195>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	[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, DOI 10.17487/RFC3209, December 2001,		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
	skipping to change at page 36, line 44 ¶		skipping to change at line 1544 ¶
	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,		RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.		<https://www.rfc-editor.org/info/rfc7951>.
	[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",		[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
	RFC 7952, DOI 10.17487/RFC7952, August 2016,		RFC 7952, DOI 10.17487/RFC7952, August 2016,
	<https://www.rfc-editor.org/info/rfc7952>.		<https://www.rfc-editor.org/info/rfc7952>.
	[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing		[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
	Management", RFC 8022, DOI 10.17487/RFC8022,		Management", RFC 8022, DOI 10.17487/RFC8022, November
	November 2016, <https://www.rfc-editor.org/info/rfc8022>.		2016, <https://www.rfc-editor.org/info/rfc8022>.
	[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System		[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System
	(I2RS) Ephemeral State Requirements", RFC 8242,		(I2RS) Ephemeral State Requirements", RFC 8242,
	DOI 10.17487/RFC8242, September 2017,		DOI 10.17487/RFC8242, September 2017,
	<https://www.rfc-editor.org/info/rfc8242>.		<https://www.rfc-editor.org/info/rfc8242>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	skipping to change at page 37, line 23 ¶		skipping to change at line 1570 ¶
	[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,		[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,
	Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model		Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
	for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,		for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
	March 2018, <https://www.rfc-editor.org/info/rfc8346>.		March 2018, <https://www.rfc-editor.org/info/rfc8346>.
	[USECASE-REQS]		[USECASE-REQS]
	Hares, S. and M. Chen, "Summary of I2RS Use Case		Hares, S. and M. Chen, "Summary of I2RS Use Case
	Requirements", Work in Progress, draft-ietf-i2rs-usecase-		Requirements", Work in Progress, draft-ietf-i2rs-usecase-
	reqs-summary-03, November 2016.		reqs-summary-03, November 2016.
	[YANG-Push]		[YANG-Push]Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
	Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
	Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "YANG		Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "YANG
	Datastore Subscription", Work in Progress,		Datastore Subscription", Work in Progress, draft-ietf-
	draft-ietf-netconf-yang-push-15, February 2018.		netconf-yang-push-15, February 2018.
	Appendix A. Model Use Cases		Appendix A. Model Use Cases
	A.1. Fetching Topology from a Network Element		A.1. Fetching Topology from a Network Element
	In its simplest form, topology is learned by a network element (e.g.,		In its simplest form, topology is learned by a network element (e.g.,
	a router) through its participation in peering protocols (IS-IS, BGP,		a router) through its participation in peering protocols (IS-IS, BGP,
	etc.). This learned topology can then be exported (e.g., to a		etc.). This learned topology can then be exported (e.g., to a
	Network Management System) for external utilization. Typically, any		Network Management System) for external utilization. Typically, any
	network element in a domain can be queried for its topology and be		network element in a domain can be queried for its topology and be
	skipping to change at page 39, line 26 ¶		skipping to change at line 1641 ¶
	A.4. SDN Controller-Based Configuration of Overlays on Top of Underlays		A.4. SDN Controller-Based Configuration of Overlays on Top of Underlays
	In this scenario, an SDN Controller (for example, Open Daylight)		In this scenario, an SDN Controller (for example, Open Daylight)
	maintains a view of the topology of the network that it controls		maintains a view of the topology of the network that it controls
	based on information that it discovers from the network. In		based on information that it discovers from the network. In
	addition, it provides an application in which it configures and		addition, it provides an application in which it configures and
	maintains an overlay topology.		maintains an overlay topology.
	The SDN Controller thus maintains two roles:		The SDN Controller thus maintains two roles:
	o It is a client to the network.		* It is a client to the network.
	o It is a server to its own northbound applications and clients,		* It is a server to its own northbound applications and clients,
	e.g., an Operations Support System (OSS).		e.g., an Operations Support System (OSS).
	In other words, one system's client (or controller, in this case) may		In other words, one system's client (or controller, in this case) may
	be another system's server (or managed system).		be another system's server (or managed system).
	In this scenario, the SDN Controller maintains a consolidated data		In this scenario, the SDN Controller maintains a consolidated data
	model of multiple layers of topology. This includes the lower layers		model of multiple layers of topology. This includes the lower layers
	of the network topology, built from information that is discovered		of the network topology, built from information that is discovered
	from the network. It also includes upper layers of topology overlay,		from the network. It also includes upper layers of topology overlay,
	configurable by the controller's client, i.e., the OSS. To the OSS,		configurable by the controller's client, i.e., the OSS. To the OSS,
	the lower topology layers constitute "read-only" information. The		the lower topology layers constitute "read-only" information. The
	upper topology layers need to be read-writable.		upper topology layers need to be read-writable.
	Appendix B. Companion YANG Data Models for Implementations Not		Appendix B. Companion YANG Data Models for Implementations Not Compliant with NMDA
	Compliant with NMDA
	The YANG modules defined in this document are designed to be used in		The YANG modules defined in this document are designed to be used in
	conjunction with implementations that support the Network Management		conjunction with implementations that support the Network Management
	Datastore Architecture (NMDA) as defined in [RFC8342]. In order to		Datastore Architecture (NMDA) as defined in [RFC8342]. In order to
	allow implementations to use the data model even in cases when NMDA		allow implementations to use the data model even in cases when NMDA
	is not supported, the following two companion modules --		is not supported, the following two companion modules --
	"ietf-network-state" and "ietf-network-topology-state" -- are		"ietf-network-state" and "ietf-network-topology-state" -- are
	defined; they represent the operational state of networks and network		defined; they represent the operational state of networks and network
	topologies, respectively. These modules mirror the "ietf-network"		topologies, respectively. These modules mirror the "ietf-network"
	and "ietf-network-topology" modules (defined in Sections 6.1 and 6.2		and "ietf-network-topology" modules (defined in Sections 6.1 and 6.2
	skipping to change at page 40, line 21 ¶		skipping to change at line 1684 ¶
	modules are redundant and SHOULD NOT be supported by implementations		modules are redundant and SHOULD NOT be supported by implementations
	that support NMDA; therefore, we define these modules in		that support NMDA; therefore, we define these modules in
	Appendices B.1 and B.2 (below) instead of the main body of this		Appendices B.1 and B.2 (below) instead of the main body of this
	document.		document.
	As the structure of both modules mirrors that of their underlying		As the structure of both modules mirrors that of their underlying
	modules, the YANG tree is not depicted separately.		modules, the YANG tree is not depicted separately.
	B.1. YANG Module for Network State		B.1. YANG Module for Network State
	<CODE BEGINS> file "ietf-network-state@2018-02-26.yang"		<CODE BEGINS> file "ietf-network-state@2018-02-26.yang"
			module ietf-network-state {
			yang-version 1.1;
			namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
			prefix nw-s;
	module ietf-network-state {		import ietf-network {
	yang-version 1.1;		prefix nw;
	namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";		reference
	prefix nw-s;		"RFC 8345: A YANG Data Model for Network Topologies";
			}
	import ietf-network {		organization
	prefix nw;		"IETF I2RS (Interface to the Routing System) Working Group";
	reference
	"RFC 8345: A YANG Data Model for Network Topologies";
	}
	organization		contact
	"IETF I2RS (Interface to the Routing System) Working Group";		"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
			WG List: <mailto:i2rs@ietf.org>
	contact		Editor: Alexander Clemm
	"WG Web: <https://datatracker.ietf.org/wg/i2rs/>		<mailto:ludwig@clemm.org>
	WG List: <mailto:i2rs@ietf.org>
	Editor: Alexander Clemm		Editor: Jan Medved
	<mailto:ludwig@clemm.org>		<mailto:jmedved@cisco.com>
	Editor: Jan Medved		Editor: Robert Varga
	<mailto:jmedved@cisco.com>		<mailto:robert.varga@pantheon.tech>
	Editor: Robert Varga		Editor: Nitin Bahadur
	<mailto:robert.varga@pantheon.tech>		<mailto:nitin_bahadur@yahoo.com>
	Editor: Nitin Bahadur		Editor: Hariharan Ananthakrishnan
	<mailto:nitin_bahadur@yahoo.com>		<mailto:hari@packetdesign.com>
	Editor: Hariharan Ananthakrishnan		Editor: Xufeng Liu
	<mailto:hari@packetdesign.com>		<mailto:xufeng.liu.ietf@gmail.com>";
	Editor: Xufeng Liu		description
	<mailto:xufeng.liu.ietf@gmail.com>";		"This module defines a common base data model for a collection
			of nodes in a network. Node definitions are further used
			in network topologies and inventories. It represents
			information that either (1) is learned and automatically
			populated or (2) results from applying network information
			that has been configured per the 'ietf-network' data model,
			mirroring the corresponding data nodes in this data model.
	description		The data model mirrors 'ietf-network' but contains only
	"This module defines a common base data model for a collection		read-only state data. The data model is not needed when the
	of nodes in a network. Node definitions are further used		underlying implementation infrastructure supports the Network
	in network topologies and inventories. It represents		Management Datastore Architecture (NMDA).
	information that either (1) is learned and automatically
	populated or (2) results from applying network information
	that has been configured per the 'ietf-network' data model,
	mirroring the corresponding data nodes in this data model.
	The data model mirrors 'ietf-network' but contains only		Copyright (c) 2018 IETF Trust and the persons identified as
	read-only state data. The data model is not needed when the		authors of the code. All rights reserved.
	underlying implementation infrastructure supports the Network
	Management Datastore Architecture (NMDA).
	Copyright (c) 2018 IETF Trust and the persons identified as		Redistribution and use in source and binary forms, with or
	authors of the code. All rights reserved.		without modification, is permitted pursuant to, and subject
			to the license terms contained in, the Simplified BSD License
			set forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
	Redistribution and use in source and binary forms, with or		This version of this YANG module is part of RFC 8345;
	without modification, is permitted pursuant to, and subject		see the RFC itself for full legal notices.";
	to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC 8345;		revision 2018-02-26 {
	see the RFC itself for full legal notices.";		description
			"Initial revision.";
			reference
			"RFC 8345: A YANG Data Model for Network Topologies";
			}
	revision 2018-02-26 {		grouping network-ref {
	description		description
	"Initial revision.";		"Contains the information necessary to reference a network --
	reference		for example, an underlay network.";
	"RFC 8345: A YANG Data Model for Network Topologies";		leaf network-ref {
	}		type leafref {
	grouping network-ref {		path "/nw-s:networks/nw-s:network/nw-s:network-id";
	description		require-instance false;
	"Contains the information necessary to reference a network --		}
	for example, an underlay network.";		description
	leaf network-ref {		"Used to reference a network -- for example, an underlay
	type leafref {		network.";
	path "/nw-s:networks/nw-s:network/nw-s:network-id";		}
	require-instance false;		}
	}
	description
	"Used to reference a network -- for example, an underlay
	network.";
	}
	}
	grouping node-ref {		grouping node-ref {
	description		description
	"Contains the information necessary to reference a node.";		"Contains the information necessary to reference a node.";
	leaf node-ref {		leaf node-ref {
	type leafref {		type leafref {
	path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+		path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
	"/../network-ref]/nw-s:node/nw-s:node-id";		"/../network-ref]/nw-s:node/nw-s:node-id";
	require-instance false;		require-instance false;
	}		}
	description		description
	"Used to reference a node.		"Used to reference a node.
	Nodes are identified relative to the network that		Nodes are identified relative to the network that
	contains them.";		contains them.";
	}		}
	uses network-ref;		uses network-ref;
	}		}
	container networks {
	config false;
	description
	"Serves as a top-level container for a list of networks.";
	list network {
	key "network-id";
	description
	"Describes a network.
	A network typically contains an inventory of nodes,
	topological information (augmented through the
	network-topology data model), and layering information.";
	container network-types {
	description
	"Serves as an augmentation target.
	The network type is indicated through corresponding
	presence containers augmented into this container.";
	}
	leaf network-id {
	type nw:network-id;
	description
	"Identifies a network.";
	}
	list supporting-network {
	key "network-ref";
	description
	"An underlay network, used to represent layered network
	topologies.";
	leaf network-ref {
	type leafref {
	path "/nw-s:networks/nw-s:network/nw-s:network-id";
	require-instance false;
	}
	description
	"References the underlay network.";
	}
	}
	list node {
	key "node-id";
	description
	"The inventory of nodes of this network.";
	leaf node-id {
	type nw:node-id;
	description
	"Uniquely identifies a node within the containing
	network.";
	}
	list supporting-node {
	key "network-ref node-ref";
	description
	"Represents another node that is in an underlay network
	and that supports this node. Used to represent layering
	structure.";
	leaf network-ref {
	type leafref {
	path "../../../nw-s:supporting-network/nw-s:network-ref";
	require-instance false;
	}
	description
	"References the underlay network of which the
	underlay node is a part.";
	}
	leaf node-ref {
	type leafref {
	path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
	require-instance false;
	}
	description
	"References the underlay node itself.";
	}
	}
	}
	}
	}
	}
	<CODE ENDS>		container networks {
	B.2. YANG Module for Network Topology State		config false;
			description
			"Serves as a top-level container for a list of networks.";
			list network {
			key "network-id";
			description
			"Describes a network.
			A network typically contains an inventory of nodes,
			topological information (augmented through the
			network-topology data model), and layering information.";
			container network-types {
			description
			"Serves as an augmentation target.
			The network type is indicated through corresponding
			presence containers augmented into this container.";
			}
			leaf network-id {
			type nw:network-id;
			description
			"Identifies a network.";
			}
			list supporting-network {
			key "network-ref";
			description
			"An underlay network, used to represent layered network
			topologies.";
			leaf network-ref {
			type leafref {
			path "/nw-s:networks/nw-s:network/nw-s:network-id";
			require-instance false;
			}
			description
			"References the underlay network.";
			}
			}
			list node {
			key "node-id";
			description
			"The inventory of nodes of this network.";
			leaf node-id {
			type nw:node-id;
			description
			"Uniquely identifies a node within the containing
			network.";
			}
			list supporting-node {
			key "network-ref node-ref";
			description
			"Represents another node that is in an underlay network
			and that supports this node. Used to represent layering
			structure.";
			leaf network-ref {
			type leafref {
			path "../../../nw-s:supporting-network/nw-s:network-ref";
			require-instance false;
			}
			description
			"References the underlay network of which the
			underlay node is a part.";
			}
			leaf node-ref {
			type leafref {
			path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
			require-instance false;
			}
			description
			"References the underlay node itself.";
			}
			}
			}
			}
			}
			}
			<CODE ENDS>
	<CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang"		B.2. YANG Module for Network Topology State
	module ietf-network-topology-state {		<CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang"
	yang-version 1.1;		module ietf-network-topology-state {
	namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";		yang-version 1.1;
	prefix nt-s;		namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
			prefix nt-s;
	import ietf-network-state {		import ietf-network-state {
	prefix nw-s;		prefix nw-s;
	reference		reference
	"RFC 8345: A YANG Data Model for Network Topologies";		"RFC 8345: A YANG Data Model for Network Topologies";
	}		}
	import ietf-network-topology {		import ietf-network-topology {
	prefix nt;		prefix nt;
	reference		reference
	"RFC 8345: A YANG Data Model for Network Topologies";		"RFC 8345: A YANG Data Model for Network Topologies";
	}		}
	organization		organization
	"IETF I2RS (Interface to the Routing System) Working Group";		"IETF I2RS (Interface to the Routing System) Working Group";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/wg/i2rs/>		"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
	WG List: <mailto:i2rs@ietf.org>		WG List: <mailto:i2rs@ietf.org>
	Editor: Alexander Clemm		Editor: Alexander Clemm
	<mailto:ludwig@clemm.org>		<mailto:ludwig@clemm.org>
	Editor: Jan Medved		Editor: Jan Medved
	<mailto:jmedved@cisco.com>		<mailto:jmedved@cisco.com>
	Editor: Robert Varga		Editor: Robert Varga
	<mailto:robert.varga@pantheon.tech>		<mailto:robert.varga@pantheon.tech>
	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:xufeng.liu.ietf@gmail.com>";		<mailto:xufeng.liu.ietf@gmail.com>";
	description		description
	"This module defines a common base data model for network		"This module defines a common base data model for network
	topology state, representing topology that either (1) is learned		topology state, representing topology that either (1) is learned
	or (2) results from applying topology that has been configured		or (2) results from applying topology that has been configured
	per the 'ietf-network-topology' data model, mirroring the		per the 'ietf-network-topology' data model, mirroring the
	corresponding data nodes in this data model. It augments the		corresponding data nodes in this data model. It augments the
	base network state data model with links to connect nodes, as		base network state data model with links to connect nodes, as
	well as termination points to terminate links on nodes.		well as termination points to terminate links on nodes.
	The data model mirrors 'ietf-network-topology' but contains only		The data model mirrors 'ietf-network-topology' but contains only
	read-only state data. The data model is not needed when the		read-only state data. The data model is not needed when the
	underlying implementation infrastructure supports the Network		underlying implementation infrastructure supports the Network
	Management Datastore Architecture (NMDA).		Management Datastore Architecture (NMDA).
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC 8345;		This version of this YANG module is part of RFC 8345;
	see the RFC itself for full legal notices.";		see the RFC itself for full legal notices.";
	revision 2018-02-26 {		revision 2018-02-26 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC 8345: A YANG Data Model for Network Topologies";		"RFC 8345: A YANG Data Model for Network Topologies";
	}		}
	grouping link-ref {
	description
	"References a link in a specific network. Although this
	grouping is not used in this module, it is defined here for
	the convenience of augmenting modules.";
	leaf link-ref {
	type leafref {
	path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
	"/../network-ref]/nt-s:link/nt-s:link-id";
	require-instance false;
	}
	description
	"A type for an absolute reference to a link instance.
	(This type should not be used for relative references.
	In such a case, a relative path should be used instead.)";
	}
	uses nw-s:network-ref;
	}
	grouping tp-ref {		grouping link-ref {
	description		description
	"References a termination point in a specific node. Although		"References a link in a specific network. Although this
	this grouping is not used in this module, it is defined here		grouping is not used in this module, it is defined here for
	for the convenience of augmenting modules.";		the convenience of augmenting modules.";
	leaf tp-ref {		leaf link-ref {
	type leafref {		type leafref {
	path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+		path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
	"/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+		"/../network-ref]/nt-s:link/nt-s:link-id";
	"node-ref]/nt-s:termination-point/nt-s:tp-id";		require-instance false;
	require-instance false;		}
	}		description
	description		"A type for an absolute reference to a link instance.
	"A type for an absolute reference to a termination point.		(This type should not be used for relative references.
	(This type should not be used for relative references.		In such a case, a relative path should be used instead.)";
	In such a case, a relative path should be used instead.)";		}
	}		uses nw-s:network-ref;
	uses nw-s:node-ref;		}
	}
	augment "/nw-s:networks/nw-s:network" {		grouping tp-ref {
	description		description
	"Add links to the network data model.";		"References a termination point in a specific node. Although
	list link {		this grouping is not used in this module, it is defined here
	key "link-id";		for the convenience of augmenting modules.";
	description		leaf tp-ref {
	"A network link connects a local (source) node and		type leafref {
	a remote (destination) node via a set of the respective		path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
	node's termination points. It is possible to have several		"/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
	links between the same source and destination nodes.		"node-ref]/nt-s:termination-point/nt-s:tp-id";
	Likewise, a link could potentially be re-homed between		require-instance false;
	termination points. Therefore, in order to ensure that we		}
	would always know to distinguish between links, every link		description
	is identified by a dedicated link identifier. Note that a		"A type for an absolute reference to a termination point.
	link models a point-to-point link, not a multipoint link.";		(This type should not be used for relative references.
	container source {		In such a case, a relative path should be used instead.)";
	description		}
	"This container holds the logical source of a particular		uses nw-s:node-ref;
	link.";		}
	leaf source-node {
	type leafref {
	path "../../../nw-s:node/nw-s:node-id";
	require-instance false;
	}
	description
	"Source node identifier. Must be in the same topology.";
	}
	leaf source-tp {
	type leafref {
	path "../../../nw-s:node[nw-s:node-id=current()/../"+
	"source-node]/termination-point/tp-id";
	require-instance false;
	}
	description
	"This termination point is located within the source node
	and terminates the link.";
	}
	}
	container destination {
	description
	"This container holds the logical destination of a
	particular link.";
	leaf dest-node {
	type leafref {
	path "../../../nw-s:node/nw-s:node-id";
	require-instance false;
	}
	description
	"Destination node identifier. Must be in the same
	network.";
	}
	leaf dest-tp {
	type leafref {
	path "../../../nw-s:node[nw-s:node-id=current()/../"+
	"dest-node]/termination-point/tp-id";
	require-instance false;
	}
	description
	"This termination point is located within the
	destination node and terminates the link.";
	}
	}
	leaf link-id {
	type nt:link-id;
	description
	"The identifier of a link in the topology.
	A link is specific to a topology to which it belongs.";
	}
	list supporting-link {
	key "network-ref link-ref";
	description
	"Identifies the link or links on which this link depends.";
	leaf network-ref {
	type leafref {
	path "../../../nw-s:supporting-network/nw-s:network-ref";
	require-instance false;
	}
	description
	"This leaf identifies in which underlay topology
	the supporting link is present.";
	}
	leaf link-ref {
	type leafref {
	path "/nw-s:networks/nw-s:network[nw-s:network-id="+
	"current()/../network-ref]/link/link-id";
	require-instance false;
	}
	description
	"This leaf identifies a link that is a part
	of this link's underlay. Reference loops in which
	a link identifies itself as its underlay, either
	directly or transitively, are not allowed.";
	}
	}
	}
	}
	augment "/nw-s:networks/nw-s:network/nw-s:node" {
	description
	"Augments termination points that terminate links.
	Termination points can ultimately be mapped to interfaces.";
	list termination-point {
	key "tp-id";
	description
	"A termination point can terminate a link.
	Depending on the type of topology, a termination point
	could, for example, refer to a port or an interface.";
	leaf tp-id {
	type nt:tp-id;
	description
	"Termination point identifier.";
	}
	list supporting-termination-point {
	key "network-ref node-ref tp-ref";
	description
	"This list identifies any termination points on which a
	given termination point depends or onto which it maps.
	Those termination points will themselves be contained
	in a supporting node. This dependency information can be
	inferred from the dependencies between links. Therefore,
	this item is not separately configurable. Hence, no
	corresponding constraint needs to be articulated.
	The corresponding information is simply provided by the
	implementing system.";
	leaf network-ref {
	type leafref {
	path "../../../nw-s:supporting-node/nw-s:network-ref";
	require-instance false;
	}
	description
	"This leaf identifies in which topology the
	supporting termination point is present.";
	}
	leaf node-ref {
	type leafref {
	path "../../../nw-s:supporting-node/nw-s:node-ref";
	require-instance false;
	}
	description
	"This leaf identifies in which node the supporting
	termination point is present.";
	}
	leaf tp-ref {
	type leafref {
	path "/nw-s:networks/nw-s:network[nw-s:network-id="+
	"current()/../network-ref]/nw-s:node[nw-s:node-id="+
	"current()/../node-ref]/termination-point/tp-id";
	require-instance false;
	}
	description
	"Reference to the underlay node (the underlay node must
	be in a different topology).";
	}
	}
	}
	}
	}
	<CODE ENDS>		augment "/nw-s:networks/nw-s:network" {
			description
			"Add links to the network data model.";
			list link {
			key "link-id";
			description
			"A network link connects a local (source) node and
			a remote (destination) node via a set of the respective
			node's termination points. It is possible to have several
			links between the same source and destination nodes.
			Likewise, a link could potentially be re-homed between
			termination points. Therefore, in order to ensure that we
			would always know to distinguish between links, every link
			is identified by a dedicated link identifier. Note that a
			link models a point-to-point link, not a multipoint link.";
			container source {
			description
			"This container holds the logical source of a particular
			link.";
			leaf source-node {
			type leafref {
			path "../../../nw-s:node/nw-s:node-id";
			require-instance false;
			}
			description
			"Source node identifier. Must be in the same topology.";
			}
			leaf source-tp {
			type leafref {
			path "../../../nw-s:node[nw-s:node-id=current()/../"+
			"source-node]/termination-point/tp-id";
			require-instance false;
			}
			description
			"This termination point is located within the source node
			and terminates the link.";
			}
			}
			container destination {
			description
			"This container holds the logical destination of a
			particular link.";
			leaf dest-node {
			type leafref {
			path "../../../nw-s:node/nw-s:node-id";
			require-instance false;
			}
			description
			"Destination node identifier. Must be in the same
			network.";
			}
			leaf dest-tp {
			type leafref {
			path "../../../nw-s:node[nw-s:node-id=current()/../"+
			"dest-node]/termination-point/tp-id";
			require-instance false;
			}
			description
			"This termination point is located within the
			destination node and terminates the link.";
			}
			}
			leaf link-id {
			type nt:link-id;
			description
			"The identifier of a link in the topology.
			A link is specific to a topology to which it belongs.";
			}
			list supporting-link {
			key "network-ref link-ref";
			description
			"Identifies the link or links on which this link depends.";
			leaf network-ref {
			type leafref {
			path "../../../nw-s:supporting-network/nw-s:network-ref";
			require-instance false;
			}
			description
			"This leaf identifies in which underlay topology
			the supporting link is present.";
			}
			leaf link-ref {
			type leafref {
			path "/nw-s:networks/nw-s:network[nw-s:network-id="+
			"current()/../network-ref]/link/link-id";
			require-instance false;
			}
			description
			"This leaf identifies a link that is a part
			of this link's underlay. Reference loops in which
			a link identifies itself as its underlay, either
			directly or transitively, are not allowed.";
			}
			}
			}
			}
			augment "/nw-s:networks/nw-s:network/nw-s:node" {
			description
			"Augments termination points that terminate links.
			Termination points can ultimately be mapped to interfaces.";
			list termination-point {
			key "tp-id";
			description
			"A termination point can terminate a link.
			Depending on the type of topology, a termination point
			could, for example, refer to a port or an interface.";
			leaf tp-id {
			type nt:tp-id;
			description
			"Termination point identifier.";
			}
			list supporting-termination-point {
			key "network-ref node-ref tp-ref";
			description
			"This list identifies any termination points on which a
			given termination point depends or onto which it maps.
			Those termination points will themselves be contained
			in a supporting node. This dependency information can be
			inferred from the dependencies between links. Therefore,
			this item is not separately configurable. Hence, no
			corresponding constraint needs to be articulated.
			The corresponding information is simply provided by the
			implementing system.";
			leaf network-ref {
			type leafref {
			path "../../../nw-s:supporting-node/nw-s:network-ref";
			require-instance false;
			}
			description
			"This leaf identifies in which topology the
			supporting termination point is present.";
			}
			leaf node-ref {
			type leafref {
			path "../../../nw-s:supporting-node/nw-s:node-ref";
			require-instance false;
			}
			description
			"This leaf identifies in which node the supporting
			termination point is present.";
			}
			leaf tp-ref {
			type leafref {
			path "/nw-s:networks/nw-s:network[nw-s:network-id="+
			"current()/../network-ref]/nw-s:node[nw-s:node-id="+
			"current()/../node-ref]/termination-point/tp-id";
			require-instance false;
			}
			description
			"Reference to the underlay node (the underlay node must
			be in a different topology).";
			}
			}
			}
			}
			}
			<CODE ENDS>
	Appendix C. An Example		Appendix C. An Example
	This section contains an example of an instance data tree in JSON		This section contains an example of an instance data tree in JSON
	encoding [RFC7951]. The example instantiates "ietf-network-topology"		encoding [RFC7951]. The example instantiates "ietf-network-topology"
	(and "ietf-network", which "ietf-network-topology" augments) for the		(and "ietf-network", which "ietf-network-topology" augments) for the
	topology depicted in Figure 7. There are three nodes: D1, D2, and		topology depicted in Figure 7. There are three nodes: D1, D2, and
	D3. D1 has three termination points (1-0-1, 1-2-1, and 1-3-1).		D3. D1 has three termination points (1-0-1, 1-2-1, and 1-3-1).
	D2 has three termination points as well (2-1-1, 2-0-1, and 2-3-1).		D2 has three termination points as well (2-1-1, 2-0-1, and 2-3-1).
	D3 has two termination points (3-1-1 and 3-2-1). In addition, there		D3 has two termination points (3-1-1 and 3-2-1). In addition, there
	skipping to change at page 52, line 38 ¶		skipping to change at line 2171 ¶
	| | | |		| | | |
	| | +------------+ | |		| | +------------+ | |
	| | | D3 | | |		| | | D3 | | |
	| | /-\ /-\ | |		| | /-\ /-\ | |
	| +----->| | 3-1-1 | |-------+ |		| +----->| | 3-1-1 | |-------+ |
	+---------| | 3-2-1 | |<---------+		+---------| | 3-2-1 | |<---------+
	\-/ \-/		\-/ \-/
	| |		| |
	+------------+		+------------+
	Figure 7: A Network Topology Example		Figure 7: A Network Topology Example
	The corresponding instance data tree is depicted in Figure 8:		The corresponding instance data tree is depicted in Figure 8:
	{		{
	"ietf-network:networks": {		"ietf-network:networks": {
	"network": [		"network": [
	{		{
	"network-types": {		"network-types": {
	},		},
	"network-id": "otn-hc",		"network-id": "otn-hc",
	skipping to change at page 55, line 43 ¶		skipping to change at line 2296 ¶
	"dest-node": "D2",		"dest-node": "D2",
	"dest-tp": "2-3-1"		"dest-tp": "2-3-1"
	}		}
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 8: Instance Data Tree		Figure 8: Instance Data Tree
	Acknowledgments		Acknowledgments
	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, Andy Bierman, Martin		suggestions that were received from Alia Atlas, Andy Bierman, Martin
	Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka,		Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka,
	Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, Qin Wu, and		Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, Qin Wu, and
	Xian Zhang.		Xian Zhang.
	Contributors		Contributors
	More people contributed to the data model presented in this paper		More people contributed to the data model presented in this paper
	than can be listed in the "Authors' Addresses" section. Additional		than can be listed in the "Authors' Addresses" section. Additional
	contributors include:		contributors include:
	o Vishnu Pavan Beeram, Juniper		* Vishnu Pavan Beeram, Juniper
	o Ken Gray, Cisco		* Ken Gray, Cisco
	o Tom Nadeau, Brocade		* Tom Nadeau, Brocade
	o Tony Tkacik		* Tony Tkacik
	o Kent Watsen, Juniper		* Kent Watsen, Juniper
	o Aleksandr Zhdankin, Cisco		* Aleksandr Zhdankin, Cisco
	Authors' Addresses		Authors' Addresses
	Alexander Clemm		Alexander Clemm
	Huawei USA - Futurewei Technologies Inc.		Huawei USA - Futurewei Technologies Inc.
	Santa Clara, CA		Santa Clara, CA
	United States of America		United States of America
	Email: ludwig@clemm.org, alexander.clemm@huawei.com		Email: ludwig@clemm.org, alexander.clemm@huawei.com
	Jan Medved
	Cisco
	Email: jmedved@cisco.com		Email: jmedved@cisco.com
	Robert Varga
	Pantheon Technologies SRO
	Email: robert.varga@pantheon.tech		Email: robert.varga@pantheon.tech
	Nitin Bahadur
	Bracket Computing
	Email: nitin_bahadur@yahoo.com		Email: nitin_bahadur@yahoo.com
	Hariharan Ananthakrishnan
	Packet Design
	Email: hari@packetdesign.com		Email: hari@packetdesign.com
	Xufeng Liu
	Jabil
	Email: xufeng.liu.ietf@gmail.com		Email: xufeng.liu.ietf@gmail.com
End of changes. 83 change blocks.
	524 lines changed or deleted		509 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/

mirror server hosted at Truenetwork, Russian Federation.