The following errata report has been rejected 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/eid9001/ -------------------------------------- Status: Rejected Type: Technical Reported by: Anand Narayanan <[email protected]> Date Reported: June 11, 2026, 1:09 a.m. Rejected by: Gunter Van de Velde (IESG) 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 ----- Claim by submitter ============ 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. AD Review ======= I agree that the sequence of events identifies a limitation in a mixed RFC 7432/RFC 9721 deployment. RFC 7432 assigns mobility sequence numbers per MAC address, so a legacy PE learning IPx-Mx is not required to make the Mx sequence number higher than the sequence number previously advertised for IPx-My. RFC 9721 Section 6.1 adds that requirement, but an RFC 7432-only PE naturally does not implement it. I do not think this establishes that RFC 9721 is backward incompatible, however. The example exercises the new IP-to-different-MAC mobility behavior at a legacy PE, which RFC 7432 never specified. Lack of the new behavior in an old implementation is not, by itself, backward incompatibility. The existing route encoding remains usable, and the previously supported mobility behavior continues to interoperate. The proposed corrected text therefore overstates the issue. My recommendation is to reject this erratum as submitted. A future update could usefully clarify that the extended mobility behavior requires the relevant PEs to implement RFC 9721. -------------------------------------- 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 _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
