RFC 9746

BGP EVPN Multihoming Extensions for Split-Horizon Filtering

📅 published March 2025, from ietf

RFC 9746: BGP EVPN Multihoming Extensions for Split-Horizon Filtering ✨🎀

Okay bestie, this is RFC 9746, and it's giving main character energy 💅. It's a Standards Track document, so the real protocol rules live here, and it was published in March 2025 🌸. The IETF calls it "Request for Comments: 9746," and its ISSN is 2070-1721 🦋.

It's written by a whole squad of people. J. Rabadan is the editor (that's the "Ed." part 🫶), and the other authors are K. Nagaraj from Nokia, W. Lin from Juniper, and A. Sajassi from Cisco 💜.

It updates two older EVPN specs, RFC 7432 and RFC 8365 🔥. Nothing gets obsoleted here. These two docs are getting a glow-up, not getting replaced 💖.

Abstract

okay so EVPN gets used with a bunch of different tunnels, like NVO tunnels, MPLS, and Segment Routing 🧚. Depending on which tunnel you're using, the multihoming rules can be a little different ✨. The big problem is two split-horizon procedures, which are how you stop looped frames from bouncing around multihomed Customer Edge (CE) devices 🙈. One is the ESI Label-based procedure, which is used for MPLS-based tunnels like MPLSoUDP, and the other is the local-bias procedure, which is used for tunnels like VXLAN 🌈.

Here's the drama 💀: the current specs don't let operators pick which one to use when a tunnel supports both methods. Tunnels like MPLSoUDP, MPLSoGRE, Geneve, and SRv6 can all do both, so this document updates RFCs 7432 and 8365 to give operators that choice 👑. Literally iconic.

Status of This Memo

This is an Internet Standards Track document 🎀.

It's a product of the IETF, which means it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💅. If you want more info about Internet Standards, check Section 2 of RFC 7841 🦋.

Errata and feedback for this doc live at https://www.rfc-editor.org/info/rfc9746 🌸.

Copyright (c) 2025 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) as they stand on the publication date. Please read them carefully, bestie, because they explain your rights and restrictions 🫶. Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 🔥.

Table of Contents ✨

1.  Introduction
  1.1.  Conventions and Terminology
  1.2.  Split-Horizon Filtering and Tunnel Encapsulations
2.  BGP EVPN Extensions
  2.1.  The Split-Horizon Type
  2.2.  Use of the Split-Horizon Type in A-D per ES Routes
  2.3.  The ESI Label Value in A-D per ES Routes
  2.4.  Backwards Compatibility with NVEs from RFC 8365
3.  Procedures for NVEs Supporting Multiple Encapsulations
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🦋

Okay so EVPNs (Ethernet Virtual Private Networks) are commonly paired with these tunnel encapsulations 💖:

  • NVO tunnels, where the EVPN procedures are in [RFC8365]. MPLSoGRE [RFC4023], MPLSoUDP [RFC7510], Geneve [RFC8926], and VXLAN [RFC7348] tunnels all count as NVO tunnels 🌈.
  • MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the relevant EVPN procedures are in [RFC7432]. SR-MPLS tunneling is specified in [RFC8660] 🧚.
  • Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN procedures are in [RFC9252]. SRv6 is specified in [RFC8402] and [RFC8754] 💜.

In this doc, "split horizon" follows the definition in [RFC7432] ✨. Split horizon is the EVPN multihoming procedure that stops a Provider Edge (PE) from sending a frame back to a multihomed CE when that CE was the one who sent it in the first place 🙈. Iconic behavior, honestly.

EVPN multihoming can change depending on which tunnel type is used inside the EVPN Broadcast Domain 🌸. There are two split-horizon procedures that stop looped frames on multihomed CE devices: the ESI Label-based procedure and the local-bias procedure 👑.

The ESI Label-based split-horizon procedure is used for MPLS or MPLS over X (MPLSoX) tunnels, like MPLSoUDP, and it's detailed in [RFC7432] 🔥. The local-bias procedure is used for IP-based tunnels, like VXLAN tunnels, and it's described in [RFC8365] 💅.

