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 protected]
<mailto:[email protected]>> wrote:
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).
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 protected]
<mailto:[email protected]>> wrote:
+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 protected]
<mailto:[email protected]>> 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
>
> Michael Richardson schreef op 2016-11-17 04:08:
>> 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
<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 protected] <mailto:[email protected]>
http://www.sandelman.ca/ | ruby on rails [
>> _______________________________________________
>> Roll mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll>
>
> _______________________________________________
> Roll mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll>
_______________________________________________
Roll mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll>
_______________________________________________
Roll mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
