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

From: Michael McBride <[email-masked]>
Date: Mon, 16 Mar 2020 23:38:27 +0000

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

---

From: William Atwood <[email-masked]>
Date: Mon, 16 Mar 2020 20:34:32 -0400

I support adoption.

I believe that IANA will require more information than what is currently
contained in Section 8; for example, they will need guidance as to what
to call this new registry.  Is there a guideline for writing IANA
Considerations sections?  I expect so.

  Bill

On 2020-03-16 7:38 p.m., Michael McBride wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: William Atwood <[email-masked]>
Date: Mon, 16 Mar 2020 20:35:00 -0400

I support adoption.

  Bill

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Mar 2020 18:00:42 -0700

Hi Bill

Yes, there are some RFCs on how to write IANA considerations. I know
it is too brief in this draft at this point. It certainly should be
improved before we consider WGLC. We need to specify allocation
guidelines (what is required for someone to get an allocation), the
name of the registry, and the format of the registry (like type and
description). Especially the allocation guidelines is something we
need to discuss.

Thanks,
Stig

On Mon, Mar 16, 2020 at 5:35 PM William Atwood
<[email-masked]> wrote:
>
> I support adoption.
>
> I believe that IANA will require more information than what is currently contained in Section 8; for example, they will need guidance as to what to call this new registry.  Is there a guideline for writing IANA Considerations sections?  I expect so.
>
>   Bill
>

---

From: <[email-masked]>
Date: Tue, 17 Mar 2020 09:04:02 +0800 (CST)

Support as co-author.

Thanks,

Sandy

原始邮件

发件人：MichaelMcBride <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2020年03月17日 07:38
主 题 ：[pim] Call for adoption: draft-venaas-pim-igmp-mld-extension

 

 

 

Thanks,

mike

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 17 Mar 2020 11:24:45 +0900

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 <[email-masked]> wrote:
>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Mar 2020 19:54:53 -0400

I support adoption.

Thanks

Gyan

On Mon, Mar 16, 2020 at 10:25 PM Hitoshi Asaeda <[email-masked]> 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;
> 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
>
>
> you support the adoption of this proposal for defining the extensions of
> IGMP/MLD using a new message type.
> >
> > Thanks,
> > mike
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 24 Mar 2020 13:33:47 +0900

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 <[email-masked]> wrote:
> 
> Hi,
>

---

From: <[email-masked]>
Date: Tue, 24 Mar 2020 13:39:30 +0800 (CST)

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 <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2020年03月24日 12:35
主 题 ：Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension

Hi,

        0                   1                   2                   3

Any comments?

Regards,

Hitoshi

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 24 Mar 2020 15:15:38 +0900

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, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Hitoshi,
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 24 Mar 2020 14:33:43 +0800 (CST)

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 <[email-masked]>
收件人：张征00007940;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2020年03月24日 14:16
主 题 ：Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension

Sandy,

Regards,

Hitoshi

>        .                               .                               ..
>        .                               .                               ..
>        .                               .                               ..
>        .                               .                               ..

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 24 Mar 2020 15:42:12 +0900

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, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Hitoshi,
> 
> 
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Mar 2020 09:40:35 -0700

Hi Hitoshi

Appreciate your detailed response. Sorry for my slow reply. Please see inline.

> 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 (co…

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.

> 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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Mar 2020 09:43:18 -0700

Hi

If there is agreement that we should use TLVs, rather than having a
single field with mutually exclusive extension types, then the BIER
extension should just be one such TLV, allowing it to be combined with
other TLVs.

Thanks,
Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 25 Mar 2020 12:30:23 +0900

Hi Stig,

> On Mar 25, 2020, at 1:40, Stig Venaas <[email-masked]> wrote:
> 
> Hi Hitoshi
> 

It is better to consider other possible scenarios, not only BIER, as IGMP/MLD are the core protocols of every multicast service.

My concern is that the extension format defined in this draft will eliminate the chance of other flexible extensions. Although the specific router/host implementations would distinguish the extension based on the differentiated Extension Type value you defined, yet they cannot support multiple extension fields or other different/complex scenarios.
(BTW I wonder how multiple BFR-Prefix fields can be embedded without a length value while the figure allows the multiple BFR-Prefixes..)

I don't also want to make the extension complex, but encoding with TLV format is simple but flexible.

> can distinguish between those and other uses of additional data.

Right. Version number verification by packet length is embarrassing (and I was opposed it when IGMPv3 was specified, sigh), but using this extension may be only the way to distinguish the future v4/v3 protocols in keeping with the traditional way. Let's carefully define the last resort.

> handle, so the complexity isn't very big.

I don't recommend "another extension later" or "3rd extension" because TLV is simple enough and there is no reason to later consider the interoperability or compatibility between non-TLV extensions and TLV extensions.

Regards,

Hitoshi

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 30 Mar 2020 01:25:28 +0000

I support the adoption.

Thanks
Jingrong

From: pim [mailto:[email-masked]] On Behalf Of Michael McBride
Sent: Tuesday, March 17, 2020 7:38 AM
To: [email-masked]
Subject: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension

Thanks,
mike