1.1. Conventions and Terminology 🎀

Here's the rule for the key words 🫶. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like this 💖.

Now for the vocab, bestie 📚:

  • AC: Attachment Circuit 🦋
  • A-D per ES route: Auto-Discovery per Ethernet Segment route, as defined in [RFC7432] 🌈
  • Arg.FE2: The ESI filtering argument used for split horizon, as specified in [RFC9252] ✨
  • BD: Broadcast Domain. It's an emulated Ethernet, so two systems on the same BD receive each other's BUM traffic 🧚. In this doc, BD also means the instance of a BD on an EVPN PE. A PE can be attached to one or several BDs of the same tenant 💜.
  • BUM: Broadcast, Unknown Unicast, and Multicast 🌸
  • CE: Customer Edge 💅
  • DF: Designated Forwarder. Per [RFC7432], an ES can be multihomed (attached to more than one PE) 🫶. An ES can also hold multiple BDs from one or more EVIs. For each EVI, one PE attached to the segment becomes that EVI's DF for that segment. Since a BD can only belong to one EVI, you can say "the BD's DF for a given segment" without any confusion 👑.
  • ES: Ethernet Segment 🔥
  • ESI: Ethernet Segment Identifier 🎀
  • EVI: EVPN Instance 🦋
  • EVI-RT: EVI Route Target. It refers to a group of NVEs attached to the same EVI that all share the same EVI-RT 🌸.
  • Geneve: Generic Network Virtualization Encapsulation [RFC8926] (tunnel type 19 in [TUNNEL-ENCAP]) 💖.
  • MPLS tunnels and non-MPLS NVO tunnels: This means Multiprotocol Label Switching tunnels (or NVO tunnels without MPLS). NVO tunnels use an IP encapsulation for overlay frames, where the source IP address identifies the ingress NVE and the destination IP address identifies the egress NVE 🌈.
  • MPLSoUDP: Multiprotocol Label Switching over User Datagram Protocol [RFC7510] (tunnel type 13 in [TUNNEL-ENCAP]) ✨.
  • MPLSoGRE: Multiprotocol Label Switching over Generic Network Encapsulation [RFC4023] (tunnel type 11 in [TUNNEL-ENCAP]) 🧚.
  • MPLSoX: MPLS over any IP encapsulation, like MPLSoUDP or MPLSoGRE 💜.
  • NVE: Network Virtualization Edge 🌸.
  • NVGRE: Network Virtualization Using Generic Routing Encapsulation [RFC7637] (tunnel type 9 in [TUNNEL-ENCAP]) 💅.
  • PE: Provider Edge 🫶.
  • RTs: Route Targets 👑.
  • VXLAN: Virtual eXtensible Local Area Network [RFC7348] (tunnel type 8 in [TUNNEL-ENCAP]) 🔥.
  • VXLAN-GPE: VXLAN Generic Protocol Extension [VXLAN-GPE] (tunnel type 12 in [TUNNEL-ENCAP]) 🎀.
  • SHT: Split-Horizon Type. It's the split-horizon method a PE intends to use, and it advertises that in an A-D per ES route 🦋.
  • SRv6: Segment Routing over IPv6 (see [RFC8402] and [RFC8754]) 🌈.
  • TLV: Type-Length-Value ✨.

This doc also assumes you already know the terminology from [RFC7432] and [RFC8365] 🧚.

1.2. Split-Horizon Filtering and Tunnel Encapsulations ✨

okay bestie, let's talk split-horizon, because this is where the whole "don't loop my packets back at me" drama lives 🌀 EVPN has two split-horizon filtering mechanisms, and each one gives something different:

  1. ESI Label-based split-horizon filtering [RFC7432]:

