Abhayakara
commented
3 months ago I think the issue here is not about usable prefixes, but about routes.
Suppose we have a DHCPv6 prefix, and the DHCPv6 server doesn't renew it. In this case, we probably want to stop advertising it at some point and start advertising a prefix based on our site ULA. We should talk about the timing of this switch-over.
Separately, whenever we have advertised a prefix on either link, we need to continue advertising a route to that prefix until the prefix is no longer valid on the link on which we advertised it. So if we switch from DHCPv6 prefix to ULA prefix on infrastructure, we need to be advertising routes to both for as long as both are valid.
Similarly, if we advertise a prefix on the stub network and later withdraw it because a higher-priority prefix is advertised there, we need to continue advertising a route to that prefix on the infrastructure link until the valid lifetime of the prefix we advertised has expired. I think all routers that have seen the prefix need to do this.
Then there's the case where a stub router advertising a prefix reboots. We can't assume that it's written anything to stable storage other than what prefix it's allocated for the stub network and for the infrastructure network. So when the router comes up after booting, it needs to advertise routes to these prefixes on the appropriate link until the maximum possible valid lifetime for the prefix has expired.
And finally there's the DHCPv6 case, where we got a prefix to advertise on the stub network via DHCPv6. In this case, I think we need to write the DHCPv6 prefix to stable storage when we get it, and remove it from stable storage when it expires. We should limit the lifetime we advertise on the stub network to a constant value (e.g. 30 minutes), and then if we find the DHCPv6 prefix recorded in stable storage, we advertise a route to it on infrastructure for 30 minutes after reboot. After 30 minutes, we can erase it from stable storage so that this doesn't repeat.
I think if the BR doesn't have stable storage, then if it reboots with a DHCPv6 prefix still valid on the stub network, we just have to hope that it gets the same prefix when it comes back. If it does not, then that prefix may become unreachable while hosts on the stub network are still using it.
We could have the stub network snoop source addresses to discover prefixes still in use on the stub network to ameliorate this situation, but that's somewhat problematic because it's a lot of work.
the text in this section can be confusing when dealing with 2 usable prefixes (see section 5.2.1.4 - ULA/non-ULA). In MCR's words: if there are two suitable prefixes, one of them will still need to be deprecated. According to Ted, this issue is orthogonal to reachability. Perhaps, we should explain that this state-machine does not talk about reachability for both the suitable prefixes. At least give forward reference to section 5.4 for complete behavior.
This will explain that we can only transition to STATE-BEGIN-ADVERTIZING and in no case we transition to STATE_USABLE