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

Tassos Chatzithomaoglou <> Wed, 13 November 2019 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70640120859 for <>; Wed, 13 Nov 2019 15:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DakayLt05oy0 for <>; Wed, 13 Nov 2019 15:41:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA13F120848 for <>; Wed, 13 Nov 2019 15:41:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DDD04121927 for <>; Thu, 14 Nov 2019 01:41:23 +0200 (EET)
Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by (Postfix) with ESMTP id CEEB6121B55; Thu, 14 Nov 2019 01:41:23 +0200 (EET)
X-DSPAM-Result: Spam
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 1RlJ_J5jhFXd; Thu, 14 Nov 2019 01:41:23 +0200 (EET)
Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by (Postfix) with ESMTP id 1E390121B5D; Thu, 14 Nov 2019 01:41:23 +0200 (EET)
DKIM-Filter: OpenDKIM Filter v2.9.2 1E390121B5D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=zm; t=1573688483; bh=Z+85r+VopbtfYqHnsQReqY74Pu04VLUkerN+KOC8QEA=; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=N1Q1QE5F03CO64CecotgCZfEF/kuzurlky7cEMEeuhRSKar9c/x06RNHIUz34Lx25 /Nms2bbdqTSYGtopzfEd+7KBWzFj6CfAURVQutwipqb+NN5QxIAX/k64Dg40hKbXUw I1biQyaLHYStdRXrNZR1u3a7ubucVnPVgXLRwuOY=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id k60HAeCPoWj5; Thu, 14 Nov 2019 01:41:23 +0200 (EET)
Received: from [] ( []) by (Postfix) with ESMTPA id CA0F7121B55; Thu, 14 Nov 2019 01:41:22 +0200 (EET)
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tassos Chatzithomaoglou <>
Openpgp: preference=signencrypt
Autocrypt:; keydata= mQENBFPWrY4BCADa9txOlMMGA1PvelU2qfkJ3cIoF+M9wXhSvZTI63FfgZAMWVM/NryJQ74q kiaWFyprgqo2BBk6vWkCw0N8pVwx0Z0sbPisB1fo/zB29cyM0HeB8lnu+Z5AvkfjwekMtGJd 3+tsRwOqdAJpCpJNhS0cVAkk1lIe3i8pdBbbKYJ5VNpBTyi0zL18WRvz9qf8nnP50rQOF8Oc LNCyKrT5S02SonWH5fQDTMVaSDVRvzRLU34pL0WEsIfTQciwg9LhjRpGj6mHxX1OdRHBpHmH WAI05lg7xRwYZq2/X/9Xizd0j9hbr6Ph7oiW7u6e4zAndvPSxXaBVCzpVI0hhaJl11yVABEB AAG0G1Rhc3NvcyA8Y2hhdGFzb3NAeWFob28uY29tPokBPwQTAQIAKQUCU9atjgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG9JgN4loaV7D0kIAKfyVLWFzOfYM0uT m78iJsh9nAaxYiM0t40oF+HY7Cri35FDAzrRjbB0os/KehCz6uuBqDe+3swkVX9bwE9/GsHc Tb5C1IOdvgb2Rp3MfSF1+Ju/3uGtiktQIqZ5YrIZhIjGiwUCVC6ewpC3VRiFVo/HvE23p16y 6Ws9y4xoRNuxs0952twZjT9jwVub8TWm/uES6RERZ68FGA1jVFXtAgMXljP29KcL8zRw9xiY VNI1MgUIRhOKENzpChS+7jZSDWKKD9fwPUNDNPG9kNuXoinRX1g2wlgWKmaBNVBOZMunR20P eVewZ2v35uaiHyzzHw92vjjfxOtpXoW0QFlT5cg=
To: v6ops list <>
Message-ID: <>
Date: Thu, 14 Nov 2019 01:41:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 23:41:32 -0000

Ted Lemon wrote on 13/11/19 17:18:
> On Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou < <>> 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.