idnits 2.17.00 (12 Aug 2021) /tmp/idnits17430/draft-kreeger-nvo3-hypervisor-nve-cp-01.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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 3365 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4301' is defined on line 670, but no explicit reference was found in the text == Outdated reference: draft-ietf-nvo3-framework has been published as RFC 7365 == Outdated reference: draft-ietf-nvo3-overlay-problem-statement has been published as RFC 7364 == Outdated reference: A later version (-02) exists of draft-kompella-nvo3-server2nve-01 == Outdated reference: A later version (-04) exists of draft-kreeger-nvo3-overlay-cp-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Kreeger 3 Internet-Draft Cisco 4 Intended status: Informational T. Narten 5 Expires: August 29, 2013 IBM 6 D. Black 7 EMC 8 February 25, 2013 10 Network Virtualization Hypervisor-to-NVE Overlay Control Protocol 11 Requirements 12 draft-kreeger-nvo3-hypervisor-nve-cp-01 14 Abstract 16 The document "Problem Statement: Overlays for Network Virtualization" 17 discusses the needs for network virtualization using overlay networks 18 in highly virtualized data centers. The problem statement outlines a 19 need for control protocols to facilitate running these overlay 20 networks. This document outlines the high level requirements related 21 to the interaction between hypervisors and the Network Virtualization 22 Edge device when the two entities are not co-located on the same 23 physical device. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 29, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Entity Relationships . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. VNIC Containment Relationship . . . . . . . . . . . . . . 6 63 3.1.1. Layer 2 Virtual Network Service . . . . . . . . . . . 7 64 3.1.2. Layer 3 Virtual Network Service . . . . . . . . . . . 8 65 4. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 9 66 4.1. VN Connect/Disconnect . . . . . . . . . . . . . . . . . . 11 67 4.2. VNIC Address Association . . . . . . . . . . . . . . . . . 12 68 4.3. VNIC Address Disassociation . . . . . . . . . . . . . . . 12 69 4.4. VNIC Shutdown/Startup/Migration . . . . . . . . . . . . . 13 70 4.5. VN Profile . . . . . . . . . . . . . . . . . . . . . . . . 14 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 Note: the contents of this document were originally in 79 [I-D.kreeger-nvo3-overlay-cp]. The content has been pulled into its 80 own document because the problem area covered is distinct and 81 different from what most folk think of as a "control protocol" for 82 NVO3. Other related documents on this same general topic include 83 [I-D.kompella-nvo3-server2nve], [I-D.gu-nvo3-overlay-cp-arch], and 84 [I-D.gu-nvo3-tes-nve-mechanism]. 86 "Problem Statement: Overlays for Network Virtualization" 87 [I-D.ietf-nvo3-overlay-problem-statement] discusses the needs for 88 network virtualization using overlay networks in highly virtualized 89 data centers and provides a general motivation for building such 90 networks. "Framework for DC Network Virtualization" 91 [I-D.ietf-nvo3-framework] provides a framework for discussing overlay 92 networks generally and the various components that must work together 93 in building such systems. The reader is assumed to be familiar with 94 both documents. 96 Section 4.5 of [I-D.ietf-nvo3-overlay-problem-statement] describes 97 three separate work areas that fall under the general category of a 98 control protocol for NVO3. This document focuses entirely on the 99 control protocol related to the hypervisor-to-NVE interaction, 100 labeled as the "third work item" in 101 [I-D.ietf-nvo3-overlay-problem-statement]. Requirements for the 102 interaction between an NVE and the "oracle" are described in 103 [I-D.kreeger-nvo3-overlay-cp]. 105 The NVO3 WG needs to decide on a better term for "oracle". This 106 document will use Information Mapping Authority (IMA) until a 107 decision is made. 109 This document uses the term "hypervisor" throughout when describing 110 the scenario where NVE functionality is implemented on a separate 111 device from the "hypervisor" that contains a VM connected to a VN. 112 In this context, the term "hypervisor" is meant to cover any device 113 type where the NVE functionality is offloaded in this fashion, e.g., 114 a Network Service Appliance. 116 This document often uses the term "VM" and "Tenant System" (TS) 117 interchangeably, even though a VM is just one type of Tenant System 118 that may connect to a VN. For example, a service instance within a 119 Network Service Appliance may be another type of TS. When this 120 document uses the term VM, it will in most cases apply to other types 121 of TSs. 123 2. Terminology 125 This document uses the same terminology as found in the NVO3 126 Framework document, [I-D.ietf-nvo3-framework]. Some of the terms 127 defined in the Framework document have been repeated in this section 128 for the convenience of the reader, along with additional terminology 129 that is used by this document. 131 IMA: Information Mapping Authority. 132 [I-D.ietf-nvo3-overlay-problem-statement] uses the term "oracle" 133 to describe this. It is a back-end system that is responsible for 134 distributing and maintaining the mapping information for the 135 entire overlay system. Note that the WG never reached consensus 136 on what to call this architectural entity within the overlay 137 system, so this term is subject to change. 139 Tenant System: A physical or virtual system that can play the role 140 of a host, or a forwarding element such as a router, switch, 141 firewall, etc. It belongs to a single tenant and connects to one 142 or more VNs of that tenant. 144 End Device: A physical system to which networking service is 145 provided. Examples include hosts (e.g. server or server blade), 146 storage systems (e.g., file servers, iSCSI storage systems), and 147 network devices (e.g., firewall, load-balancer, IPSec gateway). 148 An end device may include internal networking functionality that 149 interconnects the device's components (e.g. virtual switches that 150 interconnect VMs running on the same server). NVE functionality 151 may be implemented as part of that internal networking. 153 Network Service Appliance: A stand-alone physical device or a 154 virtual device that provides a network service, such as a 155 firewall, load balancer, etc. Such appliances may embed Network 156 Virtualization Edge (NVE) functionality within them in order to 157 more efficiently operate as part of a virtualized network. 159 VN: Virtual Network. This is a virtual L2 or L3 domain that belongs 160 to a tenant. 162 VDC: Virtual Data Center. A container for virtualized compute, 163 storage and network services. Managed by a single tenant, a VDC 164 can contain multiple VNs and multiple Tenant Systems that are 165 connected to one or more of these VNs. 167 VN Alias: A string name for a VN as used by administrators and 168 customers to name a specific VN. A VN Alias is a human-usable 169 string that can be listed in contracts, customer forms, email, 170 configuration files, etc. and that can be communicated easily 171 vocally (e.g., over the phone). A VN Name is independent of the 172 underlying technology used to implement a VN and will generally 173 not be carried in protocol fields of control protocols used in 174 virtual networks. Rather, a VN Alias will be mapped into a VN 175 Name where precision is required. 177 VN Name: A globally unique identifier for a VN suitable for use 178 within network protocols. A VN Name will usually be paired with a 179 VN Alias, with the VN Alias used by humans as a shorthand way to 180 name and identify a specific VN. A VN Name should have a compact 181 representation to minimize protocol overhead where a VN Name is 182 carried in a protocol field. Using a Universally Unique 183 Identifier (UUID) as discussed in RFC 4122, may work well because 184 it is both compact and a fixed size and can be generated locally 185 with a very high likelihood of global uniqueness. 187 VN ID: A unique and compact identifier for a VN within the scope of 188 a specific NVO3 administrative domain. It will generally be more 189 efficient to carry VN IDs as fields in control protocols than VN 190 Aliases. There is a one-to-one mapping between a VN Name and a VN 191 ID within an NVO3 Administrative Domain. Depending on the 192 technology used to implement an overlay network, the VN ID could 193 be used as the Context Identifier in the data plane, or would need 194 to be mapped to a locally-significant Context Identifier. 196 VN Profile: Meta data associated with a VN that is used by an NVE 197 when ingressing/egressing packets to/from a specific VN. Meta 198 data could include such information as ACLs, QoS settings, etc. 199 The VN Profile contains parameters that apply to the VN as a 200 whole. Control protocols could use the VN ID or VN Name to obtain 201 the VN Profile. 203 VNIC: A Virtual NIC that connects a Tenant System to a Virtual 204 Network Instance (VNI). Virtual NICs have virtual MAC addresses 205 that may not be globally unique, but must be unique within a VN 206 for proper network operation. 208 VNIC Name: A globally unique identifier for a VNIC suitable for use 209 within network protocols. Note that because VNIC MAC addresses 210 may not be globally unique, they cannot be used as the VNIC Name. 211 A VNIC Name should have a compact representation to minimize 212 protocol overhead where a VNIC Name is carried in a protocol 213 field. Using a Universally Unique Identifier (UUID) as discussed 214 in RFC 4122, may work well because it is both compact and a fixed 215 size and can be generated locally with a very high likelihood of 216 global uniqueness. 218 3. Entity Relationships 220 This section describes the relationships between the entities 221 involved in the Hypervisor-to-NVE control protocol. 223 3.1. VNIC Containment Relationship 225 The root of the containment tree is a VNIC. Even though a VM may 226 have multiple VNICs, from the point of view of an NVE, each VNIC can 227 be treated independently. There is no need to identify the VM itself 228 within the Hypervisor-to-NVE protocol. 230 Each VNIC can connect to multiple VNs. Within each VNIC-VN pair, 231 multiple MAC addresses may be reachable. Within each VNIC-VN-MAC 232 triplet, there may be multiple IP addresses. This containment 233 hierarchy is depicted below. 235 VNIC-+-VN-+-MAC-+-IP 236 | | +-IP ... 237 | | 238 | +-MAC-+-IP 239 | +-IP ... 240 | 241 +-VN-+-MAC-+-IP 242 | +-IP ... 243 | 244 +-MAC-+-IP 245 +-IP ... 247 VNIC Containment Relationship 249 Figure 1 251 Any of these entities can be added or removed dynamically at any 252 time. 254 The relationship implies that if one entity in the hierarchy is 255 deleted then all the entities it contains are also deleted. For 256 example, if a given VNIC disassociates from one VN, all the MAC and 257 IP addresses are also disassociated. There is no need to signal the 258 deletion of every entity within a VNIC when the VNIC is brought down 259 or deleted (or the VM it is attached to is powered off or migrates 260 away from the hypervisor). 262 If a VNIC provides connectivity to a range of IP addresses (e.g. the 263 VM is a load balancer with many Virtual IP addresses), it will be 264 more efficient to signal a range or address mask in place of 265 individual IP addresses. 267 In the majority of cases, a VM will be acting as a simple host that 268 will have the following containment tree: 270 VNIC--VN--MAC--IP 272 Figure 2 274 Since this is the most common case, the Hypervisor-to-NVE protocol 275 should be optimized to handle this case. 277 Tenant Systems (TS) that are providing network services (such as 278 firewall, load balancer, VPN gateway) are likely to have a more 279 complex containment hierarchy. For example, a TS acting as a load 280 balancer is quite likely to terminate multiple IP addresses, one for 281 each application, or farm of servers that it is providing the front 282 end for. 284 Hypervisors often have a limit on the number of VNICs that a VM can 285 have (e.g. in the range of 8 to 10 VNICs). If a VM has the need to 286 connect to more networks than the number of VNICs the hypervisor 287 supports, the solutions is often to configure the VNIC (and the 288 associated virtual port on the virtual switch the VNIC connects to) 289 as an 802.1Q trunk. In the case of a virtual switch that supports 290 only VLANs, the VLAN tags used by all the VNICs connected to the 291 switch (as well as the bridged network the hypervisor is physically 292 connected to) share a common VLAN ID. 294 In a multi-tenant scenario using overlay Virtual Networks instead of 295 VLANs, VNICs can still use 802.1Q tagging to isolate traffic from 296 different VNs as it crosses the virtual link between the VNIC and the 297 virtual switch; However, The tags would have only local significance 298 across that virtual link, with the virtual switch mapping each tag 299 value to a different VN. This implies that two different virtual 300 links may use different 802.1Q tag values but with each mapped to the 301 same VN by the virtual switch. Similarly, two VNICs could use the 302 same VLAN tag value but the virtual switch can map each vPort/Tag 303 pair to a different VN. 305 Each VNIC must attach to at least one VN and have at minimum one MAC 306 address. An IP address can be optional depending on whether the VN 307 is providing L2 or L3 service. 309 3.1.1. Layer 2 Virtual Network Service 311 When the Virtual Network is providing only Layer 2 forwarding, the 312 NVEs only require knowledge of the Tenant System's MAC addresses, 313 while layer 3 termination and routing happens only in the Tenant 314 Systems. 316 For example, if a VM is acting as a router to connect together two 317 layer 2 VNs, the overlay system will forward frames to this router VM 318 based on the VNIC's MAC address, but inside the frames may be packets 319 destined to many different IP addresses. There is no need for the 320 NVEs to know the IP address of the router VM itself, nor the IP 321 addresses of other TS that have packets routing through the VM. 322 However, it may be useful for the NVE to know the IP address of the 323 router itself for either troubleshooting, or for providing other 324 network optimizations such as local termination of ARP (even though 325 ARP optimizations are not strictly layer 2). It is recommended (but 326 optional) for an End Device to provide an IP address for a VNIC even 327 if the NVE is providing an L2 service. 329 When the overlay VN is forwarding at layer 2, it is possible for 330 Tenant Systems to perform bridging between two VNs belonging to that 331 tenant (provided the tenant MAC addresses do not overlap between the 332 two VNs that are being bridged). Reasons for VMs to do this are the 333 same as in the physical world, such as the insertion of a transparent 334 firewall device. For example, a VM running firewall software can be 335 inserted in between two groups of Tenant Systems on the same subnet 336 by putting each group on a different VN and having the firewall VM 337 bridge between them. 339 When a VM is acting as a transparent bridge, it will appear to the 340 overlay system that the VM is terminating multiple MAC addresses - 341 one for each TS that exists on the other VN the VM is bridging to. 342 In order for the overlay system to properly forward traffic to the 343 bridging VM, it must know the MAC addresses of all the tenant systems 344 the VM is bridging towards. This is one case where a VNIC can appear 345 to terminate more than one MAC address for the same VNIC/VN. 347 3.1.2. Layer 3 Virtual Network Service 349 When the Virtual Network is providing Layer 3 forwarding, the NVEs 350 must have knowledge of the Tenant System IP addresses. In the case 351 where there is a Tenant System providing L3 forwarding for the tenant 352 (e.g. an L3 VPN gateway), The TS VNIC may only terminate frames with 353 a single MAC address, but will be forwarding IP packets on the behalf 354 of other Tenant Systems. This scenario requires more exploration to 355 determine how the TS forwarding interacts with the VN forwarding; 356 However, in one scenario, the TS VNIC may be seen as containing many 357 IP addresses. 359 Note that a MAC address is required even for a pure L3 VN service 360 because VNICs filter out frames with destination MAC addresses that 361 do not match the VNIC's address; Therefore, the NVE providing an L3 362 service must first encapsulate an IP packet in an Ethernet frame with 363 the VNIC's destination MAC before it is sent to the End Device 364 containing the VNIC. 366 4. Hypervisor-to-NVE Control Plane Protocol Functionality 368 The problem statement [I-D.ietf-nvo3-overlay-problem-statement], 369 discusses the needs for a control plane protocol (or protocols) to 370 populate each NVE with the state needed to perform its functions. 372 In one common scenario, an NVE provides overlay encapsulation/ 373 decapsulation packet forwarding services to Tenant Systems (TSs) that 374 are co-resident with the NVE on the same End Device (e.g. when the 375 NVE is embedded within a hypervisor or a Network Service Appliance). 376 In such cases, there is no need for a standardized protocol between 377 the hypervisor and NVE, as the interaction is implemented via 378 software on a single device. 380 Alternatively, a Tenant System may use an externally connected NVE. 381 An external NVE can provide an offload of the encapsulation / 382 decapsulation function, network policy enforcement, as well as the VN 383 Overlay protocol overheads. This offloading may provide performance 384 improvements and/or resource savings to the End Device (e.g. 385 hypervisor) making use of the external NVE. 387 The following figures give example scenarios where the Tenant System 388 and NVE are on different devices separated by an access network. 390 Hypervisor Access Switch 391 +------------------+ +-----+-------+ 392 | +--+ +-------+ | | | | 393 | |VM|---| | | VLAN | | | 394 | +--+ |Virtual|---------+ NVE | +--- Underlying 395 | +--+ |Switch | | Trunk | | | Network 396 | |VM|---| | | | | | 397 | +--+ +-------+ | | | | 398 +------------------+ +-----+-------+ 400 Hypervisor with an External NVE. 402 Figure 3 404 Access 405 Hypervisor Switch NVE 406 +------------------+ +-----+ +-----+ 407 | +--+ +-------+ | | | | | 408 | |VM|---| | | VLAN | | VLAN | | 409 | +--+ |Virtual|---------+ +-------+ +--- Underlying 410 | +--+ |Switch | | Trunk | | Trunk | | Network 411 | |VM|---| | | | | | | 412 | +--+ +-------+ | | | | | 413 +------------------+ +-----+ +-----+ 415 Hypervisor with an External NVE across an Ethernet Access Switch. 417 Figure 4 419 Network Service Appliance Access Switch 420 +--------------------------+ +-----+-------+ 421 | +------------+ |\ | | | | 422 | |Net Service |----| \ | | | | 423 | |Instance | | \ | VLAN | | | 424 | +------------+ | |---------+ NVE | +--- Underlying 425 | +------------+ | | | Trunk| | | Network 426 | |Net Service |----| / | | | | 427 | |Instance | | / | | | | 428 | +------------+ |/ | | | | 429 +--------------------------+ +-----+-------+ 431 Physical Network Service Appliance with an External NVE. 433 Figure 5 435 In the examples above, the physical VLAN Trunk from the Hypervisor or 436 Network Services Appliance towards the external NVE only needs to 437 carry locally significant VLAN tag values. How "local" the 438 significance is depends on whether the Hypervisor has a direct 439 physical connection to the NVE (in which case the significance is 440 local to the physical link), or whether there is an Ethernet switch 441 (e.g. a blade switch) connecting the Hypervisor to the NVE (in which 442 case the significance is local to the intervening switch and all the 443 links connected to it). 445 These VLAN tags are used to differentiate between different VNs as 446 packets cross the shared access network to the external NVE. When 447 the NVE receives packets, it uses the VLAN tag to identify the VN of 448 packets coming from a given Tenant System's VNIC, strips the tag, and 449 adds the appropriate overlay encapsulation for that VN. 451 On the hypervisor-facing side of the NVE, a control plane protocol is 452 necessary to provide an NVE with the information it needs to provide 453 connectivity across the Virtual Network for a given VNIC. 454 Specifically, the Hypervisor (or Network Service Appliance) utilizing 455 an external NVE needs to "attach to" and "detach from" a VN, as well 456 as communicate the addresses within that VN that are reachable within 457 it. Thus, they will need a protocol that runs across the access 458 network between the two devices that identifies the Tenant System 459 (TS) VNIC addresses and VN Name (or ID) for which the NVE is 460 providing service. In addition, such a protocol will identify a 461 locally significant tag (e.g., an 802.1Q VLAN tag) that can be used 462 to identify the data frames that flow between the TS VNIC and the VN. 464 4.1. VN Connect/Disconnect 466 In the previous figures, NVEs reside on an external networking device 467 (e.g. an access switch). When an NVE is external, a protocol is 468 needed between the End Device (e.g. Hypervisor) making use of the 469 external NVE and the external NVE in order to make the NVE aware of 470 the changing VN membership requirements of the Tenant Systems within 471 the End Device. 473 A key driver for using a protocol rather than using static 474 configuration of the external NVE is because the VN connectivity 475 requirements can change frequently as VMs are brought up, moved and 476 brought down on various hypervisors throughout the data center. 478 The NVE must be notified when an End Device requires connection to a 479 particular VN and when it no longer requires connection. In 480 addition, the external NVE must provide a local tag value for each 481 connected VN to the End Device to use for exchange of packets between 482 the End Device and the NVE (e.g. a locally significant 802.1Q tag 483 value). 485 The Identification of the VN in this protocol could either be through 486 a VN Name or a VN ID. A globally unique VN Name facilitates 487 portability of a Tenant's Virtual Data Center. When a VN within a 488 VDC is instantiated within a particular administrative domain, it can 489 be allocated a VN Context which only the NVE needs to use. Once an 490 NVE receives a VN connect indication, the NVE needs a way to get a VN 491 Context allocated (or receive the already allocated VN Context) for a 492 given VN Name or ID (as well as any other information needed to 493 transmit encapsulated packets). How this is done is the subject of 494 the NVE-to-oracle (called NVE-to-IMA in this document) protocol which 495 are part of work items 1 and 2 in 496 [I-D.ietf-nvo3-overlay-problem-statement]. 498 An End Device that is making use of an offloaded NVE only needs to 499 communicate the VN Name or ID to the NVE, and get back a locally 500 significant tag value. 502 4.2. VNIC Address Association 504 Typically, a VNIC is assigned a single MAC address and all frames 505 transmitted and received on that VNIC use that single MAC address. 506 As discussed in the section above on the containment hierarch, it is 507 also possible for a Tenant System to exchange frames using multiple 508 MAC addresses (ones that are not assigned to the VNIC) or packets 509 with multiple IP addresses. 511 Particularly in the case of a TS that is forwarding frames or packets 512 from other TSs, the NVE will need to communicate the mapping between 513 the NVE's IP address (on the underlying network) and ALL the 514 addresses the TS is forwarding on behalf of to the Information 515 Mapping Authority (IMA). 517 The NVE has two ways in which it can discover the tenant addresses 518 for which frames must be forwarded to a given End Device (and 519 ultimately to the TS within that End Device). 521 1. It can glean the addresses by inspecting the source addresses in 522 packets it receives from the End Device. 524 2. The End Device can explicitly signal the addresses to the NVE. 525 The End Device could have discovered the addresses for a given 526 VNIC by gleaning them itself from data packets sent by the VNIC, 527 or by some other internal means within the End Device itself. 529 To perform the second approach above, the "hypervisor-to-NVE" 530 protocol requires a means to allow End Devices to communicate new 531 tenant addresses associations for a given VNIC within a given VN. 533 4.3. VNIC Address Disassociation 535 When a VNIC within an End Device terminates function (due to events 536 such as VNIC shutdown, Tenant System (TS) shutdown, or VM migration 537 to another hypervisor), all addresses associated with that VNIC must 538 be disassociated with the End Device on the connected NVE. 540 If the VNIC only has a single address associated with it, then this 541 can be a single address disassociate message to the NVE. However, if 542 the VNIC had hundreds of addresses associated with it, then the 543 protocol with the NVE would be better optimized to simply 544 disassociate the VNIC with the NVE, and the NVE can automatically 545 disassociate all addresses that were associated with the VNIC. 547 Having TS addresses associated with a VNIC can also provide 548 scalability benefits when the VM migrates between hypervisors that 549 are connected to the same NVE. When a VM migrates to another 550 hypervisor connected to the same NVE, if the NVE is aware of the 551 migration, there is no need for all the addresses to be purged from 552 NVE (and IMA) only to be immediately re-established again when the VM 553 migration completes. 555 If the device containing the NVE is supporting many hypervisors, it 556 may be quite likely that the VM migration will result in the VNICs 557 still being associated with the same NVE, but simply on a different 558 port. From the point of view of the IMA, nothing has changed and it 559 would be inefficent to signal these changes to the IMA for no 560 benefit. The NVE only needs to associate the addresses with a 561 different port/tag pair. 563 It is possible for the NVE to handle a VM migration by using a timer 564 to retain the VNIC addresses for a short time to see if the 565 disassociated VNIC re-assocatiates on another NVE port, but this could 566 be better handled if the NVE knew the difference between a VNIC/VM 567 shutdown and a VM migration. This leads to the next section. 569 4.4. VNIC Shutdown/Startup/Migration 571 As discussed above, the NVE can make optimizations if it knows which 572 addresses are associated with which VNICs within an End Device and 573 also is notified of state changes of that VNIC, specifically the 574 difference between VNIC shutdown/startup and VNIC migration arrival/ 575 departure. 577 Upon VNIC shutdown, the NVE can immediately signal to the IMA that 578 the bindings of the VNIC's addresses to the NVE's IP address can be 579 removed. 581 Upon VNIC arrival, the NVE could either start a timer to hold the 582 VNIC address bindings waiting to see if the VNIC arrives on a 583 different port, or if there is a pre-arrival handshake with the NVE, 584 then it will already know that the VNIC is going to be reassociated 585 with the same NVE. 587 Upon VNIC arrival, the NVE knows that any addresses previously bound 588 to the VNIC are still present and has no need to signal any change in 589 address mappings to the IMA. 591 Note that if the IMA is also aware of VNIC address bindings, it can 592 similarly participate efficiently in a VM migration that occurs 593 across two different NVEs. 595 4.5. VN Profile 597 Once an NVE (embedded or external) receives a VN connect indication 598 with a specified VN Name or ID, the NVE must determine the VN Context 599 value to encapsulate packets with as well as other information that 600 may be needed (e.g., QoS settings). The NVE serving that hypervisor 601 needs a way to get a VN Context allocated or receive the already 602 allocated VN Context for a given VN Name or ID (as well as any other 603 information needed to transmit encapsulated packets). A protocol for 604 an NVE to get this mapping may be a useful function, but would be the 605 subject of work items 1 and 2 in 606 [I-D.ietf-nvo3-overlay-problem-statement]. 608 5. Security Considerations 610 Editor's Note: This is an initial start on the security 611 considerations section; it will need to be expanded, and suggestions 612 for material to add are welcome. 614 NVEs must ensure that only properly authorized Tenant Systems are 615 allowed to join and become a part of any specific Virtual Network. 616 In addition, NVEs will need appropriate mechanisms to ensure that any 617 hypervisor wishing to use the services of an NVE are properly 618 authorized to do so. One design point is whether the hypervisor 619 should supply the NVE with necessary information (e.g., VM addresses, 620 VN information, or other parameters) that the NVE uses directly, or 621 whether the hypervisor should only supply a VN ID and an identifier 622 for the associated VM (e.g., its MAC address), with the NVE using 623 that information to obtain the information needed to validate the 624 hypervisor-provided parameters or obtain related parameters in a 625 secure manner. 627 6. Acknowledgements 629 Thanks to the following people for reviewing and providing feedback: 630 Vipin Jain and Shyam Kapadia. 632 7. Informative References 634 [I-D.gu-nvo3-overlay-cp-arch] 635 Yingjie, G. and W. Hao, "Analysis of external assistance 636 to NVE and consideration of architecture", 637 draft-gu-nvo3-overlay-cp-arch-00 (work in progress), 638 July 2012. 640 [I-D.gu-nvo3-tes-nve-mechanism] 641 Yingjie, G. and L. Yizhou, "The mechanism and signalling 642 between TES and NVE", draft-gu-nvo3-tes-nve-mechanism-01 643 (work in progress), October 2012. 645 [I-D.ietf-nvo3-framework] 646 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 647 Rekhter, "Framework for DC Network Virtualization", 648 draft-ietf-nvo3-framework-02 (work in progress), 649 February 2013. 651 [I-D.ietf-nvo3-overlay-problem-statement] 652 Narten, T., Gray, E., Black, D., Dutt, D., Fang, L., 653 Kreeger, L., Napierala, M., and M. Sridharan, "Problem 654 Statement: Overlays for Network Virtualization", 655 draft-ietf-nvo3-overlay-problem-statement-02 (work in 656 progress), February 2013. 658 [I-D.kompella-nvo3-server2nve] 659 Kompella, K., Rekhter, Y., and T. Morin, "Signaling 660 Virtual Machine Activity to the Network Virtualization 661 Edge", draft-kompella-nvo3-server2nve-01 (work in 662 progress), October 2012. 664 [I-D.kreeger-nvo3-overlay-cp] 665 Kreeger, L., Dutt, D., Narten, T., and M. Sridharan, 666 "Network Virtualization Overlay Control Protocol 667 Requirements", draft-kreeger-nvo3-overlay-cp-02 (work in 668 progress), October 2012. 670 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 671 Internet Protocol", RFC 4301, December 2005. 673 Authors' Addresses 675 Lawrence Kreeger 676 Cisco 678 Email: kreeger@cisco.com 680 Thomas Narten 681 IBM 683 Email: narten@us.ibm.com 684 David Black 685 EMC 687 Email: david.black@emc.com