Advertisement Interval Vs Timeout

[Mukesh Gupta]

Don/Joe/Steve/Bob,

It is nice to see some energetic discussion on the VRRP mailing list :)

I don't know if you guys have noticed but the latest version of VRRPv3
draft (08) has made a significant change related to Advertisement
Interval and Timeout.  Instead of setting the Master_Down_Interval to
the (3 * configured Advertisement Interval), it is now set to (3 *
Master's Advertisement Interval).

This change effectively makes the field Advertisement Interval in the
packet, a timeout (one third of the timeout, actually) advertised by the
Master.

This change was made to fix the exact problem that Don mentioned.  The
protocol does not need to match the Advertisement Intervals; it needs to
match the Timeout Intervals.

I think the solution in the draft is better at least in one sense.  It
is backwards compatible.  If we change the meaning of the field (from
Advertisement Interval to Timeout), the older implementations will
assume that the value in the packet is Advertisement Interval and will
set their down timer to 3 times that value.  That would cause issues!

One of the downside (and I can't see others) of the solution in the
draft is that the minimum value of the timeout allowed is 3
centiseconds.  It would be 1 centiseconds if the field was changed to be
the timeout.

Does this change address your concerns or you would like to make further
changes?  VRRPv3 is still a draft and we can still make changes to it.
At this stage of the draft, we should not be making any changes that
might not interoperate with the current version of the draft though.

Regards
Mukesh

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Don Provan]

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
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Mukesh Gupta]

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:dprovan@...]
> Sent: Saturday, April 14, 2007 2:52 PM
> To: vrrp@...
> 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
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Don Provan]

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:mukesh.gupta@...]
Sent: Saturday, April 14, 2007 6:30 PM
To: Don Provan; vrrp@...
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:dprovan@...]
> Sent: Saturday, April 14, 2007 2:52 PM
> To: vrrp@...
> 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
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[John Cruz (johcruz)]

Hi,

I haven't looked at the sub-second timer draft yet.
But if the advertisement interval in VRRP for IPv6 can be
as low as 10 ms (1 centisecond), then we can fail-over in
30 ms, right? Isn't this sufficient?

John

> -----Original Message-----
> From: Mukesh Gupta [mailto:mukesh.gupta@...]
> Sent: Saturday, April 14, 2007 6:30 PM
> To: Don Provan; vrrp@...
> 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:dprovan@...]
> > Sent: Saturday, April 14, 2007 2:52 PM
> > To: vrrp@...
> > 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
> vrrp@...
> https://www1.ietf.org/mailman/listinfo/vrrp
>

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Mukesh Gupta]

John,

As far as I remember, it was sufficient for the VRRPv3 (VRRP for IPv6)
but the sub-second draft was trying to fix the same thing for VRRPv2
(VRRP for IPv4) because we did not have enough space for extension of
Advertisement Interval in VRRPv2.

Regards
Mukesh

> -----Original Message-----
> From: John Cruz (johcruz) [mailto:johcruz@...]
> Sent: Monday, April 16, 2007 8:20 AM
> To: Mukesh Gupta; Don Provan; vrrp@...
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>
> Hi,
>
> I haven't looked at the sub-second timer draft yet.
> But if the advertisement interval in VRRP for IPv6 can be
> as low as 10 ms (1 centisecond), then we can fail-over in
> 30 ms, right? Isn't this sufficient?
>
> John
>
> > -----Original Message-----
> > From: Mukesh Gupta [mailto:mukesh.gupta@...]
> > Sent: Saturday, April 14, 2007 6:30 PM
> > To: Don Provan; vrrp@...
> > 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:dprovan@...]
> > > Sent: Saturday, April 14, 2007 2:52 PM
> > > To: vrrp@...
> > > 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
> > vrrp@...
> > https://www1.ietf.org/mailman/listinfo/vrrp
> >

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[John Cruz (johcruz)]

Hi Mukesh,

Then why change Advertisement_Interval to
Minimum_Advertisement_Interval in the VRRP for IPv6 draft?

John

> -----Original Message-----
> From: Mukesh Gupta [mailto:mukesh.gupta@...]
> Sent: Tuesday, April 17, 2007 7:04 AM
> To: John Cruz (johcruz); Don Provan; vrrp@...
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>
> John,
>
> As far as I remember, it was sufficient for the VRRPv3 (VRRP for IPv6)
> but the sub-second draft was trying to fix the same thing for VRRPv2
> (VRRP for IPv4) because we did not have enough space for extension of
> Advertisement Interval in VRRPv2.
>
> Regards
> Mukesh
>
> > -----Original Message-----
> > From: John Cruz (johcruz) [mailto:johcruz@...]
> > Sent: Monday, April 16, 2007 8:20 AM
> > To: Mukesh Gupta; Don Provan; vrrp@...
> > Subject: RE: [VRRP] Advertisement Interval Vs Timeout
> >
> > Hi,
> >
> > I haven't looked at the sub-second timer draft yet.
> > But if the advertisement interval in VRRP for IPv6 can be
> > as low as 10 ms (1 centisecond), then we can fail-over in
> > 30 ms, right? Isn't this sufficient?
> >
> > John
> >
> > > -----Original Message-----
> > > From: Mukesh Gupta [mailto:mukesh.gupta@...]
> > > Sent: Saturday, April 14, 2007 6:30 PM
> > > To: Don Provan; vrrp@...
> > > 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:dprovan@...]
> > > > Sent: Saturday, April 14, 2007 2:52 PM
> > > > To: vrrp@...
> > > > 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
> > > vrrp@...
> > > https://www1.ietf.org/mailman/listinfo/vrrp
> > >
>

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Don Provan]

John,

It's to allow more than 3 advertisements before the timeout.
With this change, an implementation can send an arbitrary
number of advertisements from the master in that 30ms.

-don

-----Original Message-----
From: John Cruz (johcruz) [mailto:johcruz@...]
Sent: Tuesday, April 17, 2007 7:54 AM
To: Mukesh Gupta; Don Provan; vrrp@...
Subject: RE: [VRRP] Advertisement Interval Vs Timeout

Hi Mukesh,

Then why change Advertisement_Interval to Minimum_Advertisement_Interval in
the VRRP for IPv6 draft?

John

> -----Original Message-----
> From: Mukesh Gupta [mailto:mukesh.gupta@...]
> Sent: Tuesday, April 17, 2007 7:04 AM
> To: John Cruz (johcruz); Don Provan; vrrp@...
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>
> John,
>
> As far as I remember, it was sufficient for the VRRPv3 (VRRP for IPv6)
> but the sub-second draft was trying to fix the same thing for VRRPv2
> (VRRP for IPv4) because we did not have enough space for extension of
> Advertisement Interval in VRRPv2.
>
> Regards
> Mukesh
>
> > -----Original Message-----
> > From: John Cruz (johcruz) [mailto:johcruz@...]
> > Sent: Monday, April 16, 2007 8:20 AM
> > To: Mukesh Gupta; Don Provan; vrrp@...
> > Subject: RE: [VRRP] Advertisement Interval Vs Timeout
> >
> > Hi,
> >
> > I haven't looked at the sub-second timer draft yet.
> > But if the advertisement interval in VRRP for IPv6 can be as low as
> > 10 ms (1 centisecond), then we can fail-over in 30 ms, right? Isn't
> > this sufficient?
> >
> > John
> >
> > > -----Original Message-----
> > > From: Mukesh Gupta [mailto:mukesh.gupta@...]
> > > Sent: Saturday, April 14, 2007 6:30 PM
> > > To: Don Provan; vrrp@...
> > > 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:dprovan@...]
> > > > Sent: Saturday, April 14, 2007 2:52 PM
> > > > To: vrrp@...
> > > > 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
> > > vrrp@...
> > > https://www1.ietf.org/mailman/listinfo/vrrp
> > >
>

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Danny J. Mitzel]

I'll admit right up front that I haven't been
following the subsecond timers draft, feel free to
ignore this question if it's already been discussed.


--- Don Provan <dprovan@...> wrote:
> 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.

I'm not understanding why people experimenting with
faster timeouts are claiming more Advertisements
are required to insure VRRP stability?  Stability of
the protocol as currently written is not dependent on
the timeout interval it's dependent on the packet loss
rate (link Bit Error Rate (BER) and/or switch or
router packet drops).  Are the fast timeout
experimenters emulating higher BER or non-linerate
capable switches with high packet drop rates?

I agree that the ability to send Advertisements at a
higher rate can make VRRP more robust in LANs with
extremely high BER or congested switches.  I'm just
trying to understand if there's some claim that this
is required just because the timeout is scaled down?


danny




_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Radia Perlman]

Yeah. It seems like it would be better to advertise "Timeout", and it's
up to the
advertiser how many advertisements to do per timeout period. But I don't see
that mentioned explicitly, even though the subject of this thread is
"advertisement
interval vs timeout".

So, if, for instance, you send hellos every second, and therefore people
time you out
in 3 seconds, you could advertise timeout of 3 seconds, and send as many
hellos
during that interval as you want, in order to account for lossiness of
the link.

As Danny said -- the lossiness is an orthogonal aspect of the link, from
speed.

And as for backward compatibility -- if some people are expecting the
field to
be "interval between hellos" and others are expecting it to be "time to
declare me down",
and what is advertised is "time to declare me down", the only bad thing
that would happen
is that the former listeners will take 3 times as long to declare you down.

Radia


Danny J. Mitzel wrote:

> I'll admit right up front that I haven't been
> following the subsecond timers draft, feel free to
> ignore this question if it's already been discussed.
>
>
> --- Don Provan <dprovan@...> wrote:
>  
>> 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.
>>    
>
> I'm not understanding why people experimenting with
> faster timeouts are claiming more Advertisements
> are required to insure VRRP stability?  Stability of
> the protocol as currently written is not dependent on
> the timeout interval it's dependent on the packet loss
> rate (link Bit Error Rate (BER) and/or switch or
> router packet drops).  Are the fast timeout
> experimenters emulating higher BER or non-linerate
> capable switches with high packet drop rates?
>
> I agree that the ability to send Advertisements at a
> higher rate can make VRRP more robust in LANs with
> extremely high BER or congested switches.  I'm just
> trying to understand if there's some claim that this
> is required just because the timeout is scaled down?
>
>
> danny
>
>
>
>
> _______________________________________________
> vrrp mailing list
> vrrp@...
> https://www1.ietf.org/mailman/listinfo/vrrp
>  

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Don Provan]

Danny,

Actually I agree with you 100%, and I made similar
arguments earlier. Theoretically, this result doesn't
make sense and I suspect it really means something
else is going on that we don't yet understand.

Nevertheless, since *I* was not (and am still not)
in a position to get any hands on experience, I felt
I should defer to the people that were actually seeing
the issues first hand, even when the protocol itself
was being complicated by the issue, as was the case
then.

Happily, as things stand now (with the Minimum
Advert Int), it's no longer a protocol issue at all,
and we can leave it to administrators actually in the
field with real operational environments to adjust
this value if they find they need to. The cost to
the protocol itself is now essentially zero: "less
than or equal to" vs. just "equal to", and even that's
in the implementation, not the protocol description.

(Well, except I guess it makes sense to add an
"actual advert interval" to the MIB, although I
hate to say it.)

-don

> -----Original Message-----
> From: Danny J. Mitzel [mailto:mitzel@...]
> Sent: Tuesday, April 17, 2007 2:00 PM
> To: vrrp@...
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>
>
> I'll admit right up front that I haven't been
> following the subsecond timers draft, feel free to
> ignore this question if it's already been discussed.
>
>
> --- Don Provan <dprovan@...> wrote:
> > 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.
>
> I'm not understanding why people experimenting with
> faster timeouts are claiming more Advertisements
> are required to insure VRRP stability?  Stability of
> the protocol as currently written is not dependent on
> the timeout interval it's dependent on the packet loss
> rate (link Bit Error Rate (BER) and/or switch or
> router packet drops).  Are the fast timeout
> experimenters emulating higher BER or non-linerate
> capable switches with high packet drop rates?
>
> I agree that the ability to send Advertisements at a
> higher rate can make VRRP more robust in LANs with
> extremely high BER or congested switches.  I'm just
> trying to understand if there's some claim that this
> is required just because the timeout is scaled down?
>
>
> danny
>
>
>
>
> _______________________________________________
> vrrp mailing list
> vrrp@...
> https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Joe Fioramonti XJ (VI/EUS)]

Both RFC3768 and draft-ietf-vrrp-ipv6-spec-08 state that the
Advertisement Interval, which is included in ADVERTISEMENT packets, is
used for troubleshooting misconfigured routers.  It is used to validate
received packets - packets that contain the wrong value are discarded.
The routers use their locally configured intervals to actually time out.

Are we suggesting some other behavior?

