Diff: rfc9135xml2.original.xml

	rfc9135xml2.original.xml	rfc9135.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY I-D.ietf-bess-evpn-prefix-advertisement SYSTEM "https://xml2rfc.ietf.or
	g/public/rfc/bibxml3/reference.I-D.draft-ietf-bess-evpn-prefix-advertisement-11.
	xml">
	<!ENTITY I-D.ietf-idr-tunnel-encaps SYSTEM "https://xml2rfc.ietf.org/public/rfc/
	bibxml3/reference.I-D.draft-ietf-idr-tunnel-encaps-22.xml">
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2119.xml">
	<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4364.xml">
	<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7348.xml">
	<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7432.xml">
	<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7606.xml">
	<!ENTITY RFC7637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7637.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-irb-extended-mobility SYSTEM "https://xml2rfc.ietf.o
	rg/public/rfc/bibxml3/reference.I-D.draft-ietf-bess-evpn-irb-extended-mobility-0
	3.xml">
	<!ENTITY I-D.ietf-nvo3-vxlan-gpe SYSTEM "https://xml2rfc.ietf.org/public/rfc/bib
	xml3/reference.I-D.draft-ietf-nvo3-vxlan-gpe-10.xml">
	<!ENTITY RFC4365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4365.xml">
	<!ENTITY RFC5798 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5798.xml">
	<!ENTITY RFC7365 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7365.xml">
	]>
	<rfc submissionType="IETF" docName="draft-ietf-bess-evpn-inter-subnet-forwarding
	-15" category="std" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2021-08-06T22:40:56Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc toc="yes"?>
	<front>
	<title>Integrated Routing and Bridging in EVPN</title>
	<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
	<organization>Cisco Systems</organization>
	<address><email>sajassi@cisco.com</email>
	</address>
	</author>


	<author initials="S." surname="Salam" fullname="Samer Salam">	<!DOCTYPE rfc [
	<organization>Cisco Systems</organization>	<!ENTITY nbsp " ">
	<address><email>ssalam@cisco.com</email>	<!ENTITY zwsp "">
	</address>	<!ENTITY nbhy "‑">
	</author>	<!ENTITY wj "⁠">
		]>


	<author initials="S." surname="Thoria" fullname="Samir Thoria">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-evpn-in
	<organization>Cisco Systems</organization>	ter-subnet-forwarding-15" number="9135" submissionType="IETF" category="std" con
	<address><email>sthoria@cisco.com</email>	sensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="t
	</address>	rue" sortRefs="true" tocInclude="true" version="3">
	</author>


	<author initials="J." surname="Drake" fullname="John E Drake">	<front>
	<organization>Juniper</organization>
	<address><email>jdrake@juniper.net</email>
	</address>
	</author>


	<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">	<title abbrev="IRB EVPN">Integrated Routing and Bridging in Ethernet VPN (EV
	<organization>Nokia</organization>	PN)</title>
	<address><email>jorge.rabadan@nokia.com</email>	<seriesInfo name="RFC" value="9135"/>
	</address>	<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
	</author>	<organization>Cisco Systems</organization>
		<address>
		<email>sajassi@cisco.com</email>
		</address>
		</author>
		<author initials="S." surname="Salam" fullname="Samer Salam">
		<organization>Cisco Systems</organization>
		<address>
		<email>ssalam@cisco.com</email>
		</address>
		</author>
		<author initials="S." surname="Thoria" fullname="Samir Thoria">
		<organization>Cisco Systems</organization>
		<address>
		<email>sthoria@cisco.com</email>
		</address>
		</author>
		<author initials="J." surname="Drake" fullname="John E Drake">
		<organization>Juniper</organization>
		<address>
		<email>jdrake@juniper.net</email>
		</address>
		</author>
		<author initials="J." surname="Rabadan" fullname="Jorge Rabadan">
		<organization>Nokia</organization>
		<address>
		<email>jorge.rabadan@nokia.com</email>
		</address>
		</author>
		<date year="2021" month="October"/>
		<workgroup>BESS WorkGroup</workgroup>


	<date year="2021" month="August"/>	<keyword>IRB</keyword>
	<workgroup>BESS WorkGroup</workgroup>	<keyword>inter-subnet-forwarding</keyword>
	<abstract><t>	<keyword>symmetric</keyword>
	Ethernet VPN (EVPN) provides an extensible and flexible multi-homing	<keyword>asymmetric</keyword>
		<keyword>mobility</keyword>
		<abstract>
		<t>
		Ethernet VPN (EVPN) provides an extensible and flexible multihoming
	VPN solution over an MPLS/IP network for intra-subnet connectivity	VPN solution over an MPLS/IP network for intra-subnet connectivity

	among Tenant Systems and End Devices that can be physical or virtual.	among Tenant Systems and end devices that can be physical or virtual.
	However, there are scenarios for which there is a need for a dynamic	However, there are scenarios for which there is a need for a dynamic
	and efficient inter-subnet connectivity among these Tenant Systems	and efficient inter-subnet connectivity among these Tenant Systems

	and End Devices while maintaining the multi-homing capabilities of	and end devices while maintaining the multihoming capabilities of
	EVPN. This document describes an Integrated Routing and Bridging	EVPN. This document describes an Integrated Routing and Bridging
	(IRB) solution based on EVPN to address such requirements.</t>	(IRB) solution based on EVPN to address such requirements.</t>

		</abstract>
	</abstract>	</front>
	</front>	<middle>
		<section anchor="intro" numbered="true" toc="default">
	<middle>	<name>Introduction</name>
	<section title="Terminology" anchor="sect-1"><t>	<t>
	AC: Attachment Circuit</t>	EVPN <xref target="RFC7432" format="default"/> provides an extensible and fle
		xible multihoming VPN
	<t>
	ARP: Address Resolution Protocol</t>

	<t>
	ARP table: A logical view of a forwarding table on a PE that
	maintains an IP to MAC binding entry on an IP interface for both IPv4
	and IPv6. These entries are learned through ARP/ND or through EVPN.</t>

	<t>
	Broadcast Domain: As per <xref target="RFC7432"/>, an EVI consists of a singl
	e or multiple
	broadcast domains. In the case of VLAN-bundle and VLAN-based service
	models (see <xref target="RFC7432"/>), a broadcast domain is equivalent to an
	EVI. In the
	case of VLAN-aware bundle service model, an EVI contains multiple broadcast
	domains. Also, in this document, broadcast domain and subnet are
	equivalent terms and wherever "subnet" is used, it means "IP subnet"</t>

	<t>
	Broadcast Domain Route Target: refers to the Broadcast Domain
	assigned Route Target <xref target="RFC4364"/>. In the case of VLAN-aware bu
	ndle
	service model, all the broadcast domain instances in the MAC-VRF
	share the same Route Target</t>

	<t>
	Bridge Table: The instantiation of a broadcast domain in a MAC-VRF,
	as per <xref target="RFC7432"/>.</t>

	<t>
	Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels
	with Ethernet payload as specified for VxLAN in <xref target="RFC7348"/> and
	for
	NVGRE in <xref target="RFC7637"/>.</t>

	<t>
	EVI: EVPN Instance spanning the NVE/PE devices that are participating
	on that EVPN, as per <xref target="RFC7432"/>.</t>

	<t>
	EVPN: Ethernet Virtual Private Networks, as per <xref target="RFC7432"/>.</t>

	<t>
	IP NVO tunnel: it refers to Network Virtualization Overlay tunnels
	with IP payload (no MAC header in the payload) as specified for GPE
	in <xref target="I-D.ietf-nvo3-vxlan-gpe"/>.</t>

	<t>
	IP-VRF: A Virtual Routing and Forwarding table for IP 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 3 VPN in an
	NVE/PE.</t>

	<t>
	IRB: Integrated Routing and Bridging interface. It connects an IP-VRF to a
	broadcast domain (or subnet).</t>

	<t>
	MAC-VRF: A Virtual Routing and Forwarding table for Media Access
	Control (MAC) addresses on an NVE/PE, as per <xref target="RFC7432"/>. A MAC
	-VRF is
	also an instantiation of an EVI in an NVE/PE.</t>

	<t>
	ND: Neighbor Discovery Protocol</t>

	<t>
	NVE: Network Virtualization Edge</t>

	<t>
	NVGRE: Network Virtualization Generic Routing Encapsulation,
	<xref target="RFC7637"/></t>

	<t>
	NVO: Network Virtualization Overlays</t>

	<t>
	RT-2: EVPN route type 2, i.e., MAC/IP Advertisement route, as defined
	in <xref target="RFC7432"/></t>

	<t>
	RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in
	Section 3 of <xref target="I-D.ietf-bess-evpn-prefix-advertisement"/></t>

	<t>
	TS: Tenant System</t>

	<t>
	VA: Virtual Appliance</t>

	<t>
	VNI: Virtual Network Identifier. As in <xref target="RFC8365"/>, the term is
	used
	as a representation of a 24-bit NVO instance identifier, with the
	understanding that VNI will refer to a VXLAN Network Identifier in
	VXLAN, or Virtual Subnet Identifier in NVGRE, etc. unless it is
	stated otherwise.</t>

	<t>
	VTEP: VXLAN Termination End Point, as in <xref target="RFC7348"/>.</t>

	<t>
	VXLAN: Virtual Extensible LAN, as in <xref target="RFC7348"/>.</t>

	<t>
	This document also assumes familiarity with the terminology of
	<xref target="RFC7432"/>, <xref target="RFC8365"/> and <xref target="RFC7365"
	/>.</t>

	<section title="Requirements Language" anchor="sect-1.1"><t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 <xref target="RFC2119"/> and RFC 8174 <xref target="RFC8174"/> when, and
	only when, they
	appear in all capitals, as shown here.</t>

	</section>

	</section>

	<section title="Introduction" anchor="sect-2"><t>
	EVPN <xref target="RFC7432"/> provides an extensible and flexible multi-homin
	g VPN
	solution over an MPLS/IP network for intra-subnet connectivity among	solution over an MPLS/IP network for intra-subnet connectivity among

	Tenant Systems (TSes) and End Devices that can be physical or	Tenant Systems (TSs) and end devices that can be physical or
	virtual; where an IP subnet is represented by an EVPN Instance (EVI)	virtual, where an IP subnet is represented by an EVPN instance (EVI)
	for a VLAN-based service or by an (EVI, VLAN) for a VLAN-aware bundle	for a VLAN-based service or by an (EVI, VLAN) association for a VLAN-aware bu
		ndle
	service. However, there are scenarios for which there is a need for	service. However, there are scenarios for which there is a need for
	a dynamic and efficient inter-subnet connectivity among these Tenant	a dynamic and efficient inter-subnet connectivity among these Tenant

	Systems and End Devices while maintaining the multi-homing	Systems and end devices while maintaining the multihoming
	capabilities of EVPN. This document describes an Integrated Routing	capabilities of EVPN. This document describes an Integrated Routing
	and Bridging (IRB) solution based on EVPN to address such	and Bridging (IRB) solution based on EVPN to address such
	requirements.</t>	requirements.</t>

		<t>
	<t>	Inter-subnet communication is typically performed by centralized Layer 3 (L3)
	The inter-subnet communication is traditionally achieved at	gateway (GW) devices, which enforce all inter-subnet communication policies
	centralized L3 Gateway (L3GW) devices where all the inter-subnet	and perform all inter-subnet forwarding. When two TSs belonging to two different
	forwarding is performed and all the inter-subnet communication	subnets connected to the same Provider Edge (PE) wanted to communicate with e
	policies are enforced. When two TSes belonging to two different	ach
	subnets connected to the same PE wanted to communicate with each
	other, their traffic needed to be backhauled from the PE all the way	other, their traffic needed to be backhauled from the PE all the way
	to the centralized gateway where inter-subnet switching is performed	to the centralized gateway where inter-subnet switching is performed

	and then back to the PE. For today's large multi-tenant data center,	and then sent back to the PE. For today's large multi-tenant Data Center (DC ),
	this scheme is very inefficient and sometimes impractical.</t>	this scheme is very inefficient and sometimes impractical.</t>

		<t>
	<t>	In order to overcome the drawback of the centralized L3 GW
	In order to overcome the drawback of the centralized layer-3 GW
	approach, IRB functionality is needed on the PEs (also referred to as	approach, IRB functionality is needed on the PEs (also referred to as

	EVPN NVEs) attached to TSes in order to avoid inefficient forwarding	EVPN Network Virtualization Edges (NVEs)) attached to TSs in order to avoid i
	of tenant traffic (i.e., avoid back-hauling and hair-pinning). When	nefficient forwarding
		of tenant traffic (i.e., avoid backhauling and hair pinning). When
	a PE with IRB capability receives tenant traffic over an Attachment	a PE with IRB capability receives tenant traffic over an Attachment

	Circuit (AC), it can not only locally bridge the tenant intra-subnet	Circuit (AC), it cannot only locally bridge the tenant intra-subnet
	traffic but also can locally route the tenant inter-subnet traffic on	traffic but also locally route the tenant inter-subnet traffic on
	a packet by packet basis thus meeting the requirements for both intra	a packet-by-packet basis, thus meeting the requirements for both intra-
	and inter-subnet forwarding and avoiding non-optimal traffic	and inter-subnet forwarding and avoiding non-optimal traffic

	forwarding associated with centralized layer-3 GW approach.</t>	forwarding associated with a centralized L3 GW approach.</t>
		<t>
	<t>	Some TSs run non-IP protocols in conjunction with their IP traffic.
	Some TSes run non-IP protocols in conjunction with their IP traffic.	Therefore, it is important to handle both kinds of traffic optimally --
	Therefore, it is important to handle both kinds of traffic optimally -
	e.g., to bridge non-IP and intra-subnet traffic and to route inter-subnet	e.g., to bridge non-IP and intra-subnet traffic and to route inter-subnet
	IP traffic. Therefore, the solution needs to meet the following	IP traffic. Therefore, the solution needs to meet the following
	requirements:</t>	requirements:</t>

		<dl>
	<t>	<dt>R1:</dt><dd> The solution must provide each tenant with IP routing of its
	R1: The solution must provide each tenant with IP routing of its
	inter-subnet traffic and Ethernet bridging of its intra-subnet	inter-subnet traffic and Ethernet bridging of its intra-subnet
	traffic and non-routable traffic, where non-routable traffic refers	traffic and non-routable traffic, where non-routable traffic refers

	both to non-IP traffic and IP traffic whose version differs from the	to both non-IP traffic and IP traffic whose version differs from the
	IP version configured in the IP-VRF. For example, if an IP-VRF in a	IP version configured in IP Virtual Routing and Forwarding (IP-VRF). For exa
		mple, if an IP-VRF in an
	NVE is configured for IPv6 and that NVE receives IPv4 traffic on the	NVE is configured for IPv6 and that NVE receives IPv4 traffic on the
	corresponding VLAN, then the IPv4 traffic is treated as non-routable	corresponding VLAN, then the IPv4 traffic is treated as non-routable

	traffic.</t>	traffic.</dd>
		<dt>
	<t>	R2:</dt><dd> The solution must allow IP routing of inter-subnet traffic to be
	R2: The solution must allow IP routing of inter-subnet traffic to be
	disabled on a per-VLAN basis on those PEs that are backhauling that	disabled on a per-VLAN basis on those PEs that are backhauling that

	traffic to another PE for routing.</t>	traffic to another PE for routing.</dd></dl>
		</section>
	</section>	<section anchor="terms" numbered="true" toc="default">
		<name>Terminology</name>
		<dl indent="10">
		<dt>AC:</dt><dd>Attachment Circuit</dd>
		<dt>ARP:</dt><dd>Address Resolution Protocol</dd>
		<dt>ARP Table:</dt><dd> A logical view of a forwarding table on a PE that
		maintains an IP to a MAC binding entry on an IP interface for both IPv4
		and IPv6. These entries are learned through ARP/ND or through EVPN.</dd>
		<dt>BD:</dt><dd>Broadcast Domain. As per <xref target="RFC7432" format="default"
		/>, an EVI consists of a single BD or multiple
		BDs. In the case of VLAN-bundle and VLAN-based service
		models (see <xref target="RFC7432" format="default"/>), a BD is equivalent to
		an EVI. In the
		case of a VLAN-aware bundle service model, an EVI contains multiple BDs. Als
		o, in this document, "BD" and "subnet" are
		equivalent terms, and wherever "subnet" is used, it means "IP subnet".</dd>
		<dt>BD Route Target:</dt><dd>Refers to the broadcast-domain-assigned Route Targe
		t <xref target="RFC4364" format="default"/>. In the case of a VLAN-aware bundle
		service model, all the BD instances in the MAC-VRF
		share the same Route Target.</dd>


	<section title="EVPN PE Model for IRB Operation" anchor="sect-3"><t>	<dt>BT:</dt><dd>Bridge Table. The instantiation of a BD in a MAC-VRF,
		as per <xref target="RFC7432" format="default"/>.</dd>
		<dt>CE:</dt><dd>Customer Edge</dd>
		<dt>DA:</dt><dd>Destination Address</dd>
		<dt>Ethernet NVO Tunnel:</dt><dd>Refers to Network Virtualization Overlay tunnel
		s
		with an Ethernet payload, as specified for VXLAN in <xref target="RFC7348" fo
		rmat="default"/> and for
		NVGRE in <xref target="RFC7637" format="default"/>.</dd>
		<dt>EVI:</dt><dd>EVPN Instance spanning NVE/PE devices that are participating
		on that EVPN, as per <xref target="RFC7432" format="default"/>.</dd>
		<dt>EVPN:</dt><dd>Ethernet VPN, as per <xref target="RFC7432" format="default"/>
		.</dd>
		<dt>IP NVO Tunnel:</dt><dd>Refers to Network Virtualization Overlay tunnels
		with IP payload (no MAC header in the payload) as specified for Generic Proto
		col Extension (GPE)
		in <xref target="I-D.ietf-nvo3-vxlan-gpe" format="default"/>.</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 IP-VPN address
		families. An IP-VRF is also an instantiation of a Layer 3 VPN in an
		NVE/PE.</dd>
		<dt>IRB:</dt><dd>Integrated Routing and Bridging interface. It connects an IP-V
		RF to a
		BD (or subnet).</dd>
		<dt>MAC:</dt><dd>Media Access Control</dd>
		<dt>MAC-VRF:</dt><dd>A Virtual Routing and Forwarding table for
		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 NVE/PE.</dd>
		<dt>ND:</dt><dd>Neighbor Discovery</dd>
		<dt>NVE:</dt><dd>Network Virtualization Edge</dd>
		<dt>NVGRE:</dt><dd>Network Virtualization Using Generic Routing Encapsulation, a
		s per
		<xref target="RFC7637" format="default"/>.</dd>
		<dt>NVO:</dt><dd>Network Virtualization Overlay</dd>
		<dt>PE:</dt><dd>Provider Edge</dd>
		<dt>RT-2:</dt><dd>EVPN Route Type 2, i.e., MAC/IP Advertisement route, as define
		d
		in <xref target="RFC7432" format="default"/>.</dd>
		<dt>RT-5:</dt><dd>EVPN Route Type 5, i.e., IP Prefix route, as defined in <xr
		ef target="RFC9136" sectionFormat="of" section="3"/>.</dd>
		<dt>SA:</dt><dd>Source Address</dd>
		<dt>TS:</dt><dd>Tenant System</dd>
		<dt>VA:</dt><dd>Virtual Appliance</dd>
		<dt>VNI:</dt><dd>Virtual Network Identifier. As in <xref target="RFC8365" forma
		t="default"/>, the term is used
		as a representation of a 24-bit NVO instance identifier, with the
		understanding that "VNI" will refer to a VXLAN Network Identifier in
		VXLAN, or a Virtual Subnet Identifier in NVGRE, etc., unless it is
		stated otherwise.</dd>
		<dt>VTEP:</dt><dd>VXLAN Termination End Point, as per <xref target="RFC7348" for
		mat="default"/>.</dd>
		<dt>VXLAN:</dt><dd>Virtual eXtensible Local Area Network, as per <xref target="R
		FC7348" format="default"/>.</dd>
		</dl>
		<t>
		This document also assumes familiarity with the terminology of <xref target="
		RFC7365" format="default"/>, <xref target="RFC7432" format="default"/>, and <xre
		f target="RFC8365" format="default"/>.</t>
		<section anchor="sect-1.1" numbered="true" toc="default">
		<name>Requirements Language</name>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		</section>
		</section>
		<section anchor="sect-3" numbered="true" toc="default">
		<name>EVPN PE Model for IRB Operation</name>
		<t>
	Since this document discusses IRB operation in relationship to EVPN	Since this document discusses IRB operation in relationship to EVPN

	MAC-VRF, IP-VRF, EVI, Broadcast Domain, Bridge Table, and IRB	MAC-VRF, IP-VRF, EVI, BD, bridge table, and IRB
	interfaces, it is important to understand the relationship between	interfaces, it is important to understand the relationship between

	these components. Therefore, the following PE model is illustrated	these components. Therefore, the PE model is illustrated
	below to a) describe these components and b) illustrate the	below to a) describe these components and b) illustrate the
	relationship among them.</t>	relationship among them.</t>

		<figure anchor="fig-1">
	<figure title="EVPN IRB PE Model" anchor="fig-1"><artwork><![CDATA[	<name>EVPN IRB PE Model</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+-------------------------------------------------------------+	+-------------------------------------------------------------+
	\| \|	\| \|
	\| +------------------+ IRB PE \|	\| +------------------+ IRB PE \|
	\| Attachment \| +------------------+ \|	\| Attachment \| +------------------+ \|
	\| Circuit(AC1) \| \| +----------+ \| MPLS/NVO tnl	\| Circuit(AC1) \| \| +----------+ \| MPLS/NVO tnl
	----------------------*Bridge \| \| +-----	----------------------*Bridge \| \| +-----
	\| \| \| \|Table(BT1)\| \| +-----------+ / \ \	\| \| \| \|Table(BT1)\| \| +-----------+ / \ \
	\| \| \| \| --------- \|<--> \|Eth\|	\| \| \| \| --------- \|<--> \|Eth\|
	\| \| \| \| VLAN x \| \|IRB1\| \| \ / /	\| \| \| \| VLAN x \| \|IRB1\| \| \ / /
	\| \| \| +----------+ \| \| \| +-----	\| \| \| +----------+ \| \| \| +-----

	skipping to change at line 285 ¶	skipping to change at line 229 ¶
	\| \| \| \| --------- \|<--> \|IP \|	\| \| \| \| --------- \|<--> \|IP \|
	----------------------* VLAN y \| \| +-----------+ \ / /	----------------------* VLAN y \| \| +-----------+ \ / /
	\| AC2 \| \| +----------+ \| +-----	\| AC2 \| \| +----------+ \| +-----
	\| \| \| MAC-VRF1 \| \|	\| \| \| MAC-VRF1 \| \|
	\| +-+ RD1/RT1 \| \|	\| +-+ RD1/RT1 \| \|
	\| +------------------+ \|	\| +------------------+ \|
	\| \|	\| \|
	\| \|	\| \|
	+-------------------------------------------------------------+	+-------------------------------------------------------------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	A tenant needing IRB services on a PE, requires an IP Virtual Routing and	A tenant needing IRB services on a PE requires an IP-VRF table along with one
	Forwarding table (IP-VRF) along with one or more MAC Virtual Routing and	or more MAC-VRF tables. An IP-VRF, as defined in <xref target="RFC4364" format
	Forwarding tables (MAC-VRFs). An IP-VRF, as defined in <xref target="RFC4364	="default"/>, is the
	"/>, is the	instantiation of an IP-VPN instance in a PE. A MAC-VRF, as defined in
	instantiation of an IPVPN instance in a PE. A MAC-VRF, as defined in	<xref target="RFC7432" format="default"/>, is the instantiation of an EVI in
	<xref target="RFC7432"/>, is the instantiation of an EVI (EVPN Instance) in a	a PE. A
	PE. A
	MAC-VRF consists of one or more bridge tables, where each bridge table	MAC-VRF consists of one or more bridge tables, where each bridge table
	corresponds to a VLAN (broadcast domain). If service interfaces for an	corresponds to a VLAN (broadcast domain). If service interfaces for an

	EVPN PE are configured in VLAN-Based mode (i.e., section 6.1 of RFC7432),	EVPN PE are configured in VLAN-based mode (i.e., <xref target="RFC7432" secti
	then there is only a single bridge table per MAC-VRF (per EVI) - i.e.,	onFormat="of" section="6.1"/>),
		then there is only a single bridge table per MAC-VRF (per EVI) -- i.e.,
	there is only one tenant VLAN per EVI. However, if service interfaces for	there is only one tenant VLAN per EVI. However, if service interfaces for

	an EVPN PE are configured in VLAN-Aware Bundle mode (i.e., section 6.3 of	an EVPN PE are configured in VLAN-aware bundle mode (i.e., <xref target="RFC7
	RFC7432), then there are several bridge tables per MAC-VRF (per EVI) -	432" sectionFormat="of" section="6.3"/>), then there are several bridge tables p
		er MAC-VRF (per EVI) --
	i.e., there are several tenant VLANs per EVI.</t>	i.e., there are several tenant VLANs per EVI.</t>

		<t>
	<t>
	Each bridge table is connected to an IP-VRF via an L3 interface	Each bridge table is connected to an IP-VRF via an L3 interface

	called IRB interface. Since a single tenant subnet is typically (and	called an "IRB interface". Since a single tenant subnet is typically (and
	in this document) represented by a VLAN (and thus supported by a	in this document) represented by a VLAN (and thus supported by a

	single bridge table), for a given tenant there are as many bridge	single bridge table), for a given tenant, there are as many bridge
	tables as there are subnets and thus there are also as many IRB	tables as there are subnets. Thus, there are also as many IRB
	interfaces between the tenant IP-VRF and the associated bridge tables	interfaces between the tenant IP-VRF and the associated bridge tables
	as shown in the PE model above.</t>	as shown in the PE model above.</t>

		<t>
	<t>	IP-VRF is identified by its corresponding Route Target and Route
	IP-VRF is identified by its corresponding route target and route	Distinguisher, and MAC-VRF is also identified by its corresponding Route
	distinguisher and MAC-VRF is also identified by its corresponding route	Target and Route Distinguisher. If operating in EVPN VLAN-based mode, then
	target and route distinguisher. If operating in EVPN VLAN-Based mode, then	a receiving PE that receives an EVPN route with a MAC-VRF Route Target can
	a receiving PE that receives an EVPN route with MAC- VRF route target can
	identify the corresponding bridge table; however, if operating in EVPN	identify the corresponding bridge table; however, if operating in EVPN

	VLAN-Aware Bundle mode, then the receiving PE needs both the MAC-VRF route	VLAN-aware bundle mode, then the receiving PE needs both the MAC-VRF Route
	target and VLAN ID in order to identify the corresponding bridge table.</t>	Target and VLAN ID in order to identify the corresponding bridge table.</t>
		</section>
	</section>	<section anchor="sect-4" numbered="true" toc="default">
		<name>Symmetric and Asymmetric IRB</name>
	<section title="Symmetric and Asymmetric IRB" anchor="sect-4"><t>	<t>
	This document defines and describes two types of IRB solutions -	This document defines and describes two types of IRB solutions --
	namely symmetric and asymmetric IRB. The description of symmetric	namely, symmetric and asymmetric IRB. The description of symmetric
	and asymmetric IRB procedures relating to data path operations and	and asymmetric IRB procedures relating to data path operations and
	tables in this document is a logical view of data path lookups and	tables in this document is a logical view of data path lookups and
	related tables. Actual implementations, while following this logical	related tables. Actual implementations, while following this logical

	view, may not strictly adhere to it for performance tradeoffs.	view, may not strictly adhere to it for performance trade-offs.
	Specifically,</t>	Specifically,</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>References to ARP table in the context of asy	<li>References to an ARP table in the context of asymmetric IRB is a
	mmetric IRB is a	logical view of a forwarding table that maintains an IP-to-MAC
	logical view of a forwarding table that maintains an IP to MAC	binding entry on a Layer 3 interface for both IPv4 and IPv6.
	binding entry on a layer 3 interface for both IPv4 and IPv6.	These entries are not subject to ARP or ND protocols. For IP-to-MAC bindi
	These entries are not subject to ARP or ND protocol. For IP to	ngs learned via EVPN, an implementation may choose to
	MAC bindings learnt via EVPN, an implementation may choose to
	import these bindings directly to the respective forwarding table	import these bindings directly to the respective forwarding table
	(such as an adjacency/next-hop table) as opposed to importing them	(such as an adjacency/next-hop table) as opposed to importing them

	to ARP or ND protocol tables.</t>	to ARP or ND protocol tables.</li>
		<li>References to a host IP lookup followed by a host MAC lookup in the
	<t>References to host IP lookup followed by a host MAC lookup in the	context of asymmetric IRB <bcp14>MAY</bcp14> be collapsed into a single IP
	context of asymmetric IRB MAY be collapsed into a single IP lookup	lookup
	in a hardware implementation.</t>	in a hardware implementation.</li>
		</ul>
	</list>	<t>
	</t>	In symmetric IRB, as its name implies, the lookup operation is
		symmetric at both the ingress and egress PEs -- i.e., both ingress and
	<t>
	In symmetric IRB as its name implies, the lookup operation is
	symmetric at both ingress and egress PEs - i.e., both ingress and
	egress PEs perform lookups on both MAC and IP addresses. The ingress	egress PEs perform lookups on both MAC and IP addresses. The ingress

	PE performs a MAC lookup followed by an IP lookup and the egress PE	PE performs a MAC lookup followed by an IP lookup, and the egress PE
	performs an IP lookup followed by a MAC lookup as depicted in the	performs an IP lookup followed by a MAC lookup, as depicted in the
	following figure.</t>	following figure.</t>

		<figure anchor="fig-2">
	<figure title="Symmetric IRB" anchor="fig2"><artwork><![CDATA[	<name>Symmetric IRB</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Ingress PE Egress PE	Ingress PE Egress PE
	+-------------------+ +------------------+	+-------------------+ +------------------+
	\| \| \| \|	\| \| \| \|
	\| +-> IP-VRF ----\|---->---\|-----> IP-VRF -+ \|	\| +-> IP-VRF ----\|---->---\|-----> IP-VRF -+ \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| BT1 BT2 \| \| BT3 BT2 \|	\| BT1 BT2 \| \| BT3 BT2 \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| ^ \| \| v \|	\| ^ \| \| v \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	+-------------------+ +------------------+	+-------------------+ +------------------+
	^ \|	^ \|
	\| \|	\| \|
	TS1->-+ +->-TS2	TS1->-+ +->-TS2
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	In symmetric IRB as shown in figure-2, the inter-subnet forwarding	In symmetric IRB, as shown in <xref target="fig-2"/>, the inter-subnet forwar
		ding
	between two PEs is done between their associated IP-VRFs. Therefore,	between two PEs is done between their associated IP-VRFs. Therefore,

	the tunnel connecting these IP-VRFs can be either IP-only tunnel	the tunnel connecting these IP-VRFs can be either an IP-only tunnel
	(e.g., in case of MPLS or GPE encapsulation) or Ethernet NVO tunnel	(e.g., in the case of MPLS or GPE encapsulation) or an Ethernet NVO tunnel
	(e.g., in case of VxLAN encapsulation). If it is an Ethernet NVO	(e.g., in the case of VXLAN encapsulation). If it is an Ethernet NVO
	tunnel, the TS1's IP packet is encapsulated in an Ethernet header	tunnel, the TS1's IP packet is encapsulated in an Ethernet header

	consisting of ingress and egress PEs MAC addresses - i.e., there is	consisting of ingress and egress PE MAC addresses -- i.e., there is
	no need for ingress PE to use the destination TS2's MAC address.	no need for the ingress PE to use the destination TS2's MAC address.

	Therefore, in symmetric IRB, there is no need for the ingress PE to	Therefore, in symmetric IRB, there is no need for the ingress PE to

	maintain ARP entries for destination TS2's IP and MAC addresses	maintain ARP entries for the association of the destination TS2's IP and MAC
	association in its ARP table. Each PE participating in symmetric IRB	addresses in its ARP table.
	only maintains ARP entries for locally connected hosts and maintains
	MAC-VRFs/bridge tables for only locally configured subnets.</t>


	<t>	Each PE participating in symmetric IRB
		only maintains ARP entries for locally connected hosts and
		MAC-VRFs/BTs for only locally configured subnets.</t>
		<t>
	In asymmetric IRB, the lookup operation is asymmetric and the ingress	In asymmetric IRB, the lookup operation is asymmetric and the ingress

	PE performs three lookups; whereas the egress PE performs a single	PE performs three lookups, whereas the egress PE performs a single
	lookup - i.e., the ingress PE performs a MAC lookup, followed by an	lookup -- i.e., the ingress PE performs a MAC lookup, followed by an
	IP lookup, followed by a MAC lookup again; whereas, the egress PE	IP lookup, followed by a MAC lookup again. The egress PE
	performs just a single MAC lookup as depicted in figure 3 below.</t>	performs just a single MAC lookup as depicted in <xref target="fig-3"/> below
		.</t>
	<figure title="Asymmetric IRB" anchor="fig-3"><artwork><![CDATA[	<figure anchor="fig-3">
		<name>Asymmetric IRB</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Ingress PE Egress PE	Ingress PE Egress PE
	+-------------------+ +------------------+	+-------------------+ +------------------+
	\| \| \| \|	\| \| \| \|
	\| +-> IP-VRF -> \| \| IP-VRF \|	\| +-> IP-VRF -> \| \| IP-VRF \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| BT1 BT2 \| \| BT3 BT2 \|	\| BT1 BT2 \| \| BT3 BT2 \|
	\| \| \| \| \| \| \| \|	\| \| \| \| \| \| \| \|
	\| \| +--\|--->----\|--------------+ \| \|	\| \| +--\|--->----\|--------------+ \| \|
	\| \| \| \| v \|	\| \| \| \| v \|
	+-------------------+ +----------------\|-+	+-------------------+ +----------------\|-+
	^ \|	^ \|
	\| \|	\| \|
	TS1->-+ +->-TS2	TS1->-+ +->-TS2
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	In asymmetric IRB as shown in figure-3, the inter-subnet forwarding between	In asymmetric IRB, as shown in <xref target="fig-3"/>, the inter-subnet forwa
	two PEs is done between their associated MAC-VRFs/bridge tables.	rding between
	Therefore, the MPLS or NVO tunnel used for inter-subnet forwarding MUST be	two PEs is done between their associated MAC-VRFs/BTs.
	of type Ethernet. Since only MAC lookup is performed at the egress PE	Therefore, the MPLS or NVO tunnel used for inter-subnet forwarding <bcp14>MUS
		T</bcp14> be
		of type Ethernet.

		Since only MAC lookup is performed at the egress PE
	(e.g., no IP lookup), the TS1's IP packets need to be encapsulated with the	(e.g., no IP lookup), the TS1's IP packets need to be encapsulated with the

	destination TS2's MAC address. In order for ingress PE to perform such	destination TS2's MAC address. In order for the ingress PE to perform such
	encapsulation, it needs to maintain TS2's IP and MAC address association in	encapsulation, it needs to maintain TS2's IP and MAC address association in
	its ARP table. Furthermore, it needs to maintain destination TS2's MAC	its ARP table. Furthermore, it needs to maintain destination TS2's MAC
	address in the corresponding bridge table even though it may not have any	address in the corresponding bridge table even though it may not have any

	TSes of the corresponding subnet locally attached. In other words, each PE	TSs of the corresponding subnet locally attached. In other words, each PE
	participating in asymmetric IRB MUST maintain ARP entries for remote hosts	participating in asymmetric IRB <bcp14>MUST</bcp14> maintain ARP entries for
	(hosts connected to other PEs) as well as maintain MAC-VRFs/bridge tables	remote hosts
	and IRB interfaces for ALL subnets in an IP VRF including subnets that may	(hosts connected to other PEs) as well as maintain MAC-VRFs/BTs
	not be locally attached. Therefore, careful consideration of PE scale	and IRB interfaces for ALL subnets in an IP-VRF, including subnets that may
	aspects for its ARP table size, its IRB interfaces, number and size of its	not be locally attached. Therefore, careful consideration of the PE scale
		aspects for its ARP table size, its IRB interfaces, and the number and size o
		f its
	bridge tables should be given for the application of asymmetric IRB.</t>	bridge tables should be given for the application of asymmetric IRB.</t>

		<t>
	<t>
	It should be noted that whenever a PE performs a host IP lookup for a	It should be noted that whenever a PE performs a host IP lookup for a

	packet that is routed, IPv4 TTL or IPv6 hop limit for that packet is	packet that is routed, the IPv4 Time To Live (TTL) or IPv6 hop limit for that
	decremented by one and if it reaches zero, the packet is discarded.	packet is
	In the case of symmetric IRB, the TTL/hop limit is decremented by	decremented by one, and if it reaches zero, the packet is discarded.
	both ingress and egress PEs (once by each); whereas, in the case of	In the case of symmetric IRB, the TTL / hop limit is decremented by
	asymmetric IRB, the TTL/hop limit is decremented only once by the	both ingress and egress PEs (once by each), whereas in the case of
		asymmetric IRB, the TTL / hop limit is decremented only once by the
	ingress PE.</t>	ingress PE.</t>

		<t>
	<t>
	The following sections define the control and data plane procedures	The following sections define the control and data plane procedures
	for symmetric and asymmetric IRB on ingress and egress PEs. The	for symmetric and asymmetric IRB on ingress and egress PEs. The
	following figure is used to describe these procedures, showing a	following figure is used to describe these procedures, showing a

	single IP-VRF and a number of broadcast domains on each PE for a	single IP-VRF and a number of BDs on each PE for a
	given tenant. I.e., an IP-VRF connects one or more EVIs, each EVI	given tenant. That is, an IP-VRF connects one or more EVIs, and each EVI
	contains one MAC-VRF, each MAC VRF consists of one or more bridge	contains one MAC-VRF; each MAC VRF consists of one or more bridge
	tables, one per broadcast domain, and a PE has an associated IRB	tables, one per BD; and a PE has an associated IRB
	interface for each broadcast domain.</t>	interface for each BD.</t>
		<figure anchor="fig-4">
	<figure title="IRB forwarding" anchor="fig-4"><artwork><![CDATA[	<name>IRB Forwarding</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	PE 1 +---------+	PE 1 +---------+
	+-------------+ \| \|	+-------------+ \| \|
	TS1-----\| MACx\| \| \| PE2	TS1-----\| MACx\| \| \| PE2

	(IP1/M1) \|(BT1) \| \| \| +-------------+	(M1/IP1) \|(BT1) \| \| \| +-------------+
	TS5-----\| \ \| \| MPLS/ \| \|MACy (BT3) \|-----TS3	TS5-----\| \ \| \| MPLS/ \| \|MACy (BT3) \|-----TS3

	(IP5/M5) \|IPx/Mx \ \| \| VxLAN/ \| \| / \| (IP3/M3)	(M5/IP5) \|IPx/Mx \ \| \| VXLAN/ \| \| / \| (M3/IP3)
	\| (IP-VRF1)\|----\| NVGRE \|---\|(IP-VRF1) \|	\| (IP-VRF1)\|----\| NVGRE \|---\|(IP-VRF1) \|
	\| / \| \| \| \| \ \|	\| / \| \| \| \| \ \|
	TS2-----\|(BT2) / \| \| \| \| (BT1) \|-----TS4	TS2-----\|(BT2) / \| \| \| \| (BT1) \|-----TS4

	(IP2/M2) \| \| \| \| \| \| (IP4/M4)	(M2/IP2) \| \| \| \| \| \| (M4/IP4)
	+-------------+ \| \| +-------------+	+-------------+ \| \| +-------------+
	\| \|	\| \|
	+---------+	+---------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<section title="IRB Interface and its MAC and IP addresses" anchor="sect-	<section anchor="sect-4.1" numbered="true" toc="default">
	4.1"><t>	<name>IRB Interface and Its MAC and IP Addresses</name>
		<t>
	To support inter-subnet forwarding on a PE, the PE acts as an IP	To support inter-subnet forwarding on a PE, the PE acts as an IP

	Default Gateway from the perspective of the attached Tenant Systems	default gateway from the perspective of the attached Tenant Systems
	where default gateway MAC and IP addresses are configured on each IRB	where default gateway MAC and IP addresses are configured on each IRB

	interface associated with its subnet and falls into one of the	interface associated with its subnet and fall into one of the
	following two options:</t>	following two options:</t>

		<ol spacing="normal" type="1"><li anchor="opt1">All the PEs for a given
	<t><list style="numbers"><t>All the PEs for a given tenant subnet use the	tenant subnet use the same anycast
	same anycast	default gateway IP and MAC addresses. On each PE, these default
	default gateway IP and MAC addresses. On each PE, this default
	gateway IP and MAC addresses correspond to the IRB interface	gateway IP and MAC addresses correspond to the IRB interface
	connecting the bridge table associated with the tenant's VLAN to	connecting the bridge table associated with the tenant's VLAN to

	the corresponding tenant's IP-VRF.</t>	the corresponding tenant's IP-VRF.</li>
		<li anchor="opt2">Each PE for a given tenant subnet uses the same anyc
	<t>Each PE for a given tenant subnet uses the same anycast default	ast default
	gateway IP address but its own MAC address. These MAC addresses	gateway IP address but its own MAC address. These MAC addresses
	are aliased to the same anycast default gateway IP address	are aliased to the same anycast default gateway IP address
	through the use of the Default Gateway extended community as	through the use of the Default Gateway extended community as

	specified in <xref target="RFC7432"/>, which is carried in the EVPN MAC/I P	specified in <xref target="RFC7432" format="default"/>, which is carried in the EVPN MAC/IP
	Advertisement routes. On each PE, this default gateway IP	Advertisement routes. On each PE, this default gateway IP

	address along with its associated MAC addresses correspond to the	address, along with its associated MAC addresses, correspond to the
	IRB interface connecting the bridge table associated with the	IRB interface connecting the bridge table associated with the

	tenant's VLAN to the corresponding tenant's IP-VRF.</t>	tenant's VLAN to the corresponding tenant's IP-VRF.</li>
		</ol>
	</list>	<t>
	</t>

	<t>
	It is worth noting that if the applications that are running on the	It is worth noting that if the applications that are running on the

	TSes are employing or relying on any form of MAC security, then the	TSs are employing or relying on any form of MAC security, then the
	first option (i.e. using anycast MAC address) should be used to	first option (i.e., using an anycast MAC address) should be used to
	ensure that the applications receive traffic from the same IRB	ensure that the applications receive traffic from the same IRB

	interface MAC address that they are sending to. If the second option	interface MAC address to which they are sending. If the second option
	is used, then the IRB interface MAC address MUST be the one used in	is used, then the IRB interface MAC address <bcp14>MUST</bcp14> be the one us
	the initial ARP reply or ND Neighbor Advertisement (NA)for that TS.</t>	ed in
		the initial ARP reply or ND Neighbor Advertisement (NA) for that TS.</t>
	<t>	<t>
	Although both of these options are applicable to both symmetric and	Although both of these options are applicable to both symmetric and

	asymmetric IRB, the option-1 is recommended because of the ease of	asymmetric IRB, <xref target="opt1" format="none">option 1</xref> is recommen ded because of the ease of
	anycast MAC address provisioning on not only the IRB interface	anycast MAC address provisioning on not only the IRB interface
	associated with a given subnet across all the PEs corresponding to	associated with a given subnet across all the PEs corresponding to
	that VLAN but also on all IRB interfaces associated with all the	that VLAN but also on all IRB interfaces associated with all the
	tenant's subnets across all the PEs corresponding to all the VLANs	tenant's subnets across all the PEs corresponding to all the VLANs
	for that tenant. Furthermore, it simplifies the operation as there	for that tenant. Furthermore, it simplifies the operation as there
	is no need for Default Gateway extended community advertisement and	is no need for Default Gateway extended community advertisement and
	its associated MAC aliasing procedure. Yet another advantage is that	its associated MAC aliasing procedure. Yet another advantage is that
	following host mobility, the host does not need to refresh the	following host mobility, the host does not need to refresh the
	default GW ARP/ND entry.</t>	default GW ARP/ND entry.</t>

		<t>
	<t>	If <xref target="opt1" format="none">option 1</xref> is used, an implementat
	If option-1 is used, an implementation MAY choose to auto-derive the	ion <bcp14>MAY</bcp14> choose to auto-derive the
	anycast MAC address. If auto-derivation is used, the anycast MAC	anycast MAC address. If auto-derivation is used, the anycast MAC

	MUST be auto-derived out of the following ranges (which are defined	<bcp14>MUST</bcp14> be auto-derived out of the following ranges (which are de
	in <xref target="RFC5798"/>):	fined
		in <xref target="RFC5798" format="default"/>):
	<list style="symbols">
	<t>Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID}</t>

	<t>Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID}</t>


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

		<ul spacing="normal">
	<t>	<li>Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID}</li>
		<li>Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID}</li>
		</ul>
		<t>
	Where the last octet is generated based on a configurable Virtual Router ID	Where the last octet is generated based on a configurable Virtual Router ID

	(VRID, range 1-255)). If not explicitly configured, the default value for	(VRID) (range 1-255). If not explicitly configured, the default value for
	the VRID octet is '1'. Auto-derivation of the anycast MAC can only be used	the VRID octet is '1'. Auto-derivation of the anycast MAC can only be used
	if there is certainty that the auto-derived MAC does not collide with any	if there is certainty that the auto-derived MAC does not collide with any
	customer MAC address.</t>	customer MAC address.</t>

		<t>
	<t>
	In addition to IP anycast addresses, IRB interfaces can be configured	In addition to IP anycast addresses, IRB interfaces can be configured

	with non-anycast IP addresses for the purpose of OAM (such as	with non-anycast IP addresses for the purpose of OAM (such as sending a trace
	traceroute/ping to these interfaces) for both symmetric and	route/ping to these interfaces) for both symmetric and
	asymmetric IRB. These IP addresses need to be distributed as VPN	asymmetric IRB. These IP addresses need to be distributed as VPN
	routes when PEs operate in symmetric IRB mode. However, they don't	routes when PEs operate in symmetric IRB mode. However, they don't
	need to be distributed if the PEs are operating in asymmetric IRB	need to be distributed if the PEs are operating in asymmetric IRB
	mode as the non-anycast IP addresses are configured along with their	mode as the non-anycast IP addresses are configured along with their

	individual MACs and they get distributed via EVPN route type-2	individual MACs, and they get distributed via the EVPN route type 2
	advertisement.</t>	advertisement.</t>

		<t>
	<t>	For <xref target="opt1" format="none">option 1</xref> -- irrespective of whet
	For option-1, irrespective of using only the anycast MAC address or	her only the anycast MAC address or
	both anycast and non-anycast MAC addresses (where the latter one is	both anycast and non-anycast MAC addresses (where the latter one is

	used for the purpose of OAM) on the same IRB, when a TS sends an ARP	used for the purpose of OAM) are used on the same IRB -- when a TS sends an A
	request or ND Neighbor Solicitation (NS) to the PE that is attached	RP
	to, the request is sent for the anycast IP address of the IRB	request or ND Neighbor Solicitation (NS) to the PE to which it is attached, t
	interface associated with the TS's subnet and then the reply will use	he request is sent for the anycast IP address of the IRB
	anycast MAC address (in both Source MAC in the Ethernet header and	interface associated with the TS's subnet. The reply will use
	Sender hardware address in the payload). For example, in figure 4,	an anycast MAC address (in both the source MAC in the Ethernet header and
		sender hardware address in the payload). For example, in <xref target="fig-4
		"/>,
	TS1 is configured with the anycast IPx address as its default gateway	TS1 is configured with the anycast IPx address as its default gateway

	IP address and thus when it sends an ARP request for IPx (anycast IP	IP address; thus, when it sends an ARP request for IPx (anycast IP
	address of the IRB interface for BT1), the PE1 sends an ARP reply	address of the IRB interface for BT1), the PE1 sends an ARP reply

	with the MACx which is the anycast MAC address of that IRB interface.	with the MACx, which is the anycast MAC address of that IRB interface.
	Traffic routed from IP-VRF1 to TS1 uses the anycast MAC address as	Traffic routed from IP-VRF1 to TS1 uses the anycast MAC address as the
	source MAC address.</t>	source MAC address.</t>

		</section>
	</section>	<section anchor="sect-4.2" numbered="true" toc="default">
		<name>Operational Considerations</name>
	<section title="Operational Considerations" anchor="sect-4.2"><t>	<t>
	Symmetric and Asymmetric IRB modes may coexist in the same network, and an	Symmetric and asymmetric IRB modes may coexist in the same network, and an
	ingress PE that supports both forwarding modes for a given tenant can	ingress PE that supports both forwarding modes for a given tenant can
	interwork with egress PEs that support either IRB mode. The egress PE will	interwork with egress PEs that support either IRB mode. The egress PE will
	indicate the desired forwarding mode for a given host based on the presence	indicate the desired forwarding mode for a given host based on the presence

	of the Label2 field and the IP-VRF route-target in the EVPN MAC/IP	of the Label2 field and the IP-VRF Route Target in the EVPN MAC/IP
	Advertisement route. If the Label2 field of the received MAC/IP	Advertisement route. If the Label2 field of the received MAC/IP

	Advertisement route for host H1 is non-zero, and one of its route-targets	Advertisement route for host H1 is non-zero, and one of its Route Targets
	identifies the IP-VRF, the ingress PE will use Symmetric IRB mode when	identifies the IP-VRF, the ingress PE will use symmetric IRB mode when
	forwarding packets destined to H1. If the Label2 field is zero and the	forwarding packets destined to H1. If the Label2 field is zero and the

	MAC/IP Advertisement route for H1 does not carry any route-target that	MAC/IP Advertisement route for H1 does not carry any Route Target that
	identifies the IP-VRF, the ingress PE will use Asymmetric mode when	identifies the IP-VRF, the ingress PE will use asymmetric mode when
	forwarding traffic to H1.</t>	forwarding traffic to H1.</t>

		<t>
	<t>
	As an example that illustrates the previous statement, suppose PE1	As an example that illustrates the previous statement, suppose PE1

	and PE2 need to forward packets from TS2 to TS4 in the example of	and PE2 need to forward packets from TS2 to TS4 in
	Figure 4. Since both PEs are attached to the bridge table of the	<xref target="fig-4"/>. Since both PEs are attached to the bridge table of t
	destination host, Symmetric and Asymmetric IRB modes are both	he
		destination host, symmetric and asymmetric IRB modes are both
	possible as long as the ingress PE, PE1, supports both modes. The	possible as long as the ingress PE, PE1, supports both modes. The
	forwarding mode will depend on the mode configured in the egress PE,	forwarding mode will depend on the mode configured in the egress PE,
	PE2. That is:</t>	PE2. That is:</t>

		<ol spacing="normal" type="1"><li>If PE2 is configured for symmetric IRB
	<t><list style="numbers"><t>If PE2 is configured for Symmetric IRB mode,	mode, PE2 will advertise TS4
	PE2 will advertise TS4
	MAC/IP addresses in a MAC/IP Advertisement route with a non-zero Label2	MAC/IP addresses in a MAC/IP Advertisement route with a non-zero Label2

	field, e.g., Label2=Lx, and a route-target that identifies IP-VRF1 in	field, e.g., Label2 = Lx, and a Route Target that identifies IP-VRF1 in
	PE1. IP4 will be installed in PE1's IP-VRF1, TS4's ARP and MAC	PE1. IP4 will be installed in PE1's IP-VRF1; TS4's ARP and MAC
	information will also be installed in PE1's IRB interface ARP table and	information will also be installed in PE1's IRB interface ARP table and

	BT1 respectively. When a packet from TS2 destined to TS4 is looked up	BT1, respectively. When a packet from TS2 destined to TS4 is looked up
	in PE1's IP-VRF route-table, a longest prefix match lookup will find	in PE1's IP-VRF route table, a longest prefix match lookup will find
	IP4 in the IP-VRF, and PE1 will forward using the Symmetric IRB mode	IP4 in the IP-VRF, and PE1 will forward using the symmetric IRB mode
	and Label Lx.</t>	and Label Lx.</li>
		<li>However, if PE2 is configured for asymmetric IRB mode, PE2 will
	<t>However, if PE2 is configured for Asymmetric IRB mode, PE2 will
	advertise TS4 MAC/IP information in a MAC/IP Advertisement route	advertise TS4 MAC/IP information in a MAC/IP Advertisement route

	with a zero Label2 field and no route-target identifying IP-VRF1.	with a zero Label2 field and no Route Target identifying IP-VRF1.
	In this case, PE2 will install TS4 information in its ARP table	In this case, PE2 will install TS4 information in its ARP table
	and BT1. When a packet from TS2 to TS4 arrives at PE1, a longest	and BT1. When a packet from TS2 to TS4 arrives at PE1, a longest

	prefix match on IP-VRF1's route-table will yield the local IRB	prefix match on IP-VRF1's route table will yield the local IRB
	interface to BT1, where a subsequent ARP and bridge table lookup	interface to BT1, where a subsequent ARP and bridge table lookup

	will provide the information for an Asymmetric forwarding mode to	will provide the information for an asymmetric forwarding mode to
	PE2.</t>	PE2.</li>
		</ol>
	</list>	<t>
	</t>	Refer to <xref target="I-D.ietf-bess-evpn-modes-interop"/> for more informati
		on
	<t>	about interoperability between symmetric and asymmetric forwarding
	Refer to [I-D.ietf-bess-evpn-modes-interop] for more information
	about interoperability between Symmetric and Asymmetric forwarding
	modes.</t>	modes.</t>

		<t>
	<t>	The choice between symmetric or asymmetric mode is based on the
	The choice between Symmetric or Asymmetric mode is based on the	operator's preference, and it is a trade-off between scale (which is better i
	operator's preference and it is a trade-off between scale (better in	n
	the Symmetric IRB mode) and control plane simplicity (Asymmetric IRB	the symmetric IRB mode) and control plane simplicity (asymmetric IRB
	mode simplifies the control plane). In cases where a tenant has	mode simplifies the control plane). In cases where a tenant has

	hosts for every subnet attached to all (or most) the PEs, the ARP and	hosts for every subnet attached to all (or most of) the PEs, the ARP and
	MAC entries need to be learned by all PEs anyway and therefore the	MAC entries need to be learned by all PEs anyway; therefore, the
	Asymmetric IRB mode simplifies the forwarding model and saves space	asymmetric IRB mode simplifies the forwarding model and saves space
	in the IP-VRF route-table, since host routes are not installed in the	in the IP-VRF route table, since host routes are not installed in the
	route-table. However, if the tenant does not need to stretch subnets	route table. However, if the tenant does not need to stretch subnets
	(broadcast domains) to multiple PEs and inter-subnet-forwarding is	(broadcast domains) to multiple PEs and inter-subnet forwarding is
	needed, the Symmetric IRB model will save ARP and bridge table space	needed, the symmetric IRB model will save ARP and bridge table space
	in all the PEs (in comparison with the Asymmetric IRB model).</t>	in all the PEs (in comparison with the asymmetric IRB model).</t>
		</section>
	</section>	</section>
		<section anchor="sect-5" numbered="true" toc="default">
	</section>	<name>Symmetric IRB Procedures</name>
		<section anchor="sect-5.1" numbered="true" toc="default">
		<name>Control Plane - Advertising PE</name>


	<section title="Symmetric IRB Procedures" anchor="sect-5"><section title=	<t>
	"Control Plane - Advertising PE" anchor="sect-5.1"><t>	When a PE (e.g., PE1 in <xref target="fig-4"/> above) learns the MAC and IP a
	When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of	ddress of
	a TS (e.g., via an ARP request or Neighbor Solicitation), it adds the	a TS (e.g., via an ARP request or Neighbor Solicitation), it adds the

	MAC address to the corresponding MAC-VRF/bridge table of that	MAC address to the corresponding MAC-VRF/BT of that
	tenant's subnet and adds the IP address to the IP-VRF for that	tenant's subnet and adds the IP address to the IP-VRF for that
	tenant. Furthermore, it adds this TS's MAC and IP address	tenant. Furthermore, it adds this TS's MAC and IP address

	association to its ARP table or NDP cache. It then builds an EVPN	association to its ARP table or Neighbor Discovery
		Protocol (NDP) cache. It then builds an EVPN
	MAC/IP Advertisement route (type 2) as follows and advertises it to	MAC/IP Advertisement route (type 2) as follows and advertises it to
	other PEs participating in that tenant's VPN.</t>	other PEs participating in that tenant's VPN.</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 Network Layer Reachability Inform
	EVPN MAC/IP	ation (NLRI) for an EVPN MAC/IP
	Advertisement route MUST be either 40 (if IPv4 address is carried)	Advertisement route <bcp14>MUST</bcp14> be either 40 (if the IPv4 address
	or 52 (if IPv6 address is carried).</t>	is carried)
		or 52 (if the IPv6 address is carried).</li>
	<t>Route Distinguisher (RD), Ethernet Segment Identifier, Ethernet	<li>The Route Distinguisher (RD), Ethernet Segment Identifier, Etherne
		t
	Tag ID, MAC Address Length, MAC Address, IP Address Length, IP	Tag ID, MAC Address Length, MAC Address, IP Address Length, IP

	Address, and MPLS Label1 fields MUST be set per <xref target="RFC7432"/> a	Address, and MPLS Label1 fields <bcp14>MUST</bcp14> be set per <xref targe
	nd	t="RFC7432" format="default"/> and
	<xref target="RFC8365"/>.</t>	<xref target="RFC8365" format="default"/>.</li>
		<li>The MPLS Label2 field is set to either an MPLS label or a VNI
	<t>The MPLS Label2 field is set to either an MPLS label or a VNI
	corresponding to the tenant's IP-VRF. In the case of an MPLS	corresponding to the tenant's IP-VRF. In the case of an MPLS
	label, this field is encoded as 3 octets, where the high-order 20	label, this field is encoded as 3 octets, where the high-order 20

	bits contain the label value.</t>	bits contain the label value.</li>
		</ul>
	</list>	<t>
	</t>	Just as in <xref target="RFC7432" format="default"/>, the RD, Ethernet Tag ID
		, MAC Address Length,
	<t>
	Just as in <xref target="RFC7432"/>, the RD, Ethernet Tag ID, MAC Address Len
	gth,
	MAC Address, IP Address Length, and IP Address fields are part of the	MAC Address, IP Address Length, and IP Address fields are part of the
	route key used by BGP to compare routes. The rest of the fields are	route key used by BGP to compare routes. The rest of the fields are
	not part of the route key.</t>	not part of the route key.</t>

		<t>
	<t>
	This route is advertised along with the following two extended	This route is advertised along with the following two extended
	communities:</t>	communities:</t>

		<ol spacing="normal" type="1">
	<t><list style="numbers"><t>Encapsulation Extended Community</t>	<li>Encapsulation Extended Community</li>
		<li>EVPN Router's MAC Extended Community</li>
	<t>Router's MAC Extended Community</t>	</ol>
		<t>
	</list>	This route is advertised with one or more Encapsulation Extended
	</t>	Communities <xref target="RFC9012"/>, one for each encapsulation type support
		ed by
	<t>
	This route is advertised with one or more Encapsulation extended
	communities [RFC9012], one for each encapsulation type supported by
	the advertising PE. If one or more encapsulation types require an	the advertising PE. If one or more encapsulation types require an

	Ethernet frame, a single Router's MAC extended community, section	Ethernet frame, a single EVPN Router's MAC Extended Community (<xref target="
	8.1, is also advertised. This extended community specifies the MAC	sect-8.1"/>) is also advertised. This extended community specifies the MAC
	address to be used as the inner destination MAC address in an	address to be used as the inner destination MAC address in an
	Ethernet frame sent to the advertising PE.</t>	Ethernet frame sent to the advertising PE.</t>

		<t>
	<t>	This route <bcp14>MUST</bcp14> be advertised with two Route Targets, one
	This route MUST be advertised with two route targets, one
	corresponding to the MAC-VRF of the tenant's subnet and another	corresponding to the MAC-VRF of the tenant's subnet and another
	corresponding to the tenant's IP-VRF.</t>	corresponding to the tenant's IP-VRF.</t>

		</section>
	</section>	<section anchor="sect-5.2" numbered="true" toc="default">
		<name>Control Plane - Receiving PE</name>
	<section title="Control Plane - Receiving PE" anchor="sect-5.2"><t>	<t>
	When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP	When a PE (e.g., PE2 in <xref target="fig-4"/> above) receives this EVPN MAC/
		IP
	Advertisement route, it performs the following:</t>	Advertisement route, it performs the following:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>The MAC-VRF route target and Ethernet Tag,	<li>The MAC-VRF Route Target and Ethernet Tag,
	if the latter is non-zero, are used to identify the correct MAC-VRF	if the latter is non-zero, are used to identify the correct MAC-VRF

	and bridge table and if they are found the MAC address is imported.	and bridge table, and if they are found, the MAC address is imported.
	The IP-VRF route target is used to identify the correct IP-VRF and if	The IP-VRF Route Target is used to identify the correct IP-VRF, and if
	it is found the IP address is imported.</t>	it is found, the IP address is imported.</li>
		</ul>
	</list>	<t>
	</t>	If the MPLS Label2 field is non-zero, it means that this route is to
		be used for symmetric IRB, and the MPLS label2 value is to be used
	<t>
	If the MPLS label2 field is non-zero, it means that this route is to
	be used for symmetric IRB and the MPLS label2 value is to be used
	when sending a packet for this IP address to the advertising PE.</t>	when sending a packet for this IP address to the advertising PE.</t>

		<t>
	<t>	If the receiving PE supports asymmetric IRB mode and receives this route with
	If the receiving PE receives this route with both the MAC-VRF and IP-VRF	both the MAC-VRF and IP-VRF Route Targets but the MAC/IP Advertisement route do
	route targets but the MAC/IP Advertisement route does not include MPLS	es not include the MPLS
	label2 field and if the receiving PE supports asymmetric IRB mode, then the	Label2 field, then the receiving PE installs the MAC address in the correspon
	receiving PE installs the MAC address in the corresponding MAC-VRF and (IP,	ding MAC-VRF and the (IP,
	MAC) association in the ARP table for that tenant (identified by the	MAC) association in the ARP table for that tenant (identified by the

	corresponding IP-VRF route target).</t>	corresponding IP-VRF Route Target).</t>
		<t>
	<t>
	If the receiving PE receives this route with both the MAC-VRF and IP-VRF	If the receiving PE receives this route with both the MAC-VRF and IP-VRF

	route targets and if the receiving PE does not support either asymmetric or	Route Targets, and if the receiving PE does not support either asymmetric or
	symmetric IRB modes, then if it has the corresponding MAC-VRF, it only	symmetric IRB modes but has the corresponding MAC-VRF, then it only
	imports the MAC address.</t>	imports the MAC address.</t>

		<t>
	<t>
	If the receiving PE receives this route with both the MAC-VRF and IP-VRF	If the receiving PE receives this route with both the MAC-VRF and IP-VRF

	route targets and the MAC/IP Advertisement route includes MPLS label2 field	Route Targets and the MAC/IP Advertisement route includes the MPLS Label2 fie ld
	but the receiving PE only supports asymmetric IRB mode, then the receiving	but the receiving PE only supports asymmetric IRB mode, then the receiving

	PE MUST ignore MPLS label2 field and install the MAC address in the	PE <bcp14>MUST</bcp14> ignore the MPLS Label2 field and install the MAC addre ss in the
	corresponding MAC-VRF and (IP, MAC) association in the ARP table for that	corresponding MAC-VRF and (IP, MAC) association in the ARP table for that

	tenant (identified by the corresponding IP-VRF route target).</t>	tenant (identified by the corresponding IP-VRF Route Target).</t>
		</section>
	</section>	<section anchor="sect-5.3" numbered="true" toc="default">
		<name>Subnet Route Advertisement</name>
	<section title="Subnet route advertisement" anchor="sect-5.3"><t>	<t>
	In the case of symmetric IRB, a layer-3 subnet and IRB interface	In the case of symmetric IRB, a Layer 3 subnet and IRB interface
	corresponding to a MAC-VRF/bridge table is required to be provisioned at a	corresponding to a MAC-VRF/BT are required to be provisioned at a
	PE only if that PE has locally attached hosts in that subnet. In order to	PE only if that PE has locally attached hosts in that subnet. In order to
	enable inter-subnet routing across PEs in a deployment where not all	enable inter-subnet routing across PEs in a deployment where not all
	subnets are provisioned at all PEs participating in an EVPN IRB instance,	subnets are provisioned at all PEs participating in an EVPN IRB instance,

	PEs MUST advertise local subnet routes as EVPN RT-5. These subnet routes	PEs <bcp14>MUST</bcp14> advertise local subnet routes as EVPN RT-5. These su
	are required for bootstrapping host (MAC,IP) learning using gleaning	bnet routes
		are required for bootstrapping host (IP, MAC) learning using gleaning
	procedures initiated by an inter-subnet data packet.</t>	procedures initiated by an inter-subnet data packet.</t>

		<t>
	<t>	That is, if a given host's (IP, MAC) association is unknown, and an
	I.e., if a given host's (MAC, IP) association is unknown, and an
	ingress PE needs to send a packet to that host, then that ingress PE	ingress PE needs to send a packet to that host, then that ingress PE
	needs to know which egress PEs are attached to the subnet in which	needs to know which egress PEs are attached to the subnet in which
	the host resides in order to send the packet to one of those PEs,	the host resides in order to send the packet to one of those PEs,
	causing the PE receiving the packet to probe for that host. For	causing the PE receiving the packet to probe for that host. For

	example, Consider a subnet A that is locally attached to PE1 and	example, consider a subnet A that is locally attached to PE1 and
	subnet B that is locally attached to PE2 and to PE3. Host A in	subnet B that is locally attached to PE2 and PE3. Host A in
	subnet A, that is attached to PE1 initiates a data packet destined to	subnet A, which is attached to PE1, initiates a data packet destined to
	host B in subnet B that is attached to PE3. If host B's (MAC, IP)	host B in subnet B, which is attached to PE3. If host B's (IP, MAC)
	has not yet been learnt either via a gratuitous ARP OR via a prior	has not yet been learned via either a gratuitous ARP OR a prior
	gleaning procedure, a new gleaning procedure MUST be triggered for	gleaning procedure, a new gleaning procedure <bcp14>MUST</bcp14> be triggered
	host B's (MAC, IP) to be learnt and advertised across the EVPN	for
		host B's (IP, MAC) to be learned and advertised across the EVPN
	network. Since host B's subnet is not local to PE1, an IP lookup for	network. Since host B's subnet is not local to PE1, an IP lookup for
	host B at PE1 will not trigger this gleaning procedure for host B's	host B at PE1 will not trigger this gleaning procedure for host B's

	(MAC, IP). Therefore, PE1 MUST learn subnet B's prefix route via	(IP, MAC). Therefore, PE1 <bcp14>MUST</bcp14> learn subnet B's prefix route via
	EVPN RT-5 advertised from PE2 and PE3, so it can route the packet to	EVPN RT-5 advertised from PE2 and PE3, so it can route the packet to
	one of the PEs that have subnet B locally attached. Once the packet	one of the PEs that have subnet B locally attached. Once the packet
	is received at PE2 OR PE3, and the route lookup yields a glean	is received at PE2 OR PE3, and the route lookup yields a glean

	result, an ARP request is triggered and flooded across the layer-2	result, an ARP request is triggered and flooded across the Layer 2
	overlay. This ARP request would be received and replied to by host	overlay.
	B, resulting in host B (MAC, IP) learning at PE3, and its
		This ARP request would be received and replied to by host
		B, resulting in host B (IP, MAC) learning at PE3 and its
	advertisement across the EVPN network. Packets from host A to host B	advertisement across the EVPN network. Packets from host A to host B
	can now be routed directly from PE1 to PE3. Advertisement of local	can now be routed directly from PE1 to PE3. Advertisement of local

	subnet EVPN RT-5 for an IP VRF MAY typically be achieved via	subnet EVPN RT-5 for an IP-VRF <bcp14>MAY</bcp14> typically be achieved via
	provisioning connected route redistribution to BGP.</t>	provisioning-connected route redistribution to BGP.</t>
		</section>
	</section>	<section anchor="sect-5.4" numbered="true" toc="default">
		<name>Data Plane - Ingress PE</name>
	<section title="Data Plane - Ingress PE" anchor="sect-5.4"><t>	<t>
	When an Ethernet frame is received by an ingress PE (e.g., PE1 in	When an Ethernet frame is received by an ingress PE (e.g., PE1 in

	figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify	<xref target="fig-4"/> above), the PE uses the AC ID (e.g., VLAN ID) to ident
	the associated MAC-VRF/bridge table and it performs a lookup on the	ify
		the associated MAC-VRF/BT, and it performs a lookup on the
	destination MAC address. If the MAC address corresponds to its IRB	destination MAC address. If the MAC address corresponds to its IRB

	Interface MAC address, the ingress PE deduces that the packet must be	interface MAC address, the ingress PE deduces that the packet must be
	inter-subnet routed. Hence, the ingress PE performs an IP lookup in	inter-subnet routed. Hence, the ingress PE performs an IP lookup in

	the associated IP-VRF table. The lookup identifies BGP next hop of	the associated IP-VRF table. The lookup identifies the BGP next hop of the e
	egress PE along with the tunnel/encapsulation type and the associated	gress PE along with the tunnel/encapsulation type and the associated
	MPLS/VNI values. The ingress PE also decrements the TTL/hop limit	MPLS/VNI values. The ingress PE also decrements the TTL / hop limit
	for that packet by one and if it reaches zero, the ingress PE	for that packet by one, and if it reaches zero, the ingress PE
	discards the packet.</t>	discards the packet.</t>

		<t>
	<t>	If the tunnel type is that of an MPLS or IP-only NVO tunnel, then the TS's
	If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's
	IP packet is sent over the tunnel without any Ethernet header.	IP packet is sent over the tunnel without any Ethernet header.

	However, if the tunnel type is that of Ethernet NVO tunnel, then an	However, if the tunnel type is that of an Ethernet NVO tunnel, then an
	Ethernet header needs to be added to the TS's IP packet. The source	Ethernet header needs to be added to the TS's IP packet. The source
	MAC address of this inner Ethernet header is set to the ingress PE's	MAC address of this inner Ethernet header is set to the ingress PE's

	router MAC address and the destination MAC address of this inner	router MAC address, and the destination MAC address of this inner
	Ethernet header is set to the egress PE's router MAC address learnt	Ethernet header is set to the egress PE's router MAC address learned
	via Router's MAC extended community attached to the route. MPLS VPN	via the EVPN Router's MAC Extended Community attached to the route. The MPLS
	label is set to the received label2 in the route. In the case of	VPN
	Ethernet NVO tunnel type, VNI may be set one of two ways:</t>	label is set to the received label2 in the route. In the case of the Etherne
		t NVO tunnel type, the VNI may be set one of two ways:</t>
	<t><list style="hanging" hangIndent="6">	<dl newline="false" spacing="normal">
		<dt>downstream mode:</dt>
	<t hangText="downstream mode:"> VNI is set to the received label2 in the route	<dd>The VNI is set to the received label2 in the route,
	which is downstream assigned.</t>	which is downstream assigned.</dd>
		<dt>global mode:</dt>
	<t hangText="global mode:"> VNI is set to the received label2 in the route which	<dd>The VNI is set to the received label2 in the route, which
	is domain-wide assigned. This VNI value from received label2 MUST	is assigned domain-wide. This VNI value from the received label2 <bcp14>M
	be the same as the locally configured VNI for the IP VRF as all	UST</bcp14>
	PEs in the NVO MUST be configured with the same IP VRF VNI for	be the same as the locally configured VNI for the IP-VRF as all
		PEs in the NVO <bcp14>MUST</bcp14> be configured with the same IP-VRF VNI
		for
	this mode of operation. If the received label2 value does not	this mode of operation. If the received label2 value does not

	match the locally configured VNI value the route MUST NOT be used	match the locally configured VNI value, the route <bcp14>MUST NOT</bcp14>
	and an error message SHOULD logged.</t>	be used,
		and an error message <bcp14>SHOULD</bcp14> be logged.</dd>
	</list>	</dl>
	</t>	<t>

	<t>
	PEs may be configured to operate in one of these two modes depending	PEs may be configured to operate in one of these two modes depending
	on the administrative domain boundaries across PEs participating in	on the administrative domain boundaries across PEs participating in

	the NVO, and PE's capability to support downstream VNI mode.</t>	the NVO and the PE's capability to support downstream VNI mode.</t>
		<t>
	<t>
	In the case of NVO tunnel encapsulation, the outer source and	In the case of NVO tunnel encapsulation, the outer source and
	destination IP addresses are set to the ingress and egress PE BGP	destination IP addresses are set to the ingress and egress PE BGP

	next-hop IP addresses respectively.</t>	next-hop IP addresses, respectively.</t>
		</section>
	</section>	<section anchor="sect-5.5" numbered="true" toc="default">
		<name>Data Plane - Egress PE</name>
	<section title="Data Plane - Egress PE" anchor="sect-5.5"><t>	<t>
	When the tenant's MPLS or NVO encapsulated packet is received over an	When the tenant's MPLS or NVO encapsulated packet is received over an

	MPLS or NVO tunnel by the egress PE, the egress PE removes NVO tunnel	MPLS or NVO tunnel by the egress PE, the egress PE removes the NVO tunnel
	encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or	encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or
	VNI (for NVO encapsulation) to identify the IP-VRF in which IP lookup	VNI (for NVO encapsulation) to identify the IP-VRF in which IP lookup
	needs to be performed. If the VPN MPLS label or VNI identifies a	needs to be performed. If the VPN MPLS label or VNI identifies a

	MAC- VRF instead of an IP-VRF, then the procedures in section 6.4 for	MAC-VRF instead of an IP-VRF, then the procedures in <xref target="sect-6.4"/ > for
	asymmetric IRB are executed.</t>	asymmetric IRB are executed.</t>

		<t>
	<t>
	The lookup in the IP-VRF identifies a local adjacency to the IRB	The lookup in the IP-VRF identifies a local adjacency to the IRB

	interface associated with the egress subnet's MAC-VRF/bridge table.	interface associated with the egress subnet's MAC-VRF/BT.
	The egress PE also decrements the TTL/hop limit for that packet by	The egress PE also decrements the TTL / hop limit for that packet by
	one and if it reaches zero, the egress PE discards the packet.</t>	one, and if it reaches zero, the egress PE discards the packet.</t>
		<t>
	<t>
	The egress PE gets the destination TS's MAC address for that TS's IP	The egress PE gets the destination TS's MAC address for that TS's IP

	address from its ARP table or NDP cache, it encapsulates the packet	address from its ARP table or NDP cache. It encapsulates the packet
	with that destination MAC address and a source MAC address	with that destination MAC address and a source MAC address
	corresponding to that IRB interface and sends the packet to its	corresponding to that IRB interface and sends the packet to its

	destination subnet MAC-VRF/bridge table.</t>	destination subnet MAC-VRF/BT.</t>
		<t>
	<t>	The destination MAC address lookup in the MAC-VRF/BT
	The destination MAC address lookup in the MAC-VRF/bridge table	results in the local adjacency (e.g., local interface) over which the
	results in local adjacency (e.g., local interface) over which the	Ethernet frame is sent.</t>
	Ethernet frame is sent on.</t>	</section>
		</section>
	</section>	<section anchor="sect-6" numbered="true" toc="default">
		<name>Asymmetric IRB Procedures</name>
	</section>	<section anchor="sect-6.1" numbered="true" toc="default">
		<name>Control Plane - Advertising PE</name>
	<section title="Asymmetric IRB Procedures" anchor="sect-6"><section title	<t>
	="Control Plane - Advertising PE" anchor="sect-6.1"><t>	When a PE (e.g., PE1 in <xref target="fig-4"/> above) learns the MAC and IP a
	When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of	ddress of
	an attached TS (e.g., via an ARP request or ND Neighbor	an attached TS (e.g., via an ARP request or ND Neighbor

	Solicitation), it populates its MAC-VRF/bridge table, IP-VRF, and ARP	Solicitation), it populates its MAC-VRF/BT, IP-VRF, and ARP
	table or NDP cache just as in the case for symmetric IRB. It then	table or NDP cache just as in the case for symmetric IRB. It then
	builds an EVPN MAC/IP Advertisement route (type 2) as follows and	builds an EVPN MAC/IP Advertisement route (type 2) as follows and
	advertises it to other PEs participating in that tenant's VPN.</t>	advertises it to other PEs participating in that tenant's VPN.</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 MAC/IP
	EVPN MAC/IP	Advertisement route <bcp14>MUST</bcp14> be either 37 (if an IPv4 address i
	Advertisement route MUST be either 37 (if IPv4 address is carried)	s carried)
	or 49 (if IPv6 address is carried).</t>	or 49 (if an IPv6 address is carried).</li>
		<li>The RD, Ethernet Segment Identifier, Ethernet
	<t>Route Distinguisher (RD), Ethernet Segment Identifier, Ethernet
	Tag ID, MAC Address Length, MAC Address, IP Address Length, IP	Tag ID, MAC Address Length, MAC Address, IP Address Length, IP

	Address, and MPLS Label1 fields MUST be set per <xref target="RFC7432"/> a	Address, and MPLS Label1 fields <bcp14>MUST</bcp14> be set per <xref targe
	nd	t="RFC7432" format="default"/> and
	<xref target="RFC8365"/>.</t>	<xref target="RFC8365" format="default"/>.</li>
		<li>The MPLS Label2 field <bcp14>MUST NOT</bcp14> be included in this
	<t>The MPLS Label2 field MUST NOT be included in this route.</t>	route.</li>
		</ul>
	</list>	<t>
	</t>	Just as in <xref target="RFC7432" format="default"/>, the RD, Ethernet Tag ID
		, MAC Address Length,
	<t>
	Just as in <xref target="RFC7432"/>, the RD, Ethernet Tag ID, MAC Address Len
	gth,
	MAC Address, IP Address Length, and IP Address fields are part of the	MAC Address, IP Address Length, and IP Address fields are part of the
	route key used by BGP to compare routes. The rest of the fields are	route key used by BGP to compare routes. The rest of the fields are
	not part of the route key.</t>	not part of the route key.</t>

		<t>
	<t>
	This route is advertised along with the following extended community:</t>	This route is advertised along with the following extended community:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>Tunnel Type Extended Community</t>	<li>Tunnel Type Extended Community</li>
		</ul>
	</list>	<t>
	</t>	For asymmetric IRB mode, the EVPN Router's MAC Extended Community is not

	<t>
	For asymmetric IRB mode, Router's MAC extended community is not
	needed because forwarding is performed using destination TS's MAC	needed because forwarding is performed using destination TS's MAC

	address which is carried in this EVPN route type-2 advertisement.</t>	address, which is carried in this EVPN route type 2 advertisement.</t>
		<t>
	<t>	This route <bcp14>MUST</bcp14> always be advertised with the MAC-VRF Route Ta
	This route MUST always be advertised with the MAC-VRF route target.	rget.
	It MAY also be advertised with a second route target corresponding to	It <bcp14>MAY</bcp14> also be advertised with a second Route Target correspon
		ding to
	the IP-VRF.</t>	the IP-VRF.</t>

		</section>
	</section>	<section anchor="sect-6.2" numbered="true" toc="default">
		<name>Control Plane - Receiving PE</name>
	<section title="Control Plane - Receiving PE" anchor="sect-6.2"><t>	<t>
	When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP	When a PE (e.g., PE2 in <xref target="fig-4"/> above) receives this EVPN MAC/
		IP
	Advertisement route, it performs the following:</t>	Advertisement route, it performs the following:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>Using MAC-VRF route target, it identifies	<li>Using the MAC-VRF Route Target, it identifies
	the corresponding MAC-VRF and imports the MAC address into it. For	the corresponding MAC-VRF and imports the MAC address into it. For
	asymmetric IRB mode, it is assumed that all PEs participating in a	asymmetric IRB mode, it is assumed that all PEs participating in a
	tenant's VPN are configured with all subnets (i.e., all VLANs) and	tenant's VPN are configured with all subnets (i.e., all VLANs) and

	corresponding MAC-VRFs/bridge tables even if there are no locally	corresponding MAC-VRFs/BTs even if there are no locally
	attached TSes for some of these subnets. The reason for this is	attached TSs for some of these subnets. This is because the ingress PE ne
	because ingress PE needs to do forwarding based on destination TS's	eds to do forwarding based on the destination TS's MAC address
	MAC address and perform NVO tunnel encapsulation as a property of a	and perform NVO tunnel encapsulation as the property of a lookup in the MAC-VRF/
	lookup in MAC-VRF/bridge table.</t>	BT.</li>
		<li>If only the MAC-VRF Route Target is used, then the receiving PE us
	<t>If only MAC-VRF route target is used, then the receiving PE uses	es
	the MAC-VRF route target to identify the corresponding IP-VRF --	the MAC-VRF Route Target to identify the corresponding IP-VRF --
	i.e., many MAC-VRF route targets map to the same IP-VRF for a	i.e., many MAC-VRF Route Targets map to the same IP-VRF for a
	given tenant. In this case, MAC-VRF may be used by the receiving	given tenant. In this case, MAC-VRF may be used by the receiving

	PE to identify the corresponding IP VRF via the IRB interface	PE to identify the corresponding IP-VRF via the IRB interface
	associated with the subnet MAC-VRF/bridge table. In this case,	associated with the subnet MAC-VRF/BT. In this case,
	the MAC-VRF route target may be used by the receiving PE to	the MAC-VRF Route Target may be used by the receiving PE to
	identify the corresponding IP VRF.</t>	identify the corresponding IP-VRF.</li>
		<li>Using the MAC-VRF Route Target, the receiving PE identifies the
	<t>Using MAC-VRF route target, the receiving PE identifies the	corresponding ARP table or NDP cache for the tenant, and it adds an
	corresponding ARP table or NDP cache for the tenant and it adds an
	entry to the ARP table or NDP cache for the TS's MAC and IP	entry to the ARP table or NDP cache for the TS's MAC and IP
	address association. It should be noted that the tenant's ARP	address association. It should be noted that the tenant's ARP
	table or NDP cache at the receiving PE is identified by all the	table or NDP cache at the receiving PE is identified by all the

	MAC-VRF route targets for that tenant.</t>	MAC-VRF Route Targets for that tenant.</li>
		<li>If the IP-VRF Route Target is included, it may be used to import t
	<t>If IP-VRF route target is included, it may be used to import the	he
	route to IP-VRF. If IP-VRF route-target is not included, MAC-VRF	route to IP-VRF. If the IP-VRF Route Target is not included, MAC-VRF
	is used to derive corresponding IP-VRF for import, as explained in	is used to derive the corresponding IP-VRF for import, as explained in
	the prior section. In both cases, IP-VRF route is installed with	the prior section. In both cases, an IP-VRF route is installed with
	the TS MAC binding included in the received route.</t>	the TS MAC binding included in the received route.</li>
		</ul>
	</list>	<t>
	</t>	If the receiving PE receives the MAC/IP Advertisement route with the MPLS
		Label2 field but the receiving PE only supports asymmetric IRB mode,
	<t>	then the receiving PE <bcp14>MUST</bcp14> ignore the MPLS Label2 field and in
	If the receiving PE receives the MAC/IP Advertisement route with MPLS	stall the
	label2 field but the receiving PE only supports asymmetric IRB mode,
	then the receiving PE MUST ignore MPLS label2 field and install the
	MAC address in the corresponding MAC-VRF and (IP, MAC) association in	MAC address in the corresponding MAC-VRF and (IP, MAC) association in

	the ARP table or NDP cache for that tenant (with IRB interface	the ARP table or NDP cache for that tenant (with the IRB interface
	identified by the MAC-VRF).</t>	identified by the MAC-VRF).</t>

		</section>
	</section>	<section anchor="sect-6.3" numbered="true" toc="default">
		<name>Data Plane - Ingress PE</name>
	<section title="Data Plane - Ingress PE" anchor="sect-6.3"><t>	<t>
	When an Ethernet frame is received by an ingress PE (e.g., PE1 in	When an Ethernet frame is received by an ingress PE (e.g., PE1 in

	figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify	<xref target="fig-4"/> above), the PE uses the AC ID (e.g., VLAN ID) to ident
	the associated MAC-VRF/bridge table and it performs a lookup on the	ify
		the associated MAC-VRF/BT, and it performs a lookup on the
	destination MAC address. If the MAC address corresponds to its IRB	destination MAC address. If the MAC address corresponds to its IRB

	Interface MAC address, the ingress PE deduces that the packet must be	interface MAC address, the ingress PE deduces that the packet must be
	inter-subnet routed. Hence, the ingress PE performs an IP lookup in	inter-subnet routed. Hence, the ingress PE performs an IP lookup in
	the associated IP-VRF table. The lookup identifies a local adjacency	the associated IP-VRF table. The lookup identifies a local adjacency
	to the IRB interface associated with the egress subnet's MAC-VRF/	to the IRB interface associated with the egress subnet's MAC-VRF/

	bridge table. The ingress PE also decrements the TTL/hop limit for	bridge table. The ingress PE also decrements the TTL / hop limit for
	that packet by one and if it reaches zero, the ingress PE discards	that packet by one, and if it reaches zero, the ingress PE discards
	the packet.</t>	the packet.</t>

		<t>
	<t>
	The ingress PE gets the destination TS's MAC address for that TS's IP	The ingress PE gets the destination TS's MAC address for that TS's IP

	address from its ARP table or NDP cache, it encapsulates the packet	address from its ARP table or NDP cache. It encapsulates the packet
	with that destination MAC address and a source MAC address	with that destination MAC address and a source MAC address
	corresponding to that IRB interface and sends the packet to its	corresponding to that IRB interface and sends the packet to its

	destination subnet MAC-VRF/bridge table.</t>	destination subnet MAC-VRF/BT.</t>
		<t>
	<t>	The destination MAC address lookup in the MAC-VRF/BT
	The destination MAC address lookup in the MAC-VRF/bridge table	results in a BGP next-hop address of the egress PE along with label1 (L2
	results in BGP next hop address of egress PE along with label1 (L2	VPN MPLS label or VNI). The ingress PE encapsulates the packet using
	VPN MPLS label or VNI). The ingress PE encapsulates the packet using	the Ethernet NVO tunnel of the choice (e.g., VXLAN or NVGRE) and sends
	Ethernet NVO tunnel of the choice (e.g., VxLAN or NVGRE) and sends
	the packet to the egress PE. Because the packet forwarding is	the packet to the egress PE. Because the packet forwarding is

	between ingress PE's MAC-VRF/bridge table and egress PE's MAC-VRF/	between the ingress PE's MAC-VRF/BT and the egress PE's MAC-VRF/
	bridge table, the packet encapsulation procedures follow that of	bridge table, the packet encapsulation procedures follow that of

	<xref target="RFC7432"/> for MPLS and <xref target="RFC8365"/> for VxLAN enca	<xref target="RFC7432" format="default"/> for MPLS and <xref target="RFC8365"
	psulations.</t>	format="default"/> for VXLAN encapsulations.</t>
		</section>
	</section>	<section anchor="sect-6.4" numbered="true" toc="default">
		<name>Data Plane - Egress PE</name>
	<section title="Data Plane - Egress PE" anchor="sect-6.4"><t>	<t>
	When a tenant's Ethernet frame is received over an NVO tunnel by the	When a tenant's Ethernet frame is received over an NVO tunnel by the

	egress PE, the egress PE removes NVO tunnel encapsulation and uses	egress PE, the egress PE removes the NVO tunnel encapsulation and uses
	the VPN MPLS label (for MPLS encapsulation) or VNI (for NVO	the VPN MPLS label (for MPLS encapsulation) or VNI (for NVO

	encapsulation) to identify the MAC-VRF/bridge table in which MAC	encapsulation) to identify the MAC-VRF/BT in which the MAC
	lookup needs to be performed.</t>	lookup needs to be performed.</t>

		<t>
	<t>	The MAC lookup results in a local adjacency (e.g., local interface)
	The MAC lookup results in local adjacency (e.g., local interface)
	over which the packet needs to get sent.</t>	over which the packet needs to get sent.</t>

		<t>
	<t>	Note that the forwarding behavior on the egress PE is the same as the EVPN in
	Note that the forwarding behavior on the egress PE is the same as	tra-subnet forwarding described in <xref target="RFC7432" format="default"/> for
	EVPN intra-subnet forwarding described in <xref target="RFC7432"/> for MPLS a	MPLS and
	nd	<xref target="RFC8365" format="default"/> for NVO networks. In other words,
	<xref target="RFC8365"/> for NVO networks. In other words, all the packet	all the packet
	processing associated with the inter-subnet forwarding semantics is	processing associated with the inter-subnet forwarding semantics is
	confined to the ingress PE for asymmetric IRB mode.</t>	confined to the ingress PE for asymmetric IRB mode.</t>

		<t>
	<t>	It should also be noted that <xref target="RFC7432" format="default"/> provid
	It should also be noted that <xref target="RFC7432"/> provides a different le	es a different level of
	vel of
	granularity for the EVPN label. Besides identifying the bridge	granularity for the EVPN label. Besides identifying the bridge
	domain table, it can be used to identify the egress interface or a	domain table, it can be used to identify the egress interface or a

	destination MAC address on that interface. If EVPN label is used for	destination MAC address on that interface. If an EVPN label is used for
	egress interface or individual MAC address identification, then no	an egress interface or individual MAC address identification, then no
	MAC lookup is needed in the egress PE for MPLS encapsulation and the	MAC lookup is needed in the egress PE for MPLS encapsulation, and the
	packet can be directly forwarded to the egress interface just based	packet can be directly forwarded to the egress interface just based

	on EVPN label lookup.</t>	on the EVPN label lookup.</t>
		</section>
	</section>	</section>
		<section anchor="sect-7" numbered="true" toc="default">
	</section>	<name>Mobility Procedure</name>
		<t>
	<section title="Mobility Procedure" anchor="sect-7"><t>
	When a TS moves from one NVE (aka source NVE) to another NVE (aka	When a TS moves from one NVE (aka source NVE) to another NVE (aka

	target NVE), it is important that the MAC mobility procedures are	target NVE), it is important that the MAC Mobility procedures be
	properly executed and the corresponding MAC-VRF and IP-VRF tables on	properly executed and the corresponding MAC-VRF and IP-VRF tables on

	all participating NVEs are updated. <xref target="RFC7432"/> describes the M	all participating NVEs be updated. <xref target="RFC7432" format="default"/>
	AC	describes the MAC
	mobility procedures for L2-only services for both single-homed TS and	Mobility procedures for L2-only services for both single-homed TS and
	multi-homed TS. This section describes the incremental procedures	multihomed TS. This section describes the incremental procedures
	and BGP Extended Communities needed to handle the MAC mobility for	and BGP Extended Communities needed to handle the MAC Mobility for
	IRB. In order to place the emphasis on the differences between	IRB. In order to place the emphasis on the differences between
	L2-only and IRB use cases, the incremental procedure is described for	L2-only and IRB use cases, the incremental procedure is described for

	single-homed TS with the expectation that the additional steps needed	a single-homed TS with the expectation that the additional steps needed
	for multi-homed TS, can be extended per section 15 of <xref target="RFC7432"/	for a multihomed TS can be extended per <xref target="RFC7432" sectionFormat=
	>.	"of" section="15"/>.
	This section describes mobility procedures for both symmetric and	This section describes mobility procedures for both symmetric and
	asymmetric IRB. Although the language used in this section is for	asymmetric IRB. Although the language used in this section is for
	IPv4 ARP, it equally applies to IPv6 ND.</t>	IPv4 ARP, it equally applies to IPv6 ND.</t>

		<t>
	<t>
	When a TS moves from a source NVE to a target NVE, it can behave in	When a TS moves from a source NVE to a target NVE, it can behave in
	one of the following three ways:</t>	one of the following three ways:</t>

		<ol spacing="normal" type="1"><li anchor="way1">TS initiates an ARP reques
	<t><list style="numbers"><t>TS initiates an ARP request upon a move to th	t upon a move to the target NVE.</li>
	e target NVE</t>	<li anchor="way2">TS sends a data packet without first initiating an ARP
		request to
	<t>TS sends data packet without first initiating an ARP request to	the target NVE.</li>
	the target NVE</t>	<li anchor="way3">TS is a silent host and neither initiates an ARP reque
		st nor
	<t>TS is a silent host and neither initiates an ARP request nor	sends any packets.</li>
	sends any packets</t>	</ol>
		<t>
	</list>	Depending on the expected TS's behavior, an NVE needs to handle at least
	</t>	the <xref target="way1" format="none">first</xref> option and should be able
		to handle the <xref target="way2" format="none">second</xref> and <xref target="
	<t>	way3" format="none">third</xref> options.
	Depending on the expexted TS's behavior, an NVE needs to handle at least	The following subsections describe the procedures for each scenario where it
	the first bullet and should be able to handle the 2nd and the 3rd bullet.	is assumed that the MAC and IP addresses of a TS have a one-to-one
	The following subsections describe the procedures for each of them where it
	is assumed that the MAC and IP addresses of a TS have one-to-one
	relationship (i.e., there is one IP address per MAC address and vice	relationship (i.e., there is one IP address per MAC address and vice
	versa). The procedures for host mobility detection in the presence of	versa). The procedures for host mobility detection in the presence of

	many-to-one relationship is outside the scope of this document and it is	a many-to-one relationship is outside the scope of this document, and it is
	covered in <xref target="I-D.ietf-bess-evpn-irb-extended-mobility"/>. The	covered in <xref target="I-D.ietf-bess-evpn-irb-extended-mobility" format="de
	many-to-one relationship means many host IP addresses corresponding to a	fault"/>. The
		"many-to-one relationship" refers to many host IP addresses corresponding to
		a
	single host MAC address or many host MAC addresses corresponding to a	single host MAC address or many host MAC addresses corresponding to a

	single IP address. It should be noted that in case of IPv6, a Link Local	single IP address. It should be noted that in the case of IPv6, a link-local
	IP address does not count in many-to-one relationship because that address	IP address does not count in a many-to-one relationship because that address
	is confined to single Ethernet Segment and it is not used for host moblity	is confined to a single Ethernet segment, and it is not used for host mobilit
	(i.e., by definition host mobility is between two different Ethernet	y
	Segments). Therefore, when an IPv6 host is configured with both a Global	(i.e., by definition, host mobility is between two different Ethernet
	Unicast address (or a Unique Local address) and a Link Local address, for	segments). Therefore, when an IPv6 host is configured with both a Global
		Unicast address (or a Unique Local address) and a link-local address, for
	the purpose of host mobility, it is considered with a single IP	the purpose of host mobility, it is considered with a single IP
	address.</t>	address.</t>

		<section anchor="sect-7.1" numbered="true" toc="default">
	<section title="Initiating a gratutious ARP upon a Move" anchor="sect-7.1	<name>Initiating a Gratuitous ARP upon a Move</name>
	"><t>	<t>
	In this scenario when a TS moves from a source NVE to a target NVE,	In this scenario, when a TS moves from a source NVE to a target NVE,
	the TS initiates a gratuitous ARP upon the move to the target NVE.</t>	the TS initiates a gratuitous ARP upon the move to the target NVE.</t>

		<t>
	<t>	The target NVE, upon receiving this ARP message, updates its MAC-VRF,
	The target NVE upon receiving this ARP message, updates its MAC-VRF,
	IP-VRF, and ARP table with the host MAC, IP, and local adjacency	IP-VRF, and ARP table with the host MAC, IP, and local adjacency
	information (e.g., local interface).</t>	information (e.g., local interface).</t>

		<t>
	<t>
	Since this NVE has previously learned the same MAC and IP addresses	Since this NVE has previously learned the same MAC and IP addresses

	from the source NVE, it recognizes that there has been a MAC move and	from the source NVE, it recognizes that there has been a MAC move, and
	it initiates MAC mobility procedures per <xref target="RFC7432"/> by advertis	it initiates MAC Mobility procedures per <xref target="RFC7432" format="defau
	ing an	lt"/> by advertising an
	EVPN MAC/IP Advertisement route with both the MAC and IP addresses	EVPN MAC/IP Advertisement route with both the MAC and IP addresses

	filled in (per sections 5.1 and 6.1) along with MAC Mobility Extended	filled in (per Sections <xref target="sect-5.1" format="counter"/> and <xref
	Community with the sequence number incremented by one. The target	target="sect-6.1" format="counter"/>) along with the MAC Mobility extended
	NVE also exercises the MAC duplication detection procedure in section	community, with the sequence number incremented by one. The target
	15.1 of <xref target="RFC7432"/>.</t>	NVE also exercises the MAC duplication detection procedure in <xref target="R
		FC7432" sectionFormat="of" section="15.1"/>.</t>
	<t>	<t>
	The source NVE upon receiving this MAC/IP Advertisement route,	The source NVE, upon receiving this MAC/IP Advertisement route,
	realizes that the MAC has moved to the target NVE. It updates its	realizes that the MAC has moved to the target NVE. It updates its
	MAC-VRF and IP-VRF table accordingly with the adjacency information	MAC-VRF and IP-VRF table accordingly with the adjacency information
	of the target NVE. In the case of the asymmetric IRB, the source NVE	of the target NVE. In the case of the asymmetric IRB, the source NVE

	also updates its ARP table with the received adjacency information	also updates its ARP table with the received adjacency information,
	and in the case of the symmetric IRB, the source NVE removes the	and in the case of the symmetric IRB, the source NVE removes the

	entry associated with the received (MAC, IP) from its local ARP	entry associated with the received (IP, MAC) from its local ARP
	table. It then withdraws its EVPN MAC/IP Advertisement route.	table. It then withdraws its EVPN MAC/IP Advertisement route.
	Furthermore, it sends an ARP probe locally to ensure that the MAC is	Furthermore, it sends an ARP probe locally to ensure that the MAC is
	gone. If an ARP response is received, the source NVE updates its ARP	gone. If an ARP response is received, the source NVE updates its ARP
	entry for that (IP, MAC) and re-advertises an EVPN MAC/IP	entry for that (IP, MAC) and re-advertises an EVPN MAC/IP

	Advertisement route for that (IP, MAC) along with MAC Mobility	Advertisement route for that (IP, MAC) along with the MAC Mobility
	Extended Community with the sequence number incremented by one. The	extended community, with the sequence number incremented by one. The
	source NVE also exercises the MAC duplication detection procedure in	source NVE also exercises the MAC duplication detection procedure in

	section 15.1 of <xref target="RFC7432"/>.</t>	<xref target="RFC7432" sectionFormat="of" section="15.1"/>.</t>
		<t>
	<t>	All other remote NVE devices, upon receiving the MAC/IP Advertisement route
	All other remote NVE devices upon receiving the MAC/IP Advertisement route	with the MAC Mobility extended community, compare the sequence number in this
	with MAC Mobility extended community compare the sequence number in this
	advertisement with the one previously received. If the new sequence number	advertisement with the one previously received. If the new sequence number
	is greater than the old one, then they update the MAC/IP addresses of the	is greater than the old one, then they update the MAC/IP addresses of the
	TS in their corresponding MAC-VRF and IP-VRF tables to point to the target	TS in their corresponding MAC-VRF and IP-VRF tables to point to the target
	NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS from the	NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS from the
	source NVE, these remote PEs perform the cleanups for their BGP tables.</t>	source NVE, these remote PEs perform the cleanups for their BGP tables.</t>

		</section>
	</section>	<section anchor="sect-7.2" numbered="true" toc="default">
		<name>Sending Data Traffic without an ARP Request</name>
	<section title="Sending Data Traffic without an ARP Request" anchor="sect	<t>
	-7.2"><t>	In this scenario, when a TS moves from a source NVE to a target NVE,
	In this scenario when a TS moves from a source NVE to a target NVE,
	the TS starts sending data traffic without first initiating an ARP	the TS starts sending data traffic without first initiating an ARP
	request.</t>	request.</t>

		<t>
	<t>	The target NVE, upon receiving the first data packet, learns the MAC
	The target NVE upon receiving the first data packet, learns the MAC
	address of the TS in the data plane and updates its MAC-VRF table	address of the TS in the data plane and updates its MAC-VRF table
	with the MAC address and the local adjacency information (e.g., local	with the MAC address and the local adjacency information (e.g., local
	interface) accordingly. The target NVE realizes that there has been	interface) accordingly. The target NVE realizes that there has been
	a MAC move because the same MAC address has been learned remotely	a MAC move because the same MAC address has been learned remotely
	from the source NVE.</t>	from the source NVE.</t>

		<t>
	<t>
	If EVPN-IRB NVEs are configured to advertise MAC-only routes in	If EVPN-IRB NVEs are configured to advertise MAC-only routes in
	addition to MAC-and-IP EVPN routes, then the following steps are	addition to MAC-and-IP EVPN routes, then the following steps are
	taken:</t>	taken:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>The target NVE upon learning this MAC address	<li>The target NVE, upon learning this MAC address in the data plane,
	in the data plane,
	updates this MAC address entry in the corresponding MAC-VRF with	updates this MAC address entry in the corresponding MAC-VRF with
	the local adjacency information (e.g., local interface). It also	the local adjacency information (e.g., local interface). It also

	recognizes that this MAC has moved and initiates MAC mobility	recognizes that this MAC has moved and initiates MAC Mobility
	procedures per <xref target="RFC7432"/> by advertising an EVPN MAC/IP	procedures per <xref target="RFC7432" format="default"/> by advertising an
	Advertisement route with only the MAC address filled in along with	EVPN MAC/IP
	MAC Mobility Extended Community with the sequence number	Advertisement route with only the MAC address filled in along with the
	incremented by one.</t>	MAC Mobility extended community, with the sequence number
		incremented by one.</li>
	<t>The source NVE upon receiving this MAC/IP Advertisement route,	<li>The source NVE, upon receiving this MAC/IP Advertisement route,
	realizes that the MAC has moved to the new NVE. It updates its	realizes that the MAC has moved to the new NVE. It updates its
	MAC-VRF table with the adjacency information for that MAC address	MAC-VRF table with the adjacency information for that MAC address
	to point to the target NVE and withdraws its EVPN MAC/IP	to point to the target NVE and withdraws its EVPN MAC/IP
	Advertisement route that has only the MAC address (if it has	Advertisement route that has only the MAC address (if it has

	advertised such route previously). Furthermore, it searches for	advertised such a route previously). Furthermore, it searches for
	the corresponding MAC-IP entry and sends an ARP probe for this	the corresponding MAC-IP entry and sends an ARP probe for this

	(MAC,IP) pair. The ARP request message is sent both locally to	(IP, MAC) pair. The ARP request message is sent both locally to
	all attached TSes in that subnet as well as it is sent to other	all attached TSs in that subnet as well as to other
	NVEs participating in that subnet including the target NVE. Note	NVEs participating in that subnet, including the target NVE. Note
	that the PE needs to maintain a correlation between MAC and MAC-IP	that the PE needs to maintain a correlation between MAC and MAC-IP

	route entries in the MAC-VRF to accomplish this.</t>	route entries in the MAC-VRF to accomplish this.</li>
		<li>The target NVE passes the ARP request to its locally attached TSs,
	<t>The target NVE passes the ARP request to its locally attached TSes
	and when it receives the ARP response, it updates its IP-VRF and	and when it receives the ARP response, it updates its IP-VRF and

	ARP table with the host (MAC, IP) information. It also sends an	ARP table with the host (IP, MAC) information. It also sends an
	EVPN MAC/IP Advertisement route with both the MAC and IP addresses	EVPN MAC/IP Advertisement route with both the MAC and IP addresses

	filled in along with MAC Mobility Extended Community with the	filled in along with the MAC Mobility extended community, with the
	sequence number set to the same value as the one for MAC-only	sequence number set to the same value as the one for the MAC-only
	advertisement route it sent previously.</t>	Advertisement route it sent previously.</li>
		<li>When the source NVE receives the EVPN MAC/IP Advertisement route,
	<t>When the source NVE receives the EVPN MAC/IP Advertisement route,
	it updates its IP-VRF table with the new adjacency information	it updates its IP-VRF table with the new adjacency information
	(pointing to the target NVE). In the case of the asymmetric IRB,	(pointing to the target NVE). In the case of the asymmetric IRB,
	the source NVE also updates its ARP table with the received	the source NVE also updates its ARP table with the received

	adjacency information and in the case of the symmetric IRB, the	adjacency information, and in the case of the symmetric IRB, the
	source NVE removes the entry associated with the received (MAC,	source NVE removes the entry associated with the received (IP, MAC) from i
	IP) from its local ARP table. Furthermore, it withdraws its	ts local ARP table. Furthermore, it withdraws its
	previously advertised EVPN MAC/IP route with both the MAC and IP	previously advertised EVPN MAC/IP route with both the MAC and IP

	address fields filled in.</t>	address fields filled in.</li>
		<li>All other remote NVE devices, upon receiving the MAC/IP
	<t>All other remote NVE devices upon receiving the MAC/IP	Advertisement route with the MAC Mobility extended community, compare
	advertisement route with MAC Mobility extended community compare
	the sequence number in this advertisement with the one previously	the sequence number in this advertisement with the one previously
	received. If the new sequence number is greater than the old one,	received. If the new sequence number is greater than the old one,
	then they update the MAC/IP addresses of the TS in their	then they update the MAC/IP addresses of the TS in their
	corresponding MAC-VRF, IP-VRF, and ARP tables (in the case of	corresponding MAC-VRF, IP-VRF, and ARP tables (in the case of
	asymmetric IRB) to point to the new NVE. Furthermore, upon	asymmetric IRB) to point to the new NVE. Furthermore, upon
	receiving the MAC/IP withdraw for the TS from the old NVE, these	receiving the MAC/IP withdraw for the TS from the old NVE, these

	remote PEs perform the cleanups for their BGP tables.</t>	remote PEs perform the cleanups for their BGP tables.</li>
		</ul>
	</list>
	</t>


	<t>	<t>
	If EVPN-IRB NVEs are configured not to advertise MAC-only routes,	If an EVPN-IRB NVE is configured not to advertise MAC-only routes,
	then upon receiving the first data packet, it learns the MAC address	then upon receiving the first data packet, it learns the MAC address
	of the TS and updates the MAC entry in the corresponding MAC-VRF	of the TS and updates the MAC entry in the corresponding MAC-VRF
	table with the local adjacency information (e.g., local interface).	table with the local adjacency information (e.g., local interface).
	It also realizes that there has been a MAC move because the same MAC	It also realizes that there has been a MAC move because the same MAC
	address has been learned remotely from the source NVE. It uses the	address has been learned remotely from the source NVE. It uses the

	local MAC route to find the corresponding local MAC-IP route, and	local MAC route to find the corresponding local MAC-IP route and
	sends a unicast ARP request to the host and when receiving an ARP	sends a unicast ARP request to the host. When receiving an ARP
	response, it follows the procedure outlined in section 7.1. In the	response, it follows the procedure outlined in <xref target="sect-7.1"/>. In
		the
	prior case, where MAC-only routes are also advertised, this procedure	prior case, where MAC-only routes are also advertised, this procedure

	of triggering a unicast ARP probe at the target PE MAY also be used	of triggering a unicast ARP probe at the target PE <bcp14>MAY</bcp14> also be used
	in addition to the source PE broadcast ARP probing procedure	in addition to the source PE broadcast ARP probing procedure
	described earlier for better convergence.</t>	described earlier for better convergence.</t>

		</section>
	</section>	<section anchor="sect-7.3" numbered="true" toc="default">
		<name>Silent Host</name>
	<section title="Silent Host" anchor="sect-7.3"><t>	<t>
	In this scenario when a TS moves from a source NVE to a target NVE,	In this scenario, when a TS moves from a source NVE to a target NVE,
	the TS is silent and it neither initiates an ARP request nor it sends	the TS is silent, and it neither initiates an ARP request nor sends
	any data traffic. Therefore, neither the target nor the source NVEs	any data traffic. Therefore, neither the target nor the source NVEs
	are aware of the MAC move.</t>	are aware of the MAC move.</t>

		<t>
	<t>
	On the source NVE, an age-out timer (for the silent host that has	On the source NVE, an age-out timer (for the silent host that has
	moved) is used to trigger an ARP probe. This age-out timer can be	moved) is used to trigger an ARP probe. This age-out timer can be

	either ARP timer or MAC age-out timer and this is an implementation	either an ARP timer or a MAC age-out timer, and this is an implementation
	choice. The ARP request gets sent both locally to all the attached	choice. The ARP request gets sent both locally to all the attached

	TSes on that subnet as well as it gets sent to all the remote NVEs	TSs on that subnet as well as to all the remote NVEs
	(including the target NVE) participating in that subnet. The source	(including the target NVE) participating in that subnet. The source

	NVE also withdraw the EVPN MAC/IP Advertisement route with only the	NVE also withdraws the EVPN MAC/IP Advertisement route with only the
	MAC address (if it has previously advertised such a route).</t>	MAC address (if it has previously advertised such a route).</t>

		<t>
	<t>	The target NVE passes the ARP request to its locally attached TSs, and when
	The target NVE passes the ARP request to its locally attached TSes and when
	it receives the ARP response, it updates its MAC-VRF, IP-VRF, and ARP table	it receives the ARP response, it updates its MAC-VRF, IP-VRF, and ARP table

	with the host (MAC, IP) and local adjacency information (e.g., local	with the host (IP, MAC) and local adjacency information (e.g., local
	interface). It also sends an EVPN MAC/IP advertisement route with both the	interface). It also sends an EVPN MAC/IP Advertisement route with both the
	MAC and IP address fields filled in along with MAC Mobility Extended	MAC and IP address fields filled in along with the MAC Mobility extended
	Community with the sequence number incremented by one.</t>	community, with the sequence number incremented by one.</t>
		<t>
	<t>
	When the source NVE receives the EVPN MAC/IP Advertisement route, it	When the source NVE receives the EVPN MAC/IP Advertisement route, it
	updates its IP-VRF table with the new adjacency information (pointing	updates its IP-VRF table with the new adjacency information (pointing
	to the target NVE). In the case of the asymmetric IRB, the source	to the target NVE). In the case of the asymmetric IRB, the source
	NVE also updates its ARP table with the received adjacency	NVE also updates its ARP table with the received adjacency

	information and in the case of the symmetric IRB, the source NVE	information, and in the case of the symmetric IRB, the source NVE
	removes the entry associated with the received (MAC, IP) from its	removes the entry associated with the received (IP, MAC) from its
	local ARP table. Furthermore, it withdraws its previously advertised	local ARP table. Furthermore, it withdraws its previously advertised
	EVPN MAC/IP route with both the MAC and IP address fields filled in.</t>	EVPN MAC/IP route with both the MAC and IP address fields filled in.</t>

		<t>
	<t>	All other remote NVE devices, upon receiving the MAC/IP Advertisement route
	All other remote NVE devices upon receiving the MAC/IP Advertisement route	with the MAC Mobility extended community, compare the sequence number in this
	with MAC Mobility extended community compare the sequence number in this
	advertisement with the one previously received. If the new sequence number	advertisement with the one previously received. If the new sequence number
	is greater than the old one, then they update the MAC/IP addresses of the	is greater than the old one, then they update the MAC/IP addresses of the
	TS in their corresponding MAC-VRF, IP-VRF, and ARP (in the case of	TS in their corresponding MAC-VRF, IP-VRF, and ARP (in the case of
	asymmetric IRB) tables to point to the new NVE. Furthermore, upon	asymmetric IRB) tables to point to the new NVE. Furthermore, upon
	receiving the MAC/IP withdraw for the TS from the old NVE, these remote PEs	receiving the MAC/IP withdraw for the TS from the old NVE, these remote PEs
	perform the cleanups for their BGP tables.</t>	perform the cleanups for their BGP tables.</t>

		</section>
	</section>	</section>
		<section anchor="sect-8" numbered="true" toc="default">
	</section>	<name>BGP Encoding</name>
		<t>
	<section title="BGP Encoding" anchor="sect-8"><t>
	This document defines one new BGP Extended Community for EVPN.</t>	This document defines one new BGP Extended Community for EVPN.</t>

		<section anchor="sect-8.1" numbered="true" toc="default">
	<section title="Router's MAC Extended Community" anchor="sect-8.1"><t>	<name>EVPN Router's MAC Extended Community</name>
	A new EVPN BGP Extended Community called Router's MAC is introduced	<t>
		A new EVPN BGP Extended Community called "EVPN Router's MAC" is introduced
	here. This new extended community is a transitive extended community	here. This new extended community is a transitive extended community

	with the Type field of 0x06 (EVPN) and the Sub-Type of 0x03. It may	with a Type field of 0x06 (EVPN) and a Sub-Type field of 0x03. It may
	be advertised along with Encapsulation Extended Community defined in	be advertised along with the Encapsulation Extended Community defined in
	section 4.1 of <xref target="I-D.ietf-idr-tunnel-encaps"/>.</t>	<xref target="RFC9012" sectionFormat="of" section="4.1"/>.</t>
		<t>
	<t>	The EVPN Router's MAC Extended Community is encoded as an 8-octet value as
	The Router's MAC Extended Community is encoded as an 8-octet value as
	follows:</t>	follows:</t>

		<figure anchor="fig-5">
	<figure title="Router's MAC Extended Community" anchor="fig-5"><artwork><	<name>EVPN Router's MAC Extended Community</name>
	![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| Type=0x06 \| Sub-Type=0x03 \| Router's MAC \|	\| Type=0x06 \| Sub-Type=0x03 \| EVPN Router's MAC \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| Router's MAC Cont'd \|	\| EVPN Router's MAC Cont'd \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	This extended community is used to carry the PE's MAC address for	This extended community is used to carry the PE's MAC address for

	symmetric IRB scenarios and it is sent with EVPN RT-2. The	symmetric IRB scenarios, and it is sent with EVPN RT-2. The
	advertising PE SHALL only attach a single Router's MAC Extended	advertising PE <bcp14>SHALL</bcp14> only attach a single EVPN Router's MAC Ex
		tended
	Community to a route. In case the receiving PE receives more than	Community to a route. In case the receiving PE receives more than

	one Router's MAC Extended Community with a route, it SHALL process	one EVPN Router's MAC Extended Community with a route, it <bcp14>SHALL</bcp14 > process
	the first one in the list and not store and propagate the others.</t>	the first one in the list and not store and propagate the others.</t>

		</section>
	</section>	</section>
		<section anchor="sect-9" numbered="true" toc="default">
	</section>	<name>Operational Models for Symmetric Inter-Subnet Forwarding</name>
		<t>
	<section title="Operational Models for Symmetric Inter-Subnet Forwarding"
	anchor="sect-9"><t>
	The following sections describe two main symmetric IRB forwarding	The following sections describe two main symmetric IRB forwarding
	scenarios (within a DC -- i.e., intra-DC) along with the	scenarios (within a DC -- i.e., intra-DC) along with the
	corresponding procedures. In the following scenarios, without loss	corresponding procedures. In the following scenarios, without loss
	of generality, it is assumed that a given tenant is represented by a	of generality, it is assumed that a given tenant is represented by a
	single IP-VPN instance. Therefore, on a given PE, a tenant is	single IP-VPN instance. Therefore, on a given PE, a tenant is
	represented by a single IP-VRF table and one or more MAC-VRF tables.</t>	represented by a single IP-VRF table and one or more MAC-VRF tables.</t>

		<section anchor="sect-9.1" numbered="true" toc="default">
	<section title="IRB forwarding on NVEs for Tenant Systems" anchor="sect-9	<name>IRB Forwarding on NVEs for Tenant Systems</name>
	.1"><t>	<t>
	This section covers the symmetric IRB procedures for the scenario	This section covers the symmetric IRB procedures for the scenario

	where each Tenant System (TS) is attached to one or more NVEs and its	where each TS is attached to one or more NVEs, and its
	host IP and MAC addresses are learned by the attached NVEs and are	host IP and MAC addresses are learned by the attached NVEs and are
	distributed to all other NVEs that are interested in participating in	distributed to all other NVEs that are interested in participating in
	both intra-subnet and inter-subnet communications with that TS.</t>	both intra-subnet and inter-subnet communications with that TS.</t>

		<t>
	<t>
	In this scenario, without loss of generality, it is assumed that NVEs	In this scenario, without loss of generality, it is assumed that NVEs
	operate in VLAN-based service interface mode with one bridge table(s)	operate in VLAN-based service interface mode with one bridge table(s)
	per MAC-VRF. Thus, for a given tenant, an NVE has one MAC-VRF for	per MAC-VRF. Thus, for a given tenant, an NVE has one MAC-VRF for
	each tenant subnet (e.g., each VLAN) that is configured for extension	each tenant subnet (e.g., each VLAN) that is configured for extension

	via VxLAN or NVGRE encapsulation. In the case of VLAN-aware	via VXLAN or NVGRE encapsulation. In the case of VLAN-aware
	bundling, then each MAC-VRF consists of multiple Bridge Tables (e.g.,	bundling, each MAC-VRF consists of multiple bridge tables (e.g.,
	one bridge table per VLAN). The MAC-VRFs on an NVE for a given	one bridge table per VLAN). The MAC-VRFs on an NVE for a given
	tenant are associated with an IP-VRF corresponding to that tenant (or	tenant are associated with an IP-VRF corresponding to that tenant (or
	IP-VPN instance) via their IRB interfaces.</t>	IP-VPN instance) via their IRB interfaces.</t>

		<t>
	<t>	Since VXLAN and NVGRE encapsulations require an inner Ethernet header
	Since VxLAN and NVGRE encapsulations require inner Ethernet header	(inner MAC SA/DA) and since a TS MAC address cannot be used for inter-subnet
	(inner MAC SA/DA), and since for inter-subnet traffic, TS MAC address	traffic, the ingress NVE's MAC address is used as an inner MAC
	cannot be used, the ingress NVE's MAC address is used as inner MAC	SA. The NVE's MAC address is the device MAC address, and it is common
	SA. The NVE's MAC address is the device MAC address and it is common
	across all MAC-VRFs and IP-VRFs. This MAC address is advertised	across all MAC-VRFs and IP-VRFs. This MAC address is advertised

	using the new EVPN Router's MAC Extended Community (section 8.1).</t>	using the new EVPN Router's MAC Extended Community (<xref target="sect-8.1"/>
		).</t>
	<t>	<t>
	Figure 6 below illustrates this scenario where a given tenant (e.g., an	<xref target="fig-6"/> below illustrates this scenario, where a given tenant
		(e.g., an
	IP-VPN instance) has three subnets represented by MAC-VRF1, MAC-VRF2, and	IP-VPN instance) has three subnets represented by MAC-VRF1, MAC-VRF2, and

	MAC-VRF3 across two NVEs. There are five TSes that are associated with	MAC-VRF3 across two NVEs. There are five TSs that are associated with
	these three MAC-VRFs -- i.e., TS1, TS4, and TS5 are on the same subnet	these three MAC-VRFs -- i.e., TS1, TS4, and TS5 are on the same subnet

	(e.g., same MAC-VRF/VLAN). TS1 and TS5 are associated with MAC-VRF1 on	(e.g., the same MAC-VRF/VLAN). TS1 and TS5 are associated with MAC-VRF1 on
	NVE1, while TS4 is associated with MAC-VRF1 on NVE2. TS2 is associated	NVE1, while TS4 is associated with MAC-VRF1 on NVE2. TS2 is associated
	with MAC-VRF2 on NVE1, and TS3 is associated with MAC-VRF3 on NVE2.	with MAC-VRF2 on NVE1, and TS3 is associated with MAC-VRF3 on NVE2.

	MAC-VRF1 and MAC-VRF2 on NVE1 are in turn associated with IP-VRF1 on NVE1	MAC-VRF1 and MAC-VRF2 on NVE1 are, in turn, associated with IP-VRF1 on NVE1,
	and MAC-VRF1 and MAC-VRF3 on NVE2 are associated with IP-VRF1 on NVE2.	and MAC-VRF1 and MAC-VRF3 on NVE2 are associated with IP-VRF1 on NVE2.
	When TS1, TS5, and TS4 exchange traffic with each other, only the L2	When TS1, TS5, and TS4 exchange traffic with each other, only the L2
	forwarding (bridging) part of the IRB solution is exercised because all	forwarding (bridging) part of the IRB solution is exercised because all

	these TSes belong to the same subnet. However, when TS1 wants to exchange	these TSs belong to the same subnet. However, when TS1 wants to exchange
	traffic with TS2 or TS3 which belong to different subnets, both bridging	traffic with TS2 or TS3, which belong to different subnets, both the bridging
	and routing parts of the IRB solution are exercised. The following	and routing parts of the IRB solution are exercised. The following

	subsections describe the control and data planes operations for this IRB	subsections describe the control and data plane operations for this IRB
	scenario in details.</t>	scenario in detail.</t>
		<figure anchor="fig-6">
	<figure title="IRB forwarding on NVEs for Tenant Systems" anchor="fig-6">	<name>IRB Forwarding on NVEs for Tenant Systems</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	NVE1 +---------+	NVE1 +---------+
	+-------------+ \| \|	+-------------+ \| \|
	TS1-----\| MACx\| \| \| NVE2	TS1-----\| MACx\| \| \| NVE2

	(IP1/M1) \|(MAC- \| \| \| +-------------+	(M1/IP1) \|(MAC- \| \| \| +-------------+
	TS5-----\| VRF1)\ \| \| MPLS/ \| \|MACy (MAC- \|-----TS3	TS5-----\| VRF1)\ \| \| MPLS/ \| \|MACy (MAC- \|-----TS3

	(IP5/M5) \| \ \| \| VxLAN/ \| \| / VRF3) \| (IP3/M3)	(M5/IP5) \| \ \| \| VXLAN/ \| \| / VRF3) \| (M3/IP3)
	\| (IP-VRF1)\|----\| NVGRE \|---\|(IP-VRF1) \|	\| (IP-VRF1)\|----\| NVGRE \|---\|(IP-VRF1) \|
	\| / \| \| \| \| \ \|	\| / \| \| \| \| \ \|
	TS2-----\|(MAC- / \| \| \| \| (MAC- \|-----TS4	TS2-----\|(MAC- / \| \| \| \| (MAC- \|-----TS4

	(IP2/M2) \| VRF2) \| \| \| \| VRF1) \| (IP4/M4)	(M2/IP2) \| VRF2) \| \| \| \| VRF1) \| (M4/IP4)
	+-------------+ \| \| +-------------+	+-------------+ \| \| +-------------+
	\| \|	\| \|
	+---------+	+---------+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<section title="Control Plane Operation" anchor="sect-9.1.1"><t>	<section anchor="sect-9.1.1" numbered="true" toc="default">
	Each NVE advertises a MAC/IP Advertisement route (i.e., Route Type 2)	<name>Control Plane Operation</name>
	for each of its TSes with the following field set:</t>	<t>
		Each NVE advertises a MAC/IP Advertisement route (i.e., route type 2)
	<t><list style="symbols"><t>RD and ESI per <xref target="RFC7432"/></t>	for each of its TSs with the following field set:</t>

	<t>Ethernet Tag = 0; assuming VLAN-based service</t>

	<t>MAC Address Length = 48</t>

	<t>MAC Address = Mi ; where i = 1,2,3,4, or 5 in the above example</t>

	<t>IP Address Length = 32 or 128</t>

	<t>IP Address = IPi ; where i = 1,2,3,4, or 5 in the above example</t>

	<t>Label1 = MPLS Label or VNI corresponding to MAC-VRF</t>

	<t>Label2 = MPLS Label or VNI corresponding to IP-VRF</t>

	</list>
	</t>


	<t>	<ul spacing="normal">
		<li>RD and Ethernet Segment Identifier (ESI) per <xref target="RFC74
		32" format="default"/></li>
		<li>Ethernet Tag = 0 (assuming VLAN-based service)</li>
		<li>MAC Address Length = 48</li>
		<li>MAC Address = Mi (where i = 1, 2, 3, 4, or 5) in <xref target="f
		ig-6"/>, above</li>
		<li>IP Address Length = 32 or 128</li>
		<li>IP Address = IPi (where i = 1, 2, 3, 4, or 5) in <xref target="f
		ig-6"/>, above</li>
		<li>Label1 = MPLS label or VNI corresponding to MAC-VRF</li>
		<li>Label2 = MPLS label or VNI corresponding to IP-VRF</li>
		</ul>
		<t>
	Each NVE advertises an EVPN RT-2 route with two Route Targets (one	Each NVE advertises an EVPN RT-2 route with two Route Targets (one

	corresponding to its MAC-VRF and the other corresponding to its IP-VRF.	corresponding to its MAC-VRF and the other corresponding to its IP-VRF).
	Furthermore, the EVPN RT-2 is advertised with two BGP Extended Communities.	Furthermore, the EVPN RT-2 is advertised with two BGP Extended Communities.

	The first BGP Extended Community identifies the tunnel type and it is	The first BGP Extended Community identifies the tunnel type, and it is
	called Encapsulation Extended Community as defined in	called "Encapsulation Extended Community" as defined in
	<xref target="I-D.ietf-idr-tunnel-encaps"/> and the second BGP Extended Commu	<xref target="RFC9012" format="default"/>, and the second BGP Extended Commun
	nity includes	ity includes
	the MAC address of the NVE (e.g., MACx for NVE1 or MACy for NVE2) as	the MAC address of the NVE (e.g., MACx for NVE1 or MACy for NVE2) as

	defined in section 8.1. The Router's MAC Extended community MUST be added	defined in <xref target="sect-8.1"/>. The EVPN Router's MAC Extended Communi
	when Ethernet NVO tunnel is used. If IP NVO tunnel type is used, then	ty <bcp14>MUST</bcp14> be added
		when the Ethernet NVO tunnel is used. If the IP NVO tunnel type is used, the
		n
	there is no need to send this second Extended Community. It should be	there is no need to send this second Extended Community. It should be

	noted that IP NVO tunnel type is only applicable to symmetric IRB	noted that the IP NVO tunnel type is only applicable to symmetric IRB
	procedures.</t>	procedures.</t>

		<t>
	<t>
	Upon receiving this advertisement, the receiving NVE performs the	Upon receiving this advertisement, the receiving NVE performs the
	following:</t>	following:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>It uses Route Targets corresponding to its MA	<li>It uses Route Targets corresponding to its MAC-VRF and IP-VRF fo
	C-VRF and IP-VRF for	r
	identifying these tables and subsequently importing the MAC and IP	identifying these tables and subsequently importing the MAC and IP

	addresses into them respectively.</t>	addresses into them, respectively.</li>
		<li>It imports the MAC address from the MAC/IP Advertisement route i
	<t>It imports the MAC address from MAC/IP Advertisement route into	nto
	the MAC-VRF with BGP Next Hop address as the underlay tunnel	the MAC-VRF with the BGP next-hop address as the underlay tunnel
	destination address (e.g., VTEP DA for VxLAN encapsulation) and	destination address (e.g., VTEP DA for VXLAN encapsulation) and
	Label1 as VNI for VxLAN encapsulation or EVPN label for MPLS	label1 as the VNI for VXLAN encapsulation or an EVPN label for MPLS
	encapsulation.</t>	encapsulation.</li>


	<t>If the route carries the new Router's MAC Extended Community, and	<li>If the route carries the new EVPN Router's MAC Extended Communit
	if the receiving NVE uses Ethernet NVO tunnel, then the receiving	y and
		if the receiving NVE uses an Ethernet NVO tunnel, then the receiving
	NVE imports the IP address into IP-VRF with NVE's MAC address	NVE imports the IP address into IP-VRF with NVE's MAC address

	(from the new Router's MAC Extended Community) as inner MAC DA and	(from the new EVPN Router's MAC Extended Community) as the inner MAC DA, t
	BGP Next Hop address as the underlay tunnel destination address,	he BGP next-hop address as the underlay tunnel destination address, the VTEP DA
	VTEP DA for VxLAN encapsulation and Label2 as IP-VPN VNI for VxLAN	for VXLAN encapsulation, and label2 as the IP-VPN VNI for VXLAN
	encapsulation.</t>	encapsulation.</li>
		<li>If the receiving NVE uses MPLS encapsulation, then the receiving
	<t>If the receiving NVE uses MPLS encapsulation, then the receiving	NVE imports the IP address into IP-VRF with the BGP next-hop address
	NVE imports the IP address into IP-VRF with BGP Next Hop address	as the underlay tunnel destination address and label2 as the IP-VPN
	as the underlay tunnel destination address, and Label2 as IP-VPN	label for MPLS encapsulation.</li>
	label for MPLS encapsulation.</t>	</ul>
		<t>
	</list>	If the receiving NVE receives an EVPN RT-2 with only label1 and only
	</t>	a single Route Target corresponding to IP-VRF; an

	<t>
	If the receiving NVE receives an EVPN RT-2 with only Label1 and only
	a single Route Target corresponding to IP-VRF, or if it receives an
	EVPN RT-2 with only a single Route Target corresponding to MAC-VRF	EVPN RT-2 with only a single Route Target corresponding to MAC-VRF

	but with both Label1 and Label2, or if it receives an EVPN RT-2 with	but with both label1 and label2; or an EVPN RT-2 with a
	MAC Address Length of zero, then it MUST use the treat-as-withdraw	MAC address length of zero, then it <bcp14>MUST</bcp14> use the treat-as-with
	approach <xref target="RFC7606"/> and SHOULD log an error message.</t>	draw
		approach <xref target="RFC7606" format="default"/> and <bcp14>SHOULD</bcp14>
	</section>	log an error message.</t>
		</section>
	<section title="Data Plane Operation" anchor="sect-9.1.2"><t>	<section anchor="sect-9.1.2" numbered="true" toc="default">
	The following description of the data-plane operation describes just	<name>Data Plane Operation</name>
	the logical functions and the actual implementation may differ. Lets	<t>
	consider data-plane operation when TS1 in subnet-1 (MAC-VRF1) on NVE1	The following description of the data plane operation describes just
	wants to send traffic to TS3 in subnet-3 (MAC-VRF3) on NVE2.</t>	the logical functions, and the actual implementation may differ. Let's consid
		er the data plane operation when TS1 in subnet-1 (MAC-VRF1) on NVE1
	<t><list style="symbols"><t>NVE1 receives a packet with MAC DA correspond	wants to send traffic to TS3 in subnet-3 (MAC-VRF3) on NVE2.</t>
	ing to the MAC-VRF1 IRB	<ul spacing="normal">
	interface on NVE1 (the interface between MAC-VRF1 and IP-VRF1), and	<li>NVE1 receives a packet with the MAC DA corresponding to the MAC-
	VLAN-tag corresponding to MAC-VRF1.</t>	VRF1 IRB
		interface on NVE1 (the interface between MAC-VRF1 and IP-VRF1) and
	<t>Upon receiving the packet, the NVE1 uses VLAN-tag to identify the	the VLAN tag corresponding to MAC-VRF1.</li>
		<li>Upon receiving the packet, the NVE1 uses the VLAN tag to identif
		y the
	MAC-VRF1. It then looks up the MAC DA and forwards the frame to	MAC-VRF1. It then looks up the MAC DA and forwards the frame to

	its IRB interface.</t>	its IRB interface.</li>
		<li>The Ethernet header of the packet is stripped, and the packet is
	<t>The Ethernet header of the packet is stripped and the packet is	fed to the IP-VRF, where an IP lookup is performed on the
	fed to the IP-VRF where an IP lookup is performed on the	destination IP address. NVE1 also decrements the TTL / hop limit
	destination IP address. NVE1 also decrements the TTL/hop limit	for that packet by one, and if it reaches zero, NVE1 discards the
	for that packet by one and if it reaches zero, NVE1 discards the
	packet. This lookup yields the outgoing NVO tunnel and the	packet. This lookup yields the outgoing NVO tunnel and the

	required encapsulation. If the encapsulation is for Ethernet NVO	required encapsulation. If the encapsulation is for the Ethernet NVO
	tunnel, then it includes the egress NVE's MAC address as inner MAC	tunnel, then it includes the egress NVE's MAC address as the inner MAC
	DA, the egress NVE's IP address (e.g., BGP Next Hop address) as	DA, the egress NVE's IP address (e.g., BGP next-hop address) as
	the VTEP DA, and the VPN-ID as the VNI. The inner MAC SA and VTEP	the VTEP DA, and the VPN-ID as the VNI. The inner MAC SA and VTEP

	SA are set to NVE's MAC and IP addresses respectively. If it is a	SA are set to NVE's MAC and IP addresses, respectively. If it is an
	MPLS encapsulation, then corresponding EVPN and LSP labels are	MPLS encapsulation, then the corresponding EVPN and LSP labels are
	added to the packet. The packet is then forwarded to the egress	added to the packet. The packet is then forwarded to the egress

	NVE.</t>	NVE.</li>
		<li>If the egress NVE receives a packet from the Ethernet NVO tunnel
	<t>On the egress NVE, if the packet arrives on Ethernet NVO tunnel	(e.g., it is VXLAN encapsulated),
	(e.g., it is VxLAN encapsulated), then the NVO tunnel header is	then it removes the Ethernet header. Since the inner MAC DA is the egress NVE's
	removed. Since the inner MAC DA is the egress NVE's MAC address,	MAC address,
	the egress NVE knows that it needs to perform an IP lookup. It	the egress NVE knows that it needs to perform an IP lookup. It
	uses the VNI to identify the IP-VRF table. If the packet is MPLS	uses the VNI to identify the IP-VRF table. If the packet is MPLS
	encapsulated, then the EVPN label lookup identifies the IP-VRF	encapsulated, then the EVPN label lookup identifies the IP-VRF
	table. Next, an IP lookup is performed for the destination TS	table. Next, an IP lookup is performed for the destination TS

	(TS3) which results in an access-facing IRB interface over which	(TS3), which results in an access-facing IRB interface over which
	the packet is sent. Before sending the packet over this	the packet is sent. Before sending the packet over this
	interface, the ARP table is consulted to get the destination TS's	interface, the ARP table is consulted to get the destination TS's

	MAC address. NVE2 also decrements the TTL/hop limit for that	MAC address. NVE2 also decrements the TTL / hop limit for that
	packet by one and if it reaches zero, NVE2 discards the packet.</t>	packet by one, and if it reaches zero, NVE2 discards the packet.</li>
		<li>The IP packet is encapsulated with an Ethernet header, with the
	<t>The IP packet is encapsulated with an Ethernet header with MAC SA	MAC SA
	set to that of IRB interface MAC address (i.e, IRB interface	set to that of the IRB interface MAC address (i.e., the IRB interface
	between MAC-VRF3 and IP-VRF1 on NVE2) and MAC DA set to that of	between MAC-VRF3 and IP-VRF1 on NVE2) and the MAC DA set to that of the
	destination TS (TS3) MAC address. The packet is sent to the	destination TS (TS3) MAC address. The packet is sent to the

	corresponding MAC-VRF (i.e., MAC-VRF3) and after a lookup of MAC	corresponding MAC-VRF (i.e., MAC-VRF3) and, after a lookup of MAC
	DA, is forwarded to the destination TS (TS3) over the	DA, is forwarded to the destination TS (TS3) over the

	corresponding interface.</t>	corresponding interface.</li>
		</ul>
	</list>	<t>
	</t>

	<t>
	In this symmetric IRB scenario, inter-subnet traffic between NVEs	In this symmetric IRB scenario, inter-subnet traffic between NVEs
	will always use the IP-VRF VNI/MPLS label. For instance, traffic	will always use the IP-VRF VNI/MPLS label. For instance, traffic

	from TS2 to TS4 will be encapsulated by NVE1 using NVE2's IP-VRF VNI/	from TS2 to TS4 will be encapsulated by NVE1 using NVE2's IP-VRF VNI/MPLS lab
	MPLS label, as long as TS4's host IP is present in NVE1's IP-VRF.</t>	el, as long as TS4's host IP is present in NVE1's IP-VRF.</t>
		</section>
	</section>	</section>
		<section anchor="sect-9.2" numbered="true" toc="default">
	</section>	<name>IRB Forwarding on NVEs for Subnets behind Tenant Systems</name>
		<t>
	<section title="IRB forwarding on NVEs for Subnets behind Tenant Systems"
	anchor="sect-9.2"><t>
	This section covers the symmetric IRB procedures for the scenario where	This section covers the symmetric IRB procedures for the scenario where

	some Tenant Systems (TSes) support one or more subnets and these TSes are	some TSs support one or more subnets and these TSs are
	associated with one or more NVEs. Therefore, besides the advertisement of	associated with one or more NVEs. Therefore, besides the advertisement of

	MAC/IP addresses for each TS which can be multi-homed with All-Active	MAC/IP addresses for each TS, which can be multihomed with All-Active
	redundancy mode, the associated NVE needs to also advertise the subnets	redundancy mode, the associated NVE needs to also advertise the subnets
	statically configured on each TS.</t>	statically configured on each TS.</t>

		<t>
	<t>
	The main difference between this solution and the previous one is the	The main difference between this solution and the previous one is the
	additional advertisement corresponding to each subnet. These subnet	additional advertisement corresponding to each subnet. These subnet
	advertisements are accomplished using the EVPN IP Prefix route	advertisements are accomplished using the EVPN IP Prefix route

	defined in <xref target="I-D.ietf-bess-evpn-prefix-advertisement"/>. These s ubnet	defined in <xref target="RFC9136" format="default"/>. These subnet
	prefixes are advertised with the IP address of their associated TS	prefixes are advertised with the IP address of their associated TS

	(which is in overlay address space) as their next hop. The receiving	(which is in an overlay address space) as their next hop. The receiving
	NVEs perform recursive route resolution to resolve the subnet prefix	NVEs perform recursive route resolution to resolve the subnet prefix
	with its advertising NVE so that they know which NVE to forward the	with its advertising NVE so that they know which NVE to forward the
	packets to when they are destined for that subnet prefix.</t>	packets to when they are destined for that subnet prefix.</t>

		<t>
	<t>
	The advantage of this recursive route resolution is that when a TS	The advantage of this recursive route resolution is that when a TS
	moves from one NVE to another, there is no need to re-advertise any	moves from one NVE to another, there is no need to re-advertise any

	of the subnet prefixes for that TS. All it is needed is to advertise	of the subnet prefixes for that TS. All that is needed is to advertise
	the IP/MAC addresses associated with the TS itself and exercise MAC	the IP/MAC addresses associated with the TS itself and exercise the MAC
	mobility procedures for that TS. The recursive route resolution	Mobility procedures for that TS. The recursive route resolution
	automatically takes care of the updates for the subnet prefixes of	automatically takes care of the updates for the subnet prefixes of
	that TS.</t>	that TS.</t>

		<t>
	<t>	<xref target="fig-7"/> illustrates this scenario where a given tenant (e.g.,
	Figure 7 illustrates this scenario where a given tenant (e.g., an IP-VPN	an IP-VPN
	service) has three subnets represented by MAC-VRF1, MAC-VRF2, and MAC-VRF3	service) has three subnets represented by MAC-VRF1, MAC-VRF2, and MAC-VRF3

	across two NVEs. There are four TSes associated with these three MAC-VRFs	across two NVEs. There are four TSs associated with these three MAC-VRFs
	-- i.e., TS1 is connected to MAC-VRF1 on NVE1, TS2 is connected to MAC-VRF2	-- i.e., TS1 is connected to MAC-VRF1 on NVE1, TS2 is connected to MAC-VRF2

	on NVE1, TS3 is connected to MAC- VRF3 on NVE2, and TS4 is connected to	on NVE1, TS3 is connected to MAC-VRF3 on NVE2, and TS4 is connected to
	MAC-VRF1 on NVE2. TS1 has two subnet prefixes (SN1 and SN2) and TS3 has a	MAC-VRF1 on NVE2. TS1 has two subnet prefixes (SN1 and SN2), and TS3 has a
	single subnet prefix, SN3. The MAC-VRFs on each NVE are associated with	single subnet prefix (SN3). The MAC-VRFs on each NVE are associated with
	their corresponding IP-VRF using their IRB interfaces. When TS4 and TS1	their corresponding IP-VRF using their IRB interfaces. When TS4 and TS1

	exchange intra- subnet traffic, only L2 forwarding (bridging) part of the	exchange intra-subnet traffic, only the L2 forwarding (bridging) part of the
	IRB solution is used (i.e., the traffic only goes through their MAC-VRFs);	IRB solution is used (i.e., the traffic only goes through their MAC-VRFs);
	however, when TS3 wants to forward traffic to SN1 or SN2 sitting behind TS1	however, when TS3 wants to forward traffic to SN1 or SN2 sitting behind TS1

	(inter-subnet traffic), then both bridging and routing parts of the IRB	(inter-subnet traffic), then both the bridging and routing parts of the IRB
	solution are exercised (i.e., the traffic goes through the corresponding	solution are exercised (i.e., the traffic goes through the corresponding

	MAC-VRFs and IP-VRFs). If TS4, for example, wants to reach SN1, it uses	MAC-VRFs and IP-VRFs).

		If TS4, for example, wants to reach SN1, it uses
	its default route and sends the packet to the MAC address associated with	its default route and sends the packet to the MAC address associated with

	the IRB interface on NVE2, NVE2 then makes an IP lookup in its IP-VRF, and	the IRB interface on NVE2; NVE2 then performs an IP lookup in its IP-VRF and
	finds an entry for SN1. The following subsections describe the control and	finds an entry for SN1. The following subsections describe the control and

	data planes operations for this IRB scenario in details.</t>	data plane operations for this IRB scenario in detail.</t>
		<figure anchor="fig-7">
	<figure title="IRB forwarding on NVEs for subnets behind TSes" anchor="fi	<name>IRB Forwarding on NVEs for Subnets behind TSs</name>
	g-7"><artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	NVE1 +----------+	NVE1 +----------+
	SN1--+ +-------------+ \| \|	SN1--+ +-------------+ \| \|
	\|--TS1-----\|(MAC- \ \| \| \|	\|--TS1-----\|(MAC- \ \| \| \|

	SN2--+ IP1/M1 \| VRF1) \ \| \| \|	SN2--+ M1/IP1 \| VRF1) \ \| \| \|
	\| (IP-VRF)\|---\| \|	\| (IP-VRF)\|---\| \|
	\| / \| \| \|	\| / \| \| \|
	TS2-----\|(MAC- / \| \| MPLS/ \|	TS2-----\|(MAC- / \| \| MPLS/ \|

	IP2/M2 \| VRF2) \| \| VxLAN/ \|	M2/IP2 \| VRF2) \| \| VXLAN/ \|
	+-------------+ \| NVGRE \|	+-------------+ \| NVGRE \|
	+-------------+ \| \|	+-------------+ \| \|
	SN3--+--TS3-----\|(MAC-\ \| \| \|	SN3--+--TS3-----\|(MAC-\ \| \| \|

	IP3/M3 \| VRF3)\ \| \| \|	M3/IP3 \| VRF3)\ \| \| \|
	\| (IP-VRF)\|---\| \|	\| (IP-VRF)\|---\| \|
	\| / \| \| \|	\| / \| \| \|
	TS4-----\|(MAC- / \| \| \|	TS4-----\|(MAC- / \| \| \|

	IP4/M4 \| VRF1) \| \| \|	M4/IP4 \| VRF1) \| \| \|
	+-------------+ +----------+	+-------------+ +----------+
	NVE2	NVE2
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	Note that in figure 7, above, SN1 and SN2 are configured on NVE1,	Note that in <xref target="fig-7"/>, above, SN1 and SN2 are configured on NVE
		1,
	which then advertises each in an IP Prefix route. Similarly, SN3 is	which then advertises each in an IP Prefix route. Similarly, SN3 is
	configured on NVE2, which then advertises it in an IP Prefix route.</t>	configured on NVE2, which then advertises it in an IP Prefix route.</t>

		<section anchor="sect-9.2.1" numbered="true" toc="default">
	<section title="Control Plane Operation" anchor="sect-9.2.1"><t>	<name>Control Plane Operation</name>
	Each NVE advertises a Route Type-5 (EVPN RT-5, IP Prefix route	<t>
	defined in <xref target="I-D.ietf-bess-evpn-prefix-advertisement"/>) for each	Each NVE advertises a route type 5 (EVPN RT-5, IP Prefix route
	of its	defined in <xref target="RFC9136" format="default"/>) for each of its
	subnet prefixes with the IP address of its TS as the next hop	subnet prefixes with the IP address of its TS as the next hop

	(gateway address field) as follows:</t>	(Gateway Address field) as follows:</t>

	<t><list style="symbols"><t>RD associated with the IP-VRF</t>

	<t>ESI = 0</t>

	<t>Ethernet Tag = 0;</t>

	<t>IP Prefix Length = 0 to 32 or 0 to 128</t>

	<t>IP Prefix = SNi</t>

	<t>Gateway Address = IPi; IP address of TS</t>

	<t>MPLS Label = 0</t>

	</list>
	</t>


	<t>	<ul spacing="normal">
		<li>RD associated with the IP-VRF</li>
		<li>ESI = 0</li>
		<li>Ethernet Tag = 0</li>
		<li>IP Prefix Length = 0 to 32 or 0 to 128</li>
		<li>IP Prefix = SNi</li>
		<li>Gateway Address = IPi (IP address of TS)</li>
		<li>MPLS Label = 0</li>
		</ul>
		<t>
	This EVPN RT-5 is advertised with one or more Route Targets associated with	This EVPN RT-5 is advertised with one or more Route Targets associated with
	the IP-VRF from which the route is originated.</t>	the IP-VRF from which the route is originated.</t>

		<t>


	<t>	Each NVE also advertises an EVPN RT-2 (MAC/IP Advertisement route)
	Each NVE also advertises an EVPN RT-2 (MAC/IP Advertisement Route)	along with its associated Route Targets and Extended Communities
	along with their associated Route Targets and Extended Communities	for each of its TSs exactly as described in <xref target="sect-9.1.1"/>.</t>
	for each of its TSes exactly as described in section 9.1.1.</t>	<t>

	<t>
	Upon receiving the EVPN RT-5 advertisement, the receiving NVE	Upon receiving the EVPN RT-5 advertisement, the receiving NVE
	performs the following:</t>	performs the following:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>It uses the Route Target to identify the corr	<li>It uses the Route Target to identify the corresponding IP-VRF.</
	esponding IP-VRF</t>	li>
		<li>It imports the IP prefix into its corresponding IP-VRF
	<t>It imports the IP prefix into its corresponding IP-VRF that is
	configured with an import RT that is one of the RTs being carried	configured with an import RT that is one of the RTs being carried

	by the EVPN RT-5 route along with the IP address of the associated	by the EVPN RT-5 route, along with the IP address of the associated
	TS as its next hop.</t>	TS as its next hop.</li>
		</ul>
	</list>	<t>
	</t>	When receiving the EVPN RT-2 advertisement, the receiving NVE imports the

	<t>
	When receiving the EVPN RT-2 advertisement, the receiving NVE imports
	MAC/IP addresses of the TS into the corresponding MAC-VRF and IP-VRF	MAC/IP addresses of the TS into the corresponding MAC-VRF and IP-VRF

	per section 9.1.1. When both routes exist, recursive route	per <xref target="sect-9.1.1"/>. When both routes exist, recursive route
	resolution is performed to resolve the IP prefix (received in EVPN	resolution is performed to resolve the IP prefix (received in EVPN
	RT-5) to its corresponding NVE's IP address (e.g., its BGP next hop).	RT-5) to its corresponding NVE's IP address (e.g., its BGP next hop).

	BGP next hop will be used as the underlay tunnel destination address	The BGP next hop will be used as the underlay tunnel destination address
	(e.g., VTEP DA for VxLAN encapsulation) and Router's MAC will be used	(e.g., VTEP DA for VXLAN encapsulation), and the EVPN Router's MAC will be us
	as inner MAC for VxLAN encapsulation.</t>	ed
		as the inner MAC for VXLAN encapsulation.</t>
	</section>	</section>
		<section anchor="sect-9.2.2" numbered="true" toc="default">
	<section title="Data Plane Operation" anchor="sect-9.2.2"><t>	<name>Data Plane Operation</name>
	The following description of the data-plane operation describes just	<t>
	the logical functions and the actual implementation may differ. Lets	The following description of the data plane operation describes just
	consider data-plane operation when a host on SN1 sitting behind TS1	the logical functions, and the actual implementation may differ. Let's consi
	wants to send traffic to a host sitting behind SN3 behind TS3.</t>	der the data plane operation when a host in SN1 behind TS1 wants to send traffic
		to a host in SN3 behind TS3.</t>
	<t><list style="symbols"><t>TS1 send a packet with MAC DA corresponding t	<ul spacing="normal">
	o the MAC-VRF1 IRB	<li>TS1 sends a packet with MAC DA corresponding to the MAC-VRF1 IRB
	interface of NVE1, and VLAN-tag corresponding to MAC-VRF1.</t>	interface of NVE1 and a VLAN tag corresponding to MAC-VRF1.</li>
		<li>Upon receiving the packet, the ingress NVE1 uses the VLAN tag to
	<t>Upon receiving the packet, the ingress NVE1 uses VLAN-tag to
	identify the MAC-VRF1. It then looks up the MAC DA and forwards	identify the MAC-VRF1. It then looks up the MAC DA and forwards

	the frame to its IRB interface just like section 9.1.1.</t>	the frame to its IRB interface as in <xref target="sect-9.1.1"/>.</li>
		<li>The Ethernet header of the packet is stripped, and the packet is
	<t>The Ethernet header of the packet is stripped and the packet is	fed to the IP-VRF, where an IP lookup is performed on the
	fed to the IP-VRF; where, IP lookup is performed on the	destination address.
	destination address. This lookup yields the fields needed for
	VxLAN encapsulation with NVE2's MAC address as the inner MAC DA,
	NVE'2 IP address as the VTEP DA, and the VNI. MAC SA is set to
	NVE1's MAC address and VTEP SA is set to NVE1's IP address. NVE1
	also decrements the TTL/hop limit for that packet by one and if it
	reaches zero, NVE1 discards the packet.</t>

	<t>The packet is then encapsulated with the proper header based on
	the above info and is forwarded to the egress NVE (NVE2).</t>


	<t>On the egress NVE (NVE2), assuming the packet is VxLAN	This lookup yields the fields needed for
	encapsulated, the VxLAN and the inner Ethernet headers are removed	VXLAN encapsulation with NVE2's MAC address as the inner MAC DA,
		NVE2's IP address as the VTEP DA, and the VNI. The MAC SA is set to
		NVE1's MAC address, and the VTEP SA is set to NVE1's IP address. NVE1
		also decrements the TTL / hop limit for that packet by one, and if it
		reaches zero, NVE1 discards the packet.</li>
		<li>The packet is then encapsulated with the proper header based on
		the above info and is forwarded to the egress NVE (NVE2).</li>
		<li>On the egress NVE (NVE2), assuming the packet is VXLAN
		encapsulated, the VXLAN and the inner Ethernet headers are removed,
	and the resultant IP packet is fed to the IP-VRF associated with	and the resultant IP packet is fed to the IP-VRF associated with

	that the VNI.</t>	that VNI.</li>
		<li>Next, a lookup is performed based on the IP DA (which is in SN3)
	<t>Next, a lookup is performed based on IP DA (which is in SN3) in the	in the
	associated IP-VRF of NVE2. The IP lookup yields the access-facing IRB	associated IP-VRF of NVE2. The IP lookup yields the access-facing IRB
	interface over which the packet needs to be sent. Before sending the	interface over which the packet needs to be sent. Before sending the
	packet over this interface, the ARP table is consulted to get the	packet over this interface, the ARP table is consulted to get the

	destination TS (TS3) MAC address. NVE2 also decrements the TTL/hop	destination TS (TS3) MAC address. NVE2 also decrements the TTL / hop
	limit for that packet by one and if it reaches zero, NVE2 discards the	limit for that packet by one, and if it reaches zero, NVE2 discards the
	packet.</t>	packet.</li>
		<li>The IP packet is encapsulated with an Ethernet header with the M
	<t>The IP packet is encapsulated with an Ethernet header with the MAC	AC
	SA set to that of the access-facing IRB interface of the egress	SA set to that of the access-facing IRB interface of the egress

	NVE (NVE2) and the MAC DA is set to that of destination TS (TS3)	NVE (NVE2), and the MAC DA is set to that of the destination TS (TS3)
	MAC address. The packet is sent to the corresponding MAC-VRF3 and	MAC address. The packet is sent to the corresponding MAC-VRF3 and,
	after a lookup of MAC DA, is forwarded to the destination TS (TS3)	after a lookup of MAC DA, is forwarded to the destination TS (TS3)

	over the corresponding interface.</t>	over the corresponding interface.</li>
		</ul>
	</list>	</section>
	</t>	</section>
		</section>
	</section>	<section anchor="sect-11" numbered="true" toc="default">
		<name>Security Considerations</name>
	</section>	<t>
		The security considerations for Layer 2 forwarding in this document
	</section>	follow those of <xref target="RFC7432" format="default"/> for MPLS encapsulat
		ion and those
	<section title="Acknowledgements" anchor="sect-10"><t>	of <xref target="RFC8365" format="default"/> for VXLAN or NVGRE encapsulation
	The authors would like to thank Sami Boutros, Jeffrey Zhang,	s. This section
	Krzysztof Szarkowicz, Lukas Krattiger and Neeraj Malhotra for their
	valuable comments. The authors would also like to thank Linda
	Dunbar, Florin Balus, Yakov Rekhter, Wim Henderickx, Lucy Yong, and
	Dennis Cai for their feedback and contributions.</t>

	</section>

	<section title="Security Considerations" anchor="sect-11"><t>
	The security considerations for layer-2 forwarding in this document
	follow that of <xref target="RFC7432"/> for MPLS encapsulation and it follows
	that
	of <xref target="RFC8365"/> for VxLAN or NVGRE encapsulations. This section
	describes additional considerations.</t>	describes additional considerations.</t>

		<t>
	<t>	This document describes a set of procedures for inter-subnet
	This document describes a set of procedures for Inter-Subnet	forwarding of tenant traffic across PEs (or NVEs). These procedures
	Forwarding of tenant traffic across PEs (or NVEs). These procedures	include both Layer 2 forwarding and Layer 3 routing on a packet-by-packet bas
	include both layer-2 forwarding and layer-3 routing on a packet by	is. The security consideration for Layer 3 routing in this
	packet basis. The security consideration for layer-3 routing in this	document follows that of <xref target="RFC4365" format="default"/>, with the
	document follows that of <xref target="RFC4365"/> with the exception for the	exception of the
	application of routing protocols between CEs and PEs. Contrary to	application of routing protocols between CEs and PEs. Contrary to

	<xref target="RFC4364"/>, this document does not describe route distribution	<xref target="RFC4364" format="default"/>, this document does not describe ro
	techniques between CEs and PEs, but rather considers the CEs as TSes	ute distribution
		techniques between CEs and PEs but rather considers the CEs as TSs
	or VAs that do not run dynamic routing protocols. This can be	or VAs that do not run dynamic routing protocols. This can be
	considered a security advantage, since dynamic routing protocols can	considered a security advantage, since dynamic routing protocols can
	be blocked on the NVE/PE ACs, not allowing the tenant to interact	be blocked on the NVE/PE ACs, not allowing the tenant to interact
	with the infrastructure's dynamic routing protocols.</t>	with the infrastructure's dynamic routing protocols.</t>

		<t>
	<t>
	The VPN scheme described in this document does not provide the	The VPN scheme described in this document does not provide the

	quartet of security properties mentioned in <xref target="RFC4365"/>	quartet of security properties mentioned in <xref target="RFC4365" format="de fault"/>
	(confidentiality protection, source authentication, integrity	(confidentiality protection, source authentication, integrity

	protection, replay protection). If these are desired, they must be	protection, and replay protection). If these are desired, they must be
	provided by mechanisms that are outside the scope of the VPN	provided by mechanisms that are outside the scope of the VPN
	mechanisms.</t>	mechanisms.</t>

		<t>
	<t>
	In this document, the EVPN RT-5 is used for certain scenarios. This	In this document, the EVPN RT-5 is used for certain scenarios. This
	route uses an Overlay Index that requires a recursive resolution to a	route uses an Overlay Index that requires a recursive resolution to a
	different EVPN route (an EVPN RT-2). Because of this, it is worth	different EVPN route (an EVPN RT-2). Because of this, it is worth
	noting that any action that ends up filtering or modifying the EVPN	noting that any action that ends up filtering or modifying the EVPN

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

		</section>
		<section anchor="sect-12" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>
		IANA has allocated Sub-Type value 0x03 in the "EVPN Extended Community Sub
		-Types” registry as follows:</t>


	</section>	<table anchor="IANA_table">
		<name></name>
		<thead>
		<tr>
		<th>Sub-Type Value</th>
		<th>Name</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0x03</td>
		<td>EVPN Router's MAC Extended Community</td>
		<td>RFC 9135</td>
		</tr>
		</tbody>
		</table>


	<section title="IANA Considerations" anchor="sect-12"><t>	<t>
	IANA has allocated a new transitive extended community Type of 0x06	This document has been listed as an additional reference for the MAC/IP Adver
	and Sub-Type of 0x03 for EVPN Router's MAC Extended Community.</t>	tisement route in the "EVPN Route Types" registry.</t>
		</section>
		</middle>
		<back>


	<t>	<displayreference target="I-D.ietf-bess-evpn-irb-extended-mobility" to="EXTENDED
	This document has been listed as an additional reference for the MAC/	-MOBILITY"/>
	IP Advertisement route in the EVPN Route Type registry.</t>	<displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="VXLAN-GPE"/>
		<displayreference target="I-D.ietf-bess-evpn-modes-interop" to="EVPN"/>


	</section>	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>


	</middle>	<reference anchor='RFC9136' target="https://www.rfc-editor.org/info/rfc9136">
		<front>
		<title>IP Prefix Advertisement in Ethernet VPN (EVPN)</title>
		<author initials='J' surname='Rabadan' fullname='Jorge Rabadan' role="editor">
		<organization />
		</author>
		<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
		<organization />
		</author>
		<author initials='J' surname='Drake' fullname='John Drake'>
		<organization />
		</author>
		<author initials='W' surname='Lin' fullname='Wen Lin'>
		<organization />
		</author>
		<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
		<organization />
		</author>
		<date year='2021' month='October' />
		</front>
		<seriesInfo name="RFC" value="9136"/>
		<seriesInfo name="DOI" value="10.17487/RFC9136"/>
		</reference>


	<back>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<references title="Normative References">	FC.9012.xml"/>
	&I-D.ietf-bess-evpn-prefix-advertisement;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&I-D.ietf-idr-tunnel-encaps;	FC.2119.xml"/>
	&RFC2119;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC4364;	FC.4364.xml"/>
	&RFC7348;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC7432;	FC.7432.xml"/>
	&RFC7606;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC7637;	FC.7606.xml"/>
	&RFC8174;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC8365;	FC.8174.xml"/>
	</references>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<references title="Informative References">	FC.8365.xml"/>
	&I-D.ietf-bess-evpn-irb-extended-mobility;	</references>
	&I-D.ietf-nvo3-vxlan-gpe;	<references>
	&RFC4365;	<name>Informative References</name>
	&RFC5798;
	&RFC7365;
	</references>
	</back>


	</rfc>	<reference anchor='I-D.ietf-bess-evpn-modes-interop'>
		<front>
		<title>EVPN Interoperability Modes</title>
		<author initials='L' surname='Krattiger' fullname='Lukas Krattiger' role="editor
		">
		<organization />
		</author>
		<author initials='A' surname='Sajassi' fullname='Ali Sajassi' role="editor">
		<organization />
		</author>
		<author initials='S' surname='Thoria' fullname='Samir Thoria'>
		<organization />
		</author>
		<author initials='J' surname='Rabadan' fullname='Jorge Rabadan'>
		<organization />
		</author>
		<author initials='J' surname='Drake' fullname='John Drake'>
		<organization />
		</author>
		<date year='2021' month='May' day='26' />
		</front>
		<seriesInfo name='Internet-Draft' value='draft-ietf-bess-evpn-modes-interop-00'/
		>
		<format type='TXT' target='https://www.ietf.org/internet-drafts/ draft-ietf-bess
		-evpn-modes-interop-00.txt'/>
		</reference>

		<reference anchor='I-D.ietf-bess-evpn-irb-extended-mobility'>
		<front>
		<title>Extended Mobility Procedures for EVPN-IRB</title>
		<author initials='N' surname='Malhotra' fullname='Neeraj Malhotra' role="editor"
		>
		<organization />
		</author>
		<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
		<organization />
		</author>
		<author initials='A' surname='Pattekar' fullname='Aparna Pattekar'>
		<organization />
		</author>
		<author initials='J' surname='Rabadan' fullname='Jorge Rabadan'>
		<organization />
		</author>
		<author initials='A' surname='Lingala' fullname='Avinash Lingala'>
		<organization />
		</author>
		<author initials='J' surname='Drake' fullname='John Drake'>
		<organization />
		</author>
		<date year='2021' month='October' day='2' />
		<abstract><t>Procedure to handle host mobility in a layer 2 Network with EVPN co
		ntrol plane is defined as part of RFC 7432. EVPN has since evolved to find wide
		r applicability across various IRB use cases that include distributing both MAC
		and IP reachability via a common EVPN control plane. MAC Mobility procedures de
		fined in RFC 7432 are extensible to IRB use cases if a fixed 1:1 mapping between
		VM IP and MAC is assumed across VM moves. Generic mobility support for IP and
		MAC that allows these bindings to change across moves is required to support a b
		roader set of EVPN IRB use cases, and requires further consideration. EVPN all-
		active multihoming further introduces scenarios that require additional consider
		ation from mobility perspective. This document enumerates a set of design consi
		derations applicable to mobility across these EVPN IRB use cases and defines gen
		eric sequence number assignment procedures to address these IRB use cases.</t></
		abstract>
		</front>
		<seriesInfo name='Internet-Draft' value='draft-ietf-bess-evpn-irb-extended-mobil
		ity-07'/>
		<format type='TXT' target='https://www.ietf.org/internet-drafts/draft-ietf-bess-
		evpn-irb-extended-mobility-07.txt'/>
		</reference>

		<reference anchor='I-D.ietf-nvo3-vxlan-gpe'>
		<front>
		<title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
		<author initials='F' surname='Maino' fullname='Fabio Maino' role="editor">
		<organization />
		</author>
		<author initials='L' surname='Kreeger' fullname='Larry Kreeger' role="editor">
		<organization />
		</author>
		<author initials='U' surname='Elzur' fullname='Uri Elzur' role="editor">
		<organization />
		</author>
		<date year='2021' month='September' day='22' />
		<abstract><t>This document describes extending Virtual eXtensible Local Area Net
		work (VXLAN), via changes to the VXLAN header, with four new capabilities: suppo
		rt for multi-protocol encapsulation, support for operations, administration and
		maintenance (OAM) signaling, support for ingress-replicated BUM Traffic (i.e. B
		roadcast, Unknown unicast, or Multicast), and explicit versioning. New protocol
		capabilities can be introduced via shim headers.</t></abstract>
		</front>
		<seriesInfo name='Internet-Draft' value='draft-ietf-nvo3-vxlan-gpe-12'/>
		<format type='TXT' target='https://www.ietf.org/internet-drafts/draft-ietf-nvo3-
		vxlan-gpe-12.txt'/>
		</reference>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7348.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7637.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4365.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5798.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7365.xml"/>
		</references>
		</references>
		<section anchor="sect-10" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>
		The authors would like to thank <contact fullname="Sami Boutros"/>, <contact
		fullname="Jeffrey Zhang"/>,
		<contact fullname="Krzysztof Szarkowicz"/>, <contact fullname="Lukas Krattige
		r"/> and <contact fullname="Neeraj Malhotra"/> for their
		valuable comments. The authors would also like to thank <contact fullname="L
		inda Dunbar"/>, <contact fullname="Florin Balus"/>, <contact fullname="Yakov Rek
		hter"/>, <contact fullname="Wim Henderickx"/>, <contact fullname="Lucy Yong"/>,
		and
		<contact fullname="Dennis Cai"/> for their feedback and contributions.</t>
		</section>
		</back>

		</rfc>

End of changes. 296 change blocks.
	1281 lines changed or deleted	1198 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/