< draft-lee-rtgwg-actn-applicability-enhanced-vpn-00.txt		draft-lee-rtgwg-actn-applicability-enhanced-vpn-01.txt >
	RTGWG Working Group Daniel King		RTGWG Working Group Daniel King
	Internet Draft Lancaster University		Internet Draft Lancaster University
	Intended status: Informational		Intended status: Informational
	Young Lee		Young Lee
	Huawei		Huawei
	Expires: May 12, 2018 Jeff Tansura		Expires: November 14, 2018 Jeff Tansura
	Futurewei		Nuage
	Qin Wu		Qin Wu
	Huawei		Huawei
	November 12, 2017		Daniele Ceccarelli
			Ericsson
			May 14, 2018
	Applicability of Abstraction and Control of Traffic Engineered		Applicability of Abstraction and Control of Traffic Engineered
	Networks (ACTN) to Enhanced VPN		Networks (ACTN) to Enhanced VPN
	draft-lee-rtgwg-actn-applicability-enhanced-vpn-00		draft-lee-rtgwg-actn-applicability-enhanced-vpn-01
	Abstract		Abstract
	The Abstraction and Control of Traffic Engineered Networks (ACTN)		The Abstraction and Control of Traffic Engineered Networks (ACTN)
	defines an SDN-based architecture that relies on the concepts of		defines an SDN-based architecture that relies on the concepts of
	network and service abstraction to detach network and service		network and service abstraction to detach network and service
	control from the underlying data plane.		control from the underlying data plane.
	This document outlines the overview of ACTN capability and the		This document outlines the overview of ACTN capability and the
	applicability of ACTN to Enhanced VPN. In particular, this document		applicability of ACTN to Enhanced VPN. In particular, this document
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 6 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	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 May 12, 2018.		This Internet-Draft will expire on November 14, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 37 ¶		skipping to change at page 2, line 40 ¶
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	2. ACTN Overview..................................................3		2. ACTN Overview..................................................3
	2.1. ACTN Virtual Network......................................4		2.1. ACTN Virtual Network......................................4
	2.2. Examples of ACTN Delivering Types of Virtual Networks.....5		2.2. Examples of ACTN Delivering Types of Virtual Networks.....5
	2.2.1. ACTN Used for Virtual Private Line Model.............6		2.2.1. ACTN Used for Virtual Private Line Model.............6
	2.2.2. ACTN Used for VPN Delivery Model.....................7		2.2.2. ACTN Used for VPN Delivery Model.....................7
	2.2.3. ACTN Used to Deliver a Virtual Customer Network......8		2.2.3. ACTN Used to Deliver a Virtual Customer Network......8
	2.3. Service Mapping from TE to ACTN VN Models.................9		2.3. Service Mapping from TE to ACTN VN Models.................9
	2.4. ACTN VN KPI telemetry Models..............................9		2.4. ACTN VN KPI telemetry Models.............................10
	3. Enhanced VPN and ACTN.........................................10		3. Enhanced VPN and ACTN.........................................10
	3.1. Isolation between VPNs...................................10		3.1. Isolation between VPNs...................................10
	3.2. Guaranteed Performance...................................11		3.2. Guaranteed Performance...................................11
	3.3. Integration..............................................12		3.3. Integration..............................................13
	3.4. Dynamic Configuration....................................13		3.4. Dynamic Configuration....................................13
	3.5. Customized Control Plane.................................14		3.5. Customized Control Plane.................................14
	3.6. The Gaps.................................................14		3.6. The Gaps.................................................15
	4. Security Considerations.......................................15		4. Security Considerations.......................................15
	5. IANA Considerations...........................................15		5. IANA Considerations...........................................16
	6. Acknowledgements..............................................16		6. Acknowledgements..............................................16
	7. References....................................................16		7. References....................................................16
	7.1. Informative References...................................16		7.1. Informative References...................................16
	8. Contributors..................................................17		8. Contributors..................................................18
	Authors' Addresses...............................................17		Authors' Addresses...............................................18
	1. Introduction		1. Introduction
	The Abstraction and Control of Traffic Engineered Networks (ACTN)		The Abstraction and Control of Traffic Engineered Networks (ACTN)
	defines an SDN-based architecture that relies on the concepts of		defines an SDN-based architecture that relies on the concepts of
	network and service abstraction to detach network and service		network and service abstraction to detach network and service
	control from the underlying data plane.		control from the underlying data plane.
	This document outlines the overview of ACTN capability and the		This document outlines the overview of ACTN capability and the
	applicability of ACTN to Enhanced VPN. In particular, this document		applicability of ACTN to Enhanced VPN. In particular, this document
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 46 ¶
	Primitives (capabilities and messages) have been provided to support		Primitives (capabilities and messages) have been provided to support
	the different ACTN network control functions that will enable		the different ACTN network control functions that will enable
	virtual network. These include: topology request/query, VN service		virtual network. These include: topology request/query, VN service
	request, path computation and connection control, VN service policy		request, path computation and connection control, VN service policy
	negotiation, enforcement, routing options. [actn-info]		negotiation, enforcement, routing options. [actn-info]
	2.2. Examples of ACTN Delivering Types of Virtual Networks		2.2. Examples of ACTN Delivering Types of Virtual Networks
	In examples below the ACTN framework is used to provide control,		In examples below the ACTN framework is used to provide control,
	management and orchestration for the virtual network life-cycle, and		management and orchestration for the virtual network life-cycle, and
	the connectivity . These dynamic and highly flexible, end-to-end and		the connectivity. These dynamic and highly flexible, end-to-end and
	dedicated virtual network utilizing common physical infrastructure,		dedicated virtual network utilizing common physical infrastructure,
	and according to vertical-specific requirements.		and according to vertical-specific requirements.
	The rest of this section provides three examples of using ACTN to		The rest of this section provides three examples of using ACTN to
	achieve different scenarios of ACTN for virtual network. All three		achieve different scenarios of ACTN for virtual network. All three
	scenarios can be scaled up in capacity or be subject to topology		scenarios can be scaled up in capacity or be subject to topology
	changes as well as changes from customer requirements perspective.		changes as well as changes from customer requirements perspective.
	2.2.1. ACTN Used for Virtual Private Line Model		2.2.1. ACTN Used for Virtual Private Line Model
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 35 ¶
	o Agile: on-demand where the customer needs connectivity and		o Agile: on-demand where the customer needs connectivity and
	fully adjustable bandwidth.		fully adjustable bandwidth.
	(Customer VPL Request)		(Customer VPL Request)
	|		|
	---------		---------
	| CNC-A |		| CNC-A |
	Boundary ---------		Boundary ---------
	Between ====================|====================		Between ====================|====================
	Customer & |		Customer & |
	Network Provider --------		Network Operator --------
	| MDSC |		| MDSC |
	--------		--------
	__|__		__|__
	Site A ( PNC ) Site B		Site A ( PNC ) Site B
	------ ( ) ------		------ ( ) ------
	|vCE1|=============( Phys. )=============|vCE2|		|vCE1|=============( Phys. )=============|vCE2|
	------ ( Net ) ------		------ ( Net ) ------
	\ ----- /		\ ----- /
	\ || /		\ || /
	\ || /		\ || /
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 31 ¶
	delegated to the customer managed CNC.		delegated to the customer managed CNC.
	---------------- ----------------		---------------- ----------------
	| Site-A Users |___________ ____________| Site-B Users |		| Site-A Users |___________ ____________| Site-B Users |
	---------------- | | ----------------		---------------- | | ----------------
	-------		-------
	|CNC-A|		|CNC-A|
	Boundary -------		Boundary -------
	Between ==========================|==========================		Between ==========================|==========================
	Customer & |		Customer & |
	Network Provider |		Network Operator |
	|		|
	---------------		---------------
	| MDSC |		| MDSC |
	---------------		---------------
	_________/ | \__________		_________/ | \__________
	/ | \		/ | \
	/ | \		/ | \
	--------- --------- ---------		--------- --------- ---------
	| PNC | | PNC | | PNC |		| PNC | | PNC | | PNC |
	--------- --------- ---------		--------- --------- ---------
	skipping to change at page 8, line 41 ¶		skipping to change at page 8, line 44 ¶
	| CNC |---------->( Network 2 )		| CNC |---------->( Network 2 )
	--------------- _(_________ )		--------------- _(_________ )
	--------------- ( Virtual )_)		--------------- ( Virtual )_)
	| CNC |----------->( Network 2 ) ^		| CNC |----------->( Network 2 ) ^
	--------------- ( ) :		--------------- ( ) :
	^ (___________) :		^ (___________) :
	| ^ ^ :		| ^ ^ :
	Boundary | : : :		Boundary | : : :
	Between ==========|========================:====:====:========		Between ==========|========================:====:====:========
	Customer & | : : :		Customer & | : : :
	Network Provider | : : :		Network Operator | : : :
	v : : :		v : : :
	--------------- : :....:		--------------- : :....:
	| MDSC | : :		| MDSC | : :
	--------------- : :		--------------- : :
	^ ---^------ ...		^ ---^------ ...
	| ( ) .		| ( ) .
	v ( Physical ) .		v ( Physical ) .
	---------------- ( Network ) .		---------------- ( Network ) .
	| PNC |<------> ( ) ---^------		| PNC |<------> ( ) ---^------
	---------------- | -------- ( )		---------------- | -------- ( )
	| |-- ( Physical )		| |-- ( Physical )
	| PNC |<------------------------->( Network )		| PNC |<------------------------->( Network )
	--------------- ( )		--------------- ( )
	--------		--------
	Figure 4: Virtual Customer Networks		Figure 4: Virtual Customer Networks
	2.3. Service Mapping from TE to ACTN VN Models		2.3. Service Mapping from TE to ACTN VN Models
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 33 ¶
	The ACTN VN YANG model [actn-vn] is a generic virtual network		The ACTN VN YANG model [actn-vn] is a generic virtual network
	service model that allows customers (internal or external) to create		service model that allows customers (internal or external) to create
	a VN that meets the customer's service objective with various		a VN that meets the customer's service objective with various
	constraints.		constraints.
	The TE-service mapping model is needed to bind L3VPN specific		The TE-service mapping model is needed to bind L3VPN specific
	service model with TE-specific parameters. This binding will		service model with TE-specific parameters. This binding will
	facilitate a seamless service operation with underlay-TE network		facilitate a seamless service operation with underlay-TE network
	visibility. The TE-service model developed in this document can also		visibility. The TE-service model developed in this document can also
	be extended to support other services including L2SM, and future		be extended to support other services including L2SM, and L1CSM.
	transport network service models.
	----------- --------------- ------------		+---------+ +-------------+ +----------+
	| L3SM | <------> | | <-----> | TE-Tunnel|		| L3SM | <------> | | <-----> | ACTN VN |
	----------- | | | Model |		+---------+ | | | Model |
	| TE-Service | ------^-----		| | +----------+
	|Mapping Model| |		| |
	----------- | | ------v-----		+---------+ | TE-Service | +----------+
	| L2SM | <------> | | <-----> | ACTN VN |		| L2SM | <------> |Mapping Model| <-----> | TE-Topo |
	----------- --------------- | Model |		+---------+ | | | Model |
	------------		| | +----------+
	Figure 5: TE-Service Mapping ([te-service-mapping])		| |
			+---------+ | | +----------+
			| L1CSM | <------> | | <-----> | TE-Tunnel|
			+---------+ | | | Model |
			+-------------+ +----------+
			Figure 5: TE-Service Mapping ([te-service-mapping])
	2.4. ACTN VN KPI telemetry Models		2.4. ACTN VN KPI telemetry Models
	The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is to		The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is to
	provide YANG models so that customer can define key performance		provide YANG models so that customer can define key performance
	monitoring data relevant for its VN via the YANG subscription		monitoring data relevant for its VN via the YANG subscription model.
	model.
	Key characteristics of [actn-pm-telemetry] include:		Key characteristics of [actn-pm-telemetry] include:
	o an ability to provide scalable VN-level telemetry aggregation		o an ability to provide scalable VN-level telemetry aggregation
	based on customer-subscription model for key performance		based on customer-subscription model for key performance
	parameters defined by the customer;		parameters defined by the customer;
	o an ability to facilitate proactive re-optimization and		o an ability to facilitate proactive re-optimization and
	reconfiguration of VNs based on network		reconfiguration of VNs based on network
	autonomic traffic engineering scaling configuration		autonomic traffic engineering scaling configuration
	mechanism.		mechanism.
	3. Enhanced VPN and ACTN		3. Enhanced VPN and ACTN
	This section discusses how the advanced features of ACTN discussed		This section discusses how the advanced features of ACTN discussed
	in Section 2 can fulfill the enhanced VPN requirements defined in		in Section 3 can fulfill the enhanced VPN requirements defined in
	[vpn+]. Key requirements of the enhanced VPN include:		[vpn+]. Key requirements of the enhanced VPN include:
	1. Isolation between VPNs		1. Isolation between VPNs
	2. Guaranteed Performance		2. Guaranteed Performance
	3. Integration		3. Integration
	4. Dynamic Configuration		4. Dynamic Configuration
	5. Customized Control Plane		5. Customized Control Plane
	Simple creation, deletion and modification of the services.		Simple creation, deletion and modification of the services.
	Control over VPN Seamless integration of both physical and virtual		Control over VPN Seamless integration of both physical and virtual
	network and service functions		network and service functions
	In the subsequent sections, we discuss how each requirement can be		In the subsequent sections, we discuss how each requirement can be
	fulfilled by the ACTN features and the gaps that remain to be solved		fulfilled by the ACTN features and the gaps that remain to be solved
	if applicable.		if applicable.
	3.1. Isolation between VPNs		3.1. Isolation between VPNs
	The ACTN VN YANG model [actn-vn] fulfills the isolation requirement		The ACTN VN YANG model [actn-vn] and the TE-service mapping model
	by providing the features.		[te-service-mapping] fulfill the isolation requirement by providing
			the features.
	o Each VN is identified with a unique identifier (vn-id and vn-		o Each VN is identified with a unique identifier (vn-id and vn-
	name) and so is each VN member that belongs to the VN (vn-		name) and so is each VN member that belongs to the VN (vn-
	member-id).		member-id).
	o Each instantiated VN is managed and controlled independent of		o Each instantiated VN is managed and controlled independent of
	other VNs in the network with proper protection level		other VNs in the network with proper protection level
	(protection)		(protection)
	+--rw vn
	+--rw vn-list* [vn-id]		o Each VN is instantiated with proper isolation requirement
	+--rw vn-id uint32		mapping introduced by the TE-service mapping model [te-
	+--rw vn-name? string		service-mapping]. This mapping can support hard isolation
	+--rw vn-topology-id? te-types:te-topology-id		(i.e., dedicated TE resources in all layers (e.g., packet and
	| {type-2}?		optical)), soft isolation (i.e., optical layer may be shared
	+--rw vn-member-list* [vn-member-id]		while packet layer is dedicated) and no isolation (i.e.,
	| +--rw vn-member-id uint32		sharing with other VN).
	| +--rw src
	. . . .
	| +--rw dest
	. . . .
	| +--rw protection? Identityref
	3.2. Guaranteed Performance		3.2. Guaranteed Performance
	Performance objectives of a VN need first to be expressed in order		Performance objectives of a VN need first to be expressed in order
	to assure the performance guarantee. [actn-vn] allows configuration		to assure the performance guarantee. [actn-vn] and [te-topo] allow
	of several parameters that may affect the VN performance objectives.		configuration of several parameters that may affect the VN
	Among the performance-related parameters per a VN level provided by		performance objectives. Among the performance-related parameters per
	[actn-vn] are as follows:		a VN level provided by [actn-vn] and [te-topo] are as follows:
	o Bandwidth		o Bandwidth
	o Objective function (e.g., min cost path, min load path, etc.)		o Objective function (e.g., min cost path, min load path, etc.)
	o Metric Types and their threshold:		o Metric Types and their threshold:
	o TE cost, IGP cost, Hop count, or Unidirectional Delay (e.g.,		o TE cost, IGP cost, Hop count, or Unidirectional Delay (e.g.,
	can set all path delay <= threshold)		can set all path delay <= threshold)
	See the below actn-vn tree structure for configuration parameters		See the below actn-vn tree structure for the pointer for the
	for the pertinent performance data.		connectivity matrix identifier for each vn member in which the
			configuration parameters listed above is provisioned using [te-topo]
			model together with [te-tunnel] model in the network.
	+--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 objective-function? pcep:objective-function		+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id
	+--rw metric* [metric-type]		+--rw vn-member-list* [vn-member-id]
	| +--rw metric-type identityref		| +--rw vn-member-id uint32
	| +--rw limit		| +--rw src
	| | +--rw enabled? boolean		| | +--rw src? -> /actn/ap/access-point-list/access-point-id
	| | +--rw value? uint32		| | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
	| +--rw optimize		| | +--rw multi-src? boolean {multi-src-dest}?
	| +--rw enabled? boolean		| +--rw dest
	| +--rw value? uint32		| | +--rw dest? -> /actn/ap/access-point-list/access-point-
	+--rw bandwidth? te-types:te-bandwidth		id
			| | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
			| | +--rw multi-dest? boolean {multi-src-dest}?
			| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-
			node-attributes/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
	Once these requests are instantiated, the resources are committed		Once these requests are instantiated, the resources are committed
	and guaranteed through the life cycle of the VN.		and guaranteed through the life cycle of the VN.
	[actn-pm-telemetry] provides models that allow for key performance		[actn-pm-telemetry] provides models that allow for key performance
	telemetry configuration mechanisms per VN level, VN member level as		telemetry configuration mechanisms per VN level, VN member level as
	well as path/link level.		well as path/link level.
	The following tree structure from [actn-pm-telemetry] illustrates		The following tree structure from [actn-pm-telemetry] illustrates
	how performance data (e.g., delay, delay-variation, utilization,		how performance data (e.g., delay, delay-variation, utilization,
	etc.) can be subscribed per VN need and monitored via YANG push		etc.) can be subscribed per VN need and monitored via YANG push
	streaming mechanism.		streaming mechanism.
	module: ietf-actn-te-kpi-telemetry		module: ietf-actn-te-kpi-telemetry
	augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list:		augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list:
	+--rw vn-telemetry		+--ro vn-member-telemetry
	| +--rw grouping-op		+--ro unidirectional-delay? uint32
	| | +--rw delay-op? identityref		+--ro unidirectional-min-delay? uint32
	| | +--rw delay-variation-op? identityref		+--ro unidirectional-max-delay? uint32
	| | +--rw utilized-bandwidth-op? identityref		+--ro unidirectional-delay-variation? uint32
	| +--ro data		+--ro unidirectional-packet-loss? decimal64
	| +--ro one-way-delay? uint32		+--ro unidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32
	| +--ro two-way-delay? uint32		+--ro unidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32
	| +--ro one-way-delay-min? uint32		+--ro unidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32
	| +--ro one-way-delay-max? uint32		+--ro bidirectional-delay? uint32
	| +--ro two-way-delay-min? uint32		+--ro bidirectional-min-delay? uint32
	| +--ro two-way-delay-max? uint32		+--ro bidirectional-max-delay? uint32
	| +--ro one-way-delay-variation? uint32		+--ro bidirectional-delay-variation? uint32
	| +--ro two-way-delay-variation? uint32		+--ro bidirectional-packet-loss? decimal64
	| +--ro utilized-bandwidth? te-types:te-bandwidth		+--ro bidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32
			+--ro bidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32
			+--ro bidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32
			+--ro utilized-percentage? uint8
			+--ro vn-ref? -> /actn-vn:actn/vn/vn-list/vn-
			id
			+--ro vn-member-ref? -> /actn-vn:actn/vn/vn-list/vn-
			member-list/vn-member-id
			+--ro te-grouped-params* ->
			/te:te/tunnels/tunnel/state/te-kpi:te-telemetry/id
	......		......
	3.3. Integration		3.3. Integration
	ACTN provides mechanisms to correlate customer's VN and the actual		ACTN provides mechanisms to correlate customer's VN and the actual
	TE tunnels instantiated in the provider's network. Specifically,		TE tunnels instantiated in the provider's network. Specifically,
	o Link each VN member to actual TE tunnel		o Link each VN member to actual TE tunnel
	o Each VN can be monitored on a various level such as VN level, VN		o Each VN can be monitored on a various level such as VN level, VN
	member level, TE-tunnel level, and link/node level.		member level, TE-tunnel level, and link/node level.
	skipping to change at page 13, line 29 ¶		skipping to change at page 14, line 5 ¶
	o Dynamic control over VN the customer creates.		o Dynamic control over VN the customer creates.
	o Create, Modify, Delete		o Create, Modify, Delete
	See the following tree structure from [actn-vn] as an example for		See the following tree structure from [actn-vn] as an example for
	the dynamic configuration capability (write) VN creation, modify and		the dynamic configuration capability (write) VN creation, modify and
	delete. VN can be dynamically created/modified/deleted with		delete. VN can be dynamically created/modified/deleted with
	constraints such as metric types (e.g., delay), bandwidth,		constraints such as metric types (e.g., delay), bandwidth,
	protection, etc.		protection, etc.
	+--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
	| {type-2}?		+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-
	+--rw vn-member-list* [vn-member-id]		id
	| +--rw vn-member-id uint32		+--rw vn-member-list* [vn-member-id]
	........		| +--rw vn-member-id uint32
			| +--rw src
	+--rw objective-function? pcep:objective-function		| | +--rw src? -> /actn/ap/access-point-list/access-
	+--rw metric* [metric-type]		point-id
	| +--rw metric-type identityref		| | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-
	| +--rw limit		ap-id
	| | +--rw enabled? boolean		| | +--rw multi-src? boolean {multi-src-dest}?
	| | +--rw value? uint32		| +--rw dest
	| +--rw optimize		| | +--rw dest? -> /actn/ap/access-point-list/access-
	| +--rw enabled? boolean		point-id
	| +--rw value? uint32		| | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-
	+--rw bandwidth? te-types:te-bandwidth		ap-id
	+--rw protection? Identityref		| | +--rw multi-dest? boolean {multi-src-dest}?
			| +--rw connetivity-matrix-id? ->
			/nw:networks/network/node/tet:te/te-node-attributes/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
	3.5. Customized Control Plane		3.5. Customized Control Plane
	ACTN provides a YANG model that allows the customer network		ACTN provides a YANG model that allows the customer network
	controller (CNC) to control VN via type 2 operation. Type 2 VN		controller (CNC) to control VN via type 2 operation. Type 2 VN
	allows the customer to provision pertinent LSPs that connect their		allows the customer to provision pertinent LSPs that connect their
	endpoints over the customized VN topology dynamically.		endpoints over the customized VN topology dynamically.
	See the following tree structure from [actn-vn] as an example for		See the following tree structure from [actn-vn] as an example for
	the provisioning of LSPs over the VN topology:		the provisioning of LSPs over the VN topology:
	skipping to change at line 741 ¶		skipping to change at page 18, line 25 ¶
	Phone: (469)277-5838		Phone: (469)277-5838
	Email: leeyoung@huawei.com		Email: leeyoung@huawei.com
	Jeff Tansura		Jeff Tansura
	Futurewei		Futurewei
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Qin Wu		Qin Wu
	Huawei Technologies Co.,Ltd.		Huawei Technologies Co.,Ltd.
	Email: bill.wu@huawei.com		Email: bill.wu@huawei.com
			Daniele Ceccarelli
			Ericsson
			Email: daniele.ceccarelli@ericsson.com
End of changes. 28 change blocks.
	104 lines changed or deleted		136 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/