BESS Workgroup T. Yu
Internet-Draft April 24, 2019
Intended status: Standards Track
Expires: October 26, 2019

EVPN Enhanced Mass Withdraw


This document aims to define an enhanced mass withdraw process in case of failure of multiple ESs or vESs. This document also improves the withdraw efficiency of failure of single-homed ES or vES.

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

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 26, 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 ( 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

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 particular scenarios that cannot be covered by [RFC7432]:

Multi-homed scenario:

The mass withdraw mechanism MUST handle both single-active and active-active multi-homed vES in scenarios described above.

Single-homed scenario:

The mass withdraw mechanism SHOULD handle a huge number of vES. Convergence mechanism independent of number of (v)ES and MAC/IP routes is preferred when possible.

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. Solution Description

To achieve a fast convergence time in case of multiple vES fails, a concept of Administrative Group (AG) is introduced into EVPN. (v)ESs belonging to the same failure domain will be set with the same Administrative Group. A (v)ES MAY have more than one Administrative Groups.

A new EVPN BGP Extended Community called EVPN Administrative Group Community is defined as below. This new extended community is a transitive extended community with the Type field of 0x06 (EVPN) and the Sub-Type of TBD.

This community MUST be ignored if not supported on the the receiving PE.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type=0x06     | Sub-Type=TBD  | Flags(1 octet)| Type(1 octet) |
|                     Administrative Group                      |

Figure 1: EVPN Administrative Group Extended Community

EVPN Administrative Group Extended community is included along with EAD route when applicable. But it needs to be included with MAC/IP Advertisement Route instead of EAD route in single-homed (v)ES and PW N:1 scenario.

When a remote PE (PE2) receives EAD containing EVPN Administrative Group Community from PE1, it first check if the corresponding (v)ES exists in the same EVI, If the (v)ES does not exist on the remote PE (PE2), the remote PE maintains a relationship between the Administrative Group and the MAC/IP routes from the corresponding (v)ES. This procedure colors the MAC/IP routes with Administrative Group. If the (v)ES exists on PE2 within the same EVI, PE2 MUST not maintain the color relationship between AG and following MAC/IP routes from PE1, as PE1 and PE2 belongs to the same multi-homed (v)ES and a failure of (v)ES in PE1 does not requires withdraw of PE2. The MAC/IP route is applicable to usage defined in [RFC7432] and also ARP/ND proxy usage defined in [I-D.ietf-bess-evpn-proxy-arp-nd]

For the scenarios mentioned that AG being included in MAC/IP route, if ESI is not all 0 (multi-homed), after checking the existence of (v)ES in the same EVI, the color relationship is directly retrieved from the MAC/IP route. If ESI is all 0 (single-homed), then existence validation of the (v)ES is not required.

The 1 octet type field is defined to distinguish different types of Administrative Group to avoid overlap of the values across each other:

Examples are given below to demonstrate the usage of Administrative Group.

The 1 octet flags field is defined as below:

To construct a flushing message, ESI of the EAD route filled with MAX-ESI, Ethernet Tag and MPLS field with all 0 and the Administrative Group Community together with a list of Route Targets corresponding to the impacted service instances. If the number of Route Targets is more than they can fit into a single attribute, then can split the RTs into multiple messages with same Administrative Group Community attached.

5. Acknowledgments


6. Security Considerations


7. IANA Considerations

IANA is requested to allocate a new "EVPN Extended Community Sub-Types" registry defined in [RFC7153] as follow:

SUB-TYPE   NAME                                          Reference
  TBD     EVPN Administrative Group Community          This document

This document creates registry below.

Administrative Group Type:

Value     Meaning                                      Reference
0x00      Manually managed Administrative Group         This document
0x01      AG is retrieved via ifindex                   This document
0x02      AG is retrieved via ID of PW                  This document
0x03      AG is retrieved via EVPN service instance id  This document
0xF0~0xFF Reserved for proprietary implementation       This document      

Administrative Group Flags:

Value     Meaning                                      Reference
0x01      Flush-all-from-me                             This document
0x02      FRR-all-from-me                               This document     

8. References

8.1. Normative References

[I-D.ietf-bess-evpn-proxy-arp-nd] Rabadan, J., Sathappan, S., Nagaraj, K., Henderickx, W., Hankins, G., King, T., Melzer, D. and E. Nordmark, "Operational Aspects of Proxy-ARP/ND in EVPN Networks", Internet-Draft draft-ietf-bess-evpn-proxy-arp-nd-05, November 2018.
[I-D.ietf-bess-evpn-virtual-eth-segment] Sajassi, A., Brissette, P., Schell, R., Drake, J. and J. Rabadan, "EVPN Virtual Ethernet Segment", Internet-Draft draft-ietf-bess-evpn-virtual-eth-segment-04, January 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7432] Sajassi, A., 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.
[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.

8.2. Informative References

[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N. and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007.
[RFC6074] Rosen, E., Davie, B., Radoaca, V. and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011.

Author's Address

Tianpeng Yu EMail: