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 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. Terminology
• 3. Approach
• 3.1. Loop Prevention
• 4. Procedures
• 4.1. Constructing EVPN Routes
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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

[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) 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].

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

7.2. Informative References

Authors' Addresses