IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

Fernando Gont <fgont@si6networks.com> Tue, 19 May 2020 16:08 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2902D3A0A73 for <v6ops@ietfa.amsl.com>; Tue, 19 May 2020 09:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 J8eWmXgUKFK2 for <v6ops@ietfa.amsl.com>; Tue, 19 May 2020 09:08:39 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F075E3A0A6C for <v6ops@ietf.org>; Tue, 19 May 2020 09:08:38 -0700 (PDT)
Received: from [IPv6:2800:810:464:11f:ddb1:8740:ceee:11b0] (unknown [IPv6:2800:810:464:11f:ddb1:8740:ceee:11b0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E79C428380C; Tue, 19 May 2020 16:08:33 +0000 (UTC)
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
References: <m1jb1gz-0000MZC@stereo.hq.phicoh.net>
From: Fernando Gont <fgont@si6networks.com>
Cc: draft-ietf-v6ops-cpe-slaac-renum@tools.ietf.org, Fernando Gont <fernando.gont@gmail.com>
Message-ID: <8aa3102e-22b1-60ed-2d99-838f3fdf1736@si6networks.com>
Date: Tue, 19 May 2020 12:35:09 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <m1jb1gz-0000MZC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bNvdZWMxupUAZwCXITloNzEEYOY>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2020 16:08:41 -0000

On 19/5/20 09:49, Philip Homburg wrote:
>> I'm following up on
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum
>> https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum
>>   "Improving the Reaction of Customer Edge Routers to Renumbering =
>> Events",
>>   Fernando Gont, Jan Zorz, Richard Patterson, 2020-05-18
> 
> In my opinion, L-15 needs to be a SHOULD NOT or otherwise have space
> for the operator of the router to override this behavior. I have provided
> a use case for that in the past.

These are requirements for the CPE, not for the operator. i.e., what the 
CPE is expected to do without human intervention. It would seem to me 
that, in that light the current "MUST" conveys the meaning of "if you 
don't follow this, you are breaking things".  A device that employs 
local addresses for more than the leased time may potentially employ 
addresses for longer than valid.

Am I missing something?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email