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

Hi Don, 

I guess elaborates point 4 of the last email.  I'm okay with this as
well. 

Regards, 
Steve Nadas  

-----Original Message-----
From: Don Provan [mailto:[email protected]] 
Sent: Friday, March 30, 2007 2: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