Diff: rfc9136xml2.original.xml

	rfc9136xml2.original.xml	rfc9136.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7432.xml">
	<!ENTITY RFC5512 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5512.xml">
	<!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 RFC8365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8365.xml">
	<!ENTITY I-D.ietf-bess-evpn-inter-subnet-forwarding SYSTEM "https://xml2rfc.ietf
	.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-inter-subnet-forwarding.xml
	">
	<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4364.xml">
	<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7606.xml">
	<!ENTITY RFC7365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7365.xml">
	<!ENTITY RFC5227 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5227.xml">
	<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7348.xml">
	<!ENTITY I-D.ietf-nvo3-geneve SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml
	3/reference.I-D.draft-ietf-nvo3-geneve-06.xml">
	<!ENTITY I-D.ietf-nvo3-geneve SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml
	3/reference.I-D.ietf-nvo3-geneve.xml">
	]>
	<rfc submissionType="IETF" docName="draft-ietf-bess-evpn-prefix-advertisement-11
	" category="std" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2020-06-11T21:13:55Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="no"?>
	<?rfc text-list-symbols="oo*+-"?>
	<!--
	draft-ietf-bess-evpn-prefix-advertisement-11-manual.txt(14): Warning: Expecte
	d
	an expires indication top left, found none
	--><?rfc toc="yes"?>
	<front>
	<title abbrev="EVPN Prefix Advertisement">IP Prefix Advertisement in EVPN
	</title>
	<author initials="J." surname="Rabadan" fullname="Jorge Rabadan" role="ed
	itor">
	<organization>Nokia</organization>
	<address>
	<postal>
	<street>777 E. Middlefield Road</street>
	<city>Mountain View</city>
	<region>CA</region>
	<code>94043</code>
	<country>USA</country>
	</postal>
	<phone></phone>
	<email>jorge.rabadan@nokia.com</email>
	</address>
	</author>


	<author initials="W." surname="Henderickx" fullname="Wim Henderickx">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<organization>Nokia</organization>
	<address>
	<email>wim.henderickx@nokia.com</email>
	</address>
	</author>


	<author initials="J." surname="Drake" fullname="John Drake">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
	<organization>Juniper</organization>	std" consensus="true" docName="draft-ietf-bess-evpn-prefix-advertisement-11" num
	<address>	ber="9136" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true
	<email>jdrake@juniper.net</email>	" sortRefs="true" tocInclude="true" version="3">
	</address>
	</author>


	<author initials="W." surname="Lin" fullname="Wen Lin">	<front>
	<organization>Juniper</organization>	<title abbrev="EVPN Prefix Advertisement">IP Prefix Advertisement in
	<address>	Ethernet VPN (EVPN)</title>
	<email>wlin@juniper.net</email>	<seriesInfo name="RFC" value="9136"/>
	</address>	<author initials="J." surname="Rabadan" fullname="Jorge Rabadan" role="edito
	</author>	r">
		<organization>Nokia</organization>
		<address>
		<postal>
		<street>777 E. Middlefield Road</street>
		<city>Mountain View</city>
		<region>CA</region>
		<code>94043</code>
		<country>United States of America</country>
		</postal>
		<phone/>
		<email>jorge.rabadan@nokia.com</email>
		</address>
		</author>
		<author initials="W." surname="Henderickx" fullname="Wim Henderickx">
		<organization>Nokia</organization>
		<address>
		<email>wim.henderickx@nokia.com</email>
		</address>
		</author>
		<author initials="J." surname="Drake" fullname="John Drake">
		<organization>Juniper</organization>
		<address>
		<email>jdrake@juniper.net</email>
		</address>
		</author>
		<author initials="W." surname="Lin" fullname="Wen Lin">
		<organization>Juniper</organization>
		<address>
		<email>wlin@juniper.net</email>
		</address>
		</author>
		<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
		<organization>Cisco</organization>
		<address>
		<email>sajassi@cisco.com</email>
		</address>
		</author>
		<date year="2021" month="October"/>
		<workgroup>BESS Workgroup</workgroup>


	<author initials="A." surname="Sajassi" fullname="Ali Sajassi">	<keyword>RT5</keyword>
	<organization>Cisco</organization>	<keyword>RT-5</keyword>
	<address>	<keyword>Type-5</keyword>
	<email>sajassi@cisco.com</email>	<keyword>Interface-less</keyword>
	</address>	<keyword>Interface-ful</keyword>
	</author>


	<date year="2020" month="July"/>	<abstract>
	<workgroup>BESS Workgroup</workgroup>	<t>
	<abstract><t>	The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a
	The BGP MPLS-based Ethernet VPN (EVPN) <xref target="RFC7432"/> mechanism pro
	vides a
	flexible control plane that allows intra-subnet connectivity in an	flexible control plane that allows intra-subnet connectivity in an

	MPLS and/or NVO (Network Virtualization Overlay) <xref target="RFC7365"/> net	MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network.
	work.	In some networks, there is also a need for dynamic and efficient
	In some networks, there is also a need for a dynamic and efficient	inter-subnet connectivity across Tenant Systems and end devices that
	inter-subnet connectivity across Tenant Systems and End Devices that
	can be physical or virtual and do not necessarily participate in	can be physical or virtual and do not necessarily participate in
	dynamic routing protocols. This document defines a new EVPN route	dynamic routing protocols. This document defines a new EVPN route

	type for the advertisement of IP Prefixes and explains some use-case	type for the advertisement of IP prefixes and explains some use-case
	examples where this new route-type is used.</t>	examples where this new route type is used.</t>
		</abstract>
	</abstract>	</front>
	</front>	<middle>
		<section anchor="sect-1" numbered="true" toc="default">
	<middle>	<name>Introduction</name>
	<section title="Introduction" anchor="sect-1"><t>	<t><xref target="RFC7365" format="default"/> provides a framework for Data
	<xref target="RFC7365"/> provides a framework for Data Center (DC) Network Vi	Center (DC) Network Virtualization
	rtualization	over Layer 3 and specifies that the Network Virtualization Edge (NVE) devices
	over Layer 3 and specifies that the Network Virtualization Edge devices	must provide Layer 2 and Layer 3 virtualized network services in
	(NVEs) must provide layer 2 and layer 3 virtualized network services in	multi-tenant DCs. <xref target="RFC8365" format="default"/> discusses the use
	multi-tenant DCs. <xref target="RFC8365"/> discusses the use of EVPN as the t	of EVPN as the technology of
	echnology of	choice to provide Layer 2 or intra-subnet services in these DCs. This
	choice to provide layer 2 or intra-subnet services in these DCs. This	document, along with <xref target="RFC9135" format="default"/>, specifies the
	document, along with <xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding	use of EVPN for Layer 3 or inter-subnet connectivity services.</t>
	"/>, specifies the use of EVPN for	<t>
	layer 3 or inter-subnet connectivity services.</t>	<xref target="RFC9135" format="default"/> defines some
		fairly common inter-subnet forwarding scenarios where Tenant Systems (TSs) ca
	<t>	n exchange
	<xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> defines some	packets with TSs located in remote subnets. In order to achieve this,
	fairly common inter-subnet forwarding scenarios where TSes can exchange	<xref target="RFC9135" format="default"/> describes how Media Access
	packets with TSes located in remote subnets. In order to achieve this,	Control (MAC) and IPs encoded in TS RT-2 routes are not only used to populate
	<xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> describes how	MAC Virtual Routing and Forwarding (MAC-VRF) and
	MAC/IPs encoded in TS RT-2 routes are not only used to populate MAC-VRF and	overlay Address Resolution Protocol (ARP) tables but also IP-VRF tables with
	overlay ARP tables, but also IP-VRF tables with the encoded TS host routes	the encoded TS host routes
	(/32 or /128). In some cases, EVPN may advertise IP Prefixes and therefore	(/32 or /128). In some cases, EVPN may advertise IP prefixes and therefore
	provide aggregation in the IP-VRF tables, as opposed to propagate	provide aggregation in the IP-VRF tables, as opposed to propagating
	individual host routes. This document complements the scenarios described	individual host routes. This document complements the scenarios described

	in <xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> and defines	in <xref target="RFC9135" format="default"/> and defines
	how EVPN may be used to advertise IP Prefixes. Interoperability between	how EVPN may be used to advertise IP prefixes. Interoperability between
	EVPN and L3VPN <xref target="RFC4364"/> IP Prefix routes is out of the	EVPN and Layer 3 Virtual Private Network (VPN) <xref target="RFC4364" format=
		"default"/> IP Prefix routes is out of the
	scope of this document.</t>	scope of this document.</t>

		<t>
	<t>	<xref target="sect-2.1" format="default"/> describes the
	<xref target="sect-2.1"/> describes the inter-subnet connectivity requirement	inter-subnet connectivity requirements in DCs. <xref
	s in	target="sect-2.2" format="default"/> explains why a new EVPN route
	Data Centers. <xref target="sect-2.2"/> explains why a new EVPN route type is	type is required for IP prefix advertisements. Sections <xref
	required for IP Prefix advertisements. Sections 3, 4 and 5 will	target="sect-3" format="counter"/>, <xref target="sect-4"
		format="counter"/>, and <xref target="sect-5" format="counter"/> will
	describe this route type and how it is used in some specific use	describe this route type and how it is used in some specific use
	cases.</t>	cases.</t>

		<section anchor="sect-1.1" numbered="true" toc="default">
	<section title="Terminology" anchor="sect-1.1"><t>	<name>Terminology</name>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<t>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI
	"OPTIONAL" in this document are to be interpreted as described in BCP	RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bc
	y appear in all	p14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
		"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described
		in BCP
		14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d
		efault"/> when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.


	<list style="hanging" hangIndent="3">	</t>

	<t hangText="AC:">Attachment Circuit.</t>

	<t hangText="ARP:">Address Resolution Protocol.</t>

	<t hangText="BD:">Broadcast Domain. As per [RFC7432], an EVI consists
	of a single or multiple BDs. In case of VLAN-bundle and VLAN-based
	service models (see <xref target="RFC7432"/>), a BD is equivalent to
	an EVI. In case of VLAN-aware bundle service model, an EVI contains
	multiple BDs. Also, in this document, BD and subnet are equivalent
	terms.</t>


	<t hangText="BD Route Target:">refers to the Broadcast Domain	<dl indent="10">
	assigned Route Target <xref target="RFC4364"/>. In case of VLAN-aware	<dt>AC:</dt>
		<dd>Attachment Circuit</dd>
		<dt>ARP:</dt>
		<dd>Address Resolution Protocol</dd>
		<dt>BD:</dt>
		<dd>Broadcast Domain. As per <xref target="RFC7432"/>, an EVI consists
		of a single BD or multiple BDs. In case of VLAN-bundle and VLAN-based
		service models (see <xref target="RFC7432" format="default"/>), a BD is e
		quivalent to
		an EVI. In case of a VLAN-aware bundle service model, an EVI contains
		multiple BDs. Also, in this document, "BD" and "subnet" are equivalent
		terms.</dd>
		<dt>BD Route Target:</dt>
		<dd>Refers to the broadcast-domain-assigned Route Target <xref
		target="RFC4364" format="default"/>. In case of a VLAN-aware
	bundle service model, all the BD instances in the MAC-VRF share the	bundle service model, all the BD instances in the MAC-VRF share the

	same Route Target.</t>	same Route Target.</dd>
		<dt>BT:</dt>
	<t hangText="BT:">Bridge Table. The instantiation of a BD in a	<dd>Bridge Table. The instantiation of a BD in a
	MAC-VRF, as per <xref target="RFC7432"/>.</t>	MAC-VRF, as per <xref target="RFC7432" format="default"/>.</dd>
		<dt>CE:</dt><dd>Customer Edge</dd>
	<t hangText="DGW:">Data Center Gateway.</t>	<dt>DA:</dt><dd>Destination Address</dd>
		<dt>DGW:</dt>
	<t hangText="Ethernet A-D route:">Ethernet Auto-Discovery (A-D)	<dd>Data Center Gateway</dd>
	route, as per <xref target="RFC7432"/>.</t>	<dt>Ethernet A-D Route:</dt>
		<dd>Ethernet Auto-Discovery (A-D)
	<t hangText="Ethernet NVO tunnel:">refers to Network Virtualization	route, as per <xref target="RFC7432" format="default"/>.</dd>
		<dt>Ethernet NVO Tunnel:</dt>
		<dd>Refers to Network Virtualization
	Overlay tunnels with Ethernet payload. Examples of this type of	Overlay tunnels with Ethernet payload. Examples of this type of

	tunnels are VXLAN or GENEVE.</t>	tunnel are VXLAN or GENEVE.</dd>
		<dt>EVI:</dt>
	<t hangText="EVI:">EVPN Instance spanning the NVE/PE devices that are	<dd>EVPN Instance spanning the NVE/PE devices that are
	participating on that EVPN, as per <xref target="RFC7432"/>.</t>	participating on that EVPN, as per <xref target="RFC7432" format="default
		"/>.</dd>
	<t hangText="EVPN:">Ethernet Virtual Private Networks, as per <xref	<dt>EVPN:</dt>
	target="RFC7432"/>.</t>	<dd>Ethernet VPN, as per <xref target="RFC7432" format="default"/>.</d
		d>
	<t hangText="GRE:">Generic Routing Encapsulation.</t>	<dt>GENEVE:</dt>
		<dd>Generic Network Virtualization Encapsulation, as per <xref target=
	<t hangText="GW IP:">Gateway IP Address.</t>	"RFC8926" format="default"/>.</dd>
		<dt>GRE:</dt>
	<t hangText="IPL:">IP Prefix Length.</t>	<dd>Generic Routing Encapsulation</dd>
		<dt>GW IP:</dt>
	<t hangText="IP NVO tunnel:">it refers to Network Virtualization	<dd>Gateway IP address</dd>
	Overlay tunnels with IP payload (no MAC header in the payload).</t>	<dt>IPL:</dt>
		<dd>IP Prefix Length</dd>
	<t hangText="IP-VRF:">A VPN Routing and Forwarding table for IP	<dt>IP NVO Tunnel:</dt>
		<dd>Refers to Network Virtualization
		Overlay tunnels with IP payload (no MAC header in the payload).</dd>
		<dt>IP-VRF:</dt>
		<dd>A Virtual Routing and Forwarding table for IP
	routes on an NVE/PE. The IP routes could be populated by EVPN and	routes on an NVE/PE. The IP routes could be populated by EVPN and

	IP-VPN address families. An IP-VRF is also an instantiation of a layer	IP-VPN address families. An IP-VRF is also an instantiation of a Layer
	3 VPN in an NVE/PE.</t>	3 VPN in an NVE/PE.</dd>
		<dt>IRB:</dt>
	<t hangText="IRB:">Integrated Routing and Bridging interface. It	<dd>Integrated Routing and Bridging interface. It
	connects an IP-VRF to a BD (or subnet).</t>	connects an IP-VRF to a BD (or subnet).</dd>
		<dt>MAC:</dt>
	<t hangText="MAC-VRF:">A Virtual Routing and Forwarding table for	<dd>Media Access Control</dd>
	Media Access Control (MAC) addresses on an NVE/PE, as per <xref	<dt>MAC-VRF:</dt>
	target="RFC7432"/>. A MAC-VRF is also an instantiation of an EVI in an	<dd>A Virtual Routing and Forwarding table for
	NVE/PE.</t>	MAC addresses on an NVE/PE, as per <xref target="RFC7432" format="default
		"/>. A MAC-VRF is also an instantiation of an EVI in an
	<t hangText="ML:">MAC address length.</t>	NVE/PE.</dd>
		<dt>ML:</dt>
	<t hangText="ND:">Neighbor Discovery Protocol.</t>	<dd>MAC Address Length</dd>
		<dt>ND:</dt>
	<t hangText="NVE:">Network Virtualization Edge.</t>	<dd>Neighbor Discovery</dd>
		<dt>NVE:</dt>
	<t hangText="GENEVE:">Generic Network Virtualization Encapsulation,	<dd>Network Virtualization Edge</dd>
	<xref target="I-D.ietf-nvo3-geneve"/>.</t>	<dt>NVO:</dt>
		<dd>Network Virtualization Overlay</dd>
	<t hangText="NVO:">Network Virtualization Overlays.</t>	<dt>PE:</dt>
		<dd>Provider Edge</dd>
	<t hangText="RT-2:">EVPN route type 2, i.e., MAC/IP advertisement	<dt>RT-2:</dt>
	route, as defined in <xref target="RFC7432"/>.</t>	<dd>EVPN Route Type 2, i.e., MAC/IP Advertisement
		route, as defined in <xref target="RFC7432" format="default"/>.</dd>
	<t hangText="RT-5:">EVPN route type 5, i.e., IP Prefix route. As	<dt>RT-5:</dt>
	defined in Section 3.</t>	<dd>EVPN Route Type 5, i.e., IP Prefix route, as
		defined in <xref target="sect-3"/>.</dd>
	<t hangText="SBD:">Supplementary Broadcast Domain. A BD that does not	<dt>SBD:</dt>
	have any ACs, only IRB interfaces, and it is used to provide	<dd>Supplementary Broadcast Domain. A BD that does not
		have any ACs, only IRB interfaces, and is used to provide
	connectivity among all the IP-VRFs of the tenant. The SBD is only	connectivity among all the IP-VRFs of the tenant. The SBD is only

	required in IP-VRF-to-IP-VRF use-cases (see <xref	required in IP-VRF-to-IP-VRF use cases (see <xref target="sect-4.4" forma
	target="sect-4.4"/>.).</t>	t="default"/>).</dd>
		<dt>SN:</dt>
	<t hangText="SN:">Subnet.</t>	<dd>Subnet</dd>
		<dt>TS:</dt>
	<t hangText="TS:">Tenant System.</t>	<dd>Tenant System</dd>
		<dt>VA:</dt>
	<t hangText="VA:">Virtual Appliance.</t>	<dd>Virtual Appliance</dd>
		<dt>VM:</dt>
	<t hangText="VNI:">Virtual Network Identifier. As in [RFC8365], the	<dd>Virtual Machine</dd>
		<dt>VNI:</dt>
		<dd>Virtual Network Identifier. As in <xref target="RFC8365"/>, the
	term is used as a representation of a 24-bit NVO instance identifier,	term is used as a representation of a 24-bit NVO instance identifier,

	with the understanding that VNI will refer to a VXLAN Network	with the understanding that "VNI" will refer to a VXLAN Network
	Identifier in VXLAN, or Virtual Network Identifier in GENEVE,	Identifier in VXLAN, or a Virtual Network Identifier in GENEVE,
	etc. unless it is stated otherwise.</t>	etc., unless it is stated otherwise.</dd>
		<dt>VSID:</dt>
	<t hangText="VTEP:">VXLAN Termination End Point, as in <xref	<dd>Virtual Subnet Identifier</dd>
	target="RFC7348"/>.</t>	<dt>VTEP:</dt>
		<dd>VXLAN Termination End Point, as per <xref target="RFC7348" format=
	<t hangText="VXLAN:">Virtual Extensible LAN, as in <xref	"default"/>.</dd>
	target="RFC7348"/>.</t>	<dt>VXLAN:</dt>
		<dd>Virtual eXtensible Local Area Network, as per <xref target="RFC734
	</list>	8" format="default"/>.</dd>
	</t>	</dl>
		<t>This document also assumes familiarity with the terminology of
	<t>This document also assumes familiarity with the terminology of	<xref target="RFC7365" format="default"/>, <xref target="RFC7432" format=
	<xref target="RFC7432"/>, <xref target="RFC8365"/> and <xref	"default"/>, and <xref target="RFC8365"/>.</t>
	target="RFC7365"/>.</t>	</section>
		</section>
	</section>	<section anchor="sect-2" numbered="true" toc="default">
		<name>Problem Statement</name>
	</section>	<t>
		This section describes the inter-subnet connectivity requirements in
	<section title="Problem Statement" anchor="sect-2"><t>	DCs and why a specific route type to advertise IP prefixes
	This Section describes the inter-subnet connectivity requirements in
	Data Centers and why a specific route type to advertise IP Prefixes
	is needed.</t>	is needed.</t>

		<section anchor="sect-2.1" numbered="true" toc="default">
		<name>Inter-Subnet Connectivity Requirements in Data Centers</name>
		<t>


	<section title="Inter-Subnet Connectivity Requirements in Data Centers" a	<xref target="RFC7432" format="default"/> is used as the control plane for an N
	nchor="sect-2.1"><t>	VO solution in DCs, where NVE devices can be located in hypervisors or
	<xref target="RFC7432"/> is used as the control plane for a Network Virtualiz	Top-of-Rack (ToR) switches, as described in <xref target="RFC8365" format="de
	ation	fault"/>.</t>
	Overlay (NVO) solution in Data Centers (DC), where Network	<t>
	Virtualization Edge (NVE) devices can be located in Hypervisors or	The following considerations apply to TSs that are
	Top of Rack switches (ToRs), as described in <xref target="RFC8365"/>.</t>	physical or virtual systems identified by MAC (and possibly IP addresses)
		and are connected to BDs by Attachment Circuits:
	<t>
	The following considerations apply to Tenant Systems (TS) that are
	physical or virtual systems identified by MAC and maybe IP addresses
	and connected to BDs by Attachment Circuits:

	<list style="symbols">
	<t>The Tenant Systems may be Virtual Machines (VMs) that generate
	traffic from their own MAC and IP.</t>


	<t>The Tenant Systems may be Virtual Appliance entities (VAs) that	</t>
	forward traffic to/from IP addresses of different End Devices sitting	<ul spacing="normal">
		<li>The Tenant Systems may be VMs that generate
		traffic from their own MAC and IP.</li>
		<li>
		<t>The Tenant Systems may be VA entities that
		forward traffic to/from IP addresses of different end devices sitting
	behind them.	behind them.


	<list style="symbols">	</t>
	<t>These VAs can be firewalls, load balancers, NAT devices, other	<ul spacing="normal">
	appliances or virtual gateways with virtual routing instances.</t>	<li>These VAs can be firewalls, load balancers, NAT devices, other
		appliances, or virtual gateways with virtual routing instances.</li>
	<t>These VAs do not necessarily participate in dynamic routing	<li>These VAs do not necessarily participate in dynamic routing
	protocols and hence rely on the EVPN NVEs to advertise the routes on	protocols and hence rely on the EVPN NVEs to advertise the routes on

	their behalf.</t>	their behalf.</li>


	<t>In all these cases, the VA will forward traffic to other TSes using	<li>In all these cases, the VA will forward traffic to other TSs u
	its own source MAC but the source IP will be the one associated to the	sing
	End Device sitting behind or a translated IP address (part of a public	its own source MAC, but the source IP will be the one associated with the
	NAT pool) if the VA is performing NAT.</t>	end device sitting behind the VA or a translated IP address (part of a pu
		blic
		NAT pool) if the VA is performing NAT.</li>


	<t>Note that the same IP address and endpoint could exist behind two	<li>Note that the same IP address and endpoint could exist behind
	of these TSes. One example of this would be certain appliance	two
		of these TSs. One example of this would be certain appliance
	resiliency mechanisms, where a virtual IP or floating IP can be owned	resiliency mechanisms, where a virtual IP or floating IP can be owned

	by one of the two VAs running the resiliency protocol (the master	by one of the two VAs running the resiliency protocol (the Master
	VA). Virtual Router Redundancy Protocol (VRRP), RFC5798, is one	VA). The Virtual Router Redundancy Protocol (VRRP) <xref target="RFC5798"
	particular example of this. Another example is multi-homed subnets,	/> is one
	i.e., the same subnet is connected to two VAs.</t>	particular example of this. Another example is multihomed subnets,
		i.e., the same subnet is connected to two VAs.</li>
	<t>Although these VAs provide IP connectivity to VMs and subnets	<li>Although these VAs provide IP connectivity to VMs and the subn
		ets
	behind them, they do not always have their own IP interface connected	behind them, they do not always have their own IP interface connected

	to the EVPN NVE, e.g., layer 2 firewalls are examples of VAs not	to the EVPN NVE; Layer 2 firewalls are examples of VAs not
	supporting IP interfaces. </t>	supporting IP interfaces. </li>
		</ul>
	</list>	</li>
	</t>	</ul>
		<t><xref target="fig-1"/> illustrates some of the examples described abo
	</list>	ve.</t>
	</t>	<figure anchor="fig-1">
		<name>DC Inter-subnet Use Cases</name>
	<t>Figure 1 illustrates some of the examples described above.</t>	<artwork name="" type="" align="left" alt=""><![CDATA[

	<figure title="DC inter-subnet use-cases" anchor="fig-1">

	<artwork><![CDATA[
	NVE1	NVE1
	+-----------+	+-----------+
	TS1(VM)--\| (BD-10) \|-----+	TS1(VM)--\| (BD-10) \|-----+

	IP1/M1 +-----------+ \| DGW1	M1/IP1 +-----------+ \| DGW1
	+---------+ +-------------+	+---------+ +-------------+
	\| \|----\| (BD-10) \|	\| \|----\| (BD-10) \|
	SN1---+ NVE2 \| \| \| IRB1\ \|	SN1---+ NVE2 \| \| \| IRB1\ \|
	\| +-----------+ \| \| \| (IP-VRF)\|---+	\| +-----------+ \| \| \| (IP-VRF)\|---+
	SN2---TS2(VA)--\| (BD-10) \|-\| \| +-------------+ _\|_	SN2---TS2(VA)--\| (BD-10) \|-\| \| +-------------+ _\|_

	\| IP2/M2 +-----------+ \| VXLAN/ \| ( )	\| M2/IP2 +-----------+ \| VXLAN/ \| ( )
	IP4---+ <-+ \| GENEVE \| DGW2 ( WAN )	IP4---+ <-+ \| GENEVE \| DGW2 ( WAN )
	\| \| \| +-------------+ (___)	\| \| \| +-------------+ (___)
	vIP23 (floating) \| \|----\| (BD-10) \| \|	vIP23 (floating) \| \|----\| (BD-10) \| \|
	\| +---------+ \| IRB2\ \| \|	\| +---------+ \| IRB2\ \| \|
	SN1---+ <-+ NVE3 \| \| \| \| (IP-VRF)\|---+	SN1---+ <-+ NVE3 \| \| \| \| (IP-VRF)\|---+

	\| IP3/M3 +-----------+ \| \| \| +-------------+	\| M3/IP3 +-----------+ \| \| \| +-------------+
	SN3---TS3(VA)--\| (BD-10) \|---+ \| \|	SN3---TS3(VA)--\| (BD-10) \|---+ \| \|
	\| +-----------+ \| \|	\| +-----------+ \| \|
	IP5---+ \| \|	IP5---+ \| \|
	\| \|	\| \|
	NVE4 \| \| NVE5 +--SN5	NVE4 \| \| NVE5 +--SN5
	+---------------------+ \| \| +-----------+ \|	+---------------------+ \| \| +-----------+ \|
	IP6------\| (BD-1) \| \| +-\| (BD-10) \|--TS4(VA)--SN6	IP6------\| (BD-1) \| \| +-\| (BD-10) \|--TS4(VA)--SN6
	\| \ \| \| +-----------+ \|	\| \ \| \| +-----------+ \|
	\| (IP-VRF) \|--+ ESI4 +--SN7	\| (IP-VRF) \|--+ ESI4 +--SN7
	\| / \IRB3 \|	\| / \IRB3 \|
	\|---\| (BD-2) (BD-10) \|	\|---\| (BD-2) (BD-10) \|
	SN4\| +---------------------+	SN4\| +---------------------+


		Note:
		ESI4 = Ethernet Segment Identifier 4
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>Where:</t>
	<t>Where:</t>	<t>NVE1, NVE2, NVE3, NVE4, NVE5, DGW1, and DGW2 share the same BD for a
	<t>NVE1, NVE2, NVE3, NVE4, NVE5, DGW1 and DGW2 share the same BD for a
	particular tenant. BD-10 is comprised of the collection of BD	particular tenant. BD-10 is comprised of the collection of BD
	instances defined in all the NVEs. All the hosts connected to BD-10	instances defined in all the NVEs. All the hosts connected to BD-10
	belong to the same IP subnet. The hosts connected to BD-10 are listed	belong to the same IP subnet. The hosts connected to BD-10 are listed
	below:	below:


	<list style="symbols">	</t>
	<t>TS1 is a VM that generates/receives traffic from/to IP1, where IP1
	belongs to the BD-10 subnet.</t>


	<t>TS2 and TS3 are Virtual Appliances (VA) that send/receive traffic	<ul spacing="normal">
	from/to the subnets and hosts sitting behind them (SN1, SN2, SN3, IP4 and	<li>TS1 is a VM that generates/receives traffic to/from IP1, where IP1
	IP5). Their IP addresses (IP2 and IP3) belong to the BD-10 subnet and they	belongs to the BD-10 subnet.</li>
		<li>TS2 and TS3 are VAs that send/receive traffic
		to/from the subnets and hosts sitting behind them (SN1, SN2, SN3, IP4, and
		IP5). Their IP addresses (IP2 and IP3) belong to the BD-10 subnet, and they
	can also generate/receive traffic. When these VAs receive packets destined	can also generate/receive traffic. When these VAs receive packets destined

	to their own MAC addresses (M2 and M3) they will route the packets to the	to their own MAC addresses (M2 and M3), they will route the packets to the
	proper subnet or host. These VAs do not support routing protocols to	proper subnet or host. These VAs do not support routing protocols to
	advertise the subnets connected to them and can move to a different server	advertise the subnets connected to them and can move to a different server

	and NVE when the Cloud Management System decides to do so. These VAs may	and NVE when the cloud management system decides to do so. These VAs may
	also support redundancy mechanisms for some subnets, similar to VRRP, where	also support redundancy mechanisms for some subnets, similar to VRRP, where

	a floating IP is owned by the master VA and only the master VA forwards	a floating IP is owned by the Master VA and only the Master VA forwards
	traffic to a given subnet. E.g.,: vIP23 in Figure 1 is a floating IP that	traffic to a given subnet. For example, vIP23 in <xref target="fig-1"/> is a
	can be owned by TS2 or TS3 depending on which system is the master. Only	floating IP that
	the master will forward traffic to SN1.</t>	can be owned by TS2 or TS3 depending on which system is the Master. Only
		the Master will forward traffic to SN1.</li>
	<t>Integrated Routing and Bridging interfaces IRB1, IRB2 and IRB3 have	<li>Integrated Routing and Bridging interfaces IRB1, IRB2, and IRB3 ha
		ve
	their own IP addresses that belong to the BD-10 subnet too. These IRB	their own IP addresses that belong to the BD-10 subnet too. These IRB
	interfaces connect the BD-10 subnet to Virtual Routing and Forwarding	interfaces connect the BD-10 subnet to Virtual Routing and Forwarding
	(IP-VRF) instances that can route the traffic to other subnets for the same	(IP-VRF) instances that can route the traffic to other subnets for the same

	tenant (within the DC or at the other end of the WAN).</t>	tenant (within the DC or at the other end of the WAN).</li>
		<li>TS4 is a Layer 2 VA that provides connectivity to subnets SN5, SN6
	<t>TS4 is a layer 2 VA that provides connectivity to subnets SN5, SN6 and	, and
	SN7, but does not have an IP address itself in the BD-10. TS4 is connected	SN7 but does not have an IP address itself in the BD-10. TS4 is connected
	to a port on NVE5 assigned to Ethernet Segment Identifier 4.</t>	to a port on NVE5 that is assigned to Ethernet Segment Identifier 4 (ESI4).</
		li>
	</list>	</ul>
	</t>	<t>
		For a BD to which an ingress NVE is attached, "Overlay Index" is
	<t>
	For a BD that an ingress NVE is attached to, "Overlay Index" is
	defined as an identifier that the ingress EVPN NVE requires in order	defined as an identifier that the ingress EVPN NVE requires in order
	to forward packets to a subnet or host in a remote subnet. As an	to forward packets to a subnet or host in a remote subnet. As an

	example, vIP23 (Figure 1) is an Overlay Index that any NVE attached	example, vIP23 (<xref target="fig-1"/>) is an Overlay Index that any NVE atta
	to BD-10 needs to know in order to forward packets to SN1. IRB3 IP	ched
	address is an Overlay Index required to get to SN4, and ESI4	to BD-10 needs to know in order to forward packets to SN1. The IRB3 IP
	(Ethernet Segment Identifier 4) is an Overlay Index needed to forward	address is an Overlay Index required to get to SN4, and ESI4 is an Overlay In
	traffic to SN5. In other words, the Overlay Index is a next-hop in	dex needed to forward
	the overlay address space that can be an IP address, a MAC address or	traffic to SN5. In other words, the Overlay Index is a next hop in
	an ESI. When advertised along with an IP Prefix, the Overlay Index	the overlay address space that can be an IP address, a MAC address, or
	requires a recursive resolution to find out to what egress NVE the	an ESI. When advertised along with an IP prefix, the Overlay Index
		requires a recursive resolution to find out the egress NVE to which the
	EVPN packets need to be sent.</t>	EVPN packets need to be sent.</t>

		<t>
		All the DC use cases in <xref target="fig-1"/> require inter-subnet
		forwarding; therefore, the individual host routes and subnets:


	<t>	</t>
	All the DC use cases in Figure 1 require inter-subnet forwarding and	<ol spacing="normal" type="%c)">
	therefore, the individual host routes and subnets:	<li>must be advertised from the NVEs (since VAs and VMs do not
		participate in dynamic routing protocols) and</li>
	<list style="format (%c)">	<li>may be associated with an Overlay Index that can be a VA IP addres
	<t>must be advertised from the NVEs (since VAs and VMs do not	s,
	participate in dynamic routing protocols) and</t>	a floating IP address, a MAC address, or an ESI. The Overlay Index is
		further discussed in <xref target="sect-3.2" format="default"/>.</li>
	<t>may be associated to an Overlay Index that can be a VA IP address,	</ol>
	a floating IP address, a MAC address or an ESI. The Overlay Index is	</section>
	further discussed in <xref target="sect-3.2"/>.</t>	<section anchor="sect-2.2" numbered="true" toc="default">
		<name>The Need for the EVPN IP Prefix Route</name>
	</list>	<t>
	</t>	<xref target="RFC7432" format="default"/> defines a MAC/IP Advertisement rout
		e (also
	</section>	referred to as "RT-2") where a MAC

	<section title="The Need for the EVPN IP Prefix Route" anchor="sect-2.2">
	<t>
	<xref target="RFC7432"/> defines a MAC/IP route (also referred as RT-2) where
	a MAC
	address can be advertised together with an IP address length and IP	address can be advertised together with an IP address length and IP
	address (IP). While a variable IP address length might have been used	address (IP). While a variable IP address length might have been used
	to indicate the presence of an IP prefix in a route type 2, there are	to indicate the presence of an IP prefix in a route type 2, there are
	several specific use cases in which using this route type to deliver	several specific use cases in which using this route type to deliver

	IP Prefixes is not suitable.</t>	IP prefixes is not suitable.</t>
		<t>
	<t>
	One example of such use cases is the "floating IP" example described	One example of such use cases is the "floating IP" example described

	in <xref target="sect-2.1"/>. In this example it is needed to decouple the	in <xref target="sect-2.1" format="default"/>. In this example, it is
	advertisement of the prefixes from the advertisement of MAC address	necessary to decouple the advertisement of the prefixes from the advertisemen
	of either M2 or M3, otherwise the solution gets highly inefficient	t of a MAC address
		of either M2 or M3; otherwise, the solution gets highly inefficient
	and does not scale.</t>	and does not scale.</t>

		<t>
	<t>
	For example, if 1,000 prefixes are advertised from M2 (using RT-2)	For example, if 1,000 prefixes are advertised from M2 (using RT-2)
	and the floating IP owner changes from M2 to M3, 1,000 routes would	and the floating IP owner changes from M2 to M3, 1,000 routes would

	be withdrawn from M2 and readvertise 1k routes from M3. However if a	be withdrawn by M2 and readvertised by M3. However, if a
	separate route type is used, 1,000 routes can be advertised as	separate route type is used, 1,000 routes can be advertised as

	associated to the floating IP address (vIP23) and only one RT-2 for	associated with the floating IP address (vIP23), and only one RT-2 can be use d for
	advertising the ownership of the floating IP, i.e., vIP23 and M2 in	advertising the ownership of the floating IP, i.e., vIP23 and M2 in
	the route type 2. When the floating IP owner changes from M2 to M3, a	the route type 2. When the floating IP owner changes from M2 to M3, a

	single RT-2 withdraw/update is required to indicate the change. The	single RT-2 withdrawal/update is required to indicate the change. The
	remote DGW will not change any of the 1,000 prefixes associated to	remote DGW will not change any of the 1,000 prefixes associated with
	vIP23, but will only update the ARP resolution entry for vIP23 (now	vIP23 but will only update the ARP resolution entry for vIP23 (now
	pointing at M3).</t>	pointing at M3).</t>
		<t>
	<t>	An EVPN route (type 5) for the advertisement of IP prefixes is
	An EVPN route (type 5) for the advertisement of IP Prefixes is
	described in this document. This new route type has a differentiated	described in this document. This new route type has a differentiated

	role from the RT-2 route and addresses the Data Center (or NVO-based	role from the RT-2 route and addresses the inter-subnet connectivity
	networks in general) inter-subnet connectivity scenarios described in	scenarios for DCs (or NVO-based
	this document. Using this new RT-5, an IP Prefix may be advertised	networks in general) described in
	along with an Overlay Index that can be a GW IP address, a MAC or an	this document. Using this new RT-5, an IP prefix may be advertised
	ESI, or without an Overlay Index, in which case the BGP next-hop will	along with an Overlay Index, which can be a GW IP address, a MAC, or an
	point at the egress NVE/ASBR/ABR and the MAC in the Router's MAC	ESI. The IP prefix may also be advertised without an Overlay Index, in which
		case the BGP next hop will
		point at the egress NVE, Area Border Router (ABR), or ASBR, and the MAC in th
		e EVPN Router's MAC
	Extended Community will provide the inner MAC destination address to	Extended Community will provide the inner MAC destination address to
	be used. As discussed throughout the document, the EVPN RT-2 does not	be used. As discussed throughout the document, the EVPN RT-2 does not

	meet the requirements for all the DC use cases, therefore this EVPN	meet the requirements for all the DC use cases; therefore, this EVPN
	route type 5 is required.</t>	route type 5 is required.</t>


	<t>	<t>
	The EVPN route type 5 decouples the IP Prefix advertisements from the	The EVPN route type 5 decouples the IP prefix advertisements from the
	MAC/IP route advertisements in EVPN, hence:	MAC/IP Advertisement routes in EVPN. Hence:

	<list style="format (%c)">
	<t>Allows the clean and clear advertisements of IPv4 or IPv6 prefixes
	in an NLRI (Network Layer Reachability Information message) with no
	MAC addresses.</t>

	<t>Since the route type is different from the MAC/IP Advertisement
	route, the current <xref target="RFC7432"/> procedures do not need to
	be modified.</t>

	<t>Allows a flexible implementation where the prefix can be linked to
	different types of Overlay/Underlay Indexes: overlay IP address,
	overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc.
	</t>


	<t>An EVPN implementation not requiring IP Prefixes can simply discard	</t>
		<ol spacing="normal" type="%c)">
		<li>The clean and clear advertisements of IPv4 or IPv6 prefixes
		in a Network Layer Reachability Information (NLRI) message without
		MAC addresses are allowed.</li>
		<li>Since the route type is different from the MAC/IP Advertisement
		route, the current procedures described in <xref target="RFC7432" format=
		"default"/> do not need to
		be modified.</li>
		<li>A flexible implementation is allowed where the prefix can be linke
		d to
		different types of Overlay/Underlay Indexes: overlay IP addresses,
		overlay MAC addresses, overlay ESIs, underlay BGP next hops, etc.
		</li>
		<li>An EVPN implementation not requiring IP prefixes can simply discar
		d
	them by looking at the route type value.	them by looking at the route type value.

	</t>	</li>
		</ol>
	</list>	<t>
	</t>	The following sections describe how EVPN is extended with a route

	<t>
	The following Sections describe how EVPN is extended with a route
	type for the advertisement of IP prefixes and how this route is used	type for the advertisement of IP prefixes and how this route is used
	to address the inter-subnet connectivity requirements existing in the	to address the inter-subnet connectivity requirements existing in the

	Data Center.</t>	DC.</t>
		</section>
	</section>	</section>
		<section anchor="sect-3" numbered="true" toc="default">
	</section>	<name>The BGP EVPN IP Prefix Route</name>
		<t> The BGP EVPN NLRI as defined in <xref target="RFC7432"/> is shown belo
		w:</t>


	<section title="The BGP EVPN IP Prefix Route" anchor="sect-3">	<figure>
	<t> The BGP EVPN NLRI as defined in [RFC7432] is shown below:</t>	<name>BGP EVPN NLRI</name>
		<artwork>
		+-----------------------------------+
		\| Route Type (1 octet) \|
		+-----------------------------------+
		\| Length (1 octet) \|
		+-----------------------------------+
		\| Route Type specific (variable) \|
		+-----------------------------------+
		</artwork>
		</figure>


	<texttable style="all"><ttcol> Route Type (1 octet)</ttcol>	<!-- <t keepWithPrevious="true"> </t> -->
	<c>Length (1 octet)</c>	<t>
	<c>Route Type specific (variable)</c>
	<postamble> BGP EVPN NLRI</postamble>
	</texttable>
	<t>
	This document defines an additional route type (RT-5) in the IANA	This document defines an additional route type (RT-5) in the IANA

	EVPN Route Types registry <xref target="EVPNRouteTypes"/>, to be used for the	"EVPN Route Types" registry <xref target="EVPNRouteTypes" format="default"/>
	advertisement of EVPN routes using IP Prefixes:</t>	to be used for the
		advertisement of EVPN routes using IP prefixes:</t>
	<t>Value: 5</t>

	<t>Description: IP Prefix Route</t>


	<t>	<ul empty="true"><li>
	According to Section 5.4 in <xref target="RFC7606"/>, a node that doesn't rec	<dl spacing="compact">
	ognize the	<dt>Value:</dt><dd>5</dd>
	Route Type 5 (RT-5) will ignore it. Therefore an NVE following this	<dt>Description:</dt><dd>IP Prefix</dd>
		</dl>
		</li></ul>
		<t>
		According to <xref target="RFC7606" section="5.4" format="default"/>, a node
		that doesn't recognize the
		route type 5 (RT-5) will ignore it. Therefore, an NVE following this
	document can still be attached to a BD where an NVE ignoring RT-5s is	document can still be attached to a BD where an NVE ignoring RT-5s is

	attached to. Regular <xref target="RFC7432"/> procedures would apply in that case for both	attached. Regular procedures described in <xref target="RFC7432" format="defa ult"/> would apply in that case for both
	NVEs. In case two or more NVEs are attached to different BDs of the same	NVEs. In case two or more NVEs are attached to different BDs of the same

	tenant, they MUST support RT-5 for the proper Inter-Subnet Forwarding	tenant, they <bcp14>MUST</bcp14> support the RT-5 for the proper inter-subnet forwarding
	operation of the tenant.</t>	operation of the tenant.</t>

		<t>
	<t>
	The detailed encoding of this route and associated procedures are	The detailed encoding of this route and associated procedures are

	described in the following Sections.</t>	described in the following sections.</t>
		<section anchor="sect-3.1" numbered="true" toc="default">
	<section title="IP Prefix Route Encoding" anchor="sect-3.1"><t>	<name>IP Prefix Route Encoding</name>
	An IP Prefix Route Type for IPv4 has the Length field set to 34 and	<t>
		An IP Prefix route type for IPv4 has the Length field set to 34 and
	consists of the following fields:</t>	consists of the following fields:</t>


	<texttable style="all"><ttcol> RD (8 octets)</ttcol>	<figure>
	<c>Ethernet Segment Identifier (10 octets)</c>	<name>EVPN IP Prefix Route NLRI for IPv4</name>
	<c>Ethernet Tag ID (4 octets)</c>	<artwork>
	<c>IP Prefix Length (1 octet, 0 to 32)</c>	+---------------------------------------+
	<c>IP Prefix (4 octets)</c>	\| RD (8 octets) \|
	<c>GW IP Address (4 octets)</c>	+---------------------------------------+
	<c>MPLS Label (3 octets)</c>	\|Ethernet Segment Identifier (10 octets)\|
	<postamble> EVPN IP Prefix route NLRI for IPv4</postamble>	+---------------------------------------+
	</texttable>	\| Ethernet Tag ID (4 octets) \|
	<t>	+---------------------------------------+
	An IP Prefix Route Type for IPv6 has the Length field set to 58 and	\| IP Prefix Length (1 octet, 0 to 32) \|
		+---------------------------------------+
		\| IP Prefix (4 octets) \|
		+---------------------------------------+
		\| GW IP Address (4 octets) \|
		+---------------------------------------+
		\| MPLS Label (3 octets) \|
		+---------------------------------------+
		</artwork>
		</figure>
		<!-- <t keepWithPrevious="true"> </t> -->
		<t>
		An IP Prefix route type for IPv6 has the Length field set to 58 and
	consists of the following fields:</t>	consists of the following fields:</t>


	<texttable style="all"><ttcol> RD (8 octets)</ttcol>	<figure>
	<c>Ethernet Segment Identifier (10 octets)</c>	<name>EVPN IP Prefix Route NLRI for IPv6</name>
	<c>Ethernet Tag ID (4 octets)</c>	<artwork>
	<c>IP Prefix Length (1 octet, 0 to 128)</c>	+---------------------------------------+
	<c>IP Prefix (16 octets)</c>	\| RD (8 octets) \|
	<c>GW IP Address (16 octets)</c>	+---------------------------------------+
	<c>MPLS Label (3 octets)</c>	\|Ethernet Segment Identifier (10 octets)\|
	<postamble> EVPN IP Prefix route NLRI for IPv6</postamble>	+---------------------------------------+
	</texttable>	\| Ethernet Tag ID (4 octets) \|
	<t>	+---------------------------------------+
		\| IP Prefix Length (1 octet, 0 to 128) \|
		+---------------------------------------+
		\| IP Prefix (16 octets) \|
		+---------------------------------------+
		\| GW IP Address (16 octets) \|
		+---------------------------------------+
		\| MPLS Label (3 octets) \|
		+---------------------------------------+
		</artwork>
		</figure>
		<!-- <t keepWithPrevious="true"> </t> -->
		<t>
	Where:</t>	Where:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>The Length field of the BGP EVPN NLRI for an	<li>The Length field of the BGP EVPN NLRI for an EVPN IP Prefix route
	EVPN IP Prefix route	<bcp14>MUST</bcp14> be either 34 (if IPv4 addresses are carried) or 58 (if
	MUST be either 34 (if IPv4 addresses are carried) or 58 (if IPv6	IPv6
	addresses are carried). The IP Prefix and Gateway IP Address MUST	addresses are carried). The IP prefix and gateway IP address <bcp14>MUST</b
	be from the same IP address family.</t>	cp14>
		be from the same IP address family.</li>
	<t>Route Distinguisher (RD) and Ethernet Tag ID MUST be used as	<li>The Route Distinguisher (RD) and Ethernet Tag ID <bcp14>MUST</bcp1
	defined in <xref target="RFC7432"/> and <xref target="RFC8365"/>. In partic	4> be used as
	ular, the RD is unique	defined in <xref target="RFC7432" format="default"/> and <xref target="RFC8
		365" format="default"/>. In particular, the RD is unique
	per MAC-VRF (or IP-VRF). The MPLS Label field is set to either an	per MAC-VRF (or IP-VRF). The MPLS Label field is set to either an

	MPLS label or a VNI, as described in <xref target="RFC8365"/> for other EVP	MPLS label or a VNI, as described in <xref target="RFC8365" format="default
	N route	"/> for other EVPN route
	types.</t>	types.</li>
		<li>The Ethernet Segment Identifier <bcp14>MUST</bcp14> be a non-zero
	<t>The Ethernet Segment Identifier MUST be a non-zero 10-octet	10-octet
	identifier if the ESI is used as an Overlay Index (see the	identifier if the ESI is used as an Overlay Index (see the

	definition of Overlay Index in <xref target="sect-3.2"/>). It MUST be all b	definition of "Overlay Index" in <xref target="sect-3.2" format="default"/>
	ytes	). It <bcp14>MUST</bcp14> be all bytes zero otherwise. The ESI format is describ
	zero otherwise. The ESI format is described in <xref target="RFC7432"/>.</t	ed in <xref target="RFC7432" format="default"/>.</li>
	>	<li>The IP prefix length can be set to a value between 0 and 32 (bits)
		for IPv4 and between 0 and 128 for IPv6, and it specifies the number
	<t>The IP Prefix Length can be set to a value between 0 and 32 (bits)	of bits in the prefix. The value <bcp14>MUST NOT</bcp14> be greater than 12
	for IPv4 and between 0 and 128 for IPv6, and specifies the number	8.</li>
	of bits in the Prefix. The value MUST NOT be greater than 128.</t>	<li>The IP prefix is a 4- or 16-octet field (IPv4 or IPv6).</li>
		<li>The GW IP Address field is a 4- or 16-octet field (IPv4 or
	<t>The IP Prefix is a 4 or 16-octet field (IPv4 or IPv6).</t>	IPv6) and will encode a valid IP address as an Overlay Index for
		the IP prefixes. The GW IP field <bcp14>MUST</bcp14> be all bytes zero if i
	<t>The GW (Gateway) IP Address field is a 4 or 16-octet field (IPv4 or	t is
	IPv6), and will encode a valid IP address as an Overlay Index for	not used as an Overlay Index. Refer to <xref target="sect-3.2" format="defa
	the IP Prefixes. The GW IP field MUST be all bytes zero if it is	ult"/> for the
	not used as an Overlay Index. Refer to <xref target="sect-3.2"/> for the	definition and use of the Overlay Index.</li>
	definition and use of the Overlay Index.</t>

	<t>The MPLS Label field is encoded as 3 octets, where the high-order
	20 bits contain the label value, as per <xref target="RFC7432"/>. When send
	ing,
	the label value SHOULD be zero if recursive resolution based on
	overlay index is used. If the received MPLS Label value is zero,
	the route MUST contain an Overlay Index and the ingress NVE/PE MUST
	do recursive resolution to find the egress NVE/PE. If the received
	Label is zero and the route does not contain an Overlay Index, it
	MUST be treat-as-withdraw <xref target="RFC7606"/>.</t>

	</list>
	</t>


	<t>	<li>The MPLS Label field is encoded as 3 octets, where the high-order
	The RD, Ethernet Tag ID, IP Prefix Length and IP Prefix are part of	20 bits contain the label value, as per <xref target="RFC7432" format="defa
		ult"/>. When sending,
		the label value <bcp14>SHOULD</bcp14> be zero if a recursive resolution bas
		ed on
		an Overlay Index is used. If the received MPLS label value is zero,
		the route <bcp14>MUST</bcp14> contain an Overlay Index, and the ingress NVE
		/PE <bcp14>MUST</bcp14>
		perform a recursive resolution to find the egress NVE/PE. If the received
		label is zero and the route does not contain an Overlay Index, it
		<bcp14>MUST</bcp14> be "treat as withdraw" <xref target="RFC7606" format="d
		efault"/>.</li>
		</ul>
		<t>
		The RD, Ethernet Tag ID, IP prefix length, and IP prefix are part of
	the route key used by BGP to compare routes. The rest of the fields	the route key used by BGP to compare routes. The rest of the fields
	are not part of the route key.</t>	are not part of the route key.</t>

		<t>
	<t>	An IP Prefix route <bcp14>MAY</bcp14> be sent along with an EVPN Router's MAC
	An IP Prefix Route MAY be sent along with a Router's MAC Extended Community	Extended Community
	(defined in <xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/>) to	(defined in <xref target="RFC9135" format="default"/>) to
	carry the MAC address that is used as the overlay index. Note that the MAC	carry the MAC address that is used as the Overlay Index. Note that the MAC
	address may be that of an TS.</t>	address may be that of a TS.</t>
		<t>
	<t>	As described in <xref target="sect-3.2" format="default"/>, certain data comb
	As described in <xref target="sect-3.2"/>, certain data combinations in a rec	inations in a received
	eived	route would imply a treat-as-withdraw handling of the route
	routes would imply a "treat-as-withdraw" handling of the route	<xref target="RFC7606" format="default"/>.</t>
	<xref target="RFC7606"/>.</t>	</section>
		<section anchor="sect-3.2" numbered="true" toc="default">
	</section>	<name>Overlay Indexes and Recursive Lookup Resolution</name>
		<t>
	<section title="Overlay Indexes and Recursive Lookup Resolution" anchor="
	sect-3.2"><t>
	RT-5 routes support recursive lookup resolution through the use of	RT-5 routes support recursive lookup resolution through the use of
	Overlay Indexes as follows:</t>	Overlay Indexes as follows:</t>


	<t><list style="symbols">	<ul spacing="normal">
		<li>An Overlay Index can be an ESI or IP address in the address space
	<t>An Overlay Index can be an ESI, IP address in the address space	of the tenant or MAC address, and it is used by an NVE as the
	of the tenant or MAC address and it is used by an NVE as the	next hop for a given IP prefix. An Overlay Index always needs a
	next-hop for a given IP Prefix. An Overlay Index always needs a
	recursive route resolution on the NVE/PE that installs the RT-5 into	recursive route resolution on the NVE/PE that installs the RT-5 into

	one of its IP-VRFs, so that the NVE knows to which egress NVE/PE it	one of its IP-VRFs so that the NVE knows to which egress NVE/PE it
	needs to forward the packets. It is important to note that recursive	needs to forward the packets. It is important to note that recursive
	resolution of the Overlay Index applies upon installation into an	resolution of the Overlay Index applies upon installation into an

	IP-VRF, and not upon BGP propagation (for instance, on an ASBR).	IP-VRF and not upon BGP propagation (for instance, on an ASBR).
	Also, as a result of the recursive resolution, the egress NVE/PE is	Also, as a result of the recursive resolution, the egress NVE/PE is

	not necessarily the same NVE that originated the RT-5.</t>	not necessarily the same NVE that originated the RT-5.</li>


	<t>The Overlay Index is indicated along with the RT-5 in the ESI	<li>The Overlay Index is indicated along with the RT-5 in the ESI
	field, GW IP field or Router's MAC Extended Community, depending on	field, GW IP field, or EVPN Router's MAC Extended Community, depending
	whether the IP Prefix next-hop is an ESI, IP address or MAC address	on
	in the tenant space. The Overlay Index for a given IP Prefix is set	whether the IP prefix next hop is an ESI, an IP address, or a MAC addre
		ss
		in the tenant space. The Overlay Index for a given IP prefix is set
	by local policy at the NVE that originates an RT-5 for that IP	by local policy at the NVE that originates an RT-5 for that IP

	Prefix (typically managed by the Cloud Management System).</t>	prefix (typically managed by the cloud management system).</li>


	<t>In order to enable the recursive lookup resolution at the ingress	<li>
		<t>In order to enable the recursive lookup resolution at the ingress
	NVE, an NVE that is a possible egress NVE for a given Overlay Index	NVE, an NVE that is a possible egress NVE for a given Overlay Index
	must originate a route advertising itself as the BGP next hop on the	must originate a route advertising itself as the BGP next hop on the
	path to the system denoted by the Overlay Index. For instance:	path to the system denoted by the Overlay Index. For instance:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>If an NVE receives an RT-5 that specifies an Overlay Index, the	<li>If an NVE receives an RT-5 that specifies an Overlay Index, th
		e
	NVE cannot use the RT-5 in its IP-VRF unless (or until) it can	NVE cannot use the RT-5 in its IP-VRF unless (or until) it can

	recursively resolve the Overlay Index.</t>	recursively resolve the Overlay Index.</li>
		<li>If the RT-5 specifies an ESI as the Overlay Index, a recursive
	<t>If the RT-5 specifies an ESI as the Overlay Index, recursive
	resolution can only be done if the NVE has received and installed an	resolution can only be done if the NVE has received and installed an

	RT-1 (Auto-Discovery per-EVI) route specifying that ESI.</t>	RT-1 (auto-discovery per EVI) route specifying that ESI.</li>
		<li>If the RT-5 specifies a GW IP address as the Overlay Index,
	<t>If the RT-5 specifies a GW IP address as the Overlay Index,	a recursive resolution can only be done if the NVE has received and
	recursive resolution can only be done if the NVE has received and	installed an RT-2 (MAC/IP Advertisement route) specifying that IP addre
	installed an RT-2 (MAC/IP route) specifying that IP address in the	ss in the
	IP address field of its NLRI.</t>	IP Address field of its NLRI.</li>
		<li>If the RT-5 specifies a MAC address as the Overlay Index,
	<t>If the RT-5 specifies a MAC address as the Overlay Index,	a recursive resolution can only be done if the NVE has received and
	recursive resolution can only be done if the NVE has received and	installed an RT-2 (MAC/IP Advertisement route) specifying that MAC addr
	installed an RT-2 (MAC/IP route) specifying that MAC address in the	ess in the
	MAC address field of its NLRI.</t>	MAC Address field of its NLRI.</li>
		</ul>
	</list>
	</t>

	</list>
	</t>


	<t>Note that the RT-1 or RT-2 routes needed for the	<t>Note that the RT-1 or RT-2 routes needed for the
	recursive resolution may arrive before or after the given RT-5	recursive resolution may arrive before or after the given RT-5

	route.	route.</t>
		</li>
	<list style="symbols">

	<t>Irrespective of the recursive resolution, if there is no IGP or BGP
	route to the BGP next-hop of an RT-5, BGP MUST NOT install the RT-5
	even if the Overlay Index can be resolved.</t>


	<t>The ESI and GW IP fields may both be zero at the same time.	<li>Irrespective of the recursive resolution, if there is no IGP or BG
	However, they MUST NOT both be non-zero at the same time. A route	P
		route to the BGP next hop of an RT-5, BGP <bcp14>MUST NOT</bcp14> install
		the RT-5
		even if the Overlay Index can be resolved.</li>
		<li>The ESI and GW IP fields may both be zero at the same time.
		However, they <bcp14>MUST NOT</bcp14> both be non-zero at the same time.
		A route
	containing a non-zero GW IP and a non-zero ESI (at the same time)	containing a non-zero GW IP and a non-zero ESI (at the same time)

	SHOULD be treat-as-withdraw <xref target="RFC7606"/>.</t>	<bcp14>SHOULD</bcp14> be treat as withdraw <xref target="RFC7606" format=
		"default"/>.</li>
	<t>If either the ESI or GW IP are non-zero, then the non-zero one is	<li>If either the ESI or the GW IP are non-zero, then the non-zero one
	the Overlay Index, regardless of whether the Router's MAC Extended	is
	Community is present or the value of the Label. In case the GW IP is	the Overlay Index, regardless of whether the EVPN Router's MAC Extended
	the Overlay Index (hence ESI is zero), the Router's MAC Extended	Community is present or the value of the label. In case the GW IP is
	Community is ignored if present.</t>	the Overlay Index (hence, ESI is zero), the EVPN Router's MAC Extended
		Community is ignored if present.</li>
	<t>A route where ESI, GW IP, MAC and Label are all zero at the same	<li>A route where ESI, GW IP, MAC, and Label are all zero at the same
	time SHOULD be treat-as-withdraw.</t>	time <bcp14>SHOULD</bcp14> be treat as withdraw.</li>
		</ul>
	</list>	<t>
	</t>

	<t>
	The indirection provided by the Overlay Index and its recursive	The indirection provided by the Overlay Index and its recursive
	lookup resolution is required to achieve fast convergence in case of	lookup resolution is required to achieve fast convergence in case of
	a failure of the object represented by the Overlay Index (see the	a failure of the object represented by the Overlay Index (see the

	example described in <xref target="sect-2.2"/>).</t>	example described in <xref target="sect-2.2" format="default"/>).</t>
		<t>
	<t>	<xref target="fields_overlay_table"/> shows the different RT-5 field combinat
	Table 1 shows the different RT-5 field combinations allowed by this	ions allowed by this
	specification and what Overlay Index must be used by the receiving	specification and what Overlay Index must be used by the receiving

	NVE/PE in each case. Those cases where there is no Overlay Index, are	NVE/PE in each case. Cases where there is no Overlay Index are
	indicated as "None" in Table 1. If there is no Overlay Index the	indicated as "None" in <xref target="fields_overlay_table"/>. If there is no
		Overlay Index, the
	receiving NVE/PE will not perform any recursive resolution, and the	receiving NVE/PE will not perform any recursive resolution, and the

	actual next-hop is given by the RT-5's BGP next-hop.</t>	actual next hop is given by the RT-5's BGP next hop.</t>

	<!-- [rfced] id2xml converted the following table to artwork. Please review -->

	<figure><artwork><![CDATA[
	+----------+----------+----------+------------+----------------+
	\| ESI \| GW IP \| MAC* \| Label \| Overlay Index \|
	\|--------------------------------------------------------------\|
	\| Non-Zero \| Zero \| Zero \| Don't Care \| ESI \|
	\| Non-Zero \| Zero \| Non-Zero \| Don't Care \| ESI \|
	\| Zero \| Non-Zero \| Zero \| Don't Care \| GW IP \|
	\| Zero \| Zero \| Non-Zero \| Zero \| MAC \|
	\| Zero \| Zero \| Non-Zero \| Non-Zero \| MAC or None** \|
	\| Zero \| Zero \| Zero \| Non-Zero \| None*** \|
	+----------+----------+----------+------------+----------------+

	RT-5 fields and Indicated Overlay Index
	]]></artwork></figure>


	<t>Table NOTES:	<table anchor="fields_overlay_table">
		<name>RT-5 Fields and Indicated Overlay Index</name>
		<thead>
		<tr>
		<th>ESI</th>
		<th>GW IP</th>
		<th>MAC*</th>
		<th>Label</th>
		<th>Overlay Index</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>Non-Zero</td>
		<td>Zero</td>
		<td>Zero</td>
		<td>Don't Care</td>
		<td>ESI</td>
		</tr>
		<tr>
		<td>Non-Zero</td>
		<td>Zero</td>
		<td>Non-Zero</td>
		<td>Don't Care</td>
		<td>ESI</td>
		</tr>
		<tr>


	<list style="symbols">	<td>Zero</td>
		<td>Non-Zero</td>
		<td>Zero</td>
		<td>Don't Care</td>
		<td>GW IP</td>
		</tr>
		<tr>
		<td>Zero</td>
		<td>Zero</td>
		<td>Non-Zero</td>
		<td>Zero</td>
		<td>MAC</td>
		</tr>
		<tr>
		<td>Zero</td>
		<td>Zero</td>
		<td>Non-Zero</td>
		<td>Non-Zero</td>
		<td>MAC or None**</td>
		</tr>
		<tr>
		<td>Zero</td>
		<td>Zero</td>
		<td>Zero</td>
		<td>Non-Zero</td>
		<td>None***</td>
		</tr>
		</tbody>
		</table>


	<t> MAC with Zero value means no Router's MAC extended community is	<t>Table Notes: </t>
	present along with the RT-5. Non-Zero indicates that the extended	<dl spacing="normal" indent="6">
		<dt>*</dt><dd> MAC with "Zero" value means no EVPN Router's MAC Extend
		ed Community is
		present along with the RT-5. "Non-Zero" indicates that the extended
	community is present and carries a valid MAC address. The encoding of	community is present and carries a valid MAC address. The encoding of

	a MAC address MUST be the 6-octet MAC address specified by <xref	a MAC address <bcp14>MUST</bcp14> be the 6-octet MAC address specified b
	target="IEEE-802.1Q"/> and <xref target="IEEE-802.1D-REV"/>. Examples	y <xref target="IEEE-802.1Q" format="default"/>. Examples
	of invalid MAC addresses are broadcast or multicast MAC	of invalid MAC addresses are broadcast or multicast MAC

	addresses. The route MUST be treat-as-withdraw in case of an invalid	addresses. The route <bcp14>MUST</bcp14> be treat as withdraw in case of
	MAC address. The presence of the Router's MAC extended community	an invalid
		MAC address. The presence of the EVPN Router's MAC Extended Community
	alone is not enough to indicate the use of the MAC address as the	alone is not enough to indicate the use of the MAC address as the

	Overlay Index, since the extended community can be used for other	Overlay Index since the extended community can be used for other
	purposes.</t>	purposes.</dd>


	<t>In this case, the Overlay Index may be the RT-5's MAC address or	<dt>**</dt><dd>In this case, the Overlay Index may be the RT-5's MAC a
	None, depending on the local policy of the receiving NVE/PE. Note	ddress or
	that the advertising NVE/PE that sets the Overlay Index SHOULD	"None", depending on the local policy of the receiving NVE/PE. Note
		that the advertising NVE/PE that sets the Overlay Index <bcp14>SHOULD</b
		cp14>
	advertise an RT-2 for the MAC Overlay Index if there are receiving	advertise an RT-2 for the MAC Overlay Index if there are receiving
	NVE/PEs configured to use the MAC as the Overlay Index. This case in	NVE/PEs configured to use the MAC as the Overlay Index. This case in

	Table 1 is used in the IP-VRF-to-IP-VRF implementations described in	<xref target="fields_overlay_table"/> is used in the IP-VRF-to-IP-VRF
	4.4.1 and 4.4.3. The support of a MAC Overlay Index in this model is	implementations described in Sections <xref target="sect-4.4.1" format="
	OPTIONAL.</t>	counter"/> and <xref target="sect-4.4.3" format="counter"/>. The support of a MA
		C Overlay Index in this model is
	<t>The Overlay Index is None. This is a special case used for	<bcp14>OPTIONAL</bcp14>.</dd>
		<dt>***</dt><dd>The Overlay Index is "None". This is a special case us
		ed for
	IP-VRF-to-IP-VRF where the NVE/PEs are connected by IP NVO tunnels as	IP-VRF-to-IP-VRF where the NVE/PEs are connected by IP NVO tunnels as

	opposed to Ethernet NVO tunnels.</t>	opposed to Ethernet NVO tunnels.</dd>
		</dl>
	</list>	<t>
	</t>	If the combination of ESI, GW IP, MAC, and Label in the receiving RT-5
		is different than the combinations shown in <xref target="fields_overlay_tabl
	<t>	e"/>, the router will
	If the combination of ESI, GW IP, MAC and Label in the receiving RT-5
	is different than the combinations shown in Table 1, the router will
	process the route as per the rules described at the beginning of this	process the route as per the rules described at the beginning of this

	Section (3.2).</t>	section (<xref target="sect-3.2" format="default"/>).</t>
		<t>
	<t>	<xref target="use_overlay_table"/> shows the different inter-subnet use cases
	Table 2 shows the different inter-subnet use-cases described in this	described in this
	document and the corresponding coding of the Overlay Index in the	document and the corresponding coding of the Overlay Index in the
	route type 5 (RT-5).</t>	route type 5 (RT-5).</t>


	<!-- [rfced] id2xml converted the following table to artwork. Please review -->	<table anchor="use_overlay_table">
		<name>Use Cases and Overlay Indexes for Recursive Resolution</name>
	<figure><artwork><![CDATA[	<thead>
	+---------+---------------------+----------------------------+	<tr>
	\| Section \| Use-case \| Overlay Index in the RT-5 \|	<th>Section</th>
	+-------------------------------+----------------------------+	<th>Use Case</th>
	\| 4.1 \| TS IP address \| GW IP \|	<th>Overlay Index in the RT-5</th>
	\| 4.2 \| Floating IP address \| GW IP \|	</tr>
	\| 4.3 \| "Bump in the wire" \| ESI or MAC \|	</thead>
	\| 4.4 \| IP-VRF-to-IP-VRF \| GW IP, MAC or None \|	<tbody>
	+---------+---------------------+----------------------------+	<tr>
		<td><xref target="sect-4.1" format="counter"/></td>
	Use-cases and Overlay Indexes for Recursive Resolution	<td>TS IP address</td>
	]]></artwork>	<td>GW IP</td>
	</figure>	</tr>
	<t>	<tr>
	The above use-cases are representative of the different Overlay	<td><xref target="sect-4.2" format="counter"/></td>
	Indexes supported by RT-5 (GW IP, ESI, MAC or None).</t>	<td>Floating IP address</td>
		<td>GW IP</td>
	</section>	</tr>
		<tr>
		<td><xref target="sect-4.3" format="counter"/></td>
		<td>"Bump-in-the-wire"</td>
		<td>ESI or MAC</td>
		</tr>
		<tr>
		<td><xref target="sect-4.4" format="counter"/></td>
		<td>IP-VRF-to-IP-VRF</td>
		<td>GW IP, MAC, or None</td>
		</tr>
		</tbody>
		</table>


	</section>	<t>
		The above use cases are representative of the different Overlay
		Indexes supported by the RT-5 (GW IP, ESI, MAC, or None).</t>
		</section>
		</section>
		<section anchor="sect-4" numbered="true" toc="default">
		<name>Overlay Index Use Cases</name>
		<t> This
		section describes some use cases for the Overlay Index types used with
		the IP Prefix route.


	<section title="Overlay Index Use-Cases" anchor="sect-4"><t> This	Although the examples use IPv4 prefixes and
	Section describes some use-cases for the Overlay Index types used with
	the IP Prefix route. Although the examples use IPv4 Prefixes and
	subnets, the descriptions of the RT-5 are valid for the same cases	subnets, the descriptions of the RT-5 are valid for the same cases

	with IPv6, only replacing the IP Prefixes, IPL and GW IP by the	with IPv6, except that IP Prefixes, IPL, and GW IP are replaced by the
	corresponding IPv6 values.</t>	corresponding IPv6 values.</t>

		<section anchor="sect-4.1" numbered="true" toc="default">
	<section title="TS IP Address Overlay Index Use-Case" anchor="sect-4.1">	<name>TS IP Address Overlay Index Use Case</name>
		<t><xref target="fig-2"/> illustrates an example of inter-subnet forward
	<t>Figure 5 illustrates an example of inter-subnet forwarding for	ing for
	subnets sitting behind Virtual Appliances (on TS2 and TS3).</t>	subnets sitting behind VAs (on TS2 and TS3).</t>
		<figure anchor="fig-2">
	<figure title="TS IP address use-case" anchor="fig-2">	<name>TS IP Address Use Case</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	IP4---+ NVE2 DGW1	IP4---+ NVE2 DGW1
	\| +-----------+ +---------+ +-------------+	\| +-----------+ +---------+ +-------------+
	SN2---TS2(VA)--\| (BD-10) \|-\| \|----\| (BD-10) \|	SN2---TS2(VA)--\| (BD-10) \|-\| \|----\| (BD-10) \|

	\| IP2/M2 +-----------+ \| \| \| IRB1\ \|	\| M2/IP2 +-----------+ \| \| \| IRB1\ \|
	-+---+ \| \| \| (IP-VRF)\|---+	-+---+ \| \| \| (IP-VRF)\|---+
	\| \| \| +-------------+ _\|_	\| \| \| +-------------+ _\|_
	SN1 \| VXLAN/ \| ( )	SN1 \| VXLAN/ \| ( )
	\| \| GENEVE \| DGW2 ( WAN )	\| \| GENEVE \| DGW2 ( WAN )
	-+---+ NVE3 \| \| +-------------+ (___)	-+---+ NVE3 \| \| +-------------+ (___)

	\| IP3/M3 +-----------+ \| \|----\| (BD-10) \| \|	\| M3/IP3 +-----------+ \| \|----\| (BD-10) \| \|
	SN3---TS3(VA)--\| (BD-10) \|-\| \| \| IRB2\ \| \|	SN3---TS3(VA)--\| (BD-10) \|-\| \| \| IRB2\ \| \|
	\| +-----------+ +---------+ \| (IP-VRF)\|---+	\| +-----------+ +---------+ \| (IP-VRF)\|---+
	IP5---+ +-------------+	IP5---+ +-------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	An example of inter-subnet forwarding between subnet SN1, which uses	An example of inter-subnet forwarding between subnet SN1, which uses

	a 24 bit IP prefix (written as SN1/24 in future), and a subnet	a 24-bit IP prefix (written as SN1/24 in the future), and a subnet
	sitting in the WAN is described below. NVE2, NVE3, DGW1 and DGW2 are	sitting in the WAN is described below. NVE2, NVE3, DGW1, and DGW2 are
	running BGP EVPN. TS2 and TS3 do not participate in dynamic routing	running BGP EVPN. TS2 and TS3 do not participate in dynamic routing
	protocols, and they only have a static route to forward the traffic	protocols, and they only have a static route to forward the traffic
	to the WAN. SN1/24 is dual-homed to NVE2 and NVE3.</t>	to the WAN. SN1/24 is dual-homed to NVE2 and NVE3.</t>

		<t>
	<t>
	In this case, a GW IP is used as an Overlay Index. Although a	In this case, a GW IP is used as an Overlay Index. Although a

	different Overlay Index type could have been used, this use-case	different Overlay Index type could have been used, this use case
	assumes that the operator knows the VA's IP addresses beforehand,	assumes that the operator knows the VA's IP addresses beforehand,
	whereas the VA's MAC address is unknown and the VA's ESI is zero.	whereas the VA's MAC address is unknown and the VA's ESI is zero.
	Because of this, the GW IP is the suitable Overlay Index to be used	Because of this, the GW IP is the suitable Overlay Index to be used

	with the RT-5s. The NVEs know the GW IP to be used for a given Prefix	with the RT-5s. The NVEs know the GW IP to be used for a given prefix
	by policy.	by policy.


	<list style="format (%d)">

	<t>NVE2 advertises the following BGP routes on behalf of TS2:

	<list style="symbols">

	<t>Route type 2 (MAC/IP route) containing: ML=48 (MAC Address Length),
	M=M2 (MAC Address), IPL=32 (IP Prefix Length), IP=IP2 and [RFC5512] BGP
	Encapsulation Extended Community with the corresponding Tunnel type. The
	MAC and IP addresses may be learned via ARP snooping.</t>

	<t>Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW
	IP address=IP2. The prefix and GW IP are learned by policy.</t>

	</list>
	</t>	</t>

		<ol spacing="normal" type="(%d)">
		<li>
		<t>NVE2 advertises the following BGP routes on behalf of TS2:


	<t>Similarly, NVE3 advertises the following BGP routes on behalf of TS3:	</t>
		<ul spacing="normal">
	<list style="symbols">

	<t>Route type 2 (MAC/IP route) containing: ML=48, M=M3, IPL=32, IP=IP3
	(and BGP Encapsulation Extended Community).</t>

	<t>Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1,
	ESI=0, GW IP address=IP3.</t>

	</list>
	</t>


	<t>DGW1 and DGW2 import both received routes based on the Route Targets:	<li>Route type 2 (MAC/IP Advertisement route) containing: ML = 48
		(MAC address length),
		M = M2 (MAC address), IPL = 32 (IP prefix length), IP = IP2, and BGP
		Encapsulation Extended Community <xref target="RFC9012"/> with the corresp
		onding tunnel type. The
		MAC and IP addresses may be learned via ARP snooping.</li>
		<li>Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1,
		ESI = 0, and GW
		IP address = IP2. The prefix and GW IP are learned by policy.</li>
		</ul>
		</li>
		<li>
		<t>Similarly, NVE3 advertises the following BGP routes on behalf of
		TS3:


	<list style="symbols">	</t>
		<ul spacing="normal">
		<li>Route type 2 (MAC/IP Advertisement route) containing: ML = 48,
		M = M3, IPL = 32, IP = IP3
		(and BGP Encapsulation Extended Community).</li>
		<li>Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1,
		ESI = 0, and GW IP address = IP3.</li>
		</ul>
		</li>
		<li>
		<t>DGW1 and DGW2 import both received routes based on the Route Targ
		ets:


	<t>Based on the BD-10 Route Target in DGW1 and DGW2, the MAC/IP route	</t>
	is imported and M2 is added to the BD-10 along with its corresponding	<ul spacing="normal">
		<li>Based on the BD-10 Route Target in DGW1 and DGW2, the MAC/IP A
		dvertisement route
		is imported, and M2 is added to the BD-10 along with its corresponding
	tunnel information. For instance, if VXLAN is used, the VTEP will be	tunnel information. For instance, if VXLAN is used, the VTEP will be

	derived from the MAC/IP route BGP next-hop and VNI from the MPLS Label1	derived from the MAC/IP Advertisement route BGP next hop and VNI from the
	field. IP2 - M2 is added to the ARP table. Similarly, M3 is added to	MPLS Label1
	BD-10 and IP3 - M3 to the ARP table.</t>	field. M2/IP2 is added to the ARP table. Similarly, M3 is added to
		BD-10, and M3/IP3 is added to the ARP table.</li>
	<t>Based on the BD-10 Route Target in DGW1 and DGW2, the IP Prefix	<li>Based on the BD-10 Route Target in DGW1 and DGW2, the IP Prefi
	route is also imported and SN1/24 is added to the IP-VRF with Overlay	x
		route is also imported, and SN1/24 is added to the IP-VRF with Overlay
	Index IP2 pointing at the local BD-10. In this example, it is assumed	Index IP2 pointing at the local BD-10. In this example, it is assumed
	that the RT-5 from NVE2 is preferred over the RT-5 from NVE3. If both	that the RT-5 from NVE2 is preferred over the RT-5 from NVE3. If both
	routes were equally preferable and ECMP enabled, SN1/24 would also be	routes were equally preferable and ECMP enabled, SN1/24 would also be

	added to the routing table with Overlay Index IP3.</t>	added to the routing table with Overlay Index IP3.</li>
		</ul>
	</list>	</li>
	</t>	<li>
	<t> When DGW1 receives a packet from the WAN with destination IPx, where IPx	<t> When DGW1 receives a packet from the WAN with destination IPx,
	belongs to SN1/24:	where IPx belongs to SN1/24:

	<list style="symbols">


	<t>A destination IP lookup is performed on the DGW1 IP-VRF routing	</t>
	table and Overlay Index=IP2 is found. Since IP2 is an Overlay Index a
	recursive route resolution is required for IP2.</t>


	<t>IP2 is resolved to M2 in the ARP table, and M2 is resolved to the	<ul spacing="normal">
		<li>A destination IP lookup is performed on the DGW1 IP-VRF table,
		and Overlay Index = IP2 is found. Since IP2 is an Overlay Index, a
		recursive route resolution is required for IP2.</li>
		<li>IP2 is resolved to M2 in the ARP table, and M2 is resolved to
		the
	tunnel information given by the BD FIB (e.g., remote VTEP and VNI for	tunnel information given by the BD FIB (e.g., remote VTEP and VNI for

	the VXLAN case).</t>	the VXLAN case).</li>
		<li>
	<t>The IP packet destined to IPx is encapsulated with:	<t>The IP packet destined to IPx is encapsulated with:

	<list style="symbols">

	<t>Source inner MAC = IRB1 MAC.</t>

	<t>Destination inner MAC = M2.</t>

	<t>Tunnel information provided by the BD (VNI, VTEP IPs and MACs for
	the VXLAN case).</t>

	</list>
	</t>

	</list>
	</t>

	<t>When the packet arrives at NVE2:


	<list style="symbols">	</t>
		<ul spacing="normal">
		<li>Inner source MAC = IRB1 MAC.</li>
		<li>Inner destination MAC = M2.</li>
		<li>Tunnel information provided by the BD (VNI, VTEP IPs, and
		MACs for
		the VXLAN case).</li>
		</ul>
		</li>
		</ul>
		</li>
		<li>
		<t>When the packet arrives at NVE2:


	<t>Based on the tunnel information (VNI for the VXLAN case), the BD-10	</t>
	context is identified for a MAC lookup.</t>	<ul spacing="normal">
		<li>Based on the tunnel information (VNI for the VXLAN case), the
		BD-10
		context is identified for a MAC lookup.</li>


	<t>Encapsulation is stripped off and based on a MAC lookup	<li>Encapsulation is stripped off and, based on a MAC lookup
	(assuming MAC forwarding on the egress NVE), the packet is	(assuming MAC forwarding on the egress NVE), the packet is

	forwarded to TS2, where it will be properly routed.</t>	forwarded to TS2, where it will be properly routed.</li>
		</ul>
	</list>	</li>
	</t>	<li>Should TS2 move from NVE2 to NVE3, MAC Mobility procedures will be
		applied
	<t>Should TS2 move from NVE2 to NVE3, MAC Mobility procedures will be applied	to the MAC route M2/IP2, as defined in <xref target="RFC7432"/>. Route type 5
	to the MAC route IP2/M2, as defined in [RFC7432]. Route type 5 prefixes are	prefixes are not subject to MAC Mobility procedures; hence, no changes in the
	not subject to MAC mobility procedures, hence no changes in the DGW IP-VRF	DGW IP-VRF table will occur for TS2 mobility -- i.e., all the prefixes will stil
	routing table will occur for TS2 mobility, i.e., all the prefixes will still	l
	be pointing at IP2 as Overlay Index. There is an indirection for e.g., SN1/24,	be pointing at IP2 as the Overlay Index. There is an indirection for, e.g., SN1/
		24,
	which still points at Overlay Index IP2 in the routing table, but IP2 will be	which still points at Overlay Index IP2 in the routing table, but IP2 will be

	simply resolved to a different tunnel, based on the outcome of the MAC	simply resolved to a different tunnel based on the outcome of the MAC
	mobility procedures for the MAC/IP route IP2/M2.</t>	Mobility procedures for the MAC/IP Advertisement route M2/IP2.</li>
		</ol>
	</list>	<t>
	</t>

	<t>
	Note that in the opposite direction, TS2 will send traffic based on	Note that in the opposite direction, TS2 will send traffic based on
	its static-route next-hop information (IRB1 and/or IRB2), and regular	its static-route next-hop information (IRB1 and/or IRB2), and regular
	EVPN procedures will be applied.</t>	EVPN procedures will be applied.</t>

		</section>
		<section anchor="sect-4.2" numbered="true" toc="default">
		<name>Floating IP Overlay Index Use Case</name>


	</section>	<t>
		Sometimes TSs work in active/standby mode where an
	<section title="Floating IP Overlay Index Use-Case" anchor="sect-4.2"><t>	upstream floating IP owned by the active TS is used as the
	Sometimes Tenant Systems (TS) work in active/standby mode where an	Overlay Index to get to some subnets behind the TS. This redundancy mode,
	upstream floating IP - owned by the active TS - is used as the	already introduced in Sections <xref target="sect-2.1" format="counter"/> and
	Overlay Index to get to some subnets behind. This redundancy mode,	<xref target="sect-2.2" format="counter"/>, is illustrated in <xref target="fig
	already introduced in <xref target="sect-2.1"/> and 2.2, is illustrated in Fi	-3"/>.</t>
	gure	<figure anchor="fig-3">
	6.</t>	<name>Floating IP Overlay Index for Redundant TS</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure title="Floating IP Overlay Index for redundant TS" anchor="fig-3">
	<artwork><![CDATA[
	NVE2 DGW1	NVE2 DGW1
	+-----------+ +---------+ +-------------+	+-----------+ +---------+ +-------------+
	+---TS2(VA)--\| (BD-10) \|-\| \|----\| (BD-10) \|	+---TS2(VA)--\| (BD-10) \|-\| \|----\| (BD-10) \|

	\| IP2/M2 +-----------+ \| \| \| IRB1\ \|	\| M2/IP2 +-----------+ \| \| \| IRB1\ \|
	\| <-+ \| \| \| (IP-VRF)\|---+	\| <-+ \| \| \| (IP-VRF)\|---+
	\| \| \| \| +-------------+ _\|_	\| \| \| \| +-------------+ _\|_
	SN1 vIP23 (floating) \| VXLAN/ \| ( )	SN1 vIP23 (floating) \| VXLAN/ \| ( )
	\| \| \| GENEVE \| DGW2 ( WAN )	\| \| \| GENEVE \| DGW2 ( WAN )
	\| <-+ NVE3 \| \| +-------------+ (___)	\| <-+ NVE3 \| \| +-------------+ (___)

	\| IP3/M3 +-----------+ \| \|----\| (BD-10) \| \|	\| M3/IP3 +-----------+ \| \|----\| (BD-10) \| \|
	+---TS3(VA)--\| (BD-10) \|-\| \| \| IRB2\ \| \|	+---TS3(VA)--\| (BD-10) \|-\| \| \| IRB2\ \| \|
	+-----------+ +---------+ \| (IP-VRF)\|---+	+-----------+ +---------+ \| (IP-VRF)\|---+
	+-------------+	+-------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	In this use-case, a GW IP is used as an Overlay Index for the same	In this use case, a GW IP is used as an Overlay Index for the same
	reasons as in 4.1. However, this GW IP is a floating IP that belongs	reasons as in <xref target="sect-4.1" format="default"/>. However, this GW IP
		is a floating IP that belongs
	to the active TS. Assuming TS2 is the active TS and owns vIP23:	to the active TS. Assuming TS2 is the active TS and owns vIP23:


	<list style="format (%d)">

	<t>NVE2 advertises the following BGP routes for TS2:

	<list style="symbols">

	<t>Route type 2 (MAC/IP route) containing: ML=48, M=M2, IPL=32,
	IP=vIP23 (and BGP Encapsulation Extended Community). The MAC and IP
	addresses may be learned via ARP snooping.</t>

	<t>Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW
	IP address=vIP23. The prefix and GW IP are learned by policy.</t>

	</list>
	</t>	</t>

		<ol spacing="normal" type="(%d)">
		<li>
		<t>NVE2 advertises the following BGP routes for TS2:


	<t>NVE3 advertises the following BGP route for TS3 (it does not advertise an	</t>
	RT-2 for vIP23/M3):	<ul spacing="normal">
		<li>Route type 2 (MAC/IP Advertisement route) containing: ML = 48,
	<list style="symbols">	M = M2, IPL = 32, and
		IP = vIP23 (as well as BGP Encapsulation Extended Community). The MAC and
	<t>Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW	IP
	IP address=vIP23. The prefix and GW IP are learned by policy.</t>	addresses may be learned via ARP snooping.</li>
		<li>Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1,
	</list>	ESI = 0, and GW
	</t>	IP address = vIP23. The prefix and GW IP are learned by policy.</li>
	<t>DGW1 and DGW2 import both received routes based on the Route Target:	</ul>
		</li>
		<li>
		<t>NVE3 advertises the following BGP route for TS3 (it does not adve
		rtise an
		RT-2 for M3/vIP23):


	<list style="symbols">	</t>
		<ul spacing="normal">
		<li>Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1,
		ESI = 0, and GW
		IP address = vIP23. The prefix and GW IP are learned by policy.</li>
		</ul>
		</li>
		<li>
		<t>DGW1 and DGW2 import both received routes based on the Route Targ
		et:


	<t>M2 is added to the BD-10 FIB along with its corresponding tunnel	</t>
		<ul spacing="normal">
		<li>M2 is added to the BD-10 FIB along with its corresponding tunn
		el
	information. For the VXLAN use case, the VTEP will be derived from the	information. For the VXLAN use case, the VTEP will be derived from the

	MAC/IP route BGP next-hop and VNI from the VNI field. vIP23 - M2 is added	MAC/IP Advertisement route BGP next hop and VNI from the VNI field. M2/vIP2
	to the ARP table.</t>	3 is added
		to the ARP table.</li>
	<t>SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay index	<li>SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay In
	vIP23 pointing at M2 in the local BD-10.</t>	dex
		vIP23 pointing at M2 in the local BD-10.</li>
	</list>	</ul>
	</t>	</li>
		<li>
	<t>When DGW1 receives a packet from the WAN with destination IPx, where IPx	<t>When DGW1 receives a packet from the WAN with destination IPx, wh
		ere IPx
	belongs to SN1/24:	belongs to SN1/24:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>A destination IP lookup is performed on the DGW1 IP-VRF routing table	<li>A destination IP lookup is performed on the DGW1 IP-VRF table,
	and Overlay Index=vIP23 is found. Since vIP23 is an Overlay Index, a	and Overlay Index = vIP23 is found. Since vIP23 is an Overlay Index, a
	recursive route resolution for vIP23 is required.</t>	recursive route resolution for vIP23 is required.</li>
		<li>vIP23 is resolved to M2 in the ARP table, and M2 is resolved t
	<t>vIP23 is resolved to M2 in the ARP table, and M2 is resolved to the	o the
	tunnel information given by the BD (remote VTEP and VNI for the VXLAN	tunnel information given by the BD (remote VTEP and VNI for the VXLAN

	case).</t>	case).</li>
		<li>
	<t>The IP packet destined to IPx is encapsulated with:	<t>The IP packet destined to IPx is encapsulated with:

	<list style="symbols">

	<t>Source inner MAC = IRB1 MAC.</t>

	<t>Destination inner MAC = M2.</t>

	<t>Tunnel information provided by the BD FIB (VNI, VTEP IPs and MACs
	for the VXLAN case).</t>

	</list>
	</t>

	</list>
	</t>

	<t>When the packet arrives at NVE2:

	<list style="symbols">


	<t>Based on the tunnel information (VNI for the VXLAN case), the BD-10	</t>
	context is identified for a MAC lookup.</t>	<ul spacing="normal">
		<li>Inner source MAC = IRB1 MAC.</li>
		<li>Inner destination MAC = M2.</li>
		<li>Tunnel information provided by the BD FIB (VNI, VTEP IPs,
		and MACs
		for the VXLAN case).</li>
		</ul>
		</li>
		</ul>
		</li>
		<li>
		<t>When the packet arrives at NVE2:


	<t>Encapsulation is stripped off and based on a MAC lookup (assuming	</t>
		<ul spacing="normal">
		<li>Based on the tunnel information (VNI for the VXLAN case), the
		BD-10
		context is identified for a MAC lookup.</li>
		<li>Encapsulation is stripped off and, based on a MAC lookup (assu
		ming
	MAC forwarding on the egress NVE), the packet is forwarded to TS2,	MAC forwarding on the egress NVE), the packet is forwarded to TS2,

	where it will be properly routed.</t>	where it will be properly routed.</li>
		</ul>
	</list>	</li>
	</t>	<li>When the redundancy protocol running between TS2 and TS3 appoints
		TS3 as
	<t>When the redundancy protocol running between TS2 and TS3 appoints TS3 as
	the new active TS for SN1, TS3 will now own the floating vIP23 and will signal	the new active TS for SN1, TS3 will now own the floating vIP23 and will signal

	this new ownership, using a gratuitous ARP REPLY message (explained in <xref	this new ownership using a gratuitous ARP REPLY message (explained in <xref targ
	target="RFC5227"/>) or similar. Upon receiving the new owner's notification,	et="RFC5227" format="default"/>) or similar. Upon receiving the new owner's noti
	NVE3 will issue a route type 2 for M3-vIP23 and NVE2 will withdraw the RT-2	fication,
	for M2-vIP23. DGW1 and DGW2 will update their ARP tables with the new MAC	NVE3 will issue a route type 2 for M3/vIP23, and NVE2 will withdraw the RT-2
	resolving the floating IP. No changes are made in the IP-VRF routing	for M2/vIP23. DGW1 and DGW2 will update their ARP tables with the new MAC
	table.</t>	resolving the floating IP. No changes are made in the IP-VRF table.</li>
		</ol>
	</list>	</section>
	</t>	<section anchor="sect-4.3" numbered="true" toc="default">
		<name>Bump-in-the-Wire Use Case</name>
	</section>	<t>
		<xref target="fig-4"/> illustrates an example of inter-subnet forwarding for an
	<section title="Bump-in-the-Wire Use-Case" anchor="sect-4.3"><t>	IP
	Figure 7 illustrates an example of inter-subnet forwarding for an IP	Prefix route that carries subnet SN1. In this use case, TS2 and TS3
	Prefix route that carries a subnet SN1. In this use-case, TS2 and TS3	are Layer 2 VA devices without any IP addresses that can be included as
	are layer 2 VA devices without any IP address that can be included as
	an Overlay Index in the GW IP field of the IP Prefix route. Their MAC	an Overlay Index in the GW IP field of the IP Prefix route. Their MAC

	addresses are M2 and M3 respectively and are connected to BD-10. Note	addresses are M2 and M3, respectively, and are connected to BD-10. Note
	that IRB1 and IRB2 (in DGW1 and DGW2 respectively) have IP addresses	that IRB1 and IRB2 (in DGW1 and DGW2, respectively) have IP addresses
	in a subnet different than SN1.</t>	in a subnet different than SN1.</t>

		<figure anchor="fig-4">
	<figure title="Bump-in-the-wire use-case" anchor="fig-4">	<name>Bump-in-the-Wire Use Case</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	NVE2 DGW1	NVE2 DGW1
	M2 +-----------+ +---------+ +-------------+	M2 +-----------+ +---------+ +-------------+
	+---TS2(VA)--\| (BD-10) \|-\| \|----\| (BD-10) \|	+---TS2(VA)--\| (BD-10) \|-\| \|----\| (BD-10) \|
	\| ESI23 +-----------+ \| \| \| IRB1\ \|	\| ESI23 +-----------+ \| \| \| IRB1\ \|
	\| + \| \| \| (IP-VRF)\|---+	\| + \| \| \| (IP-VRF)\|---+
	\| \| \| \| +-------------+ _\|_	\| \| \| \| +-------------+ _\|_
	SN1 \| \| VXLAN/ \| ( )	SN1 \| \| VXLAN/ \| ( )
	\| \| \| GENEVE \| DGW2 ( WAN )	\| \| \| GENEVE \| DGW2 ( WAN )
	\| + NVE3 \| \| +-------------+ (___)	\| + NVE3 \| \| +-------------+ (___)
	\| ESI23 +-----------+ \| \|----\| (BD-10) \| \|	\| ESI23 +-----------+ \| \|----\| (BD-10) \| \|
	+---TS3(VA)--\| (BD-10) \|-\| \| \| IRB2\ \| \|	+---TS3(VA)--\| (BD-10) \|-\| \| \| IRB2\ \| \|
	M3 +-----------+ +---------+ \| (IP-VRF)\|---+	M3 +-----------+ +---------+ \| (IP-VRF)\|---+
	+-------------+	+-------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>
	Since neither TS2 nor TS3 can participate in any dynamic routing
	protocol and have no IP address assigned, there are two potential
	Overlay Index types that can be used when advertising SN1:

	<list style="format (%c)">

	<t>an ESI, i.e., ESI23, that can be provisioned on the attachment
	ports of NVE2 and NVE3, as shown in Figure 7.</t>

	<t>or the VA's MAC address, that can be added to NVE2 and NVE3 by
	policy.</t>


	</list>	<t>
	</t>	Since TS2 and TS3 cannot participate in any dynamic routing
		protocol and neither has an IP address assigned, there are two potential
		Overlay Index types that can be used when advertising SN1:


	<t>	</t>
	The advantage of using an ESI as Overlay Index as opposed to the VA's MAC	<ol spacing="normal" type="%c)">
	address, is that the forwarding to the egress NVE can be done purely based	<li>an ESI, i.e., ESI23, that can be provisioned on the attachment
	on the state of the AC in the ES (notified by the Ethernet A-D per-EVI	ports of NVE2 and NVE3, as shown in <xref target="fig-4"/> or</li>
	route) and all the EVPN multi-homing redundancy mechanisms can be	<li>the VA's MAC address, which can be added to NVE2 and NVE3 by
	reused. For instance, the <xref target="RFC7432"/> mass-withdrawal mechanism	policy.</li>
	for fast	</ol>
	failure detection and propagation can be used. This Section assumes that	<t>
	an ESI Overlay Index is used in this use-case but it does not prevent the	The advantage of using an ESI as the Overlay Index as opposed to the VA's MAC
		address is that the forwarding to the egress NVE can be done purely based
		on the state of the AC in the Ethernet segment (notified by the Ethernet A-D
		per EVI
		route), and all the EVPN multihoming redundancy mechanisms can be
		reused. For instance, the mass withdrawal mechanism described in <xref target
		="RFC7432" format="default"/> for fast
		failure detection and propagation can be used. It is assumed per this sectio
		n that
		an ESI Overlay Index is used in this use case, but this use case does not pre
		clude the
	use of the VA's MAC address as an Overlay Index. If a MAC is used as	use of the VA's MAC address as an Overlay Index. If a MAC is used as

	Overlay Index, the control plane must follow the procedures described in	the Overlay Index, the control plane must follow the procedures described in
	<xref target="sect-4.4.3"/>.</t>	<xref target="sect-4.4.3" format="default"/>.</t>
		<t>
	<t>
	The model supports VA redundancy in a similar way to the one	The model supports VA redundancy in a similar way to the one

	described in <xref target="sect-4.2"/> for the floating IP Overlay Index use-	described in <xref target="sect-4.2" format="default"/> for the floating IP O
	case,	verlay Index use case,
	except that it uses the EVPN Ethernet A-D per-EVI route instead of	except that it uses the EVPN Ethernet A-D per EVI route instead of
	the MAC advertisement route to advertise the location of the Overlay	the MAC advertisement route to advertise the location of the Overlay
	Index. The procedure is explained below:	Index. The procedure is explained below:


	<list style="format (%d)">	</t>
		<ol spacing="normal" type="(%d)">
	<t> Assuming TS2 is the active TS in ESI23, NVE2 advertises the	<li>
		<t> Assuming TS2 is the active TS in ESI23, NVE2 advertises the
	following BGP routes:	following BGP routes:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>Route type 1 (Ethernet A-D route for BD-10) containing: ESI=ESI23 and	<li>Route type 1 (Ethernet A-D route for BD-10) containing: ESI =
		ESI23 and
	the corresponding tunnel information (VNI field), as well as the BGP	the corresponding tunnel information (VNI field), as well as the BGP

	Encapsulation Extended Community as per [RFC8365].</t>	Encapsulation Extended Community as per <xref target="RFC8365"/>.</li>
		<li>Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1,
	<t>Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=ESI23,	ESI = ESI23, and GW IP address = 0. The EVPN Router's MAC Extended
	GW IP address=0. The Router's MAC Extended Community defined in	Community defined in
	[EVPN-INTERSUBNET] is added and carries the MAC address (M2) associated	<xref target="RFC9135"/> is added and carries the MAC address (M2)
	to the TS behind which SN1 sits. M2 may be learned by policy, however the	associated with the TS behind which SN1 sits. M2 may be learned by policy;
	MAC in the Extended Community is preferred if sent with the route.</t>	however, the
		MAC in the Extended Community is preferred if sent with the route.</li>
	</list>	</ul>
	</t>	</li>
		<li>
	<t>NVE3 advertises the following BGP route for TS3 (no AD per-EVI route is	<t>NVE3 advertises the following BGP route for TS3 (no AD per EVI ro
		ute is
	advertised):	advertised):


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=23,	<li>Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1,
	GW IP address=0. The Router's MAC Extended Community is added and	ESI = 23, and GW IP address = 0. The EVPN Router's MAC Extended Com
	carries the MAC address (M3) associated to the TS behind which SN1	munity is added and
	sits. M3 may be learned by policy, however the MAC in the Extended	carries the MAC address (M3) associated with the TS behind which SN1
	Community is preferred if sent with the route.</t>	sits. M3 may be learned by policy; however, the MAC in the Extended
		Community is preferred if sent with the route.</li>
	</list>	</ul>
	</t>	</li>
		<li>
	<t>DGW1 and DGW2 import the received routes based on the Route Target:	<t>DGW1 and DGW2 import the received routes based on the Route Targe
		t:


	<list style="symbols">	</t>
		<ul spacing="normal">


	<t>The tunnel information to get to ESI23 is installed in DGW1 and	<li>The tunnel information to get to ESI23 is installed in DGW1 an d
	DGW2. For the VXLAN use case, the VTEP will be derived from the	DGW2. For the VXLAN use case, the VTEP will be derived from the

	Ethernet A-D route BGP next-hop and VNI from the VNI/VSID field (see	Ethernet A-D route BGP next hop and VNI from the VNI/VSID field (see
	[RFC8365]).</t>	<xref target="RFC8365"/>).</li>
		<li>The RT-5 coming from the NVE that advertised the RT-1 is
	<t>The RT-5 coming from the NVE that advertised the RT-1 is selected	selected, and SN1/24 is added to the IP-VRF in DGW1 and DGW2 with O
	and SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay Index	verlay Index
	ESI23 and MAC = M2.</t>	ESI23 and MAC = M2.</li>
		</ul>
	</list>	</li>
	</t>	<li>
		<t>When DGW1 receives a packet from the WAN with destination IPx, wh
	<t>When DGW1 receives a packet from the WAN with destination IPx, where IPx	ere IPx
	belongs to SN1/24:	belongs to SN1/24:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>A destination IP lookup is performed on the DGW1 IP-VRF routing	<li>A destination IP lookup is performed on the DGW1 IP-VRF table,
	table and Overlay Index=ESI23 is found. Since ESI23 is an Overlay	and Overlay Index = ESI23 is found. Since ESI23 is an Overlay
	Index, a recursive route resolution is required to find the egress NVE	Index, a recursive route resolution is required to find the egress NVE

	where ESI23 resides.</t>	where ESI23 resides.</li>
		<li>
	<t>The IP packet destined to IPx is encapsulated with:	<t>The IP packet destined to IPx is encapsulated with:

	<list style="symbols">

	<t>Source inner MAC = IRB1 MAC.</t>

	<t>Destination inner MAC = M2 (this MAC will be obtained from the
	Router's MAC Extended Community received along with the RT-5 for
	SN1). Note that the Router's MAC Extended Community is used in this
	case to carry the TS' MAC address, as opposed to the NVE/PE's MAC
	address.</t>

	<t>Tunnel information for the NVO tunnel is provided by the Ethernet
	A-D route per-EVI for ESI23 (VNI and VTEP IP for the VXLAN
	case).</t>

	</list>
	</t>
	</list>
	</t>

	<t>When the packet arrives at NVE2:

	<list style="symbols">


	<t>Based on the tunnel demultiplexer information (VNI for the VXLAN	</t>
	case), the BD-10 context is identified for a MAC lookup (assuming	<ul spacing="normal">
	MAC-based disposition model [RFC7432]) or the VNI may directly identify	<li>Inner source MAC = IRB1 MAC.</li>
	the egress interface (for a MPLS-based disposition model, which in this	<li>Inner destination MAC = M2 (this MAC will be obtained from
	context is a VNI-based disposition model).</t>	the
		EVPN Router's MAC Extended Community received along with the RT-5 for
		SN1). Note that the EVPN Router's MAC Extended Community is used in th
		is
		case to carry the TS's MAC address, as opposed to the MAC
		address of the NVE/PE.</li>
		<li>Tunnel information for the NVO tunnel is provided by the E
		thernet
		A-D route per EVI for ESI23 (VNI and VTEP IP for the VXLAN
		case).</li>
		</ul>
		</li>
		</ul>
		</li>
		<li>
		<t>When the packet arrives at NVE2:


	<t>Encapsulation is stripped off and based on a MAC lookup (assuming MAC	</t>
		<ul spacing="normal">
		<li>Based on the tunnel demultiplexer information (VNI for the VXL
		AN
		case), the BD-10 context is identified for a MAC lookup (assuming a MAC-bas
		ed disposition model <xref target="RFC7432"/>), or the VNI may directly identify
		the egress interface (for an MPLS-based disposition model, which in this
		context is a VNI-based disposition model).</li>
		<li>Encapsulation is stripped off and, based on a MAC lookup (assu
		ming MAC
	forwarding on the egress NVE) or a VNI lookup (in case of VNI	forwarding on the egress NVE) or a VNI lookup (in case of VNI
	forwarding), the packet is forwarded to TS2, where it will be forwarded	forwarding), the packet is forwarded to TS2, where it will be forwarded

	to SN1.</t>	to SN1.</li>
		</ul>
	</list>	</li>
	</t>


	<t>If the redundancy protocol running between TS2 and TS3 follows an	<li>If the redundancy protocol running between TS2 and TS3 follows an
	active/standby model and there is a failure, appointing TS3 as the new active	active/standby model and there is a failure, TS3 is appointed as the new active
	TS for SN1, TS3 will now own the connectivity to SN1 and will signal this new	TS for SN1. TS3 will now own the connectivity to SN1 and will signal this new
	ownership. Upon receiving the new owner's notification, NVE3's AC will become	ownership. Upon receiving the new owner's notification, NVE3's AC will become
	active and issue a route type 1 for ESI23, whereas NVE2 will withdraw its	active and issue a route type 1 for ESI23, whereas NVE2 will withdraw its
	Ethernet A-D route for ESI23. DGW1 and DGW2 will update their tunnel	Ethernet A-D route for ESI23. DGW1 and DGW2 will update their tunnel

	information to resolve ESI23. The destination inner MAC will be changed to	information to resolve ESI23. The inner destination MAC will be changed to
	M3.</t>	M3.</li>
		</ol>
	</list>	</section>
	</t>	<section anchor="sect-4.4" numbered="true" toc="default">
		<name>IP-VRF-to-IP-VRF Model</name>
	</section>	<t>
		This use case is similar to the scenario described in <xref target="RFC9135"
	<section title="IP-VRF-to-IP-VRF Model" anchor="sect-4.4"><t>	sectionFormat="of" section="9.1"/>; however, the new
	This use-case is similar to the scenario described in "IRB forwarding on NVEs	requirement here is the advertisement of IP prefixes as opposed to
	for Tenant Systems" in <xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding
	"/>, however the new
	requirement here is the advertisement of IP Prefixes as opposed to
	only host routes.</t>	only host routes.</t>

		<t>
	<t>	In the examples described in Sections <xref target="sect-4.1" format="counter
	In the examples described in Sections 4.1, 4.2 and 4.3, the BD	"/>, <xref target="sect-4.2" format="counter"/>, and <xref target="sect-4.3" for
		mat="counter"/>, the BD
	instance can connect IRB interfaces and any other Tenant Systems	instance can connect IRB interfaces and any other Tenant Systems
	connected to it. EVPN provides connectivity for:</t>	connected to it. EVPN provides connectivity for:</t>

		<ol spacing="normal" type="1">
	<t><list style="numbers">	<li anchor="step1">Traffic destined to the IRB or TS IP interfaces, as
	<t>Traffic destined to the IRB or TS IP interfaces as well as</t>	well as</li>
		<li anchor="step2">Traffic destined to IP subnets sitting behind the T
	<t>Traffic destined to IP subnets sitting behind the TS, e.g., SN1	S, e.g., SN1
	or SN2.</t>	or SN2.</li>
		</ol>
	</list>	<t>
	</t>	In order to provide connectivity for <xref target="step1" format="none">(1)</
		xref>, MAC/IP Advertisement routes (RT-2) are
	<t>
	In order to provide connectivity for (1), MAC/IP routes (RT-2) are
	needed so that IRB or TS MACs and IPs can be distributed.	needed so that IRB or TS MACs and IPs can be distributed.

	Connectivity type (2) is accomplished by the exchange of IP Prefix	Connectivity type <xref target="step2" format="none">(2)</xref> is accomplish ed by the exchange of IP Prefix
	routes (RT-5) for IPs and subnets sitting behind certain Overlay	routes (RT-5) for IPs and subnets sitting behind certain Overlay

	Indexes, e.g., GW IP or ESI or TS MAC.</t>	Indexes, e.g., GW IP, ESI, or TS MAC.</t>
		<t>
	<t>
	In some cases, IP Prefix routes may be advertised for subnets and IPs	In some cases, IP Prefix routes may be advertised for subnets and IPs

	sitting behind an IRB. This use-case is referred to as the	sitting behind an IRB. This use case is referred to as the
	"IP-VRF-to-IP-VRF" model.</t>	"IP-VRF-to-IP-VRF" model.</t>

		<t>
	<t>	<xref target="RFC9135" format="default"/> defines an asymmetric IRB model and
	<xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> defines an asymme	a symmetric
	tric IRB model and a symmetric	IRB model based on the required lookups at the ingress and egress
	IRB model, based on the required lookups at the ingress and egress	NVE. The asymmetric model requires an IP lookup and a MAC lookup at
	NVE: the asymmetric model requires an IP lookup and a MAC lookup at
	the ingress NVE, whereas only a MAC lookup is needed at the egress	the ingress NVE, whereas only a MAC lookup is needed at the egress

	NVE; the symmetric model requires IP and MAC lookups at both, ingress	NVE; the symmetric model requires IP and MAC lookups at both the ingress
	and egress NVE. From that perspective, the IP-VRF-to-IP-VRF use-case	and egress NVE. From that perspective, the IP-VRF-to-IP-VRF use case
	described in this Section is a symmetric IRB model.</t>	described in this section is a symmetric IRB model.</t>
		<t>
	<t>	Note that in an IP-VRF-to-IP-VRF scenario, out of the many subnets that a
	Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets that a
	tenant may have, it may be the case that only a few are attached to a given	tenant may have, it may be the case that only a few are attached to a given

	NVE/PE's IP-VRF. In order to provide inter-subnet connectivity among the	IP-VRF of the NVE/PE. In order to provide inter-subnet connectivity among the
	set of NVE/PEs where the tenant is connected, a new SBD is created on all	set of NVE/PEs where the tenant is connected, a new SBD is created on all

	of them if recursive resolution is needed. This SBD is instantiated as a	of them if a recursive resolution is needed. This SBD is instantiated as a
	regular BD (with no ACs) in each NVE/PE and has an IRB interface that	regular BD (with no ACs) in each NVE/PE and has an IRB interface that
	connects the SBD to the IP-VRF. The IRB interface's IP or MAC address is	connects the SBD to the IP-VRF. The IRB interface's IP or MAC address is

	used as the overlay index for recursive resolution.</t>	used as the Overlay Index for a recursive resolution.</t>
		<t>
	<t>
	Depending on the existence and characteristics of the SBD and IRB	Depending on the existence and characteristics of the SBD and IRB
	interfaces for the IP-VRFs, there are three different IP-VRF-to-IP-VRF	interfaces for the IP-VRFs, there are three different IP-VRF-to-IP-VRF
	scenarios identified and described in this document:	scenarios identified and described in this document:


	<list style="hanging" hangIndent="3">	</t>
		<ol>
	<t hangText="Interface-less model:">no SBD and no overlay indexes	<li>Interface-less model: no SBD and no Overlay Indexes required.</li>
	required.</t>	<li>Interface-ful with an SBD IRB model: requires SBD as well as GW IP addresses
		as Overlay Indexes.</li>
	<t hangText="Interface-ful with SBD IRB model:"> it requires SBD, as	<li>Interface-ful with an unnumbered SBD IRB model: requires SBD as well as MAC
	well as GW IP addresses as overlay indexes.</t>	addresses as Overlay Indexes.</li>
		</ol>
	<t hangText="Interface-ful with unnumbered SBD IRB model:"> it	<t>
	requires SBD, as well as MAC addresses as overlay indexes.</t>

	</list>
	</t>

	<t>
	Inter-subnet IP multicast is outside the scope of this document.</t>	Inter-subnet IP multicast is outside the scope of this document.</t>

		<section anchor="sect-4.4.1" numbered="true" toc="default">
		<name>Interface-less IP-VRF-to-IP-VRF Model</name>


	<section title="Interface-less IP-VRF-to-IP-VRF Model"	<t><xref target="fig-5"/> depicts the Interface-less IP-VRF-to-IP-VRF
	anchor="sect-4.4.1">	model.</t>
		<figure anchor="fig-5">
	<t>Figure 8 will be used for the description of this model.</t>	<name>Interface-less IP-VRF-to-IP-VRF Model</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure title="Interface-less IP-VRF-to-IP-VRF model" anchor="fig-5">
	<artwork><![CDATA[
	NVE1(M1)	NVE1(M1)
	+------------+	+------------+
	IP1+----\| (BD-1) \| DGW1(M3)	IP1+----\| (BD-1) \| DGW1(M3)
	\| \ \| +---------+ +--------+	\| \ \| +---------+ +--------+
	\| (IP-VRF)\|----\| \|-\|(IP-VRF)\|----+	\| (IP-VRF)\|----\| \|-\|(IP-VRF)\|----+
	\| / \| \| \| +--------+ \|	\| / \| \| \| +--------+ \|
	+---\| (BD-2) \| \| \| _+_	+---\| (BD-2) \| \| \| _+_
	\| +------------+ \| \| ( )	\| +------------+ \| \| ( )
	SN1\| \| VXLAN/ \| ( WAN )--H1	SN1\| \| VXLAN/ \| ( WAN )--H1
	\| NVE2(M2) \| GENEVE/\| (___)	\| NVE2(M2) \| GENEVE/\| (___)
	\| +------------+ \| MPLS \| +	\| +------------+ \| MPLS \| +
	+---\| (BD-2) \| \| \| DGW2(M4) \|	+---\| (BD-2) \| \| \| DGW2(M4) \|
	\| \ \| \| \| +--------+ \|	\| \ \| \| \| +--------+ \|
	\| (IP-VRF)\|----\| \|-\|(IP-VRF)\|----+	\| (IP-VRF)\|----\| \|-\|(IP-VRF)\|----+
	\| / \| +---------+ +--------+	\| / \| +---------+ +--------+
	SN2+----\| (BD-3) \|	SN2+----\| (BD-3) \|
	+------------+	+------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>In this case:
	<t>In this case:

	<list style="format (%c)">


	<t>The NVEs and DGWs must provide connectivity between hosts in SN1,	</t>
	SN2, IP1 and hosts sitting at the other end of the WAN, for example,	<ol spacing="normal" type="%c)">
		<li>The NVEs and DGWs must provide connectivity between hosts in SN1
		,
		SN2, and IP1 and hosts sitting at the other end of the WAN -- for example
		,
	H1. It is assumed that the DGWs import/export IP and/or VPN-IP routes	H1. It is assumed that the DGWs import/export IP and/or VPN-IP routes

	from/to the WAN.</t>	to/from the WAN.</li>
		<li>The IP-VRF instances in the NVE/DGWs are directly connected thro
	<t>The IP-VRF instances in the NVE/DGWs are directly connected through	ugh
	NVO tunnels, and no IRBs and/or BD instances are instantiated to	NVO tunnels, and no IRBs and/or BD instances are instantiated to

	connect the IP-VRFs.</t>	connect the IP-VRFs.</li>
		<li>The solution must provide Layer 3 connectivity among the IP-VRFs
	<t>The solution must provide layer 3 connectivity among the IP-VRFs	for Ethernet NVO tunnels -- for instance, VXLAN or GENEVE.</li>
	for Ethernet NVO tunnels, for instance, VXLAN or GENEVE.</t>	<li>The solution may provide Layer 3 connectivity among the IP-VRFs
		for
	<t>The solution may provide layer 3 connectivity among the IP-VRFs for	IP NVO tunnels -- for example, GENEVE (with IP payload).</li>
	IP NVO tunnels, for example, GENEVE (with IP payload).</t>	</ol>
		<t>
	</list>
	</t>

	<t>
	In order to meet the above requirements, the EVPN route type 5 will be used	In order to meet the above requirements, the EVPN route type 5 will be used

	to advertise the IP Prefixes, along with the Router's MAC Extended	to advertise the IP prefixes, along with the EVPN Router's MAC Extended
	Community as defined in <xref	Community as defined in <xref target="RFC9135" format="default"/> if the adve
	target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/> if the advertising	rtising
	NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will advertise an RT-5 for	NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will advertise an RT-5 for
	each of its prefixes with the following fields:	each of its prefixes with the following fields:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>RD as per <xref target="RFC7432"/>.</t>	<li>RD as per <xref target="RFC7432" format="default"/>.</li>
		<li>Ethernet Tag ID = 0.</li>
	<t>Ethernet Tag ID=0.</t>	<li>IP prefix length and IP address, as explained in the previous
		sections.</li>
	<t>IP Prefix Length and IP address, as explained in the previous	<li>GW IP address = 0.</li>
	Sections.</t>	<li>ESI = 0.</li>
		<li>MPLS label or VNI corresponding to the IP-VRF.</li>
	<t>GW IP address=0.</t>	</ul>
		<t>
	<t>ESI=0</t>

	<t>MPLS label or VNI corresponding to the IP-VRF.</t>

	</list>
	</t>

	<t>
	Each RT-5 will be sent with a Route Target identifying the tenant	Each RT-5 will be sent with a Route Target identifying the tenant
	(IP-VRF) and may be sent with two BGP extended communities:	(IP-VRF) and may be sent with two BGP extended communities:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>The first one is the BGP Encapsulation Extended Community, as per	<li>The first one is the BGP Encapsulation Extended Community, as pe
	<xref target="RFC5512"/>, identifying the tunnel type.</t>	r
		<xref target="RFC9012" format="default"/>, identifying the tunnel type.
	<t>The second one is the Router's MAC Extended Community as per	</li>
	<xref target="I-D.ietf-bess-evpn-inter-subnet-forwarding"/>	<li>The second one is the EVPN Router's MAC Extended Community, as p
	containing the MAC address associated to the NVE advertising the	er
	route. This MAC address identifies the NVE/DGW and MAY be reused for	<xref target="RFC9135" format="default"/>, containing the MAC address a
	all the IP-VRFs in the NVE. The Router's MAC Extended Community must	ssociated with the NVE advertising the
	be sent if the route is associated to an Ethernet NVO tunnel, for	route. This MAC address identifies the NVE/DGW and <bcp14>MAY</bcp14> b
	instance, VXLAN. If the route is associated to an IP NVO tunnel, for	e reused for
	instance GENEVE with IP payload, the Router's MAC Extended Community	all the IP-VRFs in the NVE. The EVPN Router's MAC Extended Community mu
	should not be sent.</t>	st
		be sent if the route is associated with an Ethernet NVO tunnel -- for
	</list>	instance, VXLAN. If the route is associated with an IP NVO tunnel -- fo
	</t>	r
		instance, GENEVE with an IP payload -- the EVPN Router's MAC Extended C
	<t>	ommunity
		should not be sent.</li>
		</ul>
		<t>
	The following example illustrates the procedure to advertise and	The following example illustrates the procedure to advertise and
	forward packets to SN1/24 (IPv4 prefix advertised from NVE1):	forward packets to SN1/24 (IPv4 prefix advertised from NVE1):


	<list style="format (%d)">	</t>
		<ol spacing="normal" type="(%d)">
	<t>NVE1 advertises the following BGP route:	<li>
		<t>NVE1 advertises the following BGP route:
	<list style="symbols">

	<t>Route type 5 (IP Prefix route) containing:

	<list style="symbols">

	<t>IPL=24, IP=SN1, Label=10.</t>

	<t>GW IP= set to 0.</t>

	<t><xref target="RFC5512"/> BGP Encapsulation Extended
	Community.</t>

	<t>Router's MAC Extended Community that contains M1.</t>

	<t>Route Target identifying the tenant (IP-VRF).</t>

	</list>
	</t>
	</list>
	</t>

	<t>DGW1 imports the received routes from NVE1:


	<list style="symbols">	</t>
		<ul spacing="normal">
		<li>
		<t>Route type 5 (IP Prefix route) containing:


	<t>DGW1 installs SN1/24 in the IP-VRF identified by the RT-5	</t>
	Route Target.</t>	<ul spacing="normal">
		<li>IPL = 24, IP = SN1, Label = 10.</li>
		<li>GW IP = set to 0.</li>
		<li> BGP Encapsulation Extended
		Community <xref target="RFC9012" format="default"/>.</li>
		<li>EVPN Router's MAC Extended Community that contains M1.</
		li>
		<li>Route Target identifying the tenant (IP-VRF).</li>
		</ul>
		</li>
		</ul>
		</li>
		<li>
		<t>DGW1 imports the received routes from NVE1:


	<t>Since GW IP=ESI=0, the Label is a non-zero value and the	</t>
	local policy indicates this interface-less model, DGW1 will use	<ul spacing="normal">
	the Label and next-hop of the RT-5, as well as the MAC address	<li>DGW1 installs SN1/24 in the IP-VRF identified by the RT-5
	conveyed in the Router's MAC Extended Community (as inner	Route Target.</li>
		<li>Since GW IP = ESI = 0, the label is a non-zero value, and th
		e
		local policy indicates this interface-less model, DGW1, will use
		the label and next hop of the RT-5, as well as the MAC address
		conveyed in the EVPN Router's MAC Extended Community (as the inner
	destination MAC address) to set up the forwarding state and	destination MAC address) to set up the forwarding state and

	later encapsulate the routed IP packets.</t>	later encapsulate the routed IP packets.</li>
		</ul>
	</list>	</li>
	</t>	<li>
		<t>When DGW1 receives a packet from the WAN with destination IPx,
	<t>When DGW1 receives a packet from the WAN with destination IPx,
	where IPx belongs to SN1/24:	where IPx belongs to SN1/24:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>A destination IP lookup is performed on the DGW1 IP-VRF	<li>A destination IP lookup is performed on the DGW1 IP-VRF
	routing table. The lookup yields SN1/24.</t>	table. The lookup yields SN1/24.</li>
		<li>Since the RT-5 for SN1/24 had a GW IP = ESI = 0, a non-zero
	<t>Since the RT-5 for SN1/24 had a GW IP=ESI=0, a non-zero	label, and a next hop, and since the model is interface-less, DGW1
	Label and next-hop and the model is interface-less, DGW1 will	will
	not need a recursive lookup to resolve the route.</t>	not need a recursive lookup to resolve the route.</li>
		<li>The IP packet destined to IPx is encapsulated with: inner so
	<t>The IP packet destined to IPx is encapsulated with: Source	urce MAC = DGW1 MAC, inner destination MAC = M1, outer source
	inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer	IP (tunnel source IP) = DGW1 IP, and outer destination IP (tunnel
	IP (tunnel source IP) = DGW1 IP, Destination outer IP (tunnel	destination IP) = NVE1 IP. The source and inner destination MAC
	destination IP) = NVE1 IP. The Source and Destination inner MAC	addresses are not needed if IP NVO tunnels are used.</li>
	addresses are not needed if IP NVO tunnels are used.</t>	</ul>
		</li>
	</list>	<li>
	</t>	<t>When the packet arrives at NVE1:

	<t>When the packet arrives at NVE1:

	<list style="symbols">

	<t>NVE1 will identify the IP-VRF for an IP lookup based on the
	Label (the Destination inner MAC is not needed to identify the
	IP-VRF).</t>


	<t>An IP lookup is performed in the routing context, where SN1	</t>
	turns out to be a local subnet associated to BD-2. A subsequent	<ul spacing="normal">
		<li>NVE1 will identify the IP-VRF for an IP lookup based on the
		label (the inner destination MAC is not needed to identify the
		IP-VRF).</li>
		<li>An IP lookup is performed in the routing context, where SN1
		turns out to be a local subnet associated with BD-2. A subsequent
	lookup in the ARP table and the BD FIB will provide the	lookup in the ARP table and the BD FIB will provide the

	forwarding information for the packet in BD-2.</t>	forwarding information for the packet in BD-2.</li>
		</ul>
	</list>	</li>
	</t>	</ol>
		<t>
	</list>	The model described above is called an "interface-less" model since the
	</t>	IP-VRFs are connected directly through tunnels, and they don't require
		those tunnels to be terminated in SBDs instead, as in Sections <xref target="
	<t>	sect-4.4.2" format="counter"/> or <xref target="sect-4.4.3" format="counter"/>.<
	The model described above is called Interface-less model since the	/t>
	IP-VRFs are connected directly through tunnels and they don't require	</section>
	those tunnels to be terminated in SBDs instead, as in Sections 4.4.2	<section anchor="sect-4.4.2" numbered="true" toc="default">
	or 4.4.3.</t>	<name>Interface-ful IP-VRF-to-IP-VRF with SBD IRB</name>
		<t><xref target="fig-6"/> depicts the Interface-ful IP-VRF-to-IP-VRF w
	</section>	ith SBD IRB model.</t>
		<figure anchor="fig-6">
	<section title="Interface-ful IP-VRF-to-IP-VRF with SBD IRB"	<name>Interface-ful with SBD IRB Model</name>
	anchor="sect-4.4.2">	<artwork name="" type="" align="left" alt=""><![CDATA[

	<t>Figure 9 will be used for the description of this model.</t>

	<figure title="Interface-ful with SBD IRB model" anchor="fig-6">
	<artwork><![CDATA[
	NVE1	NVE1
	+------------+ DGW1	+------------+ DGW1
	IP10+---+(BD-1) \| +---------------+ +------------+	IP10+---+(BD-1) \| +---------------+ +------------+
	\| \ \| \| \| \| \|	\| \ \| \| \| \| \|
	\|(IP-VRF)-(SBD)\| \|(SBD)-(IP-VRF)\|-----+	\|(IP-VRF)-(SBD)\| \|(SBD)-(IP-VRF)\|-----+

	\| / IRB(IP1/M1) IRB(IP3/M3) \| \|	\| / IRB(M1/IP1) IRB(M3/IP3) \| \|
	+---+(BD-2) \| \| \| +------------+ _+_	+---+(BD-2) \| \| \| +------------+ _+_
	\| +------------+ \| \| ( )	\| +------------+ \| \| ( )
	SN1\| \| VXLAN/ \| ( WAN )--H1	SN1\| \| VXLAN/ \| ( WAN )--H1
	\| NVE2 \| GENEVE/ \| (___)	\| NVE2 \| GENEVE/ \| (___)
	\| +------------+ \| MPLS \| DGW2 +	\| +------------+ \| MPLS \| DGW2 +
	+---+(BD-2) \| \| \| +------------+ \|	+---+(BD-2) \| \| \| +------------+ \|
	\| \ \| \| \| \| \| \|	\| \ \| \| \| \| \| \|
	\|(IP-VRF)-(SBD)\| \|(SBD)-(IP-VRF)\|-----+	\|(IP-VRF)-(SBD)\| \|(SBD)-(IP-VRF)\|-----+

	\| / IRB(IP2/M2) IRB(IP4/M4) \|	\| / IRB(M2/IP2) IRB(M4/IP4) \|
	SN2+----+(BD-3) \| +---------------+ +------------+	SN2+----+(BD-3) \| +---------------+ +------------+
	+------------+	+------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>In this model:
	<t>In this model:

	<list style="format (%c)">

	<t>As in Section 4.4.1, the NVEs and DGWs must provide connectivity
	between hosts in SN1, SN2, IP10 and hosts sitting at the other end
	of the WAN.</t>


	<t>However, the NVE/DGWs are now connected through Ethernet NVO	</t>
		<ol spacing="normal" type="%c)">
		<li>As in <xref target="sect-4.4.1"/>, the NVEs and DGWs must provid
		e connectivity
		between hosts in SN1, SN2, and IP10 and in hosts sitting at the other e
		nd
		of the WAN.</li>
		<li>However, the NVE/DGWs are now connected through Ethernet NVO
	tunnels terminated in the SBD instance. The IP-VRFs use IRB	tunnels terminated in the SBD instance. The IP-VRFs use IRB

	interfaces for their connectivity to the SBD.</t>	interfaces for their connectivity to the SBD.</li>
		<li>Each SBD IRB has an IP and a MAC address, where the IP address
	<t>Each SBD IRB has an IP and a MAC address, where the IP address	must be reachable from other NVEs or DGWs.</li>
	must be reachable from other NVEs or DGWs.</t>	<li>The SBD is attached to all the NVE/DGWs in the tenant domain BDs
		.</li>
	<t>The SBD is attached to all the NVE/DGWs in the tenant domain BDs.</t	<li>The solution must provide Layer 3 connectivity for Ethernet NVO
	>	tunnels -- for instance, VXLAN or GENEVE (with Ethernet payload).</li>
		</ol>
	<t>The solution must provide layer 3 connectivity for Ethernet NVO	<t>
	tunnels, for instance, VXLAN or GENEVE (with Ethernet payload).</t>	EVPN type 5 routes will be used to advertise the IP prefixes, whereas

	</list>
	</t>

	<t>
	EVPN type 5 routes will be used to advertise the IP Prefixes, whereas
	EVPN RT-2 routes will advertise the MAC/IP addresses of each SBD IRB	EVPN RT-2 routes will advertise the MAC/IP addresses of each SBD IRB
	interface. Each NVE/DGW will advertise an RT-5 for each of its	interface. Each NVE/DGW will advertise an RT-5 for each of its
	prefixes with the following fields:	prefixes with the following fields:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>RD as per <xref target="RFC7432"/>.</t>	<li>RD as per <xref target="RFC7432" format="default"/>.</li>
		<li>Ethernet Tag ID = 0.</li>
	<t>Ethernet Tag ID=0.</t>	<li>IP prefix length and IP address, as explained in the previous
		sections.</li>
	<t>IP Prefix Length and IP address, as explained in the previous	<li>GW IP address = IRB-IP of the SBD (this is the Overlay Index tha
	Sections.</t>	t
		will be used for the recursive route resolution).</li>
	<t>GW IP address=IRB-IP of the SBD (this is the Overlay Index that	<li>ESI = 0.</li>
	will be used for the recursive route resolution).</t>	<li>Label value should be zero since the RT-5 route requires a

	<t>ESI=0</t>

	<t>Label value should be zero since the RT-5 route requires a
	recursive lookup resolution to an RT-2 route. It is ignored on	recursive lookup resolution to an RT-2 route. It is ignored on

	reception, and, when forwarding packets, the MPLS label or VNI from	reception, and the MPLS label or VNI from
	the RT-2's MPLS Label1 field is used.</t>	the RT-2's MPLS Label1 field is used when forwarding packets.</li>
		</ul>
	</list>	<t>
	</t>

	<t>
	Each RT-5 will be sent with a Route Target identifying the tenant	Each RT-5 will be sent with a Route Target identifying the tenant

	(IP-VRF). The Router's MAC Extended Community should not be sent in	(IP-VRF). The EVPN Router's MAC Extended Community should not be sent in
	this case.</t>	this case.</t>

		<t>
	<t>
	The following example illustrates the procedure to advertise and	The following example illustrates the procedure to advertise and
	forward packets to SN1/24 (IPv4 prefix advertised from NVE1):	forward packets to SN1/24 (IPv4 prefix advertised from NVE1):


	<list style="format (%d)">	</t>
		<ol spacing="normal" type="(%d)">
	<t>NVE1 advertises the following BGP routes:	<li>
		<t>NVE1 advertises the following BGP routes:
	<list style="symbols">

	<t>Route type 5 (IP Prefix route) containing:

	<list style="symbols">

	<t>IPL=24, IP=SN1, Label= SHOULD be set to 0.</t>

	<t>GW IP=IP1 (SBD IRB's IP)</t>

	<t>Route Target identifying the tenant (IP-VRF).</t>

	</list>
	</t>

	<t>Route type 2 (MAC/IP route for the SBD IRB) containing:

	<list style="symbols">

	<t>ML=48, M=M1, IPL=32, IP=IP1, Label=10.</t>

	<t>A <xref target="RFC5512"/> BGP Encapsulation Extended Community.</t>

	<t>Route Target identifying the SBD. This Route Target may be the
	same as the one used with the RT-5.</t>

	</list>
	</t>


	</list>	</t>
	</t>	<ul spacing="normal">
		<li>
		<t>Route type 5 (IP Prefix route) containing:


	<t>DGW1 imports the received routes from NVE1:	</t>
		<ul spacing="normal">
		<li>IPL = 24, IP = SN1, Label = <bcp14>SHOULD</bcp14> be set
		to 0.</li>
		<li>GW IP = IP1 (SBD IRB's IP).</li>
		<li>Route Target identifying the tenant (IP-VRF).</li>
		</ul>
		</li>
		<li>
		<t>Route type 2 (MAC/IP Advertisement route for the SBD IRB) c
		ontaining:


	<list style="symbols">	</t>
		<ul spacing="normal">
		<li>ML = 48, M = M1, IPL = 32, IP = IP1, Label = 10.</li>
		<li>A BGP Encapsulation Extended Community <xref target="RFC
		9012" format="default"/>.</li>
		<li>Route Target identifying the SBD. This Route Target may
		be the
		same as the one used with the RT-5.</li>
		</ul>
		</li>
		</ul>
		</li>
		<li>
		<t>DGW1 imports the received routes from NVE1:


	<t>DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route	</t>
		<ul spacing="normal">
		<li>
		<t>DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 R
		oute
	Target.	Target.


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>Since GW IP is different from zero, the GW IP (IP1) will be	<li>Since GW IP is different from zero, the GW IP (IP1) will
		be
	used as the Overlay Index for the recursive route resolution to	used as the Overlay Index for the recursive route resolution to

	the RT-2 carrying IP1.</t>	the RT-2 carrying IP1.</li>
		</ul>
	</list>	</li>
	</t>	</ul>
		</li>
	</list>	<li>
	</t>	<t>When DGW1 receives a packet from the WAN with destination IPx,

	<t>When DGW1 receives a packet from the WAN with destination IPx,
	where IPx belongs to SN1/24:	where IPx belongs to SN1/24:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>A destination IP lookup is performed on the DGW1 IP-VRF	<li>A destination IP lookup is performed on the DGW1 IP-VRF
	routing table. The lookup yields SN1/24, which is associated to	table. The lookup yields SN1/24, which is associated with
	the Overlay Index IP1. The forwarding information is derived from	the Overlay Index IP1. The forwarding information is derived from

	the RT-2 received for IP1.</t>	the RT-2 received for IP1.</li>
		<li>The IP packet destined to IPx is encapsulated with: inner so
	<t>The IP packet destined to IPx is encapsulated with: Source	urce MAC = M3, inner destination MAC = M1, outer source IP
	inner MAC = M3, Destination inner MAC = M1, Source outer IP	(source VTEP) = DGW1 IP, and outer destination IP (destination VTEP)
	(source VTEP) = DGW1 IP, Destination outer IP (destination VTEP)	= NVE1 IP.</li>
	= IP1.</t>	</ul>
		</li>
	</list>	<li>
	</t>	<t>When the packet arrives at NVE1:

	<t>When the packet arrives at NVE1:

	<list style="symbols">

	<t>NVE1 will identify the IP-VRF for an IP lookup based on the
	Label and the inner MAC DA.</t>


	<t>An IP lookup is performed in the routing context, where SN1	</t>
	turns out to be a local subnet associated to BD-2. A subsequent	<ul spacing="normal">
		<li>NVE1 will identify the IP-VRF for an IP lookup based on the
		label and the inner MAC DA.</li>
		<li>An IP lookup is performed in the routing context, where SN1
		turns out to be a local subnet associated with BD-2. A subsequent
	lookup in the ARP table and the BD FIB will provide the	lookup in the ARP table and the BD FIB will provide the

	forwarding information for the packet in BD-2.</t>	forwarding information for the packet in BD-2.</li>
		</ul>
	</list>	</li>
	</t>	</ol>
		<t>
	</list>	The model described above is called an "interface-ful with SBD IRB" model bec
	</t>	ause the tunnels connecting the DGWs and NVEs need to be

	<t>
	The model described above is called 'Interface-ful with SBD IRB
	model' because the tunnels connecting the DGWs and NVEs need to be
	terminated into the SBD. The SBD is connected to the IP-VRFs via SBD	terminated into the SBD. The SBD is connected to the IP-VRFs via SBD
	IRB interfaces, and that allows the recursive resolution of RT-5s to	IRB interfaces, and that allows the recursive resolution of RT-5s to
	GW IP addresses.</t>	GW IP addresses.</t>

		</section>
	</section>	<section anchor="sect-4.4.3" numbered="true" toc="default">
		<name>Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB</name>
	<section title="Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB" a	<t>
	nchor="sect-4.4.3"><t>	<xref target="fig-7"/> depicts the Interface-ful IP-VRF-to-IP-VRF with unnumbere
	Figure 10 will be used for the description of this model. Note that	d SBD IRB model. Note that this model is similar to the one described in <xref t
	this model is similar to the one described in <xref target="sect-4.4.2"/>, on	arget="sect-4.4.2" format="default"/>, only
	ly
	without IP addresses on the SBD IRB interfaces.</t>	without IP addresses on the SBD IRB interfaces.</t>

		<figure anchor="fig-7">
	<figure title="Interface-ful with unnumbered SBD IRB model" anchor="fig-7	<name>Interface-ful with Unnumbered SBD IRB Model</name>
	">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	NVE1	NVE1
	+------------+ DGW1	+------------+ DGW1
	IP1+----+(BD-1) \| +---------------+ +------------+	IP1+----+(BD-1) \| +---------------+ +------------+
	\| \ \| \| \| \| \|	\| \ \| \| \| \| \|
	\|(IP-VRF)-(SBD)\| (SBD)-(IP-VRF) \|-----+	\|(IP-VRF)-(SBD)\| (SBD)-(IP-VRF) \|-----+
	\| / IRB(M1)\| \| IRB(M3) \| \|	\| / IRB(M1)\| \| IRB(M3) \| \|
	+---+(BD-2) \| \| \| +------------+ _+_	+---+(BD-2) \| \| \| +------------+ _+_
	\| +------------+ \| \| ( )	\| +------------+ \| \| ( )
	SN1\| \| VXLAN/ \| ( WAN )--H1	SN1\| \| VXLAN/ \| ( WAN )--H1
	\| NVE2 \| GENEVE/ \| (___)	\| NVE2 \| GENEVE/ \| (___)
	\| +------------+ \| MPLS \| DGW2 +	\| +------------+ \| MPLS \| DGW2 +
	+---+(BD-2) \| \| \| +------------+ \|	+---+(BD-2) \| \| \| +------------+ \|
	\| \ \| \| \| \| \| \|	\| \ \| \| \| \| \| \|
	\|(IP-VRF)-(SBD)\| (SBD)-(IP-VRF) \|-----+	\|(IP-VRF)-(SBD)\| (SBD)-(IP-VRF) \|-----+
	\| / IRB(M2)\| \| IRB(M4) \|	\| / IRB(M2)\| \| IRB(M4) \|
	SN2+----+(BD-3) \| +---------------+ +------------+	SN2+----+(BD-3) \| +---------------+ +------------+
	+------------+	+------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>In this model:
	<t>In this model:

	<list style="format (%c)">

	<t>As in Section 4.4.1 and 4.4.2, the NVEs and DGWs must provide
	connectivity between hosts in SN1, SN2, IP1 and hosts sitting at the
	other end of the WAN.</t>


	<t>As in Section 4.4.2, the NVE/DGWs are connected through Ethernet	</t>
		<ol spacing="normal" type="%c)">
		<li>As in Sections <xref target="sect-4.4.1" format="counter"/> and
		<xref target="sect-4.4.2" format="counter"/>, the NVEs and DGWs must provide
		connectivity between hosts in SN1, SN2, and IP1 and in hosts sitting at t
		he
		other end of the WAN.</li>
		<li>As in <xref target="sect-4.4.2"/>, the NVE/DGWs are connected th
		rough Ethernet
	NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB	NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB

	interfaces for their connectivity to the SBD.</t>	interfaces for their connectivity to the SBD.</li>
		<li>However, each SBD IRB has a MAC address only and no IP address
	<t>However, each SBD IRB has a MAC address only, and no IP address	(which is why the model refers to an "unnumbered" SBD IRB). In this
	(that is why the model refers to an 'unnumbered' SBD IRB). In this
	model, there is no need to have IP reachability to the SBD IRB	model, there is no need to have IP reachability to the SBD IRB

	interfaces themselves and there is a requirement to limit the number	interfaces themselves, and there is a requirement to limit the number
	of IP addresses used.</t>	of IP addresses used.</li>
		<li>As in <xref target="sect-4.4.2"/>, the SBD is composed of all th
	<t>As in Section 4.4.2, the SBD is composed of all the NVE/DGW BDs of	e NVE/DGW BDs of
	the tenant that need inter-subnet-forwarding.</t>	the tenant that need inter-subnet forwarding.</li>
		<li>As in <xref target="sect-4.4.2"/>, the solution must provide Lay
	<t>As in Section 4.4.2, the solution must provide layer 3 connectivity	er 3 connectivity
	for Ethernet NVO tunnels, for instance, VXLAN or GENEVE (with Ethernet	for Ethernet NVO tunnels -- for instance, VXLAN or GENEVE (with Ethernet
	payload).</t>	payload).</li>
		</ol>
	</list>	<t>
	</t>

	<t>
	This model will also make use of the RT-5 recursive resolution. EVPN	This model will also make use of the RT-5 recursive resolution. EVPN

	type 5 routes will advertise the IP Prefixes along with the Router's	type 5 routes will advertise the IP prefixes along with the EVPN Router's
	MAC Extended Community used for the recursive lookup, whereas EVPN	MAC Extended Community used for the recursive lookup, whereas EVPN
	RT-2 routes will advertise the MAC addresses of each SBD IRB	RT-2 routes will advertise the MAC addresses of each SBD IRB
	interface (this time without an IP).</t>	interface (this time without an IP).</t>

		<t>
	<t>
	Each NVE/DGW will advertise an RT-5 for each of its prefixes with the	Each NVE/DGW will advertise an RT-5 for each of its prefixes with the

	same fields as described in 4.4.2 except for:	same fields as described in <xref target="sect-4.4.2"/>, except:

	<list style="symbols">

	<t>GW IP address= set to 0.</t>

	</list>
	</t>


	<t>	</t>
		<ul spacing="normal">
		<li>GW IP address = set to 0.</li>
		</ul>
		<t>
	Each RT-5 will be sent with a Route Target identifying the tenant	Each RT-5 will be sent with a Route Target identifying the tenant

	(IP-VRF) and the Router's MAC Extended Community containing the MAC	(IP-VRF) and the EVPN Router's MAC Extended Community containing the MAC
	address associated to SBD IRB interface. This MAC address may be	address associated with the SBD IRB interface. This MAC address may be
	reused for all the IP-VRFs in the NVE.</t>	reused for all the IP-VRFs in the NVE.</t>

		<t>
		The example is similar to the one in <xref target="sect-4.4.2"/>:


	<t>	</t>
	The example is similar to the one in Section 4.4.2:	<ol spacing="normal" type="(%d)">
		<li>
	<list style="format (%d)">	<t>NVE1 advertises the following BGP routes:

	<t>NVE1 advertises the following BGP routes:

	<list style="symbols">

	<t>Route type 5 (IP Prefix route) containing the same values as
	in the example in <xref target="sect-4.4.2"/>, except for:

	<list style="symbols">

	<t>GW IP= SHOULD be set to 0.</t>

	<t>Router's MAC Extended Community containing M1 (this will be used
	for the recursive lookup to a RT-2).</t>

	</list>
	</t>

	<t>Route type 2 (MAC route for the SBD IRB) with the same values
	as in <xref target="sect-4.4.2"/> except for:

	<list style="symbols">

	<t>ML=48, M=M1, IPL=0, Label=10.</t>

	</list>
	</t>


	</list>	</t>
	</t>	<ul spacing="normal">
		<li>
		<t>Route type 5 (IP Prefix route) containing the same values a
		s
		in the example in <xref target="sect-4.4.2" format="default"/>, except
		:


	<t>DGW1 imports the received routes from NVE1:	</t>
		<ul spacing="normal">
		<li>GW IP = <bcp14>SHOULD</bcp14> be set to 0.</li>
		<li>EVPN Router's MAC Extended Community containing M1 (this
		will be used
		for the recursive lookup to an RT-2).</li>
		</ul>
		</li>
		<li>
		<t>Route type 2 (MAC route for the SBD IRB) with the same valu
		es
		as in <xref target="sect-4.4.2" format="default"/>, except:


	<list style="symbols">	</t>
		<ul spacing="normal">
		<li>ML = 48, M = M1, IPL = 0, Label = 10.</li>
		</ul>
		</li>
		</ul>
		</li>
		<li>
		<t>DGW1 imports the received routes from NVE1:


	<t>DGW1 installs SN1/24 in the IP-VRF identified by the RT-5	</t>
		<ul spacing="normal">
		<li>
		<t>DGW1 installs SN1/24 in the IP-VRF identified by the RT-5
	Route Target.	Route Target.


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>The MAC contained in the Router's MAC Extended Community sent	<li>The MAC contained in the EVPN Router's MAC Extended Comm
		unity sent
	along with the RT-5 (M1) will be used as the Overlay Index for the	along with the RT-5 (M1) will be used as the Overlay Index for the

	recursive route resolution to the RT-2 carrying M1.</t>	recursive route resolution to the RT-2 carrying M1.</li>
		</ul>
	</list>	</li>
	</t>	</ul>
		</li>
	</list>	<li>
	</t>	<t>When DGW1 receives a packet from the WAN with destination IPx,

	<t>When DGW1 receives a packet from the WAN with destination IPx,
	where IPx belongs to SN1/24:	where IPx belongs to SN1/24:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>A destination IP lookup is performed on the DGW1 IP-VRF	<li>A destination IP lookup is performed on the DGW1 IP-VRF
	routing table. The lookup yields SN1/24, which is associated to	table. The lookup yields SN1/24, which is associated with
	the Overlay Index M1. The forwarding information is derived from	the Overlay Index M1. The forwarding information is derived from

	the RT-2 received for M1.</t>	the RT-2 received for M1.</li>
		<li>The IP packet destined to IPx is encapsulated with: inner so
	<t>The IP packet destined to IPx is encapsulated with: Source	urce MAC = M3, inner destination MAC = M1, outer source IP
	inner MAC = M3, Destination inner MAC = M1, Source outer IP	(source VTEP) = DGW1 IP, and outer destination IP (destination VTEP
	(source VTEP) = DGW1 IP, Destination outer IP (destination VTEP)	)
	= NVE1 IP.</t>	= NVE1 IP.</li>
		</ul>
	</list>	</li>
	</t>	<li>
		<t>When the packet arrives at NVE1:
	<t>When the packet arrives at NVE1:

	<list style="symbols">

	<t>NVE1 will identify the IP-VRF for an IP lookup based on the
	Label and the inner MAC DA.</t>


	<t>An IP lookup is performed in the routing context, where SN1	</t>
	turns out to be a local subnet associated to BD-2. A subsequent	<ul spacing="normal">
		<li>NVE1 will identify the IP-VRF for an IP lookup based on the
		label and the inner MAC DA.</li>
		<li>An IP lookup is performed in the routing context, where SN1
		turns out to be a local subnet associated with BD-2. A subsequent
	lookup in the ARP table and the BD FIB will provide the	lookup in the ARP table and the BD FIB will provide the

	forwarding information for the packet in BD-2.</t>	forwarding information for the packet in BD-2.</li>
		</ul>
	</list>	</li>
	</t>	</ol>
		<t>
	</list>	The model described above is called an "interface-ful with unnumbered SBD
	</t>	IRB" model (as in <xref target="sect-4.4.2" format="default"/>) but without t
		he SBD IRB having an IP address.</t>
	<t>	</section>
	The model described above is called Interface-ful with unnumbered SBD	</section>
	IRB model (as in <xref target="sect-4.4.2"/>), only this time the SBD IRB doe	</section>
	s not	<section anchor="sect-5" numbered="true" toc="default">
	have an IP address.</t>	<name>Security Considerations</name>
		<t>
	</section>	This document provides a set of procedures to achieve inter-subnet
		forwarding across NVEs or PEs attached to a group of BDs that belong
	</section>

	</section>

	<section title="Security Considerations" anchor="sect-5"><t>
	This document provides a set of procedures to achieve Inter-Subnet
	Forwarding across NVEs or PEs attached to a group of BDs that belong
	to the same tenant (or VPN). The security considerations discussed in	to the same tenant (or VPN). The security considerations discussed in

	<xref target="RFC7432"/> apply to the Intra-Subnet Forwarding or communicatio n	<xref target="RFC7432" format="default"/> apply to the intra-subnet forwardin g or communication
	within each of those BDs. In addition, the security considerations in	within each of those BDs. In addition, the security considerations in

	<xref target="RFC4364"/> should also be understood, since this document and	<xref target="RFC4364" format="default"/> should also be understood, since th
	<xref target="RFC4364"/> may be used in similar applications.</t>	is document and
		<xref target="RFC4364" format="default"/> may be used in similar applications
	<t>	.</t>
	Contrary to <xref target="RFC4364"/>, this document does not describe PE/CE r	<t>
	oute	Contrary to <xref target="RFC4364" format="default"/>, this document does not
	distribution techniques, but rather considers the CEs as TSes or VAs	describe PE/CE route
		distribution techniques but rather considers the CEs as TSs or VAs
	that do not run dynamic routing protocols. This can be considered a	that do not run dynamic routing protocols. This can be considered a
	security advantage, since dynamic routing protocols can be blocked on	security advantage, since dynamic routing protocols can be blocked on
	the NVE/PE ACs, not allowing the tenant to interact with the	the NVE/PE ACs, not allowing the tenant to interact with the
	infrastructure's dynamic routing protocols.</t>	infrastructure's dynamic routing protocols.</t>

		<t>
	<t>	In this document, the RT-5 may use a regular BGP next hop for its
	In this document, the RT-5 may use a regular BGP Next Hop for its
	resolution or an Overlay Index that requires a recursive resolution	resolution or an Overlay Index that requires a recursive resolution
	to a different EVPN route (an RT-2 or an RT-1). In the latter case,	to a different EVPN route (an RT-2 or an RT-1). In the latter case,
	it is worth noting that any action that ends up filtering or	it is worth noting that any action that ends up filtering or

	modifying the RT-2/RT-1 routes used to convey the Overlay Indexes,	modifying the RT-2 or RT-1 routes used to convey the Overlay Indexes
	will modify the resolution of the RT-5 and therefore the forwarding	will modify the resolution of the RT-5 and therefore the forwarding
	of packets to the remote subnet.</t>	of packets to the remote subnet.</t>

		</section>
		<section anchor="sect-6" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>
		IANA has registered value 5 in the "EVPN Route Types" registry <xref target="
		EVPNRouteTypes" format="default"/>
		defined by <xref target="RFC7432" format="default"/> as follows:</t>


	</section>	<table>
		<thead>
	<section title="IANA Considerations" anchor="sect-6"><t>	<tr>
	This document requests value 5 in the <xref target="EVPNRouteTypes"/> registr	<th>Value</th>
	y	<th>Description</th>
	defined by <xref target="RFC7432"/>:</t>	<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>5</td>
		<td>IP Prefix</td>
		<td>RFC 9136</td>
		</tr>
		</tbody>
		</table>


	<figure><artwork><![CDATA[	</section>
	Value Description Reference	</middle>
	5 IP Prefix route [this document]	<back>
	]]></artwork>	<references>
	</figure>	<name>References</name>
	</section>	<references>
		<name>Normative References</name>


	</middle>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7432.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.9012.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.2119.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8174.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8365.xml"/>


	<back>	<reference anchor='RFC9135' target='https://www.rfc-editor.org/info/rfc9135'>
	<references title="Normative References">	<front>
	&RFC7432;	<title>Integrated Routing and Bridging in Ethernet VPN (EVPN)</title>
	&RFC5512;	<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
	&RFC2119;	<organization />
	&RFC8174;	</author>
	&RFC8365;
	&I-D.ietf-bess-evpn-inter-subnet-forwarding;
	<reference anchor="EVPNRouteTypes" target="https://www.iana.org/assignmen
	ts/evpn"><front>
	<title>EVPN Route Type registry</title>
	<author>
	<organization>IANA</organization>
	</author>


	<date/>	<author initials='S' surname='Salam' fullname='Samer Salam'>
	</front>	<organization />
		</author>


	</reference>	<author initials='S' surname='Thoria' fullname='Samir Thoria'>
	</references>	<organization />
	<references title="Informative References">	</author>
	&RFC4364;
	&RFC7606;
	<reference anchor="IEEE-802.1D-REV"><front>
	<title>IEEE Standard for Local and metropolitan area networks - Media Acc
	ess Control (MAC) Bridges</title>
	<author>
	</author>


	<date month="June" year="2004"/>	<author initials='J' surname='Drake' fullname='John Drake'>
	</front>	<organization />
		</author>


	<seriesInfo name="IEEE" value="Std. 802.1D"/>	<author initials='J' surname='Rabadan' fullname='Jorge Rabadan'>
	</reference>	<organization />
		</author>
		<date month='October' year='2021' />
		</front>
		<seriesInfo name="RFC" value="9135"/>
		<seriesInfo name="DOI" value="10.17487/RFC9135"/>
		</reference>


	<reference anchor="IEEE-802.1Q"><front>	<reference anchor="EVPNRouteTypes" target="https://www.iana.org/assignme
	<title>"IEEE Standard for Local and metropolitan area networks -	nts/evpn">
	Media Access Control (MAC) Bridges and Virtual Bridged Local Area	<front>
	Networks"</title>	<title>EVPN Route Types</title>
	<author>	<author>
		<organization>IANA</organization>
		</author>
		<date/>
		</front>
		</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4364.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		7606.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5798.xml"/>
		<reference anchor="IEEE-802.1Q" target="https://standards.ieee.org/stand
		ard/802_1Q-2018.html">
		<front>
		<title>IEEE Standard for Local and Metropolitan Area Networks -- Bri
		dges and Bridged Networks</title>
		<seriesInfo name="IEEE Std" value="802.1Q"/>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
		<author><organization>IEEE</organization>
	</author>	</author>

	<date month="November" year="2014"/>	<date month="July" year="2018"/>
	</front>	</front>
	<seriesInfo name="IEEE" value="Std 802.1Q(tm)"/>	</reference>
	</reference>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	&RFC7365;	ence.RFC.7365.xml"/>
	&RFC5227;	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	&RFC7348;	ence.RFC.5227.xml"/>
	&I-D.ietf-nvo3-geneve;	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	</references>	ence.RFC.7348.xml"/>
	<section title="Acknowledgments" anchor="sect-8"><t>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	The authors would like to thank Mukul Katiyar and Jeffrey Zhang for	ence.RFC.8926.xml"/>
	their valuable feedback and contributions. The following people also
	helped improving this document with their feedback: Tony Przygienda
	and Thomas Morin. Special THANK YOU to Eric Rosen for his detailed
	review, it really helped improve the readability and clarify the
	concepts. Thank you to Alvaro Retana for his thorough review.</t>

	</section>


	<section title="Contributors" anchor="sect-9"><t>	</references>
		</references>
		<section anchor="sect-8" numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>
		The authors would like to thank <contact fullname="Mukul Katiyar"/>, <contact
		fullname="Jeffrey Zhang"/>, and <contact fullname="Alex Nichol"/> for
		their valuable feedback and contributions. <contact fullname="Tony Przygienda
		"/>
		and <contact fullname="Thomas Morin"/> also helped improve this document with
		their feedback. Special thanks to <contact fullname="Eric Rosen"/> for his deta
		iled
		review, which really helped improve the readability and clarify the
		concepts. We also thank <contact fullname="Alvaro Retana"/> for his thorough
		review.</t>
		</section>
		<section anchor="sect-9" numbered="false" toc="default">
		<name>Contributors</name>
		<t>
	In addition to the authors listed on the front page, the following	In addition to the authors listed on the front page, the following

	co-authors have also contributed to this document:</t>	coauthors have also contributed to this document:</t>

	<figure><artwork><![CDATA[
	Senthil Sathappan
	Florin Balus
	Aldrin Isaac
	Senad Palislamovic
	Samir Thoria
	]]></artwork>
	</figure>
	</section>

	<section title="Authors' Addresses" anchor="sect-10"/>


	</back>	<ul empty="true" spacing="compact">
		<li><t><contact fullname="Senthil Sathappan"/></t></li>
		<li><t><contact fullname="Florin Balus"/></t></li>
		<li><t> <contact fullname="Aldrin Isaac"/></t></li>
		<li><t> <contact fullname="Senad Palislamovic"/></t></li>
		<li><t> <contact fullname="Samir Thoria"/></t></li>
		</ul>
		</section>


	</rfc>	</back>
		</rfc>

End of changes. 251 change blocks.
	1601 lines changed or deleted	1663 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/