Subject: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

From: [email-masked]
Date: Fri, 05 Jun 2020 00:40:21 -0700

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           : Mode of Operation extension
        Authors         : Rahul Arvind Jadhav
                          Pascal Thubert
                          Michael Richardson
	Filename        : draft-ietf-roll-mopex-01.txt
	Pages           : 8
	Date            : 2020-06-05

Abstract:
   RPL allows different mode of operations which allows nodes to have a
   consensus on the basic primitives that must be supported to join the
   network.  The MOP field in [RFC6550] is of 3 bits and is fast
   depleting.  This document extends the MOP for future use.

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

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

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

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: Rahul Jadhav <[email-masked]>
Date: Fri, 5 Jun 2020 07:44:03 +0000

Hello All,

The primary update is about the Extended Control Option format that we discussed during the interim.

Best,
Rahul
________________________________
From: Roll <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 05 June 2020 03:40 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

Abstract:

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

---

From: rabi narayan sahoo <[email-masked]>
Date: Sun, 21 Jun 2020 14:27:59 +0530

Hi Rahul

In section 4 its mentioned
"I" (Ignore) bit in Option Flags: A node which does not understand the
Option Type MUST ignore this whole message if the ’I’ bit is
set. If ’I’ bit is set* than* the value of ’J’ and ’C’ bits are irrelevant
and the *message MUST be ignored.*"

1-  I didn't get why the whole message needs to be ignored if an option is
not understood?  I think this bit MUST say if the option is optional or
mandatory. If it's mandatory then 'J' flag will control
     if the node can join as a leaf or an LR.
    Am I missing something here?

2- There is a typo error (Than)

Thanks
Rabi

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 22 Jun 2020 09:10:43 +0800

Thanks Rabi for the review.

1. The 'I' bit was introduced recently so that a node not understanding the
option ignores the whole message. This could potentially lead to a node not
joining as a 6LR or a 6LN. The J flag decides only for node joining as 6LR.
As an example, the I bit can be used by root to ensure that only the nodes
understanding a given option join (as 6LN/6LR) that instance. There are
several other possibilities even for non-root nodes.

2. Will fix the typo.

Thanks,
Rahul

On Sun, 21 Jun 2020 at 16:58, rabi narayan sahoo <[email-masked]>
wrote:

> set. If ’I’ bit is set* than* the value of ’J’ and ’C’ bits are
> irrelevant and the *message MUST be ignored.*"
>

---

From: <[email-masked]>
Date: Wed, 24 Jun 2020 17:06:28 +0000

Hello Rahul,

Food for discussion at the upcoming interim:
I'm surprised the Extended Control Option is recognized by the X bit being set, where X is bit 6 of the Option Type (or bit number 1 counting from 0 left to right in the byte).
"Option Type 0x40 to 0x7F are thus applicable only as extended options."
What is your intention regarding Option Type 0x80-0xFF?
With the current definition, it follows that "Option Type 0xC0 to 0xFF are thus applicable only as extended options." as well.
Or should X be a two bits field, where 0b00 designates the legacy Control Option and anything different from 0b00 the Extended Control Option?
I'm assuming the Extended option is better, and we don't want to save have of the space for the legacy one.
Thanks

