RE: Reviving draft-ietf-vrrp-ipv4-timers-02: timeout vs interval

Ah, yes, it's all coming back to me now....

Right, Joe, the significant change I'm supporting is the one
Bob originally floated last year: changing the protocol to
send the timeout time instead of the interval. My claim is
that the timeout is the number required for protocol function.
The original protocol mistakenly sent the interval, and that
forced the 3 retransmission requirement to be hardcoded not
merely in the application, but all the way back in the protocol
spec.

Practical experience (not mine, and I don't remember whether
it was Bob or someone else) revealed that, with very small
timeouts, higher retransmission counts increased stability.
The choice is to encode the retransmission count in the
packet (which is what the -02 spec does), or recognize that
the retransmission cycle time is irrelevant to the protocol
operation and leave it out of the protocol, replacing it with
the timeout.

I propose the latter as a simplification. I agree it is a change
from all previous versions including RFC-3768. And what makes
that worse is, as I recall, the entire spec is written around
the ticker as the core of the protocol behavior, so it might
take some doing to rewrite the change, particularly while
retaining the original mode as the default configuration, even
though the actual change is really minor in terms of how an
implementation works.

On the other hand, draft-ietf-vrrp-ipv6-spec-08 is still
a draft. May I suggest that *it* be changed so the interval
field becomes a timeout field? That would allow it to support
higher retransmission counts as well. (In fact, are there
any other differences between the two protocols, other than
the obvious differences in the addresses? I haven't paid
much attention at all to IPv6, so I don't remember why we're
working on them as independent versions.)

But I just think it's the way to go: the protocol changes by
one field difference between the two packet types, and, if
anything, the new field use is more obvious and easier to
understand in the new mode.

Let me point out that I was the principle antagonist to the
idea that the retransmission count should be configurable.
I opposed the idea because I wasn't convinced that the
complexity added to the protocol was really worth it. With
this change, the protocol isn't effected: the number of
retransmission is a simple configuration parameter the
administrator of each router can set to their tastes. Two
admins of two cooperating routers don't even have to agree
on the rate, as long as they agree on the timeout.

-don

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp