Reviewer: Brian Haberman Review result: Ready with Issues 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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
