Re: [v6ops] What problem are we trying to solve? (Re: 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> Thu, 14 November 2019 00:02 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 11E6E120842 for <v6ops@ietfa.amsl.com>; Wed, 13 Nov 2019 16:02:25 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 eaAiqRr45Qi5 for <v6ops@ietfa.amsl.com>; Wed, 13 Nov 2019 16:02:20 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 C3A9012008D for <v6ops@ietf.org>; Wed, 13 Nov 2019 16:02:20 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id o11so4688635qtr.11 for <v6ops@ietf.org>; Wed, 13 Nov 2019 16:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=GOYJLnXQ2KHs77Z2DZWxGVF0W18JfrG+j0SA+wDAm2g=; b=c83Tk83XDfs3X+hTyr1cRyljWm4BaK3GTuLXjaV4zFYJVaX3EFT3B0jCScvyzWxuDH nfyBMQz92MZ3JiLHW0EYr7HAUhHVbg9VRcBUSx/vHr5GmtthzKMOXjXyN/zcL6/JLw6d XngWaOheL2zfZeA1gzAzt5lF8sB3m+zzwNQFnxAbeo4TQuxHU5sy0MpQPRug1Z9bdulm hnwl7h+heeeKI8xMFdZ0nXrhoLfZYMI5HpB2R7MKWbyskTS0bUu61DpyFu3LW9lN29Qt LpHyZIMdKiu6I9gXiDwRxuWHlK1thCQT0klR9crMXXsjRRGBkhWUIlPalDpNPgDETgFB fcjg==
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:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=GOYJLnXQ2KHs77Z2DZWxGVF0W18JfrG+j0SA+wDAm2g=; b=ZVN+6oKfjazKDZyvsqKYIAqlvlgSMStXsky0dkasTUjru3uDWoAknZj2N+3blYQpSG Z4a5IryzF4Babq0Wv6f45safDgAr1fGYYxH1/MUjUL/5Bzjdx2IC1wQ57W7ZZ4CJExzE rAVeK8GNNlogH/A2d4mozcjCTTSw9PkKEZE3yTGNh6aI6EAeuH3wHe6o/0I4/X7XmXZY DylLinOBKj86ttsTtbo1SQEeRu6msG/d5Tc+400lY0hTsHEEYmJZWACUf6zAroSZz5s4 KZ8ElsriFJXUXvxDwxODjRYyPcnVybvdQbbhIPBIp/JM0ZmqBpqZGgKn1MDvNXwpJRgJ fH0A==
X-Gm-Message-State: APjAAAVNhuCkuwRktNe/sAKVmBPbjCjm16o7EHt2cZOVCnMNDXBvAdQW KOyiwfqs5QxFKknWxgV7yfaMxk6CcF3ldA==
X-Google-Smtp-Source: APXvYqx9YGWzzuPbI9+GCzcJJVqj1VWuV4ejN8hMMYHIh1ZvvOocaqfrKZyCfmd3JntbTiQBn9Eqrw==
X-Received: by 2002:ac8:608:: with SMTP id d8mr5592749qth.258.1573689739567; Wed, 13 Nov 2019 16:02:19 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:b5d9:8475:5209:db41? ([2601:18b:300:36ee:b5d9:8475:5209:db41]) by smtp.gmail.com with ESMTPSA id f6sm1703588qke.16.2019.11.13.16.02.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 16:02:18 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 13 Nov 2019 19:02:17 -0500
Message-Id: <B9640FE3-82F4-46D1-9285-D1E12E20095D@fugue.com>
References: <554dfc6d-0a29-aa4e-a8ae-57943b02930e@forthnet.gr>
Cc: v6ops list <v6ops@ietf.org>
In-Reply-To: <554dfc6d-0a29-aa4e-a8ae-57943b02930e@forthnet.gr>
To: Tassos Chatzithomaoglou <achatz@forthnet.gr>
X-Mailer: iPhone Mail (17B84)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/C-KKkQOM_6JzKCoTZ3JMBN8zngM>
Subject: Re: [v6ops] What problem are we trying to solve? (Re: 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: Thu, 14 Nov 2019 00:02:25 -0000

Your lifetimes should not be so long. Graceful renumbering means advertising two prefixes, one deprecated. You keep the route for the deprecated prefix up until the valid lifetime expires. Then you eliminate it. The number of routes should not grow over time. 

> On Nov 13, 2019, at 18:41, Tassos Chatzithomaoglou <achatz@forthnet.gr> wrote:
> 
> 
> Ted Lemon wrote on 13/11/19 17:18:
>>> On Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou <achatz@forthnet.gr <mailto:achatz@forthnet.gr>> wrote:
>>> We do the same in IPv4 because many subscribers had asked for it. They wanted to easily (disconnect the line or reboot the CPE) change addresses.
>> 
>> Supposing IPv6 customers ask for this.   Why would you not give it to them with graceful renumbering rather than flash renumbering?
>> 
>>> That's mostly a commercial decision. Commercially we want to differentiate static vs dynamic.
>> 
>> So you are charging customers to not do something that costs you money and them reliability to do.   Customers who pay you get nothing, and customers who don’t pay you get what amounts to a punishment.   I guess that’s your prerogative, but again, if you are going to do this, why not do it right?  Don’t flash renumber—renumber gracefully.   You still are able to punish customers who don’t pay you, but you aren’t creating a support problem for yourself in the process.
>> 
> I can see a disadvantage (it's a customer choice after all), but not a punishment. As i said in my previous emails, we haven't got any such complaints. So, either the customers don't care/understand, or the customers don't experience such issues (invalidating the previous prefix at next reconnect helps).
>>> The biggest technical issue i see is routing de-aggregation due to many different BRAS serving the same customers.
>> 
>> So am I to understand that you have many different routes to the customer, and no way to be consistent about which route the customer gets when they disconnect and reconnect?   Isn’t that a problem with the BRAS setup?
>> 
>>> Aggregating at another level is not an option, because we don't want to have hundreds of thousands of /56s at this level.
>> 
>> Absolutely.   But is that your only option?   E.g., if you were to just have a route at this level for every customer that had been renumbered and still needed their old prefix to be routed, would that tend to be hundreds of thousands?   If so, isn’t that evidence that there’s something wrong with your setup?
>> 
> 
> We do have this for static customers who are a very small percentage. I guess for dynamic customers it wouldn't be hundreds of thousands in time t0, but i would see it easily increasing to tens of thousands in time t1 (after few weeks). Not to mention all the routing updates which would move deeper into the core of the network. That's because our N+1 BRAS clustering scheme has been designed with a simple concept in mind: provide the highest possible availability using the lowest possible budget. By increasing the budget, we can have more M+1 (M<N) BRAS clusters, so we can decrease the endpoints for a specific subscriber, until we reach the 1+1 model (active/hot-standby) where it would be silly not to have stable prefixes per subscriber.
> 
> --
> Tassos
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops