Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

Ted Lemon <mellon@fugue.com> Mon, 11 November 2019 17:11 UTC

Return-Path: <mellon@fugue.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 71AF8120A4B for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 09:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 6txs4HzfuVbc for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 09:11:19 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3DA120A44 for <v6ops@ietf.org>; Mon, 11 Nov 2019 09:11:19 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id t20so16404567qtn.9 for <v6ops@ietf.org>; Mon, 11 Nov 2019 09:11:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=ys2Mo6kUnIUxNVp7UHtUSeA4QkS5P5H46rT2EdHuL7s=; b=KdrCtH2Mgu+bXd1zsAG2iIAuvizD1YoVeuj2S2qXlAlqbLxv+PShqoSI2UVxyq0SpE qFLjXnK7zDNBb3+MLKkdDuy8o8FHTriEnPC41Wxt9KQL/FepKisRqRoUuZ+nlYX5X0Rz NlB6IgG8SCXcjx+DIRk3hQ8SLMR8zmw0+SC1NoLxQN8Iq2QKb0BrhmhCE0JPf4yHw2ew tf6TxJmzR4+jBYKThbFxGfSVvAaZFLdVL3QPr9XFFfoobkezeNIF8cdr04bU+7l6ccuv QVWDBn3IB8iPt6wNcmSTdr40coZ89E961TJ0jEXNZvIDVqlXp0jwn/m7ZQF1aOP50Z22 1C8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=ys2Mo6kUnIUxNVp7UHtUSeA4QkS5P5H46rT2EdHuL7s=; b=tnOtJB7YMFQ7kDrEHlF7joCkAF9miA0WEVPntaYo0GdrVjECOucp8HcAVhk9X0K7Xt WwpUr+5jga1F1dLRAOikV91r72adcVYOxsGmiNuR/PSvoF4ZNMj3SMnn9yCFikQefEmp /uk7CRRBEvEVVyDIPQBevl/tzAPv+bvZZalGzKRuY5AmjC7yWykJfc19jxZzvP8HS5PR 1VPbwsXB4R101KtqMR7Ln4FyARKg6iqVU7iIoS4lDpEuq+5kwBQWIG6tg7jyJsrATkxk 5iMnIpZ9dbAXYpuG4/DosvyAFSVpmvT1egPprx+sQhhVScv5dVPKFueApcTXQC0ZznMV YZkg==
X-Gm-Message-State: APjAAAWQaT8iMcnq88A1V+DmnPk6p2jNWaC4zS8hBAhgBoLqeJG/92qU DtPkceKGQXLXDJpLLS2h8x3tb/fcwMtTJw==
X-Google-Smtp-Source: APXvYqxrd1UFqwPYf6HjzNLj1IERcHR12+DEXVkcb5XVGs5QkykMn30K3gHQ+3dq5k1pebtAbPtxbg==
X-Received: by 2002:ac8:4686:: with SMTP id g6mr26121219qto.215.1573492278135; Mon, 11 Nov 2019 09:11:18 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:789b:98b5:343d:2290? ([2601:18b:300:36ee:789b:98b5:343d:2290]) by smtp.gmail.com with ESMTPSA id i12sm7541513qkm.78.2019.11.11.09.11.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 09:11:17 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-72118C97-DB68-41B4-9B38-3A88D45CA961
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com>
Cc: "v6ops@ietf.org list" <v6ops@ietf.org>
Date: Mon, 11 Nov 2019 12:11:16 -0500
Message-Id: <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com>
References: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com>
To: Richard Patterson <richard@helix.net.nz>
X-Mailer: iPhone Mail (17B84)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Y3cLM9NzFNnwAZY9aa3_SkzIU6I>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)
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: Mon, 11 Nov 2019 17:11:24 -0000

Nobody is expecting you to never renumber.   Well, at least I am not. What I am talking about here is deliberate, opportunistic renumbering. If your topology changes and you have to renumber, so be it. If you can avoid that it’s better, and if you can give notice it’s also better. If you can do it gracefully with temporary routes, even better. But you shouldn’t be renumbering just ‘cuz. 

>> On Nov 11, 2019, at 11:21, Richard Patterson <richard@helix.net.nz> wrote:
> 
>>> On Mon, 11 Nov 2019 at 11:02, Ted Lemon <mellon@fugue.com> wrote:
>> 
>> The ISP has to install a DHCPv6 server in order to do an IPv6 deployment.  We’ve already heard from one of the main vendors of DHCPv6 servers that their server behaves correctly and does not do flash renumbering.   The two DHCPv6 servers that I have worked on don’t either.  So why is the ISP going to have to delay?  The one time I was asked to help an ISP to set up DHCPv6 in a way that would allow frequent renumbering, it was a major engineering effort (which we wound up not doing).   The ISP would have to go out of their way to not support stable prefixes.
> 
> This is an oversimplification, ignoring the complexities introduced by various topology, architectural and indeed vendor decisions.
> i.e.
> - Centralised vs distributed DHCP server.
> Distributed helps scale but centralised is easier to manage.
> Centralised would require some topology-awareness to know where a subscriber is to be numbered from, unless you're OK with deaggregation and the scaling impact it has. 
> 
> - Via a relay or direct?
> Direct could mean large broadcast domains and may not scale, but helps minimise the need for the server to be topology-aware.
> Relays would help scale but will need to keep state, and to completely avoid flash renumbering during planned or unplanned outages, they would need to write leases to persistent storage also.    (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements )
> 
> - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution?
> Off-box solution is yet-another-thing to manage and scale.  Presumably there'll also need to be an IPAM, if we're to do 100% fixed statics, just for subscriber assignments.
> BNG/CMTS Vendor server may have it's on constraints and limitations.
> 
> 
> As a network operator, we can make sure we do as much as we can to keep PDs stable and honour leases up to the lease-time advertised, but there will always be the risk that sometimes we have to revoke the validity of a lease, either intentionally or unintentionally.  And sadly in the worse case scenarios, we may not be able to offer the same PD or NA as previously leased.
> If we can offer some recommendations to CPE & DHCP client/relay/server developers, as well as Operators, to help minimise this impact, I think it's worthwhile to do.
> If we can slightly tweak protocols to help minimise this impact, I understand that it may be a contentious idea, but would like to think it's also worthwhile looking in to?