Re: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00

Rahul Jadhav <> Fri, 14 July 2017 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4CE1128768; Fri, 14 Jul 2017 03:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0x9PRDZ71szq; Fri, 14 Jul 2017 03:12:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36C62131828; Fri, 14 Jul 2017 03:12:44 -0700 (PDT)
Received: by with SMTP id g13so30559312uaj.0; Fri, 14 Jul 2017 03:12:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ESWO4R7vYDuE6brUbrTdV7T1CtVzgcf4NQ/4vRuLpZI=; b=Bb8neqJjBMbDmn5hQbE/8kq6mQU3uJVhw5sBCGRde4cMn2Snf2x85hPyLIlVB7AyoM l0QNkcZOqr0PSiKqWiRGh6xMk3SGCGVVskO4doIYQs2p1MVYE5Qt9pipdSep7WIjBuIo nqz1MWfySil002dAdRZmLCAGbSwu1v2Q1LPGUWEUjklV9GRrvfnnDHCHfTcGEwOwd/di d9YtyUA/TItq0aQ7BJUap3sSZI2OfpiImFs2CrcxITNnMrgFM/KSe+4XBSnkPjGH7Q7A ohZeTzVcAV0IdAlOX/dZ+sheHKEXCQqg0kJ0KhdTuNFhUkH5lwEjg7K5c5r+diDbsrnd 9i5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ESWO4R7vYDuE6brUbrTdV7T1CtVzgcf4NQ/4vRuLpZI=; b=o2/xoWDb1OCLNDe6yfTM0crqmm1FRaQMOhLhoBIpY7xetP9Be1xLEuWXXSYTKwVz7b INXODbV+ctbB40lkXYL+uKYz+5fiOSLxPq1Qh86eYJdqPdbrImCQSZFdgSb2NNXQpSxr duFkCVKXNjFA97EUBYBDAvci1D5sEl3aOr+D8S3DghcAvZTvglrbbTuSWRJTNAsmvCxe PSM7Pp2NwhsApLkLcCmSTKDYZORH4JfhXC47YWlSKsAFyJb9/Q9lsguBQOABx2APRJlZ yyLFXrKEeHqGzTzz0apwVs2c81bAAQ1dvQwMIo/ehq9lH1T8pTFjGjDJrZiKdtxHvsQh syKg==
X-Gm-Message-State: AIVw113UWROFo9ZIHHsEmSwm+nw15KH0hX6cF0wu4LShk/7KbV1TNM3N l94VqAgJcRTVgFeE5CkvtIlKwtNsJQ==
X-Received: by with SMTP id 100mr5453945uac.108.1500027163270; Fri, 14 Jul 2017 03:12:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Jul 2017 03:12:42 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Rahul Jadhav <>
Date: Fri, 14 Jul 2017 15:42:42 +0530
Message-ID: <>
To: Zhen Cao <>
Cc:,, lo <>, Routing Over Low power and Lossy networks <>
Content-Type: multipart/alternative; boundary="001a113562da3863d80554444aa4"
Archived-At: <>
Subject: Re: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jul 2017 10:12:47 -0000

Thank you Zhen for the review and comments...
Please find my responses inline ...


On 14 July 2017 at 06:18, Zhen Cao <> wrote:

> Dear Rahul and co-authors,
> Many thanks for the hard work in contributing this draft to the lwig
> wg. (I am copying roll and 6lo since some discussion will be quite
> relevant)
> As I go through the document, I found essentially there are three
> types of different policies discussed:
> a. Trivial neighbor management (FCFS/LRU)
> b. advanced neighbor management (proactive and reactive)
> c. proposed ‘reservation based’ approach
> Logically I understand the shortcomings of the trivial approach,
> however in practice, how much this many impact the network stability
> is not convincing enough yet. (what’s the possible size of node
> density/mobility may be impacted? ).

a) Existing open sources (such as RioT and Contiki) implement trivial nbr
mgmt policies ... for e.g. riot uses FCFS, and Contiki previously used LRU
(but Contiki in the past some time has upgraded and put out a new
implementation inline to what we have proposed) ... Through this draft we
want to highlight scalability issues with such trivial policies ...
Scalability issues arise especially in case of dense networks with nodes
having limited memory for neighbor cache ...
b) Currently the draft talks only about reactive "reservation" based
policy, since our aim to begin with, is to check what best can be achieved
without making any signaling changes ... But clearly this has limitations
which also are highlighted by the draft and we have put forth  the
reasoning for using proactive signaling ...
In my deployment scenario, we could never stabilize the network unless we
implemented such a policy ... My deployment is a typical metering scenario
and the node density is not in control (network size is, but not the node
density) ... In some areas the node density is high (100 nodes on the same
hop) .. and the nbr cache is limited to say 25 entries ... in such a case
NCEs undergo a churn which results in routing adjacencies never stabilizing
...  Specifically, the draft will help implementers in cases "where the
node density is higher than nbr cache size".
Another way to look at that is, even if a node can afford to store a bigger
nbr cache, it is inefficient use of dynamic memory. Proposed policy can be
used to reduce the nbr cache size and thus optimize mem usage!

> The discussion of reactive and proactive ways of managing the neighbor
> cache entries is helpful. The discussion about the proactive approach
> in Sec.2.5.2 quoted below has some pending relationship with RPL (if
> this is an acknowledged problem by ROLL WG).  Anyway this is something
> we need to discuss with the ROLL wg to see if this a need feature.
>     Currently there is no standard way of signaling such neighbor cache
>    space availability information.  RPL's DIO messages carry metric
>    information and can be augmented with neighbor cache space as an
>    additional metric.

[RJ] As I mentioned before, the current approach is a reactive
"reservation" based approach ... It improves network stability but still
has its own limitations (highlighted in the draft). These limitations could
be worked out with some changes to existing protocols (such as RPL). As
part of LWIG draft we have set forth only requirements towards such changes.

> For the proposed reservation based approach,  I think this is quite a
> practical recommendation (if my concern about a. will be relaxed).
> I also found the Contiki RPL implementation has recently used a
> similar way in its rpl-nbr-policy. Shall we link the draft to the open
> source community to see if the document has provided additional help
> to the implementation? (or that’s already done given coauthors Simon
> and Joakim are both active contributors of Contiki)?

[RJ] The Contiki rpl-nbr-policy implementation is already in line with the
proposed draft. We already have the Contiki implementers as co-authors of
this draft and their inputs have shaped the draft quite a lot.

> Many thanks for discussion.

Thank You!

> Cheers,
> Zhen