<?xml version='1.0' encoding='ascii'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes" ?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-evpn-irb-extended-mobility-21" number="9721" consensus="true" ipr="trust200902" obsoletes="" submissionType="IETF" xml:lang="en"> xml:lang="en" updates="" tocInclude="true" tocDepth="6" symRefs="true" sortRefs="true" version="3">

<!-- [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>
    <title abbrev="EVPN-IRB Extended Mobility">
      Extended Mobility">Extended Mobility Procedures
    for EVPN-IRB
    </title> Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)</title>
    <seriesInfo name="RFC" value="9721"/>
    <author fullname="Neeraj Malhotra" initials="N." surname="Malhotra" role="editor">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Drive</street>
          <street/>
          <city>San Jose</city>
          <code>95134</code>
          <region>CA</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>nmalhotr@cisco.com</email>
      </address>
    </author>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Drive</street>
          <street/>
          <city>San Jose</city>
          <code>95134</code>
          <region>CA</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <author fullname="Aparna Pattekar" initials="A." surname="Pattekar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Drive</street>
          <street/>
          <city>San Jose</city>
          <code>95134</code>
          <region>CA</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>apjoshi@cisco.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>777 E. Middlefield Road</street>
          <city>Mountain View</city>
          <code>94043</code>
          <region>CA</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Avinash Lingala" initials="A." surname="Lingala">
      <organization>AT&amp;T</organization>
      <address>
        <postal>
          <street>3400 W Plano Pkwy</street>
          <city>Plano</city>
          <region>TX</region>
          <code>75075</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>ar977m@att.com</email>
      </address>
    </author>
    <author fullname="John Drake" initials="J." surname="Drake">
      <organization>Juniper Networks</organization>
      <address>
        <email>jdrake@juniper.net</email>
      </address>
    </author>
    <date month="December" day="4" year="2024"/>
    <area>Routing</area>
    <workgroup>BESS WorkGroup</workgroup> month="April" year="2025"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract> <t>
      This
      <t>This document specifies extensions to the Ethernet VPN (EVPN) Integrated
      Routing and Bridging (IRB) (EVPN-IRB) procedures specified in RFC7432 RFCs 7432 and RFC9135
      9135 to enhance the mobility mechanisms
      for EVPN-IRB networks based networks. on EVPN-IRB. The proposed extensions improve the
      handling of host mobility and duplicate address detection in EVPN-IRB
      networks to cover a broader set of scenarios where a
      host's unicast IP address to MAC Media Access Control (MAC) address bindings
      may change across moves.  These enhancements address limitations in the
      existing EVPN-IRB mobility procedures by providing more efficient and
      scalable solutions. The extensions are backward compatible with existing
      EVPN-IRB implementations and aim to optimize network performance in
      scenarios involving frequent IP address mobility.
      </t>
      <t>
        NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six authors which is above the required limit of five. Given significant and active contributions to the draft from all six authors over the course of six years, we would like to request IESG to allow publication with six authors. Specifically, the three Cisco authors are the original inventors of these procedures and contributed heavily to rev 0 draft, most of which is still intact. AT&amp;T is also a key contributor towards defining the use cases that this document addresses as well as the proposed solution. Authors from Nokia and Juniper have further contributed to revisions and discussions steadily over last six years to enable respective implementations and a wider adoption.
      </t> mobility.</t>
    </abstract>
  </front>
  <middle>

    <section anchor="Intro" title="Introduction" numbered="true" toc="default">
      <t>
        EVPN-IRB
      <name>Introduction</name>
      <t>EVPN-IRB facilitates
      the advertisement of both MAC and IP routes via a
      single MAC+IP Route Type 2 (RT-2) advertisement. The MAC address is
      integrated into the local MAC-VRF MAC Virtual Routing and Forwarding (MAC-VRF)
      bridge table, enabling Layer 2 (L2) bridged traffic across the network
      overlay. The IP address is incorporated into the local ARP/NDP Address Resolution Protocol (ARP) / Neighbor Discovery Protocol (NDP) table in an
      asymmetric IRB design, design or into the IP-VRF IP Virtual Routing and Forwarding
      (IP-VRF) routing table in a symmetric IRB design, facilitating design. This facilitates
      routed traffic across the network overlay. For additional context on
      EVPN-IRB forwarding modes, refer to [RFC9135].
      </t>
      <t>
        To <xref target="RFC9135"/>.</t>

      <t>To support the EVPN mobility procedure, a single sequence number
      mobility attribute is advertised with the combined MAC+IP route. This
      approach, which resolves both MAC and IP reachability with a single
      sequence number, inherently assumes a fixed 1:1 mapping between an IP
      address and MAC address. While this fixed 1:1 mapping is a common use
      case and is addressed via the existing mobility procedure defined in [RFC7432],
      <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 Virtual
      Machines (VMs) or containerized workloads. The following IRB mobility
      scenarios are considered:
        <list style="symbols"> <t> considered:</t>

      <ul spacing="normal">
        <li>
            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 address association.
          </t> <t>
        </li>
        <li>
            A host move results in the host's MAC address moving to a new IP address association.
          </t>
        </list>
      </t>
      <t>
        While
        </li>
      </ul>

      <t>While the existing mobility procedure can manage the MAC+IP address
      move in the first scenario, the subsequent scenarios lead to new MAC-IP
      address associations. Therefore, a single sequence number assigned
      independently per-{MAC for each {MAC address, IP address} is insufficient to determine
      the most recent reachability for both MAC address and IP address address, unless
      the sequence number assignment algorithm allows for changing MAC-IP
      address bindings across moves.
      </t>
      <t> moves.</t>

<!-- [rfced] May we number the text below for ease of the reader? Please
review:

Original:

   This document updates the sequence number assignment procedures
   defined in [RFC7432] to adequately address mobility support across
   EVPN-IRB overlay use cases that permit MAC-IP address bindings to
   change across host moves and support mobility for both MAC and IP
   route components carried in an EVPN RT-2 for these use cases.
      </t>
      <t>
        Additionally,

Perhaps:

   This document updates the sequence number assignment procedures
   defined in [RFC7432] to 1) adequately address mobility support across
   EVPN-IRB overlay use cases that permit MAC-IP address bindings to change
   across host moves and 2) support mobility for both MAC and IP
   route components carried in an EVPN RT-2 for these use cases.

-->

      <t>This document updates the sequence number assignment procedures
      defined in <xref target="RFC7432"/> to adequately
      address mobility support across EVPN-IRB overlay use cases that permit
      MAC-IP address bindings to change across host moves and
      support mobility for both MAC and IP route components carried in an
      EVPN RT-2 for these use cases.</t>

      <t>Additionally, for hosts on an ESI Ethernet Segment Identifier (ESI) that
      is multi-homed to multiple PE Provider Edge (PE) devices, additional
      procedures are specified to ensure synchronized sequence number
      assignments across the multi-homing devices.
      </t>
      <t>
        This devices.</t>

      <t>This document addresses mobility for the following cases, independent
      of the overlay encapsulation (e.g., MPLS, SRv6, NVO Tunnel):
        <list style="symbols"> <t>
            Symmetric Segment Routing over IPv6
      (SRv6), and Network Virtualization Overlay (NVO) tunnel):</t>

      <ul spacing="normal">
        <li>Symmetric EVPN-IRB overlay
          </t> <t>
            Asymmetric overlay</li>
        <li>Asymmetric EVPN-IRB overlay
          </t> <t>
            Routed overlay</li>
        <li>Routed EVPN overlay
          </t>
        </list>
      </t> overlay</li>
      </ul>

      <section anchor="doc-structure" title="Document Structure" numbered="true" toc="default">
        <t>
          Following
        <name>Document Structure</name>
        <t>The following sections of the document are informative:
        <list style="symbols"> <t>
            section 3 informative:</t>
        <ul spacing="normal">
          <li>
            <xref target="Background-Problem-Statement"/> provides the
            necessary background and problem statement being addressed in this
            document.
          </t> <t>
            section 4
          </li>
          <li>
	    <xref target="Design-Considerations"/> lists the resulting design
	    considerations for the document.
          </t> <t>
            section 5
          </li>
          <li>
            <xref target="Solution-Components"/> lists the main solution
            components that are foundational for the sepecifications specifications that
            follow in subsequent sections.
          </t>
        </list>
        </t>
        <t>
          Following
          </li>
        </ul>

        <t>The following sections of the document are normative:
        <list style="symbols"> <t>
            section 6 normative:</t>

        <ul spacing="normal">
          <li>
            <xref target="Methods-for-Sequence-Number-Assignment"/> describes
            the mobility and sequence number assigment assignment procedures in an
            EVPN-IRB overlay that are required to address the scenarios described in section 4.
          </t> <t>
            section 7
            <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.
          </t> <t>
            section 8
	  </li>
          <li>
            <xref target="Duplicate-Host-Detection"/> describes corresponding
            duplicate detection procedures for EVPN-IRB and routed overlays.
          </t>
        </list>
        </t>
          </li>
        </ul>
      </section>
    </section>

    <section anchor="Req" title="Requirements Language and Terminology" numbered="true" toc="default">
      <name>Requirements Language and Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 [RFC2119] [RFC8174] BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
      <t>
      <list style="symbols"> <t> here.
        </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].
      </t><t>
         Underlay: IP, MPLS, or SRv6 fabric core network that provides routed reachability between EVPN PEs.
      </t><t>

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

   *  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 IPv6 protocol 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 [RFC8986].
      </t><t> [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].
      </t><t>
         VXLAN: Virtual

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 target="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 (as specified in [RFC7348]
      </t><t>
         MPLS: Multi-Protocol <xref target="RFC7348"/>).</dd>

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

         <dt>EVPN PE:</dt><dd>Ethernet VPN Provider Edge.  A PE switch-router
         switch router in an EVPN-IRB network that runs overlay BGP-EVPN
         control plane planes and connects to overlay CE host devices. An EVPN PE
         may also be the first-hop layer-3 L3 gateway for CE/host 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 ToR
         switching device (ToR) OR or at layer(s) above the ToR in the Clos fabric. An
         EVPN PE is typically also an IP or MPLS tunnel end-point endpoint for overlay
         VPN flow.
      </t><t>
         Symmetric EVPN-IRB: is a flows.</dd>

         <dt>Symmetric EVPN-IRB:</dt><dd>A specific design approach used in
         EVPN-based networks [RFC9135] <xref target="RFC9135"/> to handle both Layer 2 (L2) L2 and Layer 3 (L3) 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.
      </t><t>
         Asymmetric EVPN-IRB: is a traffic.</dd>

         <dt>Asymmetric EVPN-IRB:</dt><dd>A design approach used in EVPN-based
         networks [RFC9135] <xref target="RFC9135"/> to handle Layer 2 (L2) L2 and Layer 3 (L3) L3 forwarding. In
         this approach, only the ingress Provider Edge (PE) PE router performs routing for
         inter-subnet traffic, while the egress PE router performs bridging.
      </t><t>
         ARP: Address
         bridging.</dd>

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

         <dt>NDP:</dt><dd>Neighbor Discovery Protocol [RFC4861].
      </t><t>
         Ethernet-Segment: Physical (for IPv6 <xref target="RFC4861"/>).</dd>

         <dt>ES:</dt><dd>Ethernet Segment. A physical ethernet or LAG (Link Aggregation Group) port that
         connects an access device to an EVPN PE, as defined in [RFC7432].
      </t><t>
         MC-LAG: Multi-Chasis <xref
         target="RFC7432"/>.</dd>

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

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

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

         <dt>RT-5:</dt><dd>Route Type 5. EVPN route type 5 RT-5 carrying IP
         prefix reachability as specified in [RFC7432].
      </t><t>
         MAC-IP address: <xref target="RFC7432"/>.</dd>

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

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

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

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

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

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

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

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

	<t>In an EVPN-IRB scenario, 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 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> advertisements.</t>
      </section>

      <section anchor="Mobility-Use-Cases" title="Mobility Use Cases" numbered="true" toc="default">
        <t>
        <name>Mobility Use Cases</name>

        <t>This section outlines the IRB mobility use cases addressed in this
        document. Detailed procedures to handle these scenarios are provided
        in Sections <xref target="Methods-for-Sequence-Number-Assignment"
        format="counter"/> and <xref target="Routed-Overlay"
        format="counter"/>.</t>

<!-- [rfced] Section 3.2: May we add the following lead-in text to the list
below? The proposed text is from the same list in the Introduction.

Original:

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.
        </t> <t>
        <list style="symbols"> <t>

   *  A host move results in both the host's IP and MAC addresses moving
      together.
          </t> <t>

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

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

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" title="Host MAC+IP Address Move" numbered="true" toc="default">
          <t>
            This
          <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 [RFC7432] <xref target="RFC7432"/> can be leveraged to support this
          MAC+IP address mobility scenario.
          </t> scenario.</t>
        </section>

        <section anchor="Host-IP-Move-to-new-MAC" title="Host numbered="true" toc="default">
          <name>Host IP address Address Move to new New MAC address" numbered="true" toc="default">
          <t>
            This Address</name>

          <t>This scenario involves a host move where the host's IP address is
          reassigned to a new MAC address.
          </t> address.</t>

          <section anchor="Host-Reload" title="Host Reload" numbered="true" toc="default">
            <t>
              A
            <name>Host Reload</name>

            <t>A host reload or orchestrated move may cause a host to be
            re-spawned at the same or new PE location, resulting in a new MAC
            address assignment while retaining the existing IP address. This
            results in the host's IP address moving to a new MAC address
            binding, as shown below:
            </t>
            <t> below:</t>

            <artwork>
              IP-a, MAC-a ---> ---&gt; IP-a, MAC-b
            </t>
            </artwork>
          </section>

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

            <t>This scenario considers cases where multiple hosts, each with a
            unique IP address, share a common MAC address. A host move results
            in a new MAC address binding for the host IP address. For example,
            hosts running on a single physical server might share the same MAC
            address. Alternatively, an L2 access network behind a firewall may
            have all host IP addresses learned with a common firewall MAC
            address. In these "shared MAC" scenarios, multiple local MAC-IP
            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> IP.</t>
          </section>

          <section anchor="Problem" title="Problem" numbered="true" toc="default">
            <t>
              In
            <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>
            design.</t>
            <figure anchor="problem" title="" suppress-title="false" align="left" alt="" width="" height=""> anchor="problem">
              <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
                     +------------------------+
                     | Underlay Network Fabric|
                     +------------------------+

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

              </artwork>
]]></artwork>
            </figure>
            <t>
              Figure 1

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

        </section>
        <section anchor="Host-MAC-move-to-new-IP" title="Host numbered="true" toc="default">
          <name>Host MAC address move Address Move to new New IP address" numbered="true" toc="default">
          <t>
            This Address</name>

          <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, assigned while keeping the same MAC address.
          </t> address.</t>

          <section anchor="Problem-2" title="Problem" numbered="true" toc="default">
            <t>
              The
            <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> reachability.</t>

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

              </artwork>
]]></artwork>
            </figure>
            <t>
              For

            <t>For instance, consider that host IP1-M1 is learned locally at PE1 and
            PE2 and advertised to remote hosts with sequence number N. If this
            host with MAC address M1 is re-provisioned at Server2 and assigned
            a different IP address (e.g., IP7), then the new IP7-M1 route learned
            at PE3 and PE4 would be advertised with sequence number
            0. Consequently, L3 reachability to IP7 would be established
            across the overlay, but the MAC mobility procedure for M1 would
            not trigger due to the new MAC-IP route advertisement. Advertising
            an optional MAC-only route with its sequence number would trigger
            MAC mobility per [RFC7432]. <xref target="RFC7432"/>. However, without this
            additional advertisement, a single sequence number associated with
            a combined MAC+IP route may be insufficient to update MAC address
            reachability across the overlay.
            </t>
            <t>
              A overlay.</t>

            <t>A MAC-IP route sequence number assignment procedure is required
            to unambiguously determine the most recent MAC address
            reachability in such the previous scenarios without advertising a
            MAC-only route.
            </t>
            <t>
              Furthermore, PE1 and PE2, route.</t>

            <t>Furthermore, upon learning new reachability for IP7-M1 via PE3
            and PE4, PE1 and PE2 must probe and delete any local IPs
            associated with the MAC address M1, such as IP1-M1.
            </t>
            <t>
              It IP1-M1.</t>

            <t>It could be argued that the MAC mobility sequence number
            defined in [RFC7432] <xref target="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] <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> document.</t>
          </section>
        </section>
      </section>

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

              +-----+   +-----+       +-----+   +-----+
              | PE1 |   | PE2 |       | PE3 |   | PE4 |
              +-----+   +-----+       +-----+   +-----+
                \\         //           \\         //
                 \\ ESI-1 //             \\ ESI-2 //
                  \\     //               \\     //
                  +\\---//+               +\\---//+
                  | \\ // |               | \\ // |
                  +---+---+               +---+---+
                      |                       |
                     CEs                     CEs
          </artwork>
]]></artwork>
        </figure>
        <t>
          Consider
        <t>Consider an EVPN-IRB overlay network illustrated in Figure 3, <xref
        target="pece_link_failure"/>, where hosts are multi-homed to two or
        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 the multi-homing PE devices sharing this ES. This
        synchronization enables local switching of intra- and inter-subnet
        ECMP traffic flows from remote hosts. Thus, local MAC and ARP/NDP
        entries on a given ES may be learned through local learning and/or
        synchronization from another PE device sharing the same ES.
        </t>
        <t>
          For ES.</t>

        <t>For a host that is multi-homed to multiple PE devices via an
        all-active ES interface, the local learning of the host MAC and MAC-IP
        routes at each PE device is an independent asynchronous event,
        dependent on traffic flow or an ARP/NDP response from the host hashing to
        a directly connected PE on the MC-LAG interface. Consequently, the
        sequence number mobility attribute value assigned to a locally learned
        MAC or MAC-IP route at each device may not always be the same,
        depending on transient states on the device at the time of local learning.
        </t>
        <t>
          For
        learning.</t>

        <t>For example, consider a host that is deleted from ESI-2 and moved
        to ESI-1. It is possible for the host to be learned on PE1 following
        the deletion of the remote route from PE3 and PE4, PE4 while being learned
        on PE2 prior to the deletion of the remote route from PE3 and PE4. In
        this case, PE1 would process local host route learning as a new route
        and assign a sequence number of 0, while PE2 would process local host
        route learning as a remote-to-local move and assign a sequence number
        of N+1, where N is the existing sequence number assigned at PE3 and PE4.
        </t>
        <t>
          Inconsistent
        PE4.</t>

        <t>Inconsistent sequence numbers advertised from multi-homing devices:
          <list style="symbols"> <t>
              Creates devices:</t>

        <ul spacing="normal">
          <li>
            <t>Create ambiguity regarding how remote PEs should handle paths
            with the same ESI but different sequence numbers. A remote PE
            might not program ECMP paths if it receives routes with different
            sequence numbers from a set of multi-homing PEs sharing the same ESI.
            </t> <t>
              Breaks
            ESI.</t>
          </li>
          <li>
            <t>Break consistent route versioning across the network overlay
            that is needed for EVPN mobility procedures to work.
            </t>
          </list>
        </t>
        <t>
          For work.</t>
          </li>
        </ul>

        <t>For instance, in this inconsistent state, PE2 would drop a remote
        route received for the same host with sequence number N (since its
        local sequence number is N+1), while PE1 would install it as the best
        route (since its local sequence number is 0).
        </t>
        <t>
          To 0).</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> PEs.</t>
      </section>
    </section>

    <section anchor="Design-Considerations" title="Design Considerations" numbered="true" toc="default">
        <t>
          To
      <name>Design Considerations</name>
      <t>To summarize, the sequence number assignment scheme and
      implementation must consider the following:
          <list style="symbols"> <t>
              Synchronization Across Multi-Homing following:</t>
      <ul spacing="normal">
        <li>
          <t>Synchronization across multi-homing PE Devices: MAC+IP devices:</t>
	  <t>MAC+IP routes may be learned on an ES that is multi-homed to
	  multiple PE devices, requiring synchronized sequence numbers across
	  these devices.
            </t> <t>
              Optional MAC-Only RT-2: In devices.</t>
        </li>
        <li>
          <t>Optional MAC-only RT-2:</t>
	  <t>In an IRB scenario, MAC-only RT-2 is
          optional and may not be advertised alongside MAC+IP RT-2.
            </t> <t>
              Multiple RT-2.</t>
        </li>
        <li>
          <t>Multiple IPs Associated associated with a Single MAC: A single MAC:</t>
	  <t>A single MAC address may be linked to multiple IP addresses,
	  indicating multiple host IPs sharing a common MAC address.
            </t> <t>
              Host address.</t>
        </li>
        <li>
          <t>Host IP Movement: A movement:</t>
	  <t>A host IP address move may result in a new MAC
          address association, necessitating a new IP address to MAC address
          association and a new MAC+IP route.
            </t> <t>
              Host route.</t>
        </li>
        <li>
          <t>Host MAC Address Movement: A address movement:</t>
	  <t>A host MAC address move may result in a new IP address
	  association, requiring a new MAC address to IP address association and a new
	  MAC+IP route.
            </t> <t>
              Local route.</t>
        </li>
        <li>
          <t>Local MAC-IP Route Learning route learning via ARP/NDP: Local ARP/NDP:</t>
	  <t>Local MAC-IP route learning via ARP/NDP always accompanies a
	  local MAC route learning event resulting from the ARP/NDP
	  packet. However, MAC and MAC-IP route learning can occur in any order.
            </t> <t>
              Separate Sequence Numbers
	  order.</t>
        </li>
        <li>
          <t>Separate sequence numbers for MAC and IP routes: Use routes:</t>
	  <t>Use cases that do not maintain a constant 1:1 MAC-IP address
	  mapping across moves could potentially be addressed by using
	  separate sequence numbers for MAC and IP route components of the
	  MAC+IP route. However, maintaining two separate sequence numbers
	  adds significant complexity, debugging challenges, and backward
	  compatibility issues. Therefore, this document addresses these
	  requirements using a single sequence number attribute.
            </t>
          </list>
        </t> attribute.</t>
        </li>
      </ul>
    </section>

    <section anchor="Solution-Components" title="Solution Components" numbered="true" toc="default">
      <t>
        This
      <name>Solution Components</name>

      <t>This section outlines the main components of the EVPN-IRB mobility
      solution specified in this document. Subsequent sections will detail the
      exact sequence number assignment procedures based on the concepts
      described here.
      </t> here.</t>

      <section anchor="Sequence-Number-Inheritance" title="Sequence Number Inheritance" numbered="true" toc="default">
        <t>
          The
        <name>Sequence Number Inheritance</name>

        <t>The key concept presented here is to treat a local MAC-IP route as
        a child of the corresponding local MAC route within the local context
        of a PE. This ensures that the local MAC-IP route inherits the
        sequence number attribute from the parent local MAC-only route. In
        terms of object dependencies, this could be represented as the MAC-IP
        route being a dependent child of the parent MAC route:
        </t>
        <t> route:</t>

