Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X"

sthaug@nethelp.no Fri, 01 November 2019 18:19 UTC

Return-Path: <sthaug@nethelp.no>
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 6C1A71209BA for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 11:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 0XuPaA9LX1ZZ for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 11:19:53 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26912006F for <v6ops@ietf.org>; Fri, 1 Nov 2019 11:19:53 -0700 (PDT)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A69A4E6079; Fri, 1 Nov 2019 19:19:51 +0100 (CET)
Date: Fri, 01 Nov 2019 19:19:51 +0100 (CET)
Message-Id: <20191101.191951.54041693.sthaug@nethelp.no>
To: owen@delong.com
Cc: otroan@employees.org, v6ops@ietf.org
From: sthaug@nethelp.no
In-Reply-To: <BEC713D0-361F-4489-9D57-29781BC70B67@delong.com>
References: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> <BEC713D0-361F-4489-9D57-29781BC70B67@delong.com>
X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uJdLRmTkW3-OBxreo4iZiUwXdEE>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X"
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: Fri, 01 Nov 2019 18:19:56 -0000

>> So - TL;DR: We don't do "flash renumbering" for fun, on the other
>> hand we also don't strictly follow RFC 4192.
> 
> Put another way, from the customer perspective…
> 
> “We don’t do flash renumbering for fun, but we do value our convenience
> above the impact this has on our customers and therefore when we find it
> convenient, we do flash renumber customers as needed.”

Not sure if you understood my example:

1. DHCP customer needs to be moved to a different router.
2. Because customer will be moved to a different router, customer
*will* be down for some time.
3. Moving the customer is done as a planned activity, at night, with
alert to the customer several days in advance, in order to minimize
customer inconvenience.

Also, not directly related to the above: Business customers can also
choose static addresses. If such a customer needs to be moved to a
new router, addresses are also moved.

I fail to see how this can be described as "we value our convenience
above the impact this has on our customers". But I'll stop here.

Steinar Haug, AS2116