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

[Gyan Mishra <[e-mail]>]

I support adoption.

Thanks

Gyan

On Mon, Mar 16, 2020 at 10:25 PM Hitoshi Asaeda <[e-mail]> 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 <[e-mail]>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pim
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pim
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]