<artwork name="" type="" align="left" alt=""><![CDATA[
  Mx-IPx -----> Mx (seq# = N)
        </t>
        <t>
          Thus,
]]></artwork>

       <t>Thus, both the parent MAC route and the child MAC-IP routes share a
       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 [RFC7432]. <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 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. Implementation 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>
      </section>

      <section anchor="MAC-Sharing-2" title="MAC Address Sharing" numbered="true" toc="default">
        <t>
          For
        <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: route:</t>

        <figure anchor="mac_sharing" title="" suppress-title="false" align="left" alt="" width="" height=""> anchor="mac_sharing">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""> alt=""><![CDATA[
  Mx-IP1 -----
   |          |
  Mx-IP2 -----
    .         |
    .         +---> Mx (seq# = N)
    .         |
  Mx-IPw -----
    |         |
  Mx-IPx -----
          </artwork>
]]></artwork>
        </figure>
        </t> <t>
          In

<!-- [rfced] We have clarified "higher than N and the previous Mz sequence
number M" as follows. Please review and let us know if this update has
altered the intended meaning.

Original:

  If IPx moves to 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 the previous Mz sequence number M.

Current:

  If IPx moves to 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.

-->

        <t>In such cases, a host-IP move to a different physical server
        results in the IP moving to a new MAC address binding. A new MAC-IP
        route resulting from this move must be advertised with a sequence
        number higher than the previous MAC-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 moves to
        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 allows 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, IRB while clearing and withdrawing the stale Mx-IPx route
        with the lower sequence number.
        </t> <t>
          This 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. Implementation 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>
        children.</t>
      </section>

      <section anchor="Sequence-Number-Synchronization" title="Sequence Number Synchronization" numbered="true" toc="default">
        <t>
          To
        <name>Sequence Number Synchronization</name>
        <t>To support mobility for multi-homed hosts, local MAC and MAC-IP
        routes learned on a shared ES must be advertised with the same
        sequence number by all PE devices to which the ES is multi-homed. This
        applies to local MAC-only routes as well. MAC and MAC-IP routes for a
        host that is attached to a local ES may be learned natively via data
        plane and ARP/NDP ARP/NDP, respectively, as well as via BGP EVPN from another
        multi-homing PE to achieve local switching. MAC and MAC-IP routes learnt
        learned natively via data plane and ARP/NDP are respectively referred
        to as Local local MAC routes and Local local MAC-IP routes. BGP EVPN learnt learned MAC
        and MAC-IP routes for a host that is attached to a local ES are
        respectively referred to as Peer-Sync-Local MAC routes and
        Peer-Sync-Local MAC-IP routes as they are effectively local routes
        synchronized from a multi-homing peer. Local and Peer-Sync-Local route
        learning can occur in any order. Local MAC-IP routes advertised by all
        multi-homing PE devices sharing the ES must carry the same sequence
        number, independent of the order in which they are learned. This implies:
          <list style="symbols"> <t>
              On
        implies that:</t>

        <ul spacing="normal">
          <li>
            <t>On local or Peer-Sync-Local MAC-IP route learning, the sequence
            number for the local MAC-IP route must be compared and updated to
            the higher value.
            </t> <t>
              On value.</t>
          </li>
          <li>
            <t>On local or Peer-Sync-Local MAC route learning, the sequence
            number for the local MAC route must be compared and updated to the
            higher value.
            </t>
          </list>
        </t> <t>
          If 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
        local MAC-IP route.
        </t> route.</t>
      </section>
    </section>

<!-- [rfced] May we clarify "local and Peer-Sync-Local MAC and MAC-IP
route" as follows?

Original:

   The following sections specify the sequence number assignment
   procedures required for local and Peer-Sync-Local MAC and MAC-IP
   route learning events to achieve the objectives outlined.

Perhaps:

   The following sections specify the sequence number assignment
   procedures required for local MAC, local MAC-IP, Peer-Sync-Local MAC,
   and Peer-Sync-Local MAC-IP route learning events to achieve the
   outlined objectives.

-->

    <section anchor="Methods-for-Sequence-Number-Assignment" title="Methods numbered="true" toc="default">
      <name>Methods for Sequence Number Assignment" numbered="true" toc="default">
      <t>
        The Assignment</name>

      <t>The following sections specify the sequence number assignment
      procedures required for local and Peer-Sync-Local MAC and MAC-IP route
      learning events to achieve the objectives outlined.
      </t> outlined objectives.</t>

      <section anchor="Local-MAC-IP-learning" title="Local MAC-IP learning" numbered="true" toc="default">
        <t>
        <name>Local MAC-IP Learning</name>

<!-- [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 MUST
        <bcp14>MUST</bcp14> be computed as follows:
          <list style="symbols"> <t>
              MUST follows:</t>

        <ul spacing="normal">
          <li>It <bcp14>MUST</bcp14> be higher than any existing remote MAC route
          for Mx, as per [RFC7432].
            </t> <t>
              MUST <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.
            </t> <t>
              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," it MUST be higher than the "Mz" sequence number.
            </t>
          </list>
        </t> <t>
          Once "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 MUST
        <bcp14>MUST</bcp14> inherit the updated sequence number.
        </t> number.</t>
      </section>

      <section anchor="Local-MAC-learning" title="Local MAC learning" numbered="true" toc="default">
        <t>
          The
        <name>Local MAC Learning</name>
        <t>The local MAC route Mx Sequence sequence number MUST <bcp14>MUST</bcp14> be computed as follows:
          <list style="symbols"> <t>
              MUST follows:</t>

        <ul spacing="normal">
          <li>It <bcp14>MUST</bcp14> be higher than any existing remote MAC
          route for Mx, as per [RFC7432].
            </t> <t>
              MUST <xref target="RFC7432"/>.</li>

          <li>
	    <t>It <bcp14>MUST</bcp14> be at least equal to the corresponding
          Peer-Sync-Local MAC route sequence number if one is present. If present.</t>
	  <t>If the
          existing local MAC route sequence number is less than the
          Peer-Sync-Local MAC route sequence number, then the PE MUST
          <bcp14>MUST</bcp14> update the local MAC route sequence number to be
          equal to the Peer-Sync-Local MAC route sequence number. If number.</t>
	  <t>If the
          existing local MAC route sequence number is equal to or greater than
          the Peer-Sync-Local MAC route sequence number, no update is required
          to the local MAC route sequence number.
            </t>
          </list>
        </t> <t>
          Once number.</t></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 the MAC route
        Mx MUST <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 which case route. In
        this case, the above may not result in any change in the local MAC
        route sequence number.
        </t> number.</t>
      </section>

      <section anchor="Remote-MAC-OR-MAC-IP-Update" title="Remote numbered="true" toc="default">
        <name>Remote MAC or MAC-IP Route Update" numbered="true" toc="default">
        <t>
          Upon Update</name>

        <t>Upon receiving a remote MAC or MAC-IP route update associated with
        a MAC address Mx with a sequence number that is:
          <list style="symbols"> <t>
              Either higher is either:</t>

        <ul spacing="normal">
          <li>
            <t>higher than the sequence number assigned to a local
            route for MAC Mx,
            </t> <t>
              Or equal Mx or</t>
          </li>
          <li>
	    <t>equal to the sequence number assigned to a local route for MAC
	    Mx, but the remote route is selected as best due to a lower VTEP VXLAN
	    Tunnel End Point (VTEP) IP as per [RFC7432],
            </t>
          </list>
          the <xref target="RFC7432"/>,</t>
          </li>
        </ul>

        <t>the following actions are REQUIRED <bcp14>REQUIRED</bcp14> on the receiving PE:
          <list style="symbols"> <t>
              The
        PE:</t>

        <ul spacing="normal">
          <li>
            <t>The PE MUST <bcp14>MUST</bcp14> trigger a probe and deletion
            procedure for all local MAC-IP routes associated with MAC Mx.
            </t> <t>
              The Mx.</t>
          </li>
          <li>
            <t>The PE MUST <bcp14>MUST</bcp14> trigger a deletion procedure for the
            local MAC route for Mx.
            </t>
          </list>
        </t> Mx.</t>
          </li>
        </ul>
      </section>

      <section anchor="Peer-Sync-MAC-update" title="Peer-Sync-Local MAC route update" numbered="true" toc="default">
        <t>
          Upon
        <name>Peer-Sync-Local MAC Route Update</name>

        <t>Upon receiving a Peer-Sync-Local MAC route, the corresponding local
        MAC route Mx sequence number (if present) should be re-computed as follows:
          <list style="symbols"> <t>
              If
        follows:</t>
        <ul spacing="normal">
          <li>
            <t>If the current sequence number is less than the received
            Peer-Sync-Local MAC route sequence number, it MUST <bcp14>MUST</bcp14>
            be increased to be equal to the received Peer-Sync-Local MAC route
            sequence number.
            </t> <t>
              If number.</t>
          </li>
          <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 MUST
            <bcp14>MUST</bcp14> inherit the updated sequence number.
            </t>
          </list>
        </t> number.</t>
          </li>
        </ul>
      </section>

      <section anchor="Peer-Sync-MAC-IP-update" title="Peer-Sync-Local MAC-IP route update" numbered="true" toc="default">
        <t>
          Receiving
        <name>Peer-Sync-Local MAC-IP Route Update</name>

        <t>Because the MAC-only RT-2 advertisement is optional, receiving a
        Peer-Sync-Local MAC-IP route for a locally attached host results in a
        derived Peer-Sync-Local MAC Mx route entry as the MAC-only RT-2 advertisement is optional. entry. The corresponding local MAC
        Mx route sequence number (if present) should be re-computed as follows:
          <list style="symbols"> <t>
              If
        follows:</t>

        <ul spacing="normal">
          <li>
            <t>If the current sequence number is less than the received
            Peer-Sync-Local MAC route sequence number, it MUST <bcp14>MUST</bcp14>
            be increased to be equal to the received Peer-Sync-Local MAC route
            sequence number.
            </t> <t>
              If number.</t>
          </li>
          <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 MUST
            <bcp14>MUST</bcp14> inherit the updated sequence number.
            </t>
          </list>
        </t> number.</t>
          </li>
        </ul>
      </section>

      <section anchor="Inter-Op" title="Interoperability" numbered="true" toc="default">
        <t>
          Generally,
        <name>Interoperability</name>

        <t>Generally, if all PE nodes in the overlay network follow the above
        sequence number assignment procedures and the PE is advertising both
        MAC+IP and MAC routes, the sequence numbers advertised with the MAC
        and MAC+IP routes with the same MAC address would always be the
        same. However, an interoperability scenario with a different
        implementation could arise, where a non-compliant PE implementation
        assigns and advertises independent sequence numbers to MAC and MAC+IP
        routes. To handle this case, if different sequence numbers are
        received for remote MAC+IP routes and corresponding remote MAC routes
        from a remote PE, the sequence number associated with the remote MAC
        route <bcp14>MUST</bcp14> be computed and interpreted as:</t>

<!--[rfced] The following list reads awkwardly. May we rephrase the list
items so that they each describe the way a sequence number from the remote
MAC route should be handled?

Original:

   To handle this case, if different sequence numbers are received for
   remote MAC+IP routes and corresponding remote MAC routes from a
   remote PE, the sequence number associated with the remote MAC route
   MUST be computed and interpreted as:
          <list style="symbols"> <t>

   *  The highest of all received sequence numbers with remote MAC+IP
      and MAC routes with the same MAC address.
            </t> <t>

   *  The MAC route sequence number would be re-computed on a MAC or
      MAC+IP route withdraw as per the above.
            </t>
          </list>
        </t> <t>
          A

Perhaps:

   To handle this case, if different sequence numbers are received for
   remote MAC+IP routes and corresponding remote MAC routes from a
   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
        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 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> address.</t>

      </section>

      <section anchor="MAC-Sharing-Race-Condition" title="MAC numbered="true" toc="default">
        <name>MAC Address Sharing Race Condition" numbered="true" toc="default">
        <t>
          In Condition</name>
        <t>In a MAC address sharing use case described in section 5.2, <xref
        target="MAC-Sharing-2"/>, a race condition is possible with
        simultaneous host moves between a pair of PEs. Example The example scenario below
        illustrates this race condition and its remediation:
          <list style="symbols"> <t>
              PE1 remediation:</t>

        <ul spacing="normal">
          <li>
            <t>PE1 with locally attached host IPs I1 and I2 that share MAC
            address M1. PE1 as As a result result, PE1 has local MAC-IP routes I1-M1 and I2-M1.
            </t> <t>
              PE2
            I2-M1.</t>
          </li>
          <li>
            <t>PE2 with locally attached host IPs I3 and I4 that share MAC
            address M2. PE2 as As a result result, PE2 has local MAC-IP routes I3-M2 and I4-M2.
            </t> <t>
              A
            I4-M2.</t>
          </li>
          <li>
            <t>A simultaneous move of I1 from PE1 to PE2 and of I3 from PE2 to
            PE1 will cause I1's MAC address to change from M1 to M2 and cause
            I3's MAC address to change from M2 to M1.
            </t> <t>
              Route M1.</t>
          </li>
          <li>
            <t>Route I3-M1 may be learnt learned on PE1 before I1's local entry I1-M1
            has been probed out on PE1 and/or route I1-M2 may be learnt learned on PE2
            before I3's local entry I3-M2 has been probed out on PE2.
            </t> <t>
              In PE2.</t>
          </li>
          <li>
	    <t>In such a scenario, MAC route sequence number assignment rules
            defined in section 6.1 <xref target="Local-MAC-IP-learning"/> will cause new mac-ip
            MAC-IP routes I1-M2 and I3-M1 to bounce between PE1 and PE2 with seuence
            sequence number increments until stale entries I1-M1 and I3-M2
            have been probed out from PE1 and PE2 respectively.
            </t>
          </list>
        </t> <t>
          An PE2, respectively.</t>
          </li>
        </ul>
        <t>An implementation MUST <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 section 6.3 <xref
        target="Remote-MAC-OR-MAC-IP-Update"/> (and as per [RFC9135]) <xref
        target="RFC9135"/>) to minimize exposure to this race condition.
        </t> condition.</t>
      </section>

      <section anchor="Mobility-Convergence" title="Mobility Convergence" numbered="true" toc="default">
        <t>
          This
        <name>Mobility Convergence</name>

        <t>This section is optional and details ARP and NDP probing procedures
        that MAY <bcp14>MAY</bcp14> be implemented to achieve faster host re-learning
        relearning and convergence on mobility events. PE1 and PE2 are used
        as two example PEs in the network to illustrate the mobility
        convergence scenarios in this section.
          <list style="symbols"> <t>
              Following section.</t>

        <ul spacing="normal">
          <li>
            <t>Following a host move from PE1 to PE2, the host's MAC address
            is discovered 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 <bcp14>MAY</bcp14> be
            triggered at PE2 to learn the MAC-IP address as a local adjacency
            and trigger EVPN RT-2 advertisement for this MAC-IP address across
            the overlay with new reachability via PE2. This results in a
            reliable "event-based" host IP learning triggered by a "MAC
            address learning event" across the overlay, and hence hence, a faster
            convergence of overlay routed flows to the host.
            </t> <t>
              Following host.</t>
          </li>
          <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 MAY <bcp14>MAY</bcp14> be triggered at PE1 to clear the stale
            local MAC-IP neighbor adjacency or to re-learn relearn the local MAC-IP in
            case the host has moved back or is duplicated.

            </t> <t>
              Following 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 MAY
            <bcp14>MAY</bcp14> be triggered for this IP to either re-learn 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>
          </list>
        </t> location.</t>
          </li>
        </ul>

        <section anchor="Generalized-Probing-Logic" title="Generalized Probing Logic" numbered="true" toc="default">
          <t>
            The
          <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 section 5.1 MAY <xref target="Sequence-Number-Inheritance"/>
          <bcp14>MAY</bcp14> be used to achieve this logic.
          </t> logic.</t>

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

    <section anchor="Routed-Overlay" title="Routed Overlay" numbered="true" toc="default">
      <t>
        An
      <name>Routed Overlay</name>

      <t>An additional use case involves traffic to an end host in the overlay
      being entirely IP routed. In such a purely routed overlay:
          <list style="symbols"> <t>
              A overlay:</t>

      <ul spacing="normal">
        <li>
          <t>A host MAC route is never advertised in the EVPN overlay control plane.
            </t> <t>
              Host plane.</t>
        </li>
        <li>
          <t>Host /32 or /128 IP reachability is distributed across the
          overlay via EVPN Route Type 5 (RT-5) along with a zero or non-zero ESI.
            </t> <t>
              An
          ESI.</t>
        </li>
        <li>
          <t>An overlay IP subnet may still be stretched across the underlay
          fabric. However, intra-subnet traffic across the stretched overlay
          is never bridged.
            </t> <t>
              Both bridged.</t>
        </li>
        <li>
          <t>Both inter-subnet and intra-subnet traffic in the overlay is IP routed at the EVPN PE.
            </t>
          </list>
      </t> <t>
        Please PE.</t>
        </li>
      </ul>

      <t>Please refer to [RFC7814] <xref target="RFC7814"/> for more details.
      </t> <t>
        Host details.</t>

      <t>Host mobility within the stretched subnet still needs support. In the
      absence of host MAC routes, the sequence number mobility Extended
      Community specified in [RFC7432] section 7.7 MAY <xref target="RFC7432" sectionFormat="of"
      section="7.7"/> <bcp14>MAY</bcp14> be associated with a /32 or /128 host
      IP prefix advertised via EVPN Route Type 5. MAC mobility procedures
      defined in [RFC7432] <xref target="RFC7432"/> can be applied to host IP prefixes
      as follows:
          <list style="symbols"> <t>
              On follows:</t>

      <ul spacing="normal">
        <li>
          <t>On local learning of a host IP on a new ESI, the host IP MUST
          <bcp14>MUST</bcp14> be advertised with a sequence number higher than
          what is currently advertised with the old ESI.
            </t> <t>
              On ESI.</t>
        </li>
        <li>
          <t>On receiving a host IP route advertisement with a higher sequence
          number, a PE MUST <bcp14>MUST</bcp14> trigger ARP/NDP probe and deletion
          procedures on any local route for that IP with a lower sequence
          number. The PE will update the forwarding entry to point to the
          remote route with a higher sequence number and send an ARP/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.
            </t>
          </list>
      </t> <t>
        Note 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 address.</t>

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

    </section>
    <section anchor="Duplicate-Host-Detection" title="Duplicate Host Detection" numbered="true" toc="default">
      <t>
        Duplicate
      <name>Duplicate Host Detection</name>

      <t>Duplicate host detection scenarios across EVPN-IRB can be classified as follows:
        <list style="symbols"> <t>
            Scenario follows:</t>

      <ul spacing="normal">
        <li>
          <t>Scenario A: Two hosts have the same MAC address (host IPs may or may not be duplicates).
          </t> <t>
            Scenario duplicates).</t>
        </li>
        <li>
          <t>Scenario B: Two hosts have the same IP address but different MAC addresses.
          </t> <t>
            Scenario addresses.</t>
        </li>
        <li>
          <t>Scenario C: Two hosts have the same IP address, and the host MAC address is not advertised.
          </t>
        </list>
      </t> <t>
        As advertised.</t>
        </li>
      </ul>
      <t>As specified in [RFC9161], Duplicate <xref target="RFC9161"/>, duplicate detection
      procedures for Scenarios B and C do not apply to "anycast IPv6" "anycast" IPv6 hosts
      advertised via NA messages with the Override Flag (O Flag) set to 0.
      </t> 0.</t>

      <section anchor="Scenario-A" title="Scenario A" numbered="true" toc="default">
        <t>
          In
        <name>Scenario A</name>

	<t>In cases where duplicate hosts share the same MAC address, the MAC
	address is detected as duplicate using the duplicate MAC address
	detection procedure described in [RFC7432]. <xref
	target="RFC7432"/>. Corresponding MAC-IP routes with the same MAC
	address do not require separate duplicate detection and MUST
	<bcp14>MUST</bcp14> inherit the duplicate property from the MAC
	route. If a MAC route is marked as duplicate, all associated MAC-IP
	routes MUST <bcp14>MUST</bcp14> also be treated as duplicates. Duplicate
	detection procedures need only be applied to MAC routes.
        </t> routes.</t>
      </section>

      <section anchor="Scenario-B" title="Scenario B" numbered="true" toc="default">
        <t>
          Misconfigurations
        <name>Scenario B</name>

        <t>Misconfigurations may lead to different MAC addresses being
        assigned the same IP address. This scenario is not detected by [RFC7432] the
        duplicate MAC address detection procedures from <xref
        target="RFC7432"/> and can result in incorrect routing of traffic
        destined for the IP address.
        </t> <t>
          Such address.</t>

        <t>Such situations, when detected locally, are identified as a move
        scenario through the local MAC route sequence number computation
        procedure described in section 6.1:
          <list style="symbols"> <t>
              If <xref target="Local-MAC-IP-learning"/>:</t>

        <ul spacing="normal">
          <li>
            <t>If the IP is associated with a different remote MAC "Mz," "Mz", the
            sequence number MUST <bcp14>MUST</bcp14> be higher than the "Mz"
            sequence number.
            </t>
          </list>
        </t> <t>
          This number.</t>
          </li>
        </ul>

        <t>This move results in a sequence number increment for the local MAC
        route due to the remote MAC-IP route being associated with a different MAC
        address, counting which counts as an "IP move" against the IP, independent of the
        MAC. The duplicate detection procedure described in [RFC7432] <xref
        target="RFC7432"/> can then be applied to the IP entity independent 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 routes related to this MAC should not be affected.
        </t> affected.</t>

        <section anchor="Duplicate-IP-Detection-Procedure-for-Scenario-B" title="Duplicate numbered="true" toc="default">
          <name>Duplicate IP Detection Procedure for Scenario B" numbered="true" toc="default">
        <t>
          The B</name>

          <t>The duplicate IP detection procedure for this scenario is
          specified in [RFC9161]. <xref target="RFC9161"/>. An "IP move" is further
          clarified as follows:
          <list style="symbols"> <t>
              Upon follows:</t>
          <ul spacing="normal">

            <li>
              <t>Upon learning a local MAC-IP route Mx-IPx, check for existing
              remote or local routes for IPx with a different MAC address
              association (Mz-IPx). If found, count this as an "IP move" for
              IPx, independent of the MAC.
            </t> <t>
              Upon MAC.</t>
            </li>
            <li>
              <t>Upon learning a remote MAC-IP route Mz-IPx, check for
              existing local routes for IPx with a different MAC address
              association (Mx-IPx). If found, count this as an "IP move" for
              IPx, independent of the MAC.
            </t>
          </list>
        </t> <t>
          A MAC.</t>
            </li>
          </ul>

          <t>A MAC-IP route MUST <bcp14>MUST</bcp14> be treated as duplicate if either:
          <list style="symbols"> <t>
              The either:</t>

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

        </section>
      </section>

      <section anchor="Scenario-C" title="Scenario C" numbered="true" toc="default">
        <t>
          In
        <name>Scenario C</name>

        <t>As described in <xref target="Routed-Overlay"/>, in a purely routed
        overlay scenario, as described in section 7, scenario where only a host IP is advertised via EVPN RT-5 with
        a sequence number mobility attribute, procedures similar to the
        duplicate MAC address detection procedures specified in [RFC7432] <xref
        target="RFC7432"/> can be applied to
        IP-only host routes for duplicate IP detection as follows:
          <list style="symbols"> <t>
              Upon follows:</t>

        <ul spacing="normal">
          <li>
            <t>Upon learning a local host IP route IPx, check for existing
            remote or local routes for IPx with a different ESI
            association. If found, count this as an "IP move" for IPx.
            </t> <t>
              Upon IPx.</t>
          </li>
          <li>
            <t>Upon learning a remote host IP route IPx, check for existing
            local routes for IPx with a different ESI association. If found,
            count this as an "IP move" for IPx.
            </t> <t>
              Using IPx.</t>
          </li>
          <li>
            <t>Using configurable parameters "N" and "M," "M", if "N" IP moves are
            detected within "M" seconds for IPx, then IPx should be treated as duplicate.
            </t>
          </list>
        </t>
            duplicate.</t>
          </li>
        </ul>
      </section>

      <section anchor="Duplicate-Host-Recovery" title="Duplicate Host Recovery" numbered="true" toc="default">
        <t>
          Once
        <name>Duplicate Host Recovery</name>

	<t>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. Un-provisioning refers to corrective action taken
        on the host side. Following this correction, normal operation will not
        resume until the duplicate MAC or IP address ages out out, unless
        additional action is taken to expedite recovery.
        </t> <t>
          Possible recovery.</t>

        <t>Possible additional corrective actions for faster recovery include:
        </t> are
        outlined in the following sections.</t>

        <section anchor="Route-Un-freezing-Configuration" title="Route Un-freezing Configuration" numbered="true" toc="default">
          <t>
          <name>Route Unfreezing Configuration</name>

          <t>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. Unfreezing the MAC or IP route should result in advertising
          it with a sequence number higher than that advertised from the other location.
          </t> <t>
            Two
          location.</t>

          <t>Two scenarios exist:
            <list style="symbols"> <t>
                Scenario exist:</t>

          <ul spacing="normal">
            <li>
              <t>Scenario A: The duplicate MAC or IP address is un-provisioned
              at the location where it was not marked as duplicate.
              </t> <t>
                Scenario duplicate.</t>
            </li>
            <li>
              <t>Scenario B: The duplicate MAC or IP address is un-provisioned
              at the location where it was marked as duplicate.
              </t>
            </list>
          </t> <t>
            Unfreezing duplicate.</t>
            </li>
          </ul>
          <t>Unfreezing the duplicate and frozen MAC or IP route will result
          in recovery to a steady state as follows:
            <list style="symbols"> <t>
                Scenario follows:</t>

          <ul spacing="normal">
            <li>
              <t>Scenario A: If the duplicate MAC or IP address is
              un-provisioned at the non-duplicate location, unfreezing the
              route at the frozen location results in advertising with a
              higher sequence number, leading to automatic clearing of the
              local route at the un-provisioned location via ARP/NDP PROBE and
              DELETE procedures.
              </t> <t>
                Scenario procedures.</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 re-learning relearning and clearing of the local route
              at the original location upon receiving the remote route advertisement.
              </t>
            </list>
            Probes
              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>
          independently.</t>
        </section>

        <section anchor="Route-Clearing-Configuration" title="Route Clearing Configuration" numbered="true" toc="default">
          <t>
            In

          <name>Route Clearing Configuration</name>
          <t>In addition to the above, route clearing CLIs may be used to
          clear the local MAC or IP route after the duplicate host is un-provisioned:
            <list style="symbols"> <t>
                Clear
          un-provisioned:</t>

          <ul spacing="normal">
            <li>
              <t>Clear MAC CLI: Used to clear a duplicate MAC route.
              </t> <t>
                Clear route.</t>
            </li>
            <li>
              <t>Clear ARP/NDP: Used to clear a duplicate IP route.
              </t>
            </list>
          </t> <t>
            The route.</t>
            </li>
          </ul>

          <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> optional.</t>
        </section>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations" numbered="true" toc="default">
      <t>
        Security
      <name>Security Considerations</name>

      <t>The security considerations discussed in [RFC7432] <xref target="RFC7432"/> and [RFC9135]
      <xref target="RFC9135"/> apply to this document. Methods described in
      this document further extend the consumption of sequence numbers for IRB
      deployments. They Hence, they are hence subject to the same considerations if the
      control plane or data plane was to be compromised. As an example, if host facing the
      host-facing data plane is compromised, spoofing attempts could result in
      a legitimate host being perceived as moved, eventually resulting in the
      host being marked as duplicate. Considerations The considerations for protecting control
      and data plane planes described in [RFC7432] <xref target="RFC7432"/> are equally
      applicable to such mobility spoofing use cases.
      </t> cases.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations" numbered="true" toc="default">
      <t>
        No
      <name>IANA Considerations</name>
      <t>This document has no IANA actions required.
      </t>
    </section>
    <section anchor="Contributors" title="Contributors" numbered="true" toc="default">
      <author fullname="Gunter van de Velde">
        <organization>Nokia</organization>
        <address>
          <email>van_de_velde@nokia.com</email>
        </address>
      </author>
      <author fullname="Wen Lin">
        <organization>Juniper</organization>
        <address>
          <email>wlin@juniper.net</email>
        </address>
      </author>
      <author fullname="Sonal Agarwal">
        <organization>Arrcus</organization>
        <address>
          <email>sonal@arrcus.com</email>
        </address>
      </author> 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.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9161.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9135.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7814.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements" numbered="true" numbered="false" toc="default">
      <t>
        Authors
      <name>Acknowledgements</name>
      <t>The authors would like to thank Gunter van <contact fullname="Gunter Van de Velde
      Velde"/> for the significant contribution contributions to improve the readability of this
      document. Authors The authors would also like to thank Sonal Agarwal <contact fullname="Sonal
      Agarwal"/> and Larry Kreeger <contact fullname="Larry Kreeger"/> for multiple
      contributions through the implementation process. Authors The authors would like to
      thank Vibov Bhan and Patrice Brissette <contact fullname="Vibov Bhan"/> and <contact fullname="Patrice
      Brissette"/> for early feedback during the implementation and testing of
      several procedures defined in this document. Authors The authors would like to
      thank Wen Lin <contact fullname="Wen Lin"/> for a detailed review and valuable
      comments related to MAC sharing race conditions. Authors The authors would also
      like to thank Saumya Dikshit <contact fullname="Saumya Dikshit"/> for a detailed review
      and valuable comments across the document.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <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 signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, 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="editor">
            <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>

    <section anchor="Contributors" numbered="false" toc="default">
      <name>Contributors</name>
      <author initials="J." surname="Uttaro" fullname="J. Uttaro">
            <organization/> fullname="Gunter Van de Velde">
        <organization>Nokia</organization>
        <address>
          <email>van_de_velde@nokia.com</email>
        </address>
      </author>
      <author initials="J." surname="Drake" fullname="J. Drake">
            <organization/> fullname="Wen Lin">
        <organization>Juniper</organization>
        <address>
          <email>wlin@juniper.net</email>
        </address>
      </author>
      <author initials="W." surname="Henderickx" fullname="W. Henderickx">
            <organization/> fullname="Sonal Agarwal">
        <organization>Arrcus</organization>
        <address>
          <email>sonal@arrcus.com</email>
        </address>
      </author>
          <date year="2015" month="February"/>
          <abstract>
            <t>This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN).  The procedures described here meet
    </section>
  </back>
