draft-gont-6man-slaac-renum: Protocol-based improvements (Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes)

[Fernando Gont <[e-mail]>]

Hi, Bernie,

On 8/4/20 16:44, Bernie Volz (volz) wrote:
> 
> Ole, perhaps if there was a concrete proposal for an alternative approach, we would go there? So maybe this debate needs to be put on hold a bit to allow alternative approaches to come about. Though as stated earlier, some of this has been discussed for a while and I don't think there are any yet?

We have discussed this for over a year now. Ole has repeatedly argued 
that this is not a problem, or that this is not a problem worth solving, 
because the networks that face these problems suffer from the 
incompetence/lack of knowledge of their admins/operators (even after 
multiple-statements from operators on why these scenarios take place). 
He deems these occurrences as rare, while concrete data and anecdotal 
evidence suggests 40% of deployments doing dynamic addresses. In such 
scenarios, he argues that the user should switch ISPs, when in so many 
different places I know of, there is no other ISP to switch to.

Now, the topic has been debated for over a year now. Nobody prevented 
anybody to come up with something better.. and as you correctly note, 
nobody did.

On our side, we kept working on this. A few folks (Jen and Philip to 
name a few) found flaws in our early proposal, and suggested 
improvements, which we did our best to incorporate.

We also discussed this with as many operators (this was discussed, IIRC, 
in RIPE, UKNOF, LACNOG..) and developers as possible, and received very 
positive feedback. And we also took the time to produce implementations 
of some of the improvements we propose (please see: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#section-6), 
or discuss this with developers that might want to improve SLAAC.


Maybe in order to honor the motto of "we reject kings", it would be time 
for the working group to be polled for adoption of this document. 
Certainly not to rubber-stamp it, but to continue polishing and 
improving it where/as appropriate.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492