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 <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> Ted Lemon wrote on 13/11/19 17:18:
>>> On Nov 13, 2019, at 2:32 AM, Tassos Chatzithomaoglou <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops