idnits 2.17.1 draft-ietf-nvo3-nve-nva-cp-req-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3830 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.kreeger-nvo3-hypervisor-nve-cp-req' is mentioned on line 163, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-03 Summary: 1 error (**), 0 flaws (~~), 3 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 D. Dutt 5 Expires: April 24, 2014 Cumulus Networks 6 T. Narten 7 IBM 8 D. Black 9 EMC 10 October 21, 2013 12 Network Virtualization NVE to NVA Control Protocol Requirements 13 draft-ietf-nvo3-nve-nva-cp-req-01 15 Abstract 17 The document "Problem Statement: Overlays for Network Virtualization" 18 discusses the needs for network virtualization using overlay networks 19 in highly virtualized data centers. The problem statement outlines a 20 need for control protocols to facilitate running these overlay 21 networks. This document outlines the high level requirements to be 22 fulfilled by the control protocols related to building and managing 23 the mapping tables and other state information used by the Network 24 Virtualization Edge to transmit encapsulated packets across the 25 underlying network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 24, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Control Plane Protocol Functionality . . . . . . . . . . . . 4 64 3.1. Inner to Outer Address Mapping . . . . . . . . . . . . . 7 65 3.2. Underlying Network Multi-Destination Delivery Address(es) 7 66 3.3. VN Connect/Disconnect Notification . . . . . . . . . . . 8 67 3.4. VN Name to VN ID Mapping . . . . . . . . . . . . . . . . 8 68 4. Control Plane Characteristics . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Informative References . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 "Problem Statement: Overlays for Network Virtualization" 77 [I-D.ietf-nvo3-overlay-problem-statement] discusses the needs for 78 network virtualization using overlay networks in highly virtualized 79 data centers and provides a general motivation for building such 80 networks. "Framework for DC Network Virtualization" 81 [I-D.ietf-nvo3-framework] provides a framework for discussing overlay 82 networks generally and the various components that must work together 83 in building such systems. The reader is assumed to be familiar with 84 both documents. 86 Section 4.5 of [I-D.ietf-nvo3-overlay-problem-statement] describes 87 three separate work areas that fall under the general category of a 88 control protocol for NVO3. This document focuses entirely on those 89 aspects of the control protocol related to the building and 90 distributing the mapping tables an NVE uses to tunnel traffic from 91 one VM to another. Specifically, this document focuses on work areas 92 1 and 2 given in Section 4.5 of 93 [I-D.ietf-nvo3-overlay-problem-statement]. Work areas 1 and 2 cover 94 the interaction between an NVE and the Network Virtualization 95 Authority (NVA) (work area 2) or operation of the NVA itself (work 96 area 1). Requirements related to interaction between a hypervisor 97 and NVE when the two entities reside on separate physical devices 98 (work area 3) are covered in [I-D.kreeger-nvo3-hypervisor-nve-cp- 99 req]. 101 2. Terminology 103 This document uses the same terminology as found in 104 [I-D.ietf-nvo3-framework]. This section defines additional 105 terminology used by this document. 107 Network Service Appliance: A stand-alone physical device or a 108 virtual device that provides a network service, such as a 109 firewall, load balancer, etc. Such appliances may embed Network 110 Virtualization Edge (NVE) functionality within them in order to 111 more efficiently operate as part of a virtualized network. 113 VN Alias: A string name for a VN as used by administrators and 114 customers to name a specific VN. A VN Alias is a human-usable 115 string that can be listed in contracts, customer forms, email, 116 configuration files, etc. and that can be communicated easily 117 vocally (e.g., over the phone). A VN Alias is independent of the 118 underlying technology used to implement a VN and will generally 119 not be carried in protocol fields of control protocols used in 120 virtual networks. Rather, a VN Alias will be mapped into a VN 121 Name where precision is required. 123 VN Name: A globally unique identifier for a VN suitable for use 124 within network protocols. A VN Name will usually be paired with a 125 VN Alias, with the VN Alias used by humans as a shorthand way to 126 name and identify a specific VN. A VN Name should have a compact 127 representation to minimize protocol overhead where a VN Name is 128 carried in a protocol field. Using a Universally Unique 129 Identifier (UUID) as discussed in RFC 4122, may work well because 130 it is both compact and a fixed size and can be generated locally 131 with a very high likelihood of global uniqueness. 133 VN ID: A unique and compact identifier for a VN within the scope of 134 a specific NVO3 administrative domain. It will generally be more 135 efficient to carry VN IDs as fields in control protocols than VN 136 Names or VN Aliases. There is a one-to-one mapping between a VN 137 Name and a VN ID within an NVO3 Administrative Domain. Depending 138 on the technology used to implement an overlay network, the VN ID 139 could be used as the VN Context in the data plane, or would need 140 to be mapped to a locally-significant context ID. 142 3. Control Plane Protocol Functionality 144 The NVO3 problem statement [I-D.ietf-nvo3-overlay-problem-statement], 145 discusses the needs for a control plane protocol (or protocols) to 146 populate each NVE with the state needed to perform its functions. 148 In one common scenario, an NVE provides overlay encapsulation/ 149 decapsulation packet forwarding services to Tenant Systems that are 150 co-resident with the NVE on the same End Device. For example, when 151 the NVE is embedded within a hypervisor or a Network Service 152 Appliance, as depicted in Figure 1 and Figure 2 below. 153 Alternatively, a Tenant System may use an externally connected NVE. 154 For example, an NVE residing on a physical Network Switch connected 155 to the End Device, as depicted in Figure 3 and Figure 4 below. 157 There are two control plane aspects for an NVE. One is the protocol 158 between the NVE and its NVA used to populate the NVE's mapping tables 159 for tunneling traffic across the underlying network. Another is the 160 protocol between an End Device (e.g. Hypervisor) and an external NVE 161 used to promptly update the NVE of Tenant System Interface status. 162 This latter control plane aspect is not discussed in this document, 163 but is covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req]. The 164 functional requirements for the NVE to NVA control plane are the same 165 regardless of whether the NVE is embedded within and End Device or in 166 an external device as depicted in Figure 1 through Figure 4 below. 168 Hypervisor 169 +-----------------------+ 170 | +--+ +-------+---+ | 171 | |VM|---| | | | 172 | +--+ |Virtual|NVE|----- Underlying 173 | +--+ |Switch | | | Network 174 | |VM|---| | | | 175 | +--+ +-------+---+ | 176 +-----------------------+ 178 Hypervisor with an Embedded NVE. 180 Figure 1 182 Network Service Appliance 183 +---------------------------+ 184 | +------------+ +-----+ | 185 | |Net Service |---| | | 186 | |Instance | | | | 187 | +------------+ | NVE |------ Underlying 188 | +------------+ | | | Network 189 | |Net Service |---| | | 190 | |Instance | | | | 191 | +------------+ +-----+ | 192 +---------------------------+ 194 Network Service Appliance (physical or virtual) with an Embedded NVE. 196 Figure 2 198 Hypervisor Access Switch 199 +------------------+ +-----+-------+ 200 | +--+ +-------+ | | | | 201 | |VM|---| | | VLAN | | | 202 | +--+ |Virtual|---------+ NVE | +--- Underlying 203 | +--+ |Switch | | Trunk | | | Network 204 | |VM|---| | | | | | 205 | +--+ +-------+ | | | | 206 +------------------+ +-----+-------+ 208 Hypervisor with an External NVE. 210 Figure 3 212 Network Service Appliance Access Switch 213 +--------------------------+ +-----+-------+ 214 | +------------+ |\ | | | | 215 | |Net Service |----| \ | | | | 216 | |Instance | | \ | VLAN | | | 217 | +------------+ | |---------+ NVE | +--- Underlying 218 | +------------+ | | | Trunk| | | Network 219 | |Net Service |----| / | | | | 220 | |Instance | | / | | | | 221 | +------------+ |/ | | | | 222 +--------------------------+ +-----+-------+ 224 Physical Network Service Appliance with an External NVE. 226 Figure 4 228 To support an NVE, a control plane protocol is necessary to provide 229 an NVE with the information it needs to maintain its own internal 230 state necessary to carry out its forwarding functions as explained in 231 detail below. 233 1. An NVE maintains a per-VN table of mappings from Tenant System 234 (inner) addresses to Underlying Network (outer) addresses of 235 remote NVEs. 237 2. An NVE maintains per-VN state for delivering tenant multicast and 238 broadcast packets to other Tenant Systems. Such state could 239 include a list of multicast addresses and/or unicast addresses on 240 the Underlying Network for the NVEs associated with a particular 241 VN. 243 3. End Devices (such as a Hypervisor or Network Service Appliance) 244 utilizing an external NVE need to "attach to" and "detach from" 245 an NVE. Specifically, a mechanism is needed to notify an NVE 246 when a Tenant System attaches to or detaches from a specific VN. 247 Such a mechanism would provide the necessary information to the 248 NVE that it needs to provide service to a particular Tenant 249 System. The details of such a mechanism are out-of-scope for 250 this document and are covered in [I-D.kreeger-nvo3-hypervisor- 251 nve-cp-req]. 253 4. An NVE needs a mapping from each unique VN name to the VN Context 254 value used within encapsulated data packets within the 255 administrative domain that the VN is instantiated. 257 The NVE to NVA control protocol operates directly over the underlay 258 network. The NVA is expected to be connected to the same underlay 259 network as the NVEs. 261 Each NVE communicates with only a single logical NVA; However, the 262 NVA can be centralized or distributed between multiple entities for 263 redundancy purposes. When the NVA is made up of multiple entities, 264 better resiliency may be achieved by physically separating them, 265 which may require each entity to be connected to a different IP 266 subnet of the underlay network. For this reason, each NVE should be 267 allowed to be configured with more than one IP addresses for its 268 logical NVA. NVEs should be able to switch between these IP 269 addresses when it detects that the address it is currently using for 270 the NVA is unreachable. 272 Note that a single device could contain both NVE and NVA 273 functionality, but the functional interaction between the NVE and NVA 274 within that device should operate similarly to when the NVE and NVA 275 are implemented in separate devices. 277 3.1. Inner to Outer Address Mapping 279 When presented with a data packet to forward to a Tenant System 280 within a VN, the NVE needs to know the mapping of the Tenant System 281 destination (inner) address to the (outer) address on the Underlying 282 Network of the remote NVE which can deliver the packet to the 283 destination Tenant System. In addition, the NVE needs to know what 284 VN Context to use when sending to a destination Tenant System. 286 A protocol is needed to provide this inner to outer mapping and VN 287 Context to each NVE that requires it and keep the mapping updated in 288 a timely manner. Timely updates are important for maintaining 289 connectivity between Tenant Systems when one Tenant System is a VM. 291 Note that one technique that could be used to create this mapping 292 without the need for a control protocol is via data plane learning; 293 However, the learning approach requires packets to be flooded to all 294 NVEs participating in the VN when no mapping exists. One goal of 295 using a control protocol is to eliminate this flooding. 297 3.2. Underlying Network Multi-Destination Delivery Address(es) 299 Each NVE needs a way to deliver multi-destination packets (i.e. 300 tenant broadcast/multicast) within a given VN to each remote NVE 301 which has a destination Tenant System for these packets. Three 302 possible ways of accomplishing this are: 304 o Use the multicast capabilities of the Underlying Network. 306 o Have each NVE replicate the packets and send a copy across the 307 Underlying Network to each remote NVE currently participating in 308 the VN. 310 o Use one or more distribution servers that replicate the packets on 311 the behalf of the NVEs. 313 Whichever method is used, a protocol is needed to provide on a per VN 314 basis, one or more multicast addresses (assuming the Underlying 315 Network supports multicast), and/or one or more unicast addresses of 316 either the remote NVEs which are not multicast reachable, or of one 317 or more distribution servers for the VN. 319 The protocol must also keep the list of addresses up to date in a 320 timely manner as the set of NVEs for a given VN changes over time. 321 For example, the set of NVEs for a VN could change as VMs power on/ 322 off or migrate to different hypervisors. 324 3.3. VN Connect/Disconnect Notification 326 For the purposes of this document, it is assumed that an NVE receives 327 appropriate notifications when a Tenant System attaches to or 328 detaches from a specific VN. The details of how that is done are 329 orthogonal to the NVE-to-NVA control plane, so long as such 330 notification provides the necessary information needed by the control 331 plane. As one example, the attach/detach notification would 332 presumably include a VN Name that identifies the specific VN to which 333 the attach/detach operation applies to. 335 3.4. VN Name to VN ID Mapping 337 Once an NVE (embedded or external) receives a VN connect indication 338 with a specified VN Name, the NVE must determine what VN Context 339 value and other necessary information to use to forward Tenant System 340 traffic to remote NVEs. In one approach, the NVE-to-NVA protocol 341 uses VN Names directly when interacting, with the NVA providing such 342 information as the VN Context (or VN ID) along with egress NVE's 343 address. Alternatively, it may be desirable for the NVE-to-NVA 344 protocol to use a more compact representation of the VN name, that 345 is, a VN ID. In such a case, a specific NVE-to-NVA operation might 346 be needed to first map the VN Name into a VN ID, with subsequent NVE- 347 to-NVA operations utilizing the VN ID directly. Thus, it may be 348 useful for the NVE-to-NVA protocol to support an operation that maps 349 VN Names into VN IDs. 351 4. Control Plane Characteristics 352 NVEs are expected to be implemented within both hypervisors (or 353 Network Service Appliances) and within access switches. Any 354 resources used by these protocols (e.g. processing or memory) takes 355 away resources that could be better used by these devices to perform 356 their intended functions (e.g. providing resources for hosted VMs). 358 A large scale data center may contain hundreds of thousands of these 359 NVEs (which may be several independent implementations); Therefore, 360 any savings in per-NVE resources can be multiplied hundreds of 361 thousands of times. 363 Given this, the control plane protocol(s) implemented by NVEs to 364 provide the functionality discussed above should have the below 365 characteristics. 367 1. Minimize the amount of state needed to be stored on each NVE. 368 The NVE should only be required to cache state that it is 369 actively using, and be able to discard any cached state when it 370 is no longer required. For example, an NVE should only need to 371 maintain an inner-to-outer address mapping for destinations to 372 which it is actively sending traffic as opposed to maintaining 373 mappings for all possible destinations. 375 2. Fast acquisition of needed state. For example, when a Tenant 376 System emits a packet destined to an inner address that the NVE 377 does not have a mapping for, the NVE should be able to acquire 378 the needed mapping quickly. 380 3. Fast detection/update of stale cached state information. This 381 only applies if the cached state is actually being used. For 382 example, when a VM moves such that it is connected to a 383 different NVE, the inner to outer mapping for this VM's address 384 that is cached on other NVEs must be updated in a timely manner 385 (if they are actively in use). If the update is not timely, the 386 NVEs will forward data to the wrong NVE until it is updated. 388 4. Minimize processing overhead. This means that an NVE should 389 only be required to perform protocol processing directly related 390 to maintaining state for the Tenant Systems it is actively 391 communicating with. For example, if the NVA provides 392 unsolicited information to the NVEs, then one way to minimize 393 the processing on the NVE is for it to subscribe for getting 394 these mappings on a per VN basis. Consequently an NVE is not 395 required to maintain state for all VNs within a domain. An NVE 396 only needs to maintain state (or participate in protocol 397 exchanges) about the VNs it is currently attached to. If the 398 NVE obtains mappings on demand from the NVA, then it only needs 399 to obtain the information relevant to the traffic flows that are 400 currently active. This requirement is for the NVE functionality 401 only. The network node that contains the NVE may be involved in 402 other functionality for the underlying network that maintains 403 connectivity that the NVE is not actively using (e.g., routing 404 and multicast distribution protocols for the underlying 405 network). 407 5. Highly scalable. This means scaling to hundreds of thousands of 408 NVEs and several million VNs within a single administrative 409 domain. As the number of NVEs and/or VNs within a data center 410 grows, the protocol overhead at any one NVE should not increase 411 significantly. 413 6. Minimize the complexity of the implementation. This argues for 414 using the least number of protocols to achieve all the 415 functionality listed above. Ideally a single protocol should be 416 able to be used. The less complex the protocol is on the NVE, 417 the more likely interoperable implementations will be created in 418 a timely manner. 420 7. Extensible. The protocol should easily accommodate extension to 421 meet related future requirements. For example, access control 422 or QoS policies, or new address families for either inner or 423 outer addresses should be easy to add while maintaining 424 interoperability with NVEs running older versions. 426 8. Simple protocol configuration. A minimal amount of 427 configuration should be required for a new NVE to be 428 provisioned. Existing NVEs should not require any configuration 429 changes when a new NVE is provisioned. Ideally NVEs should be 430 able to auto configure themselves. 432 9. Do not rely on IP Multicast in the Underlying Network. Many 433 data centers do not have IP multicast routing enabled. If the 434 Underlying Network is an IP network, the protocol should allow 435 for, but not require the presence of IP multicast services 436 within the data center. 438 10. Flexible mapping sources. It should be possible for either NVEs 439 themselves, or other third party entities (e.g. data center 440 management or orchestration systems) to create inner to outer 441 address mappings in the NVA. The protocol should allow for 442 mappings created by an NVE to be automatically removed from all 443 other NVEs if it fails or is brought down unexpectedly. 445 11. Secure. See the Security Considerations section below. 447 5. Security Considerations 449 Editor's Note: This is an initial start on the security 450 considerations section; it will need to be expanded, and suggestions 451 for material to add are welcome. 453 The protocol(s) should protect the integrity of the mapping against 454 both off-path and on-path attacks. It should authenticate the 455 systems that are creating mappings, and rely on light weight security 456 mechanisms to minimize the impact on scalability and allow for simple 457 configuration. 459 Use of an overlay exposes virtual networks to attacks on the 460 underlying network beyond attacks on the control protocol that is the 461 subject of this draft. In addition to the directly applicable 462 security considerations for the networks involved, the use of an 463 overlay enables attacks on encapsulated virtual networks via the 464 underlying network. Examples of such attacks include traffic 465 injection into a virtual network via injection of encapsulated 466 traffic into the underlying network and modifying underlying network 467 traffic to forward traffic among virtual networks that should have no 468 connectivity. The control protocol should provide functionality to 469 help counter some of these attacks, e.g., distribution of NVE access 470 control lists for each virtual network to enable packets from non- 471 participating NVEs to be discarded, but the primary security measures 472 for the underlying network need to be applied to the underlying 473 network. For example, if the underlying network includes 474 connectivity across the public Internet, use of secure gateways 475 (e.g., based on IPsec [RFC4301]) may be appropriate. 477 The inner to outer address mappings used for forwarding data towards 478 a remote NVE could also be used to filter incoming traffic to ensure 479 the inner address sourced packet came from the correct NVE source 480 address, allowing access control to discard traffic that does not 481 originate from the correct NVE. This destination filtering 482 functionality should be optional to use. 484 6. Acknowledgements 486 Thanks to the following people for reviewing and providing feedback: 487 Fabio Maino, Victor Moreno, Ajit Sanzgiri, Chris Wright. 489 7. Informative References 491 [I-D.ietf-nvo3-framework] 492 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 493 Rekhter, "Framework for DC Network Virtualization", draft- 494 ietf-nvo3-framework-03 (work in progress), July 2013. 496 [I-D.ietf-nvo3-overlay-problem-statement] 497 Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., 498 and M. Napierala, "Problem Statement: Overlays for Network 499 Virtualization", draft-ietf-nvo3-overlay-problem- 500 statement-04 (work in progress), July 2013. 502 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 503 Internet Protocol", RFC 4301, December 2005. 505 Authors' Addresses 507 Lawrence Kreeger 508 Cisco 510 Email: kreeger@cisco.com 512 Dinesh Dutt 513 Cumulus Networks 515 Email: ddutt@cumulusnetworks.com 517 Thomas Narten 518 IBM 520 Email: narten@us.ibm.com 522 David Black 523 EMC 525 Email: david.black@emc.com