Subject: [Roll] useofrplinfo version 5

From: peter van der Stok <[email-masked]>
Date: Wed, 06 Jul 2016 14:14:23 +0200

Hi Authors,

Below my review of the document.

Although the subject is tedious, the draft looks important to me to 
assure inter-operability between implementations

This version was much more readable than the first one. So, I mostly 
signal nits and typos.
It is important that someone with more implementation experience also 
carefully reviews the document to signal missing text.

Below my comments,

Peter

______________________________________________________________________________________

Review of RPLinfo version 05.
Intro, last line, change to: “… type 3 {RFC6554], an efficient IP-in-IP 
technique, and use cases …”.
Section 3, Figure 1 is not referred to in the text.
Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed 
by the phrase “The numbers …”
Page 5, line 3: leaf -> leafs
Page 5, line 7: “is mentioned as well as” -> “is often named”
Page 6, figure 3 is not referred to.
Page 7, phrase 2, “This is a fundamental” -> “A fundamental”
Page 8, line 8,”to add to remove” -> “to add or remove”
Page 8, line 22, “In tables” -> “In table 1”
Page 8, line 25, complete -> extensive
Section 5, phrase 1 change to: “In storing mode (fully stateful), the 
sender cannot determine whether the destination is RPL-capable and thus 
….”
Section 5, line 9, indicates when (when to be added)
Page 9, last line; don’t understand: “and are the RPL root node.”
Page 10, line 6: remove: “in order to be able to”
Section 5.2, line 3, insert -> inserts; send ->sends
Section 5.3 and section 5.2: If the 6LBR does not know whether 
destination is Raf or not_Raf in section 5.3, then this is also the case 
in section 5.2. Question why is the IPv6-in-IPv6 header not also used in 
section 5.2. The problem for the 6LBR is the same.
The text in section 5.3 seems to suggest that at each 6LR the 
IPv6-in-IPv6 is removed and then re-added again. I would expect the row 
re-added headers be filled in under 6LR.
Other question: how does the last 6LR know that the next node is a 
not_Raf?
Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers 
to the following sections 5.x
Section 5.8 and section 5.6; same question as for section 5.3 and 
section 5.2.
Section 5.9, line 11, sending 6LN to (“6LN to” added)
Section 5.10, line 4, remove “sends”
Page 16, “Alternatively, …. Compress.” I miss a lot of context to 
understand this paragraph.
Section 5.11, line 5, addresses -> addressed
Section 5.11, line 6, subject of “must send” misses.
Section 5.12, The phrase “The IP-in-IP header must be addressed on a 
hop-by-hop basis” suggests that the header is removed and re-inserted at 
every hop. Nevertheless, that is not mentioned in the accompanying 
table. This is the same question I have for earlier sections 5.x.
Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the 
destination!
Section 6.2, “the traffic originates with an RPL aware node”. What do 
you mean? 6LBR is RPL aware? The destination is known to 6LBR because 
destination is RPL aware? Or something else?
Section 6.3, My interpretation: In 6LBR the RH3 is added and modified in 
each consecutive 6LR until it is fully consumed and removed in the last 
6LR.
Section 6.3, You cite several alternatives. I suggest to only mention 
the solution without RPI.
Section 6.5, line 3, remoted -> removed
Identical to storing mode case (please mention section).
Section 6.6 same remark about RPI as section 6.3
Sections 6.7 – 6.12, Here you use 6LN for not-RPL aware node, while in 
earlier section 6.x you use IPv6 node. Why?
Section 7.1, line 6, stiaution -> approach
Section 7.1, line 10; what is a “single code path”?
Section 7.2, line 1, This -> In
Section 7.2 line 3, all DODAG nodes, (added DODAG)
Section 7.2, line 12, “intermediate 6LN nodes” should be “intermediate 
IPv6 nodes”? If not, I don’t understand the phrase.
Section 7.2, line 20, there are -> there is

-- 
Peter van der Stok
mailto: [email-masked]

---

From: Cenk Gündogan <[email-masked]>
Date: Wed, 6 Jul 2016 17:14:41 +0200

