draft-ietf-teas-actn-vn-yang-04.txt		draft-ietf-teas-actn-vn-yang-05.txt
	TEAS Working Group Y. Lee (Editor)		TEAS Working Group Y. Lee (Editor)
	Internet Draft Dhruv Dhody (Editor)		Internet Draft Futurewei
	Intended Status: Standard Track Huawei		Intended Status: Standard Track
	Expires: August 3, 2019 D. Ceccarelli		Expires: December 13, 2019 D. Dhody (Editor)
	Ericsson
	Igor Bryskin
	Huawei		Huawei
	Bin Yeong Yoon
			D. Ceccarelli
			Ericsson
			I. Bryskin
			Futurewei
			B. Yoon
	ETRI		ETRI
	Qin Wu
	Huawei
	Peter Park
	KT
	February 4, 2019		June 13, 2019
	A Yang Data Model for VN Operation		A Yang Data Model for VN Operation
	draft-ietf-teas-actn-vn-yang-04		draft-ietf-teas-actn-vn-yang-05
	Abstract		Abstract
	This document provides a YANG data model generally applicable to any		This document provides a YANG data model generally applicable to any
	mode of Virtual Network (VN) operation.		mode of Virtual Network (VN) operation.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.		the provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on August 3, 2019.		This Internet-Draft will expire on December 13, 2019.
	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
	(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 32 ¶		skipping to change at page 2, line 32 ¶
	Introduction.....................................................3		Introduction.....................................................3
	1.................................................................3		1.................................................................3
	1.1. Terminology...............................................4		1.1. Terminology...............................................4
	1.2. Tree diagram..............................................4		1.2. Tree diagram..............................................4
	1.3. Prefixes in Data Node Names...............................4		1.3. Prefixes in Data Node Names...............................4
	2. Use-case of VN Yang Model in the ACTN context..................5		2. Use-case of VN Yang Model in the ACTN context..................5
	2.1. Type 1 VN.................................................5		2.1. Type 1 VN.................................................5
	2.2. Type 2 VN.................................................6		2.2. Type 2 VN.................................................6
	3. High-Level Control Flows with Examples.........................7		3. High-Level Control Flows with Examples.........................7
	3.1. Type 1 VN Illustration....................................7		3.1. Type 1 VN Illustration....................................7
	3.2. Type 2 VN Illustration....................................8		3.2. Type 2 VN Illustration....................................9
	4. VN Model Usage................................................11		4. VN Model Usage................................................12
	4.1. Customer view of VN......................................11		4.1. Customer view of VN......................................12
	4.2. Auto-creation of VN by MDSC..............................11		4.2. Auto-creation of VN by MDSC..............................12
	4.3. Innovative Services......................................11		4.3. Innovative Services......................................12
	4.3.1. VN Compute..........................................11		4.3.1. VN Compute..........................................12
	4.3.2. Multi-sources and Multi-destinations................12		4.3.2. Multi-sources and Multi-destinations................12
	4.3.3. Others..............................................12		4.3.3. Others..............................................13
	4.3.4. Summary.............................................13		4.3.4. Summary.............................................14
	5. VN YANG Model (Tree Structure)................................13		5. VN YANG Model (Tree Structure)................................14
	6. VN YANG Code..................................................15		6. VN YANG Code..................................................16
	7. JSON Example..................................................27		7. JSON Example..................................................29
	7.1. VN JSON..................................................28		7.1. VN JSON..................................................30
	7.2. TE-topology JSON.........................................33		7.2. TE-topology JSON.........................................35
	8. Security Considerations.......................................49		8. Security Considerations.......................................51
	9. IANA Considerations...........................................51		9. IANA Considerations...........................................52
	10. Acknowledgments..............................................51		10. Acknowledgments..............................................53
	11. References...................................................52		11. References...................................................54
	11.1. Normative References....................................52		11.1. Normative References....................................54
	11.2. Informative References..................................52		11.2. Informative References..................................54
	12. Contributors.................................................53		12. Contributors.................................................55
	Authors' Addresses...............................................53		Authors' Addresses...............................................55
	1. Introduction		1. Introduction
	This document provides a YANG data model generally applicable to any		This document provides a YANG data model generally applicable to any
	mode of Virtual Network (VN) operation.		mode of Virtual Network (VN) operation.
	The VN model defined in this document is applicable in generic sense		The VN model defined in this document is applicable in generic sense
	as an independent model in and of itself. The VN model defined in		as an independent model in and of itself. The VN model defined in
	this document can also work together with other customer service		this document can also work together with other customer service
	models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to		models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	|		|
	+-----------------------+		+-----------------------+
	| MDSC |		| MDSC |
	+-----------------------+		+-----------------------+
	Figure 1. ACTN CMI		Figure 1. ACTN CMI
	Both ACTN VN YANG and TE-topology models are used over the CMI to		Both ACTN VN YANG and TE-topology models are used over the CMI to
	establish a VN over TE networks.		establish a VN over TE networks.
			In the context of 5G transport application, 5G Traffic Provisioning
			Manager (TPM) that provides slicing requirements to the transport
			networks (i.e., MDSC) can be considered as a type of CNC. The ACTN
			CMI provides the necessary interface functions between 5G and
			transport networks in order to facilitate dynamic VN creation and
			its lifecycle management with proper feedback loop for monitoring.
	2.1. Type 1 VN		2.1. Type 1 VN
	As defined in [RFC8453], a Virtual Network is a customer view of the		As defined in [RFC8453], a Virtual Network is a customer view of the
	TE network. To recapitulate VN types from [RFC8453], Type 1 VN is		TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
	defined as follows:		defined as follows:
	The VN can be seen as a set of edge-to-edge abstract links (a Type 1		The VN can be seen as a set of edge-to-edge abstract links (a Type 1
	VN). Each abstract link is referred to as a VN member and is formed		VN). Each abstract link is referred to as a VN member and is formed
	as an end-to-end tunnel across the underlying networks. Such tunnels		as an end-to-end tunnel across the underlying networks. Such tunnels
	may be constructed by recursive slicing or abstraction of paths in		may be constructed by recursive slicing or abstraction of paths in
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 21 ¶
	+---------------+		+---------------+
	L1 ------| |------ L4		L1 ------| |------ L4
	L2 ------| AN 1 |------ L7		L2 ------| AN 1 |------ L7
	L3 ------| |------ L8		L3 ------| |------ L8
	+---------------+		+---------------+
	If this VN is Type 1, the following diagram shows the message flow		If this VN is Type 1, the following diagram shows the message flow
	between CNC and MDSC to instantiate this VN using VN and TE-Topology		between CNC and MDSC to instantiate this VN using VN and TE-Topology
	Models.		Models.
	+--------+ +--------+		+--------+ +--------+
	| CNC | | MDSC |		| CNC | | MDSC |
	+--------+ +--------+		+--------+ +--------+
	| |		| |
	| |		| |
	CNC POST TE-topo | POST /nw:networks/nw:network/ |		CNC POST TE-topo | POST /nw:networks/nw:network/ |
	model(with Conn. | nw:node/te-node-id/tet:connectivity- |		model(with Conn. | nw:node/te-node-id/ |
	Matrix on one | matrices/tet:connectivity-matrix |		| tet:connectivity-matrices/ |
	Abstract node |---------------------------------------->|		Matrix on one | tet:connectivity-matrix |
	| HTTP 200 |		Abstract node |-------------------------------->|
	|<----------------------------------------|		| HTTP 200 |
	| |		|<--------------------------------|
	CNC POST the | POST /VN |		| |
	VN identifying |---------------------------------------->| If there is		CNC POST the | POST /VN |
	AP, VNAP and VN- | | multi-dest'n		VN identifying |-------------------------------->| If there is
	Members and maps | | module, then		AP, VNAP and VN- | | multi-dest'n
	to the TE-topo | HTTP 200 | MDSC selects a		Members and maps | | module, then
	|<----------------------------------------| src or dest'n		to the TE-topo | HTTP 200 | MDSC selects a
	| | and update		|<--------------------------------| src or dest'n
	| | VN YANG		| | and update
	CNC GET the | GET /VN |		| | VN YANG
	VN YANG status |---------------------------------------->|		CNC GET the | GET /VN |
	| |		VN YANG status |-------------------------------->|
	| HTTP 200 (VN with status: selected |		| |
	| VN-members in case of multi s-d |		| HTTP 200 (VN with status: |
	|<----------------------------------------|		| selected VN-members |
			| in case of multi s-d) |
			|<--------------------------------|
	| |		| |
	3.2. Type 2 VN Illustration		3.2. Type 2 VN Illustration
	For some VN members, the customer may want to "configure" explicit		For some VN members, the customer may want to "configure" explicit
	routes over the path that connects its two end-points. Let us		routes over the path that connects its two end-points. Let us
	consider the following example.		consider the following example.
	VN-Member 1 L1-L4		VN-Member 1 L1-L4 (via S3, S4, and S5)
	VN-Member 2 L1-L7 (via S4 and S7)		VN-Member 2 L1-L7 (via S3, S4, S7 and S8)
	VN-Member 3 L2-L4		VN-Member 3 L2-L7 (via S9, S10, and S11)
	VN-Member 4 L3-L8 (via S10)		VN-Member 4 L3-L8 (via S9, S10 and S11)
	Where the following topology is the underlay for Abstraction Node 1		Where the following topology is the underlay for Abstraction Node 1
	(AN1).		(AN1).
	S1 S2		AN1
	O---------------O		............................................
	________/ \______ \		. S1 S2 .
	/ \ \		. O---------------O .
	S3 / \ S4 \ S5		. ________/ \______ \ .
	L1------O----------------------O---------O------------------L4		. / \ \ .
	\ \ \		. S3/ \ S4 \ S5 .
	\ \ \		L1----.-O----------------------O---------O-------.----------L4
	\ S6 \ S7 \ S8		. \ \ \ .
	O ----------------O---------O--------------L5		. \ \ \ .
	/ \ / \ ____/ \_____________L6		. \ S6 \ S7 \ S8 .
	S9 / \ /S10 \ /		. O ----------------O---------O---.----------L5
	L2---------O-----O---------------------O---------------------L7		. / \ / \ ____/ \__.__________L6
	/ S11\____________________L8		.S9 / \ /S10 \ / .
	L3--------		L2-----.---O-----O---------------------O----------.----------L7
			. / S11\_________.__________L8
			L3-----.-- .
			............................................
	If CNC creates the single abstract topology, the following diagram		There are two options depending on whether CNC or MDSC creates the
	shows the message flow between CNC and MDSC to instantiate this VN		single abstract node topology.
	using VN and TE-Topology Model.
	+--------+ +--------+		Case 1:
			If CNC creates the single abstract node topology, the following
			diagram shows the message flow between CNC and MDSC to instantiate
			this VN using VN and TE-Topology Model.
			+--------+ +--------+
	| CNC | | MDSC |		| CNC | | MDSC |
	+--------+ +--------+		+--------+ +--------+
	| |		| |
	| |		| |
	CNC POST TE-topo | POST /nw:networks/nw:network/ |		CNC POST TE-topo | POST /nw:networks/nw:network/ |
	model(with Conn. | nw:node/te-node-id/tet:connectivity- |		model(with Conn. | nw:node/te-node-id/tet:connectivity- |
	Matrix on one | matrices/tet:connectivity-matrix |		Matrix on one | matrices/tet:connectivity-matrix |
	Abstract node and|---------------------------------------->|		Abstract node and|---------------------------------------->|
	Explicit paths in| |		Explicit paths in| |
	The conn. Matrix | HTTP 200 |		The conn. Matrix | HTTP 200 |
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 42 ¶
	|<----------------------------------------|		|<----------------------------------------|
	| |		| |
	| |		| |
	CNC GET the | GET /VN |		CNC GET the | GET /VN |
	VN YANG status |---------------------------------------->|		VN YANG status |---------------------------------------->|
	| |		| |
	| HTTP 200 (VN with status) |		| HTTP 200 (VN with status) |
	|<----------------------------------------|		|<----------------------------------------|
	| |		| |
	On the other hand, if MDSC create single node topology based VN YANG		Case 2:
	posted by the CNC, the following diagram shows the message flow
	between CNC and MDSC to instantiate this VN using VN and TE-Topology
	Models.
	+--------+ +--------+		On the other hand, if MDSC create the single abstract node topology
	| CNC | | MDSC |		based VN YANG posted by the CNC, the following diagram shows the
	+--------+ +--------+		message flow between CNC and MDSC to instantiate this VN using VN
	| |		and TE-Topology Models.
	| |
	CNC POST VN | |		+--------+ +--------+
	Identifying AP, | |		| CNC | | MDSC |
	VNAP and VN- | POST /VN | MDSC populates		+--------+ +--------+
	Members |---------------------------------------->| a single Abst.		| |
	| HTTP 200 | node topology		| |
	|<----------------------------------------| by itself		CNC POST VN | |
	| |		Identifying AP, | |
	CNC POST the | POST /VN |		VNAP and VN- | POST /VN | MDSC populates
	VN identifying |---------------------------------------->|		Members |-------------------------------->| a single Abst.
	AP, VNAP and VN- | |		| HTTP 200 | node topology
	Members and maps | |		|<--------------------------------| by itself
	to the TE-topo | HTTP 200 |		| |
	|<----------------------------------------|		CNC GET VN & | GET /VN & |
	| |		POST TE-Topo | POST /nw:networks/nw:network/ |
	| |		Models (with | nw:node/te-node-id/tet: |
	CNC GET the | GET /VN |		Conn. Matrix on | connectivity-matrices/ |
	VN YANG status |---------------------------------------->|		| tet:connectivity-matrix |
	| |		the Abstract Node|-------------------------------->|
	| HTTP 200 (VN with status) |		and explicit | |
	|<----------------------------------------|		paths in the | |
	| |		Conn. Matrix | |
			| HTTP 200 |
			|<--------------------------------|
			| |
			| |
			CNC GET the | GET /VN |
			VN YANG status |-------------------------------->|
			| |
			| HTTP 200 (VN with status) |
			|<--------------------------------|
			| |
			Section 7 provides JSON examples for both VN model and TE-topology
			Connectivity Matrix sub-model to illustrate how a VN can be created
			by the CNC making use of the VN module as well as the TE-topology
			Connectivity Matrix module.
	4. VN Model Usage		4. VN Model Usage
	4.1. Customer view of VN		4.1. Customer view of VN
	The VN-Yang model allows to define a customer view, and allows the		The VN-Yang model allows to define a customer view, and allows the
	customer to communicate using the VN constructs as described in the		customer to communicate using the VN constructs as described in the
	[ACTN-INFO]. It also allows to group the set of edge-to-edge links		[ACTN-INFO]. It also allows to group the set of edge-to-edge links
	(i.e., VN members) under a common umbrella of VN. This allows the		(i.e., VN members) under a common umbrella of VN. This allows the
	customer to instantiate and view the VN as one entity, making it		customer to instantiate and view the VN as one entity, making it
	skipping to change at page 12, line 26 ¶		skipping to change at page 13, line 17 ¶
	destinations from which the optimal source-destination may be		destinations from which the optimal source-destination may be
	chosen. The following YANG module is shown for describing source		chosen. The following YANG module is shown for describing source
	container and destination container. The following YANG tree shows		container and destination container. The following YANG tree shows
	how to model multi-sources and multi-destinations.		how to model multi-sources and multi-destinations.
	+--rw vn		+--rw vn
	+--rw vn-list* [vn-id]		+--rw vn-list* [vn-id]
	+--rw vn-id uint32		+--rw vn-id uint32
	+--rw vn-name? string		+--rw vn-name? string
	+--rw vn-topology-id? te-types:te-topology-id		+--rw vn-topology-id? te-types:te-topology-id
	+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id		+--rw abstract-node?
			-> /nw:networks/network/node/tet:te-node-id
	+--rw vn-member-list* [vn-member-id]		+--rw vn-member-list* [vn-member-id]
	&gt; /nw:networks/network/node/tet:te-node-id
	| +--rw vn-member-id uint32		| +--rw vn-member-id uint32
	| +--rw src		| +--rw src
	| | +--rw src? -> /ap/access-point-list/access-point-id		| | +--rw src?
	| | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		-> /ap/access-point-list/access-point-id
			| | +--rw src-vn-ap-id?
			-> /ap/access-point-list/vn-ap/vn-ap-id
	| | +--rw multi-src? boolean {multi-src-dest}?		| | +--rw multi-src? boolean {multi-src-dest}?
	&gt; /ap/access-point-list/vn-ap/vn-ap-id
	| +--rw dest		| +--rw dest
	| | +--rw dest? -> /ap/access-point-list/access-point-id		| | +--rw dest?
	| | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		-> /ap/access-point-list/access-point-id
			| | +--rw dest-vn-ap-id?
			-> /ap/access-point-list/vn-ap/vn-ap-id
	| | +--rw multi-dest? boolean {multi-src-dest}?		| | +--rw multi-dest? boolean {multi-src-dest}?
	&gt; /ap/access-point-list/vn-ap/vn-ap-id		| +--rw connetivity-matrix-id?
	| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-		-> /nw:networks/network/node/tet:te/te-node-attributes/connectivity-
	node-attributes/connectivity-matrices/connectivity-matrix/id		matrices/connectivity-matrix/id
	| +--ro oper-status? identityref		| +--ro oper-status? identityref
	+--ro if-selected? boolean {multi-src-dest}?		+--ro if-selected? boolean {multi-src-dest}?
	+--rw admin-status? identityref		+--rw admin-status? identityref
	+--ro oper-status? identityref		+--ro oper-status? identityref
	4.3.3. Others		4.3.3. Others
	The VN Yang model can be easily augmented to support the mapping of		The VN Yang model can be easily augmented to support the mapping of
	VN to the Services such as L3SM and L2SM as described in [TE-MAP].		VN to the Services such as L3SM and L2SM as described in [TE-MAP].
	skipping to change at page 13, line 34 ¶		skipping to change at page 14, line 31 ¶
	Members.		Members.
	No other details need to be set by customer, making for a		No other details need to be set by customer, making for a
	simplified operations for the customer.		simplified operations for the customer.
	* VN Type 2: Along with VN Members, the customer could also		* VN Type 2: Along with VN Members, the customer could also
	provide an abstract topology, this topology is provided by		provide an abstract topology, this topology is provided by
	the Abstract TE Topology Yang Model.		the Abstract TE Topology Yang Model.
	5. VN YANG Model (Tree Structure)		5. VN YANG Model (Tree Structure)
	module: ietf-vn		module: ietf-vn
	+--rw ap		+-rw ap
	| +--rw access-point-list* [access-point-id]		| +-rw access-point-list* [access-point-id]
	| +--rw access-point-id uint32		| +-rw access-point-id uint32
	| +--rw access-point-name? string		| +-rw access-point-name? string
	| +--rw max-bandwidth? te-types:te-bandwidth		| +-rw max-bandwidth? te-types:te-bandwidth
	| +--rw avl-bandwidth? te-types:te-bandwidth		| +-rw avl-bandwidth? te-types:te-bandwidth
	| +--rw vn-ap* [vn-ap-id]		| +-rw vn-ap* [vn-ap-id]
	| +--rw vn-ap-id uint32		| +-rw vn-ap-id uint32
	| +--rw vn? -> /vn/vn-list/vn-id		| +-rw vn?
	| +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id		-> /vn/vn-list/vn-id
	| +--rw ltp? te-types:te-tp-id		| +-rw abstract-node?
	+--rw vn		-> /nw:networks/network/node/tet:te-node-id
	+--rw vn-list* [vn-id]		| +-rw ltp?
	+--rw vn-id uint32		-> /nw:networks/network/node/nt:termination-point/tet:te-tp-id
	+--rw vn-name? string		+-rw vn
	+--rw vn-topology-id? te-types:te-topology-id		+-rw vn-list* [vn-id]
	+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id		+-rw vn-id uint32
	+--rw vn-member-list* [vn-member-id]		+-rw vn-name? string
	| +--rw vn-member-id uint32		+-rw vn-topology-id? te-types:te-topology-id
	| +--rw src		+-rw abstract-node?
	| | +--rw src? -> /ap/access-point-list/access-point-id		-> /nw:networks/network/node/tet:te-node-id
	| | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		+-rw vn-member-list* [vn-member-id]
	| | +--rw multi-src? boolean {multi-src-dest}?		| +-rw vn-member-id uint32
	| +--rw dest		| +-rw src
	| | +--rw dest? -> /ap/access-point-list/access-point-id		| | +-rw src?
	| | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		-> /ap/access-point-list/access-point-id
	| | +--rw multi-dest? boolean {multi-src-dest}?		| | +-rw src-vn-ap-id?
	| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-		-> /ap/access-point-list/vn-ap/vn-ap-id
	node-attributes/connectivity-matrices/connectivity-matrix/id		| | +-rw multi-src? boolean {multi-src-dest}?
	| +--ro oper-status? identityref		| +-rw dest
	+--ro if-selected? boolean {multi-src-dest}?		| | +-rw dest?
	+--rw admin-status? identityref		-> /ap/access-point-list/access-point-id
	+--ro oper-status? identityref		| | +-rw dest-vn-ap-id?
	+--rw vn-level-diversity? vn-disjointness		-> /ap/access-point-list/vn-ap/vn-ap-id
			| | +-rw multi-dest? boolean {multi-src-dest}?
			| +-rw connectivity-matrix-id?
			-> /nw:networks/network/node/tet:te/te-node-attribute
			/connectivity-matrices/connectivity-matrix/id
			| +-ro oper-status? identityref
			+-ro if-selected? boolean {multi-src-dest}?
			+-rw admin-status? identityref
			+-ro oper-status? identityref
			+-rw vn-level-diversity? vn-disjointness
	rpcs:		rpcs:
	+---x vn-compute		+--x vn-compute
	+---w input		+--w input
	| +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id		| +--w abstract-node?
	| +---w vn-member-list* [vn-member-id]		-> /nw:networks/network/node/tet:te-node-id
	| | +---w vn-member-id uint32		| +--w vn-member-list* [vn-member-id]
	| | +---w src		| | +--w vn-member-id uint32
	| | | +---w src? -> /ap/access-point-list/access-point-id		| | +--w src
	| | | +---w src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		| | | +--w src?
	| | | +---w multi-src? boolean {multi-src-dest}?		-> /ap/access-point-list/access-point-id
	| | +---w dest		| | | +--w src-vn-ap-id?
	| | | +---w dest? -> /ap/access-point-list/access-point-id		-> /ap/access-point-list/vn-ap/vn-ap-id
	| | | +---w dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		| | | +--w multi-src? boolean {multi-src-dest}?
	| | | +---w multi-dest? boolean {multi-src-dest}?		| | +--w dest
	| | +---w connetivity-matrix-id? ->		| | | +--w dest?
	/nw:networks/network/node/tet:te/te-node-attributes/connectivity-		-> /ap/access-point-list/access-point-id
	matrices/connectivity-matrix/id		| | | +--w dest-vn-ap-id?
	| +---w vn-level-diversity? vn-disjointness		-> /ap/access-point-list/vn-ap/vn-ap-id
	+--ro output		| | | +--w multi-dest? boolean {multi-src-dest}?
	+--ro vn-member-list* [vn-member-id]		| | +--w connectivity-matrix-id?
	+--ro vn-member-id uint32		-> /nw:networks/network/node/tet:te/te-node-attributes
	+--ro src		/connectivity-matrices/connectivity-matrix/id
	| +--ro src? -> /ap/access-point-list/access-point-id		| +--w vn-level-diversity? vn-disjointness
	| +--ro src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		+-ro output
	| +--ro multi-src? boolean {multi-src-dest}?		+-ro vn-member-list* [vn-member-id]
	+--ro dest		+-ro vn-member-id uint32
	| +--ro dest? -> /ap/access-point-list/access-point-id		+-ro src
	| +--ro dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id		| +-ro src? ->
	| +--ro multi-dest? boolean {multi-src-dest}?		/ap/access-point-list/access-point-id
	+--ro connetivity-matrix-id? ->		| +-ro src-vn-ap-id? ->
	/nw:networks/network/node/tet:te/te-node-attributes/connectivity-		/ap/access-point-list/vn-ap/vn-ap-id
	matrices/connectivity-matrix/id		| +-ro multi-src? boolean {multi-src-dest}?
	+--ro if-selected? boolean {multi-src-dest}?		+-ro dest
	+--ro compute-status? Identityref		| +-ro dest? ->
			/ap/access-point-list/access-point-id
			| +-ro dest-vn-ap-id? ->
			/ap/access-point-list/vn-ap/vn-ap-id
			| +-ro multi-dest? boolean {multi-src-dest}?
			+-ro connectivity-matrix-id?
			-> /nw:networks/network/node/tet:te/te-node-attributes
			/connectivity-matrices/connectivity-matrix/id
			+-ro if-selected? boolean {multi-src-dest}?
			+-ro compute-status? identityref
	6. VN YANG Code		6. VN YANG Code
	The YANG code is as follows:		The YANG code is as follows:
	<CODE BEGINS> file "ietf-vn@2019-02-04.yang"		<CODE BEGINS> file "ietf-vn@2019-06-20.yang"
	module ietf-vn {		module ietf-vn {
			yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-vn";		namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
	prefix "vn";		prefix "vn";
	/* Import network */		/* Import network */
	import ietf-network {		import ietf-network {
	prefix "nw";		prefix "nw";
			reference
			"RFC 8345: A YANG Data Model for Network Topologies";
			}
			/* Import network topology */
			import ietf-network-topology {
			prefix "nt";
			reference
			"RFC 8345: A YANG Data Model for Network Topologies";
	}		}
	/* Import TE generic types */		/* Import TE generic types */
	import ietf-te-types {		import ietf-te-types {
	prefix "te-types";		prefix "te-types";
			reference
			"I-D.ietf-teas-yang-te-types: Traffic Engineering
			Common YANG Types";
	}		}
	/* Import Abstract TE Topology */		/* Import Abstract TE Topology */
	import ietf-te-topology {		import ietf-te-topology {
	prefix "tet";		prefix "tet";
			reference
			"I-D.ietf-teas-yang-te-topo: YANG Data Model for
			Traffic Engineering (TE) Topologies";
	}		}
	organization		organization
	"IETF Traffic Engineering Architecture and Signaling (TEAS)		"IETF Traffic Engineering Architecture and Signaling (TEAS)
	Working Group";		Working Group";
	contact		contact
	"Editor: Young Lee <leeyoung@huawei.com>		"Editor: Young Lee <younglee.tx@gmail.com>
	: Dhruv Dhody <dhruv.ietf@gmail.com>";		: Dhruv Dhody <dhruv.ietf@gmail.com>";
	description		description
	"This module contains a YANG module for the VN. It		"This module contains a YANG module for the VN. It
	describes a VN operation module that takes place in the		describes a VN operation module that takes place in the
	context of the CNC-MDSC Interface (CMI) of the ACTN		context of the CNC-MDSC Interface (CMI) of the ACTN
	architecture where the CNC is the actor of a VN		architecture where the CNC is the actor of a VN
	Instantiation/modification /deletion.";		Instantiation/modification /deletion.";
	revision 2019-02-04 {		revision 2019-06-10 {
	description		description
	"initial version.";		"initial version.";
	reference		reference
	"TBD";		"TBD";
	}		}
	/*		/*
	* Features		* Features
	*/		*/
	feature multi-src-dest {		feature multi-src-dest {
	description		description
	skipping to change at page 18, line 33 ¶		skipping to change at page 20, line 19 ¶
	"unique identifier for the referred		"unique identifier for the referred
	VNAP";		VNAP";
	}		}
	leaf vn {		leaf vn {
	type leafref {		type leafref {
	path "/vn/vn-list/vn-id";		path "/vn/vn-list/vn-id";
	}		}
	description		description
	"reference to the VN";		"reference to the VN";
	}		}
	leaf abstract-node {		leaf abstract-node {
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/"		path "/nw:networks/nw:network/nw:node/"
	+ "tet:te-node-id";		+"tet:te-node-id";
	}		}
	description		description
	"a reference to the abstract node in TE		"a reference to the abstract node in TE
	Topology";		Topology";
	}		}
	leaf ltp {		leaf ltp {
	type te-types:te-tp-id;		type leafref {
			path "/nw:networks/nw:network/nw:node/"
			+"nt:termination-point/tet:te-tp-id";
			}
	description		description
	"Reference LTP in the TE-topology";		"Reference LTP in the TE-topology";
	}		}
	}		}
	grouping access-point{		grouping access-point{
	description		description
	"AP related information";		"AP related information";
	leaf access-point-id {		leaf access-point-id {
	type uint32;		type uint32;
	description		description
	skipping to change at page 21, line 9 ¶		skipping to change at page 22, line 43 ¶
	"reference to dest VNAP";		"reference to dest VNAP";
	}		}
	leaf multi-dest {		leaf multi-dest {
	if-feature multi-src-dest;		if-feature multi-src-dest;
	type boolean;		type boolean;
	description		description
	"Is destination part of multi-destination, where		"Is destination part of multi-destination, where
	only one of the destination is enabled";		only one of the destination is enabled";
	}		}
	}		}
	leaf connetivity-matrix-id{		leaf connectivity-matrix-id{
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/tet:te/"		path "/nw:networks/nw:network/nw:node/tet:te/"
	+ "tet:te-node-attributes/"		+ "tet:te-node-attributes/"
	+ "tet:connectivity-matrices/"		+ "tet:connectivity-matrices/"
	+ "tet:connectivity-matrix/tet:id";		+ "tet:connectivity-matrix/tet:id";
	}		}
	description		description
	"reference to connetivity-matrix";		"reference to connectivity-matrix";
	}		}
	}//vn-member		}//vn-member
	/*		/*
	grouping policy {		grouping policy {
	description		description
	"policy related to vn-member-id";		"policy related to vn-member-id";
	leaf local-reroute {		leaf local-reroute {
	type boolean;		type boolean;
	description		description
	"Policy to state if reroute		"Policy to state if reroute
	skipping to change at page 53, line 38 ¶		skipping to change at page 55, line 38 ¶
	Nokia		Nokia
	Email: sergio.belotti@nokia.com		Email: sergio.belotti@nokia.com
	Takuya Miyasaka		Takuya Miyasaka
	KDDI		KDDI
	Email: ta-miyasaka@kddi.com		Email: ta-miyasaka@kddi.com
	Authors' Addresses		Authors' Addresses
	Young Lee (ed.)		Young Lee (ed.)
	Huawei Technologies		Futurewei Technologies
	Email: leeyoung@huawei.com		Email: younglee.tx@gmail.com
	Dhruv Dhody (ed.)		Dhruv Dhody (ed.)
	Huawei Technologies		Huawei Technologies
	Email: dhruv.ietf@gmail.com		Email: dhruv.ietf@gmail.com
	Daniele Ceccarelli		Daniele Ceccarelli
	Ericsson		Ericsson
	Torshamnsgatan,48		Torshamnsgatan,48
	Stockholm, Sweden		Stockholm, Sweden
	Email: daniele.ceccarelli@ericsson.com		Email: daniele.ceccarelli@ericsson.com
	Igor Bryskin		Igor Bryskin
	Huawei		Huawei
	Email: Igor.Bryskin@huawei.com		Email: ibryskin@futurewei.com
	Bin Yeong Yoon		Bin Yeong Yoon
	ETRI		ETRI
	Email: byyun@etri.re.kr		Email: byyun@etri.re.kr
	Qin Wu		Qin Wu
	Huawei Technologies		Huawei Technologies
	Email: bill.wu@huawei.com		Email: bill.wu@huawei.com
	Peter Park		Peter Park
End of changes. 42 change blocks.
	211 lines changed or deleted		281 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/