Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    mcr> So I think that the errata against 6550 is that it should be a lollipop
    mcr> counter, and I think that this solves the reboot problem, and eliminates
    mcr> having to write it to flash.

    rj> [RJ] this still does not solve the reboot issue... The text in the
    rj> draft actually considers dtsn to be a lollipop counter and explains
    rj> the problem when rebooting within the sequence window of lollipop
    rj> counter. Please refer to section 7.2 of the draft for example. Errata
    rj> is nonetheless needed for dtsn to be a lollipop counter.

    pt> Well, yes, but that’s true for any of the sequence counters, not just
    pt> DTSN, and was not perceived as an “issue”. 
    pt> The lollipop by design detects one reboot during the straight
    pt> part. More will cause a delay. There are ways to avoid that like
    pt> persistent memory or alleviate it like making the straight part
    pt> shorted on reliable links.  I’m not sure there’s much to add to that
    pt> or to fix, is there?

Pascal, I feel that Rahul has some point that we've missed.

>   behalf of node A).  As per section 7.2. of [RFC6550], when node B
>   receives this packet it will consider the information to be old
>   (since 240 < 250).

>   Based on this figure, there is dead zone (240 to 0) in which if A
>   operates after reboot then the seqcnt will always be considered
>   smaller.  Thus node A needs to maintain the seqcnt in persistent
>   storage and reuse this on reboot.

My instinct is there are one of two bugs (maybe both documentation and code):
   a) node A SHOULD rapidly move from 240 to 0, that the numbers from 240 to
      0 should be considered "setup", and node A was wrong to advance only
      to 250, and not as soon as it felt "stable", move to 0.

   b) that node B, should recognize that during the 240 to 0 stage, that
      the counters should not be compared.  Anything < 0 is "setup", and is
      always "new", but that 251 > 250 require immediate action.

I found it unusual that the lollipop should require 16 values in the stem, I
think that one ('0') would have worked, but maybe there was some reason to
prefer 16.

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