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

Owen DeLong <owen@delong.com> Fri, 01 November 2019 18:59 UTC

Return-Path: <owen@delong.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 3C4671200B6 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 11:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 MI2rkmLO4f8z for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 11:59:54 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BBCBA120073 for <v6ops@ietf.org>; Fri, 1 Nov 2019 11:59:40 -0700 (PDT)
Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1Iwa0H028064 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 11:58:37 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1Iwa0H028064
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572634718; bh=ijhGIFM9cXcjoO6bauv6VJ7kqsarLFoT0G9/BM8/lZo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=R17web3DdKVBTJ4a5HbHl+xGd6GvTfLe9BdgmqDbS/uw0tyBNCE2fOnEqTMzaBwx6 ZbI+5G236+BaH6Pts7pjTo058dlfcRL3ztw8wsnptCIpCsw0MGzX2myP3jSgynx+t7 ib7FG4b/TU8Zx7mZyaFQnGflegEsG6IJVdxVmOY8=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20191101.191951.54041693.sthaug@nethelp.no>
Date: Fri, 1 Nov 2019 11:58:35 -0700
Cc: otroan@employees.org, v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6302CC3A-A26E-42B4-A455-D031ACC9D047@delong.com>
References: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <20191101.124409.30333597.sthaug@nethelp.no> <BEC713D0-361F-4489-9D57-29781BC70B67@delong.com> <20191101.191951.54041693.sthaug@nethelp.no>
To: sthaug@nethelp.no
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 11:58:38 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DAg2UTx9aTp4TvfW7GKAKewhzIU>
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:59:56 -0000


> On Nov 1, 2019, at 11:19 AM, sthaug@nethelp.no wrote:
> 
>>> 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.

Well, consider this optional (but less convenient) approach:

Customers moving to other routers are generally groups of customers. (e.g. CMTS splits, etc.)

In such a case, creating a new prefix for that class of customers and advertising it to them several days in advance as well as shortening the preferred and valid lifetimes on the old prefix at that same time could be done.

The new prefix would then move with the customers.

This is inconvenient, but achievable. If you then wanted to migrate the customers to the prefix associated with the new router instead of making the transition prefix permanent, you could use short preferred and valid lifetimes on the transition prefix and start expiring it once the move was completed and the new permanent prefix had been advertised to them.

> 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.

Sure.

> 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.

See above.

Owen