Diff: rfc9014xml2.original.xml

	rfc9014xml2.original.xml	rfc9014.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC4761 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	C.4761.xml">
	<!ENTITY RFC4762 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	C.4762.xml">	category="std" consensus="true"
	<!ENTITY RFC6074 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	docName="draft-ietf-bess-dci-evpn-overlay-10" number="9014"
	C.6074.xml">	ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true"
	<!ENTITY RFC7041 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	sortRefs="true" tocInclude="true" version="3">
	C.7041.xml">
	<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!-- xml2rfc v2v3 conversion 2.45.2 -->
	C.7432.xml">	<!-- Generated by id2xml 1.5.0 on 2020-05-27T19:59:24Z -->
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2119.xml">	<front>
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8174.xml">	<title abbrev="Interconnect for EVPN-Overlays">Interconnect Solution for
	<!ENTITY I-D.ietf-idr-tunnel-encaps SYSTEM "https://xml2rfc.ietf.org/public/rfc/	Ethernet VPN (EVPN) Overlay Networks</title>
	bibxml3/reference.I-D.ietf-idr-tunnel-encaps.xml">	<seriesInfo name="RFC" value="9014"/>
	<!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<author initials="J." surname="Rabadan" fullname="Jorge Rabadan" role="edito
	C.7623.xml">	r">
	<!ENTITY I-D.ietf-bess-evpn-overlay SYSTEM "https://xml2rfc.ietf.org/public/rfc/	<organization>Nokia</organization>
	bibxml3/reference.I-D.ietf-bess-evpn-overlay.xml">	<address>
	<!ENTITY RFC7543 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7543.xml">
	<!ENTITY RFC4684 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4684.xml">
	<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7348.xml">
	<!ENTITY RFC7637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7637.xml">
	<!ENTITY RFC4023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4023.xml">
	<!ENTITY RFC6870 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6870.xml">
	<!ENTITY RFC3031 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.3031.xml">
	<!ENTITY I-D.sajassi-bess-evpn-virtual-eth-segment SYSTEM "https://xml2rfc.ietf.
	org/public/rfc/bibxml3/reference.I-D.sajassi-bess-evpn-virtual-eth-segment.xml">
	]>
	<rfc submissionType="IETF" docName="draft-ietf-bess-dci-evpn-overlay-10" categor
	y="std" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2020-05-27T19:59:24Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="no"?>
	<?rfc text-list-symbols="o++*-"?>
	<!--
	draft-ietf-bess-dci-evpn-overlay-10-manual.txt(13): Warning: Expected an expi
	res
	indication top left, found none
	--><?rfc toc="yes"?>
	<front>
	<title abbrev="Interconnect Solution for EVPN-Overlays">Interconnect Solu
	tion for EVPN Overlay networks</title>
	<author initials="J." surname="Rabadan" fullname="Jorge Rabadan" role="ed
	itor">
	<organization>Nokia</organization>
	<address>
	<postal>	<postal>
	<street>777 E. Middlefield Road</street>	<street>777 E. Middlefield Road</street>
	<city>Mountain View</city>	<city>Mountain View</city>
	<region>CA</region>	<region>CA</region>
	<code>94043</code>	<code>94043</code>
	<country>USA</country>	<country>USA</country>
	</postal>	</postal>
	<email>jorge.rabadan@nokia.com</email>	<email>jorge.rabadan@nokia.com</email>

	</address>	</address>
	</author>	</author>
		<author initials="S." surname="Sathappan" fullname="Senthil Sathappan">
	<author initials="S." surname="Sathappan" fullname="Senthil Sathappan">	<organization>Nokia</organization>
	<organization>Nokia</organization>	<address>
	<address>	<email>senthil.sathappan@nokia.com</email>
	<email>senthil.sathappan@nokia.com</email>	</address>
	</address>	</author>
	</author>	<author initials="W." surname="Henderickx" fullname="Wim Henderickx">
		<organization>Nokia</organization>
	<author initials="W." surname="Henderickx" fullname="Wim Henderickx">	<address>
	<organization>Nokia</organization>	<email>wim.henderickx@nokia.com</email>
	<address>	</address>
	<email>wim.henderickx@nokia.com</email>	</author>
	</address>	<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
	</author>	<organization>Cisco</organization>
		<address>
	<author initials="A." surname="Sajassi" fullname="Ali Sajassi">	<email>sajassi@cisco.com</email>
	<organization>Cisco</organization>	</address>
	<address>	</author>
	<email>sajassi@cisco.com</email>	<author initials="J." surname="Drake" fullname="John Drake">
	</address>	<organization>Juniper</organization>
	</author>	<address>
		<email>jdrake@juniper.net</email>
	<author initials="J." surname="Drake" fullname="John Drake">	</address>
	<organization>Juniper</organization>	</author>
	<address>	<date year="2021" month="May"/>
	<email>jdrake@juniper.net</email>	<workgroup>BESS Workgroup</workgroup>
	</address>
	</author>


	<date year="2020" month="May"/>	<abstract>
	<workgroup>BESS Workgroup</workgroup>	<t>
	<abstract><t>	This document describes how Network Virtualization Overlays (NVOs) can
	This document describes how Network Virtualization Overlays (NVO) can
	be connected to a Wide Area Network (WAN) in order to extend the	be connected to a Wide Area Network (WAN) in order to extend the

	layer-2 connectivity required for some tenants. The solution analyzes	Layer 2 connectivity required for some tenants. The solution analyzes
	the interaction between NVO networks running Ethernet Virtual Private	the interaction between NVO networks running Ethernet Virtual Private

	Networks (EVPN) and other L2VPN technologies used in the WAN, such as	Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN,
	Virtual Private LAN Services (VPLS), VPLS extensions for Provider	such as
	Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how	Virtual Private LAN Services (VPLSs), VPLS extensions for Provider
	the existing technical specifications apply to the Interconnection	Backbone Bridging (PBB-VPLS), EVPN, or PBB-EVPN. It also describes how
		the existing technical specifications apply to the interconnection
	and extends the EVPN procedures needed in some cases. In particular,	and extends the EVPN procedures needed in some cases. In particular,
	this document describes how EVPN routes are processed on Gateways	this document describes how EVPN routes are processed on Gateways
	(GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well	(GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well

	as the Interconnect Ethernet Segment (I-ES) to provide multi-homing,	as the Interconnect Ethernet Segment (I-ES), to provide multihoming. This
	and the use of the Unknown MAC route to avoid MAC scale issues on	document also describes the use of the Unknown MAC Route (UMR) to avoid issue
	Data Center Network Virtualization Edge (NVE) devices.</t>	s of a Media Access Control (MAC) scale on Data Center Network Virtualization Ed
		ge (NVE) devices.</t>
	</abstract>	</abstract>
	</front>	</front>
		<middle>
	<middle>	<section anchor="sect-2" numbered="true" toc="default">
	<section title="Conventions and Terminology" anchor="sect-1"><t>	<name>Introduction</name>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<t>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	<xref target="RFC8365" format="default"/> discusses the use of Ethernet Virtu
	"OPTIONAL" in this document are to be interpreted as described in BCP	al Private
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the	Networks (EVPNs) <xref target="RFC7432" format="default"/> as the control pla
	y appear in all	ne for Network
	capitals, as shown here.</t>	Virtualization Overlays (NVOs), where VXLAN <xref target="RFC7348"
		format="default"/>, NVGRE <xref target="RFC7637" format="default"/>, or
	<t>	MPLS over GRE <xref target="RFC4023" format="default"/> can be used as
	AC: Attachment Circuit.</t>	possible data plane encapsulation options.</t>
		<t>
	<t>	While this model provides a scalable and efficient multitenant solution
	ARP: Address Resolution Protocol.</t>

	<t>
	BUM: refers to Broadcast, Unknown unicast and Multicast traffic.</t>

	<t>
	CE: Customer Equipment.</t>

	<t>
	CFM: Connectivity Fault Management.</t>

	<t>
	DC and DCI: Data Center and Data Center Interconnect.</t>

	<t>
	DC RR(s) and WAN RR(s): refers to the Data Center and Wide Area
	Network Route Reflectors, respectively.</t>

	<t>
	DF and NDF: Designated Forwarder and Non-Designated Forwarder.</t>

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

	<t>
	EVI: EVPN Instance.</t>

	<t>
	EVPN Tunnel binding: refers to a tunnel to a remote PE/NVE for a
	given EVI. Ethernet packets in these bindings are encapsulated with
	the Overlay or MPLS encapsulation and the EVPN label at the bottom of
	the stack.</t>

	<t>
	ES and vES: Ethernet Segment and virtual Ethernet Segment.</t>

	<t>
	ESI: Ethernet Segment Identifier.</t>

	<t>
	GW: Gateway or Data Center Gateway.</t>

	<t>
	I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect Ethernet
	Segment Identifier. An I-ES is defined on the GWs for multi-homing to/from
	the WAN.</t>

	<t>
	MAC-VRF: refers to an EVI instance in a particular node.</t>

	<t>
	MP2P and LSM tunnels: refer to Multi-Point to Point and Label
	Switched Multicast tunnels.</t>

	<t>
	ND: Neighbor Discovery protocol.</t>

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

	<t>
	NVGRE: Network Virtualization using Generic Routing Encapsulation.</t>

	<t>
	NVO: refers to Network Virtualization Overlays.</t>

	<t>
	OAM: Operations and Maintenance.</t>

	<t>
	PBB: Provider Backbone Bridging.</t>

	<t>
	PE: Provider Edge.</t>

	<t>
	PW: Pseudowire.</t>

	<t>
	RD: Route-Distinguisher.</t>

	<t>
	RT: Route-Target.</t>

	<t>
	S/C-TAG: refers to a combination of Service Tag and Customer Tag in a
	802.1Q frame.</t>

	<t>
	TOR: Top-Of-Rack switch.</t>

	<t>
	UMR: Unknown MAC Route.</t>

	<t>
	VNI/VSID: refers to VXLAN/NVGRE virtual identifiers.</t>

	<t>
	VPLS: Virtual Private LAN Service.</t>

	<t>
	VSI: Virtual Switch Instance or VPLS instance in a particular PE.</t>

	<t>
	VXLAN: Virtual eXtensible LAN.</t>

	</section>

	<section title="Introduction" anchor="sect-2"><t>
	<xref target="I-D.ietf-bess-evpn-overlay"/> discusses the use of Ethernet Vir
	tual Private
	Networks (EVPN) <xref target="RFC7432"/> as the control plane for Network
	Virtualization Overlays (NVO), where VXLAN <xref target="RFC7348"/>, NVGRE <x
	ref target="RFC7637"/>
	or MPLS over GRE <xref target="RFC4023"/> can be used as possible data plane
	encapsulation options.</t>

	<t>
	While this model provides a scalable and efficient multi-tenant solution
	within the Data Center, it might not be easily extended to the Wide Area	within the Data Center, it might not be easily extended to the Wide Area

	Network (WAN) in some cases due to the requirements and existing deployed	Network (WAN) in some cases, due to the requirements and existing deployed
	technologies. For instance, a Service Provider might have an already	technologies. For instance, a Service Provider might have an already

	deployed Virtual Private LAN Service (VPLS) <xref target="RFC4761"/><xref tar	deployed Virtual Private LAN Service (VPLS) <xref target="RFC4761" format="de
	get="RFC4762"/>, VPLS	fault"/> <xref target="RFC4762" format="default"/>, VPLS
	extensions for Provider Backbone Bridging (PBB-VPLS) <xref target="RFC7041"/>	extensions for Provider Backbone Bridging (PBB-VPLS) <xref target="RFC7041"
	, EVPN	format="default"/>, EVPN
	<xref target="RFC7432"/> or PBB-EVPN <xref target="RFC7623"/> network that ha	<xref target="RFC7432" format="default"/>, or PBB-EVPN <xref
	s to be used to interconnect	target="RFC7623" format="default"/> network that has to be used to
		interconnect
	Data Centers and WAN VPN users. A Gateway (GW) function is required in	Data Centers and WAN VPN users. A Gateway (GW) function is required in

	these cases. In fact, <xref target="I-D.ietf-bess-evpn-overlay"/> discusses t	these cases. In fact, <xref target="RFC8365" format="default"/> discusses two
	wo main Data Center	main Data Center
	Interconnect solution groups: "DCI using GWs" and "DCI using ASBRs". This	Interconnect (DCI) solution groups: "DCI using GWs" and "DCI using ASBRs". Th
		is
	document specifies the solutions that correspond to the "DCI using GWs"	document specifies the solutions that correspond to the "DCI using GWs"
	group.</t>	group.</t>

		<t>
	<t>	It is assumed that the NVO GW and the WAN Edge functions
	It is assumed that the NVO Gateway (GW) and the WAN Edge functions	can be decoupled into two separate systems or integrated into the same
	can be decoupled in two separate systems or integrated into the same	system. The former option will be referred to as "decoupled interconnect
	system. The former option will be referred as "Decoupled Interconnect solutio	solution" throughout the document, whereas the latter one will be
	n" throughout the document, whereas the latter one will be	referred to as "integrated interconnect solution".</t>
	referred as "Integrated Interconnect solution".</t>	<t>

	<t>
	The specified procedures are local to the redundant GWs connecting a	The specified procedures are local to the redundant GWs connecting a
	DC to the WAN. The document does not preclude any combination across	DC to the WAN. The document does not preclude any combination across
	different DCs for the same tenant. For instance, a "Decoupled"	different DCs for the same tenant. For instance, a "Decoupled"

	solution can be used in GW1 and GW2 (for DC1) and an "Integrated"	solution can be used in GW1 and GW2 (for DC1), and an "Integrated"
	solution can be used in GW3 and GW4 (for DC2).</t>	solution can be used in GW3 and GW4 (for DC2).</t>

		<t>
	<t>	While the Gateways and WAN Provider Edges (PEs) use existing specifications i
	While the Gateways and WAN PEs use existing specifications in some	n some
	cases, the document also defines extensions that are specific to DCI.	cases, the document also defines extensions that are specific to DCI.
	In particular, those extensions are:</t>	In particular, those extensions are:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>The Interconnect Ethernet Segment (I-ES), an	<li>The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that
	Ethernet Segment that	can be associated to a set of pseudowires (PWs) or other tunnels. The I-ES
	can be associated to a set of PWs or other tunnels. I-ES defined in	defined in
	this document is not associated with a set of Ethernet links, as	this document is not associated with a set of Ethernet links, as

	per <xref target="RFC7432"/>, but rather with a set of virtual tunnels (e.g ., a	per <xref target="RFC7432" format="default"/>, but rather with a set of vir tual tunnels (e.g., a
	set of PWs). This set of virtual tunnels is referred to as vES	set of PWs). This set of virtual tunnels is referred to as vES

	<xref target="I-D.sajassi-bess-evpn-virtual-eth-segment"/>.</t>	<xref target="I-D.ietf-bess-evpn-virtual-eth-segment" format="default"/>.</
		li>
	<t>The use of the Unknown MAC route in a DCI scenario.</t>	<li>The use of the Unknown MAC Route (UMR) in a DCI scenario.</li>
		<li>The processing of EVPN routes on Gateways with MAC-VRFs connecting
	<t>The processing of EVPN routes on Gateways with MAC-VRFs connecting
	EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-Overlay	EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-Overlay

	networks.</t>	networks.</li>
		</ul>
	</list>	</section>
	</t>	<section anchor="sect-1" numbered="true" toc="default">
		<name>Conventions and Terminology</name>
	</section>	<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		<dl>
		<dt>AC:</dt><dd> Attachment Circuit</dd>
		<dt>ARP:</dt><dd>Address Resolution Protocol</dd>
		<dt>BUM:</dt><dd>Broadcast, Unknown Unicast and Multicast (traffic)</dd>
		<dt>CE:</dt><dd>Customer Equipment</dd>
		<dt>CFM:</dt><dd>Connectivity Fault Management</dd>
		<dt>DC:</dt><dd>Data Center</dd>
		<dt>DCI:</dt><dd>Data Center Interconnect</dd>
		<dt>DF:</dt><dd>Designated Forwarder</dd>
		<dt>EVI:</dt><dd>EVPN Instance</dd>
		<dt>EVPN:</dt><dd>Ethernet Virtual Private Network, as in <xref
		target="RFC7432" format="default"/></dd>
		<dt>EVPN Tunnel binding:</dt><dd>refers to a tunnel to a remote PE/NVE
		for a given EVI. Ethernet packets in these bindings are encapsulated with
		the Overlay or MPLS encapsulation and the EVPN label at the bottom of
		the stack.</dd>
		<dt>ES:</dt><dd>Ethernet Segment</dd>
		<dt>ESI:</dt><dd>Ethernet Segment Identifier</dd>
		<dt>GW:</dt><dd>Gateway or Data Center Gateway</dd>
		<dt>I-ES and I-ESI:</dt><dd>Interconnect Ethernet Segment and
		Interconnect Ethernet Segment Identifier. An I-ES is defined on the GWs
		for multihoming to/from the WAN.</dd>
		<dt>MAC</dt><dd>Media Access Control</dd>
		<dt>MAC-VRF:</dt><dd>refers to an EVI instance in a particular node</dd>
		<dt>MP2P and LSM tunnels:</dt><dd>refer to multipoint-to-point and label
		switched multicast tunnels</dd>
		<dt>ND:</dt><dd>Neighbor Discovery</dd>
		<dt>NDF:</dt><dd>Non-Designated Forwarder</dd>
		<dt>NVE:</dt><dd>Network Virtualization Edge</dd>
		<dt>NVGRE:</dt><dd>Network Virtualization using Generic Routing
		Encapsulation</dd>
		<dt>NVO:</dt><dd>Network Virtualization Overlay</dd>
		<dt>OAM:</dt><dd>Operations, Administration, and Maintenance</dd>
		<dt>PBB:</dt><dd>Provider Backbone Bridging</dd>
		<dt>PE:</dt><dd>Provider Edge</dd>
		<dt>PW:</dt><dd>Pseudowire</dd>
		<dt>RD:</dt><dd>Route Distinguisher</dd>
		<dt>RR:</dt><dd>Route Reflector</dd>
		<dt>RT:</dt><dd>Route Target</dd>
		<dt>S/C-TAG:</dt><dd>refers to a combination of Service Tag and Customer
		Tag in a 802.1Q frame</dd>
		<dt>TOR:</dt><dd>Top-Of-Rack</dd>
		<dt>UMR:</dt><dd>Unknown MAC Route</dd>
		<dt>vES:</dt><dd>virtual Ethernet Segment</dd>
		<dt>VNI/VSID:</dt><dd>refers to VXLAN/NVGRE virtual identifiers</dd>
		<dt>VPLS:</dt><dd>Virtual Private LAN Service</dd>
		<dt>VSI:</dt><dd>Virtual Switch Instance or VPLS instance in a
		particular PE</dd>
		<dt>VXLAN:</dt><dd>Virtual eXtensible LAN</dd>
		</dl>
		</section>


	<section title="Decoupled Interconnect solution for EVPN overlay networks	<section anchor="sect-3" numbered="true" toc="default">
	" anchor="sect-3"><t>	<name>Decoupled Interconnect Solution for EVPN-Overlay Networks</name>
		<t>
	This section describes the interconnect solution when the GW and WAN	This section describes the interconnect solution when the GW and WAN

	Edge functions are implemented in different systems. Figure 1 depicts	Edge functions are implemented in different systems. <xref target="fig-1"/> d epicts
	the reference model described in this section. Note that, although	the reference model described in this section. Note that, although

	not shown in Figure 1, GWs may have local ACs (Attachment Circuits).</t>	not shown in <xref target="fig-1"/>, GWs may have local Attachment Circuits
		(ACs).</t>
	<figure title="Decoupled Interconnect model" anchor="ure-decoupled-interc	<figure anchor="fig-1">
	onnect-model"><artwork><![CDATA[	<name>Decoupled Interconnect Model</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+--+	+--+
	\|CE\|	\|CE\|
	+--+	+--+
	\|	\|
	+----+	+----+
	+----\| PE \|----+	+----\| PE \|----+
	+---------+ \| +----+ \| +---------+	+---------+ \| +----+ \| +---------+
	+----+ \| +---+ +----+ +----+ +---+ \| +----+	+----+ \| +---+ +----+ +----+ +---+ \| +----+
	\|NVE1\|--\| \| \| \|WAN \| \|WAN \| \| \| \|--\|NVE3\|	\|NVE1\|--\| \| \| \|WAN \| \|WAN \| \| \| \|--\|NVE3\|
	+----+ \| \|GW1\|--\|Edge\| \|Edge\|--\|GW3\| \| +----+	+----+ \| \|GW1\|--\|Edge\| \|Edge\|--\|GW3\| \| +----+
	\| +---+ +----+ +----+ +---+ \|	\| +---+ +----+ +----+ +---+ \|
	\| NVO-1 \| \| WAN \| \| NVO-2 \|	\| NVO-1 \| \| WAN \| \| NVO-2 \|
	\| +---+ +----+ +----+ +---+ \|	\| +---+ +----+ +----+ +---+ \|
	\| \| \| \|WAN \| \|WAN \| \| \| \|	\| \| \| \|WAN \| \|WAN \| \| \| \|
	+----+ \| \|GW2\|--\|Edge\| \|Edge\|--\|GW4\| \| +----+	+----+ \| \|GW2\|--\|Edge\| \|Edge\|--\|GW4\| \| +----+
	\|NVE2\|--\| +---+ +----+ +----+ +---+ \|--\|NVE4\|	\|NVE2\|--\| +---+ +----+ +----+ +---+ \|--\|NVE4\|
	+----+ +---------+ \| \| +---------+ +----+	+----+ +---------+ \| \| +---------+ +----+
	+--------------+	+--------------+

	\|<-EVPN-Overlay-->\|<-VLAN->\|<-WAN L2VPN->\|<--PW-->\|<--EVPN-Overlay->\|	\|<-EVPN-Overlay-->\|<-VLAN->\|<-WAN L2VPN->\|<--PW-->\|<--EVPN-Overlay->\|

	hand-off hand-off	handoff handoff
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	The following section describes the interconnect requirements for	The following section describes the interconnect requirements for
	this model.</t>	this model.</t>

		<section anchor="sect-3.1" numbered="true" toc="default">
	<section title="Interconnect requirements" anchor="sect-3.1"><t>	<name>Interconnect Requirements</name>
	The Decoupled Interconnect architecture is intended to be deployed in	<t>
		The decoupled interconnect architecture is intended to be deployed in
	networks where the EVPN-Overlay and WAN providers are different	networks where the EVPN-Overlay and WAN providers are different
	entities and a clear demarcation is needed. This solution solves the	entities and a clear demarcation is needed. This solution solves the
	following requirements:</t>	following requirements:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>A simple connectivity hand-off between the EV	<li>A simple connectivity handoff between the EVPN-Overlay network
	PN-Overlay network
	provider and the WAN provider so that QoS and security enforcement	provider and the WAN provider so that QoS and security enforcement

	is easily accomplished.</t>	are easily accomplished.</li>
		<li>Independence of the L2VPN technology deployed in
	<t>Independence of the Layer Two VPN (L2VPN) technology deployed in	the WAN.</li>
	the WAN.</t>	<li>Multihoming between GW and WAN Edge routers, including per-service
		load balancing. Per-flow load balancing is not a strong requirement,
	<t>Multi-homing between GW and WAN Edge routers, including per-service
	load balancing. Per-flow load balancing is not a strong requirement
	since a deterministic path per service is usually required for an	since a deterministic path per service is usually required for an

	easy QoS and security enforcement.</t>	easy QoS and security enforcement.</li>
		<li>Support of Ethernet OAM and Connectivity Fault Management (CFM)
	<t>Support of Ethernet OAM and Connectivity Fault Management (CFM)	<xref target="IEEE.802.1AG" format="default"/> <xref target="Y.1731" format
	<xref target="IEEE.802.1AG"/><xref target="Y.1731"/> functions between the	="default"/> functions between the GW and the WAN Edge router
	GW and the WAN Edge router	to detect individual AC failures.</li>
	to detect individual AC failures.</t>	<li>
		<t>Support for the following optimizations at the GW:</t>
	<t>Support for the following optimizations at the GW:<list style="symbols	<ul spacing="normal">
	"><t>Flooding reduction of unknown unicast traffic sourced from the DC	<li>Flooding reduction of unknown unicast traffic sourced from the
	Network Virtualization Edge devices (NVEs).</t>	DC
		Network Virtualization Edge (NVE) devices.</li>
	<t>Control of the WAN MAC addresses advertised to the DC.</t>	<li>Control of the WAN MAC addresses advertised to the DC.</li>
		<li>Address Resolution Protocol (ARP) and Neighbor Discovery (ND)
	<t>Address Resolution Protocol (ARP) and Neighbor Discovery (ND)	flooding control for the requests coming from the WAN.</li>
	flooding control for the requests coming from the WAN.</t>	</ul>
		</li>
	</list>	</ul>
	</t>	</section>
		<section anchor="sect-3.2" numbered="true" toc="default">
	</list>	<name>VLAN-Based Handoff</name>
	</t>	<t>
		In this option, the handoff between the GWs and the WAN Edge routers
	</section>	is based on VLANs <xref target="IEEE.802.1Q" format="default"/>. This
		is illustrated in <xref target="fig-1"/>
	<section title="VLAN-based hand-off" anchor="sect-3.2"><t>
	In this option, the hand-off between the GWs and the WAN Edge routers
	is based on VLANs <xref target="IEEE.802.1Q-2014"/>. This is illustrated in F
	igure 1
	(between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in	(between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in
	the GW is connected to a different VSI/MAC-VRF instance in the WAN	the GW is connected to a different VSI/MAC-VRF instance in the WAN
	Edge router by using a different C-TAG VLAN ID or a different	Edge router by using a different C-TAG VLAN ID or a different
	combination of S/C-TAG VLAN IDs that matches at both sides.</t>	combination of S/C-TAG VLAN IDs that matches at both sides.</t>

		<t>
	<t>
	This option provides the best possible demarcation between the DC and	This option provides the best possible demarcation between the DC and

	WAN providers and it does not require control plane interaction	WAN providers, and it does not require control plane interaction
	between both providers. The disadvantage of this model is the	between both providers. The disadvantage of this model is the

	provisioning overhead since the service has to be mapped to a C-TAG	provisioning overhead, since the service has to be mapped to a C-TAG
	or S/C-TAG VLAN ID combination at both GW and WAN Edge routers.</t>	or S/C-TAG VLAN ID combination at both GW and WAN Edge routers.</t>

		<t>
	<t>
	In this model, the GW acts as a regular Network Virtualization Edge	In this model, the GW acts as a regular Network Virtualization Edge

	(NVE) towards the DC. Its control plane, data plane procedures and	(NVE) towards the DC. Its control plane, data plane procedures, and
	interactions are described in <xref target="I-D.ietf-bess-evpn-overlay"/>.</t	interactions are described in <xref target="RFC8365" format="default"/>.</t>
	>	<t>

	<t>
	The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with	The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with

	attachment circuits (ACs) to the GWs. Its functions are described in	Attachment Circuits (ACs) to the GWs.
	<xref target="RFC4761"/>, <xref target="RFC4762"/>, <xref target="RFC6074"/>
	or <xref target="RFC7432"/>, <xref target="RFC7623"/>.</t>

	</section>


	<section title="PW-based (Pseudowire-based) hand-off" anchor="sect-3.3"><	Its functions are described in
	t>	<xref target="RFC4761" format="default"/>, <xref target="RFC4762"
		format="default"/>, <xref target="RFC6074" format="default"/>, <xref
		target="RFC7432" format="default"/>, and <xref target="RFC7623"
		format="default"/>.</t>
		</section>
		<section anchor="sect-3.3" numbered="true" toc="default">
		<name>PW-Based Handoff</name>
		<t>
	If MPLS between the GW and the WAN Edge router is an option, a PW-based	If MPLS between the GW and the WAN Edge router is an option, a PW-based

	Interconnect solution can be deployed. In this option the hand-off between	interconnect solution can be deployed. In this option, the handoff between
	both routers is based on FEC128-based PWs <xref target="RFC4762"/> or FEC129-	both routers is based on FEC128-based PWs <xref target="RFC4762" format="defa
	based PWs	ult"/> or FEC129-based PWs
	(for a greater level of network automation) <xref target="RFC6074"/>. Note th	(for a greater level of network automation) <xref target="RFC6074" format="de
	at this model	fault"/>. Note that this model
	still provides a clear demarcation boundary between DC and WAN (since there	still provides a clear demarcation between DC and WAN (since there
	is a single PW between each MAC-VRF and peer VSI), and security/QoS	is a single PW between each MAC-VRF and peer VSI), and security/QoS

	policies may be applied on a per PW basis. This model provides better	policies may be applied on a per-PW basis. This model provides better
	scalability than a C-TAG based hand-off and less provisioning overhead than	scalability than a C-TAG-based handoff and less provisioning overhead than
	a combined C/S-TAG hand-off. The PW-based hand-off interconnect is	a combined C/S-TAG handoff. The PW-based handoff interconnect is
	illustrated in Figure 1 (between the NVO-2 GWs and the WAN Edge routers).</t>	illustrated in <xref target="fig-1"/> (between the NVO-2 GWs and the WAN Edge
		routers).</t>
	<t>	<t>
	In this model, besides the usual MPLS procedures between GW and WAN	In this model, besides the usual MPLS procedures between GW and WAN

	Edge router <xref target="RFC3031"/>, the GW MUST support an interworking fun ction	Edge router <xref target="RFC3031" format="default"/>, the GW <bcp14>MUST</bc p14> support an interworking function
	in each MAC-VRF that requires extension to the WAN:</t>	in each MAC-VRF that requires extension to the WAN:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>If a FEC128-based PW is used between the MAC-	<li>If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI
	VRF (GW) and the VSI (WAN	(WAN
	Edge), the corresponding VCID MUST be provisioned on the MAC-VRF and	Edge), the corresponding Virtual Connection Identifier (VCID) <bcp14>MUST</
	match the VCID used in the peer VSI at the WAN Edge router.</t>	bcp14> be provisioned on the MAC-VRF and
		match the VCID used in the peer VSI at the WAN Edge router.</li>
	<t>If BGP Auto-discovery <xref target="RFC6074"/> and FEC129-based PWs ar	<li>If BGP Auto-discovery <xref target="RFC6074" format="default"/> an
	e used	d FEC129-based PWs are used
	between the GW MAC-VRF and the WAN Edge VSI, the provisioning of	between the GW MAC-VRF and the WAN Edge VSI, the provisioning of

	the VPLS-ID MUST be supported on the MAC-VRF and MUST match the	the VPLS-ID <bcp14>MUST</bcp14> be supported on the MAC-VRF and <bcp14>MUST
	VPLS-ID used in the WAN Edge VSI.</t>	</bcp14> match the
		VPLS-ID used in the WAN Edge VSI.</li>
	</list>	</ul>
	</t>	<t>

	<t>
	If a PW-based handoff is used, the GW's AC (or point of attachment to	If a PW-based handoff is used, the GW's AC (or point of attachment to

	the EVPN Instance) uses a combination of a PW label and VLAN IDs. PWs	the EVPN instance) uses a combination of a PW label and VLAN IDs. PWs
	are treated as service interfaces defined in <xref target="RFC7432"/>.</t>	are treated as service interfaces, defined in <xref target="RFC7432" format="
		default"/>.</t>
	</section>	</section>
		<section anchor="sect-3.4" numbered="true" toc="default">
	<section title="Multi-homing solution on the GWs" anchor="sect-3.4"><t>	<name>Multihoming Solution on the GWs</name>
	EVPN single-active multi-homing, i.e. per-service load-balancing	<t>
	multi-homing is required in this type of interconnect.</t>	EVPN single-active multihoming -- i.e., per-service load-balancing
		multihoming -- is required in this type of interconnect.</t>
		<t>


	<t>	The GWs will be provisioned with a unique ES for each WAN interconnect,
	The GWs will be provisioned with a unique ES per WAN interconnect,	and the handoff attachment circuits or PWs between the GW and the
	and the hand-off attachment circuits or PWs between the GW and the	WAN Edge router will be assigned an ESI for each such ES. The ESI will be
	WAN Edge router will be assigned an ESI for such ES. The ESI will be
	administratively configured on the GWs according to the procedures in	administratively configured on the GWs according to the procedures in

	<xref target="RFC7432"/>. This Interconnect ES will be referred as "I-ES" her	<xref target="RFC7432" format="default"/>. This I-ES will be
	eafter,	referred to as "I-ES" hereafter,
	and its identifier will be referred as "I-ESI". <xref target="RFC7432"/> desc	and its identifier will be referred to as "I-ESI". Different ESI types are de
	ribes	scribed in <xref target="RFC7432"
	different ESI Types. The use of Type 0 for the I-ESI is RECOMMENDED	format="default"/>. The use of Type 0 for the I-ESI is <bcp14>RECOMMENDED</bc
		p14>
	in this document.</t>	in this document.</t>

		<t>
	<t>	The solution (on the GWs) <bcp14>MUST</bcp14> follow the single-active multih
	The solution (on the GWs) MUST follow the single-active multi-homing	oming
	procedures as described in <xref target="I-D.ietf-bess-evpn-overlay"/> for th	procedures as described in <xref target="RFC8365" format="default"/> for
	e provisioned I-ESI,	the provisioned I-ESI -- i.e., Ethernet A-D routes per ES and per EVI will be
	i.e. Ethernet A-D routes per ES and per EVI will be advertised to the DC	advertised to the DC
	NVEs for the multi-homing functions, ES routes will be advertised so that	NVEs for the multihoming functions, and ES routes will be advertised so that
	ES discovery and Designated Forwarder (DF) procedures can be followed. The	ES discovery and Designated Forwarder (DF) procedures can be followed. The

	MAC addresses learned (in the data plane) on the hand-off links will be	MAC addresses learned (in the data plane) on the handoff links will be
	advertised with the I-ESI encoded in the ESI field.</t>	advertised with the I-ESI encoded in the ESI field.</t>

		</section>
	</section>	<section anchor="sect-3.5" numbered="true" toc="default">
		<name>Gateway Optimizations</name>
	<section title="Gateway Optimizations" anchor="sect-3.5"><t>	<t>
	The following GW features are optional and optimize the control plane	The following GW features are optional and optimize the control plane
	and data plane in the DC.</t>	and data plane in the DC.</t>

		<section anchor="sect-3.5.1" numbered="true" toc="default">
	<section title="MAC Address Advertisement Control" anchor="sect-3.5.1"><t	<name>MAC Address Advertisement Control</name>
	>	<t>
	The use of EVPN in NVO networks brings a significant number of	The use of EVPN in NVO networks brings a significant number of

	benefits as described in <xref target="I-D.ietf-bess-evpn-overlay"/>. However , if multiple DCs	benefits, as described in <xref target="RFC8365" format="default"/>. However, if multiple DCs
	are interconnected into a single EVI, each DC will have to import all	are interconnected into a single EVI, each DC will have to import all
	of the MAC addresses from each of the other DCs.</t>	of the MAC addresses from each of the other DCs.</t>

		<t>
	<t>	Even if optimized BGP techniques like RT constraint <xref target="RFC4684" fo
	Even if optimized BGP techniques like RT-constraint <xref target="RFC4684"/>	rmat="default"/> are
	are
	used, the number of MAC addresses to advertise or withdraw (in case	used, the number of MAC addresses to advertise or withdraw (in case
	of failure) by the GWs of a given DC could overwhelm the NVEs within	of failure) by the GWs of a given DC could overwhelm the NVEs within
	that DC, particularly when the NVEs reside in the hypervisors.</t>	that DC, particularly when the NVEs reside in the hypervisors.</t>

		<t>
	<t>	The solution specified in this document uses the Unknown MAC Route (UMR)
	The solution specified in this document uses the 'Unknown MAC Route' (UMR)	that is advertised into a given DC by each of the DC's GWs. This route is
	which is advertised into a given DC by each of the DC's GWs. This route is	defined in <xref target="RFC7543" format="default"/> and is a regular EVPN MA
	defined in <xref target="RFC7543"/> and is a regular EVPN MAC/IP Advertisemen	C/IP Advertisement route in
	t route in
	which the MAC Address Length is set to 48, the MAC address is set to 0, and	which the MAC Address Length is set to 48, the MAC address is set to 0, and
	the ESI field is set to the DC GW's I-ESI.</t>	the ESI field is set to the DC GW's I-ESI.</t>

		<t>
	<t>	An NVE within that DC that understands and processes the UMR will send
	An NVE within that DC that understands and process the UMR will send	unknown unicast frames to one of the DC's GWs, which will then forward
	unknown unicast frames to one of the DCs GWs, which will then forward
	that packet to the correct egress PE. Note that, because the ESI is	that packet to the correct egress PE. Note that, because the ESI is

	set to the DC GW's I-ESI, all-active multi-homing can be applied to	set to the DC GW's I-ESI, all-active multihoming can be applied to
	unknown unicast MAC addresses. An NVE that does not understand the	unknown unicast MAC addresses. An NVE that does not understand the

	Unknown MAC route will handle unknown unicast as described in	Unknown MAC Route will handle unknown unicast as described in
	<xref target="RFC7432"/>.</t>	<xref target="RFC7432" format="default"/>.</t>
		<t>
	<t>	This document proposes that local policy determine whether MAC
	This document proposes that local policy determines whether MAC
	addresses and/or the UMR are advertised into a given DC. As an	addresses and/or the UMR are advertised into a given DC. As an
	example, when all the DC MAC addresses are learned in the	example, when all the DC MAC addresses are learned in the
	control/management plane, it may be appropriate to advertise only the	control/management plane, it may be appropriate to advertise only the
	UMR. Advertising all the DC MAC addresses in the control/management	UMR. Advertising all the DC MAC addresses in the control/management
	plane is usually the case when the NVEs reside in hypervisors. Refer	plane is usually the case when the NVEs reside in hypervisors. Refer

	to <xref target="I-D.ietf-bess-evpn-overlay"/> section 7.</t>	to <xref target="RFC8365" sectionFormat="comma" section="7"/>.</t>
		<t>
	<t>	It is worth noting that the UMR usage in <xref target="RFC7543"
	It is worth noting that the UMR usage in <xref target="RFC7543"/> and the UMR	format="default"/> and the UMR usage in
	usage in
	this document are different. In the former, a Virtual Spoke (V-spoke) does	this document are different. In the former, a Virtual Spoke (V-spoke) does
	not necessarily learn all the MAC addresses pertaining to hosts in other	not necessarily learn all the MAC addresses pertaining to hosts in other
	V-spokes of the same network. The communication between two V-spokes is	V-spokes of the same network. The communication between two V-spokes is

	done through the DMG, until the V-spokes learn each other's MAC	done through the Default MAC Gateway (DMG) until the V-spokes learn each othe r's MAC
	addresses. In this document, two leaf switches in the same DC are	addresses. In this document, two leaf switches in the same DC are

	recommended to learn each other's MAC addresses for the same EVI. The leaf	recommended for V-spokes to learn each other's MAC addresses for the same EVI
	to leaf communication is always direct and does not go through the GW.</t>	. The
		leaf-to-leaf communication is always direct and does not go through
	</section>	the GW.</t>
		</section>
	<section title="ARP/ND flooding control" anchor="sect-3.5.2"><t>	<section anchor="sect-3.5.2" numbered="true" toc="default">
		<name>ARP/ND Flooding Control</name>
		<t>
	Another optimization mechanism, naturally provided by EVPN in the	Another optimization mechanism, naturally provided by EVPN in the
	GWs, is the Proxy ARP/ND function. The GWs should build a Proxy	GWs, is the Proxy ARP/ND function. The GWs should build a Proxy

	ARP/ND cache table as per <xref target="RFC7432"/>. When the active GW receiv	ARP/ND cache table, as per <xref target="RFC7432" format="default"/>. When
	es an	the active GW receives an
	ARP/ND request/solicitation coming from the WAN, the GW does a Proxy	ARP/ND request/solicitation coming from the WAN, the GW does a Proxy
	ARP/ND table lookup and replies as long as the information is	ARP/ND table lookup and replies as long as the information is
	available in its table.</t>	available in its table.</t>

		<t>
	<t>
	This mechanism is especially recommended on the GWs, since it	This mechanism is especially recommended on the GWs, since it
	protects the DC network from external ARP/ND-flooding storms.</t>	protects the DC network from external ARP/ND-flooding storms.</t>

		</section>
	</section>	<section anchor="sect-3.5.3" numbered="true" toc="default">
		<name>Handling Failures between GW and WAN Edge Routers</name>
	<section title="Handling failures between GW and WAN Edge routers" anchor	<t>
	="sect-3.5.3"><t>	Link/PE failures are handled on the GWs as specified in <xref target="RFC7432
	Link/PE failures are handled on the GWs as specified in <xref target="RFC7432	" format="default"/>.
	"/>.	The GW detecting the failure will withdraw the EVPN routes, as per
	The GW detecting the failure will withdraw the EVPN routes as per	<xref target="RFC7432" format="default"/>.</t>
	<xref target="RFC7432"/>.</t>	<t>

	<t>
	Individual AC/PW failures may be detected by OAM mechanisms. For	Individual AC/PW failures may be detected by OAM mechanisms. For
	instance:</t>	instance:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>If the Interconnect solution is based on a VL	<li>If the interconnect solution is based on a VLAN handoff, Etherne
	AN hand-off, Ethernet-CFM	t-CFM
	<xref target="IEEE.802.1AG"/><xref target="Y.1731"/> may be used to detect	<xref target="IEEE.802.1AG" format="default"/> <xref target="Y.1731" format
	individual AC failures on both,	="default"/> may be used to detect individual AC failures on both
	the GW and WAN Edge router. An individual AC failure will trigger the	the GW and WAN Edge router. An individual AC failure will trigger the
	withdrawal of the corresponding A-D per EVI route as well as the MACs	withdrawal of the corresponding A-D per EVI route as well as the MACs

	learned on that AC.</t>	learned on that AC.</li>
		<li>If the interconnect solution is based on a PW handoff, the Label
	<t>If the Interconnect solution is based on a PW hand-off, the Label	Distribution Protocol (LDP) PW Status bits TLV <xref target="RFC6870" forma
	Distribution Protocol (LDP) PW Status bits TLV <xref target="RFC6870"/> may	t="default"/> may be
	be	used to detect individual PW failures on both the GW and WAN Edge
	used to detect individual PW failures on both, the GW and WAN Edge	router.</li>
	router.</t>	</ul>
		</section>
	</list>	</section>
	</t>	</section>
		<section anchor="sect-4" numbered="true" toc="default">
	</section>	<name>Integrated Interconnect Solution for EVPN-Overlay Networks</name>
		<t>
	</section>

	</section>

	<section title="Integrated Interconnect solution for EVPN overlay network
	s" anchor="sect-4"><t>
	When the DC and the WAN are operated by the same administrative	When the DC and the WAN are operated by the same administrative
	entity, the Service Provider can decide to integrate the GW and WAN	entity, the Service Provider can decide to integrate the GW and WAN

	Edge PE functions in the same router for obvious CAPEX and OPEX	Edge PE functions in the same router for obvious reasons to save as relates t
	saving reasons. This is illustrated in Figure 2. Note that this model	o Capital Expenditure (CAPEX) and Operating Expenses (OPEX). This is illustrated
		in <xref target="fig-2"/>. Note that this
		model
	does not provide an explicit demarcation link between DC and WAN	does not provide an explicit demarcation link between DC and WAN

	anymore. Although not shown in Figure 2, note that the GWs may have	anymore. Although not shown in <xref target="fig-2"/>, note that the GWs may have
	local ACs.</t>	local ACs.</t>

		<figure anchor="fig-2">
	<figure title="Integrated Interconnect model" anchor="ure-integrated-inte	<name>Integrated Interconnect Model</name>
	rconnect-model"><artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	+--+	+--+
	\|CE\|	\|CE\|
	+--+	+--+
	\|	\|
	+----+	+----+
	+----\| PE \|----+	+----\| PE \|----+
	+---------+ \| +----+ \| +---------+	+---------+ \| +----+ \| +---------+
	+----+ \| +---+ +---+ \| +----+	+----+ \| +---+ +---+ \| +----+
	\|NVE1\|--\| \| \| \| \| \|--\|NVE3\|	\|NVE1\|--\| \| \| \| \| \|--\|NVE3\|
	+----+ \| \|GW1\| \|GW3\| \| +----+	+----+ \| \|GW1\| \|GW3\| \| +----+

	skipping to change at line 566 ¶	skipping to change at line 472 ¶
	+----+ \| \|GW2\| \|GW4\| \| +----+	+----+ \| \|GW2\| \|GW4\| \| +----+
	\|NVE2\|--\| +---+ +---+ \|--\|NVE4\|	\|NVE2\|--\| +---+ +---+ \|--\|NVE4\|
	+----+ +---------+ \| \| +---------+ +----+	+----+ +---------+ \| \| +---------+ +----+
	+--------------+	+--------------+

	\|<--EVPN-Overlay--->\|<-----VPLS--->\|<---EVPN-Overlay-->\|	\|<--EVPN-Overlay--->\|<-----VPLS--->\|<---EVPN-Overlay-->\|
	\|<--PBB-VPLS-->\|	\|<--PBB-VPLS-->\|
	Interconnect -> \|<-EVPN-MPLS-->\|	Interconnect -> \|<-EVPN-MPLS-->\|
	options \|<--EVPN-Ovl-->\|*	options \|<--EVPN-Ovl-->\|*
	\|<--PBB-EVPN-->\|	\|<--PBB-EVPN-->\|

	]]></artwork>
	</figure>
	<t>* EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect optio
	n).</t>


	<section title="Interconnect requirements" anchor="sect-4.1"><t>	* EVPN-Ovl stands for EVPN-Overlay (and it's an interconnect option).
	The Integrated Interconnect solution meets the following	]]></artwork>
		</figure>
		<section anchor="sect-4.1" numbered="true" toc="default">
		<name>Interconnect Requirements</name>
		<t>
		The integrated interconnect solution meets the following
	requirements:</t>	requirements:</t>

		<ul spacing="normal">
	<t><list style="symbols"><t>Control plane and data plane interworking bet	<li>Control plane and data plane interworking between the EVPN-Overlay
	ween the EVPN-overlay
	network and the L2VPN technology supported in the WAN, irrespective	network and the L2VPN technology supported in the WAN, irrespective

	of the technology choice, i.e. (PBB-)VPLS or (PBB-)EVPN, as	of the technology choice -- i.e., (PBB-)VPLS or (PBB-)EVPN, as
	depicted in Figure 2.</t>	depicted in <xref target="fig-2"/>.</li>
		<li>Multihoming, including single-active multihoming with per-service
	<t>Multi-homing, including single-active multi-homing with per-service lo	load
	ad	balancing or all-active multihoming -- i.e., per-flow load-balancing -- as
	balancing or all-active multi-homing, i.e. per-flow load-balancing, as	long as the technology deployed in the WAN supports it.</li>
	long as the technology deployed in the WAN supports it.</t>	<li>Support for end-to-end MAC Mobility, Static MAC protection and
		other procedures (e.g., proxy-arp) described in <xref target="RFC7432" form
	<t>Support for end-to-end MAC Mobility, Static MAC protection and	at="default"/> as long as
	other procedures (e.g. proxy-arp) described in <xref target="RFC7432"/> as	EVPN-MPLS is the technology of choice in the WAN.</li>
	long as	<li>Independent inclusive multicast trees in the WAN and in the DC.
	EVPN-MPLS is the technology of choice in the WAN.</t>

	<t>Independent inclusive multicast trees in the WAN and in the DC.
	That is, the inclusive multicast tree type defined in the WAN does	That is, the inclusive multicast tree type defined in the WAN does

	not need to be the same as in the DC.</t>	not need to be the same as in the DC.</li>
		</ul>
	</list>	</section>
	</t>	<section anchor="sect-4.2" numbered="true" toc="default">
		<name>VPLS Interconnect for EVPN-Overlay Networks</name>
	</section>	<section anchor="sect-4.2.1" numbered="true" toc="default">
		<name>Control/Data Plane Setup Procedures on the GWs</name>
	<section title="VPLS Interconnect for EVPN-Overlay networks" anchor="sect	<t>
	-4.2"><section title="Control/Data Plane setup procedures on the GWs" anchor="se	Regular MPLS tunnels and Targeted LDP (tLDP) / BGP sessions will be set up to
	ct-4.2.1"><t>	the WAN
	Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN	PEs and RRs as per <xref target="RFC4761" format="default"/>, <xref
	PEs and RRs as per <xref target="RFC4761"/>, <xref target="RFC4762"/>, <xref	target="RFC4762" format="default"/>, and <xref target="RFC6074" format="defau
	target="RFC6074"/> and overlay	lt"/>, and overlay
	tunnels and EVPN will be setup as per <xref target="I-D.ietf-bess-evpn-overla	tunnels and EVPN will be set up as per <xref target="RFC8365" format="default
	y"/>. Note that	"/>. Note that
	different route-targets for the DC and for the WAN are normally	different route targets for the DC and the WAN are normally
	required (unless <xref target="RFC4762"/> is used in the WAN, in which case n	required (unless <xref target="RFC4762" format="default"/> is used in the WAN
	o WAN	, in which case no WAN
	route-target is needed). A single type-1 RD per service may be used.</t>	route target is needed). A single type-1 RD per service may be used.</t>
		<t>
	<t>	In order to support multihoming, the GWs will be provisioned with an
	In order to support multi-homing, the GWs will be provisioned with an	I-ESI (see <xref target="sect-3.4"/>), which will be unique for each
	I-ESI (see section 3.4), that will be unique per interconnection. The	interconnection. In this case, the I-ES will represent the
	I-ES in this case will represent the group of PWs to the WAN PEs and	group of PWs to the WAN PEs and
	GWs. All the <xref target="RFC7432"/> procedures are still followed for the I	GWs. All the <xref target="RFC7432" format="default"/> procedures are still
	-ES,	followed for the I-ES -- e.g., any MAC address learned from the WAN will be a
	e.g. any MAC address learned from the WAN will be advertised to the	dvertised to the
	DC with the I-ESI in the ESI field.</t>	DC with the I-ESI in the ESI field.</t>

		<t>
	<t>
	A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have	A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have
	two different types of tunnel bindings instantiated in two different	two different types of tunnel bindings instantiated in two different

	split-horizon-groups:</t>	split-horizon groups:</t>
		<ul spacing="normal">
	<t><list style="symbols">	<li> VPLS PWs will be instantiated in the WAN split-horizon group.</
		li>
	<t> VPLS PWs will be instantiated in the "WAN split-horizon-group".</t>	<li> Overlay tunnel bindings (e.g., VXLAN, NVGRE) will be instantiat
		ed
	<t> Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated	in the DC split-horizon group.</li>
	in the "DC split-horizon-group".</t>	</ul>
		<t>
	</list>
	</t>

	<t>
	Attachment circuits are also supported on the same MAC-VRF (although	Attachment circuits are also supported on the same MAC-VRF (although

	not shown in Figure 2), but they will not be part of any of the above	not shown in <xref target="fig-2"/>), but they will not be part of any of the
	split-horizon-groups.</t>	above
		split-horizon groups.</t>
	<t>	<t>
	Traffic received in a given split-horizon-group will never be	Traffic received in a given split-horizon group will never be
	forwarded to a member of the same split-horizon-group.</t>	forwarded to a member of the same split-horizon group.</t>
		<t>
	<t>
	As far as BUM flooding is concerned, a flooding list will be composed	As far as BUM flooding is concerned, a flooding list will be composed

	of the sub-list created by the inclusive multicast routes and the	of the sublist created by the inclusive multicast routes and the
	sub-list created for VPLS in the WAN. BUM frames received from a	sublist created for VPLS in the WAN. BUM frames received from a
	local Attachment Circuit (AC) will be forwarded to the flooding list.	local Attachment Circuit (AC) will be forwarded to the flooding list.
	BUM frames received from the DC or the WAN will be forwarded to the	BUM frames received from the DC or the WAN will be forwarded to the

	flooding list observing the split-horizon-group rule described above.</t>	flooding list, observing the split-horizon group rule described above.</t>
		<t>
	<t>
	Note that the GWs are not allowed to have an EVPN binding and a PW to	Note that the GWs are not allowed to have an EVPN binding and a PW to

	the same far-end within the same MAC-VRF, so that loops and packet	the same far end within the same MAC-VRF, so that loops and packet
	duplication are avoided. In case a GW can successfully establish	duplication are avoided. In case a GW can successfully establish

	both, an EVPN binding and a PW to the same far-end PE, the EVPN	both an EVPN binding and a PW to the same far-end PE, the EVPN
	binding will prevail and the PW will be brought operationally down.</t>	binding will prevail, and the PW will be brought down operationally.</t>
		<t>
	<t>	The optimization procedures described in <xref target="sect-3.5"/> can
	The optimizations procedures described in section 3.5 can also be	also be applied to this model.</t>
	applied to this model.</t>	</section>
		<section anchor="sect-4.2.2" numbered="true" toc="default">
	</section>	<name>Multihoming Procedures on the GWs</name>
		<t>
	<section title="Multi-homing procedures on the GWs" anchor="sect-4.2.2"><	This model supports single-active multihoming on the GWs. All-active
	t>	multihoming is not supported by VPLS; therefore, it cannot be used on
	This model supports single-active multi-homing on the GWs. All-active
	multi-homing is not supported by VPLS, therefore it cannot be used on
	the GWs.</t>	the GWs.</t>

		<t>
	<t>	In this case, for a given EVI, all the PWs in the WAN split-horizon group
	In this case, for a given EVI, all the PWs in the WAN split-horizon-group	are assigned to I-ES. All the single-active multihoming procedures as
	are assigned to I-ES. All the single-active multi-homing procedures as	described by <xref target="RFC8365" format="default"/> will be followed for t
	described by <xref target="I-D.ietf-bess-evpn-overlay"/> will be followed for	he I-ES.</t>
	the I-ES.</t>	<t>

	<t>
	The non-DF GW for the I-ES will block the transmission and reception	The non-DF GW for the I-ES will block the transmission and reception

	of all the PWs in the "WAN split-horizon-group" for BUM and unicast	of all the PWs in the WAN split-horizon group for BUM and unicast
	traffic.</t>	traffic.</t>

		</section>
	</section>	</section>
		<section anchor="sect-4.3" numbered="true" toc="default">
	</section>	<name>PBB-VPLS Interconnect for EVPN-Overlay Networks</name>
		<section anchor="sect-4.3.1" numbered="true" toc="default">
	<section title="PBB-VPLS Interconnect for EVPN-Overlay networks" anchor="	<name>Control/Data Plane Setup Procedures on the GWs</name>
	sect-4.3"><section title="Control/Data Plane setup procedures on the GWs" anchor	<t>
	="sect-4.3.1"><t>
	In this case, there is no impact on the procedures described in	In this case, there is no impact on the procedures described in

	<xref target="RFC7041"/> for the B-component. However the I-component instanc	<xref target="RFC7041" format="default"/> for the B-component. However, the
	es	I-component instances
	become EVI instances with EVPN-Overlay bindings and potentially local	become EVI instances with EVPN-Overlay bindings and potentially local
	attachment circuits. A number of MAC-VRF instances can be multiplexed	attachment circuits. A number of MAC-VRF instances can be multiplexed
	into the same B-component instance. This option provides significant	into the same B-component instance. This option provides significant
	savings in terms of PWs to be maintained in the WAN.</t>	savings in terms of PWs to be maintained in the WAN.</t>

		<t>
	<t>	The I-ESI concept described in <xref target="sect-4.2.1"/> will also be
	The I-ESI concept described in section 4.2.1 will also be used for	used for the PBB-VPLS-based interconnect.</t>
	the PBB-VPLS-based Interconnect.</t>	<t>
		B-component PWs and I-component EVPN-Overlay bindings established to
	<t>	the same far end will be compared. The following rules will be
	B-component PWs and I-component EVPN-overlay bindings established to
	the same far-end will be compared. The following rules will be
	observed:</t>	observed:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li> Attempts to set up a PW between the two GWs within the B-compon
		ent
	<t> Attempts to setup a PW between the two GWs within the B-component	context will never be blocked.</li>
	context will never be blocked.</t>	<li> If a PW exists between two GWs for the B-component and an attem
		pt
	<t> If a PW exists between two GWs for the B-component and an attempt	is made to set up an EVPN binding on an I-component linked to that
	is made to setup an EVPN binding on an I-component linked to that	B-component, the EVPN binding will be kept down operationally. Note
	B-component, the EVPN binding will be kept operationally down. Note	that the BGP EVPN routes will still be valid but not used.</li>
	that the BGP EVPN routes will still be valid but not used.</t>	<li> The EVPN binding will only be up and used as long as there is n
		o
	<t> The EVPN binding will only be up and used as long as there is no	PW to the same far end in the corresponding B-component. The EVPN
	PW to the same far-end in the corresponding B-component. The EVPN
	bindings in the I-components will be brought down before the PW in the	bindings in the I-components will be brought down before the PW in the

	B-component is brought up.</t>	B-component is brought up.</li>
		</ul>
	</list>	<t>
	</t>	The optimization procedures described in <xref target="sect-3.5"/> can also b
		e
	<t>	applied to this interconnect option.</t>
	The optimizations procedures described in section 3.5 can also be	</section>
	applied to this Interconnect option.</t>	<section anchor="sect-4.3.2" numbered="true" toc="default">
		<name>Multihoming Procedures on the GWs</name>
	</section>	<t>
		This model supports single-active multihoming on the GWs. All-active
	<section title="Multi-homing procedures on the GWs" anchor="sect-4.3.2"><	multihoming is not supported by this scenario.</t>
	t>	<t>
	This model supports single-active multi-homing on the GWs. All-active	The single-active multihoming procedures as described by <xref target="RFC836
	multi-homing is not supported by this scenario.</t>	5" format="default"/>

	<t>
	The single-active multi-homing procedures as described by <xref target="I-D.i
	etf-bess-evpn-overlay"/>
	will be followed for the I-ES for each EVI instance connected to the	will be followed for the I-ES for each EVI instance connected to the
	B-component. Note that in this case, for a given EVI, all the EVPN bindings	B-component. Note that in this case, for a given EVI, all the EVPN bindings
	in the I-component are assigned to the I-ES. The non-DF GW for the I-ES	in the I-component are assigned to the I-ES. The non-DF GW for the I-ES
	will block the transmission and reception of all the I-component EVPN	will block the transmission and reception of all the I-component EVPN
	bindings for BUM and unicast traffic. When learning MACs from the WAN, the	bindings for BUM and unicast traffic. When learning MACs from the WAN, the

	non-DF MUST NOT advertise EVPN MAC/IP routes for those MACs.</t>	non-DF <bcp14>MUST NOT</bcp14> advertise EVPN MAC/IP routes for those MACs.</
		t>
	</section>	</section>
		</section>
	</section>	<section anchor="sect-4.4" numbered="true" toc="default">
		<name>EVPN-MPLS Interconnect for EVPN-Overlay Networks</name>
	<section title="EVPN-MPLS Interconnect for EVPN-Overlay networks" anchor=	<t>
	"sect-4.4"><t>	If EVPN for MPLS tunnels (referred to as "EVPN-MPLS" hereafter) are supported
	If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the	in the
	WAN, an end-to-end EVPN solution can be deployed. The following	WAN, an end-to-end EVPN solution can be deployed. The following

	sections describe the proposed solution as well as the impact	sections describe the proposed solution as well as its impact
	required on the <xref target="RFC7432"/> procedures.</t>	on the procedures from <xref target="RFC7432" format="default"/>.</t>
		<section anchor="sect-4.4.1" numbered="true" toc="default">
	<section title="Control Plane setup procedures on the GWs" anchor="sect-4	<name>Control plane Setup Procedures on the GWs</name>
	.4.1"><t>	<t>
	The GWs MUST establish separate BGP sessions for sending/receiving	The GWs <bcp14>MUST</bcp14> establish separate BGP sessions for sending/recei
	EVPN routes to/from the DC and to/from the WAN. Normally each GW will	ving
	setup one BGP EVPN session to the DC RR (or two BGP EVPN sessions if	EVPN routes to/from the DC and to/from the WAN. Normally, each GW will
		set up one BGP EVPN session to the DC RR (or two BGP EVPN sessions if
	there are redundant DC RRs) and one session to the WAN RR (or two	there are redundant DC RRs) and one session to the WAN RR (or two
	sessions if there are redundant WAN RRs).</t>	sessions if there are redundant WAN RRs).</t>

		<t>
	<t>
	In order to facilitate separate BGP processes for DC and WAN, EVPN	In order to facilitate separate BGP processes for DC and WAN, EVPN

	routes sent to the WAN SHOULD carry a different route-distinguisher	routes sent to the WAN <bcp14>SHOULD</bcp14> carry a different Route Distingu isher
	(RD) than the EVPN routes sent to the DC. In addition, although	(RD) than the EVPN routes sent to the DC. In addition, although

	reusing the same value is possible, different route-targets are	reusing the same value is possible, different route targets are
	expected to be handled for the same EVI in the WAN and the DC. Note	expected to be handled for the same EVI in the WAN and the DC. Note
	that the EVPN service routes sent to the DC RRs will normally include	that the EVPN service routes sent to the DC RRs will normally include

	a <xref target="I-D.ietf-idr-tunnel-encaps"/> BGP encapsulation extended comm unity with a	a <xref target="RFC9012" format="default"/> BGP encapsulation extended commun ity with a
	different tunnel type than the one sent to the WAN RRs.</t>	different tunnel type than the one sent to the WAN RRs.</t>

		<t>
	<t>
	As in the other discussed options, an I-ES and its assigned I-ESI	As in the other discussed options, an I-ES and its assigned I-ESI

	will be configured on the GWs for multi-homing. This I-ES represents	will be configured on the GWs for multihoming. This I-ES represents
	the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to	the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to
	the WAN. Optionally, different I-ESI values are configured for	the WAN. Optionally, different I-ESI values are configured for
	representing the WAN and the DC. If different EVPN-Overlay networks	representing the WAN and the DC. If different EVPN-Overlay networks
	are connected to the same group of GWs, each EVPN-Overlay network	are connected to the same group of GWs, each EVPN-Overlay network

	MUST get assigned a different I-ESI.</t>	<bcp14>MUST</bcp14> get assigned a different I-ESI.</t>
		<t>
	<t>	Received EVPN routes will never be reflected on the GWs but instead will be
	Received EVPN routes will never be reflected on the GWs but consumed	consumed and re-advertised (if needed):</t>
	and re-advertised (if needed):</t>	<ul spacing="normal">
		<li>Ethernet A-D routes, ES routes, and Inclusive Multicast routes a
	<t><list style="symbols">	re
		consumed by the GWs and processed locally for the corresponding <xref tar
	<t>Ethernet A-D routes, ES routes and Inclusive Multicast routes are	get="RFC7432" format="default"/> procedures.</li>
	consumed by the GWs and processed locally for the corresponding <xref	<li>
	target="RFC7432"/> procedures.</t>	<t>MAC/IP advertisement routes will be received and imported, and
		if they
	<t>MAC/IP advertisement routes will be received, imported and if they
	become active in the MAC-VRF, the information will be re-advertised as	become active in the MAC-VRF, the information will be re-advertised as
	new routes with the following fields:	new routes with the following fields:


	<list style="symbols">	</t>
		<ul spacing="normal">
	<t>The RD will be the GW's RD for the MAC-VRF.</t>	<li>The RD will be the GW's RD for the MAC-VRF.</li>
		<li>The ESI will be set to the I-ESI.</li>
	<t>The ESI will be set to the I-ESI.</t>	<li>The Ethernet-tag value will be kept from the received NLRI t
		he
	<t>The Ethernet-tag value will be kept from the received NLRI the	received NLRI.</li>
	received NLRI.</t>	<li>The MAC length, MAC address, IP Length, and IP address value
		s will
	<t>The MAC length, MAC address, IP Length and IP address values will	be kept from the received NLRI.</li>
	be kept from the received NLRI.</t>	<li>The MPLS label will be a local 20-bit value (when sent to th
		e
	<t>The MPLS label will be a local 20-bit value (when sent to the
	WAN) or a DC-global 24-bit value (when sent to the DC for	WAN) or a DC-global 24-bit value (when sent to the DC for

	encapsulations using a VNI).</t>	encapsulations using a VNI).</li>
		<li>The appropriate Route Targets (RTs) and <xref
	<t>The appropriate Route-Targets (RTs) and <xref	target="RFC9012" format="default"/> BGP encapsulation extended
	target="I-D.ietf-idr-tunnel-encaps"/> BGP Encapsulation extended	community will be used according to <xref target="RFC8365" format="defa
	community will be used according to <xref	ult"/>.</li>
	target="I-D.ietf-bess-evpn-overlay"/>.</t>	</ul>
		</li>
	</list>	</ul>
	</t>	<t>

	</list>
	</t>

	<t>
	The GWs will also generate the following local EVPN routes that will be	The GWs will also generate the following local EVPN routes that will be

	sent to the DC and WAN, with their corresponding RTs and <xref target="I-D.ie	sent to the DC and WAN, with their corresponding RTs and <xref
	tf-idr-tunnel-encaps"/> BGP	target="RFC9012" format="default"/> BGP encapsulation extended community valu
	Encapsulation extended community values:</t>	es:</t>
		<ul spacing="normal">
	<t><list style="symbols">	<li>ES route(s) for the I-ESI(s).</li>
		<li>Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D
	<t>ES route(s) for the I-ESI(s).</t>

	<t>Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D
	per-EVI routes sent to the WAN and the DC will have consistent	per-EVI routes sent to the WAN and the DC will have consistent

	Ethernet-Tag values.</t>	Ethernet-Tag values.</li>
		<li>Inclusive Multicast routes with independent tunnel-type value
	<t>Inclusive Multicast routes with independent tunnel type value	for the WAN and DC. For example, a P2MP Label Switched Path (LSP) may be
	for the WAN and DC. E.g. a P2MP LSP may be used in the WAN	used in the WAN,
	whereas ingress replication may be used in the DC. The routes	whereas ingress replication may be used in the DC. The routes

	sent to the WAN and the DC will have a consistent Ethernet-Tag.</t>	sent to the WAN and the DC will have a consistent Ethernet-Tag.</li>

	<t>MAC/IP advertisement routes for MAC addresses learned in local
	attachment circuits. Note that these routes will not include the
	I-ESI, but ESI=0 or different from 0 for local multi-homed
	Ethernet Segments (ES). The routes sent to the WAN and the DC
	will have a consistent Ethernet-Tag.</t>

	</list>
	</t>


	<t>	<li>MAC/IP advertisement routes for MAC addresses learned in local
		attachment circuits. Note that these routes will not include the
		I-ESI value in the ESI field. These routes will include a zero ESI or a non-zero
		ESI for local multihomed
		Ethernet Segments (ES). The routes sent to the WAN and the DC
		will have a consistent Ethernet-Tag.</li>
		</ul>
		<t>
	Assuming GW1 and GW2 are peer GWs of the same DC, each GW will generate two	Assuming GW1 and GW2 are peer GWs of the same DC, each GW will generate two

	sets of the above local service routes: Set-DC will be sent to the DC RRs	sets of the above local service routes: set-DC will be sent to the DC RRs
	and will include A-D per EVI, Inclusive Multicast and MAC/IP routes for the	and will include an A-D per EVI, Inclusive Multicast, and MAC/IP routes for t
		he
	DC encapsulation and RT. Set-WAN will be sent to the WAN RRs and will	DC encapsulation and RT. Set-WAN will be sent to the WAN RRs and will
	include the same routes but using the WAN RT and encapsulation. GW1 and GW2	include the same routes but using the WAN RT and encapsulation. GW1 and GW2
	will receive each other's set-DC and set-WAN. This is the expected behavior	will receive each other's set-DC and set-WAN. This is the expected behavior
	on GW1 and GW2 for locally generated routes:</t>	on GW1 and GW2 for locally generated routes:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>Inclusive multicast routes: When setting up the flooding lists f
		or a
	<t>Inclusive multicast routes: when setting up the flooding lists for a
	given MAC-VRF, each GW will include its DC peer GW only in the	given MAC-VRF, each GW will include its DC peer GW only in the
	EVPN-MPLS flooding list (by default) and not the EVPN-Overlay flooding	EVPN-MPLS flooding list (by default) and not the EVPN-Overlay flooding
	list. That is, GW2 will import two Inclusive Multicast routes from GW1	list. That is, GW2 will import two Inclusive Multicast routes from GW1
	(from set-DC and set-WAN) but will only consider one of the two,	(from set-DC and set-WAN) but will only consider one of the two,

	having the set-WAN route higher priority. An administrative option MAY	giving the set-WAN route higher priority. An administrative option <bcp1
	change this preference so that the set-DC route is selected first.</t>	4>MAY</bcp14>
		change this preference so that the set-DC route is selected first.</li>
	<t>MAC/IP advertisement routes for local attachment circuits: as	<li>MAC/IP advertisement routes for local attachment circuits: As
	above, the GW will select only one, having the route from the	above, the GW will select only one, giving the route from the
	set-WAN a higher priority. As with the Inclusive multicast	set-WAN a higher priority. As with the Inclusive multicast

	routes, an administrative option MAY change this priority.</t>	routes, an administrative option <bcp14>MAY</bcp14> change this priority
		.</li>
	</list>	</ul>
	</t>	</section>
		<section anchor="sect-4.4.2" numbered="true" toc="default">
	</section>	<name>Data Plane Setup Procedures on the GWs</name>
		<t>
	<section title="Data Plane setup procedures on the GWs" anchor="sect-4.4.
	2"><t>
	The procedure explained at the end of the previous section will make sure	The procedure explained at the end of the previous section will make sure
	there are no loops or packet duplication between the GWs of the same	there are no loops or packet duplication between the GWs of the same

	EVPN-Overlay network (for frames generated from local ACs) since only one	EVPN-Overlay network (for frames generated from local ACs), since only one
	EVPN binding per EVI (or per Ethernet Tag in case of VLAN-aware bundle	EVPN binding per EVI (or per Ethernet Tag in the case of VLAN-aware bundle
	services) will be setup in the data plane between the two nodes. That	services) will be set up in the data plane between the two nodes. That
	binding will by default be added to the EVPN-MPLS flooding list.</t>	binding will by default be added to the EVPN-MPLS flooding list.</t>

		<t>
	<t>
	As for the rest of the EVPN tunnel bindings, they will be added to one of	As for the rest of the EVPN tunnel bindings, they will be added to one of
	the two flooding lists that each GW sets up for the same MAC-VRF:</t>	the two flooding lists that each GW sets up for the same MAC-VRF:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>EVPN-Overlay flooding list (composed of bindings to the remote N
		VEs
	<t>EVPN-overlay flooding list (composed of bindings to the remote NVEs	or multicast tunnel to the NVEs).</li>
	or multicast tunnel to the NVEs).</t>	<li>EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the
		remote PEs).</li>
	<t>EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the	</ul>
	remote PEs)</t>	<t>
		Each flooding list will be part of a separate split-horizon group:
	</list>	the WAN split-horizon group or the DC split-horizon group. Traffic
	</t>

	<t>
	Each flooding list will be part of a separate split-horizon-group:
	the WAN split-horizon-group or the DC split-horizon-group. Traffic
	generated from a local AC can be flooded to both	generated from a local AC can be flooded to both

	split-horizon-groups. Traffic from a binding of a split-horizon-group	split-horizon groups. Traffic from a binding of a split-horizon group
	can be flooded to the other split-horizon-group and local ACs, but	can be flooded to the other split-horizon group and local ACs, but
	never to a member of its own split-horizon-group.</t>	never to a member of its own split-horizon group.</t>
		<t>
	<t>	When either GW1 or GW2 receives a BUM frame on an MPLS tunnel, including an
	When either GW1 or GW2 receive a BUM frame on an MPLS tunnel including an
	ESI label at the bottom of the stack, they will perform an ESI label lookup	ESI label at the bottom of the stack, they will perform an ESI label lookup

	and split-horizon filtering as per <xref target="RFC7432"/> in case the ESI l	and split-horizon filtering as per <xref target="RFC7432"
	abel	format="default"/>, in case the ESI label
	identifies a local ESI (I-ESI or any other non-zero ESI).</t>	identifies a local ESI (I-ESI or any other nonzero ESI).</t>
		</section>
	</section>	<section anchor="sect-4.4.3" numbered="true" toc="default">
		<name>Multihoming Procedure Extensions on the GWs</name>
	<section title="Multi-homing procedure extensions on the GWs" anchor="sec	<t>
	t-4.4.3"><t>	This model supports single-active as well as all-active multihoming.</t>
	This model supports single-active as well as all-active multi-homing.</t>	<t>
		All the <xref target="RFC7432" format="default"/> multihoming procedures
	<t>	for the DF election on I-ES(s), as
	All the <xref target="RFC7432"/> multi-homing procedures for the DF election
	on I-ES(s) as
	well as the backup-path (single-active) and aliasing (all-active)	well as the backup-path (single-active) and aliasing (all-active)

	procedures will be followed on the GWs. Remote PEs in the EVPN-MPLS network	procedures, will be followed on the GWs. Remote PEs in the EVPN-MPLS network
	will follow regular <xref target="RFC7432"/> aliasing or backup-path procedur	will follow regular <xref target="RFC7432" format="default"/> aliasing or bac
	es for	kup-path procedures for
	MAC/IP routes received from the GWs for the same I-ESI. So will NVEs in the	MAC/IP routes received from the GWs for the same I-ESI. So will NVEs in the
	EVPN-Overlay network for MAC/IP routes received with the same I-ESI.</t>	EVPN-Overlay network for MAC/IP routes received with the same I-ESI.</t>

		<t>
	<t>
	As far as the forwarding plane is concerned, by default, the EVPN-Overlay	As far as the forwarding plane is concerned, by default, the EVPN-Overlay

	network will have an analogous behavior to the access ACs in <xref target="RF	network will have an analogous behavior to the access ACs in <xref target="RF
	C7432"/>	C7432" format="default"/>
	multi-homed Ethernet Segments.</t>	multihomed Ethernet Segments.</t>
		<t>The forwarding behavior on the GWs is described below:</t>
	<t><list style="symbols">	<ul spacing="normal">
		<li>
	<t>The forwarding behavior on the GWs is described below:</t>	<t>Single-active multihoming; assuming a WAN split-horizon group
		(comprised of EVPN-MPLS bindings), a DC split-horizon group
	<t>Single-active multi-homing; assuming a WAN split-horizon-group	(comprised of EVPN-Overlay bindings), and local ACs on the GWs:
	(comprised of EVPN-MPLS bindings), a DC split-horizon-group
	(comprised of EVPN-Overlay bindings) and local ACs on the GWs:

	<list style="symbols">


	<t>Forwarding behavior on the non-DF: the non-DF MUST block	</t>
		<ul spacing="normal">
		<li>Forwarding behavior on the non-DF: The non-DF <bcp14>MUST</b
		cp14> block
	ingress and egress forwarding on the EVPN-Overlay bindings	ingress and egress forwarding on the EVPN-Overlay bindings
	associated to the I-ES. The EVPN-MPLS network is considered to	associated to the I-ES. The EVPN-MPLS network is considered to

	be the core network and the EVPN-MPLS bindings to the remote	be the core network, and the EVPN-MPLS bindings to the remote
	PEs and GWs will be active.</t>	PEs and GWs will be active.</li>
		<li>Forwarding behavior on the DF: The DF <bcp14>MUST NOT</bcp14
	<t>Forwarding behavior on the DF: the DF MUST NOT forward BUM or	> forward BUM or
	unicast traffic received from a given split-horizon-group to a	unicast traffic received from a given split-horizon group to a
	member of his own split-horizon group. Forwarding to other	member of its own split-horizon group. Forwarding to other
	split-horizon-groups and local ACs is allowed (as long as the ACs	split-horizon groups and local ACs is allowed (as long as the ACs
	are not part of an ES for which the node is non-DF). As per <xref	are not part of an ES for which the node is non-DF). As per <xref targ
	target="RFC7432"/> and for split-horizon purposes, when receiving	et="RFC7432" format="default"/> and for split-horizon purposes, when receiving
	BUM traffic on the EVPN-Overlay bindings associated to an I-ES, the	BUM traffic on the EVPN-Overlay bindings associated to an I-ES, the

	DF GW SHOULD add the I-ESI label when forwarding to the peer GW	DF GW <bcp14>SHOULD</bcp14> add the I-ESI label when forwarding to the
	over EVPN-MPLS.</t>	peer GW
		over EVPN-MPLS.</li>
	<t>When receiving EVPN MAC/IP routes from the WAN, the non-DF MUST	<li>When receiving EVPN MAC/IP routes from the WAN, the non-DF <
	NOT re-originate the EVPN routes and advertise them to the DC	bcp14>MUST
		NOT</bcp14> reoriginate the EVPN routes and advertise them to the DC
	peers. In the same way, EVPN MAC/IP routes received from the DC	peers. In the same way, EVPN MAC/IP routes received from the DC

	MUST NOT be advertised to the WAN peers. This is consistent with	<bcp14>MUST NOT</bcp14> be advertised to the WAN peers. This is consis
	<xref target="RFC7432"/> and allows the remote PE/NVEs know who the	tent with
	primary GW is, based on the reception of the MAC/IP routes.</t>	<xref target="RFC7432" format="default"/> and allows the remote
		PE/NVEs to know who the
	</list>	primary GW is, based on the reception of the MAC/IP routes.</li>
	</t>	</ul>
		</li>
	</list>	</ul>
	</t>	<ul spacing="normal">
		<li>
	<t><list style="symbols">	<t>All-active multihoming; assuming a WAN split-horizon group
		(comprised of EVPN-MPLS bindings), a DC split-horizon group
	<t>All-active multi-homing; assuming a WAN split-horizon-group	(comprised of EVPN-Overlay bindings), and local ACs on the GWs:
	(comprised of EVPN-MPLS bindings), a DC split-horizon-group
	(comprised of EVPN-Overlay bindings) and local ACs on the GWs:

	<list style="symbols">


	<t>Forwarding behavior on the non-DF: the non-DF follows the same	</t>
	behavior as the non-DF in the single-active case but only for BUM	<ul spacing="normal">
	traffic. Unicast traffic received from a split-horizon-group MUST	<li>Forwarding behavior on the non-DF: The non-DF follows the sa
	NOT be forwarded to a member of its own split-horizon-group but can	me
	be forwarded normally to the other split-horizon-groups and local	behavior as the non-DF in the single-active case, but only for BUM
		traffic. Unicast traffic received from a split-horizon group <bcp14>M
		UST
		NOT</bcp14> be forwarded to a member of its own split-horizon group b
		ut can
		be forwarded normally to the other split-horizon groups and local
	ACs. If a known unicast packet is identified as a "flooded" packet,	ACs. If a known unicast packet is identified as a "flooded" packet,

	the procedures for BUM traffic MUST be followed.</t>	the procedures for BUM traffic <bcp14>MUST</bcp14> be followed.</li>
		<li>Forwarding behavior on the DF: The DF follows the same behav
	<t>Forwarding behavior on the DF: the DF follows the same behavior	ior
	as the DF in the single-active case but only for BUM	as the DF in the single-active case, but only for BUM
	traffic. Unicast traffic received from a split-horizon-group MUST	traffic. Unicast traffic received from a split-horizon group <bcp14>MU
	NOT be forwarded to a member of its own split-horizon-group but can	ST
	be forwarded normally to the other split-horizon-group and local	NOT</bcp14> be forwarded to a member of its own split-horizon group bu
		t can
		be forwarded normally to the other split-horizon group and local
	ACs. If a known unicast packet is identified as a "flooded" packet,	ACs. If a known unicast packet is identified as a "flooded" packet,

	the procedures for BUM traffic MUST be followed. As per <xref	the procedures for BUM traffic <bcp14>MUST</bcp14> be followed. As per
	target="RFC7432"/> and for split-horizon purposes, when receiving	<xref target="RFC7432" format="default"/> and for split-horizon purposes, when
		receiving
	BUM traffic on the EVPN-Overlay bindings associated to an I-ES, the	BUM traffic on the EVPN-Overlay bindings associated to an I-ES, the

	DF GW MUST add the I-ESI label when forwarding to the peer GW over	DF GW <bcp14>MUST</bcp14> add the I-ESI label when forwarding to the p
	EVPN-MPLS.</t>	eer GW over
		EVPN-MPLS.</li>
	<t>Contrary to the single-active multi-homing case, both DF and	<li>Contrary to the single-active multihoming case, both DF and
	non-DF re-originate and advertise MAC/IP routes received from	non-DF reoriginate and advertise MAC/IP routes received from
	the WAN/DC peers, adding the corresponding I-ESI so that the	the WAN/DC peers, adding the corresponding I-ESI so that the

	remote PE/NVEs can perform regular aliasing as per <xref target="RFC7	remote PE/NVEs can perform regular aliasing, as per <xref
	432"/>.</t>	target="RFC7432" format="default"/>.</li>
		</ul>
	</list>	</li>
	</t>	</ul>
		<t>
	</list>	The example in <xref target="fig-3"/> illustrates the forwarding of BUM traff
	</t>	ic
		originated from an NVE on a pair of all-active multihoming GWs.</t>
	<t>	<figure anchor="fig-3">
	The example in Figure 3 illustrates the forwarding of BUM traffic	<name>Multihoming BUM Forwarding</name>
	originated from an NVE on a pair of all-active multi-homing GWs.</t>	<artwork name="" type="" align="left" alt=""><![CDATA[

	<figure title="Multi-homing BUM forwarding" anchor="ure-multi-homing-bum-
	forwarding"><artwork><![CDATA[
	\|<--EVPN-Overlay--->\|<--EVPN-MPLS-->\|	\|<--EVPN-Overlay--->\|<--EVPN-MPLS-->\|

	+---------+ +--------------+	+---------+ +--------------+
	+----+ BUM +---+ \|	+----+ BUM +---+ \|
	\|NVE1+----+----> \| +-+-----+ \|	\|NVE1+----+----> \| +-+-----+ \|
	+----+ \| \| DF \|GW1\| \| \| \|	+----+ \| \| DF \|GW1\| \| \| \|
	\| \| +-+-+ \| \| ++--+	\| \| +-+-+ \| \| ++--+
	\| \| \| \| +--> \|PE1\|	\| \| \| \| +--> \|PE1\|
	\| +--->X +-+-+ \| ++--+	\| +--->X +-+-+ \| ++--+
	\| NDF\| \| \| \|	\| NDF\| \| \| \|
	+----+ \| \|GW2<-+ \|	+----+ \| \|GW2<-+ \|
	\|NVE2+--+ +-+-+ \|	\|NVE2+--+ +-+-+ \|
	+----+ +--------+ \| +------------+	+----+ +--------+ \| +------------+
	v	v
	+--+	+--+
	\|CE\|	\|CE\|
	+--+	+--+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	<t>	<t>
	GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is	GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is
	the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2	the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2

	will include the ESI-label for the I-ES. Based on the ESI-label, GW2	will include the ESI label for the I-ES. Based on the ESI label, GW2
	identifies the packets as I-ES-generated packets and will only	identifies the packets as I-ES-generated packets and will only
	forward them to local ACs (CE in the example) and not back to the	forward them to local ACs (CE in the example) and not back to the
	EVPN-Overlay network.</t>	EVPN-Overlay network.</t>

		</section>
	</section>	<section anchor="sect-4.4.4" numbered="true" toc="default">
		<name>Impact on MAC Mobility Procedures</name>
	<section title="Impact on MAC Mobility procedures" anchor="sect-4.4.4"><t	<t>
	>	MAC Mobility procedures described in <xref target="RFC7432" format="default"/
	MAC Mobility procedures described in <xref target="RFC7432"/> are not modifie	> are not modified by
	d by
	this document.</t>	this document.</t>

		<t>
	<t>
	Note that an intra-DC MAC move still leaves the MAC attached to the	Note that an intra-DC MAC move still leaves the MAC attached to the

	same I-ES, so under the rules of <xref target="RFC7432"/> this is not conside	same I-ES, so under the rules of <xref target="RFC7432" format="default"/>,
	red a	this is not considered a
	MAC mobility event. Only when the MAC moves from the WAN domain to	MAC Mobility event. Only when the MAC moves from the WAN domain to
	the DC domain (or from one DC to another) the MAC will be learned	the DC domain (or from one DC to another) will the MAC be learned
	from a different ES and the MAC Mobility procedures will kick in.</t>	from a different ES, and the MAC Mobility procedures will kick in.</t>
		<t>
	<t>	The sticky-bit indication in the MAC Mobility extended community <bcp14>MUST<
	The sticky bit indication in the MAC Mobility extended community MUST	/bcp14>
	be propagated between domains.</t>	be propagated between domains.</t>

		</section>
	</section>	<section anchor="sect-4.4.5" numbered="true" toc="default">
		<name>Gateway Optimizations</name>
	<section title="Gateway optimizations" anchor="sect-4.4.5"><t>	<t>
	All the Gateway optimizations described in section 3.5 MAY be applied	All the Gateway optimizations described in <xref target="sect-3.5"/>
	to the GWs when the Interconnect is based on EVPN-MPLS.</t>	<bcp14>MAY</bcp14> be applied
		to the GWs when the interconnect is based on EVPN-MPLS.</t>
	<t>	<t>
	In particular, the use of the Unknown MAC Route, as described in	In particular, the use of the Unknown MAC Route, as described in

	section 3.5.1, solves some transient packet duplication issues in	<xref target="sect-3.5.1"/>, solves some transient packet-duplication
	cases of all-active multi-homing, as explained below.</t>	issues in
		cases of all-active multihoming, as explained below.</t>
	<t>	<t>
	Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all-active	Consider the diagram in <xref target="fig-2"/> for EVPN-MPLS interconnect and
	multi-homing, and the following sequence:</t>	all-active
		multihoming, and the following sequence:</t>
	<t><list style="format (%c)">	<ol spacing="normal" type="(%c)">
		<li>MAC Address M1 is advertised from NVE3 in EVI-1.</li>
	<t>MAC Address M1 is advertised from NVE3 in EVI-1.</t>	<li>GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN
		with I-ESI-2 in the ESI field.</li>
	<t>GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN	<li>GW1 and GW2 learn M1 and install GW3/GW4 as next hops following
	with I-ESI-2 in the ESI field.</t>	the EVPN aliasing procedures.</li>
		<li>Before NVE1 learns M1, a packet arrives at NVE1 with destination
	<t>GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following
	the EVPN aliasing procedures.</t>

	<t>Before NVE1 learns M1, a packet arrives at NVE1 with destination
	M1. If the Unknown MAC Route had not been advertised into the DC,	M1. If the Unknown MAC Route had not been advertised into the DC,
	NVE1 would have flooded the packet throughout the DC, in particular	NVE1 would have flooded the packet throughout the DC, in particular
	to both GW1 and GW2. If the same VNI/VSID is used for both known	to both GW1 and GW2. If the same VNI/VSID is used for both known
	unicast and BUM traffic, as is typically the case, there is no	unicast and BUM traffic, as is typically the case, there is no

	indication in the packet that it is a BUM packet and both GW1 and	indication in the packet that it is a BUM packet, and both GW1 and
	GW2 would have forwarded it, creating packet duplication. However,	GW2 would have forwarded it, creating packet duplication. However,
	because the Unknown MAC Route had been advertised into the DC, NVE1	because the Unknown MAC Route had been advertised into the DC, NVE1

	will unicast the packet to either GW1 or GW2.</t>	will unicast the packet to either GW1 or GW2.</li>
		<li>Since both GW1 and GW2 know M1, the GW receiving the packet will
	<t>Since both GW1 and GW2 know M1, the GW receiving the packet will	forward it to either GW3 or GW4.</li>
	forward it to either GW3 or GW4.</t>	</ol>
		</section>
	</list>	<section anchor="sect-4.4.6" numbered="true" toc="default">
	</t>	<name>Benefits of the EVPN-MPLS Interconnect Solution</name>
		<t>
	</section>	The "DCI using ASBRs" solution described in <xref target="RFC8365" format="de
		fault"/> and the GW solution
	<section title="Benefits of the EVPN-MPLS Interconnect solution" anchor="	with EVPN-MPLS interconnect may be seen as similar, since they both
	sect-4.4.6"><t>
	The <xref target="I-D.ietf-bess-evpn-overlay"/> "DCI using ASBRs" solution an
	d the GW solution
	with EVPN-MPLS Interconnect may be seen similar since they both
	retain the EVPN attributes between Data Centers and throughout the	retain the EVPN attributes between Data Centers and throughout the

	WAN. However the EVPN-MPLS Interconnect solution on the GWs has	WAN. However, the EVPN-MPLS interconnect solution on the GWs has
	significant benefits compared to the "DCI using ASBRs" solution:</t>	significant benefits compared to the "DCI using ASBRs" solution:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>As in any of the described GW models, this solution supports the

	<t>As in any of the described GW models, this solution supports the
	connectivity of local attachment circuits on the GWs. This is not	connectivity of local attachment circuits on the GWs. This is not

	possible in a "DCI using ASBRs" solution.</t>	possible in a "DCI using ASBRs" solution.</li>
		<li>Different data plane encapsulations can be supported in the DC
	<t>Different data plane encapsulations can be supported in the DC
	and the WAN, while a uniform encapsulation is needed in the "DCI	and the WAN, while a uniform encapsulation is needed in the "DCI

	using ASBRs" solution.</t>	using ASBRs" solution.</li>
		<li>Optimized multicast solution, with independent inclusive
	<t>Optimized multicast solution, with independent inclusive	multicast trees in DC and WAN.</li>
	multicast trees in DC and WAN.</t>	<li>MPLS label aggregation: For the case where MPLS labels are
		signaled from the NVEs for MAC/IP advertisement routes, this
	<t>MPLS Label aggregation: for the case where MPLS labels are	solution provides label aggregation. A remote PE <bcp14>MAY</bcp14> rec
	signaled from the NVEs for MAC/IP Advertisement routes, this	eive a
	solution provides label aggregation. A remote PE MAY receive a	single label per GW MAC-VRF, as opposed to a label per NVE/MAC-VRF
	single label per GW MAC-VRF as opposed to a label per NVE/MAC-VRF	connected to the GW MAC-VRF. For instance, in <xref target="fig-2"/>, P
	connected to the GW MAC-VRF. For instance, in Figure 2, PE would	E would
	receive only one label for all the routes advertised for a given	receive only one label for all the routes advertised for a given

	MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF.</t>	MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF.</li>
		<li>The GW will not propagate MAC Mobility for the MACs moving withi
	<t>The GW will not propagate MAC mobility for the MACs moving within	n
	a DC. Mobility intra-DC is solved by all the NVEs in the DC. The MAC	a DC. Mobility intra-DC is solved by all the NVEs in the DC. The MAC
	Mobility procedures on the GWs are only required in case of mobility	Mobility procedures on the GWs are only required in case of mobility

	across DCs.</t>	across DCs.</li>
		<li>Proxy-ARP/ND function on the DC GWs can be leveraged to reduce
	<t>Proxy-ARP/ND function on the DC GWs can be leveraged to reduce	ARP/ND flooding in the DC or/and the WAN.</li>
	ARP/ND flooding in the DC or/and in the WAN.</t>	</ul>
		</section>
	</list>	</section>
	</t>	<section anchor="sect-4.5" numbered="true" toc="default">
		<name>PBB-EVPN Interconnect for EVPN-Overlay Networks</name>
	</section>	<t>
		PBB-EVPN <xref target="RFC7623" format="default"/> is yet another interconnec
	</section>	t option. It requires

	<section title="PBB-EVPN Interconnect for EVPN-Overlay networks" anchor="
	sect-4.5"><t>
	PBB-EVPN <xref target="RFC7623"/> is yet another Interconnect option. It requ
	ires
	the use of GWs where I-components and associated B-components are	the use of GWs where I-components and associated B-components are
	part of EVI instances.</t>	part of EVI instances.</t>

		<section anchor="sect-4.5.1" numbered="true" toc="default">
	<section title="Control/Data Plane setup procedures on the GWs" anchor="s	<name>Control/Data Plane Setup Procedures on the GWs</name>
	ect-4.5.1"><t>	<t>
	EVPN will run independently in both components, the I-component MAC-VRF and	EVPN will run independently in both components, the I-component MAC-VRF and

	B-component MAC-VRF. Compared to <xref target="RFC7623"/>, the DC C-MACs are	B-component MAC-VRF. Compared to <xref target="RFC7623" format="default"/>,
	no longer	the DC customer MACs (C-MACs) are no longer
	learned in the data plane on the GW but in the control plane through EVPN	learned in the data plane on the GW but in the control plane through EVPN
	running on the I-component. Remote C-MACs coming from remote PEs are still	running on the I-component. Remote C-MACs coming from remote PEs are still
	learned in the data plane. B-MACs in the B-component will be assigned and	learned in the data plane. B-MACs in the B-component will be assigned and

	advertised following the procedures described in <xref target="RFC7623"/>.</t	advertised following the procedures described in <xref target="RFC7623" forma
	>	t="default"/>.</t>
		<t>
	<t>	An I-ES will be configured on the GWs for multihoming, but its I-ESI will
	An I-ES will be configured on the GWs for multi-homing, but its I-ESI will
	only be used in the EVPN control plane for the I-component EVI. No	only be used in the EVPN control plane for the I-component EVI. No

	non-reserved ESIs will be used in the control plane of the B-component EVI	unreserved ESIs will be used in the control plane of the B-component EVI,
	as per <xref target="RFC7623"/>, that is, the I-ES will be represented to the	as per <xref target="RFC7623" format="default"/>. That is, the I-ES will be
	WAN PBB-EVPN	represented to the WAN PBB-EVPN
	PEs using shared or dedicated B-MACs.</t>	PEs using shared or dedicated B-MACs.</t>

		<t>
	<t>	The rest of the control plane procedures will follow <xref target="RFC7432" f
	The rest of the control plane procedures will follow <xref target="RFC7432"/>	ormat="default"/> for
	for	the I-component EVI and <xref target="RFC7623" format="default"/> for the B-c
	the I-component EVI and <xref target="RFC7623"/> for the B-component EVI.</t>	omponent EVI.</t>
		<t>
	<t>
	From the data plane perspective, the I-component and B-component EVPN	From the data plane perspective, the I-component and B-component EVPN

	bindings established to the same far-end will be compared and the	bindings established to the same far end will be compared, and the
	I-component EVPN-overlay binding will be kept down following the rules	I-component EVPN-Overlay binding will be kept down following the rules
	described in section 4.3.1.</t>	described in <xref target="sect-4.3.1"/>.</t>
		</section>
	</section>	<section anchor="sect-4.5.2" numbered="true" toc="default">
		<name>Multihoming Procedures on the GWs</name>
	<section title="Multi-homing procedures on the GWs" anchor="sect-4.5.2"><	<t>
	t>	This model supports single-active as well as all-active multihoming.</t>
	This model supports single-active as well as all-active multi-homing.</t>	<t>

	<t>
	The forwarding behavior of the DF and non-DF will be changed based on	The forwarding behavior of the DF and non-DF will be changed based on

	the description outlined in section 4.4.3, only replacing the "WAN split-hori	the description outlined in <xref target="sect-4.4.3"/>, substituting the
	zon-group" for the B-component, and using <xref target="RFC7623"/>	WAN split-horizon group for the B-component, and using <xref
		target="RFC7623" format="default"/>
	procedures for the traffic sent or received on the B-component.</t>	procedures for the traffic sent or received on the B-component.</t>

		</section>
	</section>	<section anchor="sect-4.5.3" numbered="true" toc="default">
		<name>Impact on MAC Mobility Procedures</name>
	<section title="Impact on MAC Mobility procedures" anchor="sect-4.5.3"><t	<t>
	>
	C-MACs learned from the B-component will be advertised in EVPN within	C-MACs learned from the B-component will be advertised in EVPN within
	the I-component EVI scope. If the C-MAC was previously known in the	the I-component EVI scope. If the C-MAC was previously known in the
	I-component database, EVPN would advertise the C-MAC with a higher	I-component database, EVPN would advertise the C-MAC with a higher

	sequence number, as per <xref target="RFC7432"/>. From a Mobility perspective	sequence number, as per <xref target="RFC7432" format="default"/>. From the
	and	perspective of Mobility and the related procedures described in <xref
	the related procedures described in <xref target="RFC7432"/>, the C-MACs lear	target="RFC7432" format="default"/>, the C-MACs learned
	ned
	from the B-component are considered local.</t>	from the B-component are considered local.</t>

		</section>
	</section>	<section anchor="sect-4.5.4" numbered="true" toc="default">
		<name>Gateway Optimizations</name>
	<section title="Gateway optimizations" anchor="sect-4.5.4"><t>	<t>
	All the considerations explained in section 4.4.5 are applicable to	All the considerations explained in <xref target="sect-4.4.5"/> are
	the PBB-EVPN Interconnect option.</t>	applicable to
		the PBB-EVPN interconnect option.</t>
	</section>	</section>
		</section>
	</section>	<section anchor="sect-4.6" numbered="true" toc="default">
		<name>EVPN-VXLAN Interconnect for EVPN-Overlay Networks</name>
	<section title="EVPN-VXLAN Interconnect for EVPN-Overlay networks" anchor	<t>
	="sect-4.6"><t>	If EVPN for Overlay tunnels is supported in the WAN, and a GW function
	If EVPN for Overlay tunnels is supported in the WAN and a GW function
	is required, an end-to-end EVPN solution can be deployed. While	is required, an end-to-end EVPN solution can be deployed. While
	multiple Overlay tunnel combinations at the WAN and the DC are	multiple Overlay tunnel combinations at the WAN and the DC are

	possible (MPLSoGRE, nvGRE, etc.), VXLAN is described here, given its	possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its
	popularity in the industry. This section focuses on the specific case	popularity in the industry. This section focuses on the specific case
	of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the	of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the

	<xref target="RFC7432"/> procedures.</t>	<xref target="RFC7432" format="default"/> procedures.</t>
		<t>
	<t>	The procedures described in <xref target="sect-4.4"/> apply to this section,
	The procedures described in section 4.4 apply to this section too, only	too, only
	replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and using	substituting EVPN-MPLS for EVPN-VXLAN control plane specifics and using
	<xref target="I-D.ietf-bess-evpn-overlay"/> "Local Bias" procedures instead o	<xref target="RFC8365" format="default"/> "Local Bias" procedures instead
	f section 4.4.3. Since	of <xref target="sect-4.4.3"/>. Since
	there are no ESI-labels in VXLAN, GWs need to rely on "Local Bias" to apply	there are no ESI labels in VXLAN, GWs need to rely on "Local Bias" to apply
	split-horizon on packets generated from the I-ES and sent to the peer GW.</t>	split horizon on packets generated from the I-ES and sent to the peer GW.</t>
		<t>
	<t>	This use case assumes that NVEs need to use the VNIs or VSIDs as
	This use-case assumes that NVEs need to use the VNIs or VSIDs as a	globally unique identifiers within a Data Center, and a Gateway needs
	globally unique identifiers within a data center, and a Gateway needs	to be employed at the edge of the Data-Center network to translate
	to be employed at the edge of the data center network to translate
	the VNI or VSID when crossing the network boundaries. This GW	the VNI or VSID when crossing the network boundaries. This GW

	function provides VNI and tunnel IP address translation. The use-case	function provides VNI and tunnel-IP-address translation. The use case
	in which local downstream assigned VNIs or VSIDs can be used (like	in which local downstream-assigned VNIs or VSIDs can be used (like
	MPLS labels) is described by <xref target="I-D.ietf-bess-evpn-overlay"/>.</t>	MPLS labels) is described by <xref target="RFC8365" format="default"/>.</t>
		<t>
	<t>
	While VNIs are globally significant within each DC, there are two	While VNIs are globally significant within each DC, there are two

	possibilities in the Interconnect network:</t>	possibilities in the interconnect network:</t>
		<ol spacing="normal">
	<t><list style="format (%c)">	<li>Globally unique VNIs in the interconnect network. In this case,
		the GWs and PEs in the interconnect network will agree on a common
	<t>Globally unique VNIs in the Interconnect network: In this case,	VNI for a given EVI. The RT to be used in the interconnect network
	the GWs and PEs in the Interconnect network will agree on a common	can be autoderived from the agreed-upon interconnect VNI. The VNI used
	VNI for a given EVI. The RT to be used in the Interconnect network	inside each DC <bcp14>MAY</bcp14> be the same as the interconnect VNI.<
	can be auto-derived from the agreed Interconnect VNI. The VNI used	/li>
	inside each DC MAY be the same as the Interconnect VNI.</t>	<li>Downstream-assigned VNIs in the interconnect network. In this
		case, the GWs and PEs <bcp14>MUST</bcp14> use the proper RTs to import/
	<t>Downstream assigned VNIs in the Interconnect network. In this	export the EVPN routes. Note that even if the VNI is downstream assigned in the
	case, the GWs and PEs MUST use the proper RTs to import/export the	interconnect network, and unlike option (a), it only identifies the
	EVPN routes. Note that even if the VNI is downstream assigned in the
	Interconnect network, and unlike option (a), it only identifies the
	<Ethernet Tag, GW> pair and not the <Ethernet Tag, egress	<Ethernet Tag, GW> pair and not the <Ethernet Tag, egress

	PE> pair. The VNI used inside each DC MAY be the same as the	PE> pair. The VNI used inside each DC <bcp14>MAY</bcp14> be the same
	Interconnect VNI. GWs SHOULD support multiple VNI spaces per EVI	as the
	(one per Interconnect network they are connected to).	interconnect VNI. GWs <bcp14>SHOULD</bcp14> support multiple VNI spaces
	</t>	per EVI
		(one per interconnect network they are connected to).
	</list>	</li>
	</t>	</ol>
		<t>
	<t>
	In both options, NVEs inside a DC only have to be aware of a single	In both options, NVEs inside a DC only have to be aware of a single
	VNI space, and only GWs will handle the complexity of managing	VNI space, and only GWs will handle the complexity of managing
	multiple VNI spaces. In addition to VNI translation above, the GWs	multiple VNI spaces. In addition to VNI translation above, the GWs
	will provide translation of the tunnel source IP for the packets	will provide translation of the tunnel source IP for the packets
	generated from the NVEs, using their own IP address. GWs will use	generated from the NVEs, using their own IP address. GWs will use

	that IP address as the BGP next-hop in all the EVPN updates to the	that IP address as the BGP next hop in all the EVPN updates to the
	Interconnect network.</t>	interconnect network.</t>
		<t>
	<t>
	The following sections provide more details about these two options.</t>	The following sections provide more details about these two options.</t>

		<section anchor="sect-4.6.1" numbered="true" toc="default">
	<section title="Globally unique VNIs in the Interconnect network" anchor=	<name>Globally Unique VNIs in the Interconnect Network</name>
	"sect-4.6.1"><t>	<t>
	Considering Figure 2, if a host H1 in NVO-1 needs to communicate with a	Considering <xref target="fig-2"/>, if a host H1 in NVO-1 needs to communicat
		e with a
	host H2 in NVO-2, and assuming that different VNIs are used in each DC for	host H2 in NVO-2, and assuming that different VNIs are used in each DC for

	the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs MUST	the same EVI (e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2), then the VNIs
	be translated to a common Interconnect VNI (e.g. VNI-100) on the GWs. Each	<bcp14>MUST</bcp14>
		be translated to a common interconnect VNI (e.g., VNI-100) on the GWs. Each
	GW is provisioned with a VNI translation mapping so that it can translate	GW is provisioned with a VNI translation mapping so that it can translate
	the VNI in the control plane when sending BGP EVPN route updates to the	the VNI in the control plane when sending BGP EVPN route updates to the

	Interconnect network. In other words, GW1 and GW2 MUST be configured to map	interconnect network. In other words, GW1 and GW2 <bcp14>MUST</bcp14> be conf
	VNI-10 to VNI-100 in the BGP update messages for H1's MAC route. This	igured to map
		VNI-10 to VNI-100 in the BGP update messages for H1's MAC route.

		This
	mapping is also used to translate the VNI in the data plane in both	mapping is also used to translate the VNI in the data plane in both

	directions, that is, VNI- 10 to VNI-100 when the packet is received from	directions: that is, VNI-10 to VNI-100 when the packet is received from
	NVO-1 and the reverse mapping from VNI-100 to VNI-10 when the packet is	NVO-1 and the reverse mapping from VNI-100 to VNI-10 when the packet is
	received from the remote NVO-2 network and needs to be forwarded to NVO-1.</t >	received from the remote NVO-2 network and needs to be forwarded to NVO-1.</t >

		<t>
	<t>	The procedures described in <xref target="sect-4.4"/> will be followed,
	The procedures described in section 4.4 will be followed, considering	considering
	that the VNIs advertised/received by the GWs will be translated	that the VNIs advertised/received by the GWs will be translated
	accordingly.</t>	accordingly.</t>

		</section>
	</section>	<section anchor="sect-4.6.2" numbered="true" toc="default">
		<name>Downstream-Assigned VNIs in the Interconnect Network</name>
	<section title="Downstream assigned VNIs in the Interconnect network" anc	<t>
	hor="sect-4.6.2"><t>
	In this case, if a host H1 in NVO-1 needs to communicate with a host	In this case, if a host H1 in NVO-1 needs to communicate with a host
	H2 in NVO-2, and assuming that different VNIs are used in each DC for	H2 in NVO-2, and assuming that different VNIs are used in each DC for

	the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs	the same EVI, e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs
	MUST be translated as in section 4.6.1. However, in this case, there	<bcp14>MUST</bcp14> be translated as in <xref
	is no need to translate to a common Interconnect VNI on the GWs. Each	target="sect-4.6.1"/>. However, in this case, there
		is no need to translate to a common interconnect VNI on the GWs. Each
	GW can translate the VNI received in an EVPN update to a locally	GW can translate the VNI received in an EVPN update to a locally

	assigned VNI advertised to the Interconnect network. Each GW can use	assigned VNI advertised to the interconnect network. Each GW can use
	a different Interconnect VNI, hence this VNI does not need to be	a different interconnect VNI; hence, this VNI does not need to be
	agreed on all the GWs and PEs of the Interconnect network.</t>	agreed upon on all the GWs and PEs of the interconnect network.</t>
		<t>
	<t>	The procedures described in <xref target="sect-4.4"/> will be followed,
	The procedures described in section 4.4 will be followed, taking the	taking into account the considerations above for the VNI translation.</t>
	considerations above for the VNI translation.</t>	</section>
		</section>
	</section>	</section>
		<section anchor="sect-5" numbered="true" toc="default">
	</section>	<name>Security Considerations</name>
		<t>
	</section>

	<section title="Security Considerations" anchor="sect-5"><t>
	This document applies existing specifications to a number of	This document applies existing specifications to a number of

	Interconnect models. The Security Considerations included in those	interconnect models. The security considerations included in those
	documents, such as <xref target="RFC7432"/>, <xref target="I-D.ietf-bess-evpn	documents, such as <xref target="RFC7432" format="default"/>, <xref
	-overlay"/>, <xref target="RFC7623"/>, <xref target="RFC4761"/>	target="RFC8365" format="default"/>, <xref target="RFC7623"
	and <xref target="RFC4762"/> apply to this document whenever those technologi	format="default"/>, <xref target="RFC4761" format="default"/>,
	es are	and <xref target="RFC4762" format="default"/> apply to this document
		whenever those technologies are
	used.</t>	used.</t>

		<t>
	<t>	As discussed, <xref target="RFC8365" format="default"/> discusses two main DC
	As discussed, <xref target="I-D.ietf-bess-evpn-overlay"/> discusses two main	I solution groups:
	DCI solution groups:
	"DCI using GWs" and "DCI using ASBRs". This document specifies the	"DCI using GWs" and "DCI using ASBRs". This document specifies the
	solutions that correspond to the "DCI using GWs" group. It is	solutions that correspond to the "DCI using GWs" group. It is

	important to note that the use of GWs provide a superior level of	important to note that the use of GWs provides a superior level of
	security on a per tenant basis, compared to the use of ASBRs. This is	security on a per-tenant basis, compared to the use of ASBRs. This is
	due to the fact that GWs need to perform a MAC lookup on the frames	due to the fact that GWs need to perform a MAC lookup on the frames
	being received from the WAN, and they apply security procedures, such	being received from the WAN, and they apply security procedures, such
	as filtering of undesired frames, filtering of frames with a source	as filtering of undesired frames, filtering of frames with a source

	MAC that matches a protected MAC in the DC or application of MAC	MAC that matches a protected MAC in the DC, or application of
	duplication procedures defined in <xref target="RFC7432"/>. On ASBRs though,	MAC-duplication procedures defined in <xref target="RFC7432"
	traffic	format="default"/>. On ASBRs, though, traffic
	is forwarded based on a label or VNI swap and there is usually no	is forwarded based on a label or VNI swap, and there is usually no
	visibility of the encapsulated frames, which can carry malicious	visibility of the encapsulated frames, which can carry malicious
	traffic.</t>	traffic.</t>

		<t>
	<t>	In addition, the GW optimizations specified in this document provide
	In addition, the GW optimizations specified in this document, provide	additional protection of the DC tenant systems. For instance, the
	additional protection of the DC Tenant Systems. For instance, the MAC	MAC-address advertisement control and Unknown MAC Route defined in
	address advertisement control and Unknown MAC Route defined in	<xref target="sect-3.5.1"/> protect the DC NVEs from being overwhelmed with a
	section 3.5.1 protect the DC NVEs from being overwhelmed with an	n
	excessive number MAC/IP routes being learned on the GWs from the WAN.	excessive number of MAC/IP routes being learned on the GWs from the WAN.
	The ARP/ND flooding control described in 3.5.2 can reduce/suppress	The ARP/ND flooding control described in <xref target="sect-3.5.2"/> can redu
		ce/suppress
	broadcast storms being injected from the WAN.</t>	broadcast storms being injected from the WAN.</t>

		<t>
	<t>
	Finally, the reader should be aware of the potential security	Finally, the reader should be aware of the potential security

	implications of designing a DCI with the Decoupled Interconnect	implications of designing a DCI with the decoupled interconnect
	solution (section 3) or the Integrated Interconnect solution (section	solution (<xref target="sect-3"/>) or the integrated interconnect solution
	4). In the Decoupled Interconnect solution the DC is typically easier	(<xref target="sect-4"/>). In the decoupled interconnect solution, the DC is
		typically easier
	to protect from the WAN, since each GW has a single logical link to	to protect from the WAN, since each GW has a single logical link to
	one WAN PE, whereas in the Integrated solution, the GW has logical	one WAN PE, whereas in the Integrated solution, the GW has logical
	links to all the WAN PEs that are attached to the tenant. In either	links to all the WAN PEs that are attached to the tenant. In either
	model, proper control plane and data plane policies should be put in	model, proper control plane and data plane policies should be put in
	place in the GWs in order to protect the DC from potential attacks	place in the GWs in order to protect the DC from potential attacks
	coming from the WAN.</t>	coming from the WAN.</t>

		</section>
		<section anchor="sect-6" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>
		This document has no IANA actions.</t>
		</section>
		</middle>
		<back>


	</section>	<displayreference target="I-D.ietf-bess-evpn-virtual-eth-segment" to="VIRTUAL-ES "/>


	<section title="IANA Considerations" anchor="sect-6"><t>	<references>
	This document has no IANA actions.</t>	<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4761.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4762.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6074.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7041.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7432.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>


	</section>	<!-- draft-ietf-idr-tunnel-encaps-15 is now RFC 9012-->
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9012.
		xml"/>


	</middle>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7623.xml"/>


	<back>	<!-- [I-D.ietf-bess-evpn-overlay] Published as RFC 8365 -->
	<references title="Normative References">
	&RFC4761;
	&RFC4762;
	&RFC6074;
	&RFC7041;
	&RFC7432;
	&RFC2119;
	&RFC8174;
	&I-D.ietf-idr-tunnel-encaps;
	&RFC7623;
	&I-D.ietf-bess-evpn-overlay;
	&RFC7543;
	</references>
	<references title="Informative References">
	&RFC4684;
	&RFC7348;
	&RFC7637;
	&RFC4023;
	<reference anchor="Y.1731"><front>
	<title>OAM functions and mechanisms for Ethernet based networks</title>
	<author>
	<organization>ITU-T Recommendation Y.1731</organization>
	</author>


	<date month="July" year="2011"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</front>	FC.8365.xml"/>


	</reference>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<reference anchor="IEEE.802.1AG"><front>	FC.7543.xml"/>
	<title>IEEE Standard for Local and Metropolitan Area Networks - Virtual B
	ridged Local Area Networks Amendment 5: Connectivity Fault Management</title>
	<author>
	<organization>IEEE 802.1AG_2007</organization>
	</author>


	<date month="January" year="2008"/>	</references>
	</front>	<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4684.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7348.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7637.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4023.xml"/>


	</reference>	<reference anchor="Y.1731">
	<reference anchor="IEEE.802.1Q-2014"><front>	<front>
	<title>IEEE Standard for Local and metropolitan area networks--Bridges an	<title>OAM functions and mechanisms for Ethernet based networks</tit
	d Bridged Networks</title>	le>
	<author>	<author>
	<organization>IEEE 802.1Q-2014</organization>	<organization>ITU-T</organization>
	</author>	</author>
		<date month="August" year="2019"/>
		</front>
		<seriesInfo name="ITU-T Recommendation" value="Y.1731" />
		</reference>


	<date month="December" year="2014"/>	<reference anchor="IEEE.802.1AG">
	</front>	<front>
		<title>IEEE Standard for Local and Metropolitan Area Networks
		Virtual Bridged Local Area Networks Amendment 5: Connectivity
		Fault Management</title>
		<author>
		<organization>IEEE</organization>
		</author>
		<date month="January" year="2008"/>
		</front>
		<seriesInfo name="IEEE standard" value="802.1ag-2007"/>
		</reference>


	</reference>	<reference anchor="IEEE.802.1Q">
	&RFC6870;	<front>
	&RFC3031;	<title>IEEE Standard for Local and metropolitan area
	&I-D.sajassi-bess-evpn-virtual-eth-segment;	networks--Bridges and Bridged Networks</title>
	</references>	<author>
	<section title="Acknowledgments" anchor="sect-8"><t>	<organization>IEEE</organization>
	The authors would like to thank Neil Hart, Vinod Prabhu and Kiran	</author>
	Nagaraj for their valuable comments and feedback. We would also like	<date month="December" year="2014"/>
	to thank Martin Vigoureux and Alvaro Retana for his detailed review	</front>
	and comments.</t>	<seriesInfo name="IEEE standard" value="802.1Q-2014" />
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6991462"/>
		</reference>


	</section>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6870.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3031.xml"/>


	<section title="Contributors" anchor="sect-9"><t>	<!-- [I-D.sajassi-bess-evpn-virtual-eth-segment] Replaced by
		draft-ietf-bess-evpn-virtual-eth-segment; IESG state I-D Exists -->

		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
		.ietf-bess-evpn-virtual-eth-segment.xml"/>

		</references>
		</references>
		<section anchor="sect-8" numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>
		The authors would like to thank <contact fullname="Neil Hart"/>, <contact
		fullname="Vinod Prabhu"/>, and <contact fullname="Kiran Nagaraj"/> for
		their valuable comments and feedback. We would also like
		to thank <contact fullname="Martin Vigoureux"/> and <contact
		fullname="Alvaro Retana"/> for their detailed reviews and comments.</t>
		</section>
		<section anchor="sect-9" numbered="false" toc="default">
		<name>Contributors</name>
		<t>
	In addition to the authors listed on the front page, the following	In addition to the authors listed on the front page, the following

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


	<figure><artwork><![CDATA[	<contact fullname="Ravi Shekhar">
	Ravi Shekhar	<organization>Juniper Networks</organization>
	Anil Lohiya	</contact>
	Wen Lin
	Juniper Networks


	Florin Balus	<contact fullname="Anil Lohiya">
	Patrice Brissette	<organization>Juniper Networks</organization>
	Cisco	</contact>


	Senad Palislamovic	<contact fullname="Wen Lin">
	Nokia	<organization>Juniper Networks</organization>
		</contact>


	Dennis Cai	<contact fullname="Florin Balus">
	Alibaba	<organization>Cisco</organization>
	]]></artwork>	</contact>
	</figure>
	</section>


	</back>	<contact fullname="Patrice Brissette">
		<organization>Cisco</organization>
		</contact>


	</rfc>	<contact fullname="Senad Palislamovic">
		<organization>Nokia</organization>
		</contact>

		<contact fullname="Dennis Cai">
		<organization>Alibaba</organization>
		</contact>
		</section>
		</back>

		</rfc>

End of changes. 183 change blocks.
	1210 lines changed or deleted	1066 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/