Thanks for comment. Please find inline comments.
From:
Henning Rogge via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, September 14, 2021 at 12:51 AM
To: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>, draft-ietf-bess-evpn-igmp-mld-proxy.all@xxxxxxxx <draft-ietf-bess-evpn-igmp-mld-proxy.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
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
