| Internet-Draft | Enhance All Active EVPN | May 2023 |
| Eastlake, et al. | Expires 1 December 2023 | [Page] |
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.¶
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 1 December 2023.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A principal feature of EVPN (Ethernet VPN [rfc7432bis]) is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipments (PEs) with links used in an all-active redundancy mode. That mode is where a device is multihomed to a group of two or more PEs and where all PEs in such redundancy group can forward traffic to/from the multihomed device or network for a given VLAN [RFC7209]. This draft specifies an improvement in load balancing such PE to CE all-active multi-homing links.¶
In the case where a CE is multihomed to multiple PE nodes, using a Link Aggregation Group (LAG) with All-Active redundancy, it is possible that only a single PE learns a set of the MAC addresses associated with traffic transmitted by the CE. This leads to a situation where remote PE nodes receive MAC/IP Advertisement routes for these addresses from a single PE, even though multiple PEs are connected to the multihomed segment.¶
To address this issue, EVPN introduces the concept of "aliasing", which is the ability of a PE to signal that it has reachability to an EVPN instance (EVI) on a given Ethernet segment (ES) even when it has learned no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC/IP Advertisement route with a non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address's EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet tag, if applicable) AND Ethernet A-D per ES routes for that ES with the "Single-Active" bit in the flags of the ESI Label extended community set to 0.¶
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.¶
This document uses the following acronyms and terms:¶
Consider the example in Figure 1. CE1 is multihomed to PE1 and PE2. CE1 typically uses a hash algorithm to determine whether to send a particular traffic to PE1 or to PE2. Thus, if such traffic from CE1 is only sent to PE1, then PE1 will learn CE1's MAC address(es) and that PE2 will not.¶
PE3 and PE4 can do aliasing [rfc7432bis] because PE1 and PE2 will be advertising the same ESI. Thus PE3 and PE4 will expect that a MAC address reachable from PE1 will also be reachable from PE2. This aliasing will cause PE3 and PE4 to load balance to CE1's MAC(s), sending some traffic to PE1 and some to PE2.¶
.........
+----------+ . . +----------+
| PE1 MAC +------+ +------+ PE3 |
| Learning | . . | |
+----------+ . . +----------+
/ ^ . . | \
+---+ | . EVPN . | +---+
|CE1| | . MPLS . | |CE2|
+---+ | . . | +---+
\ | . . | /
+----------+ . . +----------+
| PE2 | . . | PE4 |
| +------+ +------+ |
+----------+ . . +----------+
.........
There are two problems associated with this situation that are described in the subsections below. Section 3 describes the mechanism to address these problems.¶
Since PE2 has not learning CE1's MAC(s), the MAC lookup at PE2 will find that MAC address associated with PE1. PE2 will then tunnel the traffic to PE1.¶
As an enhancement that solves this problem, PE1 can send MAC address(es) with VLAN and ESI information. PE2 will then receive the MAC address(es) and VLAN that PE1 associates with the ESI and PE2 can use this to update its forwarding tables (see Figure 2). As a result, when traffic addressed to a CE1 MAC arrives at PE2, it can send it on the appropriate local interface and VLAN. This avoids the unnecessary extra hop through PE1 for such traffic arriving at PE2.¶
.........
+----------+ . . +----------+
| PE1 MAC +------+ +------+ PE3 |
| Learning | . . | |
+----------+ . . +----------+
/ ^ . . | \
+---+ | . EVPN . | +---+
|CE1| Sy|nc . MPLS . | |CE2|
+---+ | . . | +---+
\ v . . | /
+----------+ . . +----------+
| PE2 | . . | PE4 |
| +------+ +------+ |
+----------+ . . +----------+
.........
If CE1 is connected through a VLAN and has only one VLAN under the EVPN instance of PE2, the unicast traffic can be directly sent to the appropriate interface and encapsulated with the appropriate VID and forwarded to CE1.¶
However, there may be multiple ways for CE1 to connect to PE1 and PE2, including Ethernet Tag, Ethernet Tag termination, and Q-in-Q. PE2 cannot always obtain the appropriate VLANs and in such cases PE2 is missing the information needed to forward the unicast traffic to CE1 directly.¶
This document defines a new BGP extended community attribute called the VLAN-Redirect-Extended Community attribute as shown in Figure 3.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 | Sub-Type=TBA | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-VLAN | C-VLAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Operation with the solution specified in Section 3 and the topology shown in Figure 2 is described below.¶
IANA is requested to assign a new EVPN Extended Community SubType as follows:¶
| Sub-Type Value | Name | Reference |
|---|---|---|
| TBA | VLAN-Redirect Extended Community | [this doc] |
TBD¶
For general EVPN Security Considerations, see [rfc7432bis].¶
The authors would like to thank the following for their comments and review of this document:¶
TBD¶