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