rfc9135.original		rfc9135.txt
	BESS WorkGroup A. Sajassi		Internet Engineering Task Force (IETF) A. Sajassi
	Internet-Draft S. Salam		Request for Comments: 9135 S. Salam
	Intended status: Standards Track S. Thoria		Category: Standards Track S. Thoria
	Expires: January 27, 2022 Cisco Systems		ISSN: 2070-1721 Cisco Systems
	J. Drake		J. Drake
	Juniper		Juniper
	J. Rabadan		J. Rabadan
	Nokia		Nokia
	July 26, 2021		October 2021
	Integrated Routing and Bridging in EVPN		Integrated Routing and Bridging in Ethernet VPN (EVPN)
	draft-ietf-bess-evpn-inter-subnet-forwarding-15
	Abstract		Abstract
	Ethernet VPN (EVPN) provides an extensible and flexible multi-homing		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.		(IRB) solution based on EVPN to address such requirements.
	Requirements Language
	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 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they
	appear in all capitals, as shown here.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute		(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-		received public review and has been approved for publication by the
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	Internet-Drafts are draft documents valid for a maximum of six months		Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any		and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference		https://www.rfc-editor.org/info/rfc9135.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 27, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology
	3. EVPN PE Model for IRB Operation . . . . . . . . . . . . . . . 6		2.1. Requirements Language
	4. Symmetric and Asymmetric IRB . . . . . . . . . . . . . . . . 7		3. EVPN PE Model for IRB Operation
	4.1. IRB Interface and its MAC and IP addresses . . . . . . . 10		4. Symmetric and Asymmetric IRB
	4.2. Operational Considerations . . . . . . . . . . . . . . . 12		4.1. IRB Interface and Its MAC and IP Addresses
	5. Symmetric IRB Procedures . . . . . . . . . . . . . . . . . . 13		4.2. Operational Considerations
	5.1. Control Plane - Advertising PE . . . . . . . . . . . . . 13		5. Symmetric IRB Procedures
	5.2. Control Plane - Receiving PE . . . . . . . . . . . . . . 14		5.1. Control Plane - Advertising PE
	5.3. Subnet route advertisement . . . . . . . . . . . . . . . 15		5.2. Control Plane - Receiving PE
	5.4. Data Plane - Ingress PE . . . . . . . . . . . . . . . . . 16		5.3. Subnet Route Advertisement
	5.5. Data Plane - Egress PE . . . . . . . . . . . . . . . . . 17		5.4. Data Plane - Ingress PE
	6. Asymmetric IRB Procedures . . . . . . . . . . . . . . . . . . 17		5.5. Data Plane - Egress PE
	6.1. Control Plane - Advertising PE . . . . . . . . . . . . . 17		6. Asymmetric IRB Procedures
	6.2. Control Plane - Receiving PE . . . . . . . . . . . . . . 18		6.1. Control Plane - Advertising PE
	6.3. Data Plane - Ingress PE . . . . . . . . . . . . . . . . . 19		6.2. Control Plane - Receiving PE
	6.4. Data Plane - Egress PE . . . . . . . . . . . . . . . . . 19		6.3. Data Plane - Ingress PE
	7. Mobility Procedure . . . . . . . . . . . . . . . . . . . . . 20		6.4. Data Plane - Egress PE
	7.1. Initiating a gratutious ARP upon a Move . . . . . . . . . 21		7. Mobility Procedure
	7.2. Sending Data Traffic without an ARP Request . . . . . . . 22		7.1. Initiating a Gratuitous ARP upon a Move
	7.3. Silent Host . . . . . . . . . . . . . . . . . . . . . . . 24		7.2. Sending Data Traffic without an ARP Request
	8. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 24		7.3. Silent Host
	8.1. Router's MAC Extended Community . . . . . . . . . . . . . 25		8. BGP Encoding
	9. Operational Models for Symmetric Inter-Subnet Forwarding . . 25		8.1. EVPN Router's MAC Extended Community
	9.1. IRB forwarding on NVEs for Tenant Systems . . . . . . . . 25		9. Operational Models for Symmetric Inter-Subnet Forwarding
	9.1.1. Control Plane Operation . . . . . . . . . . . . . . . 27		9.1. IRB Forwarding on NVEs for Tenant Systems
	9.1.2. Data Plane Operation . . . . . . . . . . . . . . . . 28		9.1.1. Control Plane Operation
	9.2. IRB forwarding on NVEs for Subnets behind Tenant Systems 30		9.1.2. Data Plane Operation
	9.2.1. Control Plane Operation . . . . . . . . . . . . . . . 31		9.2. IRB Forwarding on NVEs for Subnets behind Tenant Systems
	9.2.2. Data Plane Operation . . . . . . . . . . . . . . . . 32		9.2.1. Control Plane Operation
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33		9.2.2. Data Plane Operation
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 33		10. Security Considerations
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		11. IANA Considerations
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		12. References
	13.1. Normative References . . . . . . . . . . . . . . . . . . 34		12.1. Normative References
	13.2. Informative References . . . . . . . . . . . . . . . . . 35		12.2. Informative References
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Acknowledgements
			Authors' Addresses
	1. Terminology		1. Introduction
	AC: Attachment Circuit		EVPN [RFC7432] provides an extensible and flexible multihoming VPN
			solution over an MPLS/IP network for intra-subnet connectivity among
			Tenant Systems (TSs) and end devices that can be physical or virtual,
			where an IP subnet is represented by an EVPN instance (EVI) for a
			VLAN-based service or by an (EVI, VLAN) association for a VLAN-aware
			bundle service. However, there are scenarios for which there is a
			need for a dynamic and efficient inter-subnet connectivity among
			these Tenant Systems and end devices while maintaining the
			multihoming capabilities of EVPN. This document describes an
			Integrated Routing and Bridging (IRB) solution based on EVPN to
			address such requirements.
	ARP: Address Resolution Protocol		Inter-subnet communication is typically performed by centralized
			Layer 3 (L3) gateway (GW) devices, which enforce all inter-subnet
			communication policies and perform all inter-subnet forwarding. When
			two TSs belonging to two different subnets connected to the same
			Provider Edge (PE) wanted to communicate with each other, their
			traffic needed to be backhauled from the PE all the way to the
			centralized gateway where inter-subnet switching is performed and
			then sent back to the PE. For today's large multi-tenant Data Center
			(DC), this scheme is very inefficient and sometimes impractical.
	ARP table: A logical view of a forwarding table on a PE that		In order to overcome the drawback of the centralized L3 GW approach,
	maintains an IP to MAC binding entry on an IP interface for both IPv4		IRB functionality is needed on the PEs (also referred to as EVPN
	and IPv6. These entries are learned through ARP/ND or through EVPN.		Network Virtualization Edges (NVEs)) attached to TSs in order to
			avoid inefficient forwarding of tenant traffic (i.e., avoid
			backhauling and hair pinning). When a PE with IRB capability
			receives tenant traffic over an Attachment Circuit (AC), it cannot
			only locally bridge the tenant intra-subnet traffic but also locally
			route the tenant inter-subnet traffic on a packet-by-packet basis,
			thus meeting the requirements for both intra- and inter-subnet
			forwarding and avoiding non-optimal traffic forwarding associated
			with a centralized L3 GW approach.
	Broadcast Domain: As per [RFC7432], an EVI consists of a single or		Some TSs run non-IP protocols in conjunction with their IP traffic.
	multiple broadcast domains. In the case of VLAN-bundle and VLAN-		Therefore, it is important to handle both kinds of traffic optimally
	based service models (see [RFC7432]), a broadcast domain is		-- e.g., to bridge non-IP and intra-subnet traffic and to route
	equivalent to an EVI. In the case of VLAN-aware bundle service		inter-subnet IP traffic. Therefore, the solution needs to meet the
	model, an EVI contains multiple broadcast domains. Also, in this		following requirements:
	document, broadcast domain and subnet are equivalent terms and
	wherever "subnet" is used, it means "IP subnet"
	Broadcast Domain Route Target: refers to the Broadcast Domain		R1: The solution must provide each tenant with IP routing of its
	assigned Route Target [RFC4364]. In the case of VLAN-aware bundle		inter-subnet traffic and Ethernet bridging of its intra-subnet
	service model, all the broadcast domain instances in the MAC-VRF		traffic and non-routable traffic, where non-routable traffic
	share the same Route Target		refers to both non-IP traffic and IP traffic whose version differs
			from the IP version configured in IP Virtual Routing and
			Forwarding (IP-VRF). For example, if an IP-VRF in an NVE is
			configured for IPv6 and that NVE receives IPv4 traffic on the
			corresponding VLAN, then the IPv4 traffic is treated as non-
			routable traffic.
	Bridge Table: The instantiation of a broadcast domain in a MAC-VRF,		R2: The solution must allow IP routing of inter-subnet traffic to be
	as per [RFC7432].		disabled on a per-VLAN basis on those PEs that are backhauling
			that traffic to another PE for routing.
	Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels		2. Terminology
	with Ethernet payload as specified for VxLAN in [RFC7348] and for
	NVGRE in [RFC7637].
	EVI: EVPN Instance spanning the NVE/PE devices that are participating		AC: Attachment Circuit
	on that EVPN, as per [RFC7432].
	EVPN: Ethernet Virtual Private Networks, as per [RFC7432].		ARP: Address Resolution Protocol
	IP NVO tunnel: it refers to Network Virtualization Overlay tunnels		ARP Table: A logical view of a forwarding table on a PE that
	with IP payload (no MAC header in the payload) as specified for GPE		maintains an IP to a MAC binding entry on an IP interface
	in [I-D.ietf-nvo3-vxlan-gpe].		for both IPv4 and IPv6. These entries are learned through
			ARP/ND or through EVPN.
	IP-VRF: A Virtual Routing and Forwarding table for IP routes on an		BD: Broadcast Domain. As per [RFC7432], an EVI consists of a
	NVE/PE. The IP routes could be populated by EVPN and IP-VPN address		single BD or multiple BDs. In the case of VLAN-bundle and
	families. An IP-VRF is also an instantiation of a layer 3 VPN in an		VLAN-based service models (see [RFC7432]), a BD is
	NVE/PE.		equivalent to an EVI. In the case of a VLAN-aware bundle
			service model, an EVI contains multiple BDs. Also, in this
			document, "BD" and "subnet" are equivalent terms, and
			wherever "subnet" is used, it means "IP subnet".
	IRB: Integrated Routing and Bridging interface. It connects an IP-		BD Route Target: Refers to the broadcast-domain-assigned Route
	VRF to a broadcast domain (or subnet).		Target [RFC4364]. In the case of a VLAN-aware bundle
			service model, all the BD instances in the MAC-VRF share
			the same Route Target.
	MAC-VRF: A Virtual Routing and Forwarding table for Media Access		BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as
	Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is		per [RFC7432].
	also an instantiation of an EVI in an NVE/PE.
	ND: Neighbor Discovery Protocol		CE: Customer Edge
	NVE: Network Virtualization Edge		DA: Destination Address
	NVGRE: Network Virtualization Generic Routing Encapsulation,		Ethernet NVO Tunnel: Refers to Network Virtualization Overlay
	[RFC7637]		tunnels with an Ethernet payload, as specified for VXLAN in
			[RFC7348] and for NVGRE in [RFC7637].
	NVO: Network Virtualization Overlays		EVI: EVPN Instance spanning NVE/PE devices that are
			participating on that EVPN, as per [RFC7432].
	RT-2: EVPN route type 2, i.e., MAC/IP Advertisement route, as defined		EVPN: Ethernet VPN, as per [RFC7432].
	in [RFC7432]
	RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in		IP NVO Tunnel: Refers to Network Virtualization Overlay tunnels with
	Section 3 of [I-D.ietf-bess-evpn-prefix-advertisement]		IP payload (no MAC header in the payload) as specified for
			Generic Protocol Extension (GPE) in [VXLAN-GPE].
	TS: Tenant System		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.
	VA: Virtual Appliance		IRB: Integrated Routing and Bridging interface. It connects an
			IP-VRF to a BD (or subnet).
	VNI: Virtual Network Identifier. As in [RFC8365], the term is used		MAC: Media Access Control
	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.
	VTEP: VXLAN Termination End Point, as in [RFC7348].		MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on
			an NVE/PE, as per [RFC7432]. A MAC-VRF is also an
			instantiation of an EVI in an NVE/PE.
	VXLAN: Virtual Extensible LAN, as in [RFC7348].		ND: Neighbor Discovery
	This document also assumes familiarity with the terminology of		NVE: Network Virtualization Edge
	[RFC7432], [RFC8365] and [RFC7365].
	2. Introduction		NVGRE: Network Virtualization Using Generic Routing Encapsulation,
			as per [RFC7637].
	EVPN [RFC7432] provides an extensible and flexible multi-homing VPN		NVO: Network Virtualization Overlay
	solution over an MPLS/IP network for intra-subnet connectivity among
	Tenant Systems (TSes) and End Devices that can be physical or
	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
	service. However, there are scenarios for which there is a need for
	a dynamic and efficient inter-subnet connectivity among these Tenant
	Systems and End Devices while maintaining the multi-homing
	capabilities of EVPN. This document describes an Integrated Routing
	and Bridging (IRB) solution based on EVPN to address such
	requirements.
	The inter-subnet communication is traditionally achieved at		PE: Provider Edge
	centralized L3 Gateway (L3GW) devices where all the inter-subnet
	forwarding is performed and all the inter-subnet communication
	policies are enforced. When two TSes belonging to two different
	subnets connected to the same PE wanted to communicate with each
	other, their traffic needed to be backhauled from the PE all the way
	to the centralized gateway where inter-subnet switching is performed
	and then back to the PE. For today's large multi-tenant data center,
	this scheme is very inefficient and sometimes impractical.
	In order to overcome the drawback of the centralized layer-3 GW		RT-2: EVPN Route Type 2, i.e., MAC/IP Advertisement route, as
	approach, IRB functionality is needed on the PEs (also referred to as		defined in [RFC7432].
	EVPN NVEs) attached to TSes in order to avoid inefficient forwarding
	of tenant traffic (i.e., avoid back-hauling and hair-pinning). When
	a PE with IRB capability receives tenant traffic over an Attachment
	Circuit (AC), it can not only locally bridge the tenant intra-subnet
	traffic but also can locally route the tenant inter-subnet traffic on
	a packet by packet basis thus meeting the requirements for both intra
	and inter-subnet forwarding and avoiding non-optimal traffic
	forwarding associated with centralized layer-3 GW approach.
	Some TSes run non-IP protocols in conjunction with their IP traffic.		RT-5: EVPN Route Type 5, i.e., IP Prefix route, as defined in
	Therefore, it is important to handle both kinds of traffic optimally		Section 3 of [RFC9136].
	- 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 requirements:
	R1: The solution must provide each tenant with IP routing of its		SA: Source Address
	inter-subnet traffic and Ethernet bridging of its intra-subnet
	traffic and non-routable traffic, where non-routable traffic refers
	both to 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
	NVE is configured for IPv6 and that NVE receives IPv4 traffic on the
	corresponding VLAN, then the IPv4 traffic is treated as non-routable
	traffic.
	R2: The solution must allow IP routing of inter-subnet traffic to be		TS: Tenant System
	disabled on a per-VLAN basis on those PEs that are backhauling that
	traffic to another PE for routing.		VA: Virtual Appliance
			VNI: Virtual Network Identifier. As in [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 a Virtual Subnet
			Identifier in NVGRE, etc., unless it is stated otherwise.
			VTEP: VXLAN Termination End Point, as per [RFC7348].
			VXLAN: Virtual eXtensible Local Area Network, as per [RFC7348].
			This document also assumes familiarity with the terminology of
			[RFC7365], [RFC7432], and [RFC8365].
			2.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. EVPN PE Model for IRB Operation		3. EVPN PE Model for IRB Operation
	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
	interfaces, it is important to understand the relationship between		important to understand the relationship between these components.
	these components. Therefore, the following PE model is illustrated		Therefore, the PE model is illustrated below to a) describe these
	below to a) describe these components and b) illustrate the		components and b) illustrate the relationship among them.
	relationship among them.
	+-------------------------------------------------------------+		+-------------------------------------------------------------+
	| |		| |
	| +------------------+ 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 page 6, line 44 ¶		skipping to change at line 285 ¶
	| | | | *---------* |<--> |IP |		| | | | *---------* |<--> |IP |
	----------------------* VLAN y | | +-----------+ \ / /		----------------------* VLAN y | | +-----------+ \ / /
	| AC2 | | +----------+ | +-----		| AC2 | | +----------+ | +-----
	| | | MAC-VRF1 | |		| | | MAC-VRF1 | |
	| +-+ RD1/RT1 | |		| +-+ RD1/RT1 | |
	| +------------------+ |		| +------------------+ |
	| |		| |
	| |		| |
	+-------------------------------------------------------------+		+-------------------------------------------------------------+
	Figure 1: EVPN IRB PE Model		Figure 1: EVPN IRB PE Model
	A tenant needing IRB services on a PE, requires an IP Virtual Routing		A tenant needing IRB services on a PE requires an IP-VRF table along
	and Forwarding table (IP-VRF) along with one or more MAC Virtual		with one or more MAC-VRF tables. An IP-VRF, as defined in [RFC4364],
	Routing and Forwarding tables (MAC-VRFs). An IP-VRF, as defined in		is the instantiation of an IP-VPN instance in a PE. A MAC-VRF, as
	[RFC4364], is the instantiation of an IPVPN instance in a PE. A MAC-		defined in [RFC7432], is the instantiation of an EVI in a PE. A MAC-
	VRF, as defined in [RFC7432], is the instantiation of an EVI (EVPN		VRF consists of one or more bridge tables, where each bridge table
	Instance) in a PE. A MAC-VRF consists of one or more bridge tables,		corresponds to a VLAN (broadcast domain). If service interfaces for
	where each bridge table corresponds to a VLAN (broadcast domain). If		an EVPN PE are configured in VLAN-based mode (i.e., Section 6.1 of
	service interfaces for an EVPN PE are configured in VLAN- Based mode		[RFC7432]), then there is only a single bridge table per MAC-VRF (per
	(i.e., section 6.1 of RFC7432), then there is only a single bridge		EVI) -- i.e., there is only one tenant VLAN per EVI. However, if
	table per MAC-VRF (per EVI) - i.e., there is only one tenant VLAN per		service interfaces for an EVPN PE are configured in VLAN-aware bundle
	EVI. However, if service interfaces for an EVPN PE are configured in		mode (i.e., Section 6.3 of [RFC7432]), then there are several bridge
	VLAN-Aware Bundle mode (i.e., section 6.3 of RFC7432), then there are		tables per MAC-VRF (per EVI) -- i.e., there are several tenant VLANs
	several bridge tables per MAC-VRF (per EVI) - i.e., there are several		per EVI.
	tenant VLANs per EVI.
	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
	in this document) represented by a VLAN (and thus supported by a		(and 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.		as shown in the PE model above.
	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		Distinguisher, and MAC-VRF is also identified by its corresponding
	route target and route distinguisher. If operating in EVPN VLAN-		Route Target and Route Distinguisher. If operating in EVPN VLAN-
	Based mode, then a receiving PE that receives an EVPN route with MAC-		based mode, then a receiving PE that receives an EVPN route with a
	VRF route target can identify the corresponding bridge table;		MAC-VRF Route Target can identify the corresponding bridge table;
	however, if operating in EVPN VLAN-Aware Bundle mode, then the		however, if operating in EVPN VLAN-aware bundle mode, then the
	receiving PE needs both the MAC-VRF route target and VLAN ID in order		receiving PE needs both the MAC-VRF Route Target and VLAN ID in order
	to identify the corresponding bridge table.		to identify the corresponding bridge table.
	4. Symmetric and Asymmetric IRB		4. Symmetric and Asymmetric IRB
	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,		Specifically,
	o References to ARP table in the context of asymmetric IRB is a		* References to an ARP table in the context of asymmetric 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 protocol. For IP to		These entries are not subject to ARP or ND protocols. For IP-to-
	MAC bindings learnt via EVPN, an implementation may choose to		MAC bindings learned 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.		to ARP or ND protocol tables.
	o References to host IP lookup followed by a host MAC lookup in the		* References to a host IP lookup followed by a host MAC lookup in
	context of asymmetric IRB MAY be collapsed into a single IP lookup		the context of asymmetric IRB MAY be collapsed into a single IP
	in a hardware implementation.		lookup in a hardware implementation.
	In symmetric IRB as its name implies, the lookup operation is		In symmetric IRB, as its name implies, the lookup operation is
	symmetric at both ingress and egress PEs - i.e., both ingress and		symmetric at both the ingress and egress PEs -- i.e., both ingress
	egress PEs perform lookups on both MAC and IP addresses. The ingress		and egress PEs perform lookups on both MAC and IP addresses. The
	PE performs a MAC lookup followed by an IP lookup and the egress PE		ingress PE performs a MAC lookup followed by an IP lookup, and the
	performs an IP lookup followed by a MAC lookup as depicted in the		egress PE performs an IP lookup followed by a MAC lookup, as depicted
	following figure.		in the following figure.
	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
	Figure 2: Symmetric IRB
	In symmetric IRB as shown in figure-2, the inter-subnet forwarding		Figure 2: Symmetric IRB
			In symmetric IRB, as shown in Figure 2, the inter-subnet forwarding
	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
	(e.g., in case of VxLAN encapsulation). If it is an Ethernet NVO		tunnel (e.g., in the case of VXLAN encapsulation). If it is an
	tunnel, the TS1's IP packet is encapsulated in an Ethernet header		Ethernet NVO tunnel, the TS1's IP packet is encapsulated in an
	consisting of ingress and egress PEs MAC addresses - i.e., there is		Ethernet header consisting of ingress and egress PE MAC addresses --
	no need for ingress PE to use the destination TS2's MAC address.		i.e., there is no need for the ingress PE to use the destination
	Therefore, in symmetric IRB, there is no need for the ingress PE to		TS2's MAC address. Therefore, in symmetric IRB, there is no need for
	maintain ARP entries for destination TS2's IP and MAC addresses		the ingress PE to maintain ARP entries for the association of the
	association in its ARP table. Each PE participating in symmetric IRB		destination TS2's IP and MAC addresses in its ARP table. Each PE
	only maintains ARP entries for locally connected hosts and maintains		participating in symmetric IRB only maintains ARP entries for locally
	MAC-VRFs/bridge tables for only locally configured subnets.		connected hosts and MAC-VRFs/BTs for only locally configured subnets.
	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
	performs just a single MAC lookup as depicted in figure 3 below.		just a single MAC lookup as depicted in Figure 3 below.
	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
	Figure 3: Asymmetric IRB
	In asymmetric IRB as shown in figure-3, the inter-subnet forwarding		Figure 3: Asymmetric IRB
	between two PEs is done between their associated MAC-VRFs/bridge
	tables. Therefore, the MPLS or NVO tunnel used for inter-subnet		In asymmetric IRB, as shown in Figure 3, the inter-subnet forwarding
	forwarding MUST be of type Ethernet. Since only MAC lookup is		between two PEs is done between their associated MAC-VRFs/BTs.
	performed at the egress PE (e.g., no IP lookup), the TS1's IP packets		Therefore, the MPLS or NVO tunnel used for inter-subnet forwarding
	need to be encapsulated with the destination TS2's MAC address. In		MUST be of type Ethernet. Since only MAC lookup is performed at the
	order for ingress PE to perform such encapsulation, it needs to		egress PE (e.g., no IP lookup), the TS1's IP packets need to be
	maintain TS2's IP and MAC address association in its ARP table.		encapsulated with the destination TS2's MAC address. In order for
	Furthermore, it needs to maintain destination TS2's MAC address in		the ingress PE to perform such encapsulation, it needs to maintain
	the corresponding bridge table even though it may not have any TSes		TS2's IP and MAC address association in its ARP table. Furthermore,
	of the corresponding subnet locally attached. In other words, each		it needs to maintain destination TS2's MAC address in the
	PE participating in asymmetric IRB MUST maintain ARP entries for		corresponding bridge table even though it may not have any TSs of the
	remote hosts (hosts connected to other PEs) as well as maintain MAC-		corresponding subnet locally attached. In other words, each PE
	VRFs/bridge tables and IRB interfaces for ALL subnets in an IP VRF		participating in asymmetric IRB MUST maintain ARP entries for remote
	including subnets that may not be locally attached. Therefore,		hosts (hosts connected to other PEs) as well as maintain MAC-VRFs/BTs
	careful consideration of PE scale aspects for its ARP table size, its		and IRB interfaces for ALL subnets in an IP-VRF, including subnets
	IRB interfaces, number and size of its bridge tables should be given		that may not be locally attached. Therefore, careful consideration
	for the application of asymmetric IRB.		of the PE scale aspects for its ARP table size, its IRB interfaces,
			and the number and size of its bridge tables should be given for the
			application of asymmetric IRB.
	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
	decremented by one and if it reaches zero, the packet is discarded.		for that packet is decremented by one, and if it reaches zero, the
	In the case of symmetric IRB, the TTL/hop limit is decremented by		packet is discarded. In the case of symmetric IRB, the TTL / hop
	both ingress and egress PEs (once by each); whereas, in the case of		limit is decremented by both ingress and egress PEs (once by each),
	asymmetric IRB, the TTL/hop limit is decremented only once by the		whereas in the case of asymmetric IRB, the TTL / hop limit is
	ingress PE.		decremented only once by the ingress PE.
	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.
	given tenant. I.e., an IP-VRF connects one or more EVIs, each EVI		That is, an IP-VRF connects one or more EVIs, and each EVI contains
	contains one MAC-VRF, each MAC VRF consists of one or more bridge		one MAC-VRF; each MAC VRF consists of one or more bridge tables, one
	tables, one per broadcast domain, and a PE has an associated IRB		per BD; and a PE has an associated IRB interface for each BD.
	interface for each broadcast domain.
	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)
	+-------------+ | | +-------------+		+-------------+ | | +-------------+
	| |		| |
	+---------+		+---------+
	Figure 4: IRB forwarding		Figure 4: IRB Forwarding
	4.1. IRB Interface and its MAC and IP addresses		4.1. IRB Interface and Its MAC and IP Addresses
	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:		following two options:
	1. All the PEs for a given tenant subnet use the same anycast		1. All the PEs for a given tenant subnet use the same anycast
	default gateway IP and MAC addresses. On each PE, this default		default gateway IP and MAC addresses. On each PE, these 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.		the corresponding tenant's IP-VRF.
	2. Each PE for a given tenant subnet uses the same anycast default		2. Each PE for a given tenant subnet uses the same anycast 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 [RFC7432], which is carried in the EVPN MAC/IP		specified in [RFC7432], 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
	IRB interface connecting the bridge table associated with the		the IRB interface connecting the bridge table associated with the
	tenant's VLAN to the corresponding tenant's IP-VRF.		tenant's VLAN to the corresponding tenant's IP-VRF.
	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
	is used, then the IRB interface MAC address MUST be the one used in		option is used, then the IRB interface MAC address MUST be the one
	the initial ARP reply or ND Neighbor Advertisement (NA)for that TS.		used in the initial ARP reply or ND Neighbor Advertisement (NA) for
			that TS.
	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, option 1 is recommended 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.		default GW ARP/ND entry.
	If option-1 is used, an implementation MAY choose to auto-derive the		If option 1 is used, an implementation MAY 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		MUST be auto-derived out of the following ranges (which are defined
	in [RFC5798]):		in [RFC5798]):
	o Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID}		* Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID}
	o Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID}		* Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID}
	Where the last octet is generated based on a configurable Virtual		Where the last octet is generated based on a configurable Virtual
	Router ID (VRID, range 1-255)). If not explicitly configured, the		Router ID (VRID) (range 1-255). If not explicitly configured, the
	default value for the VRID octet is '1'. Auto-derivation of the		default value for the VRID octet is '1'. Auto-derivation of the
	anycast MAC can only be used if there is certainty that the auto-		anycast MAC can only be used if there is certainty that the auto-
	derived MAC does not collide with any customer MAC address.		derived MAC does not collide with any customer MAC address.
	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
	traceroute/ping to these interfaces) for both symmetric and		a traceroute/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.		advertisement.
	For option-1, irrespective of using only the anycast MAC address or		For option 1 -- irrespective of whether only the anycast MAC address
	both anycast and non-anycast MAC addresses (where the latter one is		or both anycast and non-anycast MAC addresses (where the latter one
	used for the purpose of OAM) on the same IRB, when a TS sends an ARP		is used for the purpose of OAM) are used on the same IRB -- when a TS
	request or ND Neighbor Solicitation (NS) to the PE that is attached		sends an ARP request or ND Neighbor Solicitation (NS) to the PE to
	to, the request is sent for the anycast IP address of the IRB		which it is attached, the request is sent for the anycast IP address
	interface associated with the TS's subnet and then the reply will use		of the IRB interface associated with the TS's subnet. The reply will
	anycast MAC address (in both Source MAC in the Ethernet header and		use an anycast MAC address (in both the source MAC in the Ethernet
	Sender hardware address in the payload). For example, in figure 4,		header and sender hardware address in the payload). For example, in
	TS1 is configured with the anycast IPx address as its default gateway		Figure 4, TS1 is configured with the anycast IPx address as its
	IP address and thus when it sends an ARP request for IPx (anycast IP		default gateway IP address; thus, when it sends an ARP request for
	address of the IRB interface for BT1), the PE1 sends an ARP reply		IPx (anycast IP address of the IRB interface for BT1), the PE1 sends
	with the MACx which is the anycast MAC address of that IRB interface.		an ARP reply with the MACx, which is the anycast MAC address of that
	Traffic routed from IP-VRF1 to TS1 uses the anycast MAC address as		IRB interface. Traffic routed from IP-VRF1 to TS1 uses the anycast
	source MAC address.		MAC address as the source MAC address.
	4.2. Operational Considerations		4.2. Operational Considerations
	Symmetric and Asymmetric IRB modes may coexist in the same network,		Symmetric and asymmetric IRB modes may coexist in the same network,
	and an ingress PE that supports both forwarding modes for a given		and an ingress PE that supports both forwarding modes for a given
	tenant can interwork with egress PEs that support either IRB mode.		tenant can interwork with egress PEs that support either IRB mode.
	The egress PE will indicate the desired forwarding mode for a given		The egress PE will indicate the desired forwarding mode for a given
	host based on the presence of the Label2 field and the IP-VRF route-		host based on the presence of the Label2 field and the IP-VRF Route
	target in the EVPN MAC/IP Advertisement route. If the Label2 field		Target in the EVPN MAC/IP Advertisement route. If the Label2 field
	of the received MAC/IP Advertisement route for host H1 is non-zero,		of the received MAC/IP Advertisement route for host H1 is non-zero,
	and one of its route-targets identifies the IP-VRF, the ingress PE		and one of its Route Targets identifies the IP-VRF, the ingress PE
	will use Symmetric IRB mode when forwarding packets destined to H1.		will use symmetric IRB mode when forwarding packets destined to H1.
	If the Label2 field is zero and the MAC/IP Advertisement route for H1		If the Label2 field is zero and the MAC/IP Advertisement route for H1
	does not carry any route-target that identifies the IP-VRF, the		does not carry any Route Target that identifies the IP-VRF, the
	ingress PE will use Asymmetric mode when forwarding traffic to H1.		ingress PE will use asymmetric mode when forwarding traffic to H1.
	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
	Figure 4. Since both PEs are attached to the bridge table of the		both PEs are attached to the bridge table of the destination host,
	destination host, Symmetric and Asymmetric IRB modes are both		symmetric and asymmetric IRB modes are both possible as long as the
	possible as long as the ingress PE, PE1, supports both modes. The		ingress PE, PE1, supports both modes. The forwarding mode will
	forwarding mode will depend on the mode configured in the egress PE,		depend on the mode configured in the egress PE, PE2. That is:
	PE2. That is:
	1. If PE2 is configured for Symmetric IRB mode, PE2 will advertise		1. If PE2 is configured for symmetric IRB mode, PE2 will advertise
	TS4 MAC/IP addresses in a MAC/IP Advertisement route with a non-		TS4 MAC/IP addresses in a MAC/IP Advertisement route with a non-
	zero Label2 field, e.g., Label2=Lx, and a route-target that		zero Label2 field, e.g., Label2 = Lx, and a Route Target that
	identifies IP-VRF1 in PE1. IP4 will be installed in PE1's IP-		identifies IP-VRF1 in PE1. IP4 will be installed in PE1's IP-
	VRF1, TS4's ARP and MAC information will also be installed in		VRF1; TS4's ARP and MAC information will also be installed in
	PE1's IRB interface ARP table and BT1 respectively. When a		PE1's IRB interface ARP table and BT1, respectively. When a
	packet from TS2 destined to TS4 is looked up in PE1's IP-VRF		packet from TS2 destined to TS4 is looked up in PE1's IP-VRF
	route-table, a longest prefix match lookup will find IP4 in the		route table, a longest prefix match lookup will find IP4 in the
	IP-VRF, and PE1 will forward using the Symmetric IRB mode and		IP-VRF, and PE1 will forward using the symmetric IRB mode and
	Label Lx.		Label Lx.
	2. However, if PE2 is configured for Asymmetric IRB mode, PE2 will		2. 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.		PE2.
	Refer to [I-D.ietf-bess-evpn-modes-interop] for more information		Refer to [EVPN] for more information about interoperability between
	about interoperability between Symmetric and Asymmetric forwarding		symmetric and asymmetric forwarding modes.
	modes.
	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 (better in		operator's preference, and it is a trade-off between scale (which is
	the Symmetric IRB mode) and control plane simplicity (Asymmetric IRB		better in the symmetric IRB mode) and control plane simplicity
	mode simplifies the control plane). In cases where a tenant has		(asymmetric IRB mode simplifies the control plane). In cases where a
	hosts for every subnet attached to all (or most) the PEs, the ARP and		tenant has hosts for every subnet attached to all (or most of) the
	MAC entries need to be learned by all PEs anyway and therefore the		PEs, the ARP and MAC entries need to be learned by all PEs anyway;
	Asymmetric IRB mode simplifies the forwarding model and saves space		therefore, the asymmetric IRB mode simplifies the forwarding model
	in the IP-VRF route-table, since host routes are not installed in the		and saves space in the IP-VRF route table, since host routes are not
	route-table. However, if the tenant does not need to stretch subnets		installed in the route table. However, if the tenant does not need
	(broadcast domains) to multiple PEs and inter-subnet-forwarding is		to stretch subnets (broadcast domains) to multiple PEs and inter-
	needed, the Symmetric IRB model will save ARP and bridge table space		subnet forwarding is needed, the symmetric IRB model will save ARP
	in all the PEs (in comparison with the Asymmetric IRB model).		and bridge table space in all the PEs (in comparison with the
			asymmetric IRB model).
	5. Symmetric IRB Procedures		5. Symmetric IRB Procedures
	5.1. Control Plane - Advertising PE		5.1. Control Plane - Advertising PE
	When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of		When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
	a TS (e.g., via an ARP request or Neighbor Solicitation), it adds the		of a TS (e.g., via an ARP request or Neighbor Solicitation), it adds
	MAC address to the corresponding MAC-VRF/bridge table of that		the MAC address to the corresponding MAC-VRF/BT of that tenant's
	tenant's subnet and adds the IP address to the IP-VRF for that		subnet and adds the IP address to the IP-VRF for that tenant.
	tenant. Furthermore, it adds this TS's MAC and IP address		Furthermore, it adds this TS's MAC and IP address association to its
	association to its ARP table or NDP cache. It then builds an EVPN		ARP table or Neighbor Discovery Protocol (NDP) cache. It then builds
	MAC/IP Advertisement route (type 2) as follows and advertises it to		an EVPN MAC/IP Advertisement route (type 2) as follows and advertises
	other PEs participating in that tenant's VPN.		it to other PEs participating in that tenant's VPN.
	o The Length field of the BGP EVPN NLRI for an EVPN MAC/IP		* The Length field of the BGP EVPN Network Layer Reachability
	Advertisement route MUST be either 40 (if IPv4 address is carried)		Information (NLRI) for an EVPN MAC/IP Advertisement route MUST be
	or 52 (if IPv6 address is carried).		either 40 (if the IPv4 address is carried) or 52 (if the IPv6
			address is carried).
	o Route Distinguisher (RD), Ethernet Segment Identifier, Ethernet		* The Route Distinguisher (RD), Ethernet Segment Identifier,
	Tag ID, MAC Address Length, MAC Address, IP Address Length, IP		Ethernet Tag ID, MAC Address Length, MAC Address, IP Address
	Address, and MPLS Label1 fields MUST be set per [RFC7432] and		Length, IP Address, and MPLS Label1 fields MUST be set per
	[RFC8365].		[RFC7432] and [RFC8365].
	o The MPLS Label2 field is set to either an MPLS label or a VNI		* 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.		bits contain the label value.
	Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length,		Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length,
	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.		not part of the route key.
	This route is advertised along with the following two extended		This route is advertised along with the following two extended
	communities:		communities:
	1. Encapsulation Extended Community		1. Encapsulation Extended Community
	2. Router's MAC Extended Community		2. EVPN Router's MAC Extended Community
	This route is advertised with one or more Encapsulation extended		This route is advertised with one or more Encapsulation Extended
	communities [RFC9012], one for each encapsulation type supported by		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
	8.1, is also advertised. This extended community specifies the MAC		(Section 8.1) is also advertised. This extended community specifies
	address to be used as the inner destination MAC address in an		the MAC address to be used as the inner destination MAC address in an
	Ethernet frame sent to the advertising PE.		Ethernet frame sent to the advertising PE.
	This route MUST 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.		corresponding to the tenant's IP-VRF.
	5.2. Control Plane - Receiving PE		5.2. Control Plane - Receiving PE
	When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP		When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP
	Advertisement route, it performs the following:		Advertisement route, it performs the following:
	o The MAC-VRF route target and Ethernet Tag, if the latter is non-		* The MAC-VRF Route Target and Ethernet Tag, if the latter is non-
	zero, are used to identify the correct MAC-VRF and bridge table		zero, are used to identify the correct MAC-VRF and bridge table,
	and if they are found the MAC address is imported. The IP-VRF		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 it is		Route Target is used to identify the correct IP-VRF, and if it is
	found the IP address is imported.		found, the IP address is imported.
	If the MPLS label2 field is non-zero, it means that this route is to		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		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.		when sending a packet for this IP address to the advertising PE.
	If the receiving PE receives this route with both the MAC-VRF and IP-		If the receiving PE supports asymmetric IRB mode and receives this
	VRF route targets but the MAC/IP Advertisement route does not include		route with both the MAC-VRF and IP-VRF Route Targets but the MAC/IP
	MPLS label2 field and if the receiving PE supports asymmetric IRB		Advertisement route does not include the MPLS Label2 field, then the
	mode, then the receiving PE installs the MAC address in the		receiving PE installs the MAC address in the corresponding MAC-VRF
	corresponding MAC-VRF and (IP, MAC) association in the ARP table for		and the (IP, MAC) association in the ARP table for that tenant
	that tenant (identified by the corresponding IP-VRF route target).		(identified by the corresponding IP-VRF Route Target).
	If the receiving PE receives this route with both the MAC-VRF and IP-		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		VRF Route Targets, and if the receiving PE does not support either
	asymmetric or symmetric IRB modes, then if it has the corresponding		asymmetric or symmetric IRB modes but has the corresponding MAC-VRF,
	MAC-VRF, it only imports the MAC address.		then it only imports the MAC address.
	If the receiving PE receives this route with both the MAC-VRF and IP-		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		VRF Route Targets and the MAC/IP Advertisement route includes the
	label2 field but the receiving PE only supports asymmetric IRB mode,		MPLS Label2 field but the receiving PE only supports asymmetric IRB
	then the receiving PE MUST ignore MPLS label2 field and install the		mode, then the receiving PE MUST ignore the MPLS Label2 field and
	MAC address in the corresponding MAC-VRF and (IP, MAC) association in		install the MAC address in the corresponding MAC-VRF and (IP, MAC)
	the ARP table for that tenant (identified by the corresponding IP-VRF		association in the ARP table for that tenant (identified by the
	route target).		corresponding IP-VRF Route Target).
	5.3. Subnet route advertisement		5.3. Subnet Route Advertisement
	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		corresponding to a MAC-VRF/BT are required to be provisioned at a PE
	at a PE only if that PE has locally attached hosts in that subnet.		only if that PE has locally attached hosts in that subnet. In order
	In order to enable inter-subnet routing across PEs in a deployment		to enable inter-subnet routing across PEs in a deployment where not
	where not all subnets are provisioned at all PEs participating in an		all subnets are provisioned at all PEs participating in an EVPN IRB
	EVPN IRB instance, PEs MUST advertise local subnet routes as EVPN RT-		instance, PEs MUST advertise local subnet routes as EVPN RT-5. These
	5. These subnet routes are required for bootstrapping host (MAC,IP)		subnet routes are required for bootstrapping host (IP, MAC) learning
	learning using gleaning procedures initiated by an inter-subnet data		using gleaning procedures initiated by an inter-subnet data packet.
	packet.
	I.e., if a given host's (MAC, IP) association is unknown, and an		That is, if a given host's (IP, MAC) 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
	subnet A, that is attached to PE1 initiates a data packet destined to		A, which is attached to PE1, initiates a data packet destined to host
	host B in subnet B that is attached to PE3. If host B's (MAC, IP)		B in subnet B, which is attached to PE3. If host B's (IP, MAC) has
	has not yet been learnt either via a gratuitous ARP OR via a prior		not yet been learned via either a gratuitous ARP OR a prior gleaning
	gleaning procedure, a new gleaning procedure MUST be triggered for		procedure, a new gleaning procedure MUST be triggered for host B's
	host B's (MAC, IP) to be learnt and advertised across the EVPN		(IP, MAC) to be learned and advertised across the EVPN network.
	network. Since host B's subnet is not local to PE1, an IP lookup for		Since host B's subnet is not local to PE1, an IP lookup for host B at
	host B at PE1 will not trigger this gleaning procedure for host B's		PE1 will not trigger this gleaning procedure for host B's (IP, MAC).
	(MAC, IP). Therefore, PE1 MUST learn subnet B's prefix route via		Therefore, PE1 MUST learn subnet B's prefix route via EVPN RT-5
	EVPN RT-5 advertised from PE2 and PE3, so it can route the packet to		advertised from PE2 and PE3, so it can route the packet to one of the
	one of the PEs that have subnet B locally attached. Once the packet		PEs that have subnet B locally attached. Once the packet is received
	is received at PE2 OR PE3, and the route lookup yields a glean		at PE2 OR PE3, and the route lookup yields a glean result, an ARP
	result, an ARP request is triggered and flooded across the layer-2		request is triggered and flooded across the Layer 2 overlay. This
	overlay. This ARP request would be received and replied to by host		ARP request would be received and replied to by host B, resulting in
	B, resulting in host B (MAC, IP) learning at PE3, and its		host B (IP, MAC) learning at PE3 and its advertisement across the
	advertisement across the EVPN network. Packets from host A to host B		EVPN network. Packets from host A to host B can now be routed
	can now be routed directly from PE1 to PE3. Advertisement of local		directly from PE1 to PE3. Advertisement of local subnet EVPN RT-5
	subnet EVPN RT-5 for an IP VRF MAY typically be achieved via		for an IP-VRF MAY typically be achieved via provisioning-connected
	provisioning connected route redistribution to BGP.		route redistribution to BGP.
	5.4. Data Plane - Ingress PE		5.4. Data Plane - Ingress PE
	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		Figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify
	the associated MAC-VRF/bridge table and it performs a lookup on the		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
	egress PE along with the tunnel/encapsulation type and the associated		of the egress PE along with the tunnel/encapsulation type and the
	MPLS/VNI values. The ingress PE also decrements the TTL/hop limit		associated MPLS/VNI values. The ingress PE also decrements the TTL /
	for that packet by one and if it reaches zero, the ingress PE		hop limit for that packet by one, and if it reaches zero, the ingress
	discards the packet.		PE discards the packet.
	If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's		If the tunnel type is that of an MPLS or IP-only NVO tunnel, then the
	IP packet is sent over the tunnel without any Ethernet header.		TS's 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
	Ethernet header needs to be added to the TS's IP packet. The source		an Ethernet header needs to be added to the TS's IP packet. The
	MAC address of this inner Ethernet header is set to the ingress PE's		source MAC address of this inner Ethernet header is set to the
	router MAC address and the destination MAC address of this inner		ingress PE's router MAC address, and the destination MAC address of
	Ethernet header is set to the egress PE's router MAC address learnt		this inner Ethernet header is set to the egress PE's router MAC
	via Router's MAC extended community attached to the route. MPLS VPN		address learned via the EVPN Router's MAC Extended Community attached
	label is set to the received label2 in the route. In the case of		to the route. The MPLS VPN label is set to the received label2 in
	Ethernet NVO tunnel type, VNI may be set one of two ways:		the route. In the case of the Ethernet NVO tunnel type, the VNI may
			be set one of two ways:
	o downstream mode: VNI is set to the received label2 in the route		downstream mode: The VNI is set to the received label2 in the route,
	which is downstream assigned.		which is downstream assigned.
	o global mode: VNI is set to the received label2 in the route which		global mode: The VNI is set to the received label2 in the route,
	is domain-wide assigned. This VNI value from received label2 MUST		which is assigned domain-wide. This VNI value from the received
	be the same as the locally configured VNI for the IP VRF as all		label2 MUST be the same as the locally configured VNI for the IP-
	PEs in the NVO MUST be configured with the same IP VRF VNI for		VRF as all PEs in the NVO MUST be configured with the same IP-VRF
	this mode of operation. If the received label2 value does not		VNI for this mode of operation. If the received label2 value does
	match the locally configured VNI value the route MUST NOT be used		not match the locally configured VNI value, the route MUST NOT be
	and an error message SHOULD logged.		used, and an error message SHOULD be logged.
	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.		the NVO and the PE's capability to support downstream VNI mode.
	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.		next-hop IP addresses, respectively.
	5.5. Data Plane - Egress PE		5.5. Data Plane - Egress PE
	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
	encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or		tunnel encapsulation and uses the VPN MPLS label (for MPLS
	VNI (for NVO encapsulation) to identify the IP-VRF in which IP lookup		encapsulation) or VNI (for NVO encapsulation) to identify the IP-VRF
	needs to be performed. If the VPN MPLS label or VNI identifies a		in which IP lookup needs to be performed. If the VPN MPLS label or
	MAC- VRF instead of an IP-VRF, then the procedures in section 6.4 for		VNI identifies a MAC-VRF instead of an IP-VRF, then the procedures in
	asymmetric IRB are executed.		Section 6.4 for asymmetric IRB are executed.
	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
	The egress PE also decrements the TTL/hop limit for that packet by		PE also decrements the TTL / hop limit for that packet by one, and if
	one and if it reaches zero, the egress PE discards the packet.		it reaches zero, the egress PE discards the packet.
	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.		destination subnet MAC-VRF/BT.
	The destination MAC address lookup in the MAC-VRF/bridge table		The destination MAC address lookup in the MAC-VRF/BT results in the
	results in local adjacency (e.g., local interface) over which the		local adjacency (e.g., local interface) over which the Ethernet frame
	Ethernet frame is sent on.		is sent.
	6. Asymmetric IRB Procedures		6. Asymmetric IRB Procedures
	6.1. Control Plane - Advertising PE		6.1. Control Plane - Advertising PE
	When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of		When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
	an attached TS (e.g., via an ARP request or ND Neighbor		of 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
	table or NDP cache just as in the case for symmetric IRB. It then		NDP cache just as in the case for symmetric IRB. It then builds an
	builds an EVPN MAC/IP Advertisement route (type 2) as follows and		EVPN MAC/IP Advertisement route (type 2) as follows and advertises it
	advertises it to other PEs participating in that tenant's VPN.		to other PEs participating in that tenant's VPN.
	o The Length field of the BGP EVPN NLRI for an EVPN MAC/IP		* The Length field of the BGP EVPN NLRI for an EVPN MAC/IP
	Advertisement route MUST be either 37 (if IPv4 address is carried)		Advertisement route MUST be either 37 (if an IPv4 address is
	or 49 (if IPv6 address is carried).		carried) or 49 (if an IPv6 address is carried).
	o Route Distinguisher (RD), Ethernet Segment Identifier, Ethernet		* The RD, Ethernet Segment Identifier, Ethernet Tag ID, MAC Address
	Tag ID, MAC Address Length, MAC Address, IP Address Length, IP		Length, MAC Address, IP Address Length, IP Address, and MPLS
	Address, and MPLS Label1 fields MUST be set per [RFC7432] and		Label1 fields MUST be set per [RFC7432] and [RFC8365].
	[RFC8365].
	o The MPLS Label2 field MUST NOT be included in this route.		* The MPLS Label2 field MUST NOT be included in this route.
	Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length,		Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length,
	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.		not part of the route key.
	This route is advertised along with the following extended community:		This route is advertised along with the following extended community:
	o Tunnel Type Extended Community		* Tunnel Type Extended Community
	For asymmetric IRB mode, Router's MAC extended community is not		For asymmetric IRB mode, the EVPN Router's MAC Extended Community is
	needed because forwarding is performed using destination TS's MAC		not needed because forwarding is performed using destination TS's MAC
	address which is carried in this EVPN route type-2 advertisement.		address, which is carried in this EVPN route type 2 advertisement.
	This route MUST always be advertised with the MAC-VRF route target.		This route MUST always be advertised with the MAC-VRF Route Target.
	It MAY also be advertised with a second route target corresponding to		It MAY also be advertised with a second Route Target corresponding to
	the IP-VRF.		the IP-VRF.
	6.2. Control Plane - Receiving PE		6.2. Control Plane - Receiving PE
	When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP		When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP
	Advertisement route, it performs the following:		Advertisement route, it performs the following:
	o Using MAC-VRF route target, it identifies the corresponding MAC-		* Using the MAC-VRF Route Target, it identifies the corresponding
	VRF and imports the MAC address into it. For asymmetric IRB mode,		MAC-VRF and imports the MAC address into it. For asymmetric IRB
	it is assumed that all PEs participating in a tenant's VPN are		mode, it is assumed that all PEs participating in a tenant's VPN
	configured with all subnets (i.e., all VLANs) and corresponding		are configured with all subnets (i.e., all VLANs) and
	MAC-VRFs/bridge tables even if there are no locally attached TSes		corresponding MAC-VRFs/BTs even if there are no locally attached
	for some of these subnets. The reason for this is because ingress		TSs for some of these subnets. This is because the ingress PE
	PE needs to do forwarding based on destination TS's MAC address		needs to do forwarding based on the destination TS's MAC address
	and perform NVO tunnel encapsulation as a property of a lookup in		and perform NVO tunnel encapsulation as the property of a lookup
	MAC-VRF/bridge table.		in the MAC-VRF/BT.
	o If only MAC-VRF route target is used, then the receiving PE uses		* If only the MAC-VRF Route Target is used, then the receiving PE
	the MAC-VRF route target to identify the corresponding IP-VRF --		uses 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
	the MAC-VRF route target may be used by the receiving PE to		Route Target may be used by the receiving PE to identify the
	identify the corresponding IP VRF.		corresponding IP-VRF.
	o Using MAC-VRF route target, the receiving PE identifies the		* Using the 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
	entry to the ARP table or NDP cache for the TS's MAC and IP		an 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.		MAC-VRF Route Targets for that tenant.
	o If IP-VRF route target is included, it may be used to import the		* If the IP-VRF Route Target is included, it may be used to import
	route to IP-VRF. If IP-VRF route-target is not included, MAC-VRF		the route to IP-VRF. If the IP-VRF Route Target is not included,
	is used to derive corresponding IP-VRF for import, as explained in		MAC-VRF is used to derive the corresponding IP-VRF for import, as
	the prior section. In both cases, IP-VRF route is installed with		explained in the prior section. In both cases, an IP-VRF route is
	the TS MAC binding included in the received route.		installed with the TS MAC binding included in the received route.
	If the receiving PE receives the MAC/IP Advertisement route with MPLS		If the receiving PE receives the MAC/IP Advertisement route with the
	label2 field but the receiving PE only supports asymmetric IRB mode,		MPLS Label2 field but the receiving PE only supports asymmetric IRB
	then the receiving PE MUST ignore MPLS label2 field and install the		mode, then the receiving PE MUST ignore the MPLS Label2 field and
	MAC address in the corresponding MAC-VRF and (IP, MAC) association in		install the MAC address in the corresponding MAC-VRF and (IP, MAC)
	the ARP table or NDP cache for that tenant (with IRB interface		association in the ARP table or NDP cache for that tenant (with the
	identified by the MAC-VRF).		IRB interface identified by the MAC-VRF).
	6.3. Data Plane - Ingress PE		6.3. Data Plane - Ingress PE
	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		Figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify
	the associated MAC-VRF/bridge table and it performs a lookup on the		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.		the packet.
	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.		destination subnet MAC-VRF/BT.
	The destination MAC address lookup in the MAC-VRF/bridge table		The destination MAC address lookup in the MAC-VRF/BT results in a BGP
	results in BGP next hop address of egress PE along with label1 (L2		next-hop address of the egress PE along with label1 (L2 VPN MPLS
	VPN MPLS label or VNI). The ingress PE encapsulates the packet using		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
	[RFC7432] for MPLS and [RFC8365] for VxLAN encapsulations.		[RFC7432] for MPLS and [RFC8365] for VXLAN encapsulations.
	6.4. Data Plane - Egress PE		6.4. Data Plane - Egress PE
	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
	the VPN MPLS label (for MPLS encapsulation) or VNI (for NVO		uses 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
	lookup needs to be performed.		needs to be performed.
	The MAC lookup results in local adjacency (e.g., local interface)		The MAC lookup results in a local adjacency (e.g., local interface)
	over which the packet needs to get sent.		over which the packet needs to get sent.
	Note that the forwarding behavior on the egress PE is the same as		Note that the forwarding behavior on the egress PE is the same as the
	EVPN intra-subnet forwarding described in [RFC7432] for MPLS and		EVPN intra-subnet forwarding described in [RFC7432] for MPLS and
	[RFC8365] for NVO networks. In other words, all the packet		[RFC8365] for NVO networks. In other words, 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.		confined to the ingress PE for asymmetric IRB mode.
	It should also be noted that [RFC7432] provides a different level of		It should also be noted that [RFC7432] provides a different level 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
	egress interface or individual MAC address identification, then no		for an egress interface or individual MAC address identification,
	MAC lookup is needed in the egress PE for MPLS encapsulation and the		then no MAC lookup is needed in the egress PE for MPLS encapsulation,
	packet can be directly forwarded to the egress interface just based		and the packet can be directly forwarded to the egress interface just
	on EVPN label lookup.		based on the EVPN label lookup.
	7. Mobility Procedure		7. Mobility Procedure
	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. [RFC7432] describes the MAC		all participating NVEs be updated. [RFC7432] 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
	and BGP Extended Communities needed to handle the MAC mobility for		BGP Extended Communities needed to handle the MAC Mobility for IRB.
	IRB. In order to place the emphasis on the differences between		In order to place the emphasis on the differences between L2-only and
	L2-only and IRB use cases, the incremental procedure is described for		IRB use cases, the incremental procedure is described for a single-
	single-homed TS with the expectation that the additional steps needed		homed TS with the expectation that the additional steps needed for a
	for multi-homed TS, can be extended per section 15 of [RFC7432].		multihomed TS can be extended per Section 15 of [RFC7432]. This
	This section describes mobility procedures for both symmetric and		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.		IPv4 ARP, it equally applies to IPv6 ND.
	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:		one of the following three ways:
	1. TS initiates an ARP request upon a move to the target NVE		1. TS initiates an ARP request upon a move to the target NVE.
	2. TS sends data packet without first initiating an ARP request to		2. TS sends a data packet without first initiating an ARP request to
	the target NVE		the target NVE.
	3. TS is a silent host and neither initiates an ARP request nor		3. TS is a silent host and neither initiates an ARP request nor
	sends any packets		sends any packets.
	Depending on the expexted TS's behavior, an NVE needs to handle at		Depending on the expected TS's behavior, an NVE needs to handle at
	least the first bullet and should be able to handle the 2nd and the		least the first option and should be able to handle the second and
	3rd bullet. The following subsections describe the procedures for		third options. The following subsections describe the procedures for
	each of them where it is assumed that the MAC and IP addresses of a		each scenario 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		TS have a one-to-one relationship (i.e., there is one IP address per
	MAC address and vice versa). The procedures for host mobility		MAC address and vice versa). The procedures for host mobility
	detection in the presence of many-to-one relationship is outside the		detection in the presence of a many-to-one relationship is outside
	scope of this document and it is covered in		the scope of this document, and it is covered in [EXTENDED-MOBILITY].
	[I-D.ietf-bess-evpn-irb-extended-mobility]. The many-to-one		The "many-to-one relationship" refers to many host IP addresses
	relationship means many host IP addresses corresponding to a single		corresponding to a single host MAC address or many host MAC addresses
	host MAC address or many host MAC addresses corresponding to a single		corresponding to a single IP address. It should be noted that in the
	IP address. It should be noted that in case of IPv6, a Link Local IP		case of IPv6, a link-local IP address does not count in a many-to-one
	address does not count in many-to-one relationship because that		relationship because that address is confined to a single Ethernet
	address is confined to single Ethernet Segment and it is not used for		segment, and it is not used for host mobility (i.e., by definition,
	host moblity (i.e., by definition host mobility is between two		host mobility is between two different Ethernet segments).
	different Ethernet Segments). Therefore, when an IPv6 host is		Therefore, when an IPv6 host is configured with both a Global Unicast
	configured with both a Global Unicast address (or a Unique Local		address (or a Unique Local address) and a link-local address, for the
	address) and a Link Local address, for the purpose of host mobility,		purpose of host mobility, it is considered with a single IP address.
	it is considered with a single IP address.
	7.1. Initiating a gratutious ARP upon a Move		7.1. Initiating a Gratuitous ARP upon a Move
	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.		the TS initiates a gratuitous ARP upon the move to the target NVE.
	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).		information (e.g., local interface).
	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,
	it initiates MAC mobility procedures per [RFC7432] by advertising an		and it initiates MAC Mobility procedures per [RFC7432] by advertising
	EVPN MAC/IP Advertisement route with both the MAC and IP addresses		an 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 5.1 and 6.1) along with the MAC Mobility
	Community with the sequence number incremented by one. The target		extended community, with the sequence number incremented by one. The
	NVE also exercises the MAC duplication detection procedure in section		target NVE also exercises the MAC duplication detection procedure in
	15.1 of [RFC7432].		Section 15.1 of [RFC7432].
	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 [RFC7432].		Section 15.1 of [RFC7432].
	All other remote NVE devices upon receiving the MAC/IP Advertisement		All other remote NVE devices, upon receiving the MAC/IP Advertisement
	route with MAC Mobility extended community compare the sequence		route with the MAC Mobility extended community, compare the sequence
	number in this advertisement with the one previously received. If		number in this advertisement with the one previously received. If
	the new sequence number is greater than the old one, then they update		the new sequence number is greater than the old one, then they update
	the MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-		the MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-
	VRF tables to point to the target NVE. Furthermore, upon receiving		VRF tables to point to the target NVE. Furthermore, upon receiving
	the MAC/IP withdraw for the TS from the source NVE, these remote PEs		the MAC/IP withdraw for the TS from the source NVE, these remote PEs
	perform the cleanups for their BGP tables.		perform the cleanups for their BGP tables.
	7.2. Sending Data Traffic without an ARP Request		7.2. Sending Data Traffic without an ARP Request
	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.		request.
	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.		from the source NVE.
	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:		taken:
	o The target NVE upon learning this MAC address in the data plane,		* The target NVE, upon learning this MAC address 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 [RFC7432] by advertising an EVPN MAC/IP		procedures per [RFC7432] by advertising an EVPN MAC/IP
	Advertisement route with only the MAC address filled in along with		Advertisement route with only the MAC address filled in along with
	MAC Mobility Extended Community with the sequence number		the MAC Mobility extended community, with the sequence number
	incremented by one.		incremented by one.
	o 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 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
	NVEs participating in that subnet including the target NVE. Note		participating in that subnet, including the target NVE. Note that
	that the PE needs to maintain a correlation between MAC and MAC-IP		the PE needs to maintain a correlation between MAC and MAC-IP
	route entries in the MAC-VRF to accomplish this.		route entries in the MAC-VRF to accomplish this.
	o The target NVE passes the ARP request to its locally attached TSes		* The target NVE passes the ARP request to its locally attached TSs,
	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.		Advertisement route it sent previously.
	o When the source NVE receives the EVPN MAC/IP Advertisement route,		* 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,
	IP) from its local ARP table. Furthermore, it withdraws its		MAC) from its 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.		address fields filled in.
	o All other remote NVE devices upon receiving the MAC/IP		* All other remote NVE devices, upon receiving the MAC/IP
	advertisement route with MAC Mobility extended community compare		Advertisement route with the MAC Mobility extended community,
	the sequence number in this advertisement with the one previously		compare the sequence number in this advertisement with the one
	received. If the new sequence number is greater than the old one,		previously received. If the new sequence number is greater than
	then they update the MAC/IP addresses of the TS in their		the old one, then they update the MAC/IP addresses of the TS in
	corresponding MAC-VRF, IP-VRF, and ARP tables (in the case of		their corresponding MAC-VRF, IP-VRF, and ARP tables (in the case
	asymmetric IRB) to point to the new NVE. Furthermore, upon		of 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.		remote PEs perform the cleanups for their BGP tables.
	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 Section 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 MAY 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.		described earlier for better convergence.
	7.3. Silent Host		7.3. Silent Host
	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.		are aware of the MAC move.
	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
	choice. The ARP request gets sent both locally to all the attached		implementation choice. The ARP request gets sent both locally to all
	TSes on that subnet as well as it gets sent to all the remote NVEs		the attached 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).		MAC address (if it has previously advertised such a route).
	The target NVE passes the ARP request to its locally attached TSes		The target NVE passes the ARP request to its locally attached TSs,
	and when it receives the ARP response, it updates its MAC-VRF, IP-		and when it receives the ARP response, it updates its MAC-VRF, IP-
	VRF, and ARP table with the host (MAC, IP) and local adjacency		VRF, and ARP table with the host (IP, MAC) and local adjacency
	information (e.g., local interface). It also sends an EVPN MAC/IP		information (e.g., local interface). It also sends an EVPN MAC/IP
	advertisement route with both the MAC and IP address fields filled in		Advertisement route with both the MAC and IP address fields filled in
	along with MAC Mobility Extended Community with the sequence number		along with the MAC Mobility extended community, with the sequence
	incremented by one.		number incremented by one.
	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.		EVPN MAC/IP route with both the MAC and IP address fields filled in.
	All other remote NVE devices upon receiving the MAC/IP Advertisement		All other remote NVE devices, upon receiving the MAC/IP Advertisement
	route with MAC Mobility extended community compare the sequence		route with the MAC Mobility extended community, compare the sequence
	number in this advertisement with the one previously received. If		number in this advertisement with the one previously received. If
	the new sequence number is greater than the old one, then they update		the new sequence number is greater than the old one, then they update
	the MAC/IP addresses of the TS in their corresponding MAC-VRF, IP-		the MAC/IP addresses of the TS in their corresponding MAC-VRF, IP-
	VRF, and ARP (in the case of asymmetric IRB) tables to point to the		VRF, and ARP (in the case of asymmetric IRB) tables to point to the
	new NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS		new NVE. Furthermore, upon receiving the MAC/IP withdraw for the TS
	from the old NVE, these remote PEs perform the cleanups for their BGP		from the old NVE, these remote PEs perform the cleanups for their BGP
	tables.		tables.
	8. BGP Encoding		8. BGP Encoding
	This document defines one new BGP Extended Community for EVPN.		This document defines one new BGP Extended Community for EVPN.
	8.1. Router's MAC Extended Community		8.1. EVPN Router's MAC Extended Community
	A new EVPN BGP Extended Community called Router's MAC is introduced		A new EVPN BGP Extended Community called "EVPN Router's MAC" is
	here. This new extended community is a transitive extended community		introduced here. This new extended community is a transitive
	with the Type field of 0x06 (EVPN) and the Sub-Type of 0x03. It may		extended community with a Type field of 0x06 (EVPN) and a Sub-Type
	be advertised along with Encapsulation Extended Community defined in		field of 0x03. It may be advertised along with the Encapsulation
	section 4.1 of [I-D.ietf-idr-tunnel-encaps].		Extended Community defined in Section 4.1 of [RFC9012].
	The Router's MAC Extended Community is encoded as an 8-octet value as		The EVPN Router's MAC Extended Community is encoded as an 8-octet
	follows:		value as follows:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Router's MAC Extended Community		Figure 5: EVPN Router's MAC Extended Community
	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 SHALL only attach a single EVPN Router's MAC Extended
	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 SHALL
	the first one in the list and not store and propagate the others.		process the first one in the list and not store and propagate the
			others.
	9. Operational Models for Symmetric Inter-Subnet Forwarding		9. Operational Models for Symmetric Inter-Subnet Forwarding
	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.		represented by a single IP-VRF table and one or more MAC-VRF tables.
	9.1. IRB forwarding on NVEs for Tenant Systems		9.1. IRB Forwarding on NVEs for Tenant Systems
	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
	host IP and MAC addresses are learned by the attached NVEs and are		MAC addresses are learned by the attached NVEs and are distributed to
	distributed to all other NVEs that are interested in participating in		all other NVEs that are interested in participating in both intra-
	both intra-subnet and inter-subnet communications with that TS.		subnet and inter-subnet communications with that TS.
	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
	one bridge table per VLAN). The MAC-VRFs on an NVE for a given		bridge table per VLAN). The MAC-VRFs on an NVE for a given tenant
	tenant are associated with an IP-VRF corresponding to that tenant (or		are associated with an IP-VRF corresponding to that tenant (or IP-VPN
	IP-VPN instance) via their IRB interfaces.		instance) via their IRB interfaces.
	Since VxLAN and NVGRE encapsulations require inner Ethernet header		Since VXLAN and NVGRE encapsulations require an inner Ethernet header
	(inner MAC SA/DA), and since for inter-subnet traffic, TS MAC address		(inner MAC SA/DA) and since a TS MAC address cannot be used for
	cannot be used, the ingress NVE's MAC address is used as inner MAC		inter-subnet traffic, the ingress NVE's MAC address is used as an
	SA. The NVE's MAC address is the device MAC address and it is common		inner MAC SA. The NVE's MAC address is the device MAC address, and
	across all MAC-VRFs and IP-VRFs. This MAC address is advertised		it is common across all MAC-VRFs and IP-VRFs. This MAC address is
	using the new EVPN Router's MAC Extended Community (section 8.1).		advertised using the new EVPN Router's MAC Extended Community
			(Section 8.1).
	Figure 6 below illustrates this scenario where a given tenant (e.g.,		Figure 6 below illustrates this scenario, where a given tenant (e.g.,
	an IP-VPN instance) has three subnets represented by MAC-VRF1, MAC-		an IP-VPN instance) has three subnets represented by MAC-VRF1, MAC-
	VRF2, and MAC-VRF3 across two NVEs. There are five TSes that are		VRF2, and MAC-VRF3 across two NVEs. There are five TSs that are
	associated with these three MAC-VRFs -- i.e., TS1, TS4, and TS5 are		associated with 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		on the same subnet (e.g., the same MAC-VRF/VLAN). TS1 and TS5 are
	associated with MAC-VRF1 on NVE1, while TS4 is associated with MAC-		associated with MAC-VRF1 on NVE1, while TS4 is associated with MAC-
	VRF1 on NVE2. TS2 is associated with MAC-VRF2 on NVE1, and TS3 is		VRF1 on NVE2. TS2 is associated with MAC-VRF2 on NVE1, and TS3 is
	associated with MAC-VRF3 on NVE2. MAC-VRF1 and MAC-VRF2 on NVE1 are		associated with MAC-VRF3 on NVE2. MAC-VRF1 and MAC-VRF2 on NVE1 are,
	in turn associated with IP-VRF1 on NVE1 and MAC-VRF1 and MAC-VRF3 on		in turn, associated with IP-VRF1 on NVE1, and MAC-VRF1 and MAC-VRF3
	NVE2 are associated with IP-VRF1 on NVE2. When TS1, TS5, and TS4		on NVE2 are associated with IP-VRF1 on NVE2. When TS1, TS5, and TS4
	exchange traffic with each other, only the L2 forwarding (bridging)		exchange traffic with each other, only the L2 forwarding (bridging)
	part of the IRB solution is exercised because all these TSes belong		part of the IRB solution is exercised because all these TSs belong to
	to the same subnet. However, when TS1 wants to exchange traffic with		the same subnet. However, when TS1 wants to exchange traffic with
	TS2 or TS3 which belong to different subnets, both bridging and		TS2 or TS3, which belong to different subnets, both the bridging and
	routing parts of the IRB solution are exercised. The following		routing parts of the IRB solution are exercised. The following
	subsections describe the control and data planes operations for this		subsections describe the control and data plane operations for this
	IRB scenario in details.		IRB scenario in detail.
	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)
	+-------------+ | | +-------------+		+-------------+ | | +-------------+
	| |		| |
	+---------+		+---------+
	Figure 6: IRB forwarding on NVEs for Tenant Systems		Figure 6: IRB Forwarding on NVEs for Tenant Systems
	9.1.1. Control Plane Operation		9.1.1. Control Plane Operation
	Each NVE advertises a MAC/IP Advertisement route (i.e., Route Type 2)		Each NVE advertises a MAC/IP Advertisement route (i.e., route type 2)
	for each of its TSes with the following field set:		for each of its TSs with the following field set:
	o RD and ESI per [RFC7432]		* RD and Ethernet Segment Identifier (ESI) per [RFC7432]
	o Ethernet Tag = 0; assuming VLAN-based service		* Ethernet Tag = 0 (assuming VLAN-based service)
	o MAC Address Length = 48		* MAC Address Length = 48
	o MAC Address = Mi ; where i = 1,2,3,4, or 5 in the above example		* MAC Address = Mi (where i = 1, 2, 3, 4, or 5) in Figure 6, above
	o IP Address Length = 32 or 128		* IP Address Length = 32 or 128
	o IP Address = IPi ; where i = 1,2,3,4, or 5 in the above example		* IP Address = IPi (where i = 1, 2, 3, 4, or 5) in Figure 6, above
	o Label1 = MPLS Label or VNI corresponding to MAC-VRF		* Label1 = MPLS label or VNI corresponding to MAC-VRF
	o Label2 = MPLS Label or VNI corresponding to IP-VRF		* Label2 = MPLS label or VNI corresponding to IP-VRF
	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-		corresponding to its MAC-VRF and the other corresponding to its IP-
	VRF. Furthermore, the EVPN RT-2 is advertised with two BGP Extended		VRF). Furthermore, the EVPN RT-2 is advertised with two BGP Extended
	Communities. The first BGP Extended Community identifies the tunnel		Communities. The first BGP Extended Community identifies the tunnel
	type and it is called Encapsulation Extended Community as defined in		type, and it is called "Encapsulation Extended Community" as defined
	[I-D.ietf-idr-tunnel-encaps] and the second BGP Extended Community		in [RFC9012], and the second BGP Extended Community includes the MAC
	includes the MAC address of the NVE (e.g., MACx for NVE1 or MACy for		address of the NVE (e.g., MACx for NVE1 or MACy for NVE2) as defined
	NVE2) as defined in section 8.1. The Router's MAC Extended community		in Section 8.1. The EVPN Router's MAC Extended Community MUST be
	MUST be added when Ethernet NVO tunnel is used. If IP NVO tunnel		added when the Ethernet NVO tunnel is used. If the IP NVO tunnel
	type is used, then there is no need to send this second Extended		type is used, then there is no need to send this second Extended
	Community. It should be noted that IP NVO tunnel type is only		Community. It should be noted that the IP NVO tunnel type is only
	applicable to symmetric IRB procedures.		applicable to symmetric IRB procedures.
	Upon receiving this advertisement, the receiving NVE performs the		Upon receiving this advertisement, the receiving NVE performs the
	following:		following:
	o It uses Route Targets corresponding to its MAC-VRF and IP-VRF for		* It uses Route Targets corresponding to its MAC-VRF and IP-VRF for
	identifying these tables and subsequently importing the MAC and IP		identifying these tables and subsequently importing the MAC and IP
	addresses into them respectively.		addresses into them, respectively.
	o It imports the MAC address from MAC/IP Advertisement route into		* It imports the MAC address from the MAC/IP Advertisement route
	the MAC-VRF with BGP Next Hop address as the underlay tunnel		into the MAC-VRF with the BGP next-hop address as the underlay
	destination address (e.g., VTEP DA for VxLAN encapsulation) and		tunnel destination address (e.g., VTEP DA for VXLAN encapsulation)
	Label1 as VNI for VxLAN encapsulation or EVPN label for MPLS		and label1 as the VNI for VXLAN encapsulation or an EVPN label for
	encapsulation.		MPLS encapsulation.
	o If the route carries the new Router's MAC Extended Community, and		* If the route carries the new EVPN Router's MAC Extended Community
	if the receiving NVE uses Ethernet NVO tunnel, then the receiving		and if the receiving NVE uses an Ethernet NVO tunnel, then the
	NVE imports the IP address into IP-VRF with NVE's MAC address		receiving NVE imports the IP address into IP-VRF with NVE's MAC
	(from the new Router's MAC Extended Community) as inner MAC DA and		address (from the new EVPN Router's MAC Extended Community) as the
	BGP Next Hop address as the underlay tunnel destination address,		inner MAC DA, the BGP next-hop address as the underlay tunnel
	VTEP DA for VxLAN encapsulation and Label2 as IP-VPN VNI for VxLAN		destination address, the VTEP DA for VXLAN encapsulation, and
	encapsulation.		label2 as the IP-VPN VNI for VXLAN encapsulation.
	o If the receiving NVE uses MPLS encapsulation, then the receiving		* If the receiving NVE uses MPLS encapsulation, then the receiving
	NVE imports the IP address into IP-VRF with BGP Next Hop address		NVE imports the IP address into IP-VRF with the BGP next-hop
	as the underlay tunnel destination address, and Label2 as IP-VPN		address as the underlay tunnel destination address and label2 as
	label for MPLS encapsulation.		the IP-VPN label for MPLS encapsulation.
	If the receiving NVE receives an EVPN RT-2 with only Label1 and only		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		a single Route Target corresponding to IP-VRF; an EVPN RT-2 with only
	EVPN RT-2 with only a single Route Target corresponding to MAC-VRF		a single Route Target corresponding to MAC-VRF but with both label1
	but with both Label1 and Label2, or if it receives an EVPN RT-2 with		and label2; or an EVPN RT-2 with a MAC address length of zero, then
	MAC Address Length of zero, then it MUST use the treat-as-withdraw		it MUST use the treat-as-withdraw approach [RFC7606] and SHOULD log
	approach [RFC7606] and SHOULD log an error message.		an error message.
	9.1.2. Data Plane Operation		9.1.2. Data Plane Operation
	The following description of the data-plane operation describes just		The following description of the data plane operation describes just
	the logical functions and the actual implementation may differ. Lets		the logical functions, and the actual implementation may differ.
	consider data-plane operation when TS1 in subnet-1 (MAC-VRF1) on NVE1		Let's consider the data plane operation when TS1 in subnet-1 (MAC-
	wants to send traffic to TS3 in subnet-3 (MAC-VRF3) on NVE2.		VRF1) on NVE1 wants to send traffic to TS3 in subnet-3 (MAC-VRF3) on
			NVE2.
	o NVE1 receives a packet with MAC DA corresponding to the MAC-VRF1		* NVE1 receives a packet with the MAC DA corresponding to the MAC-
	IRB interface on NVE1 (the interface between MAC-VRF1 and IP-		VRF1 IRB interface on NVE1 (the interface between MAC-VRF1 and IP-
	VRF1), and VLAN-tag corresponding to MAC-VRF1.		VRF1) and the VLAN tag corresponding to MAC-VRF1.
	o Upon receiving the packet, the NVE1 uses VLAN-tag to identify the		* Upon receiving the packet, the NVE1 uses the VLAN tag to identify
	MAC-VRF1. It then looks up the MAC DA and forwards the frame to		the MAC-VRF1. It then looks up the MAC DA and forwards the frame
	its IRB interface.		to its IRB interface.
	o The Ethernet header of the packet is stripped and the packet is		* 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
	tunnel, then it includes the egress NVE's MAC address as inner MAC		NVO tunnel, then it includes the egress NVE's MAC address as the
	DA, the egress NVE's IP address (e.g., BGP Next Hop address) as		inner MAC DA, the egress NVE's IP address (e.g., BGP next-hop
	the VTEP DA, and the VPN-ID as the VNI. The inner MAC SA and VTEP		address) as the VTEP DA, and the VPN-ID as the VNI. The inner MAC
	SA are set to NVE's MAC and IP addresses respectively. If it is a		SA and VTEP SA are set to NVE's MAC and IP addresses,
	MPLS encapsulation, then corresponding EVPN and LSP labels are		respectively. If it is an MPLS encapsulation, then the
	added to the packet. The packet is then forwarded to the egress		corresponding EVPN and LSP labels are added to the packet. The
	NVE.		packet is then forwarded to the egress NVE.
	o On the egress NVE, if the packet arrives on Ethernet NVO tunnel		* If the egress NVE receives a packet from the Ethernet NVO tunnel
	(e.g., it is VxLAN encapsulated), then the NVO tunnel header is		(e.g., it is VXLAN encapsulated), then it removes the Ethernet
	removed. Since the inner MAC DA is the egress NVE's MAC address,		header. Since the inner MAC DA is the egress NVE's 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.		packet by one, and if it reaches zero, NVE2 discards the packet.
	o The IP packet is encapsulated with an Ethernet header with MAC SA		* The IP packet is encapsulated with an Ethernet header, with the
	set to that of IRB interface MAC address (i.e, IRB interface		MAC SA set to that of the IRB interface MAC address (i.e., the IRB
	between MAC-VRF3 and IP-VRF1 on NVE2) and MAC DA set to that of		interface between MAC-VRF3 and IP-VRF1 on NVE2) and the MAC DA set
	destination TS (TS3) MAC address. The packet is sent to the		to that of the destination TS (TS3) MAC address. The packet is
	corresponding MAC-VRF (i.e., MAC-VRF3) and after a lookup of MAC		sent to the corresponding MAC-VRF (i.e., MAC-VRF3) and, after a
	DA, is forwarded to the destination TS (TS3) over the		lookup of MAC DA, is forwarded to the destination TS (TS3) over
	corresponding interface.		the corresponding interface.
	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 label, as long as TS4's host IP is present in NVE1's IP-VRF.		MPLS label, as long as TS4's host IP is present in NVE1's IP-VRF.
	9.2. IRB forwarding on NVEs for Subnets behind Tenant Systems		9.2. IRB Forwarding on NVEs for Subnets behind Tenant Systems
	This section covers the symmetric IRB procedures for the scenario		This section covers the symmetric IRB procedures for the scenario
	where some Tenant Systems (TSes) support one or more subnets and		where some TSs support one or more subnets and these TSs are
	these TSes are associated with one or more NVEs. Therefore, besides		associated with one or more NVEs. Therefore, besides the
	the advertisement of MAC/IP addresses for each TS which can be multi-		advertisement of MAC/IP addresses for each TS, which can be
	homed with All-Active redundancy mode, the associated NVE needs to		multihomed with All-Active redundancy mode, the associated NVE needs
	also advertise the subnets statically configured on each TS.		to also advertise the subnets statically configured on each TS.
	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 [I-D.ietf-bess-evpn-prefix-advertisement]. These subnet		defined in [RFC9136]. These subnet prefixes are advertised with the
	prefixes are advertised with the IP address of their associated TS		IP address of their associated TS (which is in an overlay address
	(which is in overlay address space) as their next hop. The receiving		space) as their next hop. The receiving NVEs perform recursive route
	NVEs perform recursive route resolution to resolve the subnet prefix		resolution to resolve the subnet prefix with its advertising NVE so
	with its advertising NVE so that they know which NVE to forward the		that they know which NVE to forward the packets to when they are
	packets to when they are destined for that subnet prefix.		destined for that subnet prefix.
	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
	the IP/MAC addresses associated with the TS itself and exercise MAC		advertise the IP/MAC addresses associated with the TS itself and
	mobility procedures for that TS. The recursive route resolution		exercise the MAC Mobility procedures for that TS. The recursive
	automatically takes care of the updates for the subnet prefixes of		route resolution automatically takes care of the updates for the
	that TS.		subnet prefixes of that TS.
	Figure 7 illustrates this scenario where a given tenant (e.g., an IP-		Figure 7 illustrates this scenario where a given tenant (e.g., an IP-
	VPN service) has three subnets represented by MAC-VRF1, MAC-VRF2, and		VPN service) has three subnets represented by MAC-VRF1, MAC-VRF2, and
	MAC-VRF3 across two NVEs. There are four TSes associated with these		MAC-VRF3 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		three MAC-VRFs -- 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,		connected to MAC-VRF2 on NVE1, TS3 is connected to MAC-VRF3 on NVE2,
	and TS4 is connected to MAC-VRF1 on NVE2. TS1 has two subnet		and TS4 is connected to MAC-VRF1 on NVE2. TS1 has two subnet
	prefixes (SN1 and SN2) and TS3 has a single subnet prefix, SN3. The		prefixes (SN1 and SN2), and TS3 has a single subnet prefix (SN3).
	MAC-VRFs on each NVE are associated with their corresponding IP-VRF		The MAC-VRFs on each NVE are associated with their corresponding IP-
	using their IRB interfaces. When TS4 and TS1 exchange intra- subnet		VRF using their IRB interfaces. When TS4 and TS1 exchange intra-
	traffic, only L2 forwarding (bridging) part of the IRB solution is		subnet traffic, only the L2 forwarding (bridging) part of the IRB
	used (i.e., the traffic only goes through their MAC- VRFs); however,		solution is used (i.e., the traffic only goes through their MAC-
	when TS3 wants to forward traffic to SN1 or SN2 sitting behind TS1		VRFs); however, when TS3 wants to forward traffic to SN1 or SN2
	(inter-subnet traffic), then both bridging and routing parts of the		sitting behind TS1 (inter-subnet traffic), then both the bridging and
	IRB solution are exercised (i.e., the traffic goes through the		routing parts of the IRB solution are exercised (i.e., the traffic
	corresponding MAC-VRFs and IP-VRFs). If TS4, for example, wants to		goes through the corresponding MAC-VRFs and IP-VRFs). If TS4, for
	reach SN1, it uses its default route and sends the packet to the MAC		example, wants to reach SN1, it uses its default route and sends the
	address associated with the IRB interface on NVE2, NVE2 then makes an		packet to the MAC address associated with the IRB interface on NVE2;
	IP lookup in its IP- VRF, and finds an entry for SN1. The following		NVE2 then performs an IP lookup in its IP-VRF and finds an entry for
	subsections describe the control and data planes operations for this		SN1. The following subsections describe the control and data plane
	IRB scenario in details.		operations for this IRB scenario in detail.
	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
	Figure 7: IRB forwarding on NVEs for subnets behind TSes		Figure 7: IRB Forwarding on NVEs for Subnets behind TSs
	Note that in figure 7, above, SN1 and SN2 are configured on NVE1,		Note that in Figure 7, above, SN1 and SN2 are configured on NVE1,
	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.		configured on NVE2, which then advertises it in an IP Prefix route.
	9.2.1. Control Plane Operation		9.2.1. Control Plane Operation
	Each NVE advertises a Route Type-5 (EVPN RT-5, IP Prefix route		Each NVE advertises a route type 5 (EVPN RT-5, IP Prefix route
	defined in [I-D.ietf-bess-evpn-prefix-advertisement]) for each of its		defined in [RFC9136]) for each of its subnet prefixes with the IP
	subnet prefixes with the IP address of its TS as the next hop		address of its TS as the next hop (Gateway Address field) as follows:
	(gateway address field) as follows:
	o RD associated with the IP-VRF		* RD associated with the IP-VRF
	o ESI = 0		* ESI = 0
	o Ethernet Tag = 0;		* Ethernet Tag = 0
	o IP Prefix Length = 0 to 32 or 0 to 128		* IP Prefix Length = 0 to 32 or 0 to 128
	o IP Prefix = SNi		* IP Prefix = SNi
	o Gateway Address = IPi; IP address of TS		* Gateway Address = IPi (IP address of TS)
			* MPLS Label = 0
	o MPLS Label = 0
	This EVPN RT-5 is advertised with one or more Route Targets		This EVPN RT-5 is advertised with one or more Route Targets
	associated with the IP-VRF from which the route is originated.		associated with the IP-VRF from which the route is originated.
	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 their associated Route Targets and Extended Communities		along with its associated Route Targets and Extended Communities for
	for each of its TSes exactly as described in section 9.1.1.		each of its TSs exactly as described in Section 9.1.1.
	Upon receiving the EVPN RT-5 advertisement, the receiving NVE		Upon receiving the EVPN RT-5 advertisement, the receiving NVE
	performs the following:		performs the following:
	o It uses the Route Target to identify the corresponding IP-VRF		* It uses the Route Target to identify the corresponding IP-VRF.
	o It imports the IP prefix into its corresponding IP-VRF that is		* It imports the IP prefix into its corresponding IP-VRF configured
	configured with an import RT that is one of the RTs being carried		with an import RT that is one of the RTs being carried by the EVPN
	by the EVPN RT-5 route along with the IP address of the associated		RT-5 route, along with the IP address of the associated TS as its
	TS as its next hop.		next hop.
	When receiving the EVPN RT-2 advertisement, the receiving NVE imports		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		the MAC/IP addresses of the TS into the corresponding MAC-VRF and IP-
	per section 9.1.1. When both routes exist, recursive route		VRF per Section 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
	(e.g., VTEP DA for VxLAN encapsulation) and Router's MAC will be used		address (e.g., VTEP DA for VXLAN encapsulation), and the EVPN
	as inner MAC for VxLAN encapsulation.		Router's MAC will be used as the inner MAC for VXLAN encapsulation.
	9.2.2. Data Plane Operation		9.2.2. Data Plane Operation
	The following description of the data-plane operation describes just		The following description of the data plane operation describes just
	the logical functions and the actual implementation may differ. Lets		the logical functions, and the actual implementation may differ.
	consider data-plane operation when a host on SN1 sitting behind TS1		Let's consider the data plane operation when a host in SN1 behind TS1
	wants to send traffic to a host sitting behind SN3 behind TS3.		wants to send traffic to a host in SN3 behind TS3.
	o TS1 send a packet with MAC DA corresponding to the MAC-VRF1 IRB		* TS1 sends a packet with MAC DA corresponding to the MAC-VRF1 IRB
	interface of NVE1, and VLAN-tag corresponding to MAC-VRF1.		interface of NVE1 and a VLAN tag corresponding to MAC-VRF1.
	o Upon receiving the packet, the ingress NVE1 uses VLAN-tag to		* Upon receiving the packet, the ingress NVE1 uses the 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.		the frame to its IRB interface as in Section 9.1.1.
	o The Ethernet header of the packet is stripped and the packet is		* The Ethernet header of the packet is stripped, and the packet is
	fed to the IP-VRF; where, IP lookup is performed on the		fed to the IP-VRF, where an IP lookup is performed on the
	destination address. This lookup yields the fields needed for		destination address. This lookup yields the fields needed for
	VxLAN encapsulation with NVE2's MAC address as the inner MAC DA,		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		NVE2's IP address as the VTEP DA, and the VNI. The MAC SA is set
	NVE1's MAC address and VTEP SA is set to NVE1's IP address. NVE1		to NVE1's MAC address, and the VTEP SA is set to NVE1's IP
	also decrements the TTL/hop limit for that packet by one and if it		address. NVE1 also decrements the TTL / hop limit for that packet
	reaches zero, NVE1 discards the packet.		by one, and if it reaches zero, NVE1 discards the packet.
	o The packet is then encapsulated with the proper header based on		* The packet is then encapsulated with the proper header based on
	the above info and is forwarded to the egress NVE (NVE2).		the above info and is forwarded to the egress NVE (NVE2).
	o On the egress NVE (NVE2), assuming the packet is VxLAN		* On the egress NVE (NVE2), assuming the packet is VXLAN
	encapsulated, the VxLAN and the inner Ethernet headers are removed		encapsulated, the VXLAN and the inner Ethernet headers are
	and the resultant IP packet is fed to the IP-VRF associated with		removed, and the resultant IP packet is fed to the IP-VRF
	that the VNI.		associated with that VNI.
	o Next, a lookup is performed based on IP DA (which is in SN3) in		* Next, a lookup is performed based on the IP DA (which is in SN3)
	the associated IP-VRF of NVE2. The IP lookup yields the access-		in the associated IP-VRF of NVE2. The IP lookup yields the
	facing IRB interface over which the packet needs to be sent.		access-facing IRB interface over which the packet needs to be
	Before sending the packet over this interface, the ARP table is		sent. Before sending the packet over this interface, the ARP
	consulted to get the destination TS (TS3) MAC address. NVE2 also		table is consulted to get the destination TS (TS3) MAC address.
	decrements the TTL/hop limit for that packet by one and if it		NVE2 also decrements the TTL / hop limit for that packet by one,
	reaches zero, NVE2 discards the packet.		and if it reaches zero, NVE2 discards the packet.
	o The IP packet is encapsulated with an Ethernet header with the MAC		* The IP packet is encapsulated with an Ethernet header with the MAC
	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
	MAC address. The packet is sent to the corresponding MAC-VRF3 and		(TS3) MAC address. The packet is sent to the corresponding MAC-
	after a lookup of MAC DA, is forwarded to the destination TS (TS3)		VRF3 and, after a lookup of MAC DA, is forwarded to the
	over the corresponding interface.		destination TS (TS3) over the corresponding interface.
	10. Acknowledgements
	The authors would like to thank Sami Boutros, Jeffrey Zhang,
	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.
	11. Security Considerations		10. Security Considerations
	The security considerations for layer-2 forwarding in this document		The security considerations for Layer 2 forwarding in this document
	follow that of [RFC7432] for MPLS encapsulation and it follows that		follow those of [RFC7432] for MPLS encapsulation and those of
	of [RFC8365] for VxLAN or NVGRE encapsulations. This section		[RFC8365] for VXLAN or NVGRE encapsulations. This section describes
	describes additional considerations.		additional considerations.
	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		include both Layer 2 forwarding and Layer 3 routing on a packet-by-
	packet basis. The security consideration for layer-3 routing in this		packet basis. The security consideration for Layer 3 routing in this
	document follows that of [RFC4365] with the exception for the		document follows that of [RFC4365], with the exception of the
	application of routing protocols between CEs and PEs. Contrary to		application of routing protocols between CEs and PEs. Contrary to
	[RFC4364], this document does not describe route distribution		[RFC4364], this document does not describe route distribution
	techniques between CEs and PEs, but rather considers the CEs as TSes		techniques between CEs and PEs but rather considers the CEs as TSs or
	or VAs that do not run dynamic routing protocols. This can be		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.		with the infrastructure's dynamic routing protocols.
	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 [RFC4365]		quartet of security properties mentioned in [RFC4365]
	(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
	provided by mechanisms that are outside the scope of the VPN		be provided by mechanisms that are outside the scope of the VPN
	mechanisms.		mechanisms.
	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.		to the remote subnet.
	12. IANA Considerations		11. IANA Considerations
	IANA has allocated a new transitive extended community Type of 0x06		IANA has allocated Sub-Type value 0x03 in the "EVPN Extended
	and Sub-Type of 0x03 for EVPN Router's MAC Extended Community.		Community Sub-Types" registry as follows:
	This document has been listed as an additional reference for the MAC/		+================+======================================+===========+
	IP Advertisement route in the EVPN Route Type registry.		| Sub-Type Value | Name | Reference |
			+================+======================================+===========+
			| 0x03 | EVPN Router's MAC | RFC 9135 |
			| | Extended Community | |
			+----------------+--------------------------------------+-----------+
	13. References		Table 1
	13.1. Normative References		This document has been listed as an additional reference for the MAC/
			IP Advertisement route in the "EVPN Route Types" registry.
	[I-D.ietf-bess-evpn-prefix-advertisement]		12. References
	Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
	Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
	bess-evpn-prefix-advertisement-11 (work in progress), May
	2018.
	[I-D.ietf-idr-tunnel-encaps]		12.1. Normative References
	Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
	Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
	encaps-22 (work in progress), January 2021.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
	[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
	eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3
	Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
	<https://www.rfc-editor.org/info/rfc7348>.
	[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,		[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
	Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
	Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February		Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
	2015, <https://www.rfc-editor.org/info/rfc7432>.		2015, <https://www.rfc-editor.org/info/rfc7432>.
	[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.		[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
	Patel, "Revised Error Handling for BGP UPDATE Messages",		Patel, "Revised Error Handling for BGP UPDATE Messages",
	RFC 7606, DOI 10.17487/RFC7606, August 2015,		RFC 7606, DOI 10.17487/RFC7606, August 2015,
	<https://www.rfc-editor.org/info/rfc7606>.		<https://www.rfc-editor.org/info/rfc7606>.
	[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
	Virtualization Using Generic Routing Encapsulation",
	RFC 7637, DOI 10.17487/RFC7637, September 2015,
	<https://www.rfc-editor.org/info/rfc7637>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,		[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
	Uttaro, J., and W. Henderickx, "A Network Virtualization		Uttaro, J., and W. Henderickx, "A Network Virtualization
	Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,		Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
	DOI 10.17487/RFC8365, March 2018,		DOI 10.17487/RFC8365, March 2018,
	<https://www.rfc-editor.org/info/rfc8365>.		<https://www.rfc-editor.org/info/rfc8365>.
	13.2. Informative References		[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
			"The BGP Tunnel Encapsulation Attribute", RFC 9012,
			DOI 10.17487/RFC9012, April 2021,
			<https://www.rfc-editor.org/info/rfc9012>.
	[I-D.ietf-bess-evpn-irb-extended-mobility]		[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
	Malhotra, N., Sajassi, A., Pattekar, A., Lingala, A.,		A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
	Rabadan, J., and J. Drake, "Extended Mobility Procedures		(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
	for EVPN-IRB", draft-ietf-bess-evpn-irb-extended-		<https://www.rfc-editor.org/info/rfc9136>.
	mobility-03 (work in progress), May 2020.
	[I-D.ietf-nvo3-vxlan-gpe]		12.2. Informative References
	Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
	Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-		[EVPN] Krattiger, L., Ed., Sajassi, A., Ed., Thoria, S., Rabadan,
	gpe-10 (work in progress), July 2020.		J., and J. Drake, "EVPN Interoperability Modes", Work in
			Progress, Internet-Draft, draft-ietf-bess-evpn-modes-
			interop-00, 26 May 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
			evpn-modes-interop-00>.
			[EXTENDED-MOBILITY]
			Malhotra, N., Ed., Sajassi, A., Pattekar, A., Rabadan, J.,
			Lingala, A., and J. Drake, "Extended Mobility Procedures
			for EVPN-IRB", Work in Progress, Internet-Draft, draft-
			ietf-bess-evpn-irb-extended-mobility-07, 2 October 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
			evpn-irb-extended-mobility-07>.
	[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP		[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP
	Virtual Private Networks (VPNs)", RFC 4365,		Virtual Private Networks (VPNs)", RFC 4365,
	DOI 10.17487/RFC4365, February 2006,		DOI 10.17487/RFC4365, February 2006,
	<https://www.rfc-editor.org/info/rfc4365>.		<https://www.rfc-editor.org/info/rfc4365>.
	[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)		[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
	Version 3 for IPv4 and IPv6", RFC 5798,		Version 3 for IPv4 and IPv6", RFC 5798,
	DOI 10.17487/RFC5798, March 2010,		DOI 10.17487/RFC5798, March 2010,
	<https://www.rfc-editor.org/info/rfc5798>.		<https://www.rfc-editor.org/info/rfc5798>.
			[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
			L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
			eXtensible Local Area Network (VXLAN): A Framework for
			Overlaying Virtualized Layer 2 Networks over Layer 3
			Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
			<https://www.rfc-editor.org/info/rfc7348>.
	[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.		[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
	Rekhter, "Framework for Data Center (DC) Network		Rekhter, "Framework for Data Center (DC) Network
	Virtualization", RFC 7365, DOI 10.17487/RFC7365, October		Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
	2014, <https://www.rfc-editor.org/info/rfc7365>.		2014, <https://www.rfc-editor.org/info/rfc7365>.
			[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
			Virtualization Using Generic Routing Encapsulation",
			RFC 7637, DOI 10.17487/RFC7637, September 2015,
			<https://www.rfc-editor.org/info/rfc7637>.
			[VXLAN-GPE]
			Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed.,
			"Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work
			in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12,
			22 September 2021, <https://datatracker.ietf.org/doc/html/
			draft-ietf-nvo3-vxlan-gpe-12>.
			Acknowledgements
			The authors would like to thank Sami Boutros, Jeffrey Zhang,
			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.
	Authors' Addresses		Authors' Addresses
	Ali Sajassi		Ali Sajassi
	Cisco Systems		Cisco Systems
	Email: sajassi@cisco.com		Email: sajassi@cisco.com
	Samer Salam		Samer Salam
	Cisco Systems		Cisco Systems
End of changes. 301 change blocks.
	909 lines changed or deleted		940 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/