Hi Brian, Thank you for your review and comments. I will post a revision. For now, please see zzh> below. Juniper Business Use Only -----Original Message----- From: Brian Haberman via Datatracker <noreply@xxxxxxxx> Sent: Thursday, February 22, 2024 12:27 PM To: int-dir@xxxxxxxx Cc: bess@xxxxxxxx; draft-ietf-bess-evpn-irb-mcast.all@xxxxxxxx; last-call@xxxxxxxx Subject: Intdir telechat review of draft-ietf-bess-evpn-irb-mcast-09 [External Email. Be cautious of content] 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://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!Bx0bNC3eOL4kGtr34kvBCeiPvJn5p5ANXiHZr-ZJa_wfCj3KVIZ4QsqlBZpRhP64_-HXi10psON49uU$ <https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!Bx0bNC3eOL4kGtr34kvBCeiPvJn5p5ANXiHZr-ZJa_wfCj3KVIZ4QsqlBZpRhP64_-HXi10psON49uU$ >. 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. Zzh> I will add a diagram. 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? Zzh> Are you referring to the following? * If a Tenant Domain contains several BDs, it MUST be possible for a multicast flow (even when the multicast group address is an "any source multicast" (ASM) address), to have sources in one of those BDs and receivers in one or more of the other BDs, without requiring the presence of any system performing PIM Rendezvous Point (RP) functions [RFC7761]. Multicast throughout a Tenant Domain must not require the tenant systems to be aware of any underlying multicast infrastructure. Zzh> It does not say "not using multicast routing". It only says RPs must not be required. One may argue this is not a justified requirement, but the solution in this document does have the nice property that RP is not needed at all. I removed the last sentence, because it is true even in the traditional multicast routing outside the context of EVPN. 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. Zzh> Correct. 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. Zzh> Are you referring to that the following paragraph only references 2236 and 2710? That's an oversight. We now reference 3376 (which obsoletes 2236), 2710, and 3810. In this section, and in the remainder of this document, we assume the reader is familiar with the procedures of IGMP/MLD (see [RFC2236] and [RFC2710]), by which hosts announce their interest in receiving particular multicast flows. 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? Zzh> It does not need to distinguish between SSM and ASM (besides that one uses (s,g) while the other uses (*,g) states triggered by (s,g) or (*,g) joins), and there is no need for an RP even for 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. Zzh> It is actually the IP header information. "Layer 3 multicast state" refers to what we're used to for multicast routing. "layer 2 multicast state" refers to the multicast state in BDs built by IGMP/MLD snooping or the OISM procedures in this document, but it is still (S,G)/(*,G) based. I understand that "layer 2 multicast state" may be misleading - I will add some clarifying text. 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. Zzh> In "An EVPN-PE may run IGMP/MLD snooping procedures on each of its ACs", the snooping is based on RFC4541 (I've added a reference). RFC9251 is also based on RFC4541 - it's about how the snooped states are propagated to other EVPN PEs. Zzh> I see that in an earlier "snooping" reference is to RFC9251. I've changed that to RFC4541. 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? Zzh> SSM is supported. It is not mentioned because there is no special procedure needed for it. I've updated the references (see above). Zzh> Thanks! Zzh> Jeffrey -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
