EVPN Split Horizon Filtering Enhancement
draft-jiang-bess-evpn-split-horizon-enhancement-00

Abstract

Ethernet Virtual Private Network (EVPN) multi-homing accommodates load balance, link/node redundancy and fast convergence. The split horizon filtering in EVPN avoids loop happens on multi-homed CE. However, this mechanism brings challenges switching chipsets on data plane. This document describes an approach for the challenges by enhancing current split horizon filtering mechanism. The advantage of this approach is that it simplifies data plane behaviors.

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 5, 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
• 4. Procedures
• 4.1. Advertising EVPN VRF Route Import Extended Community
• 4.2. Constructing IMET Routes
• 4.3. Flooding Handling on Data Plane
• 5. EVPN VRF Route Import Extended Community
• 6. IANA Considerations
• 6.1. EVPN VRF Route Import Extended Community
• 7. Security Considerations
• 8. Normative References
• Authors' Addresses

1. Introduction

Ethernet Virtual Private Network (EVPN) multi-homing accommodates load balance, link/node redundancy and fast convergence. The split horizon filtering in EVPN avoids loop happens on multi-homed CE. In particular, there are two split horizon filtering mechanisms to avoid looped frames on the multi-homed CE: ESI Label based [RFC7432] for MPLS based tunnels and Local Bias[RFC8365] for non-MPLS NVO tunnels, E.g. VXLAN tunnels.

However, each mechanism introduces challenges for data plane because extra logic is introduced but not available on some typical switching chipsets. ESI Label based mechanism requires ingress PE to push ESI label into MPLS stack to indicate Ethernet Segment Identifier, and requires egress PE to filter out the corresponding port based on ESI label before flooding. Local Bias does not require ingress PE to have extra procedure but still requires egress PE to filter out the corresponding ports based on source IP address before flooding.

This document describes an approach towards the challenges, by enhancing current Local Bias split horizon filtering mechanism, for MPLS based tunnels and non-MPLS NVO tunnels. The advantage of this approach is that it simplifies data plane behaviors.

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.

BUM: Broadcast, Unknown unicast and Multicast

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'.

Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'.

EVI: An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN.

EVPN: Ethernet Virtual Private Network

NVO: Network Virtualization Overlay

PE: Provider Edge device.

VXLAN: Virtual Extensible LAN

NVGRE: Network Virtualization using Generic Routing Encapsulation

VNI: VXLAN Network Identifier

VSID: Virtual Subnet Identifier (for NVGRE)

3. Approach

When the PE advertises Inclusive Multicast Ethernet Tag (IMET) Routes to PEs which share the same multi-homed CE, it allocates unique label for each PE, rather than using the same label for all PEs. To accomplish this, An EVPN VRF Route Import Extended Community is introduced.

When the PE receives BUM packet from ingress PE, based on the BUM label encapsulated, it can determine the packet is from PEs which share the same multi-homed CE or not. If yes, the PE can also determine which PE the packet is from. Because the PE has determined the ingress PE, Local Bias based mechanism can be implemented for split horizon filtering without source IP information, but simply based on a single BUM label to determine the flooding scope.

For NVO solution, this approach requires locally assigned VNIs to be used just like downstream-assigned MPLS labels.

Based on this extended mechanism, for MPLS based tunnels, no ESI label encapsulation is required on ingress PE either.

4. Procedures

Let's suppose an EVPN network, where CE1 is multi-homed to PE1 and PE2 with all-active mode, CE2 and CE3 are single-homed to PE2 and PE3 separately.

                        +--------------+  
            /--- PE1    |              |    
        CE1             |     EVPN     |    PE3 --- CE3
            \--- PE2    |              |
                  |     +--------------+
                 CE2
       

Figure 1: Sample EVPN Multi-homing Scenario

4.1. Advertising EVPN VRF Route Import Extended Community

In order to receive IMET route with unique label assigned by multi-homed peer, each VRF on PE1 MUST have an import Route Target Extended Community, and communicate the value to all other multi-homed peers.

We refer to this Route Target as the "EVPN IMET Import RT", as this Route Target controls imports of EVPN IMET routes into a particular VRF.

To communicate the value to all other multi-homed peers, PE1 when advertising an Ethernet Auto-discovery Route per EVI SHALL carry the EVPN VRF Route Import Extended Community (as defined in Section 5) that has the value of the EVPN IMET Import RT of the VRF associated with the route.

4.2. Constructing IMET Routes

Once EVPN routes with EVPN VRF Route Import Extended Community received on PE2, PE2 extracts the value of the EVPN VRF Route Import Extended Community. The value of EVPN IMET Import RT is set to this value.

Besides advertising IMET routes to other PEs as usual, PE2 advertises IMET route with unique BUM label to each multi-homed peer (here only PE1) by using EVPN IMET Import RT as route target. It is suggested to set a higher LOCAL_PREF for this BGP message, if another general IMET route is sent to PE1 also.

Now suppose PE3 receives IMET route with label BUM0 from PE2, and PE1 receives IMET route with label BUM1 from PE2.

4.3. Flooding Handling on Data Plane

Once PE2 advertises all IMET routes, including general and unique ones, it sets data plane to handle BUM labels as figure 2 described below (Suppose it is the Designated Forwarder).

                     +-----------+-------------+ 
                     | In Label  |  Out Ports  |  
                     +-----------+-------------+
       (from PE3) -> | BUM0      |  CE1, CE2   | 
                     +-----------+-------------+   
       (from PE1) -> | BUM1      |  CE2        |
                     +-----------+-------------+
        

Figure 2: Flooding handling on PE2 Data Plane

Now BUM traffic is properly handled, no matter from multi-homed peers (E.g. PE1) or other PEs (E.g. PE3). Unlike ESI Label based or Local Bias which requires two parameters for flooding decision, this flooding behavior requires only one parameter, the single BUM label.

5. EVPN VRF Route Import Extended Community

This document defines a new BGP Extended Community called "EVPN VRF Route Import".

The EVPN VRF Route Import is an IP-address-specific Extended Community, of an extended type, and is transitive across AS boundaries [RFC4360].

 0                   1                   2                   3
 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  |    Global Administrator       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.)  |    Local Administrator        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The EVPN VRF Route Import Extended Community has following format:

This document expands the definition of EVPN Extended Community [RFC7153]. This Extended Community has a Type field value of 0x06 and the Sub-Type TBD.

The Global Administrator field of the EVPN VRF Route Import EC MUST be set to an IP address of the PE. This address SHOULD be common for all the VRFs on the PE (e.g., this address may be the PE's loopback address).The Local Administrator field of the EVPN VRF Route Import EC associated with a given VRF contains a 2-octet number that uniquely identifies that VRF within the PE.

For procedures and usage of this attribute, please see Section 4

6. IANA Considerations

6.1. EVPN VRF Route Import Extended Community

This document makes the following registrations for EVPN VRF Route Import Extended Community.

Type  Description
----  -----------
TBD   EVPN VRF Route Import Extended Community

7. Security Considerations

If BGP is used as a CE-PE routing protocol, then when a PE receives a route from a CE, if this route carries the EVPN VRF Route Import Extended Community, the PE MUST remove this Community from the route before turning it into a VPF. Routes that a PE advertises to a CE MUST NOT carry the EVPN VRF Route Import Extended Community.

8. Normative References

Authors' Addresses