Re: A common problem with SLAAC in "renumbering" scenarios

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 31 January 2019 13:25 UTC

Return-Path: <prvs=193435552d=jordi.palet@consulintel.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D17129508; Thu, 31 Jan 2019 05:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 8qZLhaWEoOw4; Thu, 31 Jan 2019 05:24:58 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDCE128CB7; Thu, 31 Jan 2019 05:24:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1548941096; x=1549545896; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=49GRcBs2vPtN1xrKgJ0dX4FCixxdahV5wNzjHuRkodA=; b=b/xvXHCHCnr4h +i+nnR1/9M8O9C5Sgk4OvG5x5GkOWqU4YqvA936cSnbCbT8q2Ghcec2yzoTyOF/G v0B/3wvWfO3Gj0Rz5RDI4t2qR/2s4srn7WYWH7J+AW+j006RXFhquYhspcsH4p5V bCR7WkViZ80j7YDFgrEc4U/g4iuhus=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 31 Jan 2019 14:24:56 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 31 Jan 2019 14:24:55 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006135564.msg; Thu, 31 Jan 2019 14:24:55 +0100
X-MDRemoteIP: 2001:470:1f09:495:8509:9a05:69aa:b8d0
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Thu, 31 Jan 2019 14:24:55 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=193435552d=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.6.190114
Date: Thu, 31 Jan 2019 14:24:55 +0100
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Fernando Gont <fgont@si6networks.com>, Mikael Abrahamsson <swmike@swm.pp.se>
CC: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Message-ID: <F28DB13E-BCCF-4C19-A568-CEEA5056B691@consulintel.es>
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <A03364DB-B179-43AD-B509-21A429BD3A41@consulintel.es> <360e3a32-e039-cd26-3634-bf3f4c744cdf@si6networks.com>
In-Reply-To: <360e3a32-e039-cd26-3634-bf3f4c744cdf@si6networks.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/--c7AUI1sbLzcg6pgMgSKTfVIYA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 13:25:00 -0000

If the problem is no really about increasing the hardware cost, but proper engineering, as Sander suggested, to manage how to write info in the flash, and a CE, even if it has several power outages per day, can last for more than 5 years, I think is fine to go for MUST.

So, in the worst case a CE that get a power outage or whatever else, average 2 times a day, give, for a flash with 3.000 cycles, between 4-5 years CE lifetime, which I think in most of the case will be sufficient.

I'm sure that this can be improved not just with better flash, but with techniques to better manage the flash, file system, etc.

My concern is why many routers get corrupted when "saving" data in the flash if there is a power outage in the middle of the operation. I'm convinced it is again about proper engineering.

I guess this is the same problem for IoT devices when being update OTA, etc., so sure it is solved, but it is not being applied to Linux filesystems in routers?

Regards,
Jordi
 
 

-----Mensaje original-----
De: Fernando Gont <fgont@si6networks.com>
Fecha: jueves, 31 de enero de 2019, 13:18
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, Mikael Abrahamsson <swmike@swm.pp.se>
CC: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    On 31/1/19 08:57, JORDI PALET MARTINEZ wrote:
    > Exactly, this is the reason why 99% of the CEs don't save this data in the flash, because it is prone to creating troubles and bringing the CE to a "brick" state.
    > 
    > I've seen that several times, having for example statistics written in the internal router flash, easily will break the router, 
    
    Yes, this has been my point while discussing these issues while working
    on the I-D.
    
    
    > or at least needed a factory reset or something similar. Alternatively using a "good quality" USB stick to save this kind of data, avoids the problem 
    >(most of the time, because from time to time I've got also good USBs
    being damaged after some months of usage).
    
    Same here. I run a lot of Raspberry Pis for measurement purposes, and
    quite often the SD cards get damaged.
    
    
    > 
    > I think for example, RIPE Atlas get the same problem from time to time, so the USBs get wrong. Sometimes reformatting is sufficient, but not always.
    > 
    > Mandating that in low cost CEs will mean CEs are no longer "low cost", unless new "safe" opensource ways to keep the flash are available and can be included in new firmware releases.
    
    FWIW, i don't think mandating this is the way to go. We were not sure
    whether to make this a MUST (and then CPEs might claim whether they
    comply with this spec or not), a SHOULD, or have no normative language.
    
    I guess we could elaborate a bit more about the CPEs, discuss why it may
    not be feasible to do this, and s/MUST/SHOULD/. What do you think?
    
    Thanks!
    
    Cheers,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: fgont@si6networks.com
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    
    
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.