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

Hi
I agree with Rahul. I want to add few more points here.
1- If a rebooted router has to chose a higher value how it will decide
which one to choose so that it can recover it's reouting table. Choosing
higher value still has chance of failure in recovery
2- If wait for auto recovery we are not sure how long it will take
.Currently we have only one option
a- Node sends a refresh DAO
Till that time all the nodes having downward path via the rebooted node
won't be reachable unless until they switch the pp.

RFC 6550 must consider the reboot case in general for storing mode. In non
storing mode we doesn't have such issue
Thanks
Rabi

On Fri 4 May, 2018, 6:42 AM Rahul Jadhav, <rahul.ietf@gmail.com> wrote:

> Thanks Pascal..
>
> Yes, Rebooting within the lollipop is the problem that i have described in
> the draft... It is not possible to completely avoid that scenario if
> persistent storage is not used... The problem is, the nodes cannot recover
> (or they recover very very late) if they get into this scenario. Choosing a
> higher increment factor may reduces the probability but cannot eliminate
> it.
>
> There is no text in 6550 which says dtsn should be maintained in
> persistent storage. But  then 6550 does not talk about handling reboots in
> general.
>
>
> On Thu, 3 May 2018 at 1:47 PM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
>> Hello Rahul :
>>
>>
>>
>> Rebooting within the lollipop is really bad luck; the whole point of the
>> lollipop is to detect intermittent reboots and not force to store the
>> sequence in flash.
>>
>> Note that you do not need to start from default 240, you may restart
>> from, say, 250. Or you may increase the sequence by more than one. All that
>> to stay less in the straight piece of the lollipop.
>>
>> All in all, I do not think that the DTSN has to be stored in persistent
>> memory. Is there text that I do not remember that would indicate so?
>>
>>
>>
>> Take care,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Roll <roll-bounces@ietf.org> *On Behalf Of *Rahul Jadhav
>> *Sent:* jeudi 3 mai 2018 02:41
>>
>>
>> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
>>
>> *Subject:* Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1:
>> Wear leveling
>>
>>
>>
>>
>>
>> On Thu, 3 May 2018 at 4:49 AM, Michael Richardson <mcr+ietf@sandelman.ca>
>> wrote:
>>
>>
>> I think that I don't remember why a node needs to save the DTSN across
>> reboots.
>>
>>
>>
>> [RJ] dtsn is for triggering the dao from downstream nodes. If the child
>> nodes do not see a new dtsn from the parent then they won't send dao and
>> thus routing state for the (sub)childs won't be added for any child nodes
>>  on the restarted 6lr.
>>
>> An example,.... the 6lr dtsn was 245 when it got restarted and on restart
>> it sets its dtsn to default 240... Now the child nodes (they have stored
>> 245) don't respond to the DIOs because they see an older dtsn(value 240).
>> Thus no DAOs are triggered causing no routing state to be installed on
>> restarted 6lr for the (sub)childs resulting in unavailability of downstream
>> path to the subdodag rooted at that 6lr.
>>
>>
>>
>> (I hate being away from code for so long that I forget these
>> things, I wish I could spend more time writing code)
>>
>> I think that in storing mode, that a node can set it's DTSN to whatever
>> value
>> is sees in the parents' DIO, and increment from there.
>>
>>
>>
>> [RJ] i do not think that a node infers or should infer its dtsn from
>> parents dio... Per section 7.2 of 6550, the default dtsn should be set to
>> 240 (assuming sequence window of 16).
>>
>>
>>
>>
>>
>> I'm confused as to why any node other than the root needs it to be stored
>> in
>> flash?   I do not think it should be required to store info in flash.
>>
>>
>>
>> [RJ] this is true only for non storing mop but for storing mop the 6lrs
>> needs to remember for the reason mentioned above.
>>
>>
>> (OSPF doesn't require this...)
>> This also makes it hard to replace hardware in the field, or do firmware
>> updates if we have to keep this kind of data around.
>>
>>
>>
>> [RJ]true
>>
>>
>>
>> Can we expand 7.1 to better explain what is written, and why?
>>
>>
>>
>> [RJ] sure will do.
>>
>>
>>
>>
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh
>> networks [
>> ]   Michael Richardson, Sandelman Software Works        | network
>> architect  [
>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>> rails    [
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>