Re: [Roll] Router Capabilities

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Fri, 31 May 2019 00:30 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEB612016F for <roll@ietfa.amsl.com>; Thu, 30 May 2019 17:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSXtq0wK27X6 for <roll@ietfa.amsl.com>; Thu, 30 May 2019 17:30:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B55120048 for <roll@ietf.org>; Thu, 30 May 2019 17:30:26 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8135FA710002BB3512FD; Fri, 31 May 2019 01:30:23 +0100 (IST)
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 31 May 2019 01:30:22 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.12]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0439.000; Fri, 31 May 2019 06:00:09 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: rabi narayan sahoo <rabinarayans0828@gmail.com>, Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: Router Capabilities
Thread-Index: AQHVFv2YvHPOqQzcvUmcgbjKQnYKbKaEW66w
Date: Fri, 31 May 2019 00:30:08 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DEC8CA5@BLREML503-MBX.china.huawei.com>
References: <CAPT0++3xhfwcDwxv9SbNE-LVnihBn5XiyB-EMgbDGKoHUOKUCw@mail.gmail.com>
In-Reply-To: <CAPT0++3xhfwcDwxv9SbNE-LVnihBn5XiyB-EMgbDGKoHUOKUCw@mail.gmail.com>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.157.44]
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DEC8CA5BLREML503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Qc2kfcgilfgehyZqIeOQEITwo3A>
Subject: Re: [Roll] Router Capabilities
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2019 00:30:29 -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.