EVPN Enhanced Mass Withdraw
draft-yu-bess-evpn-mass-withdraw-00

Abstract

This document aims to define a enhanced mass withdraw process in case of multiple ES or vES fails.

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 July 19, 2019.

Copyright Notice

Copyright (c) 2019 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. Specification of Requirements
• 3. Terminology
• 4. Requriments
• 5. Solution Description
• 6. EVPN Mass-Withdraw Community
• 7. Security Considerations
• 8. IANA Considerations
• 9. Normative References
• Author's Address

1. Introduction

EVPN [RFC7432] defines a mass withdraw mechanism to efficiently and quickly signal to remote PE nodes in case of a connection to ES fails. But there are paticular scenarios that failure of multiple ESs can happen listed but not limited below:

• ES scenario: Failue of a line-card leads to failure of multiple ESs.
• vES scenario: Failure of physical port leads to failure of multiple vESs aggregating EVC.
• vES scenario: Failure of LAG leads to failure of multiple vESs aggregating EVC.
• vES scenario: Failure of multiple MPLS NNI ports leads to failure of LSP and multiple vESs aggregating PWs.
• vES scenario: Failure of EVC leading to failure of multiple vESs.
• vES scenario: Failure of PW leading to failure of multiple vESs.
• vES scenario: Failure of line-card leads to failure of multiple vESs.

This document aims to introduce a solution improving convegence performance in case of failure on multiple ESs.

2. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Terminology

EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432]

EVI: EVPN Instance

EVPN VPWS: Refers to [RFC8214]

vES: Virtual Ethernet Segment [I-D.ietf-bess-evpn-virtual-eth-segment]

EVC: Ethernet Virtual Circuit

PW: Pseudowire

4. Requriments

(R1a): The mass withdraw mechanism MUST handle both single-active and active-active multi-homed ES.

(R1b): The mass withdraw mechanism MUST handle both single-active and active-active multi-homed vES.

(R1c): The mass withdraw mechanism SHOULD handle a huge number of ES/vES.

(R1d): The mass withdraw mechanism SHOULD handle failure scenarios mentioned in section 1.

(R1e): The mass withdraw mechanism SHOULD allowing aggregating sequential ESI.

(R1f): A suppresion mechanism is requried in case flapping occours leading to failure of large number of ES/vES

5. Solution Description

In order to reduce the number of ES/vES withdraw routes, the PE SHOULD aggregate ESI if the impacted ESI are sequential and send along with EVPN mass-withdraw community defined in section 6. If the impacted ES/vES are nonsequential then multiple EVPN mass-withdraw communities can be sent along the flush message.

To achieve a fast convergence time in case of multiple ES/vES fails, a sequential ES/vES helps. This can be achieved via proper ES/vES auto-generating algorithm or proper planning. An example is given below:

Assume type 0 ESI is used. An ESI/vESI planning rule is:

3 octs are used to identify device id

4 octs are used to identify ifindex. Ifindex uniquelly idenfies physical port, LAG or any logical ENNI port.

3 octs are used to identify service id under each interface, if 0 it is used as ES, if not 0 it is used as vES.

In case of port LAG or PW failure, an EVPN mass-withdraw community can be generated with all impacted vES with bit map.

The auto-generating algorithm and planning rule on ES/vES is out of scope of current document. Example given above is only used to explan the possibility of ESI aggregation.

A timer SHOULD be started each time for each flushing. Further failure during the timer SHOULD be suppressed. A half-life based damping mechanism MAY be implemented.

6. EVPN Mass-Withdraw Community

A new EVPN BGP Extended Community called EVPN Mass-Withdraw Community is introduced. This new extended community is a transitive extended community with the Type field of 0x06 (EVPN) and the Sub-Type of TBD.

+-------------------------------------------+
|  Type (0x06) / Sub-type (TBD) (2 octets)  |
+-------------------------------------------+
|  ESI  (10 octets)                         |
+-------------------------------------------+
|  Bitmap (10 octets)                       |
+-------------------------------------------+

Figure 1: EVPN Mass-Withdraw Community

7. Security Considerations

TBD

8. IANA Considerations

Sub-type for EVPN Mass-Withdraw Community to be allocated.

9. Normative References

Author's Address