Subject: [Roll] Reclaiming the bits

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Dec 2019 13:33:30 +0000

Dear all

Going through our last meeting (https://www.youtube.com/watch?v=3UiF5FDAEjA) around 1:40, we discussed the way we can recover the configuration bits used by use-of-rpl-info and turnon-rfc8138.

The proposal on the table was:
- change turnon-rfc8138 to say that the configuration bit only applies to MOP < 7 (RPL v1)
- use-of-rpl-info is edited to say the same thing
- we create a IANA registry with a MOP column so the bits depend on the MOP. MOPext could be the place for introducing this registry.

I'd like to check if the ML is in line with this approach.

All the best

Pascal

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/logo/Cisco_Logo_no_TM_Indigo_Blue-RGB_43px.png]
Pascal Thubert
PRINCIPAL ENGINEER.ENGINEERING
[email-masked]<mailto:[email-masked]>
Tel: +33 49 723 2634
 cisco.com
Cisco Systems, Inc.
45 All Des Ormes Regus Centre
BP1200
06250 MOUGINS CEDEX
France
[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]
Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html> for Company Registration Information.

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 12 Dec 2019 09:12:39 +0800

> - we create a IANA registry with a MOP column so the bits depend on the
> MOP. MOPext could be the place for introducing this registry.
>
>
>
> I’d like to check if the ML is in line with this approach.
>

[RJ] I am inline with these points.
I would like to confirm a point here... Reclaiming the turnon-8138 flag in
MOP>=7 would mean that 8138 is _mandatorily_ supported in the nodes above
MOP>=7 such that they no more depend on this flag. This in itself is a
bigger decision! Is my understanding correct? While the advantages of 8138
are obvious in non-storing MOP case, they are less impacting/obvious in
storing MOP case.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Dec 2019 09:06:35 +0000

Hello Rahul

> [RJ] I am inline with these points. I would like to confirm a point here... Reclaiming the turnon-8138 flag in MOP>=7 would mean that 8138 is _mandatorily_ supported in the nodes above MOP>=7 such that they no more depend on this flag. This in itself is a bigger decision! Is my understanding correct? While the advantages of 8138 are obvious in non-storing MOP case, they are less impacting/obvious in storing MOP case.

We have to discuss that, let’s start a thread. Same goes for the RPI HbH-H option value. But neither turnon nor useofrplinfo should make any assumption on what happens for MOP values >= 7. It is up to the drafts specifying MOP values >= 7 to decide. IMHO MOPext would be the place to write text if we make RFC 8138 support mandatory for RPLv2.

All the best,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: jeudi 12 décembre 2019 02:13
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Reclaiming the bits

[RJ] I am inline with these points.
I would like to confirm a point here... Reclaiming the turnon-8138 flag in MOP>=7 would mean that 8138 is _mandatorily_ supported in the nodes above MOP>=7 such that they no more depend on this flag. This in itself is a bigger decision! Is my understanding correct? While the advantages of 8138 are obvious in non-storing MOP case, they are less impacting/obvious in storing MOP case.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Dec 2019 09:13:36 +0000

To clarify I suggest the following text on draft-ietf-roll-turnon-rfc8138-01:

“
   Section 6.3.1.  of [RFC6550] defines a 3-bit Mode of Operation (MOP)
   in the DIO Base Object.  The new "T" flag is defined only for MOP
   value between 0 to 6.  For a MOP value of 7 or above, the flag MAY
   indicate something different and MUST NOT be interpreted as "Enable
   RFC8138 Compression" unless the specification of the MOP indicates to
   do so.
“

All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Dec 2019 12:05:23 +0000

For Use of RPL info I propose the following addition

"

Section 6.3.1. of <xref target="RFC6550"/> defines a 3-bit Mode of
Operation (MOP) in the DIO Base Object. The flag is defined only
for MOP value between 0 to 6. For a MOP value of 7 or above, the flag
MAY indicate something different and MUST NOT be interpreted as
"RPI 0x23 enable" unless the specification of the MOP
indicates to do so.

"

I created a pull request to the authors. The pull request also proposes some clean up since the original text really abuses terms like "RPI value".
The RPI is an abstract data defined in RFC 6550. RFC 6553 defines a RPL Option. 0x63 is the value of the Option Type field of the RPL Option. I changed the draft to use "RPI" in abusive replacement of "RPL Option" so we can use " RPI Option Type" but kept the abuse at that.

https://github.com/roll-wg/useofrplinfo/pull/6

Ines: You author section does not compile well, if you could look at it as well?

All the best

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Dec 2019 16:44:09 -0500

Rahul Jadhav <[email-masked]> wrote:
    > [RJ] I am inline with these points.  I would like to confirm a point
    > here... Reclaiming the turnon-8138 flag in
    > MOP >=7 would mean that 8138 is _mandatorily_ supported in the nodes
    > above >=7 such that they no more depend on this flag. This in itself
    > is a bigger
    > decision! Is my understanding correct? While the advantages of 8138 are
    > obvious in non-storing MOP case, they are less impacting/obvious in
    > storing MOP case.

I agree that it is a bigger decision.
I also think that it's tying RPL to 802.15.4/6lo a lot too!

So, let me attempt to rephrase it.
For MOP >= 7, the bits being reclaimed, and that bit does not indicate turnon-8138.
We could have a capability that turned it on/off.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ines Robles <[email-masked]>
Date: Fri, 13 Dec 2019 13:17:32 -0300

Thank you very much Pascal for add the clarification. Version 33 was just
posted with that.

Diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-33.txt

Please comments,

Thank you,

Ines.

On Thu, Dec 12, 2019 at 9:05 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> I created a pull request to the authors. The pull request also proposes
> some clean up since the original text really abuses terms like "RPI value".
> The RPI is an abstract data defined in RFC 6550. RFC 6553 defines a RPL
> Option. 0x63 is the value of the Option Type field of the RPL Option. I
> changed the draft to use "RPI" in abusive replacement of "RPL Option" so we
> can use " RPI Option Type" but kept the abuse at that.
>