rfc9746v1.txt   rfc9746.txt 
Internet Engineering Task Force (IETF) J. Rabadan, Ed. Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9746 K. Nagaraj Request for Comments: 9746 K. Nagaraj
Updates: 7432, 8365 Nokia Updates: 7432, 8365 Nokia
Category: Standards Track W. Lin Category: Standards Track W. Lin
ISSN: 2070-1721 Juniper ISSN: 2070-1721 Juniper
A. Sajassi A. Sajassi
Cisco Cisco
February 2025 March 2025
BGP EVPN Multihoming Extensions for Split Horizon Filtering BGP EVPN Multihoming Extensions for Split-Horizon Filtering
Abstract Abstract
An Ethernet Virtual Private Network (EVPN) is commonly used with An Ethernet Virtual Private Network (EVPN) is commonly used with
Network Virtualization Overlay (NVO) tunnels as well as with MPLS and Network Virtualization Overlay (NVO) tunnels as well as with MPLS and
Segment Routing (SR) tunnels. The multihoming procedures in EVPN may Segment Routing (SR) tunnels. The multihoming procedures in EVPN may
vary based on the type of tunnel used within the EVPN Broadcast vary based on the type of tunnel used within the EVPN Broadcast
Domain. Specifically, there are two multihoming Split Horizon Domain. Specifically, there are two multihoming split-horizon
procedures designed to prevent looped frames on multihomed Customer procedures designed to prevent looped frames on multihomed Customer
Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based
procedure and the Local Bias procedure. The ESI Label-based Split procedure and the local-bias procedure. The ESI Label-based split-
Horizon procedure is applied to MPLS-based tunnels such as MPLS over horizon procedure is applied to MPLS-based tunnels such as MPLS over
UDP (MPLSoUDP), while the Local Bias procedure is used for other UDP (MPLSoUDP), while the local-bias procedure is used for other
tunnels such as Virtual eXtensible Local Area Network (VXLAN) tunnels such as Virtual eXtensible Local Area Network (VXLAN)
tunnels. tunnels.
Current specifications do not allow operators to choose which Split Current specifications do not allow operators to choose which split-
Horizon procedure to use for tunnel encapsulations that support both horizon procedure to use for tunnel encapsulations that support both
methods. Examples of tunnels that may support both procedures methods. Examples of tunnels that may support both procedures
include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network
Virtualization Encapsulation (GENEVE), and Segment Routing over IPv6 Virtualization Encapsulation (Geneve), and Segment Routing over IPv6
(SRv6) tunnels. This document updates the EVPN multihoming (SRv6) tunnels. This document updates the EVPN multihoming
procedures described in RFCs 7432 and 8365, enabling operators to procedures described in RFCs 7432 and 8365, enabling operators to
select the Split Horizon procedure that meets their specific select the split-horizon procedure that meets their specific
requirements. requirements.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
skipping to change at line 71 skipping to change at line 71
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Conventions and Terminology 1.1. Conventions and Terminology
1.2. Split Horizon Filtering and Tunnel Encapsulations 1.2. Split-Horizon Filtering and Tunnel Encapsulations
2. BGP EVPN Extensions 2. BGP EVPN Extensions
2.1. The Split Horizon Type 2.1. The Split-Horizon Type
2.2. Use of the Split Horizon Type in A-D per ES Routes 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.3. The ESI Label Value in A-D per ES Routes
2.4. Backwards Compatibility with RFC 8365 NVEs 2.4. Backwards Compatibility with NVEs from RFC 8365
3. Procedures for NVEs Supporting Multiple Encapsulations 3. Procedures for NVEs Supporting Multiple Encapsulations
4. Security Considerations 4. Security Considerations
5. IANA Considerations 5. IANA Considerations
6. References 6. References
6.1. Normative References 6.1. Normative References
6.2. Informative References 6.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Ethernet Virtual Private Networks (EVPNs) are commonly used with the Ethernet Virtual Private Networks (EVPNs) are commonly used with the
following tunnel encapsulations: following tunnel encapsulations:
* Network Virtualization Overlay (NVO) tunnels, where the EVPN * Network Virtualization Overlay (NVO) tunnels, where the EVPN
procedures are specified in [RFC8365]. MPLSoGRE [RFC4023], procedures are specified in [RFC8365]. MPLSoGRE [RFC4023],
MPLSoUDP [RFC7510], GENEVE [RFC8926], or VXLAN [RFC7348] tunnels MPLSoUDP [RFC7510], Geneve [RFC8926], or VXLAN [RFC7348] tunnels
are considered NVO tunnels. are considered NVO tunnels.
* MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the * MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the
relevant EVPN procedures are specified in [RFC7432]. SR-MPLS relevant EVPN procedures are specified in [RFC7432]. SR-MPLS
tunneling is specified in [RFC8660]. tunneling is specified in [RFC8660].
* Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN * Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN
procedures are specified in [RFC9252]. SRv6 is specified in procedures are specified in [RFC9252]. SRv6 is specified in
[RFC8402] and [RFC8754]. [RFC8402] and [RFC8754].
In this document, the term "Split Horizon" follows the definition in In this document, the term "split horizon" follows the definition in
[RFC7432]. Split Horizon refers to the EVPN multihoming procedure [RFC7432]. Split horizon refers to the EVPN multihoming procedure
that prevents a Provider Edge (PE) from sending a frame back to a that prevents a Provider Edge (PE) from sending a frame back to a
multihomed Customer Edge (CE) when that CE originated the frame in multihomed Customer Edge (CE) when that CE originated the frame in
the first place. the first place.
EVPN multihoming procedures may vary depending on the type of tunnel EVPN multihoming procedures may vary depending on the type of tunnel
utilized within the EVPN Broadcast Domain. Specifically, there are utilized within the EVPN Broadcast Domain. Specifically, there are
two multihoming Split Horizon procedures employed to prevent looped two multihoming split-horizon procedures employed to prevent looped
frames on multihomed CE devices: the ESI Label-based procedure and frames on multihomed CE devices: the ESI Label-based procedure and
the Local Bias procedure. the local-bias procedure.
The ESI Label-based Split Horizon procedure is used for MPLS or MPLS The ESI Label-based split-horizon procedure is used for MPLS or MPLS
over X (MPLSoX) tunnels, such as MPLSoUDP, and its procedures are over X (MPLSoX) tunnels, such as MPLSoUDP, and its procedures are
detailed in [RFC7432]. Conversely, the Local Bias procedure is used detailed in [RFC7432]. Conversely, the local-bias procedure is used
for IP-based tunnels, such as VXLAN tunnels, and it is described in for IP-based tunnels, such as VXLAN tunnels, and it is described in
[RFC8365]. [RFC8365].
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AC: Attachment Circuit AC: Attachment Circuit
A-D per ES route: Auto-Discovery per Ethernet Segment route. Refers A-D per ES route: Auto-Discovery per Ethernet Segment route (as
to the EVPN Ethernet Auto-Discovery per ES route defined in defined in [RFC7432]).
[RFC7432].
Arg.FE2: Refers to the ESI filtering argument used for Split Horizon Arg.FE2: Refers to the ESI filtering argument used for split horizon
as specified in [RFC9252]. as specified in [RFC9252].
BD: Broadcast Domain. Refers to an emulated Ethernet, such that two BD: Broadcast Domain. Refers to an emulated Ethernet, such that two
systems on the same BD will receive each other's BUM traffic. In systems on the same BD will receive each other's BUM traffic. In
this document, BD also refers to the instantiation of a BD on an this document, BD also refers to the instantiation of a BD on an
EVPN PE. An EVPN PE can be attached to one or multiple BDs of the EVPN PE. An EVPN PE can be attached to one or multiple BDs of the
same tenant. same tenant.
BUM: Broadcast, Unknown Unicast, and Multicast BUM: Broadcast, Unknown Unicast, and Multicast
CE: Customer Edge
DF: Designated Forwarder. As defined in [RFC7432], an ES may be DF: Designated Forwarder. As defined in [RFC7432], an ES may be
multihomed (attached to more than one PE). An ES may also contain multihomed (attached to more than one PE). An ES may also contain
multiple BDs of one or more EVIs. For each such EVI, one of the multiple BDs of one or more EVIs. For each such EVI, one of the
PEs attached to the segment becomes that EVI's DF for that PEs attached to the segment becomes that EVI's DF for that
segment. Since a BD may belong to only one EVI, we can speak segment. Since a BD may belong to only one EVI, we can speak
unambiguously of the BD's DF for a given segment. unambiguously of the BD's DF for a given segment.
ES: Ethernet Segment ES: Ethernet Segment
ESI: Ethernet Segment Identifier ESI: Ethernet Segment Identifier
EVI: EVPN Instance EVI: EVPN Instance
EVI-RT: EVI Route Target. Refers to a group of NVEs attached to the EVI-RT: EVI Route Target. Refers to a group of NVEs attached to the
same EVI that will share the same EVI-RT. same EVI that will share the same EVI-RT.
GENEVE: Generic Network Virtualization Encapsulation [RFC8926] (see Geneve: Generic Network Virtualization Encapsulation [RFC8926] (see
tunnel type 19 in [TUNNEL-ENCAP]). tunnel type 19 in [TUNNEL-ENCAP]).
MPLS tunnels and non-MPLS NVO tunnels: Refers to Multiprotocol Label MPLS tunnels and non-MPLS NVO tunnels: Refers to Multiprotocol Label
Switching (or the absence of it) Network Virtualization Overlay Switching (or the absence of it) Network Virtualization Overlay
tunnels. NVO tunnels use an IP encapsulation for overlay frames, tunnels. NVO tunnels use an IP encapsulation for overlay frames,
where the source IP address identifies the ingress NVE and the where the source IP address identifies the ingress NVE and the
destination IP address identifies the egress NVE. destination IP address identifies the egress NVE.
MPLSoUDP: Multiprotocol Label Switching over User Datagram Protocol MPLSoUDP: Multiprotocol Label Switching over User Datagram Protocol
[RFC7510] (see tunnel type 13 in [TUNNEL-ENCAP]). [RFC7510] (see tunnel type 13 in [TUNNEL-ENCAP]).
skipping to change at line 186 skipping to change at line 187
Encapsulation [RFC4023] (see tunnel type 11 in [TUNNEL-ENCAP]). Encapsulation [RFC4023] (see tunnel type 11 in [TUNNEL-ENCAP]).
MPLSoX: Refers to MPLS over any IP encapsulation, for example, MPLSoX: Refers to MPLS over any IP encapsulation, for example,
MPLSoUDP or MPLSoGRE. MPLSoUDP or MPLSoGRE.
NVE: Network Virtualization Edge NVE: Network Virtualization Edge
NVGRE: Network Virtualization Using Generic Routing Encapsulation NVGRE: Network Virtualization Using Generic Routing Encapsulation
[RFC7637] (see tunnel type 9 in [TUNNEL-ENCAP]). [RFC7637] (see tunnel type 9 in [TUNNEL-ENCAP]).
PE: Provider Edge
RTs: Route Targets
VXLAN: Virtual eXtensible Local Area Network [RFC7348] (see tunnel VXLAN: Virtual eXtensible Local Area Network [RFC7348] (see tunnel
type 8 in [TUNNEL-ENCAP]). type 8 in [TUNNEL-ENCAP]).
VXLAN-GPE: VXLAN Generic Protocol Extension [VXLAN-GPE] (see tunnel VXLAN-GPE: VXLAN Generic Protocol Extension [VXLAN-GPE] (see tunnel
type 12 in [TUNNEL-ENCAP]). type 12 in [TUNNEL-ENCAP]).
SHT: Split Horizon Type. Refers to the Split Horizon method that a SHT: Split-Horizon Type. Refers to the split-horizon method that a
PE intends to use and advertises in an A-D per ES route. PE intends to use and advertises in an A-D per ES route.
SRv6: Segment Routing over IPv6 (see [RFC8402] and [RFC8754]). SRv6: Segment Routing over IPv6 (see [RFC8402] and [RFC8754]).
TLV: Type-Length-Value
This document also assumes familiarity with the terminology of This document also assumes familiarity with the terminology of
[RFC7432] and [RFC8365]. [RFC7432] and [RFC8365].
1.2. Split Horizon Filtering and Tunnel Encapsulations 1.2. Split-Horizon Filtering and Tunnel Encapsulations
EVPN supports two Split Horizon filtering mechanisms: EVPN supports two split-horizon filtering mechanisms:
1. ESI Label-based Split Horizon filtering [RFC7432]: 1. ESI Label-based split-horizon filtering [RFC7432]:
When EVPN is employed for MPLS transport tunnels, an MPLS label When EVPN is employed for MPLS transport tunnels, an MPLS label
facilitates Split Horizon filtering to support All-Active facilitates split-horizon filtering to support All-Active
multihoming. The ingress NVE device appends a label multihoming. The ingress NVE device appends a label
corresponding to the source Ethernet Segment Identifier (ESI corresponding to the source ESI (the ESI label) during packet
label) during packet encapsulation. The egress NVE verifies the encapsulation. The egress NVE verifies the ESI label when
ESI label when attempting to forward a multi-destination frame attempting to forward a multi-destination frame through a local
through a local Ethernet Segment (ES) interface. If the ESI ES interface. If the ESI label matches the site identifier (the
label matches the site identifier (ESI) associated with that ES ESI) associated with that ES interface, then the packet is not
interface, then the packet is not forwarded. This mechanism forwarded. This mechanism effectively prevents forwarding loops
effectively prevents forwarding loops for BUM traffic. for BUM traffic.
ESI Label Split Horizon filtering should also be utilized with ESI Label split-horizon filtering should also be utilized with
Single-Active multihoming to prevent transient loops for in- Single-Active multihoming to prevent transient loops for in-
flight packets when the egress NVE assumes the role of DF for an flight packets when the egress NVE assumes the role of DF for an
ES. ES.
2. Local Bias filtering [RFC8365]: 2. Local-bias filtering [RFC8365]:
Since IP tunnels such as VXLAN or NVGRE do not support the ESI Since IP tunnels such as VXLAN or NVGRE do not support the ESI
label or any MPLS label, an alternative Split Horizon filtering label or any MPLS label, an alternative split-horizon filtering
procedure must be implemented for All-Active multihoming. This procedure must be implemented for All-Active multihoming. This
mechanism, known as Local Bias, relies on the source IP address mechanism, known as local bias, relies on the source IP address
of the tunnel to determine whether to forward BUM traffic to a of the tunnel to determine whether to forward BUM traffic to a
local ES interface at the egress NVE. local ES interface at the egress NVE.
In summary and as specified in [RFC8365], each NVE tracks the IP In summary and as specified in [RFC8365], each NVE tracks the IP
address(es) of other NVEs with which it shares multihomed ESs. address(es) of other NVEs with which it shares multihomed ESs.
Upon receiving a BUM frame encapsulated in an IP tunnel, the Upon receiving a BUM frame encapsulated in an IP tunnel, the
egress NVE inspects the source IP address in the tunnel header, egress NVE inspects the source IP address in the tunnel header,
which identifies the ingress NVE. The egress NVE then filters which identifies the ingress NVE. The egress NVE then filters
out the frame on all local interfaces connected to ESs that are out the frame on all local interfaces connected to ESs that are
shared with the ingress NVE. shared with the ingress NVE.
Due to this behavior at the egress NVE, the ingress NVE is Due to this behavior at the egress NVE, the ingress NVE is
required to perform local replication to all directly attached required to perform local replication to all directly attached
ESs, regardless of the DF election state, for all BUM traffic ESs, regardless of the DF election state, for all BUM traffic
ingressing from the access ACs. This local replication at the ingressing from the access ACs. This local replication at the
ingress NVE is the basis for the term "Local Bias". ingress NVE is the basis for the term "local bias".
Local Bias is not suitable for Single-Active multihoming, as the Local bias is not suitable for Single-Active multihoming, as the
ingress NVE deactivates the ACs for which it is not the DF. ingress NVE deactivates the ACs for which it is not the DF.
Consequently, local replication to non-DF ACs cannot occur, Consequently, local replication to non-DF ACs cannot occur,
leading to transient in-flight BUM packets being looped back to leading to transient in-flight BUM packets being looped back to
the originating site by newly elected DF egress NVEs. the originating site by newly elected DF egress NVEs.
[RFC8365] specifies that Local Bias is exclusively utilized for IP [RFC8365] specifies that local bias is exclusively utilized for IP
tunnels, while ESI Label-based Split Horizon is employed for IP-based tunnels, while ESI Label-based split horizon is employed for IP-based
MPLS tunnels. However, IP-based MPLS tunnels such as MPLSoGRE or MPLS tunnels. However, IP-based MPLS tunnels such as MPLSoGRE or
MPLSoUDP are also categorized as IP tunnels and have the potential to MPLSoUDP are also categorized as IP tunnels and have the potential to
support both procedures. These tunnels are capable of carrying ESI support both procedures. These tunnels are capable of carrying ESI
labels and also utilize a tunnel IP header in which the source IP labels and also utilize a tunnel IP header in which the source IP
address identifies the ingress NVE. address identifies the ingress NVE.
Similarly, certain IP tunnels (those that include an identifier for Similarly, certain IP tunnels (those that include an identifier for
the source ES in the tunnel header) may also potentially support the source ES in the tunnel header) may also potentially support
either procedure. Examples of such tunnels include GENEVE and SRv6: either procedure. Examples of such tunnels include Geneve and SRv6:
* In a GENEVE tunnel, the source IP address identifies the ingress * In a Geneve tunnel, the source IP address identifies the ingress
NVE; therefore, Local Bias is possible. Also, Section 4.1 of NVE; therefore, local bias is possible. Also, Section 4.1 of
[EVPN-GENEVE] defines an Ethernet option Type-Length-Value (TLV) [EVPN-GENEVE] defines an Ethernet option Type-Length-Value (TLV)
to encode an ESI label value. to encode an ESI label value.
* In an SRv6 tunnel, the source IP address identifies the ingress * In an SRv6 tunnel, the source IP address identifies the ingress
NVE. By default, and as outlined in [RFC9252], the ingress PE NVE. By default, and as outlined in [RFC9252], the ingress PE
adds specific information to the SRv6 packet to enable the egress adds specific information to the SRv6 packet to enable the egress
PE to identify the source ES of the BUM packet. This information PE to identify the source ES of the BUM packet. This information
is the ESI filtering argument (Arg.FE2) (see Section 6.1.1 of is the ESI filtering argument (Arg.FE2) (see Section 6.1.1 of
[RFC9252] and Section 4.12 of [RFC8986]) of the service Segment [RFC9252] and Section 4.12 of [RFC8986]) of the service Segment
Identifier (SID) received on an A-D per ES route from the egress Identifier (SID) received on an A-D per ES route from the egress
PE. PE.
Table 1 presents various tunnel encapsulations along with their Table 1 presents various tunnel encapsulations along with their
supported and default Split Horizon methods. For GENEVE, the default supported and default split-horizon methods. For Geneve, the default
SHT is contingent upon the negotiation of the Ethernet Option with SHT is contingent upon the negotiation of the Ethernet Option with
the Source ID TLV. In the case of SRv6, the default SHT is specified the Source ID TLV. In the case of SRv6, the default SHT is specified
as ESI Label filtering in the table, as its behavior is analogous to as ESI Label filtering in the table, as its behavior is analogous to
that of ESI Label filtering. In this document, "ESI Label filtering" that of ESI Label filtering. In this document, "ESI Label filtering"
refers to the Split Horizon filtering based on the presence of a refers to the split-horizon filtering based on the presence of a
source ES identifier in the tunnel header. source ES identifier in the tunnel header.
This document classifies the tunnel encapsulations used by EVPN into: This document classifies the tunnel encapsulations used by EVPN into:
1. IP-based MPLS tunnels 1. IP-based MPLS tunnels
2. (SR-)MPLS tunnels, that is, MPLS and Segment Routing with MPLS 2. MPLS and SR-MPLS tunnels
data plane tunnels
3. IP tunnels 3. IP tunnels
4. SRv6 tunnels 4. SRv6 tunnels
Table 1 lists the encapsulations supported by this document. Any Table 1 lists the encapsulations supported by this document. Any
tunnel encapsulation not listed in Table 1 is out of scope. Tunnel tunnel encapsulation not listed in Table 1 is out of scope. Tunnel
encapsulations used by EVPN can be categorized into one of the four encapsulations used by EVPN can be categorized into one of the four
encapsulation groups mentioned above and support Split Horizon encapsulation groups mentioned above and support split-horizon
filtering based on the following rules: filtering based on the following rules:
* IP-based MPLS tunnels and SRv6 tunnels are capable of supporting * IP-based MPLS tunnels and SRv6 tunnels are capable of supporting
both Split Horizon filtering methods. both split-horizon filtering methods.
* (SR-)MPLS tunnels only support ESI Label-based Split Horizon * MPLS and SR-MPLS tunnels only support ESI Label-based split-
filtering. horizon filtering.
* IP tunnels support Local Bias Split Horizon filtering and may also * IP tunnels support local-bias split-horizon filtering and may also
support ESI Label-based Split Horizon filtering, provided they support ESI Label-based split-horizon filtering, provided they
incorporate a mechanism to identify the source ESI in the header. incorporate a mechanism to identify the source ESI in the header.
+===============+====================+============+===========+ +===============+====================+============+===========+
| Tunnel | Default Split | Supports | Supports | | Tunnel | Default Split- | Supports | Supports |
| Encapsulation | Horizon Type (SHT) | Local Bias | ESI Label | | Encapsulation | Horizon Type (SHT) | Local Bias | ESI Label |
+===============+====================+============+===========+ +===============+====================+============+===========+
| MPLSoGRE (IP- | ESI Label | Yes | Yes | | MPLSoGRE (IP- | ESI Label | Yes | Yes |
| based MPLS) | filtering | | | | based MPLS) | filtering | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| MPLSoUDP (IP- | ESI Label | Yes | Yes | | MPLSoUDP (IP- | ESI Label | Yes | Yes |
| based MPLS) | filtering | | | | based MPLS) | filtering | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| (SR-)MPLS | ESI Label | No | Yes | | MPLS and SR- | ESI Label | No | Yes |
| | filtering | | | | MPLS | filtering | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| VXLAN (IP | Local Bias | Yes | No | | VXLAN (IP | Local Bias | Yes | No |
| tunnels) | | | | | tunnels) | | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| NVGRE (IP | Local Bias | Yes | No | | NVGRE (IP | Local Bias | Yes | No |
| tunnels) | | | | | tunnels) | | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| VXLAN-GPE (IP | Local Bias | Yes | No | | VXLAN-GPE (IP | Local Bias | Yes | No |
| tunnels) | | | | | tunnels) | | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| GENEVE (IP | Local Bias (if no | Yes | Yes | | Geneve (IP | Local Bias (if no | Yes | Yes |
| tunnels) | ESI Lb), ESI Label | | | | tunnels) | ESI Lb), ESI Label | | |
| | (if ESI lb) | | | | | (if ESI lb) | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| SRv6 | ESI Label | Yes | Yes | | SRv6 | ESI Label | Yes | Yes |
| | filtering | | | | | filtering | | |
+---------------+--------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
Table 1: Tunnel Encapsulations and Split Horizon Types Table 1: Tunnel Encapsulations and Split-Horizon Types
The ESI Label method is applicable for both All-Active and Single- The ESI Label method is applicable for both All-Active and Single-
Active configurations, whereas the Local Bias method is suitable only Active configurations, whereas the local-bias method is suitable only
for All-Active configurations. Moreover, the ESI Label method is for All-Active configurations. Moreover, the ESI Label method is
effective across different network domains, while Local Bias is effective across different network domains, while local bias is
constrained to networks where there is no change in the next hop constrained to networks where there is no change in the next hop
between the NVEs attached to the same ES. Nonetheless, some between the NVEs attached to the same ES. Nonetheless, some
operators favor the Local Bias method due to its simplification of operators favor the local-bias method due to its simplification of
the encapsulation process, reduced resource consumption on NVEs, and the encapsulation process, reduced resource consumption on NVEs, and
the fact that the ingress NVE always forwards traffic locally to the fact that the ingress NVE always forwards traffic locally to
other interfaces, thereby decreasing the delay in reaching multihomed other interfaces, thereby decreasing the delay in reaching multihomed
hosts. hosts.
This document extends the EVPN multihoming procedures to allow This document extends the EVPN multihoming procedures to allow
operators to select the preferred Split Horizon method for a given operators to select the preferred split-horizon method for a given
NVO tunnel according to their specific requirements. The choice NVO tunnel according to their specific requirements. The choice
between Local Bias and ESI Label Split Horizon is now allowed (by between local bias and ESI Label split horizon is now allowed (by
configuration) for tunnel encapsulations that support both methods, configuration) for tunnel encapsulations that support both methods,
and this selection is advertised along with the EVPN A-D per ES and this selection is advertised along with the EVPN A-D per ES
route. IP tunnels that do not support both methods, such as VXLAN or route. IP tunnels that do not support both methods, such as VXLAN or
NVGRE, will continue to adhere to the procedures specified in NVGRE, will continue to adhere to the procedures specified in
[RFC8365]. Note that this document does not modify the Local Bias or [RFC8365]. Note that this document does not modify the local bias or
the ESI Label Split Horizon procedures themselves, just focuses on the ESI Label split-horizon procedures themselves, just focuses on
the signaling and selection of the Split Horizon method to apply by the signaling and selection of the split-horizon method to apply by
the multihomed NVEs. the multihomed NVEs.
2. BGP EVPN Extensions 2. BGP EVPN Extensions
Extensions to EVPN are required to enable NVEs to advertise their Extensions to EVPN are required to enable NVEs to advertise their
preferred Split Horizon method for a given ES. Figure 1 illustrates preferred split-horizon method for a given ES. Figure 1 illustrates
the ESI Label extended community (Section 7.5 of [RFC7432]), which is the ESI Label extended community (Section 7.5 of [RFC7432]), which is
consistently advertised alongside the EVPN A-D per ES route. All consistently advertised alongside the EVPN A-D per ES route. All
NVEs connected to an ES advertise an A-D per ES route for that ES, NVEs connected to an ES advertise an A-D per ES route for that ES,
including the extended community, which communicates information including the extended community, which communicates information
regarding the multihoming mode (either All-Active or Single-Active) regarding the multihoming mode (either All-Active or Single-Active)
and, if necessary, specifies the ESI Label to be utilized. and, if necessary, specifies the ESI Label to be utilized.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 404 skipping to change at line 410
* A value of 0 means that the multihomed ES is operating in All- * A value of 0 means that the multihomed ES is operating in All-
Active multihoming redundancy mode. Active multihoming redundancy mode.
* A value of 1 means that the multihomed ES is operating in Single- * A value of 1 means that the multihomed ES is operating in Single-
Active multihoming redundancy mode. Active multihoming redundancy mode.
Section 5 establishes a registry for the Flags octet, designating the Section 5 establishes a registry for the Flags octet, designating the
"Single-Active" bit as the low-order bit of the newly defined "Single-Active" bit as the low-order bit of the newly defined
Multihoming Redundancy Mode field. Multihoming Redundancy Mode field.
2.1. The Split Horizon Type 2.1. The Split-Horizon Type
[RFC8365] does not include any explicit indication regarding the [RFC8365] does not include any explicit indication regarding the
Split Horizon method in the A-D per ES route. In this document, the split-horizon method in the A-D per ES route. In this document, the
Split Horizon procedure defined in Section 8.3.1 of [RFC8365] is split-horizon procedure defined in Section 8.3.1 of [RFC8365] is
considered the default behavior, presuming that Local Bias is considered the default behavior, presuming that local bias is
employed exclusively for IP tunnels, while ESI Label-based Split employed exclusively for IP tunnels, while ESI Label-based split
Horizon is used for IP-based MPLS tunnels. This document specifies horizon is used for IP-based MPLS tunnels. This document specifies
that the two high-order bits in the Flags octet (bits 6 and 7) that the two high-order bits in the Flags octet (bits 6 and 7)
constitute the "Split Horizon Type" or "SHT" field, where: constitute the "Split-Horizon Type" or "SHT" field, where:
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|SHT| |RED| |SHT| |RED|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
RED = "Multihoming Redundancy Mode" field (section 5) RED = "Multihoming Redundancy Mode" field (see Table 2)
SHT bit 7 6 SHT bit 7 6
----------- -----------
0 0 --> Default SHT 0 0 --> Default SHT
Backwards compatible with [RFC8365] and [RFC7432] Backwards compatible with [RFC8365] and [RFC7432]
0 1 --> Local Bias 0 1 --> Local Bias
1 0 --> ESI Label-based filtering 1 0 --> ESI Label-based filtering
1 1 --> reserved for future use 1 1 --> Unassigned
* SHT = 00 is backwards compatible with [RFC8365] and [RFC7432], and * SHT = 00 is backwards compatible with [RFC8365] and [RFC7432], and
indicates that the advertising NVE intends to use the default or indicates that the advertising NVE intends to use the default or
built-in SHT. The default SHT is shown in Table 1 for each built-in SHT. The default SHT is shown in Table 1 for each
encapsulation. An egress NVE that follows the [RFC8365] behavior encapsulation. An egress NVE that follows the [RFC8365] behavior
and does not support this specification will ignore the SHT bits and does not support this specification will ignore the SHT bits
(which is equivalent to processing them as a value of 00). (which is equivalent to processing them as a value of 00).
* SHT = 01 indicates that the advertising NVE intends to use Local * SHT = 01 indicates that the advertising NVE intends to use local-
Bias procedures in the ES for which the AD per-ES route is bias procedures in the ES for which the AD per-ES route is
advertised. advertised.
* SHT = 10 indicates that the advertising NVE intends to use the ESI * SHT = 10 indicates that the advertising NVE intends to use the ESI
Label-based Split Horizon method procedures in the ES for which Label-based split-horizon method procedures in the ES for which
the AD per-ES route is advertised. the AD per-ES route is advertised.
* SHT = 11 is a reserved value, for future use. * SHT = 11 is Unassigned.
2.2. Use of the Split Horizon Type in A-D per ES Routes 2.2. Use of the Split-Horizon Type in A-D per ES Routes
The following behavior is observed: The following behavior is observed:
* An SHT value of 01 or 10 MUST NOT be used with encapsulations that * 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 support only one SHT in Table 1, and MAY be used by encapsulations
that support the two SHTs in Table 1. that support the two SHTs in Table 1.
* An SHT value different than 00 expresses the intent to use a * An SHT value different than 00 expresses the intent to use a
specific Split Horizon method, but does not reflect the actual specific split-horizon method, but does not reflect the actual
operational SHT used by the advertising NVE, unless all the NVEs operational SHT used by the advertising NVE, unless all the NVEs
attached to the ES advertise the same SHT. attached to the ES advertise the same SHT.
* In case of an inconsistency in the SHT value advertised by the * In case of an inconsistency in the SHT value advertised by the
NVEs attached to the same ES for a given EVI, all the NVEs MUST NVEs attached to the same ES for a given EVI, all the NVEs MUST
revert to the behavior in [RFC8365] and use the default SHT in revert to the behavior in [RFC8365] and use the default SHT in
Table 1, irrespective of the advertised SHT. Table 1, irrespective of the advertised SHT.
* An SHT different than 00 MUST NOT be set if the "Single-Active" * 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" bit is set. A received A-D per ES route where the "Single-Active"
skipping to change at line 478 skipping to change at line 484
* The SHT MUST have the same value in each Ethernet A-D per ES route * 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 that an NVE advertises for a given ES and a given encapsulation
(see Section 3 for NVEs supporting multiple encapsulations). (see Section 3 for NVEs supporting multiple encapsulations).
As an example, egress NVEs that support IP-based MPLS tunnels, such As an example, egress NVEs that support IP-based MPLS tunnels, such
as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES
along with the BGP Encapsulation Extended Community, as defined in along with the BGP Encapsulation Extended Community, as defined in
[RFC9012]. This extended community indicates the encapsulation type [RFC9012]. This extended community indicates the encapsulation type
(MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to (MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to
signify the intent to use Local Bias or the ESI Label, respectively. signify the intent to use local bias or the ESI Label, respectively.
An egress NVE MUST NOT use an SHT value other than 00 when An egress NVE MUST NOT use an SHT value other than 00 when
advertising an A-D per ES route with [RFC9012] Tunnel encapsulation advertising an A-D per ES route with the following tunnel
types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP encapsulation types from [RFC9012]: VXLAN (type 8), NVGRE (type 9),
Tunnel Encapsulation Extended Community at all. In all these cases, MPLS (type 10), or no BGP Tunnel Encapsulation Extended Community at
it is presumed that there is no choice for the Split Horizon method; all. In all these cases, it is presumed that there is no choice for
therefore, the SHT value MUST be set to 00. If a route with any of the split-horizon method; therefore, the SHT value MUST be set to 00.
the mentioned encapsulation options is received and has an SHT value If a route with any of the mentioned encapsulation options is
different than 00, it SHOULD apply the treat-as-withdraw behavior, received and has an SHT value different than 00, it SHOULD apply the
per [RFC7606]. treat-as-withdraw behavior, per [RFC7606].
An egress NVE advertising A-D per ES route(s) for an ES with GENEVE An egress NVE advertising A-D per ES route(s) for an ES with Geneve
encapsulation ([RFC9012], Tunnel encapsulation type 19, encapsulation (tunnel encapsulation type 19 in the BGP Tunnel
[EVPN-GENEVE]) MAY use an SHT value of 01 or 10. A value of 01 Encapsulation attribute [RFC9012]) MAY use an SHT value of 01 or 10.
indicates the intent to use Local Bias, regardless of the presence of A value of 01 indicates the intent to use local bias, regardless of
an Ethernet option TLV with a non-zero Source-ID, as described in the presence of an Ethernet option TLV with a non-zero Source-ID, as
[EVPN-GENEVE]. A value of 10 indicates the intent to use ESI Label- described in [EVPN-GENEVE]. A value of 10 indicates the intent to
based Split Horizon, and it is only valid if an Ethernet option TLV use ESI Label-based split horizon, and it is only valid if an
with a non-zero Source-ID is present. A value of 00 indicates the Ethernet option TLV with a non-zero Source-ID is present. A value of
default behavior outlined in Table 1, which is to use Local Bias if: 00 indicates the default behavior outlined in Table 1, which is to
use local bias if:
a. no ESI Label is present in the Ethernet option TLV, or a. no ESI Label is present in the Ethernet option TLV, or
b. there is no Ethernet option TLV. b. there is no Ethernet option TLV.
Otherwise, the ESI Label Split Horizon method is applied. Otherwise, the ESI Label split-horizon method is applied.
These procedures assume a single encapsulation supported in the These procedures assume a single encapsulation supported in the
egress NVE. Section 3 describes additional procedures for NVEs egress NVE. Section 3 describes additional procedures for NVEs
supporting multiple encapsulations. supporting multiple encapsulations.
2.3. The ESI Label Value in A-D per ES Routes 2.3. The ESI Label Value in A-D per ES Routes
This document also updates [RFC8365] regarding the value that is This document also updates [RFC8365] regarding the value that is
advertised in the ESI Label field of the ESI Label extended advertised in the ESI Label field of the ESI Label extended
community, as follows: community, as follows:
* The A-D per ES route(s) for an ES MAY have an ESI Label value of * 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 specifies the scenarios zero if the SHT value is 01. Section 2.2 specifies the scenarios
where the SHT can be 01. An ESI Label value of zero eliminates where the SHT can be 01. An ESI Label value of zero eliminates
the need to allocate labels in cases where they are not utilized, the need to allocate labels in cases where they are not utilized,
such as in the Local Bias method. such as in the local-bias method.
* The A-D per ES route(s) for an ES MAY have an ESI Label value of * The A-D per ES route(s) for an ES MAY have an ESI Label value of
zero for VXLAN or NVGRE encapsulations. zero for VXLAN or NVGRE encapsulations.
2.4. Backwards Compatibility with RFC 8365 NVEs 2.4. Backwards Compatibility with NVEs from RFC 8365
As discussed in Section 2.2, this specification is backwards As discussed in Section 2.2, this specification is backwards
compatible with the Split Horizon filtering behavior in [RFC8365] and compatible with the split-horizon filtering behavior in [RFC8365] and
a non-upgraded NVE can be attached to the same ES as other NVEs a non-upgraded NVE can be attached to the same ES as other NVEs
supporting this specification. supporting this specification.
An NVE maintains an administrative SHT value for an ES, which is An NVE maintains an administrative SHT value for an ES, which is
advertised alongside the A-D per ES route, and an operational SHT advertised alongside the A-D per ES route, and an operational SHT
value, which is the one actually used regardless of what the NVE has value, which is the one actually used regardless of what the NVE has
advertised. The administrative SHT matches the operational SHT if advertised. The administrative SHT matches the operational SHT if
all the NVEs attached to the ES have the same administrative SHT. all the NVEs attached to the ES have the same administrative SHT.
This document assumes that an implementation of [RFC7432] or This document assumes that an implementation of [RFC7432] or
[RFC8365] that does not support the specifications in this document [RFC8365] that does not support the specifications in this document
will ignore the values of all the Flags in the ESI Label extended will ignore the values of all the Flags in the ESI Label extended
community, except for the "Single-Active" bit. Based on this community, except for the "Single-Active" bit. Based on this
assumption, a non-upgraded NVE will disregard any SHT value other assumption, 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 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 for the ES with an SHT value of 00, it MUST revert its operational
SHT to the default Split Horizon method, as described in Table 1, SHT to the default split-horizon method, as described in Table 1,
irrespective of its administrative SHT. irrespective of its administrative SHT.
For instance, consider an NVE attached to ES N that receives two A-D For instance, 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 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 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 value of 01, the NVE MUST use the default split-horizon method
specified in Table 1 as its operational SHT, regardless of its specified in Table 1 as its operational SHT, regardless of its
administrative SHT. administrative SHT.
All NVEs attached to an ES with an operational SHT value of 10 MUST 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 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 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 00, the ESI Label may be zero only if the default encapsulation
supports Local Bias exclusively, and the NVEs do not require the supports local bias exclusively, and the NVEs do not require the
presence of a valid, non-zero ESI Label. presence of a valid, non-zero ESI Label.
If an NVE changes its operational SHT value from 01 (Local Bias) to If an NVE changes its operational SHT value from 01 (Local Bias) to
00 (Default SHT) due to the presence of a new non-upgraded NVE in the 00 (Default SHT) due to the presence of a new non-upgraded NVE in the
ES, and it previously advertised a zero ESI Label, it MUST send an 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 update with a valid, non-zero ESI Label, unless all the non-upgraded
NVEs in the ES support only Local Bias. For example, consider NVE1 NVEs in the ES support only local bias. For example, consider NVE1
and NVE2 using MPLSoUDP as encapsulation, attached to the same and NVE2 using MPLSoUDP as encapsulation, attached to the same
Ethernet Segment ES1, and advertising an SHT value of 01 (Local Bias) Ethernet Segment ES1, and advertising an SHT value of 01 (Local Bias)
with a zero ESI Label value. Suppose NVE3, which does not support with a zero ESI Label value. Suppose NVE3, which does not support
this specification, joins ES1 and advertises an SHT value of 00 this specification, joins ES1 and advertises an SHT value of 00
(default). Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 (default). Upon receiving NVE3's A-D per ES route, NVE1 and NVE2
MUST update their A-D per ES routes for ES1 to include a valid, non- 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 zero ESI Label value. The assumption here is that NVE3 only supports
the default ESI Label-based Split Horizon filtering. the default ESI Label-based split-horizon filtering.
3. Procedures for NVEs Supporting Multiple Encapsulations 3. Procedures for NVEs Supporting Multiple Encapsulations
As specified in [RFC8365], an NVE that supports multiple data plane As specified in [RFC8365], an NVE that supports multiple data plane
encapsulations (e.g., VXLAN, NVGRE, MPLS, MPLSoUDP, GENEVE) must encapsulations (e.g., VXLAN, NVGRE, MPLS, MPLSoUDP, Geneve) must
indicate all supported encapsulations using BGP Encapsulation indicate all supported encapsulations using BGP Encapsulation
extended communities as defined in [RFC9012] for all EVPN routes. extended communities as defined in [RFC9012] for all EVPN routes.
This section provides clarification on the multihoming Split Horizon This section provides clarification on the multihoming split-horizon
behavior for NVEs that advertise and receive multiple BGP behavior for NVEs that advertise and receive multiple BGP
Encapsulation extended communities along with the A-D per ES routes. Encapsulation extended communities along with the A-D per ES routes.
This section uses the notation {x, y} (more than two encapsulations This section uses the notation {x, y} (more than two encapsulations
is possible too) to denote the encapsulations advertised in BGP is possible too) to denote the encapsulations advertised in BGP
Encapsulation extended communities (or the BGP Tunnel Encapsulation Encapsulation extended communities (or the BGP Tunnel Encapsulation
Attribute), where x and y represent different encapsulation values. Attribute), where x and y represent different encapsulation values.
When GENEVE is one of the encapsulations, the tunnel type is When Geneve is one of the encapsulations, the tunnel type is
indicated in either a BGP Encapsulation extended community or a BGP indicated in either a BGP Encapsulation extended community or a BGP
Tunnel Encapsulation Attribute. Tunnel Encapsulation Attribute.
It is important to note that an NVE MAY advertise multiple A-D per ES It is important to note that an NVE MAY advertise multiple A-D per ES
routes for the same ES, rather than a single route, with each route routes for the same ES, rather than a single route, with each route
conveying a set of Route Targets (RTs). The total set of RTs conveying a set of Route Targets (RTs). The total set of RTs
associated with a given ES is referred to as the RT-set for that ES. associated with a given ES is referred to as the RT-set for that ES.
Each of the EVIs represented in the RT-set will have its RT included Each 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 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 per ES routes are advertised for the same ES, each route must have a
distinct Route Distinguisher. distinct Route Distinguisher.
As per [RFC8365], an NVE that advertises multiple encapsulations in As per [RFC8365], an NVE that advertises multiple encapsulations in
the A-D per ES route(s) for an ES MUST advertise encapsulations that 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 use the same split-horizon filtering method in the same route. For
example: example:
* An A-D per ES route for ES-x may be advertised with {VXLAN, NVGRE} * An A-D per ES route for ES-x may be advertised with {VXLAN, NVGRE}
encapsulations. encapsulations.
* An A-D per ES route for ES-y may be advertised with {MPLS, * An A-D per ES route for ES-y may be advertised with {MPLS,
MPLSoUDP, MPLSoGRE} encapsulations (or a subset). MPLSoUDP, MPLSoGRE} encapsulations (or a subset).
* However, an A-D per ES route for ES-z MUST NOT be advertised with * However, an A-D per ES route for ES-z MUST NOT be advertised with
{MPLS, VXLAN} encapsulations. {MPLS, VXLAN} encapsulations.
This document extends the described behavior as follows: This document extends the described behavior as follows:
a. An A-D per ES route for ES-x may be advertised with multiple a. An A-D per ES route for ES-x may be advertised with multiple
encapsulations, some of which support a single Split Horizon encapsulations, some of which support a single split-horizon
method. In this case, the SHT value MUST be 00. For instance, method. In this case, the SHT value MUST be 00. For instance,
encapsulations such as {VXLAN, NVGRE}, {VXLAN, GENEVE}, or {MPLS, encapsulations such as {VXLAN, NVGRE}, {VXLAN, Geneve}, or {MPLS,
MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In
all these cases, the SHT value MUST be 00 and the treat-as- all these cases, the SHT value MUST be 00 and the treat-as-
withdraw behavior [RFC7606] is applied in case of any other withdraw behavior [RFC7606] is applied in case of any other
value. value.
b. An A-D per ES route for ES-y may be advertised with multiple b. An A-D per ES route for ES-y may be advertised with multiple
encapsulations that all support both Split Horizon methods. In encapsulations that all support both split-horizon methods. In
this case, the SHT value MAY be 01 if the preferred method is 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 local bias, or 10 if the ESI Label-based method is desired. For
example, encapsulations such as {MPLSoGRE, MPLSoUDP, GENEVE} (or example, encapsulations such as {MPLSoGRE, MPLSoUDP, Geneve} (or
a subset) MAY be advertised in an A-D per ES route with an SHT 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. value of 01. The ESI Label value in this case MAY be zero.
c. If ES-z with an RT-set composed of (RT1, RT2, RT3.. RTn) supports c. If ES-z with an RT-set composed of (RT1, RT2, RT3.. RTn) supports
multiple encapsulations requiring different Split Horizon multiple encapsulations requiring different split-horizon
methods, a distinct A-D per ES route (or group of routes) per methods, a distinct A-D per ES route (or group of routes) per
Split Horizon method MUST be advertised. For example, consider split-horizon method MUST be advertised. For example, consider
an ES-z with n RTs, where: an ES-z with n RTs, where:
* the EVIs corresponding to (RT1..RTi) support VXLAN, * the EVIs corresponding to (RT1..RTi) support VXLAN,
* the ones for (RTi+1..RTm) (with i<m) support MPLSoUDP with * the ones for (RTi+1..RTm) (with i<m) support MPLSoUDP with
Local Bias, and local bias, and
* the ones for (RTm+1..RTn) (with m<n) support GENEVE with ESI * the ones for (RTm+1..RTn) (with m<n) support Geneve with ESI
Label-based Split Horizon. Label-based split horizon.
In this scenario, three groups of A-D per ES routes MUST be In this scenario, three groups of A-D per ES routes MUST be
advertised for ES-z: advertised for ES-z:
* A-D per ES route group 1, including (RT1..RTi) with * A-D per ES route group 1, including (RT1..RTi) with
encapsulation {VXLAN} and an SHT value of 00. The ESI Label encapsulation {VXLAN} and an SHT value of 00. The ESI Label
MAY be zero. MAY be zero.
* A-D per ES route group 2, including (RTi+1..RTm) with * A-D per ES route group 2, including (RTi+1..RTm) with
encapsulation {MPLSoUDP} and an SHT value of 01. The ESI encapsulation {MPLSoUDP} and an SHT value of 01. The ESI
Label MAY be zero. Label MAY be zero.
* A-D per ES route group 3, including (RTm+1..RTn) with * A-D per ES route group 3, including (RTm+1..RTn) with
encapsulation {GENEVE} and an SHT value of 10. The ESI Label encapsulation {Geneve} and an SHT value of 10. The ESI Label
MUST have a valid, non-zero value, and the Ethernet option as MUST have a valid, non-zero value, and the Ethernet option as
defined in [RFC8926] MUST be advertised. defined in [RFC8926] MUST be advertised.
As per [RFC8365], it is the responsibility of the operator of a given As per [RFC8365], it is the responsibility of the operator of a given
EVI to ensure that all of the NVEs within that EVI support a common EVI to ensure that all of the NVEs within that EVI support a common
encapsulation. Failure to meet this condition may result in service encapsulation. Failure to meet this condition may result in service
disruption or failure. disruption or failure.
4. Security Considerations 4. Security Considerations
All the security considerations described in [RFC7432] are applicable All the security considerations described in [RFC7432] are applicable
to this document. to this document.
Additionally, this document modifies the procedures for Split Horizon Additionally, this document modifies the procedures for split-horizon
filtering as outlined in [RFC8365], offering operators a choice filtering as outlined in [RFC8365], offering operators a choice
between Local Bias and ESI Label-based filtering for tunnels that between local bias and ESI Label-based filtering for tunnels that
support both methods. Misconfiguration of the desired SHT could lead support both methods. Misconfiguration of the desired SHT could lead
to forwarding behaviors that differ from the intended configuration. to forwarding behaviors that differ from the intended configuration.
Apart from this risk, this document describes procedures to ensure Apart from this risk, this document describes procedures to ensure
that all PE devices or NVEs connected to the same ES agree on a that all PE devices or NVEs connected to the same ES agree on a
common SHT method, with a fallback to a default behavior in case of a common SHT method, with a fallback to a default behavior in case of a
mismatch in the SHT bits being advertised by any two PEs or NVEs in mismatch in the SHT bits being advertised by any two PEs or NVEs in
the ES. Consequently, unauthorized changes to the SHT configuration the ES. Consequently, unauthorized changes to the SHT configuration
by an attacker on a single PE or NVE of the ES should not cause 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 as per this traffic disruption (as long as the SHT value is valid as per this
document) but may result in alterations to forwarding behavior. document) but may result in alterations to forwarding behavior.
skipping to change at line 702 skipping to change at line 709
Community Flags" registry for the 1-octet Flags field in the ESI Community Flags" registry for the 1-octet Flags field in the ESI
Label Extended Community [RFC7432], as follows: Label Extended Community [RFC7432], as follows:
+==============+=============================+===========+ +==============+=============================+===========+
| Bit Position | Name | Reference | | Bit Position | Name | Reference |
+==============+=============================+===========+ +==============+=============================+===========+
| 0-1 | Multihoming Redundancy Mode | [RFC7432] | | 0-1 | Multihoming Redundancy Mode | [RFC7432] |
+--------------+-----------------------------+-----------+ +--------------+-----------------------------+-----------+
| 2-5 | Unassigned | | | 2-5 | Unassigned | |
+--------------+-----------------------------+-----------+ +--------------+-----------------------------+-----------+
| 6-7 | Split Horizon Type | RFC 9746 | | 6-7 | Split-Horizon Type | RFC 9746 |
+--------------+-----------------------------+-----------+ +--------------+-----------------------------+-----------+
Table 2 Table 2
IANA has also created the "Multihoming Redundancy Mode" registry for IANA has also created the "Multihoming Redundancy Mode" registry for
the related field of the "EVPN ESI Label Extended Community Flags". the related field of the "EVPN ESI Label Extended Community Flags".
The registry has been populated with the following initial values: The registry has been populated with the following initial values:
+=======+=============================+===========+ +=======+=============================+===========+
| Value | Multihoming Redundancy Mode | Reference | | Value | Multihoming Redundancy Mode | Reference |
+=======+=============================+===========+ +=======+=============================+===========+
| 00 | All-Active mode | [RFC7432] | | 00 | All-Active | [RFC7432] |
+-------+-----------------------------+-----------+ +-------+-----------------------------+-----------+
| 01 | Single-Active mode | [RFC7432] | | 01 | Single-Active | [RFC7432] |
+-------+-----------------------------+-----------+ +-------+-----------------------------+-----------+
| 10 | Unassigned | | | 10 | Unassigned | |
+-------+-----------------------------+-----------+ +-------+-----------------------------+-----------+
| 11 | Unassigned | | | 11 | Unassigned | |
+-------+-----------------------------+-----------+ +-------+-----------------------------+-----------+
Table 3 Table 3
Finally, IANA has created the "Split Horizon Type" registry for the Finally, IANA has created the "Split-Horizon Type" registry for the
related field of the "EVPN ESI Label Extended Community Flags". The related field of the "EVPN ESI Label Extended Community Flags". The
registry has been populated with the following initial values: registry has been populated with the following initial values:
+=======+===========================+===========+ +=======+===========================+===========+
| Value | Split Horizon Type Value | Reference | | Value | Split-Horizon Type Value | Reference |
+=======+===========================+===========+ +=======+===========================+===========+
| 00 | Default SHT | RFC 9746 | | 00 | Default SHT | RFC 9746 |
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
| 01 | Local Bias | RFC 9746 | | 01 | Local Bias | RFC 9746 |
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
| 10 | ESI Label-based filtering | RFC 9746 | | 10 | ESI Label-based filtering | RFC 9746 |
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
| 11 | Unassigned | | | 11 | Unassigned | |
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
Table 4 Table 4
New registrations in the "EVPN ESI Label Extended Community Flags", New registrations in the "EVPN ESI Label Extended Community Flags",
"Multihoming Redundancy Mode", and "Split Horizon Type" registries "Multihoming Redundancy Mode", and "Split-Horizon Type" registries
will be made through the "IETF Review" procedure defined in will be made through the "IETF Review" procedure defined in
[RFC8126]. These registries are located in the "Border Gateway [RFC8126]. These registries are located in the "Border Gateway
Protocol (BGP) Extended Communities" registry group. Protocol (BGP) Extended Communities" registry group.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
May 2017, <https://www.rfc-editor.org/info/rfc8174>. 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 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February May 2017, <https://www.rfc-editor.org/info/rfc8174>.
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018, DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>. <https://www.rfc-editor.org/info/rfc8365>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252, Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
skipping to change at line 793 skipping to change at line 800
6.2. Informative References 6.2. Informative References
[EVPN-GENEVE] [EVPN-GENEVE]
Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S. Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S.
Aldrin, "EVPN control plane for Geneve", Work in Progress, Aldrin, "EVPN control plane for Geneve", Work in Progress,
Internet-Draft, draft-ietf-bess-evpn-geneve-08, 5 July Internet-Draft, draft-ietf-bess-evpn-geneve-08, 5 July
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-evpn-geneve-08>. bess-evpn-geneve-08>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
Decraene, B., Litkowski, S., and R. Shakir, "Segment "The BGP Tunnel Encapsulation Attribute", RFC 9012,
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, DOI 10.17487/RFC9012, April 2021,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. <https://www.rfc-editor.org/info/rfc9012>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [TUNNEL-ENCAP]
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header IANA, "Border Gateway Protocol (BGP) Tunnel
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, Encapsulation", <https://www.iana.org/assignments/bgp-
<https://www.rfc-editor.org/info/rfc8754>. tunnel-encapsulation>.
[VXLAN-GPE] [VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN (VXLAN-GPE)", Work in Progress, Extension for VXLAN (VXLAN-GPE)", Work in Progress,
Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
nvo3-vxlan-gpe-13>. nvo3-vxlan-gpe-13>.
[TUNNEL-ENCAP]
IANA, "Border Gateway Protocol (BGP) Tunnel
Encapsulation", <https://www.iana.org/assignments/bgp-
tunnel-encapsulation>.
Acknowledgments Acknowledgments
The authors would like to thank Anoop Ghanwani, Gyan Mishra, and The authors would like to thank Anoop Ghanwani, Gyan Mishra, and
Jeffrey Zhang for their review and useful comments. Thanks to Gunter Jeffrey Zhang for their review and useful comments. Thanks to Gunter
Van de Velde and Sue Hares as well, for their thorough review. Van de Velde and Sue Hares as well, for their thorough review.
Authors' Addresses Authors' Addresses
Jorge Rabadan (editor) Jorge Rabadan (editor)
Nokia Nokia
 End of changes. 108 change blocks. 
178 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.48.