Hi Henning, Thanks for comment. Please find inline comments. From: Henning Rogge via Datatracker <[email protected]> Date: Tuesday, September 14, 2021 at 12:51 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Rtgdir last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12 Reviewer: Henning Rogge Review result: Has Nits
Hi, the RTGDIR asked me to do a review on draft-ietf-bess-evpn-igmp-mld-proxy (which is currently in revision 12). I do not follow the BESS WG (I mostly work with mesh routing protocols), but I am familiar with the issue of "linklocal protocols" (like IGMP/ARP) flooding larger layer2-networks with unnecessary traffic, especially in wireless meshes and high performance networks. In general I think the mechanism in this draft will help to reduce the overhead of multicast traffic and increase the performance in EVPN. I am also (personally) curious if this could help to solve parts of the multicast issues we have in MANET (which is mostly still unsolved). I also think that more figures/tables in this draft should get a footer with a reference number. Most of Standard document (similar to this RFC6513, RFC6514, RFC7432) do not contain too many of figure. Is there any specific case where you think figure would make sense ? Some comments to specific chapters: the 2-item list at the end of chapter 4 feel a bit unnecessary, because they just repeat the following sub-chapter names. Maybe this should be transformed just into a descriptive sentence. 4th section provides summary of overall procedures. Where as subsequent sections are providing more detail. Chapter 9.1, 9.2 and 9.3 contain a figure/graphic that seem to define a packet format. If this a typical way to do this for BGP with one field (with variable octet length) per line? Compare to the more formal way to define a byteformat in the table in chapter 9.4. Looking at precedence in WG and other document (https://datatracker.ietf.org/doc/html/rfc6514#section-4.6) format looks aligned. The flags field also always contain a bit for an IGMP version 1. chapter 9.1 says this is deprecated, chapter 9.2/9.3 don't. If version 1 is not to be supported, why not skip the bit completely? Or is this a flags-field that has already been defined in a different document? When this draft was written initially , there was provision made for IGMP V1 in route. While WG progressed this document, PIM working group is working on deprecating IGMP V1. Some of the older implementation of draft may have already used the bit. So we wanted to make sure those bits are not changed now . and WG had decided to add statement about V1 in document. The list of new ECs in chapter 9.5 could be converted into a table for improved readability. The format of the tables in chapter 13 seem to be unusual (nor border, no lines, no heading). Maybe they can be converted into standard tables? Format of information in this section also is same as https://datatracker.ietf.org/doc/html/rfc7432#section-20 . please let me know if there is specific format you want it to be changed to. The draft contains an (informative) reference to an ID (I-D.ietf-bess-evpn-bum-procedure-updates). I assume this will be changed when both this draft and the reference become an RFC? Yes. Henning Rogge
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
