Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt

From: [email-masked]
Date: Wed, 22 Jan 2020 03:13:33 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.

        Title           : Configuration option for RFC 8138
        Authors         : Pascal Thubert
                          Li Zhao
	Filename        : draft-ietf-roll-turnon-rfc8138-03.txt
	Pages           : 8
	Date            : 2020-01-22

Abstract:
   This document complements RFC 8138 and dedicates a bit in the RPL
   configuration option defined in RFC 6550 to indicate whether RFC 8138
   compression is used within the RPL Instance.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03
https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jan 2020 11:17:24 +0000

Dear all

This publication addresses the first round of review by Rahul (many thanks Rahul!).
If Rahul is OK with the proposals then I believe we can move to WGLC.

All the best

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of [email-masked]
Sent: mercredi 22 janvier 2020 12:14
To: [email-masked]
Cc: [email-masked]
Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 22 Jan 2020 15:51:51 +0000

Thank you Pascal, Li for the changes.

One comment based on the changes:
Section 5:
"A parent propagates the "T" flag as set whether it supports RFC 8138 or not."
[RJ] I think this is confusing. Consider that the parent does not support RFC 8138... according to this text a parent may propagate "T" flag = 1, but this is not possible.

Nit:
"...connectivity regardless on the way the RPL..."
on the way -> of the way

Best,
Rahul

From: Roll <[email-masked]> on behalf of Pascal Thubert (pthubert) <[email-masked]>

Sent: Wednesday, January 22, 2020 11:17 AM

To: Routing Over Low power and Lossy networks <[email-masked]>

Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt

Dear all

All the best

Pascal

-----Original Message-----

Cc: [email-masked]

        Authors         : Pascal Thubert

                          Li Zhao

        Pages           : 8

        Date            : 2020-01-22

Abstract:

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jan 2020 16:30:48 +0000

Hello Rahul

The idea is that the parent copies the configuration bits unchanged as part of the propagation of the DIO message.

>From RFC 6550:
"
                                   This information is configured at the DODAG root and
   distributed throughout the DODAG with the DODAG Configuration option.
   Nodes other than the DODAG root MUST NOT modify this information when
   propagating the DODAG Configuration option.

"
So the parent propagates the configuration option unchanged in its DIO with possibly the "T" flag set even if the parent cannot understand what that means.

Are we in sync or do I miss something? Should I reword?

On the side, I'll be changing the security section to use set and reset for the "T" flag as opposed to turn on per your comment earlier.Of that works for you it will be in the next publication, you may already look at it in the ROLL github repo.

 Also applied your new nit.

Many thanks again : )

Pascal

> From: Rahul Jadhav <[email-masked]>
> Sent: mercredi 22 janvier 2020 16:52
> To: Pascal Thubert (pthubert) <[email-masked]>; Routing Over Low
> power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt
> 
> [RJ] I think this is confusing. Consider that the parent does not support RFC
> 8138... according to this text a parent may propagate "T" flag = 1, but this is
> not possible.
> 
> Nit:

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 22 Jan 2020 17:13:30 +0000

I think I got the point here. But I have one question,

Assume a 6LR who does not support 8138 and does not support this draft. If this happens then that link (in which the 6LR is part) won't work for compressed source-routed traffic.
Ideally, the root will set the T flag only when it knows that all the nodes support 8138. But still, it would be better to tell the reader of this scenario and let know of the dire consequences.

[Pascal] On the side, I'll be changing the security section to use set and reset for the "T" flag as opposed to turn on per your comment earlier.Of that works for you it will be in the next publication, you may already look at it in the ROLL github repo.

[RJ] Works for me. Thanks,

Best,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jan 2020 16:42:15 +0000

Hello Rahul:

Yes, and there's more.

The first sentence of the spec is
"
   The transition to [RFC8138] in a network can only be done when all
   nodes support the specification.  In a mixed case with both
   RFC8138-capable and non-capable nodes, the compression should be
   turned off.
"
But since the draft indicates transition scenarios to push non-capable nodes to the edge as leaves, which is somehow inconsistent.
To address this and cover your point we could change to:

"

   The transition of a RPL [RFC6550] network to activate the compression

   defined in [RFC8138] can only be done when all routers in the network

   support it.  A non-capable node acting as a router would drop the

   compressed packets and black-hole its subDAG.  In a mixed case with

   both RFC8138-capable and non-capable nodes, the compression may be

   turned on only if all the non-capable nodes act as leaves and their

   RPL parents handle the compression/decompression on their behalf.
"
We'll note that the best we can do with a legacy device is turn it into a RAL whereas a newer implementation could become a RUL.
In the case of a RUL, the compressed headers are removed by the parent naturally.
For a RAL, the parent needs to know it must uncompress, and we do not have a way to signal that, so it must be configuration.
Maybe we should clarify that?

The intro then says:

"

        This document complements RFC 8138 and dedicates a bit in the RPL
   configuration option to indicate whether RFC 8138 compression should
   be used within the RPL Instance.  When the bit is not set, source
   nodes that support RFC 8138 should refrain from using the compression
   unless the information is superseded by configuration.
"
It would be worth adding text in the middle per your earlier comment as follows:
"

   This document complements RFC 8138 and dedicates a bit in the RPL
   configuration option to indicate whether RFC 8138 compression should
   be used within the RPL Instance.  The setting of new bit is
   controlled by the Root and propagates as is in the whole network.
   When the bit is not set, source nodes that support RFC 8138 should
   refrain from using the compression unless the information is
   superseded by configuration

"

Finally a node that supports this spec but not the compression can decide to become a leaf without the need of the  migration scenarios.
Ideally it would become a RUL. We could mandate that so the operation of 6LR always removes the compressed piece that is the encapsulation, but then that makes the RUL draft a normative ref. Is that OK?

From: Rahul Jadhav <[email-masked]>
Sent: mercredi 22 janvier 2020 18:14
To: Pascal Thubert (pthubert) <[email-masked]>; Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt

Best,
Rahul

> From: Rahul Jadhav <[email-masked]<mailto:[email-masked]>>
> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Routing Over Low
> power and Lossy networks <[email-masked]<mailto:[email-masked]>>
> From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert)
> <[email-masked]<mailto:[email-masked]>>
>
> To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
>
> From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
>
> To: [email-masked]<mailto:[email-masked]>
>
> Cc: [email-masked]<mailto:[email-masked]>
>
> [email-masked]<mailto:[email-masked]>
>
> [email-masked]<mailto:[email-masked]>
>