--Joe.

> -----Original Message-----
> From: Don Provan [mailto:dprovan@...]
> Sent: Tuesday, April 17, 2007 5:24 PM
> To: mitzel@...
> Cc: vrrp@...
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>
> Danny,
>
> Actually I agree with you 100%, and I made similar
> arguments earlier. Theoretically, this result doesn't
> make sense and I suspect it really means something
> else is going on that we don't yet understand.
>
> Nevertheless, since *I* was not (and am still not)
> in a position to get any hands on experience, I felt
> I should defer to the people that were actually seeing
> the issues first hand, even when the protocol itself
> was being complicated by the issue, as was the case
> then.
>
> Happily, as things stand now (with the Minimum
> Advert Int), it's no longer a protocol issue at all,
> and we can leave it to administrators actually in the
> field with real operational environments to adjust
> this value if they find they need to. The cost to
> the protocol itself is now essentially zero: "less
> than or equal to" vs. just "equal to", and even that's
> in the implementation, not the protocol description.
>
> (Well, except I guess it makes sense to add an
> "actual advert interval" to the MIB, although I
> hate to say it.)
>
> -don
>
> > -----Original Message-----
> > From: Danny J. Mitzel [mailto:mitzel@...]
> > Sent: Tuesday, April 17, 2007 2:00 PM
> > To: vrrp@...
> > Subject: RE: [VRRP] Advertisement Interval Vs Timeout
> >
> >
> > I'll admit right up front that I haven't been
> > following the subsecond timers draft, feel free to
> > ignore this question if it's already been discussed.
> >
> >
> > --- Don Provan <dprovan@...> wrote:
> > > 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.
> >
> > I'm not understanding why people experimenting with
> > faster timeouts are claiming more Advertisements
> > are required to insure VRRP stability?  Stability of
> > the protocol as currently written is not dependent on
> > the timeout interval it's dependent on the packet loss
> > rate (link Bit Error Rate (BER) and/or switch or
> > router packet drops).  Are the fast timeout
> > experimenters emulating higher BER or non-linerate
> > capable switches with high packet drop rates?
> >
> > I agree that the ability to send Advertisements at a
> > higher rate can make VRRP more robust in LANs with
> > extremely high BER or congested switches.  I'm just
> > trying to understand if there's some claim that this
> > is required just because the timeout is scaled down?
> >
> >
> > danny
> >
> >
> >
> >
> > _______________________________________________
> > vrrp mailing list
> > vrrp@...
> > https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp@...
https://www1.ietf.org/mailman/listinfo/vrrp

[Don Provan]

Joe,

> It is used to validate received packets - packets that
> contain the wrong value are discarded.
> The routers use their locally configured intervals to
> actually time out.

This is true in RFC-3768, but it's different in spec-08.
In VRRPv3, the receiver notes and SHOULD report the
discrepancy, but rather than discarding the packet, it
uses the *received* interval to calculate the timeout.

This is one of several little things that I've noticed
were tightened up in the v3 spec that makes me suggest
starting with that spec for any IPv4 specific fast
timer work.

-don

> -----Original Message-----
> From: Joe Fioramonti XJ (VI/EUS)
> [mailto:joe.xj.fioramonti@...]
> Sent: Wednesday, April 18, 2007 5:06 AM
> To: Don Provan; mitzel@...
> Cc: vrrp@...
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>
>
> Both RFC3768 and draft-ietf-vrrp-ipv6-spec-08 state that the
> Advertisement Interval, which is included in ADVERTISEMENT packets, is
> used for troubleshooting misconfigured routers.  It is used
> to validate
> received packets - packets that contain the wrong value are discarded.
> The routers use their locally configured intervals to
> actually time out.
>
> Are we suggesting some other behavior?
>
> --Joe.
>
> > -----Original Message-----
> > From: Don Provan [mailto:dprovan@...]
> > Sent: Tuesday, April 17, 2007 5:24 PM
> > To: mitzel@...
> > Cc: vrrp@...
> > Subject: RE: [VRRP] Advertisement Interval Vs Timeout
> >
> > Danny,
> >
> > Actually I agree with you 100%, and I made similar
> > arguments earlier. Theoretically, this result doesn't
> > make sense and I suspect it really means something
> > else is going on that we don't yet understand.
> >
> > Nevertheless, since *I* was not (and am still not)
> >