Re: [Roll] capability handling

[Rahul Jadhav <[e-mail]>]

Thanks Pascal for the feedback. Please find [RJ] inline below.

________________________________
From: Roll <[e-mail]> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]>
Sent: 11 May 2020 10:38 PM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] capability handling


Hello Rahul



Sorry for being late on this:



There are different things we may want to convey:

- local/global: indicates whether to forward the bit. Local is a parent property, Global is a DODAG property. It boils down to your “copy” action so to your point we do not need both the G and the copy bits. Note that RPL also uses the term “propagate”, and I tend to prefer using it again here rather than copy.


[RJ] So it seems we are aligned. I will remove the 'G' flag in the next rev. Also will change the term to propagate (aligning with 6550).



Then there’s the things we define for the configuration which may also apply to capabilities:

- critical/elective: indicates what to do when the capability is not known; Ignore this capability vs. drop the message

- router/leaf: I’m wondering if we have a case where the node should become a leaf if there’s a capability it does not understand. That would be another bit.


[RJ] We already have provisions for router/leaf. 'J' (join as "leaf only" if cap not understood) and 'C' (copy) flag handle this. Regarding the critical/elective bit, I guess we do not have a way for a node to drop a message. So you are saying, there should be a way for a node to drop the message if it does not understand it and still be part of the network as a 6LR?



Does that help?


[RJ] Thanks, it does help greatly.







From: Roll <[e-mail]> On Behalf Of Rahul Jadhav
Sent: jeudi 7 mai 2020 11:37
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] capability handling



<< sorry my last mail was sent incomplete>>



Hello All,

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?

2. Regarding the use of 'G' (global) flag on per capability basis:

       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.



Best,

Rahul

________________________________

From: Rahul Jadhav
Sent: 07 May 2020 05:28 PM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: capability handling



Hello All,

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?

2. Regarding the use of 'G' (global) flag on per capability basis: