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> Date: Tuesday, 3 December 2024 at 02:51 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 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
