Re: [Roll] capability handling

[Rahul Jadhav <[e-mail]>]

Thanks Michael,

There was ​another point we discussed during the interim in context to Capability Indicators: How to arrange the Indicator bits?
a. Using left to right
b. Or using right to left (currently in the draft [1])

If we use right to left then we can give every bit a number, for e.g., currently the 'T' bit is 0x1. The length can be set accordingly i.e. if the indicators are less than 8 bits then the length will be one.
This is simpler to handle in implementation as well. Thoughts?

Best,
Rahul

[1] https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-03#section-5.1.1

________________________________
From: Roll <[e-mail]> on behalf of Michael Richardson <[e-mail]>
Sent: 08 May 2020 02:01 AM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] capability handling


Rahul Jadhav <[e-mail]> wrote:
    > We would like to solicit some feedback about two points in context to
    > capabilities:

    > 1. Capability Instances: Currently the document instantiates two
    > capabilities viz, a) Capability Indicators (which can be used to carry
    > flags such as support of 6LoRH)
    > b) Routing Resource capability which
    > indicates total RIB capacity the node has. This should be useful for
    > DAO Projection.

    > Do you think we should add Neighbor Cache capacity
    > indication as well and what would be the use-case?

In some implementations the Neighbor Cache and RIB might come from the same
pool of resources.  Both are lookup /128 and add-header and xmit :-)
(BSD systems merged them back in BSD4.4, as an example)

If a node runs out of RIB entries, it can't add any more grandchildren.
If a node runs out of NC entries,  it can't add any more peers: children or parents.

It seems that we need to collect both information, but we might need to be
clear if they are linked.

    >   Do we need an explicit 'G' flag? We already have a flag (C-copy)
    >   which indicates that nodes have to copy the cap if they don't
    >   understand the cap. A global capability from the root can be
    >   advertised with this bit set. Nodes understanding this cap will
    >   anyways know how to handle and nodes not understanding it will copy
    >   it based on the 'C' flag. Thus not requiring another 'G' flag.

I have to think more on this.

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