Last Call Review of draft-ietf-bess-evpn-igmp-mld-proxy-12
review-ietf-bess-evpn-igmp-mld-proxy-12-rtgdir-lc-rogge-2021-09-14-00

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.

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.

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.

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?

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?

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?

Henning Rogge