Internet-Draft extended ip mobility procedures October 2026
Narayanan, et al. Expires 20 April 2027 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-anarayanan-bess-evpn-extended-ip-mobility-00
Published:
Intended Status:
Informational
Expires:
Authors:
A. Narayanan
Arista Networks
A. Shashidhar
Arista Networks
Q. Yang
Arista Networks

Extended IP mobility procedures for EVPN-IRB

Abstract

[RFC9721] introduces IP mobility procedures for EVPN-IRB that couple IP and MAC mobility sequence numbers. This coupling results in excessive control plane churn when a single IP migrates among multiple IP addresses associated with a single MAC address. This document proposes separating sequence number spaces for IP mobility (MAC-IP routes) and MAC mobility (MAC-only routes), reducing BGP updates from O(N) to O(1) when one IP moves among N IPs on a MAC, while maintaining full compatibility with an implementation conforming to the recommendations of [RFC9721]. Further, this document proposes an upgrade path for deployments transitioning to IP mobility as defined in [RFC9721] or this draft.

Status of This Memo

This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 April 2027.

▲

Table of Contents

1. Introduction

The mobility procedures defined in [RFC9721] address the use case of determining the most recent IP-MAC binding when IP addresses and MAC addresses move independently in an EVPN overlay network. While this IP binding change is a common use case considered in [RFC9721], there are additional cases where the procedures defined in [RFC9721] may prove sub-optimal, causing severe control plane convergence overhead.

The following is an exhaustive list of IRB mobility scenarios that are considered:

  1. A host move results in the host's IP address and MAC address moving together.
  2. A host move results in the host's MAC address moving to a new IP address association.
  3. A host move results in the host's IP address moving to a new MAC address association that already has zero, one or more IP addresses associated with it.

The above cases are discussed in detail in sections 4.1.1 - 4.1.3.

While recommendations specified in [RFC9721] efficiently handle the cases 1-2, and case-3 when there are no IP addresses already associated with the destination MAC. Case-3 poses a unique challenge when there are already one or more IP addresses associated with the MAC. If the IP address moves to a new MAC address with a lower sequence number, the mobility procedures necessitate that the MAC-only and MAC-IP routes' sequence numbers be updated to a higher value to allow for the control plane to converge correctly. However, in case-3, since there are multiple IP addresses already associated with the target MAC address - following the recommendations would mean that one IP address moving would result in multiple EVPN RT-2 updates. The resulting overhead is directly proportional to the number of IP addresses mapped to the target MAC address.

This document updates the sequence number assignment procedures defined in [RFC9721] to handle this case, and have the control plane converge more efficiently without loss of determinism. While doing so, the recommendations of this draft remain fully compatible with another implementation that conforms to the recommendations of [RFC9721]. This document also covers the upgrade mechanism for an implementation conforming to [RFC7432] to upgrade to the recommendations outlined in this draft. Further, the draft also discusses the applicability for hosts behind an ESI multihoming to multiple PE devices.

Similar to [RFC9721], the mobility procedures defined in this draft apply to the following cases independent of the overlay encapsulation ( e.g, MPLS, SRv6, VXLAN )

  1. Symmetric IRB overlay
  2. Asymmetric IRB overlay
  3. Routed EVPN overlay

2. Requirements Language and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

EVPN-IRB:
A BGP-EVPN distributed control plane based integrated routing and bridging fabric overlay discussed in [RFC9135].
Endpoint:
An endpoint is a unique destination of a host in the Overlay network, identified by the associated ESI or by the PE address if the ESI is 0.
SRv6:
Segment Routing IPv6 protocol as specified in [RFC8986].
NVO3:
Network Virtualization Overlays as specified in [RFC8926].
VXLAN:
Virtual eXtensible Local Area Network as specified in [RFC7348].
MPLS:
Multi-Protocol Label Switching as specified in [RFC3031].
Underlay:
IP, MPLS, or SRv6 fabric core network that provides routed reachability between EVPN PEs.
Overlay:
L3 and L2 Virtual Private Network (VPN) enabled via NVO3, VXLAN, SRv6, or MPLS service layer encapsulation.
EVPN PE:
A PE switch-router in an EVPN-IRB network that runs 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- 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 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 document are equally applicable to both ARP and NDP.
NDP:
IPv6 Neighbor Discovery Protocol [RFC4861].
Ethernet Segment:
Physical ethernet or LAG (Link Aggregation Group) port that connects an access device to an EVPN PE, as defined in [RFC7432].
EVPN all-active multi-homing:
is a redundancy and load-sharing 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 reachability as specified in [RFC7432].
RT-5:
EVPN route type 5 carrying IP prefix reachability as specified in [RFC7432].
MAC-IP address:
IPv4 and/or IPv6 address and MAC address binding for an overlay host.
Peer-Sync-Local MAC route:
BGP EVPN learnt MAC route for a host 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 host that is directly attached to a local multi-homed Ethernet Segment.
Peer-Sync-Local MAC sequence number:
Sequence number received with a Peer-Sync-Local MAC route.
Peer-Sync-Local MAC-IP sequence number:
Sequence number received with a Peer-Sync-Local MAC-IP route.
VM:
Virtual Machine or containerized workloads.
Host:
Host in this document generically refers to any user/CE endpoint attached to an EVPN-IRB network which may be a VM, containerized workload or a physical end-point or CE device.

3. Background

This sections discusses the necessary background topics relevant to the mobility procedures as presented in the existing RFC literature ([RFC7432] and [RFC9721])

3.1. Optional Mac only RT-2

In EVPN-IRB deployments, the reachability of the MAC address in the overlay network is derived from both the MAC-only and MAC-IP EVPN RT-2 routes. In such a scenario, [RFC7432] suggests that advertising the MAC-only route may be optional, as the MAC-IP route conveys all of the following:

  1. The MAC address reachability
  2. The IP address reachability for the routing
  3. The IP-MAC binding information

3.2. MAC+IP and MAC-only route - handling out-of-sync sequence numbers

As discussed in section 6.1 of [RFC9721], consider a deployment where MAC-IP routes and MAC-only routes pertaining to the same MAC address are advertised, but with different sequence numbers. The sequence number used for determining the reachability of the MAC address MUST be the highest of all alternatives available for the same MAC address across all MAC-only and MAC-IP routes.

Whereas, for the IP-MAC binding determination and IP address reachability determination for routing purposes, the sequence number attached to the corresponding MAC-IP route may be used.

3.3. Sequence Number Inheritance

The MAC-IP routes are considered children of the associated MAC-only route for the purposes of sequence number assignment. In other words, a local MAC-IP route always inherits the sequence number of the parent local MAC-only route. Further, if an IP move necessitates that we increase the sequence number of a MAC-IP route, the sequence number of the parent MAC-only route is updated, this directly results in sequence number update of all the child MAC-IP EVPN RT-2 routes.

3.4. Sequence Number synchronization in All Active Multihomed ESI

In a scenario with hosts behind an all-active multihomed ESI, two or more PE devices could potentially advertise the same MAC-IP EVPN RT-2 routes. In such cases, [RFC9721] stipulates that the sequence number advertised for the MAC-only and all associated MAC-IP routes corresponding to the MAC address be synchronized to the higher value of the competing sequence numbers used across all the PEs with the same ES.

As a result, the MAC-only route and all the child MAC-IP routes from all the PEs in an ES will share the same sequence number.

4. Problem Statement

This section describes the various mobility scenarios in EVPN-IRB deployment. Particularly, Section 4.1.3 highlights the shortcomings of the existing mobility procedures in tackling the mobility use case, and the motivation for the procedures introduced in this draft

4.1. Mobility Use Cases

