Internet DRAFT - draft-pt-nvo3-vdp-vm2nve-gap-analysis
draft-pt-nvo3-vdp-vm2nve-gap-analysis
Internet Engineering Task Force J. Pelissier, Ed.
Internet Draft Cisco
Intended status: Informational
Expires: December 18, 2014 P. Thaler
Broadcom
P. Bottorff
HP
June 18, 2014
NVO3 VDP Gap Analysis - VM-to-NVE Specific Control-Plane
Requirements
draft-pt-nvo3-vdp-vm2nve-gap-analysis-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Pelissier, et al. Expires December 18, 2015 [Page 1]
Internet-Draft NVO3 VDP Gap Analysis June 2014
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
[I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for
Hypervisor-to-NVE Control Plane Protocol Functionality. The IEEE
has developed a protocol called VSI Discovery Protocol (VDP)
specified in [IEEE8021Qbg]. This protocol is intended to address the
same basic problems at layer two as the Hypervisor-to-NVE protocol
needs to address at layer three. Simply by adding the ability to
carry layer three addresses to VDP using the extensibility features
built into the protocol, VDP may be used as the Hypervisor-to-NVE
Control Plane protocol.
Table of Contents
1. Introduction...................................................3
2. Terminology and Conventions....................................3
2.1. Requirements Language.....................................3
2.2. Conventions...............................................3
2.3. Terms and Abbreviations...................................3
3. VDP Operational Summary........................................4
3.1. Introduction..............................................4
3.2. Data Formats..............................................4
3.2.1. VSI Manager ID TLV...................................5
3.2.2. VDP Association TLV..................................5
3.2.3. Organizationally Defined TLV........................10
3.3. VDP Operations...........................................11
3.3.1. Pre-Associate.......................................11
3.3.2. Pre-Associate with Resource Reservation.............12
3.3.3. Associate...........................................12
3.3.4. De-Associate........................................13
3.4. VDP Extensibility........................................13
4. Gap Analysis..................................................14
4.1. VDP Addressing support...................................16
4.2. VDP Support of VLAN Identification.......................16
4.3. VDP Support of VN Identification.........................17
4.4. Removal of all Addresses Associated with a VNIC..........17
5. Summary and Conclusions.......................................17
6. Security Considerations.......................................17
Pelissier, et al. Expires December 18, 2014 [Page 2]
Internet-Draft NVO3 VDP Gap Analysis June 2014
7. References....................................................17
7.1. Normative References.....................................17
8. Acknowledgments...............................................18
Authors' Addresses...............................................19
1. Introduction
[I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for
Hypervisor-to-NVE Control Plane Protocol Functionality. The IEEE
has developed a protocol called VSI Discovery Protocol (VDP)
specified in [IEEE8021Qbg]. This protocol is intended to address the
same basic problems at layer two as the Hypervisor-to-NVE protocol
needs to address at layer three. Simply by adding the ability to
carry layer three addresses to VDP using the extensibility features
built into the protocol, VDP may be used as the Hypervisor-to-NVE
Control Plane protocol.
This document provides a summary of the data formats and operation
of VDP. It then provides an analysis of the requirements of the
Hypervisor-to-NVE protocol and summarizes VDP's ability to meet
these requirements.
2. Terminology and Conventions
2.1. Requirements Language
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 RFC-2119 [RFC2119].
2.2. Conventions
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.
In order to avoid confusing those section numbers with the section
numbering in this document, the included numbering is parenthesized.
2.3. Terms and Abbreviations
This document uses terms and acronyms defined in [IEEE8021Qbg] and
[I-D.kreeger-nvo3-hypervisor-nve-cp-01]:
ECP: Edge Control Protocol [IEEE8021Qbg]
Pelissier, et al. Expires December 18, 2014 [Page 3]
Internet-Draft NVO3 VDP Gap Analysis June 2014
VDP: Virtual Station Interface (VSI) Discovery and Configuration
Protocol [IEEE8021Qbg]
VNIC: Virtual Network Interface Card [I-D.kreeger-nvo3-hypervisor-
nve-cp-01]
VSI: Virtual Station Interface [IEEE8021Qbg]
This document uses the following additional general terms and
abbreviations:
PDU: protocol data unit
TLV: type, length, value
3. VDP Operational Summary
3.1. Introduction
VDP associates a Virtual Station Interface (VSI) with its virtually
or physically attached bridge port. While the standard assumes the
use of a virtual station, the protocol is actually agnostic as to
whether the station is virtually or physically instantiated.
The term VSI as used in [IEEE8021Qbg] is equivalent to the term VNIC
used in [I-D.kreeger-nvo3-hypervisor-nve-cp-01].
In addition, VDP automates station configuration during the movement
of a VSI from one station to another or from one bridge to another.
3.2. Data Formats
This section provides a descriptive overview of the data formats and
the definition of the fields within these formats. For the detailed
specification, see [IEEE8021Qbg].
The VDP data formats are defined in terms of type, length, value
tuples (TLVs). There are three TLVs defined for VDP:
o VSI Manager ID
o VDP Association
o VDP Organizationally Defined
Pelissier, et al. Expires December 18, 2014 [Page 4]
Internet-Draft NVO3 VDP Gap Analysis June 2014
These TLVs are carried in a PDU using ECP. It should be noted that
ECP is independent of VDP and that VDP may be transported utilizing
any protocol capable of reliably transporting a PDU.
Each PDU contains exactly one VSI Manager ID TLV that is the first
TLV in the PDU. The VSI Manager ID TLV is followed by one or more
VDP Association TLVs and zero or more VDP Organizationally Defined
TLVs. The TLVs following the VSI Manager ID TLV occur in any order.
3.2.1. VSI Manager ID TLV
The VSI Manager ID TLV provides a way for a hypervisor to indicate
the address of a manager that contains network configuration
information for the VSIs in the PDU.
The following illustrates the format of the VSI Manager ID TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| VSI Mgr ID |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field descriptions:
TLV Type: Set to 5.
Length: Contains 16, the length of the information field in octets.
VSI Mgr ID: 16 octet field identifying the IPv6 [RFC4291] address of
the manager from which to obtain the VSI type. A value of 0
indicates that the device does not know this address.
3.2.2. VDP Association TLV
The VDP Association TLV identifies a VSI and the Filter Info for
packets from that VSI. Filter Info is information from which a
filter for packets from that VSI can be constructed.
Pelissier, et al. Expires December 18, 2014 [Page 5]
Internet-Draft NVO3 VDP Gap Analysis June 2014
The following illustrates the format of the VDP association TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length | Status | VSI Type ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSI Type ID (continued) | VSI Type Ver | VSIID Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ VSIID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | |
+-+-+-+-+-+-+-+-+ |
| Filter Info |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field definitions:
TLV Type: Set to one of the following values based on the type of
TLV:
+-------+-----------------------------------------+
| Value | TLV Type |
+-------+-----------------------------------------+
| 1 | Pre-Associate |
| 2 | Pre-Associate with resource reservation |
| 3 | Associate |
| 4 | De-associate |
+-------+-----------------------------------------+
Length: Contains the length of the TLV information string which is
23 plus the number of octets in the Filter Info field.
Status: The status field contains four flags encoded one each in
bits 16-19 and an error type encoded bits 20-23:
Bit 16: Reserved for future standardization.
Pelissier, et al. Expires December 18, 2014 [Page 6]
Internet-Draft NVO3 VDP Gap Analysis June 2014
Bit 17: Req/Ack - set to zero to indicate that the TLV contains a
request.
Bit 18: S-bit - indicates that the VSI user is suspended (S-bit =
1) or no information (S-bit = 0).
Bit 19: M-bit - indicates that the VSI user is migrating (M-bit =
1) or no information (M-bit = 0).
Bits 20-23:
+------------+--------------------------------------+
| Value | Error Type |
+------------+--------------------------------------+
| 0 | Success |
| 1 | Invalid Format |
| 2 | Insufficient Resources |
| 3 | Unable to contact VSI manager |
| 4 | Other failure |
| 5 | Invalid VID, GroupID, or MAC address |
| all others | Reserved for future standardization |
+------------+--------------------------------------+
VSI Type ID: An integer used to identify the type of the VSI. The
type of VSI is used by the VSI manager to obtain the configuration
for a VSI and its scope is limited to an individual VSI manager.
VSI Type Ver: The version of a VSI type. This allows a VSI database
to maintain multiple versions of a VSI type.
VSIID format: Indicates the format of the VSIID field. The allowed
values are:
Pelissier, et al. Expires December 18, 2014 [Page 7]
Internet-Draft NVO3 VDP Gap Analysis June 2014
+------------+---------------------------------------------------+
| Value | Description |
+------------+---------------------------------------------------+
| 1 | An IPv4 address encoded as specified in [RFC4291] |
| | |
| 2 | An IPv6 address encoded as specified in [RFC4291] |
| | |
| 3 | An IEEE 802 MAC address (6 octets) with |
| | 10 leading octets of all zeros |
| | |
| 4 | The format is locally defined |
| | |
| 5 | A UUID as specified in [RFC4122] |
| | |
| All others | Reserved for future standardization |
+------------+---------------------------------------------------+
VSIID: An identifier of the VSI instance in the format specified by
VSIID format.
Format: Indicates the format of the Filter Info field. The allowed
values are:
+------------+-------------------------------------+
| Value | Description |
+------------+-------------------------------------+
| 1 | VID |
| 2 | MAC/VID |
| 3 | GroupID/VID |
| 4 | GroupID/MAC/VID |
| All others | Reserved for future standardization |
+------------+-------------------------------------+
Filter Info: The contents of this field vary depending on the value
of the Format field.
If the Format field indicates the VID format, the format of the
Filter Info field is as follows:
Pelissier, et al. Expires December 18, 2014 [Page 8]
Internet-Draft NVO3 VDP Gap Analysis June 2014
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| PCP | VID | <-- Repeated per entry
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the Format field indicates the MAC/VID format, then the format of
the Filter Info field is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| | \
+ + |
| MAC Address | |
+ + + <-- Repeated per entry
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|P| PCP | VID | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
If the Format field indicates the GroupID/VID format, then the
format of the Filter Info field is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| | \
+ GroupID + |
| | + <-- Repeated per entry
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|P| PCP | VID | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
If the Format field indicates the GroupID/MAC/VID format, then the
format of the Filter Info field is:
Pelissier, et al. Expires December 18, 2014 [Page 9]
Internet-Draft NVO3 VDP Gap Analysis June 2014
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| | \
+ GroupID + |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ + + <-- Repeated per entry
| MAC Address | |
+ + |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|P| PCP | VID | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
The following field definitions apply to all formats of the Filter
Info field in which the defined field appears:
Number of Entries: Contains the number of filter entries in the
Filter Info field.
GroupID: Enables the specification of a VLAN when the total number
of VLANs exceeds 4095. For Filter Info formats with a GroupID,
the hypervisor can send the Null VID. The Bridge then supplies a
local VID that it maps to the GroupID. See [IEEE8021Qbg] for
details.
MAC Address: An IEEE 802 MAC address.
P: Set to one to indicate that the PCP field is significant, 0
otherwise.
PCP: Priority code point. If P is set to zero, this field is
ignored and the Filter Info entry applies to all Priority code
points.
VID: VLAN Identifier.
3.2.3. Organizationally Defined TLV
The following illustrates the format of the VDP association TLV:
Pelissier, et al. Expires December 18, 2014 [Page 10]
Internet-Draft NVO3 VDP Gap Analysis June 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI(cont.) | |
+-+-+-+-+-+-+-+ Organizationally Defined Information |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field descriptions:
TLV Type: Set to 0x7f.
Length: Contains the length of the TLV information string in octets
which is 3 (the length of the OUI) plus the length of the
Organizationally Defined Information.
OUI: An organizationally unique identifier assigned by the IEEE
registration authority that identifies the organization that defined
the content of the Organizationally Defined Information field.
Organizationally Defined Information: Information that is defined by
the organization identified by the OUI field.
3.3. VDP Operations
VDP provides for four fundamental operations:
1. Pre-Associate
2. Pre-Associate with Resource Reservation
3. Associate
4. De-Associate
These operations are described in detail with their associated state
machines in [IEEE8021Qbg]. The following sub-paragraphs provide a
general description of each of these operations. Each operation may
be initiated by a hypervisor or other entity within a station and
responded to by the bridge. In addition, the bridge may initiate
the De-Associate operation.
3.3.1. Pre-Associate
The Pre-Associate operation informs the bridge that the station may
initiate an Associate operation with the same parameters in the
Pelissier, et al. Expires December 18, 2014 [Page 11]
Internet-Draft NVO3 VDP Gap Analysis June 2014
future. This allows the bridge to validate the operation and inform
the station whether or not an identical Associate operation would
have succeeded. However, this provides no guarantee that the same or
similar Associate operation will succeed in the future.
Additionally, this operation allows the bridge to prepare for a
future Associate operation, e.g. caching configuration information
from a management server, thereby potentially decreasing the time
required to process the future Associate operation.
It is not necessary to perform a Pre-Associate operation prior to an
Associate operation.
3.3.2. Pre-Associate with Resource Reservation
The Pre-Associate with Resource Reservation operation is identical
to the Pre-Associate operation with the additional step of the
bridge reserving its necessary resources in order to increase the
probability that a future identical Associate operation will
succeed. Additionally, the reservation of resources may further
decrease the time required to process a future Associate operation.
It is not necessary to perform a Pre-Associate with Resource
Reservation prior to performing an Associate operation.
3.3.3. Associate
The Associate operation creates and activates an associate between
the VSI and the bridge port to which it is connected. The bridge
allocates the necessary resources to create this association and
applies any necessary configuration associated with the VSI Type ID.
[IEEE8021Qbg] does not specify the mechanism by which the bridge
determines the resources and configuration required by a VSI Type
ID. VSI Type ID simply acts as a handle to identify the
configuration information to be retrieved from a repository that is
outside the scope of [IEEE8021Qbg].
A station may issue an Associate without having previously issued a
Pre-Associate or Pre-Associate with Resource Reservation.
During normal operations a VSI is associated with one bridge port.
During network transitions (e.g., virtual station migration) a VSI
might be associated with more than one port.
The bridge uses only the information in the Associate operation to
establish the association. Any resource reservation that may have
Pelissier, et al. Expires December 18, 2014 [Page 12]
Internet-Draft NVO3 VDP Gap Analysis June 2014
been created based on a previous Pre-Associate or Pre-Associate with
Resource Reservation that is not required for the Associate
operation is released.
3.3.4. De-Associate
The De-Associate operation removes an association between a VSI and
a bridge port. The bridge may de-allocate any resources that were
reserved as part of the association.
In addition, a De-Associate operation may be issued to inform a
bridge that resources may be de-allocated that were reserved as a
result of a previous Pre-Associate or Pre-Associate with Resource
Reservation.
A bridge may initiate a De-Associate operation. This could be
necessary, for example, in the case of a change in the bridge's
configuration or operational status.
3.4. VDP Extensibility
3.4.1. Transport of VDP
ECP is defined in IEEE 802.1Qbg to transport VDP TLVs. It is a
simple protocol operating over layer 2. It allows for one PDU to be
outstanding at a time. Acknowledgement of an ECP PDU indicates that
the PDU contents were received. Processing and responses to TLVs in
the PDU can take place after the acknowledgement.
Currently, IEEE 802.1Qbg specifies that the Nearest Customer Bridge
group MAC address is used as the destination in ECP PDUs carrying
VDP.
NVO3 is likely to want to use a different destination address as the
NVE is not necessarily the nearest customer bridge. There have been
other protocols that initially required a certain destination
address and the requirement was modified when new uses required new
addresses. For instance ECP could be used with individual
destination addresses instead of a group address.
Alternatively, a different reliable transport could be identified
for carrying VDP TLVs for NVO3.
3.4.2 Enhancing the VDP Association TLV
The VDP Association TLV Filter Info is currently specified using
layer 2 addressing (MAC address, VLAN, etc.). It is likely that the
Pelissier, et al. Expires December 18, 2014 [Page 13]
Internet-Draft NVO3 VDP Gap Analysis June 2014
IETF would need to extend this to include IPv4 and IPv6 addressing
mechanisms and tenant IDs. There are at least two straight forward
ways to do this.
The method preferred by the authors would be to request the IEEE to
add additional Filter Info formats to cover the needed extensions.
There are currently 252 Format identifiers that are reserved for
future standardization. With this method there are two alternatives.
An IEEE 802.1 project could be initiated to add the additional
Filter Info formats to IEEE 802.1Q. Alternatively, IETF could ask
IEEE 802.1 to assign some of the Filter Info format identifiers to
IETF for definition in an RFC.
Alternatively, the IETF could autonomously define the desired
extensions using the Organizationally Defined TLV. The contents of
the Organizationally Defined Information Field could be defined by
the IETF to be identical to that of the VDP association TLV with the
addition of IETF defined Filter Info formats.
3.4.2. Enhancing Migration Support
The VDP TLV contains two status bits to help in migrating state when
a VSI is migrating. The M-bit indicates that the VSI is migrating as
opposed to a new VSI or one not known to be migrating. The S-bit
indicates when the VSI is known to have been suspended for
migration. NVO3 could provide guidance on using these bits.
4. Gap Analysis
[I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for
Hypervisor-to-NVE Control Plane Protocol Functionality. This
section summarizes the requirements and describes VDP's ability (or
lack thereof) to meet the requirements.
The requirements from [I-D.kreeger-nvo3-hypervisor-nve-cp-01] are
summarized in the table below. The column labeled "VDP Support &
Additional Discussion" indicates whether VDP supports the
requirement. The notation "SBF" in this column indicates that the
VDP framework supports the operation; however, and additional Filter
Info format or other minor extension is required for a complete
implementation. A section number in this column indicates a section
in this document that provides additional discussion of the
particular requirement and how VDP achieves it.
Pelissier, et al. Expires December 18, 2014 [Page 14]
Internet-Draft NVO3 VDP Gap Analysis June 2014
+-------------+---------------------------------------+------------+
| Paragraph | | |
| in I-D. | | VDP |
| kreeger- | | Support |
| nvo3- | | & |
| hypervisor- | | Additional |
| nve-cp-01] | Requirement | Discussion |
+-------------+----------------------------+----------+------------+
| (4.) | "...identifies the Tenant System (TS) | SBF |
| |VNIC addresses and VN Name (or ID)..." | 4.1. |
| | | |
| (4.) | "...identify a locally significant | Yes |
| | tag (e.g., an 802.1Q VLAN tag) that | 4.2. |
| | can be used to identify the data | |
| | frames that flow between the TS VNIC | |
| | and the VN." | |
| | | |
| (4.1.) | "The NVE must be notified when an End | Yes |
| | Device requires connection to a | |
| | particular VN and when it no longer | |
| | requires connection." | |
| | | |
| (4.1.) | "...the external NVE must provide a | Yes |
| | local tag value for each connected VN | 4.2. |
| | to the End Device to use for exchange | |
| | of packets between the End Device and | |
| | the NVE (e.g. a locally significant | |
| | 802.1Q tag value)." | |
| | | |
| (4.1.) | "The Identification of the VN in this | Yes |
| | protocol could either be through a VN | 4.3. |
| | Name or a VN ID." | |
| | | |
| (4.2.) | "...the "hypervisor-to-NVE" protocol | Yes |
| | requires a means to allow End Devices | |
| | to communicate new tenant addresses | |
| | associations for a given VNIC within | |
| | a VN." | |
| | | |
| (4.3.) | "When a VNIC within an End Device | Yes |
| | terminates function..., all addresses | |
| | associated with that VNIC must be | |
| | disassociated with the End Device on | |
| | the connected NVE." | |
| | | |
| (4.3.) | "If the VNIC only has a single address| Yes |
| | associated with it, then this can be | |
Pelissier, et al. Expires December 18, 2014 [Page 15]
Internet-Draft NVO3 VDP Gap Analysis June 2014
| | a single address disassociate message | |
| | to the NVE." | |
| | | |
| (4.3.) | "...if the VNIC had hundreds of | SBF |
| | addresses associated with it, then | 4.4. |
| | the protocol with the NVE would be | |
| | better optimized to simply | |
| | disassociate the VNIC with the NVE, | |
| | and the NVE can automatically | |
| | disassociate all addresses that were | |
| | associated with the VNIC." | |
| | | |
| (4.4.) | "...the NVE can make optimizations if | Yes |
| | it knows which addresses are | |
| | associated with which VNICs within an | |
| | End Device and also is notified of | |
| | state changes of that VNIC, | |
| | specifically the difference between | |
| | VNIC shutdown/startup and VNIC | |
| | migration arrival/departure. | |
| | | |
+-------------+---------------------------------------+------------+
4.1. VDP Addressing support
VDP as currently defined is fundamentally layer two. It supports
addresses composed of an IEEE 802 style MAC address optionally
combined with a VLAN identifier. These addresses are carried in the
Filter Info field of the VDP Association TLV, see 3.2.2. The
framework of VDP allows for the communication of various formats of
the Filter Info field and additional formats may be added that
support layer three addresses such as IPv4 and IPv6 addresses, see
3.3. Alternatively, using the organizationally defined TLV
mechanism, an IETF defined TLV may be used.
4.2. VDP Support of VLAN Identification
VDP supports two mechanisms for expressing a locally significant
tag. One is to express a 802.1Q VLAN ID explicitly. The other is
to use a GroupID which has local significance and can be mapped to
an actual VLAN by the network controlling entities (see
[IEEE8021Qbg] for details
Pelissier, et al. Expires December 18, 2014 [Page 16]
Internet-Draft NVO3 VDP Gap Analysis June 2014
4.3. VDP Support of VN Identification
The GroupID is a 32-bit value that may be used for VN
identification. Additional Filter Info formats may be defined to
support a GUID or other forms of a name. Alternatively, using the
organizationally defined TLV mechanism, an IETF defined TLV may be
used.
4.4. Removal of all Addresses Associated with a VNIC
VDP currently does not support the mass removal of all addresses
associated with a VNIC. Instead, these must be removed
individually. However, such a capability may be defined by creating
a Format code that indicates no Filter Info entry is present in the
VDP Association TLV. On a de-associate operation, this would
indicate the need to remove all addresses.
5. Summary and Conclusions
VDP meets most of the requirements to support the VM-to-NVE control
plane protocol. With the addition of a few Filter Info formats, all
of the requirements may be met within the framework of VDP.
6. Security Considerations
TBD
7. References
7.1. Normative References
[IEEE8021Qbg] IEEE Std 802.1Qbg(TM)-2012, IEEE Standard for Local
and metropolitan area networks-Media Access Control (MAC)
Bridges and Virtual Bridged Local Area Networks-Amendment
21: Edge Virtual Bridging.
[I-D.kreeger-nvo3-hypervisor-nve-cp-01] Kreeger, L., Narten, T., and
D. Black, "Network Virtualization Hypervisor-to-NVE
Overlay Control Protocol Requirements", draft-kreeger-
nvo3-hypervisor-nve-cp-01, August, 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Pelissier, et al. Expires December 18, 2014 [Page 17]
Internet-Draft NVO3 VDP Gap Analysis June 2014
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Pelissier, et al. Expires December 18, 2014 [Page 18]
Internet-Draft NVO3 VDP Gap Analysis June 2014
Authors' Addresses
Joseph Pelissier
Cisco
170 Tasman Drive
San Jose, CA 95134
USA
Email: jopeliss@cisco.com
Patricia Thaler
Broadcom Corporation
5300 California Ave
Irvine, California 92617
USA
Email: pthaler@broadcom.com
Paul Bottorff
8000 Foothills Blvd., M/S 1421
Roseville, CA 95747
Email: paul.bottorff@hp.com
Pelissier, et al. Expires December 18, 2014 [Page 19]
