Internet DRAFT - draft-jiang-bess-evpn-egress-frr
draft-jiang-bess-evpn-egress-frr
BESS Working Group J. He, Ed.
Internet-Draft X. Li
Intended status: Standards Track Z. Zhou
Expires: December 31, 2020 H. Qu
Ericsson
June 29, 2020
EVPN Egress Fast ReRoute
draft-jiang-bess-evpn-egress-frr-00
Abstract
Ethernet Virtual Private Network (EVPN) multi-homing accommodates
load balance, link/node redundancy and fast convergence. Once link
failure happens, egress traffic can be fast rerouted to multi-homed
peer(s) to reach CE. However, this fast reroute brings transient
loops among multi-homed peers. This document specifies a fast
reroute approach with loop prevention.
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 31, 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
He, et al. Expires December 31, 2020 [Page 1]
Internet-Draft EVPN Egress FRR June 2020
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Loop Prevention . . . . . . . . . . . . . . . . . . . . . 4
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Constructing EVPN Routes . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Ethernet Virtual Private Network (EVPN) multi-homing accommodates
load balance, link/node redundancy and fast convergence. Upon link
failure, the PE withdraws the corresponding set of Ethernet A-D per
ES routes, which triggers all PEs to switchover traffic towards other
multi-homed peers for the PE. However, failure propagation still
consumes much time. The switchover performance can be improved by
using local protection at the same time, called egress Fast ReRoute
(eFRR).
For example in figure 1, CE1 is multi-homed to PE1 and PE2 with All-
Active mode, CE2 and CE3 are single-homed to PE2 and PE3 separately.
EVPN VPLS is provided for CE1, CE2,and CE3.
In case link failure happens between CE1 and PE2, PE2 withdraws EAD/
ES route for this link which triggers PE3 to switchover traffic
towards CE1 from PE2 to PE1. At the same time, traffic towards CE1
via PE2 (CE2->CE1 or CE3->CE1) is rerouted to PE1 to reach CE1. The
local protection improves the traffic switchover performance.
+-----------+
/-------- PE1 | |
CE1(AA mode) | EVPN | PE3 --- CE3
\-------- PE2 | |
| +-----------+
CE2
Figure 1 EVPN All-Active multi-homing scenario
He, et al. Expires December 31, 2020 [Page 2]
Internet-Draft EVPN Egress FRR June 2020
[RFC8679] specifies a fast reroute approach for egress traffic
protection. It defines roles for routers and also procedures among
them. However, it only protect traffic from core and it does not
define how a unique service label is advertised. This document
describes a light weighted approach dedicated for EVPN service, while
adding protecting traffic from access link and defining the specific
service label advertisement behavior.
2. Terminology
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.
CE: Customer Edge device, e.g., a host, router, or switch.
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'.
EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN.
EVPN: Ethernet Virtual Private Network.
PE: Provider Edge device.
NVO: Network Virtualization Overlay.
VNI: VXLAN Network Identifier.
3. Approach
Using figure 1 as an example, when link failure happens between CE1
and PE2, on PE2 the rerouted traffic from CE (CE2->CE1 via PE2) is
encapsulated with the EVPN label advertised by PE1. For rerouted
traffic from EVPN core (CE3->CE1 via PE2), the EVPN label inside is
swapped to the one advertised by PE1 also.
The EVPN label is from the Ethernet Auto-Discovery Route per EVI or
MAC/IP Advertisement Route advertised by PE1. Which label to
encapsulate traffic towards PE1 is a local decision on PE2.
However, if CE1 fails, PE1 and PE2 try to reroute traffic to each
other, which leads to transient loop till EAD/ES withdrawal(s)
He, et al. Expires December 31, 2020 [Page 3]
Internet-Draft EVPN Egress FRR June 2020
received by PE1 and/or PE2. This document introduces a loop
prevention mechanism to solve the problem.
3.1. Loop Prevention
When advertise Ethernet Auto-Discovery Route per EVI or MAC/IP
Advertisement Route, PE1 allocates one dedicated EVPN label for all
PEs (e.g. PE2 here) which share the same multi-homed CE, while
allocates another one for all other PEs not multi-homed (e.g. PE3
here). Please note if EVPN VPWS, only Ethernet Auto-Discovery Route
per EVI is required.
When PE2 detects link towards CE1 fails (regardless of CE node
failure or only link failure), it encapsulates traffic towards CE1
using the dedicated EVPN label advertised by PE1 and reroutes to PE1.
On PE1, the multi-homed peer, based on the EVPN label encapsulated,
the rerouted traffic is identified as from peer. If PE1 detects link
towards CE1 fails, the traffic from peer will not be rerouted but
simply discarded. Thus loop is avoided. If no link failure, the
traffic from PE1 is forwarded to CE1.
The mechanism also works for NVO scenarios [RFC8365], where the label
mentioned above will be referred to as the VNI.
4. Procedures
4.1. Constructing EVPN Routes
In order to assign dedicated EVPN label for all PEs which share the
same multi-homed CE, when advertising Ethernet Auto-Discovery Route
per EVI or MAC/IP Advertisement Route, the PE MUST carry exactly one
ES-Import Route Target extended community. It MUST also carry
exactly one EVI-RT Extended Community (EC) as defined in
[I-D.ietf-bess-evpn-igmp-mld-proxy].
EVI-RT EC is an Extended Community that can be used to identify the
EVI with which an EVPN route is associated. But it is not a Route
Target Extended Community, is not visible to the RT Constrain
mechanism [RFC4684], and is not intended to influence the propagation
of EVPN routes by BGP.
The combination of the ES-Import RT and EVI-RT EC guarantees the EVPN
routes to be distributed only to PEs that share the same multi-homed
CE for a specific EVPN instance. If the EVPN route has no EVI-RT EC,
or has more than one EVI-RT EC, the PE MUST apply the "treat-as-
withdraw" procedure of [RFC7606].
He, et al. Expires December 31, 2020 [Page 4]
Internet-Draft EVPN Egress FRR June 2020
It is suggested to set a higher LOCAL_PREF value in the BGP message
for the EVPN routes, considering if another general EVPN route is
also advertised to all PEs, for example, through BGP Route Reflector.
5. IANA Considerations
No requests to the IANA by this document.
6. Security Considerations
Same security considerations as [RFC7432].
7. References
7.1. Normative References
[I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin,
"IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-
mld-proxy-05 (work in progress), April 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>.
[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>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[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>.
[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>.
He, et al. Expires December 31, 2020 [Page 5]
Internet-Draft EVPN Egress FRR June 2020
7.2. Informative References
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
Michel, C., and H. Chen, "MPLS Egress Protection
Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
<https://www.rfc-editor.org/info/rfc8679>.
Authors' Addresses
Jiang He (editor)
Ericsson
No. 5, Lize east street, Chaoyang district
Beijing 100102
CN
Email: jiang.he@ericsson.com
Xianmin Li
Ericsson
No. 5, Lize east street, Chaoyang district
Beijing 100102
CN
Email: xianmin.li@ericsson.com
Zhe Zhou
Ericsson
No. 5, Lize east street, Chaoyang district
Beijing 100102
CN
Email: zhe.zhou@ericsson.com
He, et al. Expires December 31, 2020 [Page 6]
Internet-Draft EVPN Egress FRR June 2020
Haifeng Qu
Ericsson
No. 5, Lize east street, Chaoyang district
Beijing 100102
CN
Email: haifeng.qu@ericsson.com
He, et al. Expires December 31, 2020 [Page 7]
