Subject: [Roll] some comments on draft-thubert-dao-projection-00.txt

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Jul 2015 09:34:12 -0400

<Chair hat off>

Pascal, thank you for this document.
I especially appreciated your figure 2, the way that you numbered the nodes
with their gross rank as the the tens part.

You write on page 8:
   The root sends the DAO directly to the last node in the segment,
   which is expected to be able to route to the targets on its own.

It would be good to make it clear which direction one counts the "segment"
to know which one is last.  I don't like "segment" here, I think it's
a routing path...  Could you define segment if you think it's the most
natural term to use.
(There are also some articles like "the" missing in places, btw)

Then you write:
   The node strips the last Via Information option which corresponds to
   self, and uses it as source address for the DAO to the predecessor.

I think that what is described, to use the numbering in your example,
is that the root would send a message to 41, with a target=51,
list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31,
with a list of VIAs 11,22,31, etc.

It's the "then" above part that I *think* is a critical part of the protocol,
and is perhaps not clearly spelled out.  I wasn't entirely sure if I
read it correctly.

In the case where nodes have different downstream and upstream addresses
(because, for instance they had different radios), then there might be
some confusion and maybe both hops should be listed.  I recall I posted a
thread asking about that a year or so ago, but I don't recall what the
conclusion was.

But, then in the example on page 9, after sending these Via-DAOs to
45 and 46, it says:
   The root
   may then send a DAO to node 35 indicating targets 55 and 56 a Via
   segment (13, 24, 35) to fully optimize that path.

While the root had initially optimized the 45/46 out the routing
header with the first set of Via-DOAs (do you have a name for these messages?
Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24
in the list as well?

Alternatively, could the root have sent a single Via-DOA with destination
*35* to 24, with the route 13,24?   That would have resulted in a routing
header like:
       ROOT -> 35
since 13 and 24 should be able to reach 35 in a loose source route,
and 35 would know how to reach 55 and 56?

****

in section 3.1, the description of the VIA extension, you write:

Option Length:  Variable, depending on whether or not Parent Address
         is present.

But the only variability I saw in the extension was whether the child
address was 8 bytes or 16 bytes.  It seems that if you are going to
optimize this, you might as well also offer an option for the Child
Address to be 2 bytes (the last two bytes).

**** DAO

I don't fundamentally see a reason why DAO is used.  I guess it has the
right properties, but I think that a new message type could be defined
equally well (as well as a new ACK), even if it just replicates the exact DAO
structure.  It seems that the ACK is mandatory (K=1).

I would prefer that DAOs always flow towards the root, and DIOs away.
It would make analysis of what is going on easier.
These DAOs in some way flow towards a node with root-like storing-like
abilities, so I can see why it was elegant to reuse DAO for this.

**** incremental deployment

Use of a new MOP makes deployment of this a flag day.
I don't think that this is necessary, although some niggling doubt going back
to the mixed storing/non-storing discussion of 2011 remains...

I think that the DAOs that come from nodes that are able to act as Route
Projection nodes could indicate that capability, and furthermore, indicate
the number of routing slots they currently have free.

It would be advantageous perhaps to explicitely number the routing slots.
My initial thought is that would permit the subsequent DAOs to perhaps
include a count of how many times the Projected route was used: once the
DODAG root pushes traffic away from the root with these projected routes,
it can no longer count how much traffic is occuring, so it should get
reports "from the field" so that it can decide whether to keep those routes.

Explicitely numbering the routing slots could be problematic I agree,
but it would allow the DODAG to manage them directly rather than the implicit
process that the VIA option's Path Sequence is doing.

The Path Sequence processing needs an example, btw.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 4 Jul 2015 20:28:29 +0000

Fantastic Michael!

I'll answer in the list but many thanks already!

Pascal

> Le 4 juil. 2015 à 15:34, Michael Richardson <[email-masked]> a écrit :
> 
> 
> <Chair hat off>
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Sun, 05 Jul 2015 20:07:34 -0400

> (There are also some articles like "the" missing in places, btw)

I also realized yesterday that 6554/RH3, uses the term segment.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 Jul 2015 08:36:13 +0000

Hello Michael:

The draft indicates that the root knows some topological information from the non-storing DAO (it knows all about the DODAG).

Per RFC 6550, a path constructed by storing-mode DAO messages is directional, packets flow parent to child,  and we do not want to introduce confusion by changing any of that.
Thus the segment that is constructed from the segment egress to the ingress. 

It results that the segment is directional but not that it is necessarily flowing down the DADOG, this depends on how much information is available to the root or whatever PCE is used as a helper.

Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: lundi 6 juillet 2015 02:08
> To: Routing Over Low power and Lossy networks
> Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt
> 
> 
> Michael Richardson <[email-masked]>, Sandelman Software
> Works  -= IPv6 IoT consulting =-
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jul 2015 10:40:45 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > The draft indicates that the root knows some topological information
    > from the non-storing DAO (it knows all about the DODAG).

yes...

    > Per RFC 6550, a path constructed by storing-mode DAO messages is
    > directional, packets flow parent to child, and we do not want to
    > introduce confusion by changing any of that.  Thus the segment that is
    > constructed from the segment egress to the ingress.

I don't think I understand what this is an alternative to.
I.e. what would the way to do it wrong be?  Why are you suddendly talking
about storing-mode DAO messages.

    > It results that the segment is directional but not that it is
    > necessarily flowing down the DADOG, this depends on how much
    > information is available to the root or whatever PCE is used as a
    > helper.

This seems to imply that traffic could flow across the mesh... i.e. hop
From branch to branch.   How would the DODAG root know that this was possible
using pure RPL?  I think that it couldn't without 6top or something.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Jul 2015 16:24:52 +0000

Yes, 

segment is used a lot these days. 
In RH that's usually one loose hop between 2 entries in the RH.
Maybe projected route is better because it is more specific to what we are doing?

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Jul 2015 16:26:53 +0000

Hello Michael

> I.e. what would the way to do it wrong be?  Why are you suddenly talking

I did that because the signaling of the projected route being installed is hop by hop using DAO in a fashion that extend storing mode.
The DAO flow from egress to ingress of that projected route while the data flow the other way. 

> using pure RPL?  I think that it couldn't without 6top or something.

Yes.  DetNet may provide means for that.
The draft does not say where the root could get more information but it does not preclude the projecting routes across the mesh.

Cheers, 

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Jul 2015 17:00:08 +0000

Hello Michael

> I think that what is described, to use the numbering in your example, is that the root would send a message to 41, with a target=51, list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIAs 11,22,31, etc.

> It's the "then" above part that I *think* is a critical part of the protocol, and is perhaps not clearly spelled out.  I wasn't entirely sure if I read it correctly.

<PT> That is correct, as shown in fig 2, but I agree we need to clarify

> In the case where nodes have different downstream and upstream addresses (because, for instance they had different radios), then there might be some confusion and maybe both hops should be listed.  I recall I posted a thread asking about that a year or so ago, but I don't recall what the conclusion was.

<PT> The root indicates the sequence of next hop address. These are the addresses that are available on the interface of the child that connects to the parent. The node uses that address as source of its own DAO, which indicates it on which interface to send the DAO.

*35* to 24, with the route 13,24?   That would have resulted in a routing
header like:
       ROOT -> 35
since 13 and 24 should be able to reach 35 in a loose source route, and 35 would know how to reach 55 and 56?

PT> That is correct, assuming that this is an alternate to 
"
The root may then send a DAO to node 35 indicating targets 55 and 56 a Via
   segment (13, 24, 35) to fully optimize that path.
"

PT > Your other points well taken, I'll talk to James and we'll fix the draft.

All the best

Pascal

Cheers,

Pascal

> Sent: samedi 4 juillet 2015 15:34
> To: [email-masked]
> Subject: [Roll] some comments on draft-thubert-dao-projection-00.txt
> 
> 
> <Chair hat off>
> 
> to know which one is last.  I don't like "segment" here, I think it's a routing
> path...  Could you define segment if you think it's the most natural term to
> use.
> I think that what is described, to use the numbering in your example, is that
> the root would send a message to 41, with a target=51, list of
> VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIAs
> 11,22,31, etc.
> 
> It's the "then" above part that I *think* is a critical part of the protocol, and
> is perhaps not clearly spelled out.  I wasn't entirely sure if I read it correctly.
> 
> In the case where nodes have different downstream and upstream
> addresses (because, for instance they had different radios), then there
> might be some confusion and maybe both hops should be listed.  I recall I
> posted a thread asking about that a year or so ago, but I don't recall what
> the conclusion was.
> 
> While the root had initially optimized the 45/46 out the routing header
> with the first set of Via-DOAs (do you have a name for these messages?
> Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24 in
> the list as well?
> 
> since 13 and 24 should be able to reach 35 in a loose source route, and 35
> would know how to reach 55 and 56?
> 
> ****
> 
> But the only variability I saw in the extension was whether the child address
> was 8 bytes or 16 bytes.  It seems that if you are going to optimize this, you
> might as well also offer an option for the Child Address to be 2 bytes (the
> last two bytes).
> 
> **** DAO
> 
> I don't fundamentally see a reason why DAO is used.  I guess it has the right
> properties, but I think that a new message type could be defined equally
> well (as well as a new ACK), even if it just replicates the exact DAO structure.
> It seems that the ACK is mandatory (K=1).
> 
> it can no longer count how much traffic is occuring, so it should get reports
> "from the field" so that it can decide whether to keep those routes.
> 
> Explicitely numbering the routing slots could be problematic I agree, but it
> would allow the DODAG to manage them directly rather than the implicit