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]