[Roll] About the flags of metric container in draft-pkm-roll-nsa-extension

"Houjianqiang (Derek)" <houjianqiang@huawei.com> Fri, 22 December 2017 09:36 UTC

Return-Path: <houjianqiang@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 E2DC91205F0 for <roll@ietfa.amsl.com>; Fri, 22 Dec 2017 01:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qxjxg1zA4JTX for <roll@ietfa.amsl.com>; Fri, 22 Dec 2017 01:35:59 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 863FC120227 for <roll@ietf.org>; Fri, 22 Dec 2017 01:35:59 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 86E07E35F6F39 for <roll@ietf.org>; Fri, 22 Dec 2017 09:35:55 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 22 Dec 2017 09:35:56 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Fri, 22 Dec 2017 17:35:37 +0800
From: "Houjianqiang (Derek)" <houjianqiang@huawei.com>
To: "aris@ariskou.com" <aris@ariskou.com>, "georgios.papadopoulos@imt-atlantique.fr" <georgios.papadopoulos@imt-atlantique.fr>
CC: roll <roll@ietf.org>
Thread-Topic: About the flags of metric container in draft-pkm-roll-nsa-extension
Thread-Index: AdN7B9o4rCjH+BtCSymcw04SSPKXaA==
Date: Fri, 22 Dec 2017 09:35:37 +0000
Message-ID: <DD0A994E4D6B3F4080662703C8C7C086AB265B@DGGEMM506-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.134.224]
Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086AB265BDGGEMM506MBSchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/55NGqtxvYgnpdljcj3CAB2Vv93U>
Subject: [Roll] About the flags of metric container in draft-pkm-roll-nsa-extension
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Dec 2017 09:36:02 -0000

Dear Remous-Aris and Georgios,

Thanks for bringing your draft "draft-pkm-roll-nsa-extension" into roll WG. It's a very interesting work and hope it could be adopted in this WG.

The recent discussion with Chenyang triggers my interest to read this draft again. Below are my comments.

It seems that your NSA metric is locally used. I mean one node includes its potential parents into NSA and sends this NSA down to its potential children. If this is correct, then it would be good to specify the parameters used in the Metric Container (P,C, O, R ,A, Prec fields). (PS: there are two 'A' and two 'O' bits in Figure 3 of your draft...) I suggest this because I find that to meet the NSA function you want, we may need to extend the usage of Metric defined in RFC6551. What RFC6551 bother me are the 'R' flag and 'A' field in the MC. When NSA is used as a metric, R=1 indicates that the NSA is recorded along the path; R=0 indicates the NSA metric is aggregated (this aggregation could be additive, multiplicative, reports a maximum or minimum according to the 'A' field). I suppose the NSA metric requires to be used locally, not aggregation or recorded along the path. I guess the 'P' flag may help to solve this issue or we may need a new flag in the MC to indicate a locally used metric.

I am involved in draft "Load Balancing Objective Function in RPL" and I have similar concern when setting the flags in the metric container for the proposed Child Node Count (CNC) metric. We also want the CNC to be used locally, and it seems we need to extend the current metric usage in RFC6551. The same requirement may appear in Chenyang's draft "Traffic-aware Objective Function".

And one more thing. I find with your proposed NSA that includes parent address(es), we don't need to insert the parent address into our CNC metric. This greatly simplifies our solution. That's good!

Best regards,
Derek Jianqiang Hou

Related drafts:
https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/
https://datatracker.ietf.org/doc/rfc6551/
https://datatracker.ietf.org/doc/draft-qasem-roll-rpl-load-balancing/
https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-function/