< draft-ietf-nvo3-hpvr2nve-cp-req-02.txt		draft-ietf-nvo3-hpvr2nve-cp-req-03.txt >
	NVO3 Working Group Yizhou Li		NVO3 Working Group Yizhou Li
	INTERNET-DRAFT Lucy Yong		INTERNET-DRAFT Lucy Yong
	Intended Status: Informational Huawei Technologies		Intended Status: Informational Huawei Technologies
	Lawrence Kreeger		Lawrence Kreeger
	Cisco		Cisco
	Thomas Narten		Thomas Narten
	IBM		IBM
	David Black		David Black
	EMC		EMC
	Expires: August 13, 2015 February 9, 2015		Expires: February 27, 2016 August 26, 2015
	Hypervisor to NVE Control Plane Requirements		Split-NVE Control Plane Requirements
	draft-ietf-nvo3-hpvr2nve-cp-req-02		draft-ietf-nvo3-hpvr2nve-cp-req-03
	Abstract		Abstract
	In a Split-NVE architructure, the functions of the NVE are split		In a Split-NVE architecture, the functions of the NVE are split
	across the hypervisor/container on a server and an external network		across a server and an external network equipment which is called an
	equipment which is called an external NVE. A control plane		external NVE. The server-resident control plane functionality
	protocol(s) between a hypervisor and its associated external NVE(s)		resides in control software, which may be part of a hypervisor or
	is used for the hypervisor to distribute its virtual machine		container management software; for simplicity, this draft refers to
	networking state to the external NVE(s) for further handling. This		the hypervisor as the location of this software.
	document illustrates the functionality required by this type of
			A control plane protocol(s) between a hypervisor and its associated
			external NVE(s) is used for the hypervisor to distribute its virtual
			machine networking state to the external NVE(s) for further handling.
			This document illustrates the functionality required by this type of
	control plane signaling protocol and outlines the high level		control plane signaling protocol and outlines the high level
	requirements. Virtual machine states as well as state transitioning		requirements. Virtual machine states as well as state transitioning
	are summarized to help clarifying the needed protocol requirements.		are summarized to help clarifying the needed protocol requirements.
	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
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 8 ¶
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	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."
	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) 2013 IETF Trust and the persons identified as the		Copyright (c) 2015 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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2 Target Scenarios . . . . . . . . . . . . . . . . . . . . . 5		1.2 Target Scenarios . . . . . . . . . . . . . . . . . . . . . 6
	2. VM Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. VM Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1 VM Creation Event . . . . . . . . . . . . . . . . . . . . . 7		2.1 VM Creation Event . . . . . . . . . . . . . . . . . . . . . 8
	2.2 VM Live Migration Event . . . . . . . . . . . . . . . . . . 8		2.2 VM Live Migration Event . . . . . . . . . . . . . . . . . . 9
	2.3 VM Termination Event . . . . . . . . . . . . . . . . . . . . 9		2.3 VM Termination Event . . . . . . . . . . . . . . . . . . . . 10
	2.4 VM Pause, Suspension and Resumption Events . . . . . . . . . 9		2.4 VM Pause, Suspension and Resumption Events . . . . . . . . . 10
	3. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 9		3. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 10
	3.1 VN connect and Disconnect . . . . . . . . . . . . . . . . . 10		3.1 VN connect and Disconnect . . . . . . . . . . . . . . . . . 11
	3.2 TSI Associate and Activate . . . . . . . . . . . . . . . . . 11		3.2 TSI Associate and Activate . . . . . . . . . . . . . . . . . 12
	3.3 TSI Disassociate and Deactivate . . . . . . . . . . . . . . 14		3.3 TSI Disassociate and Deactivate . . . . . . . . . . . . . . 15
	4. Hypervisor-to-NVE Control Plane Protocol Requirements . . . . . 15		4. Hypervisor-to-NVE Control Plane Protocol Requirements . . . . . 16
	5. VDP Applicability and Enhancement Needs . . . . . . . . . . . . 16		5. VDP Applicability and Enhancement Needs . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 19		8.1 Normative References . . . . . . . . . . . . . . . . . . . 20
	8.2 Informative References . . . . . . . . . . . . . . . . . . 19		8.2 Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. IEEE 802.1Qbg VDP Illustration (For information		Appendix A. IEEE 802.1Qbg VDP Illustration (For information
	only) . . . . . . . . . . . . . . . . . . . . . . . . . . 19		only) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	In the Split-NVE architecture shown in Figure 1, the functionality of		In the Split-NVE architecture shown in Figure 1, the functionality of
	the NVE is split across an end device supporting virtualization and		the NVE is split across an end device supporting virtualization and
	an external network device which is called an external NVE. The		an external network device which is called an external NVE. The
	portion of the NVE functionality located on the hypervisor/container		portion of the NVE functionality located on the end device is called
	is called the tNVE and the portion located on the external NVE is		the tNVE and the portion located on the external NVE is called the
	called the nNVE in this document. Overlay encapsulation/decapsulation		nNVE in this document. Overlay encapsulation/decapsulation functions
	functions are normally off-loaded to the nNVE on the external NVE.		are normally off-loaded to the nNVE on the external NVE.
	The tNVE is normally implemented as a part of hypervisor or container		The tNVE is normally implemented as a part of hypervisor or container
	in an virtualized end device.		and/or virtual switch in an virtualized end device. This document
			uses the term "hypervisor" throughout when describing the Split-NVE
			scenario where part of the NVE functionality is off-loaded to a
			separate device from the "hypervisor" that contains a VM connected to
			a VN. In this context, the term "hypervisor" is meant to cover any
			device type where part of the NVE functionality is off-loaded in this
			fashion, e.g.,a Network Service Appliance, Linux Container.
	The problem statement [RFC7364], discusses the needs for a control		The problem statement [RFC7364], discusses the needs for a control
	plane protocol (or protocols) to populate each NVE with the state		plane protocol (or protocols) to populate each NVE with the state
	needed to perform the required functions. In one scenario, an NVE		needed to perform the required functions. In one scenario, an NVE
	provides overlay encapsulation/decapsulation packet forwarding		provides overlay encapsulation/decapsulation packet forwarding
	services to Tenant Systems (TSs) that are co-resident within the NVE		services to Tenant Systems (TSs) that are co-resident within the NVE
	on the same End Device (e.g. when the NVE is embedded within a		on the same End Device (e.g. when the NVE is embedded within a
	hypervisor or a Network Service Appliance). In such cases, there is		hypervisor or a Network Service Appliance). In such cases, there is
	no need for a standardized protocol between the hypervisor and NVE,		no need for a standardized protocol between the hypervisor and NVE,
	as the interaction is implemented via software on a single device.		as the interaction is implemented via software on a single device.
	skipping to change at page 4, line 17 ¶		skipping to change at page 5, line 17 ¶
	|		|
	+---------------|-----+		+---------------|-----+
	| +------------- ----+| |		| +------------- ----+| |
	| | +--+ +---\|/--+|| +------ --------------+		| | +--+ +---\|/--+|| +------ --------------+
	| | |VM|---+ ||| | \|/ |		| | |VM|---+ ||| | \|/ |
	| | +--+ | ||| |+--------+ |		| | +--+ | ||| |+--------+ |
	| | +--+ | tNVE |||----- - - - - - -----|| | |		| | +--+ | tNVE |||----- - - - - - -----|| | |
	| | |VM|---+ ||| || nNVE | |		| | |VM|---+ ||| || nNVE | |
	| | +--+ +--------+|| || | |		| | +--+ +--------+|| || | |
	| | || |+--------+ |		| | || |+--------+ |
	| +--Hpvr/Container--+| +---------------------+		| +--Hypervisor------+| +---------------------+
	+---------------------+		+---------------------+
	End Device External NVE		End Device External NVE
	Figure 1 Split-NVE structure		Figure 1 Split-NVE structure
	This document uses the term "hypervisor" throughout when describing		This document uses VMs as an example of Tenant Systems (TSs) in order
	the Split-NVE scenario where part of the NVE functionality is off-		to describe the requirements, even though a VM is just one type of
	loaded to a separate device from the "hypervisor" that contains a VM		Tenant System that may connect to a VN. For example, a service
	connected to a VN. In this context, the term "hypervisor" is meant to		instance within a Network Service Appliance is another type of TS, as
	cover any device type where part of the NVE functionality is off-		are systems running on an OS-level virtualization technologies like
	loaded in this fashion, e.g.,a Network Service Appliance, Linux		containers. The fact that VMs have lifecycles(e.g., can be created
	Container.		and destroyed), can be moved, and can be started or stopped results
			in a general set of protocol requirements, most of which are
	This document often uses the term "VM" and "Tenant System" (TS)		applicable to other forms of TSs. It should also be noted that not
	interchangeably, even though a VM is just one type of Tenant System		all of the requirements are applicable to all forms of TSs.
	that may connect to a VN. For example, a service instance within a
	Network Service Appliance may be another type of TS, or a system
	running on an OS-level virtualization technologies like LinuX
	Containers. When this document uses the term VM, it will in most
	cases apply to other types of TSs.
	Section 2 describes VM states and state transitioning in its		Section 2 describes VM states and state transitioning in its
	lifecycle. Section 3 introduces Hypervisor-to-NVE control plane		lifecycle. Section 3 introduces Hypervisor-to-NVE control plane
	protocol functionality derived from VM operations and network events.		protocol functionality derived from VM operations and network events.
	Section 4 outlines the requirements of the control plane protocol to		Section 4 outlines the requirements of the control plane protocol to
	achieve the required functionality.		achieve the required functionality.
	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",
	skipping to change at page 5, line 15 ¶		skipping to change at page 6, line 10 ¶
	This document uses the same terminology as found in [RFC7365] and [I-		This document uses the same terminology as found in [RFC7365] and [I-
	D.ietf-nvo3-nve-nva-cp-req]. This section defines additional		D.ietf-nvo3-nve-nva-cp-req]. This section defines additional
	terminology used by this document.		terminology used by this document.
	Split-NVE: a type of NVE that the functionalities of it are split		Split-NVE: a type of NVE that the functionalities of it are split
	across an end device supporting virtualization and an external		across an end device supporting virtualization and an external
	network device.		network device.
	tNVE: the portion of Split-NVE functionalities located on the end		tNVE: the portion of Split-NVE functionalities located on the end
	device supporting virtualization.		device supporting virtualization. It interacts with tenant system by
			internal interface in end device.
	nNVE: the portion of Split-NVE functionalities located on the network		nNVE: the portion of Split-NVE functionalities located on the network
	device which is directly or indirectly connects to the end device		device which is directly or indirectly connects to the end device
	holding the corresponding tNVE.		holding the corresponding tNVE. nNVE normally performs encapsulation
			and decapsulation to the overlay network.
	External NVE: the physical network device holding nNVE		External NVE: the physical network device holding nNVE
	Hypervisor/Container: the logical collection of software, firmware		Hypervisor/Container: the logical collection of software, firmware
	and/or hardware that allows the creation and running of server or		and/or hardware that allows the creation and running of server or
	service appliance virtualization. tNVE is located on		service appliance virtualization. tNVE is located on
	Hypervisor/Container. It is loosely used in this document to refer to		Hypervisor/Container. It is loosely used in this document to refer to
	the end device supporting the virtualization. For simplicity, we also		the end device supporting the virtualization. For simplicity, we also
	use Hypervisor in this document to represent both hypervisor and		use Hypervisor in this document to represent both hypervisor and
	container.		container.
	skipping to change at page 7, line 17 ¶		skipping to change at page 8, line 11 ¶
	external NVE may be able to reach multiple MAC and IP addresses via a		external NVE may be able to reach multiple MAC and IP addresses via a
	TSI. For example, Tenant Systems that are providing network services		TSI. For example, Tenant Systems that are providing network services
	(such as transparent firewall, load balancer, VPN gateway) are likely		(such as transparent firewall, load balancer, VPN gateway) are likely
	to have complex address hierarchy. This implies that if a given TSI		to have complex address hierarchy. This implies that if a given TSI
	disassociates from one VN, all the MAC and/or IP addresses are also		disassociates from one VN, all the MAC and/or IP addresses are also
	disassociated. There is no need to signal the deletion of every MAC		disassociated. There is no need to signal the deletion of every MAC
	or IP when the TSI is brought down or deleted. In the majority of		or IP when the TSI is brought down or deleted. In the majority of
	cases, a VM will be acting as a simple host that will have a single		cases, a VM will be acting as a simple host that will have a single
	TSI and single MAC and IP visible to the external NVE.		TSI and single MAC and IP visible to the external NVE.
			Figures 2-4 show the use of VLANs to separate traffic for multiple
			VNs between the tNVE and nNVE; VLANs are not strictly necessary if
			only one VN is involved, but multiple VNs are expected in most cases,
			and hence this draft assumes their presence.
	2. VM Lifecycle		2. VM Lifecycle
	Figure 2 of [I-D.ietf-opsawg-vmm-mib] shows the state transition of a		Figure 2 of [I-D.ietf-opsawg-vmm-mib] shows the state transition of a
	VM. Some of the VM states are of interest to the external NVE. This		VM. Some of the VM states are of interest to the external NVE. This
	section illustrates the relevant phases and events in the VM		section illustrates the relevant phases and events in the VM
	lifecycle. It should be noted that the following subsections do not		lifecycle. It should be noted that the following subsections do not
	give an exhaustive traversal of VM lifecycle state. They are intended		give an exhaustive traversal of VM lifecycle state. They are intended
	as the illustrative examples which are relevant to Split-NVE		as the illustrative examples which are relevant to Split-NVE
	architecture, not as prescriptive text; the goal is to capture		architecture, not as prescriptive text; the goal is to capture
	sufficient detail to set a context for the signaling protocol		sufficient detail to set a context for the signaling protocol
	skipping to change at page 16, line 9 ¶		skipping to change at page 17, line 9 ¶
	NVEs simultaneously for the same VN.		NVEs simultaneously for the same VN.
	Req-5: The protocol MUST allow the End Device initiating a request to		Req-5: The protocol MUST allow the End Device initiating a request to
	its associated External NVE to be connected/disconnected to a given		its associated External NVE to be connected/disconnected to a given
	VN.		VN.
	Req-6: The protocol MUST allow an External NVE initiating a request		Req-6: The protocol MUST allow an External NVE initiating a request
	to its connected End Devices to be disconnected to a given VN.		to its connected End Devices to be disconnected to a given VN.
	Req-7: When a TS attaches to a VN, the protocol MUST allow for an End		Req-7: When a TS attaches to a VN, the protocol MUST allow for an End
	Device and its external NVE to negotiate a locally-significant tag		Device and its external NVE to negotiate one or more locally-
	for carrying traffic associated with a specific VN (e.g., 802.1Q		significant tag(s) for carrying traffic associated with a specific VN
	tags).		(e.g., 802.1Q tags).
	Req-8: The protocol MUST allow an End Device initiating a request to		Req-8: The protocol MUST allow an End Device initiating a request to
	associate/disassociate and/or activate/deactive address(es) of a TSI		associate/disassociate and/or activate/deactive address(es) of a TSI
	instance to a VN on an NVE port.		instance to a VN on an NVE port.
	Req-9: The protocol MUST allow the External NVE initiating a request		Req-9: The protocol MUST allow the External NVE initiating a request
	to disassociate and/or deactivate address(es) of a TSI instance to a		to disassociate and/or deactivate address(es) of a TSI instance to a
	VN on an NVE port.		VN on an NVE port.
	Req-10: The protocol MUST allow an End Device initiating a request to		Req-10: The protocol MUST allow an End Device initiating a request to
	skipping to change at page 17, line 18 ¶		skipping to change at page 18, line 19 ¶
	a reliable transportation over a layer 2 network.		a reliable transportation over a layer 2 network.
	VDP protocol needs some extensions to fulfill the requirements listed		VDP protocol needs some extensions to fulfill the requirements listed
	in this document. Table 1 shows the needed extensions and/or		in this document. Table 1 shows the needed extensions and/or
	clarifications in NVO3 context.		clarifications in NVO3 context.
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	| Req | VDP | remarks |		| Req | VDP | remarks |
	| | supported?| |		| | supported?| |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	| Req-1| |Needs extension. Dest MAC can be a specific |		| Req-1| | |
	+------+ Partially |unicast MAC besides Nearest Customer Bridge |		+------+ |Needs extension. Must be able to send to a |
	| Req-2| |group MAC |		| Req-2| |specific unicast MAC and should be able to send|
	+------+-----------+-----------------------------------------------+		+------+ Partially |to a non-reserved well known multicast address |
	| Req-3| |Needs clarification and extension for link |		| Req-3| |other than the nearest customer bridge address |
	| | |aggregation support. |		+------+ | |
	+------+ Partially |For req-4, (pre-)associate status needs to be |		| Req-4| | |
	| Req-4| |synchronized on all NVE ports. |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	| Req-5| Yes |VN is indicated by GroupID |		| Req-5| Yes |VN is indicated by GroupID |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	| Req-6| Yes |Bridge sends De-Associate |		| Req-6| Yes |Bridge sends De-Associate |
	+------+-----------+------------------------+----------------------+		+------+-----------+------------------------+----------------------+
	| Req-7| Yes |VID==NULL in request and bridge returns the |		| | |VID==NULL in request and bridge returns the |
	| | |assigned value in response |		| Req-7| Yes |assigned value in response or specify GroupID |
			| | |in request and get VID assigned in returning |
			| | |response. Multiple VLANs per group is allowed |
	+------+-----------+------------------------+----------------------+		+------+-----------+------------------------+----------------------+
	| | | requirements | VDP equivalence |		| | | requirements | VDP equivalence |
	| | +------------------------+----------------------+		| | +------------------------+----------------------+
	| | | associate/disassociate|pre-asso/de-associate |		| | | associate/disassociate|pre-asso/de-associate |
	| Req-8| Partially | activate/deactivate |associate/de-associate|		| Req-8| Partially | activate/deactivate |associate/de-associate|
	| | +------------------------+----------------------|		| | +------------------------+----------------------|
	| | |Needs extension to allow associate->pre-assoc |		| | |Needs extension to allow associate->pre-assoc |
	+------+-----------+------------------------+----------------------+		+------+-----------+------------------------+----------------------+
	| Req-9| Yes | VDP bridge initiates de-associate |		| Req-9| Yes | VDP bridge initiates de-associate |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	|Req-10| Partially |Needs extension for IPv4/IPv6 address |		|Req-10| Partially |Needs extension for IPv4/IPv6 address. Add a |
			| | |new "filter info format" type |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	|Req-11| No |Needs extension for authentication |		|Req-11| No |Out-of-band mechanism is preferred, e.g. MACSec|
			| | |or 802.1x. |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	|Req-12| Yes |L2 protocol naturally |		|Req-12| Yes |L2 protocol naturally |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	| | |M bit for migrated VM on destination hypervisor|		| | |M bit for migrated VM on destination hypervisor|
	| | |and S bit for that on source hypervisor. |		| | |and S bit for that on source hypervisor. |
	|Req-13| Partially |It is indistinguishable when M/S is 0 between |		|Req-13| Partially |It is indistinguishable when M/S is 0 between |
	| | |no guidance and events not caused by migration |		| | |no guidance and events not caused by migration |
	| | |where NVE may act differently. Needs extension |		| | |where NVE may act differently. Needs new |
	| | |to clearly define them. |		| | |New bits for migration indication in new |
			| | |"filter info format" type |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	Table 1 Compare VDP with the requirements		Table 1 Compare VDP with the requirements
	Simply adding the ability to carry layer 3 addresses, VDP can serve		Simply adding the ability to carry layer 3 addresses, VDP can serve
	the Hypervisor-to-NVE control plane functions pretty well. Other		the Hypervisor-to-NVE control plane functions pretty well. Other
	extensions are the improvement of the protocol capabilities for		extensions are the improvement of the protocol capabilities for
	better fit in NVO3 network.		better fit in NVO3 network.
	6. Security Considerations		6. Security Considerations
	NVEs must ensure that only properly authorized Tenant Systems are		NVEs must ensure that only properly authorized Tenant Systems are
End of changes. 21 change blocks.
	74 lines changed or deleted		92 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/