Subject: [VRRP] Advertisement Interval Vs Timeout

From: "Mukesh Gupta" <[email-masked]>
Date: Wed, 11 Apr 2007 23:22:41 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Sat, 14 Apr 2007 14:51:48 -0700

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

---

From: "Mukesh Gupta" <[email-masked]>
Date: Sat, 14 Apr 2007 18:29:36 -0700

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-masked]]
> Sent: Saturday, April 14, 2007 2:52 PM
> To: [email-masked]
> Subject: RE: [VRRP] Advertisement Interval Vs Timeout
>

---

From: "don provan" <[email-masked]>
Date: Sun, 15 Apr 2007 14:30:00 -0700

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-masked]] 
Sent: Saturday, April 14, 2007 6:30 PM
To: Don Provan; [email-masked]
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.

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

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

---

From: "John Cruz \(johcruz\)" <[email-masked]>
Date: Mon, 16 Apr 2007 08:20:09 -0700

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

---

From: "Mukesh Gupta" <[email-masked]>
Date: Tue, 17 Apr 2007 07:03:43 -0700

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

> From: John Cruz (johcruz) [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 8:20 AM
> To: Mukesh Gupta; Don Provan; [email-masked]

---

From: "John Cruz \(johcruz\)" <[email-masked]>
Date: Tue, 17 Apr 2007 07:53:32 -0700

Hi Mukesh,

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

John 

> Sent: Tuesday, April 17, 2007 7:04 AM
> To: John Cruz (johcruz); Don Provan; [email-masked]

---

From: "don provan" <[email-masked]>
Date: Tue, 17 Apr 2007 09:45:46 -0700

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:[email-masked]] 
Sent: Tuesday, April 17, 2007 7:54 AM
To: Mukesh Gupta; Don Provan; [email-masked]
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 

> > 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
> > 
> > > opposition to this change.  If anybody on the WG thinks that it is 
> > > a bad idea, please speak up.
> > >
> > > Don, section 16 in the VRRPv3 draft can quickly update you on how 
> > > it is different than VRRPv2.
> > >
> > > 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.
> > >

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Tue, 17 Apr 2007 14:00:28 -0700 (PDT)

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 <[email-masked]> wrote:
> more than three advertisements could be sent per
> timeout interval, which is what people experimenting
> with faster timeouts tell us they found was 

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

---

From: Radia Perlman <[email-masked]>
Date: Tue, 17 Apr 2007 14:09:56 -0700

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

---

From: "Don Provan" <[email-masked]>
Date: Tue, 17 Apr 2007 14:23:52 -0700

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

> From: Danny J. Mitzel [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 2:00 PM
> To: [email-masked]

---

From: "Joe Fioramonti XJ \(VI/EUS\)" <[email-masked]>
Date: Wed, 18 Apr 2007 07:05:51 -0500

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.

> Sent: Tuesday, April 17, 2007 5:24 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Don Provan" <[email-masked]>
Date: Wed, 18 Apr 2007 10:40:57 -0700

Joe,

> It is used to validate received packets - packets that
> contain the wrong value are discarded.

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

> From: Joe Fioramonti XJ (VI/EUS) 
> [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 5:06 AM
> To: Don Provan; [email-masked]
> Cc: [email-masked]