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

Don,

I like the proposal.  Keeping it simple and getting it out is a better
approach than making is complicated by adding support for every
possibility and then making no progress at all.  The beauty of VRRP was
always its simplicity anyway :)

Can you and Bob work together and submit the next rev of the sub-seconds
draft to incorporate these changes?  It would also be good to think
about what changes will be required in the MIB draft to support the new
sub-seconds draft.

If we have enough things to discuss, we can have a VRRP WG meeting in
Chicago.

Thanks again for picking up this work!

- Mukesh

> -----Original Message-----
> From: Don Provan [mailto:[email protected]]
> Sent: Thursday, March 29, 2007 4:46 PM
> To: [email protected]; [email protected];
[email protected]
> Cc: 'Hott, Robert W CIV B35-Branch'
> Subject: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02
> 
> > Please let me know what will be the major changes
> > to draft-ietf-vrrp-ipv4-timers-02
> > So I can add them to the MIB.
> 
> Well, let's get an idea....
> 
> As I look over the draft, I remember why I lost interest
> in it: it seems like extreme overkill for such a simple
> change. So I'd like to float the following simplifications
> and see if the list can agree on them after a year to
> think about it:
> 
> 1. Eliminate the requirement for interaction between slow
> and fast VRRP implementations: an implementation that
> supports fast timers MUST be configurable to run either
> fast or slow, but all members of the VR must run in the
> same mode. (I'm thinking the modes would be differentiated
> on the wire via the proposed new packet type, so mismatched
> routers would ignore (for slow) or complain about (for fast)
> the other router's packets, and the VR would fall into VRRP's
> standard "ships in the night" failure mode.)
> 
> 2. Eliminate the requirement to support timeouts less
> than 1 centisecond.
> 
> 3. Eliminate the requirement to support timeouts greater
> than 2.55 seconds in fast mode. Longer timeouts can be
> supported by running in slow mode.
> 
> 4. Eliminate the requirement that all VRs clocks tick
> at the same rate: only the timeout time should be
> carried in the protocol packet; the tick rate (i.e.,
> the packet transmission rate) should be a configuration
> option local to the implementation. (I don't see any
> particular advantages for cooperating routers to use
> different tick rates, I just see no reason for the
> protocol to enforce a uniform rate.)
> 
> As I look back on the most recent e-mail on this from
> last summer, it seems as if #4 was actually approaching
> a consensus, but the others may be quite contentious.
> 
> -don provan
> 


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