idnits 2.17.1 draft-yong-nvo3-frwk-dpreq-addition-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 abstract seems to contain references ([DPREQ], [NVO3FRWK]), 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 date (December 11, 2012) is 4155 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-01 == Outdated reference: A later version (-04) exists of draft-ietf-nvo3-overlay-problem-statement-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group L. Yong 2 Internet Draft L. Dunbar 3 Category: Informational Huawei 5 Expires: March 2013 December 11, 2012 7 NVO3 Framework and Data Plane Requirement Addition 8 draft-yong-nvo3-frwk-dpreq-addition-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 11, 2013. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. 45 Abstract 47 This document describes some additional functions and requirements 48 for NVO3 framework [NVO3FRWK] and data plane requirements [DPREQ]. 49 These additions are necessary in supporting VM communication and 50 mobility. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [RFC2119]. 58 Table of Contents 60 1. Introduction...................................................3 61 2. New NVE Service Type...........................................3 62 2.1. Why a New NVE Service Type................................3 63 2.2. L2-3 NVE Providing IP Routing/Bridging-like Service 64 (Framework Addition)...........................................4 65 2.3. L2-3 VNI (Data Plane Requirement Addition)................4 66 3. Tenant System Mobility.........................................5 67 3.1. Background................................................5 68 3.2. NVE Functions for TS Mobility (Framework Addition)........6 69 3.2.1. Tenant System Mobility...............................6 70 3.2.2. Tenant Multicast Traffic.............................6 71 3.2.3. The Policy Associated With TS........................7 72 3.3. Tenant System Mobility (Data Plane Requirement Addition)..7 73 4. Security Considerations........................................8 74 5. IANA Considerations............................................8 75 6. Acknowledgements...............................................8 76 7. References.....................................................8 77 7.1. Normative References......................................8 78 7.2. Informative References....................................8 80 1. Introduction 82 NVO3 framework [NVO3FRWK] and data plane requirement [DPREQ] 83 documents specify the network virtualization overlay framework and 84 data plane requirements, which aims on an architecture to support 85 the network virtualization overlay in DC [NVO3PRBM]. The main 86 application of NVO3 is to support multi-tenant networks on a common 87 infrastructure, where a tenant virtual network may contain one or 88 more subnets [HYPERV]. However, current framework specifies two NVE 89 service types. Neither of them naturally supports the communication 90 among the VMs when some VMs are on the same subnet and other on 91 different. Second, one of the key aspects of NVO3 is to support the 92 virtual machines (VM) mobility. However, neither document mentions 93 VM mobility nor specifies any function and/or requirements in 94 supporting VM mobility. This document addresses the two additions. 96 To use the terminologies specified in the framework document, this 97 document refers VM mobility as to Tenant System mobility or TS 98 mobility. 100 2. New NVE Service Type 102 2.1. Why a New NVE Service Type 104 A virtual machine on a server behaves like a physical server to an 105 application or guest OS on it. This means that any frame from/to a 106 virtual machine is an Ethernet frame, just as a frame from/to a 107 physical server. 109 L2 NVE service type specified in the framework [NVO3FRWK] provides 110 Ethernet LAN like service where multiple Tenant Systems appear to 111 interconnected by an LAN environment over a set of L3 tunnels. 112 However, from the host (physical servers or VMs) perspective, only 113 the hosts on the same subnet can communicate in an LAN network. This 114 implies that L2 NVE service type only applies to a single subnet. 116 L3 NVE service type [NVO3FRWK] provides a virtualized IP routing and 117 forwarding like IETF IP VPN. The IP VPN emulates a route domain and 118 provides forwarding and routing among TSes that are the same and/or 119 different subnets. IETF IP VPN has the assumption that the Layer 3 120 MUST be implemented between a PE and a CE, which means between an 121 NVE and a TS in this context. This assumption does not fit to the 122 case where an NVE attached by the multiple TSes that are on the same 123 subnet where the TSes uses bridging mechanism for the communication. 125 To support TSes, regardless on the same or different subnets, 126 communicating in an L2 environment, this document suggests adding a 127 new L2-3 NVE Service Type. Suggested Text for the framework and data 128 plane requirement documents is in section 2.2 and section 2.3, 129 respectively. 131 2.2. L2-3 NVE Providing IP Routing/Bridging-like Service (Framework 132 Addition) 134 L2-3 NVE is similar to IRB function on a router [CIRB] device today. 135 It supports the TSes attached to the NVE (locally or remotely) to 136 communicate with each other when they are in a same route domain, 137 i.e. a tenant virtual network. The NVE provides per tenant virtual 138 switching and routing instance with address isolation and L3 tunnel 139 encapsulation across the core. The L2-3 NVE supports the bridging 140 among TSes that are on the same subnet and the routing among TSes 141 that are on the different subnets. 143 2.3. L2-3 VNI (Data Plane Requirement Addition) 145 L2-3 VNIs MUST provide virtualized IP routing and bridging. L2-3 VNI 146 MUST support per-tenant forwarding instance with IP and MAC address 147 isolation and L3 tunneling for interconnecting instances of the same 148 VNI on NVEs. L2-3 VNI MUST perform the virtual bridging for the 149 Tenant Systems that are on the same subnet and the IP routing for 150 the Tenant Systems that are on the different subnets. L2-3 VNI MUST 151 support L2/3 gateway function. 153 L2-3 VNI MUST NOT change Tenant System communication mechanism in a 154 route domain, i.e. a tenant virtual network, and not violate Tenant 155 Systems communication rules. Tenant System communication rules are 156 if Tenant Systems are on the same subnet, they are bridged directly; 157 if Tenant Systems are on different subnets, they MUST communicate 158 through a router. A tenant system uses the ARP/ND protocol to 159 discover other tenant system MAC addresses if they are on the same 160 subnet; a tenant system sends a packet to a known gateway if the 161 destination of the packet is on different subnet from the sender TS; 162 a tenant system uses ARP/ND protocol to find the gateway MAC address. 164 Forwarding table entries provide mapping information between MAC/IP 165 and L3 Tunnel destination addresses. Such entries MAY be populated 166 by a control or management plane. 168 The L2-3 VNI MUST support the ARP protocol at virtual access points 169 (VAPs) and a default VGW MAC address. 171 In the case of L2-3 VNI, when the packet is forwarded from one 172 subnet to another subnet, inner TTL field and outer TTL field 173 process MUST be the same as described in L3 VNI section. 175 When tenant multicast is supported, L2-3 VNI SHOULD also be possible 176 to select whether the NVE provides optimized multicast trees inside 177 the VNI for individual tenant multicast groups or whether the 178 default VNI multicast tree is used, where all the NVEs of the 179 corresponding VNI are members, is used. 181 3. Tenant System Mobility 183 3.1. Background 185 NVO3 generic reference model specifies that a Tenant System can be 186 attached to an NVE locally or remotely. The local means that a TS 187 and the NVE are resident in the same device, e.g. server. The remote 188 means a TS attached to the NVE via a point-to-point connection or a 189 switched network, e.g. Ethernet. 191 When an NVE is local, the state of Tenant System can be provided 192 without protocol assistance. This implies that when Tenant System 193 state changes, the NVE is immediately aware of the changes. When an 194 NVE is remote, the state of the Tenant System needs to be exchanged 195 via a data or control plane protocol, or via a management entity. 197 VM mobility further requires support of hot and cold move [VMMOVE]. 198 In the hot move, the moving is seamless to the application that runs 199 on the moved TS, which implies that the existing connectivity 200 between the moved TS and other TSes that the moved TS communicates 201 with MUST be maintained while the TS is moved regardless if these 202 TSes are on the same or different subnets. 204 When a TS and NVE are resident in the same device, the TS moves from 205 one NVE, NVE1 to another NVE, NVE2. NVE2 instantly knows the TS 206 address, state, and etc. However other NVEs that other TSes attach 207 to and have the connectivity with the moved TS MUST be also aware of 208 the TS new location, i.e. NVE2 location, and NVE2 MUST be also aware 209 of these NVE locations in order to maintain the connectivity. 211 When a TS and NVE are remotely attached, TS moving only applies when 212 a TS attaches to the NVE via a switched network, i.e. L2 physical 213 and/or virtual network.[VMMOVE] In addition of the actions in the 214 local NVE case (mentioned above), when an NVE is remote, the state 215 of the Tenant System needs to be exchanged via a data or control 216 plane protocol, or via a management entity. 218 Other two cases are a TS moved away from a local NVE and to a remote 219 NVE and vise versa. 221 To support TS mobility, this document suggests adding a new section 222 in the NVO3 framework and data plane requirement documents and the 223 suggested text is in section 3.2 and 3.3, respectively. 225 3.2. NVE Functions for TS Mobility (Framework Addition) 227 3.2.1. Tenant System Mobility 229 If an NVE (say ingress NVE) is responsible to notify other NVEs 230 (egress NVEs) regarding a new moved TS attaching to it. If the 231 ingress NVE is not yet on the tenant virtual network that the moved 232 TS belongs to, the NVE MUST establish the membership to the virtual 233 network first and create a virtual access point (VAP) to associate 234 to the virtual network. The NVE MUST send a notification about the 235 TS to other egress NVEs that has the same membership. This can be 236 done via data plane or control plane. Upon receiving the 237 notification from an ingress NVE, an egress NVE has to update its 238 VNIs that are associate to the same membership. If an NVE is remote, 239 the VNI MUST send the new TS address notification to the access 240 networks via the virtual access points (VAPs). 242 Note that if the ingress NVE is L2-3 NVE, and if it is not yet on 243 the same tenant virtual network subnet as the moved TS belongs to, 244 the NVE MUST establish the membership to the virtual subnet network 245 first and create a VAP to associate with it. The NVE MUST send a 246 notification about the TS to other egress NVEs that has the same 247 membership. If an NVE is remote, they MUST only send the 248 notification to the access networks that are on the same tenant 249 virtual subnet as the moved TS is on. 251 Note that, when a TS moves away from an NVE and it is the last TS 252 attached to the NVE belong to the tenant virtual network, the NVE 253 MAY delete the membership of the tenant virtual network. 255 3.2.2. Tenant Multicast Traffic 257 If a tenant application on a set of TSes needs to send broadcast or 258 multicast traffic among them, the NVE multicast and broadcast 259 capability can facilitate such forwarding [NVO3FRWK]. To support VM 260 mobility, when one of the TSes is moved from one NVE (say NVE1) to 261 another (say NVE2)in hot mode, the NVE2 has to know which multicast 262 groups that the TS is associated with. If NVE2 is local, such 263 information can be available to the NVE2 via some API; if NVE2 is 264 remote, such information can be available to the NVE2 via data plane, 265 control plane, or management entity [NVO3FRWK]. If NVE2 is need to 266 learn Tenant Multicast Groups that a moved TS is on, the NVEs MUST 267 be able to send a query message to the moved TS; The TS response 268 which groups it is on. 270 Once NVE2 knows which multicast groups that the new attached TS is 271 associated with, NVE2 MUST bind itself to these multicast groups if 272 it is not on yet. Furthermore, NVE2 MAY (if not yet) have to bind 273 the overlay multicast groups to one or more underlying multicast 274 tree if it uses the underlay multicast trees to delivery overlay 275 multicast traffic. An NVE MUST provide these capabilities, if it 276 supports tenant multicast traffic, to ensure tenant application 277 seamlessly running while a Tenant System is moved. 279 Similarly, when NVE1 knows a TS moved away and being the last one on 280 the tenant virtual network, NVE1 MAY unbind itself to the 281 corresponding multicast group. Furthermore, if this is the last 282 multicast group on the NVE1, NVE1 MAY unbind the multicast group to 283 the shared multicast tree if used. 285 3.2.3. The Policy Associated With TS 287 An NVE provides the policy based forwarding and routing [NVO3FRWK] 288 [DPREQ]. When a TS is moved from one NVE (say NVE1) to another (say 289 NVE2), the NVE2 has to apply to the same set of policy to the TS as 290 well. If TS related policies are specified in the TS service profile 291 that is moved along with the TS, and the file can be passed to the 292 NVE2 via API if the TS is locally attached to or via a data plane or 293 control plane protocol, or a management entity if remotely attached 294 to. An NVE MUST be able to automatically install these policies at 295 the VAP that a new TS attaches to. NVE1 MUST automatically delete 296 the policies that are applied to the moved TS only. 298 3.3. Tenant System Mobility (Data Plane Requirement Addition) 300 If the data plane learning is used to populate the forwarding 301 table[DPREQ], an NVE (local or remote) MUST be able to send a 302 notification message to all the NVEs that are the membership of the 303 tenant virtual network that the TS belongs to, e.g. ARP gratuitous 304 message. The notification MUST contain the TS address and tenant VN 305 ID. Upon receiving the notification message, an NVE MUST update the 306 corresponding VNI indicated in the NVO3 overlay header. If the 307 receiving NVE is remote, the NVE MUST send a notification to the 308 local access networks that is on the same subnet as of one indicated 309 in the NVO3 overlay header via the VAPs. 311 4. Security Considerations 313 When a Tenant System is moved from one NVE to another, automatic 314 virtual network membership creation on an NVE may leave some 315 security concern. Either certain authentication is needed for an NVE 316 to accept a new TS or management entity assisted process is used to 317 ensure the security. 319 Supporting TS mobility brings a new challenge for NVO3 is discussed 320 in [NVO3PRBM]. 322 5. IANA Considerations 324 The document does not require any IANA action. 326 6. Acknowledgements 328 Thank Weiguo Hao for the review and input to the draft. 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC2119, March 1997. 337 7.2. Informative References 339 [DPREQ] Bitar, N., and etc, "NVO3 Data Plane Requirement", draft-bl- 340 nvo3-dataplane-requirements-03.txt, November 2012 342 [CIRB] Cisco, "Understanding and Configurating VLAN Routing and 343 Bridging on a Router Using the IRB Feature", Doc. ID 17054 345 [HYPERV] Microsoft, "Hyper-V Network Virtualization Packet Flow", 346 September 2012 348 [NVO3FRWK] LASSERRE, M., Motin, T., and etc, "Framework for DC 349 Network Virtualization", draft-ietf-nvo3-framework-01, 350 October 2012 352 [NVO3PRBM] Narten, T., and etc "Problem Statement: Overlays for 353 Network Virtualization", draft-ietf-nvo3-overlay-problem- 354 statement-01, October 2012 356 [VMMOVE] Rakhter, Y., and etc, "Network-related VM Mobility Issue", 357 draft-rekhter-nvo3-vm-mobility-issues-03.txt, Sept. 2012 359 Authors' Addresses 361 Lucy Yong 362 Huawei USA 363 5340 Legacy Drive 364 Plano, TX 75025 365 U.S.A 367 Phone: 469-277-5837 368 Email: lucy.yong@huawei.com 370 Linda Dunbar 371 Huawei USA 372 5340 Legacy Drive 373 Plano, TX 75025 374 U.S.A 376 Phone: 469-277-5840 377 Email: linda.dunbar@huawei.com