The following procedures for addressing the following host mobility cases are discussed in this document:

  1. Host move that results in the host's MAC address and all associated IP addresses moving together to a new endpoint.
  2. Host move that results in the host's MAC address moving to a new endpoint ( a new PE or a different ESI on the same PE )
  3. Host move that results in the host's IP address moving to a new MAC address that may have 0, 1 or more pre-existing IP address bindings

4.1.1. Host MAC+IP address move

This is the baseline scenario, and the most common one where the host's MAC address and IP address move to a new endpoint together. The existing MAC mobility procedures defined in [RFC7432], and updated in [RFC9721] are sufficient to cater to this use case.

4.1.2. Host MAC address move to a new IP address

In this scenario, a host's MAC address moves to a different endpoint in the overlay network, and acquires a new IP address. The recommendations as per [RFC7432] and [RFC9721] are sufficient to cater to this use case as well.

                        +------------------------+
                        | Underlay Network Fabric|
                        +------------------------+
     +-----+   +-----+      +-----+   +-----+      +-----+   +-----+
     | PE1 |   | PE2 |      | PE3 |   | PE4 |      | PE5 |   | PE6 |
     +-----+   +-----+      +-----+   +-----+      +-----+   +-----+
        \         /            \         /            \         /
         \ ESI-1 /              \ ESI-2 /              \ ESI-3 /
          \     /                \     /                \     /
          +\---/+                +\---/+                +\---/+
          | \ / |                | \ / |                | \ / |
          +--+--+                +--+--+                +--+--+
             |                      |                      |
          Server1                Server2                Server3
             |                      |                      |
       IP1-M1, IP2-M2        IP3-M3, IP4-M4         IP5-M5, IP6-M6
Figure 1

Consider M1 moving from ESI-1 to ESI-2 and acquiring a new IP address - IP7

When PE3/ PE4 chooses a sequence number for advertising IP7-M1, it considers the following:

  1. The sequence number M1 was associated with in the overlay - S(M1): S(M1) will be the highest of the sequence numbers of all the MAC-only and MAC-IP EVPN RT-2 routes associated with M1. This is regardless of

    1. Whether PE1/ PE2 has chosen to advertise a MAC-only route, because MAC-IP route is advertised
    2. Whether PE1/ PE2 has chosen to use out of sync sequence numbers for the MAC-only route and MAC-IP route
  2. The previous sequence number IP7 was associated with, since IP7 is a new IP address - this will be 0.

Now, PE3/ PE4 would advertise MAC-IP for IP7-M1, and optionally a MAC-only for M1 with a sequence number of S(M1) + 1

4.1.3. Host IP address moves to a new MAC address

In this scenario, a host's IP address moves to a different MAC address in the overlay network. The destination MAC address may be associated with one or more other IP addresses already.

This is the most interesting case as far as this document is concerned:

  1. The mobility recommendations defined in [RFC7432] are insufficient to deterministically pick the most recent IP-MAC binding in the overlay network
  2. The mobility recommendations as per [RFC9721], while sufficient in providing the determinism in picking the most recent IP-MAC binding, suffers from a high overhead of control plane advertisements directly proportional to the the number of IP addresses bound to the destination MAC address.

This can be illustrated with the following example:

               +------------------------+
               | Underlay Network Fabric|
               +------------------------+

     +-----+   +-----+            +-----+   +-----+
     | PE1 |   | PE2 |            | PE3 |   | PE4 |
     +-----+   +-----+            +-----+   +-----+
        \         /                  \         /
         \ ESI-1 /                    \ ESI-2 /
          \     /                      \     /
          +\---/+                      +\---/+
          | \ / |                      | \ / |
          +--+--+                      +--+--+
             |                            |
          Server1                      Server2
             |
       IP1-M1, IP2-M2            IP3,IP4,IP5,..IP9-M3
          (Seq-2)                       (Seq-0)
Figure 2

