idnits 2.17.1 draft-chen-nvo3-gap-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Informational T. Tsou 5 Expires: August 22, 2013 Huawei Technologies (USA) 6 E. Roch 7 Huawei Technologies 8 February 18, 2013 10 NVO3 Requirements Versus Available Protocol Capabilities 11 draft-chen-nvo3-gap-analysis-00 13 Abstract 15 This document matches candidate protocols against the NVO3 16 requirements. Based on the results, gaps are identified and further 17 protocol work is recommended. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 22, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Management Requirements . . . . . . . . . . . . . . . . . . . 4 57 3. Control Plane Requirements . . . . . . . . . . . . . . . . . . 4 58 4. Data Plane Requirements . . . . . . . . . . . . . . . . . . . 4 59 5. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 10 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 The charter of the NVO3 Working Group requires it to identify any 71 gaps between the requirements it has identified and the available 72 protocol solutions as a prerequisite to rechartering or concluding 73 the Working Group if no gaps exist. The present document is intended 74 to provide the required analysis. It provides a tabulation of the 75 candidate protocols' ability to satisfy each requirement identified 76 by the Working Group. Areas where further work is required to ensure 77 that the requirements are met are identified. 79 Since the Working Group has yet to adopt documents describing 80 requirements for the management and control planes, they are absent 81 from the present version of this document. The data plane 82 requirements are taken from [I_D.dataplane_requirements]. The 83 initial candidate protocols are NVGRE [I_D.NVGRE], VxLAN [I_D.VxLAN], 84 L2VPN [reference?], and L3VPN [reference?]. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 1.2. Abbreviations 94 This document uses the following abbreviations: 96 NVO3: Network virtualization overlays 98 L2VPN Layer 2 virtual private network 100 L3VPN Layer 3 virtual private network 102 NVE: Network virtualization edge 104 VAP: Virtual access point 106 VNI: Virtual network instance 108 LAG: Link aggregation group 110 ECMP: Equal cost multi-path 112 DSCP: Differentiated services code point 113 ECN: Explicit congestion notification [RFC3168] 115 2. Management Requirements 117 To come. 119 3. Control Plane Requirements 121 To come. 123 4. Data Plane Requirements 125 In this section, the numbering of requirement headings is taken from 126 the corresponding section numbers in [I_D.dataplane_requirements]. 128 3.1. Virtual Access Points (VAPs) 130 +-------------------------------+--------+--------+--------+--------+ 131 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 132 +-------------------------------+--------+--------+--------+--------+ 133 | MUST support VAP | | | | | 134 | identification | | | | | 135 | - | - | - | - | - | 136 | 1) Local interface | YES | | | | 137 | - | - | - | - | - | 138 | 2) Local interface + fields | YES | | | | 139 | in frame header | | | | | 140 +-------------------------------+--------+--------+--------+--------+ 142 Table 1: VAP Identification Requirements 144 3.2. Virtual Network Instance (VNI) 146 +-------------------------------+--------+--------+--------+--------+ 147 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 148 +-------------------------------+--------+--------+--------+--------+ 149 | VAP are associated with a | YES | | | | 150 | specific VNI at service | | | | | 151 | instantiation time. | | | | | 152 +-------------------------------+--------+--------+--------+--------+ 154 Table 2: VAP-VNI Association 156 3.2.1. L2 VNI 157 +-------------------------------+--------+--------+--------+--------+ 158 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 159 +-------------------------------+--------+--------+--------+--------+ 160 | L2 VNI MUST provide an | NO | | | | 161 | emulated Ethernet multipoint | | | | | 162 | service as if Tenant Systems | | | | | 163 | are interconnected by a | | | | | 164 | bridge (but instead by using | | | | | 165 | a set of NVO3 tunnels). | | | | | 166 | - | - | - | - | - | 167 | Loop avoidance capability | | | | | 168 | MUST be provided. | | | | | 169 | - | - | - | - | - | 170 | In the absence of a | | | | | 171 | management or control plane, | | | | | 172 | data plane learning MUST be | | | | | 173 | used to populate forwarding | | | | | 174 | tables. | | | | | 175 | - | - | - | - | - | 176 | When flooding is required, | | | | | 177 | either to deliver unknown | | | | | 178 | unicast, or broadcast or | | | | | 179 | multicast traffic, the NVE | | | | | 180 | MUST either support ingress | | | | | 181 | replication or multicast. | | | | | 182 | - | - | - | - | - | 183 | In this latter case, the NVE | | | | | 184 | MUST be able to build at | | | | | 185 | least a default flooding tree | | | | | 186 | per VNI. | | | | | 187 +-------------------------------+--------+--------+--------+--------+ 189 Table 3: L2 VNI Service 191 3.2.2. L3 VNI 193 +-------------------------------+--------+--------+--------+--------+ 194 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 195 +-------------------------------+--------+--------+--------+--------+ 196 | L3 VNIs MUST provide | YES | | | | 197 | virtualized IP routing and | | | | | 198 | forwarding. | | | | | 199 | - | - | - | - | - | 200 | L3 VNIs MUST support | YES | | | | 201 | per-tenant forwarding | | | | | 202 | instance with IP addressing | | | | | 203 | isolation and L3 tunneling | | | | | 204 | for interconnecting instances | | | | | 205 | of the same VNI on NVEs. | | | | | 206 +-------------------------------+--------+--------+--------+--------+ 208 Table 4: L3 VNI Service 210 3.3.1. NVO3 overlay header 212 +-------------------------------+--------+--------+--------+--------+ 213 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 214 +-------------------------------+--------+--------+--------+--------+ 215 | An NVO3 overlay header MUST | YES | | | | 216 | be included after the | | | | | 217 | underlay tunnel header when | | | | | 218 | forwarding tenant traffic. | | | | | 219 +-------------------------------+--------+--------+--------+--------+ 221 Table 5: Overlay Header 223 3.3.1.1. Virtual Network Context Identification 225 +-------------------------------+--------+--------+--------+--------+ 226 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 227 +-------------------------------+--------+--------+--------+--------+ 228 | The overlay encapsulation | YES | | | | 229 | header MUST contain a field | | | | | 230 | which allows the encapsulated | | | | | 231 | frame to be delivered to the | | | | | 232 | appropriate virtual network | | | | | 233 | endpoint by the egress NVE. | | | | | 234 +-------------------------------+--------+--------+--------+--------+ 236 Table 6: Virtual Network Context Identification 238 3.3.1.2. Service QoS identifier 239 +-------------------------------+--------+--------+--------+--------+ 240 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 241 +-------------------------------+--------+--------+--------+--------+ 242 | Traffic flows originating | NO | | | | 243 | from different applications | | | | | 244 | could rely on differentiated | | | | | 245 | forwarding treatment to meet | | | | | 246 | end-to-end availability and | | | | | 247 | performance objectives. | | | | | 248 +-------------------------------+--------+--------+--------+--------+ 250 Table 7: QoS Service Identification 252 3.3.2.1. LAG and ECMP 254 +-------------------------------+--------+--------+--------+--------+ 255 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 256 +-------------------------------+--------+--------+--------+--------+ 257 | For performance reasons, | YES | | | | 258 | multipath over LAG and ECMP | | | | | 259 | paths SHOULD be supported. | | | | | 260 +-------------------------------+--------+--------+--------+--------+ 262 Table 8: Multipath Support 264 3.3.2.2. DiffServ and ECN marking 266 +-------------------------------+--------+--------+--------+--------+ 267 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 268 +-------------------------------+--------+--------+--------+--------+ 269 | [RFC2983] defines two modes | NO | | | | 270 | for mapping the DSCP markings | | | | | 271 | from inner to outer headers | | | | | 272 | and vice versa. Both models | | | | | 273 | SHOULD be supported. | | | | | 274 | - | - | - | - | - | 275 | ECN marking MUST be performed | NO | | | | 276 | according to [RFC6040] which | | | | | 277 | describes the correct ECN | | | | | 278 | behavior for IP tunnels. | | | | | 279 +-------------------------------+--------+--------+--------+--------+ 281 Table 9: DSCP and ECN Marking 283 3.3.2.3. Handling of broadcast, unknown unicast, and multicast 284 traffic 285 +-------------------------------+--------+--------+--------+--------+ 286 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 287 +-------------------------------+--------+--------+--------+--------+ 288 | NVO3 data plane support for | YES | | | | 289 | either ingress replication or | | | | | 290 | point-to- multipoint tunnels | | | | | 291 | is required to send traffic | | | | | 292 | destined to multiple | | | | | 293 | locations on a per-VNI basis | | | | | 294 | (e.g. L2/L3 multicast | | | | | 295 | traffic, L2 broadcast and | | | | | 296 | unknown unicast traffic). | | | | | 297 +-------------------------------+--------+--------+--------+--------+ 299 Table 10: Handling of Broadcast, Unknown Unicast, and Multicast 300 Traffic 302 3.4. External NVO3 connectivity 304 +-------------------------------+--------+--------+--------+--------+ 305 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 306 +-------------------------------+--------+--------+--------+--------+ 307 | NVO3 services MUST | YES | | | | 308 | interoperate with current VPN | | | | | 309 | and Internet services. This | | | | | 310 | may happen inside one DC | | | | | 311 | during a migration phase or | | | | | 312 | as NVO3 services are | | | | | 313 | delivered to the outside | | | | | 314 | world via Internet or VPN | | | | | 315 | gateways. | | | | | 316 +-------------------------------+--------+--------+--------+--------+ 318 Table 11: Interoperation 320 3.5. Path MTU 322 +-------------------------------+--------+--------+--------+--------+ 323 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 324 +-------------------------------+--------+--------+--------+--------+ 325 | Classical ICMP-based MTU Path | NO | | | | 326 | Discovery ([RFC1191], | | | | | 327 | [RFC1981]) or Extended MTU | | | | | 328 | Path Discovery techniques | | | | | 329 | such as defined in [RFC4821]. | | | | | 330 | - | - | - | - | - | 331 | Segmentation and reassembly | YES | | | | 332 | support from the overlay | | | | | 333 | layer operations without | | | | | 334 | relying on the Tenant Systems | | | | | 335 | to know about the end-to-end | | | | | 336 | MTU. | | | | | 337 +-------------------------------+--------+--------+--------+--------+ 339 Table 12: Path MTU 341 3.7. NVE Multi-Homing Requirements 343 +-------------------------------+--------+--------+--------+--------+ 344 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 345 +-------------------------------+--------+--------+--------+--------+ 346 | Multi-homing techniques | NO | | | | 347 | SHOULD be used to increase | | | | | 348 | the reliability of an NVO3 | | | | | 349 | network. | | | | | 350 +-------------------------------+--------+--------+--------+--------+ 352 Table 13: Multihoming 354 3.8. OAM 356 +-------------------------------+--------+--------+--------+--------+ 357 | Requirement | NVGRE | VxLAN | L2VPN | L3VPN | 358 +-------------------------------+--------+--------+--------+--------+ 359 | NVE MAY be able to | NO | | | | 360 | originate/terminate OAM | | | | | 361 | messages for connectivity | | | | | 362 | verification, performance | | | | | 363 | monitoring, statistic | | | | | 364 | gathering and fault | | | | | 365 | isolation. Depending on | | | | | 366 | configuration, NVEs SHOULD be | | | | | 367 | able to process or | | | | | 368 | transparently tunnel OAM | | | | | 369 | messages, as well as | | | | | 370 | supporting alarm propagation | | | | | 371 | capabilities. | | | | | 372 +-------------------------------+--------+--------+--------+--------+ 374 Table 14: OAM Messaging 376 5. Summary and Conclusions 378 To come. 380 6. Acknowledgements 382 Peter Ashwood-Smith and Rangaraju Iyengar are acknowledged for their 383 technical contributions to this document. Tom Taylor served as 384 XML2RFC guru to produce it. 386 7. IANA Considerations 388 This memo includes no request to IANA. 390 8. Security Considerations 392 All drafts are required to have a security considerations section. 394 9. References 396 9.1. Normative References 398 [I_D.NVGRE] 399 Sridharan, M., Greenberg, A., Venkataramiah, N., Wang, Y., 400 Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., and 401 C. Tumuluri, "NVGRE: Network Virtualization using Generic 402 Routing Encapsulation (Work in progress)", July 2012. 404 [I_D.VxLAN] 405 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 406 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 407 Framework for Overlaying Virtualized Layer 2 Networks over 408 Layer 3 Networks (Work in progress)", August 2012. 410 [I_D.dataplane_requirements] 411 Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., 412 and B. Khasnabish, "NVO3 Data Plane Requirements (Work in 413 progress)", December 2012. 415 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 416 November 1990. 418 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 419 for IP version 6", RFC 1981, August 1996. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC2983] Black, D., "Differentiated Services and Tunnels", 425 RFC 2983, October 2000. 427 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 428 Discovery", RFC 4821, March 2007. 430 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 431 Notification", RFC 6040, November 2010. 433 9.2. Informative References 435 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 436 of Explicit Congestion Notification (ECN) to IP", 437 RFC 3168, September 2001. 439 Authors' Addresses 441 Xiaoming Chen 442 Huawei Technologies 444 Phone: 445 Email: ming.chen@huawei.com 447 Tina Tsou 448 Huawei Technologies (USA) 449 2330 Central Expressway 450 Santa Clara, CA 95050 451 USA 453 Phone: +1 408 330 4424 454 Email: Tina.Tsou.Zouting@huawei.com 455 URI: http://tinatsou.weebly.com/contact.html 456 Evelyne Roch 457 Huawei Technologies 458 303 Terry Fox Drive, Suite 400 459 Kanata, Ontario K2K 3J1 460 Canada 462 Phone: +1 613 595 1900 x1612 463 Email: evelyne.roch@huawei.com