Subject: [6lo] lwig presentation on neighbor cache entries

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 12:08:30 +0900

A very interesting presentation was done by Rahul Jahwad today at LWIG.
  https://www.ietf.org/proceedings/97/slides/slides-97-lwig-neighbor-management-policy-for-6lowpan-01.pdf

I think that a document will ensue.  Probably it should stay in lwig, but I
think that ROLL could contribute many comments about this, and it would be
worth having on the agenda for IETF98.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [ 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: peter van der Stok <[email-masked]>
Date: Thu, 17 Nov 2016 06:11:06 +0100

I also enjoyed the talk.
My opinion is that it should stay in lwig because it is less protocol 
and more storage optimization oriented.
But yes, I think it is certainly interesting for roll to learn about 
this work.

Peter

Michael Richardson schreef op 2016-11-17 04:08:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 17 Nov 2016 07:56:27 +0100

+1 

This is a very important topic for scalability of 6lowpan and RPL networks (we have worked on tuning our
neighbor policy implementation in Contiki at Yanzi during the last few years).

Best Regards,
— Joakim Eriksson, SICS

> On 17 Nov 2016, at 06:11, peter van der Stok <[email-masked]> wrote:
> 
> I also enjoyed the talk.
> My opinion is that it should stay in lwig because it is less protocol and more storage optimization oriented.
> But yes, I think it is certainly interesting for roll to learn about this work.
> 
> Peter
>

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 17 Nov 2016 16:21:33 +0900

Great feedback! Thank you all.
We will asap post the draft to the lwig WG.

Thanks Joakim for letting know about contiki advancements. I ll review and
understand the latest contiki code you mentioned (I assume the code is
already part of contiki master git).

Thanks,
Rahul

On 17 Nov 2016 3:56 p.m., "Joakim Eriksson" <[email-masked]> wrote:

> >> https://www.ietf.org/proceedings/97/slides/slides-
> 97-lwig-neighbor-management-policy-for-6lowpan-01.pdf

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 17 Nov 2016 10:25:06 +0100

> On 17 Nov 2016, at 08:21, Rahul Jadhav <[email-masked]> wrote:
> 
> Thanks Joakim for letting know about contiki advancements. I ll review and understand the latest contiki code you mentioned (I assume the code is already part of contiki master git).
> 
Yes, there is parts of this in upstream Contiki. Very similar to what we use at Yanzi where we scale storing mode RPL with 20 routes and 10 neighbors / node to
quite much larger networks than what was possible before. Without a policy the table with either always add new neighbors and never get stability and statistics
on neighbors or end upp totally locked with the same neighbors in the table forever and no ability to switch to better RPL parents.

Best regards,
— Joakim Eriksson, SICS

> Thanks,
> Rahul
> 
> 
> On 17 Nov 2016 3:56 p.m., "Joakim Eriksson" <[email-masked] <mailto:[email-masked]>> wrote:
> +1
> 
> > On 17 Nov 2016, at 06:11, peter van der Stok <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > I also enjoyed the talk.
> >> https://www.ietf.org/proceedings/97/slides/slides-97-lwig-neighbor-management-policy-for-6lowpan-01.pdf <https://www.ietf.org/proceedings/97/slides/slides-97-lwig-neighbor-management-policy-for-6lowpan-01.pdf>
> >> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 17 Nov 2016 14:26:44 +0100

It's an interesting presentation! I watched the recoded presentation
thanks to meetecho.

I encountered a similar situation, where a kind of neighbor management
policy was needed, when I was coding Address Registration Option (ARO)
of 6LoWPAN-ND for my implementation of RPL Non-Storing mode.

ARO has a status value used in NA to tell a failure of neighbor cache
insertion, "Neighbor Cache Full". But, there is little chance to
communicate this status because a neighbor cache for sending an NA is
expected to fail to be inserted in a neighbor cache full situation. I
thought it would be nice to have neighbor cache memory reserved for
error notification.

For the PANA case in the presentation, I have a minor comment. A PRE
cannot generate a PAR for its purpose, which is associated with an
ongoing session between a PAA and a PaC. That is, a PRE cannot perform
the graceful rejection you mentioned. The situation could be worse
than you thought; the PAA or PaC has no choice but to retransmit a
PANA message until it gives up...

Best,
Yatch

On 2016/11/17 10:25, Joakim Eriksson wrote:
>
>> On 17 Nov 2016, at 08:21, Rahul Jadhav <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     >> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>