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

[Rahul Jadhav <[e-mail]>]

Thank you Mohit for the review.
We have incorporated most of your comments and updated the ID.
Please find my responses inline.

Best,
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.

[RJ] Have added text in the first section to describe the networks under
consideration.

>
> - 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.

[RJ] Have searched through the document and ensured that all acronyms are
mentioned in the terminology section.

>
> - 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)

[RJ] Have updated the abstract text as per the suggestion. It seems better
than what we had.

>
> - 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".

[RJ] There was a description in Introduction section. I have reworded to
make it clear.

>
> - 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.

[RJ] There is no way we can come up with a typical neighbor cache size. It
varies (as you noted) depending upon platform, deployment.

>
> - 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.

[RJ] We ll add these numbers once the implementation is ready. Have raised
an issue <https://github.com/lwig-wg/lowpan-neighbor-mgmt-policy/issues/1>
on this draft's github page.

>
> - 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.

[RJ] Have updated "New" with "PaC". Yes the new node is the PaC. But it may
be better that we use general terms in the future so that the draft doesn't
become tightly coupled with the PANA method. We ll discuss this amongst and
then possibly update again. Have also raised an issue
<https://github.com/lwig-wg/lowpan-neighbor-mgmt-policy/issues/2> about
this on the github repo.

>
> - 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?

[RJ] I think mentioning this would further tightly couple the draft with
PANA. I tried checking the text but could not find text which says that
AUTHPROC is single message. But I have updated the Figure illustration to
show that AUTHPROC will be more that one 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?

[RJ] This logic is central to any routing protocol used. The draft cannot
talk about how it is done since it will be not in scope. RPL document
referenced in the draft talks about this procedure at length.

>
> - 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.

[RJ] What keys to be used depends upon the network access protocol. We do
not want to couple the draft tightly to PANA and hence I feel this is
better left out of scope.

>
> - 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.....

[RJ] Fixed and updated.

>
> - 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?

[RJ] Added a new paragraph for explaining this.

>
> - 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.

[RJ] There is no standard as of now for this signalling. The draft
establishes limitations for existing standards. We hope that in future (and
i already see some relevant discussions happening in roll-wg) other WG
which deals with routing protocol considers this as a requirement and
references this doc.

>
> - 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.

[RJ] There was a duplicate statement which is now removed.

>
> - 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
>