EVPN Support for L3 Fast Convergence and Aliasing/Backup Path
draft-sajassi-bess-evpn-ip-aliasing-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Ali Sajassi , Gaurav Badoni , Priyanka Warade , S. Pasupula , John Drake , Jorge Rabadan | ||
| Last updated | 2021-06-08 | ||
| Replaced by | draft-ietf-bess-evpn-ip-aliasing | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sajassi-bess-evpn-ip-aliasing-02
Network Working Group A. Sajassi, Ed.
Internet-Draft G. Badoni
Intended status: Standards Track P. Warade
Expires: December 10, 2021 S. Pasupula
Cisco Systems
J. Drake, Ed.
Juniper
J. Rabadan, Ed.
Nokia
June 8, 2021
EVPN Support for L3 Fast Convergence and Aliasing/Backup Path
draft-sajassi-bess-evpn-ip-aliasing-02
Abstract
This document proposes an EVPN extension to allow several of its
multihoming functions, fast convergence and aliasing/backup path, to
be used in conjunction with inter-subnet forwarding.
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 December 10, 2021.
Copyright Notice
Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect
Sajassi, et al. Expires December 10, 2021 [Page 1]
Internet-Draft IP Aliasing Support for EVPN June 2021
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Ethernet Segments for Host Routes in Symmetric IRB . . . 3
1.2. Inter-subnet Forwarding for Prefix Routes in the
Interface-less IP-VRF-to-IP-VRF Model . . . . . . . . . . 4
1.3. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF
use-cases . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology and Conventions . . . . . . . . . . . . . . . 5
2. IP Aliasing and Backup Path . . . . . . . . . . . . . . . . . 6
2.1. Constructing the IP A-D per EVI Route . . . . . . . . . . 7
3. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 8
3.1. Constructing IP A-D per Ethernet Segment Route . . . . . 9
3.1.1. IP A-D per ES Route Targets . . . . . . . . . . . . . 9
3.2. Avoiding convergence issues by synchronizing IP prefixes 9
3.3. Handling Silent Host MAC/IP route for IP Aliasing . . . . 9
3.4. MAC Aging . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Determining Reachability to Unicast IP Addresses . . . . . . 10
4.1. Local Learning . . . . . . . . . . . . . . . . . . . . . 10
4.2. Remote Learning . . . . . . . . . . . . . . . . . . . . . 11
4.3. Constructing the IP Routes . . . . . . . . . . . . . . . 11
4.3.1. Route Resolution . . . . . . . . . . . . . . . . . . 11
5. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . 11
6. Load Balancing of Unicast Packets . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
This document proposes an EVPN extension to allow several of its
multihoming functions, fast convergence and aliasing/backup path, to
be used in conjunction with inter-subnet forwarding. It re-uses the
existing EVPN routes, the Ethernet A-D per ES and the Ethernet A-D
per EVI routes, which are used for these multihoming functions. In
particular, there are three use-cases that could benefit from the use
of these multihoming functions:
Sajassi, et al. Expires December 10, 2021 [Page 2]
Internet-Draft IP Aliasing Support for EVPN June 2021
a. Inter-subnet forwarding for host routes in symmetric IRB
[I-D.ietf-bess-evpn-inter-subnet-forwarding].
b. Inter-subnet forwarding for prefix routes in the interface-less
IP-VRF-to-IP-VRF model [I-D.ietf-bess-evpn-prefix-advertisement].
c. Inter-subnet forwarding for prefix routes when the ESI is used
exclusively as an L3 construct
[I-D.ietf-bess-evpn-prefix-advertisement].
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
Sajassi, et al. Expires December 10, 2021 [Page 3]
Internet-Draft IP Aliasing Support for EVPN June 2021
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
advertisement of ES1 along with H1 in a MAC/IP route and the
availability of ES1 on PE1 and PE2.
1.2. Inter-subnet Forwarding for Prefix Routes in the Interface-less
IP-VRF-to-IP-VRF Model
In this model there is no Overlay Index and hence no recursive
resolution of the IP Prefix route to either a MAC/IP Advertisement or
an Ethernet A-D per ES/EVI route, which means that the fast
convergence and aliasing/backup path functions are disabled. In a
sense it is already described in section 4.3 of
[I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case,
but that section does not describe aliasing. I.e., this document can
be considered to be adding the aliasing/backup path function to the
Bump-in-the-Wire Use-Case.
1.3. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases
This document also enables fast convergence and aliasing/backup path
to be used even when the ESI is used exclusively as an L3 construct.
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 the links between CE1 and PE1/PE2 are used exclusively for
L3 protocols and L3 forwarding in different BDs, and a BGP session
established between CE1's loopback address and PE1's IRB address.
In these use-cases, sometimes the CE 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 can
build an IP ECMP list or backup IP list including all the PEs multi-
homed to the same CE. For example, in Figure 2, CE1 has a single
eBGP neighbor, i.e., PE1. Load-balancing for traffic from CE1 to H4
can be accomplished by a default route with next-hops PE1 and PE2,
however, load-balancing from H4 to any of the prefixes attached to
CE1 would not be possible since only PE1 would advertise EVPN IP
Prefix routes for CE1's prefixes. This document provides a solution
so that PE3 considers PE2 as a next-hop in the IP ECMP list for CE1's
Sajassi, et al. Expires December 10, 2021 [Page 4]
Internet-Draft IP Aliasing Support for EVPN June 2021
prefixes, even if PE2 did not advertise the IP Prefix routes for
those prefixes in the first place.
+-----------------------+
| 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
1.4. 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: Integrated Bridging and Routing Interface. A
virtual interface that connects the Bridge Table and the IP-VRF on
an NVE.
- BD: 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.
Sajassi, et al. Expires December 10, 2021 [Page 5]
Internet-Draft IP Aliasing Support for EVPN June 2021
- CE: Customer Edge device, e.g., a host, router, or switch.s
- 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'.
- IP-VRF: A VPN Routing and Forwarding table for IP routes on an
NVE/PE. The IP routes could be populated by any routing protocol,
E.g., EVPN, IP-VPN and BGP PE-CE IP address families. An IP-VRF
is also an instantiation of a layer 3 VPN in an NVE/PE.
- IP route: An IP Prefix route or a MAC/IP Advertisement route that
contains a host route.
- 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
Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode.
- RT5: EVPN IP Prefix route, as specified in
[I-D.ietf-bess-evpn-prefix-advertisement].
2. IP Aliasing and Backup Path
In order to address the use-cases described in Section 1, above, this
document proposes that:
Sajassi, et al. Expires December 10, 2021 [Page 6]
Internet-Draft IP Aliasing Support for EVPN June 2021
1. A PE that is attached to a given ES will advertise a set of one
or more Ethernet A-D per ES routes for that ES. Each is termed
an 'IP A-D per ES' route and is tagged with the route targets
(RTs) for one or more of the IP-VRFs defined on it for that ES;
the complete set of IP A-D per ES routes contains the RTs for all
of the IP-VRFs defined on it for that ES.
A remote PE imports an IP A-D per ES route into the IP-VRFs
corresponding to the RTs with which the route is tagged. When
the complete set of IP A-D per ES routes has been processed, a
remote PE will have imported an IP A-D per ES route into each of
the IP-VRFs defined on it for that ES; this enables fast
convergence for each of these IP-VRFs.
2. A PE advertises for this ES, an Ethernet A-D Per EVI route for
each of the IP-VRFs defined on it. Each is termed an 'IP A-D per
EVI' route and is tagged with the RT for a given IP-VRF.
A remote PE imports an IP A-D per EVI route into the IP-VRF
corresponding to the RT with which the route is tagged. The
label contained in the route enables aliasing/backup path for the
routes in that IP-VRF.
To address the third use-case described in Section 1, where the links
between a CE and its multihomed PEs are used exclusively for L3
protocols and L3 forwarding, a PE uses the procedures described in 1)
and 2), above. The ESI is of type 4 [RFC7432] and set to the router
ID of the CE.
The processing of the IP A-D per ES and the IP A-D per EVI routes is
as defined in [RFC7432] and [RFC8365] except that the fast
convergence and aliasing/backup path functions apply to the routes
contained in an IP-VRF. In particular, a remote PE that receives an
IP route with a non-reserved ESI and the RT of a particular IP-VRF
SHOULD consider it reachable by every PE that has advertised an IP
A-D per ES and IP A-D per EVI route for that ESI and IP-VRF.
2.1. Constructing the IP A-D per EVI Route
The construction of the IP A-D per EVI route is the same as that of
the Ethernet A-D per EVI route, as described in [RFC7432], with the
following exceptions:
- The Route-Distinguisher is for the corresponding IP-VRF.
- The Ethernet Tag should be set to 0.
- The route SHOULD carry the RT of the corresponding IP-VRF.
Sajassi, et al. Expires December 10, 2021 [Page 7]
Internet-Draft IP Aliasing Support for EVPN June 2021
- The route MUST carry the PE's MAC Extended Community if the
encapsulation used between the PEs for inter-subnet forwarding is
an Ethernet NVO tunnel [I-D.ietf-bess-evpn-prefix-advertisement].
- The route SHOULD carry the Layer 2 Extended Community [RFC8214].
For all-active multihoming, all PEs attached to the specified ES
will advertise P=1. For backup path, the Primary PE will
advertise P=1 and the Backup PE will advertise P=0, B=1.
o The Primary PE SHOULD be a PE with a routing adjacency to the
attached CE.
o The Primary PE MAY be determined by policy or MAY be elected by
a DF Election as in [RFC8584].
3. Fast Convergence for Routed Traffic
Host or Prefix reachability is learned via the BGP-EVPN control plane
over the MPLS/NVO network. IP routes for a given ES are advertised
by one or more of the PEs attached to that ES. When one of these PEs
fails, a remote PE needs to quickly invalidate the IP routes received
from it.
To accomplish this, EVPN defined the fast convergence function
specified in [RFC7432]. This document extends fast convergence to
inter-subnet forwarding by having each PE advertise a set of one or
more IP A-D 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 A-D 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 A-D per ES routes for the ES
allows each route to contain a subset of the complete set of Route
Targets. Each IP A-D 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 A-D 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 A-D 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.
These routes should be processed with higher priority than IP route
withdrawals upon failure. Similar priority processing is needed even
on the intermediate Route Reflectors.
Sajassi, et al. Expires December 10, 2021 [Page 8]
Internet-Draft IP Aliasing Support for EVPN June 2021
3.1. Constructing IP A-D per Ethernet Segment Route
This section describes the procedures used to construct the IP 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. IP A-D per ES Route Targets
Each IP A-D per ES route MUST carry one or more Route Targets (RTs).
The set of IP A-D per ES routes MUST carry the entire set of IP-VRF
RTs for all the IP-VRFs defined on that ES.
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 fails as the path list gets corrected
upon receiving the withdrawal of the fast convergence route(s) (IP AD
per ES routes).
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.
PE2 should install local forwarding state for IP routes advertised by
other PEs attached to the same ES (i.e., PE1) but not advertise them
as local routes. 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 IP routes across all PEs of the same Ethernet
Segment is important to solve convergence issues.
3.3. Handling Silent Host MAC/IP route for IP Aliasing
Consider the example of Figure 1 for IP aliasing. If PE1 fails, PE3
will receive the withdrawal of the fast convergence route(s) and
update the ECMP list for H1 to be just PE2. When the IP route for H1
is also withdrawn, neither PE2 nor PE3 will have a route to H1, and
traffic from H3 to H1 is blackholed until PE2 learns H1 and
advertises an IP route for it.
Sajassi, et al. Expires December 10, 2021 [Page 9]
Internet-Draft IP Aliasing Support for EVPN June 2021
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 PE1 fails, the next hop tracking to PE1 in the underlay
routing protocols can help detect the failure.
b. Upon the failure of its link to CE1, PE1 will withdraw its IP A-D
route(s) 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 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
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].
Sajassi, et al. Expires December 10, 2021 [Page 10]
Internet-Draft IP Aliasing Support for EVPN June 2021
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 the IP Routes
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 IP route alone.
If the ESI field is set to a non-reserved ESI, the IP route
resolution MUST happen only when both the IP route and the associated
set of IP A-D 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 IP route from
PE1 and a set of IP A-D per ES and IP A-D 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 A-D per ES route, then PE3 will
forward the traffic to PE2 only.
If after (1) PE2 withdraws the IP A-D per ES route, then PE3 will
forward the traffic to PE1 only.
If after (1) PE1 withdraws the IP route, then PE3 will do delayed
deletion of H1, as described in Section 3.3.
If after (1) PE2 advertised the IP route, but PE1 withdraws it, PE3
will continue forwarding to both PE1 and PE2 as long as it has the IP
A-D per ES and the IP A-D 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].
Sajassi, et al. Expires December 10, 2021 [Page 11]
Internet-Draft IP Aliasing Support for EVPN June 2021
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
No 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>.
[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>.
Sajassi, et al. Expires December 10, 2021 [Page 12]
Internet-Draft IP Aliasing Support for EVPN June 2021
[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. E., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-13 (work in
progress), February 2021.
[I-D.ietf-bess-evpn-prefix-advertisement]
Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
bess-evpn-prefix-advertisement-11 (work in progress), May
2018.
Authors' Addresses
A. Sajassi (editor)
Cisco Systems
Email: sajassi@cisco.com
G. Badoni
Cisco Systems
Email: gbadoni@cisco.com
P. Warade
Cisco Systems
Email: pwarade@cisco.com
S. Pasupula
Cisco Systems
Email: surpasup@cisco.com
Sajassi, et al. Expires December 10, 2021 [Page 13]
Internet-Draft IP Aliasing Support for EVPN June 2021
J. Drake (editor)
Juniper
Email: jdrake@juniper.net
J. Rabadan (editor)
Nokia
777 Middlefield Road
Mountain View, CA 94043
USA
Email: jorge.rabadan@nokia.com
Sajassi, et al. Expires December 10, 2021 [Page 14]