Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02: timeout vsinterval

From: "Stephen Nadas \(RL/TNT\)" <[email-masked]>
Date: Mon, 2 Apr 2007 12:20:22 -0500

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-masked]] 
Sent: Friday, March 30, 2007 2:08 PM
To: 'Hott, Robert W CIV NSWCDD, W13'; 'Fioramonti, Joseph';
[email-masked]; [email-masked]; '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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Steve Bates" <[email-masked]>
Date: Mon, 2 Apr 2007 11:50:18 -0600

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-masked]] 
Sent: Friday, March 30, 2007 12:08 PM
To: Hott, Robert W CIV NSWCDD, W13; Fioramonti, Joseph;
[email-masked]; [email-masked]; 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

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