One document matched: draft-ietf-nvo3-gap-analysis-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.ietf-l2vpn-evpn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-l2vpn-evpn.xml">
<!ENTITY I-D.ietf-nvo3-overlay-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-overlay-problem-statement.xml">
<!ENTITY I-D.kreeger-nvo3-hypervisor-nve-cp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kreeger-nvo3-hypervisor-nve-cp.xml">
<!ENTITY I-D.ashwood-nvo3-operational-requirement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ashwood-nvo3-operational-requirement.xml">
<!ENTITY I-D.hertoghs-nvo3-lisp-controlplane-unified SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hertoghs-nvo3-lisp-controlplane-unified.xml">
<!ENTITY I-D.ietf-nvo3-nve-nva-cp-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-nve-nva-cp-req.xml">
<!ENTITY I-D.ietf-nvo3-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-framework.xml">
<!ENTITY I-D.ietf-nvo3-dataplane-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-dataplane-requirements.xml">
<!ENTITY I-D.sridharan-virtualization-nvgre SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.sridharan-virtualization-nvgre.xml">
<!ENTITY I-D.mahalingam-dutt-dcops-vxlan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mahalingam-dutt-dcops-vxlan.xml">
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC1981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2983 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2983.xml">
<!ENTITY RFC3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC4365 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4365.xml">
<!ENTITY RFC4761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4761.xml">
<!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml">
<!ENTITY RFC4821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY RFC6040 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6040.xml">
<!ENTITY RFC6074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6074.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-nvo3-gap-analysis-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="NVO3 Gap Analysis">NVO3 Gap Analysis - Requirements Versus Available Technology Choices</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="E." surname="Gray" fullname="Eric Gray" role="editor">
<organization>Ericsson</organization>
<address>
<postal>
<street>120 Morris Avenue</street>
<city>Pitman</city>
<region>New Jersey</region>
<code>08071</code>
<country>USA</country>
</postal>
<phone></phone>
<email>eric.gray@ericsson.com</email>
</address>
</author>
<author initials="N." surname="Bitar" fullname="Nabil Bitar">
<organization>Verizon</organization>
<address>
<postal>
<street>40 Sylvan Road</street>
<city>Waltham</city>
<region>Massachusetts</region>
<code>02145</code>
<country>USA</country>
</postal>
<phone></phone>
<email>nabil.bitar@verizon.com</email>
</address>
</author>
<author initials="X." surname="Chen" fullname="Xiaoming Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>ming.chen@huawei.com</email>
</address>
</author>
<author initials="M." surname="Lasserre" fullname="Marc Lasserre">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>marc.lasserre@alcatel-lucent.com</email>
</address>
</author>
<author initials="T." surname="Tsou" fullname="Tina Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>California</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>Tina.Tsou.Zouting@huawei.com</email>
<uri>http://tinatsou.weebly.com/contact.html</uri>
</address>
</author>
<!--
<author initials="E." surname="Roch" fullname="Evelyne Roch">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>303 Terry Fox Drive, Suite 400</street>
<city>Kanata</city>
<region>Ontario</region>
<country>Canada</country>
<code>K2K 3J1</code>
</postal>
<phone>+1 613 595 1900 x1612</phone>
<email>evelyne.roch@huawei.com</email>
</address>
</author>
-->
<date year="2014" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is
"Network Working Group", which is used by the
RFC Editor as a nod to the history of the IETF.
-->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document evaluates candidate protocols against the NVO3
requirements. Gaps are identified and further work recommended.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The initial charter of the NVO3 Working Group requires it to
identify any gaps between the requirements identified and
available technoloogy solutions as a prerequisite to
rechartering or concluding the Working Group (if no gaps
exist). This document is intended to provide the required
gap analysis.
</t>
<t>
This document provides a tabulation of candidate solutions
and their ability to satisfy each requirement identified by
the Working Group.
</t>
<t>
Areas of work are identified where further work is required
to ensure that the requirements are met.
</t>
<t>
The major areas covered in this document include:
<list style="symbols">
<t>
Operational Requirements
<xref target="I-D.ashwood-nvo3-operational-requirement"/>
</t>
<t>
Management Requirements (TBD)
</t>
<t>
Control (Plane) Requirements
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>
</t>
<t>
Dataplane Requirements
<xref target="I-D.ietf-nvo3-dataplane-requirements"/>
</t>
</list>
</t>
<t>
Since the Working Group has yet to complete (and in some
cases adopt) documents describing requirements for some
of these areas, not all areas are complete in the present
version of this document.
</t>
<t>
The initial candidate technologies are:
<list style="symbols">
<t>
NVGRE <xref target="I-D.sridharan-virtualization-nvgre"/>,
</t>
<t>
VxLAN <xref target="I-D.mahalingam-dutt-dcops-vxlan"/>,
</t>
<t>
L2VPN: VPLS <xref target="RFC4761"/><xref target="RFC4762"/>
and EVPN <xref target="I-D.ietf-l2vpn-evpn"/>, and
</t>
<t>
L3VPN <xref target="RFC4365"/>.
</t>
</list>
</t>
</section> <!-- Introduction -->
<section title="Terminology and Conventions">
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section> <!-- Requirements Language -->
<section anchor="convent" title="Conventions">
<t>
In sections providing analysis of requirements defined in
referenced documents, section numbers from each referenced
document are used as they were listed in that document.
</t>
<t>
In order to avoid confusing those section numbers with the
section numbering in this document, the included numbering
is parenthesized.
</t>
<t>
L2VPN is represented (in tables and analysis, as a
technology) by the two differing approaches: VPLS and EVPN.
</t>
</section> <!-- convent -->
<section anchor="abbrev" title="Terms and Abbreviations">
<t>
This document uses terms and acronyms defined in
<xref target="RFC3168"/>,
<xref target="I-D.ietf-nvo3-framework"/>,
<xref target="I-D.ietf-nvo3-dataplane-requirements"/>,
<xref target="I-D.kreeger-nvo3-hypervisor-nve-cp"/> and
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>. Acronyms are
included here for convenience but are meant to remain
aligned with definitions in the references included.
<list style="hanging">
<t hangText="ECN:">Explicit Congestion Notification
<xref target="RFC3168"/>
</t>
<t hangText="NVA:">Network Virtualization Authority
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>
</t>
<t hangText="NVE:">Network Virtualization Edge
<xref target="I-D.ietf-nvo3-framework"/>
</t>
<t hangText="VAP:">Virtual Access Point
<xref target="I-D.ietf-nvo3-dataplane-requirements"/>
</t>
<t hangText="VNI:">Virtual Network Instance
<xref target="I-D.ietf-nvo3-framework"/>
</t>
<t hangText="VNIC:">Virtual Network Interface Card (NIC)
<xref target="I-D.kreeger-nvo3-hypervisor-nve-cp"/>
</t>
<t hangText="VNID:">Virtual Network Identifier
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>
</t>
</list>
</t>
<t>
This document uses the following additional general terms
and abbreviations:
<list style="hanging">
<t hangText="DSCP:">Differentiated Services Code-Point
</t>
<t hangText="ECMP:">Equal Cost Multi-Path
</t>
<t hangText="L2VPN:">Layer 2 Virtual Private Network
</t>
<t hangText="L3VPN:">Layer 3 Virtual Private Network
</t>
<t hangText="NVO3:">Network Virtualization Overlay over L3
</t>
<t hangText="VM:">Virtual Machine
</t>
<t hangText="VN:">Virtual Network
</t>
</list>
</t>
</section> <!-- abbrev -->
</section>
<section anchor="operlReq" title="Operational Requirements">
<t>TBD</t>
<!--
<texttable anchor="OprlRqT" title="Table Header">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Row 1 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 2 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 3 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
-->
</section> <!-- operlReq -->
<section anchor="mgmtReq" title="Management Requirements">
<t>TBD</t>
<!--
<texttable anchor="MgmtReqT" title="Table Header">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Row 1 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 2 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Row 3 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
-->
</section> <!-- mgmtReq -->
<section anchor="ctlReq" title="Control Plane Requirements">
<t>The NVO3 Problem Statement
<xref target="I-D.ietf-nvo3-overlay-problem-statement"/>,
describes 3 categories of control functions:
<list style="numbers">
<t>
Control functions associated with implementing the Network
Virtualization Authority (e.g. - signaling and control
required for interactions between multiple NVA devices).
</t>
<t>
Control functions associated with interactions between an
NVA and a Network Virtualization Edge (NVE).
</t>
<t>
Control functions associated with attaching and detaching
a Virtual Machine (VM) from a particular Virtual Network
Instance (VNI).
</t>
</list>
</t>
<t>
As sometimes happens, there is not a 1:1 mapping of the work
areas defined in
<xref target="I-D.ietf-nvo3-overlay-problem-statement"/> and
requirements documents intended to address the problems that
have been identified there.
</t>
<!-- Removed based on comment from Marc Lasserre (too controversial)
<t>
Part of the reason for this appears to be that at least one
of the solutions being considered collapses the NVA-NVA and
NVA-NVE control protocol requirements into a single control
plane (i.e. - the NVA-NVE protocol may be used as an NVA-NVA
protocol as well).
</t>
-->
<t>
Current control-plane requirement documents include the
following:
<list style="symbols">
<t>
NVE-NVA control-plane requirements
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>
</t>
<t>
Control-plane requirements specific to VM-to-NVE
interactions
<xref target="I-D.kreeger-nvo3-hypervisor-nve-cp"/>
</t>
</list>
</t>
<t>
In the following subsections, we consider the data-plane
candidate solutions and proposed or existing control plane
solutions that may apply to each.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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."
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section anchor="nve2nvacpreqs" title="NVE-NVA Control-Plane Requirements">
<t>
In this section, numbering of requirement headings
corresponds to section numbering in
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>.
</t>
<t>
(3.1) Inner to Outer Address Mapping
</t>
<t>
The requirements document
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>
states that avoiding the need to "flood" traffic to support
learning of mapping information from the data-plane is a goal
of NVO3 candidate technological approaches.
</t>
<t>
For each candidate technology, (how) is the mapping of header
information present in tenant traffic mapped to corresponding
header information to be used in overlay encapsulation (this
includes addresses, context identification, etc.) determined?
</t>
<texttable anchor="OA3pt1TL2" title="Inner:Outer Address Mapping (L2)">
<ttcol width="60%" align="left">Supported Approach</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<c>Control Protocol Mapping Acquisition?</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>Data-Plane Learning?</c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable anchor="OA3pt1TL3" title="Inner:Outer Address Mapping (L3)">
<ttcol width="60%" align="left">Supported Approach</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Control Protocol Mapping Acquisition?</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Data-Plane Learning?</c>
<c></c>
<c></c>
</texttable>
<!-- Removed for now
<t>
(A) See
<xref target="I-D.hertoghs-nvo3-lisp-controlplane-unified"/>, section 3.4.1.
</t>
<t>
(B) See
<xref target="I-D.hertoghs-nvo3-lisp-controlplane-unified"/>, section
3.3.4; use of LISP for control-plane learning of MAC address
mapping information for L2 VN services (VXLAN/NVGRE) is
considered (in the referenced document) to be sub-optimal.
</t>
-->
<t>
(3.2) Underlying Network Multi-Destination Address(es)
</t>
<t>
The requirements document
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/>
lists 3 approaches that may be used to deliver traffic to
multiple destinations in an overlay virtual network:
<list style="numbers">
<t>
Use the capabilities of the underlay network.
</t>
<t>
Require a sending NVE to replicate traffic.
</t>
<t>
Use a replication service provided within the overlay network.
</t>
</list>
</t>
<t>
For each delivery approach, it may be necessary to map specific
multipoint (e.g. - broadcast, unknown destination or multicast)
traffic to (for instance) addresses used to deliver this traffic
via the underlay network.
</t>
<t>
For each technological approach, which delivery approaches are
supported and does the technology provide a method by which an
NVE needing to send multi-destination traffic can determine to
what address, or addresses to which to send this traffic?
</t>
<texttable anchor="OA3pt2TL2" title="Multi-Destination Delivery (L2)">
<ttcol width="60%" align="left">Supported Approach</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<c>Underlay Network Capability</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>NVE Sender Replication</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Replication Service</c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable anchor="OA3pt2TL3" title="Multi-Destination Delivery (L3)">
<ttcol width="60%" align="left">Supported Approach</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Underlay Network Capability</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>NVE Sender Replication</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Replication Service</c>
<c></c>
<c></c>
</texttable>
<!-- Removed for now
<t>
(A) See
<xref target="I-D.hertoghs-nvo3-lisp-controlplane-unified"/>, section 3.4.2. LISP supports delivering L2 and L3 multi-destination
packets, independent of the underlying network multicast
capabilities.
</t>
-->
<t>
(3.3) VN Connect/Disconnect Notification
</t>
<t>
The requirements document
<xref target="I-D.ietf-nvo3-nve-nva-cp-req"/> states as an
assumption that a mechanism exists in the overlay technology
by which an NVE is notified of Tenant Systems attaching and
detaching from a specific Virtual Network (VN).
</t>
<t>
For each candidate technology, does the technology currently
support these functions?
</t>
<texttable anchor="OA3pt3TL2" title="Connect/Disconnect Notification (L2)">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<c>Connect Notification</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Disconnect Notification</c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable anchor="OA3pt3TL3" title="Connect/Disconnect Notification (L3)">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Connect Notification</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Disconnect Notification</c>
<c></c>
<c></c>
</texttable>
<!-- Removed for now
<t>
(A) See
<xref target="I-D.hertoghs-nvo3-lisp-controlplane-unified"/>, section 3.4.3. The LISP control plane can take advantage of presumed
network attach/detach functions or the discovery of new MAC/IP
addresses to trigger registration/de-registration of Tenant
Systems to the Mapping System.
</t>
-->
<t>
(3.4) VN Name to VNID Mapping
</t>
<t>
The requirements document
<xref target="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.
</t>
<t>
For each technological approach we are considering, is
this function currently available?
</t>
<texttable anchor="OA3pt4TL2" title="VN Name to VN ID Mapping (L2)">
<ttcol width="60%" align="left">Function</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<c>VN-Name:VN-ID Mapping</c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable anchor="OA3pt4TL3" title="VN Name to VN ID Mapping (L3)">
<ttcol width="60%" align="left">Function</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>VN-Name:VN-ID Mapping</c>
<c></c>
<c></c>
</texttable>
<!-- Removed for now
<t>
(A) See
<xref target="I-D.hertoghs-nvo3-lisp-controlplane-unified"/>, section 3.4.4. The LISP Control Plane uses the Instance ID to identify
the NVI. The VN Name to VNI mapping can be performed by the NVE
as a result of local provisioning.
</t>
-->
</section> <!-- nve2nvacpreqs -->
<section anchor="vm2nvecpreqs" title="VM-to-NVE Specific Control-Plane Requirements">
<t>
In this section, numbering of requirement headings
corresponds to section numbering in
<xref target="I-D.kreeger-nvo3-hypervisor-nve-cp"/>.
</t>
<t>
(4.1) VN Connect/Disconnect
</t>
<t>
The requirements document
<xref target="I-D.kreeger-nvo3-hypervisor-nve-cp"/> states as a
requirement that a mechanism must exist by which an NVE is
notified when an end device requires a connection, or no longer
requires a connection, to a specific Virtual Network (VN).
</t>
<t>
The requirements document further states as a requirement that
the mechanism(s) used in a candidate technological approach must
provide a local indicator (e.g. - 802.1Q tag) that the end device
will use in sending traffic to, or receiving traffic from, the
NVE (where that traffic is associated with the connected VN).
</t>
<t>
As an additional related requirement, the requirements document
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
information from the NVA.
</t>
<t>
For each candidate technology, does the technology currently
support these functions?
</t>
<texttable anchor="V2N4pt1TL2" title="VN Connect/Disconnect (L2)">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<c>Connect Notification</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Local VN Indicator</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>VN Name to VN Context Mapping</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Disconnect Notification</c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable anchor="V2N4pt1TL3" title="VN Connect/Disconnect (L3)">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Connect Notification</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Local VN Indicator</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>VN Name to VN Context Mapping</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Disconnect Notification</c>
<c></c>
<c></c>
</texttable>
<t>
(4.2) VNIC Address Association
</t>
<t>
The requirements document
<xref target="I-D.kreeger-nvo3-hypervisor-nve-cp"/> lists two approaches for acquiring VNIC address association information:
<list style="numbers">
<t>
Data Plane Learning (i.e. - by inspecting source addresses in
traffic received from an end device).
</t>
<t>
Explicit signaling from the end device when a specific VNIC
address is to be associated with a tenant system.
</t>
</list>
</t>
<texttable anchor="V2N4pt2TL2" title="VNIC Address Association (L2)">
<ttcol width="60%" align="left">Supported Approaches</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<c>Data Plane Learning</c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Explicit Signaling</c>
<c></c>
<c></c>
<c></c>
</texttable>
<texttable anchor="V2N4pt2TL3" title="VNIC Address Association (L3)">
<ttcol width="60%" align="left">Supported Approaches</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Data Plane Learning</c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>Explicit Signaling</c>
<c></c>
<c></c>
</texttable>
<t>
(4.3) VNIC Address Disassociation
</t>
<t>
TBD
</t>
<!--
<texttable anchor="V2N4pt3T" title="VNIC Address Disassociation">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Row 1 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 2 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 3 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
-->
<t>
(4.4) VNIC Shutdown/Startup/Migration
</t>
<t>
TBD
</t>
<!--
<texttable anchor="V2N4pt4T" title="Table Header">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Row 1 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 2 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 3 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
-->
<t>
(4.5) VN Profile
</t>
<t>
TBD
</t>
<!--
<texttable anchor="V2N4pt5T" title="Table Header">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Row 1 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 2 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>Row 3 Content Label</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
-->
</section> <!-- vm2nvecpreqs -->
</section> <!-- ctlReq -->
<section anchor="dataReq" title="Data Plane Requirements">
<t>
In this section, numbering of requirement headings
corresponds to section numbering in
<xref target="I-D.ietf-nvo3-dataplane-requirements"/>.
</t>
<t>(3.1) Virtual Access Points (VAPs)</t>
<texttable anchor="VAPid" title="VAP Identification Requirements">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>MUST support VAP identification</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>1) Local interface</c>
<c>YES</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>2) Local interface + fields in frame header</c>
<c>YES</c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.2) Virtual Network Instance (VNI)</t>
<t>
Network virtualization can be provided by L2 and/or L3 VNIs.
</t>
<t>(3.2.1) L2 VNI</t>
<texttable anchor="L2VNIreq" title="L2 VNI Service">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>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).</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>Loop avoidance capability MUST be provided.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>Data plane learning MUST be supported as the default means to
populate forwarding tables.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>When flooding is required for delivery of broadcast, unknown
unicast or multicast (BUM) traffic, the NVE MUST either support
ingress replication or multicast.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>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.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.2.2) L3 VNI</t>
<texttable anchor="L3VNIreq" title="L3 VNI Service">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>L3 VNIs MUST provide virtualized IP routing and forwarding.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>L3 VNIs MUST support per-tenant forwarding instance with IP addressing
isolation and L3 tunneling for interconnecting instances of the same VNI
on NVEs.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>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).</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>TTL in the outer IP header MUST be set to a value appropriate
for delivery of the encapsulated packet to the tunnel exit
point.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>The default behavior for TTL MUST use the "pipe" model.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.3.1) NVO3 overlay header</t>
<texttable anchor="OvHdrreq" title="Overlay Header">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>An NVO3 overlay header MUST be included after the underlay
tunnel header when forwarding tenant traffic.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
</texttable>
<t>(3.3.1.1) Virtual Network Context Identification</t>
<texttable anchor="VNICtxidreq" title="Virtual Network Context Identification">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>The overlay encapsulation header MUST contain a field which
allows the encapsulated frame to be delivered to the appropriate
virtual network endpoint by the egress NVE. .</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>If Global Identifiers are used, the identifier field MUST be
large enough to scale to hundreds of thousands of VNs.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.3.2.1) LAG and ECMP</t>
<texttable anchor="LAGreq" title="Multipath Support">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>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.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>All packets belonging to any specific flow MUST follow the same
path in order to prevent packet re-ordering.</c>
<c>NO</c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.3.2.2) DiffServ and ECN marking</t>
<texttable anchor="Markreq" title="DSCP and ECN Marking">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c><xref target="RFC2983"/> defines two modes for mapping the DSCP
markings from inner to outer headers and vice versa. Both models
SHOULD be supported.</c>
<c>NO</c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.3.2.3) Handling of broadcast, unknown unicast, and multicast
traffic</t>
<t>
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.
</t>
<texttable anchor="BUMreq" title="Handling of Broadcast, Unknown Unicast, and Multicast Traffic">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>
User-configurable knobs MUST be provided to select which method(s)
are used based upon the amount of replication required.
</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>When ingress replication is used, NVEs MUST track maintain (for
each VNI) the related tunnel endpoints to which it needs to
replicate the frame.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.4) External NVO3 connectivity</t>
<texttable anchor="Interopreq" title="Interoperation">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="10%" align="center">L3VPN</ttcol>
<c>
NVO3 services MUST 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.
</c>
<c>YES</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>Redundancy between NVO3 and external domains MUST be
supported.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.4.2.1) Load-balancing</t>
<t>
When using active-active load-balancing across physically
separate NVE GW's (e.g.: two, separate chassis) an NVO3
solution SHOULD support forwarding tables that can
simultaneously map a single egress NVE to more than one NVO3
tunnels.
</t>
<texttable anchor="externalLB" title="Gateway Load-balancing">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="10%" align="center">L3VPN</ttcol>
<c>The granularity of such mappings, in both active-backup and
active-active, MUST be specific to each tenant.</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.5) Path MTU</t>
<texttable anchor="MTUreq" title="Path MTU">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Classical ICMP-based MTU Path Discovery
(<xref target="RFC1191"/>, <xref target="RFC1981"/>)
or Extended MTU Path Discovery techniques such as
defined in <xref target="RFC4821"/>.</c>
<c>NO</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>- - -</c>
<c>- - -</c>
<c>- - -</c>
<c>- -</c>
<c>- -</c>
<c>- - -</c>
<c>Fragmentation and reassembly support from the overlay layer
operations without relying on the Tenant Systems to know about the
end-to-end MTU. </c>
<c>YES</c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
<t>(3.7) NVE Multi-Homing Requirements</t>
<texttable anchor="MulHomereq" title="Multihoming">
<ttcol width="60%" align="left">Requirement</ttcol>
<ttcol width="8%" align="center">NVGRE</ttcol>
<ttcol width="8%" align="center">VxLAN</ttcol>
<ttcol width="8%" align="center">VPLS</ttcol>
<ttcol width="8%" align="center">EVPN</ttcol>
<ttcol width="8%" align="center">L3VPN</ttcol>
<c>Multi-homing techniques SHOULD be used to increase the reliability
of an NVO3 network.</c>
<c>NO</c>
<c></c>
<c></c>
<c></c>
<c></c>
</texttable>
</section> <!-- dataReq -->
<section anchor="summary" title="Summary and Conclusions">
<t>TBD</t>
</section> <!-- summary -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The Authors would like to acknowledge the technical contributions of Florin Balus, Luyuan Fang, Sue Hares, Wim Henderickx, Yves Hertoghs, Yuichi Ikejiri, Rangaraju Iyengar, Mircea Pisica, Evelyn Roch, Ali Sajassi, Peter Ashwood-Smith and Lucy Yong as well as the initial help in editing the XML source for the document from Tom Taylor.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Security considerations of the requirements documents
referenced by this analysis document apply.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&I-D.ietf-nvo3-overlay-problem-statement;
&I-D.ietf-nvo3-framework;
&I-D.ietf-nvo3-dataplane-requirements;
&I-D.ietf-nvo3-nve-nva-cp-req;
&I-D.kreeger-nvo3-hypervisor-nve-cp;
&I-D.ashwood-nvo3-operational-requirement;
&I-D.mahalingam-dutt-dcops-vxlan;
&I-D.sridharan-virtualization-nvgre;
&I-D.hertoghs-nvo3-lisp-controlplane-unified;
&I-D.ietf-l2vpn-evpn;
&RFC1191;
&RFC1981;
&RFC2119;
&RFC2983;
&RFC4365;
&RFC4761;
&RFC4762;
&RFC4821;
&RFC6040;
<!--
&RFC6074;
-->
</references>
<references title="Informative References">
&RFC3168;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:27:27 |