Re: [Roll] do capabilities need to understood, can they be added?

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    pt> Seems to me that sometimes the capability of the node is something that
    pt> only the root cares about.

Yes, agreed.  This was my case (1), which I've brought up.

    >> 1) the root announces a capability.  6LRs that understand it may use the
    >> new capability unilaterally if they understand it, and see a need for it.
    >> Nodes that do not understand the new capability are not affected.
    >> This could be a control plane thing, or a data plane thing.

    pt> At least that's true when the root needs to know if all nodes support a
    pt> capability. It wants to flood a query and gather the responses from
    pt> all. Missing queries would mean a unicast retry I guess.

Agreed. That's my case (2).

    >> 2) the root announces support for capability that it wishes to enable, in
    >> order for it be used, every node must support it.  If every DAO from
    >> every node supports the capability, then the root announces that it
    >> is turned on.
    >> This in effect is a two-pass system, requiring either two capability
    >> bits.

Phase 1 is to learn whether all the nodes support it.
Phase 2 is to tell the nodes whether they can turn it on or not.
  draft-thubert-roll-turnon-rfc8138-03

could be done this way, btw.

    > At other times it might be something that the parent cares about. In
    > that case it asks one or all of its children.

Yes. That's my case (4).

    >> 4) any 6LR may announce a capability to it's children, even if it did not
    >> receive it from a parent.  The capability is not to be repeated by
    >> the children (regardless of whether they understand it), unless they also
    >> wish to enable it.

    > So we're after a capability exchange flow that is unicast or multicast,
    > with a unicast response. Either from parent to child or from root to
    > any. The flow would be independent of the storing vs. non-storing MOP.

Agreed.

    > We do not really have a flow like that in RPL. It's akin to a software
    > update, when the root wishes to now if all nodes have received the full
    > image.

So, you are suggesting that any reply from the nodes to the root shouldn't
use DAO, but something new.    I don't see why we can't put the downward
signal into the DIO though.

    > The DIO could be stretched to convey the ask to a group, but it's hard
    > to make it reliable. The DAO even less OK since it carries destination
    > not node information. As of today the root does not really know if
    > multiple addresses are on a same node.

    > All in all it seems that we are after something that is needed by RPL
    > but on the side of the current protocol. I'm not too sure that we
    > should overload the current messages for this. Rather, we may build new
    > objects for Nodes information and capability. Like a unicast or
    > multicast NIS (Node Info Solicitation) and a NAO (Node Advertisement
    > Object). We'd design operations that are independent of the current
    > MOPs. Note that we could use local broadcast NAO to discover siblings
    > and siblings siblings, something P DAO needs anyway.

I am for NAO as always being from node to root.
I see how we could do this multicast for P-DAO, but I think that I need to
know more.

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