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

Nobody is expecting you to never renumber.   Well, at least I am not. What I am talking about here is deliberate, opportunistic renumbering. If your topology changes and you have to renumber, so be it. If you can avoid that it’s better, and if you can give notice it’s also better. If you can do it gracefully with temporary routes, even better. But you shouldn’t be renumbering just ‘cuz. 

>> On Nov 11, 2019, at 11:21, Richard Patterson <[e-mail]> wrote:
> 
>>> On Mon, 11 Nov 2019 at 11:02, Ted Lemon <[e-mail]> wrote:
>> 
>> The ISP has to install a DHCPv6 server in order to do an IPv6 deployment.  We’ve already heard from one of the main vendors of DHCPv6 servers that their server behaves correctly and does not do flash renumbering.   The two DHCPv6 servers that I have worked on don’t either.  So why is the ISP going to have to delay?  The one time I was asked to help an ISP to set up DHCPv6 in a way that would allow frequent renumbering, it was a major engineering effort (which we wound up not doing).   The ISP would have to go out of their way to not support stable prefixes.
> 
> This is an oversimplification, ignoring the complexities introduced by various topology, architectural and indeed vendor decisions.
> i.e.
> - Centralised vs distributed DHCP server.
> Distributed helps scale but centralised is easier to manage.
> Centralised would require some topology-awareness to know where a subscriber is to be numbered from, unless you're OK with deaggregation and the scaling impact it has. 
> 
> - Via a relay or direct?
> Direct could mean large broadcast domains and may not scale, but helps minimise the need for the server to be topology-aware.
> Relays would help scale but will need to keep state, and to completely avoid flash renumbering during planned or unplanned outages, they would need to write leases to persistent storage also.    (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements )
> 
> - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution?
> Off-box solution is yet-another-thing to manage and scale.  Presumably there'll also need to be an IPAM, if we're to do 100% fixed statics, just for subscriber assignments.
> BNG/CMTS Vendor server may have it's on constraints and limitations.
> 
> 
> As a network operator, we can make sure we do as much as we can to keep PDs stable and honour leases up to the lease-time advertised, but there will always be the risk that sometimes we have to revoke the validity of a lease, either intentionally or unintentionally.  And sadly in the worse case scenarios, we may not be able to offer the same PD or NA as previously leased.
> If we can offer some recommendations to CPE & DHCP client/relay/server developers, as well as Operators, to help minimise this impact, I think it's worthwhile to do.
> If we can slightly tweak protocols to help minimise this impact, I understand that it may be a contentious idea, but would like to think it's also worthwhile looking in to?