When EVPN is used for MPLS transport tunnels, an MPLS label does the split-horizon filtering so All-Active multihoming works 🫶 The ingress NVE attaches a label for the source ESI (the ESI label) when it encapsulates the packet. Then, before the egress NVE tries to forward a multi-destination frame out a local ES interface, it checks that ESI label. If the ESI label matches the site identifier (the ESI) tied to that ES interface, the packet just doesn't get forwarded 🙅‍♀️ That's how loops for BUM traffic get stopped, periodt ✨

ESI Label split-horizon filtering should also be utilized with Single-Active multihoming to prevent transient loops for in-flight packets when the egress NVE takes over as DF for an ES 🌸

  1. Local-bias filtering [RFC8365]:

Since IP tunnels like VXLAN or NVGRE can't carry the ESI label or any MPLS label, they need a different split-horizon procedure for All-Active multihoming. This one's called local bias. It looks at the source IP address of the tunnel to decide whether a BUM frame should go out a local ES interface at the egress NVE 💖

So, as specified in [RFC8365], each NVE keeps track of the IP address(es) of the other NVEs it shares multihomed ESs with. When a BUM frame arrives inside an IP tunnel, the egress NVE checks the source IP address in the tunnel header, which tells it which ingress NVE sent the frame. Then it filters the frame out of every local interface connected to an ES that's shared with that ingress NVE 🙈

Because of this behavior at the egress NVE, the ingress NVE is required to do local replication to all directly attached ESs, regardless of the DF election state, for all BUM traffic coming in from the access ACs. That local replication at the ingress is literally where the name "local bias" comes from 🦋

Local bias is not suitable for Single-Active multihoming, since the ingress NVE deactivates the ACs for which it is not the DF. So local replication to non-DF ACs can't happen, and in-flight BUM packets end up looped back to the originating site by newly elected DF egress NVEs 💀

[RFC8365] specifies that local bias is exclusively used for IP tunnels, while ESI Label-based split horizon is used for IP-based MPLS tunnels. However, IP-based MPLS tunnels such as MPLSoGRE or MPLSoUDP are also categorized as IP tunnels, and they have the potential to support both procedures. These tunnels can carry ESI labels, and they also use a tunnel IP header in which the source IP address identifies the ingress NVE 🧚

Similarly, certain IP tunnels (the ones that include an identifier for the source ES in the tunnel header) may also potentially support either procedure. Examples of these are Geneve and SRv6:

  • In a Geneve tunnel, the source IP address identifies the ingress NVE, so local bias is possible. Also, Section 4.1 of [EVPN-GENEVE] defines an Ethernet option Type-Length-Value (TLV) to encode an ESI label value 🌈
  • In an SRv6 tunnel, the source IP address identifies the ingress NVE. By default, and as outlined in [RFC9252], the ingress PE adds specific information to the SRv6 packet so the egress PE can identify the source ES of the BUM packet. This information is the ESI filtering argument (Arg.FE2) (see Section 6.1.1 of [RFC9252] and Section 4.12 of [RFC8986]) of the service Segment Identifier (SID) received on an A-D per ES route from the egress PE 🍓

Table 1 presents the various tunnel encapsulations, along with their supported and default split-horizon methods. For Geneve, the default SHT depends on whether the Ethernet Option with the Source ID TLV gets negotiated. For SRv6, the default SHT is listed as ESI Label filtering in the table, because its behavior is analogous to ESI Label filtering. In this document, "ESI Label filtering" refers to split-horizon filtering based on whether a source ES identifier is present in the tunnel header 🎀

This document sorts the tunnel encapsulations used by EVPN into four groups:

  1. IP-based MPLS tunnels
  2. MPLS and SR-MPLS tunnels
  3. IP tunnels
  4. SRv6 tunnels

Table 1 lists the encapsulations this document supports. Anything not listed in Table 1 is out of scope 🙅‍♀️ Tunnel encapsulations used by EVPN can be put into one of those four groups, and they support split-horizon filtering based on these rules:

  • IP-based MPLS tunnels and SRv6 tunnels are capable of supporting both split-horizon filtering methods.
  • MPLS and SR-MPLS tunnels only support ESI Label-based split-horizon filtering.
  • IP tunnels support local-bias split-horizon filtering, and they may also support ESI Label-based split-horizon filtering, provided they include a mechanism to identify the source ESI in the header.
+===============+====================+============+===========+
| Tunnel        | Default Split-     | Supports   | Supports  |
| Encapsulation | Horizon Type (SHT) | Local Bias | ESI Label |
+===============+====================+============+===========+
| MPLSoGRE (IP- | ESI Label          | Yes        | Yes       |
| based MPLS)   | filtering          |            |           |
+---------------+--------------------+------------+-----------+
| MPLSoUDP (IP- | ESI Label          | Yes        | Yes       |
| based MPLS)   | filtering          |            |           |
+---------------+--------------------+------------+-----------+
| MPLS and SR-  | ESI Label          | No         | Yes       |
| MPLS          | filtering          |            |           |
+---------------+--------------------+------------+-----------+
| VXLAN (IP     | Local Bias         | Yes        | No        |
| tunnels)      |                    |            |           |
+---------------+--------------------+------------+-----------+
| NVGRE (IP     | Local Bias         | Yes        | No        |
| tunnels)      |                    |            |           |
+---------------+--------------------+------------+-----------+
| VXLAN-GPE (IP | Local Bias         | Yes        | No        |
| tunnels)      |                    |            |           |
+---------------+--------------------+------------+-----------+
| Geneve (IP    | Local Bias (if no  | Yes        | Yes       |
| tunnels)      | ESI Lb), ESI Label |            |           |
|               | (if ESI lb)        |            |           |
+---------------+--------------------+------------+-----------+
| SRv6          | ESI Label          | Yes        | Yes       |
|               | filtering          |            |           |
+---------------+--------------------+------------+-----------+

     Table 1: Tunnel Encapsulations and Split-Horizon Types

The ESI Label method works for both All-Active and Single-Active configurations, whereas the local-bias method only suits All-Active configurations. The ESI Label method is also effective across different network domains, while local bias is limited to networks where the next hop doesn't change between the NVEs attached to the same ES. Still, some operators like local bias because it simplifies the encapsulation process, uses fewer resources on NVEs, and means the ingress NVE always forwards traffic locally to other interfaces, which cuts down the delay in reaching multihomed hosts 🦋

This document extends the EVPN multihoming procedures so operators can pick the preferred split-horizon method for a given NVO tunnel, based on their own needs. For tunnel encapsulations that support both methods, the choice between local bias and ESI Label split horizon is now allowed (by configuration), and that selection gets advertised along with the EVPN A-D per ES route. IP tunnels that don't support both methods, such as VXLAN or NVGRE, will keep following the procedures in [RFC8365]. Note that this document doesn't change the local bias or ESI Label split-horizon procedures themselves. It just focuses on the signaling and on the selection of the split-horizon method the multihomed NVEs apply 💅

2. BGP EVPN Extensions 🎀

Extensions to EVPN are needed so NVEs can advertise their preferred split-horizon method for a given ES. Figure 1 shows the ESI Label extended community (Section 7.5 of [RFC7432]), which gets advertised consistently alongside the EVPN A-D per ES route. Every NVE connected to an ES advertises an A-D per ES route for that ES, including the extended community. That community communicates the multihoming mode (either All-Active or Single-Active) and, if needed, specifies the ESI Label to use 🌸

                    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=0x01 | Flags(1 octet)|  Reserved=0   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Reserved=0   |          ESI Label                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: ESI Label Extended Community

[RFC7432] defines the low-order bit of the Flags octet (bit 0) as the "Single-Active" bit:

  • A value of 0 means the multihomed ES is operating in All-Active multihoming redundancy mode.
  • A value of 1 means the multihomed ES is operating in Single-Active multihoming redundancy mode.

Section 5 sets up a registry for the Flags octet, marking the "Single-Active" bit as the low-order bit of the newly defined Multihoming Redundancy Mode field 🧚

