Hi Gunter: An update clarifying that the extended mobility behavior requires all PEs to implement RFC9721 is much appreciated. I do not mind the erratum being rejected in favor of a more verbose update to the RFC.
Thanks Anand On Wed, Aug 5, 2026 at 4:27 AM Gunter van de Velde (Nokia) < [email protected]> wrote: > > Thanks, Anand. > > 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. > > Before I proceed to reject this erratum, is there additional feedback from > BESS WG? > > G/ > > ------------------------------ > *From:* [email protected] <[email protected]> > *Sent:* Thursday, June 11, 2026 8:04 PM > *To:* [email protected] <[email protected]>; > [email protected] <[email protected]>; Jorge Rabadan (Nokia) < > [email protected]>; Gunter van de Velde (Nokia) < > [email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > gunter <[email protected]>; [email protected] <[email protected]> > *Cc:* [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] < > [email protected]> > *Subject:* [Technical Errata Reported] RFC9721 (9001) > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > 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/eid9001/ > > -------------------------------------- > Type: Technical > Reported by: Anand Narayanan <[email protected]> > > 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 >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
