draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

[Vasilenko Eduard <[e-mail]>]

Hi Fernando,
Reminder, draft draft-vv-6man-nd-prefix-robustness exists because the chair (Ole) did ask.
Ole has probably asked because I was strongly against solving this problem by timers - it gives extremely bad results (tens of minutes instead of 50ms like it was 60 years ago in telephony) but you insisted on timers.

Your proposal on IETF 114 for what you called "Heuristics" looks more or less good. A few-second outage programmed in the Heuristics is not very bad.
(SYN flag proposed in draft-vv-6man-nd-prefix-robustness drives it to sub-second).
Hence, I would not scream anymore. Even if you will ignore the rest of my message and leave some flash renumbering corner cases unresolved (for future standardization):

1. I would explain a little more about how I have understood Jen's comment.
The host could be abruptly moved to a different VLAN. CPE could be abruptly powered down and then replaced.
The new router could be represented by different MAC and LLA.
Whatever the new router would announce, it is not the reason to delete information from the stale router - the blackhole could persist for 15min on average.
Hence,
a) after a new router is discovered, the host SHOULD RS (I strongly prefer unicast and could explain why, Jen has mentioned multicast) of all old routers to check that they are active.
see section 6.8 of draft-vv-6man-nd-prefix-robustness
b) if the router is deleted from the router list then all information related only to this router SHOULD be deleted too. It does not make sense to use PIO that has no associated router.
see section 6.9 of draft-vv-6man-nd-prefix-robustness

2. CPE information protection against reloading by "prefixes storage in non-volatile memory" is more important.
But it makes sense for all routers that have prefix delegation in any way.
All routers could lose power and then get a different prefix (especially when more protocols for prefix distribution would be developed in the future).
It would help for hosts that do not have "heuristics" yet.
see section 6.5 of draft-vv-6man-nd-prefix-robustness

3. Nothing pushes developers now to deprecate prefixes after configuration change or shutdown.
Hence see sections 6.3 and 6.4 of draft-vv-6man-nd-prefix-robustness

It would still not resolve MHMP.
Hence, draft-vv-6man-nd-support-mhmp is applicable.
It is not a problem to split ND problems in this way (MHMP is separate from flash renumbering).
Again, draft-vv-6man-nd-support-mhmp has no any intersection with draft-ietf-6man-slaac-renum.

Eduard