Stability and Resilience (was Re: [v6ops] A common...)

[Lee Howard <[e-mail]>]

I think I have heard the following suggestions in this conversation. I 
hope that taken all together, rather than as individual spot solutions, 
they can be a consensus recommendation.


ISPs should, as much as possible, reissue the same prefix to customers. 
Some things ISPs can do to increase the chances of this:

 1.

    Share lease information between redundant DHCPv6 servers. Most ISPs
    probably have redundant servers, since this is critical provisioning
    infrastructure. It may be difficult to synch information between
    servers for millions of leases over tens of milliseconds of latency;
    see RFC6853, "DHCPv6 Redundancy Deployment Considerations." Maybe
    DHCP vendors can report.

 2.

    Aggregate above the provider edge device, so that grooming customers
    between Provider Edge boxes (PEs) doesn't force a renumbering. It's
    been a few years since I worked on CMTSs, but when I did they did
    not support MP-BGP well (if at all), so routes had to be aggregated
    on the PE, or leaked in the IGP which is bad for convergence time.
    Maybe PE vendors can report.

 3.

    Set DHCPv6 lease timers very low prior to grooming events. A short
    interval during the maintenance window will increase load on the
    DHCPv6 server until timers have been returned to normal values.

 4.

    In the case of a PE reboot, use DHCPv6 Bulk Leasequery to rebuild
    the routing table. I think all of the necessary information is in
    those responses. Again, last time I was working on CMTSs, this
    feature was not supported. Maybe PE vendors can report.


Networks should, as much as possible, be resilient to prefix changes. 
Some things networks can do to improve resilience:

 1.

    Write a learned prefix to non-volatile memory and issue a DHCPv6
    Renew for that prefix on reboot.

 2.

    Use dynamic DNS and shorter TTLs.

 3.

    Implement something like NETCONF to distribute prefix information to
    policy devices like firewalls or SD-WAN controllers. I think a
    separate document describing this application of NETCONF would make
    sense.


In the case of failures, it cannot be assumed that sessions will stay 
active. We try to build in redundancy and resilience where we can, but 
where there's a single point of failure (such as CE or PE), and it fails 
(such as an unplanned reboot), our expectations should be appropriate.

Is this a reasonable summary?

Lee