IETF Logo Mail Archive

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 20:05 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 C2068120105 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 12:05:21 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 1WzeC7511QCS for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 12:05:20 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 23F7212081C for <v6ops@ietf.org>; Mon, 11 Nov 2019 12:05:20 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id e187so12320514qkf.4 for <v6ops@ietf.org>; Mon, 11 Nov 2019 12:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CV5t+fQV7noBGnt2kjDHdSaDBbGSyQ1l1ljPCsUAOhQ=; b=hHO+51f+l1cInBqNuA/yGzRH0FU81Z9lN5T4Kg9wfUHGuoZllAmj+/cpAcUOdBWurt HVTIZVX+kCmYUjmBspNn6hf9on736qqe47iqZ96zBBwWmqrCXoblNU4ZGj6crogHfMbH D/7VwuKQ1KKfecpREbD4XzVXyTKHe4T9+gclsXwHowwKEjNbz8LIapsCpYvfvlvai2gQ fjb3hh5kTXTZ9SOadix+lgSJ3v/cRk7sg3gM169rdZgTt03ONQXV2RirxKAcGKI/7CbF ht9H8TXwEvxppIGIXkKzOgGMRyCqVkJNl3HjioAcCdobjOpRrLwyGj0NYGVY6IER4Shg BWIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CV5t+fQV7noBGnt2kjDHdSaDBbGSyQ1l1ljPCsUAOhQ=; b=oT9fegBcnMAaLVGDsiMDsifLcftgeRShYAa0+cRXbO6sXArbBpLJFmmimX7DSGXtO0 55DtGtv0j2cCpdSJMoq+19hWtnSWkP7c/cir0cYB+7RXV1OaTNgasABVDkoJ0T9t5rRz DYyxVCNuCEsByGrta+EHAQpyq8mBsH1wiUli+iMhhXrSni57IOj5xCT2xWigG9s6vxFj pBgisHr+/tThD8rVddqs+oUZ7p1rCKNe1ciuGR9Hh+rrwPn+Cgl3HyQ81bx+3OQWYjd1 0QaRjN9My9Ey6obQm/L9c3fQpf7bSu7FoLyGebV3UPfiV7FE2+9q9zb6JfwbKYa9iOIT M8zg==
X-Gm-Message-State: APjAAAWXWjNNvG/zF3BIUxIOmlgQ6v07+JQkJPqizc/dDbyYkfOXbBBX nYR7WM1DCcW6m7Cwz22HuOVPig==
X-Google-Smtp-Source: APXvYqyhRTehGxk320tXCIxUV3wvrkXmcF/QJAA08jjH4K/p817z37P9mniatRI910QzTeFg535alQ==
X-Received: by 2002:a37:4906:: with SMTP id w6mr2262895qka.82.1573502719122; Mon, 11 Nov 2019 12:05:19 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:1513:f8e0:6f18:51cb? ([2601:18b:300:36ee:1513:f8e0:6f18:51cb]) by smtp.gmail.com with ESMTPSA id c128sm1528592qkg.124.2019.11.11.12.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 12:05:18 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <ACAC2633-89BA-4891-933E-EDC75B6F28AE@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ABD43F9B-D7FE-4622-B082-501F77072CB0"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Mon, 11 Nov 2019 15:05:16 -0500
In-Reply-To: <CAO42Z2zWTediRkaF_pfot_QT9Hsf5Wdu9_77BQZjEEG5wY1jdQ@mail.gmail.com>
Cc: Richard Patterson <richard@helix.net.nz>, v6ops list <v6ops@ietf.org>
To: Mark Smith <markzzzsmith@gmail.com>
References: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com> <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <CAO42Z2zWTediRkaF_pfot_QT9Hsf5Wdu9_77BQZjEEG5wY1jdQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_mcmWkqCaghwRcgArHiCqo9HkNI>
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 20:05:22 -0000

On Nov 11, 2019, at 2:47 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
> Unplanned "flash" renumbering due to a topology change implies an unplanned "flash" topology change. That's going to be a rare event, and ideally shouldn't ever occur, because I think it is a sign that some other planning hasn't been occurring.

It’s not quite as simple as that.   A topological bifurcation (or any similar division) should be pretty easy to manage without flash renumbering, because you can just renumber before you change the topology.   Assuming you have time.  But anything more complicated is going to require the propagation of network routes for each customer to multiple places in the network.   I think this is eminently doable, but it’s not trivial, and I wouldn’t be surprised if it’s not something an operator can easily do with their existing tooling.

v2.23.0 | Report a Bug | By Email