[Roll] DIS modifications draft

"Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <rahul.jadhav@huawei.com> Tue, 21 June 2016 04:53 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9273412D6B8 for <roll@ietfa.amsl.com>; Mon, 20 Jun 2016 21:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Status: No, score=-5.646 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vB6DAfw64zh4 for <roll@ietfa.amsl.com>; Mon, 20 Jun 2016 21:53:21 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A93012D58E for <roll@ietf.org>; Mon, 20 Jun 2016 21:53:20 -0700 (PDT)
Received: from (EHLO lhreml707-cah.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRE90475; Tue, 21 Jun 2016 04:53:17 +0000 (GMT)
Received: from BLREML406-HUB.china.huawei.com ( by lhreml707-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 21 Jun 2016 05:53:16 +0100
Received: from BLREML510-MBS.china.huawei.com ([]) by BLREML406-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Tue, 21 Jun 2016 10:23:04 +0530
From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <rahul.jadhav@huawei.com>
To: Roll <roll@ietf.org>
Thread-Topic: DIS modifications draft
Thread-Index: AdHLeMnvHEm/6o+8QDqLXQ5408gOZg==
Date: Tue, 21 Jun 2016 04:53:04 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5D03BB1B@blreml510-mbs.china.huawei.com>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5D03BB1Bblreml510mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5768C83E.0048, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f981cb1b7e7dc563ff627630020f0da5
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/M7epDVVlkAXkjbJ3_RCxWQ8Tc1o>
Subject: [Roll] DIS modifications draft
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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: Tue, 21 Jun 2016 04:53:23 -0000

Dear authors of draft-zhong-roll-dis-modifications-00<https://tools.ietf.org/html/draft-zhong-roll-dis-modifications-00>00>,

Few comments:

1.       In section 3, "the "DIO Type" (T) flag: In case the N flag is set, this T flag
      specifies what type of DIO is sent in response.  It MUST be a
      unicast DIO if this flag is set and it MUST be a multicast DIO if
      this flag is reset."

Is it necessary to put a MUST clause for unicast DIO? There might be reasons why multicast DIO might prove efficient. Consider for example that nodes are started in parallel and each of them sends a multicast DIS with 'T' bit set. There are two scenarios:

A)      The number of nodes are less and sparsely located .... In this case unicast DIO might work out more efficiently.

B)      The number of nodes are more and densely populated ... In this case unicast DIO from already joined peers to every newly started node might prove inefficient.... Imo, it should be possible for the parent nodes to detect the number of mcast DIS rcvd (during the interval of response spreading time) and respond with mcast DIO if necessary i.e. if more number of mcast DIS(T=1) are rcvd then mcast  DIO may be sent in response. Also when a already joined node receives multiple mcast DIS with T=1 and with different response spreading times then the handling becomes complex!

2.       If unicast DIO option is available, do you see any scenario/reason why any node will generate a mcast DIS with T=0 ? I mean, is the node sending the DIS in a position to decide whether it requires ucast/mcast DIO ?

Imo, I feel this draft is important as it reduces the control overhead during network formation/node joinin and may also improve on the network convergence time. Thanks for your work.


This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!