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

[Toerless Eckert <[e-mail]>]

What is your feeling about making it MAY or SHOULD as opposed to MUST (which it is right now).
Is that something we could do in a doc aspiring for full STD ?

Cheers
    Toerless

On Tue, Nov 30, 2021 at 10:59:35AM -0500, Brian Haberman wrote:
> I tend to agree that exclude mode is a bit complex, but the survey results
> do show that the feature is both implemented by some vendors and enabled by
> some operators.
> 
> Given those statistics, we can't remove the function as a part of the
> process of moving IGMPv3/MLDv2 to full standard.
> 
> Brian
> 
> On 11/29/21 4:57 PM, Mankamana Mishra (mankamis) wrote:
> > I echo same thoughts. I had raised this few IETF earlier that I do not see reason for having ex mode with source list. If there are some real application, it would be good to know.
> > 
> > From: Igmp-mld-bis <[e-mail]> on behalf of Hitoshi Asaeda <asaeda=[e-mail]>
> > Date: Friday, November 26, 2021 at 12:35 AM
> > To: Brian Haberman <[e-mail]>
> > Cc: [e-mail] <[e-mail]>
> > Subject: [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 <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/igmp-mld-bis
> > 
> > --
> > Igmp-mld-bis mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/igmp-mld-bis
> > 




> -- 
> Igmp-mld-bis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/igmp-mld-bis


-- 
---
[e-mail]