idnits 2.17.1 draft-drake-nvo3-evpn-control-plane-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 (September 16, 2012) is 4240 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-ietf-l2vpn-evpn-01' is mentioned on line 102, but not defined == Unused Reference: 'I-D.draft-ietf-l2vpn-evpn' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'I-D.lasserre-nvo3-framework' is defined on line 472, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4272 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-04) exists of draft-raggarwa-sajassi-l2vpn-evpn-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-ietf-l2vpn-evpn' == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-00 ** Downref: Normative reference to an Informational draft: draft-sridharan-virtualization-nvgre (ref. 'I-D.draft-sridharan-virtualization-nvgre-00') == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-02 ** Downref: Normative reference to an Informational draft: draft-mahalingam-dutt-dcops-vxlan (ref. 'I-D.draft-mahalingam-dutt-dcops-vxlan') == Outdated reference: A later version (-04) exists of draft-ietf-nvo3-overlay-problem-statement-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-overlay-problem-statement (ref. 'I-D.draft-ietf-nvo3-overlay-problem-statement') -- No information found for draft-ietf-l2vpn-l2vpn-evpn-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-ietf-l2vpn-evpn-req' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet-Draft T. Nadeau 3 Intended status: Standards Track J. Drake 4 Expires: March 16, 2013 Editors 5 Juniper Networks 7 B. Schlisser 8 James Uttaro Y. Rekhter 9 ATT Ravi Shekhar 10 Juniper Networks 12 Wim Hendrix Nabil Bitar 13 Alcatel-Lucent Verizon 15 Aldrin Isaac 16 Bloomberg 18 September 16, 2012 20 A Control Plane for Network Virtualized Overlays 21 draft-drake-nvo3-evpn-control-plane-00 23 Abstract 25 The purpose of this document is to describe how Ethernet Virtual 26 Private Network (E-VPN) can be used as the control plane for 27 Network Virtual Overlays. Currently this protocol is defined to 28 act as the control plane for Virtual Extensible Local Area 29 Network (VXLAN), Network Virtualization using Generic Routing 30 Encapsulation (NVGRE), MPLS or VLANs while maintaining their 31 existing data plane encapsulations. The intent is that this 32 protocol will be capable of extensions in the future to handle 33 additinal data plane encapsulations and functions as needed. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on November March 16, 2012. 52 EVPN Control Plane September 14, 2012 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [RFC2119]. 75 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 77 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 78 2. E-VPN Attributes . . . . . . . . . . . . . . . . . . . . . . . 79 3. Constructing E-VPN routes . . . . . . . . . . . . . . . . . . 80 4. Interworking Capabilities . . . . . . . . . . . . . . . . . . 81 5. Active/Active Multihoming . . . . . . . . . . . . . . . . . . 82 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.1. P-Tunnel Identification . . . . . . . . . . . . . . . . . . . 84 6.2. Ingress Replication . . . . . . . . . . . . . . . . . . . . . 85 6.3. PIM-SSM/SM Tree . . . . . . . . . . . . . . . . . . . . . . . 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 93 EVPN Control Plane September 14, 2012 95 1. Introduction 97 The purpose of this document is to describe a single control 98 plane protocol control protocol that can be used for all 99 types of data planes used in network virtualization overlays 100 (NVOs). In particular, we describe how The Ethernet Virtual 101 Private Network (E-VPN) protocol, as described in 102 [I-D.draft-ietf-l2vpn-evpn-01], can be 103 used as the control plane for Virtual Extensible Local 104 Area Network (VXLAN) [I-D.draft-mahalingam-dutt-dcops-vxlan], 105 Network Virtualization using Generic Routing Encapsulation 106 (NVGRE) [I-D.draft-sridharan-virtualization-nvgre-00], MPLS or 107 Ethernet VLANs. In all cases, the existing data plane 108 encapsulations are maintained. 110 Network Virtualization Overlays (NVOs), as described in 111 [I-D.draft-ietf-nvo3-overlay-problem-statement], are intended 112 to provide separate logical tenant networks over a common 113 physical infrastructure in a data center environment. 115 Both VXLAN and NVGRE are examples of technologies provide 116 a data plane encapsulation which is used to transport a 117 packet over the common physical infrastructure between 118 NVO endpoints. 120 1.2. Acronyms 122 CE Customer Edge. 124 OAM Operation and Maintenance. 126 PE Provider Edge. 128 NVE Network Virtualization Endpoint 130 NVGRE Network Virtualization Using Generic Routing Encapsulation 132 NVO Network Virtual Overlay 134 VNE Virtual Network Identifier 136 VTEP VXLAN Tunnel End Point 137 EVPN Control Plane September 14, 2012 139 VXLAN Virtual Extensible Local Area Network 141 2. E-VPN Attributes 143 Both VXLAN and NVGRE are examples of technologies provide 144 a data plane encapsulation which is used to transport a 145 packet over the common physical infrastructure between 146 NVO endpoints, VXLAN Tunnel End Point (VTEP) in VXLAN and 147 Network Virtualization Endpoint (NVE) in NVGRE. Both of 148 these technologies include the identifier of the specific 149 NVO instance, Virtual Network Identifier (VNI) in VXLAN 150 and Tenant ID in NVGRE, in each packet. 152 E-VPN was originally designed to support the requirements 153 detailed in [I-D.draft-ietf-l2vpn-evpn-req] and therefore has 154 the following attributes which directly address control plane 155 scaling and ease of deployment issues. 157 1) Control plane traffic is distributed with BGP and Broadcast 158 and Multicast traffic is sent using a shared multicast tree 159 or with ingress replication. 161 2) Control plane learning is used instead flooding unknown 162 unicast and ARP packets. 164 3) Auto-discovery via BGP Route Reflectors is used. 166 4) Active-active multihoming is used. This allows a given 167 customer device to have multiple attachment links to an 168 E-VPN instance (EVI), via a Link Aggregation Group (LAG). 169 This allows traffic to/from that customer to fully utilize 170 all of these links. The set of attachment links to a given 171 customer device is termed an Ethernet Segment and is 172 typically identified with that customer device's MAC address. 174 5) Block withdraw is used. When a link between a customer 175 device and an EVI fails, the other nodes in the EVI are 176 notified via the withdrawal of a single E-VPN route 177 regardless of how many MAC addresses are located at the 178 customer device. 180 6) Route filtering and constrained route distribution are 181 used to ensure that the control plane traffic for a given 182 EVI is only distributed to those nodes in that EVI. 184 7) The internal identifier of a broadcast domain, the Ethernet 185 Tag, is a 32 bit number, which is mapped into whatever 186 EVPN Control Plane September 14, 2012 188 broadcast domain identifier, e.g., VLAN ID, is understood 189 by the attaching CE device. This means that there are up 190 to 4096 distinct VLAN IDs for each attaching Customer Edge 191 (CE) device in a given EVI. 193 Note that an EVI is equivalent to an NVO instance and that a 194 Provider Edge (PE) is equivalent to a VTEP/NVE. 196 8) Because the design goal for NVO is millions of instances 197 per common physical infrastructure, the scaling properties 198 of the control plane for NVO are extremely important. The 199 E-VPN and the extensions described herein, are designed 200 with this level of scalability in mind. 202 3. Constructing E-VPN routes 204 In E-VPN an MPLS label distributed by the egress PE via the E-VPN 205 control plane and placed in the MPLS header of a given packet by 206 the ingress PE is used upon receipt of that packet by the egress 207 PE to determine to which EVI that packet is to be sent. This is 208 very similar to the use of the VNI or Tenant ID by the egress 209 VTEP or NVE, respectively, with the difference being that an 210 MPLS label has local significance and is distributed by the 211 E-VPN control plane, while a VNI or Tenant ID currently has 212 global significance. 214 In E-VPN, an MPLS label is carried in a three octet MPLS Label 215 field, and consists of the twenty bit label. Both the VNI and 216 Tenant ID are also three octets in length and so could be 217 transparently carried in the MPLS label field of the E-VPN MAC 218 Advertisement or Per EVI Ethernet AD route. 220 This memo specifies that when E-VPN is to be used with a VXLAN or 221 NVGRE data plane that a VNI or Tenant ID is twenty bits in 222 length and may have either global or local significance, that 223 the remaining four bits are reserved, and that the value 224 advertised in the MPLS label field is to be treated as a three 225 octet quantity to be placed directly in the VNI or tenant ID 226 field of a packet. 228 Note that because in this context an advertised VNI or Tenant 229 ID may have local significance, the advertising PE may 230 transparently use it to represent the VN or Tenant, a set of 231 addresses within the VN or Tenant, or an individual address 232 within the VN or Tenant. 234 In order to indicate that a VXLAN or NVGRE data plane 235 encapsulation rather than MPLS label stack encapsulation is to 236 EVPN Control Plane September 14, 2012 238 be used, the Tunnel Encapsulation attribute defined in [RFC5512] 239 is included with E-VPN MAC Advertisement or Per EVI Ethernet AD 240 routes advertised by an egress PE. Two new values, one for 241 VXLAN and one for NVGRE, will be defined. This same mechanism 242 should be used to advertise MPLS or VLAN encapsulations when 243 they are used. 245 4. Interworking Capabilities 247 Through the presence of the Tunnel Encapsulation attribute, each 248 PE within a given EVI will know whether the other PEs in that EVI 249 support MPLS label stack, VXLAN, or NVGRE data plane encapsulation. 251 This means that a given EVI can support multiple data plane 252 encapsulations. This has the advantage of allowing 253 interoperability between VXLAN, NVGRE, and E-VPN (and by 254 extension L3VPNs). 256 Note that an ingress PE must use the data plane encapsulation 257 specified by a given egress PE in the subject MAC Advertisement 258 or Per EVI Ethernet AD route when sending a packet to that PE. 259 Further, an ingress node that uses shared multicast trees for 260 sending Broadcast and Multicast traffic must maintain distinct 261 trees for each different encapsulation type. 263 5. Active/Active Multihoming 265 The base E-VPN protocol supports active/active multihoming. In 266 order to prevent loops of Broadcast and Multicast packets, these 267 packets need to carry two labels, one to identify the EVI to which 268 the packet should be sent and one to identify the Ethernet Segment 269 from which it was received. The latter label is termed the 'split 270 horizon label' and when a Broadcast or Multicast packet is received 271 by an egress PE, it uses that label to stop it from sending the 272 packet back to the Ethernet Segment from which the packet was 273 received. 275 When using the VXLAN or NVGRE encapsulation, there is no field in 276 the packet in which to carry the split horizon label. 278 This memo specifies that an egress PE must use the sender MAC 279 address to determine whether to send a received Broadcast or 280 Multicast packet to a given Ethernet Segment. I.e., if the sender 281 MAC address is associated with a given Ethernet Segment, the egress 282 PE must not send the packet to that Ethernet Segment. 284 EVPN Control Plane September 14, 2012 286 6. Multicast 288 The base E-VPN protocol allows to use MPLS ingress replication or 289 P2MP LSPs to send BUM traffic to other PEs. When VXLAN/NVGRE 290 encapsulations are used with E-VPN, IP based ingress replication 291 and IP multicast trees must be supported. 293 6.1. P-Tunnel Identification 295 In order to identify the P-Tunnel used for sending broadcast, 296 unknown unicast or multicast traffic, the Inclusive Multicast 297 Ethernet Tag route MUST carry a "PMSI Tunnel Attribute" as 298 specified in [RFC6513]. The following changes are required for 299 VXLAN/NVGRE 301 + When a PE that uses a P-Multicast tree for the P-tunnel 302 wants to aggregate two or more Ethernet Tags in the same or 303 different EVIs present on the PE onto the same tree. In this 304 case, in addition to carrying the identity of the tree, the 305 PMSI Tunnel attribute MUST carry a upstream assigned VNI or 306 tenant ID in the MPLS Label field of the PMSI attribute 307 which the PE has bound uniquely to the Ethernet Tag for the 308 EVI associated with this update (as determined by its RTs). 310 + If the PE that originates the advertisement uses ingress 311 replication for the P-tunnel for E-VPN, the route MUST 312 include the PMSI Tunnel attribute with the Tunnel Type set to 313 Ingress Replication and Tunnel Identifier set to a routable 314 address of the PE. The PMSI Tunnel attribute MUST carry a 315 downstream assigned VNI or tenant ID in the MPLS Label 316 field of the PMSI attribute. This identifier is used to 317 demultiplex the broadcast, multicast or unknown unicast E-VPN 318 traffic received over a MP2P tunnel by the PE. 320 + If the PE that originates the advertisement uses IP 321 multicast replication for the P-tunnel for E-VPN, the 322 route MUST include the PMSI Tunnel attribute with the 323 Tunnel Type set to PIM-SSM or PIM ASM Tree. 325 When the Tunnel Type is set to Protocol 326 Independent Multicast - Sparse Mode (PIM-SM) tree, the 327 Tunnel Identifier is . 328 The node that originated the attribute MUST use the address 329 carried in the Sender Address as the source IP address for 330 the IP/GRE (NVGRE) or IP/UDP (VXLAN) encapsulation of the 331 BUM data. 333 When the Tunnel Type is set to PIM-SSM tree, the Tunnel 334 EVPN Control Plane September 14, 2012 336 Identifier is . The 337 node that originates the attribute MUST use the address 338 carried in the P-Root Node Address as the source IP address 339 for the IP/GRE (NVGRE) or IP/UDP (VXLAN) encapsulation of 340 the BUM data. 342 According to [RFC4607], the group address can be locally 343 allocated by the originating PE without any consideration 344 for the group address used by other PE on the same MVPN. 346 6.2. Ingress Replication 348 The PEs may use ingress replication for flooding unknown unicast, 349 multicast or broadcast traffic. The VXLAN or NVGRE encapsulations 350 are used with the VNI or tenant ID exchanged in the I-PMSI PMSI 351 attribute. 353 6.3. PIM-SSM/SM Tree 355 An PE may use an IP multicast "Inclusive" tree for sending an 356 unknown unicast, broadcast or multicast packet or a "Selective" 357 tree. For VXLAN or NVGRE the destination address of the UDP/GRE 358 encapsulations use the multicast address of the PMSI attribute in 359 the Inclusive Multicast Ethernet Tag route. When no aggregated 360 trees are used the VNI or tenant ID is set to 0. 362 7. IANA Considerations 364 4.1 E-VPN Encapsulation Types 366 IANA is requested to assign two values from the "BGP Tunnel 367 Encapsulation Attribute Tunnel Types" registry [RFC5512] as 368 follows. 370 - VxLan: Tunnel Type = TBD 372 - NVGRE: Tunnel Type = TBD +1 374 8. Security Considerations 376 This document uses IP-based tunnel technologies to support data 377 plane transport. Consequently, the security considerations of 378 those tunnel technologies apply. This document defines support 379 for VxLan [I-D.draft-mahalingam-dutt-dcops-vxlan] and 380 NVGRE [I-D.draft-sridharan-virtualization-nvgre-00]. 381 The security considerations from those documents as well as 382 EVPN Control Plane September 14, 2012 384 [RFC4301] apply to the data plane aspects of this document. 386 As with [RFC5512], any modification of the information that is used 387 to form encapsulation headers, to choose a tunnel type, or to choose 388 a particular tunnel for a particular payload type may lead to user 389 data packets getting misrouted, misdelivered, and/or dropped. 391 More broadly, the security considerations for the transport of IP 392 reachability information using BGP are discussed in [RFC4271] and 393 [RFC4272], and are equally applicable for the extensions described 394 in this document. 396 If the integrity of the BGP session is not itself protected, then an 397 imposter could mount a denial-of-service attack by establishing 398 numerous BGP sessions and forcing an IPsec SA to be created for each 399 one. However, as such an imposter could wreak havoc on the entire 400 routing system, this particular sort of attack is probably not of 401 any special importance. 403 It should be noted that a BGP session may itself be transported over 404 an IPsec tunnel. Such IPsec tunnels can provide additional security 405 to a BGP session. The management of such IPsec tunnels is outside 406 the scope of this document. 408 9. Acknowledgements 410 10. References 412 10.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 417 [RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., 418 "A Border Gateway Protocol 4 (BGP-4)", January 2006. 420 [RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.", 421 January 2006. 423 [RFC4301] S. Kent, K. Seo., "Security Architecture for the 424 Internet Protocol.", December 2005. 426 [RFC4607] H. Holbrook, B. Cain., "Source-Specific Multicast for 427 IP.", RFC4607, August 2006. 429 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 430 EVPN Control Plane September 14, 2012 432 Subsequent Address Family Identifier (SAFI) and the BGP 433 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 435 [RFC6513] Rosen, E., et al., "Multicast in MPLS/BGP IP VPNs.", 436 RFC6513, February 2012. 438 [I-D.draft-ietf-l2vpn-evpn] Aggarwal et al., "BGP MPLS Based 439 Ethernet VPN", 440 draft-raggarwa-sajassi-l2vpn-evpn-02.txt, work in 441 progress, March, 2011. 443 [I-D.draft-sridharan-virtualization-nvgre-00] Sridhavan, M., et 444 al., "NVGRE: Network Virtualization using Generic 445 Routing Encapsulation", 446 draft-sridharan-virtualization-nvgre-01.txt, July 8, 447 2012. 449 [I-D.draft-mahalingam-dutt-dcops-vxlan] Dutt, D., et al, 450 "VXLAN: A Framework for Overlaying Virtualized Layer 2 451 Networks over Layer 3 Networks", 452 draft-mahalingam-dutt-dcops-vxlan-02.txt, 453 August 22, 2012. 455 [I-D.draft-ietf-nvo3-overlay-problem-statement] Narten, et al, 456 "Problem Statement: Overlays for Network 457 Virtualization", 458 draft-ietf-nvo3-overlay-problem-statement-00.txt, 459 5-Sep-12. 461 [I-D.draft-ietf-l2vpn-evpn-req] Sajassi et al., "Requirements for 462 Ethernet VPN (E-VPN)", draft-ietf-l2vpn-l2vpn-evpn- 463 req-00.txt, work in progress, 464 March 27, 2012. 466 10.2. Informative References 468 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 469 an IANA Considerations Section in RFCs", BCP 26, 470 RFC 5226, May 2008. 472 [I-D.lasserre-nvo3-framework] 473 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 474 Rekhter, "Framework for DC Network Virtualization", 475 draft-lasserre-nvo3-framework-03 (work in progress), 476 EVPN Control Plane September 14, 2012 478 July 2012. 480 Editors' Addresses 482 Thomas D. Nadeau 483 Juniper Networks 484 Email: tnadeau@juniper.net 486 John E. Drake 487 Juniper Networks 488 Email: jnadeau@juniper.net 490 Authors' Addresses 492 Benson Schliser 493 Juniper Networks 494 Email: bensons@juniper.net 496 Yakov Reckhter 497 Juniper Networks 498 Email: yakov@juniper.net 500 Nabil Bitar 501 Verizon Communications 502 Email : nabil.n.bitar@verizon.com 504 Ravi Shekhar 505 Juniper Networks 506 1194 N. Mathilda Ave. 507 Sunnyvale, CA 94089 US 508 Email: rshekhar@juniper.net 510 Aldrin Isaac 511 Bloomberg 512 aldrin.isaac@gmail.com 514 Wim Henderickx 515 Alcatel-Lucent 516 e-mail: wim.henderickx@alcatel-lucent.com 518 James Uttaro 519 AT&T 520 200 S. Laurel Avenue 521 Middletown, NJ 07748 522 USA 523 Email: uttaro@att.com 524 EVPN Control Plane September 14, 2012