Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-irb-extended-mobility-18: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Other thanks to Brian Haberman, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-6lo-use-cases-14-intdir-telechat-bernardos-2022-11-17/ (and it seems that the authors have not yet replied to Brian's review) I hope that this review helps to improve the document, Regards, -éric ## 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Number of authors The explanation for six authors appears sensible, i.e., let's allow this exception. ### Unicast Should the document specify that it works only for unicast IP/MAC addresses ? Or is it implicit in EVPN anyway? ### 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. 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 ? Consider adding references to `MPLS, SRv6, NVO Tunnel*s*` ? ### 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. ### 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 ;) ### 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 ? 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 ;-) ### Section 6.6 s/explcit knowledge/explicit knowledge/ _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
