Reviewer: Jürgen Schönwälder Review result: Has Issues I have reviewed draft-ietf-v6ops-slaac-renum-03 as part of the ops-dir review efforts. The document addresses a problem that is of certain operational relevance. This document is labeled as informational. Perhaps indicate a bit earlier what unacceptably long means, i.e. we are talking about days and weeks. The scenarios described read a bit like somewhat rare events and hence it is useful for the reader to have an idea what unacceptably long means in such events. (BTW, I find the scenario not described at the beginning where a router announces SLAAC lifetimes that are not synchronized with obtained prefix lifetimes operationally the more tricky problem since this can lead to regular failures.) Section 2.2 seems to confuse soft-state (this is what a learned IPv6 prefix is for me) with certain protocol timers. There are many places where protocols use soft-state and implementations use timers to purge or refresh soft-state. That timers generally do not go off in normal conditions is not really correct in this context, DHCP leases are renewed when their lifetime expires, a normal operation. IP address mappings to Ethernet addresses expire when their lifetime timer goes off. Switches purge forwarding state regularly when forwarding entries expire. Cached DNS name to IP resolutions expire. The only problem here seems to be that a lifetime of 7 days / 30 days is a bit ridiculous. Is anyone shipping the RFC 4861 defaults? The few implementations I have seen do use a bit more reasonable defaults. I think this section should be rewritten to replace the "timer going off is associated with a failure" text with a discussion of soft-state in other protocols. (Section 2.2 is why I ticked 'has issues'.) Isn't a part of the solution (other than moving to less ridiculous default) that SLAAC hosts experiencing connectivity problems should try to validate the prefix that they have learned (and if the validation fails move to a newly learned prefix)? Involving the hosts in a resolution of the problem may be more robust than expecting that something in the network takes care of invalidating stale soft-state. Well, this comment is likely outside the scope of this problem statement document. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
