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

> How do you propose to calculate the skew_time?

Good question. If we think the draft got it right

  ( ( ( 256 - Priority ) * Advertisement_Interval )
    / 256 )

then I'd simply change it to the philosophically
equivalent

  ( ( ( 256 - Priority ) * ( Timeout_Interval / 3 ) )
    / 256 )

On the other hand, something more like

   ( 256 - Priority ) ms

is closer to the original RFCs, and I'm not really
convinced the skew time needs to change at all from
the RFCs'

   ( (256 - Priority) / 256 ) s

While it's true that priority 1 would add an entire
second to the failover time, priority 255 would
still add less than half a centisecond. In my mind,
it's reasonable for a priority 1 peer to take well
over the target failover time: if it could do better,
it should be assigned a higher priority.

The fact that the skew time adds a sudden demand
for a timer 3 orders of magnitude more accurate
than the advertisement interval has always been
an interesting issue for VRRP, but it becomes even
more dubious when in an attempt to get 0.03s
failover times, you require a timer accurate to
0.0001s. So I, for one, would see it as a good thing
for the required accuracy to be limited to 0.001s
(for my hypothetical ms Skew_Time) or even 0.004s
(for the existing RFC-3768 Skew_Time). The latter,
of course, has the advantage of having one less
difference between the two modes.

-don

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