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

[Michael Richardson <[e-mail]>]

Rahul Arvind Jadhav <[e-mail]> wrote:
    mcr> Are they individualized, or does every node in the LLN have to
    mcr> support 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
    RJ> should a 6LR which does not understand capability treat a DAO
    RJ> containing capability? Also how should a 6LR treat an unknown option
    RJ> in  general?  6550 mentions how to treat unknown RPL code but there
    RJ> is no handling for unknown option in DIO/DAO. Is there? I searched
    RJ> and could not find.  Most of the existing implementations just ignore
    RJ> what they  don't understand.

There is the case where an implementation does not understand the capability
extension, in which case, it likely does not copy it down, and no node below
that node can use that capability, even if would be safe.  The children could
hear other DIOs via other paths, so all is not lost.

I'm trying to address the case where the capability extension is passed on,
but the node may not know the specific capablity that was listed.

    > 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
    RJ> capability. The 6LN just needs to know whether it could make use of
    RJ> this capability of the root to do something. It may not need to reply
    RJ> back to the root saying I see it and I support it.  Also should we be
    RJ> using two capability bits or we could use the info on whether the bit
    RJ> is set in DIO/DAO to infer the direction.

That's case (1).
Case (2) is where the root wants to enable use of some capability, but to do
so, it needs to know if all nodes support it.  This where we need a discover
operation followed by an enable operation.  

    > 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
    RJ> to indicate that it also supports the same capability to the root
    RJ> then it can set the same bit in the DAO and send it back ... Thus
    RJ> working in both directions. It may not be required that capabilities
    RJ> be handshaked in both directions mandatorily. For e.g., root may
    RJ> indicate the capability that it has access to 6BBR and that unaware
    RJ> leaves could register through 6LRs. Thus 6LRs could proxy the NS
    RJ> (EARO) and other relevant messages. In this case, is it needed that
    RJ> 6LR reply back to the root saying it supports unaware leaves?  There
    RJ> might be another example which requires 6LRs/6LNs to indicate in the
    RJ> reply that it supports the feature asked by root using the same cap
    RJ> bit in DAO. The DIO/DAO decides the direction but the bit can be the
    RJ> same.

But, (3) is about an intermediate node announcing it can do something for its
children (and grandchildren).  

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [