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

[Rahul Arvind Jadhav <[e-mail]>]

    mcr> Are they individualized, or does every node in the LLN have to support
    mcr> a capability before it can be used?

Rahul Arvind Jadhav <[e-mail]> wrote:
    rj> Nice point. I haven't thought about this in detail. In non-storing
    rj> MOP, it may not be required that all the nodes support capabilities
    rj> but in storing MOP, every 6LR needs to add the cap (if present) of
    rj> the downstream child, thus requiring every node to support it. This
    rj> definitely needs handling in the draft.  [Ref:
    rj> https://github.com/roll-wg/MOPex-capabilities/issues/1

I see:

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.

[RJ] The problem may be in the other direction, .. In storing MOP, how 
should a 6LR which does not understand capability treat a DAO containing 
capability? Also how should a 6LR treat an unknown option in general? 
6550 mentions how to treat unknown RPL code but there is no handling 
for unknown option in DIO/DAO. Is there? I searched and could not find.
Most of the existing implementations just ignore what they don't 
understand.

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.
   It might be that it is better to encode these two bits are three
   values (plus 00-not supported).

[RJ] Another scenario could be that Root announces support for an 
optional capability. The 6LN just needs to know whether it could 
make use of this capability of the root to do something. It may not 
need to reply back to the root saying I see it and I support it.
Also should we be using two capability bits or we could use the info 
on whether the bit is set in DIO/DAO to infer the direction.

3) any 6LR may announce a capability to it's children that it received from
   it's parent, if it understands that capability.  If it does not, then
   it MUST clear the capability.

   This can be a unilateral capability (like 1), or one that has to be
   confirmed (like 2).  So this is really 3A and 3B.
[RJ] I get 3A .. but do we really need 3B. I mean if the node also needs 
to indicate that it also supports the same capability to the root then it 
can set the same bit in the DAO and send it back ... Thus working in 
both directions. It may not be required that capabilities be handshaked 
in both directions mandatorily. For e.g., root may indicate the capability 
that it has access to 6BBR and that unaware leaves could register 
through 6LRs. Thus 6LRs could proxy the NS (EARO) and other relevant 
messages. In this case, is it needed that 6LR reply back to the root 
saying it supports unaware leaves?
There might be another example which requires 6LRs/6LNs to indicate
in the reply that it supports the feature asked by root using the same 
cap bit in DAO. The DIO/DAO decides the direction but the bit can be 
the same.

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.
[RJ] agree

I therefore see several issues to resolve.
For capabilities that a node understands, it can know which type of capability it is.  For a capability that is unknown, if the behaviour is other than "set to zero", then we need to tell the node what kind of capability it is, and how it is encoded.

Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available, (3)-query, (3)-enable, (4)-available.  Conveniently, 7 things, plus all zeros.  We could encode capabilities in three bits, so the behaviour would be part of the encoded.

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