Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode
Toerless Eckert <tte@cs.fau.de> Sat, 04 December 2021 01:44 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: igmp-mld-bis@ietfa.amsl.com
Delivered-To: igmp-mld-bis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550FC3A0D6B for <igmp-mld-bis@ietfa.amsl.com>; Fri, 3 Dec 2021 17:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOFY3KTF3aSP for <igmp-mld-bis@ietfa.amsl.com>; Fri, 3 Dec 2021 17:44:51 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44553A0D67 for <igmp-mld-bis@ietf.org>; Fri, 3 Dec 2021 17:44:51 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 73D0B548019; Sat, 4 Dec 2021 02:44:41 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 61BD34E9F82; Sat, 4 Dec 2021 02:44:41 +0100 (CET)
Date: Sat, 04 Dec 2021 02:44:41 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Mike McBride <mmcbride7@gmail.com>
Cc: Hitoshi Asaeda <asaeda=40ieee.org@dmarc.ietf.org>, "igmp-mld-bis@ietf.org" <igmp-mld-bis@ietf.org>, Brian Haberman <brian@innovationslab.net>, "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
Message-ID: <YarICUoDxvJoD3nj@faui48e.informatik.uni-erlangen.de>
References: <4151be72-cc63-1997-e659-a8c0c155795d@innovationslab.net> <YaZO2lpTYTGfTnmM@faui48e.informatik.uni-erlangen.de> <20c39aaa-d755-5ff8-f4f7-2147917b019c@innovationslab.net> <YaagNpCquCDqGM81@faui48e.informatik.uni-erlangen.de> <bed676b1-5106-da13-6bd7-dc86de6a8063@innovationslab.net> <YadzqDuZ+TSqohri@faui48e.informatik.uni-erlangen.de> <8150ddcd-a5e2-a88d-9050-8f8f518495e9@innovationslab.net> <Yad4nJzjSEAh8BJ4@faui48e.informatik.uni-erlangen.de> <7213858D-BF59-4B55-991F-5B722D46C62D@ieee.org> <CAL3FGfwUBBx_4xZvOLB3C89==ZZcxE_mAcnzx8F0DVys3L6aaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL3FGfwUBBx_4xZvOLB3C89==ZZcxE_mAcnzx8F0DVys3L6aaw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/igmp-mld-bis/hAH8XIkBD3blDXqEYsz3_zExw64>
Subject: Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode
X-BeenThere: igmp-mld-bis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IGMPv3/MLDv2 <igmp-mld-bis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/igmp-mld-bis>, <mailto:igmp-mld-bis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/igmp-mld-bis/>
List-Post: <mailto:igmp-mld-bis@ietf.org>
List-Help: <mailto:igmp-mld-bis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/igmp-mld-bis>, <mailto:igmp-mld-bis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Dec 2021 01:44:56 -0000
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= > 40ieee.org@dmarc.ietf.org> 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 <tte@cs.fau.de> 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 <igmp-mld-bis-bounces@ietf.org> on behalf of > > Hitoshi Asaeda <asaeda=40ieee.org@dmarc.ietf.org> > > >>>>>>>>> Date: Friday, November 26, 2021 at 12:35 AM > > >>>>>>>>> To: Brian Haberman <brian@innovationslab.net> > > >>>>>>>>> Cc: igmp-mld-bis@ietf.org <igmp-mld-bis@ietf.org> > > >>>>>>>>> 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 < > > 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 > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> Igmp-mld-bis mailing list > > >>>>>>>>> Igmp-mld-bis@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis > > >>>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> -- > > >>>>>>>> Igmp-mld-bis mailing list > > >>>>>>>> Igmp-mld-bis@ietf.org > > >>>>>>>> https://www.ietf.org/mailman/listinfo/igmp-mld-bis > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > -- > > Igmp-mld-bis mailing list > > Igmp-mld-bis@ietf.org > > https://www.ietf.org/mailman/listinfo/igmp-mld-bis > > -- --- tte@cs.fau.de
- [Igmp-mld-bis] 11/17 call Brian Haberman
- [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Hitoshi Asaeda
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Mankamana Mishra (mankamis)
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Brian Haberman
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Toerless Eckert
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Brian Haberman
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Toerless Eckert
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Mankamana Mishra (mankamis)
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Brian Haberman
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Toerless Eckert
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Brian Haberman
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Toerless Eckert
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Hitoshi Asaeda
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Mike McBride
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Toerless Eckert
- Re: [Igmp-mld-bis] Remove EXCLUDE(S,G) filter mode Hitoshi Asaeda