< draft-lee-rtgwg-actn-applicability-enhanced-vpn-01.txt		draft-lee-rtgwg-actn-applicability-enhanced-vpn-02.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 (Editor)
	Huawei		Huawei
	Expires: November 14, 2018 Jeff Tansura		Expires: December 29, 2018 Jeff Tansura
	Nuage		Nuage
	Qin Wu		Qin Wu
	Huawei		Huawei
	Daniele Ceccarelli		Daniele Ceccarelli
	Ericsson		Ericsson
	May 14, 2018		June 29, 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-01		draft-lee-rtgwg-actn-applicability-enhanced-vpn-02
	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 13 ¶		skipping to change at page 2, line 13 ¶
	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 November 14, 2018.		This Internet-Draft will expire on December 29, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	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.............................10		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...................................11
	3.2. Guaranteed Performance...................................11		3.2. Guaranteed Performance...................................11
	3.3. Integration..............................................13		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.................................................15		3.6. The Gaps.................................................15
	4. Security Considerations.......................................15		4. Security Considerations.......................................16
	5. IANA Considerations...........................................16		5. IANA Considerations...........................................17
	6. Acknowledgements..............................................16		6. Acknowledgements..............................................17
	7. References....................................................16		7. References....................................................17
	7.1. Informative References...................................16		7.1. Informative References...................................17
	8. Contributors..................................................18		8. Contributors..................................................18
	Authors' Addresses...............................................18		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.
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 34 ¶
	The framework for ACTN [actn-framework] includes a reference		The framework for ACTN [actn-framework] includes a reference
	architecture that has been adapted for Figure 1 in this document, it		architecture that has been adapted for Figure 1 in this document, it
	describes the functional entities and methods for the coordination		describes the functional entities and methods for the coordination
	of resources across multiple domains, to provide end-to-end		of resources across multiple domains, to provide end-to-end
	services, components include:		services, components include:
	o Customer Network Controller (CNC);		o Customer Network Controller (CNC);
	o Multi-domain Service Coordinator (MDSC);		o Multi-domain Service Coordinator (MDSC);
	o Provisional Network Controller (PNC).		o Provisioning Network Controller (PNC).
	--------- --------- ---------		--------- --------- ---------
	| CNC-A | | CNC-B | | CNC-C |		| CNC-A | | CNC-B | | CNC-C |
	--------- --------- ---------		--------- --------- ---------
	\ | /		\ | /
	\__________ |-CMI I/F __________/		\__________ |-CMI I/F __________/
	\ | /		\ | /
	-------------------------		-------------------------
	| MDSC |		| MDSC |
	-------------------------		-------------------------
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 29 ¶
	create a binding relationship across a Layer-3 Service Model [L3sm],		create a binding relationship across a Layer-3 Service Model [L3sm],
	Layer-2 Service Model [L2SM], Layer-1 Service Model [L1CSM], and TE		Layer-2 Service Model [L2SM], Layer-1 Service Model [L1CSM], and TE
	Tunnel model [TE-tunnel], via a generic ACTN Virtual Network (VN)		Tunnel model [TE-tunnel], via a generic ACTN Virtual Network (VN)
	model [actn-vn].		model [actn-vn].
	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
	service model with TE-specific parameters. This binding will
	facilitate a seamless service operation with underlay-TE network
	visibility. The TE-service model developed in this document can also
	be extended to support other services including L2SM, and L1CSM.
	+---------+ +-------------+ +----------+		+---------+ +-------------+ +----------+
	| L3SM | <------> | | <-----> | ACTN VN |		| L3SM | <------> | | <-----> | ACTN VN |
	+---------+ | | | Model |		+---------+ | | | Model |
	| | +----------+		| | +-----^----+
	| |		| | |
	+---------+ | TE-Service | +----------+		+---------+ | TE-Service | +-----v----+
	| L2SM | <------> |Mapping Model| <-----> | TE-Topo |		| L2SM | <------> |Mapping Model| <-----> | TE-Topo |
	+---------+ | | | Model |		+---------+ | | | Model |
	| | +----------+		| | +----------+
	| |		| |
	+---------+ | | +----------+		+---------+ | | +----------+
	| L1CSM | <------> | | <-----> | TE-Tunnel|		| L1CSM | <------> | | <-----> | TE-Tunnel|
	+---------+ | | | Model |		+---------+ | | | Model |
	+-------------+ +----------+		+-------------+ +----------+
	Figure 5: TE-Service Mapping ([te-service-mapping])		Figure 5: TE-Service Mapping ([te-service-mapping])
			The TE-service mapping model [te-service-map] is needed to bind
			L1/2/3 VPN specific service requirements and policies pertaining to
			TE-specific parameters. For example, the model can express the
			isolation requirement for each VPN service instance. Some VPN
			service would require a strict hard isolation with deterministic
			characteristic. In such case the underlay TE networks has to find
			end-to-end tunnels/LSPs that satisfy this particular isolation
			requirement.
			This binding will facilitate a seamless service operation with
			underlay-TE network visibility. The TE-service model developed in
			this document can also be extended to support other services
			including L2SM, and L1CSM.
	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 model.		monitoring data relevant for its VN via the YANG subscription 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
	skipping to change at page 10, line 39 ¶		skipping to change at page 11, line 4 ¶
	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] and the TE-service mapping model		The ACTN VN YANG model [actn-vn] and the TE-service mapping model
	[te-service-mapping] fulfill the isolation requirement by providing		[te-service-mapping] fulfill the isolation requirement by providing
	the features.		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)
	o Each VN is instantiated with proper isolation requirement		o Each VN is instantiated with proper isolation requirement
	mapping introduced by the TE-service mapping model [te-		mapping introduced by the TE-service mapping model [te-
	service-mapping]. This mapping can support hard isolation		service-mapping]. This mapping can support:
	(i.e., dedicated TE resources in all layers (e.g., packet and
	optical)), soft isolation (i.e., optical layer may be shared		o hard isolation with deterministic characteristics (e.g.,
	while packet layer is dedicated) and no isolation (i.e.,		this case may need optical bypass tunnel to guarantee
	sharing with other VN).		latency with no jitter);
			o hard isolation (i.e., dedicated TE resources in all
			layers (e.g., packet and optical));
			o soft isolation (i.e., optical layer may be shared while
			packet layer is dedicated);
			o no isolation (i.e., sharing with other VN).
	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] and [te-topo] allow		to assure the performance guarantee. [actn-vn] and [te-topo] allow
	configuration of several parameters that may affect the VN		configuration of several parameters that may affect the VN
	performance objectives. Among the performance-related parameters per		performance objectives. Among the performance-related parameters per
	a VN level provided by [actn-vn] and [te-topo] are as follows:		a VN level provided by [actn-vn] and [te-topo] are as follows:
	o Bandwidth		o Bandwidth
	skipping to change at page 14, line 6 ¶		skipping to change at page 14, line 20 ¶
	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
	+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-		+--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id
	id		+--rw vn-member-list* [vn-member-id]
	+--rw vn-member-list* [vn-member-id]		| +--rw vn-member-id uint32
	| +--rw vn-member-id uint32		| +--rw src
	| +--rw src		| | +--rw src? -> /actn/ap/access-point-list/access-point-id
	| | +--rw src? -> /actn/ap/access-point-list/access-		| | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
	point-id		| | +--rw multi-src? boolean {multi-src-dest}?
	| | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-		| +--rw dest
	ap-id		| | +--rw dest? -> /actn/ap/access-point-list/access-point-id
	| | +--rw multi-src? boolean {multi-src-dest}?		| | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id
	| +--rw dest		| | +--rw multi-dest? boolean {multi-src-dest}?
	| | +--rw dest? -> /actn/ap/access-point-list/access-		| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-
	point-id		node-attributes/connectivity-matrices/connectivity-matrix/id
	| | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-		| +--ro oper-status? identityref
	ap-id		+--ro if-selected? boolean {multi-src-dest}?
	| | +--rw multi-dest? boolean {multi-src-dest}?		+--rw admin-status? identityref
	| +--rw connetivity-matrix-id? ->		+--ro oper-status? identityref
	/nw:networks/network/node/tet:te/te-node-attributes/connectivity-		+--rw vn-level-diversity? vn-disjointness
	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 via TE-topology's [TE-
			Topo] Connectivity Matrix's construct.
	+--rw vn		For some VN members of a VN, the customers are allowed to configure
	+--rw vn-list* [vn-id]		the actual path (i.e., detailed virtual nodes and virtual links)
	+--rw vn-id uint32		over the VN/abstract topology agreed mutually between CNC and MDSC
	+--rw vn-name? string		prior to or a topology created by the MDSC as part of VN
	+--rw vn-topology-id? te-types:te-topology-id		instantiation. Type 2 VN is always built on top of a Type 1 VN. If a
	| {type-2}?		Type 2 VN is desired for some or all of VN members of a type 1 VN
	+--rw vn-member-list* [vn-member-id]		(see the example in Section 2.1 of [ACTN-VN]), the TE-topology model
	| +--rw vn-member-id uint32		can provide the following abstract topology (that consists of
	.........		virtual nodes and virtual links) which is built on top of the Type 1
			VN so that customers can configure path over this topology.
	| +--rw path {type-2}?		+----------------------------------------------+
	| | +--rw path-element* [path-element-id]		| S1 S2 |
	| | +--rw path-element-id uint32		| O---------------O |
	| | +--rw index? uint32		| ________/ \______ \ |
	| | +--rw address? te-types:te-tp-id		| / \ \ |
	| | +--rw hop-type? te-types:te-hop-type		|S3 / \ S4 \ S5 |
			L1----|-O----------------------O---------O-----------|------L4
			| \ \ \ |
			| \ \ \ |
			| \ S6 \ S7 \ S8 |
			| O ----------------O---------O-------|------L7
			| / \ / \ ____/ |
			|S9 / \ /S10 \ / |
			L2-----|---O-----O---------------------O--------------|------L8
			| / S11 |
			L3-----|-- |
			| |
			+----------------------------------------------+
			Figure 3. Type 2 topology
	3.6. The Gaps		3.6. The Gaps
	ACTN allows the customers/users to subscribe and monitor VN/Tunnel		ACTN allows the customers/users to subscribe and monitor VN/Tunnel
	level performance data such as latency. The low level latency and		level performance data such as latency. The low level latency and
	isolation characteristics that are sought by some VPN+ users such as		isolation characteristics that are sought by some VPN+ users such as
	steering packets through specific queues resources are not in the		steering packets through specific queues resources are not in the
	scope of ACTN.		scope of ACTN.
	This implies that the device-level performance data such as queuing		This implies that the device-level performance data such as queuing
	skipping to change at page 16, line 43 ¶		skipping to change at page 17, line 26 ¶
	7. References		7. References
	7.1. Informative References		7.1. Informative References
	[actn-framework] Ceccarelli, D. and Y. Lee, "Framework for		[actn-framework] Ceccarelli, D. and Y. Lee, "Framework for
	Abstraction and Control of Traffic Engineered Networks",		Abstraction and Control of Traffic Engineered Networks",
	draft-ietf-teas-actn-framework, work in progress, February		draft-ietf-teas-actn-framework, work in progress, February
	2017.		2017.
	[te-service-mapping] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic		[te-service-map] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic
	Engineering and Service Mapping Yang Model", draft-lee-		Engineering and Service Mapping Yang Model", draft-lee-
	teas-te-service-mapping-yang, work in progress.		teas-te-service-mapping-yang, work in progress.
	[actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN		[actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN
	Operation", draft-lee-teas-actn-vn-yang, work in progress.		Operation", draft-lee-teas-actn-vn-yang, work in progress.
	[actn-info] Y. Lee, S. Belotti (Editors), "Information Model for		[actn-info] Y. Lee, S. Belotti (Editors), "Information Model for
	Abstraction and Control of TE Networks (ACTN)", draft-		Abstraction and Control of TE Networks (ACTN)", draft-
	ietf-teas-actn-info-model, work in progress.		ietf-teas-actn-info-model, work in progress.
	skipping to change at page 17, line 22 ¶		skipping to change at page 18, line 5 ¶
	work in progress.		work in progress.
	[vpn+] S. Bryant, and D. Jie, "Enhanced Virtual Private Networks		[vpn+] S. Bryant, and D. Jie, "Enhanced Virtual Private Networks
	(VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in		(VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in
	progress.		progress.
	[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic		[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
	Engineering Tunnels and Interfaces", draft-ietf-teas-yang-		Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
	te, work in progress.		te, work in progress.
			[TE-topo] X. Liu, et. al, "YANG Data Model for Traffic Engineering
			(TE) Topologies", draft-ietf-teas-yang-te-topo, work in
			progress.
	[L3SM] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for		[L3SM] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for
	L3VPN service delivery", draft-ietf-l3sm-l3vpn-service-		L3VPN service delivery", draft-ietf-l3sm-l3vpn-service-
	model, work in progress.		model, work in progress.
	[L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service		[L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service
	Delivery", draft-ietf-l2sm-l2vpn-service-model, work in		Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
	progress.		progress.
	[L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity		[L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity
	Service Model (L1CSM)", draft-fioccola-ccamp-l1csm-yang,		Service Model (L1CSM)", draft-fioccola-ccamp-l1csm-yang,
	work in progress.		work in progress.
	8. Contributors		8. Contributors
	Authors' Addresses		Authors' Addresses
	Daniel King		Daniel King
	Lancaster University		Lancaster University
	Email: d.king@lancaster.ac.uk		Email: d.king@lancaster.ac.uk
	Young Lee		Young Lee (Editor)
	Huawei		Huawei
	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.
End of changes. 21 change blocks.
	74 lines changed or deleted		100 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/