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

Rahul Jadhav <rahul.ietf@gmail.com> Fri, 04 May 2018 01:12 UTC

Return-Path: <rahul.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBDE126DED for <roll@ietfa.amsl.com>; Thu, 3 May 2018 18:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT6AJdGzoCkE for <roll@ietfa.amsl.com>; Thu, 3 May 2018 18:12:32 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF02126DFB for <roll@ietf.org>; Thu, 3 May 2018 18:12:31 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id v17so3757085uak.6 for <roll@ietf.org>; Thu, 03 May 2018 18:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7wtcHbwt/B0YqY7/kappk0J67mRaEGbUl4RvyTxvMQk=; b=bLxWkjtQwjFHEE94ZELOuHAEnA9CN5p/QZ9se6qFcG45kJiA4BydA6yrVLCVViJv5Q 8KNJl/v4PYC1RSTOuz+5BeK4zyRDP/En2t0oVNcncZLzS1BfecKStDkr+5zuDVbReKFH rR5+xdjYmWRzMPjppotCp6MI4zygCom3hfm4iyw5cLXzLsHCL21O7JLw8sdJ+7gZ8BMj 9CC9KQ+83oehxzYEUf9uyWurWQwIpyn3BBn3y5RQpvWDi4mtIk9Wk8W9LtoMu/MWLHsh DyKkYYDiuRW/zEudx1KI40uhOU1sPCy/utkSF90Nn9nebyC53kc7ios6n/WBOIMWSFwp RkhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7wtcHbwt/B0YqY7/kappk0J67mRaEGbUl4RvyTxvMQk=; b=WgfRCKDz6BenGXb1prQO/gIEPPuSF9VzVUSr2N+aU6P45wZx8BhkrsrxqEqVw/Nl6N cZmLDLQkjskJ2CP2YLimSChp+xQCTBbonFLURRxA1mnSgYph9Du4KgcJMq53jYWZVMwf X8umnw9b8pEZl8OmNK1hQrXTL7wj7zUkChusbwFrBpktjnixVc9Z0WgtZZZ0zSdcMdSd rzFFT5oM/Ar3W5NdJ6mc3JZi0VGyQ70y1uWIGRFrC+aWUtM2F5Y7c/31Bu/N7UG6Ihcf wA7GZjuQRfxfK9oeBO1LbBjTMBTcCfsU5quc1n2pwvNveG3rBUjNjClVavQX66Zg+Bzm zZFA==
X-Gm-Message-State: ALQs6tA9sJPNT4Vs/aWziR+wwt7+3x+SUskJirtBJxbFGDxLIac44A08 6RIXydYmPkHAtw/bWmgLJg/hlEzFB/VHapUso08=
X-Google-Smtp-Source: AB8JxZr4gVTFap65H8FaVub49OvhB/K0kVV4RoCrRIRxRpddlO3sHHiFn+Y/3rO9DJlnj469jk58iSbtjkU0xkUzAfc=
X-Received: by 10.176.6.170 with SMTP id g39mr22934872uag.82.1525396350365; Thu, 03 May 2018 18:12:30 -0700 (PDT)
MIME-Version: 1.0
References: <8EC2893F-731B-439D-86FE-984505349D8D@tzi.org> <982B626E107E334DBE601D979F31785C5DBCD1B4@BLREML503-MBS.china.huawei.com> <22477.1525301358@localhost> <CAO0Djp1sCSFJSZSbVNL+RLgV2FrjwZQrJ6p-9ExndMbQqua-QA@mail.gmail.com> <0522ea86b4234490bdd56b1428db0762@XCH-RCD-001.cisco.com>
In-Reply-To: <0522ea86b4234490bdd56b1428db0762@XCH-RCD-001.cisco.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Fri, 04 May 2018 01:12:19 +0000
Message-ID: <CAO0Djp2BBbuX33NYEMe0sZGeDe6vk=eN5GuLDvh+RE__1QzPmg@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0458a89af432056b5703ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/VKz_2zDrvMtOQFmqWzqOo-WLxjQ>
Subject: Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2018 01:12:34 -0000

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
>