Subject: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00

From: Zhen Cao <[email-masked]>
Date: Fri, 14 Jul 2017 08:48:30 +0800

Dear Rahul and co-authors,

Many thanks for the hard work in contributing this draft to the lwig
wg. (I am copying roll and 6lo since some discussion will be quite
relevant)

As I go through the document, I found essentially there are three
types of different policies discussed:
a. Trivial neighbor management (FCFS/LRU)
b. advanced neighbor management (proactive and reactive)
c. proposed ‘reservation based’ approach

Logically I understand the shortcomings of the trivial approach,
however in practice, how much this many impact the network stability
is not convincing enough yet. (what’s the possible size of node
density/mobility may be impacted? ).

The discussion of reactive and proactive ways of managing the neighbor
cache entries is helpful. The discussion about the proactive approach
in Sec.2.5.2 quoted below has some pending relationship with RPL (if
this is an acknowledged problem by ROLL WG).  Anyway this is something
we need to discuss with the ROLL wg to see if this a need feature.

    Currently there is no standard way of signaling such neighbor cache
   space availability information.  RPL's DIO messages carry metric
   information and can be augmented with neighbor cache space as an
   additional metric.

For the proposed reservation based approach,  I think this is quite a
practical recommendation (if my concern about a. will be relaxed).

I also found the Contiki RPL implementation has recently used a
similar way in its rpl-nbr-policy. Shall we link the draft to the open
source community to see if the document has provided additional help
to the implementation? (or that’s already done given coauthors Simon
and Joakim are both active contributors of Contiki)?

Many thanks for discussion.

Cheers,
Zhen

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 14 Jul 2017 15:42:42 +0530

Thank you Zhen for the review and comments...
Please find my responses inline ...

cheers,
Rahul

> density/mobility may be impacted? ).

[RJ]:
a) Existing open sources (such as RioT and Contiki) implement trivial nbr
mgmt policies ... for e.g. riot uses FCFS, and Contiki previously used LRU
(but Contiki in the past some time has upgraded and put out a new
implementation inline to what we have proposed) ... Through this draft we
want to highlight scalability issues with such trivial policies ...
Scalability issues arise especially in case of dense networks with nodes
having limited memory for neighbor cache ...
b) Currently the draft talks only about reactive "reservation" based
policy, since our aim to begin with, is to check what best can be achieved
without making any signaling changes ... But clearly this has limitations
which also are highlighted by the draft and we have put forth  the
reasoning for using proactive signaling ...
In my deployment scenario, we could never stabilize the network unless we
implemented such a policy ... My deployment is a typical metering scenario
and the node density is not in control (network size is, but not the node
density) ... In some areas the node density is high (100 nodes on the same
hop) .. and the nbr cache is limited to say 25 entries ... in such a case
NCEs undergo a churn which results in routing adjacencies never stabilizing
...  Specifically, the draft will help implementers in cases "where the
node density is higher than nbr cache size".
Another way to look at that is, even if a node can afford to store a bigger
nbr cache, it is inefficient use of dynamic memory. Proposed policy can be
used to reduce the nbr cache size and thus optimize mem usage!

>    information and can be augmented with neighbor cache space as an

[RJ] As I mentioned before, the current approach is a reactive
"reservation" based approach ... It improves network stability but still
has its own limitations (highlighted in the draft). These limitations could
be worked out with some changes to existing protocols (such as RPL). As
part of LWIG draft we have set forth only requirements towards such changes.

> and Joakim are both active contributors of Contiki)?

[RJ] The Contiki rpl-nbr-policy implementation is already in line with the
proposed draft. We already have the Contiki implementers as co-authors of
this draft and their inputs have shaped the draft quite a lot.

> Many thanks for discussion.

Thank You!

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 14 Jul 2017 13:47:37 -0700

Hi Zhen and Rahul:

Thanks for looping 6lo in the lwig-nbr-mgmt-policy draft discussions.

6lo WG, please review draft-jadhav-lwig-nbr-mgmt-policy  document for any
impact in 6lowpan-nd. Also it is a good place to discuss if anyone else is
aware of any alternative neighbor management methods.
Also please provide feedback for improving neighbor management from 6lo
perspective.

-Samita

On Thu, Jul 13, 2017 at 5:48 PM, Zhen Cao <[email-masked]> wrote:

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Simon Duquennoy <[email-masked]>
Date: Sat, 15 Jul 2017 09:35:46 +0200

> and Joakim are both active contributors of Contiki)?

The document has not influenced the implementation yet -- so far it is
the other way around: the implementation came first and we put some of
our experience into the draft. As the draft evolves, we will indeed
keep Contiki aligned.
/Simon