idnits 2.17.1 draft-gbclt-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6074' is defined on line 768, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ashwood-nvo3-operational-requirement-02 == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-03 == Outdated reference: A later version (-03) exists of draft-ietf-nvo3-dataplane-requirements-01 == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-03 == Outdated reference: A later version (-04) exists of draft-ietf-nvo3-overlay-problem-statement-03 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-04 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-02 ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Gray, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational N. Bitar 5 Expires: January 16, 2014 Verizon 6 X. Chen 7 Huawei Technologies 8 M. Lasserre 9 Alcatel-Lucent 10 T. Tsou 11 Huawei Technologies (USA) 12 July 15, 2013 14 NVO3 Gap Analysis - Requirements Versus Available Technology Choices 15 draft-gbclt-nvo3-gap-analysis-00 17 Abstract 19 This document evaluates candidate protocols against the NVO3 20 requirements. Gaps are identified and further work recommended. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 16, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.3. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 61 3. Operational Requirements . . . . . . . . . . . . . . . . . . 4 62 4. Management Requirements . . . . . . . . . . . . . . . . . . . 4 63 5. Control Plane Requirements . . . . . . . . . . . . . . . . . 4 64 5.1. Overall Control-Plane Requirements . . . . . . . . . . . 5 65 5.2. VM-to-NVE Specific Control-Plane Requirements . . . . . . 7 66 6. Data Plane Requirements . . . . . . . . . . . . . . . . . . . 9 67 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 14 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 11.2. Informative References . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 The initial charter of the NVO3 Working Group requires it to identify 79 any gaps between the requirements identified and available 80 technoloogy solutions as a prerequisite to rechartering or concluding 81 the Working Group (if no gaps exist). This document is intended to 82 provide the required gap analysis. 84 This document provides a tabulation of candidate solutions and their 85 ability to satisfy each requirement identified by the Working Group. 87 Areas of work are identified where further work is required to ensure 88 that the requirements are met. 90 The major areas covered in this document include: 92 o Operational Requirements 93 [I-D.ashwood-nvo3-operational-requirement] 95 o Management Requirements (TBD) 96 o Control (Plane) Requirements [I-D.kreeger-nvo3-overlay-cp] 98 o Dataplane Requirements [I-D.ietf-nvo3-dataplane-requirements] 100 Since the Working Group has yet to complete (and in some cases adopt) 101 documents describing requirements for some of these areas, not all 102 areas are complete in the present version of this document. 104 The initial candidate technologies are: 106 o NVGRE [I-D.sridharan-virtualization-nvgre], 108 o VxLAN [I-D.mahalingam-dutt-dcops-vxlan], 110 o L2VPN: VPLS [RFC4761][RFC4762] and EVPN [I-D.ietf-l2vpn-evpn], and 112 o L3VPN [RFC4365]. 114 2. Terminology and Conventions 116 2.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2.2. Conventions 124 In sections providing analysis of requirements defined in referenced 125 documents, section numbers from each referenced document are used as 126 they were listed in that document. 128 In order to avoid confusing those section numbers with the section 129 numbering in this document, the included numbering is parenthesized. 131 L2VPN is represented (in tables and analysis, as a technology) by the 132 two differing approaches: VPLS and EVPN. 134 2.3. Terms and Abbreviations 136 This document uses terms and acronyms defined in [RFC3168], 137 [I-D.ietf-nvo3-framework], [I-D.ietf-nvo3-dataplane-requirements], 138 [I-D.kreeger-nvo3-hypervisor-nve-cp] and 139 [I-D.kreeger-nvo3-overlay-cp]. Acronyms are included here for 140 convenience but are meant to remain aligned with definitions in the 141 references included. 143 ECN: Explicit Congestion Notification [RFC3168] 144 NVA: Network Virtualization Authority [I-D.kreeger-nvo3-overlay-cp] 146 NVE: Network Virtualization Edge [I-D.ietf-nvo3-framework] 148 VAP: Virtual Access Point [I-D.ietf-nvo3-dataplane-requirements] 150 VNI: Virtual Network Instance [I-D.ietf-nvo3-framework] 152 VNIC: Virtual Network Interface Card (NIC) 153 [I-D.kreeger-nvo3-hypervisor-nve-cp] 155 VNID: Virtual Network Identifier [I-D.kreeger-nvo3-overlay-cp] 157 This document uses the following additional general terms and 158 abbreviations: 160 DSCP: Differentiated Services Code-Point 162 ECMP: Equal Cost Multi-Path 164 L2VPN: Layer 2 Virtual Private Network 166 L3VPN: Layer 3 Virtual Private Network 168 NVO3: Network Virtualization Overlay over L3 170 VM: Virtual Machine 172 VN: Virtual Network 174 3. Operational Requirements 176 TBD 178 4. Management Requirements 180 TBD 182 5. Control Plane Requirements 184 The NVO3 Problem Statement [I-D.ietf-nvo3-overlay-problem-statement], 185 describes 3 categories of control functions: 187 1. Control functions associated with implementing the Network 188 Virtualization Authority (e.g. - signaling and control required 189 for interactions between multiple NVA devices). 191 2. Control functions associated with interactions between an NVA and 192 a Network Virtualization Edge (NVE). 194 3. Control functions associated with attaching and detaching a 195 Virtual Machine (VM) from a particular Virtual Network Instance 196 (VNI). 198 As sometimes happens, there is not a 1:1 mapping of the work areas 199 defined in [I-D.ietf-nvo3-overlay-problem-statement] and requirements 200 documents intended to address the problems that have been identified 201 there. 203 Current control-plane requirement documents include the following: 205 o Overall control-plane requirements [I-D.kreeger-nvo3-overlay-cp] 207 o Control-plane requirements specific to VM-to-NVE interactions 208 [I-D.kreeger-nvo3-hypervisor-nve-cp] 210 5.1. Overall Control-Plane Requirements 212 In this section, numbering of requirement headings corresponds to 213 section numbering in [I-D.kreeger-nvo3-overlay-cp]. 215 (3.1) Inner to Outer Address Mapping 217 The requirements document [I-D.kreeger-nvo3-overlay-cp] states that 218 avoiding the need to "flood" traffic to support learning of mapping 219 information from the data-plane is a goal of NVO3 candidate 220 technological approaches. 222 For each candidate technology, (how) is the mapping of header 223 information present in tenant traffic mapped to corresponding header 224 information to be used in overlay encapsulation (this includes 225 addresses, context identification, etc.) determined? 227 +----------------------+---------+---------+-------+-------+--------+ 228 | Supported Approach | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 229 +----------------------+---------+---------+-------+-------+--------+ 230 | Control Protocol | | | | | | 231 | Acquisition? | | | | | | 232 | - - - | - - - | - - - | - - - | - - - | - - - | 233 | Data-Plane Learning? | | | | | | 234 +----------------------+---------+---------+-------+-------+--------+ 236 Table 1: Inner:Outer Address Mapping 238 (3.2) Underlying Network Multi-Destination Address(es) 239 The requirements document [I-D.kreeger-nvo3-overlay-cp] lists 3 240 approaches that may be used to deliver traffic to multiple 241 destinations in an overlay virtual network: 243 1. Use the capabilities of the underlay network. 245 2. Require a sending NVE to replicate traffic. 247 3. Use a replication service provided within the overlay network. 249 For each delivery approach, it may be necessary to map specific 250 multipoint (e.g. - broadcast, unknown destination or multicast) 251 traffic to (for instance) addresses used to deliver this traffic via 252 the underlay network. 254 For each technological approach, which delivery approaches are 255 supported and does the technology provide a method by which an NVE 256 needing to send multi-destination traffic can determine to what 257 address, or addresses to which to send this traffic? 259 +---------------------+---------+---------+--------+-------+--------+ 260 | Supported Approach | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 261 +---------------------+---------+---------+--------+-------+--------+ 262 | Underlay Network | | | | | | 263 | Capability | | | | | | 264 | - - - | - - - | - - - | - - - | - - - | - - - | 265 | NVE Sender | | | | | | 266 | Replication | | | | | | 267 | - - - | - - - | - - - | - - - | - - - | - - - | 268 | Replication Service | | | | | | 269 +---------------------+---------+---------+--------+-------+--------+ 271 Table 2: Multi-Destination Delivery 273 (3.3) VN Connect/Disconnect Notification 275 The requirements document [I-D.kreeger-nvo3-overlay-cp] states as an 276 assumption that a mechanism exists in the overlay technology by which 277 an NVE is notified of Tenant Systems attaching and detaching from a 278 specific Virtual Network (VN). 280 For each candidate technology, does the technology currently support 281 these functions? 283 +-------------------------+-------+-------+-------+-------+-------+ 284 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 285 +-------------------------+-------+-------+-------+-------+-------+ 286 | Connect Notification | | | | | | 287 | - - - | - - - | - - - | - - - | - - - | - - - | 288 | Disconnect Notification | | | | | | 289 +-------------------------+-------+-------+-------+-------+-------+ 291 Table 3: Connect/Disconnect Notification 293 (3.4) VN Name to VNID Mapping 295 The requirements document [I-D.kreeger-nvo3-overlay-cp] concludes 296 that having a means to map for a "VN Name to a "VN ID" may be useful. 298 For each technological approach we are considering, is this function 299 currently available? 301 +-----------------------+-------+-------+------+------+-------+ 302 | Function | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 303 +-----------------------+-------+-------+------+------+-------+ 304 | VN-Name:VN-ID Mapping | | | | | | 305 +-----------------------+-------+-------+------+------+-------+ 307 Table 4: VN Name to VN ID Mapping 309 5.2. VM-to-NVE Specific Control-Plane Requirements 311 In this section, numbering of requirement headings corresponds to 312 section numbering in [I-D.kreeger-nvo3-hypervisor-nve-cp]. 314 (4.1) VN Connect/Disconnect 316 The requirements document [I-D.kreeger-nvo3-hypervisor-nve-cp] states 317 as a requirement that a mechanism must exist by which an NVE is 318 notified when an end device requires a connection, or no longer 319 requires a connection, to a specific Virtual Network (VN). 321 The requirements document further states as a requirement that the 322 mechanism(s) used in a candidate technological approach must provide 323 a local indicator (e.g. - 802.1Q tag) that the end device will use in 324 sending traffic to, or receiving traffic from, the NVE (where that 325 traffic is associated with the connected VN). 327 As an additional related requirement, the requirements document 328 states that the NVE - once notified of a connection to a VN (by VN 329 Name), needs to have a means for getting associated VN context 330 information from the NVA. 332 For each candidate technology, does the technology currently support 333 these functions? 334 +----------------------+---------+---------+-------+-------+--------+ 335 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 336 +----------------------+---------+---------+-------+-------+--------+ 337 | Connect Notification | | | | | | 338 | - - - | - - - | - - - | - - - | - - - | - - - | 339 | Local VN Indicator | | | | | | 340 | - - - | - - - | - - - | - - - | - - - | - - - | 341 | VN Name to VN | | | | | | 342 | Context Mapping | | | | | | 343 | - - - | - - - | - - - | - - - | - - - | - - - | 344 | Disconnect | | | | | | 345 | Notification | | | | | | 346 +----------------------+---------+---------+-------+-------+--------+ 348 Table 5: VN Connect/Disconnect 350 (4.2) VNIC Address Association 352 The requirements document [I-D.kreeger-nvo3-hypervisor-nve-cp] lists 353 two approaches for acquiring VNIC address association information: 355 1. Data Plane Learning (i.e. - by inspecting source addresses in 356 traffic received from an end device). 358 2. Explicit signaling from the end device when a specific VNIC 359 address is to be associated with a tenant system. 361 +----------------------+-------+-------+-------+-------+-------+ 362 | Supported Approaches | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 363 +----------------------+-------+-------+-------+-------+-------+ 364 | Data Plane Learning | | | | | | 365 | - - - | - - - | - - - | - - - | - - - | - - - | 366 | Explicit Signaling | | | | | | 367 +----------------------+-------+-------+-------+-------+-------+ 369 Table 6: VNIC Address Association 371 (4.3) VNIC Address Disassociation 373 TBD 375 (4.4) VNIC Shutdown/Startup/Migration 377 TBD 379 (4.5) VN Profile 381 TBD 383 6. Data Plane Requirements 385 In this section, numbering of requirement headings corresponds to 386 section numbering in [I-D.ietf-nvo3-dataplane-requirements]. 388 (3.1) Virtual Access Points (VAPs) 390 +------------------------+--------+-------+--------+--------+-------+ 391 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 392 +------------------------+--------+-------+--------+--------+-------+ 393 | MUST support VAP | | | | | | 394 | identification | | | | | | 395 | - - - | - - - | - - - | - - - | - - - | - - - | 396 | 1) Local interface | YES | | | | | 397 | - - - | - - - | - - - | - - - | - - - | - - - | 398 | 2) Local interface + | YES | | | | | 399 | fields in frame header | | | | | | 400 +------------------------+--------+-------+--------+--------+-------+ 402 Table 7: VAP Identification Requirements 404 (3.2) Virtual Network Instance (VNI) 406 +-------------------------+-------+-------+--------+--------+-------+ 407 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 408 +-------------------------+-------+-------+--------+--------+-------+ 409 | VAP are associated with | YES | | | | | 410 | a specific VNI at | | | | | | 411 | service instantiation | | | | | | 412 | time. | | | | | | 413 +-------------------------+-------+-------+--------+--------+-------+ 415 Table 8: VAP-VNI Association 417 (3.2.1) L2 VNI 419 +----------------------------+-------+-------+-------+------+-------+ 420 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 421 +----------------------------+-------+-------+-------+------+-------+ 422 | L2 VNI MUST provide an | | | | | | 423 | emulated Ethernet | | | | | | 424 | multipoint service as if | | | | | | 425 | Tenant Systems are | | | | | | 426 | interconnected by a bridge | | | | | | 427 | (but instead by using a | | | | | | 428 | set of NVO3 tunnels). | | | | | | 429 | - - - | - - - | - - - | - - - | - - | - - - | 430 | | | | | - | | 431 | Loop avoidance capability | | | | | | 432 | MUST be provided. | | | | | | 433 | - - - | - - - | - - - | - - - | - - | - - - | 434 | | | | | - | | 435 | In the absence of a | | | | | | 436 | management or control | | | | | | 437 | plane, data plane learning | | | | | | 438 | MUST be used to populate | | | | | | 439 | forwarding tables. | | | | | | 440 | - - - | - - - | - - - | - - - | - - | - - - | 441 | | | | | - | | 442 | When flooding is required, | | | | | | 443 | either to deliver unknown | | | | | | 444 | unicast, or broadcast or | | | | | | 445 | multicast traffic, the NVE | | | | | | 446 | MUST either support | | | | | | 447 | ingress replication or | | | | | | 448 | multicast. | | | | | | 449 | - - - | - - - | - - - | - - - | - - | - - - | 450 | | | | | - | | 451 | In this latter case, the | | | | | | 452 | NVE MUST be able to build | | | | | | 453 | at least a default | | | | | | 454 | flooding tree per VNI. | | | | | | 455 +----------------------------+-------+-------+-------+------+-------+ 457 Table 9: L2 VNI Service 459 (3.2.2) L3 VNI 461 +---------------------------+-------+-------+--------+------+-------+ 462 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 463 +---------------------------+-------+-------+--------+------+-------+ 464 | L3 VNIs MUST provide | | | | | | 465 | virtualized IP routing | | | | | | 466 | and forwarding. | | | | | | 467 | - - - | - - - | - - - | - - - | - - | - - - | 468 | | | | | - | | 469 | L3 VNIs MUST support per- | | | | | | 470 | tenant forwarding | | | | | | 471 | instance with IP | | | | | | 472 | addressing isolation and | | | | | | 473 | L3 tunneling for | | | | | | 474 | interconnecting instances | | | | | | 475 | of the same VNI on NVEs. | | | | | | 476 +---------------------------+-------+-------+--------+------+-------+ 478 Table 10: L3 VNI Service 480 (3.3.1) NVO3 overlay header 482 +---------------------------+-------+-------+--------+------+-------+ 483 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 484 +---------------------------+-------+-------+--------+------+-------+ 485 | An NVO3 overlay header | YES | YES | YES | YES | YES | 486 | MUST be included after | | | | | | 487 | the underlay tunnel | | | | | | 488 | header when forwarding | | | | | | 489 | tenant traffic. | | | | | | 490 +---------------------------+-------+-------+--------+------+-------+ 492 Table 11: Overlay Header 494 (3.3.1.1) Virtual Network Context Identification 496 +---------------------------+-------+-------+--------+------+-------+ 497 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 498 +---------------------------+-------+-------+--------+------+-------+ 499 | The overlay encapsulation | YES | YES | YES | YES | YES | 500 | header MUST contain a | | | | | | 501 | field which allows the | | | | | | 502 | encapsulated frame to be | | | | | | 503 | delivered to the | | | | | | 504 | appropriate virtual | | | | | | 505 | network endpoint by the | | | | | | 506 | egress NVE. | | | | | | 507 +---------------------------+-------+-------+--------+------+-------+ 509 Table 12: Virtual Network Context Identification 511 (3.3.1.2) Service QoS identifier 513 +----------------------------+-------+-------+-------+------+-------+ 514 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 515 +----------------------------+-------+-------+-------+------+-------+ 516 | Traffic flows originating | NO | | | | | 517 | from different | | | | | | 518 | applications could rely on | | | | | | 519 | differentiated forwarding | | | | | | 520 | treatment to meet end-to- | | | | | | 521 | end availability and | | | | | | 522 | performance objectives. | | | | | | 523 +----------------------------+-------+-------+-------+------+-------+ 525 Table 13: QoS Service Identification 527 (3.3.2.1) LAG and ECMP 528 +-------------------------+-------+-------+--------+--------+-------+ 529 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 530 +-------------------------+-------+-------+--------+--------+-------+ 531 | For performance | YES | | | | | 532 | reasons, multipath over | | | | | | 533 | LAG and ECMP paths | | | | | | 534 | SHOULD be supported. | | | | | | 535 +-------------------------+-------+-------+--------+--------+-------+ 537 Table 14: Multipath Support 539 (3.3.2.2) DiffServ and ECN marking 541 +---------------------------+-------+-------+--------+------+-------+ 542 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 543 +---------------------------+-------+-------+--------+------+-------+ 544 | [RFC2983] defines two | NO | | | | | 545 | modes for mapping the | | | | | | 546 | DSCP markings from inner | | | | | | 547 | to outer headers and vice | | | | | | 548 | versa. Both models SHOULD | | | | | | 549 | be supported. | | | | | | 550 | - - - | - - - | - - - | - - - | - - | - - - | 551 | | | | | - | | 552 | ECN marking MUST be | NO | | | | | 553 | performed according to | | | | | | 554 | [RFC6040] which describes | | | | | | 555 | the correct ECN behavior | | | | | | 556 | for IP tunnels. | | | | | | 557 +---------------------------+-------+-------+--------+------+-------+ 559 Table 15: DSCP and ECN Marking 561 (3.3.2.3) Handling of broadcast, unknown unicast, and multicast 562 traffic 564 +-----------------------------+-------+-------+------+------+-------+ 565 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 566 +-----------------------------+-------+-------+------+------+-------+ 567 | NVO3 data plane support for | YES | YES | YES | YES | YES | 568 | either ingress replication | | | | | | 569 | or point-to-multipoint | | | | | | 570 | tunnels is required to send | | | | | | 571 | traffic destined to | | | | | | 572 | multiple locations on a | | | | | | 573 | per-VNI basis (e.g. L2/L3 | | | | | | 574 | multicast traffic, L2 | | | | | | 575 | broadcast and unknown | | | | | | 576 | unicast traffic). | | | | | | 577 +-----------------------------+-------+-------+------+------+-------+ 579 Table 16: Handling of Broadcast, Unknown Unicast, and Multicast 580 Traffic 582 (3.4) External NVO3 connectivity 584 +----------------------------+-------+-------+-------+------+-------+ 585 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 586 +----------------------------+-------+-------+-------+------+-------+ 587 | NVO3 services MUST | YES | | | | | 588 | interoperate with current | | | | | | 589 | VPN and Internet services. | | | | | | 590 | This may happen inside one | | | | | | 591 | DC during a migration | | | | | | 592 | phase or as NVO3 services | | | | | | 593 | are delivered to the | | | | | | 594 | outside world via Internet | | | | | | 595 | or VPN gateways. | | | | | | 596 +----------------------------+-------+-------+-------+------+-------+ 598 Table 17: Interoperation 600 (3.5) Path MTU 602 +--------------------------+-------+-------+--------+-------+-------+ 603 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 604 +--------------------------+-------+-------+--------+-------+-------+ 605 | Classical ICMP-based MTU | NO | | | | | 606 | Path Discovery | | | | | | 607 | ([RFC1191], [RFC1981]) | | | | | | 608 | or Extended MTU Path | | | | | | 609 | Discovery techniques | | | | | | 610 | such as defined in | | | | | | 611 | [RFC4821]. | | | | | | 612 | - - - | - - - | - - - | - - - | - - - | - - - | 613 | Segmentation and | YES | | | | | 614 | reassembly support from | | | | | | 615 | the overlay layer | | | | | | 616 | operations without | | | | | | 617 | relying on the Tenant | | | | | | 618 | Systems to know about | | | | | | 619 | the end-to-end MTU. | | | | | | 620 +--------------------------+-------+-------+--------+-------+-------+ 622 Table 18: Path MTU 624 (3.7) NVE Multi-Homing Requirements 626 +--------------------------+-------+-------+--------+-------+-------+ 627 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 628 +--------------------------+-------+-------+--------+-------+-------+ 629 | Multi-homing techniques | NO | | | | | 630 | SHOULD be used to | | | | | | 631 | increase the reliability | | | | | | 632 | of an NVO3 network. | | | | | | 633 +--------------------------+-------+-------+--------+-------+-------+ 635 Table 19: Multihoming 637 (3.8) OAM 639 +-----------------------------+-------+-------+------+------+-------+ 640 | Requirement | NVGRE | VxLAN | VPLS | EVPN | L3VPN | 641 +-----------------------------+-------+-------+------+------+-------+ 642 | NVE MAY be able to | NO | | | | | 643 | originate/terminate OAM | | | | | | 644 | messages for connectivity | | | | | | 645 | verification, performance | | | | | | 646 | monitoring, statistic | | | | | | 647 | gathering and fault | | | | | | 648 | isolation. Depending on | | | | | | 649 | configuration, NVEs SHOULD | | | | | | 650 | be able to process or | | | | | | 651 | transparently tunnel OAM | | | | | | 652 | messages, as well as | | | | | | 653 | supporting alarm | | | | | | 654 | propagation capabilities. | | | | | | 655 +-----------------------------+-------+-------+------+------+-------+ 657 Table 20: OAM Messaging 659 7. Summary and Conclusions 661 TBD 663 8. Acknowledgements 665 The Authors would like to acknowledge the technical contributions of 666 Florin Balus, Luyuan Fang, Sue Hares, Wim Henderickx, Yuichi Ikejiri, 667 Rangaraju Iyengar, Mircea Pisica, Evelyn Roch, Ali Sajassi, Peter 668 Ashwood-Smith and Lucy Yong as well as the initial help in editing 669 the XML source for the document from Tom Taylor. 671 9. IANA Considerations 673 This memo includes no request to IANA. 675 10. Security Considerations 677 Security considerations of the requirements documents referenced by 678 this analysis document apply. 680 11. References 682 11.1. Normative References 684 [I-D.ashwood-nvo3-operational-requirement] 685 Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A., 686 Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3 687 Operational Requirements", draft-ashwood-nvo3-operational- 688 requirement-02 (work in progress), January 2013. 690 [I-D.ietf-l2vpn-evpn] 691 Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., 692 Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", 693 draft-ietf-l2vpn-evpn-03 (work in progress), February 694 2013. 696 [I-D.ietf-nvo3-dataplane-requirements] 697 Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., 698 and B. Khasnabish, "NVO3 Data Plane Requirements", draft- 699 ietf-nvo3-dataplane-requirements-01 (work in progress), 700 July 2013. 702 [I-D.ietf-nvo3-framework] 703 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 704 Rekhter, "Framework for DC Network Virtualization", draft- 705 ietf-nvo3-framework-03 (work in progress), July 2013. 707 [I-D.ietf-nvo3-overlay-problem-statement] 708 Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., 709 and M. Napierala, "Problem Statement: Overlays for Network 710 Virtualization", draft-ietf-nvo3-overlay-problem- 711 statement-03 (work in progress), May 2013. 713 [I-D.kreeger-nvo3-hypervisor-nve-cp] 714 Kreeger, L., Narten, T., and D. Black, "Network 715 Virtualization Hypervisor-to-NVE Overlay Control Protocol 716 Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01 717 (work in progress), February 2013. 719 [I-D.kreeger-nvo3-overlay-cp] 720 Kreeger, L., Dutt, D., Narten, T., Black, D., and M. 721 Sridharan, "Network Virtualization Overlay Control 722 Protocol Requirements", draft-kreeger-nvo3-overlay-cp-04 723 (work in progress), June 2013. 725 [I-D.mahalingam-dutt-dcops-vxlan] 726 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 727 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 728 Framework for Overlaying Virtualized Layer 2 Networks over 729 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-04 730 (work in progress), May 2013. 732 [I-D.sridharan-virtualization-nvgre] 733 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 734 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 735 and C. Tumuluri, "NVGRE: Network Virtualization using 736 Generic Routing Encapsulation", draft-sridharan- 737 virtualization-nvgre-02 (work in progress), February 2013. 739 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 740 November 1990. 742 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 743 for IP version 6", RFC 1981, August 1996. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 749 2983, October 2000. 751 [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP 752 Virtual Private Networks (VPNs)", RFC 4365, February 2006. 754 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 755 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 756 4761, January 2007. 758 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 759 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 760 RFC 4762, January 2007. 762 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 763 Discovery", RFC 4821, March 2007. 765 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 766 Notification", RFC 6040, November 2010. 768 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 769 "Provisioning, Auto-Discovery, and Signaling in Layer 2 770 Virtual Private Networks (L2VPNs)", RFC 6074, January 771 2011. 773 11.2. Informative References 775 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 776 of Explicit Congestion Notification (ECN) to IP", RFC 777 3168, September 2001. 779 Authors' Addresses 781 Eric Gray (editor) 782 Ericsson 783 120 Morris Avenue 784 Pitman, New Jersey 08071 785 USA 787 Email: eric.gray@ericsson.com 789 Nabil Bitar 790 Verizon 791 40 Sylvan Road 792 Waltham, Massachusetts 02145 793 USA 795 Email: nabil.bitar@verizon.com 797 Xiaoming Chen 798 Huawei Technologies 800 Email: ming.chen@huawei.com 802 Marc Lasserre 803 Alcatel-Lucent 805 Email: marc.lasserre@alcatel-lucent.com 806 Tina Tsou 807 Huawei Technologies (USA) 808 2330 Central Expressway 809 Santa Clara, California 95050 810 USA 812 Phone: +1 408 330 4424 813 Email: Tina.Tsou.Zouting@huawei.com 814 URI: http://tinatsou.weebly.com/contact.html