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

[Hitoshi Asaeda <[e-mail]>]

Thanks Toerless. I admit to your thoughts.

Then what do you think if we first propose the full IGMPv3/MLDv2 to be the Internet Standard as they have been longly known as the standard protocols and already developed by vendors, and after their completion, we propose their lightweight version (rfc5790bis) to be the Internet Standard as well as they are useful for future implementations especially for IoT devices (and possibly smartphone/tablets).

It's not bad to finish making the full version Internet Standard now and start rfc5790bis work for lightweight devices later (or even in parallel).

What do you think? Brian?

Regards,

Hitoshi


> On Dec 4, 2021, at 10:44, Toerless Eckert <[e-mail]> wrote:
> 
> Thats what i was going for, only that i remember that we had a really
> hard and long time getting RFC5790 out, so i wonder what changes we
> would want to do to avoid it this time.
> 
> Likewise, RFC5790 did never
> claim to update/superceed existing IGMPv2/MLDv2, but given all the
> complexities that EXCLUDE(S+,G) introduces, it would really be good
> if we could have IGMPv3lite become the recommended option for
> new implementations.
> 
> But i do see a bit wat Brian was pointing to: The way IETF standard levels
> work, it may look weird to both declare the "complex' full IGMPv3/MLDv2
> to be full standard (which they rightfully are) and to simultaneously say
> "but please from now on implement a stripped down version, so we can streamline
> the ecosystem around the protocol".
> 
> Cheers
>    Toerless
> 
> On Fri, Dec 03, 2021 at 01:39:40PM -0800, Mike McBride wrote:
>> I really like that plan Hitoshi.
>> 
>> mike
>> 
>> On Fri, Dec 3, 2021 at 7:05 AM Hitoshi Asaeda <asaeda=
>> [e-mail]> wrote:
>> 
>>> So, what do you all think of first making the Internet Standard for the
>>> full version of IGMPv3 and MLDv2 and then updating rfc5790 (rfc5790bis?) to
>>> completely remove EXCLUDE (S,G)?
>>> 
>>> Regards,
>>> 
>>> Hitoshi
>>> 
>>>> On Dec 1, 2021, at 22:29, Toerless Eckert <[e-mail]> wrote:
>>>> 
>>>> Think of it as just rfc5790bis with maybe the key goals
>>>> being to describe it as an update of the TBD full standard
>>>> IGMPv2/MLDv2 bis RFCs.
>>>> 
>>>> Currently, rfc5790 is just a derived standard without claiming
>>>> to update/superceed IGMPV3/MLDv2.
>>>> 
>>>> Cheers
>>>>   Toerless
>>>> 
>>>> On Wed, Dec 01, 2021 at 08:09:08AM -0500, Brian Haberman wrote:
>>>>> Hey Toerless,
>>>>>    So these new drafts would essentially be IGMPv4 and MLDv3?
>>>>> 
>>>>> Brian
>>>>> 
>>>>> On 12/1/21 8:07 AM, Toerless Eckert wrote:
>>>>>> I don't see the conflict you seem to see.
>>>>>> IGMPv3/MLDv2 should rightfully be full Internet standards
>>>>>> given their wide distribution, we just need to go through IETF
>>>>>> process hell.
>>>>>> 
>>>>>> Likewise, we did for 20 years in the IETF (IMHO) agree that we
>>>>>> wanted to simplify our solution suite, and in the case of IGMPv3/MLDv2
>>>>>> this means to not use EXCLUDE(S+,G).
>>>>>> 
>>>>>> This is jut playing by the rules. If we can not get full standard
>>>>>> for what (AFAIK) we want (the simple subset used in 99% deployments),
>>>>>> then wee just need to write docs according to how IETF wants us to.
>>>>>> 
>>>>>> Not ?
>>>>>> 
>>>>>> Cheers
>>>>>>    Toerless
>>>>>> 
>>>>>> On Wed, Dec 01, 2021 at 07:04:20AM -0500, Brian Haberman wrote:
>>>>>>> It seems a bit odd to promote IGMP/MLD to Internet Standard and then
>>>>>>> immediately issue an update of them. If the WG wants to do that, I
>>> would
>>>>>>> suggest stopping the current promotion effort and re-vector the
>>> drafts.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Brian
>>>>>>> 
>>>>>>> On 11/30/21 5:05 PM, Toerless Eckert wrote:
>>>>>>>> Right.
>>>>>>>> 
>>>>>>>> How about plan B: We do not modify the target IGMP/MLD bis text, but
>>> we start a
>>>>>>>> small new (proposed standard) draft that updates the full-standard
>>> bis text and
>>>>>>>> deprecates EXCLUDE{S+,G} memberships - similar to how we deprecated
>>> interdomain
>>>>>>>> ASM via rfc8815, except thart its not BCP but stds track as it talks
>>> about
>>>>>>>> protocol functionality.
>>>>>>>> 
>>>>>>>> Effectively, by being a delta against the IGMP/MLD bis text it would
>>> hopefully
>>>>>>>> be a much simpler version of the "light" variant.
>>>>>>>> 
>>>>>>>> Cheers
>>>>>>>>     Toerless
>>>>>>>> 
>>>>>>>> On Tue, Nov 30, 2021 at 01:15:19PM -0500, Brian Haberman wrote:
>>>>>>>>> That is a gray area... RFCs 2026 and 6410 do not mention changes to
>>> the 2119
>>>>>>>>> language. I think it best to raise that question with our AD or the
>>> IESG.
>>>>>>>>> 
>>>>>>>>> Brian
>>>>>>>>> 
>>>>>>>>> On 11/30/21 11:18 AM, Toerless Eckert wrote:
>>>>>>>>>> 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]
>>> 
>>> --
>>> Igmp-mld-bis mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis
>>> 
> 
> -- 
> ---
> [e-mail]