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 <Sender Address, P-Multicast Group>.
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 <P-Root Node Address, P-Multicast Group>. 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]