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

From: <[email-masked]>
Date: Mon, 18 Jun 2007 17:25:12 -0500

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-masked]] 
Sent: Wednesday, April 11, 2007 11:37 PM
To: Don Provan; Tata Kalyan (Nokia-ES/MtView);
[email-masked]; [email-masked]
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-masked]]
> Sent: Thursday, March 29, 2007 4: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

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

---

From: "Don Provan" <[email-masked]>
Date: Mon, 18 Jun 2007 15:43:56 -0700

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 18, 2007 3:25 PM
> To: [email-masked]; [email-masked];
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Mon, 18 Jun 2007 17:54:42 -0500

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-masked]] 
Sent: Monday, June 18, 2007 3:44 PM
To: Tata Kalyan (Nokia-ES/MtView); [email-masked];

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

> please let me know The changes planned.
> 

> 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.
>

---

From: "Mukesh Gupta" <[email-masked]>
Date: Thu, 28 Jun 2007 00:31:22 -0700

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

> To: [email-masked]; Mukesh Gupta;
[email-masked];
> > sub-seconds