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

From: Brian Haberman <[email-masked]>
Date: Wed, 1 Dec 2021 07:04:20 -0500

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 <[email-masked]> on behalf of Hitoshi Asaeda <asaeda=[email-masked]>
>>>>> Date: Friday, November 26, 2021 at 12:35 AM
>>>>> To: Brian Haberman <[email-masked]>
>>>>> Cc: [email-masked] <[email-masked]>
>>>>> 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 <[email-masked]> 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
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis
>>>>>
>>>>> --
>>>>> Igmp-mld-bis mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis
>>>>>
>>>
>>>
>>>
>>>
>>>> -- 
>>>> Igmp-mld-bis mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis
>>>
>>>
> 
> 
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 1 Dec 2021 14:07:52 +0100

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

-- 
---
[email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Wed, 1 Dec 2021 08:09:08 -0500

Hey Toerless,
      So these new drafts would essentially be IGMPv4 and MLDv3?

Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 1 Dec 2021 14:29:00 +0100

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

-- 
---
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 4 Dec 2021 00:05:24 +0900

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 <[email-masked]> wrote:
>

---

From: Mike McBride <[email-masked]>
Date: Fri, 3 Dec 2021 13:39:40 -0800

I really like that plan Hitoshi.

mike

On Fri, Dec 3, 2021 at 7:05 AM Hitoshi Asaeda <asaeda=
[email-masked]> 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
>
> >>>>>>>>> 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 <[email-masked]> on behalf of
> Hitoshi Asaeda <asaeda=[email-masked]>
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 4 Dec 2021 02:44:41 +0100

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

-- 
---
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 4 Dec 2021 12:19:28 +0900

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 <[email-masked]> wrote:
>