2.1. The Split-Horizon Type 🎀

Okay so bestie, [RFC8365] literally doesn't say anything explicit about the split-horizon method in the A-D per ES route 🙈 So here's the deal: the split-horizon procedure in Section 8.3.1 of [RFC8365] is the default vibe 💅. It assumes local bias is used only for IP tunnels, while ESI Label-based split horizon is for IP-based MPLS tunnels. ✨

This doc says the two high-order bits in the Flags octet (bits 6 and 7) become the "Split-Horizon Type" or "SHT" field, and it's giving main character energy 👑:

 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|SHT|       |RED|
+-+-+-+-+-+-+-+-+
RED = "Multihoming Redundancy Mode" field (see Table 2)
SHT bit 7 6
-----------
        0 0  --> Default SHT
                 Backwards compatible with [RFC8365] and [RFC7432]
        0 1  --> Local Bias
        1 0  --> ESI Label-based filtering
        1 1  --> Unassigned
  • SHT = 00 is backwards compatible with [RFC8365] and [RFC7432] 🌸 It means the advertising NVE wants the default or built-in SHT. The default SHT for each encapsulation is in Table 1. An egress NVE that follows the [RFC8365] behavior and doesn't support this spec will ignore the SHT bits, which is the same as treating them as 00. 🫶
  • SHT = 01 means the advertising NVE wants to use local-bias procedures in the ES that the AD per-ES route is advertised for. 🦋
  • SHT = 10 means the advertising NVE wants to use the ESI Label-based split-horizon method procedures in that same ES. 🧚
  • SHT = 11 is Unassigned. 💀

2.2. Use of the Split-Horizon Type in A-D per ES Routes 💖

Here's how it plays out 👀

  • An SHT value of 01 or 10 MUST NOT be used with encapsulations that support only one SHT in Table 1, and MAY be used by encapsulations that support the two SHTs in Table 1. 🙅‍♀️
  • An SHT value other than 00 expresses the intent to use a specific split-horizon method. It does NOT show the actual operational SHT the advertising NVE is using, unless all the NVEs attached to the ES advertise the same SHT. 🤔
  • If the NVEs attached to the same ES for a given EVI are inconsistent about the SHT value they advertise, all the NVEs MUST revert to the behavior in [RFC8365] and use the default SHT in Table 1, no matter what was advertised. 😭
  • An SHT different than 00 MUST NOT be set if the "Single-Active" bit is set. A received A-D per ES route where the "Single-Active" and SHT bits are both different than zero MUST follow the treat-as-withdraw behavior in [RFC7606]. 🚫
  • The SHT MUST have the same value in each Ethernet A-D per ES route that an NVE advertises for a given ES and a given encapsulation (see Section 3 for NVEs supporting multiple encapsulations). 💅

Let's do an example ✨ Egress NVEs that support IP-based MPLS tunnels, like MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES along with the BGP Encapsulation Extended Community from [RFC9012]. That community tells you the encapsulation type (MPLSoGRE or MPLSoUDP), and it may use the SHT value of 01 or 10 to signal local bias or the ESI Label, respectively. 🎀

Now the strict part 🚨 An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with these tunnel encapsulation types from [RFC9012]: VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP Tunnel Encapsulation Extended Community at all. In all these cases there's no real choice for the split-horizon method, so the SHT value MUST be set to 00. 🔒 If a route with any of those encapsulation options is received with an SHT value other than 00, it SHOULD apply the treat-as-withdraw behavior, per [RFC7606]. ⚠️

Geneve is its own thing 🧚 An egress NVE advertising A-D per ES route(s) for an ES with Geneve encapsulation (tunnel encapsulation type 19 in the BGP Tunnel Encapsulation attribute [RFC9012]) MAY use an SHT value of 01 or 10. A value of 01 means the intent to use local bias, regardless of whether an Ethernet option TLV with a non-zero Source-ID is present, as described in [EVPN-GENEVE]. A value of 10 means the intent to use ESI Label-based split horizon, and it's only valid if an Ethernet option TLV with a non-zero Source-ID is present. A value of 00 is the default behavior from Table 1, which is to use local bias if:

  • a. no ESI Label is present in the Ethernet option TLV, or
  • b. there is no Ethernet option TLV.

