Network Working Group A. Sajassi, Ed.
Internet-Draft G. Badoni
Intended status: Standards Track P. Warade
Expires: September 10, 2020 S. Pasupula
Cisco
J. Drake
Juniper
J. Rabadan
Nokia
March 9, 2020
L3 Aliasing and Mass Withdrawal Support for EVPN
draft-sajassi-bess-evpn-ip-aliasing-01
Abstract
This document proposes an extension to do Aliasing and Backup paths
for EVPN layer-3 routes in an IP-VRF. The solution leverages the use
of EVPN Ethernet Segments for an efficient layer-3 load-balancing and
fast convergence in case of failures.
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 https://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 September 10, 2020.
Copyright Notice
Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Sajassi, et al. Expires September 10, 2020 [Page 1]
Internet-Draft IP Aliasing Support for EVPN March 2020
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Ethernet Segments for Host Routes in Symmetric IRB . . . 3
1.2. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF
use-cases . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Conventions . . . . . . . . . . . . . . . 6
2. IP Aliasing and Backup Path . . . . . . . . . . . . . . . . . 7
2.1. Constructing Ethernet A-D per EVPN Instance Route . . . . 8
3. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 9
3.1. Constructing Ethernet A-D per Ethernet Segment Route . . 10
3.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . . 10
3.2. Avoiding convergence issues by synchronizing IP prefixes 10
3.3. Handling Silent Host MAC/IP route IP Aliasing . . . . . . 11
3.4. MAC Aging . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Determining Reachability to Unicast IP Addresses . . . . . . 12
4.1. Local Learning . . . . . . . . . . . . . . . . . . . . . 12
4.2. Remote Learning . . . . . . . . . . . . . . . . . . . . . 12
4.3. Constructing MAC/IP Address Advertisement . . . . . . . . 12
4.3.1. Route Resolution . . . . . . . . . . . . . . . . . . 12
5. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . 13
6. Load Balancing of Unicast Packets . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document proposes an extension to do Aliasing and Backup paths
for EVPN layer-3 routes in an IP-VRF. The solution leverages the use
of EVPN Ethernet Segments for an efficient layer-3 load-balancing and
fast convergence in case of failures in two use-cases:
a. Inter-subnet-forwarding for host routes in symmetric IRB
b. IP-VRF to IP-VRF host or prefix based forwarding
Sajassi, et al. Expires September 10, 2020 [Page 2]
Internet-Draft IP Aliasing Support for EVPN March 2020
1.1. Ethernet Segments for Host Routes in Symmetric IRB
Consider a pair of multi-homing PEs, PE1 and PE2, as illustrated in
Figure 1. Let there be a host H1 attached to them. Consider PE3 and
a host H3 attached to it.
+----------------+
| EVPN |
+------+ |
| PE1 | +---> |
+------+ | RT2 |
| | | IP1 +--+---+
+---+ | ES1 +------+ ESI1 | PE3 |
H1+--+CE1+--+ | | +-+H3
+---+ | +------+ | |
| | PE2 | +--+---+
+------+ | |
| | |
+------+ |
| |
+----------------+
Figure 1: Inter-subnet traffic between Multihoming PEs and Remote PE
With Asymmetric IRB [I-D.ietf-bess-evpn-inter-subnet-forwarding], if
H3 sends inter-subnet traffic to H1, routing will happen at PE3. PE3
will be attached to the destination IRB interface and will trigger
ARP/ND requests if it does not have an ARP/ND adjacency to H1. A
subsequent routing lookup will resolve the destination MAC to H1's
MAC address. Furthermore, H1's MAC will point to an ECMP EVPN
destination on PE1 and PE2, either due to host route advertisement
from both PE1 and PE2, or due to Ethernet Segment MAC Aliasing as
detailed in [RFC7432].
With Symmetric IRB [I-D.ietf-bess-evpn-inter-subnet-forwarding], if
H3 sends inter-subnet traffic to H1, a routing lookup will happen at
PE3's IP-VRF and this routing lookup will not yield the destination
IRB interface and therefore MAC Aliasing is not possible. In order
to have per-flow load balancing for H3's routed traffic to H1, an IP
ECMP list (to PE1/PE2) needs to be associated to H1's host route in
the IP-VRF route-table. If H1 is locally learned only at one of the
multi-homing PEs, PE1 or PE2, due to LAG hashing, PE3 will not be
able to build an IP ECMP list for the H1 host route.
With the extension described in this document, PE3's IP-VRF becomes
Ethernet-Segment-aware and builds an IP ECMP list for H1 based on the
Sajassi, et al. Expires September 10, 2020 [Page 3]
Internet-Draft IP Aliasing Support for EVPN March 2020
advertisement of ES1 along with H1 in a MAC/IP route and the
availability of ES1 on PE1 and PE2. In order to know that PE1 and
PE2 are attached to ES1, PE3 needs to import AD per ES and AD per EVI
routes that PE1/PE2 advertise for ES1. This extension is referred to
as "IP Aliasing".
If ES1 is configured as "single-active" as opposed to "all-active" in
the previous paragraph, this document describes how PE3 can build a
primary and backup IP path for H1.
In both cases, IP Aliasing and IP backup paths, fast convergence and
mass withdraw capabilities are supported in case of failures on the
multi-homing PEs.
1.2. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases
This document also allows the use of Ethernet Segments in EVPN IP
Prefix routes (or routes type 5)
[I-D.ietf-bess-evpn-prefix-advertisement] for the purpose of IP
Aliasing or IP backup paths.
As an example, consider the scenario in Figure 2 in which PE1 and PE2
are multi-homed to CE1. However, and contrary to CE1 in Figure 1, in
this case CE1 uses layer-3 links to get connected to PE1 and PE2 in
different BDs, and a BGP session established between CE1's loopback
address and PE1's IRB address.
In these use-cases, typically CE1 supports a single BGP session to
one of the PEs (through which it advertises a number of IP Prefixes
seating behind itself) and yet, it is desired that remote PEs (e.g.,
PE3) can build an IP ECMP list or backup IP list including additional
PEs (e.g., PE2 in Figure 2).
Sajassi, et al. Expires September 10, 2020 [Page 4]
Internet-Draft IP Aliasing Support for EVPN March 2020
+-----------------------+
| EVPN |
PE1 | |
+-------------------+ |
| IRB1 | |
| +---+ +------+ | -------> |
+-----------|BD1|---|IPVRF1| | RT5 |
eBGP | | +---+ | | | 50.0/24 | PE3
+------------------------>10.1 +------+ | ESI1 +--------------+
| | +-------------------+ |+------+ |
+-----+10.2 | | ^ ||IPVRF1| +---+|
| CE1 |-----+ ES1 | | || |-|BD3|--H4
| |-----+ | +----------|+------+ +---+|
+-----+20.2 | PE2 | +-----| |
lo1 | +--------------+----+ | +--------------+
1.1.1.1 | | IRB2 | | |
Prefixes: | | +---+ +------+ | | |
50.0/24 +-----------|BD2|---|IPVRF1| |<--+ |
60.0/24 | +---+ | | | |
| 20.1 +------+ | |
+-------------------+ |
| |
+-----------------------+
Figure 2: Layer-3 Multihoming PEs and Remote PE
In order to achieve IP Aliasing or IP Backup path from PE3, PE1 and
PE2 interfaces are associated to the same virtual Ethernet Segment
(ES1) even though they are attached to different BDs. All the IP
Prefixes learned from CE1 are installed in PE1's IP-VRF and
subsequently advertised from PE1 as EVPN IP Prefix routes encoding
ESI-1 in the Ethernet Segment field.
Upon configuration of ES1, both PE1 and PE2 advertise an AD per ES
route for ESI1, indicating if the ES works in single-active or all-
active mode, as per [RFC7432]. These AD per ES routes are sent along
with the set of route-targets of the IP-VRFs attached to the Ethernet
Segment.
In addition, both PEs advertise an AD per EVI route with the route-
target of IP-VRF1, indicating the availability of the IP-VRF to
forward routed IP traffic to CE1. PE3 will install the IP Prefix
routes associated to ESI1, where ESI1 is resolved to an IP ECMP list
(or IP primary and backup paths) formed upon the reception of the AD
routes for ESI1. As in the previous example, fast convergence and
mass withdrawal capabilities are supported based on the advertisement
and withdrawal of the AD per EVI/ES routes.
Sajassi, et al. Expires September 10, 2020 [Page 5]
Internet-Draft IP Aliasing Support for EVPN March 2020
1.3. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
- IRB: Integrated Routing and Bridging
- IRB Interface: A virtual interface that connects the bridging
module and the routing module on an NVE.
- BD: or Broadcast Domain. An EVI may be comprised of one BD (VLAN-
based or VLAN Bundle services) or multiple BDs (VLAN-aware Bundle
services).
- Bridge Table: An instantiation of a broadcast domain on a MAC-VRF.
- CE: Customer Edge device, e.g., a host, router, or switch.
- EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN.
- MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE.
- Ethernet Segment (ES): When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links, then
that set of links is referred to as an 'Ethernet segment'.
- Ethernet Segment Identifier (ESI): A unique non-zero identifier
that identifies an Ethernet segment is called an 'Ethernet Segment
Identifier'.
- LACP: Link Aggregation Control Protocol.
- PE: Provider Edge device.
- Single-Active Redundancy Mode: When only a single PE, among all
the PEs attached to an Ethernet segment, is allowed to forward
traffic to/from that Ethernet segment for a given VLAN, then the
Ethernet segment is defined to be operating in Single-Active
redundancy mode.
- All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward known unicast traffic to/from that
Sajassi, et al. Expires September 10, 2020 [Page 6]
Internet-Draft IP Aliasing Support for EVPN March 2020
Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode.
- AD per EVI: refers to the Auto-Discovery per EVPN instance routes
(type 1). Specified in [RFC7432], they allow for the auto-
discovery of all the EVIs attached to a given ES on a given PE.
- AD per ES: refers to the Auto-Discovery per ES routes (type 1).
Specified in [RFC7432], they allow for the auto-discovery of all
the Ethernet Segments attached to a given PE, as well as their
characteristics.
- VNF: Virtual Network Function.
2. IP Aliasing and Backup Path
MAC/IP routes are learned by PEs on the access side via a control
plane protocol like ARP/ND, whereas IP Prefix routes are learned by
the PEs via a routing protocol, typically BGP (ipv4/ipv6 families).
Without IP Aliasing, in case where a CE is multihomed to multiple PE
nodes using a LAG and is running in All-Active Redundancy Mode, the
Host IP will be learned and advertised in the MAC/IP Advertisement
only by the PE that receives the ARP packet. As a result, the remote
PE sees only one next-hop for the Host IP and forwards traffic to
that advertising PE. Hence, the remote PE is not be able to
effectively load balance the traffic towards the multihomed Ethernet
Segment.
In a similar way, where the CE is multihomed to multiple nodes using
a group of active layer-3 interfaces but it uses fewer routing
protocol adjacencies than multihoming PEs, the CE IP Prefix routes
will be learned and advertised by only the PE(s) that has(have) a
routing protocol adjacency with the CE. For example, if we consider
the scenario in Figure 2 PE3 sees only one next-hop for CE1 Prefix
routes and PE3 is not able to local balance the traffic to CE1.
To address this issue, the concept of Aliasing that was introduced
[RFC7432] can be extended for Layer 3 routes as well. The PE SHOULD
advertise reachability to an IP-VRF instance on a given ES for IP
routes using the existing AD per ES/EVI routes. In this case, the
EVPN instance is the IP-VRF table to which the host IP address or IP
Prefix belongs. This will henceforth be referred to as the IP AD per
ES/EVI route.
A remote PE that receives an IP route with a non reserved ESI SHOULD
consider it reachable by all PEs that have advertised the IP AD per
ES/EVI advertisement route for the IP-VRF. An IP AD per ES/EVI route
Sajassi, et al. Expires September 10, 2020 [Page 7]
Internet-Draft IP Aliasing Support for EVPN March 2020
is considered to be "for the IP-VRF" if it contains the IP-VRF route-
target(s).
The IP AD per ES route must have the Single-Active bit in the flags
of the ESI Label extended community set to 0 for Aliasing to take
effect. Otherwise the receiving PE will process the routes for
Primary and Backup IP paths.
The IP AD per ES route cannot be used for route forwarding until the
associated IP AD per ES route is received.
In case of Single-Active redundancy mode, the remote PE SHOULD use
the IP AD per EVI route EVPN Layer 2 attribute extended community as
mentioned in [RFC8214] in combination with the IP AD per ES route to
determine the Backup Path for the IP addresses for the given IP VRF
context. This alternate path SHOULD be installed as a backup path
for the IP address.
2.1. Constructing Ethernet A-D per EVPN Instance Route
This document proposes the advertisement of IP AD per EVI routes for
IP-VRFs to enable Aliasing or Backup paths for IP addresses. The
usage/construction of this route remains similar to that described in
[RFC7432] with a few notable exceptions as below.
- The Route-Distinguisher should be set to the corresponding IP-VRF
context.
- The Ethernet Tag should be set to 0.
- The IP AD per EVI/ES routes SHOULD carry one or more IP VRF Route-
Targets (RT) attributes.
- The IP AD per EVI route MUST carry the Router's MAC Extended
Community attribute [I-D.ietf-bess-evpn-prefix-advertisement] if
the encapsulation among the PE IP-VRFs correspond to that of an
Ethernet NVO tunnel.
- The MPLS Label usage SHOULD be used as described in [RFC7432] and
[RFC8365].
- In case of IP Aliasing, all the PEs that are attached to the same
ES will advertise P=1 in the Layer 2 attribute extended community
[RFC8214].
- When IP Primary/Backup paths are desired, the Primary PE will
advertise P=1 in the Layer 2 extended community, whereas the best
Backup PE will advertise P=0, B=1.
Sajassi, et al. Expires September 10, 2020 [Page 8]
Internet-Draft IP Aliasing Support for EVPN March 2020
o The Primary PE SHOULD be the PE that learns the IP prefix at
the access side.
o The Primary PE MAY be determined by policy or MAY be elected by
a DF Election as in [RFC8584]
It is important to note that the prefix for an IP AD per EVI and a
layer 2 AD per-EVI may be identical. However, since the Route-
Distinguisher (RD) of the IP AD per EVI is set to the corresponding
IP-VRF context and the RD of the layer-2 AD per EVI is set to the
corresponding MAC-VRF context, the import will happen in the
respective IP-VRFs and MAC-VRFs and hence, the prefix will not be
overwritten.
3. Fast Convergence for Routed Traffic
Host or Prefix reachability is learned via the BGP-EVPN control plane
over the MPLS/NVO network. All the host or prefix routes that are
connected behind an ES are advertised by the PEs belonging to the
redundancy group. A remote PE receiving these routes can loose
reachability from any of the PEs either due node reload or core
failure or access failure for that PE.
To alleviate this, EVPN defines a mechanism to efficiently and
quickly signal to remote PE nodes, the need to update their
forwarding tables upon the occurrence of a failure in connectivity to
an Ethernet segment. This is done by having each PE advertise a set
of one or more IP AD per ES routes for each locally attached Ethernet
segment (refer to Section 3.1 below for details on how these routes
are constructed). A PE may need to advertise more than one IP AD per
ES route for a given ES because the ES may be in a multiplicity of
IP-VRFs and the Route-Targets for all of these IP-VRFs may not fit
into a single route. Advertising a set of IP AD per ES routes for
the ES allows each route to contain a subset of the complete set of
Route Targets. Each IP AD per ES route is differentiated from the
other routes in the set by a different Route Distinguisher (RD).
Upon failure in connectivity to the attached ES, the PE withdraws the
corresponding set of IP AD per ES routes. This triggers all PEs that
receive the withdrawal to update their next-hop adjacencies for all
IP addresses associated with the Ethernet Segment in question, across
IP-VRFs. If no other PE has advertised an IP AD per ES route for the
same Ethernet Segment, then the PE that received the withdrawal
simply invalidates the IP entries for that segment. Otherwise, the
PE updates its next-hop adjacencies accordingly.
Sajassi, et al. Expires September 10, 2020 [Page 9]
Internet-Draft IP Aliasing Support for EVPN March 2020
These routes should be processed with higher priority than other EVPN
MAC/IP or IP Prefix route withdrawals upon failure. Similar priority
processing is needed even on the intermediate Route Reflectors.
This document is therefore addressing the mass withdrawal behavior
for routed traffic. For Layer 2 traffic, refer to Section 8.2 of
[RFC7432].
3.1. Constructing Ethernet A-D per Ethernet Segment Route
This section describes the procedures used to construct the Ethernet
A-D per ES route, which is used for fast convergence (as discussed in
Section 3). The usage/construction of this route remains similar to
that described in section 8.2.1. of [RFC7432] with a few notable
exceptions as explained in following sections.
3.1.1. Ethernet A-D Route Targets
Each IP Ethernet A-D per ES route MUST carry one or more Route
Targets (RTs). The set of IP AD routes per ES MUST carry the entire
set of IP-VRF RTs for all the IP-VRFs attached to the ES, in addition
to MAC VRF RTs for all the EVPN instances to which the Ethernet
Segment belongs.
3.2. Avoiding convergence issues by synchronizing IP prefixes
Consider a pair of multi-homing PEs, PE1 and PE2. Let there be a
host H1 attached to them. Consider PE3 and a host H3 attached to it.
If the host H1 is learned on both the PEs, the ECMP path list is
formed on PE3 pointing to (PE1/PE2). Traffic from H3 to H1 is not
impacted even if one of the PEs becomes unreachable as the path list
gets corrected upon receiving the mass withdrawal route (IP AD per ES
route).
In a case where H1 is locally learned only on PE1 due to LAG hashing
or a single routing protocol adjacency to PE1, at PE3, H1 has ECMP
path list (PE1/PE2) using Aliasing as described in this document.
Traffic from H3 can reach H1 via either PE1 or PE2.
On PE2, all the remote MAC/IP or IP Prefix routes belonging to the
same Ethernet Segment that are advertised by the ES peer (e.g., PE1)
should be synchronized and installed locally on PE2 but not
advertised as local routes by BGP-EVPN. When the traffic from H3
reaches PE2, PE2 will be able forward the traffic to H1 without any
convergence delay (caused by triggering ARP/ND to H1 or to the next-
hop to reach H1). The synchronization of the ES MAC/IP or IP Prefix
Sajassi, et al. Expires September 10, 2020 [Page 10]
Internet-Draft IP Aliasing Support for EVPN March 2020
routes across all PEs of the same Ethernet Segment is important to
solve convergence issues.
3.3. Handling Silent Host MAC/IP route IP Aliasing
Considering the example of Figure 1 for IP Aliasing, if the
reachability of PE1 is lost, PE3 will update the ECMP list for H1 to
PE2, upon receiving mass withdrawal from PE1. If host H1 is also
withdrawn from PE1, then the same route is withdrawn from PE2 and
PE3. Hence traffic from H3 to H1 is blackholed till H1 is re-learned
on PE2.
This blackholing can be much worse if the H1 behaves like a silent
host. IP address of H1 will not be re-learned on PE2 till H1 ARP/ND
messages or some traffic triggers ARP/ND for H1.
PE2 can detect the failure of PE1's reachability in different ways:
a. When core failure or node reboot happens on PE1, the next hop
tracking to PE1 in the underlay routing protocols can help detect
the failure..
b. Upon access failure, PE1 withdraws the IP AD per ES/EVI routes
and PE2 can use this as a trigger to detect failure.
Thus to avoid blackholing, when PE2 detects loss of reachability to
PE1, it should trigger ARP/ND requests for all remote IP prefixes
received from PE1 across all affected IP-VRFs. This will force host
H1 to reply to the solicited ARP/ND messages from PE2 and refresh
both MAC and IP for the corresponding host in its tables.
Even in core failure scenario on PE1, PE1 must withdraw all its local
layer-2 connectivity, as Layer-2 traffic should not be received by
PE1. So when ARP/ND is triggered from PE2 the replies from host H1
can only be received by PE2. Thus H1 will be learned as local route
and also advertised from PE2.
It is recommended to have a staggered or delayed deletion of the IP
routes from PE1, so that ARP/ND refresh can happen on PE2 before the
deletion.
3.4. MAC Aging
In the same example as in section 3.3, PE1 would do ARP/ND refresh
for H1 before it ages out. During this process, H1 on can age out
genuinely or due to the ARP/ND reply landing on PE2. PE1 must
withdraw the local entry from BGP when H1 entry ages out. PE1
Sajassi, et al. Expires September 10, 2020 [Page 11]
Internet-Draft IP Aliasing Support for EVPN March 2020
deletes the entry from the local forwarding only when there are no
remote synced entries.
4. Determining Reachability to Unicast IP Addresses
4.1. Local Learning
The procedures for local learning do not change from [RFC7432] or
[I-D.ietf-bess-evpn-prefix-advertisement].
4.2. Remote Learning
The procedures for remote learning do not change from [RFC7432] or
[I-D.ietf-bess-evpn-prefix-advertisement].
4.3. Constructing MAC/IP Address Advertisement
The procedures for constructing MAC/IP Address or IP Prefix
Advertisements do not change from [RFC7432] or
[I-D.ietf-bess-evpn-prefix-advertisement].
4.3.1. Route Resolution
If the ESI field is set to reserved values of 0 or MAX-ESI, the IP
route resolution MUST be based on the MAC/IP or IP Prefix route
alone.
If the ESI field is set to a non-reserved ESI, the IP route
resolution MUST happen only when both the MAC/IP or IP Prefix route
and the associated set of IP AD per ES routes have been received. To
illustrate this with an example, consider a pair of multi-homed PEs,
PE1 and PE2, connected to an all-active Ethernet Segment. A given
host with IP address H1 is learned by PE1 but not by PE2. When the
MAC/IP or IP Prefix advertisement route from PE1 and a set of IP AD
per ES and IP AD per EVI routes from PE1 and PE2 are received, then
(1) PE3 can forward traffic destined to H1 to both PE1 and PE2.
If after (1) PE1 withdraws the IP AD per ES route, then PE3 will
forward the traffic to PE2 only.
If after (1) PE2 withdraws the IP AD per ES route, then PE3 will
forward the traffic to PE1 only.
If after (1) PE1 withdraws the MAC/IP or IP Prefix route, then PE3
will do delayed deletion of H1, as described in section 3.3.
If after (1) PE2 advertised the MAC/IP or IP Prefix route, but PE1
withdraws it, PE3 will continue forwarding to both PE1 and PE2 as
Sajassi, et al. Expires September 10, 2020 [Page 12]
Internet-Draft IP Aliasing Support for EVPN March 2020
long as it has the IP AD per ES and the IP AD per EVI route from
both.
5. Forwarding Unicast Packets
Refer to Section 5 in [I-D.ietf-bess-evpn-inter-subnet-forwarding]
and [I-D.ietf-bess-evpn-prefix-advertisement].
6. Load Balancing of Unicast Packets
The procedures for load balancing of Unicast Packets do not change
from [RFC7432]
7. Security Considerations
The mechanisms in this document use EVPN control plane as defined in
[RFC7432]. Security considerations described in [RFC7432] are
equally applicable. This document uses MPLS and IP-based tunnel
technologies to support data plane transport. Security
considerations described in [RFC7432] and in [RFC8365] are equally
applicable.
8. IANA Considerations
9. Contributors
10. Acknowledgments
11. References
11.1. Normative References
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
Sajassi, et al. Expires September 10, 2020 [Page 13]
Internet-Draft IP Aliasing Support for EVPN March 2020
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
11.2. Informative References
[I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-08 (work in
progress), March 2019.
[I-D.ietf-bess-evpn-prefix-advertisement]
Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
bess-evpn-prefix-advertisement-11 (work in progress), May
2018.
Authors' Addresses
Ali Sajassi (editor)
Cisco
MILPITAS, CALIFORNIA 95035
UNITED STATES
Email: sajassi@cisco.com
G. Badoni
Cisco
MILPITAS, CALIFORNIA 95035
UNITED STATES
Email: gbadoni@cisco.com
Sajassi, et al. Expires September 10, 2020 [Page 14]
Internet-Draft IP Aliasing Support for EVPN March 2020
P. Warade
Cisco
MILPITAS, CALIFORNIA 95035
UNITED STATES
Email: pwarade@cisco.com
S. Pasupula
Cisco
MILPITAS, CALIFORNIA 95035
UNITED STATES
Email: surpasup@cisco.com
John E Drake
Juniper
Email: jdrake@juniper.net
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com
Sajassi, et al. Expires September 10, 2020 [Page 15]