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

Hello Rahul

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

Dominique

De : Rahul Jadhav <nyrahul@outlook.com<mailto:nyrahul@outlook.com>>
Date : Thursday 25 June 2020 05:08
À : Dominique Barthel <dominique.barthel@orange.com<mailto:dominique.barthel@orange.com>>, "roll@ietf.org<mailto:roll@ietf.org>" <roll@ietf.org<mailto:roll@ietf.org>>
Objet : Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

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

Thanks,
Rahul

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?

[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.

With the current definition, it follows that "Option Type 0xC0 to 0xFF are thus applicable only as extended options." as well.

[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).

Or should X be a two bits field, where 0b00 designates the legacy Control Option and anything different from 0b00 the Extended Control Option?

[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).

I'm assuming the Extended option is better, and we don't want to save have of the space for the legacy one.

[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.

Thank you very much for pointing this out.

Thanks

Dominique

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

Hello All,

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

Best,
Rahul
________________________________
From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Sent: 05 June 2020 03:40 PM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Cc: roll@ietf.org<mailto:roll@ietf.org> <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt

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/

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
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.

_________________________________________________________________________________________________________________________

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.