Skip to main content

Telechat Review of draft-ietf-bess-evpn-irb-mcast-09

Request Review of draft-ietf-bess-evpn-irb-mcast
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2024-02-29
Requested 2024-02-18
Requested by Éric Vyncke
Authors Wen Lin , Zhaohui (Jeffrey) Zhang , John Drake , Eric C. Rosen , Jorge Rabadan , Ali Sajassi
I-D last updated 2024-02-22
Completed reviews Intdir Telechat review of -09 by Brian Haberman (diff)
Genart Last Call review of -09 by Stewart Bryant (diff)
Secdir Last Call review of -08 by Tirumaleswar Reddy.K (diff)
Rtgdir Last Call review of -07 by Acee Lindem (diff)
Assignment Reviewer Brian Haberman
State Completed
Request Telechat review on draft-ietf-bess-evpn-irb-mcast by Internet Area Directorate Assigned
Posted at
Reviewed revision 09 (document currently at 11)
Result Ready w/issues
Completed 2024-02-22
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

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

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