BESS WG Yubao. Wang
Internet-Draft ZTE Corporation
Intended status: Standards Track April 20, 2020
Expires: October 22, 2020
EVPN Egress Protection
draft-wang-bess-evpn-egress-protection-00
Abstract
A fast reroute framework for egress node protection is specified by
[RFC8679] . But it cannot be applied to VXLAN EVPN directly. This
document specifies a mechanism to apply Egress Node Protection to
VXLAN EVPN nodes and apply Egress Link Protection to EVPN EAD/EVI
routes.
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 October 22, 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
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.
Wang Expires October 22, 2020 [Page 1]
Internet-Draft EVPN Egress Protection April 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 2
2. Detailed Problem and Solution Requirement . . . . . . . . . . 4
3. Encoding the Originating Router Address . . . . . . . . . . . 6
4. Control Plane Processing . . . . . . . . . . . . . . . . . . 6
5. Protection Procedures . . . . . . . . . . . . . . . . . . . . 7
5.1. EVPN Egress Node Protection (EENP) . . . . . . . . . . . 7
5.1.1. BUM Forwarding Protection . . . . . . . . . . . . . . 7
5.1.2. Unicast Forwarding Protection . . . . . . . . . . . . 7
5.2. Egress ESI Link Protection (EELP) . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
A principal feature of EVPN is the ability to support multi-homing
from a customer equipment (CE) to multiple PE/VTEP with Ethernet
segment (ES) links. This draft specifies a VXLAN gateway mechanism
to simplify VTEP processing in the dual-homed case and enhance EVPN
convergency on egress failures.
1.1. Terminology and Acronyms
This document uses the following acronyms and terms:
All-Active Redundancy Mode - When a device is multihomed to a group
of two or more PEs and when all PEs in such redundancy group can
forward traffic to/from the multihomed device or network for a given
VLAN.
Backup egress router - Given an egress-protected tunnel and its
egress router, this is another router that has connectivity with all
or a subset of the destinations of the egress-protected services
carried by the egress-protected tunnel.
BUM - Broadcast, Unknown unicast, and Multicast.
CE - Customer Edge equipment.
DCI - Data Center Interconnect.
Wang Expires October 22, 2020 [Page 2]
Internet-Draft EVPN Egress Protection April 2020
EELP bypass tunnel - Egress ESI Link Protection bypass tunnel - A
tunnel used to reroute service packets upon an egress ESI link
failure.
Egress failure - An egress node failure or an egress link failure.
Egress link failure - A failure of the egress link (e.g., PE-CE link,
attachment circuit) of a service.
Egress loopback - the loopback interface on the Egress router, whose
IP address is the destination of the Egress-protected tunnel.
Egress node failure - A failure of an egress router.
Egress router - A router at the egress endpoint of a tunnel. It
hosts service instances for all the services carried by the tunnel
and has connectivity with the destinations of the services.
Egress-protected tunnel - A tunnel whose egress router is protected
by a mechanism according to this framework. The egress router is
hence called a protected egress router.
Egress-protected EVI - An EVPN MAC-VRF or IP-VRF that is carried by
an egress-protected tunnel and hence protected by a mechanism
according to this framework.
Egress-protecting tunnel - A VXLAN tunnel whose destination IP
address is the same value as the Egress-protected tunnel. The
Egress-protecting tunnel is constructed on the Protector not on the
Egress router. The egress router of the egress-protecting tunnel is
the protector. Note that from the view of the ingress router the
egress-protecting tunnel and the egress-protected tunnel is the same
tunnel.
ESI - Ethernet Segment Identifier - A unique non-reserved identifier
that identifies an Ethernet segment.
OPE - Originating PE - the original Router of an EVPN route.
PE - Provider Edge equipment.
PLR - A router at the point of local repair. In egress node
protection, it is the penultimate hop router on an egress-protected
tunnel. In egress link protection, it is the egress router of the
egress- protected tunnel.
Wang Expires October 22, 2020 [Page 3]
Internet-Draft EVPN Egress Protection April 2020
Protector - A role acted by a router as an alternate of a protected
egress router, to handle service packets in the event of an egress
failure. A protector is physically independent of the egress router.
Protector loopback - the loopback interface on the Protector, whose
IP address is the destination of the Egress-protected tunnel.
Single-Active Redundancy Mode - When a device or a network is
multihomed to a group of two or more PEs and when only a single PE in
such a redundancy group can forward traffic to/from the multihomed
device or network for a given VLAN.
VTEP - VXLAN Tunnel End Point.
VXLAN - Virtual eXtensible Local Area Network [RFC7348].
2. Detailed Problem and Solution Requirement
In the scenario illustrated in Figure 1, where an CE1 is dual-homed
to VTEP1 and VTEP2 to access the VXLAN network, which enhances
network access reliability. When one VTEP fails, services can be
rapidly switched to the other VTEP, minimizing the impact on
services.
As shown in Figure 1, the VTEP address of VTEP1 is IP1 and the VTEP
address of VTEP2 is IP2, the VTEP address of VTEP3 is IP3, they are
three different IP addresses. The BGP update-source of VTEP1 is
IP10, of VTEP2 is IP20, and of VTEP3 is IP30. Note that IP1 may be
the same as IP10, IP2 may be the same as IP20, IP3 may be the same as
IP30.
Wang Expires October 22, 2020 [Page 4]
Internet-Draft EVPN Egress Protection April 2020
+-------+
----------------------- | VTEP3 |
^ | (IP3) |
| +-------+
| / \
| / \
VXLAN Tunnels / \
| / \
| / Egress \
| +----------+ protection +-----------+
v | IP1_E | | IP2_E |
--------- | |--------------| | VTEP2
| IP2_P | EELP bypass | IP1_P | (IP2)
+--+----+--+ +--+-----+--+
VTEP1 | | ES2 | |
(IP1) | +--------+ +--------+ |
| ES1 | | | ES3
| | | |
CE1 CE2 CE3
Figure 1: Egress Protection for VXLAN EVPN
From the view of VTEP3, the VXLAN tunnel to IP1 is the tunnel for
VTEP1, the VXLAN tunnel to IP2 is the tunnel for VTEP2. But now we
add a loopback interface on VTEP2 and let its IP address be IP1 too,
add another loopback interface on VTEP1 and let its IP address be IP2
too. Then we call there is an egress loopback for IP1 on VTEP1
called IP1_E, and there is a protector loopback for IP1 on VTEP2
called IP1_P, and there is an egress loopback for IP2 on VTEP2 called
IP2_E, and there is a protector loopback for IP2 on VTEP1 called
IP2_P.
Then, for IP1, we make the metric of the IGP route for IP1_P lower
than that for IP1_E. Then we do the same for IP2. Now we call the
VXLAN tunnel from IP3 to IP1_E as the egress-protected tunnel for
VTEP1, and we call the VXLAN tunnel from IP3 to IP1_P as the egress-
protecting tunnel for VTEP1. The egress-protected tunnel and egress-
protecting tunnel for VTEP2 are similar to those tunnels for VTEP1.
Note that from the view of VTEP3 the egress-protected tunnel and
egress-protecting tunnel for the same VTEP is actually the same
tunnel. When the VTEP node is active, the packets to the VTEP are
forwarded to it by the egress-protected tunnel. When the VTEP node
fails, the packets to it are forwarded to its protector by the
egress-protecting tunnel.
Wang Expires October 22, 2020 [Page 5]
Internet-Draft EVPN Egress Protection April 2020
But when VTEP2 receives the EVPN routes from VTEP3, only the egress-
protected tunnel for VTEP2 itself is constructed. the egress-
protecting tunnel for VTEP1 is not constructed by default. so when
VTEP1 fails, although the packets to VTEP1 are fast-rerouted to VTEP2
by underlay network, the VTEP2 may discard these packets because of
the absent of the corresponding VXLAN tunnel entity for their SIP and
DIP.
When VTEP2 receives the EVPN routes from VTEP1, it may discard these
routes because their nexthop is the IP address of a loopback on VTEP2
itself. Even though VTEP2 don't disccard these EVPN routes, it
cannot use their nexthop to construct a VXLAN tunnel for the same
reason as above.
3. Encoding the Originating Router Address
This sections describe the extensions specified to meeting the
requirements given in Section 3 and enhance VXLAN EVPN convergency.
This document reuse the OPE TLV defined in
[I-D.heitz-bess-evpn-option-b] section 3. the OPE TLV carries the
BGP update-source on corresponding VTEP. The VTEPs with egress
protection procedures described in this document will add the OPE TLV
in the EVPN routes they are about to advertise.
Note that the ESI label or leaf Label is not used in VXLAN packet, so
the usage for OPE TLV here won't conflict with the usage in
[I-D.heitz-bess-evpn-option-b].
4. Control Plane Processing
Using the topology in Figure 1:
We assume that the VNI for the same EVI on VTEP1 and VTEP2 must be
the same.
1) VTEP3 sends a MAC/IP route and an IMET route to VTEP1 and VTEP2.
The nexthop of these routes is IP3 (we assume that IP30=IP3). VTEP3
won't add the OPE TLV to these routes because it works as normal EVPN
VTEP.
2) When VTEP1 receives the IMET route from VTEP3, it constructs the
VXLAN tunnel (IP3,IP10). When VTEP1 receives the MAC/IP route from
VTEP3, it constructs the VXLAN tunnel (IP3,IP1) and (IP3, IP2)
because it is configured with egress loopback and protector loopback.
The procedures on VTEP2 is simlar to the above.
Wang Expires October 22, 2020 [Page 6]
Internet-Draft EVPN Egress Protection April 2020
3) VTEP1 sends a MAC/IP route, an EAD/EVI route and an IMET route to
VTEP2 and VTEP3. The nexthop of the MAC/IP route and the EAD/EVI
route is IP1 and the nexthop of the IMET route is IP10. VTEP2 sends
a MAC/IP route, an EAD/EVI route and an IMET route to VTEP1 and
VTEP3. The nexthop of the MAC/IP route and the EAD/EVI route is IP2
and the nexthop of the IMET route is IP20. VTEP1 and VTEP2 will both
add the OPE TLV to these routes because they are configured with
egress loopback and protector loopback. The OPE TLV carries their
BGP update-source IP address (IP10 or IP20).
4) When VTEP2 receives the MAC/IP or EAD/EVI route from VTEP1, it
constructs the VXLAN tunnel(IP10,IP20) because that the nexthop is
the IP address of the protector loopback on VTEP2. When VTEP2
receives the IMET route from VTEP1, it constructs the VXLAN
tunnel(IP10,IP20) too. The VXLAN tunnel(IP10,IP20) is called Egress
ESI Link Protection (EELP) bypass tunnel. and VTEP2 will apply the
egress link protection procedures to the received EAD/EVI route
following the second approach of RFC8679 section 6. The procedures
on VTEP1 is simlar to the above.
5) When VTEP3 receives the MAC/IP route from VTEP1/VTEP2, it will
ignore the OPE TLV because the route's tunnel encapsulation is VXLAN
and the nexthop is not a local address on VTEP3.
5. Protection Procedures
This section describes how Layer 2 unicast and BUM (Broadcast,
Unknown unicast, and Multicast) packet forwarding are protected. A
description of how Layer 3 packet forwarding are protected will be
provided in a furture version of this document.
5.1. EVPN Egress Node Protection (EENP)
The following two subsections discuss EENP procedures for BUM
forwarding and Unicast Forwarding.
5.1.1. BUM Forwarding Protection
VTEP1 and VTEP2 will receive a copy of BUM packet from VTEP3
separately, and the DF node for the (ESI,EVI) will forward it to the
CE node. When either of them fails, the other one will become the DF
for all (ESI,EVI)s.
5.1.2. Unicast Forwarding Protection
When VTEP1 fails, the data packets from VTEP3 to VTEP1 is fast-
rerouted to VTEP2 by the PLR node in the underlay network, the VTEP2
Wang Expires October 22, 2020 [Page 7]
Internet-Draft EVPN Egress Protection April 2020
won't discard these packets because of the existence of VXLAN
tunnel(IP3, IP1) on itself. The VTEP2 will forward them to CE.
5.2. Egress ESI Link Protection (EELP)
The EELP (ESI,EVI) forwarding entry on VTEP1 will take the ESI link
as primary forwarding path, and take the EAD/EVI route from VTEP2 as
backup forwarding path. This procedure follows the second approach
of RFC8679 section 6.
When the ESI link fails, the backup path will be activated on the
result of a FRR switch.
Note that even when the ESI is All-Active redundancy mode the EELP
will follow the FRR behavior. The EELP behavior is the same for All-
Active redundancy mode and Single-Active redundancy mode.
When ESI is All-Active redundancy mode VTEP3 will performing overlay
ECMP via EAD/EVI routes to VTEP1/VTEP2, When the ESI link on VTEP1
fails, VTEP1 will forwarding the packets via EELP bypass tunnel
before VTEP3 delete the EAD/EVI routes. But the bypass forwarding is
temporary, when VTEP delete the EAD/EVI routes upon the withdraw of
the EAD/EVI route from VTEP1, there won't be any bypass forwarding
again.
But when ESI is Single-Active redundancy mode, there is no importance
for VTEP3 to use the EAD/EVI routes from VTEP1/VTEP2. The EAD/EVI is
still useful between VTEP1 and VTEP2 for EELP procedures in Single-
Active redundancy mode.
6. IANA Considerations
IANA Considerations for OPE TLV following
[I-D.heitz-bess-evpn-option-b].
7. Security Considerations
This section will be added in future versions.
8. Acknowledgements
The authors would like to thank the following for their comments and
review of this document:
Chunning Dai, Bing Song, Zheng Zhou.
Wang Expires October 22, 2020 [Page 8]
Internet-Draft EVPN Egress Protection April 2020
9. Normative References
[I-D.heitz-bess-evpn-option-b]
Heitz, J., Sajassi, A., Drake, J., and J. Rabadan, "Multi-
homing and E-Tree in EVPN with Inter-AS Option B", draft-
heitz-bess-evpn-option-b-01 (work in progress), November
2017.
[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.
[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>.
[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>.
[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>.
Author's Address
Yubao Wang
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: wang.yubao2@zte.com.cn
Wang Expires October 22, 2020 [Page 9]