RE: Advertisement Interval Vs Timeout

Mukesh,

It seems to me that between the advances made on
the IPv6 effort and restricting the sub-second
timer effort to centisecond timers that are not
in any way interoperable with second timers,
the sub-second effort is now obsolete. (I feel
like I inadvertently laid a trap for it!)

I propose the following:

1. Abandon the work on sub-second timer effort.

2. Allow "Virtual Router Redundancy Protocol for
   IPv6" to continue on track. It's a good document
   that has just the one small improvement we just
   put on the floor open (as far as I know), so
   there's no reason for it to be delayed for
   anything concerning IPv4.

3. Start work on either
  A. "Virtual Router Redundancy Protocol
     version 3 for IPv4", which would be the IPv6
     spec "back ported" to IPv4. This would
     replace RFC-3768.
or
  B. A unified VRRPv3 document which adds IPv4
     handling to the IPv6 specific VRRPv3 RFC
     without changing the IPv6 behavior, intended
     to replace both RFC-3768 and the VRRPv3 IPv6
     RFC.

If there's some reason I'm not aware of why it's
important to do IPv4 sub-second timers specifically
as a new packet type in VRRPv2 packets, that's not
a problem, but I claim the way to approach it now
is technically 3A, but simply cast as a new packet
type rather than as a new protocol version.

-don

-----Original Message-----
From: Mukesh Gupta [mailto:[email protected]] 
Sent: Saturday, April 14, 2007 6:30 PM
To: Don Provan; [email protected]
Subject: RE: [VRRP] Advertisement Interval Vs Timeout

Don,

I like your suggestion about changing the Advertisement_Interval to
Minimum_Advertisement_Interval.  I am assuming that there is no opposition
to this change.  If anybody on the WG thinks that it is a bad idea, please
speak up.

John, what is your opinion on this?  If everybody agrees, please incorporate
this change in the next rev.

Don, section 16 in the VRRPv3 draft can quickly update you on how it is
different than VRRPv2.

I don't like the version number scheme as well but I guess it is too late to
change that now :(  VRRP is not the only protocol with the weird version
numbers for IPv4 and IPv6; OSPF is another one for example.

Let's proceed with the sub-second timer draft as an option to VRRPv2 unless
someone has a better idea.

Regards
Mukesh

> -----Original Message-----
> From: Don Provan [mailto:[email protected]]
> Sent: Saturday, April 14, 2007 2:52 PM
> To: [email protected]
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
> 
> I took Mukesh's advice and looked over the IPv6 -08 spec.
> It's really good! I claim that the draft describes exactly the timer 
> behavior we want (both in IPv4 and IPv6) except for one flaw: it says 
> the master should send an advertisement once every 
> Advertisement_Interval instead of allowing the master to send 
> advertisements at any rate it wants but no
> *slower* than once every Advertisement_Interval.
> 
> If the master were allowed to send at faster rates, more than three 
> advertisements could be sent per timeout interval, which is what 
> people experimenting with faster timeouts tell us they found was 
> necessary for stability in that environment.
> 
> Now, of course, it's a little strange if the Advertisement_Interval 
> isn't the interval the master advertises at. Perhaps we should just 
> rename it Minimum_Advertisement_Interval and call it a day?
> (In a perfect world, I'd want to just rewrite the entire protocol and 
> spec to base everything on the timeout and calculate the minimum 
> advertisement interval from that, but that seems like a lot of work 
> for no gain.)
> 
> I recommend this change for the IPv6 spec, at least.
> 
> But if the VRRPv3 spec is what we want for fast timers, shouldn't we 
> work towards making v3 go both ways? Or making a v3 for IPv4? Or 
> should we just continue on the original path of adding this new time 
> behavior as an option in the
> v2 IPv4 spec? I think I already mentioned that I didn't pay attention 
> to why the VRRPv3 spec was made IPv6 specific, so I don't know how we 
> got where we are, but it seems a shame to have two specs if we don't 
> need them.
> 
> -don


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