Hello Neeraj, Thank you for considering my suggestion to generalize the text into host rather than the apparent limited use case of VM (even if I agree that the VM use case may be the prominent one).
I sincerely think that the document is better with your changes. Regards -éric From: Neeraj Malhotra <neeraj.i...@gmail.com> Date: Tuesday, 3 December 2024 at 23:22 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org <draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com>, br...@innovationslab.net <br...@innovationslab.net> Subject: Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-irb-extended-mobility-18: (with DISCUSS and COMMENT) Hi Eric, Thanks for the follow-up comments below. It was never the intent of this document to be restricted to VM use cases, even though some of the VM use cases are used as an example for scenarios where host MAC/IP could change. On a similar note, methods specified in this document are also applicable to MAC/IP changes without a physical move to a different PE. I did go ahead and make the following changes in rev20: - updated the text thru the document to use "host" as a generic term for any kind of CE end-point (VM, container, physical device, etc.) attached to the EVPN-IRB network, as well as added this definition for the term "host" to section 2. - updated the text in section 3.2.2.1 (Host IP Move to New MAC -> Host Reload) to be inclusive of host being respawned with a new IP->MAC binding at the same or new PE location, as well as the text in section 3.2.3 (Host MAC Move to New IP) to be inclusive of same or new PE location. Thanks, Neeraj On Mon, Dec 2, 2024 at 10:38 PM Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> wrote: Hello Neeraj, Thanks for a prompt reaction and the revised -19, I will shortly clear my DISCUSS. See below for EV> (and I have elided the text for agreed upon points) From: Neeraj Malhotra <neeraj.i...@gmail.com<mailto:neeraj.i...@gmail.com>> Date: Tuesday, 3 December 2024 at 02:51 To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org> <draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com> <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>>, br...@innovationslab.net<mailto:br...@innovationslab.net> <br...@innovationslab.net<mailto:br...@innovationslab.net>> Subject: Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-irb-extended-mobility-18: (with DISCUSS and COMMENT) Hi Eric, Thanks for the review and comments. Have uploaded rev19 to address comments received from you and other reviewers. Please see inline for details. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ### Section 1 Consider using MADINAS drafts / use case as a reference for randomized and changing MAC addresses (while keeping the IP addresses). In the same vein, consider adding a reference to RFC 8981 (for changing IPv6 addresses). I.e., this I-D is far more generic than only VM. [NM]: In general, this document is decoupled from reasons why host IP - MAC bindings may change on a host move. It simply focuses on handling these scenarios as part of EVPN mobility handling independent of what caused the IP - MAC binding to change. As the reasons that lead to these scenarios can be many (including MADINAS and RFC 8981), we would prefer to keep the document decoupled from these references. I did update the VM definition to indicate that it refers to any host or endpoint attached to an EVPN network. EV> it was a non-blocking comment, but I still find sad that this I-D restrict itself to the VM use case (even with the change in section 2). I find the use of the term 'moving' weird in this section as the 'move' is not always a physical move (change of PE) but rather a new IP associated to an existing MAC (RFC 8981), or is this 'move' not covered by this document ? [NM]: Move scenarios discussed in the document are indeed physical moves where a host moves to a different PE. That said, an IP modification scenario would also be covered by the sequence number inheritance and assignment methods specified in section 6. EV> another non-blocking comment, but I still find that the text could be clearer and more generic if the term “moving” was defined to also include a change in MAC/IP without a physical move. ### Section 5.1 Like Brian noted in this int-dir review, should the impact of this seq num inheritance on the seq num wrapping be described ? [NM]: I did discuss this with other authors. We concluded that with the existing mechanism for duplicate address detection in place, this can only happen when the actual number of legitimate moves for a host exhausts the 32 bit / 4 billion sequence number space. For a host that moves every minute, this amounts to ~7K years. In other words, not likely to run into. If at all, we still decide to specify a handling for sequence number wrapping in future, we should be able to add this to 7432bis draft. EV> fair enough and good math ;-) Section 6 is also silent on this case. ## NITS (non-blocking / cosmetic) ### Use of SVG graphics Suggest to use the "aasvg" for nicer rendering on HTML ;-) [NM]: not sure on how to do this in XML source. will check. EV> indeed, this is easier in a Markdown source
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
