Subject: [Roll] capability handling

From: Rahul Jadhav <[email-masked]>
Date: Thu, 7 May 2020 09:28:17 +0000

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:

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 7 May 2020 09:36:43 +0000

<< sorry my last mail was sent incomplete>>

Hello All,

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 <[email-masked]>
Subject: capability handling

Hello All,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 May 2020 14:01:18 -0400

> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 8 May 2020 12:52:52 +0000

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 <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: 08 May 2020 02:01 AM
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] capability handling

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 May 2020 14:05:29 -0400

Rahul Jadhav <[email-masked]> wrote:
    > 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?

(1) If we number from right to left, can we expand the field to be as many octets
    are we like?  So len=3 is just an example?  Don't transmit zero bytes.

(2) If we number from left to right, then we could number them "bit 0" through
    "bit 7" of byte 0 through 255.

The IANA considerations for this might be a bit weird either way.
I guess there is a maximum number of octets that we can get into the field
anyway, so we declare it to be a field with that many bits and ask IANA to
allocate contiguously.

The effect is the same: we don't transmit bytes which are zeros, it's just
whether we consider those zeros on the left or right.

I think that (2) might easier to code because the offset of each flag will
not move as the structure gets longer, and it doesn't confuse people into
thinking they need 64-bit ints, which then fail on capability #65. (actually #64)

---

From: Rahul Jadhav <[email-masked]>
Date: Sat, 9 May 2020 12:46:18 +0000

Please find comments inline.

Sent: 09 May 2020 02:05 AM

[RJ] Yeah len=3 is just an example.

[RJ] This point makes sense. If the indicators go more than (or eq to) 64 then the operations are not so straightforward to handle. With left to right, the complexity is constant regardless of the number of bits.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 11 May 2020 14:38:14 +0000

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.

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.

Does that help?

Pascal

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

Hello All,

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

Hello All,

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 12 May 2020 01:09:14 +0000

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

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

Hello Rahul

- 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:

- 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.

Hello All,

Best,

Rahul

From: Rahul Jadhav

Hello All,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 May 2020 12:54:10 +0000

Hello Rahul

> 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?

I do not have an example but say a DIO requires something that a node does not understand, and that prevents operation even as a leaf, then we need that bit. The problem is that we need to design the infra now - before it is needed - so we need to cover all cases.

Take care,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: mardi 12 mai 2020 03:09
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] capability handling

From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>

Hello Rahul

Does that help?

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

Hello All,

Best,

Rahul

From: Rahul Jadhav

Hello All,

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 12 May 2020 13:06:37 +0000

[RJ] Sure, we can provision this. I agree that extending this later will be a pain because of compatibility issues. Anyways the packet cost is just one bit.

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

Hello Rahul

Does that help?

Hello All,

Best,

Rahul

From: Rahul Jadhav

Hello All,