Hey *,

---
5.3) The question in this scenario is how the root knows how to address
    the IPv6-in-IPv6 header.  It can not know that the destination isn't
    RPL aware, so it must insert an IPv6 header that can be removed on
    the last RPL aware node.  Since the root can not know in a storing
    network where the last RPL aware node is, the IPv6-in-IPv6 header
    must be added hop-by-hop along the path from root to leaf.
---

in section 5.3 it is said that the sender does not know whether the
destinationaddress is rpl-aware or not.
This might be true for P2P traffic, but for root->leaf traffic,
I would expect that the root knows that.

There is the Transit Option for DAOs with the 'E' flag
to indicate that the target address was not learned from rpl.
I would expect that this 'E' flag is set for all Transit Options in DAOs
until it reaches the root node (recursively).
So the root node should actually be aware which
address was learned from RPL and which not.

IMO, the actual problem why we need IPIP is _not_ that the root node isn't
aware whether the destination is rpl aware or not,
but rather that the root node does not know which node the last 
rpl-aware router is,
in case the destination is ~raf.

So, I would suggest to remove the sentence
``
It can not know that the destination isn't
    RPL aware, so it must insert an IPv6 header that can be removed on
    the last RPL aware node.
``

Secondly, Figure 1 is not used like Peter pointed out.
I would suggest to remove this figure, because it is not very
related to the content of this document.

Cenk

On 07/06/2016 02:14 PM, peter van der Stok wrote:
> Intro, last line, change to: “… type 3 {RFC6554], an efficient 
> IP-in-IP technique, and use cases …”.
> sender cannot determine whether the destination is RPL-capable and 
> thus ….”
> destination is Raf or not_Raf in section 5.3, then this is also the 
> case in section 5.2. Question why is the IPv6-in-IPv6 header not also 
> used in section 5.2. The problem for the 6LBR is the same.
> IPv6-in-IPv6 is removed and then re-added again. I would expect the 
> row re-added headers be filled in under 6LR.
> Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also 
> refers to the following sections 5.x
> hop-by-hop basis” suggests that the header is removed and re-inserted 
> at every hop. Nevertheless, that is not mentioned in the accompanying 
> Section 6.3, My interpretation: In 6LBR the RH3 is added and modified 
> in each consecutive 6LR until it is fully consumed and removed in the 
> last 6LR.

---

From: Cenk Gündogan <[email-masked]>
Date: Thu, 7 Jul 2016 10:07:30 +0200

Hello Peter,

not_Raf?

I would try to answer this question in the following way:

I expect routes that were found _not_ with RPL, but e.g. configured
manually or through any other mechanism to be marked somehow differently
than routes that were accumulated with DAOs.
How to mark routes "differently" seems to be implementation specific.
(but this information would be used to fill in the `E` flag of Transit 
Options
in DAOs later).

So, if a rpl router forwards a packet downwards (storing-mode), it somehow
needs to know whether the (dst;next-hop) pair in a forwarding table
is rpl-born or not. If it is not rpl-born, then the IPIP header
containing the RPI must be removed before continuing the forwarding process,
otherwise the IPIP+RPI is re-added and targeted to the next-hop.

You probably noticed that I used many "somehows" and generalized a lot 
in the text above,
but this process looks very blurry to me.
Any RPL veterans available to make things clearer?

Cenk

---

From: peter van der Stok <[email-masked]>
Date: Thu, 07 Jul 2016 13:18:32 +0200

HI Cenk,

> address was learned from RPL and which not.

It is probably worthwhile to describe (remind) in the draft this 
procedure for the root to learn RPL associated addresses.

Peter

---

From: peter van der Stok <[email-masked]>
Date: Thu, 07 Jul 2016 13:20:13 +0200

Hi Cenk

> Any RPL veterans available to make things clearer?
So, this certainly warrant extra text in the draft.

Peter

---

From: Ines Robles <[email-masked]>
Date: Wed, 13 Jul 2016 12:34:13 +0300

Thank you very much Peter for your comments,

We are going to address the nits/typos in the next version

About your questions.

P: Section 5.3 and section 5.2: If the 6LBR does not know whether
destination is Raf or not_Raf in section 5.3, then this is also the case in
section 5.2. Question why is the IPv6-in-IPv6 header not also used in
section 5.2. The problem for the 6LBR is the same.

-Thanks for the correction. Here, the text should say: "6LBR knows that the
destination is not_Raf". We have to describe how 6LBR does know it. We need
help in here.

The 6LBR knows when a node is raf, since the downward route is built with
DAOs.

What do you think?

-Other question: how does the last 6LR know that the next node is a not_Raf?

thank you very much to Cenk for answering this. as he said, it would be
good to have more comments on that.

Cheers,

Ines.

2016-07-06 15:14 GMT+03:00 peter van der Stok <[email-masked]>:

> Although the subject is tedious, the draft looks important to me to assure
> inter-operability between implementations
>
> Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed by
> the phrase “The numbers …”
> sender cannot determine whether the destination is RPL-capable and thus ….”
> Section 5.3 and section 5.2: If the 6LBR does not know whether destination
> is Raf or not_Raf in section 5.3, then this is also the case in section
> 5.2. Question why is the IPv6-in-IPv6 header not also used in section 5.2.
> The problem for the 6LBR is the same.
> The text in section 5.3 seems to suggest that at each 6LR the IPv6-in-IPv6
> is removed and then re-added again. I would expect the row re-added headers
> be filled in under 6LR.
> Other question: how does the last 6LR know that the next node is a not_Raf?
> Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers to
> the following sections 5.x
> Section 5.8 and section 5.6; same question as for section 5.3 and section
> 5.2.
> every hop. Nevertheless, that is not mentioned in the accompanying table.
> This is the same question I have for earlier sections 5.x.
> Section 6.2, “the traffic originates with an RPL aware node”. What do you
> mean? 6LBR is RPL aware? The destination is known to 6LBR because
> each consecutive 6LR until it is fully consumed and removed in the last 6LR.
> Section 6.3, You cite several alternatives. I suggest to only mention the
> solution without RPI.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Ines Robles <[email-masked]>
Date: Wed, 13 Jul 2016 12:38:49 +0300

Hi Cenk,

Thank you very much for your suggestions. :-)

2016-07-06 18:14 GMT+03:00 Cenk Gündogan <[email-masked]>:

> ....

Ok, we need to rephrase that section.

> related to the content of this document.

I think you mean here Figure 3, and Ok, I think we could keep only the
figure that describes the uses cases.

Cheers,

Ines.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 09:54:52 -0400

In trying to update useofrplinfo and to answer Cenk, I find myself
trying to explain inserting per-hop IPIP headers.  I am dissatisfied with
this text, and I see a clearer explanation:

             <section title="hop-by-hop IPv6-in-IPv6 headers">
                <t>
                The term "hop-by-hop IPv6-in-IPv6" header refers
                to: adding a header
                that originates from a node to an adjacent node,
                using the addresses (usually the GUA or ULA, but could use
                the link-local addresses)
                of each node.  If the packet must traverse multiple
                hops, then it must be decapsulated at each hop, and then
                re-encapsulated again in a similar fashion.

Can anyone write this clearer?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 10:28:36 -0400

> RPL aware, so it must insert an IPv6 header that can be removed on the
    > last RPL aware node.  Since the root can not know in a storing network
    > where the last RPL aware node is, the IPv6-in-IPv6 header must be added
    > hop-by-hop along the path from root to leaf.
    > ---

    > destinationaddress is rpl-aware or not.  This might be true for P2P
    > traffic, but for root->leaf traffic, I would expect that the root knows
    > that.

I don't want to be confused by the term P2P: let's use the term leaf to leaf
traffic unless you are speaking about a path that is arrived at via P2PRPL.
(RFC 6997).

    > There is the Transit Option for DAOs with the 'E' flag to indicate that
    > the target address was not learned from rpl.  I would expect that this
    > 'E' flag is set for all Transit Options in DAOs until it reaches the
    > root node (recursively).  So the root node should actually be aware
    > which address was learned from RPL and which not.

Assuming that the 'E' bit was set, and that it propogated up to the root
(I can't find any text in RFC6550 that mandates that, maybe I missed it),
the root still would not know the address of the adjacent 6LR, if there is
more than two layers of mesh.

And, as you point out, it won't work for leaf to leaf traffic, so we still
have to support the situation of hop-by-hop IPv6-in-IPv6. (unless rfc2461bis)

It does permit us to distinguish between situation 5.2 (root to rpl-aware
leaf) and 5.3 (root to not-rpl-aware-leaf), which is certainly an
improvement! The root then learn about the "E" status for all leaf nodes, and
if there are no not-RPL-aware leafs, could announce that in it's DIO.  That
would permit leafs to know that case 5.10 (leaf to not-RPL-aware leaf) never
occurs, and therefore could avoid IPv6-in-IPv6 headers in that case.
        (can you contribute any text for the document from this?)

This a definite improvement as well: and the result is that we may need a
document to describe an option to put into the DIO to announce this
situation. (If there *are* not-RPL-aware leafs, then another option instead
of IPv6-in-IPv6 hop-by-hop for all traffic, would be for leafs to
IPv6-in-IPv6 traffic to the root rather than go across the DODAG.  Serious
performance and congestion issues if we do that, but maybe less code and less

Ines and Michael.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 10:30:26 -0400

peter van der Stok <[email-masked]> wrote:
    >> There is the Transit Option for DAOs with the 'E' flag to indicate
    >> that the target address was not learned from rpl.  I would expect that
    >> this 'E' flag is set for all Transit Options in DAOs until it reaches
    >> the root node (recursively).  So the root node should actually be
    >> aware which address was learned from RPL and which not.

    > procedure for the root to learn RPL associated addresses.

Are you are referring to section 6.7.8 of RFC6550, or section 9.4?
The root does not learn adjacency in storing mode, only in non-storing mode.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 10:32:20 -0400

> manually or through any other mechanism to be marked somehow
    > differently than routes that were accumulated with DAOs.  How to mark
    > routes "differently" seems to be implementation specific.  (but this
    > information would be used to fill in the `E` flag of Transit Options in
    > DAOs later).

yes, one would expect the neighbour cache to have a direct (connected) route
to a non-RPL aware node that was discovered through neighbour
discovery. (NS/NA).

    > So, if a rpl router forwards a packet downwards (storing-mode), it
    > somehow needs to know whether the (dst;next-hop) pair in a forwarding
    > table is rpl-born or not. If it is not rpl-born, then the IPIP header
    > containing the RPI must be removed before continuing the forwarding
    > process, otherwise the IPIP+RPI is re-added and targeted to the
    > next-hop.

    > in the text above, but this process looks very blurry to me.  Any RPL
    > veterans available to make things clearer?

Actually, that's the point of this document: it's blurry for many!

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 10:34:49 -0400

> used in section 5.2. The problem for the 6LBR is the same.

Because the root doesn't know (unless we mandate that the E flag is
propogated all the way upwards), then the root has to always use hop-by-hop
IPIP for both 5.2 and 5.3, because the root can't tell which situation is in
play.  We (as omniscient god looking down) can distinguish the cases, but the
root can not.

Michael and Ines.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 18 Jul 2016 18:09:14 +0200

(unless we mandate that the E flag is
> play.

I thought that this was a good occasion to point that out in the rplinfo 
document.

Peter

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 15:16:05 -0400

peter van der Stok <[email-masked]> wrote:
    >> propogated all the way upwards), then the root has to always use
    >> hop-by-hop IPIP for both 5.2 and 5.3, because the root can't tell
    >> which situation is in play.

    > I thought that this was a good occasion to point that out in the
    > rplinfo document.

Noting that this issue goes away with rfc2460bis... but assuming that wasn't
the case...

if we need to clarify that the E flag is sent upwards, then we *can* say that
in useofrplinfo, because it was designed to be standards track *UPDATE* to
RFC6550.