| Internet-Draft | EVPN MH Split Horizon Extensions | April 2023 |
| Rabadan, et al. | Expires 9 October 2023 | [Page] |
Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The EVPN multi-homing procedures may be different depending on the tunnel type used in the EVPN Broadcast Domain. In particular, there are two multi-homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other tunnels, E.g., VXLAN tunnels. The existing specifications do not allow the operator to decide which Split Horizon procedure to use for tunnel encapsulations that could support both. Examples of tunnels that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or SRv6. This document updates the EVPN Multi-Homing procedures so that an operator can decide the Split Horizon procedure for a given tunnel depending on their own requirements.¶
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 9 October 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.¶
Ethernet Virtual Private Network (EVPN) is commonly used with the following tunnel encapsulations:¶
The EVPN multi-homing procedures may be different depending on the tunnel type used in the EVPN Broadcast Domain. In particular, there are two Multi-Homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLS or MPLSoX tunnels, E.g., MPLSoUDP [RFC7510], and its procedures described in [RFC7432]. Local Bias is used by non-MPLS NVO tunnels, E.g., VXLAN tunnels, and it is described in [RFC8365].¶
EVPN supports two Split Horizon Filtering mechanisms:¶
ESI Label based Split Horizon filtering [RFC7432]¶
When EVPN is used for MPLS transport tunnels, an MPLS label enables the Split Horizon filtering capability to support All-Active multi-homing. The ingress Network Virtualization Edge (NVE) device adds a label corresponding to the source ES (an ESI label) when encapsulating the packet. The egress NVE checks the ESI label when attempting to forward a multi-destination frame out of a local ES interface, and if the label corresponds to the same site identifier (ESI) associated with that ES interface, the packet is not forwarded. This prevents the occurrence of forwarding loops for BUM traffic.¶
The ESI Label Split Horizon filtering SHOULD also be used with Single-Active multi-homing to avoid transient loops for in-flight packets when the egress NVE takes over as Designated Forwarder for an ES.¶
Since non-MPLS IP tunnels (such as VXLAN or NVGRE) do not support the ESI label (or any MPLS label at all), a different Split Horizon filtering procedure must be used for All-Active multi-homing. This mechanism is called Local Bias and relies on the tunnel source IP address to decide whether to forward BUM traffic to a local ES interface at the egress NVE.¶
In a nutshell, every NVE tracks the IP address(es) associated with the other NVE(s) with which it has shared multi-homed ESs. When the egress NVE receives a BUM frame encapsulated in a IP tunnel, it examines the source IP address in the tunnel header (which identifies the ingress NVE) and filters out the frame on all local interfaces connected to ESes that are shared with the ingress NVE.¶
Due to this behavior at the egress NVE, the ingress NVE's behavior is also changed to perform replication locally to all directly attached ESes (regardless of the Designated Forwarder election state) for all BUM ingress from the access ACs. Because of this "local" replication at the ingress NVE, this approach is referred to as Local Bias.¶
Local Bias cannot be used for Single-Active multi-homing, since the ingress NVE brings operationally down the Attachment Circuits (ACs) for which it is non-Designated Forwarder (hence local replication to non-Designated Forwarder ACs cannot be done). This means transient in-flight BUM packets may be looped back to the originating site by new elected Designated Forwarder egress NVEs.¶
[RFC8365] states that Local Bias is used only for non-MPLS NVO tunnels, and ESI Label based Split Horizon for MPLS NVO tunnels. However, MPLS NVO tunnels, such as MPLSoGRE or MPLSoUDP, are also IP tunnels and can potentially support both procedures, since they can carry ESI Labels and they also use a tunnel IP header where the source IP address identifies the ingress NVE.¶
Similarly, some non-MPLS IP tunnels that carry an identifier of the source ES in the tunnel header, may potentially follow either procedure too. Some examples are GENEVE or SRv6:¶
Table 1 shows different tunnel encapsulations and their supported and default Split Horizon method. In the case of GENEVE, the default Split Horizon Type (SHT) depends on whether the Ethernet Option with Source ID TLV is negotiated. In the case of SRv6, the default SHT is listed as ESI label filtering in the Table, since the behavior is equivalent to that of ESI Label filtering. In this document, ESI Label filtering refers to the Split Horizon filtering based on the existence of a source ES identifier in the tunnel header.¶
This document classifies the tunnel encapsulations used by EVPN into:¶
Any other tunnel encapsulation (different from the encapsulations in Table 1) that can be classified into any of the four encapsulation groups above, supports Split Horizon based on the following rules:¶
| Tunnel Encapsulation | Default Split Horizon Type (SHT) | Supports Local Bias | Supports ESI Label |
|---|---|---|---|
| MPLSoGRE (group MPLS-based IP) | ESI Label filtering | Yes | Yes |
| MPLSoUDP (group MPLS-based IP) | ESI Label filtering | Yes | Yes |
| MPLS or SR-MPLS | ESI Label filtering | No | Yes |
| VXLAN (group non-MPLS IP) | Local Bias | Yes | No |
| NVGRE (group non-MPLS IP) | Local Bias | Yes | No |
| VXLAN-GPE (group non-MPLS IP) | Local Bias | Yes | No |
| GENEVE (group non-MPLS IP) | Local Bias (no ESI Lb) ESI Label (if ESI lb) | Yes | Yes |
| SRv6 | ESI Label filtering | Yes | Yes |
The ESI Label method works for All-Active and Single-Active, while Local Bias only works for All-Active. In addition, the ESI Label method works across different network domains, whereas Local Bias is limited to networks with no next hop change between the NVEs attached to the same ES. However, some operators prefer the Local Bias method, since it simplifies the encapsulation, consumes less resources on the NVEs and the ingress NVE always forwards locally to other interfaces, reducing the delay to reach multi-homed hosts.¶
This document extends the EVPN Multi-Homing procedures so that an operator can decide the Split Horizon procedure for a given NVO tunnel depending on their own specific requirements. The choice of Local Bias or ESI Label Split Horizon is now allowed for tunnel encapsulations that support both methods, and it is advertised along with the EVPN A-D per ES route. Non-MPLS NVO tunnels that do not support both methods, E.g., VXLAN or NVGRE, will keep following [RFC8365] procedures.¶
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 also assumes familiarity with the terminology of [RFC7432] and [RFC8365].¶
EVPN extensions are needed so that NVEs can advertise their preference for the Split Horizon method to be used in the ES. Figure 1 shows the ESI Label extended community that is always advertised along with the EVPN A-D per ES route. All the NVEs attached to an ES advertise an A-D per ES route for the ES, including this extended community that conveys the information for the multi-homing mode (All-active or Single-Active), as well as the ESI Label to be used (if needed).¶
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=0x01 | Flags(1 octet)| Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved=0 | ESI Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC7432] defines the low-order bit of the Flags octet (bit 0) as the "Single-Active" bit:¶
[RFC8365] does not add any explicit indication about the Split Horizon method in the A-D per ES route. In this document, the [RFC8365] Split Horizon procedure is the default behavior and assumes that Local Bias is used only for non-MPLS NVO tunnels, and ESI Label based Split Horizon for MPLS NVO tunnels. This document defines the two high-order bits in the Flags octet (bits 6 and 7) as the "Split Horizon Type" (SHT) field, where:¶
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|SHT| |S|
+-+-+-+-+-+-+-+-+
S = "Single-Active" bit
SHT bit 7 6
-----------
0 0 --> Default SHT. Backwards compatible with [RFC8365]
0 1 --> Local Bias
1 0 --> ESI Label based filtering
1 1 --> reserved for future use
¶
The following behavior is observed:¶
As an example, egress NVEs that support MPLS NVO tunnels, E.g., MPLSoGRE or MPLSoUDP, will advertise A-D per ES route(s) for the ES along with the [RFC9012] BGP Encapsulation extended community indicating the encapsulation (MPLSoGRE or MPLSoUDP) and MAY use the SHT = 01 or 10 to indicate the intent to use Local Bias or ESI Label, respectively.¶
An egress NVE MUST NOT use an SHT value different from 00 when advertising an A-D per ES route with encapsulation VXLAN, NVGRE, MPLS or no [RFC9012] BGP tunnel encapsulation extended community. We assume that, in all these cases, there is no Split Horizon method choice, and therefore the SHT value MUST be 00. A received route with one of the above encapsulation options and SHT value different from 00 SHOULD be treat-as-withdraw.¶
An egress NVE advertising A-D per ES route(s) for an ES with encapsulation GENEVE MAY use an SHT value of 01 or 10. A value of 01 indicates the intent to use Local Bias, irrespective of the presence of an Ethernet option TLV with a non-zero Source-ID [I-D.ietf-bess-evpn-geneve]. A value of 10 indicates the intent to use ESI Label based Split Horizon. A value of 00 indicates the default behavior in Table 1, that is, use Local Bias if no ESI-Label exists in the Ethernet option TLV or no Ethernet option TLV whatsoever. Otherwise the ESI Label Split Horizon method is used.¶
The above procedures assume a single encapsulation supported in the egress NVE. Section 3 describes additional procedures for NVEs supporting multiple encapsulations.¶
This document also updates [RFC8365] in the value that is advertised in the ESI Label field of the ESI Label extended community, as follows:¶
As discussed in Section 2.2 this specification is backwards compatible with the Split Horizon filtering behavior in [RFC8365] and a non-upgraded NVE can be attached to the same ES as other NVEs supporting this specification.¶
An NVE has an administrative SHT value for an ES (the one that is advertised along with the A-D per ES route) and an operational SHT value (the one that is actually used irrespective of what the NVE advertised). The administrative SHT matches the operational SHT if all the NVEs attached to the ES have the same administrative SHT.¶
This document assumes that an [RFC7432] or [RFC8365] implementation that does not support this document, ignores the value of all the Flags in the ESI Label extended community except for the Single-Active bit. Based on this assumption, a non-upgraded NVE will ignore an SHT different from 00. As soon as an upgraded NVE receives at least one A-D per ES route for the ES with SHT value of 00, it MUST revert its operational SHT to the default Split Horizon method, as in Table 1, and irrespective of its administrative SHT.¶
As an example, consider an NVE attached to ES N that receives two A-D per ES routes for N from different NVEs, NVE1 and NVE2. If the route from NVE1 has SHT = 00 and the one from NVE2 an SHT = 01, the NVE MUST use the default Split Horizon method in Table 1 as operational SHT, irrespective of its administrative SHT.¶
All the NVEs attached to an ES with operational SHT value of 10 MUST advertise a valid non-zero ESI Label. If the operational SHT value is 01, the ESI Label MAY be zero. If the operational SHT value is 00, the ESI Label MAY be zero only if the default encapsulation supports Local Bias only and the NVEs do not check the presence of a valid non-zero ESI Label.¶
If an NVE changes its operational SHT value from 01 (Local Bias) to 00 (Default SHT) as a result of a new non-upgraded NVE present in the ES, and it previously advertised a zero ESI Label, it MUST send an update with a non-zero valid ESI Label, unless all the non-upgraded NVEs in the ES support Local Bias only. As an example, suppose NVE1 and NVE2 use MPLSoUDP as encapsulation, they are attached to the same Ethernet Segment ES1 and advertise an SHT value of 01 (Local Bias) and a zero ESI label value. Suppose NVE3 does not support this specification and joins ES1, therefore advertises an SHT of 00 (default). Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 MUST send an update of their A-D per ES route for ES1 with a non-zero valid ESI label value. The assumption is that NVE3 supports only the default ESI label based Split Horizon filtering.¶
As specified by [RFC8365], an egress NVE that supports multiple data plane encapsulations (I.e., VXLAN, NVGRE, MPLS, MPLSoUDP, GENEVE) needs to indicate all the supported encapsulations using BGP Encapsulation extended communities defined in [RFC9012] with all EVPN routes. This section clarifies the multi-homing Split Horizon behavior for NVEs advertising and receiving multiple BGP Encapsulation extended communities along with the A-D per ES routes. This section uses a notation of {x,y} to indicate the encapsulations advertised in [RFC9012] BGP Encapsulation extended communities, with x and y being different encapsulation values.¶
It is important to remember that an NVE MAY advertise multiple A-D per ES routes for the same ES (and not only one), each route conveying a number of Route Targets (RT). We refer to the total number of Route Targets in a given ES as RT-set for that ES. Any of the EVIs represented in the RT-set will have its RT included in one (and only one) A-D per ES route for the ES. When multiple A-D per ES routes are advertised for the same ES, each route MUST have a different Route Distinguisher.¶
As per [RFC8365], an NVE that advertises multiple encapsulations in the A-D per ES route(s) for an ES, MUST advertise encapsulations that use the same Split Horizon filtering method in the same route. For example:¶
This document extends this behavior as follows:¶
If ES-z with RT-set composed of (RT1, RT2, RT3.. RTn) supports multiple encapsulations that require a different Split Horizon method, a different A-D per ES route (or group of routes) per Split Horizon method MUST be advertised. For example, consider n RTs in ES-z and:¶
In this case, three groups of A-D per ES routes MUST be advertised for ES-z:¶
As per [RFC8365], it is the responsibility of the operator of a given EVI to ensure that all of the NVEs in that EVI support a common encapsulation. If this condition is violated, it could result in service disruption or failure.¶
The same security considerations described in [RFC7432] relevant to Multi-Homing apply to this document.¶
In addition, this document modifies the [RFC8365] procedures for Split Horizon filtering, providing the operator with a choice between Local Bias and ESI Label based filtering for the tunnels that support both methods. A misconfiguration of the desired SHT to be used may result in a forwarding behavior that is different from the intended one. Other than that, this document describes procedures so that all the PEs or NVEs attached to the same ES agree on a common SHT method, therefore an attacker changing the configuration of the SHT should not cause traffic disruption, only a change in the forwarding behavior.¶
IANA is requested to allocate the SHT bits (6 and 7) in the Flags Octet of the EVPN ESI Label extended community. This field is called "Split Horizon Type" bits.¶
The authors would like to thank Anoop Ghanwani and Gyan Mishra for their review and useful comments.¶