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

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

Fantastic Michael!

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

Pascal

> Le 4 juil. 2015 à 15:34, Michael Richardson <[e-mail]> a écrit :
> 
> 
> <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 <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll