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
>