Consider the above depicted scenario where the:

  1. IP1, and IP2 are associated with MAC M2, and are advertised by PE1/PE2 with sequence number 0
  2. IP3 through IP9 are associated with MAC M3, and are advertised by PE3/PE4 with sequence number 0

When IP1 moves from Server-1 to Server-2, PE3/ PE4 considers the following while picking a sequence number to advertise the new binding with:

  1. The current sequence number in the overlay network for MAC M3: S(M3) = 0
  2. The current sequence number in the overlay network for IP address: S(IP1) = 2

The new sequence number for advertising IP1-M3 would be max(S(M3), S(IP1)) +1 = 3

However, [RFC9721] recommends that an update in sequence number for one MAC-IP route, requires a re-advertisement of all the other MAC-IP routes associated with M3.

In this case - IP1 moving from Server-1 to Server-2 would result in an update to the following:

  1. MAC-IP route for IP1-M3 binding with sequence number 3, resulting in one path update
  2. MAC-IP routes for IP3 through IP9 and M3 bindings with sequence number 3, resulting in seven path updates
  3. Optionally, MAC-only route for M3 with sequence number 3, resulting in one path update

One IP moving, results in at least 8 path updates without including the update to the optional MAC-only route. The number of updates directly scales with the number of IP addresses associated with the given MAC in the server.

5. Design Considerations and Solution Components

The solution components and sequence number scheme presented in this draft takes into account the following:

  1. Optional MAC-only EVPN RT-2: In EVPN IRB, in the presence of a MAC-IP route, the MAC-only RT-2 route is optional. The receiving PEs are supposed to derive the MAC reachability from the MAC-IP route instead.
  2. MAC address reachability with out-of-sync sequence numbers: When MAC-only and the associated MAC-IP EVPN RT-2 routes carry different sequence numbers, MAC address reachability for a given PE is ascertained by considering the MAC's sequence number as the highest among all the sequence numbers contained in the MAC-only, and MAC-IP routes from that PE
  3. Synchronization of Sequence numbers across multihoming PE devices: This is a vital aspect to multi-homing functioning accurately. Same sequence numbers must be used for the same MAC-IP and MAC-only routes across the PEs with the same ES, respectively

5.1. Inessentiality of Sequence Number Inheritance

This section illustrates the effects on MAC-only routes and MAC-IP routes without the requirement of sequence number inheritance.

5.1.1. MAC address reachability

The requirement for identical sequence numbers stems from the fact that MAC-only routes are optional and MAC reachability can be derived from MAC-IP routes.

However, to ensure MAC-IP and MAC-only routes provides reachability to a MAC originated by the same PE device, it is sufficient to ensure either MAC-only or MAC-IP routes originated by the same PE for the same MAC has a sequence number greater than or equal to the sequence number for the MAC originated by another PE/ Ethernet Segment.

The BGP bestpath picks routes based on the sequence numbers attached:

  1. If MAC-only and MAC-IP share the same sequence number, both of them may qualify for BGP bestpath winner, and would communicate identical reachability information for the MAC address
  2. If MAC-only and MAC-IP have different sequence numbers, the higher sequence number route would win BGP best path, and would dictate the reachability of the MAC address. The scheme shall ensure that the owner of the MAC address shall always advertise a MAC-only and/or a MAC-IP with a higher sequence number.

This draft permits MAC-IP routes to have sequence numbers different from those of their MAC-only counterparts, provided that MAC reachability remains consistent.

While it is strictly not required for correctness, the draft proposes that the sequence numbers in the MAC-IP routes are at least as high as the sequence numbers in the corresponding MAC-only route if present. This helps better traceability of MACs and their corresponding MAC-IP routes.

5.1.2. IP-MAC bindings and IP address routing reachability

This is the base case, and the MAC-only route plays no role in determining IP-MAC bindings and determining routing reachability for an IP address in the EVPN overlay network. Regardless of the sequence number contained in the MAC-only route, the sequence numbers in the MAC-IP route are sufficient to point to the correct PE.

