15. MAC Mobility
It is possible for a given host or end-station (as defined by its MAC
address) to move from one Ethernet segment to another; this is
referred to as 'MAC Mobility' or 'MAC move', and it is different from
the multihoming situation in which a given MAC address is reachable
via multiple PEs for the same Ethernet segment. In a MAC move, there
would be two sets of MAC/IP Advertisement routes -- one set with the
new Ethernet segment and one set with the previous Ethernet segment
-- and the MAC address would appear to be reachable via each of these
In order to allow all of the PEs in the EVPN instance to correctly
determine the current location of the MAC address, all advertisements
of it being reachable via the previous Ethernet segment MUST be
withdrawn by the PEs, for the previous Ethernet segment, that had
If local learning is performed using the data plane, these PEs will
not be able to detect that the MAC address has moved to another
Ethernet segment, and the receipt of MAC/IP Advertisement routes,
with the MAC Mobility extended community attribute, from other PEs
serves as the trigger for these PEs to withdraw their advertisements.
If local learning is performed using the control or management
planes, these interactions serve as the trigger for these PEs to
withdraw their advertisements.
In a situation where there are multiple moves of a given MAC,
possibly between the same two Ethernet segments, there may be
multiple withdrawals and re-advertisements. In order to ensure that
all PEs in the EVPN instance receive all of these correctly through
the intervening BGP infrastructure, introducing a sequence number
into the MAC Mobility extended community attribute is necessary.
In order to process mobility events correctly, an implementation MUST
handle scenarios in which sequence number wraparound occurs.
Every MAC mobility event for a given MAC address will contain a
sequence number that is set using the following rules:
- A PE advertising a MAC address for the first time advertises it
with no MAC Mobility extended community attribute.
- A PE detecting a locally attached MAC address for which it had
previously received a MAC/IP Advertisement route with a different
Ethernet segment identifier advertises the MAC address in a MAC/IP
Advertisement route tagged with a MAC Mobility extended community
attribute with a sequence number one greater than the sequence
number in the MAC Mobility extended community attribute of the
received MAC/IP Advertisement route. In the case of the first
mobility event for a given MAC address, where the received MAC/IP
Advertisement route does not carry a MAC Mobility extended
community attribute, the value of the sequence number in the
received route is assumed to be 0 for the purpose of this
- A PE detecting a locally attached MAC address for which it had
previously received a MAC/IP Advertisement route with the same
non-zero Ethernet segment identifier advertises it with:
1. no MAC Mobility extended community attribute, if the received
route did not carry said attribute.
2. a MAC Mobility extended community attribute with the sequence
number equal to the highest of the sequence number(s) in the
received MAC/IP Advertisement route(s), if the received route(s)
is (are) tagged with a MAC Mobility extended community
- A PE detecting a locally attached MAC address for which it had
previously received a MAC/IP Advertisement route with the same zero
Ethernet segment identifier (single-homed scenarios) advertises it
with a MAC Mobility extended community attribute with the sequence
number set properly. In the case of single-homed scenarios, there
is no need for ESI comparison. ESI comparison is done for
multihoming in order to prevent false detection of MAC moves among
the PEs attached to the same multihomed site.
A PE receiving a MAC/IP Advertisement route for a MAC address with a
different Ethernet segment identifier and a higher sequence number
than that which it had previously advertised withdraws its MAC/IP
Advertisement route. If two (or more) PEs advertise the same MAC
address with the same sequence number but different Ethernet segment
identifiers, a PE that receives these routes selects the route
advertised by the PE with the lowest IP address as the best route.
If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP. If its own route is not the best one, it
will withdraw the route.
15.1. MAC Duplication Issue
A situation may arise where the same MAC address is learned by
different PEs in the same VLAN because of two (or more) hosts being
misconfigured with the same (duplicate) MAC address. In such a
situation, the traffic originating from these hosts would trigger
continuous MAC moves among the PEs attached to these hosts. It is
important to recognize such a situation and avoid incrementing the
sequence number (in the MAC Mobility extended community attribute) to
infinity. In order to remedy such a situation, a PE that detects a
MAC mobility event via local learning starts an M-second timer (with
a default value of M = 180), and if it detects N MAC moves before the
timer expires (with a default value of N = 5), it concludes that a
duplicate-MAC situation has occurred. The PE MUST alert the operator
and stop sending and processing any BGP MAC/IP Advertisement routes
for that MAC address until a corrective action is taken by the
operator. The values of M and N MUST be configurable to allow for
flexibility in operator control. Note that the other PEs in the EVPN
instance will forward the traffic for the duplicate MAC address to
one of the PEs advertising the duplicate MAC address.
15.2. Sticky MAC Addresses
There are scenarios in which it is desired to configure some MAC
addresses as static so that they are not subjected to MAC moves. In
such scenarios, these MAC addresses are advertised with a MAC
Mobility extended community where the static flag is set to 1 and the
sequence number is set to zero. If a PE receives such advertisements
and later learns the same MAC address(es) via local learning, then
the PE MUST alert the operator.
16. Multicast and Broadcast
The PEs in a particular EVPN instance may use ingress replication or
P2MP LSPs to send multicast traffic to other PEs.
16.1. Ingress Replication
The PEs may use ingress replication for flooding BUM traffic as
described in Section 11 ("Handling of Multi-destination Traffic"). A
given broadcast packet must be sent to all the remote PEs. However,
a given multicast packet for a multicast flow may be sent to only a
subset of the PEs. Specifically, a given multicast flow may be sent
to only those PEs that have receivers that are interested in the
multicast flow. Determining which of the PEs have receivers for a
given multicast flow is done using explicit tracking per [RFC7117].
16.2. P2MP LSPs
A PE may use an "Inclusive" tree for sending a BUM packet. This
terminology is borrowed from [RFC7117].
A variety of transport technologies may be used in the service
provider (SP) network. For Inclusive P-multicast trees, these
transport technologies include point-to-multipoint LSPs created by
RSVP-TE or Multipoint LDP (mLDP).
16.2.1. Inclusive Trees
An Inclusive tree allows the use of a single multicast distribution
tree, referred to as an Inclusive P-multicast tree, in the SP network
to carry all the multicast traffic from a specified set of EVPN
instances on a given PE. A particular P-multicast tree can be set up
to carry the traffic originated by sites belonging to a single EVPN
instance, or to carry the traffic originated by sites belonging to
several EVPN instances. The ability to carry the traffic of more
than one EVPN instance on the same tree is termed 'Aggregation', and
the tree is called an Aggregate Inclusive P-multicast tree or
Aggregate Inclusive tree for short. The Aggregate Inclusive tree
needs to include every PE that is a member of any of the EVPN
instances that are using the tree. This implies that a PE may
receive BUM traffic even if it doesn't have any receivers that are
interested in receiving that traffic.
An Inclusive or Aggregate Inclusive tree as defined in this document
is a P2MP tree. A P2MP tree is used to carry traffic only for EVPN
CEs that are connected to the PE that is the root of the tree.
The procedures for signaling an Inclusive tree are the same as those
in [RFC7117], with the VPLS A-D route replaced with the Inclusive
Multicast Ethernet Tag route. The P-tunnel attribute [RFC7117] for
an Inclusive tree is advertised with the Inclusive Multicast Ethernet
Tag route as described in Section 11 ("Handling of Multi-destination
Traffic"). Note that for an Aggregate Inclusive tree, a PE can
"aggregate" multiple EVPN instances on the same P2MP LSP using
upstream labels. The procedures for aggregation are the same as
those described in [RFC7117], with VPLS A-D routes replaced by EVPN
Inclusive Multicast Ethernet Tag routes.
This section describes failure recovery from different types of
17.1. Transit Link and Node Failures between PEs
The use of existing MPLS fast-reroute mechanisms can provide failure
recovery on the order of 50 ms, in the event of transit link and node
failures in the infrastructure that connects the PEs.
17.2. PE Failures
Consider a host CE1 that is dual-homed to PE1 and PE2. If PE1 fails,
a remote PE, PE3, can discover this based on the failure of the BGP
session. This failure detection can be in the sub-second range if
Bidirectional Forwarding Detection (BFD) is used to detect BGP
session failures. PE3 can update its forwarding state to start
sending all traffic for CE1 to only PE2.
17.3. PE-to-CE Network Failures
If the connectivity between the multihomed CE and one of the PEs to
which it is attached fails, the PE MUST withdraw the set of Ethernet
A-D per ES routes that had been previously advertised for that ES.
This enables the remote PEs to remove the MPLS next hop to this
particular PE from the set of MPLS next hops that can be used to
forward traffic to the CE. When the MAC entry on the PE ages out,
the PE MUST withdraw the MAC address from BGP.
When an Ethernet tag is decommissioned on an Ethernet segment, then
the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for
the <ESI, Ethernet tags> that are impacted by the decommissioning.
In addition, the PE MUST also withdraw the MAC/IP Advertisement
routes that are impacted by the decommissioning.
The Ethernet A-D per ES routes should be used by an implementation to
optimize the withdrawal of MAC/IP Advertisement routes. When a PE
receives a withdrawal of a particular Ethernet A-D route from an
advertising PE, it SHOULD consider all the MAC/IP Advertisement
routes that are learned from the same ESI as in the Ethernet A-D
route from the advertising PE as having been withdrawn. This
optimizes the network convergence times in the event of PE-to-CE
18. Frame Ordering
In a MAC address, if the value of the first nibble (bits 8 through 5)
of the most significant octet of the destination MAC address (which
follows the last MPLS label) happens to be 0x4 or 0x6, then the
Ethernet frame can be misinterpreted as an IPv4 or IPv6 packet by
intermediate P nodes performing ECMP based on deep packet inspection,
thus resulting in load balancing packets belonging to the same flow
on different ECMP paths and subjecting those packets to different
delays. Therefore, packets belonging to the same flow can arrive at
the destination out of order. This out-of-order delivery can happen
during steady state in the absence of any failures, resulting in
significant impact on network operations.
In order to avoid any such misordering, the following rules are
- If a network uses deep packet inspection for its ECMP, then the
"Preferred PW MPLS Control Word" [RFC4385] SHOULD be used with the
value 0 (e.g., a 4-octet field with a value of zero) when sending
EVPN-encapsulated packets over an MP2P LSP.
- If a network uses entropy labels [RFC6790], then the control word
SHOULD NOT be used when sending EVPN-encapsulated packets over an
- When sending EVPN-encapsulated packets over a P2MP LSP or P2P LSP,
then the control word SHOULD NOT be used.
19. Security Considerations
Security considerations discussed in [RFC4761] and [RFC4762] apply to
this document for MAC learning in the data plane over an Attachment
Circuit (AC) and for flooding of unknown unicast and ARP messages
over the MPLS/IP core. Security considerations discussed in
[RFC4364] apply to this document for MAC learning in the control
plane over the MPLS/IP core. This section describes additional
As mentioned in [RFC4761], there are two aspects to achieving data
privacy and protecting against denial-of-service attacks in a VPN:
securing the control plane and protecting the forwarding path.
Compromise of the control plane could result in a PE sending customer
data belonging to some EVPN to another EVPN, or black-holing EVPN
customer data, or even sending it to an eavesdropper, none of which
are acceptable from a data privacy point of view. In addition,
compromise of the control plane could provide opportunities for
unauthorized EVPN data usage (e.g., exploiting traffic replication
within a multicast tree to amplify a denial-of-service attack based
on sending large amounts of traffic).
The mechanisms in this document use BGP for the control plane.
Hence, techniques such as those discussed in [RFC5925] help
authenticate BGP messages, making it harder to spoof updates (which
can be used to divert EVPN traffic to the wrong EVPN instance) or
withdrawals (denial-of-service attacks). In the multi-AS backbone
options (b) and (c) [RFC4364], this also means protecting the
inter-AS BGP sessions between the Autonomous System Border Routers
(ASBRs), the PEs, or the Route Reflectors.
Further discussion of security considerations for BGP may be found in
the BGP specification itself [RFC4271] and in the security analysis
for BGP [RFC4272]. The original discussion of the use of the TCP MD5
signature option to protect BGP sessions is found in [RFC5925], while
[RFC6952] includes an analysis of BGP keying and authentication
Note that [RFC5925] will not help in keeping MPLS labels private --
knowing the labels, one can eavesdrop on EVPN traffic. Such
eavesdropping additionally requires access to the data path within an
SP network. Users of VPN services are expected to take appropriate
precautions (such as encryption) to protect the data exchanged over
One of the requirements for protecting the data plane is that the
MPLS labels be accepted only from valid interfaces. For a PE, valid
interfaces comprise links from other routers in the PE's own AS. For
an ASBR, valid interfaces comprise links from other routers in the
ASBR's own AS, and links from other ASBRs in ASes that have instances
of a given EVPN. It is especially important in the case of multi-AS
EVPN instances that one accept EVPN packets only from valid
It is also important to help limit malicious traffic into a network
for an impostor MAC address. The mechanism described in Section 15.1
shows how duplicate MAC addresses can be detected and continuous
false MAC mobility can be prevented. The mechanism described in
Section 15.2 shows how MAC addresses can be pinned to a given
Ethernet segment, such that if they appear behind any other Ethernet
segments, the traffic for those MAC addresses can be prevented from
entering the EVPN network from the other Ethernet segments.
Special thanks to Yakov Rekhter for reviewing this document several
times and providing valuable comments, and for his very engaging
discussions on several topics of this document that helped shape this
document. We would also like to thank Pedro Marques, Kaushik Ghosh,
Nischal Sheth, Robert Raszuk, Amit Shukla, and Nadeem Mohammed for
discussions that helped shape this document. We would also like to
thank Han Nguyen for his comments and support of this work. We would
also like to thank Steve Kensil and Reshad Rahman for their reviews.
We would like to thank Jorge Rabadan for his contribution to
Section 5 of this document. We would like to thank Thomas Morin for
his review of this document and his contribution of Section 8.6.
Many thanks to Jakob Heitz for his help to improve several sections
of this document.
We would also like to thank Clarence Filsfils, Dennis Cai, Quaizar
Vohra, Kireeti Kompella, and Apurva Mehta for their contributions to
Last but not least, special thanks to Giles Heron (our WG chair) for
his detailed review of this document in preparation for WG Last Call
and for making many valuable suggestions.
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document: