Re: [Roll] Semantics of DAO ACK

[Michael Richardson <[e-mail]>]

{this was left in my drafts on home desktop folder from before IETF94, sorry
for the lack of timelyness}

Pascal Thubert (pthubert) <[e-mail]> wrote:
    > * We could use the status as an enumeration the way people probably
    > expect it. But you'll note that we did not create a registry for it.

    > * Which hints you that we could also use it as a metric. A scalar
    > degree of unwillingness to serve as a parent, that accounts for stuff
    > like memory, available time slots in a chunk (for 6TiSCH) and/or
    > battery depletion of the node. The status would translate in such
    > things as serving as alternate but not as preferred parent.

I think that we need to pick one or the other.
I can imagine ways to do both, using some bits for each, but I'm not sure
that it's that useful.

I think the question is: what can we reasonably expect downstream (>rank) nodes to do
with this information?   I think we should come at this the other way.

Forget what's in the DAOACK right now, and figure out what the downstream
node needs to know, and then let's figure out how to either adapt what we
have, or extend/replace it.

    > The path that is really accepted in storing mode is self as a transit
    > for a given target. Transit can be aggregated for multiple targets. And
    > there can be multiple transits for a target. The DAO Ack could include
    > the pairs (transit/target) that are trouble  and indicate for each what
    > the trouble is. It could in theory aggregate what's aggregatable, but
    > the way the info in the dao ack is aggregated may have to differ from
    > what was placed in the DAO.

I think we absolutely need to know when a storing node can't accept all the
routes.  But then what?  I'm not sure if we can actually split the targets
across parents... but well... can we?  I can't think right now of a reason
why it wouldn't work.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-