Network Working Group S. Dikshit Internet-Draft Aruba Networks, HPE Intended status: Informational 30 August 2026 Expires: 1 March 2027 Modeling EVPN MAC-Mobility Sequence State as a Conflict-Free Replicated Data Type draft-dikshit-bess-evpn-mobility-crdt-00 Abstract EVPN MAC Mobility, as carried in the MAC Mobility Extended Community defined by [RFC7432], uses a per-MAC sequence number to let PEs agree on the most recent location of a moving host. [I-D.ietf-bess-evpn-umr-mobility] extends this to cross-data-center moves via gateways, and already specifies, in some detail, how ordinary intra-DC and inter-DC moves are kept consistent: each gateway maintains two independent MAC Mobility sequence counters per host (one intra-DC, one inter-DC) specifically so that a purely local move does not have to be reconciled against the interconnect network's state. What that document does not specify is what a gateway does if it fails after locally resetting its intra-DC counter to zero (Section 5.2, the step taken when a host is confirmed to have left every local PE) but before propagating that fact onward; no failure-handling or crash-recovery text exists anywhere in the document. This document shows that this narrower, but concretely unaddressed, gap is a special case of a data type with known, formally proven convergence properties, the Last-Writer-Wins Register, one member of the Conflict-Free Replicated Data Type (CRDT) family, and proposes modeling the per-gateway mobility sequence state that way so that a mid-reset gateway crash is recovered from as a consequence of the data type's algebra rather than requiring a new, separately specified recovery procedure. 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 1 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Problem Statement 3. Background: Last-Writer-Wins Registers 4. Mapping EVPN Mobility State onto an LWW-Register 5. Convergence Argument 6. Applicability to draft-ietf-bess-evpn-umr-mobility Section 5.2 7. Cost and Compatibility 8. Relationship to Existing Work 9. Security Considerations 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Author's Address 1. Introduction [RFC7432] Section 15 defines MAC Mobility: a PE learning a MAC address locally that was previously announced by another PE compares the incoming route's Sequence Number, in the MAC Mobility Extended Community, against its own, and takes the higher value (with a documented tie-break) as authoritative. This is already, informally, a Last-Writer-Wins rule. It works within a single BGP route-reflection domain because BGP's own update and withdrawal mechanics guarantee every PE eventually sees every relevant route. [I-D.ietf-bess-evpn-umr-mobility] extends MAC mobility handling across a DC boundary via a pair of gateways translating between an intra-DC EVPN instance and an inter-DC one, using two independent per-host sequence counters (intra-DC, inter-DC) so that an ordinary local move never has to be reconciled against interconnect state. What Section 5.2 of that document does not state is the recovery procedure if a gateway crashes after locally resetting its intra-DC counter to zero but before that fact reaches remote gateways, leaving them with stale sequence state and no defined recovery path; the document has no failure-handling section at all. This document's position is that this gap should not be closed with a new, ad hoc, gateway-crash recovery procedure bolted onto the existing reset step. It should be closed by recognizing that the underlying state, "which sequence number, from which gateway, is currently authoritative for this MAC", is exactly the state a CRDT Last-Writer-Wins Register was defined to hold, with convergence properties already proven independently of any ordering or delivery assumption on messages, including the messages a restarting gateway may have lost. 2. Problem Statement Restated precisely, and narrowed to the gap [I-D.ietf-bess-evpn-umr-mobility] actually leaves open (its two-independent-counter design already handles the ordinary case): per Section 5.2 of that document, when host M1 is confirmed to have left every PE in DC1, GW1 "must reset its intra-DC MAC mobility counter for M1 to zero" and then sends a withdrawal to its local PEs and to remote GWs. If GW1 fails after performing the local reset but before that withdrawal reaches remote GW2, G2 (and any other gateway) has received nothing at all yet, so it is left holding the pre-reset state with no signal that anything is pending, and no text in the document says what happens when GW1 restarts, or how a delayed or duplicated withdrawal that arrives after GW1's restart should be reconciled against whatever GW1's counter reads at that point. This is a genuine gap: the document has no failure-handling section at all. 3. Background: Last-Writer-Wins Registers A Last-Writer-Wins Register (LWW-Register) [Shapiro2011] is a replicated register holding a single value, where every write is tagged with a totally ordered tag (typically a (timestamp, replica-id) pair, to break ties deterministically), and the merge function on receiving a remote update is: keep whichever of the local and remote value has the higher tag, discard the other. This merge function is commutative, associative, and idempotent, the three properties [Shapiro2011] proves are sufficient for every replica to converge to the same final value regardless of the order, number of retries, or duplication of the messages it receives, and regardless of which replica failed or restarted partway through. Critically, no coordination protocol, no ordering guarantee between two writes, and no rollback procedure is required for this convergence to hold; it is a property of the merge function's algebra, proven once, for every possible message schedule. 4. Mapping EVPN Mobility State onto an LWW-Register Define, for each MAC address, an LWW-Register whose tag is the pair (sequence-number, originating-gateway-id) compared lexicographically, exactly the tuple already available in [RFC7432]'s MAC Mobility Extended Community plus the originating PE's route distinguisher or router-id already present in the BGP NLRI. The register's merge function on any gateway receiving a MAC Mobility update, whether intra-DC or inter-DC, whether it arrives before, after, or interleaved with another update for the same MAC, is: adopt the update if and only if its tag is greater than the currently held tag; otherwise discard it silently. No other state, and no ordering assumption between the intra-DC reset and the inter-DC withdrawal, is required by this rule. 5. Convergence Argument Let G1 and G2 be any two gateways, and let each apply the merge rule of Section 4 to every update it ever receives for a given MAC, in whatever order those updates arrive, including duplicates and including the case where one gateway crashes and restarts having lost in-flight state (but not committed register state). Because the merge function is the standard LWW-Register merge, [Shapiro2011]'s Theorem (informally: commutative + associative + idempotent merge implies strong eventual consistency) applies directly: G1 and G2 converge to the same register value once both have received the same set of updates, regardless of delivery order. This holds even in exactly the partial-failure scenario of Section 2: G2, on receiving only the intra-DC reset and not yet the inter-DC withdrawal, simply holds whichever tag it has seen so far; when the withdrawal (or a retransmission of it after G1 restarts) eventually arrives, the merge rule resolves it correctly without any special-cased recovery logic, because there was never a "torn" intermediate state to recover from, only a register that had not yet received an update it will eventually receive. 6. Applicability to draft-ietf-bess-evpn-umr-mobility Section 5.2 Adopting Section 4's mapping would let [I-D.ietf-bess-evpn-umr-mobility] Section 5.2 close its currently unaddressed gateway-crash-recovery gap with a single sentence, with no change to the two-independent-counter design it already specifies: gateways apply the standard MAC Mobility comparison (RFC 7432 Section 15) to every intra-DC and inter-DC update they observe for a MAC, keeping the highest (sequence, origin) tag seen, with no required ordering between intra-DC and inter-DC propagation and no separate crash-recovery procedure, because none is needed. 7. Cost and Compatibility The tag (sequence-number, originating-gateway-id) requires no new wire field: the sequence number is already carried in the MAC Mobility Extended Community, and the originating gateway is already identifiable from the route's own BGP attributes. The proposal is therefore a specification and reasoning change, not a wire-format change, and is compatible with existing RFC 7432 implementations that already perform an equivalent, if less formally justified, comparison. 8. Relationship to Existing Work [RFC7432] Section 15 already implements an informal, single-domain version of the LWW-Register comparison this document formalizes; this document's contribution is extending that same comparison, with a proof of its sufficiency, to the cross-gateway, partial- failure setting that [I-D.ietf-bess-evpn-umr-mobility] introduces and for which the ordering question was left open. [Shapiro2011] is the source of the convergence proof relied on; this document does not re-derive it but applies it. 9. Security Considerations The security considerations of [RFC7432] Section 15 already apply: a compromised or misconfigured gateway announcing a falsely high sequence number can hijack a MAC's location, and this remains true under the LWW-Register framing, which does not add or remove authentication requirements on the underlying BGP UPDATE messages. The CRDT framing does not introduce a new attack surface; it removes an unspecified recovery procedure that could otherwise be a source of divergent, and therefore inconsistent and exploitable, implementation behavior across gateways from different vendors. 10. IANA Considerations This document requests no IANA actions. 11. References 11.1. Normative References [RFC7432] Sajassi, A., Ed., et al., "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015. 11.2. Informative References [I-D.ietf-bess-evpn-umr-mobility] "Applications and Procedures for the Unknown MAC Route in EVPN", Work in Progress. [Shapiro2011] Shapiro, M., Preguica, N., Baquero, C., and M. Zawirski, "A comprehensive study of Convergent and Commutative Replicated Data Types", INRIA Research Report RR-7506, 2011. Author's Address Saumya Dikshit Aruba Networks, HPE Email: saumya.dikshit@hpe.com