IETF Logo Mail Archive

Re: [pim] Alvaro/PIM: Policy for standards rev selection (IGMP / MLD)

Linus Lüssing <linus.luessing@c0d3.blue> Sat, 28 July 2018 22:59 UTC

Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111E7130E19 for <pim@ietfa.amsl.com>; Sat, 28 Jul 2018 15:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 bMxjhGQzce5G for <pim@ietfa.amsl.com>; Sat, 28 Jul 2018 15:59:29 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [138.201.29.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CB2130E0A for <pim@ietf.org>; Sat, 28 Jul 2018 15:59:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aperture-lab.de (Postfix) with ESMTP id B9EC8E5421; Sun, 29 Jul 2018 00:59:27 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aperture-lab.de
Received: from mail.aperture-lab.de ([127.0.0.1]) by localhost (mail.aperture-lab.de [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 4Ilo0biKEecX; Sun, 29 Jul 2018 00:59:17 +0200 (CEST)
Received: from localhost (ipb218f53d.dynamic.kabel-deutschland.de [178.24.245.61]) (Authenticated sender: linus.luessing@c0d3.blue) by mail.aperture-lab.de (Postfix) with ESMTPSA; Sun, 29 Jul 2018 00:59:17 +0200 (CEST)
Date: Sun, 29 Jul 2018 00:59:14 +0200
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: Stig Venaas <stig@venaas.com>
Cc: Toerless Eckert <tte@cs.fau.de>, pim@ietf.org
Message-ID: <20180728225914.GA1742@otheros>
References: <20180606143024.zqsrxu3qc5d4d4vt@faui48f.informatik.uni-erlangen.de> <CAHANBtKqd1uYse6+LSKka7z7m+LJ_rcKdyAN=WQiyomhpPk5aw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHANBtKqd1uYse6+LSKka7z7m+LJ_rcKdyAN=WQiyomhpPk5aw@mail.gmail.com>
User-Agent: Mutt/1.9.5 (2018-04-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/_MlyHAMeiGYWO6iyYbMLpf5pkeQ>
Subject: Re: [pim] Alvaro/PIM: Policy for standards rev selection (IGMP / MLD)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Jul 2018 22:59:32 -0000

Hi,

I would love to see IGMPv2/MLDv1 deprecated, too.

For batman-adv, a layer 2 mesh routing protocol available in the Linux
kernel, it was a pain to introduce multicast awareness due to the
difficulties caused by the report suppression mechanism specified in
IGMPv2/MLDv1 [0].

And the solution/workaround currently implemented is still not
100% satisfactory.

Regards, Linus

[0]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-report-suppresion


On Thu, Jun 07, 2018 at 10:51:47AM -0700, Stig Venaas wrote:
> Hi
> 
> It would be a great idea to deprecate IGMPv2/MLDv1.
> 
> Perhaps it is also time to start working on progressing IGMPv3/MLDv2
> to Internet Standard?
> 
> Stig
> 
> 
> On Wed, Jun 6, 2018 at 7:30 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> > IETF process / current practices question
> >
> > So, i was writing some 'MUST use MLDv2 (RFC3810)' into some draft (ACP),
> > and was challenged if MLDv1 was not also working. And in this case it was
> > for an ASM (link-local discovery case). Obviously, i would never want
> > to write that MLDv1 is sufficient unless being waterboarded. So i wonder:
> >
> > Given how IGMPv2/MLDv3 are just "updating" IGMPv2/MLDv1, and both the
> > old and new specs are PROPOSED STANDARD, could someone rightfully
> > argue that a spec for an app using ASM (as in this case) should really
> > only require the oldest working protocol of the highest standards
> > level ? Or if not, are there any rules how to decide what to require ?
> > "WG choice" ?
> >
> > Could we / should we (we = PIM WG) try to get IGMPv1/IGMPv2 and MLDv1 obsoleted
> > to eliminate this type of discussion and ensure IGMPv3/MLDv2 will be required ?
> > Whats the process / requirements to get protocols like these obsoleted ?
> > Why should we / could we not do it ? ;-)
> >
> > Cheers
> >     Toerless
> >
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www.ietf.org/mailman/listinfo/pim
> 
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim

v2.23.0 | Report a Bug | By Email