Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension

Hitoshi Asaeda <asaeda@ieee.org> Tue, 24 March 2020 06:42 UTC

Return-Path: <asaeda@ieee.org>
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 52B333A07D6 for <pim@ietfa.amsl.com>; Mon, 23 Mar 2020 23:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
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 L4YHOURVsJBz for <pim@ietfa.amsl.com>; Mon, 23 Mar 2020 23:42:19 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 18DF63A0F09 for <pim@ietf.org>; Mon, 23 Mar 2020 23:42:18 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id x1so2990326plm.4 for <pim@ietf.org>; Mon, 23 Mar 2020 23:42:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7uBdAh6RNOmRqdXVQIES3JyGOS36A09EEv9AjCZHdXY=; b=QfT01mZoxBgEbj4pCsGt0XqvkiaqYzV51yc5uDGFK+QpMZqPCtkTDjE5u4NjCwb+zj UZKDJUXmUGDYLqbDIBnQO0Pc9GGu5h11v4naSIWSLukk63Yuf2dFQpU1RXCxZI30Lo+q uyhEcN/5h9p51UfXgoMSrkMfv95kkRqlm0zpI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7uBdAh6RNOmRqdXVQIES3JyGOS36A09EEv9AjCZHdXY=; b=qYUh1qvZtkyXNWJoB4s7vvwaA8eO7LXXoIO1K/+bCisHBfGkFn2H4ZvrRIZtGnqJFY JdClFg5x0TdF2Nqg28hg1vEPwHM4SodnDMtRcaWJ2mEiBfpCBl1615SAKdPvgBnzs4Bd LbmOCRtjNKVvQxFExcCkbppY0Ufet1YUhr0/leEd9C3YXGQV41niVYZyn/3IMDRZBBvd sM2rShhySB6Q4Y7kF0nG/axHm3O4QW8A+ykDz8Pl+pcYWJ4jAGKp3Qtk3gbjwO2Hrq1i mp9BFyVzEGTftTDZyeUG3snbbxqQH9SXiQuH+n/KB8DFUx2W/J79GpkdfEnHIHFQu/1l hymg==
X-Gm-Message-State: ANhLgQ2Sk/syxK7dkJ9b6ogBqfHyaCOt7eM6P8RA74EU3Jn5fcU8aU2C 7yNHngER1aXaar8YofKc9HCpeYY4PNg=
X-Google-Smtp-Source: ADFU+vuGzBMuf3HtdjGFNDJ8COUrfX+4oIrvA6ukfRHeX0Del5jOuG89gyaTmmvO+5M0VtgfDGP0KQ==
X-Received: by 2002:a17:90a:b003:: with SMTP id x3mr3565763pjq.140.1585032137733; Mon, 23 Mar 2020 23:42:17 -0700 (PDT)
Received: from [133.69.36.88] ([133.69.36.88]) by smtp.gmail.com with ESMTPSA id u3sm1340934pjv.32.2020.03.23.23.42.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 23:42:17 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Hitoshi Asaeda <asaeda@ieee.org>
In-Reply-To: <202003241433436754629@zte.com.cn>
Date: Tue, 24 Mar 2020 15:42:12 +0900
Cc: pim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0827C3B5-2576-4891-907A-1EB90786902C@ieee.org>
References: <BYAPR13MB28078BBB7D9233AC6439AFAFF4F90@BYAPR13MB2807.namprd13.prod.outlook.com, 29ECCF43-5D3F-44E6-A27F-5F23A699279C@ieee.org> <202003241433436754629@zte.com.cn>
To: zhang.zheng@zte.com.cn
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/0I8RiFnfCSIviMiioNDisKrbwKQ>
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 06:42:25 -0000

No, it's different.
No length field, no multiple TLV support. And bier-mld only assumes BIER. 

Regards,

Hitoshi


> On Mar 24, 2020, at 15:33, <zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn> wrote:
> 
> Hi Hitoshi,
> 
> 
> 
> Agree with your opinion of the general TLV fields.
> 
> But I don't see much difference between your suggestion and the definition in draft-venaas-pim-igmp-mld-extension.
> 
> May the nested TLV and the extension length make the difference.
> 
> The router, which supports one specific extension type, should know the specific format from the extension type.
> 
> It's just my opinion. :-)
> 
> 
> 
> Thanks,
> 
> Sandy
> 
> 
> 
> 原始邮件
> 发件人:HitoshiAsaeda <asaeda@ieee.org>
> 收件人:张征00007940;
> 抄送人:pim@ietf.org <pim@ietf.org>;
> 日 期 :2020年03月24日 14:16
> 主 题 :Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension
> Sandy,
> 
> My opinion is that the BIER extension should be also encoded into the general TLV fields.
> Current definition in the bier-mld is a patchwork. It is much better to apply general extensions that is useful for other protocols as well, not for the specific protocol.
> It is really worse if the specific extension prohibits other/their extensions for their future use.
> 
> Regards,
> 
> Hitoshi
> 
> 
> > On Mar 24, 2020, at 14:39, <zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn> wrote:
> > 
> > Hi Hitoshi,
> > 
> > 
> > 
> > Thank you for your comments!
> > 
> > You can find the format in section 6 in draft-ietf-bier-mld-04, as Stig answered to Jake's comments.
> > 
> > 
> > 
> > Thanks,
> > 
> > Sandy
> > 
> > 原始邮件
> > 发件人:HitoshiAsaeda <asaeda@ieee.org>
> > 收件人:pim@ietf.org <pim@ietf.org>;
> > 日 期 :2020年03月24日 12:35
> > 主 题 :Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension
> > Hi,
> > 
> > While I've not received any reply for my previous mail regarding the IGMP/MLD extension, I have a few ideas to make the proposal better, IMO.
> > 
> > Currently, this draft just mentions Extension Type and Extension Value at the bottom as the optional field. This optional field should be TLV fields. And the top of the TLV field contains the total length of the extension fields and multiple sub-TLV fields can be allocated.
> > For example, figure 4 should be;
> > 
> >         0                   1                   2                   3
> >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |  Type = 0x11  | Max Resp Code |           Checksum            |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                         Group Address                         |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |                       Source Address [1]                      |
> >        +-                                                             -+
> >        |                       Source Address [2]                      |
> >        +-                              .                              -+
> >        .                               .                               ..
> >        .                               .                               ..
> >        +-                                                             -+
> >        |                       Source Address [N]                      |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |       Extension Type          |    Extension Total Length     |
> >        +-------------------------------+-------------------------------+
> >        |             Type              |             Length            |
> >        +-------------------------------+-------------------------------|
> >        /                             Value                             /
> >        +-------------------------------+-------------------------------+
> >        .                               .                               ..
> >        .                               .                               ..
> >        +-------------------------------+-------------------------------+
> > 
> > This TLV extension gives the possibility to distinguish the version related consideration because the Extension Type field can specify the IGMP/MLD version if any, and support multiple TLV fields.
> > 
> > Regarding the contradiction of the current IGMPv3/MLDv2 RFCs, we should fix the several statements/specifications in the draft standard documents we have been thinking of.
> > 
> > Any comments?
> > 
> > Regards,
> > 
> > Hitoshi
> > 
> > 
> > > On Mar 17, 2020, at 11:24, 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.
> > > 
> > > 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.
> > > 
> > > 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
> > 
> > 
> 
>