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

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

Hi Don, 

I'm am okay with all of these changes. 

Steve Nadas 

-----Original Message-----
From: Don Provan [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 7:46 PM
To: [email-masked]; [email-masked]; [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Mukesh Gupta" <[email-masked]>
Date: Wed, 11 Apr 2007 23:36:43 -0700

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

> Sent: Thursday, March 29, 2007 4:46 PM
> > 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.
> 
> 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
>