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

[Mohit Sethi <[e-mail]>]

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_ROUTING_PARENT_NCE_NUM, MAX_ROUTING_CHILD_NCE_NUM, 
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.

--Mohit