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

[Brian Haberman <[e-mail]>]

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
>>>>>
>>>>>
>>>
>>>
>>>
>>>
> 
> 
> 
>