rfc9721.original   rfc9721.txt 
BESS WorkGroup N. Malhotra, Ed. Internet Engineering Task Force (IETF) N. Malhotra, Ed.
Internet-Draft A. Sajassi Request for Comments: 9721 A. Sajassi
Intended status: Standards Track A. Pattekar Category: Standards Track A. Pattekar
Expires: 7 June 2025 Cisco Systems ISSN: 2070-1721 Cisco Systems
J. Rabadan J. Rabadan
Nokia Nokia
A. Lingala A. Lingala
AT&T AT&T
J. Drake J. Drake
Juniper Networks Independent
4 December 2024 April 2025
Extended Mobility Procedures for EVPN-IRB Extended Mobility Procedures for Ethernet VPN Integrated Routing and
draft-ietf-bess-evpn-irb-extended-mobility-21 Bridging (EVPN-IRB)
Abstract Abstract
This document specifies extensions to Ethernet VPN (EVPN) Integrated This document specifies extensions to the Ethernet VPN Integrated
Routing and Bridging (IRB) procedures specified in RFC7432 and Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and
RFC9135 to enhance the mobility mechanisms for EVPN-IRB based 9135 to enhance the mobility mechanisms for networks based on EVPN-
networks. The proposed extensions improve the handling of host IRB. The proposed extensions improve the handling of host mobility
mobility and duplicate address detection in EVPN-IRB networks to and duplicate address detection in EVPN-IRB networks to cover a
cover a broader set of scenarios where a host's unicast IP address to broader set of scenarios where a host's unicast IP address to Media
MAC address bindings may change across moves. These enhancements Access Control (MAC) address bindings may change across moves. These
address limitations in the existing EVPN-IRB mobility procedures by enhancements address limitations in the existing EVPN-IRB mobility
providing more efficient and scalable solutions. The extensions are procedures by providing more efficient and scalable solutions. The
backward compatible with existing EVPN-IRB implementations and aim to extensions are backward compatible with existing EVPN-IRB
optimize network performance in scenarios involving frequent IP implementations and aim to optimize network performance in scenarios
address mobility. involving frequent IP address mobility.
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&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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9721.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 5 1.1. Document Structure
2. Requirements Language and Terminology . . . . . . . . . . . . 5 2. Requirements Language and Terminology
3. Background and Problem Statement . . . . . . . . . . . . . . 7 2.1. Abbreviations
3.1. Optional MAC only RT-2 . . . . . . . . . . . . . . . . . 7 2.2. Definitions
3.2. Mobility Use Cases . . . . . . . . . . . . . . . . . . . 7 3. Background and Problem Statement
3.2.1. Host MAC+IP Address Move . . . . . . . . . . . . . . 8 3.1. Optional MAC-Only RT-2
3.2.2. Host IP address Move to new MAC address . . . . . . . 8 3.2. Mobility Use Cases
3.2.2.1. Host Reload . . . . . . . . . . . . . . . . . . . 8 3.2.1. Host MAC+IP Address Move
3.2.2.2. MAC Address Sharing . . . . . . . . . . . . . . . 8 3.2.2. Host IP Address Move to New MAC Address
3.2.2.3. Problem . . . . . . . . . . . . . . . . . . . . . 8 3.2.2.1. Host Reload
3.2.3. Host MAC address move to new IP address . . . . . . . 9 3.2.2.2. MAC Address Sharing
3.2.3.1. Problem . . . . . . . . . . . . . . . . . . . . . 10 3.2.2.3. Problem
3.3. EVPN All Active multi-homed ES . . . . . . . . . . . . . 11 3.2.3. Host MAC Address Move to New IP Address
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 3.2.3.1. Problem
5. Solution Components . . . . . . . . . . . . . . . . . . . . . 13 3.3. EVPN All Active Multi-Homed ES
5.1. Sequence Number Inheritance . . . . . . . . . . . . . . . 13 4. Design Considerations
5.2. MAC Address Sharing . . . . . . . . . . . . . . . . . . . 14 5. Solution Components
5.3. Sequence Number Synchronization . . . . . . . . . . . . . 15 5.1. Sequence Number Inheritance
6. Methods for Sequence Number Assignment . . . . . . . . . . . 16 5.2. MAC Address Sharing
6.1. Local MAC-IP learning . . . . . . . . . . . . . . . . . . 16 5.3. Sequence Number Synchronization
6.2. Local MAC learning . . . . . . . . . . . . . . . . . . . 16 6. Methods for Sequence Number Assignment
6.3. Remote MAC or MAC-IP Route Update . . . . . . . . . . . . 17 6.1. Local MAC-IP Learning
6.4. Peer-Sync-Local MAC route update . . . . . . . . . . . . 17 6.2. Local MAC Learning
6.5. Peer-Sync-Local MAC-IP route update . . . . . . . . . . . 18 6.3. Remote MAC or MAC-IP Route Update
6.6. Interoperability . . . . . . . . . . . . . . . . . . . . 18 6.4. Peer-Sync-Local MAC Route Update
6.7. MAC Address Sharing Race Condition . . . . . . . . . . . 19 6.5. Peer-Sync-Local MAC-IP Route Update
6.8. Mobility Convergence . . . . . . . . . . . . . . . . . . 19 6.6. Interoperability
6.8.1. Generalized Probing Logic . . . . . . . . . . . . . . 20 6.7. MAC Address Sharing Race Condition
7. Routed Overlay . . . . . . . . . . . . . . . . . . . . . . . 20 6.8. Mobility Convergence
8. Duplicate Host Detection . . . . . . . . . . . . . . . . . . 21 6.8.1. Generalized Probing Logic
8.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 22 7. Routed Overlay
8.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 22 8. Duplicate Host Detection
8.2.1. Duplicate IP Detection Procedure for Scenario B . . . 23 8.1. Scenario A
8.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Scenario B
8.4. Duplicate Host Recovery . . . . . . . . . . . . . . . . . 24 8.2.1. Duplicate IP Detection Procedure for Scenario B
8.4.1. Route Un-freezing Configuration . . . . . . . . . . . 24 8.3. Scenario C
8.4.2. Route Clearing Configuration . . . . . . . . . . . . 25 8.4. Duplicate Host Recovery
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.4.1. Route Unfreezing Configuration
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.4.2. Route Clearing Configuration
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References
13.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgements
Contributors
Authors' Addresses
1. Introduction 1. Introduction
EVPN-IRB facilitates the advertisement of both MAC and IP routes via 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 a single MAC+IP Route Type 2 (RT-2) advertisement. The MAC address
is integrated into the local MAC-VRF bridge table, enabling Layer 2 is integrated into the local MAC Virtual Routing and Forwarding (MAC-
(L2) bridged traffic across the network overlay. The IP address is VRF) bridge table, enabling Layer 2 (L2) bridged traffic across the
incorporated into the local ARP/NDP table in an asymmetric IRB network overlay. The IP address is incorporated into the local
design, or into the IP-VRF routing table in a symmetric IRB design, Address Resolution Protocol (ARP) / Neighbor Discovery Protocol (NDP)
facilitating routed traffic across the network overlay. For table in an asymmetric IRB design or into the IP Virtual Routing and
Forwarding (IP-VRF) routing table in a symmetric IRB design. This
facilitates routed traffic across the network overlay. For
additional context on EVPN-IRB forwarding modes, refer to [RFC9135]. additional context on EVPN-IRB forwarding modes, refer to [RFC9135].
To support the EVPN mobility procedure, a single sequence number To support the EVPN mobility procedure, a single sequence number
mobility attribute is advertised with the combined MAC+IP route. mobility attribute is advertised with the combined MAC+IP route.
This approach, which resolves both MAC and IP reachability with a This approach, which resolves both MAC and IP reachability with a
single sequence number, inherently assumes a fixed 1:1 mapping single sequence number, inherently assumes a fixed 1:1 mapping
between IP address and MAC address. While this fixed 1:1 mapping is between an IP address and MAC address. While this fixed 1:1 mapping
a common use case and is addressed via the existing mobility is a common use case and is addressed via the existing mobility
procedure defined in [RFC7432], there are additional IRB scenarios procedure defined in [RFC7432], there are additional IRB scenarios
that do not adhere to this assumption. Such scenarios are prevalent that do not adhere to this assumption. Such scenarios are prevalent
in virtualized host environments where hosts connected to an EVPN in virtualized host environments where hosts connected to an EVPN
network are virtual machines (VMs) or containerized workloads. The network are Virtual Machines (VMs) or containerized workloads. The
following IRB mobility scenarios are considered: following IRB mobility scenarios are considered:
* A host move results in the host's IP address and MAC address * A host move results in the host's IP address and MAC address
moving together. moving together.
* A host move results in the host's IP address moving to a new MAC * A host move results in the host's IP address moving to a new MAC
address association. address association.
* A host move results in the host's MAC address moving to a new IP * A host move results in the host's MAC address moving to a new IP
address association. address association.
While the existing mobility procedure can manage the MAC+IP address While the existing mobility procedure can manage the MAC+IP address
move in the first scenario, the subsequent scenarios lead to new MAC- move in the first scenario, the subsequent scenarios lead to new MAC-
IP address associations. Therefore, a single sequence number IP address associations. Therefore, a single sequence number
assigned independently per-{MAC address, IP address} is insufficient assigned independently for each {MAC address, IP address} is
to determine the most recent reachability for both MAC address and IP insufficient to determine the most recent reachability for both MAC
address unless the sequence number assignment algorithm allows for address and IP address, unless the sequence number assignment
changing MAC-IP address bindings across moves. algorithm allows for changing MAC-IP address bindings across moves.
This document updates the sequence number assignment procedures This document updates the sequence number assignment procedures
defined in [RFC7432] to adequately address mobility support across defined in [RFC7432] to 1) adequately address mobility support across
EVPN-IRB overlay use cases that permit MAC-IP address bindings to EVPN-IRB overlay use cases that permit MAC-IP address bindings to
change across host moves and support mobility for both MAC and IP 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. route components carried in an EVPN RT-2 for these use cases.
Additionally, for hosts on an ESI multi-homed to multiple PE devices, Additionally, for hosts on an Ethernet Segment Identifier (ESI) that
additional procedures are specified to ensure synchronized sequence is multi-homed to multiple Provider Edge (PE) devices, additional
number assignments across the multi-homing devices. procedures are specified to ensure synchronized sequence number
assignments across the multi-homing devices.
This document addresses mobility for the following cases, independent This document addresses mobility for the following cases, independent
of the overlay encapsulation (e.g., MPLS, SRv6, NVO Tunnel): of the overlay encapsulation (e.g., MPLS, Segment Routing over IPv6
(SRv6), and Network Virtualization Overlay (NVO) tunnel):
* Symmetric EVPN-IRB overlay * Symmetric EVPN-IRB overlay
* Asymmetric EVPN-IRB overlay * Asymmetric EVPN-IRB overlay
* Routed EVPN overlay * Routed EVPN overlay
1.1. Document Structure 1.1. Document Structure
Following sections of the document are informative: The following sections of the document are informative:
* section 3 provides the necessary background and problem statement * Section 3 provides the necessary background and problem statement
being addressed in this document. being addressed in this document.
* section 4 lists the resulting design considerations for the * Section 4 lists the resulting design considerations for the
document. document.
* section 5 lists the main solution components that are foundational * Section 5 lists the main solution components that are foundational
for the sepecifications that follow in subsequent sections. for the specifications that follow in subsequent sections.
Following sections of the document are normative: The following sections of the document are normative:
* section 6 describes the mobility and sequence number assigment * Section 6 describes the mobility and sequence number assignment
procedures in an EVPN-IRB overlay required to address the procedures in an EVPN-IRB overlay that are required to address the
scenarios described in section 4. scenarios described in Section 4.
* section 7 describes the mobility procedures for a routed overlay * Section 7 describes the mobility procedures for a routed overlay
network as opposed to an IRB overlay. network as opposed to an IRB overlay.
* section 8 describes corresponding duplicate detection procedures * Section 8 describes corresponding duplicate detection procedures
for EVPN-IRB and routed overlays. for EVPN-IRB and routed overlays.
2. Requirements Language and Terminology 2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
* EVPN-IRB: A BGP-EVPN distributed control plane based integrated 2.1. Abbreviations
routing and bridging fabric overlay discussed in [RFC9135].
* Underlay: IP, MPLS, or SRv6 fabric core network that provides ARP: Address Resolution Protocol [RFC0826]. ARP references in this
routed reachability between EVPN PEs. document are equally applicable to both ARP and NDP.
* Overlay: L3 and L2 Virtual Private Network (VPN) enabled via NVO3, CE: Customer Edge.
VXLAN, SRv6, or MPLS service layer encapsulation.
* SRv6: Segment Routing IPv6 protocol as specified in [RFC8986]. ES: Ethernet Segment. A physical ethernet or LAG port that connects
an access device to an EVPN PE, as defined in [RFC7432].
* NVO3: Network Virtualization Overlays as specified in [RFC8926]. EVPN PE: Ethernet VPN Provider Edge. A PE switch router in an EVPN-
IRB network that runs overlay BGP-EVPN control planes and connects
to overlay CE host devices. An EVPN PE may also be the first-hop
L3 gateway for CE host devices. This document refers to EVPN PE
as a logical function in an EVPN-IRB network. This EVPN PE
function may be physically hosted on a ToR switching device or at
layer(s) above the ToR in the Clos fabric. An EVPN PE is
typically also an IP or MPLS tunnel endpoint for overlay VPN
flows.
* VXLAN: Virtual eXtensible Local Area Network as specified in EVPN-IRB: Ethernet VPN Integrated Routing and Bridging. A BGP-EVPN
[RFC7348] distributed control plane that is based on the integrated routing
and bridging fabric overlay discussed in [RFC9135].
* MPLS: Multi-Protocol Label Switching as specified in [RFC3031]. L2: Layer 2.
* EVPN PE: A PE switch-router in an EVPN-IRB network that runs L3: Layer 3.
overlay BGP-EVPN control plane and connects to overlay CE host
devices. An EVPN PE may also be the first-hop layer-3 gateway for
CE/host devices. This document refers to EVPN PE as a logical
function in an EVPN-IRB network. This EVPN PE function may be
physically hosted on a top-of-rack switching device (ToR) OR at
layer(s) above the ToR in the Clos fabric. An EVPN PE is
typically also an IP or MPLS tunnel end-point for overlay VPN
flow.
* Symmetric EVPN-IRB: is a specific design approach used in EVPN- LAG: Link Aggregation Group.
based networks [RFC9135] to handle both Layer 2 (L2) and Layer 3
(L3) forwarding within the same network infrastructure. The key
characteristic of symmetric EVPN-IRB is that both ingress and
egress PE routers perform routing for inter-subnet traffic.
* Asymmetric EVPN-IRB: is a design approach used in EVPN-based MC-LAG: Multi-Chassis Link Aggregation Group.
networks [RFC9135] to handle Layer 2 (L2) and Layer 3 (L3)
forwarding. In this approach, only the ingress Provider Edge (PE)
router performs routing for inter-subnet traffic, while the egress
PE router performs bridging.
* ARP: Address Resolution Protocol [RFC826]. ARP references in this MPLS: Multiprotocol Label Switching (as specified in [RFC3031]).
document are equally applicable to both ARP and NDP.
* NDP: IPv6 Neighbor Discovery Protocol [RFC4861]. NDP: Neighbor Discovery Protocol (for IPv6 [RFC4861]).
* Ethernet-Segment: Physical ethernet or LAG (Link Aggregation NVO: Network Virtualization Overlay.
Group) port that connects an access device to an EVPN PE, as
defined in [RFC7432].
* MC-LAG: Multi-Chasis Link Aggregation Group. NVO3: Network Virtualization over Layer 3 (as specified in
[RFC8926]).
* EVPN all-active multi-homing: is a redundancy and load-sharing PE: Provider Edge.
mechanism used in EVPN networks. This method allows multiple PE
devices to simultaneously provide Layer 2 and Layer 3 connectivity
to a single CE device or network segment.
* RT-2: EVPN route type 2 carrying both MAC address and IP address RT-2: Route Type 2. EVPN RT-2 carrying both MAC address and IP
reachability as specified in [RFC7432]. address reachability as specified in [RFC7432].
* RT-5: EVPN route type 5 carrying IP prefix reachability as RT-5: Route Type 5. EVPN RT-5 carrying IP prefix reachability as
specified in [RFC7432]. specified in [RFC9136].
* MAC-IP address: IPv4 and/or IPv6 address and MAC address binding SRv6: Segment Routing over IPv6 (as specified in [RFC8986]).
for an overlay host.
* Peer-Sync-Local MAC route: BGP EVPN learnt MAC route for a host ToR: Top-of-Rack.
that is directly attached to a local multi-homed Ethernet Segment.
* Peer-Sync-Local MAC-IP route: BGP EVPN learnt MAC-IP route for a VM: Virtual Machine (or containerized workloads).
host that is directly attached to a local multi-homed Ethernet
Segment.
* Peer-Sync-Local MAC sequence number: Sequence number received with VXLAN: Virtual eXtensible Local Area Network (as specified in
a Peer-Sync-Local MAC route. [RFC7348]).
* Peer-Sync-Local MAC-IP sequence number: Sequence number received 2.2. Definitions
Asymmetric EVPN-IRB: A design approach used in EVPN-based networks
[RFC9135] to handle L2 and L3 forwarding. In this approach, only
the ingress PE router performs routing for inter-subnet traffic,
while the egress PE router performs bridging.
EVPN all-active multi-homing: A redundancy and load-sharing
mechanism used in EVPN networks. This method allows multiple PE
devices to simultaneously provide L2 and L3 connectivity to a
single CE device or network segment.
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.
MAC-IP address: The IPv4 and/or IPv6 address and MAC address binding
for an overlay host.
Overlay: L2 and L3 VPNs that are enabled via NVO3, VXLAN, SRv6, or
MPLS service-layer encapsulation.
Peer-Sync-Local MAC-IP route: The learned BGP EVPN MAC-IP route for
a host that is directly attached to a local multi-homed ES.
Peer-Sync-Local MAC-IP sequence number: The sequence number received
with a Peer-Sync-Local MAC-IP route. with a Peer-Sync-Local MAC-IP route.
* VM: Virtual Machine or containerized workloads. Peer-Sync-Local MAC route: The learned BGP EVPN MAC route for a host
that is directly attached to a local multi-homed ES.
* Host: Host in this document generically refers to any user/CE Peer-Sync-Local MAC sequence number: The sequence number received
endpoint attached to an EVPN-IRB network which may be a VM, with a Peer-Sync-Local MAC route.
containerized workload or a physical end-point or CE device.
Symmetric EVPN-IRB: A specific design approach used in EVPN-based
networks [RFC9135] to handle both L2 and L3 forwarding within the
same network infrastructure. The key characteristic of symmetric
EVPN-IRB is that both ingress and egress PE routers perform
routing for inter-subnet traffic.
Underlay: An IP, MPLS, or SRv6 fabric core network that provides
routed reachability between EVPN PEs.
3. Background and Problem Statement 3. Background and Problem Statement
3.1. Optional MAC only RT-2 3.1. Optional MAC-Only RT-2
In an EVPN-IRB scenario, where a single MAC+IP RT-2 advertisement In an EVPN-IRB scenario where a single MAC+IP RT-2 advertisement
carries both IP and MAC routes, a MAC-only RT-2 advertisement becomes 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. redundant for host MAC addresses already advertised via MAC+IP RT-2.
Consequently, the advertisement of a local MAC-only RT-2 is optional Consequently, the advertisement of a local MAC-only RT-2 is optional
at an EVPN PE. This consideration is important for mobility at an EVPN PE. This consideration is important for mobility
scenarios discussed in subsequent sections. It is noteworthy that a scenarios discussed in subsequent sections. It is noteworthy that a
local MAC route and its assigned sequence number are still maintained local MAC route and its assigned sequence number are still maintained
locally on a PE, and only the advertisement of this route to other locally on a PE, and only the advertisement of this route to other
PEs is optional. PEs is optional.
MAC-only RT-2 advertisements may still be issued for non-IP host MAC 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. addresses that are not included in MAC+IP RT-2 advertisements.
3.2. Mobility Use Cases 3.2. Mobility Use Cases
This section outlines the IRB mobility use cases addressed in this This section outlines the IRB mobility use cases addressed in this
document. Detailed procedures to handle these scenarios are provided document. Detailed procedures to handle these scenarios are provided
in Sections 6 and 7. in Sections 6 and 7. The following IRB mobility scenarios are
considered:
* A host move results in both the host's IP and MAC addresses moving * A host move results in both the host's IP and MAC addresses moving
together. together.
* A host move results in the host's IP address moving to a new MAC * A host move results in the host's IP address moving to a new MAC
address association. address association.
* A host move results in the host's MAC address moving to a new IP * A host move results in the host's MAC address moving to a new IP
address association. address association.
3.2.1. Host MAC+IP Address Move 3.2.1. Host MAC+IP Address Move
This is the baseline scenario where a host move results in both the 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- host's MAC and IP addresses moving together without altering the MAC-
IP address binding. The existing MAC route mobility procedures IP address binding. The existing MAC route mobility procedures
defined in [RFC7432] can be leveraged to support this MAC+IP address defined in [RFC7432] can be leveraged to support this MAC+IP address
mobility scenario. mobility scenario.
3.2.2. Host IP address Move to new MAC address 3.2.2. Host IP Address Move to New MAC Address
This scenario involves a host move where the host's IP address is This scenario involves a host move where the host's IP address is
reassigned to a new MAC address. reassigned to a new MAC address.
3.2.2.1. Host Reload 3.2.2.1. Host Reload
A host reload or orchestrated move may cause a host to be re-spawned 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 at the same or new PE location, resulting in a new MAC address
assignment while retaining the existing IP address. This results in assignment while retaining the existing IP address. This results in
the host's IP address moving to a new MAC address binding, as shown the host's IP address moving to a new MAC address binding, as shown
below: below:
IP-a, MAC-a ---> IP-a, MAC-b IP-a, MAC-a ---> IP-a, MAC-b
3.2.2.2. MAC Address Sharing 3.2.2.2. MAC Address Sharing
This scenario considers cases where multiple hosts, each with a This scenario considers cases where multiple hosts, each with a
unique IP address, share a common MAC address. A host move results 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, 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 hosts running on a single physical server might share the same MAC
address. Alternatively, an L2 access network behind a firewall may address. Alternatively, an L2 access network behind a firewall may
have all host IP addresses learned with a common firewall MAC have all host IP addresses learned with a common firewall MAC
address. In these "shared MAC" scenarios, multiple local MAC-IP ARP/ address. In these "shared MAC" scenarios, multiple local MAC-IP ARP/
skipping to change at page 9, line 39 skipping to change at line 422
If VM-IP1 moves to Server-M2, ARP or NDP-based local learning at PE3 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 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 assigned a sequence number of 0, the mobility procedure for VM-IP1
will not trigger across the overlay network. will not trigger across the overlay network.
A sequence number assignment procedure must be defined to A sequence number assignment procedure must be defined to
unambiguously determine the most recent IP address reachability, IP- unambiguously determine the most recent IP address reachability, IP-
to-MAC address binding, and MAC address reachability for such MAC to-MAC address binding, and MAC address reachability for such MAC
address sharing scenarios. address sharing scenarios.
3.2.3. Host MAC address move to new IP address 3.2.3. Host MAC Address Move to New IP Address
This is a scenario where a host move or re-provisioning behind the 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 same or new PE location may result in the host getting a new IP
address assigned, while keeping the same MAC address. address assigned while keeping the same MAC address.
3.2.3.1. Problem 3.2.3.1. Problem
The complication in this scenario arises because MAC address The complication in this scenario arises because MAC address
reachability can be carried via a combined MAC+IP route, whereas a reachability can be carried via a combined MAC+IP route, whereas a
MAC-only route may not be advertised. Associating a single sequence MAC-only route may not be advertised. Associating a single sequence
number with the MAC+IP route implicitly assumes a fixed MAC-to-IP 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 mapping. A MAC address move that results in a new IP address
association breaks this assumption and creates a new MAC+IP route. association breaks this assumption and creates a new MAC+IP route.
If this new route independently receives a new sequence number, the If this new route independently receives a new sequence number, the
skipping to change at page 10, line 36 skipping to change at line 459
+\---/+ +\---/+ +\---/+ +\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / | | \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
Server1 Server2 Server3 Server1 Server2 Server3
| | | | | |
IP1-M1, IP2-M2 IP3-M3, IP4-M4 IP5-M5, IP6-M6 IP1-M1, IP2-M2 IP3-M3, IP4-M4 IP5-M5, IP6-M6
Figure 2 Figure 2
For instance, consider host IP1-M1 learned locally at PE1 and PE2 and For instance, consider that host IP1-M1 is learned locally at PE1 and
advertised to remote hosts with sequence number N. If this host with PE2 and advertised to remote hosts with sequence number N. If this
MAC address M1 is re-provisioned at Server2 and assigned a different host with MAC address M1 is re-provisioned at Server2 and assigned a
IP address (e.g., IP7), the new IP7-M1 route learned at PE3 and PE4 different IP address (e.g., IP7), then the new IP7-M1 route learned
would be advertised with sequence number 0. Consequently, L3 at PE3 and PE4 would be advertised with sequence number 0.
reachability to IP7 would be established across the overlay, but the Consequently, L3 reachability to IP7 would be established across the
MAC mobility procedure for M1 would not trigger due to the new MAC-IP overlay, but the MAC mobility procedure for M1 would not trigger due
route advertisement. Advertising an optional MAC-only route with its to the new MAC-IP route advertisement. Advertising an optional MAC-
sequence number would trigger MAC mobility per [RFC7432]. However, only route with its sequence number would trigger MAC mobility per
without this additional advertisement, a single sequence number [RFC7432]. However, without this additional advertisement, a single
associated with a combined MAC+IP route may be insufficient to update sequence number associated with a combined MAC+IP route may be
MAC address reachability across the overlay. insufficient to update MAC address reachability across the overlay.
A MAC-IP route sequence number assignment procedure is required to A MAC-IP route sequence number assignment procedure is required to
unambiguously determine the most recent MAC address reachability in unambiguously determine the most recent MAC address reachability in
such scenarios without advertising a MAC-only route. the previous scenarios without advertising a MAC-only route.
Furthermore, PE1 and PE2, upon learning new reachability for IP7-M1 Furthermore, upon learning new reachability for IP7-M1 via PE3 and
via PE3 and PE4, must probe and delete any local IPs associated with PE4, PE1 and PE2 must probe and delete any local IPs associated with
MAC address M1, such as IP1-M1. the MAC address M1, such as IP1-M1.
It could be argued that the MAC mobility sequence number defined in It could be argued that the MAC mobility sequence number defined in
[RFC7432] applies only to the MAC route part of a MAC-IP route, thus [RFC7432] applies only to the MAC route part of a MAC-IP route, thus
covering this scenario. This interpretation could serve as a covering this scenario. This interpretation could serve as a
clarification to [RFC7432] and supports the need for a common clarification to [RFC7432] and supports the need for a common
sequence number assignment procedure across all MAC-IP mobility sequence number assignment procedure across all MAC-IP mobility
scenarios detailed in this document. scenarios detailed in this document.
3.3. EVPN All Active multi-homed ES 3.3. EVPN All Active Multi-Homed ES
+------------------------+ +------------------------+
| Underlay Network Fabric| | Underlay Network Fabric|
+------------------------+ +------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE3 | | PE4 | | PE1 | | PE2 | | PE3 | | PE4 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\\ // \\ // \\ // \\ //
\\ ESI-1 // \\ ESI-2 // \\ ESI-1 // \\ ESI-2 //
skipping to change at page 12, line 6 skipping to change at line 518
hosts are multi-homed to two or more PE devices via an all-active 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 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 also be synchronized across the multi-homing PE devices sharing this
ES. This synchronization enables local switching of intra- and ES. This synchronization enables local switching of intra- and
inter-subnet ECMP traffic flows from remote hosts. Thus, local MAC inter-subnet ECMP traffic flows from remote hosts. Thus, local MAC
and ARP/NDP entries on a given ES may be learned through local and ARP/NDP entries on a given ES may be learned through local
learning and/or synchronization from another PE device sharing the learning and/or synchronization from another PE device sharing the
same ES. same ES.
For a host that is multi-homed to multiple PE devices via an all- For a host that is multi-homed to multiple PE devices via an all-
active ES interface, the local learning of host MAC and MAC-IP routes active ES interface, the local learning of the host MAC and MAC-IP
at each PE device is an independent asynchronous event, dependent on routes at each PE device is an independent asynchronous event,
traffic flow or ARP/NDP response from the host hashing to a directly dependent on traffic flow or an ARP/NDP response from the host
connected PE on the MC-LAG interface. Consequently, the sequence hashing to a directly connected PE on the MC-LAG interface.
number mobility attribute value assigned to a locally learned MAC or Consequently, the sequence number mobility attribute value assigned
MAC-IP route at each device may not always be the same, depending on to a locally learned MAC or MAC-IP route at each device may not
transient states on the device at the time of local learning. always be the same, depending on transient states on the device at
the time of local learning.
For example, consider a host that is deleted from ESI-2 and moved to 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 ESI-1. It is possible for the host to be learned on PE1 following
the deletion of the remote route from PE3 and PE4, while being the deletion of the remote route from PE3 and PE4 while being learned
learned on PE2 prior to the deletion of the remote route from PE3 and on PE2 prior to the deletion of the remote route from PE3 and PE4.
PE4. In this case, PE1 would process local host route learning as a In this case, PE1 would process local host route learning as a new
new route and assign a sequence number of 0, while PE2 would process 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 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 sequence number of N+1, where N is the existing sequence number
assigned at PE3 and PE4. assigned at PE3 and PE4.
Inconsistent sequence numbers advertised from multi-homing devices: Inconsistent sequence numbers advertised from multi-homing devices:
* Creates ambiguity regarding how remote PEs should handle paths * Create ambiguity regarding how remote PEs should handle paths with
with the same ESI but different sequence numbers. A remote PE the same ESI but different sequence numbers. A remote PE might
might not program ECMP paths if it receives routes with different not program ECMP paths if it receives routes with different
sequence numbers from a set of multi-homing PEs sharing the same sequence numbers from a set of multi-homing PEs sharing the same
ESI. ESI.
* Breaks consistent route versioning across the network overlay that * Break consistent route versioning across the network overlay that
is needed for EVPN mobility procedures to work. is needed for EVPN mobility procedures to work.
For instance, in this inconsistent state, PE2 would drop a remote For instance, in this inconsistent state, PE2 would drop a remote
route received for the same host with sequence number N (since its 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 local sequence number is N+1), while PE1 would install it as the best
route (since its local sequence number is 0). route (since its local sequence number is 0).
To support mobility for multi-homed hosts using the sequence number To support mobility for multi-homed hosts using the sequence number
mobility attribute, local MAC and MAC-IP routes learned on a multi- 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 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 devices to which the ES is multi-homed. There is a need for a
mechanism to ensure the consistency of sequence numbers assigned mechanism to ensure the consistency of sequence numbers assigned
across these PEs. across these PEs.
4. Design Considerations 4. Design Considerations
To summarize, the sequence number assignment scheme and To summarize, the sequence number assignment scheme and
implementation must consider the following: implementation must consider the following:
* Synchronization Across Multi-Homing PE Devices: MAC+IP routes may * Synchronization across multi-homing PE devices:
be learned on an ES multi-homed to multiple PE devices, requiring
synchronized sequence numbers across these devices.
* Optional MAC-Only RT-2: In an IRB scenario, MAC-only RT-2 is MAC+IP routes may be learned on an ES that is multi-homed to
optional and may not be advertised alongside MAC+IP RT-2. multiple PE devices, requiring synchronized sequence numbers
across these devices.
* Multiple IPs Associated with a Single MAC: A single MAC address * Optional MAC-only RT-2:
may be linked to multiple IP addresses, indicating multiple host
IPs sharing a common MAC address.
* Host IP Movement: A host IP address move may result in a new MAC In an IRB scenario, MAC-only RT-2 is optional and may not be
address association, necessitating a new IP address to MAC address advertised alongside MAC+IP RT-2.
association and a new MAC+IP route.
* Host MAC Address Movement: A host MAC address move may result in a * Multiple IPs associated with a single MAC:
new IP address association, requiring a new MAC to IP address
A single MAC address may be linked to multiple IP addresses,
indicating multiple host IPs sharing a common MAC address.
* Host IP movement:
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. association and a new MAC+IP route.
* Local MAC-IP Route Learning via ARP/NDP: Local MAC-IP route * Host MAC address movement:
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.
* Separate Sequence Numbers for MAC and IP routes: Use cases that do A host MAC address move may result in a new IP address
not maintain a constant 1:1 MAC-IP address mapping across moves association, requiring a new MAC address to IP address association
could potentially be addressed by using separate sequence numbers and a new MAC+IP route.
for MAC and IP route components of the MAC+IP route. However,
maintaining two separate sequence numbers adds significant * Local MAC-IP route learning via ARP/NDP:
complexity, debugging challenges, and backward compatibility
issues. Therefore, this document addresses these requirements Local MAC-IP route learning via ARP/NDP always accompanies a local
using a single sequence number attribute. MAC route learning event resulting from the ARP/NDP packet.
However, MAC and MAC-IP route learning can occur in any order.
* Separate sequence numbers for MAC and IP routes:
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.
5. Solution Components 5. Solution Components
This section outlines the main components of the EVPN-IRB mobility This section outlines the main components of the EVPN-IRB mobility
solution specified in this document. Subsequent sections will detail solution specified in this document. Subsequent sections will detail
the exact sequence number assignment procedures based on the concepts the exact sequence number assignment procedures based on the concepts
described here. described here.
5.1. Sequence Number Inheritance 5.1. Sequence Number Inheritance
The key concept presented here is to treat a local MAC-IP route as a 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 child of the corresponding local MAC route within the local context
of a PE. This ensures that the local MAC-IP route inherits the of a PE. This ensures that the local MAC-IP route inherits the
sequence number attribute from the parent local MAC-only route. In sequence number attribute from the parent local MAC-only route. In
terms of object dependencies, this could be represented as MAC-IP terms of object dependencies, this could be represented as the MAC-IP
route being a dependent child of the parent MAC route: route being a dependent child of the parent MAC route:
Mx-IPx -----> Mx (seq# = N) Mx-IPx -----> Mx (seq# = N)
Thus, both the parent MAC route and child MAC-IP routes share a Thus, both the parent MAC route and the child MAC-IP routes share a
common sequence number associated with the parent MAC route. This common sequence number associated with the parent MAC route. This
ensures that a single sequence number attribute carried in a combined ensures that a single sequence number attribute carried in a combined
MAC+IP route represents the sequence number for both a MAC-only route 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 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 truly optional. This enables a MAC address to assume a different IP
address upon moving and still establish the most recent reachability address upon moving and still establish the most recent reachability
to the MAC address across the overlay network via the mobility to the MAC address across the overlay network via the mobility
attribute associated with the MAC+IP route advertisement. For attribute associated with the MAC+IP route advertisement. For
instance, when Mx moves to a new location, it would be assigned a instance, when Mx moves to a new location, it would be assigned a
higher sequence number at its new location per [RFC7432]. If this higher sequence number at its new location per [RFC7432]. If this
move results in Mx assuming a different IP address, IPz, the local move results in Mx assuming a different IP address, IPz, the local
Mx+IPz route would inherit the new sequence number from Mx. Mx+IPz route would inherit the new sequence number from Mx.
Local MAC and local MAC-IP routes are typically sourced from data Local MAC and local MAC-IP routes are typically sourced from data
plane learning and ARP/NDP learning, respectively, and can be learned plane learning and ARP/NDP learning, respectively, and can be learned
in the control plane in any order. Implementation can either in the control plane in any order. Implementations can either
replicate the inherited sequence number in each MAC-IP entry or replicate the inherited sequence number in each MAC-IP entry or
maintain a single attribute in the parent MAC route by creating a maintain a single attribute in the parent MAC route by creating a
forward reference local MAC object for cases where a local MAC-IP forward reference local MAC object for cases where a local MAC-IP
route is learned before the local MAC route. route is learned before the local MAC route.
5.2. MAC Address Sharing 5.2. MAC Address Sharing
For the shared MAC address scenario, multiple local MAC-IP sibling For the shared MAC address scenario, multiple local MAC-IP sibling
routes inherit the sequence number attribute from the common parent routes inherit the sequence number attribute from the common parent
MAC route: MAC route:
skipping to change at page 15, line 6 skipping to change at line 675
Figure 4 Figure 4
In such cases, a host-IP move to a different physical server results 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 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 resulting from this move must be advertised with a sequence number
higher than the previous MAC-IP route for this IP, advertised from higher than the previous MAC-IP route for this IP, advertised from
the prior location. For example, consider a route Mx-IPx currently the prior location. For example, consider a route Mx-IPx currently
advertised with sequence number N from PE1. If IPx moves to a new 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 physical server behind PE2 and is associated with MAC Mz, the new
local Mz-IPx route must be advertised with a sequence number higher local Mz-IPx route must be advertised with a sequence number higher
than N and the previous Mz sequence number M. This allows PE than N and higher than the previous Mz sequence number M. This
devices, including PE1, PE2, and other remote PE devices, to allows PE devices, including PE1, PE2, and other remote PE devices,
determine and program the most recent MAC address binding and to determine and program the most recent MAC address binding and
reachability for the IP. PE1, upon receiving this new Mz-IPx route 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 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 IPx reachability via PE2 for symmetric IRB and update IPx's ARP/NDP
binding to Mz for asymmetric IRB, while clearing and withdrawing the binding to Mz for asymmetric IRB while clearing and withdrawing the
stale Mx-IPx route with the lower sequence number. stale Mx-IPx route with the lower sequence number.
This implies that the sequence number associated with local MAC route This implies that the sequence number associated with the local MAC
Mz and all local MAC-IP child routes of Mz at PE2 must be incremented route Mz and all local MAC-IP child routes of Mz at PE2 must be
to N+1 or M+1 if the previous Mz sequence number M is greater than N incremented to N+1 or M+1 if the previous Mz sequence number M is
and re-advertised across the overlay. While this re-advertisement of greater than N and is re-advertised across the overlay. While this
all local MAC-IP children routes affected by the parent MAC route re-advertisement of all local MAC-IP children routes affected by the
adds overhead, it avoids the need for maintaining and advertising two parent MAC route adds overhead, it also avoids the need for
separate sequence number attributes for IP and MAC route components maintaining and advertising two separate sequence number attributes
of MAC+IP RT-2. Implementation must be able to look up MAC-IP routes for IP and MAC route components of MAC+IP RT-2. Implementations must
for a given IP and update the sequence number for its parent MAC be able to look up MAC-IP routes for a given IP and update the
route and its MAC-IP route children. sequence number for its parent MAC route and for its MAC-IP route
children.
5.3. Sequence Number Synchronization 5.3. Sequence Number Synchronization
To support mobility for multi-homed hosts, local MAC and MAC-IP To support mobility for multi-homed hosts, local MAC and MAC-IP
routes learned on a shared ES must be advertised with the same 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. 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 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 for a host that is attached to a local ES may be learned via data
data plane and ARP/NDP respectively, as well as via BGP EVPN from plane and ARP/NDP, respectively, as well as via BGP EVPN from another
another multi-homing PE to achieve local switching. MAC and MAC-IP multi-homing PE to achieve local switching. MAC and MAC-IP routes
routes learnt natively via data plane and ARP/NDP are respectively learned via data plane and ARP/NDP are respectively referred to as
referred to as Local MAC routes and Local MAC-IP routes. BGP EVPN local MAC routes and local MAC-IP routes. BGP EVPN learned MAC and
learnt MAC and MAC-IP routes for a host that is attached to a local MAC-IP routes for a host that is attached to a local ES are
ES are respectively referred to as Peer-Sync-Local MAC routes and respectively referred to as Peer-Sync-Local MAC routes and Peer-Sync-
Peer-Sync-Local MAC-IP routes as they are effectively local routes Local MAC-IP routes as they are effectively local routes synchronized
synchronized from a multi-homing peer. Local and Peer-Sync-Local from a multi-homing peer. Local and Peer-Sync-Local route learning
route learning can occur in any order. Local MAC-IP routes can occur in any order. Local MAC-IP routes advertised by all multi-
advertised by all multi-homing PE devices sharing the ES must carry homing PE devices sharing the ES must carry the same sequence number,
the same sequence number, independent of the order in which they are independent of the order in which they are learned. This implies
learned. This implies: that:
* On local or Peer-Sync-Local MAC-IP route learning, the sequence * 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 number for the local MAC-IP route must be compared and updated to
the higher value. the higher value.
* On local or Peer-Sync-Local MAC route learning, the sequence * On local or Peer-Sync-Local MAC route learning, the sequence
number for the local MAC route must be compared and updated to the number for the local MAC route must be compared and updated to the
higher value. higher value.
If an update to the local MAC-IP route sequence number is required as 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 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 essentially amounts to a sequence number update on the parent local
MAC route, resulting in an inherited sequence number update on the MAC route, resulting in an inherited sequence number update on the
Local MAC-IP route. local MAC-IP route.
6. Methods for Sequence Number Assignment 6. Methods for Sequence Number Assignment
The following sections specify the sequence number assignment The following sections specify the sequence number assignment
procedures required for local and Peer-Sync-Local MAC and MAC-IP procedures required for local MAC, local MAC-IP, Peer-Sync-Local MAC,
route learning events to achieve the objectives outlined. and Peer-Sync-Local MAC-IP route learning events to achieve the
outlined objectives.
6.1. Local MAC-IP learning 6.1. Local MAC-IP Learning
A local Mx-IPx learning via ARP or NDP should result in the 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 computation or re-computation of the parent MAC route Mx's sequence
number, following which the MAC-IP route Mx-IPx inherits the parent number. After this, the MAC-IP route Mx-IPx inherits the parent MAC
MAC route's sequence number. The parent MAC route Mx sequence number route's sequence number. The parent MAC route Mx sequence number
MUST be computed as follows: MUST be computed as follows:
* MUST be higher than any existing remote MAC route for Mx, as per * It MUST be higher than any existing remote MAC route for Mx, as
[RFC7432]. per [RFC7432].
* MUST be at least equal to the corresponding Peer-Sync-Local MAC * It MUST be at least equal to the corresponding Peer-Sync-Local MAC
route sequence number, if present. route sequence number, if present.
* If the IP is also associated with a different remote MAC "Mz," it * It MUST be higher than the "Mz" sequence number if the IP is also
MUST be higher than the "Mz" sequence number. associated with a different remote MAC "Mz".
Once the new sequence number for MAC route Mx is computed as per the Once the new sequence number for the MAC route Mx is computed as per
above criteria, all local MAC-IP routes associated with MAC Mx MUST the above criteria, all local MAC-IP routes associated with MAC Mx
inherit the updated sequence number. MUST inherit the updated sequence number.
6.2. Local MAC learning 6.2. Local MAC Learning
The local MAC route Mx Sequence number MUST be computed as follows: The local MAC route Mx sequence number MUST be computed as follows:
* MUST be higher than any existing remote MAC route for Mx, as per * It MUST be higher than any existing remote MAC route for Mx, as
[RFC7432]. per [RFC7432].
* MUST be at least equal to the corresponding Peer-Sync-Local MAC * It MUST be at least equal to the corresponding Peer-Sync-Local MAC
route sequence number if one is present. If the existing local route sequence number if one is present.
MAC route sequence number is less than the Peer-Sync-Local MAC
route sequence number, PE MUST update the local MAC route sequence
number to be equal to the Peer-Sync-Local MAC route sequence
number. 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.
Once the new sequence number for MAC route Mx is computed as per the If the existing local MAC route sequence number is less than the
above criteria, all local MAC-IP routes associated with MAC route Mx Peer-Sync-Local MAC route sequence number, then the PE MUST update
MUST inherit the updated sequence number. Note that the local MAC the local MAC route sequence number to be equal to the Peer-Sync-
route sequence number might already be present if there was a local Local MAC route sequence number.
MAC-IP route learned prior to the local MAC route, in which case the
above may not result in any change in the local MAC route sequence If the existing local MAC route sequence number is equal to or
number. greater than the Peer-Sync-Local MAC route sequence number, no
update is required to the local MAC route sequence number.
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 inherit the updated sequence number. Note that the
local MAC route sequence number might already be present if there was
a local MAC-IP route learned prior to the local MAC route. In this
case, the above may not result in any change in the local MAC route
sequence number.
6.3. Remote MAC or MAC-IP Route Update 6.3. Remote MAC or MAC-IP Route Update
Upon receiving a remote MAC or MAC-IP route update associated with a Upon receiving a remote MAC or MAC-IP route update associated with a
MAC address Mx with a sequence number that is: MAC address Mx with a sequence number that is either:
* Either higher than the sequence number assigned to a local route * higher than the sequence number assigned to a local route for MAC
for MAC Mx, Mx or
* Or equal to the sequence number assigned to a local route for MAC * equal to the sequence number assigned to a local route for MAC Mx,
Mx, but the remote route is selected as best due to a lower VTEP but the remote route is selected as best due to a lower VXLAN
IP as per [RFC7432], Tunnel End Point (VTEP) IP as per [RFC7432],
the following actions are REQUIRED on the receiving PE: the following actions are REQUIRED on the receiving PE:
* The PE MUST trigger a probe and deletion procedure for all local * The PE MUST trigger a probe and deletion procedure for all local
MAC-IP routes associated with MAC Mx. MAC-IP routes associated with MAC Mx.
* The PE MUST trigger a deletion procedure for the local MAC route * The PE MUST trigger a deletion procedure for the local MAC route
for Mx. for Mx.
6.4. Peer-Sync-Local MAC route update 6.4. Peer-Sync-Local MAC Route Update
Upon receiving a Peer-Sync-Local MAC route, the corresponding local Upon receiving a Peer-Sync-Local MAC route, the corresponding local
MAC route Mx sequence number (if present) should be re-computed as MAC route Mx sequence number (if present) should be re-computed as
follows: follows:
* If the current sequence number is less than the received Peer- * If the current sequence number is less than the received Peer-
Sync-Local MAC route sequence number, it MUST be increased to be Sync-Local MAC route sequence number, it MUST be increased to be
equal to the received Peer-Sync-Local MAC route sequence number. equal to the received Peer-Sync-Local MAC route sequence number.
* If a local MAC route sequence number is updated as a result of the * 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 above, all local MAC-IP routes associated with MAC route Mx MUST
inherit the updated sequence number. inherit the updated sequence number.
6.5. Peer-Sync-Local MAC-IP route update 6.5. Peer-Sync-Local MAC-IP Route Update
Receiving a Peer-Sync-Local MAC-IP route for a locally attached host Because the MAC-only RT-2 advertisement is optional, receiving a
results in a derived Peer-Sync-Local MAC Mx route entry as the MAC- Peer-Sync-Local MAC-IP route for a locally attached host results in a
only RT-2 advertisement is optional. The corresponding local MAC Mx derived Peer-Sync-Local MAC Mx route entry. The corresponding local
route sequence number (if present) should be re-computed as follows: MAC Mx route sequence number (if present) should be re-computed as
follows:
* If the current sequence number is less than the received Peer- * If the current sequence number is less than the received Peer-
Sync-Local MAC route sequence number, it MUST be increased to be Sync-Local MAC route sequence number, it MUST be increased to be
equal to the received Peer-Sync-Local MAC route sequence number. equal to the received Peer-Sync-Local MAC route sequence number.
* If a local MAC route sequence number is updated as a result of the * 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 above, all local MAC-IP routes associated with MAC route Mx MUST
inherit the updated sequence number. inherit the updated sequence number.
6.6. Interoperability 6.6. Interoperability
skipping to change at page 18, line 32 skipping to change at line 847
Generally, if all PE nodes in the overlay network follow the above Generally, if all PE nodes in the overlay network follow the above
sequence number assignment procedures and the PE is advertising both sequence number assignment procedures and the PE is advertising both
MAC+IP and MAC routes, the sequence numbers advertised with the MAC 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. and MAC+IP routes with the same MAC address would always be the same.
However, an interoperability scenario with a different implementation However, an interoperability scenario with a different implementation
could arise, where a non-compliant PE implementation assigns and could arise, where a non-compliant PE implementation assigns and
advertises independent sequence numbers to MAC and MAC+IP routes. To advertises independent sequence numbers to MAC and MAC+IP routes. To
handle this case, if different sequence numbers are received for handle this case, if different sequence numbers are received for
remote MAC+IP routes and corresponding remote MAC routes from a remote MAC+IP routes and corresponding remote MAC routes from a
remote PE, the sequence number associated with the remote MAC route remote PE, the sequence number associated with the remote MAC route
MUST be computed and interpreted as: MUST be:
* The highest of all received sequence numbers with remote MAC+IP * computed and interpreted as the highest of all received sequence
and MAC routes with the same MAC address. numbers with remote MAC+IP and MAC routes with the same MAC
address and
* The MAC route sequence number would be re-computed on a MAC or * re-computed on a MAC or MAC+IP route withdraw as per the above.
MAC+IP route withdraw as per the above.
A MAC and/or IP address move to the local PE would then result in the 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 MAC (and hence all MAC-IP) route sequence numbers being incremented
from the above computed remote MAC route sequence number. from the above computed remote MAC route sequence number.
If MAC-only routes are not advertised at all, and different sequence If MAC-only routes are not advertised at all, and different sequence
numbers are received with multiple MAC+IP routes for a given MAC numbers are received with multiple MAC+IP routes for a given MAC
address, the sequence number associated with the derived remote 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 should still be computed as the highest of all received MAC+IP
route sequence numbers with the same MAC address. route sequence numbers with the same MAC address.
Note that it is not required for a PE to maintain explicit knowledge Note that it is not required for a PE to maintain explicit knowledge
of a remote PE being compliant or non-compliant with this of a remote PE being compliant or non-compliant with this
specification as long as it implements the above logic to handle specification as long as it implements the above logic to handle
remote sequence numbers that are not synchronized between MAC route remote sequence numbers that are not synchronized between MAC route
and MAC-IP route(s) for the same remote MAC address. and MAC-IP route(s) for the same remote MAC address.
6.7. MAC Address Sharing Race Condition 6.7. MAC Address Sharing Race Condition
In a MAC address sharing use case described in section 5.2, a race In a MAC address sharing use case described in Section 5.2, a race
condition is possible with simultaneous host moves between a pair of condition is possible with simultaneous host moves between a pair of
PEs. Example scenario below illustrates this race condition and its PEs. The example scenario below illustrates this race condition and
remediation: its remediation:
* PE1 with locally attached host IPs I1 and I2 that share MAC * PE1 with locally attached host IPs I1 and I2 that share MAC
address M1. PE1 as a result has local MAC-IP routes I1-M1 and address M1. As a result, PE1 has local MAC-IP routes I1-M1 and
I2-M1. I2-M1.
* PE2 with locally attached host IPs I3 and I4 that share MAC * PE2 with locally attached host IPs I3 and I4 that share MAC
address M2. PE2 as a result has local MAC-IP routes I3-M2 and address M2. As a result, PE2 has local MAC-IP routes I3-M2 and
I4-M2. I4-M2.
* A simultaneous move of I1 from PE1 to PE2 and of I3 from PE2 to * 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 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. I3's MAC address to change from M2 to M1.
* Route I3-M1 may be learnt on PE1 before I1's local entry I1-M1 has * Route I3-M1 may be learned on PE1 before I1's local entry I1-M1
been probed out on PE1 and/or route I1-M2 may be learnt on PE2 has been probed out on PE1 and/or route I1-M2 may be learned on
before I3's local entry I3-M2 has been probed out on PE2. PE2 before I3's local entry I3-M2 has been probed out on PE2.
* In such a scenario, MAC route sequence number assignment rules * In such a scenario, MAC route sequence number assignment rules
defined in section 6.1 will cause new mac-ip routes I1-M2 and defined in Section 6.1 will cause new MAC-IP routes I1-M2 and
I3-M1 to bounce between PE1 and PE2 with seuence number increments I3-M1 to bounce between PE1 and PE2 with sequence number
until stale entries I1-M1 and I3-M2 have been probed out from PE1 increments until stale entries I1-M1 and I3-M2 have been probed
and PE2 respectively. out from PE1 and PE2, respectively.
An implementation MUST ensure proper probing procedures to remove An implementation MUST ensure proper probing procedures to remove
stale ARP, NDP, and local MAC entries, following a move, on learning stale ARP, NDP, and local MAC entries, following a move, on learning
remote routes as defined in section 6.3 (and as per [RFC9135]) to remote routes as defined in Section 6.3 (and as per [RFC9135]) to
minimize exposure to this race condition. minimize exposure to this race condition.
6.8. Mobility Convergence 6.8. Mobility Convergence
This section is optional and details ARP and NDP probing procedures This section is optional and details ARP and NDP probing procedures
that MAY be implemented to achieve faster host re-learning and that MAY be implemented to achieve faster host relearning and
convergence on mobility events. PE1 and PE2 are used as two example convergence on mobility events. PE1 and PE2 are used as two example
PEs in the network to illustrate the mobility convergence scenarios PEs in the network to illustrate the mobility convergence scenarios
in this section. in this section.
* Following a host move from PE1 to PE2, the host's MAC address is * 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 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 from the host. If PE2 has a prior remote MAC-IP host route for
this MAC address from PE1, an ARP/NDP probe MAY be triggered at this MAC address from PE1, an ARP/NDP probe MAY be triggered at
PE2 to learn the MAC-IP address as a local adjacency and trigger 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 EVPN RT-2 advertisement for this MAC-IP address across the overlay
with new reachability via PE2. This results in a reliable "event- with new reachability via PE2. This results in a reliable "event-
based" host IP learning triggered by a "MAC address learning based" host IP learning triggered by a "MAC address learning
event" across the overlay, and hence faster convergence of overlay event" across the overlay, and hence, a faster convergence of
routed flows to the host. overlay routed flows to the host.
* Following a host move from PE1 to PE2, once PE1 receives a MAC or * 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 MAC-IP route from PE2 with a higher sequence number, an ARP/NDP
probe MAY be triggered at PE1 to clear the stale local MAC-IP probe MAY be triggered at PE1 to clear the stale local MAC-IP
neighbor adjacency or to re-learn the local MAC-IP in case the neighbor adjacency or to relearn the local MAC-IP in case the host
host has moved back or is duplicated. has moved back or is duplicated.
* Following a local MAC route age-out, if there is a local IP * Following a local MAC route age-out, if there is a local IP
adjacency with this MAC address, an ARP/NDP probe MAY be triggered adjacency with this MAC address, an ARP/NDP probe MAY be triggered
for this IP to either re-learn the local MAC route and maintain for this IP to either relearn the local MAC route and maintain
local L3 and L2 reachability to this host or to clear the ARP/NDP 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 entry if the host is no longer local. This accomplishes the
clearance of stale ARP/NDP entries triggered by a MAC age-out 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 event even when the ARP/NDP refresh timer is longer than the MAC
age-out timer. Clearing stale IP neighbor entries facilitates age-out timer. Clearing stale IP neighbor entries facilitates
traffic convergence if the host was silent and not discovered at traffic convergence if the host was silent and not discovered at
its new location. Once the stale neighbor entry for the host is its new location. Once the stale neighbor entry for the host is
cleared, routed traffic flow destined for the host can re-trigger cleared, routed traffic flow destined for the host can re-trigger
ARP/NDP discovery for this host at the new location. ARP/NDP discovery for this host at the new location.
6.8.1. Generalized Probing Logic 6.8.1. Generalized Probing Logic
The above probing logic may be generalized as probing for an IP The above probing logic may be generalized as probing for an IP
neighbor anytime a resolving parent MAC route is inconsistent with neighbor anytime a resolving parent MAC route is inconsistent with
the MAC-IP neighbor route, where inconsistency is defined as being the MAC-IP neighbor route, where inconsistency is defined as being
not present or conflicting in terms of the route source being local not present or conflicting in terms of the route source being local
or remote. The MAC-IP route to parent MAC route relationship or remote. The MAC-IP route to parent MAC route relationship
described in section 5.1 MAY be used to achieve this logic. described in Section 5.1 MAY be used to achieve this logic.
7. Routed Overlay 7. Routed Overlay
An additional use case involves traffic to an end host in the overlay An additional use case involves traffic to an end host in the overlay
being entirely IP routed. In such a purely routed overlay: being entirely IP routed. In such a purely routed overlay:
* A host MAC route is never advertised in the EVPN overlay control * A host MAC route is never advertised in the EVPN overlay control
plane. plane.
* Host /32 or /128 IP reachability is distributed across the overlay * Host /32 or /128 IP reachability is distributed across the overlay
skipping to change at page 21, line 19 skipping to change at line 974
fabric. However, intra-subnet traffic across the stretched fabric. However, intra-subnet traffic across the stretched
overlay is never bridged. overlay is never bridged.
* Both inter-subnet and intra-subnet traffic in the overlay is IP * Both inter-subnet and intra-subnet traffic in the overlay is IP
routed at the EVPN PE. routed at the EVPN PE.
Please refer to [RFC7814] for more details. Please refer to [RFC7814] for more details.
Host mobility within the stretched subnet still needs support. In Host mobility within the stretched subnet still needs support. In
the absence of host MAC routes, the sequence number mobility Extended the absence of host MAC routes, the sequence number mobility Extended
Community specified in [RFC7432] section 7.7 MAY be associated with a Community specified in Section 7.7 of [RFC7432] MAY be associated
/32 or /128 host IP prefix advertised via EVPN Route Type 5. MAC with a /32 or /128 host IP prefix advertised via EVPN Route Type 5.
mobility procedures defined in [RFC7432] can be applied to host IP MAC mobility procedures defined in [RFC7432] can be applied to host
prefixes as follows: IP prefixes as follows:
* On local learning of a host IP on a new ESI, the host IP MUST be * On local learning of a host IP on a new ESI, the host IP MUST be
advertised with a sequence number higher than what is currently advertised with a sequence number higher than what is currently
advertised with the old ESI. advertised with the old ESI.
* On receiving a host IP route advertisement with a higher sequence * On receiving a host IP route advertisement with a higher sequence
number, a PE MUST trigger ARP/NDP probe and deletion procedures on number, a PE MUST trigger ARP/NDP probe and deletion procedures on
any local route for that IP with a lower sequence number. The PE 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 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 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 IP route. If the IP has moved, the probe will time out, and the
local IP host route will be deleted. local IP host route will be deleted.
Note that there is only one sequence number associated with a host 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 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 is advertised along with the host IP address, a sequence number is
only associated with the MAC address. If the MAC is not advertised, 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 as in this use case, a sequence number is associated with the host IP
address. address.
This mobility procedure does not apply to "anycast IPv6" hosts This mobility procedure does not apply to "anycast" IPv6 hosts
advertised via NA messages with the Override Flag (O Flag) set to 0. advertised via Neighbor Advertisement (NA) messages with the Override
Refer to [RFC9161] for more details. Flag (O Flag) set to 0. Refer to [RFC9161] for more details.
8. Duplicate Host Detection 8. Duplicate Host Detection
Duplicate host detection scenarios across EVPN-IRB can be classified Duplicate host detection scenarios across EVPN-IRB can be classified
as follows: as follows:
* Scenario A: Two hosts have the same MAC address (host IPs may or * Scenario A: Two hosts have the same MAC address (host IPs may or
may not be duplicates). may not be duplicates).
* Scenario B: Two hosts have the same IP address but different MAC * Scenario B: Two hosts have the same IP address but different MAC
addresses. addresses.
* Scenario C: Two hosts have the same IP address, and the host MAC * Scenario C: Two hosts have the same IP address, and the host MAC
address is not advertised. address is not advertised.
As specified in [RFC9161], Duplicate detection procedures for As specified in [RFC9161], duplicate detection procedures for
Scenarios B and C do not apply to "anycast IPv6" hosts advertised via Scenarios B and C do not apply to "anycast" IPv6 hosts advertised via
NA messages with the Override Flag (O Flag) set to 0. NA messages with the Override Flag (O Flag) set to 0.
8.1. Scenario A 8.1. Scenario A
In cases where duplicate hosts share the same MAC address, the MAC In cases where duplicate hosts share the same MAC address, the MAC
address is detected as duplicate using the duplicate MAC address address is detected as duplicate using the duplicate MAC address
detection procedure described in [RFC7432]. Corresponding MAC-IP detection procedure described in [RFC7432]. Corresponding MAC-IP
routes with the same MAC address do not require separate duplicate routes with the same MAC address do not require separate duplicate
detection and MUST inherit the duplicate property from the MAC route. detection and MUST inherit the duplicate property from the MAC route.
If a MAC route is marked as duplicate, all associated MAC-IP routes If a MAC route is marked as duplicate, all associated MAC-IP routes
MUST also be treated as duplicates. Duplicate detection procedures MUST also be treated as duplicates. Duplicate detection procedures
need only be applied to MAC routes. need only be applied to MAC routes.
8.2. Scenario B 8.2. Scenario B
Misconfigurations may lead to different MAC addresses being assigned Misconfigurations may lead to different MAC addresses being assigned
the same IP address. This scenario is not detected by [RFC7432] the same IP address. This scenario is not detected by the duplicate
duplicate MAC address detection procedures and can result in MAC address detection procedures from [RFC7432] and can result in
incorrect routing of traffic destined for the IP address. incorrect routing of traffic destined for the IP address.
Such situations, when detected locally, are identified as a move Such situations, when detected locally, are identified as a move
scenario through the local MAC route sequence number computation scenario through the local MAC route sequence number computation
procedure described in section 6.1: procedure described in Section 6.1:
* If the IP is associated with a different remote MAC "Mz," the * If the IP is associated with a different remote MAC "Mz", the
sequence number MUST be higher than the "Mz" sequence number. sequence number MUST be higher than the "Mz" sequence number.
This move results in a sequence number increment for the local MAC This move results in a sequence number increment for the local MAC
route due to the remote MAC-IP route associated with a different MAC route due to the remote MAC-IP route being associated with a
address, counting as an "IP move" against the IP, independent of the different MAC address, which counts as an "IP move" against the IP,
MAC. The duplicate detection procedure described in [RFC7432] can independent of the MAC. The duplicate detection procedure described
then be applied to the IP entity independent of the MAC. Once an IP in [RFC7432] can then be applied to the IP entity independent of the
is detected as duplicate, the corresponding MAC-IP route should be MAC. Once an IP is detected as duplicate, the corresponding MAC-IP
treated as duplicate. Associated MAC routes and any other MAC-IP route should be treated as duplicate. Associated MAC routes and any
routes related to this MAC should not be affected. other MAC-IP routes related to this MAC should not be affected.
8.2.1. Duplicate IP Detection Procedure for Scenario B 8.2.1. Duplicate IP Detection Procedure for Scenario B
The duplicate IP detection procedure for this scenario is specified The duplicate IP detection procedure for this scenario is specified
in [RFC9161]. An "IP move" is further clarified as follows: in [RFC9161]. An "IP move" is further clarified as follows:
* Upon learning a local MAC-IP route Mx-IPx, check for existing * Upon learning a local MAC-IP route Mx-IPx, check for existing
remote or local routes for IPx with a different MAC address remote or local routes for IPx with a different MAC address
association (Mz-IPx). If found, count this as an "IP move" for association (Mz-IPx). If found, count this as an "IP move" for
IPx, independent of the MAC. IPx, independent of the MAC.
* Upon learning a remote MAC-IP route Mz-IPx, check for existing * Upon learning a remote MAC-IP route Mz-IPx, check for existing
local routes for IPx with a different MAC address association (Mx- local routes for IPx with a different MAC address association (Mx-
IPx). If found, count this as an "IP move" for IPx, independent IPx). If found, count this as an "IP move" for IPx, independent
of the MAC. of the MAC.
A MAC-IP route MUST be treated as duplicate if either: A MAC-IP route MUST be treated as duplicate if either:
* The corresponding MAC route is marked as duplicate via the * the corresponding MAC route is marked as duplicate via the
existing detection procedure. existing detection procedure, or
* The corresponding IP is marked as duplicate via the extended * the corresponding IP is marked as duplicate via the extended
procedure described above. procedure described above.
8.3. Scenario C 8.3. Scenario C
In a purely routed overlay scenario, as described in section 7, where As described in Section 7, in a purely routed overlay scenario where
only a host IP is advertised via EVPN RT-5 with a sequence number only a host IP is advertised via EVPN RT-5 with a sequence number
mobility attribute, procedures similar to duplicate MAC address mobility attribute, procedures similar to the duplicate MAC address
detection procedures specified in [RFC7432] can be applied to IP-only detection procedures specified in [RFC7432] can be applied to IP-only
host routes for duplicate IP detection as follows: host routes for duplicate IP detection as follows:
* Upon learning a local host IP route IPx, check for existing remote * Upon learning a local host IP route IPx, check for existing remote
or local routes for IPx with a different ESI association. If or local routes for IPx with a different ESI association. If
found, count this as an "IP move" for IPx. found, count this as an "IP move" for IPx.
* Upon learning a remote host IP route IPx, check for existing local * Upon learning a remote host IP route IPx, check for existing local
routes for IPx with a different ESI association. If found, count routes for IPx with a different ESI association. If found, count
this as an "IP move" for IPx. this as an "IP move" for IPx.
* Using configurable parameters "N" and "M," if "N" IP moves are * Using configurable parameters "N" and "M", if "N" IP moves are
detected within "M" seconds for IPx, IPx should be treated as detected within "M" seconds for IPx, then IPx should be treated as
duplicate. duplicate.
8.4. Duplicate Host Recovery 8.4. Duplicate Host Recovery
Once a MAC or IP address is marked as duplicate and frozen, Once a MAC or IP address is marked as duplicate and frozen,
corrective action must be taken to un-provision one of the duplicate corrective action must be taken to un-provision one of the duplicate
MAC or IP addresses. Un-provisioning refers to corrective action MAC or IP addresses. Un-provisioning refers to corrective action
taken on the host side. Following this correction, normal operation taken on the host side. Following this correction, normal operation
will not resume until the duplicate MAC or IP address ages out unless will not resume until the duplicate MAC or IP address ages out,
additional action is taken to expedite recovery. unless additional action is taken to expedite recovery.
Possible additional corrective actions for faster recovery include: Possible additional corrective actions for faster recovery are
outlined in the following sections.
8.4.1. Route Un-freezing Configuration 8.4.1. Route Unfreezing Configuration
Unfreezing the duplicate or frozen MAC or IP route via a CLI can be Unfreezing the duplicate or frozen MAC or IP route via a command-line
used to recover from the duplicate and frozen state following interface (CLI) can be used to recover from the duplicate and frozen
corrective un-provisioning of the duplicate MAC or IP address. state following corrective un-provisioning of the duplicate MAC or IP
Unfreezing the MAC or IP route should result in advertising it with a address. Unfreezing the MAC or IP route should result in advertising
sequence number higher than that advertised from the other location. it with a sequence number higher than that advertised from the other
location.
Two scenarios exist: Two scenarios exist:
* Scenario A: The duplicate MAC or IP address is un-provisioned at * Scenario A: The duplicate MAC or IP address is un-provisioned at
the location where it was not marked as duplicate. the location where it was not marked as duplicate.
* Scenario B: The duplicate MAC or IP address is un-provisioned at * Scenario B: The duplicate MAC or IP address is un-provisioned at
the location where it was marked as duplicate. the location where it was marked as duplicate.
Unfreezing the duplicate and frozen MAC or IP route will result in Unfreezing the duplicate and frozen MAC or IP route will result in
recovery to a steady state as follows: recovery to a steady state as follows:
* Scenario A: If the duplicate MAC or IP address is un-provisioned * Scenario A: If the duplicate MAC or IP address is un-provisioned
at the non-duplicate location, unfreezing the route at the frozen at the non-duplicate location, unfreezing the route at the frozen
location results in advertising with a higher sequence number, location results in advertising with a higher sequence number,
leading to automatic clearing of the local route at the un- leading to automatic clearing of the local route at the un-
provisioned location via ARP/NDP PROBE and DELETE procedures. provisioned location via ARP/NDP PROBE and DELETE procedures.
* Scenario B: If the duplicate host is un-provisioned at the * Scenario B: If the duplicate host is un-provisioned at the
duplicate location, unfreezing the route triggers an advertisement duplicate location, unfreezing the route triggers an advertisement
with a higher sequence number to the other location, prompting re- with a higher sequence number to the other location, prompting
learning and clearing of the local route at the original location relearning and clearing of the local route at the original
upon receiving the remote route advertisement. location upon receiving the remote route advertisement.
Probes referred to in these scenarios are event-driven probes The probes referred to in these scenarios are event-driven probes
resulting from receiving a route with a higher sequence number. resulting from receiving a route with a higher sequence number.
Periodic probes resulting from refresh timers may also occur Periodic probes resulting from refresh timers may also occur
independently. independently.
8.4.2. Route Clearing Configuration 8.4.2. Route Clearing Configuration
In addition to the above, route clearing CLIs may be used to clear 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: the local MAC or IP route after the duplicate host is un-provisioned:
* Clear MAC CLI: Used to clear a duplicate MAC route. * Clear MAC CLI: Used to clear a duplicate MAC route.
skipping to change at page 25, line 22 skipping to change at line 1163
* Clear ARP/NDP: Used to clear a duplicate IP route. * Clear ARP/NDP: Used to clear a duplicate IP route.
The route unfreeze CLI may still need to be executed if the route was The route unfreeze CLI may still need to be executed if the route was
un-provisioned and cleared from the non-duplicate location. Given un-provisioned and cleared from the non-duplicate location. Given
that unfreezing the route via the CLI would result in auto-clearing that unfreezing the route via the CLI would result in auto-clearing
from the un-provisioned location, as explained earlier, using a route from the un-provisioned location, as explained earlier, using a route
clearing CLI for recovery from the duplicate state is optional. clearing CLI for recovery from the duplicate state is optional.
9. Security Considerations 9. Security Considerations
Security considerations discussed in [RFC7432] and [RFC9135] apply to The security considerations discussed in [RFC7432] and [RFC9135]
this document. Methods described in this document further extend the apply to this document. Methods described in this document further
consumption of sequence numbers for IRB deployments. They are hence extend the consumption of sequence numbers for IRB deployments.
subject to same considerations if the control plane or data plane was Hence, they are subject to the same considerations if the control
to be compromised. As an example, if host facing data plane is plane or data plane was to be compromised. As an example, if the
compromised, spoofing attempts could result in a legitimate host host-facing data plane is compromised, spoofing attempts could result
being perceived as moved, eventually resulting in the host being in a legitimate host being perceived as moved, eventually resulting
marked as duplicate. Considerations for protecting control and data in the host being marked as duplicate. The considerations for
plane described in [RFC7432] are equally applicable to such mobility protecting control and data planes described in [RFC7432] are equally
spoofing use cases. applicable to such mobility spoofing use cases.
10. IANA Considerations 10. IANA Considerations
No IANA actions required. This document has no IANA actions.
11. Contributors
Gunter van de Velde
Nokia
Email: van_de_velde@nokia.com
Wen Lin
Juniper
Email: wlin@juniper.net
Sonal Agarwal
Arrcus
Email: sonal@arrcus.com
12. Acknowledgements
Authors would like to thank Gunter van de Velde for significant 11. References
contribution to improve the readability of this document. Authors
would also like to thank Sonal Agarwal and Larry Kreeger for multiple
contributions through the implementation process. Authors would like
to thank Vibov Bhan and Patrice Brissette for early feedback during
implementation and testing of several procedures defined in this
document. Authors would like to thank Wen Lin for a detailed review
and valuable comments related to MAC sharing race conditions.
Authors would also like to thank Saumya Dikshit for a detailed review
and valuable comments across the document.
13. References 11.1. Normative References
13.1. Normative References [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007, <https://www.rfc-editor.org/rfc/rfc4861>. DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://datatracker.ietf.org/doc/html/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
<https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol",
RFC 826, November 1982,
<https://www.rfc-editor.org/rfc/rfc826>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", Rabadan, "Integrated Routing and Bridging in Ethernet VPN
RFC 9135, DOI 10.17487/RFC9135, October 2021, (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/rfc/rfc9135>. <https://www.rfc-editor.org/info/rfc9135>.
[RFC9161] Rabadan, J., Sathappan, S., Nagaraj, K., Hankins, G., and [RFC9161] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G.,
T. King, "Operational Aspects of Proxy-ARP/ND in EVPN and T. King, "Operational Aspects of Proxy ARP/ND in
Networks", RFC 9161, DOI 10.17487/RFC9161, January 2022, Ethernet Virtual Private Networks", RFC 9161,
<https://www.rfc-editor.org/rfc/rfc9161>. DOI 10.17487/RFC9161, January 2022,
<https://www.rfc-editor.org/info/rfc9161>.
13.2. Informative References 11.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.13031/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://datatracker.ietf.org/doc/html/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC7348] Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
Bursell, M., and C. Wright, "Virtual eXtensible Local Area L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
Network (VXLAN): A Framework for Overlaying Virtualized eXtensible Local Area Network (VXLAN): A Framework for
Layer 2 Networks over Layer 3 Networks", RFC 7348, Overlaying Virtualized Layer 2 Networks over Layer 3
DOI 10.17348/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://datatracker.ietf.org/doc/html/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7814] Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., and B. Fee, [RFC7814] Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., and B. Fee,
"Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension "Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension
Solution", RFC 7814, DOI 10.17487/RFC7814, March 2016, Solution", RFC 7814, DOI 10.17487/RFC7814, March 2016,
<https://tools.ietf.org/html/rfc7814>. <https://www.rfc-editor.org/info/rfc7814>.
[RFC8926] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
Network Virtualization Encapsulation", RFC 8926, "Geneve: Generic Network Virtualization Encapsulation",
DOI 10.18926/RFC8926, November 2020, RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://datatracker.ietf.org/doc/rfc8926/>. <https://www.rfc-editor.org/info/rfc8926>.
[RFC8986] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
Matsushima, S., and Z. LI, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.18986/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://datatracker.ietf.org/doc/rfc8986/>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
Acknowledgements
The authors would like to thank Gunter Van de Velde for the
significant contributions to improve the readability of this
document. The authors would also like to thank Sonal Agarwal and
Larry Kreeger for multiple contributions through the implementation
process. The authors would like to thank Vibov Bhan and Patrice
Brissette for early feedback during the implementation and testing of
several procedures defined in this document. The authors would like
to thank Wen Lin for a detailed review and valuable comments related
to MAC sharing race conditions. The authors would also like to thank
Saumya Dikshit for a detailed review and valuable comments across the
document.
Contributors
Gunter Van de Velde
Nokia
Email: van_de_velde@nokia.com
Wen Lin
Juniper
Email: wlin@juniper.net
Sonal Agarwal
Arrcus
Email: sonal@arrcus.com
Authors' Addresses Authors' Addresses
Neeraj Malhotra (editor) Neeraj Malhotra (editor)
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States of America United States of America
Email: nmalhotr@cisco.com Email: nmalhotr@cisco.com
skipping to change at page 28, line 26 skipping to change at line 1319
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Avinash Lingala Avinash Lingala
AT&T AT&T
3400 W Plano Pkwy 3400 W Plano Pkwy
Plano, TX 75075 Plano, TX 75075
United States of America United States of America
Email: ar977m@att.com Email: ar977m@att.com
John Drake John Drake
Juniper Networks Independent
Email: jdrake@juniper.net Email: je_drake@yahoo.com
 End of changes. 151 change blocks. 
466 lines changed or deleted 505 lines changed or added

This html diff was produced by rfcdiff 1.48.