| Internet-Draft | EVPN MH Port-Active | June 2022 |
| Brissette, et al. | Expires 12 December 2022 | [Page] |
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability, while providing different modes of sharing/balancing of traffic. RFC7432 defines EVPN based MC-LAG with single-active and all-active multi‑homing load‑balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support for port-active load‑balancing mode.¶
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 12 December 2022.¶
Copyright (c) 2022 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.¶
EVPN, as per [RFC7432], provides all-active per flow load‑balancing for multi‑homing. It also defines single-active with service carving mode, where one of the PEs, in redundancy relationship, is active per service.¶
While these two multi‑homing scenarios are most widely utilized in data center and service provider access networks, there are scenarios where active-standby per interface multi‑homing load‑balancing is useful and required. The main consideration for this mode of load‑balancing is the determinism of traffic forwarding through a specific interface rather than statistical per flow load‑balancing across multiple PEs providing multi‑homing. The determinism provided by active-standby per interface is also required for certain QOS features to work. While using this mode, customers also expect minimized convergence during failures.¶
A new type of load‑balancing mode, port-active load‑balancing, is defined. This draft describes how the new load‑balancing mode can be supported via EVPN. The new mode may also be referred to as per interface active/standby.¶
+-----+
| PE3 |
+-----+
+-----------+
| MPLS/IP |
| CORE |
+-----------+
+-----+ +-----+
| PE1 | | PE2 |
+-----+ +-----+
| |
I1 I2
\ /
\ /
+---+
|CE1|
+---+
Figure 1 shows a MC-LAG multi‑homing topology where PE1 and PE2 are part of the same redundancy group providing multi‑homing to CE1 via interfaces I1 and I2. Interfaces I1 and I2 are members of a LAG running LACP protocol. The core, shown as IP or MPLS enabled, provides wide range of L2 and L3 services. MC-LAG multi‑homing functionality is decoupled from those services in the core and it focuses on providing multi‑homing to the CE. With per-port active/standby load‑balancing, only one of the two interface I1 or I2 would be in forwarding, the other interface will be in standby. This also implies that all services on the active interface are in active mode and all services on the standby interface operate in standby mode.¶
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.¶
When a CE is multi‑homed to a set of PE nodes using the [IEEE.802.1AX_2014] Link Aggregation Control Protocol (LACP), the PEs must act as if they were a single LACP speaker for the Ethernet links to form and operate as a Link Aggregation Group (LAG). To achieve this, the PEs connected to the same multi‑homed CE must synchronize LACP configuration and operational data among them. Interchassis Communication Protocol (ICCP) [RFC7275] has been used for that purpose. EVPN LAG simplifies greatly that solution. Along with the simplification come a few assumptions:¶
Any discrepancies from this list are out of the scope of this document, as are mis-configuration and mis-wiring detection across peering PEs.¶
Following steps describe the proposed procedure with EVPN LAG to support port-active load‑balancing mode:¶
Non-DF routers will by default implement a bidirectional blocking scheme for all traffic in line with [RFC7432] Single-Active blocking scheme, albeit across all VLANS.¶
The ES routes, running in port-active load‑balancing mode, are advertised with the new Port Mode Load-Balancing capability in the DF Election Extended Community defined in [RFC8584]. Moreover, the ES associated to the port leverages existing procedure of Single-Active, and signals Single-Active Multihomed site redundancy mode along with Ethernet-AD per-ES route (Section 7.5 of [RFC7432]). Finally the ESI-label based split-horizon procedures in Section 8.3 of [RFC7432] should be used to avoid transient echo'ed packets when Layer‑2 circuits are involved.¶
The various algorithms for DF Election are discussed in Sections 4.2 to 4.5 for completeness, although the choice of algorithm in this solution doesn't affect complexity or performance as in other load-balancing modes.¶
[RFC8584] defines a DF Election extended community, and a Bitmap field to encode "capabilities" to use with the DF election algorithm in the DF algorithm field. Bitmap (2 octets) is extended by the following value:¶
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The default DF Election algorithm, or modulus-based algorithm as in
[RFC7432] and updated by [RFC8584], is used here, at the granularity
of ES only. Given that ES-Import Route Target extended community may be auto-derived and
directly inherits its auto-derived value from ESI bytes 1-6, many operators differentiate ESI
primarily within these bytes.
As a result, bytes 3‑6 are used to determine the designated forwarder using Modulo-based DF
assignment, achieving good entropy during Modulo calculation across ESIs:
Assuming a redundancy group of N PE nodes, the PE with ordinal i is the DF for an <EE>
when (Es mod N) = i, where Es represents bytes 3‑6 of that ESI.¶
Highest Random Weight (HRW) algorithm defined in [RFC8584] MAY also be used and signaled, and modified to operate at the granularity of <ES> rather than per <ES, VLAN>.¶
Section 3.2 of [RFC8584] describes computing a 32 bit CRC over the concatenation of Ethernet Tag and ESI. For port-active load‑balancing mode, the Ethernet Tag is simply removed from the CRC computation.¶
DF(Es) denotes the DF and BDF(Es) denote the BDF for the ESI es; Si is the IP address of PE i; and Weight is a function of Si, and Es.¶
Where:¶
When the new capability 'Port-Mode' is signaled, the algorithm is modified to consider the port only and not any associated Ethernet Tags. Furthermore, the "port-based" capability MUST be compatible with the "Don't Preempt" bit. When an interface recovers, a peering PE signaling D-bit will enable non-revertive behaviour at the port level.¶
The AC-DF bit MUST be set to 0 when advertising Port Mode Load-Balancing capability (P=1). When an AC (sub-interface) goes down, it does not influence the DF election. The peer's Ethernet A-D per EVI is ignored in all Port Mode DF Election algorthms.¶
Upon receiving AC-DF bit set (A=1) from a remote PE, it MUST be ignored when performing Port-Mode DF Election.¶
To improve the convergence, upon failure and recovery, when port‑active load‑balancing mode is used, some advanced synchronization between peering PEs may be required. Port-active is challenging in a sense that the "standby" port is in down state. It takes some time to bring a "standby" port in up-state and settle the network. For IRB and L3 services, ARP / ND cache may be synchronized. Moreover, associated VRF tables may also be synchronized. For L2 services, MAC table synchronization may be considered.¶
Finally, for members of a LAG running LACP the ability to set the "standby" port in "out-of-sync" state a.k.a "warm‑standby" can be leveraged.¶
The EVPN Layer 2 Attributes Control Flags extended community SHOULD be advertised in Ethernet A-D per ES route for fast convergence.¶
Only the P and B bits are relevant to this document, and only in the context of Ethernet A-D per ES routes:¶
For EVPN Layer 2 Attributes Control Flags extended community sent and received in Ethernet A-D per EVI routes used in [RFC8214], [RFC7432] and [I-D.ietf-bess-evpn-vpws-fxc]:¶
Implementations that comply with [RFC7432] or [RFC8214] only (i.e., implementations that predate this document) will not advertise the EVPN Layer 2 Attributes Control Flags extended community in Ethernet A-D per ES routes. That means that all remote PEs in the ES will not receive P and B bit per ES and will continue to receive and honour the P and B bits received in Ethernet A-D per EVI route(s). Similarly, an implementation that complies with [RFC7432] or [RFC8214] only and that receives an EVPN Layer 2 Attributes Control Flags extended community will ignore it and will continue to use the default path resolution algorithm.¶
A common deployment is to provide L2 or L3 service on the PEs providing multi‑homing. The services could be any L2 EVPN such as EVPN VPWS, EVPN [RFC7432], etc. L3 service could be in VPN context [RFC4364] or in global routing context. When a PE provides first hop routing, EVPN IRB could also be deployed on the PEs. The mechanism defined in this document is used between the PEs providing L2 and/or L3 services, when per interface single-active load‑balancing is desired.¶
A possible alternate solution is the one described in this draft is MC-LAG with ICCP [RFC7275] active-standby redundancy. However, ICCP requires LDP to be enabled as a transport of ICCP messages. There are many scenarios where LDP is not required e.g. deployments with VXLAN or SRv6. The solution defined in this draft with EVPN does not mandate the need to use LDP or ICCP and is independent of the underlay encapsulation.¶
The use of port-active multi‑homing brings the following benefits to EVPN networks:¶
Replaces legacy MC-LAG ICCP-based solution, and offers following additional benefits:¶
This document solicits the allocation of the following values:¶
The same Security Considerations described in [RFC7432] and [RFC8584] are valid for this document.¶
By introducing a new capability, a new requirement for unanimity (or lack thereof) between PEs is added. Without consensus on the new DF election procedures and Port Mode, the DF election algorithm falls back to the default DF election as provided in [RFC8584] and [RFC7432]. This behavior could be exploited by an attacker that manages to modify the configuration of one PE in the ES so that the DF election algorithm and capabilities in all the PEs in the ES fall back to the default DF election. If that is the case, the PEs will be exposed to the same unfair load balancing, service disruption, and possibly black-holing or duplicate traffic mentioned in those documents and their security sections.¶
The authors thank Anoop Ghanwani for his comments and suggestions and Stephane Litkowski for his careful review.¶