Re: [Roll] changes to OF0 in draft-hou-roll-rpl-parent-selection

houjianqiang <houjianqiang@huawei.com> Thu, 30 March 2017 21:36 UTC

From: houjianqiang <houjianqiang@huawei.com>
To: "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: RE: [Roll] changes to OF0 in draft-hou-roll-rpl-parent-selection
Thread-Index: AdKpnRt8NuK6JNPZQ9asjoJju2wuxw==
Date: Thu, 30 Mar 2017 21:36:12 +0000
Message-ID: <DD0A994E4D6B3F4080662703C8C7C086A0CF10@DGGEMM506-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086A0CF10DGGEMM506MBSchina_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/MQmrsHdeVWarCFPQgeHFg_bwTSA>
Subject: Re: [Roll] changes to OF0 in draft-hou-roll-rpl-parent-selection
Precedence: list

Dear Michael,



Many thanks for your feedback. I appreciate you valuable comments very much.



The reason I propose to tweak the defined values and put the Child Node Count (CNC) in the Metric Container is that in this way we can easily combine CNC with other metrics such as ETX (e.g. setting Prec field to control precedence ETX > CNC). When used alone, CNC as a new OF is too weak, but a combination of ETX and CNC improves the balance issues in dense situations.



My draft aims to solve the balance issue in the storing mode when nodes are able to determine the number of child nodes from the cache. Qasem proposes a way that enables parents to tell in the non-storing mode. Possibly a combination of these two drafts gives a better way to solve the balance issue.



Also thanks for pointing out my mistake in writing IANA consideration.



Best regards,

Jianqiang







Date: Thu, 30 Mar 2017 13:55:19 -0400

From: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>

To: roll@ietf.org<mailto:roll@ietf.org>

Subject: [Roll] changes to OF0 in draft-hou-roll-rpl-parent-selection

Message-ID: <11845.1490896519@obiwan.sandelman.ca<mailto:11845.1490896519@obiwan.sandelman.ca>>

Content-Type: text/plain; charset="us-ascii"





Thank you for this document.



draft-hou-roll-rpl-parent-selection proposes to tweak some things in OF0.

It seems to me that rather than tweak some well defined values in OF0 or MRHOF, that the document should simply propose a new OF.  This would seem to be a clearer solution, although taking an upgrade of all nodes to include a new OF before it can be used.



This document suggests creating a Child Node Count (CNC) object to go into

the DIO in the DAG Metric Container.    It is unclear in my reading how

the parent determines (in a non-storing network) how many children it has.



The qasem-roll-rpl-load-balancing has an interesting way for the parent to tell.  It seems that there is potentially two avenues of work represented by these two drafts, but some common protocol plumbing that the WG could take into a single (small) document.



And, when writing IANA Considerations, please do not repeat the registry, just indicate which new resources you need.  Your new value should be "TBD", (so that IANA will allocate it for you).

I'd have to check 6550 to see if we had any private use numbers for experimentation.



--

Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works  -= IPv6 IoT consulting =-

[Roll] changes to OF0 in draft-hou-roll-rpl-paren… Michael Richardson
Re: [Roll] changes to OF0 in draft-hou-roll-rpl-p… houjianqiang