< draft-so-vepc-00.txt		draft-so-vepc-01.txt >
	INTERNET-DRAFT So et al		INTERNET-DRAFT So et al
	Intended Status: Proposed Standard Verizon		Intended Status: Proposed Standard Verizon
	Expires: November 2011 October 17, 2010		Expires: August 17, 2011 February 13, 2011
	VPN Extensions for Private Clouds		VPN Extensions for Private Clouds
	draft-so-vepc-00.txt		draft-so-vepc-01.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	material or to cite them other than as "work in progress."		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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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 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.
	Abstract		Abstract
	This contribution addresses the service providers requirements to		This contribution addresses the service providers requirements to
	support Cloud services interworking with the existing MPLS-based L2		support Cloud services interworking with the existing MPLS-based L2
	and L3 VPN services. Maintenance of virtual separation of the		and L3 VPN services. Maintenance of virtual separation of the
	traffic, data, and queries must be supported for the VPN customers		traffic, data, and queries must be supported for the VPN customers
	that are conscious of end-to-end security features and functions that		that are conscious of end-to-end security features and functions that
	VPN technologies provide today.		VPN technologies provide today.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2 Cloud Customer End to End Separation . . . . . . . . . . . . . . 3		2 Cloud Customer End to End Separation . . . . . . . . . . . . . . 3
	2.1. VPN Traffic Segregation Requirements . . . . . . . . . . . 3		2.1. VPN Traffic Segregation Requirements . . . . . . . . . . . 3
	2.2. Potential Solution . . . . . . . . . . . . . . . . . . . . 3		2.2. Potential Solution . . . . . . . . . . . . . . . . . . . . 4
	2.2.1. VPN Gateway Managed Connection Segregation . . . . . . 3		2.2.1. VPN Gateway Managed Connection Segregation . . . . . . 4
	2.2.2 solution using Provider Backbone Bridging (PBB) and		2.2.2 Solution using Provider Backbone Bridging (PBB) and
	Shortest Path Bridging (SPB) . . . . . . . . . . . . . 4		Shortest Path Bridging (SPB) . . . . . . . . . . . . . 4
	2.2.3 VPN Gateway Controlled Traffic Flow . . . . . . . . . . 4		2.2.3 VPN Gateway Controlled Traffic Flow . . . . . . . . . . 5
	2.2.4 Inter-VPN Interworking . . . . . . . . . . . . . . . . 4		2.2.4 Inter-VPN Interworking . . . . . . . . . . . . . . . . 5
	2.3. Cloud Services Virtualization . . . . . . . . . . . . . . . 4		2.3. Cloud Services Virtualization . . . . . . . . . . . . . . . 5
	2.3.1. Cloud Virtualization Requirements . . . . . . . . . . 4		2.3.1. Cloud Virtualization Requirements . . . . . . . . . . 5
	2.4. Cloud Services Restoration . . . . . . . . . . . . . . . . 5		2.4. Cloud Services Restoration . . . . . . . . . . . . . . . . 6
	2.5 Other Non-VPN Specific Areas . . . . . . . . . . . . . . . . 6		2.5 Other Non-VPN Specific Areas . . . . . . . . . . . . . . . . 6
	2.5.1. Cloud Traffic Load-Balancing and Congestion		2.5.1. Cloud Traffic Load-Balancing and Congestion
	Avoidance . . . . . . . . . . . . . . . . . . . . . . 6		Avoidance . . . . . . . . . . . . . . . . . . . . . . 6
	2.5.2. QoS Synchronization . . . . . . . . . . . . . . . . . 6		2.5.2. QoS Synchronization . . . . . . . . . . . . . . . . . 6
	2.5.3 Cross Layer Optimization . . . . . . . . . . . . . . . 6		2.5.3 Cross Layer Optimization . . . . . . . . . . . . . . . 7
	2.5.4 Automation end to end Configuration . . . . . . . . . . 6		2.5.4 Automation end to end Configuration . . . . . . . . . . 7
	2.6. End-to-End Quality of Experience (ETE-QoE) . . . . . . . . 6		2.6. End-to-End Quality of Experience (ETE-QoE) . . . . . . . . 7
	2.7. OAM Considerations . . . . . . . . . . . . . . . . . . . . 7		2.7. OAM Considerations . . . . . . . . . . . . . . . . . . . . 7
	2.8. Work Item Considerations in IETF Clouds . . . . . . . . . . 7		2.8. Work Item Considerations in IETF Clouds . . . . . . . . . . 7
	3 Security Considerations . . . . . . . . . . . . . . . . . . . . 8		3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
	4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
	5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1 Normative References . . . . . . . . . . . . . . . . . . . 8		5.1 Normative References . . . . . . . . . . . . . . . . . . . 9
	5.2 Informative References . . . . . . . . . . . . . . . . . . 8		5.2 Informative References . . . . . . . . . . . . . . . . . . 9
	Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1 Introduction		1 Introduction
	Data center, WAN/MAN, and the end user are three of the components		Data center, WAN/MAN, and the end user are three of the components
	that make up the Cloud in the vision of Cloud Computing. However,		that make up the Cloud in the vision of Cloud Computing. However, the
	the existing technologies often treat each component as black boxes,		existing technologies often treat each component as black boxes,
	detached from each other. This fact limits the overall cohesiveness		detached from each other. This fact limits the overall cohesiveness
	of an end-to-end service. For example, the network often views the		of an end-to-end service. For example, the network often views the
	data center as a black box, meaning the network has no control or		data center as a black box, meaning the network has no control or
	visibility (from a standards point-of-view) into the data center.		visibility (from a standards point-of-view) into the data center. As
	As a network provider, a Cloud-service product may be offered		a network provider, a Cloud-service product may be offered across
	across multiple data centers globally, some of which may be owned by		multiple data centers globally, some of which may be owned by a
	a network provider while others may be owned by a partner/vendor. In		network provider while others may be owned by a partner/vendor. In
	addition, multiple Cloud-Service products can be offered in the same		addition, multiple Cloud-Service products can be offered in the same
	data centers. A list of the problems that this situation is causing		data centers. A list of the problems that this situation is causing
	the network provider/operator, especially for the existing VPN		the network provider/operator, especially for the existing VPN
	customers, is presented below. These must be addressed immediately,		customers, is presented below. These must be addressed immediately,
	in order for service providers to persuade the existing VPN customers		in order for service providers to persuade the existing VPN customers
	to leverage the deployed Cloud-based services.		to leverage the deployed Cloud-based services.
	1.1 Terminology		1.1 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2 Cloud Customer End to End Separation		2 Cloud Customer End to End Separation
	2.1. VPN Traffic Segregation Requirements		2.1. VPN Traffic Segregation Requirements
	The success of VPN services in the enterprise and the government		The success of VPN services in the enterprise and the government
	world is largely due to its ability to virtually segregate the		world is largely due to its ability to virtually segregate the
	customer traffic at layer 2 and layer 3. The lower the layer that		customer traffic at layer 2 and layer 3. The lower the layer that
	segregation can be maintained, the safer it is for the customers from		segregation can be maintained, the safer it is for the customers from
	security and privacy perspectives. Today data centers segregate the		security and privacy perspectives. Today, networks within a data
	customer traffic at layer 7 (application), and there is no standard		center are administrated by separate entities than the networks which
	for extending the VPN into data center. Network service providers		interconnect data centers to end users.
	view the VPN extension into data center, allowing traffic segregation
	per VPN, an essential necessity to the success of Cloud-Services in		Prior to Cloud services age, all applications running on data
	the enterprises and government markets. Cloud-Applications (or the		center's servers and data stored in data center's storage devices are
			managed by data center owners. The network segregation within data
			center, usually in Layer 2 VLAN format, is mainly to control
			broadcast domain and optimize network performance.
			With the introduction of cloud services, applications running on
			servers or virtual servers within data center can be owned and
			administrated by individual users or clients. For clients who
			already have VPN from service providers to interconnect multiple
			sites, they need their cloud service to be integrated within the same
			VPN.
			Therefore, it is very crucial for service providers to extend their
			existing VPNs into data centers. Network service providers view the
			VPN extension into data center, allowing traffic segregation per VPN,
			an essential necessity to the success of Cloud-Services in the
			enterprises and government markets. Cloud-Applications (or the
	virtualization function) SHOULD have the ability to get access to VPN		virtualization function) SHOULD have the ability to get access to VPN
	(including Layer 2/3 VPN) services, to segregate different Cloud-		(including Layer 2/3 VPN) services, to segregate different Cloud-
	Services traffic trough the network.		Services traffic trough the network.
	2.2. Potential Solution		2.2. Potential Solution
	2.2.1. VPN Gateway Managed Connection Segregation		2.2.1. VPN Gateway Managed Connection Segregation
	One possible way to achieve this is to have each Cloud-Application		One possible way to achieve this is to have each Cloud-Application
	setup connections with the VPN gateways, while the gateways attach		setup connections with the VPN gateways, while the gateways attach
	each connection to corresponding VPN. Each Cloud-Application SHALL		each connection to corresponding VPN. This can be accomplished using
	be transmitted over a pre-defined set of connections, and each VPN		a simple VRF from a provider edge router, each client can be assigned
	utilizing the application SHALL be transmitted over a sub-set of		to one VRF.
	application connections. In this case, each Cloud-Application SHALL
	maintain its own independent routing table. This is possible for some
	current operating systems, which already support multiple routing
	instances for its TCP/IP stack.
	2.2.2 solution using Provider Backbone Bridging (PBB) and Shortest Path		If Provider Edge Router (for provider VPN) is not co-located with the
			data center gateway, then it is necessary for Data Center gateway to
			build tunnels to VPN provider edge router.
			Or requiring each host running within the data center to have an
			IPSec VPN client, which can establish its own VPN tunnel to the
			provider edge router.
			2.2.2 Solution using Provider Backbone Bridging (PBB) and Shortest Path
	Bridging (SPB)		Bridging (SPB)
	Ethernet and VLANS are the standard L2 connectivity model throughout		Ethernet and VLANS are the standard L2 connectivity model throughout
	the data center environment. As such the IEEE has been working on		the data center environment. As such the IEEE has been working on
	numerous projects to simplify and extend traditional Ethernet models		numerous projects to simplify and extend traditional Ethernet models
	for scale and flexibility. Additionally the IEEE has projects		for scale and flexibility. Additionally the IEEE has projects looking
	looking at new attachments models for Virtual Machines (VM's) to		at new attachments models for Virtual Machines (VMs) to become more
	become more autonomic and secure for environments that include wholly		autonomic and secure for environments that include wholly owned and
	owned and multi-tenant.		multi-tenant. The I-SID extensions that are defined in the SPB
			standard SHOULD also be used to connect a configured I-SID to an
			existing VRF on the provider edge router when SBPB is used for L2
			discovery in the data center.
	Although VLAN and PPPoE are different types of connections, the two		Although VLAN and PPPoE are different types of connections, the two
	methods described above are fundamentally the same. Consequently, it		methods described above are fundamentally the same. Consequently, it
	is possible to generalize the descriptions above to cover both the		is possible to generalize the descriptions above to cover both the
	cases.		cases.
	2.2.3 VPN Gateway Controlled Traffic Flow		2.2.3 VPN Gateway Controlled Traffic Flow
	It is also possible for each Cloud-Application to acquire access to		When virtual switch function is supported by servers which support
	L2/L3 VPN with one shared routing table supported on the server. One		VMs, L2/L3 VPN features can be added to the Virtual Switch on the
	way to do that is to have the VPN gateway manage the traffic flow		server. One way to do that is to have the VPN gateway manage the
	instead of other way around. In that case, the VPN gateway has the		traffic flow instead of other way around. In that case, the VPN
	VRF table and the destination server connection address. Once the		gateway has the VRF table and the destination server connection
	server receives the traffic, it determines intra-data center		address. Once the server receives the traffic, it determines intra-
	destination based on the application. So the control sequence is VPN		data center destination based on the application. So the control
	first, and then application. The control sequence for the first two		sequence is VPN first, and then application. The control sequence
	methods described above is application first, and then VPN.		for the first two methods described above is application first, and
			then VPN.
	2.2.4 Inter-VPN Interworking		2.2.4 Inter-VPN Interworking
	L2/L3 VPN based MPLS network can also be deployed in the data center		L2/L3 VPN based MPLS network can also be deployed in the data center
	to manage the intra-data center traffic flow. The data center VPN		to manage the intra-data center traffic flow. The data center VPN
	structure can be set up in such a way that each external VPN can be		structure can be set up in such a way that each external VPN can be
	mapped to a unique internal VPN.		mapped to a unique internal VPN.
	2.3. Cloud Services Virtualization		2.3. Cloud Services Virtualization
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 35 ¶
	scalable, meaning problems occur in one area of the Cloud SHALL NOT		scalable, meaning problems occur in one area of the Cloud SHALL NOT
	affect all other areas of the Cloud involved. This way each		affect all other areas of the Cloud involved. This way each
	component of the Cloud can scale independently without causing		component of the Cloud can scale independently without causing
	systemic failures and/or allowing a single failure to cascade across		systemic failures and/or allowing a single failure to cascade across
	the Cloud.		the Cloud.
	2.5 Other Non-VPN Specific Areas		2.5 Other Non-VPN Specific Areas
	There are a number of known technology gaps preventing the data		There are a number of known technology gaps preventing the data
	centers, networks, and the end users from interworking together in		centers, networks, and the end users from interworking together in
	providing optimized and seamless end-to-end services. Although those		providing optimized and seamless end-to-end services. Although those
	areas are beyond VPN, they impact the VPN-based cloud services		areas are beyond VPN, they impact the VPN-based cloud services
	significantly. Those areas are listed below, but they are beyond the		significantly. Those areas are listed below, but they are beyond the
	scope of this draft.		scope of this draft.
	2.5.1. Cloud Traffic Load-Balancing and Congestion Avoidance		2.5.1. Cloud Traffic Load-Balancing and Congestion Avoidance
	Todays Cloud traffic balancing and congestion avoidance is purely		Todays Cloud traffic balancing and congestion avoidance is purely
	data center based. The network condition is not taken into		data center based. The network condition is not taken into
	consideration. The VPN extension SHOULD support the network		consideration. The VPN extension SHOULD support the network condition
	condition to be used for the traffic balancing and congestion		to be used for the traffic balancing and congestion avoidance
	avoidance decision-making.		decision-making.
	2.5.2. QoS Synchronization		2.5.2. QoS Synchronization
	It is required that the virtualization functions QoS requirement		It is required that the virtualization functions QoS requirement
	SHOULD be synchronized with VPN service.		SHOULD be synchronized with VPN service.
	2.5.3 Cross Layer Optimization		2.5.3 Cross Layer Optimization
	The VPN resource requested by the server CAN be optimized by		The VPN resource requested by the server CAN be optimized by
	statistical multiplexing of the resource. For example, for each VPN		statistical multiplexing of the resource. For example, for each VPN
	resource, it is possible to configure committed BW for each QoS		resource, it is possible to configure committed BW for each QoS
	resources and peak BW for best effort traffic, and the peak BW		resources and peak BW for best effort traffic, and the peak BW
	resources CAN be shared by different VPN service.		resources CAN be shared by different VPN service.
	2.5.4 Automation end to end Configuration		2.5.4 Automation end to end Configuration
	The automatic end-to-end network configuration will reduce the		The automatic end-to-end network configuration will reduce the
	operational cost and also the probability of occurrence of mis-		operational cost and also the probability of occurrence of
	configuration. The VPN Extension SHALL support the automatic end-to-		misconfiguration. The VPN Extension SHALL support the automatic end-
	end network configuration.		to-end network configuration.
	2.6. End-to-End Quality of Experience (ETE-QoE)		2.6. End-to-End Quality of Experience (ETE-QoE)
	Quality of experience (QoE) management refers to maintaining a set of		Quality of experience (QoE) management refers to maintaining a set of
	application /service layer parameters within certain threshold with		application /service layer parameters within certain threshold with
	an objective to retain the user experience for a specific service.		an objective to retain the user experience for a specific service.
	Very often when new underlying technologies and/or mechanisms are		Very often when new underlying technologies and/or mechanisms are
	introduced for implementing the same services (voice, data, video,		introduced for implementing the same services (voice, data, video,
	messaging, etc.), opportunities exist to improve the user		messaging, etc.), opportunities exist to improve the user
	experiences. Conversely the user experience may suffer unless the		experiences. Conversely the user experience may suffer unless the
	appropriate transport level parameters that significantly impact		appropriate transport level parameters that significantly impact the
	the QoE are monitored and managed.		QoE are monitored and managed.
	2.7. OAM Considerations		2.7. OAM Considerations
	The VPN Extension solution MUST have sufficient OAM mechanisms in		The VPN Extension solution MUST have sufficient OAM mechanisms in
	place to allow consistent end-to-end management of the solution in		place to allow consistent end-to-end management of the solution in
	existing deployed networks. The solution SHOULD use existing		existing deployed networks. The solution SHOULD use existing
	protocols (802.3ag, Y.1731, BFD) wherever possible to help with		protocols (802.3ag, Y.1731, BFD) wherever possible to help with
	interoperability of existing OAM deployments.		interoperability of existing OAM deployments.
	2.8. Work Item Considerations in IETF Clouds		2.8. Work Item Considerations in IETF Clouds
	In VPN extension to private Clouds, various application level		In VPN extension to private Clouds, various application level
	parameters, protocol level parameter, and service monitoring		parameters, protocol level parameter, and service monitoring
	parameters may need to be defined, and the results of monitoring may		parameters may need to be defined, and the results of monitoring may
	need to be exchanged periodically. In private cloud environment,		need to be exchanged periodically. In private cloud environment,
	since the resources exist in one or co-operative administrative		since the resources exist in one or co-operative administrative
	domain, it is easier to monitor and manage the application and		domain, it is easier to monitor and manage the application and
	transport level parameters for the underlying resources. In some		transport level parameters for the underlying resources. In some
	cases, proactive mechanisms can be readily implemented before user		cases, proactive mechanisms can be readily implemented before user
	experiences degrade to the level of annoyance. In public and hybrid		experiences degrade to the level of annoyance. In public and hybrid
	(a smart combination of private and public) clouds it is required to		(a smart combination of private and public) clouds it is required to
	derive a list of mutually agreed upon monitoring and management		derive a list of mutually agreed upon monitoring and management
	parameters. Active monitoring using virtual agents and resources is		parameters. Active monitoring using virtual agents and resources is
	also possible. However, allocation of resources and placement of the		also possible. However, allocation of resources and placement of the
	virtual agent including the amount of traffic generated for QoE		virtual agent including the amount of traffic generated for QoE
	management, and the exchange of the desired information back and		management, and the exchange of the desired information back and
	forth need to be achieved.		forth need to be achieved.
	3 Security Considerations		3 Security Considerations
	The VPN extension SHOULD support variety of security measures in		The VPN extension SHOULD support variety of security measures in
	securing tenancy of virtual resources such as resource locking,		securing tenancy of virtual resources such as resource locking,
	containment, authentication, access control, encryption, integrity		containment, authentication, access control, encryption, integrity
	measure, and etc. The VPN extension SHOULD allow the security to be		measure, and etc. The VPN extension SHOULD allow the security to be
	configure end-to-end on a per VPN per-user bases. For example, the		configure end-to-end on a per VPN per-user bases. For example, the
	Virtual Systems MUST resource lock resources such as memory, but must		Virtual Systems MUST resource lock resources such as memory, but must
	also provide a cleaning function to insure confidentiality, before		also provide a cleaning function to insure confidentiality, before
	being reallocated.		being reallocated.
	VPN extension for private Clouds SHOULD specify an authentication		VPN extension for private Clouds SHOULD specify an authentication
	mechanism based on an authentication algorithms (MD5, HMAC-SHA-1)for		mechanism based on an authentication algorithms (MD5, HMAC-SHA-1)for
	both header and payload. Encryption MAY also be use to provide		both header and payload. Encryption MAY also be use to provide
	confidentiality.		confidentiality.
	Security boundaries MAY also be create to maintain domains of		Security boundaries MAY also be create to maintain domains of
	TRUSTED, UNTRUSTED, and Hybrid. Within each domain access control		TRUSTED, UNTRUSTED, and Hybrid. Within each domain access control
	techniques MAY be uses to secure resource and administrative domains.		techniques MAY be uses to secure resource and administrative domains.
	4 IANA Considerations		4 IANA Considerations
	None		None
	5 References		5 References
	5.1 Normative References		5.1 Normative References
	skipping to change at page 8, line 45 ¶		skipping to change at page 9, line 45 ¶
	5.2 Informative References		5.2 Informative References
	None		None
	Author's Addresses		Author's Addresses
	Ning So		Ning So
	Verizon Inc.		Verizon Inc.
	2400 N. Glenville Rd.,		2400 N. Glenville Rd.,
	Richardson, TX 75082		Richardson, TX 75082
	ning.so@verizonbusiness.com		ning.so@verizonbusiness.com
	Henry Yu		Henry Yu
	tw telecom		tw telecom
	10475 Park Meadows Dr.		10475 Park Meadows Dr.
	Littleton, CO 80124		Littleton, CO 80124
	henry.yu@twtelecom.com		henry.yu@twtelecom.com
	John M. Heinz		John M. Heinz
	CenturyLink		CenturyLink
	Phone: 913-533-2115		Phone: 913-533-2115
	john.m.heinz@centurylink.com		john.m.heinz@centurylink.com
	skipping to change at page 9, line 33 ¶		skipping to change at page 10, line 31 ¶
	Mike Mangino		Mike Mangino
	Alcatel-Lucent		Alcatel-Lucent
	8742 Lucent Boulevard		8742 Lucent Boulevard
	Highlands Ranch, CO 80129		Highlands Ranch, CO 80129
	mike.mangino@alcatel-lucent.com		mike.mangino@alcatel-lucent.com
	Bhumip Khasnabish		Bhumip Khasnabish
	ZTE USA, Inc.		ZTE USA, Inc.
	33 Wood Ave. S., 2nd Flr		33 Wood Ave. S., 2nd Flr
	Iselin, NJ, USA		Iselin, NJ, USA
	Tel.:1-781-752-8003		vumip1@gmail.com
	Email: vumip1@gmail.com
	Lizhong Jin		Lizhong Jin
	ZTE Corporation		ZTE Corporation
	889, Bibo Road		889, Bibo Road
	Shanghai, 201203, China		Shanghai, 201203, China
	Email: lizhong.jin@zte.com.cn		lizhong.jin@zte.com.cn
End of changes. 37 change blocks.
	86 lines changed or deleted		109 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/