idnits 2.17.1 draft-ietf-nvo3-nve-nva-cp-req-02.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 (April 24, 2014) is 3648 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 255, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-01 == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-05 Summary: 1 error (**), 0 flaws (~~), 4 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: October 26, 2014 Cumulus Networks 6 T. Narten 7 IBM 8 D. Black 9 EMC 10 April 24, 2014 12 Network Virtualization NVE to NVA Control Protocol Requirements 13 draft-ietf-nvo3-nve-nva-cp-req-02 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 October 26, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 10 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Informative References . . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 73 A.1. Changes from draft-ietf-nvo3-nve-nva-cp-req-01 to -02 . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 "Problem Statement: Overlays for Network Virtualization" 79 [I-D.ietf-nvo3-overlay-problem-statement] discusses the needs for 80 network virtualization using overlay networks in highly virtualized 81 data centers and provides a general motivation for building such 82 networks. "Framework for DC Network Virtualization" 83 [I-D.ietf-nvo3-framework] provides a framework for discussing overlay 84 networks generally and the various components that must work together 85 in building such systems. "An Architecture for Overlay Networks 86 (NVO3)" [I-D.ietf-nvo3-arch] presents a high-level architecture for 87 building NVO3 Overlay networks. The reader is assumed to be familiar 88 with these documents. 90 Section 4.5 of [I-D.ietf-nvo3-overlay-problem-statement] describes 91 three separate work areas that fall under the general category of a 92 control protocol for NVO3. This document focuses entirely on those 93 aspects of the control protocol related to the building and 94 distributing the mapping tables an NVE uses to tunnel traffic from 95 one VM to another. Specifically, this document focuses on work areas 96 1 and 2 given in Section 4.5 of 98 [I-D.ietf-nvo3-overlay-problem-statement], and discussed in section 8 99 of [I-D.ietf-nvo3-arch]. Work areas 1 and 2 cover the interaction 100 between an NVE and the Network Virtualization Authority (NVA) (work 101 area 2) or operation of the NVA itself (work area 1). Requirements 102 related to interaction between a hypervisor and NVE when the two 103 entities reside on separate physical devices (work area 3) are 104 covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req]. 106 2. Terminology 108 This document uses the same terminology as found in 109 [I-D.ietf-nvo3-framework] and [I-D.ietf-nvo3-arch]. This section 110 defines additional terminology used by this document. 112 Network Service Appliance: A stand-alone physical device or a 113 virtual device that provides a network service, such as a 114 firewall, load balancer, etc. Such appliances may embed Network 115 Virtualization Edge (NVE) functionality within them in order to 116 more efficiently operate as part of a virtualized network. 118 VN Alias: A string name for a VN as used by administrators and 119 customers to name a specific VN. A VN Alias is a human-usable 120 string that can be listed in contracts, customer forms, email, 121 configuration files, etc. and that can be communicated easily 122 vocally (e.g., over the phone). A VN Alias is independent of the 123 underlying technology used to implement a VN and will generally 124 not be carried in protocol fields of control protocols used in 125 virtual networks. Rather, a VN Alias will be mapped into a VN 126 Name where precision is required. 128 VN Name: A globally unique identifier for a VN suitable for use 129 within network protocols. A VN Name will usually be paired with a 130 VN Alias, with the VN Alias used by humans as a shorthand way to 131 name and identify a specific VN. A VN Name should have a compact 132 representation to minimize protocol overhead where a VN Name is 133 carried in a protocol field. Using a Universally Unique 134 Identifier (UUID) as discussed in RFC 4122, may work well because 135 it is both compact and a fixed size and can be generated locally 136 with a very high likelihood of global uniqueness. 138 VN ID: A unique and compact identifier for a VN within the scope of 139 a specific NVO3 administrative domain. It will generally be more 140 efficient to carry VN IDs as fields in control protocols than VN 141 Names or VN Aliases. There is a one-to-one mapping between a VN 142 Name and a VN ID within an NVO3 Administrative Domain. Depending 143 on the technology used to implement an overlay network, the VN ID 144 could be used as the VN Context in the data plane, or would need 145 to be mapped to a locally-significant context ID. 147 3. Control Plane Protocol Functionality 149 The NVO3 problem statement [I-D.ietf-nvo3-overlay-problem-statement], 150 discusses the needs for a control plane protocol (or protocols) to 151 populate each NVE with the state needed to perform its functions. 153 In one common scenario, an NVE provides overlay encapsulation/ 154 decapsulation packet forwarding services to Tenant Systems that are 155 co-resident with the NVE on the same End Device. For example, when 156 the NVE is embedded within a hypervisor or a Network Service 157 Appliance, as depicted in Figure 1 and Figure 2 below. 158 Alternatively, a Tenant System may use an externally connected NVE. 159 For example, an NVE residing on a physical Network Switch connected 160 to the End Device, as depicted in Figure 3 and Figure 4 below. 162 There are two control plane aspects for an NVE. One is the protocol 163 between the NVE and its NVA used to populate the NVE's mapping tables 164 for tunneling traffic across the underlying network. Another is the 165 protocol between an End Device (e.g. Hypervisor) and an external NVE 166 used to promptly update the NVE of Tenant System Interface (TSI) 167 status. This latter control plane aspect is not discussed in this 168 document, but is covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req]. 169 The functional requirements for the NVE to NVA control plane are the 170 same regardless of whether the NVE is embedded within and End Device 171 or in an external device as depicted in Figure 1 through Figure 4 172 below. 174 Hypervisor 175 +-----------------------+ 176 | +--+ +-------+---+ | 177 | |VM|---| | | | 178 | +--+ |Virtual|NVE|----- Underlying 179 | +--+ |Switch | | | Network 180 | |VM|---| | | | 181 | +--+ +-------+---+ | 182 +-----------------------+ 184 Hypervisor with an Embedded NVE. 186 Figure 1 188 Network Service Appliance 189 +---------------------------+ 190 | +------------+ +-----+ | 191 | |Net Service |---| | | 192 | |Instance | | | | 193 | +------------+ | NVE |------ Underlying 194 | +------------+ | | | Network 195 | |Net Service |---| | | 196 | |Instance | | | | 197 | +------------+ +-----+ | 198 +---------------------------+ 200 Network Service Appliance (physical or virtual) with an Embedded NVE. 202 Figure 2 204 Hypervisor Access Switch 205 +------------------+ +-----+-------+ 206 | +--+ +-------+ | | | | 207 | |VM|---| | | VLAN | | | 208 | +--+ |Virtual|---------+ NVE | +--- Underlying 209 | +--+ |Switch | | Trunk | | | Network 210 | |VM|---| | | | | | 211 | +--+ +-------+ | | | | 212 +------------------+ +-----+-------+ 214 Hypervisor with an External NVE. 216 Figure 3 218 Network Service Appliance Access Switch 219 +--------------------------+ +-----+-------+ 220 | +------------+ |\ | | | | 221 | |Net Service |----| \ | | | | 222 | |Instance | | \ | VLAN | | | 223 | +------------+ | |---------+ NVE | +--- Underlying 224 | +------------+ | | | Trunk| | | Network 225 | |Net Service |----| / | | | | 226 | |Instance | | / | | | | 227 | +------------+ |/ | | | | 228 +--------------------------+ +-----+-------+ 230 Physical Network Service Appliance with an External NVE. 232 Figure 4 234 To support an NVE, a control plane protocol is necessary to provide 235 an NVE with the information it needs to maintain its own internal 236 state necessary to carry out its forwarding functions as explained in 237 detail below. 239 1. An NVE maintains a per-VN table of mappings from TSI (inner) 240 addresses to Underlying Network (outer) addresses of remote NVEs. 242 2. An NVE maintains per-VN state for delivering tenant multicast and 243 broadcast packets to other Tenant Systems. Such state could 244 include a list of multicast addresses and/or unicast addresses on 245 the Underlying Network for the NVEs associated with a particular 246 VN. 248 3. End Devices (such as a Hypervisor or Network Service Appliance) 249 utilizing an external NVE need to "attach to" and "detach from" 250 an NVE. Specifically, a mechanism is needed to notify an NVE 251 when a TSI attaches to or detaches from a specific VN. Such a 252 mechanism would provide the necessary information to the NVE that 253 it needs to provide service to a particular TSI. The details of 254 such a mechanism are out-of-scope for this document and are 255 covered in [I-D.kreeger-nvo3-hypervisor-nve-cp-req]. 257 4. An NVE needs a mapping from each unique VN name to the VN Context 258 value used within encapsulated data packets within the 259 administrative domain that the VN is instantiated. 261 The NVE to NVA control protocol operates directly over the underlay 262 network. The NVA is expected to be connected to the same underlay 263 network as the NVEs. 265 Each NVE communicates with only a single logical NVA; However, the 266 NVA can be centralized or distributed between multiple entities for 267 redundancy purposes. When the NVA is made up of multiple entities, 268 better resiliency may be achieved by physically separating them, 269 which may require each entity to be connected to a different IP 270 subnet of the underlay network. For this reason, each NVE should be 271 allowed to be configured with more than one IP addresses for its 272 logical NVA. NVEs should be able to switch between these IP 273 addresses when it detects that the address it is currently using for 274 the NVA is unreachable. How the NVA represents itself externally is 275 discussed in section 7.3 of [I-D.ietf-nvo3-arch]. 277 Note that a single device could contain both NVE and NVA 278 functionality, but the functional interaction between the NVE and NVA 279 within that device should operate similarly to when the NVE and NVA 280 are implemented in separate devices. 282 3.1. Inner to Outer Address Mapping 284 When presented with a data packet to forward to a TSI within a VN, 285 the NVE needs to know the mapping of the TSI destination (inner) 286 address to the (outer) address on the Underlying Network of the 287 remote NVE which can deliver the packet to the destination Tenant 288 System. In addition, the NVE needs to know what VN Context to use 289 when sending to a destination Tenant System. 291 A protocol is needed to provide this inner to outer mapping and VN 292 Context to each NVE that requires it and keep the mapping updated in 293 a timely manner. Timely updates are important for maintaining 294 connectivity between Tenant Systems when one Tenant System is a VM. 296 Note that one technique that could be used to create this mapping 297 without the need for a control protocol is via data plane learning; 298 However, the learning approach requires packets to be flooded to all 299 NVEs participating in the VN when no mapping exists. One goal of 300 using a control protocol is to eliminate this flooding. 302 3.2. Underlying Network Multi-Destination Delivery Address(es) 304 Each NVE needs a way to deliver multi-destination packets (i.e. 305 tenant broadcast/multicast) within a given VN to each remote NVE 306 which has a destination TSI for these packets. Three possible ways 307 of accomplishing this are: 309 o Use the multicast capabilities of the Underlying Network. 311 o Have each NVE replicate the packets and send a copy across the 312 Underlying Network to each remote NVE currently participating in 313 the VN. 315 o Use one or more distribution servers that replicate the packets on 316 the behalf of the NVEs. 318 Whichever method is used, a protocol is needed to provide on a per VN 319 basis, one or more multicast addresses (assuming the Underlying 320 Network supports multicast), and/or one or more unicast addresses of 321 either the remote NVEs which are not multicast reachable, or of one 322 or more distribution servers for the VN. 324 The protocol must also keep the list of addresses up to date in a 325 timely manner as the set of NVEs for a given VN changes over time. 326 For example, the set of NVEs for a VN could change as VMs power on/ 327 off or migrate to different hypervisors. 329 3.3. VN Connect/Disconnect Notification 331 For the purposes of this document, it is assumed that an NVE receives 332 appropriate notifications when a TSI attaches to or detaches from a 333 specific VN. The details of how that is done are orthogonal to the 334 NVE-to-NVA control plane, so long as such notification provides the 335 necessary information needed by the control plane. As one example, 336 the attach/detach notification would presumably include a VN Name 337 that identifies the specific VN to which the attach/detach operation 338 applies to. 340 3.4. VN Name to VN ID Mapping 342 Once an NVE (embedded or external) receives a VN connect indication 343 with a specified VN Name, the NVE must determine what VN Context 344 value and other necessary information to use to forward Tenant System 345 traffic to remote NVEs. In one approach, the NVE-to-NVA protocol 346 uses VN Names directly when interacting, with the NVA providing such 347 information as the VN Context (or VN ID) along with egress NVE's 348 address. Alternatively, it may be desirable for the NVE-to-NVA 349 protocol to use a more compact representation of the VN name, that 350 is, a VN ID. In such a case, a specific NVE-to-NVA operation might 351 be needed to first map the VN Name into a VN ID, with subsequent NVE- 352 to-NVA operations utilizing the VN ID directly. Thus, it may be 353 useful for the NVE-to-NVA protocol to support an operation that maps 354 VN Names into VN IDs. 356 4. Control Plane Characteristics 358 NVEs are expected to be implemented within both hypervisors (or 359 Network Service Appliances) and within access switches. Any 360 resources used by these protocols (e.g. processing or memory) takes 361 away resources that could be better used by these devices to perform 362 their intended functions (e.g. providing resources for hosted VMs). 364 A large scale data center may contain hundreds of thousands of these 365 NVEs (which may be several independent implementations); Therefore, 366 any savings in per-NVE resources can be multiplied hundreds of 367 thousands of times. 369 Given this, the control plane protocol(s) implemented by NVEs to 370 provide the functionality discussed above should have the below 371 characteristics. 373 1. Minimize the amount of state needed to be stored on each NVE. 374 The NVE should only be required to cache state that it is 375 actively using, and be able to discard any cached state when it 376 is no longer required. For example, an NVE should only need to 377 maintain an inner-to-outer address mapping for destinations to 378 which it is actively sending traffic as opposed to maintaining 379 mappings for all possible destinations. 381 2. Fast acquisition of needed state. For example, when a TSI emits 382 a packet destined to an inner address that the NVE does not have 383 a mapping for, the NVE should be able to acquire the needed 384 mapping quickly. 386 3. Fast detection/update of stale cached state information. This 387 only applies if the cached state is actually being used. For 388 example, when a VM moves such that it is connected to a 389 different NVE, the inner to outer mapping for this VM's address 390 that is cached on other NVEs must be updated in a timely manner 391 (if they are actively in use). If the update is not timely, the 392 NVEs will forward data to the wrong NVE until it is updated. 394 4. Minimize processing overhead. This means that an NVE should 395 only be required to perform protocol processing directly related 396 to maintaining state for the TSIs it is actively communicating 397 with. For example, if the NVA provides unsolicited information 398 to the NVEs, then one way to minimize the processing on the NVE 399 is for it to subscribe for getting these mappings on a per VN 400 basis. Consequently an NVE is not required to maintain state 401 for all VNs within a domain. An NVE only needs to maintain 402 state (or participate in protocol exchanges) about the VNs it is 403 currently attached to. If the NVE obtains mappings on demand 404 from the NVA, then it only needs to obtain the information 405 relevant to the traffic flows that are currently active. This 406 requirement is for the NVE functionality only. The network node 407 that contains the NVE may be involved in other functionality for 408 the underlying network that maintains connectivity that the NVE 409 is not actively using (e.g., routing and multicast distribution 410 protocols for the underlying network). 412 5. Highly scalable. This means scaling to hundreds of thousands of 413 NVEs and several million VNs within a single administrative 414 domain. As the number of NVEs and/or VNs within a data center 415 grows, the protocol overhead at any one NVE should not increase 416 significantly. 418 6. Minimize the complexity of the implementation. This argues for 419 using the least number of protocols to achieve all the 420 functionality listed above. Ideally a single protocol should be 421 able to be used. The less complex the protocol is on the NVE, 422 the more likely interoperable implementations will be created in 423 a timely manner. 425 7. Extensible. The protocol should easily accommodate extension to 426 meet related future requirements. For example, access control 427 or QoS policies, or new address families for either inner or 428 outer addresses should be easy to add while maintaining 429 interoperability with NVEs running older versions. 431 8. Simple protocol configuration. A minimal amount of 432 configuration should be required for a new NVE to be 433 provisioned. Existing NVEs should not require any configuration 434 changes when a new NVE is provisioned. Ideally NVEs should be 435 able to auto configure themselves. 437 9. Do not rely on IP Multicast in the Underlying Network. Many 438 data centers do not have IP multicast routing enabled. If the 439 Underlying Network is an IP network, the protocol should allow 440 for, but not require the presence of IP multicast services 441 within the data center. 443 10. Flexible mapping sources. It should be possible for either NVEs 444 themselves, or other third party entities (e.g. data center 445 management or orchestration systems) to create inner to outer 446 address mappings in the NVA. The protocol should allow for 447 mappings created by an NVE to be automatically removed from all 448 other NVEs if it fails or is brought down unexpectedly. 450 11. Secure. See the Security Considerations section below. 452 5. Security Considerations 454 Editor's Note: This is an initial start on the security 455 considerations section; it will need to be expanded, and suggestions 456 for material to add are welcome. 458 The protocol(s) should protect the integrity of the mapping against 459 both off-path and on-path attacks. It should authenticate the 460 systems that are creating mappings, and rely on light weight security 461 mechanisms to minimize the impact on scalability and allow for simple 462 configuration. 464 Use of an overlay exposes virtual networks to attacks on the 465 underlying network beyond attacks on the control protocol that is the 466 subject of this draft. In addition to the directly applicable 467 security considerations for the networks involved, the use of an 468 overlay enables attacks on encapsulated virtual networks via the 469 underlying network. Examples of such attacks include traffic 470 injection into a virtual network via injection of encapsulated 471 traffic into the underlying network and modifying underlying network 472 traffic to forward traffic among virtual networks that should have no 473 connectivity. The control protocol should provide functionality to 474 help counter some of these attacks, e.g., distribution of NVE access 475 control lists for each virtual network to enable packets from non- 476 participating NVEs to be discarded, but the primary security measures 477 for the underlying network need to be applied to the underlying 478 network. For example, if the underlying network includes 479 connectivity across the public Internet, use of secure gateways 480 (e.g., based on IPsec [RFC4301]) may be appropriate. 482 The inner to outer address mappings used for forwarding data towards 483 a remote NVE could also be used to filter incoming traffic to ensure 484 the inner address sourced packet came from the correct NVE source 485 address, allowing access control to discard traffic that does not 486 originate from the correct NVE. This destination filtering 487 functionality should be optional to use. 489 6. Acknowledgements 491 Thanks to the following people for reviewing and providing feedback: 492 Fabio Maino, Victor Moreno, Ajit Sanzgiri, Chris Wright. 494 7. Informative References 496 [I-D.ietf-nvo3-arch] 497 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 498 Narten, "An Architecture for Overlay Networks (NVO3)", 499 draft-ietf-nvo3-arch-01 (work in progress), February 2014. 501 [I-D.ietf-nvo3-framework] 502 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 503 Rekhter, "Framework for DC Network Virtualization", draft- 504 ietf-nvo3-framework-05 (work in progress), January 2014. 506 [I-D.ietf-nvo3-overlay-problem-statement] 507 Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., 508 and M. Napierala, "Problem Statement: Overlays for Network 509 Virtualization", draft-ietf-nvo3-overlay-problem- 510 statement-04 (work in progress), July 2013. 512 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 513 Internet Protocol", RFC 4301, December 2005. 515 Appendix A. Change Log 516 A.1. Changes from draft-ietf-nvo3-nve-nva-cp-req-01 to -02 518 1. Added references to the architecture document 519 [I-D.ietf-nvo3-arch]. 521 2. Terminology: Usage of "TSI" in several places. 523 Authors' Addresses 525 Lawrence Kreeger 526 Cisco 528 Email: kreeger@cisco.com 530 Dinesh Dutt 531 Cumulus Networks 533 Email: ddutt@cumulusnetworks.com 535 Thomas Narten 536 IBM 538 Email: narten@us.ibm.com 540 David Black 541 EMC 543 Email: david.black@emc.com