revisit protocol constants ??

[Thomas Narten <[e-mail]>]

Here is an excerpt from my review of the stable addresses document. I
wonder if we should rethink some of the protocol constants we are
defining. The world is becoming more diverse and it seems that a "one
size fits all" notion for some protocol constants is making less and
less sense.

> Finally, I want to raise a generic issue that applies to this
> document, but really is a general problem. The document adds a random
> delay between 0 and IDGEN_DELAY in order to avoid lock-step
> behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is
> pretty long for some network technologies (think data center with 10G
> or higher interfaces). I wonder if we should stop using constants that
> are fixed and make them more dependent on actual network
> technology. E.g., 1 second seems OK for WiFi, but not for 10G.

Note that this sort of constant being as long as a second can mean it
will take that much longer to configure an address (in some cases)...

> Likewise, should you ever stop trying to configure an address if you
> keep getting DAD failures? I'm of two minds. Going forward, it becomes
> increasingly painful to require operator intervention to "fix"
> something that isn't working. That argues for never giving up. But
> what should happen then is some sort of exponential backoff should be
> used to ensure that retries happen infrequently, so as not to cause
> network problems. The current text says:

For this, I was partly also thinking about DHCPv6 where the original
spec called for the client  giving up after a certain number of
tries. That saves bandwidth, but it also means that if a client can't
find a DHC server, at some point it quits trying and won't ever try
again. And if the machine stays up and running for  several
weeks... (I'm not sure this ever even got fixed....)

Thomas