Internet DRAFT - draft-sajassi-l2vpn-evpn-ipvpn-interop
draft-sajassi-l2vpn-evpn-ipvpn-interop
L2VPN Workgroup Ali Sajassi
INTERNET-DRAFT Samer Salam
Intended Status: Standards Track Keyur Patel
Cisco
Wim Henderickx
Alcatel-Lucent Nabil Bitar
Verizon
Yakov Rekhter
John Drake Aldrin Isaac
Juniper Bloomberg
Dennis Cai Jim Uttaro
Cisco AT&T
Expires: April 21, 2014 October 21, 2013
E-VPN and IP-VPN Integrated Solution
draft-sajassi-l2vpn-evpn-ipvpn-interop-02
Abstract
E-VPN can be an integral part of an Integrated Routing and Bridging
(IRB) solution which is capable of performing optimum unicast and
multicast forwarding not just for L2 traffic but also for L3 traffic.
This document describes how an IRB solution based on E-VPN can
interoperate seamlessly with the IP-VPN solution over MPLS and IP
networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
Sajassi et al. Expires April 21, 2014 [Page 1]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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.
Table of Contents
0 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Shortcomings of L2-Only Solution . . . . . . . . . . . . . . 4
1.2 Shortcomings of L3-Only Solution . . . . . . . . . . . . . . 5
1.3 Combined L2 & L3 Solution: IRB . . . . . . . . . . . . . . . 7
2 Seamless Interoperability with IP-VPN PEs . . . . . . . . . . . 7
2.1 Interoperability Use-Cases . . . . . . . . . . . . . . . . . 7
2.1.1 IP-VPN Clients Access to Cloud Services . . . . . . . . 8
2.1.2 Communication with IP-VPN NVEs . . . . . . . . . . . . . 8
2.1.3 Communication with IP-VPN GWs . . . . . . . . . . . . . 9
2.2 Characteristics of Seamless Interoperability . . . . . . . . 9
3 An IRB Solution Based on E-VPN . . . . . . . . . . . . . . . . 10
3.1 E-VPN PE Model for Seamless Interoperability . . . . . . . 10
3.2 IP-VPN BGP support on E-VPN PEs . . . . . . . . . . . . . . 13
3.3 Handling Multi-Destination Traffic: . . . . . . . . . . . . 13
3.2.1 Further optimization on RR . . . . . . . . . . . . . . . 14
5 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 14
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Sajassi et al. Expires April 21, 2014 [Page 2]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
0 Terminology
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].
Sajassi et al. Expires April 21, 2014 [Page 3]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
1 Introduction
E-VPN can be an integral part of an Integrated Routing and Bridging
(IRB) solution which is capable of performing optimum unicast and
multicast forwarding not just for L2 traffic (intra-subnet
forwarding), as described in the baseline draft [E-VPN], but also is
capable of performing optimum unicast and multicast forwarding for L3
traffic (inter-subnet forwarding) as described in [DC-MOBILITY].
Such IRB capability is of high relevance in data center applications
where performing either L2 or L3 forwarding alone may not be
sufficient.
1.1 Shortcomings of L2-Only Solution
Figure-1 depicts a Data Center Network (DCN) using IP overlay where
the PE functionality (and IP tunnel encapsulation) are either
residing on physical Top of Rack (ToR) switches or on virtual
hypervisor-based switches. In this document, we refer to these PE
devices (either physical or virtual) that provide IP overlay
tunneling as Network Virtualized Endpoints (NVEs). The DCN is
connected to the outside world via Data Center gateway (DC GW) nodes.
These nodes provide Data Center Interconnect and connectivity to
Internet and VPN customers.
Sajassi et al. Expires April 21, 2014 [Page 4]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
,---------.
,' `.
( IP/MPLS )
`. ,'
`-+------+'
+--+--+ +-+---+
|DC GW|+-+|DC GW|
+-+---+ +-----+
/
+----+---+ +---+-----+
| Core | | Core |
| IP SW | | IP SW |
+-+----`.+ +-+---+---+
/ .'
+---+--+ +-`.+--+ +--+----+
| ToR | | ToR | | ToR |
+-+--`.+ +-+-`.-+ +-+--+--+
/ / /
__/_ / /_ ____
:VSw : :VSw : :VSw : :VSw :
'----' '----' '----' '----'
| | | |
VM1 VM2 VM3 VM4
Figure 1: A typical DC network
If Network Virtualization Endpoints (NVEs) were only to provide L2
service (and forwarding), then for two VMs on two different subnets,
which need to communicate with each other, their packets need to be
forwarded to a router (either physical or virtual). In the above
diagram, the packets from the VMs need to be forwarded all the way to
one of the DC GW devices to perform L3 forwarding (based on end-host
IP header). This is generally sub-optimal because because the NVEs
associated with these two VMs may reside on the same physical device
(either the same server or the same ToR), in which case IP forwarding
can be performed locally within that device. Even if the two VMs are
located in different PODs within the same DC, and the traffic between
the two VMs requires transitioning a core switch, adding a GW for L3
switching adds additional hops to the data path. However, if an NVE
has IRB capability, then it can perform optimum L2 forwarding for
VMs' intra-subnet traffic and optimum L3 forwarding for VMs' inter-
subnet traffic, delivering optimum forwarding of unicast and
multicast packets at all time.
1.2 Shortcomings of L3-Only Solution
Sajassi et al. Expires April 21, 2014 [Page 5]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
Consider the scenario where a server is multi-homed to several ToR
devices using an Ethernet Link Aggregation Group with LACP [802.1AX]
and the VMs are connected to a virtual bridge on the server - i.e.,
there is an Ethernet bridge on the data path between the VMs and the
TORs. The ToRs are acting as NVEs. In this scenario, the LAG spans
across multiple PE devices (NVEs) and IGMP joins for the same
multicast group can arrives at both PEs. As such, DF election and
split-horizon filtering functions are required on the ToRs belonging
to the same LAG in order to avoid loops and packet duplication.
However, the existing IP-VPN solution does not provide such
capabilities that are available in the E-VPN solution. Therefore,
these ToR devices cannot be simple L3VPN PEs.
Assuming that the above shortcoming is addressed by adding DF
election and split-horizon filtering to IP-VPN, several other issues
will continue to exist with L3-only solution, particularly when
attempting to rely on L3 forwarding for intra-subnet traffic:
1. With L3 forwarding, in the absence of a default route, unknown IP
destination addresses are dropped. Furthermore, an IP default route
directs a particular traffic flow to a single next-hop or outbound
interface. This means that L3 forwarding cannot support the
forwarding semantics of a subnet broadcast.
2. With L3 forwarding, the MAC header is link-local and MAC addresses
are swapped on a hop-by-hop basis. This means that if an NVE resorts
to L3 forwarding of intra-subnet traffic, then all hosts within the
same subnet will receive traffic with the source MAC addresses set to
the NVE's address(es) instead of the originating hosts' MAC
addresses. As a result, any higher layer application which relies on
the source MAC address for identifying the communicating endpoint
will break, as it will no longer be able to tell apart the hosts
within the subnet based on their MAC addresses. This essentially
creates an address aliasing problem. A related issue, that results
from the MAC address being rewritten by the NVE, is that the hosts
can no longer perform duplicate MAC address detection.
3. With L3 forwarding, the IP TTL is decremented with every routed
hop. Some applications rely on this fundamental behavior to confine
traffic to the originating subnet, by setting the TTL to 1 on
transmission. Such applications will no longer work when intra-subnet
traffic is L3 forwarded.
4. IPv6 link-local addressing and duplicate address detection
[RFC4862] assumes and relies upon L2 connectivity within the subnet.
These mechanisms will break if the NVE performs L3 intra-subnet
forwarding.
Sajassi et al. Expires April 21, 2014 [Page 6]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
5. Finally last but not least, there are non-IP applications that
require L2 forwarding or there are applications that rely on end host
MAC addresses.
1.3 Combined L2 & L3 Solution: IRB
An IRB solution based on E-VPN can address the shortcomings of L2-
only as well as L3-only solutions, and provide optimum forwarding for
both inter and intra subnet switching, not only within a DCN but
across different DCNs. This E-VPN based solution fits well for DCN
overlay and DCI applications, but typical deployments will include
IP-VPN PEs that E-VPN PEs need to inter-operate with, such as:
1) IP-VPN client sites accessing cloud services
2) Communication with IP-VPN ToRs/VSw
3) Communication with IP-VPN GWs
Therefore, interoperability with IP-VPN PEs is of paramount
importance.
2 Seamless Interoperability with IP-VPN PEs
2.1 Interoperability Use-Cases
There are three use-cases that require interoperability between E-VPN
and IP-VPN. Those are discussed next.
Sajassi et al. Expires April 21, 2014 [Page 7]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
+---+ Enterprise Site 1
|PE1|----- H1
+---+
/
,---------. Enterprise Site 2
,' `. +---+
( MPLS/IP )---|PE2|----- H2
`. Core ,' +---+
`-+------+'
/ / \ \
+---+ \ \
,----|GW |. \ \
,' +---+ `. ,---------.
( DCN 1 ) ,' `.
`. ,' ( DCN2 )
`-+------+' `. ,'
__/__ `-+------+'
:NVE1 : __/__ __\__
'-----' :NVE2 : :NVE3 :
| | '-----' '-----'
VM1 VM | | |
VM3 VM4 VM5
Figure 2: Interoperability Use-Cases
2.1.1 IP-VPN Clients Access to Cloud Services
An SP offering IP-VPN services to an enterprise may wish to expand
its service offering to include Cloud services, while leveraging its
existing MPLS/IP infrastructure. The SP may deploy E-VPN on the NVE
in order to support L2 connectivity between VMs. The NVE function
could be implemented either on ToR switches or on servers. For this
scenario, interoperability between the E-VPN NVE and IP-VPN PE is
required in order to enable the new service offering. For example.,
consider Figure 2 where an IP-VPN service is being offered between
Enterprise sites 1 and 2. PE1 and PE2 act as IP-VPN PEs. Furthermore,
assume that DCN2 employ E-VPN (i.e. NVE2 and NVE3 are E-VPN PEs). For
the SP to offer Cloud service, interoperability between the IP-VPN
PEs and E-VPN NVEs is required.
2.1.2 Communication with IP-VPN NVEs
In certain deployments, where only L3 connectivity is required by
certain hosts (e.g. VMs), the NVEs associated with those hosts may
employ IP-VPN functionality only. An example of this would be running
the IP-VPN PE functionality on the hypervisor using the mechanisms of
[L3VPN-ENDSYSTEM]. Other VMs may require both L2 as well as L3
connectivity. The NVEs associated with those latter VMs would employ
Sajassi et al. Expires April 21, 2014 [Page 8]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
E-VPN. In order to allow for inter subnet communication between both
categories of VMs (i.e. those which require L3 connectivity only and
those requiring both L2 as well as L3 connectivity), interoperability
is required between the IP-VPN and the E-VPN NVEs.
To illustrate this with an example, consider the network of Figure 2.
VM5 requires L3 connectivity only, and subsequently NVE3 employs IP-
VPN PE functionality solely. VM3 requires both L2 and L3
connectivity, hence, NVE2 is employing E-VPN PE functionality. For
VM3 to be able to optimally communicate with VM5, seamless
interoperability between IP-VPN and E-VPN is required.
2.1.3 Communication with IP-VPN GWs
The DCN may be connected to the outside world via IP-VPN GW nodes.
These nodes provide Data Center Interconnect and connectivity to
Internet and VPN customers. The NVEs, in such scenarios, may have
default routes pointing to the GW. When the NVEs need to provide L2
as well as L3 connectivity to the associated VMs, they must run E-VPN
PE functionality. In order for the IP-VPN GW to learn reachability to
the VMs local to the DCN, interoperability is required between E-VPN
NVEs and the IP-VPN GW.
As an example, consider the network of Figure 2 where the GW of DCN1
is an IP-VPN gateway. If NVE1 employs E-VPN PE functionality, then
interoperability between E-VPN and IP-VPN is required for
connectivity between NVE1 and the GW.
2.2 Characteristics of Seamless Interoperability
Seamless interoperability between E-VPN and IP-VPN must meet the
following characteristics:
- Be completely transparent to the operation of the IP-VPN PE. In
other words, the IP-VPN PE would not even be aware that it is
communicating with an E-VPN endpoint. As such, no upgrade to the IP-
VPN nodes is required, not even a software upgrade.
- Be optimal from data-plane forwarding perspective. This means that
a gateway function is not required in order to normalize the
encapsulation to Ethernet in order to support the interoperability.
To elaborate on this: it is always possible to have an E-VPN PE
interoperate with an IP-VPN PE using a normalized Ethernet L2 hand-
off between the two. This however, requires that the MPLS
encapsulation be terminated on each PE, with the added overhead of
unnecessarily performing MPLS imposition and disposition on both PEs.
A side-effect of this gateway approach is that the host MAC addresses
will be visible to the E-VPN, and this may create scalability
Sajassi et al. Expires April 21, 2014 [Page 9]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
bottlenecks, especially in virtualized data center environments
because of sheer number of host MAC addresses.
>> get rid off normalizaiton stuff and instead describe what we mean
>>> check definition of optimal above and compare it with rekhter-vm-
mobility-issues
3 An IRB Solution Based on E-VPN
An IRB solution based on E-VPN can meet data center network
requirements in terms of:
>>> qualify that all the following bullets are needed when NVEs are
implemented on TORs
>>> make it explicit that this section is for NVE on TORs.
- Providing optimal forwarding for intra-subnet (L2) traffic.
- Providing optimal forwarding for inter-subnet (L3) traffic, by
avoiding the need for a centralized L3 GW. This is because the E-VPN
MAC Advertisement route can carry an IP address in addition to the
MAC address.
- Support multicast using ingress replication, in cases where
multicast applications are not required or dominant.
- Support for optimal multicast delivery through P2MP tunnels, when
required, to optimize DCN resources.
- Support for multi-homing with active/active redundancy and per-flow
load-balancing using multi-chassis LAG.
- Support for network-based as well as host-based overlay models.
- Support for consistent policy-based forwarding for both L2 and L3
forwarded traffic.
3.1 E-VPN PE Model for Seamless Interoperability
This section describes the PE data-plane model required to achieve
seamless interoperability.
The E-VPN PE establishes a many-to-one mapping between E-VPN EVIs and
an IP-VPN VRF (referred to as just a VRF in the subsequent texts).
For a given EVI, it is possible to have multiple associated bridge-
domains using the VLAN-aware bundling service interface, as defined
in [EVPN-REQ]. Each bridge-domain maps to a unique IP subnet within a
Sajassi et al. Expires April 21, 2014 [Page 10]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
VRF context. The following figure depicts the model where there are N
VRFs corresponding to N tenants, with each tenant having 2 EVIs and
up to M subnets (bridge domains) per EVI.
>>>> Either way, distributing the L3 edge to the NVE renders it
possible to avoid having an IP-VPN GW for the DCN.
Note that this PE model provides flexibility for a wide gamut of
deployment options. For example, one end of the spectrum would be
with a single EVI per tenant being mapped to a single VRF. Each EVI
hosts multiple bridge-domains (one bridge-domain per subnet). This
model allows for L2 traffic segregation between different subnets in
addition to L3 connectivity among those subnets, as long as global
Service VLANs are assigned per tenant (this uses VLAN-aware bundling
service in E-VPN). The other end of the spectrum is with multiple
EVIs per tenant all mapped to a single VRF. Each EVI hosts a single
bridge-domain in this latter case. This model allows for L2 traffic
segregation between subnets in addition to L3 connectivity among
those subnets without the need for globally assigned Service VLANs
(this uses VLAN-based service in E-VPN).
Sajassi et al. Expires April 21, 2014 [Page 11]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
+---------------------------------------------+
| |
| +-----------+ +-----------+ |
| | EVIn |---------| VRF n | |
| +------------+ | +------------+ | |
| | +-----+ | | | | | |
| | | BD1 | | | | | | |
| | +-----+ | | | VRF 1 | | |
| | .. +-------+ | | |
| | +-----+ | | | | | |
| | | BDm | | | | | | |
| | +-----+ | | | | | |
| | EVI 1 |-+ | | | |
| +------------+ | | | |
| | | | |
| +------------+ | | | |
| | EVIn*2 | | | | |
| +------------+ | | | | |
| | +-----+ | |-----| | | |
| | |BDm+1| | | | | | |
| | +-----+ | | | | | |
| | .. +-------+ | | |
| | +-----+ | | | | | |
| | |BDm*2| | | | | | |
| | +-----+ | | | | | |
| | EVI 2 |-+ | |--+ |
| +------------+ +------------+ |
| |
| E-VPN PE |
+---------------------------------------------+
Figure 3: E-VPN PE Model for Seamless Interoperability with IP-VPN
One way to visualize this model is to consider a bridged virtual
interface (BVI) to be associated with every bridge-domain in a given
EVI. The BVI is an L3 routed interface (hence terminates L2). All the
BVIs associated with a given EVI are placed in the same VRF.
The IP forwarding table in a given VRF is shared in between E-VPN and
IP-VPN. When an E-VPN MAC advertisement route is received by the PE,
the MAC address associated with the route is used to populate the
bridge-domain MAC table, whereas the IP address associated with the
route is used to populate the corresponding VRF. In other words, the
VRF table can be populated by both E-VPN as well as IP-VPN BGP
routes. For intra-subnet forwarding, the PE consults the bridge-
domain MAC table whereas for inter-subnet forwarding the PE performs
the lookup in the associated VRF.
Sajassi et al. Expires April 21, 2014 [Page 12]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
When an E-VPN packet is received by a PE, it decapsulates the MPLS
header and then performs a lookup on the destination MAC address. If
the MAC address corresponds to one of its BVI interfaces, the PE
deduces that the packet must be inter-subnet routed. Hence, the PE
performs an IP lookup in the associated VRF table. However, if the
destination MAC address does not correspond to a BVI, then the PE
concludes that this packet needs to be intra-subnet switched, and no
further IP lookup is needed.
3.2 IP-VPN BGP support on E-VPN PEs
The E-VPN PE learns host (e.g. VM) MAC addresses via normal bridge
learning, and host IP addresses either via snooping of control
traffic (e.g. ARP, DHCP..) or gleaning of data traffic. Once the PE
learns a new MAC/IP address tuple, it advertises two routes for that
tuple:
- An E-VPN MAC Advertisement route using the E-VPN AFI/SAFI and
associated NLRI, which is used to advertise reachability to other
remote E-VPN nodes. The MAC route advertises both the IP and MAC
addresses of the host.
- An IP-VPN route using IP-VPN AFI/SAFI and associated NLRIs, which
is used to advertise reachability to remote IP-VPN speakers. The IP-
VPN route advertises only the IP address of the end-station.
Given that on the E-VPN PEs there is a one-to-one mapping between an
E-VPN Instance (EVI) and a VRF, the same BGP RT and RD are used for
both E-VPN and IP-VPN routes. Received E-VPN routes carry both IP and
MAC addresses. The MAC addresses are injected into BD tables whereas
the IP addresses are injected into VRFs. When an E-VPN speaker
receives an IP-VPN route from a remote IP-VPN speaker, it installs
the associated IP address in the appropriate VRF. It should be noted
that when a MAC address is installed in the EVI, it is only installed
in a single BD associated with the subnet corresponding to the
Ethernet Tag encoded in the E-VPN MAC route.
If, for a given tenant, the IP-VPN PEs only need to share IP-VPN
routes for a subset of the subnets with their E-VPN PEs counterparts,
then one RT is used as a common RT between IP-VPN and E-VPN PEs for
the common subnets and a different one or more RTs are used by the E-
VPN PEs for the other tenant subnets that don't need to share routes
with the IP-VPN PEs. If further topology constraint is needed among
E-VPN and IP-VPN PEs, then instead of a common RT, one can use
additional RTs to satisfy the topology constraint.
3.3 Handling Multi-Destination Traffic:
Sajassi et al. Expires April 21, 2014 [Page 13]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
A key issue is how to handle multi-destination traffic, since E-VPN
uses an MPLS label for split-horizon, and the equivalent does not
exist in IP-VPN. This can be solved in two different ways, depending
on whether the network uses LSM or Ingress Replication:
For LSM, two different sets of P2MP multicast trees can be used by
the E-VPN PEs. One tree set encompasses only the IP-VPN endpoints
whereas the second set includes only the E-VPN speakers. When an E-
VPN PE receives a multi-destination frame, it sends a copy on each of
the two trees associated with a given EVI/VRF. When the PE sends
traffic on the IP-VPN tree, it does not include the split-horizon
label since the IP-VPN endpoints do not understand this label. Note
that this does not create any adverse side-effects because an E-VPN
PE and an IP-VPN will never be combined in the same Redundancy Group
(i.e. will never be multi-homed to the same Ethernet Segment), and as
such the split-horizon filtering is never required on the IP-VPN PEs.
For ingress replication, the E-VPN PE sends the right label stack
depending on the capability of the receiving (i.e. egress) PE. When
replicating to IP-VPN endpoints, the ingress PE simply does not
include any split-horizon labels.
3.2.1 Further optimization on RR
It is possible to optimize the number of routes that are advertised
by a given E-VPN speaker for a specific host address, by leveraging
extra intelligence on the BGP route reflector. A future version of
this document will describe the detailed procedures to achieve this.
5 Acknowledgement
6 Security Considerations
7 IANA Considerations
8 References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References
Sajassi et al. Expires April 21, 2014 [Page 14]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
[EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-00.txt, work in progress, February, 2012.
[DC-MOBILITY] Aggarwal et al., "Data Center Mobility based on
BGP/MPLS, IP Routing and NHRP", draft-raggarwa-data-center-mobility-
03.txt, work in progress, June, 2012.
Authors' Addresses
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Samer Salam
Cisco
595 Burrard Street
Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com
Keyur Patel
Cisco
170 West Tasman Drive
San Jose, CA 95134, US
Email: keyupate@cisco.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Aldrin Isaac
Bloomberg
aldrin.isaac@gmail.com
Wim Henderickx
Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.com
John E. Drake
Juniper Networks
Email: jnadeau@juniper.net
Sajassi et al. Expires April 21, 2014 [Page 15]
INTERNET DRAFT E-VPN Interoperability with IP-VPN October 21, 2013
Yakov Rekhter
Juniper Networks
Email: yakov@juniper.net
Sajassi et al. Expires April 21, 2014 [Page 16]
