draft-ietf-teas-actn-vn-yang-08.txt		draft-ietf-teas-actn-vn-yang-09.txt
	TEAS Working Group Y. Lee, Ed.		TEAS Working Group Y. Lee, Ed.
	Internet-Draft Samsung Electronics		Internet-Draft Samsung Electronics
	Intended status: Standards Track D. Dhody, Ed.		Intended status: Standards Track D. Dhody, Ed.
	Expires: September 9, 2020 Huawei Technologies		Expires: January 14, 2021 Huawei Technologies
	D. Ceccarelli		D. Ceccarelli
	Ericsson		Ericsson
	I. Bryskin		I. Bryskin
	Individual		Individual
	B. Yoon		B. Yoon
	ETRI		ETRI
	March 8, 2020		July 13, 2020
	A Yang Data Model for VN Operation		A YANG Data Model for VN Operation
	draft-ietf-teas-actn-vn-yang-08		draft-ietf-teas-actn-vn-yang-09
	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 in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 9, 2020.		This Internet-Draft will expire on January 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
			1.1.1. Requirements Language . . . . . . . . . . . . . . . . 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 . . . . . . . . 4		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 . . . . . . . . . . . . . . . . . 8
	3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 11		3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 11
	4. VN Model Usage . . . . . . . . . . . . . . . . . . . . . . . 12		4. VN Model Usage . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Customer view of VN . . . . . . . . . . . . . . . . . . . 12		4.1. Customer view of VN . . . . . . . . . . . . . . . . . . . 12
	4.2. Auto-creation of VN by MDSC . . . . . . . . . . . . . . . 12		4.2. Auto-creation of VN by MDSC . . . . . . . . . . . . . . . 12
	4.3. Innovative Services . . . . . . . . . . . . . . . . . . . 12		4.3. Innovative Services . . . . . . . . . . . . . . . . . . . 12
	4.3.1. VN Compute . . . . . . . . . . . . . . . . . . . . . 12		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 . . . . . . . . . . . . . . . . . . . . . . . 13		4.3.3. Others . . . . . . . . . . . . . . . . . . . . . . . 13
	4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14		4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14
	5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 14		5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 14
	6. VN YANG Code . . . . . . . . . . . . . . . . . . . . . . . . 16		6. VN YANG Model . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 26		7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 32		7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 33
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 48		8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
	11.1. Normative References . . . . . . . . . . . . . . . . . . 51		11.1. Normative References . . . . . . . . . . . . . . . . . . 51
	11.2. Informative References . . . . . . . . . . . . . . . . . 52		11.2. Informative References . . . . . . . . . . . . . . . . . 53
	Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 53		Appendix A. Performance Constraints . . . . . . . . . . . . . . 54
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54		Appendix B. Contributors Addresses . . . . . . . . . . . . . . . 54
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
	1. Introduction		1. Introduction
	This document provides a YANG data model generally applicable to any		This document provides a YANG [RFC7950] data model generally
	mode of Virtual Network (VN) operation.		applicable to any 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 [RFC8466] and L1CSM		models such as L3SM [RFC8299], L2SM [RFC8466] and L1CSM
	[I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service		[I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service
	management and operations.		management and operations.
	The YANG model discussed in this document basically provides the		The YANG model discussed in this document basically provides the
	following:		following:
	o Characteristics of Access Points (APs) that describe customer's		o Characteristics of Access Points (APs) that describe customer's
	end point characteristics;		end point characteristics;
	o Characteristics of Virtual Network Access Points (VNAP) that		o Characteristics of Virtual Network Access Points (VNAP) that
	describe How an AP is partitioned for multiple VNs sharing the AP		describe how an AP is partitioned for multiple VNs sharing the AP
	and its reference to a Link Termination Point (LTP) of the		and its reference to a Link Termination Point (LTP) of the
	Provider Edge (PE) Node;		Provider Edge (PE) Node;
	o Characteristics of Virtual Networks (VNs) that describe the		o Characteristics of Virtual Networks (VNs) that describe the
	customer's VNs in terms of VN Members comprising a VN, multi-		customer's VN in terms of multiple VN Members comprising a VN,
	source and/or multi-destination characteristics of VN Member, the		multi- source and/or multi-destination characteristics of the VN
	VN's reference to TE-topology's Abstract Node;		Member, the VN's reference to TE-topology's Abstract Node;
	The actual VN instantiation and computation is performed with		The actual VN instantiation and computation is performed with
	Connectivity Matrices sub-module of TE-Topology Model		Connectivity Matrices sub-module of TE-Topology Model
	[I-D.ietf-teas-yang-te-topo] which provides TE network topology		[I-D.ietf-teas-yang-te-topo] which provides TE network topology
	abstraction and management operation. Once TE-topology Model is used		abstraction and management operation. Once TE-topology Model is used
	in triggering VN instantiation over the networks, TE-tunnel		in triggering VN instantiation over the networks, TE-tunnel
	[I-D.ietf-teas-yang-te] Model will inevitably interact with TE-		[I-D.ietf-teas-yang-te] Model will inevitably interact with TE-
	Topology model for setting up actual tunnels and LSPs under the		Topology model for setting up actual tunnels and LSPs under the
	tunnels.		tunnels.
	Abstraction and Control of Traffic Engineered Networks (ACTN)		Abstraction and Control of Traffic Engineered Networks (ACTN)
	describes a set of management and control functions used to operate		describes a set of management and control functions used to operate
	one or more TE networks to construct virtual networks that can be		one or more TE networks to construct virtual networks that can be
	represented to customers and that are built from abstractions of the		represented to customers and that are built from abstractions of the
	underlying TE networks [RFC8453]. ACTN is the primary example of the		underlying TE networks [RFC8453]. ACTN is the primary example of the
	usage of the VN Yang model.		usage of the VN YANG model.
	Sections 2 and 3 provide the discussion of how the VN Yang model is		Sections 2 and 3 provide the discussion of how the VN YANG model is
	applicable to the ACTN context where Virtual Network Service (VNS)		applicable to the ACTN context where Virtual Network Service (VNS)
	operation is implemented for the Customer Network Controller (CNC)-		operation is implemented for the Customer Network Controller (CNC)-
	Multi-Domain Service Coordinator (MSDC) interface (CMI).		Multi-Domain Service Coordinator (MSDC) interface (CMI).
	The YANG model on the CMI is also known as customer service model in		The YANG model on the CMI is also known as customer service model in
	[RFC8309]. The YANG model discussed in this document is used to		[RFC8309]. The YANG model discussed in this document is used to
	operate customer-driven VNs during the VN instantiation, VN		operate customer-driven VNs during the VN instantiation, VN
	computation, and its life-cycle service management and operations.		computation, and its life-cycle service management and operations.
	The VN operational state is included in the same tree as the		The VN operational state is included in the same tree as the
	configuration consistent with Network Management Datastore		configuration consistent with Network Management Datastore
	Architecture (NMDA) [RFC8342]. The origin of the data is indicated		Architecture (NMDA) [RFC8342]. The origin of the data is indicated
	as per the origin metadata annotation.		as per the origin metadata annotation.
	1.1. Terminology		1.1. Terminology
	Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used		Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
	in this document.		in this document.
			1.1.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	1.2. Tree diagram		1.2. Tree diagram
	A simplified graphical representation of the data model is used in		A simplified graphical representation of the data model is used in
	Section 5 of this this document. The meaning of the symbols in these		Section 5 of this this document. The meaning of the symbols in these
	diagrams is defined in [RFC8340].		diagrams is defined in [RFC8340].
	1.3. Prefixes in Data Node Names		1.3. Prefixes in Data Node Names
	In this document, names of data nodes and other data model objects		In this document, names of data nodes and other data model objects
	are prefixed using the standard prefix associated with the		are prefixed using the standard prefix associated with the
	corresponding YANG imported modules, as shown in Table 1.		corresponding YANG imported modules, as shown in Table 1.
	+----------+-----------------------+------------------------------+		+----------+-----------------------+------------------------------+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+----------+-----------------------+------------------------------+		+----------+-----------------------+------------------------------+
	| vn | ietf-vn | [RFCXXXX] |		| vn | ietf-vn | [RFCXXXX] |
			| inet | ietf-inet-types | [RFC6991] |
	| nw | ietf-network | [RFC8345] |		| nw | ietf-network | [RFC8345] |
	| nt | ietf-network-topology | [RFC8345] |		| nt | ietf-network-topology | [RFC8345] |
	| te-types | ietf-te-types | [I-D.ietf-teas-yang-te] |		| te-types | ietf-te-types | [RFC8776] |
	| te-topo | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] |		| te-topo | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] |
	+----------+-----------------------+------------------------------+		+----------+-----------------------+------------------------------+
	Table 1: Prefixes and corresponding YANG modules		Table 1: Prefixes and corresponding YANG modules
	Note: The RFC Editor will replace XXXX with the number assigned to		Note: The RFC Editor will replace XXXX with the number assigned to
	the RFC once this draft becomes an RFC.		the RFC once this draft becomes an RFC.
	2. Use-case of VN Yang Model in the ACTN context		2. Use-case of VN YANG Model in the ACTN context
	In this section, ACTN is being used to illustrate the general usage		In this section, ACTN is being used to illustrate the general usage
	of the VN yang model. The model presented in this section has the		of the VN YANG model. The model presented in this section has the
	following ACTN context.		following ACTN context.
	+-------+		+-------+
	| CNC |		| CNC |
	+-------+		+-------+
	|		|
	| VN YANG + TE-topology YANG		| VN YANG + TE-topology YANG
	|		|
	+-----------------------+		+-----------------------+
	| 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 12, line 15 ¶		skipping to change at page 12, line 15 ¶
	added later.		added later.
	To achieve this the 'ap' container has a leaf for 'pe' node that		To achieve this the 'ap' container has a leaf for 'pe' node that
	allows AP to be created with PE information. The vn-member (and vn)		allows AP to be created with PE information. The vn-member (and vn)
	could use APs that only have PE information initially.		could use APs that only have PE information initially.
	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
	[RFC8454]. It also allows to group the set of edge-to-edge links		[RFC8454]. 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
	easier for some customers to work on VN without worrying about the		easier for some customers to work on VN without worrying about the
	details of the provider based YANG models.		details of the provider based YANG models.
	This is similar to the benefits of having a separate YANG model for		This is similar to the benefits of having a separate YANG model for
	the customer services as described in [RFC8309], which states that		the customer services as described in [RFC8309], which states that
	service models do not make any assumption of how a service is		service models do not make any assumption of how a service is
	actually engineered and delivered for a customer.		actually engineered and delivered for a customer.
	4.2. Auto-creation of VN by MDSC		4.2. Auto-creation of VN by MDSC
	The VN could be configured at the MDSC explicitly by the CNC using		The VN could be configured at the MDSC explicitly by the CNC using
	the VN yang model. In some other cases, the VN is not explicitly		the VN YANG model. In some other cases, the VN is not explicitly
	configured, but created automatically by the MDSC based on the		configured, but created automatically by the MDSC based on the
	customer service model and local policy, even in these case the VN		customer service model and local policy, even in these case the VN
	yang model can be used by the CNC to learn details of the underlying		YANG model can be used by the CNC to learn details of the underlying
	VN created to meet the requirements of customer service model.		VN created to meet the requirements of customer service model.
	4.3. Innovative Services		4.3. Innovative Services
	4.3.1. VN Compute		4.3.1. VN Compute
	VN Model supports VN compute (pre-instantiation mode) to view the		VN Model supports VN compute (pre-instantiation mode) to view the
	full VN as a single entity before instantiation. Achieving this via		full VN as a single entity before instantiation. Achieving this via
	path computation or "compute only" tunnel setup does not provide the		path computation or "compute only" tunnel setup does not provide the
	same functionality.		same functionality.
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	resource situations. Likewise, for a given destination, there may		resource situations. Likewise, for a given destination, there may
	also be multiple-sources from which the optimal source may be chosen.		also be multiple-sources from which the optimal source may be chosen.
	In some cases, there may be a pool of multiple sources and		In some cases, there may be a pool of multiple sources and
	destinations from which the optimal source-destination may be chosen.		destinations from which the optimal source-destination may be chosen.
	The following YANG module is shown for describing source container		The following YANG module is shown for describing source container
	and destination container. The following YANG tree shows how to		and destination container. The following YANG tree shows how to
	model multi-sources and multi-destinations.		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 vn-id
	+--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?		+--rw abstract-node?
	| -> /nw:networks/network/node/tet:te-node-id		| -> /nw:networks/network/node/tet:te-node-id
	+--rw vn-member-list* [vn-member-id]		+--rw vn-member-list* [vn-member-id]
	| +--rw vn-member-id uint32		| +--rw vn-member-id vn-member-id
	| +--rw src		| +--rw src
	| | +--rw src?		| | +--rw src?
	| | | -> /ap/access-point-list/access-point-id		| | | -> /ap/access-point-list/access-point-id
	| | +--rw src-vn-ap-id?		| | +--rw src-vn-ap-id?
	| | | -> /ap/access-point-list/vn-ap/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}?
	| +--rw dest		| +--rw dest
	| | +--rw dest?		| | +--rw dest?
	| | | -> /ap/access-point-list/access-point-id		| | | -> /ap/access-point-list/access-point-id
	| | +--rw dest-vn-ap-id?		| | +--rw dest-vn-ap-id?
	| | | -> /ap/access-point-list/vn-ap/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}?
	| +--rw connectivity-matrix-id? leafref		| +--rw connectivity-matrix-id? leafref
	| +--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
	+--rw vn-level-diversity? vn-disjointness		+--rw vn-level-diversity? te-types:te-path-disjointness
	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		VN to the Services such as L3SM and L2SM as described in
	[I-D.ietf-teas-te-service-mapping-yang].		[I-D.ietf-teas-te-service-mapping-yang].
	The VN Yang model can be extended to support telemetry, performance		The VN YANG model can be extended to support telemetry, performance
	monitoring and network autonomics as described in		monitoring and network autonomics as described in
	[I-D.ietf-teas-actn-pm-telemetry-autonomics].		[I-D.ietf-teas-actn-pm-telemetry-autonomics].
	4.3.4. Summary		4.3.4. Summary
	This section summarizes the innovative service features of the VN		This section summarizes the innovative service features of the VN
	Yang.		YANG.
	o Maintenance of AP and VNAP along with VN		o Maintenance of AP and VNAP along with VN
	o VN construct to group of edge-to-edge links		o VN construct to group of edge-to-edge links
	o VN Compute (pre-instantiate)		o VN Compute (pre-instantiate)
	o Multi-Source / Multi-Destination		o Multi-Source / Multi-Destination
	o Ability to support various VN and VNS Types		o Ability to support various VN and VNS Types
	* VN Type 1: Customer configures the VN as a set of VN Members.		* VN Type 1: Customer configures the VN as a set of VN 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 the		provide an abstract topology, this topology is provided by the
	Abstract TE Topology Yang Model.		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 access-point-id
	| +--rw access-point-name? string
	| +--rw pe?		| +--rw pe?
	| | -> /nw:networks/network/node/tet:te-node-id		| | -> /nw:networks/network/node/tet:te-node-id
	| +--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 access-point-id
	| +--rw vn? -> /vn/vn-list/vn-id		| +--rw vn? -> /vn/vn-list/vn-id
	| +--rw abstract-node?		| +--rw abstract-node?
	| | -> /nw:networks/network/node/tet:te-node-id		| | -> /nw:networks/network/node/tet:te-node-id
	| +--rw ltp? leafref		| +--rw ltp? leafref
			| +--ro max-bandwidth? te-types:te-bandwidth
	+--rw vn		+--rw vn
	+--rw vn-list* [vn-id]		+--rw vn-list* [vn-id]
	+--rw vn-id uint32		+--rw vn-id vn-id
	+--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?		+--rw abstract-node?
	| -> /nw:networks/network/node/tet:te-node-id		| -> /nw:networks/network/node/tet:te-node-id
	+--rw vn-member-list* [vn-member-id]		+--rw vn-member-list* [vn-member-id]
	| +--rw vn-member-id uint32		| +--rw vn-member-id vn-member-id
	| +--rw src		| +--rw src
	| | +--rw src?		| | +--rw src?
	| | | -> /ap/access-point-list/access-point-id		| | | -> /ap/access-point-list/access-point-id
	| | +--rw src-vn-ap-id?		| | +--rw src-vn-ap-id?
	| | | -> /ap/access-point-list/vn-ap/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}?
	| +--rw dest		| +--rw dest
	| | +--rw dest?		| | +--rw dest?
	| | | -> /ap/access-point-list/access-point-id		| | | -> /ap/access-point-list/access-point-id
	| | +--rw dest-vn-ap-id?		| | +--rw dest-vn-ap-id?
	| | | -> /ap/access-point-list/vn-ap/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}?
	| +--rw connectivity-matrix-id? leafref		| +--rw connectivity-matrix-id? leafref
	| +--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
	+--rw vn-level-diversity? vn-disjointness		+--rw vn-level-diversity? te-types:te-path-disjointness
	rpcs:		rpcs:
	+---x vn-compute		+---x vn-compute
	+---w input		+---w input
	| +---w abstract-node?		| +---w abstract-node?
	| | -> /nw:networks/network/node/tet:te-node-id		| | -> /nw:networks/network/node/tet:te-node-id
	| +---w vn-member-list* [vn-member-id]		| +---w vn-member-list* [vn-member-id]
	| | +---w vn-member-id uint32		| | +---w vn-member-id vn-member-id
	| | +---w src		| | +---w src
	| | | +---w src?		| | | +---w src?
	| | | | -> /ap/access-point-list/access-point-id		| | | | -> /ap/access-point-list/access-point-id
	| | | +---w src-vn-ap-id?		| | | +---w src-vn-ap-id?
	| | | | -> /ap/access-point-list/vn-ap/vn-ap-id		| | | | -> /ap/access-point-list/vn-ap/vn-ap-id
	| | | +---w multi-src? boolean {multi-src-dest}?		| | | +---w multi-src? boolean {multi-src-dest}?
	| | +---w dest		| | +---w dest
	| | | +---w dest?		| | | +---w dest?
	| | | | -> /ap/access-point-list/access-point-id		| | | | -> /ap/access-point-list/access-point-id
	| | | +---w dest-vn-ap-id?		| | | +---w dest-vn-ap-id?
	| | | | -> /ap/access-point-list/vn-ap/vn-ap-id		| | | | -> /ap/access-point-list/vn-ap/vn-ap-id
	| | | +---w multi-dest? boolean {multi-src-dest}?		| | | +---w multi-dest? boolean {multi-src-dest}?
	| | +---w connectivity-matrix-id? leafref		| | +---w connectivity-matrix-id? leafref
	| +---w vn-level-diversity? vn-disjointness		| +---w vn-level-diversity? te-types:te-path-disjointness
	+--ro output		+--ro output
	+--ro vn-member-list* [vn-member-id]		+--ro vn-member-list* [vn-member-id]
	+--ro vn-member-id uint32		+--ro vn-member-id vn-member-id
	+--ro src		+--ro src
	| +--ro src?		| +--ro src?
	| | -> /ap/access-point-list/access-point-id		| | -> /ap/access-point-list/access-point-id
	| +--ro src-vn-ap-id?		| +--ro src-vn-ap-id?
	| | -> /ap/access-point-list/vn-ap/vn-ap-id		| | -> /ap/access-point-list/vn-ap/vn-ap-id
	| +--ro multi-src? boolean {multi-src-dest}?		| +--ro multi-src? boolean {multi-src-dest}?
	+--ro dest		+--ro dest
	| +--ro dest?		| +--ro dest?
	| | -> /ap/access-point-list/access-point-id		| | -> /ap/access-point-list/access-point-id
	| +--ro dest-vn-ap-id?		| +--ro dest-vn-ap-id?
	| | -> /ap/access-point-list/vn-ap/vn-ap-id		| | -> /ap/access-point-list/vn-ap/vn-ap-id
	| +--ro multi-dest? boolean {multi-src-dest}?		| +--ro multi-dest? boolean {multi-src-dest}?
	+--ro connectivity-matrix-id? leafref		+--ro connectivity-matrix-id? leafref
	+--ro if-selected? boolean		+--ro if-selected? boolean
	| {multi-src-dest}?		| {multi-src-dest}?
	+--ro compute-status? identityref		+--ro compute-status? identityref
	6. VN YANG Code		6. VN YANG Model
	The YANG code is as follows:		The YANG model is as follows:
	<CODE BEGINS> file "ietf-vn@2020-03-08.yang"		<CODE BEGINS> file "ietf-vn@2020-07-13.yang"
	module ietf-vn {		module ietf-vn {
	yang-version 1.1;		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 inet-types */
			import ietf-inet-types {
			prefix inet;
			reference
			"RFC 6991: Common YANG Data Types";
			}
	/* Import network */		/* Import network */
	import ietf-network {		import ietf-network {
	prefix nw;		prefix nw;
	reference		reference
	"RFC 8345: A YANG Data Model for Network Topologies";		"RFC 8345: A YANG Data Model for Network Topologies";
	}		}
	/* Import network topology */		/* Import network topology */
	skipping to change at page 16, line 44 ¶		skipping to change at page 17, line 4 ¶
	/* Import network topology */		/* Import network topology */
	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";
	}		}
	/* Import TE Common types */		/* Import TE Common types */
	import ietf-te-types {		import ietf-te-types {
	prefix te-types;		prefix te-types;
	reference		reference
	"I-D.ietf-teas-yang-te-types: Traffic Engineering Common		"RFC 8776: Common YANG Data Types for Traffic Engineering";
	YANG Types";
	}		}
	/* Import TE Topology */		/* Import TE Topology */
	import ietf-te-topology {		import ietf-te-topology {
	prefix tet;		prefix tet;
	reference		reference
	"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic		"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
	Engineering (TE) Topologies";		Engineering (TE) Topologies";
	}		}
	organization		organization
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 31 ¶
	Working Group";		Working Group";
	contact		contact
	"WG Web: <https://tools.ietf.org/wg/teas/>		"WG Web: <https://tools.ietf.org/wg/teas/>
	WG List: <mailto:teas@ietf.org>		WG List: <mailto:teas@ietf.org>
	Editor: Young Lee <younglee.tx@gmail.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 describes a		"This module contains a YANG module for the VN. It describes a
	VN operation module that takes place in the context of the		VN operation module that takes place in the context of the
	CNC-MDSC Interface (CMI) of the ACTN architecture where the		CNC-MDSC Interface (CMI) of the ACTN architecture where the
	CNC is the actor of a VN Instantiation/modification/deletion.		CNC is the actor of a VN Instantiation/modification/deletion
			as per RFC 8453.
	Copyright (c) 2020 IETF Trust and the persons identified as		Copyright (c) 2020 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 to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		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 XXXX; see the		This version of this YANG module is part of RFC XXXX; see the
	RFC itself for full legal notices.		RFC itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.";		they appear in all capitals, as shown here.";
	revision 2020-03-08 {		revision 2020-07-13 {
	description		description
	"initial version.";		"initial version.";
	reference		reference
	"RFC XXXX: A Yang Data Model for VN Operation";		"RFC XXXX: A YANG Data Model for VN Operation";
	}		}
	/* Features */		/* Features */
	feature multi-src-dest {		feature multi-src-dest {
	description		description
	"Support for selection of one src or destination		"Support for selection of one src or destination
	among multiple.";		among multiple.";
			reference
			"RFC 8453: Framework for Abstraction and Control of TE
			Networks (ACTN)";
	}		}
	/* Identity VN State*/		/* Identity VN State*/
	identity vn-state-type {		identity vn-state-type {
	description		description
	"Base identity for VN state";		"Base identity for VN state";
	}		}
	identity vn-state-up {		identity vn-state-up {
	skipping to change at page 19, line 21 ¶		skipping to change at page 19, line 32 ¶
	description		description
	"State path compute in progress";		"State path compute in progress";
	}		}
	identity vn-compute-state-computation-ok {		identity vn-compute-state-computation-ok {
	base vn-compute-state-type;		base vn-compute-state-type;
	description		description
	"State path compute successful";		"State path compute successful";
	}		}
	identity vn-compute-state-computatione-failed {		identity vn-compute-state-computation-failed {
	base vn-compute-state-type;		base vn-compute-state-type;
	description		description
	"State path compute failed";		"State path compute failed";
	}		}
	/* typedef */		/* Typedef */
	typedef vn-disjointness {		typedef vn-id {
	type bits {		type inet:uri;
	bit node {
	position 0;
	description
	"node disjoint";
	}
	bit link {
	position 1;
	description
	"link disjoint";
	}
	bit srlg {
	position 2;
	description
	"srlg disjoint";
	}
	}
	description		description
	"type of the resource disjointness for VN level applied		"Identifier for a VN. The precise structure of the
	across all VN members in a VN";		vn-id will be up to the implementation. The
			identifier SHOULD be chosen such that the same VN
			will always be identified through the same
			identifier, even if the data model is instantiated
			in separate datastores.";
			}
			typedef access-point-id {
			type inet:uri;
			description
			"Identifier for an AP. The precise structure of the
			access-point-id will be up to the implementation.
			The identifier SHOULD be chosen such that the same AP
			will always be identified through the same
			identifier, even if the data model is instantiated
			in separate datastores. This type is used for both AP
			and VNAP";
			}
			typedef vn-member-id {
			type inet:uri;
			description
			"Identifier for a VN member. The precise structure of
			the vn-member-id will be up to the implementation.
			The identifier SHOULD be chosen such that the same VN
			member will always be identified through the same
			identifier, even if the data model is instantiated
			in separate datastores. ";
	}		}
	/* Groupings */		/* Groupings */
	grouping vn-ap {		grouping vn-ap {
	description		description
	"VNAP related information";		"VNAP related information";
	leaf vn-ap-id {		leaf vn-ap-id {
	type uint32;		type access-point-id;
	description		description
	"unique identifier for the referred VNAP";		"A unique identifier for the referred 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";		"A reference to the VN";
	}		}
	leaf abstract-node {		leaf abstract-node {
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/tet:te-node-id";		path "/nw:networks/nw:network/nw:node/tet:te-node-id";
	}		}
	description		description
	"a reference to the abstract node in TE Topology that		"A reference to the abstract node in TE Topology that
	represent the VN";		represent the VN";
	}		}
	leaf ltp {		leaf ltp {
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/"		path "/nw:networks/nw:network/nw:node/"
	+ "nt:termination-point/tet:te-tp-id";		+ "nt:termination-point/tet:te-tp-id";
	}		}
	description		description
	"Reference LTP in the TE-topology";		"A reference LTP in the TE-topology";
			reference
			"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
			Engineering (TE) Topologies";
			}
			leaf max-bandwidth {
			type te-types:te-bandwidth;
			config false;
			description
			"The max bandwidth of the VNAP";
	}		}
			reference
			"RFC 8453: Framework for Abstraction and Control of TE
			Networks (ACTN)";
	} //vn-ap		} //vn-ap
	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 access-point-id;
	description
	"unique identifier for the referred access point";
	}
	leaf access-point-name {
	type string;
	description		description
	"ap name";		"A unique identifier for the referred access point";
	}		}
	leaf pe {		leaf pe {
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/tet:te-node-id";		path "/nw:networks/nw:network/nw:node/tet:te-node-id";
	}		}
	description		description
	"a reference to the PE node in the native TE Topology";		"A reference to the PE node in the native TE Topology";
	}		}
	leaf max-bandwidth {		leaf max-bandwidth {
	type te-types:te-bandwidth;		type te-types:te-bandwidth;
	description		description
	"max bandwidth of the AP";		"The max bandwidth of the AP";
	}		}
	leaf avl-bandwidth {		leaf avl-bandwidth {
	type te-types:te-bandwidth;		type te-types:te-bandwidth;
	description		description
	"available bandwidth of the AP";		"The available bandwidth of the AP";
	}		}
	/*add details and any other properties of AP,		/*add details and any other properties of AP,
	not associated by a VN		not associated by a VN
	CE port, PE port etc.		CE port, PE port etc.
	*/		*/
	list vn-ap {		list vn-ap {
	key "vn-ap-id";		key "vn-ap-id";
	uses vn-ap;		uses vn-ap;
	description		description
	"list of VNAP in this AP";		"List of VNAP in this AP";
	}		}
			reference
			"RFC 8453: Framework for Abstraction and Control of TE
			Networks (ACTN)";
	} //access-point		} //access-point
	grouping vn-member {		grouping vn-member {
	description		description
	"vn-member is described by this container";		"The vn-member is described by this grouping";
	leaf vn-member-id {		leaf vn-member-id {
	type uint32;		type vn-member-id;
	description		description
	"vn-member identifier";		"A vn-member identifier";
	}		}
	container src {		container src {
	description		description
	"the source of VN Member";		"The source of VN Member";
	leaf src {		leaf src {
	type leafref {		type leafref {
	path "/ap/access-point-list/access-point-id";		path "/ap/access-point-list/access-point-id";
	}		}
	description		description
	"reference to source AP";		"A reference to source AP";
	}		}
	leaf src-vn-ap-id {		leaf src-vn-ap-id {
	type leafref {		type leafref {
	path "/ap/access-point-list/vn-ap/vn-ap-id";		path "/ap/access-point-list/vn-ap/vn-ap-id";
	}		}
	description		description
	"reference to source VNAP";		"A reference to source VNAP";
	}		}
	leaf multi-src {		leaf multi-src {
	if-feature "multi-src-dest";		if-feature "multi-src-dest";
	type boolean;		type boolean;
	description		description
	"Is source part of multi-source, where		"Is the source part of multi-source, where
	only one of the source is enabled";		only one of the source is enabled";
	}		}
	}		}
	container dest {		container dest {
	description		description
	"the destination of VN Member";		"the destination of VN Member";
	leaf dest {		leaf dest {
	type leafref {		type leafref {
	path "/ap/access-point-list/access-point-id";		path "/ap/access-point-list/access-point-id";
	}		}
	description		description
	"reference to destination AP";		"A reference to destination AP";
	}		}
	leaf dest-vn-ap-id {		leaf dest-vn-ap-id {
	type leafref {		type leafref {
	path "/ap/access-point-list/vn-ap/vn-ap-id";		path "/ap/access-point-list/vn-ap/vn-ap-id";
	}		}
	description		description
	"reference to dest VNAP";		"A 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 only one		"Is destination part of multi-destination, where only one
	of the destination is enabled";		of the destination is enabled";
	}		}
	}		}
	leaf connectivity-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 connectivity-matrix";		"A reference to connectivity-matrix";
			reference
			"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
			Engineering (TE) Topologies";
	}		}
			reference
			"RFC 8454: Information Model for Abstraction and Control of TE
			Networks (ACTN)";
	} //vn-member		} //vn-member
	grouping vn-policy {		grouping vn-policy {
	description		description
	"policy for VN-level diverisity";		"policy for VN-level diverisity";
	leaf vn-level-diversity {		leaf vn-level-diversity {
	type vn-disjointness;		type te-types:te-path-disjointness;
	description		description
	"the type of disjointness on the VN level (i.e., across all		"The type of disjointness on the VN level (i.e., across all
	VN members)";		VN members)";
	}		}
	}		}
	/* Configuration data nodes */		/* Configuration data nodes */
	container ap {		container ap {
	description		description
	"AP configurations";		"AP configurations";
	list access-point-list {		list access-point-list {
	key "access-point-id";		key "access-point-id";
	skipping to change at page 23, line 30 ¶		skipping to change at page 24, line 19 ¶
	container ap {		container ap {
	description		description
	"AP configurations";		"AP configurations";
	list access-point-list {		list access-point-list {
	key "access-point-id";		key "access-point-id";
	description		description
	"access-point identifier";		"access-point identifier";
	uses access-point {		uses access-point {
	description		description
	"access-point information";		"The access-point information";
	}		}
	}		}
			reference
			"RFC 8453: Framework for Abstraction and Control of TE
			Networks (ACTN)";
	}		}
	container vn {		container vn {
	description		description
	"VN configurations";		"VN configurations";
	list vn-list {		list vn-list {
	key "vn-id";		key "vn-id";
	description		description
	"a virtual network is identified by a vn-id";		"A virtual network is identified by a vn-id";
	leaf vn-id {		leaf vn-id {
	type uint32;		type vn-id;
	description
	"a unique vn identifier";
	}
	leaf vn-name {
	type string;
	description		description
	"vn name";		"A unique VN identifier";
	}		}
	leaf vn-topology-id {		leaf vn-topology-id {
	type te-types:te-topology-id;		type te-types:te-topology-id;
	description		description
	"An optional identifier to the TE Topology Model where the		"An optional identifier to the TE Topology Model where the
	abstract nodes and links of the Topology can be found for		abstract nodes and links of the Topology can be found for
	Type 2 VNS";		Type 2 VNS";
	}		}
	leaf abstract-node {		leaf abstract-node {
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/tet:te-node-id";		path "/nw:networks/nw:network/nw:node/tet:te-node-id";
	}		}
	description		description
	"a reference to the abstract node in TE Topology";		"A reference to the abstract node in TE Topology";
	}		}
	list vn-member-list {		list vn-member-list {
	key "vn-member-id";		key "vn-member-id";
	description		description
	"List of VN-members in a VN";		"List of vn-members in a VN";
	uses vn-member;		uses vn-member;
	leaf oper-status {		leaf oper-status {
	type identityref {		type identityref {
	base vn-state-type;		base vn-state-type;
	}		}
	config false;		config false;
	description		description
	"VN-member operational state.";		"The vn-member operational state.";
	}		}
	}		}
	leaf if-selected {		leaf if-selected {
	if-feature "multi-src-dest";		if-feature "multi-src-dest";
	type boolean;		type boolean;
	default "false";		default "false";
	config false;		config false;
	description		description
	"Is the vn-member is selected among the multi-src/dest		"Is the vn-member is selected among the multi-src/dest
	options";		options";
	skipping to change at page 25, line 9 ¶		skipping to change at page 25, line 44 ¶
	leaf oper-status {		leaf oper-status {
	type identityref {		type identityref {
	base vn-state-type;		base vn-state-type;
	}		}
	config false;		config false;
	description		description
	"VN operational state.";		"VN operational state.";
	}		}
	uses vn-policy;		uses vn-policy;
	} //vn-list		} //vn-list
			reference
			"RFC 8453: Framework for Abstraction and Control of TE
			Networks (ACTN)";
	} //vn		} //vn
	/* RPC */		/* RPC */
	rpc vn-compute {		rpc vn-compute {
	description		description
	"The VN computation without actual instantiation";		"The VN computation without actual instantiation";
	input {		input {
	leaf abstract-node {		leaf abstract-node {
	type leafref {		type leafref {
	path "/nw:networks/nw:network/nw:node/tet:te-node-id";		path "/nw:networks/nw:network/nw:node/tet:te-node-id";
	}		}
	description		description
	"a reference to the abstract node in TE Topology";		"A reference to the abstract node in TE Topology";
	}		}
	list vn-member-list {		list vn-member-list {
	key "vn-member-id";		key "vn-member-id";
	description		description
	"List of VN-members in a VN";		"List of VN-members in a VN";
	uses vn-member;		uses vn-member;
	}		}
	uses vn-policy;		uses vn-policy;
	}		}
	output {		output {
	skipping to change at page 25, line 51 ¶		skipping to change at page 26, line 41 ¶
	default "false";		default "false";
	description		description
	"Is the vn-member is selected among the multi-src/dest		"Is the vn-member is selected among the multi-src/dest
	options";		options";
	}		}
	leaf compute-status {		leaf compute-status {
	type identityref {		type identityref {
	base vn-compute-state-type;		base vn-compute-state-type;
	}		}
	description		description
	"VN-member compute state.";		"The VN-member compute state.";
	}		}
	}		}
	}		}
	} //vn-compute		} //vn-compute
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. JSON Example		7. JSON Example
	This section provides json implementation examples as to how VN YANG		This section provides json implementation examples as to how VN YANG
	model and TE topology model are used together to instantiate virtual		model and TE topology model are used together to instantiate virtual
	networks.		networks.
	The example in this section includes following VN		The example in this section includes following VN
	skipping to change at page 50, line 41 ¶		skipping to change at page 51, line 33 ¶
	--------------------------------------------------------------------		--------------------------------------------------------------------
	name: ietf-vn		name: ietf-vn
	namespace: urn:ietf:params:xml:ns:yang:ietf-vn		namespace: urn:ietf:params:xml:ns:yang:ietf-vn
	prefix: vn		prefix: vn
	reference: RFC XXXX (TDB)		reference: RFC XXXX (TDB)
	--------------------------------------------------------------------		--------------------------------------------------------------------
	10. Acknowledgments		10. Acknowledgments
	The authors would like to thank Xufeng Liu and Adrian Farrel for		The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch,
	their helpful comments and valuable suggestions.		and Kenichi Ogaki for their helpful comments and valuable
			suggestions.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-teas-yang-te]		[I-D.ietf-teas-yang-te]
	Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,		Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
	"A YANG Data Model for Traffic Engineering Tunnels and		"A YANG Data Model for Traffic Engineering Tunnels and
	Interfaces", draft-ietf-teas-yang-te-22 (work in		Interfaces", draft-ietf-teas-yang-te-23 (work in
	progress), November 2019.		progress), March 2020.
	[I-D.ietf-teas-yang-te-topo]		[I-D.ietf-teas-yang-te-topo]
	Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and		Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
	O. Dios, "YANG Data Model for Traffic Engineering (TE)		O. Dios, "YANG Data Model for Traffic Engineering (TE)
	Topologies", draft-ietf-teas-yang-te-topo-22 (work in		Topologies", draft-ietf-teas-yang-te-topo-22 (work in
	progress), June 2019.		progress), June 2019.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.		<https://www.rfc-editor.org/info/rfc6242>.
			[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
			RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
			[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
			RFC 7950, DOI 10.17487/RFC7950, August 2016,
			<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 RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
	[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.,
			and R. Wilton, "Network Management Datastore Architecture
			(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
			<https://www.rfc-editor.org/info/rfc8342>.
	[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,		[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
	Ananthakrishnan, H., and X. Liu, "A YANG Data Model for		Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
	Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March		Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
	2018, <https://www.rfc-editor.org/info/rfc8345>.		2018, <https://www.rfc-editor.org/info/rfc8345>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
			"Common YANG Data Types for Traffic Engineering",
			RFC 8776, DOI 10.17487/RFC8776, June 2020,
			<https://www.rfc-editor.org/info/rfc8776>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-ccamp-l1csm-yang]		[I-D.ietf-ccamp-l1csm-yang]
	Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D.		Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D.
	Ceccarelli, "A YANG Data Model for L1 Connectivity Service		Ceccarelli, "A YANG Data Model for L1 Connectivity Service
	Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in		Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in
	progress), September 2019.		progress), March 2020.
	[I-D.ietf-teas-actn-pm-telemetry-autonomics]		[I-D.ietf-teas-actn-pm-telemetry-autonomics]
	Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,		Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,
	and D. Ceccarelli, "YANG models for VN/TE Performance		and D. Ceccarelli, "YANG models for VN/TE Performance
	Monitoring Telemetry and Scaling Intent Autonomics",		Monitoring Telemetry and Scaling Intent Autonomics",
	draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in		draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in
	progress), October 2019.		progress), March 2020.
	[I-D.ietf-teas-te-service-mapping-yang]		[I-D.ietf-teas-te-service-mapping-yang]
	Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D.,		Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D.,
	and J. Tantsura, "Traffic Engineering (TE) and Service		and J. Tantsura, "Traffic Engineering (TE) and Service
	Mapping Yang Model", draft-ietf-teas-te-service-mapping-		Mapping Yang Model", draft-ietf-teas-te-service-mapping-
	yang-02 (work in progress), September 2019.		yang-03 (work in progress), March 2020.
	[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,		[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
	Ceccarelli, D., and X. Zhang, "Problem Statement and		Ceccarelli, D., and X. Zhang, "Problem Statement and
	Architecture for Information Exchange between		Architecture for Information Exchange between
	Interconnected Traffic-Engineered Networks", BCP 206,		Interconnected Traffic-Engineered Networks", BCP 206,
	RFC 7926, DOI 10.17487/RFC7926, July 2016,		RFC 7926, DOI 10.17487/RFC7926, July 2016,
	<https://www.rfc-editor.org/info/rfc7926>.		<https://www.rfc-editor.org/info/rfc7926>.
	[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,		[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
	"YANG Data Model for L3VPN Service Delivery", RFC 8299,		"YANG Data Model for L3VPN Service Delivery", RFC 8299,
	DOI 10.17487/RFC8299, January 2018,		DOI 10.17487/RFC8299, January 2018,
	<https://www.rfc-editor.org/info/rfc8299>.		<https://www.rfc-editor.org/info/rfc8299>.
	[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models		[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
	Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,		Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
	<https://www.rfc-editor.org/info/rfc8309>.		<https://www.rfc-editor.org/info/rfc8309>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.
	[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for		[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
	Abstraction and Control of TE Networks (ACTN)", RFC 8453,		Abstraction and Control of TE Networks (ACTN)", RFC 8453,
	DOI 10.17487/RFC8453, August 2018,		DOI 10.17487/RFC8453, August 2018,
	<https://www.rfc-editor.org/info/rfc8453>.		<https://www.rfc-editor.org/info/rfc8453>.
	[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.		[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
	Yoon, "Information Model for Abstraction and Control of TE		Yoon, "Information Model for Abstraction and Control of TE
	Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,		Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
	September 2018, <https://www.rfc-editor.org/info/rfc8454>.		September 2018, <https://www.rfc-editor.org/info/rfc8454>.
	[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG		[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
	Data Model for Layer 2 Virtual Private Network (L2VPN)		Data Model for Layer 2 Virtual Private Network (L2VPN)
	Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October		Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
	2018, <https://www.rfc-editor.org/info/rfc8466>.		2018, <https://www.rfc-editor.org/info/rfc8466>.
	Appendix A. Contributors Addresses		Appendix A. Performance Constraints
			At the time of creation of VN, it is natural to provide VN level
			constraints and optimization criteria. It should be noted that this
			YANG model rely on the TE-Topology Model [I-D.ietf-teas-yang-te-topo]
			by using a reference to an abstract node to achieve this. Further,
			connectivity-matrix structure is used to assign the constraints and
			optimization criteria include delay, jitter etc. [RFC8776] define
			some of the metric-types already and future documents are meant to
			augment it.
			Appendix B. Contributors Addresses
	Qin Wu		Qin Wu
	Huawei Technologies		Huawei Technologies
	Email: bill.wu@huawei.com		Email: bill.wu@huawei.com
	Peter Park		Peter Park
	KT		KT
	Email: peter.park@kt.com		Email: peter.park@kt.com
	Haomian Zheng		Haomian Zheng
	Huawei Technologies		Huawei Technologies
End of changes. 111 change blocks.
	152 lines changed or deleted		231 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/