Re: [pim] AD Review of draft-ietf-pim-igmp-mld-extension-04

Stig Venaas <stig@venaas.com> Fri, 10 September 2021 17:04 UTC

Return-Path: <stig@venaas.com>
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 B690E3A0E2D for <pim@ietfa.amsl.com>; Fri, 10 Sep 2021 10:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com
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 zey6VQizKZHU for <pim@ietfa.amsl.com>; Fri, 10 Sep 2021 10:04:24 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750373A0E2C for <pim@ietf.org>; Fri, 10 Sep 2021 10:04:24 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id h29so2738241ila.2 for <pim@ietf.org>; Fri, 10 Sep 2021 10:04:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NMGntRK+K1DMzU3M1mmZIiz75Fp5bMDqv6avB4E7LIM=; b=zEatImoa3sKztnutdJdx20Uc75clWb60AemXU6IS6owvREqrVn+MYro64mC+qZJ3wa Xx8fucZe0aE5Bqq4CTg8YQR/HSeLi2KSnHuDCi+mXnqtSpIJigd1QGnIqttgaAfljb0M d3yGt4unXUAhJAOEI+VC6/eTVuYPuOFAZOW25KkRdNMBz8W4jtCPPdrSlBIT4WfB1szJ fifPg7RUqYcGzOaSZFhfYnYMaz9kB7odc/m2fstDGhVjzTRXifIL+RuMQZ8KygbuQQUB eIDoWr6RCka1JKtqx2yzq0mb68WUyAkXruOerooh9N5dTdvdXC4UA9RvrPj/YGEUVNg5 Rvrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NMGntRK+K1DMzU3M1mmZIiz75Fp5bMDqv6avB4E7LIM=; b=BTH3iYk+KQbM5ZthsickK+2JoR+DnVCdF4kdRfd6yYmvt3uTB+3f3ZfEr5kCTz+C/9 LKm/R2iE+HqjavtaoJuB5+fLJsE/PjfahtTXZ4/+p+Hl6nbYM56xXKImPeovvMpi3o+n BMT9pXzjbgNpXKsjA5/lRKxndPRfi2oK6ejEl12h5CSDrbLH4AGvzrjdrioydMtbu2XM Ogw4qLzt2oWj1c2EqR2HW2VFG/wbpuXNChhbzAaggCWYHBCAIr3U4xn9XI6Sqi96fyka /9nlr9heNLw7+UHnMVYbGWK+EQotqvLRrwGwc5bVlh7Dj/SK7VZjvw+BVl+Ew1mUtiZ4 q1Ow==
X-Gm-Message-State: AOAM533tCc7F+7W7BSLkWpFS7fpHL97VEVTkB/DM1PqR8LEPFMwDuHRY nuxyvsZVIBSGEfyM3V96h28Ji8VssLw6HRmEhCqRQiWuoX3yTA==
X-Google-Smtp-Source: ABdhPJzGSZSIIcvaUPRnY7ezT2TW7sdrWTX7bYaL7UP/EXBUqpjbRO2UFTUs3qOgP1ioql31LL7PZ/z0E61+vZkD8QU=
X-Received: by 2002:a92:cd05:: with SMTP id z5mr6769812iln.206.1631293462423; Fri, 10 Sep 2021 10:04:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsw2QqJDbW3WXMNuH39DV5nDRf2925vWq9ECMnDsgtjrMQ@mail.gmail.com> <4cc46c5f-dde0-eaf0-931f-f44b8d6259b0@innovationslab.net>
In-Reply-To: <4cc46c5f-dde0-eaf0-931f-f44b8d6259b0@innovationslab.net>
From: Stig Venaas <stig@venaas.com>
Date: Fri, 10 Sep 2021 10:04:11 -0700
Message-ID: <CAHANBt+nDBwekwLgDFM6XdWFmm=vMbdnUfxfJ2_7yNJ+zYdgag@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Cc: pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/ZHwsZcMOXGAvOh2Ftf2p2YclMXQ>
Subject: Re: [pim] AD Review of draft-ietf-pim-igmp-mld-extension-04
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 10 Sep 2021 17:04:29 -0000

Hi Alvaro and Brian

As you noted Brian, when supporting this it would require relaxing at
least that one rule. Also, don't we generally make it an update when
we define use of previously reserved bits?

Note that any implementation of the existing IGMPv3/MLDv2 would ignore
this extension, which is what we want. But if an implementation is to
send messages using the new extension, it would have to deviate from
some existing text in e.g. 3376.

I believe this is similar to e.g. reserved bits in general. A base
protocol RFC would typically define reserved bits with text about how
they must be set to 0 and ignored, in order to allow future
extensions. Then new documents would say that you would set some of
these bits in certain cases, hence deviating from the base RFC
requirements. Wouldn't we then say that the new draft updates the old
one? What is the general procedure?

In this case we are also talking about sending additional octets, but
it is essentially the same as reserved bits. 3376 says to not send
additional data, but also to ignore the data if present.

Thanks,
Stig




On Fri, Sep 10, 2021 at 5:10 AM Brian Haberman <brian@innovationslab.net> wrote:
>
> Hey Alvaro,
>
> On 9/9/21 5:15 PM, Alvaro Retana wrote:
> > Dear authors:
> >
> > Thank you for this document!
> >
> > In general, I think this document is in good shape -- I do have
> > comments and suggestions below (inline) that I would like to see
> > addressed before publication.
> >
> > My main concern is the formal Update of rfc3376 and rfc3810.  Do we
> > really need to formally Update those documents?  I didn't see a
> > specific discussion on the list about this topic.
> >
>
> I think the WG needs to think about this a bit given that we are in the
> process of publishing 3376 and 3810 updates in order to move them to
> Internet Standard. In general, I agree with the sentiment that optional
> extensions do not need to update the base specification. However, we may
> have an issue here as section 4.1.10 of 3376 states:
>
> ... When sending a Query,
>    an IGMPv3 implementation MUST NOT include additional octets beyond
>    the fields described here.
>
> This extension document has to relax that rule in 3376 IMO.
>
> We can't add the necessary extension text to the -bis drafts if we want
> to make them Internet Standards.
>
> Regards,
> Brian
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim