[Lwip] Early chair review of Neighbor Management Policy for 6LoWPAN

Mohit Sethi <mohit.m.sethi@ericsson.com> Thu, 05 July 2018 09:41 UTC

Return-Path: <mohit.m.sethi@ericsson.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 61F69130E0C for <lwip@ietfa.amsl.com>; Thu, 5 Jul 2018 02:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o2RYTYZRO2Mb for <lwip@ietfa.amsl.com>; Thu, 5 Jul 2018 02:41:40 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net []) (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 954F4130E3D for <lwip@ietf.org>; Thu, 5 Jul 2018 02:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530783693; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tSZrcr3uBAmxHZyeuHOYq2xNKdZj24a72P9aEljCmuY=; b=DwKcpYY8qp+AxkmDUxC6GgmwJOAPwNWVo10NLnbiBkVsG6oyFbjtdd1cFqYxqbZ3 /NhB+XiALW7JRx2esw+VNLT1ltYzLHWyiGbDhrjIGUFglwRwV4wPXgxhvjlOJk7R 6Mt+HmAKNP07HnwPMvgk5uklDg7MhMFD6IC65P5B/f4=;
X-AuditID: c1b4fb25-e23ff70000006310-07-5b3de7cdeb99
Received: from ESESSMB504.ericsson.se (Unknown_Domain []) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.58.25360.DC7ED3B5; Thu, 5 Jul 2018 11:41:33 +0200 (CEST)
Received: from ESESSMB501.ericsson.se ( by ESESSMB504.ericsson.se ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 5 Jul 2018 11:41:32 +0200
Received: from nomadiclab.fi.eu.ericsson.se ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Thu, 5 Jul 2018 11:41:32 +0200
Received: from nomadiclab.fi.eu.ericsson.se (localhost []) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id B0E4D4819BB; Thu, 5 Jul 2018 12:41:32 +0300 (EEST)
Received: from [] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 6CFE64813E3; Thu, 5 Jul 2018 12:41:32 +0300 (EEST)
To: "lwip@ietf.org" <lwip@ietf.org>, draft-ietf-lwig-nbr-mgmt-policy@ietf.org
From: Mohit Sethi <mohit.m.sethi@ericsson.com>
Message-ID: <b3c76adb-844c-1fcc-baf9-779d360ba89a@ericsson.com>
Date: Thu, 05 Jul 2018 12:41:32 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AV-Checked: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM2J7le7Z57bRBnO/Mlk07tS3mLdP2IHJ Y8mSn0wBjFFcNimpOZllqUX6dglcGXNaepkLZmpVbJ72m72BsUmpi5GTQ0LAROLm8u9sXYxc HEICRxklHj55xwrhfGWUmN8wgxnCucAosfP9Z6jMZkaJyyu+MEI4CxklJncfYgYZJiIQKLHv w012EJtNQE+i89xxoDgHh7CAq8ScgywgYV4Be4lN68+xgIRZBFQkOqbJgYRFBSIkmuatYYco EZQ4OfMJWDmzgIXEzPnnGSFseYntb+cwQ9jiEreezGeCeEFZYkHLIrAaIQF1ia0dBxgnMArN QjJqFpJRs5CMmoVk1AJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgUF9cMtv1R2Ml984 HmIU4GBU4uEtvGQbLcSaWFZcmXuIUYKDWUmE1+gaUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv Q/PNUUIC6YklqdmpqQWpRTBZJg5OqQZGp6INa2aVvNqTU2unelVzU51pqMrf26klTI2tn81v CJRNCVzBz225O+ngXP1n5b01zqIts1oCj13N0l2SOy/mrs+jCz9e8zc0PLrV45F3eXLxH6tv vZLNUk85EjmYHqtmLk2YvDErYP3N7oyOt6naQSoRqc+FGQ/W+fmIKzY/6/278gLfbHElluKM REMt5qLiRAAFphD+ZgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/5fxj4p4gM3KmLgPm48Ao6SPO_BA>
Subject: [Lwip] Early chair review of Neighbor Management Policy for 6LoWPAN
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 09:41:42 -0000

Hi Rahul and co-authors,

Here is my early chair review of the Neighbor Management Policy draft. I 
believe that more work is needed to improve the document going forward.

- The document currently needs more text on what kind of networks is the 
suggested neighbor management policy suitable for. Does it work equally 
well in networks with static nodes and networks with mobile nodes? What 
kind of resource-constrained devices are considered in this document? 
For example, what kind of processor, memory and energy-resources are 
available on devices considered in this document.

- The document uses so many acronyms without expanding them even once. 
For example NDP/DAO/NS/NA are never expanded or explained. It would make 
sense to add these to the terminology section 1.1. While it is 
reasonable to assume that the reader has some background in 6lowpan 
networks, it would not hurt to explain what these messages are used for. 
Please also state in the Introduction section that the reader is assumed 
to be familiar with 6lo and RPL networks.

- The abstract could be re-phrased and expanded. Here is a suggestion: 
This document describes the problems associated with neighbor cache 
management in multihop networks involving resource-constrained devices. 
Thereafter, it also presents a sample neighbor management policy that 
allows efficient cache management in multihop networks of 
resource-constrained devices. (Possible add info on what kind of 
networks is this neighbor management policy suitable for)

- The document defines node density as maximum number of devices 
connected on a single hop? This needs to be more precise. Would it be 
right to say: node density is the "maximum number of nodes that are 
reachable with a single hop from any given node in the network".

- What is typical neighbor cache size in devices being considered. Is it 
4 nodes/8 nodes? For an average reader who hasn't deployed a 6lo 
network, it is hard to judge. I guess it would depend on the type of 
platform and available resources on the device.

- The document says that FCFS (First Come First Server) and LRU (Least 
Recently Used) don't always result in efficient cache entry management. 
However, they are also easy to implement in practice. Any smarter 
management policy would likely result in more lines of code? Since you 
have implementation, it would be good to document some experience from 
that here.

- It is currently hard to understand Figure 2 and 3. It refers to "New". 
Perhaps rename it to "New node"/"New joining node". Isn't the new node 
that is joining an existing network also the PaC (PANA Client). Perhaps 
it would help to say that in the text. What is the message PCI in figure 
2. It is not explained anywhere in text.

- The neighbor management policy presented in this document is 
independent from the credentials used for authentication over PANA. 
However, it would still help the reader if you mention the credentials 
used in your deployment and how many round-trips are necessary for the 
AUTHPROC shown in Figure 2 to complete. Currently, it looks like that 
the AUTHPROC is a single message?

- The current text says "The node selects one or more of its neighboring 
peer as its preferred parent based on the DIO received from these 
peers". What logic does it use when picking one peer over the others?

- The current text says "The child node may send a secure unicast NS 
with ARO option containing its global address to be registered on the 
parent node." Perhaps it would help to give more context here. What keys 
are used for the secured unicast NS message. Did they result from the 
initial authentication over PANA.

- The section on NCE Deletion is easy to understand and makes sense. 
Thanks for that.

- In Section 3, the text says "As shown in the figure, the neighbor 
cache is partitioned into different entry types.". Please use the figure 
label, As shown in figure 5, the neighbor cache.....

- There is no explanation for the counters in Table 1: 
MAX_OTHER_NCE_NUM. Is it the maximum cache entries that a node can store 
or the cache entries currently available?

- The proactive approach wherein the parent node signals its 
resource-availability in DIO message. How does this signaling work? 
There is no information in the draft? Does it use the flags or DIO 
options such as "0x03 Routing Information" specified in RFC 6550. 
Remember, the document is informational, so we should not be 
standardizing new message formats here.

- The security considerations sections needs some organization. The text 
"Only a subset of entries are reserved for un-authenticated nodes" is 
repeated. Isn't there an inherent assumption that after authentication, 
all the nodes are expected to behave as honest. Otherwise misbehaving 
nodes could always advertise that they don't have any cache entries 
remaining. If so, it might be worth writing some text around this.

- There were some grammar issues but we can fix them after the issues I 
raised above are addressed. Overall, the document provides useful 
guidance but more work is needed to improve its readability and more 
precise text is needed for a developer to implement neighbor management 
policy presented here.