[bess] Re: Question about default SMET route RFC9251

["Mankamana Mishra (mankamis)" <[e-mail]>]

Hi Nitsan,

This problem being addressed as part of

https://datatracker.ietf.org/doc/html/draft-sajassi-bess-rfc9251-00#section-9.1.3 .

please let me know your thoughts about new test. Last IETF this draft was presented , and open to get input from working group.

Mankamana

From: Nitsan Dolev <[e-mail]>
Date: Monday, May 26, 2025 at 5:06 AM
To: [e-mail] <[e-mail]>, Ali Sajassi (sajassi) <[e-mail]>, Samir Thoria (sthoria) <[e-mail]>, Mankamana Mishra (mankamis) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Question about default SMET route RFC9251
Dear RFC9251 co-authors,

Your help with the following question will be appreciated.

Regarding https://www.rfc-editor.org/rfc/rfc9251.html#section-9.1.3 Default selective Multicast Route:
The text of this section seems to assume that a default SMET can only be created for both IGMP and MLD, I,e, since a * source address is indicated by source address length = 0, while using the same methodology for the Group address would mean that the Group address length should be zero,
This means that one cannot distinguish between an IGMP default SMET Route and MLD default SMET route (unless the version flag combination of V 1/2/3 means IGMP and 1/2 means MLD)

Alternatively, we may deduce that default SMET route means (*,*) under the specific context, which means that if the related EVPN EVI is IGMP-Proxy enabled but MLD Proxy disabled than the received default SMET route only means that the default SMET Route receiving PE shall send only IPv4 Multicast traffic to the advertising remote PE. (…and vice versa)
But if both IGMP Proxy and MLD Proxy are enabled than the default SMET Route receiver shall send all IPv4 and IPv6 Multicast traffic to the default SMET advertising remote PE.

Can you please share your thoughts about my interpretation of RFC9251 default SMET route section 9.1.3?

Looking forward to getting your response,
Regards,
Nitsan Dolev
Ribbon Communications


Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.