Subject: RE: [VRRP] Diffs for the drafts

From: [email-masked]
Date: Fri, 23 May 2003 12:32:01 -0700

I'm in agreement with bob.  ietf standardizing protocol that
requires sub-second timers&processing is going to be a detriment
to more vendors than it helps, and increase potential for 
protocol instability.

to me end-to-end behavior characterizes the user/application
experience.  vrrp typically operates only at the endpoint along the 
end-to-end path.  I see minimal benefit in optimizing this single hop 
for sub-second convergence if failure at other points along the path
requires seconds for convergence.

danny

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

---

From: Jamal Hadi <[email-masked]>
Date: Sat, 24 May 2003 09:51:45 -0400 (EDT)

Ive had experiences with subsecond timing and it works just fine.
Its more implementation specific and hardware limitations mostly that
is being described as a "detriment".
Some OSes (rather implementations) get overwhelmed just handling the
heartbeats at say 100ms intervals. This, however, should not
be an excuse that the advert interval has to be in the second granularity.
"Stabilization" is achievable by mucking with Master_Down_Interval -
should be able to make the number > or < 3 * Advertisement_Interval.
Note, VRRP should be more useful than just for end user experiences
(ex: as the failover link management protcol between a mesh a of L3
switches where lower failover times (think sonet-like) is quiet valuable).

cheers,
jamal