Subject: [Roll] RPI Option Type in useofrplinfo

From: Rahul Jadhav <[email-masked]>
Date: Thu, 12 Mar 2020 09:04:20 +0000

While reading section related to RPI Option Type, I had some doubts:

Section 4.3 states,
"In the case of rebooting, the node (6LN or 6LR) does not remember the
RPL Option Type (i.e., whether or not the flag is set), so DIO
messages sent by the node would be sent with the flag unset until a
DIO message is received with the flag set, indicating the new RPI
value. The node will use the value 0x23 if it supports this feature."

[RJ] A node can initiate a DIO only when it decides to attach itself to the Instance/DAG based on DIO received from the upstream node. Thus a 6LR/6LN __will always have a ref value to use from its parent's DIO__. The para states, ".... so DIO messages sent by the node would be sent with the flag unset until a DIO message is received with the flag set.....". This may be incorrect because the node will always have a flag ref from config option from DIO rcvd from upstream node.
Subsequently, in the same para, the text says, "The node will use the value 0x23 if it supports this feature." Do you mean even if the flag in Config option is not set it can use 0x23 if it supports the feature? This doesn't seem right! Contradicts with other stmts in the same section for e.g., "Thus, when a node join to a network will know which value to use."
>From my point of view, this para is not needed since there is no impact on 6LR/6LN for this flag because of the reboot operation.

Regarding the terminology: The draft terms, the new option type as "RPI Option Type" (value 0x23) and the old "RPL Option Type" (value 0x63). Is this correct?

Thanks,
Rahul

---

From: Ines Robles <[email-masked]>
Date: Thu, 12 Mar 2020 13:33:21 +0200

Thank you very much Rahul for your review, please find in-line some
comments.

On Thu, Mar 12, 2020 at 11:04 AM Rahul Jadhav <[email-masked]> wrote:

> [RJ] A node can initiate a DIO only when it decides to attach itself to
> the Instance/DAG based on DIO received from the upstream node. Thus a
> 6LR/6LN __will always have a ref value to use from its parent's DIO__. The
> para states, ".... so DIO messages sent by the node would be sent with the
> flag unset until a DIO message is received with the flag set.....". This
> may be incorrect because the node will always have a flag ref from config
> option from DIO rcvd from upstream node.
>

[IR] Thank you for pointing it out. Thus, in case of rebooting the node
waits to receive a DIO (or it may send a DIS msge?), and when it receives a
DIO, then it can trigger one.

> Subsequently, in the same para, the text says, "The node will use the
> value 0x23 if it supports this feature." Do you mean even if the flag in
> Config option is not set it can use 0x23 if it supports the feature?
>

[IR] No, the flag in Config option indicates when then 0x23 RPI option Type
can be safely used. This means, the flag is going to indicate the value of
Option Type that the network is using for the RPI Option

The correct? sentence could be: "The node will use the value 0x23 if the
network supports this feature (DODAG Configuration option flag set)" .

> This doesn't seem right! Contradicts with other stmts in the same section
> for e.g., "Thus, when a node join to a network will know which value to
> use."
>
[IR] yes, which know the value based on the flag in the config option.

> From my point of view, this para is not needed since there is no impact on
> 6LR/6LN for this flag because of the reboot operation.
>

[IR] Thank you, we could delete the para if people/other coauthors agree.
But in case that we want to specify the case on rebooting, would it the
following make sense?

"In the case of rebooting, the node (6LN or 6LR) does not remember the
RPI Option Type (i.e., whether or not the flag is set), so the node will
not trigger DIO
messages until a DIO message is received indicating the RPI
value to be used. The node will use the value 0x23 if the network supports
this feature."

Regarding the terminology: The draft terms, the new option type as "RPI
> Option Type" (value 0x23) and the old "RPL Option Type" (value 0x63). Is
> this correct?
>

[IR] we define RPI here as follows:

RPL Packet Information (RPI): The abstract information that [RFC6550
<https://tools.ietf.org/html/rfc6550>]
   places in IP packets.  The term is commonly used, including in this
   document, to refer to the RPL Option [RFC6553
<https://tools.ietf.org/html/rfc6553>] that transports that

   abstract information in an IPv6 Hob-by-Hop Header

Yes, with RPI Option Type we refer to the RPL Option described in 6553

Thank you very much Rahul for constantly helping us to improve our work :)

Best,

Ines.

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

---

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

Thanks Ines. The updated text is more clear and in sync with other text in the section. Please find my resp inline.

Best,
Rahul

[IR] Thank you, we could delete the para if people/other coauthors agree. But in case that we want to specify the case on rebooting, would it the following make sense?

"In the case of rebooting, the node (6LN or 6LR) does not remember the
RPI Option Type (i.e., whether or not the flag is set), so the node will not trigger DIO
messages until a DIO message is received indicating the RPI
value to be used. The node will use the value 0x23 if the network supports this feature."

[RJ] Yes this para is more clear for me. Thanks.

RPL Packet Information (RPI): The abstract information that [RFC6550<https://tools.ietf.org/html/rfc6550>]
   places in IP packets.  The term is commonly used, including in this
   document, to refer to the RPL Option [RFC6553<https://tools.ietf.org/html/rfc6553>] that transports that

[RJ] Great! Please also check the PR I raised on GitHub and use the changes if it makes sense.

---

From: Ines Robles <[email-masked]>
Date: Thu, 12 Mar 2020 15:13:55 +0200

Thank you very much Rahul! We'll fix it and post new version

Best,

Ines.

On Thu, Mar 12, 2020 at 3:08 PM Rahul Jadhav <[email-masked]> wrote:

> RPL Packet Information (RPI): The abstract information that [RFC6550 <https://tools.ietf.org/html/rfc6550>]
>    document, to refer to the RPL Option [RFC6553 <https://tools.ietf.org/html/rfc6553>] that transports that
>