Network Working Group Internet-Draft T. Nadeau Intended status: Standards Track J. Drake Expires: March 16, 2013 Editors Juniper Networks B. Schlisser James Uttaro Y. Rekhter ATT Ravi Shekhar Juniper Networks Wim Hendrix Nabil Bitar Alcatel-Lucent Verizon Aldrin Isaac Bloomberg September 16, 2012 A Control Plane for Network Virtualized Overlays draft-drake-nvo3-evpn-control-plane-00 Abstract The purpose of this document is to describe how Ethernet Virtual Private Network (E-VPN) can be used as the control plane for Network Virtual Overlays. Currently this protocol is defined to act as the control plane for Virtual Extensible Local Area Network (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), MPLS or VLANs while maintaining their existing data plane encapsulations. The intent is that this protocol will be capable of extensions in the future to handle additinal data plane encapsulations and functions as needed. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November March 16, 2012. Nadeau & Drake, Editors Expires March 14, 2013 [Page 1] EVPN Control Plane September 14, 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2. E-VPN Attributes . . . . . . . . . . . . . . . . . . . . . . . 3. Constructing E-VPN routes . . . . . . . . . . . . . . . . . . 4. Interworking Capabilities . . . . . . . . . . . . . . . . . . 5. Active/Active Multihoming . . . . . . . . . . . . . . . . . . 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1. P-Tunnel Identification . . . . . . . . . . . . . . . . . . . 6.2. Ingress Replication . . . . . . . . . . . . . . . . . . . . . 6.3. PIM-SSM/SM Tree . . . . . . . . . . . . . . . . . . . . . . . 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10.2. Informative References . . . . . . . . . . . . . . . . . . Nadeau & Drake, Editors Expires March 14, 2013 [Page 2] EVPN Control Plane September 14, 2012 1. Introduction The purpose of this document is to describe a single control plane protocol control protocol that can be used for all types of data planes used in network virtualization overlays (NVOs). In particular, we describe how The Ethernet Virtual Private Network (E-VPN) protocol, as described in [I-D.draft-ietf-l2vpn-evpn-01], can be used as the control plane for Virtual Extensible Local Area Network (VXLAN) [I-D.draft-mahalingam-dutt-dcops-vxlan], Network Virtualization using Generic Routing Encapsulation (NVGRE) [I-D.draft-sridharan-virtualization-nvgre-00], MPLS or Ethernet VLANs. In all cases, the existing data plane encapsulations are maintained. Network Virtualization Overlays (NVOs), as described in [I-D.draft-ietf-nvo3-overlay-problem-statement], are intended to provide separate logical tenant networks over a common physical infrastructure in a data center environment. Both VXLAN and NVGRE are examples of technologies provide a data plane encapsulation which is used to transport a packet over the common physical infrastructure between NVO endpoints. 1.2. Acronyms CE Customer Edge. OAM Operation and Maintenance. PE Provider Edge. NVE Network Virtualization Endpoint NVGRE Network Virtualization Using Generic Routing Encapsulation NVO Network Virtual Overlay VNE Virtual Network Identifier VTEP VXLAN Tunnel End Point Nadeau & Drake, Editors Expires March 14, 2013 [Page 3] EVPN Control Plane September 14, 2012 VXLAN Virtual Extensible Local Area Network 2. E-VPN Attributes Both VXLAN and NVGRE are examples of technologies provide a data plane encapsulation which is used to transport a packet over the common physical infrastructure between NVO endpoints, VXLAN Tunnel End Point (VTEP) in VXLAN and Network Virtualization Endpoint (NVE) in NVGRE. Both of these technologies include the identifier of the specific NVO instance, Virtual Network Identifier (VNI) in VXLAN and Tenant ID in NVGRE, in each packet. E-VPN was originally designed to support the requirements detailed in [I-D.draft-ietf-l2vpn-evpn-req] and therefore has the following attributes which directly address control plane scaling and ease of deployment issues. 1) Control plane traffic is distributed with BGP and Broadcast and Multicast traffic is sent using a shared multicast tree or with ingress replication. 2) Control plane learning is used instead flooding unknown unicast and ARP packets. 3) Auto-discovery via BGP Route Reflectors is used. 4) Active-active multihoming is used. This allows a given customer device to have multiple attachment links to an E-VPN instance (EVI), via a Link Aggregation Group (LAG). This allows traffic to/from that customer to fully utilize all of these links. The set of attachment links to a given customer device is termed an Ethernet Segment and is typically identified with that customer device's MAC address. 5) Block withdraw is used. When a link between a customer device and an EVI fails, the other nodes in the EVI are notified via the withdrawal of a single E-VPN route regardless of how many MAC addresses are located at the customer device. 6) Route filtering and constrained route distribution are used to ensure that the control plane traffic for a given EVI is only distributed to those nodes in that EVI. 7) The internal identifier of a broadcast domain, the Ethernet Tag, is a 32 bit number, which is mapped into whatever Nadeau & Drake, Editors Expires March 14, 2013 [Page 4] EVPN Control Plane September 14, 2012 broadcast domain identifier, e.g., VLAN ID, is understood by the attaching CE device. This means that there are up to 4096 distinct VLAN IDs for each attaching Customer Edge (CE) device in a given EVI. Note that an EVI is equivalent to an NVO instance and that a Provider Edge (PE) is equivalent to a VTEP/NVE. 8) Because the design goal for NVO is millions of instances per common physical infrastructure, the scaling properties of the control plane for NVO are extremely important. The E-VPN and the extensions described herein, are designed with this level of scalability in mind. 3. Constructing E-VPN routes In E-VPN an MPLS label distributed by the egress PE via the E-VPN control plane and placed in the MPLS header of a given packet by the ingress PE is used upon receipt of that packet by the egress PE to determine to which EVI that packet is to be sent. This is very similar to the use of the VNI or Tenant ID by the egress VTEP or NVE, respectively, with the difference being that an MPLS label has local significance and is distributed by the E-VPN control plane, while a VNI or Tenant ID currently has global significance. In E-VPN, an MPLS label is carried in a three octet MPLS Label field, and consists of the twenty bit label. Both the VNI and Tenant ID are also three octets in length and so could be transparently carried in the MPLS label field of the E-VPN MAC Advertisement or Per EVI Ethernet AD route. This memo specifies that when E-VPN is to be used with a VXLAN or NVGRE data plane that a VNI or Tenant ID is twenty bits in length and may have either global or local significance, that the remaining four bits are reserved, and that the value advertised in the MPLS label field is to be treated as a three octet quantity to be placed directly in the VNI or tenant ID field of a packet. Note that because in this context an advertised VNI or Tenant ID may have local significance, the advertising PE may transparently use it to represent the VN or Tenant, a set of addresses within the VN or Tenant, or an individual address within the VN or Tenant. In order to indicate that a VXLAN or NVGRE data plane encapsulation rather than MPLS label stack encapsulation is to Nadeau & Drake, Editors Expires March 14, 2013 [Page 5] EVPN Control Plane September 14, 2012 be used, the Tunnel Encapsulation attribute defined in [RFC5512] is included with E-VPN MAC Advertisement or Per EVI Ethernet AD routes advertised by an egress PE. Two new values, one for VXLAN and one for NVGRE, will be defined. This same mechanism should be used to advertise MPLS or VLAN encapsulations when they are used. 4. Interworking Capabilities Through the presence of the Tunnel Encapsulation attribute, each PE within a given EVI will know whether the other PEs in that EVI support MPLS label stack, VXLAN, or NVGRE data plane encapsulation. This means that a given EVI can support multiple data plane encapsulations. This has the advantage of allowing interoperability between VXLAN, NVGRE, and E-VPN (and by extension L3VPNs). Note that an ingress PE must use the data plane encapsulation specified by a given egress PE in the subject MAC Advertisement or Per EVI Ethernet AD route when sending a packet to that PE. Further, an ingress node that uses shared multicast trees for sending Broadcast and Multicast traffic must maintain distinct trees for each different encapsulation type. 5. Active/Active Multihoming The base E-VPN protocol supports active/active multihoming. In order to prevent loops of Broadcast and Multicast packets, these packets need to carry two labels, one to identify the EVI to which the packet should be sent and one to identify the Ethernet Segment from which it was received. The latter label is termed the 'split horizon label' and when a Broadcast or Multicast packet is received by an egress PE, it uses that label to stop it from sending the packet back to the Ethernet Segment from which the packet was received. When using the VXLAN or NVGRE encapsulation, there is no field in the packet in which to carry the split horizon label. This memo specifies that an egress PE must use the sender MAC address to determine whether to send a received Broadcast or Multicast packet to a given Ethernet Segment. I.e., if the sender MAC address is associated with a given Ethernet Segment, the egress PE must not send the packet to that Ethernet Segment. Nadeau & Drake, Editors Expires March 14, 2013 [Page 6] EVPN Control Plane September 14, 2012 6. Multicast The base E-VPN protocol allows to use MPLS ingress replication or P2MP LSPs to send BUM traffic to other PEs. When VXLAN/NVGRE encapsulations are used with E-VPN, IP based ingress replication and IP multicast trees must be supported. 6.1. P-Tunnel Identification In order to identify the P-Tunnel used for sending broadcast, unknown unicast or multicast traffic, the Inclusive Multicast Ethernet Tag route MUST carry a "PMSI Tunnel Attribute" as specified in [RFC6513]. The following changes are required for VXLAN/NVGRE + When a PE that uses a P-Multicast tree for the P-tunnel wants to aggregate two or more Ethernet Tags in the same or different EVIs present on the PE onto the same tree. In this case, in addition to carrying the identity of the tree, the PMSI Tunnel attribute MUST carry a upstream assigned VNI or tenant ID in the MPLS Label field of the PMSI attribute which the PE has bound uniquely to the Ethernet Tag for the EVI associated with this update (as determined by its RTs). + If the PE that originates the advertisement uses ingress replication for the P-tunnel for E-VPN, the route MUST include the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication and Tunnel Identifier set to a routable address of the PE. The PMSI Tunnel attribute MUST carry a downstream assigned VNI or tenant ID in the MPLS Label field of the PMSI attribute. This identifier is used to demultiplex the broadcast, multicast or unknown unicast E-VPN traffic received over a MP2P tunnel by the PE. + If the PE that originates the advertisement uses IP multicast replication for the P-tunnel for E-VPN, the route MUST include the PMSI Tunnel attribute with the Tunnel Type set to PIM-SSM or PIM ASM Tree. When the Tunnel Type is set to Protocol Independent Multicast - Sparse Mode (PIM-SM) tree, the Tunnel Identifier is . The node that originated the attribute MUST use the address carried in the Sender Address as the source IP address for the IP/GRE (NVGRE) or IP/UDP (VXLAN) encapsulation of the BUM data. When the Tunnel Type is set to PIM-SSM tree, the Tunnel Nadeau & Drake, Editors Expires March 14, 2013 [Page 7] EVPN Control Plane September 14, 2012 Identifier is . The node that originates the attribute MUST use the address carried in the P-Root Node Address as the source IP address for the IP/GRE (NVGRE) or IP/UDP (VXLAN) encapsulation of the BUM data. According to [RFC4607], the group address can be locally allocated by the originating PE without any consideration for the group address used by other PE on the same MVPN. 6.2. Ingress Replication The PEs may use ingress replication for flooding unknown unicast, multicast or broadcast traffic. The VXLAN or NVGRE encapsulations are used with the VNI or tenant ID exchanged in the I-PMSI PMSI attribute. 6.3. PIM-SSM/SM Tree An PE may use an IP multicast "Inclusive" tree for sending an unknown unicast, broadcast or multicast packet or a "Selective" tree. For VXLAN or NVGRE the destination address of the UDP/GRE encapsulations use the multicast address of the PMSI attribute in the Inclusive Multicast Ethernet Tag route. When no aggregated trees are used the VNI or tenant ID is set to 0. 7. IANA Considerations 4.1 E-VPN Encapsulation Types IANA is requested to assign two values from the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry [RFC5512] as follows. - VxLan: Tunnel Type = TBD - NVGRE: Tunnel Type = TBD +1 8. Security Considerations This document uses IP-based tunnel technologies to support data plane transport. Consequently, the security considerations of those tunnel technologies apply. This document defines support for VxLan [I-D.draft-mahalingam-dutt-dcops-vxlan] and NVGRE [I-D.draft-sridharan-virtualization-nvgre-00]. The security considerations from those documents as well as Nadeau & Drake, Editors Expires March 14, 2013 [Page 8] EVPN Control Plane September 14, 2012 [RFC4301] apply to the data plane aspects of this document. As with [RFC5512], any modification of the information that is used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type may lead to user data packets getting misrouted, misdelivered, and/or dropped. More broadly, the security considerations for the transport of IP reachability information using BGP are discussed in [RFC4271] and [RFC4272], and are equally applicable for the extensions described in this document. If the integrity of the BGP session is not itself protected, then an imposter could mount a denial-of-service attack by establishing numerous BGP sessions and forcing an IPsec SA to be created for each one. However, as such an imposter could wreak havoc on the entire routing system, this particular sort of attack is probably not of any special importance. It should be noted that a BGP session may itself be transported over an IPsec tunnel. Such IPsec tunnels can provide additional security to a BGP session. The management of such IPsec tunnels is outside the scope of this document. 9. Acknowledgements 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March [RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", January 2006. [RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.", January 2006. [RFC4301] S. Kent, K. Seo., "Security Architecture for the Internet Protocol.", December 2005. [RFC4607] H. Holbrook, B. Cain., "Source-Specific Multicast for IP.", RFC4607, August 2006. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Nadeau & Drake, Editors Expires March 14, 2013 [Page 9] EVPN Control Plane September 14, 2012 Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009. [RFC6513] Rosen, E., et al., "Multicast in MPLS/BGP IP VPNs.", RFC6513, February 2012. [I-D.draft-ietf-l2vpn-evpn] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-raggarwa-sajassi-l2vpn-evpn-02.txt, work in progress, March, 2011. [I-D.draft-sridharan-virtualization-nvgre-00] Sridhavan, M., et al., "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan-virtualization-nvgre-01.txt, July 8, 2012. [I-D.draft-mahalingam-dutt-dcops-vxlan] Dutt, D., et al, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02.txt, August 22, 2012. [I-D.draft-ietf-nvo3-overlay-problem-statement] Narten, et al, "Problem Statement: Overlays for Network Virtualization", draft-ietf-nvo3-overlay-problem-statement-00.txt, 5-Sep-12. [I-D.draft-ietf-l2vpn-evpn-req] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)", draft-ietf-l2vpn-l2vpn-evpn- req-00.txt, work in progress, March 27, 2012. 10.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [I-D.lasserre-nvo3-framework] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for DC Network Virtualization", draft-lasserre-nvo3-framework-03 (work in progress), Nadeau & Drake, Editors Expires March 14, 2013 [Page 10] EVPN Control Plane September 14, 2012 July 2012. Editors' Addresses Thomas D. Nadeau Juniper Networks Email: tnadeau@juniper.net John E. Drake Juniper Networks Email: jnadeau@juniper.net Authors' Addresses Benson Schliser Juniper Networks Email: bensons@juniper.net Yakov Reckhter Juniper Networks Email: yakov@juniper.net Nabil Bitar Verizon Communications Email : nabil.n.bitar@verizon.com Ravi Shekhar Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: rshekhar@juniper.net Aldrin Isaac Bloomberg aldrin.isaac@gmail.com Wim Henderickx Alcatel-Lucent e-mail: wim.henderickx@alcatel-lucent.com James Uttaro AT&T 200 S. Laurel Avenue Middletown, NJ 07748 USA Email: uttaro@att.com Nadeau & Drake, Editors Expires March 14, 2013 [Page 11] EVPN Control Plane September 14, 2012 Nadeau & Drake, Editors Expires March 14, 2013 [Page 12]