5.2. Sequence Number Assignment scheme

The following sub sections discuss the scheme for sequence number assignment on various events that would require a sequence number recompute:

  1. Learning a local MAC or receiving Peer-Sync-Local MAC/ MAC-IP Route Update
  2. Learning a local ARP or NDP or receiving Peer-Sync-Local MAC-IP Route Update
  3. Remote MAC or MAC-IP route update

5.2.1. Learning a local MAC or receiving Peer-Sync-Local MAC/ MAC-IP Route Update

Regardless of whether a deployment chooses to advertise a MAC-only route, the local Mac route Mx sequence number MUST be computed as follows:

  1. It MUST be higher than that of any existing remote (non peer-sync) MAC route for Mx, as per [RFC7432].
  2. It MUST be higher than that of any existing remote (non peer sync) MAC-IP route for Mx and arbitrary IP.
  3. It MUST be equal or higher than that of the corresponding Peer-Sync-Local MAC route's sequence number, if present.

If a MAC-only route needs to be advertised, it shall use the sequence number computed above.

5.2.2. Learning a local ARP or NDP or receiving Peer-Sync-Local MAC-IP Route Update

Local sequence number for MAC Mx MUST be computed first if not present. A local Mx-IPx sequence number MUST be computed as follows:

  1. It MUST be equal to or higher to the locally computed MAC sequence number for MAC Mx
  2. It MUST be higher than the sequence numbers of existing MAC-IP routes ( remote or local ) for IPx
  3. It MUST be equal to or higher than that of the Peer-Sync-Local MAC-IP route, if present

The sequence number for the MAC-only route for MAC Mx remains unchanged.

5.2.3. Remote MAC or MAC-IP route update

Upon receiving a remote MAC route update or a MAC-IP route update that's associated with MAC Mx carrying either a zero-ESID or a non-zero non-local ESID, with a sequence number that is

  1. Higher than the sequence number assigned to local route for MAC Mx
  2. Equal to sequence number assigned to local route for MAC Mx, but the remote route is selected as best due to a lower VXLAN Tunnel End Point IP as per [RFC7432]

The following actions are REQUIRED on the receiving PE:

  1. The PE MUST probe the local MAC-IP routes for MAC Mx as per [RFC9721]
  2. The PE MUST trigger deletion procedure for all local MAC-IP routes associated with MAC Mx
  3. The PE MUST trigger deletion procedure for the local MAC route for Mx

If the said update is a MAC-IP route with IPx, the receiving PE is REQUIRED to do the following in addition to the above:

  1. The PE MUST probe the local MAC-IP route associated with IPx
  2. The PE MUST trigger deletion procedure for local MAC-IP route associated with IPx

5.3. Route Update optimizations due to the mobility scheme

Due to the removal of the requirement for sequence number inheritance in the proposed scheme, IP move across endpoints result in less number of route updates.

5.3.1. IP move to a standalone PE

Consider the following scenario:

  1. IP I1 behind PE1 associated with MAC M1. The MAC-IP route for I1-M1 advertised by PE1 has a sequence number 5.
  2. IPs I2-I10 are behind PE2, each associated with MAC M2. The MAC-IP route for I2-M2 through I10-M2 are at sequence number 0

I1 moves to be behind PE2, and is now associated with MAC M2.

RFC9721 scheme: Mobility scheme as per [RFC9721] would have required all the routes associated with MAC M2 from PE2 to be updated to sequence number 6, resulting in a total of at least 10 route updates.

Route Updates with mobility scheme prescribed above: The mobility scheme prescribed above will result in exactly one route update from PE2 for I1-M2 MAC-IP route with a sequence number 6.

5.3.2. IP move to a Multihomed PE

Consider the following scenario:

  1. PE2 and PE3 are Multihoming PEs sharing an Ethernet Segment ES1. PE1 is a standalone PE.
  2. IP I1 behind PE1 associated with MAC M1. The MAC-IP route for I1-M1 advertised by PE1 has a sequence number 5.
  3. IPs I2-I10 are behind ES1, each associated with MAC M2. The MAC-IP route for I2-M2 through I10-M2 are at sequence number 0, and are advertised by both PE2 and PE3

