Re: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Rahul

Many thanks for your review!

Li created a new repo within the ROLL github, you'll find it under https://github.com/roll-wg
Please see below:


Overall the document is very much to the point and I do not have any major comments.
Following are my comments for the draft(-02):

1. Section 5
"It results whether a parent supports RFC 8138 is not known by the child with the current level of specifications, and a child cannot favor a parent based on a particular support."
I think the purpose of this sentence is to let know that one cannot use T flag as a way to know that the parent supports 8138 or not. But I am not sure of this. Do you think this can be rephrased?

<Pascal>
You're correct. What about replacing with:
"
A parent propagates the "T" flag as set whether it supports
RFC 8138 or not. The setting of the "T" flag can thus not be
used as an indication of the support by the sender, and a child
cannot favor a parent based on it.

"
</Pascal>

2. A 6LR may be 8138 + this draft compliant and may want to initiate "a local instance" in which case the 'T' flag needs to be set/unset. I believe the 6LR could use the knowledge of Global Instance to handle this. But again, may be there is no relation here, and it is completely the choice of the Instance root (in this case the given 6LR) to decide this. I just wanted to say it loud, to check if there is anything missing!

<Pascal>
Great question, and yes. Each root is responsible to set the "T" flag based on its own knowledge and needs, true for local and global RPL Instances.

If the OF support mandates RFC 8138 then that will work. If the 6LR/root knows that all participants support RFC 8138 that will work as well. Once we have the capability draft and the 6LR/root found that all the members of the DODAG have the capability, that will work.
What if the 6LR knows none of that? This question affects in particular the DAO projection work. A projected path may cross over multiple DODAGS so it cannot inherit from one.

Also I gave a new look at the transition scenarios. We say that a node that does not support RFC 8138 can act as a leaf if the 6LR un-compresses the packets before delivery. Same question, how does it know? As it goes, useofrplinfo says that external targets are not expected to support RFC 8138 since it is a RPL thing. So acting as a RUL, we know things work.

Till the capability work comes in we need a separate source of knowledge (config, management) for a 6LR to know if 1) it can form a local instance with the "T" flag set and 2) to deliver packets to a RAL in compressed form.

I suggest to mod the section on leaf as follows:
"
    A node that does not support <xref target='RFC8138'/> can interoperate with a
    node that supports this specification in a network with RFC 8138 compression
    turned off. But it cannot forward compressed packets and therefore it cannot
    act as a router in a network with RFC 8138 compression turned on. It may
    remain connected to that network as a leaf and generate uncompressed packets.
    The leaf can receive packets if they are delivered by the parent 6LR in the
    uncompressed form. This requires a knowledge by the 6LR that the leaf does
    not support RFC 8138.
    A RPL-Unaware-Leaf (RUL) <xref target='I-D.ietf-roll-useofrplinfo'/>
      is an external target and by default is not expected to support RFC 8138. "

</Pascal>

3. Section 5
"But the node is also free to refrain from joining an Instance when a parameter is not suitable."
Refrain from joining an instance is not the same as "join as a leaf". A node that joins as a leaf, still is joining the instance. A node may join as a leaf when a parameter is not suitable. (It is possible that I have completely misunderstood the statement here).

<Pascal>
Yes that sentence is not that useful. It says that the node may decide not to join at all. Which is true but not a scientific breakthrough.
I'd rather indicate the following
"
   [ietf-roll-useofrplinfo] indicates that the node may also
   join as a RUL, in which case it refrains from participating to RPL and depends on the
   6LR to ensure connectivity regardless on the way the RPL network is operated.

"
</Pascal>

4. Section 5.3
"instances operate as ships-in-the-night"
ships-in-the-night? I didn't find any explanation in the given ref. After searching online, I think I understand :-), better to put in simple terms.
<Pascal>
What about
"
The two RPL Instances operate independently as specified
   in <xref target='RFC6550'/>.
"
</Pascal>


Nits:
1. "network is rebooted with implicitely"
implicitely -> implicitly

ok

2. "in an homogeneous network" -> "in a homogeneous ..."

Ok

3. "but MAY still joins as a leaf" -> "but MAY still join as a leaf"
Ok


4. ". when it finally" -> ". When it finally" .... Better would be to rephrase
... "The root migrates to new OCP when it finally sets the "T" flag."

<Pascal>
I'd wish to indicate clearly that they go together. What about:
"
The root sets the "T" flag at the time it migrates to the new OCP.
"
</Pascal>

5. "distribute the uncompresses"
uncompresses -> uncompressed

ok

6. Instance 'I' is used capital in some cases, 'i' in other cases for exact similar context.

<Pascal>
Should use "RPL Instance" every time as RFC 6550 does.
</Pascal>


7. The term "turn on" is used in a few places... For e.g., in security considerations, "Turning the "T" flag on before...." ... Can we use ON in caps here to specify the meaning appropriately?
<Pascal>
Unsure. Do we need to define "turning on"?
</Pascal>


Thanks,
Rahul


________________________________
From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of Ines Robles <mariainesrobles=[e-mail]<mailto:mariainesrobles=[e-mail]>>
Sent: Friday, January 17, 2020 10:39 AM
To: roll <[e-mail]<mailto:[e-mail]>>
Subject: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02

Dear all,

We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02<https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/> , we understand that it is ready for Last Call.

Thank you in advance,

Ines and Dominique