Otherwise, the ESI Label split-horizon method is applied. 🫧

These procedures assume a single encapsulation is supported in the egress NVE. Section 3 describes the extra procedures for NVEs that support multiple encapsulations. 🌈

2.3. The ESI Label Value in A-D per ES Routes 🧁

This doc also updates [RFC8365] about the value advertised in the ESI Label field of the ESI Label extended community, like so:

  • The A-D per ES route(s) for an ES MAY have an ESI Label value of zero if the SHT value is 01. Section 2.2 lists the scenarios where the SHT can be 01. An ESI Label value of zero means you don't have to allocate labels where they aren't used, such as in the local-bias method. 🦋
  • The A-D per ES route(s) for an ES MAY have an ESI Label value of zero for VXLAN or NVGRE encapsulations. 🍓

2.4. Backwards Compatibility with NVEs from RFC 8365 🫶

As we covered in Section 2.2, this spec is backwards compatible with the split-horizon filtering behavior in [RFC8365], so a non-upgraded NVE can be attached to the same ES as other NVEs that support this spec. 💖

Each NVE keeps an administrative SHT value for an ES, which gets advertised alongside the A-D per ES route. It also has an operational SHT value, which is the one actually used, no matter 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 doc assumes that an implementation of [RFC7432] or [RFC8365] that doesn't support this spec will ignore the values of all the Flags in the ESI Label extended community, except for the "Single-Active" bit. So a non-upgraded NVE will disregard any SHT value other than 00. 👀 If an upgraded NVE receives at least one A-D per ES route for the ES with an SHT value of 00, it MUST revert its operational SHT to the default split-horizon method in Table 1, no matter its administrative SHT. 🔄

Here's an example 🎀 Say an NVE attached to ES N receives two A-D per ES routes for N from different NVEs, NVE1 and NVE2. If the route from NVE1 has an SHT value of 00 and the one from NVE2 has an SHT value of 01, the NVE MUST use the default split-horizon method specified in Table 1 as its operational SHT, regardless of its administrative SHT. 😭

All NVEs attached to an ES with an 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 exclusively, and the NVEs don't need a valid, non-zero ESI Label. 🧠

If an NVE switches its operational SHT value from 01 (Local Bias) to 00 (Default SHT) because a new non-upgraded NVE joined the ES, and it previously advertised a zero ESI Label, it MUST send an update with a valid, non-zero ESI Label, unless all the non-upgraded NVEs in the ES support only local bias. 🚨

For example, say NVE1 and NVE2 use MPLSoUDP as their encapsulation, are attached to the same Ethernet Segment ES1, and advertise an SHT value of 01 (Local Bias) with a zero ESI Label value. Now NVE3, which doesn't support this spec, joins ES1 and advertises an SHT value of 00 (default). When NVE1 and NVE2 receive NVE3's A-D per ES route, they MUST update their A-D per ES routes for ES1 to include a valid, non-zero ESI Label value. 💅 The assumption here is that NVE3 only supports the default ESI Label-based split-horizon filtering. 🦋

3. Procedures for NVEs Supporting Multiple Encapsulations 🎀

okay so bestie, this is where things get really juicy 💅. As laid out in [RFC8365], an NVE that supports multiple data plane encapsulations (like VXLAN, NVGRE, MPLS, MPLSoUDP, Geneve) MUST indicate all of them using BGP Encapsulation extended communities as defined in [RFC9012] for all EVPN routes. Slay the consistency 🫶. This section clarifies the multihoming split-horizon behavior for NVEs that advertise and receive multiple BGP Encapsulation extended communities along with the A-D per ES routes ✨.

