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

Thanks Don,
	That will make changes I need to make easier - We will not have
two different units to take care of. 
	
Thanks,
Kalyan

-----Original Message-----
From: ext Don Provan [mailto:[email protected]] 
Sent: Monday, June 18, 2007 3:44 PM
To: Tata Kalyan (Nokia-ES/MtView); [email protected];
[email protected]; [email protected]
Cc: [email protected]
Subject: RE: [VRRP] Reviving draft-ietf-vrrp-ipv4-timers-02

The decision, as I understood it, was to make IPv4 timers just like IPv6
timers. As far as I know, the MIB can march in that direction. Last I
heard, Mukesh was going to discuss with Radia and the ADs whether we
should accomplish the end by "back porting"
the IPv6 timer work to a replacement IPv4 VRRP RFC or by adding the IPv4
specific details to the IPv6 RFC to make it a unified RFC.
I've been pretending to wait for that decision, although the truth is
I've been up to my eyeballs in other things and wouldn't have had many
spare cycles to work on it, anyway.
-don

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, June 18, 2007 3:25 PM
> To: [email protected]; [email protected]; 
> [email protected]; [email protected]
> Cc: [email protected]
> Subject: RE: [VRRP] 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