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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 03 May 2018 07:47 UTC

Return-Path: <pthubert@cisco.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 D539412D82F for <roll@ietfa.amsl.com>; Thu, 3 May 2018 00:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 u0IuvjFlyMge for <roll@ietfa.amsl.com>; Thu, 3 May 2018 00:47:42 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531B5126C26 for <roll@ietf.org>; Thu, 3 May 2018 00:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17176; q=dns/txt; s=iport; t=1525333662; x=1526543262; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vkDJI/ViELx2sjfZHFzv1570Pd3jvEQdNCSMqN3c1/E=; b=DWe5wpuv/QDvIoC8fJ/HpU6HGabXkqK8a8CUFcDDhP2cBTEIOqxp+r2X xvCnp6/zVL1sbObjM5qCGK3jZYDeMufGf24UILtbo5v/2GSfxP22kG9f5 guaeS3UwpukgIBXXBSp3nAR9e7ODz1rxsYX7esqCIoYkdjTQ7p/OlA5fO U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DFAABMvepa/5ldJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYJNdmEXYygKg2OIAoxwgXSBD44qhHCBeAsYAQqBVIJ1AhqCTSE0GAECAQEBAQEBAmwcDIUoAQEBAQMBASEKQRsCAQgRBAEBKAMCAgIlCxQJCAIEEwiEI2QPqEOCHIhIgkKIG4FUP4EPgRCBe4MRAQECgUJSgkqCVAKYFwgCjkKMYZAaAhETAYEkARw4gVJwFTuCQwmFH4VohT5vj1GBGAEB
X-IronPort-AV: E=Sophos;i="5.49,357,1520899200"; d="scan'208,217";a="386835314"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 07:47:41 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w437lfHl007121 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 3 May 2018 07:47:41 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 02:47:40 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Thu, 3 May 2018 02:47:40 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling
Thread-Index: AQHTwciVQsGzK7ypcECrCDATupfKUqQOrAGAgA7z2gCAAB9OgIAAIbNA
Date: Thu, 03 May 2018 07:47:21 +0000
Deferred-Delivery: Thu, 3 May 2018 07:46:50 +0000
Message-ID: <0522ea86b4234490bdd56b1428db0762@XCH-RCD-001.cisco.com>
References: <8EC2893F-731B-439D-86FE-984505349D8D@tzi.org> <982B626E107E334DBE601D979F31785C5DBCD1B4@BLREML503-MBS.china.huawei.com> <22477.1525301358@localhost> <CAO0Djp1sCSFJSZSbVNL+RLgV2FrjwZQrJ6p-9ExndMbQqua-QA@mail.gmail.com>
In-Reply-To: <CAO0Djp1sCSFJSZSbVNL+RLgV2FrjwZQrJ6p-9ExndMbQqua-QA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.216.15]
Content-Type: multipart/alternative; boundary="_000_0522ea86b4234490bdd56b1428db0762XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/s3MIXyxgvmfB2BVG83b9ivKjM2I>
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: Thu, 03 May 2018 07:47:45 -0000

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<mailto:mcr%2Bietf@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<mailto:mcr@sandelman.ca>  http://www.sandelman.ca/        |   ruby on rails    [


_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll