Subject: [Roll] turnon-8138 review

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 8 Jul 2019 00:40:10 +0000

Hello Authors,

Following is my review of draft-thubert-roll-turnon-rfc8138-02:

Section 5.4. "Rolling Back", says, the administrator SHOULD make sure that all nodes have converged to the "T" flag reset before allowing nodes that do not support the compression in the network.
[RJ] How would a root know that all the nodes have accepted the T-reset? Doesn't this require use of capability flag ? Also I'm not sure if the same capability flag used before can be used here?

Section 5.3. "Double Instance Scenario", says that nodes that do not support 8138 would either not be configured for the new instance, or would be configured to join it as leaves only.
[RJ] Thus I believe there is some non-RPL management involved to tell the legacy nodes to not join the Instance-with-T-flag.

Section 5.2. "Single Instance Scenario", The root encapsulates packets to the leaves all the way to the parent, which decapsulates and distribute the uncompresses inner packet to the leaf.
[RJ] When it says encapsulate/decapsulate, it means IP-in-IP encapsulation/decapsulation, right?

Section 4. "Updating RFC 8138"
[RJ] I didn't find any updates to 8138! I believe the text in the section does not result in 8138 update.

Regards,
Rahul

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 8 Jul 2019 01:52:11 +0000

Thank you Rahul for the reviewing. Please find my reply [LZ] inline.

Best regards,
Li

From: Rahul Arvind Jadhav <[email-masked]>
Date: Monday, July 8, 2019 at 8:40 AM
To: "[email-masked]" <[email-masked]>
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: turnon-8138 review
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Li Zhao <[email-masked]>
Resent-Date: Monday, July 8, 2019 at 8:40 AM

Hello Authors,

Section 5.4. “Rolling Back”, says, the administrator SHOULD make sure that all nodes have converged to the “T” flag reset before allowing nodes that do not support the compression in the network.
[RJ] How would a root know that all the nodes have accepted the T-reset? Doesn't this require use of capability flag ? Also I’m not sure if the same capability flag used before can be used here?
[LZ]Yes. This requires use of  capability flag. I think there is no capability flag before to identify the T-reset. One option is using reserving flag in DAO base object. Another option is leveraging draft-rahul-roll-mop-ext<https://datatracker.ietf.org/doc/draft-rahul-roll-mop-ext/>
Section 5.3. “Double Instance Scenario”, says that nodes that do not support 8138 would either not be configured for the new instance, or would be configured to join it as leaves only.
[RJ] Thus I believe there is some non-RPL management involved to tell the legacy nodes to not join the Instance-with-T-flag.
[LZ] Agree. Section 5 has listed an example method with “Sections 8.5<https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-02#section-8.5> and 9.2<https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-02#section-9.2> of [RFC6550<https://tools.ietf.org/html/rfc6550>]”.

Section 5.2. “Single Instance Scenario”, The root encapsulates packets to the leaves all the way to the parent, which decapsulates and distribute the uncompresses inner packet to the leaf.
[RJ] When it says encapsulate/decapsulate, it means IP-in-IP encapsulation/decapsulation, right?
[LZ] Correct. IP tunnel can be used to encapsulate packet.

Section 4. “Updating RFC 8138”
[RJ] I didn't find any updates to 8138! I believe the text in the section does not result in 8138 update.
[LZ] It means that 8138 SHOULD have enable and disable the use of 8138 compression for compatibility issue. But 8138 missed it. Thus we propose to update 8138.

Regards,
Rahul

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 8 Jul 2019 02:26:14 +0000

Thanks Zhao, Please find my comment inline.

Section 5.4. “Rolling Back”, says, the administrator SHOULD make sure that all nodes have converged to the “T” flag reset before allowing nodes that do not support the compression in the network.
[RJ] How would a root know that all the nodes have accepted the T-reset? Doesn't this require use of capability flag ? Also I’m not sure if the same capability flag used before can be used here?
[LZ]Yes. This requires use of  capability flag. I think there is no capability flag before to identify the T-reset. One option is using reserving flag in DAO base object. Another option is leveraging draft-rahul-roll-mop-ext<https://datatracker.ietf.org/doc/draft-rahul-roll-mop-ext/>
[RJ] the point I wanted to convey is, you may need two flags if rolling back needs to be supported. Flag1 is Supports8138. Flag2 is Enabled8138. For rolling back and for nodes supporting 8138, these nodes need to inform the root with Enabled8138=0 and Supports8138=1 flag.
Secondly, the option you mentioned of using DAO base object for such flags may not be correct. These are target specific flags and a DAO object might carry multiple targets.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jul 2019 07:53:04 +0000

Dear all:

Many thanks to Rahul for his excellent review : )

I agree with Rahul that we are not modifying RFC 8138 but complementing it. We’re back to the long discussion on what “updates” means. Trust me, you do not enter that discussion, it is really a grey zone and caused very long threads for not much outcome AFAIK. For now I’d rather leave it as is because when people implement RFC 8138 it’s good that the RFC header points at this draft so the implementer implements them together. Note that https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-30 chose the same and passed IESG review with it.

I also agree that using MOP-ext is the way to go, and we’d need a flag from the device to indicate in which setting it is operating. Note that this creates a normative dependency => this draft cannot ship before MOP-ext. Note also that this is a “current setting” flag as opposed to a “capability” flag, so it would be good to enlarge a bit the wording in MOP-ext to cover that form of usage.

For the IP in IP, I agree it’s good to clarify. I provided text in https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-30#section-4.3 on how that happens. We can reference it in the next version of this draft. I placed similar text in annex of the RUL draft, see https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#appendix-A. I’ll try to push a fix today.

All the best,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Arvind Jadhav
Sent: lundi 8 juillet 2019 04:26
To: Li Zhao (liz3) <[email-masked]>; [email-masked]
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] turnon-8138 review

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jul 2019 08:27:04 +0000

Dear Rahul and all:

I published 03

Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-roll-turnon-rfc8138

Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-roll-turnon-rfc8138-03

To address your comments. Please let me know if I missed something.

All the best,

Pascal

From: Rahul Arvind Jadhav <[email-masked]>
Sent: lundi 8 juillet 2019 02:40
To: [email-masked]
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: turnon-8138 review

Hello Authors,

Regards,
Rahul