Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension
Stig Venaas <stig@venaas.com> Tue, 24 March 2020 16:40 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 F1B9E3A0A6C for <pim@ietfa.amsl.com>; Tue, 24 Mar 2020 09:40:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 F-RHRurkC7Ln for <pim@ietfa.amsl.com>; Tue, 24 Mar 2020 09:40:48 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 A8B7F3A0C5B for <pim@ietf.org>; Tue, 24 Mar 2020 09:40:47 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id b21so21451606edy.9 for <pim@ietf.org>; Tue, 24 Mar 2020 09:40:47 -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:content-transfer-encoding; bh=EjjkB4nSlXVb7xsY4irLIlXmy8Qvf9LEDTgxHLmc8xg=; b=a0BVp2jeT3ZH7xpecUVpupDrUc3oY3CKSWIzIhKwgMjzinnXEBGyLKipURvUb0D7km urViJo0u8xD6hkCwhHCrKKSLi+ZzbrA6HTahKAcN5thAMux5UZtnmtODzlSp5McUoYM7 zVaPnA7oSEE/1dZm2SPOwL4VtyQgboP7OiC7YvXZsDN031DlI3Rs3sBGvNU0Qyup3KWW c8qGrd0G/ZQ5n+htkICs7/Faa05C8ypn7PY653VMzVK2jpBOJQLMBGeYmzRqukcOVpEl lkUw4Ua4GxZZtdIDjycaqJOTxj0KA4eRhDD1JRTlc5sQYU+IYKHgy5oGUvn1kJfoU7Um YOhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EjjkB4nSlXVb7xsY4irLIlXmy8Qvf9LEDTgxHLmc8xg=; b=Q0XProFluB9Oo/CPBdlrevcWgW4+cyTTPNw0fQJVYnwNBNN6U6yO3mlF37aWRBhYrp o9PYeaI1IQTxRRTdfQLDHAw9zevTlLyuIe4XpDmjnKkkC8Usra7NobkfTOeZKMOtN+G5 Y1ARWJO+O8b6yFCvlcExmCT6CfyFxbjID0dEw+dZhr2CqdMqpoi+38HWhIm9vJlTYkVU UAITh0K3ylOt64Ikbh0ruK9M4CBgSOZ93Z23aqemAaDIjMUlRcoEXv9Q4FqW/H2q7diV rFYY7PcmBNV+hjhBZzcz+IpAvodPqPpUwWO2LOlUEJcUdbLdigGeDzqzH54h/uSj4pBb 21cg==
X-Gm-Message-State: ANhLgQ2QQ8JPAW+aVVW/ECaip6o9d8CuTCwX5O7Qhd3w2XaZtOniDW+u TNjjLBZW8mearMZqQWIUAHLC5artGBBRtSkE2DX8TRme
X-Google-Smtp-Source: ADFU+vuThwrXfk9CoaCbmRZyJ+PAsb7R6LH3n+V7ATeY3FSwrRJCqSmld5XrFqjhlIy8kWcUobjyS4QQf0VawMiFuZY=
X-Received: by 2002:a05:6402:1d10:: with SMTP id dg16mr11082436edb.99.1585068045916; Tue, 24 Mar 2020 09:40:45 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR13MB28078BBB7D9233AC6439AFAFF4F90@BYAPR13MB2807.namprd13.prod.outlook.com> <5C6C03E9-A5A9-44A0-A3D9-C98D97C72C34@ieee.org>
In-Reply-To: <5C6C03E9-A5A9-44A0-A3D9-C98D97C72C34@ieee.org>
From: Stig Venaas <stig@venaas.com>
Date: Tue, 24 Mar 2020 09:40:35 -0700
Message-ID: <CAHANBt+wrb=-fL77LfpfSEGykUcmufetuxYeoKBjmZqCpehN0g@mail.gmail.com>
To: Hitoshi Asaeda <asaeda@ieee.org>
Cc: "pim@ietf.org" <pim@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Huu4HzjrM0jZp9rDdcCZKgYok1w>
Subject: Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension
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: Tue, 24 Mar 2020 16:40:51 -0000
Hi Hitoshi Appreciate your detailed response. Sorry for my slow reply. Please see inline. On Mon, Mar 16, 2020 at 7:25 PM Hitoshi Asaeda <asaeda@ieee.org> wrote: > > Hi, > > I like the idea and also wanted to add such optional fields in IGMPv3/MLDv2 that can be used for various purposes. The reasons why I hesitated to propose the additional optional fields in IGMPv3/MLDv2 are as follows; > > This I-D says; > The extension will be part of additional data as mentioned in > [RFC3810] Section 5.1.12 (resp. [RFC3376] Section 4.1.10) for query > messages and [RFC3810] Section 5.2.12 (resp. [RFC3376] > Section 4.2.11) for report messages. > However, for example, sect.4.1.10 in rfc3376 says; > If the Packet Length field in the IP header of a received Query > indicates that there are additional octets of data present, beyond > the fields described here, IGMPv3 implementations MUST include those > octets in the computation to verify the received IGMP Checksum, but > MUST otherwise ignore those additional octets. When sending a Query, > an IGMPv3 implementation MUST NOT include additional octets beyond > the fields described here. > From this last sentence, I understand hosts accepts the longer IGMPv3 query (if the checksum is correct) but ignores the additional fields for the further processes. This may be Ok for existing (conventional) implementations as they simply ignore the additional fields, which they don't understand/proceed. However, you should investigate and mention the situations and conditions in which conventional hosts (that don't support this I-D) and new hosts (that support this I-D) exist in a LAN. Moreover, according to rfc3376, the new hosts that support this I-D must also support rfc3376, which seems a contradiction. This draft would update those RFCs, so that if you implement this draft you will consider the extension types. Otherwise you will ignore it as any current implementations of those RFCs would do. This is similar to when RFCs have reserved bits that MUST be ignored, but later new RFCs will update that. Generally if we add an extension, we cannot expect hosts to support it, or at least it might take years for implementations to add support, so we would always have to assume that the majority of hosts will simply ignore the extension. Due to this I don't foresee many extensions. Generally, we also need to worry about how snooping or proxying devices would handle it. While some of this need to be discussed in individual extension drafts, we should add general text discussing these issues in this draft. The one extension I'm proposing now is specific for BIER. It will only be used in BIER overlay, where support for the extension would be part of writing new code to support IGMP/MLD over BIER. Also, we need not worry about snooping/proxying. > One more another thing is that since IGMP/MLD classifies their version by the packet length, we cannot propose IGMPv4/MLDv3 if you allow this variable length fields in IGMPv3/MLDv2. > > If lucky this I-D is accepted, don't forget to refer Lightweight-IGMPv3/MLDv2 [RFC5790] as they also define the standard IGMPv3/MLDv2 formats. Right, agree. Defining extension types will make it easier to introduce IGMPv4/MLDv3 if we want to. If those were to be backwards compatible, they would I think add extra data in the "additional data" section, and we could define a type indicating IGMPv4/MLDv3 so that we can distinguish between those and other uses of additional data. In your follow-up email you suggest using TLVs rather than just a single extension. I also thought about this. We should definitely have a thorough discussion on this and update the draft to reflect the WG's decisions. I thought about this myself. I've been thinking that extensions will be rare so it may not be worth the complexity. On the other hand, if for instance we define another extension later and we want to use that with BIER, then it would be nice if one could add both extensions using TLVs. Alternatively we would maybe define a 3rd extension that can contain both. TLVs are of course fairly simple to handle, so the complexity isn't very big. Thanks, Stig > Regards, > > Hitoshi > > > > On Mar 17, 2020, at 8:38, Michael McBride <michael.mcbride@futurewei.com> wrote: > > > > Hope everyone is doing well hunkering down. > > > > Today begins a two week call for adoption for https://tools.ietf.org/id/draft-venaas-pim-igmp-mld-extension-01.txt. > > > > Please give it a read (just six pages) and let us know whether or not you support the adoption of this proposal for defining the extensions of IGMP/MLD using a new message type. > > > > Thanks, > > mike > > _______________________________________________ > > 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
- [pim] Call for adoption: draft-venaas-pim-igmp-ml… Michael McBride
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Mankamana Mishra (mankamis)
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Gyan Mishra
- Re: [pim] Call for adoption: draft-venaas-pim-igm… William Atwood
- Re: [pim] Call for adoption: draft-venaas-pim-igm… William Atwood
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Stig Venaas
- Re: [pim] Call for adoption: draft-venaas-pim-igm… zhang.zheng
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Hitoshi Asaeda
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Holland, Jake
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Stig Venaas
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Gyan Mishra
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Hitoshi Asaeda
- Re: [pim] Call for adoption: draft-venaas-pim-igm… zhang.zheng
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Hitoshi Asaeda
- Re: [pim] Call for adoption: draft-venaas-pim-igm… zhang.zheng
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Hitoshi Asaeda
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Stig Venaas
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Stig Venaas
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Hitoshi Asaeda
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Ehsan Hemmati (ehemmati)
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Xiejingrong (Jingrong)
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Ramakrishnan Chokkanathapuram (ramaksun)
- Re: [pim] Call for adoption: draft-venaas-pim-igm… Michael McBride