I1 moves to be behind ES1, and is now associated with MAC M2.

[RFC9721] scheme: The sequence number recomputation would result in the MAC M2's sequence number to be picked as 6, and this would result in route update for all the routes associated with MAC M2 from both PE2 and PE3, resulting in a total of at least 20 route updates

Route Updates with mobility scheme prescribed above

When MAC route is not advertised by PEs when MAC-IP is present:

  1. Assuming PE2 learns the binding I1-M2, it computes sequence number 6 for the MAC-IP route for I1-M2 and advertises the route
  2. PE3 receives the Peer Sync Local MAC-IP route update, and starts advertising MAC-IP route for I1-M2 with sequence number 6

Note that there's no change in either the MAC-only route's sequence number nor a change in the MAC-IP route's sequence number for IPs I2 through I10. There's exactly two updates that are required to conform to the scheme.

6. Upgrade Scenario

6.1. Upgrading a network with PEs with mobility procedures based on RFC7432

Similar to the extended mobility procedures defined in [RFC9721], the procedures defined in this draft are not backwards compatible with the procedures defined in [RFC7432]. An IP address moves from a speaker with extended mobility procedures defined in this draft to a speaker with mobility procedures according to [RFC7432], the resulting MAC-IP route does not trigger a re-compute, and instead acquires the current sequence number of the MAC route.

If the MAC route's sequence number happens to be lower than the original MAC-IP route, the speaker with extended mobility procedures will be unable to remove the stale MAC-IP route because the remote route has a lower sequence number than the advertised one. This necessitates the entire network to be upgraded to use the extended scheme for correctness. This section discusses procedures to allow a network with [RFC7432] EVPN speakers to upgrade to the extended mobility scheme discussed in this draft.

Under the recommendations of [RFC7432], it is left to a specific implementation on how a PE picks a winner when there exists multiple MAC-IP routes for a given IPx. Among the alternatives, a functional implementation that supports IP moves across MACs would pick the latest advertised MAC-IP route as the winner. Under the assumption that an [RFC7432] picks the latest MAC-IP route as the winner, we introduce a new "advertise-only" mode to help upgrade the network to the scheme discussed in this draft.

6.1.1. Advertise-Only Mode

This is an intermediate mode in which the PE advertises routes by picking sequence numbers according to the scheme discussed in this draft. However, it continues to pick the winning route based on the latest received route criterion ( the [RFC7432] compliant ).

This operating procedure allows this mode to be compatible with both [RFC7432] mobility procedures, and the extended mobility procedures defined in this draft.

When a network where all the PEs are operating with [RFC7432] sequence number scheme has to be migrated to use the extended scheme covered in this draft, we first have all the PEs operate in advertise-only mode, prior to moving the PEs to follow the scheme recommended in this draft. This ensures that at no point in time, we have PEs that are not compatible with each other in terms of mobility schemes.

While the advertise-only mode is discussed for the mobility scheme prescribed in this draft, it does equally apply when one wants to upgrade their network with PEs speaking [RFC7432] mobility scheme to the scheme dictated in [RFC9721].

6.1.1.1. Compatibility of Advertise Only mode with RFC7432 mobility procedures

Consider a (i) PE (PE1) that follows the recommendations of [RFC7432] and picks the winning MAC-IP route based on the latest received route criterion (ii) another PE (PE2) that follows the recommendations of this draft operating in advertise-only mode. Following cases are discussed when these PEs interop with each other:

  1. IP move from PE1 to PE2 from MAC M1 to M2

PE2 increments the sequence number of the MAC-IP route, PE1 picks the incoming MAC-IP route as the winner based on recency of the route

  1. IP move from PE2 to PE1 from MAC M2 to M1

