< draft-ietf-nvo3-gap-analysis-00.txt		draft-ietf-nvo3-gap-analysis-01.txt >
	Internet Engineering Task Force E. Gray, Ed.		Internet Engineering Task Force E. Gray, Ed.
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational N. Bitar		Intended status: Informational N. Bitar
	Expires: March 29, 2014 Verizon		Expires: August 18, 2014 Verizon
	X. Chen		X. Chen
	Huawei Technologies		Huawei Technologies
	M. Lasserre		M. Lasserre
	Alcatel-Lucent		Alcatel-Lucent
	T. Tsou		T. Tsou
	Huawei Technologies (USA)		Huawei Technologies (USA)
	September 25, 2013		February 14, 2014
	NVO3 Gap Analysis - Requirements Versus Available Technology Choices		NVO3 Gap Analysis - Requirements Versus Available Technology Choices
	draft-ietf-nvo3-gap-analysis-00		draft-ietf-nvo3-gap-analysis-01
	Abstract		Abstract
	This document evaluates candidate protocols against the NVO3		This document evaluates candidate protocols against the NVO3
	requirements. Gaps are identified and further work recommended.		requirements. Gaps are identified and further work recommended.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 29, 2014.		This Internet-Draft will expire on August 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3		2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3		2.3. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3
	3. Operational Requirements . . . . . . . . . . . . . . . . . . 4		3. Operational Requirements . . . . . . . . . . . . . . . . . . 4
	4. Management Requirements . . . . . . . . . . . . . . . . . . . 4		4. Management Requirements . . . . . . . . . . . . . . . . . . . 4
	5. Control Plane Requirements . . . . . . . . . . . . . . . . . 4		5. Control Plane Requirements . . . . . . . . . . . . . . . . . 4
	5.1. Overall Control-Plane Requirements . . . . . . . . . . . 5		5.1. NVE-NVA Control-Plane Requirements . . . . . . . . . . . 6
	5.2. VM-to-NVE Specific Control-Plane Requirements . . . . . . 7		5.2. VM-to-NVE Specific Control-Plane Requirements . . . . . . 9
	6. Data Plane Requirements . . . . . . . . . . . . . . . . . . . 9		6. Data Plane Requirements . . . . . . . . . . . . . . . . . . . 11
	7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 14		7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 17
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 15		10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The initial charter of the NVO3 Working Group requires it to identify		The initial charter of the NVO3 Working Group requires it to identify
	any gaps between the requirements identified and available		any gaps between the requirements identified and available
	technoloogy solutions as a prerequisite to rechartering or concluding		technoloogy solutions as a prerequisite to rechartering or concluding
	the Working Group (if no gaps exist). This document is intended to		the Working Group (if no gaps exist). This document is intended to
	provide the required gap analysis.		provide the required gap analysis.
	This document provides a tabulation of candidate solutions and their		This document provides a tabulation of candidate solutions and their
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	Areas of work are identified where further work is required to ensure		Areas of work are identified where further work is required to ensure
	that the requirements are met.		that the requirements are met.
	The major areas covered in this document include:		The major areas covered in this document include:
	o Operational Requirements		o Operational Requirements
	[I-D.ashwood-nvo3-operational-requirement]		[I-D.ashwood-nvo3-operational-requirement]
	o Management Requirements (TBD)		o Management Requirements (TBD)
	o Control (Plane) Requirements [I-D.kreeger-nvo3-overlay-cp]		o Control (Plane) Requirements [I-D.ietf-nvo3-nve-nva-cp-req]
	o Dataplane Requirements [I-D.ietf-nvo3-dataplane-requirements]		o Dataplane Requirements [I-D.ietf-nvo3-dataplane-requirements]
	Since the Working Group has yet to complete (and in some cases adopt)		Since the Working Group has yet to complete (and in some cases adopt)
	documents describing requirements for some of these areas, not all		documents describing requirements for some of these areas, not all
	areas are complete in the present version of this document.		areas are complete in the present version of this document.
	The initial candidate technologies are:		The initial candidate technologies are:
	o NVGRE [I-D.sridharan-virtualization-nvgre],		o NVGRE [I-D.sridharan-virtualization-nvgre],
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	numbering in this document, the included numbering is parenthesized.		numbering in this document, the included numbering is parenthesized.
	L2VPN is represented (in tables and analysis, as a technology) by the		L2VPN is represented (in tables and analysis, as a technology) by the
	two differing approaches: VPLS and EVPN.		two differing approaches: VPLS and EVPN.
	2.3. Terms and Abbreviations		2.3. Terms and Abbreviations
	This document uses terms and acronyms defined in [RFC3168],		This document uses terms and acronyms defined in [RFC3168],
	[I-D.ietf-nvo3-framework], [I-D.ietf-nvo3-dataplane-requirements],		[I-D.ietf-nvo3-framework], [I-D.ietf-nvo3-dataplane-requirements],
	[I-D.kreeger-nvo3-hypervisor-nve-cp] and		[I-D.kreeger-nvo3-hypervisor-nve-cp] and
	[I-D.kreeger-nvo3-overlay-cp]. Acronyms are included here for		[I-D.ietf-nvo3-nve-nva-cp-req]. Acronyms are included here for
	convenience but are meant to remain aligned with definitions in the		convenience but are meant to remain aligned with definitions in the
	references included.		references included.
	ECN: Explicit Congestion Notification [RFC3168]		ECN: Explicit Congestion Notification [RFC3168]
	NVA: Network Virtualization Authority [I-D.kreeger-nvo3-overlay-cp]		NVA: Network Virtualization Authority [I-D.ietf-nvo3-nve-nva-cp-req]
	NVE: Network Virtualization Edge [I-D.ietf-nvo3-framework]		NVE: Network Virtualization Edge [I-D.ietf-nvo3-framework]
	VAP: Virtual Access Point [I-D.ietf-nvo3-dataplane-requirements]		VAP: Virtual Access Point [I-D.ietf-nvo3-dataplane-requirements]
	VNI: Virtual Network Instance [I-D.ietf-nvo3-framework]		VNI: Virtual Network Instance [I-D.ietf-nvo3-framework]
	VNIC: Virtual Network Interface Card (NIC)		VNIC: Virtual Network Interface Card (NIC)
	[I-D.kreeger-nvo3-hypervisor-nve-cp]		[I-D.kreeger-nvo3-hypervisor-nve-cp]
	VNID: Virtual Network Identifier [I-D.kreeger-nvo3-overlay-cp]		VNID: Virtual Network Identifier [I-D.ietf-nvo3-nve-nva-cp-req]
	This document uses the following additional general terms and		This document uses the following additional general terms and
	abbreviations:		abbreviations:
	DSCP: Differentiated Services Code-Point		DSCP: Differentiated Services Code-Point
	ECMP: Equal Cost Multi-Path		ECMP: Equal Cost Multi-Path
	L2VPN: Layer 2 Virtual Private Network		L2VPN: Layer 2 Virtual Private Network
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	Virtual Machine (VM) from a particular Virtual Network Instance		Virtual Machine (VM) from a particular Virtual Network Instance
	(VNI).		(VNI).
	As sometimes happens, there is not a 1:1 mapping of the work areas		As sometimes happens, there is not a 1:1 mapping of the work areas
	defined in [I-D.ietf-nvo3-overlay-problem-statement] and requirements		defined in [I-D.ietf-nvo3-overlay-problem-statement] and requirements
	documents intended to address the problems that have been identified		documents intended to address the problems that have been identified
	there.		there.
	Current control-plane requirement documents include the following:		Current control-plane requirement documents include the following:
	o Overall control-plane requirements [I-D.kreeger-nvo3-overlay-cp]		o NVE-NVA control-plane requirements [I-D.ietf-nvo3-nve-nva-cp-req]
	o Control-plane requirements specific to VM-to-NVE interactions		o Control-plane requirements specific to VM-to-NVE interactions
	[I-D.kreeger-nvo3-hypervisor-nve-cp]		[I-D.kreeger-nvo3-hypervisor-nve-cp]
	5.1. Overall Control-Plane Requirements		In the following subsections, we consider the data-plane candidate
			solutions and proposed or existing control plane solutions that may
			apply to each.
			In each case, the control-plane solutions can be divided into support
			for Layer-2 and Layer-3 services, and for each of these cases, the
			data-plane solutions considered will be limited to those services and
			solutions that make sense for that case.
			Tables are thus organized into separate tables for both L2 and L3
			data/control service options. It may turn out that - for all
			potential control-plane solutions - each solution applies equally to
			all data-plane solutions considered for the layer applicable.
			If this turns out to be the case, then the tables may be further
			simplified - possibly by reducing each pair of L2/L3 tables to a
			single table where the columns are simply "Layer-2" and "Layer-3."
			The intent is to show potential mapping of data-plane to applicable
			control-plane alternatives and evaluate each applicable control-plane
			against defined control-plane requirements.
			The way this document attempts to do this is to list the control
			planes that may be applicable to each of the candidate data-planes in
			table footnotes and then stating in table footnotes the extent to
			which candidate control plane technologies satisfy each requirement.
			As with tables in other sections of this draft, the rows in each
			table list the applicable requirements found in analogous sections of
			applicable requirements documents.
			5.1. NVE-NVA Control-Plane Requirements
	In this section, numbering of requirement headings corresponds to		In this section, numbering of requirement headings corresponds to
	section numbering in [I-D.kreeger-nvo3-overlay-cp].		section numbering in [I-D.ietf-nvo3-nve-nva-cp-req].
	(3.1) Inner to Outer Address Mapping		(3.1) Inner to Outer Address Mapping
	The requirements document [I-D.kreeger-nvo3-overlay-cp] states that		The requirements document [I-D.ietf-nvo3-nve-nva-cp-req] states that
	avoiding the need to "flood" traffic to support learning of mapping		avoiding the need to "flood" traffic to support learning of mapping
	information from the data-plane is a goal of NVO3 candidate		information from the data-plane is a goal of NVO3 candidate
	technological approaches.		technological approaches.
	For each candidate technology, (how) is the mapping of header		For each candidate technology, (how) is the mapping of header
	information present in tenant traffic mapped to corresponding header		information present in tenant traffic mapped to corresponding header
	information to be used in overlay encapsulation (this includes		information to be used in overlay encapsulation (this includes
	addresses, context identification, etc.) determined?		addresses, context identification, etc.) determined?
	+----------------------+---------+---------+-------+-------+--------+		+---------------------------------------+-------+-------+-------+
	| Supported Approach | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Supported Approach | VxLAN | VPLS | EVPN |
	+----------------------+---------+---------+-------+-------+--------+		+---------------------------------------+-------+-------+-------+
	| Control Protocol | | | | | |		| Control Protocol Mapping Acquisition? | | | |
	| Acquisition? | | | | | |		| - - - | - - - | - - - | - - |
	| - - - | - - - | - - - | - - - | - - - | - - - |		| Data-Plane Learning? | | | |
	| Data-Plane Learning? | | | | | |		+---------------------------------------+-------+-------+-------+
	+----------------------+---------+---------+-------+-------+--------+
	Table 1: Inner:Outer Address Mapping		Table 1: Inner:Outer Address Mapping (L2)
			+---------------------------------------+-------+-------+
			| Supported Approach | NVGRE | L3VPN |
			+---------------------------------------+-------+-------+
			| Control Protocol Mapping Acquisition? | | |
			| - - - | - - - | - - - |
			| Data-Plane Learning? | | |
			+---------------------------------------+-------+-------+
			Table 2: Inner:Outer Address Mapping (L3)
	(3.2) Underlying Network Multi-Destination Address(es)		(3.2) Underlying Network Multi-Destination Address(es)
	The requirements document [I-D.kreeger-nvo3-overlay-cp] lists 3
			The requirements document [I-D.ietf-nvo3-nve-nva-cp-req] lists 3
	approaches that may be used to deliver traffic to multiple		approaches that may be used to deliver traffic to multiple
	destinations in an overlay virtual network:		destinations in an overlay virtual network:
	1. Use the capabilities of the underlay network.		1. Use the capabilities of the underlay network.
	2. Require a sending NVE to replicate traffic.		2. Require a sending NVE to replicate traffic.
	3. Use a replication service provided within the overlay network.		3. Use a replication service provided within the overlay network.
	For each delivery approach, it may be necessary to map specific		For each delivery approach, it may be necessary to map specific
	multipoint (e.g. - broadcast, unknown destination or multicast)		multipoint (e.g. - broadcast, unknown destination or multicast)
	traffic to (for instance) addresses used to deliver this traffic via		traffic to (for instance) addresses used to deliver this traffic via
	the underlay network.		the underlay network.
	For each technological approach, which delivery approaches are		For each technological approach, which delivery approaches are
	supported and does the technology provide a method by which an NVE		supported and does the technology provide a method by which an NVE
	needing to send multi-destination traffic can determine to what		needing to send multi-destination traffic can determine to what
	address, or addresses to which to send this traffic?		address, or addresses to which to send this traffic?
	+---------------------+---------+---------+--------+-------+--------+		+------------------------------------+-------+-------+-------+
	| Supported Approach | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Supported Approach | VxLAN | VPLS | EVPN |
	+---------------------+---------+---------+--------+-------+--------+		+------------------------------------+-------+-------+-------+
	| Underlay Network | | | | | |		| Underlay Network Capability | | | |
	| Capability | | | | | |		| - - - | - - - | - - - | - - - |
	| - - - | - - - | - - - | - - - | - - - | - - - |		| NVE Sender Replication | | | |
	| NVE Sender | | | | | |		| - - - | - - - | - - - | - - - |
	| Replication | | | | | |		| Replication Service | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |		+------------------------------------+-------+-------+-------+
	| Replication Service | | | | | |
	+---------------------+---------+---------+--------+-------+--------+
	Table 2: Multi-Destination Delivery		Table 3: Multi-Destination Delivery (L2)
			+--------------------------------------+-------+-------+
			| Supported Approach | NVGRE | L3VPN |
			+--------------------------------------+-------+-------+
			| Underlay Network Capability | | |
			| - - - | - - - | - - - |
			| NVE Sender Replication | | |
			| - - - | - - - | - - - |
			| Replication Service | | |
			+--------------------------------------+-------+-------+
			Table 4: Multi-Destination Delivery (L3)
	(3.3) VN Connect/Disconnect Notification		(3.3) VN Connect/Disconnect Notification
	The requirements document [I-D.kreeger-nvo3-overlay-cp] states as an		The requirements document [I-D.ietf-nvo3-nve-nva-cp-req] states as an
	assumption that a mechanism exists in the overlay technology by which		assumption that a mechanism exists in the overlay technology by which
	an NVE is notified of Tenant Systems attaching and detaching from a		an NVE is notified of Tenant Systems attaching and detaching from a
	specific Virtual Network (VN).		specific Virtual Network (VN).
	For each candidate technology, does the technology currently support		For each candidate technology, does the technology currently support
	these functions?		these functions?
			+------------------------------------+-------+-------+-------+
			| Requirement | VxLAN | VPLS | EVPN |
			+------------------------------------+-------+-------+-------+
			| Connect Notification | | | |
			| - - - | - - - | - - - | - - - |
			| Disconnect Notification | | | |
			+------------------------------------+-------+-------+-------+
	+-------------------------+-------+-------+-------+-------+-------+		Table 5: Connect/Disconnect Notification (L2)
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+-------------------------+-------+-------+-------+-------+-------+
	| Connect Notification | | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |
	| Disconnect Notification | | | | | |
	+-------------------------+-------+-------+-------+-------+-------+
	Table 3: Connect/Disconnect Notification		+--------------------------------------+-------+-------+
			| Requirement | NVGRE | L3VPN |
			+--------------------------------------+-------+-------+
			| Connect Notification | | |
			| - - - | - - - | - - - |
			| Disconnect Notification | | |
			+--------------------------------------+-------+-------+
			Table 6: Connect/Disconnect Notification (L3)
	(3.4) VN Name to VNID Mapping		(3.4) VN Name to VNID Mapping
	The requirements document [I-D.kreeger-nvo3-overlay-cp] concludes		The requirements document [I-D.ietf-nvo3-nve-nva-cp-req] concludes
	that having a means to map for a "VN Name to a "VN ID" may be useful.		that having a means to map for a "VN Name to a "VN ID" may be useful.
	For each technological approach we are considering, is this function		For each technological approach we are considering, is this function
	currently available?		currently available?
	+-----------------------+-------+-------+------+------+-------+		+------------------------------------+-------+-------+-------+
	| Function | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Function | VxLAN | VPLS | EVPN |
	+-----------------------+-------+-------+------+------+-------+		+------------------------------------+-------+-------+-------+
	| VN-Name:VN-ID Mapping | | | | | |		| VN-Name:VN-ID Mapping | | | |
	+-----------------------+-------+-------+------+------+-------+		+------------------------------------+-------+-------+-------+
	Table 4: VN Name to VN ID Mapping		Table 7: VN Name to VN ID Mapping (L2)
			+--------------------------------------+-------+-------+
			| Function | NVGRE | L3VPN |
			+--------------------------------------+-------+-------+
			| VN-Name:VN-ID Mapping | | |
			+--------------------------------------+-------+-------+
			Table 8: VN Name to VN ID Mapping (L3)
	5.2. VM-to-NVE Specific Control-Plane Requirements		5.2. VM-to-NVE Specific Control-Plane Requirements
	In this section, numbering of requirement headings corresponds to		In this section, numbering of requirement headings corresponds to
	section numbering in [I-D.kreeger-nvo3-hypervisor-nve-cp].		section numbering in [I-D.kreeger-nvo3-hypervisor-nve-cp].
	(4.1) VN Connect/Disconnect		(4.1) VN Connect/Disconnect
	The requirements document [I-D.kreeger-nvo3-hypervisor-nve-cp] states		The requirements document [I-D.kreeger-nvo3-hypervisor-nve-cp] states
	as a requirement that a mechanism must exist by which an NVE is		as a requirement that a mechanism must exist by which an NVE is
	skipping to change at page 8, line 4 ¶		skipping to change at page 9, line 30 ¶
	sending traffic to, or receiving traffic from, the NVE (where that		sending traffic to, or receiving traffic from, the NVE (where that
	traffic is associated with the connected VN).		traffic is associated with the connected VN).
	As an additional related requirement, the requirements document		As an additional related requirement, the requirements document
	states that the NVE - once notified of a connection to a VN (by VN		states that the NVE - once notified of a connection to a VN (by VN
	Name), needs to have a means for getting associated VN context		Name), needs to have a means for getting associated VN context
	information from the NVA.		information from the NVA.
	For each candidate technology, does the technology currently support		For each candidate technology, does the technology currently support
	these functions?		these functions?
	+----------------------+---------+---------+-------+-------+--------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+----------------------+---------+---------+-------+-------+--------+
	| Connect Notification | | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |
	| Local VN Indicator | | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |
	| VN Name to VN | | | | | |
	| Context Mapping | | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |
	| Disconnect | | | | | |
	| Notification | | | | | |
	+----------------------+---------+---------+-------+-------+--------+
	Table 5: VN Connect/Disconnect		+------------------------------------+-------+-------+-------+
			| Requirement | VxLAN | VPLS | EVPN |
			+------------------------------------+-------+-------+-------+
			| Connect Notification | | | |
			| - - - | - - - | - - - | - - - |
			| Local VN Indicator | | | |
			| - - - | - - - | - - - | - - - |
			| VN Name to VN Context Mapping | | | |
			| - - - | - - - | - - - | - - - |
			| Disconnect Notification | | | |
			+------------------------------------+-------+-------+-------+
			Table 9: VN Connect/Disconnect (L2)
			+--------------------------------------+-------+-------+
			| Requirement | NVGRE | L3VPN |
			+--------------------------------------+-------+-------+
			| Connect Notification | | |
			| - - - | - - - | - - - |
			| Local VN Indicator | | |
			| - - - | - - - | - - - |
			| VN Name to VN Context Mapping | | |
			| - - - | - - - | - - - |
			| Disconnect Notification | | |
			+--------------------------------------+-------+-------+
			Table 10: VN Connect/Disconnect (L3)
	(4.2) VNIC Address Association		(4.2) VNIC Address Association
	The requirements document [I-D.kreeger-nvo3-hypervisor-nve-cp] lists		The requirements document [I-D.kreeger-nvo3-hypervisor-nve-cp] lists
	two approaches for acquiring VNIC address association information:		two approaches for acquiring VNIC address association information:
	1. Data Plane Learning (i.e. - by inspecting source addresses in		1. Data Plane Learning (i.e. - by inspecting source addresses in
	traffic received from an end device).		traffic received from an end device).
	2. Explicit signaling from the end device when a specific VNIC		2. Explicit signaling from the end device when a specific VNIC
	address is to be associated with a tenant system.		address is to be associated with a tenant system.
	+----------------------+-------+-------+-------+-------+-------+		+------------------------------------+-------+-------+-------+
	| Supported Approaches | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Supported Approaches | VxLAN | VPLS | EVPN |
	+----------------------+-------+-------+-------+-------+-------+		+------------------------------------+-------+-------+-------+
	| Data Plane Learning | | | | | |		| Data Plane Learning | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |		| - - - | - - - | - - - | - - - |
	| Explicit Signaling | | | | | |		| Explicit Signaling | | | |
	+----------------------+-------+-------+-------+-------+-------+		+------------------------------------+-------+-------+-------+
	Table 6: VNIC Address Association		Table 11: VNIC Address Association (L2)
			+--------------------------------------+-------+-------+
			| Supported Approaches | NVGRE | L3VPN |
			+--------------------------------------+-------+-------+
			| Data Plane Learning | | |
			| - - - | - - - | - - - |
			| Explicit Signaling | | |
			+--------------------------------------+-------+-------+
			Table 12: VNIC Address Association (L3)
	(4.3) VNIC Address Disassociation		(4.3) VNIC Address Disassociation
	TBD		TBD
	(4.4) VNIC Shutdown/Startup/Migration		(4.4) VNIC Shutdown/Startup/Migration
	TBD		TBD
	(4.5) VN Profile		(4.5) VN Profile
	TBD		TBD
	6. Data Plane Requirements		6. Data Plane Requirements
	In this section, numbering of requirement headings corresponds to		In this section, numbering of requirement headings corresponds to
	section numbering in [I-D.ietf-nvo3-dataplane-requirements].		section numbering in [I-D.ietf-nvo3-dataplane-requirements].
	(3.1) Virtual Access Points (VAPs)		(3.1) Virtual Access Points (VAPs)
	+------------------------+--------+-------+--------+--------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+------------------------+--------+-------+--------+--------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| MUST support VAP | | | | | |		| MUST support VAP | | | | | |
	| identification | | | | | |		| identification | | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |		| - - - | - - - | - - - | - - | - - | - - - |
	| 1) Local interface | YES | | | | |		| 1) Local interface | YES | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |		| - - - | - - - | - - - | - - | - - | - - - |
	| 2) Local interface + | YES | | | | |		| 2) Local interface + fields | YES | | | | |
	| fields in frame header | | | | | |		| in frame header | | | | | |
	+------------------------+--------+-------+--------+--------+-------+		+-----------------------------+-------+-------+------+------+-------+
	Table 7: VAP Identification Requirements		Table 13: VAP Identification Requirements
	(3.2) Virtual Network Instance (VNI)		(3.2) Virtual Network Instance (VNI)
	+-------------------------+-------+-------+--------+--------+-------+		Network virtualization can be provided by L2 and/or L3 VNIs.
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+-------------------------+-------+-------+--------+--------+-------+
	| VAP are associated with | YES | | | | |
	| a specific VNI at | | | | | |
	| service instantiation | | | | | |
	| time. | | | | | |
	+-------------------------+-------+-------+--------+--------+-------+
	Table 8: VAP-VNI Association
	(3.2.1) L2 VNI		(3.2.1) L2 VNI
			+-----------------------------+-------+-------+------+------+-------+
			| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
			+-----------------------------+-------+-------+------+------+-------+
			| L2 VNI MUST provide an | | | | | |
			| emulated Ethernet | | | | | |
			| multipoint service as if | | | | | |
			| Tenant Systems are | | | | | |
			| interconnected by a bridge | | | | | |
			| (but instead by using a set | | | | | |
			| of NVO3 tunnels). | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| Loop avoidance capability | | | | | |
			| MUST be provided. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| Data plane learning MUST be | | | | | |
			| supported as the default | | | | | |
			| means to populate | | | | | |
			| forwarding tables. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| When flooding is required | | | | | |
			| for delivery of broadcast, | | | | | |
			| unknown unicast or | | | | | |
			| multicast (BUM) traffic, | | | | | |
			| the NVE MUST either support | | | | | |
			| ingress replication or | | | | | |
			| multicast. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| If using multicast, the NVE | | | | | |
			| MUST be able to build at | | | | | |
			| least one default flooding | | | | | |
			| tree for use by local VNIs | | | | | |
			| for flooding to NVEs | | | | | |
			| belonging to the same VN. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	+----------------------------+-------+-------+-------+------+-------+		Table 14: L2 VNI Service
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+----------------------------+-------+-------+-------+------+-------+
	| L2 VNI MUST provide an | | | | | |
	| emulated Ethernet | | | | | |
	| multipoint service as if | | | | | |
	| Tenant Systems are | | | | | |
	| interconnected by a bridge | | | | | |
	| (but instead by using a | | | | | |
	| set of NVO3 tunnels). | | | | | |
	| - - - | - - - | - - - | - - - | - - | - - - |
	| | | | | - | |
	| Loop avoidance capability | | | | | |
	| MUST be provided. | | | | | |
	| - - - | - - - | - - - | - - - | - - | - - - |
	| | | | | - | |
	| In the absence of a | | | | | |
	| management or control | | | | | |
	| plane, data plane learning | | | | | |
	| MUST be used to populate | | | | | |
	| forwarding tables. | | | | | |
	| - - - | - - - | - - - | - - - | - - | - - - |
	| | | | | - | |
	| When flooding is required, | | | | | |
	| either to deliver unknown | | | | | |
	| unicast, or broadcast or | | | | | |
	| multicast traffic, the NVE | | | | | |
	| MUST either support | | | | | |
	| ingress replication or | | | | | |
	| multicast. | | | | | |
	| - - - | - - - | - - - | - - - | - - | - - - |
	| | | | | - | |
	| In this latter case, the | | | | | |
	| NVE MUST be able to build | | | | | |
	| at least a default | | | | | |
	| flooding tree per VNI. | | | | | |
	+----------------------------+-------+-------+-------+------+-------+
	Table 9: L2 VNI Service
	(3.2.2) L3 VNI		(3.2.2) L3 VNI
			+-----------------------------+-------+-------+------+------+-------+
			| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
			+-----------------------------+-------+-------+------+------+-------+
			| L3 VNIs MUST provide | | | | | |
			| virtualized IP routing and | | | | | |
			| forwarding. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| L3 VNIs MUST support per- | | | | | |
			| tenant forwarding instance | | | | | |
			| with IP addressing | | | | | |
			| isolation and L3 tunneling | | | | | |
			| for interconnecting | | | | | |
			| instances of the same VNI | | | | | |
			| on NVEs. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| For L3 VNI, the inner TTL | | | | | |
			| field MUST be decremented | | | | | |
			| by at least 1 (as if the | | | | | |
			| NVO3 egress was at least 1 | | | | | |
			| hop away). | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| TTL in the outer IP header | | | | | |
			| MUST be set to a value | | | | | |
			| appropriate for delivery of | | | | | |
			| the encapsulated packet to | | | | | |
			| the tunnel exit point. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| The default behavior for | | | | | |
			| TTL MUST use the "pipe" | | | | | |
			| model. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	+---------------------------+-------+-------+--------+------+-------+		Table 15: L3 VNI Service
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+---------------------------+-------+-------+--------+------+-------+
	| L3 VNIs MUST provide | | | | | |
	| virtualized IP routing | | | | | |
	| and forwarding. | | | | | |
	| - - - | - - - | - - - | - - - | - - | - - - |
	| | | | | - | |
	| L3 VNIs MUST support per- | | | | | |
	| tenant forwarding | | | | | |
	| instance with IP | | | | | |
	| addressing isolation and | | | | | |
	| L3 tunneling for | | | | | |
	| interconnecting instances | | | | | |
	| of the same VNI on NVEs. | | | | | |
	+---------------------------+-------+-------+--------+------+-------+
	Table 10: L3 VNI Service
	(3.3.1) NVO3 overlay header		(3.3.1) NVO3 overlay header
	+---------------------------+-------+-------+--------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+---------------------------+-------+-------+--------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| An NVO3 overlay header | YES | YES | YES | YES | YES |		| An NVO3 overlay header MUST | YES | YES | YES | YES | YES |
	| MUST be included after | | | | | |		| be included after the | | | | | |
	| the underlay tunnel | | | | | |		| underlay tunnel header when | | | | | |
	| header when forwarding | | | | | |		| forwarding tenant traffic. | | | | | |
	| tenant traffic. | | | | | |		+-----------------------------+-------+-------+------+------+-------+
	+---------------------------+-------+-------+--------+------+-------+
	Table 11: Overlay Header		Table 16: Overlay Header
	(3.3.1.1) Virtual Network Context Identification		(3.3.1.1) Virtual Network Context Identification
			+-----------------------------+-------+-------+------+------+-------+
			| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
			+-----------------------------+-------+-------+------+------+-------+
			| The overlay encapsulation | YES | YES | YES | YES | YES |
			| header MUST contain a field | | | | | |
			| which allows the | | | | | |
			| encapsulated frame to be | | | | | |
			| delivered to the | | | | | |
			| appropriate virtual network | | | | | |
			| endpoint by the egress NVE. | | | | | |
			| . | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| If Global Identifiers are | | | | | |
			| used, the identifier field | | | | | |
			| MUST be large enough to | | | | | |
			| scale to hundreds of | | | | | |
			| thousands of VNs. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	+---------------------------+-------+-------+--------+------+-------+		Table 17: Virtual Network Context Identification
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+---------------------------+-------+-------+--------+------+-------+
	| The overlay encapsulation | YES | YES | YES | YES | YES |
	| header MUST contain a | | | | | |
	| field which allows the | | | | | |
	| encapsulated frame to be | | | | | |
	| delivered to the | | | | | |
	| appropriate virtual | | | | | |
	| network endpoint by the | | | | | |
	| egress NVE. | | | | | |
	+---------------------------+-------+-------+--------+------+-------+
	Table 12: Virtual Network Context Identification
	(3.3.1.2) Service QoS identifier
	+----------------------------+-------+-------+-------+------+-------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+----------------------------+-------+-------+-------+------+-------+
	| Traffic flows originating | NO | | | | |
	| from different | | | | | |
	| applications could rely on | | | | | |
	| differentiated forwarding | | | | | |
	| treatment to meet end-to- | | | | | |
	| end availability and | | | | | |
	| performance objectives. | | | | | |
	+----------------------------+-------+-------+-------+------+-------+
	Table 13: QoS Service Identification
	(3.3.2.1) LAG and ECMP		(3.3.2.1) LAG and ECMP
	+-------------------------+-------+-------+--------+--------+-------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+-------------------------+-------+-------+--------+--------+-------+
	| For performance | YES | | | | |
	| reasons, multipath over | | | | | |
	| LAG and ECMP paths | | | | | |
	| SHOULD be supported. | | | | | |
	+-------------------------+-------+-------+--------+--------+-------+
	Table 14: Multipath Support		+-----------------------------+-------+-------+------+------+-------+
			| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
			+-----------------------------+-------+-------+------+------+-------+
			| In order to perform fine- | | | | | |
			| grained load-balancing, the | | | | | |
			| data-plane encapsulation | | | | | |
			| MUST result in sufficient | | | | | |
			| entropy to exercise all | | | | | |
			| paths through several | | | | | |
			| LAG/ECMP hops. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| All packets belonging to | NO | | | | |
			| any specific flow MUST | | | | | |
			| follow the same path in | | | | | |
			| order to prevent packet re- | | | | | |
			| ordering. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	(3.3.2.2) DiffServ and ECN marking		Table 18: Multipath Support
	+---------------------------+-------+-------+--------+------+-------+		(3.3.2.2) DiffServ and ECN marking
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		+-----------------------------+-------+-------+------+------+-------+
	+---------------------------+-------+-------+--------+------+-------+		| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	| [RFC2983] defines two | NO | | | | |		+-----------------------------+-------+-------+------+------+-------+
	| modes for mapping the | | | | | |		| [RFC2983] defines two modes | NO | | | | |
	| DSCP markings from inner | | | | | |		| for mapping the DSCP | | | | | |
	| to outer headers and vice | | | | | |		| markings from inner to | | | | | |
	| versa. Both models SHOULD | | | | | |		| outer headers and vice | | | | | |
	| be supported. | | | | | |		| versa. Both models SHOULD | | | | | |
	| - - - | - - - | - - - | - - - | - - | - - - |		| be supported. | | | | | |
	| | | | | - | |		+-----------------------------+-------+-------+------+------+-------+
	| ECN marking MUST be | NO | | | | |
	| performed according to | | | | | |
	| [RFC6040] which describes | | | | | |
	| the correct ECN behavior | | | | | |
	| for IP tunnels. | | | | | |
	+---------------------------+-------+-------+--------+------+-------+
	Table 15: DSCP and ECN Marking		Table 19: DSCP and ECN Marking
	(3.3.2.3) Handling of broadcast, unknown unicast, and multicast		(3.3.2.3) Handling of broadcast, unknown unicast, and multicast
	traffic		traffic
			NVO3 data plane support for either ingress replication or point-to-
			multipoint tunnels is required to send traffic destined to multiple
			locations on a per-VNI basis (e.g. L2/L3 multicast traffic, L2
			broadcast and unknown unicast traffic). It is possible that both
			methods be used simultaneously.
	+-----------------------------+-------+-------+------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+-----------------------------+-------+-------+------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| NVO3 data plane support for | YES | YES | YES | YES | YES |		| User-configurable knobs | | | | | |
	| either ingress replication | | | | | |		| MUST be provided to select | | | | | |
	| or point-to-multipoint | | | | | |		| which method(s) are used | | | | | |
	| tunnels is required to send | | | | | |		| based upon the amount of | | | | | |
	| traffic destined to | | | | | |		| replication required. | | | | | |
	| multiple locations on a | | | | | |		| - - - | - - - | - - - | - - | - - | - - - |
	| per-VNI basis (e.g. L2/L3 | | | | | |		| When ingress replication is | | | | | |
	| multicast traffic, L2 | | | | | |		| used, NVEs MUST track | | | | | |
	| broadcast and unknown | | | | | |		| maintain (for each VNI) the | | | | | |
	| unicast traffic). | | | | | |		| related tunnel endpoints to | | | | | |
			| which it needs to replicate | | | | | |
			| the frame. | | | | | |
	+-----------------------------+-------+-------+------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	Table 16: Handling of Broadcast, Unknown Unicast, and Multicast		Table 20: Handling of Broadcast, Unknown Unicast, and Multicast
	Traffic		Traffic
	(3.4) External NVO3 connectivity		(3.4) External NVO3 connectivity
			+-----------------------------+-------+-------+------+------+-------+
			| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
			+-----------------------------+-------+-------+------+------+-------+
			| NVO3 services MUST | YES | | | | |
			| interoperate with current | | | | | |
			| VPN and Internet services. | | | | | |
			| This may happen inside one | | | | | |
			| DC during a migration phase | | | | | |
			| or as NVO3 services are | | | | | |
			| delivered to the outside | | | | | |
			| world via Internet or VPN | | | | | |
			| gateways. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| Redundancy between NVO3 and | | | | | |
			| external domains MUST be | | | | | |
			| supported. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	+----------------------------+-------+-------+-------+------+-------+		Table 21: Interoperation
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+----------------------------+-------+-------+-------+------+-------+
	| NVO3 services MUST | YES | | | | |
	| interoperate with current | | | | | |
	| VPN and Internet services. | | | | | |
	| This may happen inside one | | | | | |
	| DC during a migration | | | | | |
	| phase or as NVO3 services | | | | | |
	| are delivered to the | | | | | |
	| outside world via Internet | | | | | |
	| or VPN gateways. | | | | | |
	+----------------------------+-------+-------+-------+------+-------+
	Table 17: Interoperation
	(3.5) Path MTU		(3.4.2.1) Load-balancing
	+--------------------------+-------+-------+--------+-------+-------+		When using active-active load-balancing across physically separate
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		NVE GW's (e.g.: two, separate chassis) an NVO3 solution SHOULD
	+--------------------------+-------+-------+--------+-------+-------+		support forwarding tables that can simultaneously map a single egress
	| Classical ICMP-based MTU | NO | | | | |		NVE to more than one NVO3 tunnels.
	| Path Discovery | | | | | |
	| ([RFC1191], [RFC1981]) | | | | | |
	| or Extended MTU Path | | | | | |
	| Discovery techniques | | | | | |
	| such as defined in | | | | | |
	| [RFC4821]. | | | | | |
	| - - - | - - - | - - - | - - - | - - - | - - - |
	| Segmentation and | YES | | | | |
	| reassembly support from | | | | | |
	| the overlay layer | | | | | |
	| operations without | | | | | |
	| relying on the Tenant | | | | | |
	| Systems to know about | | | | | |
	| the end-to-end MTU. | | | | | |
	+--------------------------+-------+-------+--------+-------+-------+
	Table 18: Path MTU		+-----------------------------+-------+-------+------+------+-------+
			| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
			+-----------------------------+-------+-------+------+------+-------+
			| The granularity of such | | | | | |
			| mappings, in both active- | | | | | |
			| backup and active-active, | | | | | |
			| MUST be specific to each | | | | | |
			| tenant. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	(3.7) NVE Multi-Homing Requirements		Table 22: Gateway Load-balancing
	+--------------------------+-------+-------+--------+-------+-------+		(3.5) Path MTU
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		+-----------------------------+-------+-------+------+------+-------+
	+--------------------------+-------+-------+--------+-------+-------+		| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	| Multi-homing techniques | NO | | | | |		+-----------------------------+-------+-------+------+------+-------+
	| SHOULD be used to | | | | | |		| Classical ICMP-based MTU | NO | | | | |
	| increase the reliability | | | | | |		| Path Discovery ([RFC1191], | | | | | |
	| of an NVO3 network. | | | | | |		| [RFC1981]) or Extended MTU | | | | | |
	+--------------------------+-------+-------+--------+-------+-------+		| Path Discovery techniques | | | | | |
			| such as defined in | | | | | |
			| [RFC4821]. | | | | | |
			| - - - | - - - | - - - | - - | - - | - - - |
			| Fragmentation and | YES | | | | |
			| reassembly support from the | | | | | |
			| overlay layer operations | | | | | |
			| without relying on the | | | | | |
			| Tenant Systems to know | | | | | |
			| about the end-to-end MTU. | | | | | |
			+-----------------------------+-------+-------+------+------+-------+
	Table 19: Multihoming		Table 23: Path MTU
	(3.8) OAM		(3.7) NVE Multi-Homing Requirements
	+-----------------------------+-------+-------+------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |		| Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN |
	+-----------------------------+-------+-------+------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	| NVE MAY be able to | NO | | | | |		| Multi-homing techniques | NO | | | | |
	| originate/terminate OAM | | | | | |		| SHOULD be used to increase | | | | | |
	| messages for connectivity | | | | | |		| the reliability of an NVO3 | | | | | |
	| verification, performance | | | | | |		| network. | | | | | |
	| monitoring, statistic | | | | | |
	| gathering and fault | | | | | |
	| isolation. Depending on | | | | | |
	| configuration, NVEs SHOULD | | | | | |
	| be able to process or | | | | | |
	| transparently tunnel OAM | | | | | |
	| messages, as well as | | | | | |
	| supporting alarm | | | | | |
	| propagation capabilities. | | | | | |
	+-----------------------------+-------+-------+------+------+-------+		+-----------------------------+-------+-------+------+------+-------+
	Table 20: OAM Messaging		Table 24: Multihoming
	7. Summary and Conclusions		7. Summary and Conclusions
	TBD		TBD
	8. Acknowledgements		8. Acknowledgements
	The Authors would like to acknowledge the technical contributions of		The Authors would like to acknowledge the technical contributions of
	Florin Balus, Luyuan Fang, Sue Hares, Wim Henderickx, Yuichi Ikejiri,		Florin Balus, Luyuan Fang, Sue Hares, Wim Henderickx, Yves Hertoghs,
	Rangaraju Iyengar, Mircea Pisica, Evelyn Roch, Ali Sajassi, Peter		Yuichi Ikejiri, Rangaraju Iyengar, Mircea Pisica, Evelyn Roch, Ali
	Ashwood-Smith and Lucy Yong as well as the initial help in editing		Sajassi, Peter Ashwood-Smith and Lucy Yong as well as the initial
	the XML source for the document from Tom Taylor.		help in editing the XML source for the document from Tom Taylor.
	9. IANA Considerations		9. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	10. Security Considerations		10. Security Considerations
	Security considerations of the requirements documents referenced by		Security considerations of the requirements documents referenced by
	this analysis document apply.		this analysis document apply.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ashwood-nvo3-operational-requirement]		[I-D.ashwood-nvo3-operational-requirement]
	Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A.,		Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A.,
	Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3		Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3
	Operational Requirements", draft-ashwood-nvo3-operational-		Operational Requirements", draft-ashwood-nvo3-operational-
	requirement-03 (work in progress), July 2013.		requirement-03 (work in progress), July 2013.
			[I-D.hertoghs-nvo3-lisp-controlplane-unified]
			Hertoghs, Y., Maino, F., Moreno, V., Smith, M., Farinacci,
			D., and L. Iannone, "A Unified LISP Mapping Database for
			L2 and L3 Network Virtualization Overlays", draft-
			hertoghs-nvo3-lisp-controlplane-unified-01 (work in
			progress), February 2014.
	[I-D.ietf-l2vpn-evpn]		[I-D.ietf-l2vpn-evpn]
	Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,		Sajassi, A., Aggarwal, R., Henderickx, W., Isaac, A., and
	Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",		J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-
	draft-ietf-l2vpn-evpn-04 (work in progress), July 2013.		l2vpn-evpn-05 (work in progress), February 2014.
	[I-D.ietf-nvo3-dataplane-requirements]		[I-D.ietf-nvo3-dataplane-requirements]
	Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L.,		Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L.,
	and B. Khasnabish, "NVO3 Data Plane Requirements", draft-		and B. Khasnabish, "NVO3 Data Plane Requirements", draft-
	ietf-nvo3-dataplane-requirements-01 (work in progress),		ietf-nvo3-dataplane-requirements-02 (work in progress),
	July 2013.		November 2013.
	[I-D.ietf-nvo3-framework]		[I-D.ietf-nvo3-framework]
	Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.		Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
	Rekhter, "Framework for DC Network Virtualization", draft-		Rekhter, "Framework for DC Network Virtualization", draft-
	ietf-nvo3-framework-03 (work in progress), July 2013.		ietf-nvo3-framework-05 (work in progress), January 2014.
			[I-D.ietf-nvo3-nve-nva-cp-req]
			Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network
			Virtualization NVE to NVA Control Protocol Requirements",
			draft-ietf-nvo3-nve-nva-cp-req-01 (work in progress),
			October 2013.
	[I-D.ietf-nvo3-overlay-problem-statement]		[I-D.ietf-nvo3-overlay-problem-statement]
	Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,		Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
	and M. Napierala, "Problem Statement: Overlays for Network		and M. Napierala, "Problem Statement: Overlays for Network
	Virtualization", draft-ietf-nvo3-overlay-problem-		Virtualization", draft-ietf-nvo3-overlay-problem-
	statement-04 (work in progress), July 2013.		statement-04 (work in progress), July 2013.
	[I-D.kreeger-nvo3-hypervisor-nve-cp]		[I-D.kreeger-nvo3-hypervisor-nve-cp]
	Kreeger, L., Narten, T., and D. Black, "Network		Kreeger, L., Narten, T., and D. Black, "Network
	Virtualization Hypervisor-to-NVE Overlay Control Protocol		Virtualization Hypervisor-to-NVE Overlay Control Protocol
	Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01		Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01
	(work in progress), February 2013.		(work in progress), February 2013.
	[I-D.kreeger-nvo3-overlay-cp]
	Kreeger, L., Dutt, D., Narten, T., Black, D., and M.
	Sridharan, "Network Virtualization Overlay Control
	Protocol Requirements", draft-kreeger-nvo3-overlay-cp-04
	(work in progress), June 2013.
	[I-D.mahalingam-dutt-dcops-vxlan]		[I-D.mahalingam-dutt-dcops-vxlan]
	Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A		L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
	Framework for Overlaying Virtualized Layer 2 Networks over		Framework for Overlaying Virtualized Layer 2 Networks over
	Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-04		Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-08
	(work in progress), May 2013.		(work in progress), February 2014.
	[I-D.sridharan-virtualization-nvgre]		[I-D.sridharan-virtualization-nvgre]
	Sridharan, M., Greenberg, A., Wang, Y., Garg, P.,		Sridharan, M., Greenberg, A., Wang, Y., Garg, P.,
	Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson,		Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson,
	M., Thaler, P., and C. Tumuluri, "NVGRE: Network		M., Thaler, P., and C. Tumuluri, "NVGRE: Network
	Virtualization using Generic Routing Encapsulation",		Virtualization using Generic Routing Encapsulation",
	draft-sridharan-virtualization-nvgre-03 (work in		draft-sridharan-virtualization-nvgre-04 (work in
	progress), August 2013.		progress), February 2014.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
	[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	for IP version 6", RFC 1981, August 1996.		for IP version 6", RFC 1981, August 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 69 change blocks.
	324 lines changed or deleted		417 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/