Dominique

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of Rahul Jadhav <[email-masked]<mailto:[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Friday 5 June 2020 09:44
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

Hello All,

Best,
Rahul
________________________________
From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 05 June 2020 03:40 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

Abstract:

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 25 Jun 2020 03:08:12 +0000

Thanks Dominique for the review. Your points about extended options are right. Please find my comments [RJ] inline.

Thanks,
Rahul

Hello Rahul,

[RJ] I was under the confusion that the MSB bit of option type means "secure" bit and thus I option Types 0x80-0xff were considered to be secure options. But my understanding is wrong. Only the RPL control codes have this MSB set to indicate secure message so indeed we are free to use MSB of the Control Option type.
But yes my assumption was we reserve set of option type as extended option types and currently the draft reserves range 0x40-0x7f for this.

[RJ] Like I mentioned that the MSB was assumed to be the secure bit (this assumption is clearly wrong). Thus 0xC0 to 0xFF was assumed to be extended options with secure message. But just ignore this part since it does not make sense anymore (because of incorrect assumption of secure bit).

[RJ] I didn't get this. 0b00 represent two bytes however Control Option Type field is of 1 byte.

[RJ] It is better to have legacy option as well since it saves 1 byte per option. Ext options can be used only when the RPL extension intends to use the 'J/I/C' flags. The draft has also mandates what an implementation should do on witnessing an unknown regular control option (not ext opt).
Overall, I will change the draft to use MSB as ext bit and thus reserve, 0x80 to 0xff for extended options.
Thank you very much for pointing this out.

Thanks

Dominique

Hello All,

Best,
Rahul

Abstract:

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 25 Jun 2020 03:53:51 +0000

Hi Dominique,

I have added PR [1] and will upload the draft after the interim once we are aligned.
Diff can be viewed here: https://github.com/nyrahul/mopex/blob/master/diff-draft-ietf-roll-mopex.html

Also many thanks for the nit-fixes PR.

Thanks,
Rahul

[1]https://github.com/roll-wg/mopex/pull/7
[https://avatars3.githubusercontent.com/u/41386261?s=400&v=4]<https://github.com/roll-wg/mopex/pull/7>
RPL Extended Control Option Fixes by nyrahul · Pull Request #7 · roll-wg/mopex<https://github.com/roll-wg/mopex/pull/7>
updates based on Dominique review IANA consideration added @dbarthel-ol Thanks.
github.com

________________________________
From: Roll <[email-masked]> on behalf of Rahul Jadhav <[email-masked]>
Sent: 25 June 2020 11:08 AM
To: [email-masked] <[email-masked]>; Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

Thanks,
Rahul

Hello Rahul,

Thanks

Dominique

Hello All,

Best,
Rahul

Abstract:

---

From: <[email-masked]>
Date: Thu, 25 Jun 2020 05:20:01 +0000

Hello Rahul

Some further comment inline, noted with [DB]
Best regards,

Dominique

De : Rahul Jadhav <[email-masked]<mailto:[email-masked]>>
Date : Thursday 25 June 2020 05:08
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

Thanks,
Rahul

Hello Rahul,

[RJ] I didn't get this. 0b00 represent two bytes however Control Option Type field is of 1 byte.
[DB] I really meant two bits, not bytes. Out of all combinations of the top two bits, we could keep the binary value 0 ( which I noted as 0b00)  for legacy Options (that’s 64 options), and use any other value (1, 2 or 3) for the new Options (that's 192 Options).

[RJ] It is better to have legacy option as well since it saves 1 byte per option. Ext options can be used only when the RPL extension intends to use the 'J/I/C' flags. The draft has also mandates what an implementation should do on witnessing an unknown regular control option (not ext opt).
[DB] Got it. I was assuming no one would want to create new legacy Options any more, but I get your point.

Overall, I will change the draft to use MSB as ext bit and thus reserve, 0x80 to 0xff for extended options.
[DB] this choice reserves space for 128 legacy Options and 128 extended Options. Fine by me. No strong opinion on the 128/128 vs. 64/192 split.

Thanks

Dominique

Hello All,

Best,
Rahul

Abstract:

---

From: rabi narayan sahoo <[email-masked]>
Date: Fri, 26 Jun 2020 16:39:25 +0530

Hi Rahul
Find my comments inline.

On Mon, Jun 22, 2020 at 6:41 AM Rahul Jadhav <[email-masked]> wrote:

> 1. The 'I' bit was introduced recently so that a node not understanding
> the option ignores the whole message. This could potentially lead to a node
> not joining as a 6LR or a 6LN. The J flag decides only for node joining as
> 6LR. As an example, the I bit can be used by root to ensure that only the
> nodes understanding a given option join (as 6LN/6LR) that instance. There
> are several other possibilities even for non-root nodes.
>
>    [Rabi]-: I got this point. I feel this is very very specific to DIO.
Even the J bit.
                This will be the new Control Option format that is going to
be used in RPLv2 . This will be used to define new options meant for DIS,
DIO, DAO, DAO-ACK, DCO or other new messages to be  added in future.
                I have one suggestion: can we let such flag bits be part of
the option data itself?
                We have one flag bit to indicate if this option is
mandatory or optional. Maybe the 'J' flag can make M to serve the purpose.
If an option is mandatory to be understood then let the particular option
                take a decision about what action to be taken. If the
option is part of DIO it can define join as leaf or don't join. What do you
think?
2. Will fix the typo.

>
> Thanks,
> Rahul
>
>
>
> On Sun, 21 Jun 2020 at 16:58, rabi narayan sahoo <
> [email-masked]> wrote:
>
>> Hi Rahul
>>
>> 1-  I didn't get why the whole message needs to be ignored if an option
>> is not understood?  I think this bit MUST say if the option is optional or

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 26 Jun 2020 12:37:17 +0000

Hi Rabi,

Please find my resp inline.
I/J/C flags are not only for DIO but can be used for any RPL message/control options. I am not sure why you say that the flags are DIO specific?

Best,
Rahul

________________________________
From: Roll <[email-masked]> on behalf of rabi narayan sahoo <[email-masked]>
Sent: 26 June 2020 07:09 PM
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

Hi Rahul
Find my comments inline.

On Mon, Jun 22, 2020 at 6:41 AM Rahul Jadhav <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Rabi for the review.

1. The 'I' bit was introduced recently so that a node not understanding the option ignores the whole message. This could potentially lead to a node not joining as a 6LR or a 6LN.. The J flag decides only for node joining as 6LR. As an example, the I bit can be used by root to ensure that only the nodes understanding a given option join (as 6LN/6LR) that instance. There are several other possibilities even for non-root nodes.

   [Rabi]-: I got this point. I feel this is very very specific to DIO. Even the J bit.

[RJ] Why do you think this is very specific to DIO? Any RPL message can be ignored/dropped for the said reason, not only DIO.

                This will be the new Control Option format that is going to be used in RPLv2 . This will be used to define new options meant for DIS, DIO, DAO, DAO-ACK, DCO or other new messages to be  added in future.
                I have one suggestion: can we let such flag bits be part of the option data itself?

[RJ] In a way it is already part of option data. If you see the flags have carved out a space from option data. Option length includes option data (which includes these flags too).

                We have one flag bit to indicate if this option is mandatory or optional. Maybe the 'J' flag can make M to serve the purpose. If an option is mandatory to be understood then let the particular option
                take a decision about what action to be taken. If the option is part of DIO it can define join as leaf or don't join. What do you think?
2. Will fix the typo.

Thanks,
Rahul

On Sun, 21 Jun 2020 at 16:58, rabi narayan sahoo <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rahul

In section 4 its mentioned
"I" (Ignore) bit in Option Flags: A node which does not understand the Option Type MUST ignore this whole message if the ’I’ bit is
set. If ’I’ bit is set than the value of ’J’ and ’C’ bits are irrelevant and the message MUST be ignored."

1-  I didn't get why the whole message needs to be ignored if an option is not understood?  I think this bit MUST say if the option is optional or mandatory. If it's mandatory then 'J' flag will control
     if the node can join as a leaf or an LR.
    Am I missing something here?

Thanks
Rabi

On Fri, Jun 5, 2020 at 1:11 PM <[email-masked]<mailto:[email-masked]>> wrote:

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<http://tools.ietf.org>.