RE: 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