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

Don,

Sorry for replying late.  Have been really busy at work :(

I had an email exchange with Radia and both of us were inclined towards
a unified document but I haven't had a chance to discuss this with ADs.

- Mukesh

> -----Original Message-----
> From: Don Provan [mailto:[email protected]]
> Sent: Monday, June 18, 2007 3:44 PM
> To: [email protected]; Mukesh Gupta;
[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