Subject: Re: [Roll] Router Capabilities

From: Rahul Arvind Jadhav <[email-masked]>
Date: Fri, 31 May 2019 00:30:08 +0000

Hi Rabi,

<Taking the discussion to ROLL ML>
Thanks for the review and feedback. Please find my responses inline.

Regards,
Rahul

Hi Rahul
I was going through the https://tools.ietf.org/html/draft-rahul-roll-mop-ext-00.
There you have mentioned about the capability option. I feel this will be very useful. All the linked state routing protocols like (ISIS or OSPF) has routing capabilities TLVs added to their LSP packets(RFC 7981).
I think this configuration option can also use the TLV format to define multiple  capabilities of the LR nodes. Few Capabilities that can be added
1-- Extended MOP can be part of this also i think
2-- RPI Types supported
3-- Lowpan Compression type.
4-- Resource Information
[RJ] Currently MOPex (extended MOP) is a new option type. Is there any reason why you think MOPex should be part of capabilities section and not different option type?
RPI types is not optional i.e., a network either support new RPI type 0x23 or it doesn’t. Hence the point of using flag day to update all nodes with new RPI type. This cannot be part of capabilities I feel. But we can discuss more if you have other point about this.
LoWPAN compression type is an interesting point but isn’t there a dispatch code already which can distinguish between different compression types on per packet basis?
Resource information is a potential candidate. This capability option handshake could aid DAO projection as well. If you have any specific proposition, it will be nice to discuss here or better have an ID.

I didn't get why capabilities need to be added DAO. When a node knows all the capabilities of the joining router it can select accordingly. Anyway when he sends his capabilities in its DIO its parent will receive it and can update the capabilities.
[RJ] by adding caps to DAO we have a mechanism wherein the 6LR or 6LN node could signal the root (and intermediate 6LRs along the path) about its capabilities. One relevant case which is currently been discussed on the ML is the turn-on of 8138. The nodes need to signal the root whether they are 8138 ready, such that subsequently the root could update the network with the T-flag in DIO, signaling nodes to switch to 8138-mode of compression.

Coming to the current discussion on 0x23 and 0x63 RPI option we have already seen during OTA it can be a problem some node can never be reachable.
I can describe the scenario. We have faced it while working with Enterprise team.
[RJ] It will be great if you could summarize the pain point here. Thanks.