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

[Lee Howard <[e-mail]>]

On 2/22/19 12:53 PM, David Farmer wrote:
> Generally, I agree with what you are saying, but I'd like to see 
> something like the following added as well;
>
> Even if an ISP intends to change the IPv6 prefix regularly in 
> the longer-term, say every few months or even each month at an 
> extreme, in the shorter-term IPv6 prefixes SHOULD be stable, for time 
> periods of hours, days, and maybe even weeks at a time. Or, put 
> another way, CPE devices SHOULD NOT get a new IPv6 prefix every time 
> they are rebooted.  Note: even in locations where utility power is 
> generally stable, power outages frequently occur in clusters over a 
> few hours or days.  This occurs when an emergency repair is made to 
> restore power and then more permanent repairs cause short outages in 
> the following hours or days. In this scenario, each of these events in 
> the cluster SHOULD NOT result in the CPE receiving a different IPv6 
> prefix.
>
> Conversely, when widespread power events occur, affecting thousands or 
> even tens of thousands of customers, it may not be practical or even 
> possible for an ISP to guarantee all CPE will receive the same IPv6 
> prefix they had before. Therefore to the extent possible, CPE and 
> local networks SHOULD be resilient to their ISP provided IPv6 prefix 
> changing, sometimes even unexpectedly changing.

What's the difference between what you said and "ISPs should, as much as 
possible, reissue the same prefix to customers."?

Lee

>
> Thanks.
>
> On Fri, Feb 22, 2019 at 10:36 AM Lee Howard <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>
>
>
>
>
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
>
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================