Diff: rfc9721xml2.original.xml

	rfc9721xml2.original.xml	rfc9721.xml

	<?xml version='1.0' encoding='ascii'?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	<!DOCTYPE rfc [
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<!ENTITY nbsp " ">
	<?rfc toc="yes"?>	<!ENTITY zwsp "">
	<?rfc tocompact="no"?>	<!ENTITY nbhy "‑">
	<?rfc tocdepth="6"?>	<!ENTITY wj "⁠">
	<?rfc symrefs="yes"?>	]>
	<?rfc sortrefs="yes"?>
	<?rfc compact="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc subcompact="no"?>	tf-bess-evpn-irb-extended-mobility-21" number="9721" consensus="true" ipr="trust
	<?rfc strict="yes" ?>	200902" obsoletes="" submissionType="IETF" xml:lang="en" updates="" tocInclude="
	<rfc category="std" docName="draft-ietf-bess-evpn-irb-extended-mobility-21" ipr=	true" tocDepth="6" symRefs="true" sortRefs="true" version="3">
	"trust200902" obsoletes="" submissionType="IETF" xml:lang="en">
		<!-- [rfced] Please note that the title of the document has been updated as
		follows:

		Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
		Style Guide"). Please review.

		Original:

		Extended Mobility Procedures for EVPN-IRB

		Current:

		Extended Mobility Procedures for Ethernet VPN Integrated Routing and
		Bridging (EVPN-IRB)
		-->

	<front>	<front>

	<title abbrev="EVPN-IRB Extended Mobility">	<title abbrev="EVPN-IRB Extended Mobility">Extended Mobility Procedures
	Extended Mobility Procedures for EVPN-IRB	for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)</title>
	</title>	<seriesInfo name="RFC" value="9721"/>
	<author fullname="Neeraj Malhotra" initials="N." surname="Malhotra" role="ed itor">	<author fullname="Neeraj Malhotra" initials="N." surname="Malhotra" role="ed itor">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>
	<address>	<address>
	<postal>	<postal>
	<street>170 W. Tasman Drive</street>	<street>170 W. Tasman Drive</street>

	<street/>
	<city>San Jose</city>	<city>San Jose</city>
	<code>95134</code>	<code>95134</code>
	<region>CA</region>	<region>CA</region>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>nmalhotr@cisco.com</email>	<email>nmalhotr@cisco.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Ali Sajassi" initials="A." surname="Sajassi">	<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>
	<address>	<address>
	<postal>	<postal>
	<street>170 W. Tasman Drive</street>	<street>170 W. Tasman Drive</street>

	<street/>
	<city>San Jose</city>	<city>San Jose</city>
	<code>95134</code>	<code>95134</code>
	<region>CA</region>	<region>CA</region>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>sajassi@cisco.com</email>	<email>sajassi@cisco.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Aparna Pattekar" initials="A." surname="Pattekar">	<author fullname="Aparna Pattekar" initials="A." surname="Pattekar">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>
	<address>	<address>
	<postal>	<postal>
	<street>170 W. Tasman Drive</street>	<street>170 W. Tasman Drive</street>

	<street/>
	<city>San Jose</city>	<city>San Jose</city>
	<code>95134</code>	<code>95134</code>
	<region>CA</region>	<region>CA</region>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>apjoshi@cisco.com</email>	<email>apjoshi@cisco.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">	<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
	<organization>Nokia</organization>	<organization>Nokia</organization>
	<address>	<address>
	<postal>	<postal>
	<street>777 E. Middlefield Road</street>	<street>777 E. Middlefield Road</street>
	<city>Mountain View</city>	<city>Mountain View</city>
	<code>94043</code>	<code>94043</code>
	<region>CA</region>	<region>CA</region>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>jorge.rabadan@nokia.com</email>	<email>jorge.rabadan@nokia.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Avinash Lingala" initials="A." surname="Lingala">	<author fullname="Avinash Lingala" initials="A." surname="Lingala">
	<organization>AT&T</organization>	<organization>AT&T</organization>
	<address>	<address>
	<postal>	<postal>
	<street>3400 W Plano Pkwy</street>	<street>3400 W Plano Pkwy</street>
	<city>Plano</city>	<city>Plano</city>
	<region>TX</region>	<region>TX</region>
	<code>75075</code>	<code>75075</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>ar977m@att.com</email>	<email>ar977m@att.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="John Drake" initials="J." surname="Drake">	<author fullname="John Drake" initials="J." surname="Drake">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>
	<address>	<address>
	<email>jdrake@juniper.net</email>	<email>jdrake@juniper.net</email>
	</address>	</address>
	</author>	</author>

	<date month="December" day="4" year="2024"/>	<date month="April" year="2025"/>
	<area>Routing</area>	<area>RTG</area>
	<workgroup>BESS WorkGroup</workgroup>	<workgroup>bess</workgroup>
	<abstract> <t>
	This document specifies extensions to Ethernet VPN (EVPN) Integrated Routi	<!-- [rfced] Please insert any keywords (beyond those that appear in
	ng and Bridging (IRB) procedures specified in RFC7432 and RFC9135 to enhance the	the title) for use on https://www.rfc-editor.org/search. -->
	mobility mechanisms for EVPN-IRB based networks. The proposed extensions improv
	e the handling of host mobility and duplicate address detection in EVPN-IRB netw	<keyword>example</keyword>
	orks to cover a broader set of scenarios where a host's unicast IP address to MA
	C address bindings may change across moves. These enhancements address limitati	<abstract>
	ons in the existing EVPN-IRB mobility procedures by providing more efficient and	<t>This document specifies extensions to the Ethernet VPN Integrated
	scalable solutions. The extensions are backward compatible with existing EVPN-I	Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and
	RB implementations and aim to optimize network performance in scenarios involvin	9135 to enhance the mobility mechanisms
	g frequent IP address mobility.	for networks based on EVPN-IRB. The proposed extensions improve the
	</t>	handling of host mobility and duplicate address detection in EVPN-IRB
	<t>	networks to cover a broader set of scenarios where a
	NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six aut	host's unicast IP address to Media Access Control (MAC) address bindings
	hors which is above the required limit of five. Given significant and active con	may change across moves. These enhancements address limitations in the
	tributions to the draft from all six authors over the course of six years, we wo	existing EVPN-IRB mobility procedures by providing more efficient and
	uld like to request IESG to allow publication with six authors. Specifically, th	scalable solutions. The extensions are backward compatible with existing
	e three Cisco authors are the original inventors of these procedures and contrib	EVPN-IRB implementations and aim to optimize network performance in
	uted heavily to rev 0 draft, most of which is still intact. AT&T is also a k	scenarios involving frequent IP address mobility.</t>
	ey contributor towards defining the use cases that this document addresses as we
	ll as the proposed solution. Authors from Nokia and Juniper have further contrib
	uted to revisions and discussions steadily over last six years to enable respect
	ive implementations and a wider adoption.
	</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>

	<section anchor="Intro" title="Introduction" numbered="true" toc="default">
	<t>	<section anchor="Intro" numbered="true" toc="default">
	EVPN-IRB facilitates the advertisement of both MAC and IP routes via a s	<name>Introduction</name>
	ingle MAC+IP Route Type 2 (RT-2) advertisement. The MAC address is integrated in	<t>EVPN-IRB facilitates
	to the local MAC-VRF bridge table, enabling Layer 2 (L2) bridged traffic across	the advertisement of both MAC and IP routes via a
	the network overlay. The IP address is incorporated into the local ARP/NDP table	single MAC+IP Route Type 2 (RT-2) advertisement. The MAC address is
	in an asymmetric IRB design, or into the IP-VRF routing table in a symmetric IR	integrated into the local MAC Virtual Routing and Forwarding (MAC-VRF)
	B design, facilitating routed traffic across the network overlay. For additional	bridge table, enabling Layer 2 (L2) bridged traffic across the network
	context on EVPN-IRB forwarding modes, refer to [RFC9135].	overlay. The IP address is incorporated into the local Address Resolution
	</t>	Protocol (ARP) / Neighbor Discovery Protocol (NDP) table in an
	<t>	asymmetric IRB design or into the IP Virtual Routing and Forwarding
	To support the EVPN mobility procedure, a single sequence number mobilit	(IP-VRF) routing table in a symmetric IRB design. This facilitates
	y attribute is advertised with the combined MAC+IP route. This approach, which r	routed traffic across the network overlay. For additional context on
	esolves both MAC and IP reachability with a single sequence number, inherently a	EVPN-IRB forwarding modes, refer to <xref target="RFC9135"/>.</t>
	ssumes a fixed 1:1 mapping between IP address and MAC address. While this fixed
	1:1 mapping is a common use case and is addressed via the existing mobility proc	<t>To support the EVPN mobility procedure, a single sequence number
	edure defined in [RFC7432], there are additional IRB scenarios that do not adher	mobility attribute is advertised with the combined MAC+IP route. This
	e to this assumption. Such scenarios are prevalent in virtualized host environme	approach, which resolves both MAC and IP reachability with a single
	nts where hosts connected to an EVPN network are virtual machines (VMs) or conta	sequence number, inherently assumes a fixed 1:1 mapping between an IP
	inerized workloads. The following IRB mobility scenarios are considered:	address and MAC address. While this fixed 1:1 mapping is a common use
	<list style="symbols"> <t>	case and is addressed via the existing mobility procedure defined in
		<xref target="RFC7432"/>, there are additional IRB scenarios that do not
		adhere to this assumption. Such scenarios are prevalent in virtualized
		host environments where hosts connected to an EVPN network are Virtual
		Machines (VMs) or containerized workloads. The following IRB mobility
		scenarios are considered:</t>

		<ul spacing="normal">
		<li>
	A host move results in the host's IP address and MAC address moving together.	A host move results in the host's IP address and MAC address moving together.

	</t> <t>	</li>
		<li>
	A host move results in the host's IP address moving to a new MAC add ress association.	A host move results in the host's IP address moving to a new MAC add ress association.

	</t> <t>	</li>
		<li>
	A host move results in the host's MAC address moving to a new IP add ress association.	A host move results in the host's MAC address moving to a new IP add ress association.

	</t>	</li>
	</list>	</ul>
	</t>
	<t>	<t>While the existing mobility procedure can manage the MAC+IP address
	While the existing mobility procedure can manage the MAC+IP address move	move in the first scenario, the subsequent scenarios lead to new MAC-IP
	in the first scenario, the subsequent scenarios lead to new MAC-IP address asso	address associations. Therefore, a single sequence number assigned
	ciations. Therefore, a single sequence number assigned independently per-{MAC ad	independently for each {MAC address, IP address} is insufficient to determ
	dress, IP address} is insufficient to determine the most recent reachability for	ine
	both MAC address and IP address unless the sequence number assignment algorithm	the most recent reachability for both MAC address and IP address, unless
	allows for changing MAC-IP address bindings across moves.	the sequence number assignment algorithm allows for changing MAC-IP
	</t>	address bindings across moves.</t>
	<t>
	This document updates the sequence number assignment procedures defined	<!-- [rfced] May we number the text below for ease of the reader? Please
	in [RFC7432] to adequately address mobility support across EVPN-IRB overlay use	review:
	cases that permit MAC-IP address bindings to change across host moves and suppor
	t mobility for both MAC and IP route components carried in an EVPN RT-2 for thes	Original:
	e use cases.
	</t>	This document updates the sequence number assignment procedures
	<t>	defined in [RFC7432] to adequately address mobility support across
	Additionally, for hosts on an ESI multi-homed to multiple PE devices, ad	EVPN-IRB overlay use cases that permit MAC-IP address bindings to
	ditional procedures are specified to ensure synchronized sequence number assignm	change across host moves and support mobility for both MAC and IP
	ents across the multi-homing devices.	route components carried in an EVPN RT-2 for these use cases.
	</t>
	<t>	Perhaps:
	This document addresses mobility for the following cases, independent of
	the overlay encapsulation (e.g., MPLS, SRv6, NVO Tunnel):	This document updates the sequence number assignment procedures
	<list style="symbols"> <t>	defined in [RFC7432] to 1) adequately address mobility support across
	Symmetric EVPN-IRB overlay	EVPN-IRB overlay use cases that permit MAC-IP address bindings to change
	</t> <t>	across host moves and 2) support mobility for both MAC and IP
	Asymmetric EVPN-IRB overlay	route components carried in an EVPN RT-2 for these use cases.
	</t> <t>
	Routed EVPN overlay	-->
	</t>
	</list>	<t>This document updates the sequence number assignment procedures
	</t>	defined in <xref target="RFC7432"/> to adequately
	<section anchor="doc-structure" title="Document Structure" numbered="true"	address mobility support across EVPN-IRB overlay use cases that permit
	toc="default">	MAC-IP address bindings to change across host moves and
	<t>	support mobility for both MAC and IP route components carried in an
	Following sections of the document are informative:	EVPN RT-2 for these use cases.</t>
	<list style="symbols"> <t>
	section 3 provides the necessary background and problem statement be	<t>Additionally, for hosts on an Ethernet Segment Identifier (ESI) that
	ing addressed in this document.	is multi-homed to multiple Provider Edge (PE) devices, additional
	</t> <t>	procedures are specified to ensure synchronized sequence number
	section 4 lists the resulting design considerations for the document	assignments across the multi-homing devices.</t>
	.
	</t> <t>	<t>This document addresses mobility for the following cases, independent
	section 5 lists the main solution components that are foundational f	of the overlay encapsulation (e.g., MPLS, Segment Routing over IPv6
	or the sepecifications that follow in subsequent sections.	(SRv6), and Network Virtualization Overlay (NVO) tunnel):</t>
	</t>
	</list>	<ul spacing="normal">
	</t>	<li>Symmetric EVPN-IRB overlay</li>
	<t>	<li>Asymmetric EVPN-IRB overlay</li>
	Following sections of the document are normative:	<li>Routed EVPN overlay</li>
	<list style="symbols"> <t>	</ul>
	section 6 describes the mobility and sequence number assigment proce
	dures in an EVPN-IRB overlay required to address the scenarios described in sect	<section anchor="doc-structure" numbered="true" toc="default">
	ion 4.	<name>Document Structure</name>
	</t> <t>	<t>The following sections of the document are informative:</t>
	section 7 describes the mobility procedures for a routed overlay net	<ul spacing="normal">
	work as opposed to an IRB overlay.	<li>
	</t> <t>	<xref target="Background-Problem-Statement"/> provides the
	section 8 describes corresponding duplicate detection procedures for	necessary background and problem statement being addressed in this
	EVPN-IRB and routed overlays.	document.
	</t>	</li>
	</list>	<li>
	</t>	<xref target="Design-Considerations"/> lists the resulting design
		considerations for the document.
		</li>
		<li>
		<xref target="Solution-Components"/> lists the main solution
		components that are foundational for the specifications that
		follow in subsequent sections.
		</li>
		</ul>

		<t>The following sections of the document are normative:</t>

		<ul spacing="normal">
		<li>
		<xref target="Methods-for-Sequence-Number-Assignment"/> describes
		the mobility and sequence number assignment procedures in an
		EVPN-IRB overlay that are required to address the scenarios describe
		d in
		<xref target="Design-Considerations"/>.
		</li>
		<li>
		<xref target="Routed-Overlay"/> describes the mobility procedures
		for a routed overlay network as opposed to an IRB overlay.
		</li>
		<li>
		<xref target="Duplicate-Host-Detection"/> describes corresponding
		duplicate detection procedures for EVPN-IRB and routed overlays.
		</li>
		</ul>
	</section>	</section>
	</section>	</section>

	<section anchor="Req" title="Requirements Language and Terminology" numbered
	="true" toc="default">	<section anchor="Req" numbered="true" toc="default">
	<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<name>Requirements Language and Terminology</name>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
	appear in all capitals, as shown here.</t>
	<t>
	<list style="symbols"> <t>
	EVPN-IRB: A BGP-EVPN distributed control plane based integrated routing
	and bridging fabric overlay discussed in [RFC9135].
	</t><t>
	Underlay: IP, MPLS, or SRv6 fabric core network that provides routed re
	achability between EVPN PEs.
	</t><t>
	Overlay: L3 and L2 Virtual Private Network (VPN) enabled via NVO3, VXLA
	N, SRv6, or MPLS service layer encapsulation.
	</t><t>
	SRv6: Segment Routing IPv6 protocol as specified in [RFC8986].
	</t><t>
	NVO3: Network Virtualization Overlays as specified in [RFC8926].
	</t><t>
	VXLAN: Virtual eXtensible Local Area Network as specified in [RFC7348]
	</t><t>
	MPLS: Multi-Protocol Label Switching as specified in [RFC3031].
	</t><t>
	EVPN PE: A PE switch-router in an EVPN-IRB network that runs overlay BG
	P-EVPN control plane and connects to overlay CE host devices. An EVPN PE may als
	o be the first-hop layer-3 gateway for CE/host devices. This document refers to
	EVPN PE as a logical function in an EVPN-IRB network. This EVPN PE function may
	be physically hosted on a top-of-rack switching device (ToR) OR at layer(s) abov
	e the ToR in the Clos fabric. An EVPN PE is typically also an IP or MPLS tunnel
	end-point for overlay VPN flow.
	</t><t>
	Symmetric EVPN-IRB: is a specific design approach used in EVPN-based ne
	tworks [RFC9135] to handle both Layer 2 (L2) and Layer 3 (L3) forwarding within
	the same network infrastructure. The key characteristic of symmetric EVPN-IRB is
	that both ingress and egress PE routers perform routing for inter-subnet traffi
	c.
	</t><t>
	Asymmetric EVPN-IRB: is a design approach used in EVPN-based networks [
	RFC9135] to handle Layer 2 (L2) and Layer 3 (L3) forwarding. In this approach, o
	nly the ingress Provider Edge (PE) router performs routing for inter-subnet traf
	fic, while the egress PE router performs bridging.
	</t><t>
	ARP: Address Resolution Protocol [RFC826]. ARP references in this docum
	ent are equally applicable to both ARP and NDP.
	</t><t>
	NDP: IPv6 Neighbor Discovery Protocol [RFC4861].
	</t><t>
	Ethernet-Segment: Physical ethernet or LAG (Link Aggregation Group) por
	t that connects an access device to an EVPN PE, as defined in [RFC7432].
	</t><t>
	MC-LAG: Multi-Chasis Link Aggregation Group.
	</t><t>
	EVPN all-active multi-homing: is a redundancy and load-sharing mechanis
	m used in EVPN networks. This method allows multiple PE devices to simultaneousl
	y provide Layer 2 and Layer 3 connectivity to a single CE device or network segm
	ent.
	</t><t>
	RT-2: EVPN route type 2 carrying both MAC address and IP address reacha
	bility as specified in [RFC7432].
	</t><t>
	RT-5: EVPN route type 5 carrying IP prefix reachability as specified in
	[RFC7432].
	</t><t>
	MAC-IP address: IPv4 and/or IPv6 address and MAC address binding for an
	overlay host.
	</t><t>
	Peer-Sync-Local MAC route: BGP EVPN learnt MAC route for a host that is
	directly attached to a local multi-homed Ethernet Segment.
	</t><t>
	Peer-Sync-Local MAC-IP route: BGP EVPN learnt MAC-IP route for a host t
	hat is directly attached to a local multi-homed Ethernet Segment.
	</t><t>
	Peer-Sync-Local MAC sequence number: Sequence number received with a Pe
	er-Sync-Local MAC route.
	</t><t>
	Peer-Sync-Local MAC-IP sequence number: Sequence number received with a
	Peer-Sync-Local MAC-IP route.
	</t><t>
	VM: Virtual Machine or containerized workloads.
	</t><t>
	Host: Host in this document generically refers to any user/CE endpoint
	attached to an EVPN-IRB network which may be a VM, containerized workload or a p
	hysical end-point or CE device.
	</t></list> </t>
	</section>
	<section anchor="Background-Problem-Statement" title="Background and Problem
	Statement" numbered="true" toc="default">
	<section anchor="Optional-MAC-RT-2" title="Optional MAC only RT-2" numbere
	d="true" toc="default">
	<t>	<t>

	In an EVPN-IRB scenario, where a single MAC+IP RT-2 advertisement carr	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	ies both IP and MAC routes, a MAC-only RT-2 advertisement becomes redundant for	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	host MAC addresses already advertised via MAC+IP RT-2. Consequently, the adverti	",
	sement of a local MAC-only RT-2 is optional at an EVPN PE. This consideration is	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	important for mobility scenarios discussed in subsequent sections. It is notewo	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	rthy that a local MAC route and its assigned sequence number are still maintaine	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	d locally on a PE, and only the advertisement of this route to other PEs is opti	be
	onal.	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
	</t> <t>	target="RFC8174"/> when, and only when, they appear in all capitals, as
	MAC-only RT-2 advertisements may still be issued for non-IP host MAC a	shown here.
	ddresses that are not included in MAC+IP RT-2 advertisements.
	</t>	</t>


		<!-- [rfced] Section 2: Please review the following questions and changes
		regarding the terminology list in this section.

		a.) FYI - We have made several updates to reflect a 1:1 relationship between
		abbreviation and expansion. Please carefully review these updates and let us
		know any objections.

		b.) As this list contains both abbreviations and definitions, would you like
		to separate these items into two separate lists for readability?

		c.) Would you like to order these terms alphabetically?

		d.) We have adjusted the list items below for clarity. Please review to ensure
		these updates do not change your intended meaning.

		Original:

		* EVPN-IRB: A BGP-EVPN distributed control plane based integrated
		routing and bridging fabric overlay discussed in [RFC9135].

		* Overlay: L3 and L2 Virtual Private Network (VPN) enabled via NVO3,
		VXLAN, SRv6, or MPLS service layer encapsulation.

		* Host: Host in this document generically refers to any user/CE
		endpoint attached to an EVPN-IRB network which may be a VM,
		containerized workload or a physical end-point or CE device.

		* Ethernet-Segment: Physical ethernet or LAG (Link Aggregation
		Group) port that connects an access device to an EVPN PE, as
		defined in [RFC7432].

		Current:

		EVPN-IRB: Ethernet VPN Integrated Routing and Bridging. A
		BGP-EVPN distributed control plane that is based on the integrated
		routing and bridging fabric overlay discussed in [RFC9135].

		Overlay: L2 and L3 VPNs that are enabled via NVO3, VXLAN,
		SRv6, or MPLS service-layer encapsulation.

		Host: In this document, generically refers to any user or CE
		endpoint attached to an EVPN-IRB network, which may be a VM,
		containerized workload, physical endpoint, or CE device.

		ES: Ethernet Segment. A physical ethernet or LAG port that connects
		an access device to an EVPN PE, as defined in [RFC7432].

		e.) Route Type 5 does not appear to be mentioned in RFC 7432; however, it is
		defined in RFC 9136. May we update the citation in this list entry to RFC 9136
		and add an Informative Reference entry for it?

		Original:

		* RT-5: EVPN route type 5 carrying IP prefix reachability as
		specified in [RFC7432].

		Perhaps:

		RT-5: Route Type 5. Refers to the EVPN RT-5 carrying IP prefix
		reachability as specified in [RFC9136].

		f.) For consistency with RFC 8926 and to reflect a 1:1 relationship between
		abbreviation and expansion, we have separated this list item into two separate
		items:

		Original:

		* NVO3: Network Virtualization Overlays as specified in [RFC8926].

		Current:

		NVO: Network Virtualization Overlay.

		NVO3: Network Virtualization over Layer 3 (as specified in
		[RFC8926]).

		g.) FYI - We plan to add the following abbreviations in the terminology
		section, as they appear within other definitions in this list. Please let
		us know of any objections.

		CE: Customer Edge.
		PE: Provider Edge.
		LAG: Link Aggregation Group.
		L2: Layer 2.
		L3: Layer 3.
		ToR: Top-of-Rack.
		-->

		<dl spacing="normal" newline="false">

		<dt>EVPN-IRB:</dt><dd>Ethernet VPN Integrated Routing and Bridging.
		A BGP-EVPN distributed control plane that is based on the
		integrated routing and bridging fabric overlay discussed in <xref
		target="RFC9135"/>.</dd>

		<dt>Underlay:</dt><dd>An IP, MPLS, or SRv6 fabric core network that
		provides routed reachability between EVPN PEs.</dd>

		<dt>Overlay:</dt><dd>L2 and L3 VPNs that are enabled
		via NVO3, VXLAN, SRv6, or MPLS service-layer encapsulation.</dd>

		<dt>SRv6:</dt><dd>Segment Routing over IPv6 (as specified in <xref targ
		et="RFC8986"/>).</dd>

		<dt>NVO:</dt><dd>Network Virtualization Overlay.</dd>

		<dt>NVO3:</dt><dd>Network Virtualization over Layer 3 (as specified in
		<xref
		target="RFC8926"/>).</dd>

		<dt>VXLAN:</dt><dd>Virtual eXtensible Local Area Network (as specified
		in <xref target="RFC7348"/>).</dd>

		<dt>MPLS:</dt><dd>Multiprotocol Label Switching (as specified in <xref
		target="RFC3031"/>).</dd>

		<dt>EVPN PE:</dt><dd>Ethernet VPN Provider Edge. A PE
		switch router in an EVPN-IRB network that runs overlay BGP-EVPN
		control planes and connects to overlay CE host devices. An EVPN PE
		may also be the first-hop L3 gateway for CE host devices. This
		document refers to EVPN PE as a logical function in an EVPN-IRB
		network. This EVPN PE function may be physically hosted on a ToR
		switching device or at layer(s) above the ToR in the Clos fabric. An
		EVPN PE is typically also an IP or MPLS tunnel endpoint for overlay
		VPN flows.</dd>

		<dt>Symmetric EVPN-IRB:</dt><dd>A specific design approach used in
		EVPN-based networks <xref target="RFC9135"/> to handle both L2 and L3
		forwarding within the same network infrastructure. The key
		characteristic of symmetric EVPN-IRB is that both ingress and egress
		PE routers perform routing for inter-subnet traffic.</dd>

		<dt>Asymmetric EVPN-IRB:</dt><dd>A design approach used in EVPN-based
		networks <xref target="RFC9135"/> to handle L2 and L3 forwarding. In
		this approach, only the ingress PE router performs routing for
		inter-subnet traffic, while the egress PE router performs
		bridging.</dd>

		<dt>ARP:</dt><dd>Address Resolution Protocol <xref
		target="RFC0826"/>. ARP references in this document are equally
		applicable to both ARP and NDP.</dd>

		<dt>NDP:</dt><dd>Neighbor Discovery Protocol (for IPv6 <xref target="RF
		C4861"/>).</dd>

		<dt>ES:</dt><dd>Ethernet Segment. A physical ethernet or LAG port that
		connects an access device to an EVPN PE, as defined in <xref
		target="RFC7432"/>.</dd>

		<dt>MC-LAG:</dt><dd>Multi-Chassis Link Aggregation Group.</dd>

		<dt>EVPN all-active multi-homing:</dt><dd>A redundancy and
		load-sharing mechanism used in EVPN networks. This method allows
		multiple PE devices to simultaneously provide L2 and L3
		connectivity to a single CE device or network segment.</dd>

		<dt>RT-2:</dt><dd>Route Type 2. EVPN RT-2 carrying both MAC address and
		IP
		address reachability as specified in <xref target="RFC7432"/>.</dd>

		<dt>RT-5:</dt><dd>Route Type 5. EVPN RT-5 carrying IP
		prefix reachability as specified in <xref target="RFC7432"/>.</dd>

		<dt>MAC-IP address:</dt><dd>The IPv4 and/or IPv6 address
		and MAC address binding for an overlay host.</dd>

		<dt>Peer-Sync-Local MAC route:</dt><dd>The learned BGP EVPN MAC route f
		or
		a host that is directly attached to a local multi-homed ES.</dd>

		<dt>Peer-Sync-Local MAC-IP route:</dt><dd>The learned BGP
		EVPN MAC-IP route for a host that is directly attached to a local
		multi-homed ES.</dd>

		<dt>Peer-Sync-Local MAC sequence number:</dt><dd>The sequence number
		received with a Peer-Sync-Local MAC route.</dd>

		<dt>Peer-Sync-Local MAC-IP sequence number:</dt><dd>The sequence number
		received with a Peer-Sync-Local MAC-IP route.</dd>

		<dt>VM:</dt><dd>Virtual Machine (or containerized workloads).</dd>

		<dt>Host:</dt><dd>In this document, generically refers to any
		user or CE endpoint attached to an EVPN-IRB network, which may be a VM,
		containerized workload, physical endpoint, or CE device.</dd>
		</dl>
		</section>

		<section anchor="Background-Problem-Statement" numbered="true" toc="default"
		>
		<name>Background and Problem Statement</name>
		<section anchor="Optional-MAC-RT-2" numbered="true" toc="default">
		<name>Optional MAC-Only RT-2</name>

		<t>In an EVPN-IRB scenario where a single MAC+IP RT-2 advertisement
		carries both IP and MAC routes, a MAC-only RT-2 advertisement becomes
		redundant for host MAC addresses already advertised via
		MAC+IP RT-2. Consequently, the advertisement of a local MAC-only RT-2
		is optional at an EVPN PE. This consideration is important for
		mobility scenarios discussed in subsequent sections. It is noteworthy
		that a local MAC route and its assigned sequence number are still
		maintained locally on a PE, and only the advertisement of this route
		to other PEs is optional.</t>

		<t>MAC-only RT-2 advertisements may still be issued for non-IP host
		MAC addresses that are not included in MAC+IP RT-2 advertisements.</t>
	</section>	</section>


	<section anchor="Mobility-Use-Cases" title="Mobility Use Cases" numbered="	<section anchor="Mobility-Use-Cases" numbered="true" toc="default">
	true" toc="default">	<name>Mobility Use Cases</name>
	<t>
	This section outlines the IRB mobility use cases addressed in this doc	<t>This section outlines the IRB mobility use cases addressed in this
	ument. Detailed procedures to handle these scenarios are provided in Sections 6	document. Detailed procedures to handle these scenarios are provided
	and 7.	in Sections <xref target="Methods-for-Sequence-Number-Assignment"
	</t> <t>	format="counter"/> and <xref target="Routed-Overlay"
	<list style="symbols"> <t>	format="counter"/>.</t>
	A host move results in both the host's IP and MAC addresses moving t
	ogether.	<!-- [rfced] Section 3.2: May we add the following lead-in text to the list
	</t> <t>	below? The proposed text is from the same list in the Introduction.
	A host move results in the host's IP address moving to a new MAC add
	ress association.	Original:
	</t> <t>
	A host move results in the host's MAC address moving to a new IP add	3.2. Mobility Use Cases
	ress association.
	</t>	This section outlines the IRB mobility use cases addressed in this
	</list>	document. Detailed procedures to handle these scenarios are provided
	</t>	in Sections 6 and 7.
	<section anchor="Host-MAC-IP-Move" title="Host MAC+IP Address Move" numb
	ered="true" toc="default">	* A host move results in both the host's IP and MAC addresses moving
	<t>	together.
	This is the baseline scenario where a host move results in both the
	host's MAC and IP addresses moving together without altering the MAC-IP address	* A host move results in the host's IP address moving to a new MAC
	binding. The existing MAC route mobility procedures defined in [RFC7432] can be	address association.
	leveraged to support this MAC+IP address mobility scenario.
	</t>	* A host move results in the host's MAC address moving to a new IP
		address association.

		Perhaps:

		3.2. Mobility Use Cases

		This section outlines the IRB mobility use cases addressed in this
		document. Detailed procedures to handle these scenarios are provided in
		Sections 6 and 7. The following IRB mobility scenarios are considered:

		...

		-->

		<ul spacing="normal">
		<li>A host move results in both the host's IP and MAC addresses
		moving together.</li>
		<li>A host move results in the host's IP address moving to a new MAC
		address association.</li>
		<li>A host move results in the host's MAC address moving to a new IP
		address association.</li>
		</ul>

		<section anchor="Host-MAC-IP-Move" numbered="true" toc="default">
		<name>Host MAC+IP Address Move</name>

		<t>This is the baseline scenario where a host move results in both
		the host's MAC and IP addresses moving together without altering the
		MAC-IP address binding. The existing MAC route mobility procedures
		defined in <xref target="RFC7432"/> can be leveraged to support this
		MAC+IP address mobility scenario.</t>
	</section>	</section>

	<section anchor="Host-IP-Move-to-new-MAC" title="Host IP address Move to
	new MAC address" numbered="true" toc="default">	<section anchor="Host-IP-Move-to-new-MAC" numbered="true" toc="default">
	<t>	<name>Host IP Address Move to New MAC Address</name>
	This scenario involves a host move where the host's IP address is re
	assigned to a new MAC address.	<t>This scenario involves a host move where the host's IP address is
	</t>	reassigned to a new MAC address.</t>
	<section anchor="Host-Reload" title="Host Reload" numbered="true" toc=
	"default">	<section anchor="Host-Reload" numbered="true" toc="default">
	<t>	<name>Host Reload</name>
	A host reload or orchestrated move may cause a host to be re-spawn
	ed at the same or new PE location, resulting in a new MAC address assignment whi	<t>A host reload or orchestrated move may cause a host to be
	le retaining the existing IP address. This results in the host's IP address movi	re-spawned at the same or new PE location, resulting in a new MAC
	ng to a new MAC address binding, as shown below:	address assignment while retaining the existing IP address. This
	</t>	results in the host's IP address moving to a new MAC address
	<t>	binding, as shown below:</t>
	IP-a, MAC-a ---> IP-a, MAC-b
	</t>	<artwork>
		IP-a, MAC-a ---> IP-a, MAC-b
		</artwork>
	</section>	</section>

	<section anchor="MAC-Sharing" title="MAC Address Sharing" numbered="tr
	ue" toc="default">	<section anchor="MAC-Sharing" numbered="true" toc="default">
	<t>	<name>MAC Address Sharing</name>
	This scenario considers cases where multiple hosts, each with a un
	ique IP address, share a common MAC address. A host move results in a new MAC ad	<t>This scenario considers cases where multiple hosts, each with a
	dress binding for the host IP address. For example, hosts running on a single ph	unique IP address, share a common MAC address. A host move results
	ysical server might share the same MAC address. Alternatively, an L2 access netw	in a new MAC address binding for the host IP address. For example,
	ork behind a firewall may have all host IP addresses learned with a common firew	hosts running on a single physical server might share the same MAC
	all MAC address. In these "shared MAC" scenarios, multiple local MAC-IP ARP/NDP	address. Alternatively, an L2 access network behind a firewall may
	entries may be learned with the same MAC address. A host IP address move to a ne	have all host IP addresses learned with a common firewall MAC
	w physical server could result in a new MAC address association for the host IP.	address. In these "shared MAC" scenarios, multiple local MAC-IP
	</t>	ARP/NDP entries may be learned with the same MAC address. A host
		IP address move to a new physical server could result in a new MAC
		address association for the host IP.</t>
	</section>	</section>

	<section anchor="Problem" title="Problem" numbered="true" toc="default
	">
	<t>
	In the aforementioned scenarios, a combined MAC+IP EVPN RT-2 adver
	tised with a single sequence number attribute assumes a fixed IP-to-MAC address
	mapping. A host IP address move to a new MAC address breaks this assumption and
	results in a new MAC+IP route. If this new route is independently assigned a new
	sequence number, the sequence number can no longer determine the most recent ho
	st IP reachability in a symmetric EVPN-IRB design or the most recent IP-to-MAC a
	ddress binding in an asymmetric EVPN-IRB design.
	</t>
	<figure anchor="problem" title="" suppress-title="false" align="left
	" alt="" width="" height="">
	<artwork xml:space="preserve" name="" type="" align="left" alt=""
	width="" height="">


		<section anchor="Problem" numbered="true" toc="default">
		<name>Problem</name>
		<t>In the aforementioned scenarios, a combined MAC+IP EVPN RT-2
		advertised with a single sequence number attribute assumes a fixed
		IP-to-MAC address mapping. A host IP address move to a new MAC
		address breaks this assumption and results in a new MAC+IP
		route. If this new route is independently assigned a new sequence
		number, the sequence number can no longer determine the most
		recent host IP reachability in a symmetric EVPN-IRB design or the
		most recent IP-to-MAC address binding in an asymmetric EVPN-IRB
		design.</t>
		<figure anchor="problem">
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+------------------------+	+------------------------+
	\| Underlay Network Fabric\|	\| Underlay Network Fabric\|
	+------------------------+	+------------------------+

	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
	\| PE1 \| \| PE2 \| \| PE3 \| \| PE4 \| \| PE5 \| \| PE6 \|	\| PE1 \| \| PE2 \| \| PE3 \| \| PE4 \| \| PE5 \| \| PE6 \|
	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
	\ / \ / \ /	\ / \ / \ /
	\ ESI-1 / \ ESI-2 / \ ESI-3 /	\ ESI-1 / \ ESI-2 / \ ESI-3 /
	\ / \ / \ /	\ / \ / \ /
	+\---/+ +\---/+ +\---/+	+\---/+ +\---/+ +\---/+
	\| \ / \| \| \ / \| \| \ / \|	\| \ / \| \| \ / \| \| \ / \|
	+--+--+ +--+--+ +--+--+	+--+--+ +--+--+ +--+--+
	\| \| \|	\| \| \|
	Server-M1 Server-M2 Server-M3	Server-M1 Server-M2 Server-M3
	\| \| \|	\| \| \|
	VM-IP1, VM-IP2 VM-IP3, VM-IP4 VM-IP5, VM-IP6	VM-IP1, VM-IP2 VM-IP3, VM-IP4 VM-IP5, VM-IP6

		]]></artwork>
	</artwork>
	</figure>	</figure>

	<t>
	Figure 1 illustrates a topology with host VMs sharing the physical	<t><xref target="problem"/> illustrates a topology with host VMs
	server MAC address. In steady state, the IP1-M1 route is learned at PE1 and PE2	sharing the physical server MAC address. In steady state, the
	and advertised to remote PEs with a sequence number N. If VM-IP1 moves to Serve	IP1-M1 route is learned at PE1 and PE2 and advertised to remote
	r-M2, ARP or NDP-based local learning at PE3 and PE4 would result in a new IP1-M	PEs with a sequence number N. If VM-IP1 moves to Server-M2, ARP or
	2 route. If this new route is assigned a sequence number of 0, the mobility proc	NDP-based local learning at PE3 and PE4 would result in a new
	edure for VM-IP1 will not trigger across the overlay network.	IP1-M2 route. If this new route is assigned a sequence number of
	</t>	0, the mobility procedure for VM-IP1 will not trigger across the
	<t>	overlay network.</t>
	A sequence number assignment procedure must be defined to unambigu	<t>A sequence number assignment procedure must be defined to
	ously determine the most recent IP address reachability, IP-to-MAC address bindi	unambiguously determine the most recent IP address reachability,
	ng, and MAC address reachability for such MAC address sharing scenarios.	IP-to-MAC address binding, and MAC address reachability for such
	</t>	MAC address sharing scenarios.</t>
	</section>	</section>


	</section>	</section>

	<section anchor="Host-MAC-move-to-new-IP" title="Host MAC address move t	<section anchor="Host-MAC-move-to-new-IP" numbered="true" toc="default">
	o new IP address" numbered="true" toc="default">	<name>Host MAC Address Move to New IP Address</name>
	<t>
	This is a scenario where a host move or re-provisioning behind the s
	ame or new PE location may result in the host getting a new IP address assigned,
	while keeping the same MAC address.
	</t>
	<section anchor="Problem-2" title="Problem" numbered="true" toc="defau
	lt">
	<t>
	The complication in this scenario arises because MAC address reach
	ability can be carried via a combined MAC+IP route, whereas a MAC-only route may
	not be advertised. Associating a single sequence number with the MAC+IP route i
	mplicitly assumes a fixed MAC-to-IP mapping. A MAC address move that results in
	a new IP address association breaks this assumption and creates a new MAC+IP rou
	te. If this new route independently receives a new sequence number, the sequence
	number can no longer reliably indicate the most recent host MAC address reachab
	ility.
	</t>
	<figure anchor="problem-2" title="" suppress-title="false" align="le
	ft" alt="" width="" height="">
	<artwork xml:space="preserve" name="" type="" align="left" alt=""
	width="" height="">


		<t>This is a scenario where a host move or re-provisioning behind
		the same or new PE location may result in the host getting a new IP
		address assigned while keeping the same MAC address.</t>

		<section anchor="Problem-2" numbered="true" toc="default">
		<name>Problem</name>
		<t>The complication in this scenario arises because MAC address
		reachability can be carried via a combined MAC+IP route, whereas a
		MAC-only route may not be advertised. Associating a single
		sequence number with the MAC+IP route implicitly assumes a fixed
		MAC-to-IP mapping. A MAC address move that results in a new IP
		address association breaks this assumption and creates a new
		MAC+IP route. If this new route independently receives a new
		sequence number, the sequence number can no longer reliably
		indicate the most recent host MAC address reachability.</t>

		<figure anchor="problem-2">
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+------------------------+	+------------------------+
	\| Underlay Network Fabric\|	\| Underlay Network Fabric\|
	+------------------------+	+------------------------+
	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
	\| PE1 \| \| PE2 \| \| PE3 \| \| PE4 \| \| PE5 \| \| PE6 \|	\| PE1 \| \| PE2 \| \| PE3 \| \| PE4 \| \| PE5 \| \| PE6 \|
	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
	\ / \ / \ /	\ / \ / \ /
	\ ESI-1 / \ ESI-2 / \ ESI-3 /	\ ESI-1 / \ ESI-2 / \ ESI-3 /
	\ / \ / \ /	\ / \ / \ /
	+\---/+ +\---/+ +\---/+	+\---/+ +\---/+ +\---/+
	\| \ / \| \| \ / \| \| \ / \|	\| \ / \| \| \ / \| \| \ / \|
	+--+--+ +--+--+ +--+--+	+--+--+ +--+--+ +--+--+
	\| \| \|	\| \| \|
	Server1 Server2 Server3	Server1 Server2 Server3
	\| \| \|	\| \| \|
	IP1-M1, IP2-M2 IP3-M3, IP4-M4 IP5-M5, IP6-M6	IP1-M1, IP2-M2 IP3-M3, IP4-M4 IP5-M5, IP6-M6

		]]></artwork>
	</artwork>
	</figure>	</figure>

	<t>
	For instance, consider host IP1-M1 learned locally at PE1 and PE2	<t>For instance, consider that host IP1-M1 is learned locally at PE1
	and advertised to remote hosts with sequence number N. If this host with MAC add	and
	ress M1 is re-provisioned at Server2 and assigned a different IP address (e.g.,	PE2 and advertised to remote hosts with sequence number N. If this
	IP7), the new IP7-M1 route learned at PE3 and PE4 would be advertised with seque	host with MAC address M1 is re-provisioned at Server2 and assigned
	nce number 0. Consequently, L3 reachability to IP7 would be established across t	a different IP address (e.g., IP7), then the new IP7-M1 route learne
	he overlay, but the MAC mobility procedure for M1 would not trigger due to the n	d
	ew MAC-IP route advertisement. Advertising an optional MAC-only route with its s	at PE3 and PE4 would be advertised with sequence number
	equence number would trigger MAC mobility per [RFC7432]. However, without this a	0. Consequently, L3 reachability to IP7 would be established
	dditional advertisement, a single sequence number associated with a combined MAC	across the overlay, but the MAC mobility procedure for M1 would
	+IP route may be insufficient to update MAC address reachability across the over	not trigger due to the new MAC-IP route advertisement. Advertising
	lay.	an optional MAC-only route with its sequence number would trigger
	</t>	MAC mobility per <xref target="RFC7432"/>. However, without this
	<t>	additional advertisement, a single sequence number associated with
	A MAC-IP route sequence number assignment procedure is required to	a combined MAC+IP route may be insufficient to update MAC address
	unambiguously determine the most recent MAC address reachability in such scenar	reachability across the overlay.</t>
	ios without advertising a MAC-only route.
	</t>	<t>A MAC-IP route sequence number assignment procedure is required
	<t>	to unambiguously determine the most recent MAC address
	Furthermore, PE1 and PE2, upon learning new reachability for IP7-M	reachability in the previous scenarios without advertising a
	1 via PE3 and PE4, must probe and delete any local IPs associated with MAC addre	MAC-only route.</t>
	ss M1, such as IP1-M1.
	</t>	<t>Furthermore, upon learning new reachability for IP7-M1 via PE3
	<t>	and PE4, PE1 and PE2 must probe and delete any local IPs
	It could be argued that the MAC mobility sequence number defined i	associated with the MAC address M1, such as IP1-M1.</t>
	n [RFC7432] applies only to the MAC route part of a MAC-IP route, thus covering
	this scenario. This interpretation could serve as a clarification to [RFC7432] a	<t>It could be argued that the MAC mobility sequence number
	nd supports the need for a common sequence number assignment procedure across al	defined in <xref target="RFC7432"/> applies only to the MAC route
	l MAC-IP mobility scenarios detailed in this document.	part of a MAC-IP route, thus covering this scenario. This
	</t>	interpretation could serve as a clarification to <xref
		target="RFC7432"/> and supports the need for a common sequence
		number assignment procedure across all MAC-IP mobility scenarios
		detailed in this document.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="EVPN-All-Active-multi-homed-ES" title="EVPN All Active mu
	lti-homed ES" numbered="true" toc="default">	<section anchor="EVPN-All-Active-multi-homed-ES" numbered="true" toc="defa
	<figure anchor="pece_link_failure" title="" suppress-title="false" align	ult">
	="left" alt="" width="" height="">	<name>EVPN All Active Multi-Homed ES</name>
	<artwork xml:space="preserve" name="" type="" align="left" alt="" widt	<figure anchor="pece_link_failure">
	h="" height="">	<artwork name="" type="" align="left" alt=""><![CDATA[
	+------------------------+	+------------------------+
	\| Underlay Network Fabric\|	\| Underlay Network Fabric\|
	+------------------------+	+------------------------+

	+-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+
	\| PE1 \| \| PE2 \| \| PE3 \| \| PE4 \|	\| PE1 \| \| PE2 \| \| PE3 \| \| PE4 \|
	+-----+ +-----+ +-----+ +-----+	+-----+ +-----+ +-----+ +-----+
	\\ // \\ //	\\ // \\ //
	\\ ESI-1 // \\ ESI-2 //	\\ ESI-1 // \\ ESI-2 //
	\\ // \\ //	\\ // \\ //
	+\\---//+ +\\---//+	+\\---//+ +\\---//+
	\| \\ // \| \| \\ // \|	\| \\ // \| \| \\ // \|
	+---+---+ +---+---+	+---+---+ +---+---+
	\| \|	\| \|
	CEs CEs	CEs CEs

	</artwork>	]]></artwork>
	</figure>	</figure>

	<t>	<t>Consider an EVPN-IRB overlay network illustrated in <xref
	Consider an EVPN-IRB overlay network illustrated in Figure 3, where ho	target="pece_link_failure"/>, where hosts are multi-homed to two or
	sts are multi-homed to two or more PE devices via an all-active multi-homed ES.	more PE devices via an all-active multi-homed ES.
	MAC and ARP/NDP entries learned on a local ES may also be synchronized across th	MAC and ARP/NDP entries learned on a local ES may also be
	e multi-homing PE devices sharing this ES. This synchronization enables local sw	synchronized across the multi-homing PE devices sharing this ES. This
	itching of intra- and inter-subnet ECMP traffic flows from remote hosts. Thus, l	synchronization enables local switching of intra- and inter-subnet
	ocal MAC and ARP/NDP entries on a given ES may be learned through local learning	ECMP traffic flows from remote hosts. Thus, local MAC and ARP/NDP
	and/or synchronization from another PE device sharing the same ES.	entries on a given ES may be learned through local learning and/or
	</t>	synchronization from another PE device sharing the same ES.</t>
	<t>
	For a host that is multi-homed to multiple PE devices via an all-activ	<t>For a host that is multi-homed to multiple PE devices via an
	e ES interface, the local learning of host MAC and MAC-IP routes at each PE devi	all-active ES interface, the local learning of the host MAC and MAC-IP
	ce is an independent asynchronous event, dependent on traffic flow or ARP/NDP re	routes at each PE device is an independent asynchronous event,
	sponse from the host hashing to a directly connected PE on the MC-LAG interface.	dependent on traffic flow or an ARP/NDP response from the host hashing t
	Consequently, the sequence number mobility attribute value assigned to a locall	o
	y learned MAC or MAC-IP route at each device may not always be the same, dependi	a directly connected PE on the MC-LAG interface. Consequently, the
	ng on transient states on the device at the time of local learning.	sequence number mobility attribute value assigned to a locally learned
	</t>	MAC or MAC-IP route at each device may not always be the same,
	<t>	depending on transient states on the device at the time of local
	For example, consider a host that is deleted from ESI-2 and moved to E	learning.</t>
	SI-1. It is possible for the host to be learned on PE1 following the deletion of
	the remote route from PE3 and PE4, while being learned on PE2 prior to the dele	<t>For example, consider a host that is deleted from ESI-2 and moved
	tion of the remote route from PE3 and PE4. In this case, PE1 would process local	to ESI-1. It is possible for the host to be learned on PE1 following
	host route learning as a new route and assign a sequence number of 0, while PE2	the deletion of the remote route from PE3 and PE4 while being learned
	would process local host route learning as a remote-to-local move and assign a	on PE2 prior to the deletion of the remote route from PE3 and PE4. In
	sequence number of N+1, where N is the existing sequence number assigned at PE3	this case, PE1 would process local host route learning as a new route
	and PE4.	and assign a sequence number of 0, while PE2 would process local host
	</t>	route learning as a remote-to-local move and assign a sequence number
	<t>	of N+1, where N is the existing sequence number assigned at PE3 and
	Inconsistent sequence numbers advertised from multi-homing devices:	PE4.</t>
	<list style="symbols"> <t>
	Creates ambiguity regarding how remote PEs should handle paths wit	<t>Inconsistent sequence numbers advertised from multi-homing devices:</
	h the same ESI but different sequence numbers. A remote PE might not program ECM	t>
	P paths if it receives routes with different sequence numbers from a set of mult
	i-homing PEs sharing the same ESI.	<ul spacing="normal">
	</t> <t>	<li>
	Breaks consistent route versioning across the network overlay that	<t>Create ambiguity regarding how remote PEs should handle paths
	is needed for EVPN mobility procedures to work.	with the same ESI but different sequence numbers. A remote PE
	</t>	might not program ECMP paths if it receives routes with different
	</list>	sequence numbers from a set of multi-homing PEs sharing the same
	</t>	ESI.</t>
	<t>	</li>
	For instance, in this inconsistent state, PE2 would drop a remote rout	<li>
	e received for the same host with sequence number N (since its local sequence nu	<t>Break consistent route versioning across the network overlay
	mber is N+1), while PE1 would install it as the best route (since its local sequ	that is needed for EVPN mobility procedures to work.</t>
	ence number is 0).	</li>
	</t>	</ul>
	<t>
	To support mobility for multi-homed hosts using the sequence number mo	<t>For instance, in this inconsistent state, PE2 would drop a remote
	bility attribute, local MAC and MAC-IP routes learned on a multi-homed ES must b	route received for the same host with sequence number N (since its
	e advertised with the same sequence number by all PE devices to which the ES is	local sequence number is N+1), while PE1 would install it as the best
	multi-homed. There is a need for a mechanism to ensure the consistency of sequen	route (since its local sequence number is 0).</t>
	ce numbers assigned across these PEs.
	</t>	<t>To support mobility for multi-homed hosts using the sequence number
		mobility attribute, local MAC and MAC-IP routes learned on a
		multi-homed ES must be advertised with the same sequence number by all
		PE devices to which the ES is multi-homed. There is a need for a
		mechanism to ensure the consistency of sequence numbers assigned
		across these PEs.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="Design-Considerations" title="Design Considerations" numb
	ered="true" toc="default">	<section anchor="Design-Considerations" numbered="true" toc="default">
	<t>	<name>Design Considerations</name>
	To summarize, the sequence number assignment scheme and implementation	<t>To summarize, the sequence number assignment scheme and
	must consider the following:	implementation must consider the following:</t>
	<list style="symbols"> <t>	<ul spacing="normal">
	Synchronization Across Multi-Homing PE Devices: MAC+IP routes may	<li>
	be learned on an ES multi-homed to multiple PE devices, requiring synchronized s	<t>Synchronization across multi-homing PE devices:</t>
	equence numbers across these devices.	<t>MAC+IP routes may be learned on an ES that is multi-homed to
	</t> <t>	multiple PE devices, requiring synchronized sequence numbers across
	Optional MAC-Only RT-2: In an IRB scenario, MAC-only RT-2 is optio	these devices.</t>
	nal and may not be advertised alongside MAC+IP RT-2.	</li>
	</t> <t>	<li>
	Multiple IPs Associated with a Single MAC: A single MAC address ma	<t>Optional MAC-only RT-2:</t>
	y be linked to multiple IP addresses, indicating multiple host IPs sharing a com	<t>In an IRB scenario, MAC-only RT-2 is
	mon MAC address.	optional and may not be advertised alongside MAC+IP RT-2.</t>
	</t> <t>	</li>
	Host IP Movement: A host IP address move may result in a new MAC a	<li>
	ddress association, necessitating a new IP address to MAC address association an	<t>Multiple IPs associated with a single MAC:</t>
	d a new MAC+IP route.	<t>A single MAC address may be linked to multiple IP addresses,
	</t> <t>	indicating multiple host IPs sharing a common MAC address.</t>
	Host MAC Address Movement: A host MAC address move may result in a	</li>
	new IP address association, requiring a new MAC to IP address association and a	<li>
	new MAC+IP route.	<t>Host IP movement:</t>
	</t> <t>	<t>A host IP address move may result in a new MAC
	Local MAC-IP Route Learning via ARP/NDP: Local MAC-IP route learni	address association, necessitating a new IP address to MAC address
	ng via ARP/NDP always accompanies a local MAC route learning event resulting fro	association and a new MAC+IP route.</t>
	m the ARP/NDP packet. However, MAC and MAC-IP route learning can occur in any or	</li>
	der.	<li>
	</t> <t>	<t>Host MAC address movement:</t>
	Separate Sequence Numbers for MAC and IP routes: Use cases that do	<t>A host MAC address move may result in a new IP address
	not maintain a constant 1:1 MAC-IP address mapping across moves could potential	association, requiring a new MAC address to IP address association and
	ly be addressed by using separate sequence numbers for MAC and IP route componen	a new
	ts of the MAC+IP route. However, maintaining two separate sequence numbers adds	MAC+IP route.</t>
	significant complexity, debugging challenges, and backward compatibility issues.	</li>
	Therefore, this document addresses these requirements using a single sequence n	<li>
	umber attribute.	<t>Local MAC-IP route learning via ARP/NDP:</t>
	</t>	<t>Local MAC-IP route learning via ARP/NDP always accompanies a
	</list>	local MAC route learning event resulting from the ARP/NDP
	</t>	packet. However, MAC and MAC-IP route learning can occur in any
	</section>	order.</t>
	<section anchor="Solution-Components" title="Solution Components" numbered="	</li>
	true" toc="default">	<li>
	<t>	<t>Separate sequence numbers for MAC and IP routes:</t>
	This section outlines the main components of the EVPN-IRB mobility solut	<t>Use cases that do not maintain a constant 1:1 MAC-IP address
	ion specified in this document. Subsequent sections will detail the exact sequen	mapping across moves could potentially be addressed by using
	ce number assignment procedures based on the concepts described here.	separate sequence numbers for MAC and IP route components of the
	</t>	MAC+IP route. However, maintaining two separate sequence numbers
	<section anchor="Sequence-Number-Inheritance" title="Sequence Number Inher	adds significant complexity, debugging challenges, and backward
	itance" numbered="true" toc="default">	compatibility issues. Therefore, this document addresses these
	<t>	requirements using a single sequence number attribute.</t>
	The key concept presented here is to treat a local MAC-IP route as a c	</li>
	hild of the corresponding local MAC route within the local context of a PE. This	</ul>
	ensures that the local MAC-IP route inherits the sequence number attribute from	</section>
	the parent local MAC-only route. In terms of object dependencies, this could be
	represented as MAC-IP route being a dependent child of the parent MAC route:	<section anchor="Solution-Components" numbered="true" toc="default">
	</t>	<name>Solution Components</name>
	<t>
	Mx-IPx -----> Mx (seq# = N)	<t>This section outlines the main components of the EVPN-IRB mobility
	</t>	solution specified in this document. Subsequent sections will detail the
	<t>	exact sequence number assignment procedures based on the concepts
	Thus, both the parent MAC route and child MAC-IP routes share a common	described here.</t>
	sequence number associated with the parent MAC route. This ensures that a singl
	e sequence number attribute carried in a combined MAC+IP route represents the se	<section anchor="Sequence-Number-Inheritance" numbered="true" toc="default
	quence number for both a MAC-only route and a MAC+IP route, making the advertise	">
	ment of the MAC-only route truly optional. This enables a MAC address to assume	<name>Sequence Number Inheritance</name>
	a different IP address upon moving and still establish the most recent reachabil
	ity to the MAC address across the overlay network via the mobility attribute ass	<t>The key concept presented here is to treat a local MAC-IP route as
	ociated with the MAC+IP route advertisement. For instance, when Mx moves to a ne	a child of the corresponding local MAC route within the local context
	w location, it would be assigned a higher sequence number at its new location pe	of a PE. This ensures that the local MAC-IP route inherits the
	r [RFC7432]. If this move results in Mx assuming a different IP address, IPz, th	sequence number attribute from the parent local MAC-only route. In
	e local Mx+IPz route would inherit the new sequence number from Mx.	terms of object dependencies, this could be represented as the MAC-IP
	</t>	route being a dependent child of the parent MAC route:</t>
	<t>
	Local MAC and local MAC-IP routes are typically sourced from data plan	<artwork name="" type="" align="left" alt=""><![CDATA[
	e learning and ARP/NDP learning, respectively, and can be learned in the control	Mx-IPx -----> Mx (seq# = N)
	plane in any order. Implementation can either replicate the inherited sequence	]]></artwork>
	number in each MAC-IP entry or maintain a single attribute in the parent MAC rou
	te by creating a forward reference local MAC object for cases where a local MAC-	<t>Thus, both the parent MAC route and the child MAC-IP routes share a
	IP route is learned before the local MAC route.	common sequence number associated with the parent MAC route. This
		ensures that a single sequence number attribute carried in a combined
		MAC+IP route represents the sequence number for both a MAC-only route
		and a MAC+IP route, making the advertisement of the MAC-only route
		truly optional. This enables a MAC address to assume a different IP
		address upon moving and still establish the most recent reachability to
		the MAC address across the overlay network via the mobility attribute
		associated with the MAC+IP route advertisement. For instance, when Mx
		moves to a new location, it would be assigned a higher sequence number
		at its new location per <xref target="RFC7432"/>. If this move results
		in Mx assuming a different IP address, IPz, the local Mx+IPz route
		would inherit the new sequence number from Mx.</t>

		<t>Local MAC and local MAC-IP routes are typically sourced from data
		plane learning and ARP/NDP learning, respectively, and can be learned
		in the control plane in any order. Implementations can either replicate
		the inherited sequence number in each MAC-IP entry or maintain a
		single attribute in the parent MAC route by creating a forward
		reference local MAC object for cases where a local MAC-IP route is
		learned before the local MAC route.
	</t>	</t>
	</section>	</section>

	<section anchor="MAC-Sharing-2" title="MAC Address Sharing" numbered="true
	" toc="default">
	<t>
	For the shared MAC address scenario, multiple local MAC-IP sibling rou
	tes inherit the sequence number attribute from the common parent MAC route:
	<figure anchor="mac_sharing" title="" suppress-title="false" align="left
	" alt="" width="" height="">
	<artwork xml:space="preserve" name="" type="" align="left" alt="" widt
	h="" height="">


		<section anchor="MAC-Sharing-2" numbered="true" toc="default">
		<name>MAC Address Sharing</name>

		<t>For the shared MAC address scenario, multiple local MAC-IP sibling
		routes inherit the sequence number attribute from the common parent
		MAC route:</t>

		<figure anchor="mac_sharing">
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Mx-IP1 -----	Mx-IP1 -----
	\| \|	\| \|
	Mx-IP2 -----	Mx-IP2 -----
	. \|	. \|
	. +---> Mx (seq# = N)	. +---> Mx (seq# = N)
	. \|	. \|
	Mx-IPw -----	Mx-IPw -----
	\| \|	\| \|
	Mx-IPx -----	Mx-IPx -----

	</artwork>	]]></artwork>
	</figure>	</figure>

	</t> <t>
	In such cases, a host-IP move to a different physical server results i	<!-- [rfced] We have clarified "higher than N and the previous Mz sequence
	n the IP moving to a new MAC address binding. A new MAC-IP route resulting from	number M" as follows. Please review and let us know if this update has
	this move must be advertised with a sequence number higher than the previous MAC	altered the intended meaning.
	-IP route for this IP, advertised from the prior location. For example, consider
	a route Mx-IPx currently advertised with sequence number N from PE1. If IPx mov	Original:
	es to a new physical server behind PE2 and is associated with MAC Mz, the new lo
	cal Mz-IPx route must be advertised with a sequence number higher than N and the	If IPx moves to a new physical server behind PE2 and is associated with MAC
	previous Mz sequence number M. This allows PE devices, including PE1, PE2, and	Mz, the new local Mz-IPx route must be advertised with a sequence number
	other remote PE devices, to determine and program the most recent MAC address bi	higher than N and the previous Mz sequence number M.
	nding and reachability for the IP. PE1, upon receiving this new Mz-IPx route wit
	h sequence number N+1 or M+1 (whichever is greater), would update IPx reachabili	Current:
	ty via PE2 for symmetric IRB and update IPx's ARP/NDP binding to Mz for asymmetr
	ic IRB, while clearing and withdrawing the stale Mx-IPx route with the lower seq	If IPx moves to a new physical server behind PE2 and is associated with MAC
	uence number.	Mz, the new local Mz-IPx route must be advertised with a sequence number
	</t> <t>	higher than N and higher than the previous Mz sequence number M.
	This implies that the sequence number associated with local MAC route
	Mz and all local MAC-IP child routes of Mz at PE2 must be incremented to N+1 or	-->
	M+1 if the previous Mz sequence number M is greater than N and re-advertised acr
	oss the overlay. While this re-advertisement of all local MAC-IP children routes	<t>In such cases, a host-IP move to a different physical server
	affected by the parent MAC route adds overhead, it avoids the need for maintain	results in the IP moving to a new MAC address binding. A new MAC-IP
	ing and advertising two separate sequence number attributes for IP and MAC route	route resulting from this move must be advertised with a sequence
	components of MAC+IP RT-2. Implementation must be able to look up MAC-IP routes	number higher than the previous MAC-IP route for this IP, advertised
	for a given IP and update the sequence number for its parent MAC route and its	from the prior location. For example, consider a route Mx-IPx
	MAC-IP route children.	currently advertised with sequence number N from PE1. If IPx moves to
	</t>	a new physical server behind PE2 and is associated with MAC Mz, the
		new local Mz-IPx route must be advertised with a sequence number
		higher than N and higher than the previous Mz sequence number M. This al
		lows PE
		devices, including PE1, PE2, and other remote PE devices, to determine
		and program the most recent MAC address binding and reachability for
		the IP. PE1, upon receiving this new Mz-IPx route with sequence number
		N+1 or M+1 (whichever is greater), would update IPx reachability via
		PE2 for symmetric IRB and update IPx's ARP/NDP binding to Mz for
		asymmetric IRB while clearing and withdrawing the stale Mx-IPx route
		with the lower sequence number.</t>

		<t>This implies that the sequence number associated with the local MAC
		route Mz and all local MAC-IP child routes of Mz at PE2 must be
		incremented to N+1 or M+1 if the previous Mz sequence number M is
		greater than N and is re-advertised across the overlay. While this
		re-advertisement of all local MAC-IP children routes affected by the
		parent MAC route adds overhead, it also avoids the need for
		maintaining and advertising two separate sequence number attributes
		for IP and MAC route components of MAC+IP RT-2. Implementations must
		be able to look up MAC-IP routes for a given IP and update the
		sequence number for its parent MAC route and for its MAC-IP route
		children.</t>
	</section>	</section>

	<section anchor="Sequence-Number-Synchronization" title="Sequence Number S
	ynchronization" numbered="true" toc="default">	<section anchor="Sequence-Number-Synchronization" numbered="true" toc="def
	<t>	ault">
	To support mobility for multi-homed hosts, local MAC and MAC-IP routes	<name>Sequence Number Synchronization</name>
	learned on a shared ES must be advertised with the same sequence number by all	<t>To support mobility for multi-homed hosts, local MAC and MAC-IP
	PE devices to which the ES is multi-homed. This applies to local MAC-only routes	routes learned on a shared ES must be advertised with the same
	as well. MAC and MAC-IP routes for a host that is attached to a local ES may be	sequence number by all PE devices to which the ES is multi-homed. This
	learned natively via data plane and ARP/NDP respectively, as well as via BGP EV	applies to local MAC-only routes as well. MAC and MAC-IP routes for a
	PN from another multi-homing PE to achieve local switching. MAC and MAC-IP route	host that is attached to a local ES may be learned natively via data
	s learnt natively via data plane and ARP/NDP are respectively referred to as Loc	plane and ARP/NDP, respectively, as well as via BGP EVPN from another
	al MAC routes and Local MAC-IP routes. BGP EVPN learnt MAC and MAC-IP routes for	multi-homing PE to achieve local switching. MAC and MAC-IP routes
	a host that is attached to a local ES are respectively referred to as Peer-Sync	learned natively via data plane and ARP/NDP are respectively referred
	-Local MAC routes and Peer-Sync-Local MAC-IP routes as they are effectively loca	to as local MAC routes and local MAC-IP routes. BGP EVPN learned MAC
	l routes synchronized from a multi-homing peer. Local and Peer-Sync-Local route	and MAC-IP routes for a host that is attached to a local ES are
	learning can occur in any order. Local MAC-IP routes advertised by all multi-hom	respectively referred to as Peer-Sync-Local MAC routes and
	ing PE devices sharing the ES must carry the same sequence number, independent o	Peer-Sync-Local MAC-IP routes as they are effectively local routes
	f the order in which they are learned. This implies:	synchronized from a multi-homing peer. Local and Peer-Sync-Local route
	<list style="symbols"> <t>	learning can occur in any order. Local MAC-IP routes advertised by all
	On local or Peer-Sync-Local MAC-IP route learning, the sequence nu	multi-homing PE devices sharing the ES must carry the same sequence
	mber for the local MAC-IP route must be compared and updated to the higher value	number, independent of the order in which they are learned. This
	.	implies that:</t>
	</t> <t>
	On local or Peer-Sync-Local MAC route learning, the sequence numbe	<ul spacing="normal">
	r for the local MAC route must be compared and updated to the higher value.	<li>
	</t>	<t>On local or Peer-Sync-Local MAC-IP route learning, the sequence
	</list>	number for the local MAC-IP route must be compared and updated to
	</t> <t>	the higher value.</t>
	If an update to the local MAC-IP route sequence number is required as	</li>
	a result of the comparison with the Peer-Sync-Local MAC-IP route, it essentially	<li>
	amounts to a sequence number update on the parent local MAC route, resulting in	<t>On local or Peer-Sync-Local MAC route learning, the sequence
	an inherited sequence number update on the Local MAC-IP route.	number for the local MAC route must be compared and updated to the
	</t>	higher value.</t>
		</li>
		</ul>

		<t>If an update to the local MAC-IP route sequence number is required
		as a result of the comparison with the Peer-Sync-Local MAC-IP route,
		it essentially amounts to a sequence number update on the parent local
		MAC route, resulting in an inherited sequence number update on the
		local MAC-IP route.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="Methods-for-Sequence-Number-Assignment" title="Methods for
	Sequence Number Assignment" numbered="true" toc="default">	<!-- [rfced] May we clarify "local and Peer-Sync-Local MAC and MAC-IP
	<t>	route" as follows?
	The following sections specify the sequence number assignment procedures
	required for local and Peer-Sync-Local MAC and MAC-IP route learning events to	Original:
	achieve the objectives outlined.
	</t>	The following sections specify the sequence number assignment
	<section anchor="Local-MAC-IP-learning" title="Local MAC-IP learning" numb	procedures required for local and Peer-Sync-Local MAC and MAC-IP
	ered="true" toc="default">	route learning events to achieve the objectives outlined.
	<t>
	A local Mx-IPx learning via ARP or NDP should result in the computatio	Perhaps:
	n or re-computation of the parent MAC route Mx's sequence number, following whic
	h the MAC-IP route Mx-IPx inherits the parent MAC route's sequence number. The p	The following sections specify the sequence number assignment
	arent MAC route Mx sequence number MUST be computed as follows:	procedures required for local MAC, local MAC-IP, Peer-Sync-Local MAC,
	<list style="symbols"> <t>	and Peer-Sync-Local MAC-IP route learning events to achieve the
	MUST be higher than any existing remote MAC route for Mx, as per [	outlined objectives.
	RFC7432].
	</t> <t>	-->
	MUST be at least equal to the corresponding Peer-Sync-Local MAC ro
	ute sequence number, if present.	<section anchor="Methods-for-Sequence-Number-Assignment" numbered="true" toc
	</t> <t>	="default">
	If the IP is also associated with a different remote MAC "Mz," it	<name>Methods for Sequence Number Assignment</name>
	MUST be higher than the "Mz" sequence number.
	</t>	<t>The following sections specify the sequence number assignment
	</list>	procedures required for local and Peer-Sync-Local MAC and MAC-IP route
	</t> <t>	learning events to achieve the outlined objectives.</t>
	Once the new sequence number for MAC route Mx is computed as per the a
	bove criteria, all local MAC-IP routes associated with MAC Mx MUST inherit the u	<section anchor="Local-MAC-IP-learning" numbered="true" toc="default">
	pdated sequence number.	<name>Local MAC-IP Learning</name>
	</t>
		<!-- [rfced] To improve readability, may we split the sentence below
		into two sentences? Please review and let us know if this changes the
		intended meaning.

		Original:

		A local Mx-IPx learning via ARP or NDP should result in the
		computation or re-computation of the parent MAC route Mx's sequence
		number, following which the MAC-IP route Mx-IPx inherits the parent
		MAC route's sequence number.

		Perhaps:

		A local Mx-IPx learning via ARP or NDP should result in the
		computation or re-computation of the parent MAC route Mx's sequence
		number. After this, the MAC-IP route Mx-IPx inherits the parent
		MAC route's sequence number.

		-->

		<t>A local Mx-IPx learning via ARP or NDP should result in the
		computation or re-computation of the parent MAC route Mx's sequence
		number, following which the MAC-IP route Mx-IPx inherits the parent
		MAC route's sequence number. The parent MAC route Mx sequence number
		<bcp14>MUST</bcp14> be computed as follows:</t>

		<ul spacing="normal">
		<li>It <bcp14>MUST</bcp14> be higher than any existing remote MAC rout
		e
		for Mx, as per <xref target="RFC7432"/>.</li>
		<li>It <bcp14>MUST</bcp14> be at least equal to the corresponding
		Peer-Sync-Local MAC route sequence number, if present.</li>
		<li>It <bcp14>MUST</bcp14> be higher than the "Mz" sequence number
		if the IP is also associated with a different remote MAC "Mz".</li>
		</ul>

		<t>Once the new sequence number for the MAC route Mx is computed as per
		the above criteria, all local MAC-IP routes associated with MAC Mx
		<bcp14>MUST</bcp14> inherit the updated sequence number.</t>
	</section>	</section>

	<section anchor="Local-MAC-learning" title="Local MAC learning" numbered="
	true" toc="default">	<section anchor="Local-MAC-learning" numbered="true" toc="default">
	<t>	<name>Local MAC Learning</name>
	The local MAC route Mx Sequence number MUST be computed as follows:	<t>The local MAC route Mx sequence number <bcp14>MUST</bcp14> be compute
	<list style="symbols"> <t>	d as follows:</t>
	MUST be higher than any existing remote MAC route for Mx, as per [
	RFC7432].	<ul spacing="normal">
	</t> <t>	<li>It <bcp14>MUST</bcp14> be higher than any existing remote MAC
	MUST be at least equal to the corresponding Peer-Sync-Local MAC ro	route for Mx, as per <xref target="RFC7432"/>.</li>
	ute sequence number if one is present. If the existing local MAC route sequence
	number is less than the Peer-Sync-Local MAC route sequence number, PE MUST updat	<li>
	e the local MAC route sequence number to be equal to the Peer-Sync-Local MAC rou	<t>It <bcp14>MUST</bcp14> be at least equal to the corresponding
	te sequence number. If the existing local MAC route sequence number is equal to	Peer-Sync-Local MAC route sequence number if one is present.</t>
	or greater than the Peer-Sync-Local MAC route sequence number, no update is requ	<t>If the
	ired to the local MAC route sequence number.	existing local MAC route sequence number is less than the
	</t>	Peer-Sync-Local MAC route sequence number, then the PE
	</list>	<bcp14>MUST</bcp14> update the local MAC route sequence number to be
	</t> <t>	equal to the Peer-Sync-Local MAC route sequence number.</t>
	Once the new sequence number for MAC route Mx is computed as per the a	<t>If the
	bove criteria, all local MAC-IP routes associated with MAC route Mx MUST inherit	existing local MAC route sequence number is equal to or greater than
	the updated sequence number. Note that the local MAC route sequence number migh	the Peer-Sync-Local MAC route sequence number, no update is required
	t already be present if there was a local MAC-IP route learned prior to the loca	to the local MAC route sequence number.</t></li>
	l MAC route, in which case the above may not result in any change in the local M	</ul>
	AC route sequence number.
	</t>	<t>Once the new sequence number for the MAC route Mx is computed as per
		the above criteria, all local MAC-IP routes associated with the MAC rout
		e
		Mx <bcp14>MUST</bcp14> inherit the updated sequence number. Note that
		the local MAC route sequence number might already be present if there
		was a local MAC-IP route learned prior to the local MAC route. In
		this case, the above may not result in any change in the local MAC
		route sequence number.</t>
	</section>	</section>

	<section anchor="Remote-MAC-OR-MAC-IP-Update" title="Remote MAC or MAC-IP
	Route Update" numbered="true" toc="default">	<section anchor="Remote-MAC-OR-MAC-IP-Update" numbered="true" toc="default
	<t>	">
	Upon receiving a remote MAC or MAC-IP route update associated with a M	<name>Remote MAC or MAC-IP Route Update</name>
	AC address Mx with a sequence number that is:
	<list style="symbols"> <t>	<t>Upon receiving a remote MAC or MAC-IP route update associated with
	Either higher than the sequence number assigned to a local route f	a MAC address Mx with a sequence number that is either:</t>
	or MAC Mx,
	</t> <t>	<ul spacing="normal">
	Or equal to the sequence number assigned to a local route for MAC	<li>
	Mx, but the remote route is selected as best due to a lower VTEP IP as per [RFC7	<t>higher than the sequence number assigned to a local
	432],	route for MAC Mx or</t>
	</t>	</li>
	</list>	<li>
	the following actions are REQUIRED on the receiving PE:	<t>equal to the sequence number assigned to a local route for MAC
	<list style="symbols"> <t>	Mx, but the remote route is selected as best due to a lower VXLAN
	The PE MUST trigger a probe and deletion procedure for all local M	Tunnel End Point (VTEP) IP as per <xref target="RFC7432"/>,</t>
	AC-IP routes associated with MAC Mx.	</li>
	</t> <t>	</ul>
	The PE MUST trigger a deletion procedure for the local MAC route f
	or Mx.	<t>the following actions are <bcp14>REQUIRED</bcp14> on the receiving
	</t>	PE:</t>
	</list>
	</t>	<ul spacing="normal">
		<li>
		<t>The PE <bcp14>MUST</bcp14> trigger a probe and deletion
		procedure for all local MAC-IP routes associated with MAC Mx.</t>
		</li>
		<li>
		<t>The PE <bcp14>MUST</bcp14> trigger a deletion procedure for the
		local MAC route for Mx.</t>
		</li>
		</ul>
	</section>	</section>

	<section anchor="Peer-Sync-MAC-update" title="Peer-Sync-Local MAC route up
	date" numbered="true" toc="default">	<section anchor="Peer-Sync-MAC-update" numbered="true" toc="default">
	<t>	<name>Peer-Sync-Local MAC Route Update</name>
	Upon receiving a Peer-Sync-Local MAC route, the corresponding local MA
	C route Mx sequence number (if present) should be re-computed as follows:	<t>Upon receiving a Peer-Sync-Local MAC route, the corresponding local
	<list style="symbols"> <t>	MAC route Mx sequence number (if present) should be re-computed as
	If the current sequence number is less than the received Peer-Sync	follows:</t>
	-Local MAC route sequence number, it MUST be increased to be equal to the receiv	<ul spacing="normal">
	ed Peer-Sync-Local MAC route sequence number.	<li>
	</t> <t>	<t>If the current sequence number is less than the received
	If a local MAC route sequence number is updated as a result of the	Peer-Sync-Local MAC route sequence number, it <bcp14>MUST</bcp14>
	above, all local MAC-IP routes associated with MAC route Mx MUST inherit the up	be increased to be equal to the received Peer-Sync-Local MAC route
	dated sequence number.	sequence number.</t>
	</t>	</li>
	</list>	<li>
	</t>	<t>If a local MAC route sequence number is updated as a result of
		the above, all local MAC-IP routes associated with MAC route Mx
		<bcp14>MUST</bcp14> inherit the updated sequence number.</t>
		</li>
		</ul>
	</section>	</section>

	<section anchor="Peer-Sync-MAC-IP-update" title="Peer-Sync-Local MAC-IP ro
	ute update" numbered="true" toc="default">	<section anchor="Peer-Sync-MAC-IP-update" numbered="true" toc="default">
	<t>	<name>Peer-Sync-Local MAC-IP Route Update</name>
	Receiving a Peer-Sync-Local MAC-IP route for a locally attached host r
	esults in a derived Peer-Sync-Local MAC Mx route entry as the MAC-only RT-2 adve	<t>Because the MAC-only RT-2 advertisement is optional, receiving a
	rtisement is optional. The corresponding local MAC Mx route sequence number (if	Peer-Sync-Local MAC-IP route for a locally attached host results in a
	present) should be re-computed as follows:	derived Peer-Sync-Local MAC Mx route entry. The corresponding local MAC
	<list style="symbols"> <t>	Mx route sequence number (if present) should be re-computed as
	If the current sequence number is less than the received Peer-Sync	follows:</t>
	-Local MAC route sequence number, it MUST be increased to be equal to the receiv
	ed Peer-Sync-Local MAC route sequence number.	<ul spacing="normal">
	</t> <t>	<li>
	If a local MAC route sequence number is updated as a result of the	<t>If the current sequence number is less than the received
	above, all local MAC-IP routes associated with MAC route Mx MUST inherit the up	Peer-Sync-Local MAC route sequence number, it <bcp14>MUST</bcp14>
	dated sequence number.	be increased to be equal to the received Peer-Sync-Local MAC route
	</t>	sequence number.</t>
	</list>	</li>
	</t>	<li>
		<t>If a local MAC route sequence number is updated as a result of
		the above, all local MAC-IP routes associated with MAC route Mx
		<bcp14>MUST</bcp14> inherit the updated sequence number.</t>
		</li>
		</ul>
	</section>	</section>

	<section anchor="Inter-Op" title="Interoperability" numbered="true" toc="d
	efault">	<section anchor="Inter-Op" numbered="true" toc="default">
	<t>	<name>Interoperability</name>
	Generally, if all PE nodes in the overlay network follow the above seq
	uence number assignment procedures and the PE is advertising both MAC+IP and MAC	<t>Generally, if all PE nodes in the overlay network follow the above
	routes, the sequence numbers advertised with the MAC and MAC+IP routes with the	sequence number assignment procedures and the PE is advertising both
	same MAC address would always be the same. However, an interoperability scenari	MAC+IP and MAC routes, the sequence numbers advertised with the MAC
	o with a different implementation could arise, where a non-compliant PE implemen	and MAC+IP routes with the same MAC address would always be the
	tation assigns and advertises independent sequence numbers to MAC and MAC+IP rou	same. However, an interoperability scenario with a different
	tes. To handle this case, if different sequence numbers are received for remote	implementation could arise, where a non-compliant PE implementation
	MAC+IP routes and corresponding remote MAC routes from a remote PE, the sequence	assigns and advertises independent sequence numbers to MAC and MAC+IP
	number associated with the remote MAC route MUST be computed and interpreted as	routes. To handle this case, if different sequence numbers are
	:	received for remote MAC+IP routes and corresponding remote MAC routes
	<list style="symbols"> <t>	from a remote PE, the sequence number associated with the remote MAC
	The highest of all received sequence numbers with remote MAC+IP an	route <bcp14>MUST</bcp14> be computed and interpreted as:</t>
	d MAC routes with the same MAC address.
	</t> <t>	<!--[rfced] The following list reads awkwardly. May we rephrase the list
	The MAC route sequence number would be re-computed on a MAC or MAC	items so that they each describe the way a sequence number from the remote
	+IP route withdraw as per the above.	MAC route should be handled?
	</t>
	</list>	Original:
	</t> <t>
	A MAC and/or IP address move to the local PE would then result in the	To handle this case, if different sequence numbers are received for
	MAC (and hence all MAC-IP) route sequence numbers being incremented from the abo	remote MAC+IP routes and corresponding remote MAC routes from a
	ve computed remote MAC route sequence number.	remote PE, the sequence number associated with the remote MAC route
	</t> <t>	MUST be computed and interpreted as:
	If MAC-only routes are not advertised at all, and different sequence n
	umbers are received with multiple MAC+IP routes for a given MAC address, the seq	* The highest of all received sequence numbers with remote MAC+IP
	uence number associated with the derived remote MAC route should still be comput	and MAC routes with the same MAC address.
	ed as the highest of all received MAC+IP route sequence numbers with the same MA
	C address.	* The MAC route sequence number would be re-computed on a MAC or
	</t> <t>	MAC+IP route withdraw as per the above.
	Note that it is not required for a PE to maintain explicit knowledge o
	f a remote PE being compliant or non-compliant with this specification as long a	Perhaps:
	s it implements the above logic to handle remote sequence numbers that are not s
	ynchronized between MAC route and MAC-IP route(s) for the same remote MAC addres	To handle this case, if different sequence numbers are received for
	s.	remote MAC+IP routes and corresponding remote MAC routes from a
	</t>	remote PE, the sequence number associated with the remote MAC route
		MUST be:

		* computed and interpreted as the highest of all received sequence
		numbers with remote MAC+IP and MAC routes with the same MAC address
		and

		* re-computed on a MAC or MAC+IP route withdraw as per the above.
		-->

		<ul spacing="normal">
		<li>
		<t>The highest of all received sequence numbers with remote MAC+IP
		and MAC routes with the same MAC address.</t>
		</li>
		<li>
		<t>The MAC route sequence number would be re-computed on a MAC or
		MAC+IP route withdraw as per the above.</t>
		</li>
		</ul>

		<t>A MAC and/or IP address move to the local PE would then result in
		the MAC (and hence all MAC-IP) route sequence numbers being
		incremented from the above computed remote MAC route sequence
		number.</t>

		<t>If MAC-only routes are not advertised at all, and different
		sequence numbers are received with multiple MAC+IP routes for a given
		MAC address, the sequence number associated with the derived remote
		MAC route should still be computed as the highest of all received
		MAC+IP route sequence numbers with the same MAC address.</t>

		<t>Note that it is not required for a PE to maintain explicit
		knowledge of a remote PE being compliant or non-compliant with this
		specification as long as it implements the above logic to handle
		remote sequence numbers that are not synchronized between MAC route
		and MAC-IP route(s) for the same remote MAC address.</t>

	</section>	</section>

	<section anchor="MAC-Sharing-Race-Condition" title="MAC Address Sharing Ra
	ce Condition" numbered="true" toc="default">	<section anchor="MAC-Sharing-Race-Condition" numbered="true" toc="default"
	<t>	>
	In a MAC address sharing use case described in section 5.2, a race con	<name>MAC Address Sharing Race Condition</name>
	dition is possible with simultaneous host moves between a pair of PEs. Example s	<t>In a MAC address sharing use case described in <xref
	cenario below illustrates this race condition and its remediation:	target="MAC-Sharing-2"/>, a race condition is possible with
	<list style="symbols"> <t>	simultaneous host moves between a pair of PEs. The example scenario belo
	PE1 with locally attached host IPs I1 and I2 that share MAC addres	w
	s M1. PE1 as a result has local MAC-IP routes I1-M1 and I2-M1.	illustrates this race condition and its remediation:</t>
	</t> <t>
	PE2 with locally attached host IPs I3 and I4 that share MAC addres	<ul spacing="normal">
	s M2. PE2 as a result has local MAC-IP routes I3-M2 and I4-M2.	<li>
	</t> <t>	<t>PE1 with locally attached host IPs I1 and I2 that share MAC
	A simultaneous move of I1 from PE1 to PE2 and of I3 from PE2 to PE	address M1. As a result, PE1 has local MAC-IP routes I1-M1 and
	1 will cause I1's MAC address to change from M1 to M2 and cause I3's MAC address	I2-M1.</t>
	to change from M2 to M1.	</li>
	</t> <t>	<li>
	Route I3-M1 may be learnt on PE1 before I1's local entry I1-M1 has	<t>PE2 with locally attached host IPs I3 and I4 that share MAC
	been probed out on PE1 and/or route I1-M2 may be learnt on PE2 before I3's loca	address M2. As a result, PE2 has local MAC-IP routes I3-M2 and
	l entry I3-M2 has been probed out on PE2.	I4-M2.</t>
	</t> <t>	</li>
	In such a scenario, MAC route sequence number assignment rules def	<li>
	ined in section 6.1 will cause new mac-ip routes I1-M2 and I3-M1 to bounce betwe	<t>A simultaneous move of I1 from PE1 to PE2 and of I3 from PE2 to
	en PE1 and PE2 with seuence number increments until stale entries I1-M1 and I3-M	PE1 will cause I1's MAC address to change from M1 to M2 and cause
	2 have been probed out from PE1 and PE2 respectively.	I3's MAC address to change from M2 to M1.</t>
	</t>	</li>
	</list>	<li>
	</t> <t>	<t>Route I3-M1 may be learned on PE1 before I1's local entry I1-M1
	An implementation MUST ensure proper probing procedures to remove stal	has been probed out on PE1 and/or route I1-M2 may be learned on PE2
	e ARP, NDP, and local MAC entries, following a move, on learning remote routes a	before I3's local entry I3-M2 has been probed out on PE2.</t>
	s defined in section 6.3 (and as per [RFC9135]) to minimize exposure to this rac	</li>
	e condition.	<li>
	</t>	<t>In such a scenario, MAC route sequence number assignment rules
		defined in <xref target="Local-MAC-IP-learning"/> will cause new
		MAC-IP routes I1-M2 and I3-M1 to bounce between PE1 and PE2 with
		sequence number increments until stale entries I1-M1 and I3-M2
		have been probed out from PE1 and PE2, respectively.</t>
		</li>
		</ul>
		<t>An implementation <bcp14>MUST</bcp14> ensure proper probing
		procedures to remove stale ARP, NDP, and local MAC entries, following
		a move, on learning remote routes as defined in <xref
		target="Remote-MAC-OR-MAC-IP-Update"/> (and as per <xref
		target="RFC9135"/>) to minimize exposure to this race condition.</t>
	</section>	</section>

	<section anchor="Mobility-Convergence" title="Mobility Convergence" number
	ed="true" toc="default">
	<t>
	This section is optional and details ARP and NDP probing procedures th
	at MAY be implemented to achieve faster host re-learning and convergence on mobi
	lity events. PE1 and PE2 are used as two example PEs in the network to illustrat
	e the mobility convergence scenarios in this section.
	<list style="symbols"> <t>
	Following a host move from PE1 to PE2, the host's MAC address is d
	iscovered at PE2 as a local MAC route via data frames received from the host. If
	PE2 has a prior remote MAC-IP host route for this MAC address from PE1, an ARP/
	NDP probe MAY be triggered at PE2 to learn the MAC-IP address as a local adjacen
	cy and trigger EVPN RT-2 advertisement for this MAC-IP address across the overla
	y with new reachability via PE2. This results in a reliable "event-based" host I
	P learning triggered by a "MAC address learning event" across the overlay, and h
	ence faster convergence of overlay routed flows to the host.
	</t> <t>
	Following a host move from PE1 to PE2, once PE1 receives a MAC or
	MAC-IP route from PE2 with a higher sequence number, an ARP/NDP probe MAY be tri
	ggered at PE1 to clear the stale local MAC-IP neighbor adjacency or to re-learn
	the local MAC-IP in case the host has moved back or is duplicated.


	</t> <t>	<section anchor="Mobility-Convergence" numbered="true" toc="default">
	Following a local MAC route age-out, if there is a local IP adjace	<name>Mobility Convergence</name>
	ncy with this MAC address, an ARP/NDP probe MAY be triggered for this IP to eith
	er re-learn the local MAC route and maintain local L3 and L2 reachability to thi	<t>This section is optional and details ARP and NDP probing procedures
	s host or to clear the ARP/NDP entry if the host is no longer local. This accomp	that <bcp14>MAY</bcp14> be implemented to achieve faster host
	lishes the clearance of stale ARP/NDP entries triggered by a MAC age-out event e	relearning and convergence on mobility events. PE1 and PE2 are used
	ven when the ARP/NDP refresh timer is longer than the MAC age-out timer. Clearin	as two example PEs in the network to illustrate the mobility
	g stale IP neighbor entries facilitates traffic convergence if the host was sile	convergence scenarios in this section.</t>
	nt and not discovered at its new location. Once the stale neighbor entry for the
	host is cleared, routed traffic flow destined for the host can re-trigger ARP/N	<ul spacing="normal">
	DP discovery for this host at the new location.	<li>
	</t>	<t>Following a host move from PE1 to PE2, the host's MAC address
	</list>	is discovered at PE2 as a local MAC route via data frames received
	</t>	from the host. If PE2 has a prior remote MAC-IP host route for
	<section anchor="Generalized-Probing-Logic" title="Generalized Probing L	this MAC address from PE1, an ARP/NDP probe <bcp14>MAY</bcp14> be
	ogic" numbered="true" toc="default">	triggered at PE2 to learn the MAC-IP address as a local adjacency
	<t>	and trigger EVPN RT-2 advertisement for this MAC-IP address across
	The above probing logic may be generalized as probing for an IP neig	the overlay with new reachability via PE2. This results in a
	hbor anytime a resolving parent MAC route is inconsistent with the MAC-IP neighb	reliable "event-based" host IP learning triggered by a "MAC
	or route, where inconsistency is defined as being not present or conflicting in	address learning event" across the overlay, and hence, a faster
	terms of the route source being local or remote. The MAC-IP route to parent MAC	convergence of overlay routed flows to the host.</t>
	route relationship described in section 5.1 MAY be used to achieve this logic.	</li>
	</t>	<li>
		<t>Following a host move from PE1 to PE2, once PE1 receives a MAC
		or MAC-IP route from PE2 with a higher sequence number, an ARP/NDP
		probe <bcp14>MAY</bcp14> be triggered at PE1 to clear the stale
		local MAC-IP neighbor adjacency or to relearn the local MAC-IP in
		case the host has moved back or is duplicated.</t>
		</li>
		<li>
		<t>Following a local MAC route age-out, if there is a local IP
		adjacency with this MAC address, an ARP/NDP probe
		<bcp14>MAY</bcp14> be triggered for this IP to either relearn the
		local MAC route and maintain local L3 and L2 reachability to this
		host or to clear the ARP/NDP entry if the host is no longer
		local. This accomplishes the clearance of stale ARP/NDP entries
		triggered by a MAC age-out event even when the ARP/NDP refresh
		timer is longer than the MAC age-out timer. Clearing stale IP
		neighbor entries facilitates traffic convergence if the host was
		silent and not discovered at its new location. Once the stale
		neighbor entry for the host is cleared, routed traffic flow
		destined for the host can re-trigger ARP/NDP discovery for this
		host at the new location.</t>
		</li>
		</ul>

		<section anchor="Generalized-Probing-Logic" numbered="true" toc="default
		">
		<name>Generalized Probing Logic</name>

		<t>The above probing logic may be generalized as probing for an IP
		neighbor anytime a resolving parent MAC route is inconsistent with
		the MAC-IP neighbor route, where inconsistency is defined as being
		not present or conflicting in terms of the route source being local
		or remote. The MAC-IP route to parent MAC route relationship
		described in <xref target="Sequence-Number-Inheritance"/>
		<bcp14>MAY</bcp14> be used to achieve this logic.</t>

	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="Routed-Overlay" title="Routed Overlay" numbered="true" toc=
	"default">	<section anchor="Routed-Overlay" numbered="true" toc="default">
	<t>	<name>Routed Overlay</name>
	An additional use case involves traffic to an end host in the overlay be
	ing entirely IP routed. In such a purely routed overlay:	<t>An additional use case involves traffic to an end host in the overlay
	<list style="symbols"> <t>	being entirely IP routed. In such a purely routed overlay:</t>
	A host MAC route is never advertised in the EVPN overlay control p
	lane.	<ul spacing="normal">
	</t> <t>	<li>
	Host /32 or /128 IP reachability is distributed across the overlay	<t>A host MAC route is never advertised in the EVPN overlay control pl
	via EVPN Route Type 5 (RT-5) along with a zero or non-zero ESI.	ane.</t>
	</t> <t>	</li>
	An overlay IP subnet may still be stretched across the underlay fa	<li>
	bric. However, intra-subnet traffic across the stretched overlay is never bridge	<t>Host /32 or /128 IP reachability is distributed across the
	d.	overlay via EVPN Route Type 5 (RT-5) along with a zero or non-zero
	</t> <t>	ESI.</t>
	Both inter-subnet and intra-subnet traffic in the overlay is IP ro	</li>
	uted at the EVPN PE.	<li>
	</t>	<t>An overlay IP subnet may still be stretched across the underlay
	</list>	fabric. However, intra-subnet traffic across the stretched overlay
	</t> <t>	is never bridged.</t>
	Please refer to [RFC7814] for more details.	</li>
	</t> <t>	<li>
	Host mobility within the stretched subnet still needs support. In the ab	<t>Both inter-subnet and intra-subnet traffic in the overlay is IP rou
	sence of host MAC routes, the sequence number mobility Extended Community specif	ted at the EVPN PE.</t>
	ied in [RFC7432] section 7.7 MAY be associated with a /32 or /128 host IP prefix	</li>
	advertised via EVPN Route Type 5. MAC mobility procedures defined in [RFC7432]	</ul>
	can be applied to host IP prefixes as follows:
	<list style="symbols"> <t>	<t>Please refer to <xref target="RFC7814"/> for more details.</t>
	On local learning of a host IP on a new ESI, the host IP MUST be a
	dvertised with a sequence number higher than what is currently advertised with t	<t>Host mobility within the stretched subnet still needs support. In the
	he old ESI.	absence of host MAC routes, the sequence number mobility Extended
	</t> <t>	Community specified in <xref target="RFC7432" sectionFormat="of"
	On receiving a host IP route advertisement with a higher sequence	section="7.7"/> <bcp14>MAY</bcp14> be associated with a /32 or /128 host
	number, a PE MUST trigger ARP/NDP probe and deletion procedures on any local rou	IP prefix advertised via EVPN Route Type 5. MAC mobility procedures
	te for that IP with a lower sequence number. The PE will update the forwarding e	defined in <xref target="RFC7432"/> can be applied to host IP prefixes
	ntry to point to the remote route with a higher sequence number and send an ARP/	as follows:</t>
	NDP probe for the local IP route. If the IP has moved, the probe will time out,
	and the local IP host route will be deleted.	<ul spacing="normal">
	</t>	<li>
	</list>	<t>On local learning of a host IP on a new ESI, the host IP
	</t> <t>	<bcp14>MUST</bcp14> be advertised with a sequence number higher than
	Note that there is only one sequence number associated with a host route	what is currently advertised with the old ESI.</t>
	at any time. For previous use cases where a host MAC address is advertised alon	</li>
	g with the host IP address, a sequence number is only associated with the MAC ad	<li>
	dress. If the MAC is not advertised, as in this use case, a sequence number is a	<t>On receiving a host IP route advertisement with a higher sequence
	ssociated with the host IP address.	number, a PE <bcp14>MUST</bcp14> trigger ARP/NDP probe and deletion
	</t> <t>	procedures on any local route for that IP with a lower sequence
	This mobility procedure does not apply to "anycast IPv6" hosts advertise	number. The PE will update the forwarding entry to point to the
	d via NA messages with the Override Flag (O Flag) set to 0. Refer to [RFC9161] f	remote route with a higher sequence number and send an ARP/NDP probe
	or more details.	for the local IP route. If the IP has moved, the probe will time
	</t>	out, and the local IP host route will be deleted.</t>
		</li>
		</ul>

		<t>Note that there is only one sequence number associated with a host
		route at any time. For previous use cases where a host MAC address is
		advertised along with the host IP address, a sequence number is only
		associated with the MAC address. If the MAC is not advertised, as in
		this use case, a sequence number is associated with the host IP address.</
		t>

		<t>This mobility procedure does not apply to "anycast" IPv6 hosts
		advertised via Neighbor Advertisement (NA) messages with the Override Flag
		(O Flag) set to
		0. Refer to <xref target="RFC9161"/> for more details.</t>

	</section>	</section>

	<section anchor="Duplicate-Host-Detection" title="Duplicate Host Detection"	<section anchor="Duplicate-Host-Detection" numbered="true" toc="default">
	numbered="true" toc="default">	<name>Duplicate Host Detection</name>
	<t>
	Duplicate host detection scenarios across EVPN-IRB can be classified as	<t>Duplicate host detection scenarios across EVPN-IRB can be classified as
	follows:	follows:</t>
	<list style="symbols"> <t>
	Scenario A: Two hosts have the same MAC address (host IPs may or may	<ul spacing="normal">
	not be duplicates).	<li>
	</t> <t>	<t>Scenario A: Two hosts have the same MAC address (host IPs may or ma
	Scenario B: Two hosts have the same IP address but different MAC add	y not be duplicates).</t>
	resses.	</li>
	</t> <t>	<li>
	Scenario C: Two hosts have the same IP address, and the host MAC add	<t>Scenario B: Two hosts have the same IP address but different MAC ad
	ress is not advertised.	dresses.</t>
	</t>	</li>
	</list>	<li>
	</t> <t>	<t>Scenario C: Two hosts have the same IP address, and the host MAC ad
	As specified in [RFC9161], Duplicate detection procedures for Scenarios	dress is not advertised.</t>
	B and C do not apply to "anycast IPv6" hosts advertised via NA messages with the	</li>
	Override Flag (O Flag) set to 0.	</ul>
	</t>	<t>As specified in <xref target="RFC9161"/>, duplicate detection
	<section anchor="Scenario-A" title="Scenario A" numbered="true" toc="defau	procedures for Scenarios B and C do not apply to "anycast" IPv6 hosts
	lt">	advertised via NA messages with the Override Flag (O Flag) set to 0.</t>
	<t>
	In cases where duplicate hosts share the same MAC address, the MAC add	<section anchor="Scenario-A" numbered="true" toc="default">
	ress is detected as duplicate using the duplicate MAC address detection procedur	<name>Scenario A</name>
	e described in [RFC7432]. Corresponding MAC-IP routes with the same MAC address
	do not require separate duplicate detection and MUST inherit the duplicate prope	<t>In cases where duplicate hosts share the same MAC address, the MAC
	rty from the MAC route. If a MAC route is marked as duplicate, all associated MA	address is detected as duplicate using the duplicate MAC address
	C-IP routes MUST also be treated as duplicates. Duplicate detection procedures n	detection procedure described in <xref
	eed only be applied to MAC routes.	target="RFC7432"/>. Corresponding MAC-IP routes with the same MAC
	</t>	address do not require separate duplicate detection and
		<bcp14>MUST</bcp14> inherit the duplicate property from the MAC
		route. If a MAC route is marked as duplicate, all associated MAC-IP
		routes <bcp14>MUST</bcp14> also be treated as duplicates. Duplicate
		detection procedures need only be applied to MAC routes.</t>
	</section>	</section>

	<section anchor="Scenario-B" title="Scenario B" numbered="true" toc="defau
	lt">	<section anchor="Scenario-B" numbered="true" toc="default">
	<t>	<name>Scenario B</name>
	Misconfigurations may lead to different MAC addresses being assigned t
	he same IP address. This scenario is not detected by [RFC7432] duplicate MAC add	<t>Misconfigurations may lead to different MAC addresses being
	ress detection procedures and can result in incorrect routing of traffic destine	assigned the same IP address. This scenario is not detected by the
	d for the IP address.	duplicate MAC address detection procedures from <xref
	</t> <t>	target="RFC7432"/> and can result in incorrect routing of traffic
	Such situations, when detected locally, are identified as a move scena	destined for the IP address.</t>
	rio through the local MAC route sequence number computation procedure described
	in section 6.1:	<t>Such situations, when detected locally, are identified as a move
	<list style="symbols"> <t>	scenario through the local MAC route sequence number computation
	If the IP is associated with a different remote MAC "Mz," the sequ	procedure described in <xref target="Local-MAC-IP-learning"/>:</t>
	ence number MUST be higher than the "Mz" sequence number.
	</t>	<ul spacing="normal">
	</list>	<li>
	</t> <t>	<t>If the IP is associated with a different remote MAC "Mz", the
	This move results in a sequence number increment for the local MAC rou	sequence number <bcp14>MUST</bcp14> be higher than the "Mz"
	te due to the remote MAC-IP route associated with a different MAC address, count	sequence number.</t>
	ing as an "IP move" against the IP, independent of the MAC. The duplicate detect	</li>
	ion procedure described in [RFC7432] can then be applied to the IP entity indepe	</ul>
	ndent of the MAC. Once an IP is detected as duplicate, the corresponding MAC-IP
	route should be treated as duplicate. Associated MAC routes and any other MAC-IP	<t>This move results in a sequence number increment for the local MAC
	routes related to this MAC should not be affected.	route due to the remote MAC-IP route being associated with a different M
	</t>	AC
	<section anchor="Duplicate-IP-Detection-Procedure-for-Scenario-B" title=	address, which counts as an "IP move" against the IP, independent of the
	"Duplicate IP Detection Procedure for Scenario B" numbered="true" toc="default">	MAC. The duplicate detection procedure described in <xref
	<t>	target="RFC7432"/> can then be applied to the IP entity independent of
	The duplicate IP detection procedure for this scenario is specified in	the MAC. Once an IP is detected as duplicate, the corresponding MAC-IP
	[RFC9161]. An "IP move" is further clarified as follows:	route should be treated as duplicate. Associated MAC routes and any
	<list style="symbols"> <t>	other MAC-IP routes related to this MAC should not be affected.</t>
	Upon learning a local MAC-IP route Mx-IPx, check for existing remo
	te or local routes for IPx with a different MAC address association (Mz-IPx). If	<section anchor="Duplicate-IP-Detection-Procedure-for-Scenario-B" number
	found, count this as an "IP move" for IPx, independent of the MAC.	ed="true" toc="default">
	</t> <t>	<name>Duplicate IP Detection Procedure for Scenario B</name>
	Upon learning a remote MAC-IP route Mz-IPx, check for existing loc
	al routes for IPx with a different MAC address association (Mx-IPx). If found, c	<t>The duplicate IP detection procedure for this scenario is
	ount this as an "IP move" for IPx, independent of the MAC.	specified in <xref target="RFC9161"/>. An "IP move" is further
	</t>	clarified as follows:</t>
	</list>	<ul spacing="normal">
	</t> <t>
	A MAC-IP route MUST be treated as duplicate if either:	<li>
	<list style="symbols"> <t>	<t>Upon learning a local MAC-IP route Mx-IPx, check for existing
	The corresponding MAC route is marked as duplicate via the existin	remote or local routes for IPx with a different MAC address
	g detection procedure.	association (Mz-IPx). If found, count this as an "IP move" for
	</t> <t>	IPx, independent of the MAC.</t>
	The corresponding IP is marked as duplicate via the extended proce	</li>
	dure described above.	<li>
	</t>	<t>Upon learning a remote MAC-IP route Mz-IPx, check for
	</list>	existing local routes for IPx with a different MAC address
	</t>	association (Mx-IPx). If found, count this as an "IP move" for
		IPx, independent of the MAC.</t>
		</li>
		</ul>

		<t>A MAC-IP route <bcp14>MUST</bcp14> be treated as duplicate if eithe
		r:</t>

		<ul spacing="normal">
		<li>the corresponding MAC route is marked as duplicate via the
		existing detection procedure, or</li>
		<li>the corresponding IP is marked as duplicate via the extended
		procedure described above.</li>
		</ul>

	</section>	</section>
	</section>	</section>

	<section anchor="Scenario-C" title="Scenario C" numbered="true" toc="defau
	lt">	<section anchor="Scenario-C" numbered="true" toc="default">
	<t>	<name>Scenario C</name>
	In a purely routed overlay scenario, as described in section 7, where
	only a host IP is advertised via EVPN RT-5 with a sequence number mobility attri	<t>As described in <xref target="Routed-Overlay"/>, in a purely routed
	bute, procedures similar to duplicate MAC address detection procedures specified	overlay scenario where only a host IP is advertised via EVPN RT-5 with
	in [RFC7432] can be applied to IP-only host routes for duplicate IP detection a	a sequence number mobility attribute, procedures similar to the
	s follows:	duplicate MAC address detection procedures specified in <xref
	<list style="symbols"> <t>	target="RFC7432"/> can be applied to
	Upon learning a local host IP route IPx, check for existing remote	IP-only host routes for duplicate IP detection as follows:</t>
	or local routes for IPx with a different ESI association. If found, count this
	as an "IP move" for IPx.	<ul spacing="normal">
	</t> <t>	<li>
	Upon learning a remote host IP route IPx, check for existing local	<t>Upon learning a local host IP route IPx, check for existing
	routes for IPx with a different ESI association. If found, count this as an "IP	remote or local routes for IPx with a different ESI
	move" for IPx.	association. If found, count this as an "IP move" for IPx.</t>
	</t> <t>	</li>
	Using configurable parameters "N" and "M," if "N" IP moves are det	<li>
	ected within "M" seconds for IPx, IPx should be treated as duplicate.	<t>Upon learning a remote host IP route IPx, check for existing
	</t>	local routes for IPx with a different ESI association. If found,
	</list>	count this as an "IP move" for IPx.</t>
	</t>	</li>
		<li>
		<t>Using configurable parameters "N" and "M", if "N" IP moves are
		detected within "M" seconds for IPx, then IPx should be treated as
		duplicate.</t>
		</li>
		</ul>
	</section>	</section>

	<section anchor="Duplicate-Host-Recovery" title="Duplicate Host Recovery"
	numbered="true" toc="default">	<section anchor="Duplicate-Host-Recovery" numbered="true" toc="default">
	<t>	<name>Duplicate Host Recovery</name>
	Once a MAC or IP address is marked as duplicate and frozen, corrective
	action must be taken to un-provision one of the duplicate MAC or IP addresses.	<t>Once a MAC or IP address is marked as duplicate and frozen,
	Un-provisioning refers to corrective action taken on the host side. Following th	corrective action must be taken to un-provision one of the duplicate
	is correction, normal operation will not resume until the duplicate MAC or IP ad	MAC or IP addresses. Un-provisioning refers to corrective action taken
	dress ages out unless additional action is taken to expedite recovery.	on the host side. Following this correction, normal operation will not
	</t> <t>	resume until the duplicate MAC or IP address ages out, unless
	Possible additional corrective actions for faster recovery include:	additional action is taken to expedite recovery.</t>
	</t>
	<section anchor="Route-Un-freezing-Configuration" title="Route Un-freezi	<t>Possible additional corrective actions for faster recovery are
	ng Configuration" numbered="true" toc="default">	outlined in the following sections.</t>
	<t>
	Unfreezing the duplicate or frozen MAC or IP route via a CLI can be	<section anchor="Route-Un-freezing-Configuration" numbered="true" toc="d
	used to recover from the duplicate and frozen state following corrective un-prov	efault">
	isioning of the duplicate MAC or IP address. Unfreezing the MAC or IP route shou	<name>Route Unfreezing Configuration</name>
	ld result in advertising it with a sequence number higher than that advertised f
	rom the other location.	<t>Unfreezing the duplicate or frozen MAC or IP route via a CLI can
	</t> <t>	be used to recover from the duplicate and frozen state following
	Two scenarios exist:	corrective un-provisioning of the duplicate MAC or IP
	<list style="symbols"> <t>	address. Unfreezing the MAC or IP route should result in advertising
	Scenario A: The duplicate MAC or IP address is un-provisioned at	it with a sequence number higher than that advertised from the other
	the location where it was not marked as duplicate.	location.</t>
	</t> <t>
	Scenario B: The duplicate MAC or IP address is un-provisioned at	<t>Two scenarios exist:</t>
	the location where it was marked as duplicate.
	</t>	<ul spacing="normal">
	</list>	<li>
	</t> <t>	<t>Scenario A: The duplicate MAC or IP address is un-provisioned
	Unfreezing the duplicate and frozen MAC or IP route will result in r	at the location where it was not marked as duplicate.</t>
	ecovery to a steady state as follows:	</li>
	<list style="symbols"> <t>	<li>
	Scenario A: If the duplicate MAC or IP address is un-provisioned	<t>Scenario B: The duplicate MAC or IP address is un-provisioned
	at the non-duplicate location, unfreezing the route at the frozen location resu	at the location where it was marked as duplicate.</t>
	lts in advertising with a higher sequence number, leading to automatic clearing	</li>
	of the local route at the un-provisioned location via ARP/NDP PROBE and DELETE p	</ul>
	rocedures.	<t>Unfreezing the duplicate and frozen MAC or IP route will result
	</t> <t>	in recovery to a steady state as follows:</t>
	Scenario B: If the duplicate host is un-provisioned at the dupli
	cate location, unfreezing the route triggers an advertisement with a higher sequ	<ul spacing="normal">
	ence number to the other location, prompting re-learning and clearing of the loc	<li>
	al route at the original location upon receiving the remote route advertisement.	<t>Scenario A: If the duplicate MAC or IP address is
	</t>	un-provisioned at the non-duplicate location, unfreezing the
	</list>	route at the frozen location results in advertising with a
	Probes referred to in these scenarios are event-driven probes result	higher sequence number, leading to automatic clearing of the
	ing from receiving a route with a higher sequence number. Periodic probes result	local route at the un-provisioned location via ARP/NDP PROBE and
	ing from refresh timers may also occur independently.	DELETE procedures.</t>
	</t>	</li>
		<li>
		<t>Scenario B: If the duplicate host is un-provisioned at the
		duplicate location, unfreezing the route triggers an
		advertisement with a higher sequence number to the other
		location, prompting relearning and clearing of the local route
		at the original location upon receiving the remote route
		advertisement.</t>
		</li>
		</ul>

		<t>The probes referred to in these scenarios are event-driven probes
		resulting from receiving a route with a higher sequence
		number. Periodic probes resulting from refresh timers may also occur
		independently.</t>
	</section>	</section>

	<section anchor="Route-Clearing-Configuration" title="Route Clearing Con
	figuration" numbered="true" toc="default">	<section anchor="Route-Clearing-Configuration" numbered="true" toc="defa
	<t>	ult">
	In addition to the above, route clearing CLIs may be used to clear t
	he local MAC or IP route after the duplicate host is un-provisioned:	<name>Route Clearing Configuration</name>
	<list style="symbols"> <t>	<t>In addition to the above, route clearing CLIs may be used to
	Clear MAC CLI: Used to clear a duplicate MAC route.	clear the local MAC or IP route after the duplicate host is
	</t> <t>	un-provisioned:</t>
	Clear ARP/NDP: Used to clear a duplicate IP route.
	</t>	<ul spacing="normal">
	</list>	<li>
	</t> <t>	<t>Clear MAC CLI: Used to clear a duplicate MAC route.</t>
	The route unfreeze CLI may still need to be executed if the route wa	</li>
	s un-provisioned and cleared from the non-duplicate location. Given that unfreez	<li>
	ing the route via the CLI would result in auto-clearing from the un-provisioned	<t>Clear ARP/NDP: Used to clear a duplicate IP route.</t>
	location, as explained earlier, using a route clearing CLI for recovery from the	</li>
	duplicate state is optional.	</ul>
	</t>
		<t>The route unfreeze CLI may still need to be executed if the route
		was un-provisioned and cleared from the non-duplicate
		location. Given that unfreezing the route via the CLI would result
		in auto-clearing from the un-provisioned location, as explained
		earlier, using a route clearing CLI for recovery from the duplicate
		state is optional.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="Security" title="Security Considerations" numbered="true" t
	oc="default">	<section anchor="Security" numbered="true" toc="default">
	<t>	<name>Security Considerations</name>
	Security considerations discussed in [RFC7432] and [RFC9135] apply to th
	is document. Methods described in this document further extend the consumption o	<t>The security considerations discussed in <xref target="RFC7432"/> and
	f sequence numbers for IRB deployments. They are hence subject to same considera	<xref target="RFC9135"/> apply to this document. Methods described in
	tions if the control plane or data plane was to be compromised. As an example, i	this document further extend the consumption of sequence numbers for IRB
	f host facing data plane is compromised, spoofing attempts could result in a leg	deployments. Hence, they are subject to the same considerations if the
	itimate host being perceived as moved, eventually resulting in the host being ma	control plane or data plane was to be compromised. As an example, if the
	rked as duplicate. Considerations for protecting control and data plane describe	host-facing data plane is compromised, spoofing attempts could result in
	d in [RFC7432] are equally applicable to such mobility spoofing use cases.	a legitimate host being perceived as moved, eventually resulting in the
	</t>	host being marked as duplicate. The considerations for protecting control
		and data planes described in <xref target="RFC7432"/> are equally
		applicable to such mobility spoofing use cases.</t>
	</section>	</section>

	<section anchor="IANA" title="IANA Considerations" numbered="true" toc="defa
	ult">	<section anchor="IANA" numbered="true" toc="default">
	<t>	<name>IANA Considerations</name>
	No IANA actions required.	<t>This document has no IANA actions.</t>
		</section>
		</middle>
		<back>

		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		432.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		161.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		135.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
		826.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		861.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		814.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		986.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		031.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		348.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		926.xml"/>
		</references>
		</references>

		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>The authors would like to thank <contact fullname="Gunter Van de
		Velde"/> for the significant contributions to improve the readability of t
		his
		document. The authors would also like to thank <contact fullname="Sonal
		Agarwal"/> and <contact fullname="Larry Kreeger"/> for multiple
		contributions through the implementation process. The authors would like t
		o
		thank <contact fullname="Vibov Bhan"/> and <contact fullname="Patrice
		Brissette"/> for early feedback during the implementation and testing of
		several procedures defined in this document. The authors would like to
		thank <contact fullname="Wen Lin"/> for a detailed review and valuable
		comments related to MAC sharing race conditions. The authors would also
		like to thank <contact fullname="Saumya Dikshit"/> for a detailed review
		and valuable comments across the document.
	</t>	</t>
	</section>	</section>

	<section anchor="Contributors" title="Contributors" numbered="true" toc="def
	ault">	<section anchor="Contributors" numbered="false" toc="default">
	<author fullname="Gunter van de Velde">	<name>Contributors</name>
		<author fullname="Gunter Van de Velde">
	<organization>Nokia</organization>	<organization>Nokia</organization>
	<address>	<address>
	<email>van_de_velde@nokia.com</email>	<email>van_de_velde@nokia.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Wen Lin">	<author fullname="Wen Lin">
	<organization>Juniper</organization>	<organization>Juniper</organization>
	<address>	<address>
	<email>wlin@juniper.net</email>	<email>wlin@juniper.net</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Sonal Agarwal">	<author fullname="Sonal Agarwal">
	<organization>Arrcus</organization>	<organization>Arrcus</organization>
	<address>	<address>
	<email>sonal@arrcus.com</email>	<email>sonal@arrcus.com</email>
	</address>	</address>
	</author>	</author>
	</section>	</section>

	<section anchor="Acknowledgements" title="Acknowledgements" numbered="true"
	toc="default">
	<t>
	Authors would like to thank Gunter van de Velde for significant contribu
	tion to improve the readability of this document. Authors would also like to tha
	nk Sonal Agarwal and Larry Kreeger for multiple contributions through the implem
	entation process. Authors would like to thank Vibov Bhan and Patrice Brissette f
	or early feedback during implementation and testing of several procedures define
	d in this document. Authors would like to thank Wen Lin for a detailed review an
	d valuable comments related to MAC sharing race conditions. Authors would also l
	ike to thank Saumya Dikshit for a detailed review and valuable comments across t
	he document.
	</t>
	</section>
	</middle>
	<back>
	<references title="Normative References">
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211
	9">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title
	>
	<author initials="S." surname="Bradner" fullname="S. Bradner">
	<organization/>
	</author>
	<date year="1997" month="March"/>
	<abstract>
	<t>In many standards track documents several words are used to signi
	fy the requirements in the specification. These words are often capitalized. Th
	is document defines these words as they should be interpreted in IETF documents.
	This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC7432" target="https://datatracker.ietf.org/doc/html/
	rfc7432">
	<front>
	<title>BGP MPLS-Based Ethernet VPN</title>
	<author initials="A." surname="Sajassi" fullname="A. Sajassi" role="ed
	itor">
	<organization/>
	</author>
	<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
	<organization/>
	</author>
	<author initials="N." surname="Bitar" fullname="N. Bitar">
	<organization/>
	</author>
	<author initials="A." surname="Isaac" fullname="A. Isaac">
	<organization/>
	</author>
	<author initials="J." surname="Uttaro" fullname="J. Uttaro">
	<organization/>
	</author>
	<author initials="J." surname="Drake" fullname="J. Drake">
	<organization/>
	</author>
	<author initials="W." surname="Henderickx" fullname="W. Henderickx">
	<organization/>
	</author>
	<date year="2015" month="February"/>
	<abstract>
	<t>This document describes procedures for BGP MPLS-based Ethernet VP
	Ns (EVPN). The procedures described here meet the requirements specified in RFC
	7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7432"/>
	<seriesInfo name="DOI" value="10.17487/RFC7432"/>
	</reference>
	<reference anchor="RFC9161">
	<front>
	<title>Operational Aspects of Proxy-ARP/ND in EVPN Networks</title>
	<author initials="J" surname="Rabadan" fullname="Jorge Rabadan">
	<organization/>
	</author>
	<author initials="S" surname="Sathappan" fullname="S. Sathappan">
	<organization/>
	</author>
	<author initials="K" surname="Nagaraj" fullname="Kiran Nagaraj">
	<organization/>
	</author>
	<author initials="G" surname="Hankins" fullname="Greg Hankins">
	<organization/>
	</author>
	<author initials="T" surname="King" fullname="Thomas King">
	<organization/>
	</author>
	<date month="Jan" year="2022"/>
	</front>
	<seriesInfo name="RFC" value="9161"/>
	<seriesInfo name="DOI" value="10.17487/RFC9161"/>
	</reference>
	<reference anchor="RFC9135">
	<front>
	<title>Integrated Routing and Bridging in EVPN</title>
	<author initials="A" surname="Sajassi" fullname="Ali Sajassi">
	<organization/>
	</author>
	<author initials="S" surname="Salam" fullname="Samer Salam">
	<organization/>
	</author>
	<author initials="S" surname="Thoria" fullname="Samir Thoria">
	<organization/>
	</author>
	<author initials="J" surname="Drake" fullname="John Drake">
	<organization/>
	</author>
	<author initials="J" surname="Rabadan" fullname="Jorge Rabadan">
	<organization/>
	</author>
	<date month="October" year="2021"/>
	<abstract>
	<t>[RFC7432] describes mechanism to elect designated forwarder (DF)
	at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in cas
	e of VLAN bundle or VLAN-aware bundle service). However, the current level of g
	ranularity of per-VLAN is not adequate for some of applications. [RFC8584] impr
	oves base line DF election. This document is an extension to HRW base drafts ([I
	-D.ietf-bess-evpn-ac-df] and [I-D.ietf-bess-evpn-df-election]) and further enhan
	ces HRW algorithm to do DF election at the granularity of (ESI, VLAN, Mcast flow
	).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9135"/>
	<seriesInfo name="DOI" value="10.17487/RFC9135"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
	e>
	<author initials="B" surname="Leiba" fullname="B Leiba">
	<organization/>
	</author>
	<date month="May" day="" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protocol
	specifications. This document aims to reduce the ambiguity by
	clarifying that only UPPERCASE usage of the key words have the
	defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8174"/>
	</reference>
	<reference anchor="RFC826">
	<front>
	<title>An Ethernet Address Resolution Protocol</title>
	<author initials="D" surname="Plummer" fullname="David C. Plummer">
	<organization/>
	</author>
	<date month="November" year="1982"/>
	</front>
	<seriesInfo name="RFC" value="826"/>
	</reference>
	<reference anchor="RFC4861">
	<front>
	<title>Neighbor Discovery for IP version 6 (IPv6)</title>
	<author initials="T" surname="Narten" fullname="Thomas Narten">
	<organization/>
	</author>
	<author initials="E" surname="Nordmark" fullname="Erik Nordmark">
	<organization/>
	</author>
	<author initials="W" surname="Simpson" fullname="William Allen Simpson
	">
	<organization/>
	</author>
	<author initials="H" surname="Soliman" fullname="Hesham Soliman">
	<organization/>
	</author>
	<date month="September" year="2007"/>
	</front>
	<seriesInfo name="RFC" value="4861"/>
	</reference>
	</references>
	<references title="Informative References">
	<reference anchor="RFC7814" target="https://tools.ietf.org/html/rfc7814">
	<front>
	<title>Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Soluti
	on</title>
	<author initials="X." surname="Xu" fullname="X. Xu">
	<organization/>
	</author>
	<author initials="C." surname="Jacquenet" fullname="C. Jacquenet">
	<organization/>
	</author>
	<author initials="R." surname="Raszuk" fullname="R. Raszuk">
	<organization/>
	</author>
	<author initials="T." surname="Boyes" fullname="T. Boyes">
	<organization/>
	</author>
	<author initials="B." surname="Fee" fullname="B. Fee">
	<organization/>
	</author>
	<date year="2016" month="March"/>
	<abstract>
	<t>This document describes a BGP/MPLS IP VPN-based subnet extension
	solution referred to as "Virtual Subnet", which can be used for building Layer 3
	network virtualization overlays within and/or between data centers.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7814"/>
	<seriesInfo name="DOI" value="10.17487/RFC7814"/>
	</reference>
	<reference anchor="RFC8986" target="https://datatracker.ietf.org/doc/rfc89
	86/">
	<front>
	<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
	<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
	<organization/>
	</author>
	<author initials="P." surname="Camarillo" fullname="Pablo Camarillo">
	<organization/>
	</author>
	<author initials="J." surname="Leddy" fullname="John Reddy">
	<organization/>
	</author>
	<author initials="D." surname="Voyer" fullname="Daniel Voyer">
	<organization/>
	</author>
	<author initials="S." surname="Matsushima" fullname="Satoru Matsushima
	">
	<organization/>
	</author>
	<author initials="Z." surname="LI" fullname="Zhenbin Li">
	<organization/>
	</author>
	<date year="2021" month="February"/>
	<abstract>
	<t>This document defines the SRv6 Network Programming concept and
	specifies the base set of SRv6 behaviors that enables the creation of
	interoperable overlays with underlay optimization</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8986"/>
	<seriesInfo name="DOI" value="10.18986/RFC8986"/>
	</reference>
	<reference anchor="RFC3031" target="https://datatracker.ietf.org/doc/html/
	rfc3031">
	<front>
	<title>Multiprotocol Label Switching Architecture</title>
	<author initials="E." surname="Rosen" fullname="Eric Rosen">
	<organization/>
	</author>
	<author initials="A." surname="Viswanathan" fullname="A. Viswanathan">
	<organization/>
	</author>
	<author initials="R." surname="Callon" fullname="R. Callon">
	<organization/>
	</author>
	<date year="2001" month="January"/>
	</front>
	<seriesInfo name="RFC" value="3031"/>
	<seriesInfo name="DOI" value="10.13031/RFC3031"/>
	</reference>
	<reference anchor="RFC7348" target="https://datatracker.ietf.org/doc/html/
	rfc7348">
	<front>
	<title>Virtual eXtensible Local Area Network (VXLAN): A Framework
	for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
	<author initials="D." surname="Dutt" fullname="D. Dutt">
	<organization/>
	</author>
	<author initials="K." surname="Duda" fullname="K. Duda">
	<organization/>
	</author>
	<author initials="P." surname="Agarwal" fullname="P. Agarwal">
	<organization/>
	</author>
	<author initials="L." surname="Kreeger" fullname="L. Kreeger">
	<organization/>
	</author>
	<author initials="T." surname="Sridhar" fullname="T. Sridhar">
	<organization/>
	</author>
	<author initials="M." surname="Bursell" fullname="M. Bursell">
	<organization/>
	</author>
	<author initials="C." surname="Wright" fullname="C. Wright">
	<organization/>
	</author>
	<date year="2014" month="August"/>
	</front>
	<seriesInfo name="RFC" value="7348"/>
	<seriesInfo name="DOI" value="10.17348/RFC7348"/>
	</reference>
	<reference anchor="RFC8926" target="https://datatracker.ietf.org/doc/rfc89
	26/">
	<front>
	<title>Geneve: Generic Network Virtualization Encapsulation</title>
	<author initials="J." surname="Gross" fullname="J. Gross">
	<organization/>
	</author>
	<author initials="I." surname="Ganga" fullname="I. Ganga">
	<organization/>
	</author>
	<author initials="T." surname="Sridhar" fullname="T. Sridhar">
	<organization/>
	</author>
	<date year="2020" month="November"/>
	</front>
	<seriesInfo name="RFC" value="8926"/>
	<seriesInfo name="DOI" value="10.18926/RFC8926"/>
	</reference>
	</references>
	</back>	</back>
	</rfc>	</rfc>


		<!-- [rfced] Please review the following questions and changes regarding the
		abbreviations used in this document. Per Section 3.6 of RFC 7322 ("RFC Style
		Guide"), abbreviations should be expanded upon first use.

		a.) How may we expand "CLI" in the sentence below? As "command-line interface",
		"Call Level Interface", "Calling Line Identification", or something else?

		Original:

		Unfreezing the duplicate or frozen MAC or IP route via a CLI can be
		used to recover from the duplicate and frozen state following
		corrective un-provisioning of the duplicate MAC or IP address.

		b.) FYI - We have already expanded the following abbreviations upon first use.
		Please review each expansion in the document carefully to ensure correctness.

		Media Access Control (MAC)
		MAC Virtual Routing and Forwarding (MAC-VRF)
		IP Virtual Routing and Forwarding (IP-VRF)
		Ethernet Segment Identifier (ESI)
		Ethernet Segment (ES)
		Provider Edge (PE)
		Neighbor Advertisement (NA)
		VXLAN Tunnel End Point (VTEP)

		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		For example, please consider whether "natively" should be updated in the
		instances below:

		...for a host that is attached to a local ES may be learned natively via...
		...routes learnt natively via data plane and ARP/NDP are respectively...

		-->

End of changes. 59 change blocks.
	1373 lines changed or deleted	1555 lines changed or added
This html diff was produced by rfcdiff 1.48.