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

Hi Don,
Was it decided to update draft-ietf-vrrp-ipv4-timers-02? If so, could
please let me know
The changes planned.

I am able to spend some time next week to update the
draft-ietf-vrrp-unified-mib-06
And one of the main change would be to accommodate updated
draft-ietf-vrrp-ipv4-timers-02

Thanks,
Kalyan

-----Original Message-----
From: ext Mukesh Gupta [mailto:[email protected]] 
Sent: Wednesday, April 11, 2007 11:37 PM
To: Don Provan; Tata Kalyan (Nokia-ES/MtView);
[email protected]; [email protected]
Cc: Hott, Robert W CIV B35-Branch
Subject: RE: [VRRP] 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

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