Subject: [Roll] RPLinfo review

From: peter van der Stok <[email-masked]>
Date: Fri, 13 May 2016 11:14:51 +0200

Dear authors,

Thanks for your document. In my opinion the document is very useful. 
Although many things are well explained, I am still left with questions 
and possible ambiguities in my understanding. Consequently, my review 
goes up to section 5.8. Continuing the review becomes more effective 
when my current questions are answered.
Line numbers are with respect to page or to section header; hope this is 
clear.
Below my review:
____________________________________________________________________________
Page 3, section1, line1: the first use of RPL please write in full.
Section 2: please provide the reader with a list of terms from RFC7102 
that is used in the document.
Page 4: ICMPv6 may need a reference?
DIS, DIO, and DAO are not provided by RFC7102. Please write in full or 
provide reference in section 2.
Page 5 I like figure 2, and use it as a reference throughout the 
document.
Page 5, line 2: I assume that 6LN is not RPI aware.
Page 5: The phrase:  “Advertisement, 6lowPAN  … network” may need 
reference to RFC.
Page 5 2nd al. write 6tisch in full?
Page 5, 3rd al; write LLN in full (first occurrence)
Page 6, Figure 3 and architecture text is informative, but please 
clarify how the use cases of section 4 map to figure 3. For example 
where does Internet start/end: at border router or at backbone router?
And how does flow from one mesh over the backbone to the next mesh map 
to the use cases.
I also did not see a mapping of flow from one RPL instance to another 
instance.
Page 8, line 3: route -> root.
Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and 
RPL-NSM, otherwise explain the meaning of the N.
Page 8, Please align terminology of table 1 with terminology of Figure 2
I would suggest to move table 1 and its concluding text to a last 
summary section of section 5. At the beginning of section 5, the import 
of the text is far from clear.
I would recommend to write down at the beginning of section 5 the 
characteristics of storing mode for this document; e.g. root and 6lr do 
not know if a destination is part of RPL DODAG; and thus needs IP over 
IP header in all cases.
Page 9 , section 5.1 line 1: states -> stated
Page 9, line 7: is suitable -> is compulsory; or use SHOULD in different 
kind of phrase
“in storing mode …….information”. suggestion to move section to start of 
section 5
Page9, Line 10: RPL-aware-leaf (6LN) in figure 2 it is called 6LR, I 
recommend to use 6LR throughout. According to figure 2, 6LN stands for 
something else. This is relevant for whole section 5.
“Note:….root node”. Remove this phrase is already done in section 3.
Page9 line13: send -> sends
Line14: decrement -> decrements; send -> sends
Line 15 arrives to 6LBR -> arrives at 6LBR
Line 20: “The RPI header …DIO messages” -> The 6LR recognizes the 
address of the 6LBR (root?) from earlier received DIO messages, and can 
thus insert RPI directly in the header. The 6LBR receives the packet and 
accepts the payload.
NB: In the whole document root and 6LBR is freely exchanged. May be good 
to say something about this in section 3.
Section 5.2
Everywhere: 6LN -> 6LR
Page10, line 1: insert -> inserts; send -> sends
This is weird. According to the intro, 6LBR does not know if destination 
is a 6LR or a 6LN. In my opinion treatment, described in 5.2 and 5.3, by 
6LBR and 6LR should be identical.
Section 5.3
Put the alinea “ The question…. To leaf” up front of section 5.3.
Section 5.3, Line 3: It includes -> The root (6LBR) uses
Section 5.3 line 6: “the header ….node” -> the header before it passes 
the packet to 6LN.
IPv6 is a new term not introduced earlier.
Section 5.4
I assume IPv6 node is 6LN.
How can the RPI header be encapsulated in the IP-IP header. I thought 
the encapsulating IPIP header contains RPI.
Section 5.4, line 6: process -> processes.
Section 5.5 6LN -> 6LR in whole section
It would help the reader to explain that 6LR knows the destination is 
Internet because the prefixes differ.
Why should it be done hop by hop? Interoperability requires that it is 
done in one way. So one IPIP encapsulation with RPI, with encapsulation 
removed by 6LBR.
Section 5.6
6LN ->6LR for whole section
Section 5.6, line 4: send -> sent
Section 5.6, line 5: When the packet arrives at 6LR, the …
Why is this not done in a hop by hop fashion as in section 5.2 modelled 
on section 5.3, because also here the root does not know whether the 
destination is 6LR or 6LN node.
Page 13, line 1 Why two fashions: direct root, and hop by hop to root.
Section 5.8
Can refer to section 5.3 directly, and remove text.
-----------------------------------------------------------------------------------------------------------------------------------------
I stop here because I made too many assumptions about the text, and the 
validity of the rest of the review becomes more and more questionable.
I hope this helps; and my misinterpretations may lead to better text.
Greetings,
peter

---

From: Ines Robles <[email-masked]>
Date: Tue, 24 May 2016 11:50:40 +0300

Hi Peter,

Thanks for your comments, please find comments below.

2016-05-13 12:14 GMT+03:00 peter van der Stok <[email-masked]>:

> Although many things are well explained, I am still left with questions and
> possible ambiguities in my understanding. Consequently, my review goes up
> to section 5.8. Continuing the review becomes more effective when my
> current questions are answered.
Section 2: please provide the reader with a list of terms from RFC7102 that
> is used in the document.
> Page 5 I like figure 2, and use it as a reference throughout the document.
>
OK, we are addressing all of above editorial issues

Yes

> Page 6, Figure 3 and architecture text is informative, but please clarify
> how the use cases of section 4 map to figure 3. For example where does
> Internet start/end: at border router or at backbone router? And how does
> flow from one mesh over the backbone to the next mesh map to the use cases.
>

Ok, we will clarify the figure.

> instance.

I do not understand this. Could you please clarify?

> Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and RPL-NSM,
> otherwise explain the meaning of the N.
> I would suggest to move table 1 and its concluding text to a last summary
> section of section 5. At the beginning of section 5, the import of the text
> is far from clear.
> characteristics of storing mode for this document; e.g. root and 6lr do not
> know if a destination is part of RPL DODAG; and thus needs IP over IP
> header in all cases.
> Line 20: “The RPI header …DIO messages” -> The 6LR recognizes the address
> of the 6LBR (root?) from earlier received DIO messages, and can thus insert
> RPI directly in the header. The 6LBR receives the packet and accepts the
> payload.
>

Ok, thanks for the suggestions.

> to say something about this in section 3.

We use 6LN as leaf, and not as router, we are going to clarify this.

> Section 5.3 line 6: “the header ….node” -> the header before it passes the
> packet to 6LN.
> How can the RPI header be encapsulated in the IP-IP header. I thought the
> encapsulating IPIP header contains RPI.
>

We are going to clarify the text with your suggestions.

> done in one way. So one IPIP encapsulation with RPI, with encapsulation

The simplest fully general situation for storing mode is to always put in
hop-by-hop IPIP headers.

> Why is this not done in a hop by hop fashion as in section 5.2 modelled on
> section 5.3, because also here the root does not know whether the

Yes, it is hop-by-hop, we will clarify the text.

> Page 13, line 1 Why two fashions: direct root, and hop by hop to root.

For direct root, the 6LR can know the address of the root because it knows
the address of the root via the DODAGID in the DIO messages, and In all
cases hop by hop can be used

> Can refer to section 5.3 directly, and remove text.

I would prefer leave the text for a better understanding.

Many thanks again to help to clarify the draft. :-)

Cheers,

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 May 2016 11:17:17 +0200

> 
>> I also did not see a mapping of flow from one RPL instance to
>> another instance.
> 

A node belonging to one RPL instance sends a message to a node belonging 
to another RPL instance.
This seems possible in Figure 3, with 3 RPL instances?

If possible, it means an additional use case.

Peter

---

From: Ines Robles <[email-masked]>
Date: Tue, 24 May 2016 13:16:06 +0300

Hi,

Thanks for the clarification.

We are just considering here one RPLInstance.

Working with different RPLInstances, involves deeply analysis, which we
could do in the future. But, actually I dont know if it is possible/useful
to send a message from one RPL Instance to another one , since for
example a RPL
node may belong to multiple RPL Instances, and it may act as a router in
some and as a leaf in others[1], for this reason it does not make sense to
me sending packet from one RPLInstance to other RPLInstance. Besides the
control messages has one field for RPLInstanceID, it does not have
RPLInstanceID origen or RPLInstanceID dst.

What do you think?

Thank you,

Ines

[1] RFC6550. Section 5. RFC 6550 describes only how a single instance
behaves

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 May 2016 12:22:53 +0200

Hi,

that means writing "one RPL instance" in figure 3 in stead of "RPL 
instance" to remove that ambiguity.
Writing in the use case section a phrase as the one below will be more 
than sufficient for me.

peter

Ines  Robles schreef op 2016-05-24 12:16:
> Working with different RPLInstances, involves deeply analysis, which
> we could do in the future. But, actually I dont know if it is
> possible/useful to send a message from one RPL Instance to another one
> , since for example a RPL node may belong to multiple RPL Instances,
> and it may act as a router in some and as a leaf in others[1], for
> this reason it does not make sense to me sending packet from one
> RPLInstance to other RPLInstance. Besides the control messages has one
> field for RPLInstanceID, it does not have RPLInstanceID origen or
> RPLInstanceID dst.
> 
> What do you think?
> 
> Thank you,
> 
> Ines
> 
>  A node belonging to one RPL instance sends a message to a node
> belonging to another RPL instance.

---

From: Ines Robles <[email-masked]>
Date: Tue, 24 May 2016 13:26:50 +0300

Ah, got it, thank you very much.

Ines

---

From: Ines Robles <[email-masked]>
Date: Tue, 24 May 2016 13:42:57 +0300

btw, I just found a proposed approach for interaction between RPL Instances

Barcelo, Marc, Alejandro Correa, Jose Lopez Vicario, and Antoni Morell.
"Cooperative interaction among multiple RPL instances in wireless sensor
networks." *Computer Communications* (2015).

Cheers,

Ines.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 May 2016 22:52:41 -0400

> could do in the future. But, actually I dont know if it is

In general, you have to leave one instance (popping all artifacts as if going
out to the Internet), and then enter the new instance.

It matters not if these are two RPLinstances (by instanceID), or two
different LLNs seperated by the Internet.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-