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. ## DISCUSS (blocking) > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a > DISCUSS ballot is just a request to have a discussion on the following > topics: > > ### Section 1 > > What about IPv6 NDP in `the IP address is incorporated into the local ARP > table` ? The "equivalence" ARP-NDP only appears in section 2. > > Just use "in the local NDP/ARP tables" to address this point. > [NM]: addressed in rev19. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ## COMMENTS (non-blocking) > > ### Number of authors > > The explanation for six authors appears sensible, i.e., let's allow this > exception. [NM]: Many thanks. > ### Unicast > > Should the document specify that it works only for unicast IP/MAC > addresses ? > Or is it implicit in EVPN anyway? > [NM]: ack. Have modified the abstract text in rev19 to clarify this. > > ### 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. > > 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. > > Consider adding references to `MPLS, SRv6, NVO Tunnel*s*` ? > [NM]: ack. added all references in rev19. > > ### Section 2 > > In 2024, I would prefer s/ARP references in this document are equally > applicable to ND as well./NDP references in this document are equally > applicable to ARP as well./ and having this document only using NDP in the > text. > [NM]: Since most places in the document were already using ARP / ND terminology, I have replaced all such references in place to ARP / NDP in rev19. > > ### Section 3.2.2.2 > > s/all host IPs learned/all host IP addresses learned/ > > s/A host IP move/A host IP address move/ > > This oversimplification happens in several places, i.e., I won't mention > all of > the occurences ;) > [NM]: ack. addressed in rev19. > > ### 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. > > 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. > ### Section 6.6 > > s/explcit knowledge/explicit knowledge/ > [NM]: addressed in rev19. Thanks, Neeraj
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
