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> 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> > *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
