rfc9746xml2.original.xml   rfc9746.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.xml">
<!ENTITY RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8365.xml">
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8584.xml">
<!ENTITY I-D.ietf-bess-evpn-geneve SYSTEM "https://xml2rfc.ietf.org/public/rfc/b
ibxml3/reference.I-D.ietf-bess-evpn-geneve.xml">
<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7348.xml">
<!ENTITY RFC5512 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5512.xml">
<!ENTITY RFC4023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4023.xml">
<!ENTITY RFC7637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7637.xml">
<!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7510.xml">
<!ENTITY RFC8926 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8926.xml">
<!ENTITY RFC9012 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9012.xml">
<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7606.xml">
<!ENTITY RFC8660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8660.xml">
<!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8986.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8402.xml">
<!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8754.xml">
<!ENTITY RFC9252 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9252.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
<!ENTITY I-D.ietf-nvo3-vxlan-gpe SYSTEM "https://xml2rfc.ietf.org/public/rfc/bib
xml3/reference.I-D.ietf-nvo3-vxlan-gpe.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-bess-evpn-mh-split-horizon-11"
ipr="trust200902" submissionType="IETF" updates="8365, 7432">
<!--Generated by id2xml 1.5.0 on 2020-07-31T12:56:54Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="oo*+-"?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-bess-evpn-mh-split-horizon-11" number="9746" ipr="trust200902" consensus="tru e" submissionType="IETF" updates="7432, 8365" obsoletes="" xml:lang="en" tocIncl ude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="EVPN MH Split Horizon Extensions">BGP EVPN Multi-Homing <title abbrev="EVPN MH Split-Horizon Extensions">BGP EVPN Multihoming
Extensions for Split Horizon Filtering</title> Extensions for Split-Horizon Filtering</title>
<seriesInfo name="RFC" value="9746"/>
<author fullname="Jorge Rabadan" initials="J." role="editor" <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
surname="Rabadan"> n">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj"> <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>520 Almanor Avenue</street> <street>520 Almanor Avenue</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>kiran.nagaraj@nokia.com</email> <email>kiran.nagaraj@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Wen Lin" initials="W." surname="Lin"> <author fullname="Wen Lin" initials="W." surname="Lin">
<organization abbrev="Juniper">Juniper Networks</organization> <organization abbrev="Juniper">Juniper Networks</organization>
<address> <address>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<email>sajassi@cisco.com</email> <email>sajassi@cisco.com</email>
</address> </address>
</author> </author>
<date month="March" year="2025"/>
<area>RTG</area>
<workgroup>bess</workgroup>
<date day="16" month="August" year="2024"/> <keyword>EVPN Multihoming</keyword>
<keyword>split-horizon filtering</keyword>
<workgroup>BESS Workgroup</workgroup> <keyword>split horizon filtering</keyword>
<keyword>local bias</keyword>
<keyword>ESI</keyword>
<keyword>encapsulations</keyword>
<keyword>SHT</keyword>
<abstract> <abstract>
<t>Ethernet Virtual Private Network (EVPN) is commonly used with Network <t>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 on Segment Routing (SR) tunnels. The multihoming procedures in EVPN may
the type of tunnel used within the EVPN Broadcast Domain. Specifically, vary based on the type of tunnel used within the EVPN Broadcast
there are two multi-homing Split Horizon procedures designed to prevent Domain. Specifically, there are two multihoming split-horizon procedures
looped frames on multi-homed Customer Edge (CE) devices: the ESI designed to prevent looped frames on multihomed Customer Edge (CE)
Label-based procedure and the Local Bias procedure. The ESI Label-based devices: the Ethernet Segment Identifier (ESI) Label-based procedure and
Split Horizon is applied to MPLS-based tunnels, such as MPLSoUDP, while the local-bias procedure. The ESI Label-based split-horizon procedure is
the Local Bias procedure is used for other tunnels, such as VXLAN.</t> applied to MPLS-based tunnels such as MPLS over UDP (MPLSoUDP), while
the local-bias procedure is used for other tunnels such as Virtual
eXtensible Local Area Network (VXLAN) tunnels.</t>
<t>Current specifications do not allow operators to choose which Split <t>Current specifications do not allow operators to choose which split-hor
Horizon procedure to use for tunnel encapsulations that support both izon procedure to use for tunnel encapsulations that support both
methods. Examples of tunnels that may support both procedures include methods. Examples of tunnels that may support both procedures include
MPLSoGRE, MPLSoUDP, GENEVE, and SRv6. This document updates the EVPN MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network Virtualization
multi-homing procedures described in RFC 8365 and RFC 7432, enabling Encapsulation (Geneve), and Segment Routing over IPv6 (SRv6)
operators to select the Split Horizon procedure that meets their tunnels. This document updates the EVPN multihoming procedures described
specific requirements.</t> in RFCs 7432 and 8365, enabling operators to select the split-horizon
procedure that meets their specific requirements.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Introduction"> <section anchor="sect-1" numbered="true" toc="default">
<t>Ethernet Virtual Private Networks (EVPN) are commonly used with the <name>Introduction</name>
<t>Ethernet Virtual Private Networks (EVPNs) are commonly used with the
following tunnel encapsulations:</t> following tunnel encapsulations:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Network Virtualization Overlay (NVO) tunnels, where the EVPN <t>Network Virtualization Overlay (NVO) tunnels, where the EVPN
procedures are specified in <xref target="RFC8365"/>. MPLSoGRE <xref procedures are specified in <xref target="RFC8365"
target="RFC4023"/>, MPLSoUDP <xref target="RFC7510"/>, GENEVE <xref format="default"/>. MPLSoGRE <xref target="RFC4023"
target="RFC8926"/> or VXLAN <xref target="RFC7348"/> tunnels are format="default"/>, MPLSoUDP <xref target="RFC7510"
format="default"/>, Geneve <xref target="RFC8926" format="default"/>,
or VXLAN <xref target="RFC7348" format="default"/> tunnels are
considered NVO tunnels.</t> considered NVO tunnels.</t>
</li>
<t>MPLS and Segment Routing with MPLS data plane (SR-MPLS), where <li>
the relevant EVPN procedures are specified in <xref <t>MPLS and Segment Routing over MPLS (SR-MPLS) tunnels, where the
target="RFC7432"/>. Segment Routing with MPLS data plane tunneling relevant EVPN procedures are specified in <xref target="RFC7432"
is specified in <xref target="RFC8660"/>.</t> format="default"/>. SR-MPLS tunneling is specified in <xref
target="RFC8660" format="default"/>.</t>
<t>Segment Routing with IPv6 data plane (SRv6), where the relevant </li>
EVPN procedures are specified in <xref target="RFC9252"/>. SRv6 is <li>
specified in <xref target="RFC8402"/><xref target="RFC8754"/>.</t> <t>Segment Routing over IPv6 (SRv6) tunnels, where the relevant EVPN
</list></t> procedures are specified in <xref target="RFC9252"
format="default"/>. SRv6 is specified in <xref target="RFC8402"
<t>Split Horizon, in this document, follows the definition in <xref format="default"/> and <xref target="RFC8754"
target="RFC7432"/>. Split Horizon refers to the EVPN multihoming format="default"/>.</t>
procedure that prevents a PE from sending a frame back to a multihomed </li>
Customer Edge (CE) when that CE originated the frame in the first </ul>
place.</t> <t>In this document, the term "split horizon" follows the definition in <x
ref
target="RFC7432" format="default"/>. Split horizon refers to the EVPN
multihoming procedure that prevents a Provider Edge (PE) from sending a
frame back to a multihomed Customer Edge (CE) when that CE originated
the frame in the first place.</t>
<t>EVPN multihoming procedures may vary depending on the type of tunnel <t>EVPN multihoming procedures may vary depending on the type of tunnel
utilized within the EVPN Broadcast Domain. Specifically, there are two utilized within the EVPN Broadcast Domain. Specifically, there are two
multihoming Split Horizon procedures employed to prevent looped frames multihoming split-horizon procedures employed to prevent looped frames
on multihomed CE devices: the ESI Label-based procedure and the Local on multihomed CE devices: the ESI Label-based procedure and the local-bias
Bias procedure.</t> procedure.</t>
<t>The ESI Label-based Split Horizon procedure is used for MPLS or <t>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 MPLS over X (MPLSoX) tunnels, such as MPLSoUDP, and its procedures
are detailed in <xref target="RFC7432"/>. Conversely, the Local Bias are detailed in <xref target="RFC7432" format="default"/>. Conversely, the
local-bias
procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is procedure is used for IP-based tunnels, such as VXLAN tunnels, and it is
described in <xref target="RFC8365"/>. </t> described in <xref target="RFC8365" format="default"/>.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Conventions and Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<section anchor="sect-1.1" title="Conventions and Terminology"> <dl spacing="normal">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t><list style="symbols"> <dt>AC:</dt>
<t>AC: Attachment Circuit.</t> <dd>Attachment Circuit</dd>
<t>A-D per ES route: refers to the EVPN Ethernet Auto-Discovery <dt>A-D per ES route:</dt>
per ES route defined in <xref target="RFC7432"/>.</t> <dd>Auto-Discovery per Ethernet Segment
route (as defined in <xref target="RFC7432" format="default"/>).</dd
>
<t>Arg.FE2: refers to the ESI filtering argument used for Split <dt>Arg.FE2:</dt>
Horizon as specified in <xref target="RFC9252"/>.</t> <dd>Refers to the ESI filtering argument used for split horizon as
specified in <xref target="RFC9252" format="default"/>.</dd>
<t>Broadcast Domain (BD): an emulated Ethernet, such that two <dt>BD:</dt>
systems on the same BD will receive each other's broadcast, <dd>Broadcast Domain. Refers to an emulated Ethernet, such that
unknown and multicast traffic. In this document, BD also refers to two systems on the same BD will receive each other's BUM
the instantiation of a Broadcast Domain on an EVPN PE. An EVPN PE traffic. In this document, BD also refers to the instantiation of
can be attached to one or multiple BDs of the same tenant.</t> a BD on an EVPN PE. An EVPN PE can be attached to one or multiple
BDs of the same tenant.</dd>
<t>BUM: Broadcast, Unknown unicast and Multicast traffic.</t> <dt>BUM:</dt>
<dd>Broadcast, Unknown Unicast, and Multicast</dd>
<t>Designated Forwarder (DF): as defined in <xref <dt>CE:</dt><dd>Customer Edge</dd>
target="RFC7432"/>, an ES may be 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 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 unambiguously of the BD's DF for a given
segment.</t>
<t>ES and ESI: Ethernet Segment and Ethernet Segment <dt>DF:</dt>
Identifier.</t> <dd>Designated Forwarder. As defined in <xref
target="RFC7432" format="default"/>, an ES may be 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 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
unambiguously of the BD's DF for a given segment.</dd>
<t>EVI: EVPN Instance</t> <dt>ES:</dt>
<dd>Ethernet Segment</dd>
<t>EVI-RT: EVI Route Target. A group of NVEs attached to the same <dt>ESI:</dt>
EVI will share the same EVI-RT.</t> <dd>Ethernet Segment Identifier</dd>
<t>GENEVE: Generic Network Virtualization Encapsulation, <xref <dt>EVI:</dt>
target="RFC8926"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/> tunnel <dd>EVPN Instance</dd>
type 19).</t>
<t>MPLS tunnels and non-MPLS NVO tunnels: refer to Multi-Protocol <dt>EVI-RT:</dt><dd>EVI Route Target. Refers to a group of NVEs atta
Label Switching (or the absence of it) Network Virtualization ched to the same
Overlay tunnels. Network Virtualization Overlay tunnels use an IP EVI that will share the same EVI-RT.</dd>
<dt>Geneve:</dt><dd>Generic Network Virtualization Encapsulation
<xref target="RFC8926" format="default"/> (see tunnel type 19 in <xr
ef
target="TUNNEL-ENCAP" format="default"/>).</dd>
<dt>MPLS tunnels and non-MPLS NVO tunnels:</dt><dd>Refers to
Multiprotocol Label Switching (or the absence of it) Network
Virtualization Overlay tunnels. NVO tunnels use an IP
encapsulation for overlay frames, where the source IP address encapsulation for overlay frames, where the source IP address
identifies the ingress NVE and the destination IP address the identifies the ingress NVE and the destination IP address identifies
egress NVE.</t> the
egress NVE.</dd>
<t>MPLSoUDP: Multi-Protocol Label Switching over User Datagram <dt>MPLSoUDP:</dt><dd>Multiprotocol Label Switching over User
Protocol, <xref target="RFC7510"/> (<xref Datagram Protocol <xref target="RFC7510" format="default"/> (see
target="IANA-BGP-TUNNEL-ENCAP"/> tunnel type 13).</t> tunnel type 13 in <xref target="TUNNEL-ENCAP"
format="default"/>).</dd>
<t>MPLSoGRE: Multi-Protocol Label Switching over Generic Network <dt>MPLSoGRE:</dt><dd>Multiprotocol Label Switching over Generic
Encapsulation, <xref target="RFC4023"/> (<xref Network Encapsulation <xref target="RFC4023" format="default"/>
target="IANA-BGP-TUNNEL-ENCAP"/> tunnel type 11).</t> (see tunnel type 11 in <xref target="TUNNEL-ENCAP"
format="default"/>).</dd>
<t>MPLSoX: refers to MPLS over any IP encapsulation. Examples are <dt>MPLSoX:</dt><dd>Refers to MPLS over any IP encapsulation, for
MPLS-over-UDP or MPLS-over-GRE.</t> example, MPLSoUDP or MPLSoGRE.</dd>
<t>NVE: Network Virtualization Edge device.</t> <dt>NVE:</dt><dd>Network Virtualization Edge</dd>
<t>NVGRE: Network Virtualization Using Generic Routing <dt>NVGRE:</dt><dd>Network Virtualization Using Generic Routing
Encapsulation, <xref target="RFC7637"/> (<xref Encapsulation <xref target="RFC7637" format="default"/> (see
target="IANA-BGP-TUNNEL-ENCAP"/> tunnel type 9).</t> tunnel type 9 in <xref target="TUNNEL-ENCAP"
format="default"/>).</dd>
<t>VXLAN: Virtual eXtensible Local Area Network, <xref <dt>PE:</dt><dd>Provider Edge</dd>
target="RFC7348"/> (<xref target="IANA-BGP-TUNNEL-ENCAP"/> tunnel
type 8).</t>
<t>VXLAN-GPE: VXLAN Generic Protocol Extension, <xref <dt>RTs:</dt><dd>Route Targets</dd>
target="I-D.ietf-nvo3-vxlan-gpe"/> (<xref
target="IANA-BGP-TUNNEL-ENCAP"/> tunnel type 12).</t>
<t>SHT: Split Horizon Type, it refers to the Split Horizon method <dt>VXLAN:</dt><dd>Virtual eXtensible Local Area Network <xref
target="RFC7348" format="default"/> (see tunnel type 8 in <xref
target="TUNNEL-ENCAP" format="default"/>).</dd>
<dt>VXLAN-GPE:</dt><dd>VXLAN Generic Protocol Extension <xref
target="I-D.ietf-nvo3-vxlan-gpe" format="default"/> (see tunnel
type 12 in <xref target="TUNNEL-ENCAP"
format="default"/>).</dd>
<dt>SHT:</dt><dd>Split-Horizon Type. Refers to the split-horizon met
hod
that a PE intends to use and advertises in an A-D per ES that a PE intends to use and advertises in an A-D per ES
route.</t> route.</dd>
<t>SRv6: Segment Routing with an IPv6 data plane, <xref <dt>SRv6:</dt><dd>Segment Routing over IPv6 (see <xref target="RFC84
target="RFC8402"/><xref target="RFC8754"/>.</t> 02"
</list></t> format="default"/> and <xref target="RFC8754" format="default"/>).</
dd>
<dt>TLV:</dt><dd>Type-Length-Value</dd>
</dl>
<t>This document also assumes familiarity with the terminology of <t>This document also assumes familiarity with the terminology of
<xref target="RFC7432"/> and <xref target="RFC8365"/>.</t> <xref target="RFC7432" format="default"/> and <xref target="RFC8365"
format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Split-Horizon Filtering and Tunnel Encapsulations</name>
<section title="Split Horizon Filtering and Tunnel Encapsulations"> <t>EVPN supports two split-horizon filtering mechanisms:</t>
<t>EVPN supports two Split Horizon Filtering mechanisms:</t> <ol type="1" spacing="normal">
<li>
<t>ESI Label-based split-horizon filtering <xref target="RFC7432"
format="default"/>:</t>
<t><list style="symbols"> <t>When EVPN is employed for MPLS transport tunnels, an MPLS label
<t>ESI Label based Split Horizon filtering <xref facilitates split-horizon filtering to support All-Active
target="RFC7432"/><vspace blankLines="1"/>When EVPN is employed multihoming. The ingress NVE device appends a label corresponding to t
for MPLS transport tunnels, an MPLS label facilitates Split he source ESI
Horizon filtering to support All-Active multihoming. The ingress (the ESI label) during packet encapsulation. The egress NVE verifies
Network Virtualization Edge (NVE) device appends a label the ESI label when attempting to forward a multi-destination frame
corresponding to the source Ethernet Segment Identifier (ESI through a local ES interface. If the ESI label matches the site
label) during packet encapsulation. The egress NVE verifies the identifier (the ESI) associated with that ES interface, then the packet i
ESI label when attempting to forward a multi-destination frame s not forwarded. This mechanism effectively prevents forwarding loops for BUM tr
through a local Ethernet Segment (ES) interface. If the ESI label affic. </t>
matches the site identifier (ESI) associated with that ES
interface, the packet is not forwarded. This mechanism effectively <t>ESI Label split-horizon filtering should also
prevents forwarding loops for BUM traffic. <vspace
blankLines="1"/>The ESI Label Split Horizon filtering should also
be utilized with Single-Active multihoming to prevent transient be utilized with Single-Active multihoming to prevent transient
loops for in-flight packets when the egress NVE assumes the role loops for in-flight packets when the egress NVE assumes the role
of Designated Forwarder for an ES.</t> of DF for an ES.</t>
</li>
<t>Local Bias <xref target="RFC8365"/><vspace <li>
blankLines="1"/>Since IP tunnels, such as VXLAN or NVGRE, do not <t>Local-bias filtering <xref target="RFC8365" format="default"/>:</
support the ESI label or any MPLS label, an alternative Split t>
Horizon filtering procedure must be implemented for All-Active <t>Since IP tunnels such as VXLAN or NVGRE do not
multihoming. This mechanism, known as Local Bias, relies on the support the ESI label or any MPLS label, an alternative split-horizo
n filtering procedure must be implemented for All-Active
multihoming. This mechanism, known as local bias, relies on the
source IP address of the tunnel to determine whether to forward source IP address of the tunnel to determine whether to forward
BUM traffic to a local Ethernet Segment (ES) interface at the BUM traffic to a local ES interface at the
egress Network Virtualization Edge (NVE). <vspace egress NVE.</t>
blankLines="1"/>In summary and as specified in <xref <t>In summary and as specified in <xref target="RFC8365"
target="RFC8365"/>, each NVE tracks the IP address(es) of other format="default"/>, each NVE tracks the IP address(es) of other
NVEs with which it shares multihomed ESs. Upon receiving a BUM NVEs with which it shares multihomed ESs. Upon receiving a BUM
frame encapsulated in an IP tunnel, the egress NVE inspects the frame encapsulated in an IP tunnel, the egress NVE inspects the
source IP address in the tunnel header, which identifies the source IP address in the tunnel header, which identifies the
ingress NVE. The egress NVE then filters out the frame on all ingress NVE. The egress NVE then filters out the frame on all
local interfaces connected to ESs that are shared with the ingress local interfaces connected to ESs that are shared with the ingress
NVE. <vspace blankLines="1"/>Due to this behavior at the egress NVE.</t>
NVE, the ingress NVE is required to perform local replication to
all directly attached ESs, regardless of the Designated Forwarder
election state, for all BUM traffic ingressing from the access
Attachment Circuits (ACs). This local replication at the ingress
NVE is the basis for the term Local Bias. <vspace
blankLines="1"/>Local Bias is not suitable for Single-Active
multihoming, as the ingress NVE deactivates the ACs for which it
is not the Designated Forwarder. Consequently, local replication
to non-Designated Forwarder ACs cannot occur, leading to transient
in-flight BUM packets to be looped back to the originating site by
newly elected Designated Forwarder egress NVEs.</t>
</list></t>
<t><xref target="RFC8365"/> specifies that Local Bias is exclusively <t>Due to this behavior at the egress NVE, the ingress NVE is
utilized for IP tunnels, while ESI Label-based Split Horizon is required to perform local replication to all directly attached
employed for IP-based MPLS tunnels. However, IP-based MPLS tunnels, ESs, regardless of the DF election state, for all BUM traffic
such as MPLS over GRE (MPLSoGRE) or MPLS over UDP (MPLSoUDP), are also ingressing from the access ACs. This local replication at the
categorized as IP tunnels and have the potential to support both ingress NVE is the basis for the term "local bias".</t>
procedures. These tunnels are capable of carrying ESI labels and also
utilize a tunnel IP header in which the source IP address identifies
the ingress Network Virtualization Edge (NVE).</t>
<t>Similarly, certain IP tunnels - that include an identifier for the <t>Local bias is not suitable for Single-Active multihoming, as
source Ethernet Segment (ES) in the tunnel header - may also the ingress NVE deactivates the ACs for which it is not the
potentially support either procedure. Examples of such tunnels include DF. Consequently, local replication to non-DF ACs cannot occur,
GENEVE and SRv6.:</t> leading to transient in-flight BUM packets being looped back to
the originating site by newly elected DF egress NVEs.</t>
</li>
</ol>
<t><list style="symbols"> <t><xref target="RFC8365" format="default"/> specifies that local bias
<t>In a GENEVE tunnel, the source IP address identifies the is exclusively utilized for IP tunnels, while ESI Label-based split hori
ingress NVE therefore local bias is possible. Also, <xref zon is employed for IP-based MPLS tunnels. However, IP-based MPLS
target="I-D.ietf-bess-evpn-geneve"/> section 4.1 defines an tunnels such as MPLSoGRE or MPLSoUDP are also categorized as IP
Ethernet option TLV (Type Length Value) to encode an ESI label tunnels and have the potential to support both procedures. These
value.</t> tunnels are capable of carrying ESI labels and also utilize a tunnel
IP header in which the source IP address identifies the ingress
NVE.</t>
<t>Similarly, certain IP tunnels (those that include an identifier for
the source ES in the tunnel header) may also potentially support either
procedure. Examples of such tunnels include Geneve and SRv6:</t>
<ul spacing="normal">
<li>
<t>In a Geneve tunnel, the source IP address identifies the
ingress NVE; therefore, local bias is possible. Also, Section 4.1
of <xref target="I-D.ietf-bess-evpn-geneve" format="default"/>
defines an Ethernet option Type-Length-Value (TLV) to encode an
ESI label value.</t>
</li>
<li>
<t>In an SRv6 tunnel, the source IP address identifies the ingress <t>In an SRv6 tunnel, the source IP address identifies the ingress
NVE. By default, and as outlined in <xref target="RFC9252"/>, the NVE. By default, and as outlined in <xref target="RFC9252"
ingress PE adds specific information to the SRv6 packet to enable format="default"/>, the ingress PE adds specific information to
the egress PE to identify the source ES of the BUM packet. This the SRv6 packet to enable the egress PE to identify the source ES
information is the ESI filtering argument (Arg.FE2) <xref of the BUM packet. This information is the ESI filtering argument
target="RFC9252"/> (section 6.1.1) <xref target="RFC8986"/> (Arg.FE2) (see <xref target="RFC9252" sectionFormat="of"
(section 4.12) of the service Segment Identifier (SID) received on section="6.1.1"/> and <xref target="RFC8986" sectionFormat="of"
an A-D per ES route from the egress PE.</t> section="4.12"/>) of the service Segment Identifier (SID) received
</list></t> on an A-D per ES route from the egress PE.</t>
</li>
</ul>
<t><xref target="Tunnel"/> presents various tunnel encapsulations <t><xref target="Tunnel" format="default"/> presents various tunnel
along with their supported and default Split Horizon methods. For encapsulations along with their supported and default split-horizon
GENEVE, the default Split Horizon Type (SHT) is contingent upon the methods. For Geneve, the default SHT is contingent upon the
negotiation of the Ethernet Option with the Source ID TLV. In the case negotiation of the Ethernet Option with the Source ID TLV. In the case
of SRv6, the default SHT is specified as ESI Label filtering in the of SRv6, the default SHT is specified as ESI Label filtering in the
table, as its behavior is analogous to that of ESI Label filtering. In table, as its behavior is analogous to that of ESI Label filtering. In
this document, ESI Label filtering refers to the Split Horizon this document, "ESI Label filtering" refers to the split-horizon
filtering based on the presence of a source Ethernet Segment (ES) filtering based on the presence of a source ES
identifier in the tunnel header.</t> identifier in the tunnel header.</t>
<t>This document classifies the tunnel encapsulations used by EVPN <t>This document classifies the tunnel encapsulations used by EVPN
into:<list style="numbers"> into:</t>
<t>IP-based MPLS tunnels</t>
<t>(SR-)MPLS tunnels, that is, MPLS and Segment Routing with MPLS
data plane tunnels</t>
<ol spacing="normal" type="1"><li>
<t>IP-based MPLS tunnels</t>
</li>
<li>
<t>MPLS and SR-MPLS tunnels</t>
</li>
<li>
<t>IP tunnels</t> <t>IP tunnels</t>
</li>
<li>
<t>SRv6 tunnels</t> <t>SRv6 tunnels</t>
</list></t> </li>
</ol>
<t><xref target="Tunnel"/> lists the encapsulations supported by this <t><xref target="Tunnel" format="default"/> lists the encapsulations
document. Any tunnel encapsulation not listed in <xref supported by this document. Any tunnel encapsulation not listed in
target="Tunnel"/>) is out of scope. Tunnel encapsulations used by EVPN <xref target="Tunnel" format="default"/> is out of scope. Tunnel
can be categorized into one of the four encapsulation groups mentioned encapsulations used by EVPN can be categorized into one of the four
above and support Split Horizon filtering based on the following encapsulation groups mentioned above and support split-horizon
rules:</t> filtering based on the following rules:</t>
<t><list style="symbols"> <ul spacing="normal">
<li>
<t>IP-based MPLS tunnels and SRv6 tunnels are capable of <t>IP-based MPLS tunnels and SRv6 tunnels are capable of
supporting both Split Horizon filtering methods.</t> supporting both split-horizon filtering methods.</t>
</li>
<t>(SR-)MPLS tunnels only support ESI Label-based Split Horizon <li>
filtering</t> <t>MPLS and SR-MPLS tunnels only support ESI Label-based split-horiz
on filtering.</t>
<t>IP tunnels support Local Bias Split Horizon filtering and may </li>
also support ESI Label-based Split Horizon filtering, provided <li>
<t>IP tunnels support local-bias split-horizon filtering and may
also support ESI Label-based split-horizon filtering, provided
they incorporate a mechanism to identify the source ESI in the they incorporate a mechanism to identify the source ESI in the
header.</t> header.</t>
</list></t> </li>
<texttable align="left" anchor="Tunnel" style="all"
title="Tunnel Encapsulations and Split Horizon Types">
<ttcol>Tunnel Encapsulation</ttcol>
<ttcol>Default Split Horizon Type (SHT)</ttcol>
<ttcol>Supports Local Bias</ttcol>
<ttcol>Supports ESI Label</ttcol>
<c>MPLSoGRE (IP-based MPLS)</c>
<c>ESI Label filtering</c>
<c>Yes</c>
<c>Yes</c>
<c>MPLSoUDP (IP-based MPLS)</c>
<c>ESI Label filtering</c>
<c>Yes</c>
<c>Yes</c>
<c>(SR-)MPLS</c>
<c>ESI Label filtering</c>
<c>No</c>
<c>Yes</c>
<c>VXLAN (IP tunnels)</c>
<c>Local Bias</c>
<c>Yes</c>
<c>No</c>
<c>NVGRE (IP tunnels)</c>
<c>Local Bias</c>
<c>Yes</c>
<c>No</c>
<c>VXLAN-GPE (IP tunnels)</c>
<c>Local Bias</c>
<c>Yes</c>
<c>No</c>
<c>GENEVE (IP tunnels)</c>
<c>Local Bias (no ESI Lb), ESI Label (if ESI lb)</c>
<c>Yes</c>
<c>Yes</c>
<c>SRv6</c>
<c>ESI Label filtering</c>
<c>Yes</c>
<c>Yes</c>
</texttable>
</ul>
<table align="left" anchor="Tunnel">
<name>Tunnel Encapsulations and Split-Horizon Types</name>
<thead>
<tr>
<th align="left">Tunnel Encapsulation</th>
<th align="left">Default Split-Horizon Type (SHT)</th>
<th align="left">Supports Local Bias</th>
<th align="left">Supports ESI Label</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">MPLSoGRE (IP-based MPLS)</td>
<td align="left">ESI Label filtering</td>
<td align="left">Yes</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">MPLSoUDP (IP-based MPLS)</td>
<td align="left">ESI Label filtering</td>
<td align="left">Yes</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">MPLS and SR-MPLS</td>
<td align="left">ESI Label filtering</td>
<td align="left">No</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">VXLAN (IP tunnels)</td>
<td align="left">Local Bias</td>
<td align="left">Yes</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">NVGRE (IP tunnels)</td>
<td align="left">Local Bias</td>
<td align="left">Yes</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">VXLAN-GPE (IP tunnels)</td>
<td align="left">Local Bias</td>
<td align="left">Yes</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">Geneve (IP tunnels)</td>
<td align="left">Local Bias (if no ESI Lb), ESI Label (if ESI lb)<
/td>
<td align="left">Yes</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">SRv6</td>
<td align="left">ESI Label filtering</td>
<td align="left">Yes</td>
<td align="left">Yes</td>
</tr>
</tbody>
</table>
<t>The ESI Label method is applicable for both All-Active and <t>The ESI Label method is applicable for both All-Active and
Single-Active configurations, whereas the Local Bias method is Single-Active configurations, whereas the local-bias method is
suitable only for All-Active configurations. Moreover, the ESI Label suitable only for All-Active configurations. Moreover, the ESI Label
method is effective across different network domains, while Local Bias method is effective across different network domains, while local bias
is constrained to networks where there is no change in the next hop is constrained to networks where there is no change in the next hop
between the NVEs attached to the same ES. Nonetheless, some operators between the NVEs attached to the same ES. Nonetheless, some operators
favor the Local Bias method due to its simplification of the 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 other fact that the ingress NVE always forwards traffic locally to other
interfaces, thereby decreasing the delay in reaching multihomed interfaces, thereby decreasing the delay in reaching multihomed
hosts.</t> hosts.</t>
<t>This document extends the EVPN multihoming procedures to allow <t>This document extends the EVPN multihoming procedures to allow
operators to select the preferred Split Horizon method for a given NVO operators to select the preferred split-horizon method for a given NVO
tunnel according to their specific requirements. The choice between tunnel according to their specific requirements. The choice between
Local Bias and ESI Label Split Horizon is now allowed (by 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 route. 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 NVGRE, IP tunnels that do not support both methods, such as VXLAN or NVGRE,
will continue to adhere to the procedures specified in <xref will continue to adhere to the procedures specified in <xref
target="RFC8365"/>. Note that this document does not modify the Local target="RFC8365" format="default"/>. Note that this document does not
Bias or the ESI Label Split Horizon procedures themselves, just modify the local bias or the ESI Label split-horizon procedures
focuses on the signaling and selection of the Split Horizon method to themselves, just focuses on the signaling and selection of the split-hor
apply by the multihomed NVEs. </t> izon method to apply by the multihomed NVEs. </t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<section anchor="sect-2" title="BGP EVPN Extensions"> <name>BGP EVPN Extensions</name>
<t>Extensions to EVPN are required to enable NVEs to advertise their <t>Extensions to EVPN are required to enable NVEs to advertise their
preferred Split Horizon method for a given ES. <xref preferred split-horizon method for a given ES. <xref
target="esi-label-extended-community"/> illustrates the ESI Label target="esi-label-extended-community" format="default"/> illustrates the
extended community (<xref target="RFC7432"/> Section 7.5), which is ESI Label extended community (<xref target="RFC7432" sectionFormat="of"
consistently advertised alongside the EVPN A-D per ES route. All NVEs section="7.5"/>), which is consistently advertised alongside the EVPN
connected to an ES advertise an A-D per ES route for that ES, including A-D per ES route. All NVEs connected to an ES advertise an A-D per ES
the extended community, which communicates information regarding the route for that ES, including the extended community, which communicates
multihoming mode (either All-Active or Single-Active) and, if necessary, information regarding the multihoming mode (either All-Active or
specifies the ESI Label to be utilized.</t> Single-Active) and, if necessary, specifies the ESI Label to be
utilized.</t>
<figure anchor="esi-label-extended-community" <figure anchor="esi-label-extended-community">
title="ESI Label extended community"> <name>ESI Label Extended Community</name>
<artwork><![CDATA[ 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><xref target="RFC7432"/> defines the low-order bit of the Flags octet <t><xref target="RFC7432" format="default"/> defines the low-order bit
(bit 0) as the "Single-Active" bit:</t> of the Flags octet (bit 0) as the "Single-Active" bit:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A value of 0 means that the multihomed ES is operating in <t>A value of 0 means that the multihomed ES is operating in
All-Active multihoming redundancy mode.</t> All-Active multihoming redundancy mode.</t>
</li>
<li>
<t>A value of 1 means that the multihomed ES is operating in <t>A value of 1 means that the multihomed ES is operating in
Single-Active multihoming redundancy mode.</t> Single-Active multihoming redundancy mode.</t>
</list><xref target="sect-5"/> establishes a registry for the Flags </li>
</ul>
<t><xref target="sect-5" format="default"/> establishes a registry for the
Flags
octet, designating the "Single-Active" bit as the low-order bit of the octet, designating the "Single-Active" bit as the low-order bit of the
newly defined multihoming redundancy mode field.</t> newly defined Multihoming Redundancy Mode field.</t>
<section anchor="sect-2.1" numbered="true" toc="default">
<section anchor="sect-2.1" title="The Split Horizon Type"> <name>The Split-Horizon Type</name>
<t><xref target="RFC8365"/> does not include any explicit indication <t><xref target="RFC8365" format="default"/> does not include any
regarding the Split Horizon method in the A-D per Ethernet Segment explicit indication regarding the split-horizon method in the A-D per
(ES) route. In this document, the Split Horizon procedure defined in ES route. In this document, the split-horizon procedure defined in
<xref target="RFC8365"/> (section 8.3.1) is considered the default <xref target="RFC8365" sectionFormat="of" section="8.3.1"/> is
behavior, presuming that Local Bias is employed exclusively for IP considered the default behavior, presuming that local bias is employed
tunnels, while ESI Label-based Split Horizon is used for IP-based MPLS exclusively for IP tunnels, while ESI Label-based split horizon is
tunnels. This document specifies that the two high-order bits in the used for IP-based MPLS tunnels. This document specifies that the two
Flags octet (bits 6 and 7) constitute the "Split Horizon Type" (SHT) high-order bits in the Flags octet (bits 6 and 7) constitute the "Split-
Horizon Type" or "SHT"
field, where:</t> field, where:</t>
<figure> <artwork name="" type="" align="left" alt="">
<artwork><![CDATA[ 7 6 5 4 3 2 1 0 <![CDATA[
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
]]></artwork> ]]></artwork>
</figure> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>SHT = 00 is backwards compatible with <xref target="RFC8365" form
<t>SHT = 00 is backwards compatible with <xref target="RFC8365"/> at="default"/>
and <xref target="RFC7432"/>, and indicates that the advertising and <xref target="RFC7432" format="default"/>, and indicates that th
e advertising
NVE intends to use the default or built-in SHT. The default SHT is NVE intends to use the default or built-in SHT. The default SHT is
shown in <xref target="Tunnel"/> for each encapsulation. An egress shown in <xref target="Tunnel" format="default"/> for each encapsula
NVE that follows the <xref target="RFC8365"/> behavior and does tion. An egress
NVE that follows the <xref target="RFC8365" format="default"/> behav
ior and does
not support this specification will ignore the SHT bits (which is not support this specification will ignore the SHT bits (which is
equivalent to process them as value of 00).</t> equivalent to processing them as a value of 00).</t>
</li>
<li>
<t>SHT = 01 indicates that the advertising NVE intends to use <t>SHT = 01 indicates that the advertising NVE intends to use
Local Bias procedures in the ES for which the AD per-ES route is local-bias procedures in the ES for which the AD per-ES route is
advertised.</t> advertised.</t>
</li>
<li>
<t>SHT = 10 indicates that the advertising NVE intends to use the <t>SHT = 10 indicates that the advertising NVE intends to use the
ESI Label based Split Horizon method procedures in the ES for ESI Label-based split-horizon method procedures in the ES for
which the AD per-ES route is advertised.</t> which the AD per-ES route is advertised.</t>
</li>
<t>SHT = 11 is a reserved value, for future use.</t> <li>
</list></t> <t>SHT = 11 is Unassigned.</t>
</li>
</ul>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default">
<section anchor="sect-2.2" <name>Use of the Split-Horizon Type in A-D per ES Routes</name>
title="Use of the Split Horizon Type In A-D Per ES Routes">
<t>The following behavior is observed:</t> <t>The following behavior is observed:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>An SHT value of 01 or 10 MUST NOT be used with encapsulations <t>An SHT value of 01 or 10 <bcp14>MUST NOT</bcp14> be used with
that support only one SHT in <xref target="Tunnel"/>, and MAY be encapsulations that support only one SHT in <xref target="Tunnel"
used by encapsulations that support the two SHTs in <xref format="default"/>, and <bcp14>MAY</bcp14> be used by
target="Tunnel"/>.</t> encapsulations that support the two SHTs in <xref target="Tunnel"
format="default"/>.</t>
<t>An SHT value different from 00 expresses the intent to use a </li>
specific Split Horizon method, but does not reflect the actual <li>
<t>An SHT value different than 00 expresses the intent to use a
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.</t> attached to the ES advertise the same SHT.</t>
</li>
<t>In case of inconsistency in the SHT value advertised by the <li>
NVEs attached to the same ES for a given EVI, all the NVEs MUST <t>In case of an inconsistency in the SHT value advertised by the
revert to the <xref target="RFC8365"/> behavior, and use the NVEs attached to the same ES for a given EVI, all the NVEs <bcp14>MU
default SHT in <xref target="Tunnel"/>, irrespective of the ST</bcp14>
revert to the behavior in <xref target="RFC8365" format="default"/>
and use the
default SHT in <xref target="Tunnel" format="default"/>, irrespectiv
e of the
advertised SHT.</t> advertised SHT.</t>
</li>
<t>An SHT different from 00 MUST NOT be set if the Single-Active <li>
bit is set. A received A-D per ES route where Single-Active and <t>An SHT different than 00 <bcp14>MUST NOT</bcp14> be set if the "S
SHT bits are different from zero MUST follow the treat-as-withdraw ingle-Active"
behavior <xref target="RFC7606"/>.</t> bit is set. A received A-D per ES route where the "Single-Active" an
d
<t>The SHT MUST have the same value in each Ethernet A-D per ES SHT bits are different than zero <bcp14>MUST</bcp14> follow the trea
t-as-withdraw
behavior in <xref target="RFC7606" format="default"/>.</t>
</li>
<li>
<t>The SHT <bcp14>MUST</bcp14> have the same value in each Ethernet
A-D per ES
route that an NVE advertises for a given ES and a given route that an NVE advertises for a given ES and a given
encapsulation (see <xref target="sect-3"/> for NVEs supporting encapsulation (see <xref target="sect-3" format="default"/> for NVEs supporting
multiple encapsulations).</t> multiple encapsulations).</t>
</list></t> </li>
</ul>
<t>As an example, egress NVEs that support IP-based MPLS tunnels, such <t>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
<xref target="RFC9012"/>. This extended community indicates the <xref target="RFC9012" format="default"/>. This extended community indic
ates the
encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of
01 or 10 to signify the intent to use Local Bias or ESI Label, 01 or 10 to signify the intent to use local bias or the ESI Label,
respectively.</t> respectively.</t>
<t>An egress NVE MUST NOT use an SHT value other than 00 when <t>An egress NVE <bcp14>MUST NOT</bcp14> use an SHT value other than 00
advertising an A-D per ES route with <xref target="RFC9012"/> Tunnel when
encapsulation types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), advertising an A-D per ES route with the following tunnel encapsulation
or no BGP tunnel encapsulation extended community at all. In all these types from <xref target="RFC9012" format="default"/>:
cases, it is presumed that there is no choice for the Split Horizon VXLAN (type 8), NVGRE (type 9), MPLS (type 10),
method; therefore, the SHT value MUST be set to 00. If a route with or no BGP Tunnel Encapsulation Extended Community at all. In all these
cases, it is presumed that there is no choice for the split-horizon
method; therefore, the SHT value <bcp14>MUST</bcp14> be set to 00. If a
route with
any of the mentioned encapsulation options is received and has an SHT any of the mentioned encapsulation options is received and has an SHT
value different from 00, it SHOULD apply the treat-as-withdraw value different than 00, it <bcp14>SHOULD</bcp14> apply the treat-as-wit
behavior, per <xref target="RFC7606"/>.</t> hdraw
behavior, per <xref target="RFC7606" format="default"/>.</t>
<t>An egress NVE advertising A-D per ES route(s) for an ES with GENEVE <t>An egress NVE advertising A-D per ES route(s) for an ES with Geneve
encapsulation (<xref target="RFC9012"/>, Tunnel encapsulation type 19, encapsulation (tunnel encapsulation type 19 in the BGP Tunnel Encapsula
<xref target="I-D.ietf-bess-evpn-geneve"/>) MAY use an SHT value of 01 tion attribute <xref target="RFC9012" format="default"/>) <bcp14>MAY</bcp14> use
or 10. A value of 01 indicates the intent to use Local Bias, an SHT value of 01 or 10. A
regardless of the presence of an Ethernet option TLV with a non-zero value of 01 indicates the intent to use local bias, regardless of the
Source-ID, as described in <xref target="I-D.ietf-bess-evpn-geneve"/>. presence of an Ethernet option TLV with a non-zero Source-ID, as
A value of 10 indicates the intent to use ESI Label-based Split described in <xref target="I-D.ietf-bess-evpn-geneve"
Horizon, and it is only valid if an Ethernet option TLV with non-zero format="default"/>. A value of 10 indicates the intent to use ESI
Source-ID is present. A value of 00 indicates the default behavior Label-based split horizon, and it is only valid if an Ethernet option
outlined in <xref target="Tunnel"/>, which is to use Local Bias if: a) TLV with a non-zero Source-ID is present. A value of 00 indicates the
no ESI-Label is present in the Ethernet option TLV, or b) if there is default behavior outlined in <xref target="Tunnel" format="default"/>,
no Ethernet option TLV. Otherwise, the ESI Label Split Horizon method which is to use local bias if:</t>
is applied.</t>
<ol type="a">
<li>no ESI Label is present in the Ethernet option TLV, or </li>
<li>there is no Ethernet option TLV.</li>
</ol>
<t>Otherwise, the ESI Label split-horizon method is applied.</t>
<t>These procedures assume a single encapsulation supported in the <t>These procedures assume a single encapsulation supported in the
egress NVE. <xref target="sect-3"/> describes additional procedures egress NVE. <xref target="sect-3" format="default"/> describes additiona l procedures
for NVEs supporting multiple encapsulations.</t> for NVEs supporting multiple encapsulations.</t>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default">
<section anchor="sect-2.3" title="ESI Label Value In A-D Per ES Routes"> <name>The ESI Label Value in A-D per ES Routes</name>
<t>This document also updates <xref target="RFC8365"/> regarding the <t>This document also updates <xref target="RFC8365" format="default"/>
regarding the
value that is advertised in the ESI Label field of the ESI Label value that is advertised in the ESI Label field of the ESI Label
extended community, as follows:</t> extended community, as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The A-D per ES route(s) for an ES MAY have an ESI Label value <t>The A-D per ES route(s) for an ES <bcp14>MAY</bcp14> have an ESI
of zero if the SHT value is 01. <xref target="sect-2.2"/> Label value
of zero if the SHT value is 01. <xref target="sect-2.2" format="defa
ult"/>
specifies the scenarios where the SHT can be 01. An ESI Label specifies the scenarios where the SHT can be 01. An ESI Label
value of zero eliminates the need to allocate labels in cases value of zero eliminates the need to allocate labels in cases
where they are not utilized, such as in the Local Bias method.</t> where they are not utilized, such as in the local-bias method.</t>
</li>
<t>The A-D per ES route(s) for an ES MAY have an ESI Label value <li>
<t>The A-D per ES route(s) for an ES <bcp14>MAY</bcp14> have an ESI
Label value
of zero for VXLAN or NVGRE encapsulations.</t> of zero for VXLAN or NVGRE encapsulations.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="sect-2.4" <section anchor="sect-2.4" numbered="true" toc="default">
title="Backwards Compatibility With RFC8365 NVEs"> <name>Backwards Compatibility with NVEs from RFC 8365</name>
<t>As discussed in <xref target="sect-2.2"/> this specification is <t>As discussed in <xref target="sect-2.2" format="default"/>, this
backwards compatible with the Split Horizon filtering behavior in specification is backwards compatible with the split-horizon filtering
<xref target="RFC8365"/> and a non-upgraded NVE can be attached to the behavior in <xref target="RFC8365" format="default"/> and a
same ES as other NVEs supporting this specification.</t> non-upgraded NVE can be attached to the same ES as other NVEs
supporting this specification.</t>
<t>An NVE maintains an administrative SHT value for an Ethernet <t>An NVE maintains an administrative SHT value for an ES, which is
Segment (ES), which is advertised alongside the A-D per ES route, and advertised alongside the A-D per ES route, and an operational SHT
an 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 all
operational SHT if all the NVEs attached to the ES have the same the NVEs attached to the ES have the same administrative SHT.</t>
administrative SHT.</t> <t>This document assumes that an implementation of <xref target="RFC7432
" format="default"/> or <xref target="RFC8365" format="default"/> that does not
<t>This document assumes that an implementation of <xref support
target="RFC7432"/> or <xref target="RFC8365"/> that does not support
the specifications in this document will ignore the values of all the the specifications in this document will ignore the values of all the
Flags in the ESI Label extended community, except for the Flags in the ESI Label extended community, except for the
Single-Active bit. Based on this assumption, a non-upgraded NVE will "Single-Active" bit. Based on this assumption, a non-upgraded NVE will
disregard any SHT value other than 00. If an upgraded NVE receives at disregard any SHT value other than 00. If an upgraded NVE receives at
least one A-D per ES route for the ES with an SHT value of 00, it MUST least one A-D per ES route for the ES with an SHT value of 00, it <bcp14
revert its operational SHT to the default Split Horizon method, as >MUST</bcp14>
described in <xref target="Tunnel"/>, irrespective of its revert its operational SHT to the default split-horizon method, as
described in <xref target="Tunnel" format="default"/>, irrespective of i
ts
administrative SHT.</t> administrative SHT.</t>
<t>For instance, consider an NVE attached to ES N that receives two <t>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 A-D per ES routes for N from different NVEs, NVE1 and NVE2. If the
route from NVE1 has an SHT value of 00 and the one from NVE2 has an route from NVE1 has an SHT value of 00 and the one from NVE2 has an
SHT value of 01, the NVE MUST use the default Split Horizon method SHT value of 01, the NVE <bcp14>MUST</bcp14> use the default split-horiz
specified in <xref target="Tunnel"/> as its operational SHT, on method
specified in <xref target="Tunnel" format="default"/> as its operational
SHT,
regardless of its administrative SHT.</t> regardless of its administrative SHT.</t>
<t>All NVEs attached to an ES with an operational SHT value of 10 <bcp14
<t>All NVEs attached to an ES with an operational SHT value of 10 MUST >MUST</bcp14>
advertise a valid, non-zero ESI Label. If the operational SHT value is advertise a valid, non-zero ESI Label. If the operational SHT value is
01, the ESI Label MAY be zero. If the operational SHT value is 00, the 01, the ESI Label <bcp14>MAY</bcp14> be zero. If the operational SHT val
ESI Label may be zero only if the default encapsulation supports Local ue is 00, the
Bias exclusively, and the NVEs do not require the presence of a valid, ESI Label may be zero only if the default encapsulation supports local
bias exclusively, and the NVEs do not require the presence of a valid,
non-zero ESI Label.</t> non-zero ESI Label.</t>
<t>If an NVE changes its operational SHT value from 01 (Local Bias) to <t>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 <bcp14>MUST</bcp14 > 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 and NVEs in the ES support only local bias. For example, consider NVE1 and
NVE2 using MPLSoUDP as encapsulation, attached to the same Ethernet NVE2 using MPLSoUDP as encapsulation, attached to the same Ethernet
Segment ES1, and advertising an SHT value of 01 (Local Bias) with a Segment ES1, and advertising an SHT value of 01 (Local Bias) with a
zero ESI Label value. Suppose NVE3, which does not support this zero ESI Label value. Suppose NVE3, which does not support this
specification, joins ES1 and advertises an SHT value of 00 (default). specification, joins ES1 and advertises an SHT value of 00 (default).
Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 MUST update Upon receiving NVE3's A-D per ES route, NVE1 and NVE2 <bcp14>MUST</bcp14 > update
their A-D per ES routes for ES1 to include a valid, non-zero ESI Label their A-D per ES routes for ES1 to include a valid, non-zero ESI Label
value. The assumption here is that NVE3 only supports the default ESI value. The assumption here is that NVE3 only supports the default ESI
Label-based Split Horizon filtering.</t> Label-based split-horizon filtering.</t>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<name>Procedures for NVEs Supporting Multiple Encapsulations</name>
<t>As specified in <xref target="RFC8365" format="default"/>, an NVE
that supports multiple data plane encapsulations (e.g., VXLAN, NVGRE,
MPLS, MPLSoUDP, Geneve) must indicate all supported encapsulations using
BGP Encapsulation extended communities as defined in <xref
target="RFC9012" format="default"/> for all EVPN routes. This section
provides clarification on the multihoming split-horizon behavior for
NVEs that advertise and receive multiple BGP Encapsulation extended
communities along with the A-D per ES routes. This section uses the
notation {x, y} (more than two encapsulations is possible too) to denote
the encapsulations advertised in BGP Encapsulation extended communities
(or the BGP Tunnel Encapsulation Attribute), where x and y represent
different encapsulation values. When Geneve is one of the
encapsulations, the tunnel type is indicated in either a BGP
Encapsulation extended community or a BGP Tunnel Encapsulation
Attribute.</t>
<section anchor="sect-3" <t>It is important to note that an NVE <bcp14>MAY</bcp14> advertise multip
title="Procedures for NVEs Supporting Multiple Encapsulations"> le A-D per ES
<t>As specified in <xref target="RFC8365"/>, an NVE that supports
multiple data plane encapsulations (e.g., VXLAN, NVGRE, MPLS, MPLSoUDP,
GENEVE) must indicate all supported encapsulations using BGP
Encapsulation extended communities as defined in <xref
target="RFC9012"/> for all EVPN routes. This section provides
clarification on the multihoming Split Horizon behavior for NVEs that
advertise and receive multiple BGP Encapsulation extended communities
along with the A-D per ES routes. This section uses the notation {x, y}
(more than two encapsulations is possible too) to denote the
encapsulations advertised in BGP Encapsulation extended communities (or
BGP Tunnel Encapsulation Attribute), where x and y represent different
encapsulation values. When GENEVE is one of the encapsulations, the
tunnel type is indicated in either a BGP Encapsulation extended
community or a BGP Tunnel Encapsulation Attribute. </t>
<t>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 Targets 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 in 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 per ES 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 distinct routes are advertised for the same ES, each route must have a distinct
Route Distinguisher.</t> Route Distinguisher.</t>
<t>As per <xref target="RFC8365"/>, an NVE that advertises multiple <t>As per <xref target="RFC8365" format="default"/>, an NVE that advertise
encapsulations in the A-D per ES route(s) for an ES MUST advertise s multiple
encapsulations that use the same Split Horizon filtering method in the encapsulations in the A-D per ES route(s) for an ES <bcp14>MUST</bcp14> ad
vertise
encapsulations that use the same split-horizon filtering method in the
same route. For example:</t> same route. For example:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>An A-D per ES route for ES-x may be advertised with {VXLAN, <t>An A-D per ES route for ES-x may be advertised with {VXLAN,
NVGRE} encapsulations.</t> NVGRE} encapsulations.</t>
</li>
<li>
<t>An A-D per ES route for ES-y may be advertised with {MPLS, <t>An A-D per ES route for ES-y may be advertised with {MPLS,
MPLSoUDP, MPLSoGRE} encapsulations (or a subset).</t> MPLSoUDP, MPLSoGRE} encapsulations (or a subset).</t>
</li>
<t>But an A-D per ES route for ES-z MUST NOT be advertised with <li>
<t>However, an A-D per ES route for ES-z <bcp14>MUST NOT</bcp14> be ad
vertised with
{MPLS, VXLAN} encapsulations.</t> {MPLS, VXLAN} encapsulations.</t>
</list></t> </li>
</ul>
<t>This document extends the described behavior as follows:</t> <t>This document extends the described behavior as follows:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters">
<t>An A-D per ES route for ES-x may be advertised with multiple <t>An A-D per ES route for ES-x may be advertised with multiple
encapsulations, some of which support a single Split Horizon method. encapsulations, some of which support a single split-horizon method.
In this case, the Split Horizon Type (SHT) value MUST be 00. For In this case, the SHT value <bcp14>MUST</bcp14> be 00. For instance,
instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, GENEVE}, or encapsulations such as {VXLAN, NVGRE}, {VXLAN, Geneve}, or {MPLS,
{MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In
In all these cases, the SHT value MUST be 00 and the behavior all these cases, the SHT value <bcp14>MUST</bcp14> be 00 and the
treat-as-withdraw <xref target="RFC7606"/> is applied in case of any treat-as-withdraw behavior <xref target="RFC7606" format="default"/>
other value.</t> is applied in case of any other value.</t>
</li>
<li>
<t>An A-D per ES route for ES-y may be advertised with multiple <t>An A-D per ES route for ES-y may be advertised with multiple
encapsulations that all support both Split Horizon methods. In this encapsulations that all support both split-horizon methods. In this
case, the SHT value MAY be 01 if the preferred method is Local Bias, case, the SHT value <bcp14>MAY</bcp14> be 01 if the preferred method i
s local bias,
or 10 if the ESI Label-based method is desired. For example, or 10 if the ESI Label-based method is desired. For example,
encapsulations such as {MPLSoGRE, MPLSoUDP, GENEVE} (or a subset) encapsulations such as {MPLSoGRE, MPLSoUDP, Geneve} (or a subset)
MAY be advertised in an A-D per ES route with an SHT value of 01. <bcp14>MAY</bcp14> be advertised in an A-D per ES route with an SHT va
The ESI Label value in this case MAY be zero.</t> lue of 01.
The ESI Label value in this case <bcp14>MAY</bcp14> be zero.</t>
<t>If ES-z with RT-set composed of (RT1, RT2, RT3.. RTn) supports </li>
multiple encapsulations requiring different Split Horizon methods, a <li>
distinct A-D per ES route (or group of routes) per Split Horizon <t>If ES-z with an RT-set composed of (RT1, RT2, RT3.. RTn) supports
method MUST be advertised. For example, consider an ES-z with n multiple encapsulations requiring different split-horizon methods, a
Route Targets (RTs) where:<list style="symbols"> distinct A-D per ES route (or group of routes) per split-horizon
method <bcp14>MUST</bcp14> be advertised. For example, consider an ES-
z with n RTs, where:</t>
<ul spacing="normal">
<li>
<t>the EVIs corresponding to (RT1..RTi) support VXLAN,</t> <t>the EVIs corresponding to (RT1..RTi) support VXLAN,</t>
</li>
<li>
<t>the ones for (RTi+1..RTm) (with i&lt;m) support MPLSoUDP with <t>the ones for (RTi+1..RTm) (with i&lt;m) support MPLSoUDP with
Local Bias,</t> local bias, and</t>
</li>
<t>and the ones for (RTm+1..RTn) (with m&lt;n) support GENEVE <li>
with ESI Label based Split Horizon.</t> <t>the ones for (RTm+1..RTn) (with m&lt;n) support Geneve
</list>In this scenario, three groups of A-D per ES routes MUST be with ESI Label-based split horizon.</t>
advertised for ES-z:<list style="symbols"> </li>
<t>A-D per ES route group 1, including (RT1..RTi), with </ul>
encapsulation {VXLAN}, and an SHT value of 00. The ESI Label MAY <t>In this scenario, three groups of A-D per ES routes <bcp14>MUST</bc
p14> be
advertised for ES-z:</t>
<ul spacing="normal">
<li>
<t>A-D per ES route group 1, including (RT1..RTi) with
encapsulation {VXLAN} and an SHT value of 00. The ESI Label <bcp14
>MAY</bcp14>
be zero.</t> be zero.</t>
</li>
<t>A-D per ES route group 2, including (RTi+1..RTm), with <li>
encapsulation {MPLSoUDP}, and an SHT value of 01. The ESI Label <t>A-D per ES route group 2, including (RTi+1..RTm) with
MAY be zero.</t> encapsulation {MPLSoUDP} and an SHT value of 01. The ESI Label
<bcp14>MAY</bcp14> be zero.</t>
<t>A-D per ES route group 3, including (RTm+1..RTn), with </li>
encapsulation {GENEVE}, and an SHT value of 10. The ESI Label <li>
MUST have a valid, non-zero value, and the Ethernet option as <t>A-D per ES route group 3, including (RTm+1..RTn) with
defined in <xref target="RFC8926"/> MUST be advertised.</t> encapsulation {Geneve} and an SHT value of 10. The ESI Label
</list></t> <bcp14>MUST</bcp14> have a valid, non-zero value, and the Ethernet
</list></t> option as
defined in <xref target="RFC8926" format="default"/> <bcp14>MUST</
<t>As per <xref target="RFC8365"/>, it is the responsibility of the bcp14> be advertised.</t>
</li>
</ul>
</li>
</ol>
<t>As per <xref target="RFC8365" format="default"/>, it is the responsibil
ity of the
operator of a given EVI to ensure that all of the NVEs within that EVI operator of a given EVI to ensure that all of the NVEs within that EVI
support a common encapsulation. Failure to meet this condition may support a common encapsulation. Failure to meet this condition may
result in service disruption or failure.</t> result in service disruption or failure.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>All the security considerations described in <xref target="RFC7432"/> <t>All the security considerations described in <xref target="RFC7432" for
mat="default"/>
are applicable to this document.</t> are applicable to this document.</t>
<t>Additionally, this document modifies the procedures for Split Horizon <t>Additionally, this document modifies the procedures for split-horizon
filtering as outlined in <xref target="RFC8365"/>, offering operators a filtering as outlined in <xref target="RFC8365" format="default"/>,
choice between Local Bias and ESI Label-based filtering for tunnels that offering operators a choice between local bias and ESI Label-based
support both methods. Misconfiguration of the desired Split Horizon Type filtering for tunnels that support both methods. Misconfiguration of the
(SHT) could lead to forwarding behaviors that differ from the intended desired SHT could lead to forwarding behaviors that differ from the
configuration. Apart from this risk, this document describes procedures intended configuration. Apart from this risk, this document describes
to ensure that all Provider Edge (PE) devices or Network Virtualization procedures to ensure that all PE devices or NVEs connected to the same
Edges (NVEs) connected to the same Ethernet Segment (ES) agree on a ES agree on a common SHT method, with a fallback to a default behavior
common SHT method, with a fallback to a default behavior in case of a in case of a mismatch in the SHT bits being advertised by any two PEs or
mismatch in the SHT bits being advertised by any two PEs or NVEs in the NVEs in the ES. Consequently, unauthorized changes to the SHT
Ethernet Segment. Consequently, unauthorized changes to the SHT configuration by an attacker on a single PE or NVE of the ES should not
configuration by an attacker on a single PE or NVE of the Ethernet cause traffic disruption (as long as the SHT value is valid as per this
Segment should not cause traffic disruption (as long as the SHT value is document) but may result in alterations to forwarding behavior.</t>
valid as per this document) but may result in alterations to forwarding
behavior.</t>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="sect-5" title="IANA Considerations"> <t>Per this document, IANA has created the "EVPN ESI Label Extended Commun
<t>This document creates a registry called "EVPN ESI Label Extended ity Flags" registry for the 1-octet Flags field in the ESI Label Extended
Community Flags" for the 1-octet Flags field in the ESI Label Extended Community <xref target="RFC7432" format="default"/>, as follows:</t>
Community <xref target="RFC7432"/>, as follows:</t> <table align="center">
<thead>
<texttable> <tr>
<ttcol>Bit Position</ttcol> <th align="left">Bit Position</th>
<th align="left">Name</th>
<ttcol>Name</ttcol> <th align="left">Reference</th>
</tr>
<ttcol>Reference</ttcol> </thead>
<tbody>
<c>0-1</c> <tr>
<td align="left">0-1</td>
<c>Multihoming Redundancy Mode</c> <td align="left">Multihoming Redundancy Mode</td>
<td align="left">
<c><xref target="RFC7432"/></c> <xref target="RFC7432" format="default"/></td>
</tr>
<c>2-5</c> <tr>
<td align="left">2-5</td>
<c>Unassigned</c> <td align="left">Unassigned</td>
<td align="left"/>
<c/> </tr>
<tr>
<c>6-7</c> <td align="left">6-7</td>
<td align="left">Split-Horizon Type</td>
<c>Split Horizon Type</c> <td align="left">RFC 9746</td>
</tr>
<c>This Document</c> </tbody>
</texttable> </table>
<t>This document also creates a registry for the "Multihoming Redundancy
Mode" field of the EVPN ESI Label Extended Community Flags. This
registry is called "Multihoming Redundancy Mode" and is initialized as
follows:</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Multihoming redundancy mode</ttcol>
<ttcol>Reference</ttcol>
<c>00</c>
<c>All-Active mode</c>
<c><xref target="RFC7432"/></c>
<c>01</c>
<c>Single-Active mode</c>
<c><xref target="RFC7432"/></c>
<c>10</c>
<c>Unassigned</c>
<c/>
<c>11</c>
<c>Unassigned</c>
<c/>
</texttable>
<t>Finally, a third registry for the "Split Horizon Type" field of the
EVPN ESI Label Extended Community Flags is created by this document too.
This registry is called "Split Horizon Type" and is initialized as
follows:</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Split Horizon Type value</ttcol>
<ttcol>Reference</ttcol>
<c>00</c>
<c>Default SHT</c>
<c>This document</c>
<c>01</c>
<c>Local Bias</c>
<c>This document</c>
<c>10</c>
<c>ESI Label based filtering</c>
<c>This document</c>
<c>11</c>
<c>Unassigned</c>
<c/>
</texttable>
<t>IANA has also created the "Multihoming Redundancy
Mode" registry for the related field of the "EVPN ESI Label Extended Commu
nity Flags". The registry has been populated with the following initial values:
</t>
<table align="center">
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Multihoming Redundancy Mode</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">00</td>
<td align="left">All-Active</td>
<td align="left">
<xref target="RFC7432" format="default"/></td>
</tr>
<tr>
<td align="left">01</td>
<td align="left">Single-Active</td>
<td align="left">
<xref target="RFC7432" format="default"/></td>
</tr>
<tr>
<td align="left">10</td>
<td align="left">Unassigned</td>
<td align="left"/>
</tr>
<tr>
<td align="left">11</td>
<td align="left">Unassigned</td>
<td align="left"/>
</tr>
</tbody>
</table>
<t>Finally, IANA has created the "Split-Horizon Type" registry for the rel
ated field of the
"EVPN ESI Label Extended Community Flags". The registry has been populated
with the following initial values:</t>
<table align="center">
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Split-Horizon Type Value</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">00</td>
<td align="left">Default SHT</td>
<td align="left">RFC 9746</td>
</tr>
<tr>
<td align="left">01</td>
<td align="left">Local Bias</td>
<td align="left">RFC 9746</td>
</tr>
<tr>
<td align="left">10</td>
<td align="left">ESI Label-based filtering</td>
<td align="left">RFC 9746</td>
</tr>
<tr>
<td align="left">11</td>
<td align="left">Unassigned</td>
<td align="left"/>
</tr>
</tbody>
</table>
<t>New registrations in the "EVPN ESI Label Extended Community Flags", <t>New registrations in the "EVPN ESI Label Extended Community Flags",
"Multihoming Redundancy Mode", and "Split Horizon Type" registries will "Multihoming Redundancy Mode", and "Split-Horizon Type" registries will
be made through the "IETF Review" procedure defined in <xref be made through the "IETF Review" procedure defined in <xref
target="RFC8126"/>. These registries are located in the "Border Gateway target="RFC8126" format="default"/>. These registries are located in the
Protocol (BGP) Extended Communities" registry group.</t> "Border Gateway Protocol (BGP) Extended Communities" registry group.</t>
</section> </section>
<section anchor="sect-6" title="Acknowledgments">
<t>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.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-bess-evpn-geneve" to="EVPN-GENEVE"/>
&RFC2119; <displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="VXLAN-GPE"/>
<references>
&RFC8174; <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
252.xml"/>
</references>
<references>
<name>Informative References</name>
&RFC8126; <!-- [I-D.ietf-bess-evpn-geneve] IESG state: I-D Exists as of 09/05/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-bess-evpn-geneve.xml"/>
&RFC7432; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
348.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
023.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
637.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
510.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
926.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
012.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
606.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
&RFC8365; <!-- [I-D.ietf-nvo3-vxlan-gpe] IESG state: Expired as of 09/05/24 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-nv
o3-vxlan-gpe.xml"/>
&RFC9252; <reference anchor="TUNNEL-ENCAP" target="https://www.iana.org/assignment
s/bgp-tunnel-encapsulation">
<front>
<title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Anoop Ghanwani"/>,
<contact fullname="Gyan Mishra"/>, and <contact fullname="Jeffrey
Zhang"/> for their review and useful comments. Thanks to <contact
fullname="Gunter Van de Velde"/> and <contact fullname="Sue Hares"/> as
well, for their thorough review.</t>
</section>
<references title="Informative References">
&I-D.ietf-bess-evpn-geneve;
&RFC7348;
&RFC4023;
&RFC7637;
&RFC7510;
&RFC8926;
&RFC9012;
&RFC7606;
&RFC8660;
&RFC8986;
&RFC8402;
&RFC8754;
&I-D.ietf-nvo3-vxlan-gpe;
<reference anchor="IANA-BGP-TUNNEL-ENCAP"
target="https://www.iana.org/assignments/bgp-tunnel-encapsulati
on/bgp-tunnel-encapsulation.xhtml#tunnel-types">
<front>
<title>Border Gateway Protocol (BGP) Tunnel Encapsulation</title>
<author fullname="IANA">
<organization/>
</author>
<date/>
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 163 change blocks. 
781 lines changed or deleted 842 lines changed or added

This html diff was produced by rfcdiff 1.48.