rfc9746.original   rfc9746.txt 
BESS Workgroup J. Rabadan, Ed. Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Internet-Draft K. Nagaraj Request for Comments: 9746 K. Nagaraj
Updates: 8365, 7432 (if approved) Nokia Updates: 7432, 8365 Nokia
Intended status: Standards Track W. Lin Category: Standards Track W. Lin
Expires: 17 February 2025 Juniper ISSN: 2070-1721 Juniper
A. Sajassi A. Sajassi
Cisco Cisco
16 August 2024 February 2025
BGP EVPN Multi-Homing Extensions for Split Horizon Filtering BGP EVPN Multihoming Extensions for Split Horizon Filtering
draft-ietf-bess-evpn-mh-split-horizon-11
Abstract Abstract
Ethernet Virtual Private Network (EVPN) is commonly used with Network An Ethernet Virtual Private Network (EVPN) is commonly used with
Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Network Virtualization Overlay (NVO) tunnels as well as with MPLS and
Routing tunnels. The multi-homing procedures in EVPN may vary based Segment Routing (SR) tunnels. The multihoming procedures in EVPN may
on the type of tunnel used within the EVPN Broadcast Domain. vary based on the type of tunnel used within the EVPN Broadcast
Specifically, there are two multi-homing Split Horizon procedures Domain. Specifically, there are two multihoming split-horizon
designed to prevent looped frames on multi-homed Customer Edge (CE) procedures designed to prevent looped frames on multihomed Customer
devices: the ESI Label-based procedure and the Local Bias procedure. Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based
The ESI Label-based Split Horizon is applied to MPLS-based tunnels, procedure and the local-bias procedure. The ESI Label-based split-
such as MPLSoUDP, while the Local Bias procedure is used for other horizon procedure is applied to MPLS-based tunnels such as MPLS over
tunnels, such as VXLAN. UDP (MPLSoUDP), while the local-bias procedure is used for other
tunnels such as Virtual eXtensible Local Area Network (VXLAN)
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 MPLSoGRE, MPLSoUDP, GENEVE, and SRv6. This document updates include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network
the EVPN multi-homing procedures described in RFC 8365 and RFC 7432, Virtualization Encapsulation (Geneve), and Segment Routing over IPv6
enabling operators to select the Split Horizon procedure that meets (SRv6) tunnels. This document updates the EVPN multihoming
their specific requirements. procedures described in RFCs 7432 and 8365, enabling operators to
select the split-horizon procedure that meets their specific
requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9746.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 February 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 1.1. Conventions and Terminology
1.2. Split Horizon Filtering and Tunnel Encapsulations . . . . 5 1.2. Split-Horizon Filtering and Tunnel Encapsulations
2. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . 9 2. BGP EVPN Extensions
2.1. The Split Horizon Type . . . . . . . . . . . . . . . . . 9 2.1. The Split-Horizon Type
2.2. Use of the Split Horizon Type In A-D Per ES Routes . . . 10 2.2. Use of the Split-Horizon Type in A-D per ES Routes
2.3. ESI Label Value In A-D Per ES Routes . . . . . . . . . . 12 2.3. The ESI Label Value in A-D per ES Routes
2.4. Backwards Compatibility With RFC8365 NVEs . . . . . . . . 12 2.4. Backwards Compatibility with NVEs from RFC 8365
3. Procedures for NVEs Supporting Multiple Encapsulations . . . 13 3. Procedures for NVEs Supporting Multiple Encapsulations
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.2. Informative References
7.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses
1. Introduction 1. Introduction
Ethernet Virtual Private Networks (EVPN) 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 with MPLS data plane (SR-MPLS), where the * MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the
relevant EVPN procedures are specified in [RFC7432]. Segment relevant EVPN procedures are specified in [RFC7432]. SR-MPLS
Routing with MPLS data plane tunneling is specified in [RFC8660]. tunneling is specified in [RFC8660].
* Segment Routing with IPv6 data plane (SRv6), where the relevant * Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN
EVPN procedures are specified in [RFC9252]. SRv6 is specified in procedures are specified in [RFC9252]. SRv6 is specified in
[RFC8402][RFC8754]. [RFC8402] and [RFC8754].
Split Horizon, in this document, follows the definition in [RFC7432]. In this document, the term "split horizon" follows the definition in
Split Horizon refers to the EVPN multihoming procedure that prevents [RFC7432]. Split horizon refers to the EVPN multihoming procedure
a PE from sending a frame back to a multihomed Customer Edge (CE) that prevents a Provider Edge (PE) from sending a frame back to a
when that CE originated the frame in the first place. multihomed Customer Edge (CE) when that CE originated the frame in
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 MPLS-over-UDP, and its procedures over X (MPLSoX) tunnels, such as MPLSoUDP, and its procedures are
are detailed in [RFC7432]. Conversely, the Local Bias procedure is detailed in [RFC7432]. Conversely, the local-bias procedure is used
used for IP-based tunnels, such as VXLAN tunnels, and it is described for IP-based tunnels, such as VXLAN tunnels, and it is described in
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 BCP "OPTIONAL" in this document are to be interpreted as described in
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: refers to the EVPN Ethernet Auto-Discovery per A-D per ES route: Auto-Discovery per Ethernet Segment route (as
ES route defined in [RFC7432]. defined in [RFC7432]).
* Arg.FE2: refers to the ESI filtering argument used for Split Arg.FE2: Refers to the ESI filtering argument used for split horizon
Horizon as specified in [RFC9252]. as specified in [RFC9252].
* Broadcast Domain (BD): an emulated Ethernet, such that two systems BD: Broadcast Domain. Refers to an emulated Ethernet, such that two
on the same BD will receive each other's broadcast, unknown and systems on the same BD will receive each other's BUM traffic. In
multicast traffic. In this document, BD also refers to the this document, BD also refers to the instantiation of a BD on an
instantiation of a Broadcast Domain on an EVPN PE. An EVPN PE can EVPN PE. An EVPN PE can be attached to one or multiple BDs of the
be attached to one or multiple BDs of the same tenant. same tenant.
* BUM: Broadcast, Unknown unicast and Multicast traffic. BUM: Broadcast, Unknown Unicast, and Multicast
* Designated Forwarder (DF): as defined in [RFC7432], an ES may be CE: Customer Edge
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 and ESI: Ethernet Segment and Ethernet Segment Identifier. ES: Ethernet Segment
* EVI: EVPN Instance ESI: Ethernet Segment Identifier
* EVI-RT: EVI Route Target. A group of NVEs attached to the same EVI: EVPN Instance
EVI will share the same EVI-RT.
* GENEVE: Generic Network Virtualization Encapsulation, [RFC8926] EVI-RT: EVI Route Target. Refers to a group of NVEs attached to the
([IANA-BGP-TUNNEL-ENCAP] tunnel type 19). same EVI that will share the same EVI-RT.
* MPLS tunnels and non-MPLS NVO tunnels: refer to Multi-Protocol Geneve: Generic Network Virtualization Encapsulation [RFC8926] (see
Label Switching (or the absence of it) Network Virtualization tunnel type 19 in [TUNNEL-ENCAP]).
Overlay tunnels. Network Virtualization Overlay tunnels use an IP
encapsulation for overlay frames, where the source IP address
identifies the ingress NVE and the destination IP address the
egress NVE.
* MPLSoUDP: Multi-Protocol Label Switching over User Datagram MPLS tunnels and non-MPLS NVO tunnels: Refers to Multiprotocol Label
Protocol, [RFC7510] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 13). Switching (or the absence of it) Network Virtualization Overlay
tunnels. 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.
* MPLSoGRE: Multi-Protocol Label Switching over Generic Network MPLSoUDP: Multiprotocol Label Switching over User Datagram Protocol
Encapsulation, [RFC4023] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 11). [RFC7510] (see tunnel type 13 in [TUNNEL-ENCAP]).
* MPLSoX: refers to MPLS over any IP encapsulation. Examples are MPLSoGRE: Multiprotocol Label Switching over Generic Network
MPLS-over-UDP or MPLS-over-GRE. Encapsulation [RFC4023] (see tunnel type 11 in [TUNNEL-ENCAP]).
* NVE: Network Virtualization Edge device. MPLSoX: Refers to MPLS over any IP encapsulation, for example,
MPLSoUDP or MPLSoGRE.
* NVGRE: Network Virtualization Using Generic Routing Encapsulation, NVE: Network Virtualization Edge
[RFC7637] ([IANA-BGP-TUNNEL-ENCAP] tunnel type 9).
* VXLAN: Virtual eXtensible Local Area Network, [RFC7348] NVGRE: Network Virtualization Using Generic Routing Encapsulation
([IANA-BGP-TUNNEL-ENCAP] tunnel type 8). [RFC7637] (see tunnel type 9 in [TUNNEL-ENCAP]).
* VXLAN-GPE: VXLAN Generic Protocol Extension, PE: Provider Edge
[I-D.ietf-nvo3-vxlan-gpe] ([IANA-BGP-TUNNEL-ENCAP] tunnel type
12).
* SHT: Split Horizon Type, it refers to the Split Horizon method RTs: Route Targets
that a PE intends to use and advertises in an A-D per ES route.
* SRv6: Segment Routing with an IPv6 data plane, [RFC8402][RFC8754]. VXLAN: Virtual eXtensible Local Area Network [RFC7348] (see tunnel
type 8 in [TUNNEL-ENCAP]).
VXLAN-GPE: VXLAN Generic Protocol Extension [VXLAN-GPE] (see tunnel
type 12 in [TUNNEL-ENCAP]).
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.
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:
* 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 Network Virtualization Edge (NVE) device multihoming. The ingress NVE device appends a label
appends a label corresponding to the source Ethernet Segment corresponding to the source ESI (the ESI label) during packet
Identifier (ESI label) during packet encapsulation. The egress encapsulation. The egress NVE verifies the ESI label when
NVE verifies the ESI label when attempting to forward a multi- attempting to forward a multi-destination frame through a local
destination frame through a local Ethernet Segment (ES) interface. ES interface. If the ESI label matches the site identifier (the
If the ESI label matches the site identifier (ESI) associated with ESI) associated with that ES interface, then the packet is not
that ES interface, the packet is not forwarded. This mechanism forwarded. This mechanism effectively prevents forwarding loops
effectively prevents forwarding loops for BUM traffic. for BUM traffic.
The 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-flight Single-Active multihoming to prevent transient loops for in-
packets when the egress NVE assumes the role of Designated flight packets when the egress NVE assumes the role of DF for an
Forwarder for an ES. ES.
* Local Bias [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 of mechanism, known as local bias, relies on the source IP address
the tunnel to determine whether to forward BUM traffic to a local of the tunnel to determine whether to forward BUM traffic to a
Ethernet Segment (ES) interface at the egress Network local ES interface at the egress NVE.
Virtualization Edge (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 out which identifies the ingress NVE. The egress NVE then filters
the frame on all local interfaces connected to ESs that are shared out the frame on all local interfaces connected to ESs that are
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 Designated Forwarder election state, for ESs, regardless of the DF election state, for all BUM traffic
all BUM traffic ingressing from the access Attachment Circuits ingressing from the access ACs. This local replication at the
(ACs). This local replication at the ingress NVE is the basis for ingress NVE is the basis for the term "local bias".
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 Designated ingress NVE deactivates the ACs for which it is not the DF.
Forwarder. Consequently, local replication to non-Designated Consequently, local replication to non-DF ACs cannot occur,
Forwarder ACs cannot occur, leading to transient in-flight BUM leading to transient in-flight BUM packets being looped back to
packets to be looped back to the originating site by newly elected the originating site by newly elected DF egress NVEs.
Designated Forwarder 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 MPLS over GRE MPLS tunnels. However, IP-based MPLS tunnels such as MPLSoGRE or
(MPLSoGRE) or MPLS over UDP (MPLSoUDP), are also categorized as IP MPLSoUDP are also categorized as IP tunnels and have the potential to
tunnels and have the potential to support both procedures. These support both procedures. These tunnels are capable of carrying ESI
tunnels are capable of carrying ESI labels and also utilize a tunnel labels and also utilize a tunnel IP header in which the source IP
IP header in which the source IP address identifies the ingress address identifies the ingress NVE.
Network Virtualization Edge (NVE).
Similarly, certain IP tunnels - that include an identifier for the Similarly, certain IP tunnels (those that include an identifier for
source Ethernet Segment (ES) in the tunnel header - may also the source ES in the tunnel header) may also potentially support
potentially support either procedure. Examples of such tunnels either procedure. Examples of such tunnels include Geneve and SRv6:
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, NVE; therefore, local bias is possible. Also, Section 4.1 of
[I-D.ietf-bess-evpn-geneve] section 4.1 defines an Ethernet option [EVPN-GENEVE] defines an Ethernet option Type-Length-Value (TLV)
TLV (Type Length Value) 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) [RFC9252] (section 6.1.1) is the ESI filtering argument (Arg.FE2) (see Section 6.1.1 of
[RFC8986] (section 4.12) of the service Segment Identifier (SID) [RFC9252] and Section 4.12 of [RFC8986]) of the service Segment
received on an A-D per ES route from the egress PE. Identifier (SID) received on an A-D per ES route from the egress
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
Split Horizon Type (SHT) is contingent upon the negotiation of the SHT is contingent upon the negotiation of the Ethernet Option with
Ethernet Option with the Source ID TLV. In the case of SRv6, the the Source ID TLV. In the case of SRv6, the default SHT is specified
default SHT is specified as ESI Label filtering in the table, as its as ESI Label filtering in the table, as its behavior is analogous to
behavior is analogous to that of ESI Label filtering. In this that of ESI Label filtering. In this document, "ESI Label filtering"
document, ESI Label filtering refers to the Split Horizon filtering refers to the split-horizon filtering based on the presence of a
based on the presence of a source Ethernet Segment (ES) identifier in source ES identifier in the tunnel header.
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 Horizon | Supports | Supports | | Tunnel | Default Split- | Supports | Supports |
| Encapsulation | Type (SHT) | Local Bias | ESI Label | | Encapsulation | Horizon Type (SHT) | Local Bias | ESI Label |
+===============+=========================+============+===========+ +===============+====================+============+===========+
| MPLSoGRE (IP- | ESI Label filtering | Yes | Yes | | MPLSoGRE (IP- | ESI Label | Yes | Yes |
| based MPLS) | | | | | based MPLS) | filtering | | |
+---------------+-------------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| MPLSoUDP (IP- | ESI Label filtering | Yes | Yes | | MPLSoUDP (IP- | ESI Label | Yes | Yes |
| based MPLS) | | | | | based MPLS) | filtering | | |
+---------------+-------------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| (SR-)MPLS | ESI Label filtering | No | Yes | | MPLS and SR- | ESI Label | No | Yes |
+---------------+-------------------------+------------+-----------+ | MPLS | filtering | | |
| VXLAN (IP | Local Bias | Yes | No | +---------------+--------------------+------------+-----------+
| tunnels) | | | | | VXLAN (IP | Local Bias | Yes | No |
+---------------+-------------------------+------------+-----------+ | tunnels) | | | |
| NVGRE (IP | Local Bias | Yes | No | +---------------+--------------------+------------+-----------+
| tunnels) | | | | | NVGRE (IP | Local Bias | Yes | No |
+---------------+-------------------------+------------+-----------+ | tunnels) | | | |
| VXLAN-GPE (IP | Local Bias | Yes | No | +---------------+--------------------+------------+-----------+
| tunnels) | | | | | VXLAN-GPE (IP | Local Bias | Yes | No |
+---------------+-------------------------+------------+-----------+ | tunnels) | | | |
| GENEVE (IP | Local Bias (no ESI Lb), | Yes | Yes | +---------------+--------------------+------------+-----------+
| tunnels) | ESI Label (if ESI lb) | | | | Geneve (IP | Local Bias (if no | Yes | Yes |
+---------------+-------------------------+------------+-----------+ | tunnels) | ESI Lb), ESI Label | | |
| SRv6 | ESI Label filtering | Yes | Yes | | | (if ESI lb) | | |
+---------------+-------------------------+------------+-----------+ +---------------+--------------------+------------+-----------+
| SRv6 | ESI Label | Yes | Yes |
| | 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 ([RFC7432] Section 7.5), 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | ESI Label | | Reserved=0 | ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ESI Label extended community Figure 1: ESI Label Extended Community
[RFC7432] defines the low-order bit of the Flags octet (bit 0) as the [RFC7432] defines the low-order bit of the Flags octet (bit 0) as the
"Single-Active" bit: "Single-Active" bit:
* 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 Ethernet Segment (ES) route. In split-horizon method in the A-D per ES route. In this document, the
this document, the Split Horizon procedure defined in [RFC8365] split-horizon procedure defined in Section 8.3.1 of [RFC8365] is
(section 8.3.1) is considered the default behavior, presuming that considered the default behavior, presuming that local bias is
Local Bias is employed exclusively for IP tunnels, while ESI Label- employed exclusively for IP tunnels, while ESI Label-based split
based Split Horizon is used for IP-based MPLS tunnels. This document horizon is used for IP-based MPLS tunnels. This document specifies
specifies that the two high-order bits in the Flags octet (bits 6 and that the two high-order bits in the Flags octet (bits 6 and 7)
7) constitute the "Split Horizon Type" (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 process them as 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 a reserved value, for future use.
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 from 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 inconsistency in the SHT value advertised by the NVEs * In case of an inconsistency in the SHT value advertised by the
attached to the same ES for a given EVI, all the NVEs MUST revert NVEs attached to the same ES for a given EVI, all the NVEs MUST
to the [RFC8365] behavior, and use the default SHT in Table 1, revert to the behavior in [RFC8365] and use the default SHT in
irrespective of the advertised SHT. Table 1, irrespective of the advertised SHT.
* An SHT different from 00 MUST NOT be set if the Single-Active bit * An SHT different than 00 MUST NOT be set if the "Single-Active"
is set. A received A-D per ES route where Single-Active and SHT bit is set. A received A-D per ES route where the "Single-Active"
bits are different from zero MUST follow the treat-as-withdraw and SHT bits are different than zero MUST follow the treat-as-
behavior [RFC7606]. withdraw behavior in [RFC7606].
* 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 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 from 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
[I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. A Encapsulation attribute [RFC9012]) MAY use an SHT value of 01 or 10.
value of 01 indicates the intent to use Local Bias, regardless of the A value of 01 indicates the intent to use local bias, regardless of
presence of an Ethernet option TLV with a non-zero Source-ID, as the presence of an Ethernet option TLV with a non-zero Source-ID, as
described in [I-D.ietf-bess-evpn-geneve]. A value of 10 indicates described in [EVPN-GENEVE]. A value of 10 indicates the intent to
the intent to use ESI Label-based Split Horizon, and it is only valid use ESI Label-based split horizon, and it is only valid if an
if an Ethernet option TLV with non-zero Source-ID is present. A Ethernet option TLV with a non-zero Source-ID is present. A value of
value of 00 indicates the default behavior outlined in Table 1, which 00 indicates the default behavior outlined in Table 1, which is to
is to use Local Bias if: a) no ESI-Label is present in the Ethernet use local bias if:
option TLV, or b) if there is no Ethernet option TLV. Otherwise, the
ESI Label Split Horizon method is applied. 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 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. 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 RFC8365 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 Ethernet Segment An NVE maintains an administrative SHT value for an ES, which is
(ES), which is advertised alongside the A-D per ES route, and an advertised alongside the A-D per ES route, and an operational SHT
operational SHT value, which is the one actually used regardless of value, which is the one actually used regardless of what the NVE has
what the NVE has advertised. The administrative SHT matches the advertised. The administrative SHT matches the operational SHT if
operational SHT if all the NVEs attached to the ES have the same all the NVEs attached to the ES have the same administrative SHT.
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 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 (RT). The total set of Route conveying a set of Route Targets (RTs). The total set of RTs
Targets associated with a given ES is referred to as the RT-set for associated with a given ES is referred to as the RT-set for that ES.
that ES. Each of the EVIs represented in the RT-set will have its RT Each of the EVIs represented in the RT-set will have its RT included
included in one, and only one, A-D per ES route for the ES. When in one, and only one, A-D per ES route for the ES. When multiple A-D
multiple A-D per ES routes are advertised for the same ES, each route per ES routes are advertised for the same ES, each route must have a
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).
* But 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 Split Horizon Type (SHT) value MUST be method. In this case, the SHT value MUST be 00. For instance,
00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, encapsulations such as {VXLAN, NVGRE}, {VXLAN, Geneve}, or {MPLS,
GENEVE}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In
A-D per ES route. In all these cases, the SHT value MUST be 00 all these cases, the SHT value MUST be 00 and the treat-as-
and the behavior treat-as-withdraw [RFC7606] is applied in case withdraw behavior [RFC7606] is applied in case of any other
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 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 Route Targets (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, local bias, and
* and the ones for (RTm+1..RTn) (with m<n) support GENEVE with * the ones for (RTm+1..RTn) (with m<n) support Geneve with ESI
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 Split Horizon support both methods. Misconfiguration of the desired SHT could lead
Type (SHT) could lead to forwarding behaviors that differ from the to forwarding behaviors that differ from the intended configuration.
intended configuration. Apart from this risk, this document Apart from this risk, this document describes procedures to ensure
describes procedures to ensure that all Provider Edge (PE) devices or that all PE devices or NVEs connected to the same ES agree on a
Network Virtualization Edges (NVEs) connected to the same Ethernet common SHT method, with a fallback to a default behavior in case of a
Segment (ES) agree on a common SHT method, with a fallback to a mismatch in the SHT bits being advertised by any two PEs or NVEs in
default behavior in case of a mismatch in the SHT bits being the ES. Consequently, unauthorized changes to the SHT configuration
advertised by any two PEs or NVEs in the Ethernet Segment. by an attacker on a single PE or NVE of the ES should not cause
Consequently, unauthorized changes to the SHT configuration by an traffic disruption (as long as the SHT value is valid as per this
attacker on a single PE or NVE of the Ethernet Segment should not document) but may result in alterations to forwarding behavior.
cause traffic disruption (as long as the SHT value is valid as per
this document) but may result in alterations to forwarding behavior.
5. IANA Considerations 5. IANA Considerations
This document creates a registry called "EVPN ESI Label Extended Per this document, IANA has created the "EVPN ESI Label Extended
Community Flags" for the 1-octet Flags field in the ESI Label Community Flags" registry for the 1-octet Flags field in the ESI
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 | This Document | | 6-7 | Split-Horizon Type | RFC 9746 |
+--------------+-----------------------------+---------------+ +--------------+-----------------------------+-----------+
Table 2 Table 2
This document also creates a registry for the "Multihoming Redundancy IANA has also created the "Multihoming Redundancy Mode" registry for
Mode" field of the EVPN ESI Label Extended Community Flags. This the related field of the "EVPN ESI Label Extended Community Flags".
registry is called "Multihoming Redundancy Mode" and is initialized The registry has been populated with the following initial values:
as follows:
+=======+=============================+===========+ +=======+=============================+===========+
| 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, a third registry for the "Split Horizon Type" field of the Finally, IANA has created the "Split-Horizon Type" registry for the
EVPN ESI Label Extended Community Flags is created by this document related field of the "EVPN ESI Label Extended Community Flags". The
too. This registry is called "Split Horizon Type" and is initialized registry has been populated with the following initial values:
as follows:
+=======+===========================+===============+ +=======+===========================+===========+
| Value | Split Horizon Type value | Reference | | Value | Split-Horizon Type Value | Reference |
+=======+===========================+===============+ +=======+===========================+===========+
| 00 | Default SHT | This document | | 00 | Default SHT | RFC 9746 |
+-------+---------------------------+---------------+ +-------+---------------------------+-----------+
| 01 | Local Bias | This document | | 01 | Local Bias | RFC 9746 |
+-------+---------------------------+---------------+ +-------+---------------------------+-----------+
| 10 | ESI Label based filtering | This document | | 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. Acknowledgments 6. References
The authors would like to thank Anoop Ghanwani, Gyan Mishra and
Jeffrey Zhang for their review and useful comments. Thanks to Gunter
van de Velde and Sue Hares as well, for their thorough review.
7. References
7.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,
DOI 10.17487/RFC9252, July 2022, DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>. <https://www.rfc-editor.org/info/rfc9252>.
7.2. Informative References 6.2. Informative References
[I-D.ietf-bess-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>.
[I-D.ietf-nvo3-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>.
[IANA-BGP-TUNNEL-ENCAP] Acknowledgments
IANA, "Border Gateway Protocol (BGP) Tunnel
Encapsulation", <https://www.iana.org/assignments/bgp- The authors would like to thank Anoop Ghanwani, Gyan Mishra, and
tunnel-encapsulation/bgp-tunnel- Jeffrey Zhang for their review and useful comments. Thanks to Gunter
encapsulation.xhtml#tunnel-types>. Van de Velde and Sue Hares as well, for their thorough review.
Authors' Addresses Authors' Addresses
Jorge Rabadan (editor) Jorge Rabadan (editor)
Nokia Nokia
520 Almanor Avenue 520 Almanor Avenue
Sunnyvale, CA 94085 Sunnyvale, CA 94085
United States of America United States of America
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Kiran Nagaraj Kiran Nagaraj
Nokia Nokia
520 Almanor Avenue 520 Almanor Avenue
 End of changes. 144 change blocks. 
441 lines changed or deleted 448 lines changed or added

This html diff was produced by rfcdiff 1.48.