Quick notation check 🧚: we use {x, y} (more than two is possible too) to show the encapsulations advertised in BGP Encapsulation extended communities (or the BGP Tunnel Encapsulation Attribute), where x and y are different encapsulation values. And when Geneve is one of them, the tunnel type gets indicated in either a BGP Encapsulation extended community or a BGP Tunnel Encapsulation Attribute 🌈.

It's important to know that an NVE MAY advertise multiple A-D per ES routes for the same ES instead of just one 💖. Each route carries a set of Route Targets (RTs), and the total set of RTs for a given ES is called the RT-set for that ES. Every EVI represented in the RT-set gets its RT included in one, and only one, A-D per ES route for that ES 🦋. And when multiple A-D per ES routes go out for the same ES, each route MUST have a distinct Route Distinguisher. No copy-paste RDs, periodt 💅.

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. Here's how that plays out 🍓:

  • An A-D per ES route for ES-x may be advertised with {VXLAN, NVGRE} encapsulations.
  • An A-D per ES route for ES-y may be advertised with {MPLS, MPLSoUDP, MPLSoGRE} encapsulations (or a subset).
  • But an A-D per ES route for ES-z MUST NOT be advertised with {MPLS, VXLAN} encapsulations. Absolutely not 💀.

This document levels up the described behavior 👑 as follows:

a. An A-D per ES route for ES-x MAY be advertised with multiple encapsulations, some of which support a single split-horizon method. In this case, the SHT value MUST be 00. So encapsulations like {VXLAN, NVGRE}, {VXLAN, Geneve}, or {MPLS, MPLSoGRE, MPLSoUDP} can all show up in an A-D per ES route. For all of these, the SHT value MUST be 00, and the treat-as-withdraw behavior [RFC7606] gets applied if any other value shows up 🙈.

b. An A-D per ES route for ES-y MAY be advertised with multiple encapsulations that all support both split-horizon methods. In this case, the SHT value MAY be 01 if the preferred method is local bias, or 10 if the ESI Label-based method is desired ✨. For example, encapsulations like {MPLSoGRE, MPLSoUDP, Geneve} (or a subset) MAY be advertised in an A-D per ES route with an SHT value of 01. The ESI Label value in this case MAY be zero 🌸.

c. If ES-z with an RT-set made of (RT1, RT2, RT3.. RTn) supports multiple encapsulations that need different split-horizon methods, a distinct A-D per ES route (or group of routes) per split-horizon method MUST be advertised. Let's say we have an ES-z with n RTs, where:

  • the EVIs for (RT1..RTi) support VXLAN,
  • the ones for (RTi+1..RTm) (with i<m) support MPLSoUDP with local bias, and
  • the ones for (RTm+1..RTn) (with m<n) support Geneve with ESI Label-based split horizon.

In this scenario, three groups of A-D per ES routes MUST be advertised for ES-z 🧚‍♀️:

  • A-D per ES route group 1, including (RT1..RTi) with encapsulation {VXLAN} and an SHT value of 00. The ESI Label MAY be zero.
  • A-D per ES route group 2, including (RTi+1..RTm) with encapsulation {MPLSoUDP} and an SHT value of 01. The ESI Label MAY be zero.
  • A-D per ES route group 3, including (RTm+1..RTn) with encapsulation {Geneve} and an SHT value of 10. The ESI Label MUST have a valid, non-zero value, and the Ethernet option as defined in [RFC8926] MUST be advertised. Non-negotiable 😭.

As per [RFC8365], it is the responsibility of the operator of a given EVI to make sure that all of the NVEs within that EVI support a common encapsulation. If that condition isn't met, you could be looking at service disruption or failure 💔.

4. Security Considerations 🔥

okay this section is lowkey the most serious one, so let's be real 🫶. All the security considerations described in [RFC7432] apply to this document too 🔐.