PE1 may advertise the MAC-IP route for IP-M1 with a lower sequence number, but advertise-only mode in PE2 allows it to pick the incoming MAC-IP route as the winner based on recency disregarding the higher sequence number in locally originated MAC-IP route for IP-M2

6.1.1.2. Compatibility of Advertise Only mode with recommendations of this draft

Consider a (i) PE (PE1) that follows the recommendations of this draft NOT operating in advertise-only mode, and (ii) another PE (PE2) that follows the recommendations of this draft operating in advertise-only mode. Following cases are discussed when these PEs interop with each other:

  1. IP move from MAC M1/PE1 to MAC M2/PE2

PE2 increments the sequence number of the MAC-IP route, PE1 picks the incoming MAC-IP route as the winner based on the higher sequence number criteria

  1. IP move from MAC M2/PE2 to MAC M1/PE1

Upon move to PE1, it advertises the MAC-IP route for IP-M1 with a higher sequence number, but advertise-only mode in PE2 picks the incoming MAC-IP route as the winner based solely on recency.

7. Interoperability

While the previous section describes the upgrade pathway from [RFC7432] mobility scheme to either [RFC9721] scheme or the mobility scheme prescribed in this draft, this section covers the interoperability of PEs operating in [RFC9721] scheme and the mobility scheme in this draft. The mobility schemes are completely compatible with each other.

               +------------------------+
               | Underlay Network Fabric|
               +------------------------+
               +-----+            +-----+
      RFC9721  | PE1 |            | PE2 |  current draft
     compliant +-----+            +-----+    compliant
                  |                  |
                Host1              Host2
               M1 / I1            M2 / I2, I3
               MAC M1: 2          MAC M2: 5
               MAC-IP I1/M1: 2    MAC-IP I2/M2: 3
                                  MAC-IP I3/M2: 7
Figure 3

Consider the following:

  1. PE1 employs the sequence number scheme defined in [RFC9721].
  2. PE2 employs the sequence number scheme defined in this draft.
  3. MAC M1 is initially behind PE1, and is associated with IP I1
  4. MAC route for M1, and MAC-IP route for M2/I2 is advertised with sequence number 2
  5. MAC M2 is initially behind PE2, and is associated with IP I2, and IP I3.
  6. MAC route for M2 is advertised with sequence number 5
  7. MAC-IP route for M2/I2 is advertised with sequence number 3
  8. MAC-IP route for M2/I3 is advertised with sequence number 7

The following interoperability scenarios are considered between PE1, which follows [RFC9721], and PE2, which follows the procedures in this draft. The scenarios cover both IP moves and MAC moves, including cases where MAC-IP bindings are learned in different orders.

7.1. IP I1 moves from PE1 to PE2

  1. This move triggers a sequence number recompute for IP I1 at PE2
  2. Since there are no competing remote routes for M2, MAC-IP for I1 simply has to be better than (i) remote MAC-IP route for I1, and (ii) as good as local MAC route for MAC M2. The sequence number so computed is 5.
  3. PE2 sends exactly one MAC-IP route update for I1/M2 with sequence number 5.
  4. When PE1 processes this update, it triggers probing and withdrawal for the local I1/M2 binding.

There is a total of 1 route update from PE2

7.2. IP I2 moves from PE2 to PE1

  1. This move triggers a sequence number recompute for MAC M1 at PE1 due to sequence number inheritance.
  2. PE1 picks a sequence number that MUST be higher than the remote MAC-IP route for I2/M2, and applies it for all the routes associated with MAC M1. It picks sequence number 4.
  3. PE1 now sends 3 route updates (i) MAC route for M1, (ii) MAC-IP route for M1/I1, and (iii) MAC-IP route for M1/I2 with sequence number 4
  4. When PE2 receives these route updates, it triggers probing and removal procedures for the local I2/M2 binding.

There are a total of 3 route updates from PE1

