Subject: [bess] Re: [Technical Errata Reported] RFC9721 (9002)
From: Madison Church <[email-masked]>
To: Anand Narayanan <anarayanan=[email-masked]>
Cc: RFC Editor <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 12 Jun 2026 14:54:01
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>

Hi Anand,

The RPC has deleted the duplicate report in favor of EID 9001.

Thank you!

Madison Church
RFC Production Center

> On Jun 11, 2026, at 3:20 PM, Anand Narayanan <anarayanan=[email-masked]> wrote:
> 
> Hi All:
> 
> Apologies for the duplicate entry. We can reject this in favor of Errata#9001
> 
> Thanks
> Anand
> 
> On Thu, Jun 11, 2026 at 1:06 PM <[email-masked]> wrote:
> The following errata report has been submitted for RFC9721,
> "Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)"
> 
> --------------------------------------
> You may review the report below and at:
> https://errata.rfc-editor.org/eid9002/
> 
> --------------------------------------
> Type: Technical
> Reported by: Anand Narayanan <[email-masked]>
> 
> Section Abstract says:
> 
> Original Text
> -------------
> The extensions are backward compatible with existing EVPN-IRB implementations and aim to optimize network performance in scenarios involving frequent IP address mobility.
> 
> Corrected Text
> --------------
> The extensions while backwards incompatible, allow EVPN-IRB implementations to deterministically handle scenarios involving frequent IP address mobility
> 
> Notes
> -----
> The mobility procedures defined in RFC9721 does not seem backwards compatible with the procedures defined in RFC7432. 
> 
> Example:
> 
> Premise: 
> 
> 1. An RFC7432 speaker has MAC Mx with sequence number = 1
> 2. An RFC9721 speaker has MAC My with sequence number = 2
> 
> Sequence of Events:
> 
> 1. The RFC9721 speaker learns a local ARP for IPx-My, and advertised MAC-IP route with sequence number 2
> 2. IPx moves to be behind RFC7432 speaker
> 3. RFC7432 speaker would simply advertise IPx-Mx with sequence number 1
> 4. When RFC9721 speaker receives the MAC-IP route advertised by RFC7432 for IPx-Mx, it will be unable to remove it's local ARP binding because the remote route has an inferior sequence number.
> 
> This makes the schemes not compatible with each other.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC9721 (draft-ietf-bess-evpn-irb-extended-mobility)
> --------------------------------------
> Title               : Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)
> Publication Date    : April 2025
> Author(s)           : N. Malhotra, Ed., A. Sajassi, A. Pattekar, J. Rabadan, A. Lingala, J. Drake
> Category            : Proposed Standard
> Source              : bess (rtg)
> Stream              : IETF
> Verifying Party     : IESG