Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC

From: Michael McBride <[email-masked]>
Date: Tue, 8 Dec 2020 00:23:42 +0000

Hello all,

Today begins a two week wglc for https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02

Please review (it's a quick read) and let us know your opinion on it's readiness to progress to the iesg.

Thanks,
mike

---

From: Stig Venaas <[email-masked]>
Date: Sun, 13 Dec 2020 08:53:47 -0800

Hi all

This draft is in WGLC, but it has been very quiet. I'm hoping some of
you can find the time to read through it and comment. It's a fairly
short draft.

Thanks,
Stig

On Mon, Dec 7, 2020 at 4:23 PM Michael McBride
<[email-masked]> wrote:
> Please review (it’s a quick read) and let us know your opinion on it’s readiness to progress to the iesg.
>
>
>
> Thanks,
>
> mike
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: <[email-masked]>
Date: Mon, 14 Dec 2020 08:26:34 +0800 (CST)

Support the advancement of this draft as co-author.

Thanks,

Sandy

原始邮件

发件人：MichaelMcBride
收件人：[email-masked];
日 期 ：2020年12月08日 08:24
主 题 ：[pim] draft-ietf-pim-igmp-mld-extension WGLC

Hello all,

 

 

Thanks,

mike

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 14 Dec 2020 14:06:23 +0900

Hi,

This is a short but very important draft for the basic host-router multicast communications as this provides the common IGMP/MLD extension fields.
It's good to move forward.

Regards,

Hitoshi

> On Dec 14, 2020, at 1:53, Stig Venaas <[email-masked]> wrote:
> 
> Hi all
>

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 15 Dec 2020 10:48:10 -0800

A few minor nits:

-Sect3, 1st sentence: "A previously reserved bit in the IGMPv2 and MLDv2 
headers..."
	-did you mean IGMPv3?

-Sect4, 1st para, penultimate sentence: "...if they support non of the 
extension types..."
	-"none" instead of "non"

Otherwise, looks good to me to progress.

-Lenny

On Sun, 13 Dec 2020, Stig Venaas wrote:

| 
| 
| Hi all
| 
| This draft is in WGLC, but it has been very quiet. I'm hoping some of
| you can find the time to read through it and comment. It's a fairly
| short draft.
| 
| Thanks,
| Stig
| 
| On Mon, Dec 7, 2020 at 4:23 PM Michael McBride
| <[email-masked]> wrote:
| >
| > Hello all,
| >
| >
| >
| > Today begins a two week wglc for https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02__;!!NEt6yMaO-gk!WP1Dg8iBl-8iIwKxP4jPe3EGdtsUBL_UFArvxu1Qgm2c9ufO9Gf-K5M3tmN63lk$
| >
| >
| >
| > Please review (it?s a quick read) and let us know your opinion on it?s readiness to progress to the iesg.
| >
| >
| >
| > Thanks,
| >
| > mike
| >
| > _______________________________________________
| > pim mailing list
| > [email-masked]
| > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!WP1Dg8iBl-8iIwKxP4jPe3EGdtsUBL_UFArvxu1Qgm2c9ufO9Gf-K5M3JofNoyE$
| 
| _______________________________________________
| pim mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!WP1Dg8iBl-8iIwKxP4jPe3EGdtsUBL_UFArvxu1Qgm2c9ufO9Gf-K5M3JofNoyE$
|

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 16 Dec 2020 02:21:18 +0000

Support progressing this work.

I have a couple of curiosity questions on the following:

   Note that there may be additional data following this extension.  The
   Total Extension Length field would indicate where this extension
   ends, and the additional data starts.

How would you have additional data following this extension? The TLV mechanism seems to be universal/generic to handle all possible extensions, so why would you have another extension blob after this, and how would you indicate so? By another bit in the reserved field?
Just wondering if this additional data needs to be mentioned at all.

  Also, there is a possibility
   that an implementation uses the Additional Data part of IGMP/MLD
   messages, but not according to this extension scheme.

Do you mean a non-standard existing implementation? Now that you mention that, are we supposed to define the interop procedures? Are they supposed to interop with the implementations following this draft at all?

Also, for the following:

   The extension will be part of additional data as mentioned in

   [RFC3810] Section 5.1.12<https://tools.ietf.org/html/rfc3810#section-5.1.12> (resp.  [RFC3376] Section 4.1.10<https://tools.ietf.org/html/rfc3376#section-4.1.10>) for query

   messages and [RFC3810] Section 5.2.12<https://tools.ietf.org/html/rfc3810#section-5.2.12> (resp.  [RFC3376]<https://tools.ietf.org/html/rfc3376#section-4.2.11>

   Section 4.2.11<https://tools.ietf.org/html/rfc3376#section-4.2.11>) for report messages.

5.2.12 should be 5.2.11.

Jeffrey

From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Monday, December 7, 2020 7:24 PM
To: [email-masked]
Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC

[External Email. Be cautious of content]

Hello all,

Today begins a two week wglc for https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02__;!!NEt6yMaO-gk!U4mK606KM0ZrTIM1QF0yL3WB9NyFG1GlMc4OewxOWjcDUuzrpumqho-EBxMMejks$>

Thanks,
mike

Juniper Business Use Only

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 16 Dec 2020 12:07:57 +0900

Hi,

> On Dec 16, 2020, at 11:21, Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> wrote:
> 

I think this is a good question.
IMO, the text, "Note that there may be additional data following this extension.", should be replaced to "Note that additional TLV or some specific fields may be nested (i.e., enclosed) in the Extension Value field in the TLV field defined in this document."

> Do you mean a non-standard existing implementation? Now that you mention that, are we supposed to define the interop procedures? Are they supposed to interop with the implementations following this…

I also think this text is strange.
Can we simply remove this text?

Regards,

Hitoshi

>    [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.
>  
> 5.2.12 should be 5.2.11.
>  
> Jeffrey
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 16 Dec 2020 04:27:03 +0000

Hi,

I support the publication of the draft.

Thanks
Jingrong

From: pim [mailto:[email-masked]] On Behalf Of Michael McBride
Sent: Tuesday, December 8, 2020 8:24 AM
To: [email-masked]
Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC

Hello all,

Thanks,
mike

---

From: Stig Venaas <[email-masked]>
Date: Thu, 17 Dec 2020 15:25:57 -0800

Hi Jeffrey

I appreciate your comments, please see responses inline.

> Just wondering if this additional data needs to be mentioned at all.

I agree that there should be no need for additional data for future
extensions as TLVs can provide any potential extension. If the WG and
co-authors agree, I'm happy to remove the additional additional data.
We can then also simplify the length check and say that the extension
length specified must be equal to the remaining payload (subtracting
from packet payload length).

> Do you mean a non-standard existing implementation? Now that you mention that, are we supposed to define the interop procedures? Are they supposed to interop with the implementations following this…

The IGMP/MLD RFCs specify how additional data may be present and how
it should be ignored. I've seen cases where implementations
intentionally (or maybe by accident) have sent packets with additional
data. I think it is safest to use a reserved bit to clearly indicate
that this extension is in place, rather than trying to parse whatever
additional data may be present.

If we receive data from an existing implementation, the reserved bit
would not be set, and we would process it exactly as before.
If an existing implementation receives the new IGMP/MLD message, it
would both ignore the reserved bit, and the additional data according
to the RFCs (although if implementations tried to use additional data
in some way, then they might break, but I think we have to live with
that). They were not supposed to use it.

When using the extension, one must consider interoperability with
implementations that do not support the extension mechanism, as well
as implementations that do not support the specified types. Not
supporting the mechanism, should be equivalent to not supporting any
of the types.

I can try to add a few more details in the draft.
>    Section 4.2.11) for report messages.

Good catch!

Let me know if you have any thoughts on what I wrote above, or anything else.

Thanks,
Stig