</rfc>

<!-- [rfced] Please review the requirements specified following questions and changes regarding the
abbreviations used 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 this document. Per Section 3.6 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 RFC 7322 ("RFC Style
Guide"), abbreviations should be expanded upon first use.

a.) How may we expand "CLI" 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 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 elect designated forwarder (DF) at recover from the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case duplicate and frozen state following
   corrective un-provisioning of VLAN bundle the duplicate MAC or VLAN-aware bundle service).  However, IP address.

b.) FYI - We have already expanded the following abbreviations upon first use.
Please review each expansion in the current level of granularity of per-VLAN is not adequate for some of applications.  [RFC8584] improves base line DF election. This document is an extension carefully to HRW base drafts ([I-D.ietf-bess-evpn-ac-df] ensure correctness.

Media Access Control (MAC)
MAC Virtual Routing and [I-D.ietf-bess-evpn-df-election]) Forwarding (MAC-VRF)
IP Virtual Routing and further enhances HRW algorithm to do DF election at 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 granularity "Inclusive Language" portion 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 the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of Uppercase vs Lowercase this nature typically
result in RFC 2119 Key Words</title>
          <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 more precise language, which is helpful for readers.

For example, please consider whether "natively" should be used updated 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 Solution</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
instances below:

...for a BGP/MPLS IP VPN-based subnet extension solution referred host that is attached to as "Virtual Subnet", which can a local ES may be used for building Layer 3 network virtualization overlays within and/or between learned natively via...
...routes learnt natively via 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/rfc8986/">
        <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 plane 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/rfc8926/">
        <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>
</rfc> ARP/NDP are respectively...

-->