7.3. Host I1/M1 moves from PE1 to PE2 and I1/M1 is learned later

  1. This move triggers a sequence number recompute for MAC M1 at PE2
  2. PE2 picks a sequence number that is higher than all the remote routes for MAC M1, and picks sequence number 3
  3. PE2 sends a MAC route update for M1 with sequence number 3.
  4. PE1 processes this update, and triggers a probe for IP1, and triggers removal of IP1/M1 local binding and MAC M1.
  5. I1/M1 binding is now learned at PE2, and triggers a sequence number recompute for IP I1 at PE2
  6. I1/M1 ends up picking sequence number 3 because there's no other remote route for either M1 or I1, and the local MAC route for M1 has sequence number 3.
  7. PE2 advertises MAC-IP route for I1/M1 with sequence number 3
  8. PE1 processes this update, and has no other actions aside from updating reachability for I1

All the routes require an update when the MAC moves

7.4. Host I1/M1 moves from PE1 to PE2 and I1/M1 binding is learned initially

Regardless of whether IP-MAC binding is learned first or whether the MAC is learned first, the scheme dictates that the sequence number of the MAC is computed first, and then subsequently used in the computation of the sequence number for the MAC-IP route.

Here are the sequence of events:

  1. This move triggers a sequence number recomputation for MAC M1 at PE2.
  2. PE2 picks a sequence number that is higher than all the remote routes for MAC M1, and picks sequence number 3
  3. I1/M1 ends up picking sequence number 3 because there's no other remote route for either M1 or I1, and the local MAC route for M1 has sequence number 3.
  4. PE2 sends a MAC-IP route update for I1/M1 with sequence number 3.
  5. PE1 processes this update, and triggers a probe for IP1, and triggers removal of IP1/M1 local binding and MAC M1.
  6. MAC M1 binding is now learned at PE2, and there's no change in the MAC sequence number already computed
  7. PE2 advertises MAC route for M1 with sequence number 3
  8. PE1 processes this update, and has no other actions

All the routes require an update when the MAC moves

7.5. Host I2/M2, and I3/M2 move from PE2 to PE1

  1. This move triggers a sequence number recompute for MAC M2 at PE1
  2. PE1 picks a sequence number that MUST be higher than the perceived sequence number for MAC M2 from the remote routes, which would be 7 because MAC-IP route for M2/I2 is at sequence number 7, and picks sequence number 8.
  3. PE1 advertises MAC route for M2 with sequence number 8
  4. PE2 processes the update, triggers a probe for IP I2, and triggers the removal of MAC M2, and binding M2/I2
  5. Regardless of when the bindings I2/M2, and I3/M2 show up at PE1, the sequence number computed would be the same, due to the inheritance of sequence number from the parent MAC route at PE1.

All the routes require an update when the MAC moves

8. Security Considerations

The security considerations discussed in [RFC9721] apply to this draft as well.

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC7432]
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, , <https://www.rfc-editor.org/info/rfc7432>.
[RFC9135]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", RFC 9135, DOI 10.17487/RFC9135, , <https://www.rfc-editor.org/info/rfc9135>.
[RFC9721]
Malhotra, N., Ed., Sajassi, A., Pattekar, A., Rabadan, J., Lingala, A., and J. Drake, "Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)", RFC 9721, DOI 10.17487/RFC9721, , <https://www.rfc-editor.org/info/rfc9721>.

10.2. Informative References

[RFC826]
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/RFC826, , <https://www.rfc-editor.org/info/rfc826>.
[RFC3031]
Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, , <https://www.rfc-editor.org/info/rfc3031>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC7348]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, , <https://www.rfc-editor.org/info/rfc7348>.
[RFC8926]
Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", RFC 8926, DOI 10.17487/RFC8926, , <https://www.rfc-editor.org/info/rfc8926>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.

Authors' Addresses

Anand Narayanan
Arista Networks
Akhil Shashidhar
Arista Networks
Qing Yang
Arista Networks