idnits 2.17.1 draft-pt-nvo3-vdp-vm2nve-gap-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.kreeger-nvo3-hypervisor-nve-cp-01], [IEEE8021Qbg]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 18, 2014) is 3600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Pelissier, Ed. 2 Internet Draft Cisco 3 Intended status: Informational 4 Expires: December 18, 2014 P. Thaler 5 Broadcom 7 P. Bottorff 8 HP 10 June 18, 2014 12 NVO3 VDP Gap Analysis - VM-to-NVE Specific Control-Plane 13 Requirements 14 draft-pt-nvo3-vdp-vm2nve-gap-analysis-00.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on December 18, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 [I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for 57 Hypervisor-to-NVE Control Plane Protocol Functionality. The IEEE 58 has developed a protocol called VSI Discovery Protocol (VDP) 59 specified in [IEEE8021Qbg]. This protocol is intended to address the 60 same basic problems at layer two as the Hypervisor-to-NVE protocol 61 needs to address at layer three. Simply by adding the ability to 62 carry layer three addresses to VDP using the extensibility features 63 built into the protocol, VDP may be used as the Hypervisor-to-NVE 64 Control Plane protocol. 66 Table of Contents 68 1. Introduction...................................................3 69 2. Terminology and Conventions....................................3 70 2.1. Requirements Language.....................................3 71 2.2. Conventions...............................................3 72 2.3. Terms and Abbreviations...................................3 73 3. VDP Operational Summary........................................4 74 3.1. Introduction..............................................4 75 3.2. Data Formats..............................................4 76 3.2.1. VSI Manager ID TLV...................................5 77 3.2.2. VDP Association TLV..................................5 78 3.2.3. Organizationally Defined TLV........................10 79 3.3. VDP Operations...........................................11 80 3.3.1. Pre-Associate.......................................11 81 3.3.2. Pre-Associate with Resource Reservation.............12 82 3.3.3. Associate...........................................12 83 3.3.4. De-Associate........................................13 84 3.4. VDP Extensibility........................................13 85 4. Gap Analysis..................................................14 86 4.1. VDP Addressing support...................................16 87 4.2. VDP Support of VLAN Identification.......................16 88 4.3. VDP Support of VN Identification.........................17 89 4.4. Removal of all Addresses Associated with a VNIC..........17 90 5. Summary and Conclusions.......................................17 91 6. Security Considerations.......................................17 92 7. References....................................................17 93 7.1. Normative References.....................................17 94 8. Acknowledgments...............................................18 95 Authors' Addresses...............................................19 97 1. Introduction 99 [I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for 100 Hypervisor-to-NVE Control Plane Protocol Functionality. The IEEE 101 has developed a protocol called VSI Discovery Protocol (VDP) 102 specified in [IEEE8021Qbg]. This protocol is intended to address the 103 same basic problems at layer two as the Hypervisor-to-NVE protocol 104 needs to address at layer three. Simply by adding the ability to 105 carry layer three addresses to VDP using the extensibility features 106 built into the protocol, VDP may be used as the Hypervisor-to-NVE 107 Control Plane protocol. 109 This document provides a summary of the data formats and operation 110 of VDP. It then provides an analysis of the requirements of the 111 Hypervisor-to-NVE protocol and summarizes VDP's ability to meet 112 these requirements. 114 2. Terminology and Conventions 116 2.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC-2119 [RFC2119]. 122 2.2. Conventions 124 In sections providing analysis of requirements defined in referenced 125 documents, section numbers from each referenced document are used as 126 they were listed in that document. 128 In order to avoid confusing those section numbers with the section 129 numbering in this document, the included numbering is parenthesized. 131 2.3. Terms and Abbreviations 133 This document uses terms and acronyms defined in [IEEE8021Qbg] and 134 [I-D.kreeger-nvo3-hypervisor-nve-cp-01]: 136 ECP: Edge Control Protocol [IEEE8021Qbg] 137 VDP: Virtual Station Interface (VSI) Discovery and Configuration 138 Protocol [IEEE8021Qbg] 140 VNIC: Virtual Network Interface Card [I-D.kreeger-nvo3-hypervisor- 141 nve-cp-01] 143 VSI: Virtual Station Interface [IEEE8021Qbg] 145 This document uses the following additional general terms and 146 abbreviations: 148 PDU: protocol data unit 150 TLV: type, length, value 152 3. VDP Operational Summary 154 3.1. Introduction 156 VDP associates a Virtual Station Interface (VSI) with its virtually 157 or physically attached bridge port. While the standard assumes the 158 use of a virtual station, the protocol is actually agnostic as to 159 whether the station is virtually or physically instantiated. 161 The term VSI as used in [IEEE8021Qbg] is equivalent to the term VNIC 162 used in [I-D.kreeger-nvo3-hypervisor-nve-cp-01]. 164 In addition, VDP automates station configuration during the movement 165 of a VSI from one station to another or from one bridge to another. 167 3.2. Data Formats 169 This section provides a descriptive overview of the data formats and 170 the definition of the fields within these formats. For the detailed 171 specification, see [IEEE8021Qbg]. 173 The VDP data formats are defined in terms of type, length, value 174 tuples (TLVs). There are three TLVs defined for VDP: 176 o VSI Manager ID 178 o VDP Association 180 o VDP Organizationally Defined 181 These TLVs are carried in a PDU using ECP. It should be noted that 182 ECP is independent of VDP and that VDP may be transported utilizing 183 any protocol capable of reliably transporting a PDU. 185 Each PDU contains exactly one VSI Manager ID TLV that is the first 186 TLV in the PDU. The VSI Manager ID TLV is followed by one or more 187 VDP Association TLVs and zero or more VDP Organizationally Defined 188 TLVs. The TLVs following the VSI Manager ID TLV occur in any order. 190 3.2.1. VSI Manager ID TLV 192 The VSI Manager ID TLV provides a way for a hypervisor to indicate 193 the address of a manager that contains network configuration 194 information for the VSIs in the PDU. 196 The following illustrates the format of the VSI Manager ID TLV: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | TLV Type | Length | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 203 | | 204 + + 205 | VSI Mgr ID | 206 + + 207 | | 208 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Field descriptions: 214 TLV Type: Set to 5. 216 Length: Contains 16, the length of the information field in octets. 218 VSI Mgr ID: 16 octet field identifying the IPv6 [RFC4291] address of 219 the manager from which to obtain the VSI type. A value of 0 220 indicates that the device does not know this address. 222 3.2.2. VDP Association TLV 224 The VDP Association TLV identifies a VSI and the Filter Info for 225 packets from that VSI. Filter Info is information from which a 226 filter for packets from that VSI can be constructed. 228 The following illustrates the format of the VDP association TLV: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | TLV Type | Length | Status | VSI Type ID | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | VSI Type ID (continued) | VSI Type Ver | VSIID Format | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + + 239 | | 240 + VSIID + 241 | | 242 + + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Format | | 246 +-+-+-+-+-+-+-+-+ | 247 | Filter Info | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Field definitions: 253 TLV Type: Set to one of the following values based on the type of 254 TLV: 256 +-------+-----------------------------------------+ 257 | Value | TLV Type | 258 +-------+-----------------------------------------+ 259 | 1 | Pre-Associate | 260 | 2 | Pre-Associate with resource reservation | 261 | 3 | Associate | 262 | 4 | De-associate | 263 +-------+-----------------------------------------+ 265 Length: Contains the length of the TLV information string which is 266 23 plus the number of octets in the Filter Info field. 268 Status: The status field contains four flags encoded one each in 269 bits 16-19 and an error type encoded bits 20-23: 271 Bit 16: Reserved for future standardization. 273 Bit 17: Req/Ack - set to zero to indicate that the TLV contains a 274 request. 276 Bit 18: S-bit - indicates that the VSI user is suspended (S-bit = 277 1) or no information (S-bit = 0). 279 Bit 19: M-bit - indicates that the VSI user is migrating (M-bit = 280 1) or no information (M-bit = 0). 282 Bits 20-23: 284 +------------+--------------------------------------+ 285 | Value | Error Type | 286 +------------+--------------------------------------+ 287 | 0 | Success | 288 | 1 | Invalid Format | 289 | 2 | Insufficient Resources | 290 | 3 | Unable to contact VSI manager | 291 | 4 | Other failure | 292 | 5 | Invalid VID, GroupID, or MAC address | 293 | all others | Reserved for future standardization | 294 +------------+--------------------------------------+ 296 VSI Type ID: An integer used to identify the type of the VSI. The 297 type of VSI is used by the VSI manager to obtain the configuration 298 for a VSI and its scope is limited to an individual VSI manager. 300 VSI Type Ver: The version of a VSI type. This allows a VSI database 301 to maintain multiple versions of a VSI type. 303 VSIID format: Indicates the format of the VSIID field. The allowed 304 values are: 306 +------------+---------------------------------------------------+ 307 | Value | Description | 308 +------------+---------------------------------------------------+ 309 | 1 | An IPv4 address encoded as specified in [RFC4291] | 310 | | | 311 | 2 | An IPv6 address encoded as specified in [RFC4291] | 312 | | | 313 | 3 | An IEEE 802 MAC address (6 octets) with | 314 | | 10 leading octets of all zeros | 315 | | | 316 | 4 | The format is locally defined | 317 | | | 318 | 5 | A UUID as specified in [RFC4122] | 319 | | | 320 | All others | Reserved for future standardization | 321 +------------+---------------------------------------------------+ 323 VSIID: An identifier of the VSI instance in the format specified by 324 VSIID format. 326 Format: Indicates the format of the Filter Info field. The allowed 327 values are: 329 +------------+-------------------------------------+ 330 | Value | Description | 331 +------------+-------------------------------------+ 332 | 1 | VID | 333 | 2 | MAC/VID | 334 | 3 | GroupID/VID | 335 | 4 | GroupID/MAC/VID | 336 | All others | Reserved for future standardization | 337 +------------+-------------------------------------+ 339 Filter Info: The contents of this field vary depending on the value 340 of the Format field. 342 If the Format field indicates the VID format, the format of the 343 Filter Info field is as follows: 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Number of Entries | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |P| PCP | VID | <-- Repeated per entry 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 If the Format field indicates the MAC/VID format, then the format of 352 the Filter Info field is: 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Number of Entries | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 357 | | \ 358 + + | 359 | MAC Address | | 360 + + + <-- Repeated per entry 361 | | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 363 |P| PCP | VID | / 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 366 If the Format field indicates the GroupID/VID format, then the 367 format of the Filter Info field is: 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Number of Entries | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 372 | | \ 373 + GroupID + | 374 | | + <-- Repeated per entry 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 376 |P| PCP | VID | / 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 379 If the Format field indicates the GroupID/MAC/VID format, then the 380 format of the Filter Info field is: 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Number of Entries | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 385 | | \ 386 + GroupID + | 387 | | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 389 | | | 390 + + + <-- Repeated per entry 391 | MAC Address | | 392 + + | 393 | | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 395 |P| PCP | VID | / 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 398 The following field definitions apply to all formats of the Filter 399 Info field in which the defined field appears: 401 Number of Entries: Contains the number of filter entries in the 402 Filter Info field. 404 GroupID: Enables the specification of a VLAN when the total number 405 of VLANs exceeds 4095. For Filter Info formats with a GroupID, 406 the hypervisor can send the Null VID. The Bridge then supplies a 407 local VID that it maps to the GroupID. See [IEEE8021Qbg] for 408 details. 410 MAC Address: An IEEE 802 MAC address. 412 P: Set to one to indicate that the PCP field is significant, 0 413 otherwise. 415 PCP: Priority code point. If P is set to zero, this field is 416 ignored and the Filter Info entry applies to all Priority code 417 points. 419 VID: VLAN Identifier. 421 3.2.3. Organizationally Defined TLV 423 The following illustrates the format of the VDP association TLV: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | TLV Type | Length | OUI | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | OUI(cont.) | | 431 +-+-+-+-+-+-+-+ Organizationally Defined Information | 432 | | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Field descriptions: 438 TLV Type: Set to 0x7f. 440 Length: Contains the length of the TLV information string in octets 441 which is 3 (the length of the OUI) plus the length of the 442 Organizationally Defined Information. 444 OUI: An organizationally unique identifier assigned by the IEEE 445 registration authority that identifies the organization that defined 446 the content of the Organizationally Defined Information field. 448 Organizationally Defined Information: Information that is defined by 449 the organization identified by the OUI field. 451 3.3. VDP Operations 453 VDP provides for four fundamental operations: 455 1. Pre-Associate 456 2. Pre-Associate with Resource Reservation 457 3. Associate 458 4. De-Associate 460 These operations are described in detail with their associated state 461 machines in [IEEE8021Qbg]. The following sub-paragraphs provide a 462 general description of each of these operations. Each operation may 463 be initiated by a hypervisor or other entity within a station and 464 responded to by the bridge. In addition, the bridge may initiate 465 the De-Associate operation. 467 3.3.1. Pre-Associate 469 The Pre-Associate operation informs the bridge that the station may 470 initiate an Associate operation with the same parameters in the 471 future. This allows the bridge to validate the operation and inform 472 the station whether or not an identical Associate operation would 473 have succeeded. However, this provides no guarantee that the same or 474 similar Associate operation will succeed in the future. 476 Additionally, this operation allows the bridge to prepare for a 477 future Associate operation, e.g. caching configuration information 478 from a management server, thereby potentially decreasing the time 479 required to process the future Associate operation. 481 It is not necessary to perform a Pre-Associate operation prior to an 482 Associate operation. 484 3.3.2. Pre-Associate with Resource Reservation 486 The Pre-Associate with Resource Reservation operation is identical 487 to the Pre-Associate operation with the additional step of the 488 bridge reserving its necessary resources in order to increase the 489 probability that a future identical Associate operation will 490 succeed. Additionally, the reservation of resources may further 491 decrease the time required to process a future Associate operation. 493 It is not necessary to perform a Pre-Associate with Resource 494 Reservation prior to performing an Associate operation. 496 3.3.3. Associate 498 The Associate operation creates and activates an associate between 499 the VSI and the bridge port to which it is connected. The bridge 500 allocates the necessary resources to create this association and 501 applies any necessary configuration associated with the VSI Type ID. 503 [IEEE8021Qbg] does not specify the mechanism by which the bridge 504 determines the resources and configuration required by a VSI Type 505 ID. VSI Type ID simply acts as a handle to identify the 506 configuration information to be retrieved from a repository that is 507 outside the scope of [IEEE8021Qbg]. 509 A station may issue an Associate without having previously issued a 510 Pre-Associate or Pre-Associate with Resource Reservation. 512 During normal operations a VSI is associated with one bridge port. 513 During network transitions (e.g., virtual station migration) a VSI 514 might be associated with more than one port. 516 The bridge uses only the information in the Associate operation to 517 establish the association. Any resource reservation that may have 518 been created based on a previous Pre-Associate or Pre-Associate with 519 Resource Reservation that is not required for the Associate 520 operation is released. 522 3.3.4. De-Associate 524 The De-Associate operation removes an association between a VSI and 525 a bridge port. The bridge may de-allocate any resources that were 526 reserved as part of the association. 528 In addition, a De-Associate operation may be issued to inform a 529 bridge that resources may be de-allocated that were reserved as a 530 result of a previous Pre-Associate or Pre-Associate with Resource 531 Reservation. 533 A bridge may initiate a De-Associate operation. This could be 534 necessary, for example, in the case of a change in the bridge's 535 configuration or operational status. 537 3.4. VDP Extensibility 539 3.4.1. Transport of VDP 541 ECP is defined in IEEE 802.1Qbg to transport VDP TLVs. It is a 542 simple protocol operating over layer 2. It allows for one PDU to be 543 outstanding at a time. Acknowledgement of an ECP PDU indicates that 544 the PDU contents were received. Processing and responses to TLVs in 545 the PDU can take place after the acknowledgement. 547 Currently, IEEE 802.1Qbg specifies that the Nearest Customer Bridge 548 group MAC address is used as the destination in ECP PDUs carrying 549 VDP. 551 NVO3 is likely to want to use a different destination address as the 552 NVE is not necessarily the nearest customer bridge. There have been 553 other protocols that initially required a certain destination 554 address and the requirement was modified when new uses required new 555 addresses. For instance ECP could be used with individual 556 destination addresses instead of a group address. 558 Alternatively, a different reliable transport could be identified 559 for carrying VDP TLVs for NVO3. 561 3.4.2 Enhancing the VDP Association TLV 563 The VDP Association TLV Filter Info is currently specified using 564 layer 2 addressing (MAC address, VLAN, etc.). It is likely that the 565 IETF would need to extend this to include IPv4 and IPv6 addressing 566 mechanisms and tenant IDs. There are at least two straight forward 567 ways to do this. 569 The method preferred by the authors would be to request the IEEE to 570 add additional Filter Info formats to cover the needed extensions. 571 There are currently 252 Format identifiers that are reserved for 572 future standardization. With this method there are two alternatives. 573 An IEEE 802.1 project could be initiated to add the additional 574 Filter Info formats to IEEE 802.1Q. Alternatively, IETF could ask 575 IEEE 802.1 to assign some of the Filter Info format identifiers to 576 IETF for definition in an RFC. 578 Alternatively, the IETF could autonomously define the desired 579 extensions using the Organizationally Defined TLV. The contents of 580 the Organizationally Defined Information Field could be defined by 581 the IETF to be identical to that of the VDP association TLV with the 582 addition of IETF defined Filter Info formats. 584 3.4.2. Enhancing Migration Support 586 The VDP TLV contains two status bits to help in migrating state when 587 a VSI is migrating. The M-bit indicates that the VSI is migrating as 588 opposed to a new VSI or one not known to be migrating. The S-bit 589 indicates when the VSI is known to have been suspended for 590 migration. NVO3 could provide guidance on using these bits. 592 4. Gap Analysis 594 [I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for 595 Hypervisor-to-NVE Control Plane Protocol Functionality. This 596 section summarizes the requirements and describes VDP's ability (or 597 lack thereof) to meet the requirements. 599 The requirements from [I-D.kreeger-nvo3-hypervisor-nve-cp-01] are 600 summarized in the table below. The column labeled "VDP Support & 601 Additional Discussion" indicates whether VDP supports the 602 requirement. The notation "SBF" in this column indicates that the 603 VDP framework supports the operation; however, and additional Filter 604 Info format or other minor extension is required for a complete 605 implementation. A section number in this column indicates a section 606 in this document that provides additional discussion of the 607 particular requirement and how VDP achieves it. 609 +-------------+---------------------------------------+------------+ 610 | Paragraph | | | 611 | in I-D. | | VDP | 612 | kreeger- | | Support | 613 | nvo3- | | & | 614 | hypervisor- | | Additional | 615 | nve-cp-01] | Requirement | Discussion | 616 +-------------+----------------------------+----------+------------+ 617 | (4.) | "...identifies the Tenant System (TS) | SBF | 618 | |VNIC addresses and VN Name (or ID)..." | 4.1. | 619 | | | | 620 | (4.) | "...identify a locally significant | Yes | 621 | | tag (e.g., an 802.1Q VLAN tag) that | 4.2. | 622 | | can be used to identify the data | | 623 | | frames that flow between the TS VNIC | | 624 | | and the VN." | | 625 | | | | 626 | (4.1.) | "The NVE must be notified when an End | Yes | 627 | | Device requires connection to a | | 628 | | particular VN and when it no longer | | 629 | | requires connection." | | 630 | | | | 631 | (4.1.) | "...the external NVE must provide a | Yes | 632 | | local tag value for each connected VN | 4.2. | 633 | | to the End Device to use for exchange | | 634 | | of packets between the End Device and | | 635 | | the NVE (e.g. a locally significant | | 636 | | 802.1Q tag value)." | | 637 | | | | 638 | (4.1.) | "The Identification of the VN in this | Yes | 639 | | protocol could either be through a VN | 4.3. | 640 | | Name or a VN ID." | | 641 | | | | 642 | (4.2.) | "...the "hypervisor-to-NVE" protocol | Yes | 643 | | requires a means to allow End Devices | | 644 | | to communicate new tenant addresses | | 645 | | associations for a given VNIC within | | 646 | | a VN." | | 647 | | | | 648 | (4.3.) | "When a VNIC within an End Device | Yes | 649 | | terminates function..., all addresses | | 650 | | associated with that VNIC must be | | 651 | | disassociated with the End Device on | | 652 | | the connected NVE." | | 653 | | | | 654 | (4.3.) | "If the VNIC only has a single address| Yes | 655 | | associated with it, then this can be | | 656 | | a single address disassociate message | | 657 | | to the NVE." | | 658 | | | | 659 | (4.3.) | "...if the VNIC had hundreds of | SBF | 660 | | addresses associated with it, then | 4.4. | 661 | | the protocol with the NVE would be | | 662 | | better optimized to simply | | 663 | | disassociate the VNIC with the NVE, | | 664 | | and the NVE can automatically | | 665 | | disassociate all addresses that were | | 666 | | associated with the VNIC." | | 667 | | | | 668 | (4.4.) | "...the NVE can make optimizations if | Yes | 669 | | it knows which addresses are | | 670 | | associated with which VNICs within an | | 671 | | End Device and also is notified of | | 672 | | state changes of that VNIC, | | 673 | | specifically the difference between | | 674 | | VNIC shutdown/startup and VNIC | | 675 | | migration arrival/departure. | | 676 | | | | 677 +-------------+---------------------------------------+------------+ 679 4.1. VDP Addressing support 681 VDP as currently defined is fundamentally layer two. It supports 682 addresses composed of an IEEE 802 style MAC address optionally 683 combined with a VLAN identifier. These addresses are carried in the 684 Filter Info field of the VDP Association TLV, see 3.2.2. The 685 framework of VDP allows for the communication of various formats of 686 the Filter Info field and additional formats may be added that 687 support layer three addresses such as IPv4 and IPv6 addresses, see 688 3.3. Alternatively, using the organizationally defined TLV 689 mechanism, an IETF defined TLV may be used. 691 4.2. VDP Support of VLAN Identification 693 VDP supports two mechanisms for expressing a locally significant 694 tag. One is to express a 802.1Q VLAN ID explicitly. The other is 695 to use a GroupID which has local significance and can be mapped to 696 an actual VLAN by the network controlling entities (see 697 [IEEE8021Qbg] for details 699 4.3. VDP Support of VN Identification 701 The GroupID is a 32-bit value that may be used for VN 702 identification. Additional Filter Info formats may be defined to 703 support a GUID or other forms of a name. Alternatively, using the 704 organizationally defined TLV mechanism, an IETF defined TLV may be 705 used. 707 4.4. Removal of all Addresses Associated with a VNIC 709 VDP currently does not support the mass removal of all addresses 710 associated with a VNIC. Instead, these must be removed 711 individually. However, such a capability may be defined by creating 712 a Format code that indicates no Filter Info entry is present in the 713 VDP Association TLV. On a de-associate operation, this would 714 indicate the need to remove all addresses. 716 5. Summary and Conclusions 718 VDP meets most of the requirements to support the VM-to-NVE control 719 plane protocol. With the addition of a few Filter Info formats, all 720 of the requirements may be met within the framework of VDP. 722 6. Security Considerations 724 TBD 726 7. References 728 7.1. Normative References 730 [IEEE8021Qbg] IEEE Std 802.1Qbg(TM)-2012, IEEE Standard for Local 731 and metropolitan area networks-Media Access Control (MAC) 732 Bridges and Virtual Bridged Local Area Networks-Amendment 733 21: Edge Virtual Bridging. 735 [I-D.kreeger-nvo3-hypervisor-nve-cp-01] Kreeger, L., Narten, T., and 736 D. Black, "Network Virtualization Hypervisor-to-NVE 737 Overlay Control Protocol Requirements", draft-kreeger- 738 nvo3-hypervisor-nve-cp-01, August, 2013. 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, March 1997. 743 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 744 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 745 2005. 747 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 748 Architecture", RFC 4291, February 2006. 750 8. Acknowledgments 752 This document was prepared using 2-Word-v2.0.template.dot. 754 Authors' Addresses 756 Joseph Pelissier 757 Cisco 758 170 Tasman Drive 759 San Jose, CA 95134 760 USA 762 Email: jopeliss@cisco.com 764 Patricia Thaler 765 Broadcom Corporation 766 5300 California Ave 767 Irvine, California 92617 768 USA 770 Email: pthaler@broadcom.com 772 Paul Bottorff 773 8000 Foothills Blvd., M/S 1421 774 Roseville, CA 95747 776 Email: paul.bottorff@hp.com