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
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
