RFC 9721
Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)
RFC 9721: Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) 🦋
okay so bestie, this one is all about mobility in EVPN-IRB networks, which means what happens when a host hops from one spot to another and its addresses have to follow it 💅✨ It's an Internet Standards Track document from the IETF, published April 2025 ✨
Here's the title block tea 🫖🎀:
- Authors: N. Malhotra (Ed.), A. Sajassi, A. Pattekar (Cisco Systems), J. Rabadan (Nokia), A. Lingala (AT&T), and J. Drake (Independent) 💜
- Category: Standards Track
- Date: April 2025
- Status: ISSN 2070-1721
- Updates: RFC 7432 and RFC 9135 are the base specs this one extends 🧚
- Obsoletes: Nothing is obsoleted here 🙈
Its spot in the RFC number line is RFC 9721, and it's officially listed at https://www.rfc-editor.org/info/rfc9721 🌸
Status of This Memo ✨
This is an Internet Standards Track document. It's a product of the IETF and reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards lives in Section 2 of RFC 7841 💖
Want the current status, errata, or a way to give feedback? Check https://www.rfc-editor.org/info/rfc9721 🦋
Copyright Notice ✨
Copyright (c) 2025 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) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🫶
Table of Contents 🌈
1. Introduction
1.1. Document Structure
2. Requirements Language and Terminology
2.1. Abbreviations
2.2. Definitions
3. Background and Problem Statement
3.1. Optional MAC-Only RT-2
3.2. Mobility Use Cases
3.2.1. Host MAC+IP Address Move
3.2.2. Host IP Address Move to New MAC Address
3.2.2.1. Host Reload
3.2.2.2. MAC Address Sharing
3.2.2.3. Problem
3.2.3. Host MAC Address Move to New IP Address
3.2.3.1. Problem
3.3. EVPN All Active Multi-Homed ES
4. Design Considerations
5. Solution Components
5.1. Sequence Number Inheritance
5.2. MAC Address Sharing
5.3. Sequence Number Synchronization
6. Methods for Sequence Number Assignment
6.1. Local MAC-IP Learning
6.2. Local MAC Learning
6.3. Remote MAC or MAC-IP Route Update
6.4. Peer-Sync-Local MAC Route Update
6.5. Peer-Sync-Local MAC-IP Route Update
6.6. Interoperability
6.7. MAC Address Sharing Race Condition
6.8. Mobility Convergence
6.8.1. Generalized Probing Logic
7. Routed Overlay
8. Duplicate Host Detection
8.1. Scenario A
8.2. Scenario B
8.2.1. Duplicate IP Detection Procedure for Scenario B
8.3. Scenario C
8.4. Duplicate Host Recovery
8.4.1. Route Unfreezing Configuration
8.4.2. Route Clearing Configuration
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses1. Introduction 🌸
okay so EVPN-IRB lets you advertise both the MAC and the IP route in one single MAC+IP Route Type 2 (RT-2) advertisement 💅 The MAC goes into the local MAC-VRF bridge table so Layer 2 traffic can flow across the overlay ✨ The IP goes into the local ARP/NDP table in an asymmetric IRB design, or into the IP-VRF routing table in a symmetric IRB design, so routed traffic can flow too 🦋 If you want more on the EVPN-IRB forwarding modes, check out [RFC9135] 🫶
Now for mobility. A single sequence number mobility attribute rides along with that combined MAC+IP route 🎀 The catch is it quietly assumes a fixed 1:1 mapping between an IP address and a MAC address. That's the common case, and the existing procedure in [RFC7432] handles it just fine 💖 But there are other IRB scenarios that don't follow that rule, and they're everywhere in virtualized environments where the hosts are Virtual Machines (VMs) or containerized workloads 😭 These are the IRB mobility scenarios considered here:
- A host move results in the host's IP address and MAC address moving together.
- A host move results in the host's IP address moving to a new MAC address association.
- A host move results in the host's MAC address moving to a new IP address association.
The existing mobility procedure can handle the first one, the MAC+IP move 🌈 The other two create brand-new MAC-IP address associations 🙈 So one sequence number assigned independently for each {MAC address, IP address} just isn't enough to tell which reachability is the most recent for both the MAC and the IP, unless the sequence number assignment algorithm allows MAC-IP bindings to change across moves 💀
This document updates the sequence number assignment procedures from [RFC7432] to do two things: 1) properly support mobility across EVPN-IRB overlay use cases where MAC-IP bindings are allowed to change across host moves, and 2) support mobility for both the MAC and IP route components carried in an EVPN RT-2 for those use cases 👑
There's also a bit for hosts on an Ethernet Segment Identifier (ESI) that's multi-homed to several Provider Edge (PE) devices. Extra procedures make sure sequence number assignments stay synchronized across those multi-homing devices 🧚
This document covers mobility for these cases, no matter which overlay encapsulation you use (MPLS, Segment Routing over IPv6 (SRv6), or Network Virtualization Overlay (NVO) tunnel) 🌸
- Symmetric EVPN-IRB overlay
- Asymmetric EVPN-IRB overlay
- Routed EVPN overlay
1.1. Document Structure 🎀
These sections are informative:
- Section 3 gives the background and the problem statement 💅
- Section 4 lists the resulting design considerations ✨
- Section 5 lists the main solution components that the later sections build on 🦋
These sections are normative:
- Section 6 describes the mobility and sequence number assignment procedures in an EVPN-IRB overlay that are required to handle the scenarios from Section 4 💖
- Section 7 describes the mobility procedures for a routed overlay network, as opposed to an IRB overlay 🌈
- Section 8 describes the matching duplicate detection procedures for EVPN-IRB and routed overlays 👑
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🌟
2.1. Abbreviations 🧚
ARP: : Address Resolution Protocol [RFC0826]. ARP references in this document are equally applicable to both ARP and NDP 💅
CE: : Customer Edge. 🌸
ES: : Ethernet Segment. A physical ethernet or LAG port that connects an access device to an EVPN PE, as defined in [RFC7432] ✨
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 🦋
EVPN-IRB: : Ethernet VPN Integrated Routing and Bridging. A BGP-EVPN distributed control plane that is based on the integrated routing and bridging fabric overlay discussed in [RFC9135] 💖
L2: : Layer 2. 🎀
L3: : Layer 3. 🎀
LAG: : Link Aggregation Group. 🌈
MC-LAG: : Multi-Chassis Link Aggregation Group. 👑
MPLS: : Multiprotocol Label Switching (as specified in [RFC3031]). 🫶
NDP: : Neighbor Discovery Protocol (for IPv6 [RFC4861]). 🧚
NVO: : Network Virtualization Overlay. 🌸
NVO3: : Network Virtualization over Layer 3 (as specified in [RFC8926]). ✨
PE: : Provider Edge. 💅
RT-2: : Route Type 2. EVPN RT-2 carrying both MAC address and IP address reachability as specified in [RFC7432] 🦋
RT-5: : Route Type 5. EVPN RT-5 carrying IP prefix reachability as specified in [RFC9136] 💖
SRv6: : Segment Routing over IPv6 (as specified in [RFC8986]). 🌈
ToR: : Top-of-Rack. 👑
VM: : Virtual Machine (or containerized workloads). 🫶
VXLAN: : Virtual eXtensible Local Area Network (as specified in [RFC7348]). 🧚
Part 1 of 6 is done, bestie 🎀 Part 2 is coming next, starting with Section 2.2 Definitions and running into Section 3 Background and Problem Statement 💅
2.2. Definitions
Okay, so this is the glossary bit, and it's where all the key vocab lives 💅
Asymmetric EVPN-IRB: a design approach in EVPN-based networks [RFC9135] for handling L2 and L3 forwarding. Here, only the ingress PE router does the routing for inter-subnet traffic, and the egress PE router does the bridging. 🦋
EVPN all-active multi-homing: a redundancy and load-sharing mechanism in EVPN networks. Multiple PE devices can simultaneously give L2 and L3 connectivity to one CE device or network segment. Team effort, no cap 🫶
Host: in this doc, this is the generic term for any user or CE endpoint attached to an EVPN-IRB network. It could be a VM, a containerized workload, a physical endpoint, or a CE device 🧚
MAC-IP address: the binding between an IPv4 and/or IPv6 address and a MAC address for an overlay host. It's giving pairing 💜
Overlay: the L2 and L3 VPNs that get 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's directly attached to a local multi-homed ES 🎀
Peer-Sync-Local MAC-IP sequence number: the sequence number that comes with a Peer-Sync-Local MAC-IP route ✨
Peer-Sync-Local MAC route: the learned BGP EVPN MAC route for a host that's directly attached to a local multi-homed ES 🌸
Peer-Sync-Local MAC sequence number: the sequence number that comes with a Peer-Sync-Local MAC route 🍓
Symmetric EVPN-IRB: a specific design approach in EVPN-based networks [RFC9135] that handles both L2 and L3 forwarding within the same network infrastructure. The key thing is that both the ingress and egress PE routers do the routing for inter-subnet traffic. Main character energy 👑
Underlay: the IP, MPLS, or SRv6 fabric core network that gives routed reachability between EVPN PEs. It's the foundation, bestie 🧱
3. Background and Problem Statement ✨
3.1. Optional MAC-Only RT-2
Okay, so picture an EVPN-IRB setup where a single MAC+IP RT-2 advertisement carries both the IP and MAC routes. In that case, a MAC-only RT-2 advertisement becomes redundant for host MAC addresses that are already advertised via MAC+IP RT-2. 🙈 So, the advertisement of a local MAC-only RT-2 is optional at an EVPN PE. This matters a lot for the mobility scenarios we get into later.
Lowkey the coolest part: a local MAC route and its assigned sequence number are still kept locally on the PE. Only the advertisement of that route to other PEs is optional 🫶
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 💅
3.2. Mobility Use Cases
This section lays out the IRB mobility use cases this document covers. The detailed procedures for handling these scenarios are in Sections 6 and 7 🦋 The IRB mobility scenarios being considered are:
- A host move results in both the host's IP and MAC addresses moving together.
- A host move results in the host's IP address moving to a new MAC address association.
- A host move results in the host's MAC address moving to a new IP address association.
3.2.1. Host MAC+IP Address Move
This is the baseline scenario 🍼 A host move results in both the host's MAC and IP addresses moving together, and the MAC-IP binding doesn't change. The existing MAC route mobility procedures defined in [RFC7432] can be used to support this MAC+IP address mobility scenario. Easy win ✨
3.2.2. Host IP Address Move to New MAC Address
Here, the host's IP address gets reassigned to a new MAC address during a host move 🔄
3.2.2.1. Host Reload
A host reload or an orchestrated move might cause a host to be re-spawned at the same or a new PE location. That gives it a new MAC address assignment while it keeps its existing IP address. So the host's IP address moves to a new MAC address binding, like this:
IP-a, MAC-a ---> IP-a, MAC-b3.2.2.2. MAC Address Sharing
This scenario is about multiple hosts, each with a unique IP address, that all share a common MAC address. A host move results in a new MAC address binding for the host IP address. Like, hosts running on a single physical server might share the same MAC address 🖥️ Or an L2 access network behind a firewall might have every host IP address learned with a common firewall MAC address 🧱 In these "shared MAC" scenarios, multiple local MAC-IP ARP/NDP entries may be learned with the same MAC address. And if a host IP address moves to a new physical server, that could result in a new MAC address association for the host IP 🌀
3.2.2.3. Problem
Here's the tea 🍵 In the scenarios above, a combined MAC+IP EVPN RT-2 advertised with a single sequence number number assumes a fixed IP-to-MAC address mapping. When a host IP address moves to a new MAC address, that assumption breaks, and a new MAC+IP route gets created. If this new route is independently assigned a new sequence number, then the sequence number can no longer tell you the most recent host IP reachability in a symmetric EVPN-IRB design. It also can't tell you the most recent IP-to-MAC address binding in an asymmetric EVPN-IRB design 😭
+------------------------+
| Underlay Network Fabric|
+------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE3 | | PE4 | | PE5 | | PE6 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ /
\ ESI-1 / \ ESI-2 / \ ESI-3 /
\ / \ / \ /
+\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+
| | |
Server-M1 Server-M2 Server-M3
| | |
VM-IP1, VM-IP2 VM-IP3, VM-IP4 VM-IP5, VM-IP6
Figure 1Figure 1 shows a topology where host VMs share the physical server MAC address 🎀 In steady state, the IP1-M1 route is learned at PE1 and PE2 and advertised to remote PEs with a sequence number N. If VM-IP1 moves to Server-M2, ARP or NDP-based local learning at PE3 and PE4 would result in a new IP1-M2 route. And if this new route is assigned a sequence number of 0, the mobility procedure for VM-IP1 will not trigger across the overlay network. Oof 💀
A sequence number assignment procedure must be defined so that the most recent IP address reachability, IP-to-MAC address binding, and MAC address reachability can be determined without ambiguity for these MAC address sharing scenarios 🔥
3.2.3. Host MAC Address Move to New IP Address
This scenario is where a host move or re-provisioning behind the same or a new PE location might leave the host with a new IP address assigned, while it keeps the same MAC address 🧚
3.2.3.1. Problem
The complication here is that MAC address reachability can be carried via a combined MAC+IP route, while a MAC-only route may not be advertised. Tying a single sequence number to the MAC+IP route implicitly assumes a fixed MAC-to-IP mapping. A MAC address move that results in a new IP address association breaks that assumption and creates a new MAC+IP route. If this new route independently gets a new sequence number, then the sequence number can no longer reliably show the most recent host MAC address reachability 😵💫
+------------------------+
| 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 2For instance, say host IP1-M1 is learned locally at PE1 and PE2 and advertised to remote hosts with sequence number N. Now, if this host with MAC address M1 is re-provisioned at Server2 and assigned a different IP address (e.g., IP7), then the new IP7-M1 route learned at PE3 and PE4 would be advertised with sequence number 0. As a result, L3 reachability to IP7 would be established across the overlay. But the MAC mobility procedure for M1 would not trigger, because of the new MAC-IP route advertisement. Advertising an optional MAC-only route with its sequence number would trigger MAC mobility per [RFC7432]. Without that extra advertisement, though, a single sequence number tied to a combined MAC+IP route may not be enough to update MAC address reachability across the overlay 🫠
A MAC-IP route sequence number assignment procedure is required to unambiguously determine the most recent MAC address reachability in the previous scenarios, without advertising a MAC-only route 🌈
Furthermore, after learning the new reachability for IP7-M1 via PE3 and PE4, PE1 and PE2 must probe and delete any local IPs associated with the MAC address M1, such as IP1-M1 🧹
It could be argued that the MAC mobility sequence number defined in [RFC7432] only applies to the MAC route part of a MAC-IP route, which would cover this scenario. That interpretation could serve as a clarification to [RFC7432]. It also supports the need for a common sequence number assignment procedure across all the MAC-IP mobility scenarios detailed in this document 💜
3.3. EVPN All Active Multi-Homed ES ✨
Okay bestie, picture this 🌸 an EVPN-IRB overlay where hosts are multi-homed to two or more PE devices through an all-active multi-homed ES. Look at Figure 3 and you'll see PE1 and PE2 both hanging off ESI-1, and PE3 and PE4 both hanging off ESI-2, all sitting on top of the underlay network fabric 🧚
+------------------------+
| Underlay Network Fabric|
+------------------------+
+-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE3 | | PE4 |
+-----+ +-----+ +-----+ +-----+
\\ // \\ //
\\ ESI-1 // \\ ESI-2 //
\\ // \\ //
+\\---//+ +\\---//+
| \\ // | | \\ // |
+---+---+ +---+---+
| |
CEs CEs
Figure 3So the vibe is that MAC and ARP/NDP entries learned on a local ES can also get synced across all the multi-homing PEs sharing that ES 💅 This is what lets local switching of intra- and inter-subnet ECMP traffic from remote hosts actually happen 🔥 Basically, a local MAC or ARP/NDP entry on a given ES can be learned the normal way, or synced over from another PE sharing the same ES. Main character energy, no cap.
Now here's where it gets messy 😭 For a host multi-homed to multiple PEs through an all-active ES interface, every PE learns the host MAC and MAC-IP routes as its own independent asynchronous event 🙈 That event depends on whether a traffic flow or an ARP/NDP response from the host hashes to a PE that's directly connected on the MC-LAG interface. So the sequence number mobility attribute on a locally learned MAC or MAC-IP route might not match across devices, because it depends on what state each device happens to be in when it does the learning. Lowkey chaotic ngl.
Let's walk through an example 🦋 Say a host gets deleted from ESI-2 and moves to ESI-1. It's possible that PE1 learns the host after the remote route from PE3 and PE4 is already deleted, while PE2 learns it before that deletion happens. In this case, PE1 treats the local host route learning as a brand-new route and assigns sequence number 0. Meanwhile PE2 treats it as a remote-to-local move and assigns sequence number N+1, where N is the existing sequence number assigned at PE3 and PE4.
Why is this a problem? 💀 Inconsistent sequence numbers coming from multi-homing devices cause two big issues:
- They create ambiguity about how remote PEs should handle paths that share the same ESI but have different sequence numbers. A remote PE might not program ECMP paths if it gets routes with different sequence numbers from a set of multi-homing PEs sharing the same ESI.
- They break the consistent route versioning across the network overlay that EVPN mobility procedures need in order to work.
Picture the inconsistent state for a sec 👀 PE2 would drop a remote route for the same host with sequence number N, since its local sequence number is N+1. PE1 would install that same route as the best route, since its local sequence number is 0. Chaos, honestly 😭
So here's the fix 🫶 To support mobility for multi-homed hosts using the sequence number mobility attribute, local MAC and MAC-IP routes learned on a multi-homed ES must be advertised with the same sequence number by all PE devices the ES is multi-homed to. We need a mechanism that keeps the sequence numbers assigned across these PEs consistent 🎀
4. Design Considerations 💖
Okay so, when you're deciding on a sequence number assignment scheme and implementation, you have to think about all of these:
- Synchronization across multi-homing PE devices: MAC+IP routes may be learned on an ES that is multi-homed to multiple PE devices, which means their sequence numbers need to be synchronized across those devices.
- Optional MAC-only RT-2: In an IRB scenario, MAC-only RT-2 is optional and may not be advertised alongside MAC+IP RT-2.
- Multiple IPs associated with a single MAC: A single MAC address can be linked to multiple IP addresses, meaning multiple host IPs share one common MAC address.
- Host IP movement: When a host IP address moves, it may end up with a new MAC address association. That requires a new IP-to-MAC address association and a new MAC+IP route 🦋
- Host MAC address movement: When a host MAC address moves, it may end up with a new IP address association. That requires a new MAC-to-IP address association and a new MAC+IP route ✨
- Local MAC-IP route learning via ARP/NDP: Local MAC-IP route learning via ARP/NDP always comes with a local MAC route learning event triggered by the ARP/NDP packet. However, MAC and MAC-IP route learning can happen in any order 🌈
- Separate sequence numbers for MAC and IP routes: Some use cases don't keep a constant 1:1 MAC-IP address mapping across moves. Those could in theory be handled with separate sequence numbers for the MAC and IP parts of a MAC+IP route. But keeping two separate sequence numbers adds serious complexity, debugging headaches, and backward compatibility issues 😵💫 So this document handles all of these requirements with a single sequence number attribute 💅
5. Solution Components 🎀
This section lays out the main pieces of the EVPN-IRB mobility solution specified in this document. The later sections dig into the exact sequence number assignment procedures based on the ideas here 🧚
5.1. Sequence Number Inheritance 👑
The big idea here is to treat a local MAC-IP route as a child of its matching local MAC route, within the local context of a PE 💜 That way the local MAC-IP route inherits the sequence number attribute from its parent local MAC-only route. In terms of object dependencies, it looks like the MAC-IP route is a dependent child of the parent MAC route:
Mx-IPx -----> Mx (seq# = N)So the parent MAC route and its child MAC-IP routes all share one sequence number, the one tied to the parent MAC route. This means a single sequence number attribute in a combined MAC+IP route covers both the MAC-only route and the MAC+IP route, which makes advertising the MAC-only route truly optional 🙌 It also lets a MAC address take on a different IP address after a move and still establish the most recent reachability to that MAC across the overlay, via the mobility attribute on the MAC+IP route advertisement. For example, when Mx moves somewhere new, it gets a higher sequence number at its new location per [RFC7432]. If that move leaves Mx with a different IP address, IPz, then the local Mx+IPz route inherits the new sequence number from Mx 🦋
Local MAC routes and local MAC-IP routes usually come from data plane learning and ARP/NDP learning, respectively, and they can show up in the control plane in any order 🌸 Implementations have two options: they can copy the inherited sequence number into each MAC-IP entry, or they can keep one attribute in the parent MAC route by creating a forward reference local MAC object for the case where a local MAC-IP route is learned before its local MAC route 🎀
5.2. MAC Address Sharing 🫧
In the shared MAC address scenario, several local MAC-IP sibling routes inherit the sequence number attribute from one common parent MAC route:
Mx-IP1 -----
| |
Mx-IP2 -----
. |
. +---> Mx (seq# = N)
. |
Mx-IPw -----
| |
Mx-IPx -----Figure 4
Here's the deal 💅 When a host IP moves to a different physical server, that IP ends up bound to a new MAC address. The new MAC-IP route from this move MUST be advertised with a sequence number higher than the previous MAC-IP route for this IP, which was advertised from the prior location. For example, say route Mx-IPx is currently advertised with sequence number N from PE1. If IPx moves to a new physical server behind PE2 and is associated with MAC Mz, then the new local Mz-IPx route MUST be advertised with a sequence number higher than N and higher than the previous Mz sequence number M. This lets PE devices, including PE1, PE2, and other remote PEs, figure out and program the most recent MAC address binding and reachability for the IP 🔥 PE1, once it receives this new Mz-IPx route with sequence number N+1 or M+1 (whichever is greater), would update IPx reachability via PE2 for symmetric IRB and update IPx's ARP/NDP binding to Mz for asymmetric IRB. It would also clear and withdraw the stale Mx-IPx route with the lower sequence number ✨
This also means that the sequence number for the local MAC route Mz and all of its local MAC-IP child routes at PE2 MUST be incremented to N+1 or M+1 if the previous Mz sequence number M is greater than N and is re-advertised across the overlay. Yes, re-advertising every MAC-IP child route affected by the parent MAC route adds overhead 😩 But it saves you from maintaining and advertising two separate sequence number attributes for the IP and MAC parts of MAC+IP RT-2, so it's worth it 💖 Implementations MUST be able to look up MAC-IP routes for a given IP and update the sequence number for its parent MAC route and for its MAC-IP route children 🧚
5.3. Sequence Number Synchronization 🌈
To support mobility for multi-homed hosts, local MAC and MAC-IP routes learned on a shared ES MUST be advertised with the same sequence number by all PE devices the ES is multi-homed to. This applies to local MAC-only routes too 💅 A MAC route and a MAC-IP route for a host attached to a local ES can come from data plane learning and ARP/NDP, respectively. They can also come from BGP EVPN, sent by another multi-homing PE, so that local switching can happen 🦋 MAC and MAC-IP routes learned via data plane and ARP/NDP are called local MAC routes and local MAC-IP routes. BGP EVPN learned MAC and MAC-IP routes for a host attached to a local ES are called Peer-Sync-Local MAC routes and Peer-Sync-Local MAC-IP routes, since they're effectively local routes synced over from a multi-homing peer 🫶 Local and Peer-Sync-Local route learning can happen in any order. Local MAC-IP routes advertised by all multi-homing PE devices sharing the ES MUST carry the same sequence number, no matter what order they were learned in. That means:
- On local or Peer-Sync-Local MAC-IP route learning, the sequence number for the local MAC-IP route MUST be compared and updated to the higher value.
- On local or Peer-Sync-Local MAC route learning, the sequence number for the local MAC route MUST be compared and updated to the higher value.
If comparing against the Peer-Sync-Local MAC-IP route means the local MAC-IP route's sequence number has to change, that's basically a sequence number update on the parent local MAC route, which then gets passed down as an inherited sequence number update on the local MAC-IP route 🎀
6. Methods for Sequence Number Assignment 👑
The next sections spell out the sequence number assignment procedures needed for local MAC, local MAC-IP, Peer-Sync-Local MAC, and Peer-Sync-Local MAC-IP route learning events, so everything hits those objectives 🧚💖
6.1. Local MAC-IP Learning 🎀
Okay so when a local Mx-IPx pair gets learned through ARP or NDP, it should result in the computation or re-computation of the parent MAC route Mx's sequence number 💅. After that, the MAC-IP route Mx-IPx inherits the parent MAC route's sequence number ✨. The parent MAC route Mx sequence number MUST be computed like this:
- It MUST be higher than any existing remote MAC route for Mx, per [RFC7432] 🦋
- It MUST be at least equal to the matching Peer-Sync-Local MAC route sequence number, if one is present 🫶
- It MUST be higher than the "Mz" sequence number if the IP is also associated with a different remote MAC "Mz" 😭
Once the new sequence number for the MAC route Mx is computed using the criteria above, all local MAC-IP routes associated with MAC Mx MUST inherit the updated sequence number 💖
6.2. Local MAC Learning 🌸
The local MAC route Mx sequence number MUST be computed like this:
- It MUST be higher than any existing remote MAC route for Mx, as per [RFC7432] ✨
- It MUST be at least equal to the corresponding Peer-Sync-Local MAC route sequence number if one is present 🧚
- If the existing local MAC route sequence number is less than the Peer-Sync-Local MAC route sequence number, then the 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 the MAC route Mx is computed using the criteria above, 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 before the local MAC route. In this case, the above may not result in any change in the local MAC route sequence number. It's giving "it was already handled" energy 💅
6.3. Remote MAC or MAC-IP Route Update 🦋
Upon receiving a remote MAC or MAC-IP route update associated with a MAC address Mx, with a sequence number that is either:
- higher than the sequence number assigned to a local route for MAC Mx, or
- equal to the sequence number assigned to a local route for MAC Mx, but the remote route is selected as best due to a lower VXLAN Tunnel End Point (VTEP) IP as per [RFC7432],
the following actions are REQUIRED on the receiving PE 🚨
- The PE MUST trigger a probe and deletion procedure for all local MAC-IP routes associated with MAC Mx. 🌈
- The PE MUST trigger a deletion procedure for the local MAC route for Mx. 💀
6.4. Peer-Sync-Local MAC Route Update 🍓
Upon receiving a Peer-Sync-Local MAC route, the corresponding local MAC route Mx sequence number (if present) should be re-computed as follows:
- If the current sequence number is less than the received Peer-Sync-Local MAC route sequence number, it MUST be increased to be 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 above, all local MAC-IP routes associated with MAC route Mx MUST inherit the updated sequence number. 🫶
6.5. Peer-Sync-Local MAC-IP Route Update 🧚
Because the MAC-only RT-2 advertisement is optional, receiving a Peer-Sync-Local MAC-IP route for a locally attached host results in a derived Peer-Sync-Local MAC Mx route entry. The corresponding local MAC Mx route sequence number (if present) should be re-computed as follows:
- If the current sequence number is less than the received Peer-Sync-Local MAC route sequence number, it MUST be increased to be 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 above, all local MAC-IP routes associated with MAC route Mx MUST inherit the updated sequence number. ✨
6.6. Interoperability 🌈
Generally, if all PE nodes in the overlay network follow the above sequence number assignment procedures, and the PE is advertising both MAC+IP and MAC routes, the sequence numbers advertised with the MAC and MAC+IP routes with the same MAC address would always be the same. 💅
However, an interoperability scenario with a different implementation could arise, where a non-compliant PE implementation assigns and advertises independent sequence numbers to MAC and MAC+IP routes. To handle this case, if different sequence numbers are received for remote MAC+IP routes and corresponding remote MAC routes from a remote PE, the sequence number associated with the remote MAC route MUST be:
- computed and interpreted as the highest of all received sequence numbers with remote MAC+IP and MAC routes with the same MAC address, and
- re-computed on a MAC or MAC+IP route withdraw as per the above. 🦋
A MAC and/or IP address move to the local PE would then result in the MAC (and hence all MAC-IP) route sequence numbers being incremented from the above computed remote MAC route sequence number. ✨
If MAC-only routes are not advertised at all, and different sequence numbers are received with multiple MAC+IP routes for a given MAC address, the sequence number associated with the derived remote MAC route should still be computed as the highest of all received MAC+IP route sequence numbers with the same MAC address. 🫶
Note that it is not required for a PE to maintain explicit knowledge of a remote PE being compliant or non-compliant with this specification, as long as it implements the above logic to handle remote sequence numbers that are not synchronized between the MAC route and MAC-IP route(s) for the same remote MAC address. It's the vibe of "we don't need to know who's who, we just need to handle the mismatch" 🤷♀️💖
6.7. MAC Address Sharing Race Condition 🔥
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 PEs. The example scenario below illustrates this race condition and its remediation:
- PE1 with locally attached host IPs I1 and I2 that share MAC address M1. As a result, PE1 has local MAC-IP routes I1-M1 and I2-M1. 🎀
- PE2 with locally attached host IPs I3 and I4 that share MAC address M2. As a result, PE2 has local MAC-IP routes I3-M2 and I4-M2. 🎀
- A simultaneous move of I1 from PE1 to PE2 and of I3 from PE2 to PE1 will cause I1's MAC address to change from M1 to M2 and cause I3's MAC address to change from M2 to M1. 😭
- Route I3-M1 may be learned on PE1 before I1's local entry I1-M1 has been probed out on PE1, and/or route I1-M2 may be learned on PE2 before I3's local entry I3-M2 has been probed out on PE2. 💀
- In such a scenario, MAC route sequence number assignment rules defined in Section 6.1 will cause new MAC-IP routes I1-M2 and I3-M1 to bounce between PE1 and PE2 with sequence number increments until stale entries I1-M1 and I3-M2 have been probed out from PE1 and PE2, respectively. 🌀
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 as per [RFC9135]) to minimize exposure to this race condition. This is a lowkey must-do, bestie 🫶
6.8. Mobility Convergence 🦋
This section is optional and details ARP and NDP probing procedures that MAY be implemented to achieve faster host relearning and convergence on mobility events. PE1 and PE2 are used as two example PEs in the network to illustrate the mobility convergence scenarios in this section. ✨
- Following a host move from PE1 to PE2, the host's MAC address is discovered at PE2 as a local MAC route via data frames received from the host. If PE2 has a prior remote MAC-IP host route for this MAC address from PE1, an ARP/NDP probe MAY be triggered at PE2 to learn the MAC-IP address as a local adjacency and trigger EVPN RT-2 advertisement for this MAC-IP address across the overlay with new reachability via PE2. This results in a reliable "event-based" host IP learning triggered by a "MAC address learning event" across the overlay and hence a faster convergence of overlay routed flows to the host. Iconic behaviour, honestly 👑
- Following a host move from PE1 to PE2, once PE1 receives a MAC or MAC-IP route from PE2 with a higher sequence number, an ARP/NDP probe MAY be triggered at PE1 to clear the stale local MAC-IP neighbor adjacency, or to relearn the local MAC-IP in case the host has moved back or is duplicated. 🙈
- 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 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 entry if the host is no longer local. This accomplishes the clearance of stale ARP/NDP entries triggered by a MAC age-out event, even when the ARP/NDP refresh timer is longer than the MAC age-out timer. Clearing stale IP neighbor entries facilitates traffic convergence if the host was silent and not discovered at its new location. Once the stale neighbor entry for the host is cleared, routed traffic flow destined for the host can re-trigger ARP/NDP discovery for this host at the new location. 🧚
6.8.1. Generalized Probing Logic 💜
The above probing logic may be generalized as probing for an IP neighbor anytime a resolving parent MAC route is inconsistent with the MAC-IP neighbor route, where inconsistency is defined as being not present or conflicting in terms of the route source being local or remote. The MAC-IP route to parent MAC route relationship described in Section 5.1 MAY be used to achieve this logic. Main character energy for the whole probing story 🌟
7. Routed Overlay 🦋
okay so the next use case is where traffic to an end host in the overlay is entirely IP routed 💅 in a purely routed overlay:
- A host MAC route is never advertised in the EVPN overlay control plane.
- Host /32 or /128 IP reachability is distributed across the overlay via EVPN Route Type 5 (RT-5) along with a zero or non-zero ESI.
- An overlay IP subnet may still be stretched across the underlay fabric. However, intra-subnet traffic across the stretched overlay is never bridged.
- Both inter-subnet and intra-subnet traffic in the overlay is IP routed at the EVPN PE.
Please refer to [RFC7814] for more details ✨
Host mobility within the stretched subnet still needs support 🥹 Without host MAC routes, the sequence number mobility Extended Community specified in Section 7.7 of [RFC7432] MAY be associated with a /32 or /128 host IP prefix advertised via EVPN Route Type 5. MAC mobility procedures from [RFC7432] can be applied to host IP prefixes like this:
- 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 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. The PE will update the forwarding entry to point to the remote route with a higher sequence number and send an ARP/NDP probe for the local IP route. If the IP has moved, the probe will time out, and the local IP host route will be deleted 💀
Note that there is only one sequence number associated with a host route at any time 🎀 For the earlier use cases where a host MAC address is advertised along with the host IP address, a sequence number is only associated with the MAC address. If the MAC is not advertised, like in this use case, the sequence number is associated with the host IP address instead.
This mobility procedure does not apply to "anycast" IPv6 hosts advertised via Neighbor Advertisement (NA) messages with the Override Flag (O Flag) set to 0. Refer to [RFC9161] for more details 🌸
8. Duplicate Host Detection 👯♀️
duplicate host detection across EVPN-IRB can be sorted into three scenarios:
- Scenario A: Two hosts have the same MAC address (host IPs may or may not be duplicates).
- Scenario B: Two hosts have the same IP address but different MAC addresses.
- Scenario C: Two hosts have the same IP address, and the host MAC address is not advertised.
As specified in [RFC9161], duplicate detection procedures for Scenarios B and C do not apply to "anycast" IPv6 hosts advertised via NA messages with the Override Flag (O Flag) set to 0 🙈
8.1. Scenario A 🍓
when duplicate hosts share the same MAC address, the MAC address gets detected as a duplicate using the duplicate MAC address detection procedure described in [RFC7432]. Corresponding MAC-IP routes with the same MAC address don't need their own 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. Duplicate detection procedures need only be applied to MAC routes, so no extra work there 🫶
8.2. Scenario B 🌈
misconfigurations can lead to different MAC addresses being assigned the same IP address. This scenario is not detected by the duplicate MAC address detection procedures from [RFC7432] and can result in incorrect routing of traffic destined for the IP address 😭
when this is detected locally, it's identified as a move scenario through the local MAC route sequence number computation procedure described in Section 6.1:
- If the IP is associated with a different remote MAC "Mz", the sequence number MUST be higher than the "Mz" sequence number.
this move causes a sequence number increment for the local MAC route, because the remote MAC-IP route is associated with a different MAC address. That counts as an "IP move" against the IP, independent of the MAC 🦋 The duplicate detection procedure described in [RFC7432] can then be applied to the IP entity independent of the MAC. Once an IP is detected as duplicate, the corresponding MAC-IP route should be treated as duplicate. Associated MAC routes and any other MAC-IP routes related to this MAC should not be affected ✨
8.2.1. Duplicate IP Detection Procedure for Scenario B 🔥
the duplicate IP detection procedure for this scenario is specified in [RFC9161]. An "IP move" is further clarified as follows:
- Upon learning a local MAC-IP route
Mx-IPx, check for existing remote or local routes forIPxwith a different MAC address association (Mz-IPx). If found, count this as an "IP move" forIPx, independent of the MAC. - Upon learning a remote MAC-IP route
Mz-IPx, check for existing local routes forIPxwith a different MAC address association (Mx-IPx). If found, count this as an "IP move" forIPx, independent of the MAC.
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 procedure described above.
8.3. Scenario C 👑
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 mobility attribute, procedures similar to the duplicate MAC address detection procedures specified in [RFC7432] can be applied to IP-only host routes for duplicate IP detection, like this:
- Upon learning a local host IP route
IPx, check for existing remote or local routes forIPxwith a different ESI association. If found, count this as an "IP move" forIPx. - Upon learning a remote host IP route
IPx, check for existing local routes forIPxwith a different ESI association. If found, count this as an "IP move" forIPx. - Using configurable parameters "N" and "M", if "N" IP moves are detected within "M" seconds for
IPx, thenIPxshould be treated as duplicate.
8.4. Duplicate Host Recovery 🧚
once a MAC or IP address is marked as duplicate and frozen, corrective action must be taken to un-provision one of the duplicate MAC or IP addresses. Un-provisioning means corrective action taken on the host side. After that fix, normal operation won't resume until the duplicate MAC or IP address ages out, unless extra action is taken to expedite recovery 🙃
there are some possible additional corrective actions for faster recovery, outlined in the following sections.
8.4.1. Route Unfreezing Configuration 🧊
unfreezing the duplicate or frozen MAC or IP route via a command-line interface (CLI) can be used to recover from the duplicate and frozen state, after the corrective un-provisioning of the duplicate MAC or IP address. Unfreezing the MAC or IP route should result in advertising it with a sequence number higher than that advertised from the other location.
two scenarios exist:
- Scenario A: The duplicate MAC or IP address is un-provisioned at the location where it was not marked as duplicate.
- Scenario B: The duplicate MAC or IP address is un-provisioned at the location where it was marked as duplicate.
unfreezing the duplicate and frozen MAC or IP route will get things back to a steady state like this:
- Scenario A: If the duplicate MAC or IP address is un-provisioned at the non-duplicate location, unfreezing the route at the frozen location results in advertising with a higher sequence number. That leads to automatic clearing of the local route at the un-provisioned location via ARP/NDP PROBE and DELETE procedures.
- Scenario B: If the duplicate host is un-provisioned at the duplicate location, unfreezing the route triggers an advertisement with a higher sequence number to the other location. That prompts relearning and clearing of the local route at the original location upon receiving the remote route advertisement.
the probes mentioned in these scenarios are event-driven probes, triggered by receiving a route with a higher sequence number. Periodic probes resulting from refresh timers may also happen independently 🌸
8.4.2. Route Clearing Configuration 🧹
on top of the above, route clearing CLIs may be used to clear the local MAC or IP route after the duplicate host is un-provisioned:
- Clear MAC CLI: Used to clear a duplicate MAC route.
- Clear ARP/NDP: Used to clear a duplicate IP route.
the route unfreeze CLI may still need to be run if the route was un-provisioned and cleared from the non-duplicate location. Since unfreezing the route via the CLI results in auto-clearing from the un-provisioned location (as explained earlier), using a route clearing CLI for recovery from the duplicate state is optional 💖
9. Security Considerations 🔐
the security considerations discussed in [RFC7432] and [RFC9135] apply to this document. The methods described here further extend the consumption of sequence numbers for IRB deployments. So they're subject to the same considerations if the control plane or data plane gets compromised. For example, if the host-facing data plane is compromised, spoofing attempts could make a legitimate host look like it moved, which could eventually get the host marked as duplicate 😱 The considerations for protecting control and data planes described in [RFC7432] are equally applicable to these mobility spoofing use cases. Be careful out there, bestie 🛡️
10. IANA Considerations 🌷
This document has no IANA actions.
11. References 📚
11.1. Normative References 📚
okay so these are the must-read-first docs 💅 you can't really get through this spec without them, bestie.
[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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[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, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[RFC9161] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G.,
and T. King, "Operational Aspects of Proxy ARP/ND in
Ethernet Virtual Private Networks", RFC 9161,
DOI 10.17487/RFC9161, January 2022,
<https://www.rfc-editor.org/info/rfc9161>.11.2. Informative References 🦋
these ones are the nice-to-know extras that give you the bigger picture 🌈
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[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, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7814] Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., and B. Fee,
"Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension
Solution", RFC 7814, DOI 10.17487/RFC7814, March 2016,
<https://www.rfc-editor.org/info/rfc7814>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<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, February 2021,
<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 gave a huge shoutout to Gunter Van de Velde 🫶 for making this doc way more readable. they also thanked Sonal Agarwal and Larry Kreeger for a bunch of help during implementation, and Vibov Bhan and Patrice Brissette for early feedback while testing a few of the procedures in here 🧪. Wen Lin got a special thank-you for a detailed review and great comments on the MAC sharing race conditions ✨, and Saumya Dikshit was thanked for a detailed review across the whole 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.comAuthors' Addresses 🎀
Neeraj Malhotra (editor)
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: nmalhotr@cisco.com
Ali Sajassi
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
Aparna Pattekar
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: apjoshi@cisco.com
Jorge Rabadan
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: jorge.rabadan@nokia.com
Avinash Lingala
AT&T
3400 W Plano Pkwy
Plano, TX 75075
United States of America
Email: ar977m@att.com
John Drake
Independent
Email: je_drake@yahoo.comthat's the whole spec, bestie!! 🧚💜 you made it through every single section ✨ period 💅
📦 where this page comes from
- ietf: rfc9721 2025-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms