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

[Rahul Jadhav <[e-mail]>]

Thank you Mohit for the review.
This helps a lot. We ll update the draft and provide the detailed response soon.

Thanks,
Rahul
On Thu, 5 Jul 2018 at 15:11, Mohit Sethi <[e-mail]> wrote:
>
> 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
>