Telechat Review of draft-ietf-bess-evpn-irb-mcast-09
review-ietf-bess-evpn-irb-mcast-09-intdir-telechat-haberman-2024-02-22-00

I am an assigned INT directorate reviewer for draft-ietf-bess-evpn-irb-mcast.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

I have a number of comments/questions/suggestions about this draft. Happy to be
pointed to other documents where these topics are addressed, but they stood out
to me in this document.

1. Section 1.2 - The (S,G) flow example would benefit greatly from a diagram.
It is difficult to follow the explanation without some visualization of the
connectivity.

2. Section 1.3 - I see very little traceability or justification for the
requirements. For example, what is the genesis of the fourth requirement for
not using multicast routing when you have multiple broadcast domains?

3. Section 1.4 - I am failing to see the distinction in the definitions of
"(S,G) Multicast Frame" and "(S,G) Multicast Packet". I suspect the definition
of the former should be for an ethernet frame carrying an IP multicast packet.

4. Section 1.5.1 - At this point in time, why does the specification mandate
IGMPv2/MLDv1 rather than IGMPv3/MLDv2? Those specifications support ASM as well
as SSM.

5. It appears that this specification is assuming that all multicast addresses
that fall outside of the designated SSM range should be treated as ASM.
However, multicast routers can apply SSM handling procedures to any multicast
group if it has been configured to do so. Will OISM also require a
configuration option to designate which address ranges are SSM vs ASM?

6. Section 4.1 - It is unclear if the forwarding being described is using
ethernet frame information or IP header information. I am assuming the former,
but clarity would be good given the overloaded use of the "(S,G)" nomenclature.

7. Section 4.1.1 - It is unclear if the snooping being described here is based
on RFC 9251 or RFC 4541. Assuming the former, but a reference would be good.

8. The document calls out ASM several times, but never mentions SSM. Given the
references to IGMPv2/MLDv1, does that mean SSM is not supported in this
approach?