Re: A common problem with SLAAC in "renumbering" scenarios

[Bob Hinden <[e-mail]>]

Lee,

> On Feb 19, 2019, at 7:29 AM, Lee Howard <[e-mail]> wrote:
> 
> 
> On 2/19/19 7:22 AM, Ole Troan wrote:
>>>>> Seems to me several operators have offered their opinions here. If you want more opinions, maybe ask a group of operators?
>>>> Not a very helpful comment... I think the underlying problem here is that there is no technical solution available that solves stable IPv6 address delegation at residential scale in an acceptable way.
>>>> 
>>>> - For stable address delegation the routing inside the ISP becomes a mess, especially when it can't be guaranteed that a customer consistently ends up at the same BNG.
>>>> - To keep ISP networks scalable, prefixes are aggregated to (roughly) BNG level, making it impossible to keep prefix delegation stable at the customer's end
>>>> 
>>> It's not a hard requirement to aggregate prefixes at the individual
>>> BNG level, and most ISPs should be running BGP to carry customer
>>> routes. Obviously BGP to scale to 100s of 1000s of routes because the
>>> Internet runs with it.
>>> 
>>> The minimum PD stability needed for fixed access customers (e.g. ADSL,
>>> FTTH etc.) is within the pool of BNGs they can attach to upon
>>> reconnection. So if you need or want to aggregate those routes, you
>>> place the BGP route aggregation boundary at the boundary of your BNG
>>> pool, rather than at the individual BNG. You then say to your
>>> customers that if they physically move their service by e.g. moving
>>> house, they may not receive the same stable PD prefix again, because
>>> you're not guaranteeing they will reconnect to the same BNG pool.
>>> 
>>> It would however be nice to try to provide the customer with a stable
>>> prefix on a greater scale than just within the same BNG pool, so you
>>> could pick greater geographic boundaries for your aggregation points,
>>> rather than at the boundary of an individual BNG pool. For example,
>>> here in Australia, I'd try to aim for that boundary to be at each of
>>> the 7 capital city boundaries, even though I may have multiple PoPs
>>> within a city, with each PoP containing a number of BNGs in a pool
>>> (and possibly multiple BNG pools within a PoP). Smaller aggregation
>>> domains e.g. dividing cities into 4 regions might be necessary
>>> depending on numbers of subscribers.
>>> 
>>> You can still provide a guaranteed static and persistent PD prefix to
>>> customers that want to pay for it, which means that prefix isn't ever
>>> aggregated and can follow them regardless of where they geographically
>>> because you never aggregate that prefix. They're paying for and
>>> getting more value because they're getting a guarantee.
>> Indeed. Wonder how these pesky mobile phone operators manage to deliver the same telephone number to a user, for years. Across different providers and contracts.
>> I can’t think this argument is anything but a strawman.
> 
> You are saying he (maybe others) is either a liar, intentionally creating false arguments, or a fool, not understanding the network.
> 
> Your insinuation that fixed network operators must be doing something fundamentally wrong because mobile voice networks work differently is ignorant and insulting.

Expressing technical requirements is within scope for this (and other) 6man discussions.  I don’t see how you turned this into saying someone called others liars, making false statements, or being a fool, etc.  Given the number of posts on this topic, there are clearly many views.   

Please return to the technical discussion.

Bob



> 
> That's out of line for a working group chair.
> 
>> 
>> There’s nothing a bit of regulation can’t fix. :-)
> 
> Because of the smiley I don't know how to interpret this. Either you actually think regulation would work, and the question is whether you mean governmental or IETF, or you don't, in which case there's no argument that 6man should tell network operators they're doing it wrong.
> 
> Lee
> 
> 
> 
>> 
>> Ole
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------