RE: Reviving draft-ietf-vrrp-ipv4-timers-02: timeout vsinterval

Don,

With regard to your observation that the entire spec is written around the
advertisement interval, the calculation of the skew time would need to be
addressed.  Complicating matters (slightly), in the latest VRRPv3 draft
backups accept and apply the masters advertisement interval.  Presumably any
backup would do the same for the timeout value.  This was a change that had
been discussed for VRRPv2 as well.

Steve

-----Original Message-----
From: Don Provan [mailto:[email protected]] 
Sent: Friday, March 30, 2007 12:08 PM
To: Hott, Robert W CIV NSWCDD, W13; Fioramonti, Joseph;
[email protected]; [email protected]; Fioramonti, Joseph
Cc: Chappell, Brett L CIV NSWCDD, W13; Odonoghue, Karen F CIV NSWCDD, W13
Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02: timeout
vsinterval

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