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