Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)
Extracted elements (22)
A single sequence number attribute was chosen over two separate sequence numbers for MAC and IP route components of MAC+IP RT-2. Maintaining two separate sequence numbers would add significant complexity, debugging challenges, and backward compatibility issues.
For multi-homed ES hosts, all PE devices sharing the ES must advertise local MAC and MAC-IP routes with the same sequence number regardless of learning order. Inconsistent sequence numbers across multi-homing PEs create ambiguity for remote PEs handling same-ESI paths with different sequence numbers and break consistent route versioning needed for EVPN mobility.
In a MAC address sharing scenario, multiple local MAC-IP sibling routes inherit the sequence number from their common parent MAC route. When a host IP moves to a new physical server with a different MAC, the new MAC-IP route must be advertised with a sequence number higher than both the previous MAC-IP route's sequence number and the new MAC's prior sequence number, requiring re-advertisement of all child routes when the parent sequence number is incremented.
In an EVPN-IRB scenario, a MAC-only RT-2 advertisement is optional for host MAC addresses already advertised via MAC+IP RT-2 because the MAC+IP route makes the MAC-only route redundant. MAC-only RT-2 may still be issued for non-IP host MAC addresses not included in MAC+IP RT-2.
MAC-IP routes are treated as children of the corresponding parent MAC route, inheriting the parent's sequence number. This ensures a single sequence number in a combined MAC+IP RT-2 represents both MAC and IP reachability, making MAC-only RT-2 advertisement truly optional and enabling a MAC address to assume a new IP address after moving while still establishing the most recent reachability.
A non-compliant PE implementation may assign and advertise independent sequence numbers to MAC and MAC+IP routes for the same MAC address, differing from compliant PEs where these sequence numbers are always identical. The receiving PE must handle this by computing the effective remote MAC route sequence number as the maximum across all received MAC+IP and MAC routes with the same MAC address, without requiring knowledge of whether the remote PE is compliant.
The mobility procedure for routed overlay RT-5 host IP routes does not apply to 'anycast' IPv6 hosts advertised via Neighbor Advertisement (NA) messages with the Override Flag (O Flag) set to 0. Similarly, duplicate detection procedures for Scenarios B and C do not apply to such anycast IPv6 hosts per RFC 9161.
A MAC-IP route MUST be treated as duplicate if either the corresponding MAC route is marked as duplicate via the existing detection procedure, or the corresponding IP is marked as duplicate via the extended IP move counting procedure for Scenario B. The duplicate IP detection procedure counts an 'IP move' when a local or remote MAC-IP route for IPx is learned with a different MAC address association.
An implementation MUST ensure proper probing procedures to remove stale ARP, NDP, and local MAC entries following a move, on learning remote routes as defined in Section 6.3 (and per RFC 9135), to minimize exposure to the MAC address sharing race condition where new MAC-IP routes can bounce between PEs with sequence number increments.
Because MAC-only RT-2 advertisement is optional, receiving a Peer-Sync-Local MAC-IP route for a locally attached host results in a derived Peer-Sync-Local MAC Mx route entry. If the current local MAC Mx sequence number is less than the received value, it MUST be increased to equal that value, and all local MAC-IP routes associated with Mx MUST inherit the updated sequence number.
For interoperability with non-compliant PEs that advertise independent sequence numbers for MAC and MAC+IP routes, the sequence number associated with a remote MAC route MUST be computed as the highest of all received sequence numbers across remote MAC+IP and MAC routes with the same MAC address, and MUST be re-computed on any MAC or MAC+IP route withdrawal.
In a routed overlay, on local learning of a host IP on a new ESI, the host IP MUST be advertised via RT-5 with a sequence number higher than what is currently advertised with the old ESI. On receiving a host IP route advertisement with a higher sequence number, a PE MUST trigger ARP/NDP probe and deletion procedures on any local route for that IP with a lower sequence number.
In Scenario A (duplicate MAC addresses), MAC-IP routes with the same MAC address as a duplicate MAC route do not require separate duplicate detection and MUST inherit the duplicate property from the MAC route. If a MAC route is marked as duplicate, all associated MAC-IP routes MUST also be treated as duplicates.
On local MAC-IP learning via ARP/NDP, the parent MAC route Mx sequence number MUST be higher than any existing remote MAC route for Mx, MUST be at least equal to the corresponding Peer-Sync-Local MAC route sequence number, and MUST be higher than the 'Mz' sequence number if the IP is also associated with a different remote MAC 'Mz'. All local MAC-IP routes associated with MAC Mx MUST inherit the updated sequence number.
On local MAC route learning, the local MAC route Mx sequence number MUST be higher than any existing remote MAC route for Mx, and MUST be at least equal to the corresponding Peer-Sync-Local MAC route sequence number. If the existing local sequence number is less than the Peer-Sync-Local sequence number, the PE MUST update it to equal the Peer-Sync-Local value. All local MAC-IP routes associated with Mx MUST inherit the updated sequence number.
Upon receiving a Peer-Sync-Local MAC route, if the current local MAC route Mx sequence number is less than the received Peer-Sync-Local MAC route sequence number, it MUST be increased to equal the received value. If updated, all local MAC-IP routes associated with MAC route Mx MUST inherit the updated sequence number.
Upon receiving a remote MAC or MAC-IP route for MAC Mx with a sequence number higher than (or equal but selected as best due to lower VTEP IP per RFC 7432) the local route's sequence number, the PE MUST trigger a probe and deletion procedure for all local MAC-IP routes associated with MAC Mx and MUST trigger a deletion procedure for the local MAC route for Mx.
In a routed overlay, host /32 or /128 IP reachability is distributed via EVPN Route Type 5 (RT-5) with a zero or non-zero ESI, and the sequence number mobility Extended Community from RFC 7432 Section 7.7 MAY be associated with the host IP prefix. No MAC route is advertised in the EVPN overlay control plane, and both inter- and intra-subnet traffic is IP routed at the EVPN PE.
Peer-Sync-Local MAC and MAC-IP routes are BGP EVPN-learned MAC and MAC-IP routes for a host attached to a local ES, synchronized from a multi-homing peer PE to enable local switching. These are distinct from locally learned routes and their sequence numbers are used to synchronize the local MAC route sequence number across all multi-homing PEs sharing the ES.
The MAC-IP route to parent MAC route relationship: each local MAC-IP route (Mx-IPx) is a dependent child of the parent local MAC route (Mx), inheriting its sequence number. Multiple sibling MAC-IP routes may share a common parent MAC route in the MAC address sharing scenario. The parent MAC route maintains the authoritative sequence number for all children.
The extensions in this document further extend sequence number consumption for IRB deployments, making them subject to the same security considerations as RFC 7432 if the control or data plane is compromised. A compromised host-facing data plane could enable spoofing attacks that make a legitimate host appear to have moved, eventually causing it to be marked as duplicate. Protections for control and data planes described in RFC 7432 apply equally to such mobility spoofing use cases.
Duplicate host recovery transitions through states: (1) duplicate detected and route frozen, (2) corrective un-provisioning of one duplicate host, (3) recovery via route unfreezing CLI (advertising with higher sequence number triggers auto-clearing at the un-provisioned location) or route clearing CLI (Clear MAC CLI / Clear ARP/NDP), returning to normal operation. Without corrective CLI action, the frozen route remains frozen until the duplicate MAC or IP ages out.