[Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode

Hi Brian and all,

What do you think of remove the EXCLUDE(S,G) filter mode operation from the standard IGMPv3/MLDv2?

There was a draft in PIM WG based on the inquiry to operators about IGMP/MLD implementation and operation status in the global networks. Were there any reports about such filter mode operation? Does someone know there are any specific use cases/applications or precise reasons to keep EXCLUDE(S,G) join in the protocol spec?

I guess EXCLUDE(S,G) is not commonly used by applications to block unnecessary sources. Even if a user wants tp explicitly refuse traffic from some sources in a group, the sources can be ignored by the application itself, not by the protocol or kernel (i.e. IGMP/MLD host side implementation).
In fact, having both INCLUDE(S,G) and EXCLUDE(S,G) filter mode operations makes the state transition in the host side implementation very complex. Even worse, EXCLUDE(S,G) requests to (re)initiate ASM tree ((*,G) tree) even though SSM tree is already created at that time. (Well, in any case, SSM can be easily stopped by receiving an EXCLUDE(S,G) or (*,G) join request, and hence SSM applications must use the SSM address range and any EXCLUDE request must be ignored for them.)

RFC5790, Lightweight IGMPv3/MLDv2, simplifies the full IGMPv3/MLDv2. It also supports/interoperates with the full version; it translates EXCLUDE(S,G) join to (*,G) join when an application requests EXCLUDE(S,G) join.
Lightweight IGMPv3/MLDv2 is hence more feasible than the full version of IGMPv3/MLDv2. But it does not ignore the EXCLUDE(S,G). It requires to implement such translation or "mapping" function, which should be eliminated from the protocol if possible. IMO, to make the protocol simpler, EXCLUDE(S,G) filter mode operation should be completely removed from the protocol.

Any comment?

Regards,

Hitoshi

> On Nov 18, 2021, at 0:43, Brian Haberman <brian@innovationslab.net> wrote:
> 
> All,
>     I will not be able to make today's call. I believe there are two primary things to do next...
> 
> 1. Start a discussion on whether to move IGMPv1, IGMPv2, and MLDv1 to Historic status,
> 
> 2. Determine if/what functionality from RFC 4604 needs to be incorporated into the bis drafts.
> 
> Other items to work on?
> 
> Regards,
> Brian
> -- 
> Igmp-mld-bis mailing list
> Igmp-mld-bis@ietf.org
> https://www.ietf.org/mailman/listinfo/igmp-mld-bis