Also, this document modifies the procedures for split-horizon filtering as outlined in [RFC8365], giving operators a choice between local bias and ESI Label-based filtering for tunnels that support both methods 🦋. Misconfiguring the desired SHT could lead to forwarding behaviors that differ from what was intended, and that's a real risk 😬. Beyond that risk, this document describes procedures to make sure all PE devices or NVEs connected to the same ES agree on a common SHT method, with a fallback to a default behavior if any two PEs or NVEs in the ES advertise mismatched SHT bits 🛡️. So, consequently, unauthorized changes to the SHT configuration by an attacker on a single PE or NVE of the ES should not cause traffic disruption (as long as the SHT value is valid per this document), but they may still alter forwarding behavior 💀. Stay vigilant, bestie 👑.

5. IANA Considerations 🌈

Per this document, IANA has created the "EVPN ESI Label Extended Community Flags" registry for the 1-octet Flags field in the ESI Label Extended Community [RFC7432], as follows:

     +==============+=============================+===========+
     | Bit Position | Name                        | Reference |
     +==============+=============================+===========+
     | 0-1          | Multihoming Redundancy Mode | [RFC7432] |
     +--------------+-----------------------------+-----------+
     | 2-5          | Unassigned                  |           |
     +--------------+-----------------------------+-----------+
     | 6-7          | Split-Horizon Type          | RFC 9746  |
     +--------------+-----------------------------+-----------+

Table 2 📋

IANA has also created the "Multihoming Redundancy Mode" registry for the related field of the "EVPN ESI Label Extended Community Flags". The registry has been populated with the following initial values:

     +=======+=============================+===========+
     | Value | Multihoming Redundancy Mode | Reference |
     +=======+=============================+===========+
     | 00    | All-Active                  | [RFC7432] |
     +-------+-----------------------------+-----------+
     | 01    | Single-Active               | [RFC7432] |
     +-------+-----------------------------+-----------+
     | 10    | Unassigned                  |           |
     +-------+-----------------------------+-----------+
     | 11    | Unassigned                  |           |
     +-------+-----------------------------+-----------+

Table 3 📋

Finally, IANA has created the "Split-Horizon Type" registry for the related field of the "EVPN ESI Label Extended Community Flags". The registry has been populated with the following initial values:

      +=======+===========================+===========+
      | Value | Split-Horizon Type Value  | Reference |
      +=======+===========================+===========+
      | 00    | Default SHT               | RFC 9746  |
      +-------+---------------------------+-----------+
      | 01    | Local Bias                | RFC 9746  |
      +-------+---------------------------+-----------+
      | 10    | ESI Label-based filtering | RFC 9746  |
      +-------+---------------------------+-----------+
      | 11    | Unassigned                |           |
      +-------+---------------------------+-----------+

Table 4 📋

New registrations in the "EVPN ESI Label Extended Community Flags", "Multihoming Redundancy Mode", and "Split-Horizon Type" registries will be made through the "IETF Review" procedure defined in [RFC8126]. These registries live in the "Border Gateway Protocol (BGP) Extended Communities" registry group 🧁.

6. References 📚

6.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7432]  Sajassi, A., Ed., 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, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

   [RFC9252]  Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
              B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
              Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
              DOI 10.17487/RFC9252, July 2022,
              <https://www.rfc-editor.org/info/rfc9252>.

6.2. Informative References 📚

Acknowledgments 🫶

The authors wanna give a huge shoutout to Anoop Ghanwani, Gyan Mishra, and Jeffrey Zhang for reviewing and leaving super useful comments 💖. Big thanks also to Gunter Van de Velde and Sue Hares for their thorough review 💅✨.

Authors' Addresses 🦋

Jorge Rabadan (editor) 🌸

Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com

Kiran Nagaraj 🍓

Kiran Nagaraj
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: kiran.nagaraj@nokia.com

Wen Lin 💜

Wen Lin
Juniper Networks
Email: wlin@juniper.net

Ali Sajassi 👑

Ali Sajassi
Cisco Systems, Inc.
Email: sajassi@cisco.com
📦 where this page comes from