Subject: [VRRP] draft-ietf-vrrp-unified-spec-00 issues

From: "Steve Bates" <[email-masked]>
Date: Thu, 10 Jan 2008 14:41:53 -0700

Two issues:

Back when Bob Hott first proposed the subsecond failover draft I raised the
issue of futureproofing VRRP and I would like to raise it again now.  We are
seeing more and more requests to support rates of failure detection this
draft addresses but it seems likely that in another decade, with terabit
speed links for example, that we will see demands for failure detection 100
times faster than we currently address.  Utilizing the bits in the rsvd
field of the packet to define granularity, an inverse log function could be
used to represent granularity from 10**0 to 10**-15 (where the negative of
the field value is the exponent) giving us an insanely fine granularity.
This would help us avoid generating a new RFC when faster failure detection
rates are required.  If it weren't for the version field it might also help
with migration since a packet with a granularity of 0 would look identical
to the v2 packet (assuming authentication is off the table) and the
advertisement interval would mean the same thing (seconds). 

The second issue involves a backup virtual router accepting a masters
advertising interval.  It would be interesting to know why RFC 2338 didn't
do this in the first place.  Was it for simplicity or just oversight?  As
proposed this represents a pretty one sided negotiation.  For a backup on a
device lacking horsepower or resources a master sending advertisements every
centisecond might as well be initiating a denial of service attack.  A
clever backup might reject the faster rate and instead become master and
send advertisements at its maximum acceptable rate.  An equally clever
master would notice that it keeps getting advertisements from a lower
priority virtual router and adjust its rate appropriately until the backup
submits.  A granularity field might be a better way to accomplish this.  

Steve

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

---

From: "Don Provan" <[email-masked]>
Date: Thu, 10 Jan 2008 15:54:13 -0800

> submits.  A granularity field might be a better way to accomplish this.  

It *is* a one sided negotiation: the user configures the
higher priority router's timeout interval specifically to
control when the *backup* will take over. The user's decision
has to be based on the abilities of the backup system to
actually take over in the configured amount of time. It is
just a fluke of the protocol that that amount of time has to
be configured on the *failing* system.

It makes very little sense to me to build into the protocol
a procedure to second guess the user's decision about the fail
over requirements of the virtual router.

To me, this all becomes clearer when I consider what it really
means when two routers have different intervals configured. The
interval of the lower priority router means *nothing whatsoever*
to the speed of failover *to* that router: it *only* controls
how fast a yet lower priority router will take over from the
middle backup. The lack of symmetry in the intervals is easy to
overlook, and my guess as to why different intervals weren't
considered in the earlier versions is that everyone thought
of the intervals as being symmetric.

-don provan

---

From: "Steve Bates" <[email-masked]>
Date: Fri, 11 Jan 2008 11:48:52 -0700

Hi Don,

Let me explain where I'm coming from on this.  I certainly can't speak for
the others on the list, but I suspect almost none of my users share your
view on the asymmetry of the advertisement interval.  I would be pleasantly
surprised if ten percent of them knew that the advertisement interval was
part of the advertisement, and really surprised if any of them thought that
the value they configured on the master was intended for the backup.  There
are at least two reasons for this.  First, almost all of them run with very
symmetric configurations.  Interestingly, they actually use the model we
describe in example one for individual LANs (the one the RFC felt was going
to be less common), but they run many LANs on a device.  They do load
splitting by making the virtual routers for half of the LANs master on one
device and half on another.  The two devices are viewed as peers, not as
master and slave.  Their virtual router configurations for each device are
almost identical, but they usually have some criteria to make the priority
higher for half the virtual routers on one device and half on the other.
It's usually something like the odd VRIDs have higher priority on  device A,
the even VRIDs have higher priority on device B.  I have never seen a
customer setup with multiple backups.  That doesn't mean there aren't any,
they're just few and far between.  The second reason is implementation
based.  Simply stated, based on the current RFC, the participants in the
virtual router must have the same advertisement interval, otherwise VRRP
doesn't work.  This is not a fluke.  

So from my perspective the change in the draft to accept the masters
advertisement interval is an effort to "keep it running" in spite of a
misconfiguration.  It will also be useful in migrating to new interval
values but this leads to the scenario I'm worried about.  My users seldom
misconfigure one virtual router - typically they misconfigure all the
virtual routers on a device.  Assume a setup like I described above in which
the user has twenty virtual routers, and she misconfigures all the virtual
routers on one device with an interval of one instead of 100.  Upon reboot,
there may be a burst of advertisements from the 10 virtual routers that are
supposed to be in a backup state but eventually they will hear the
advertisements from the other device and (thanks to the change we've made in
the draft) they will accept the advertised interval and revert to backup.
The 10 virtual routers with higher priority however do not stop advertising,
so the other device instead of receiving the 10 advertisements per second it
expected and could safely handle, now receives 1000 advertisements per
second and not being able to support that additional load it hangs, or
crashes. 

I realize this is exception upon exception, but I worry that we may be
taking a protocol induced problem that was bad (double masters) and
replacing it with a protocol induced problem that's disastrous.  The
protocol doesn't have to require a negotiation step, just be flexible enough
to allow it, and I think the draft as written does that.  The question is is
the cure worse than the disease?   

Steve 

-----Original Message-----
From: Don Provan [mailto:[email-masked]] 
Sent: Thursday, January 10, 2008 4:54 PM
To: 'Steve Bates'; 'Stephen Nadas'; [email-masked]
Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues

> advertising interval.  It would be interesting to know why RFC 2338 
> didn't do this in the first place.  Was it for simplicity or just 
> oversight?  As proposed this represents a pretty one sided 
> negotiation.  For a backup on a device lacking horsepower or resources 
> a master sending advertisements every centisecond might as well be 
> initiating a denial of service attack.  A clever backup might reject 
> the faster rate and instead become master and send advertisements at 
> its maximum acceptable rate.  An equally clever master would notice 
> that it keeps getting advertisements from a lower priority virtual 
> router and adjust its rate appropriately until the backup submits.  A
granularity field might be a better way to accomplish this.

It *is* a one sided negotiation: the user configures the higher priority
router's timeout interval specifically to control when the *backup* will
take over. The user's decision has to be based on the abilities of the
backup system to actually take over in the configured amount of time. It is
just a fluke of the protocol that that amount of time has to be configured
on the *failing* system.

It makes very little sense to me to build into the protocol a procedure to
second guess the user's decision about the fail over requirements of the
virtual router.

To me, this all becomes clearer when I consider what it really means when
two routers have different intervals configured. The interval of the lower
priority router means *nothing whatsoever* to the speed of failover *to*
that router: it *only* controls how fast a yet lower priority router will
take over from the middle backup. The lack of symmetry in the intervals is
easy to overlook, and my guess as to why different intervals weren't
considered in the earlier versions is that everyone thought of the intervals
as being symmetric.

-don provan

---

From: "Don Provan" <[email-masked]>
Date: Fri, 11 Jan 2008 12:43:27 -0800

Hi, Steve,

First, the principle advantage of this change is that
it allows the interval to be changed by reconfiguring
routers one at a time. The original spec forced the
user to change all routers at the same time least the
network be confused with two masters during the switch
over. For this reason alone, I consider the change to
be a big improvement.

But let's look at the problem case you have brought up:
a router misconfigured with a cripplingly short interval.
The change from rejection to acquiescence has two
negative effects on this problem:

N1. Because the rejected packet is dropped earlier,
there's less VRRP processing done on it than if we
accept it for processing. I assume this is negligible,
but perhaps you don't.

N2. A rejected packet might cause an alarm.

On the other hand, acquiescence also has a couple of
advantageous effects on the same problem:

A1. As you pointed out, a misconfigured backup will
learn and use the correct value from the master. In
other words, the problem will be resolved. Without
this change, not only will the backup keep spewing at
the crippling rate, it will also continuously seize
control of the VR.

A2. A backup facing a misconfigured master will stay
out of the way instead of try to announce its control
of the VR at its configured pace.

These advantages are even more useful when the
misconfigured interval is merely different, but not
crippling. To me, this is what wins the day. The
much more typical misconfiguration would be forgetting
which of a range of reasonable values was actually
selected, something the new approach just deals with
in a perfectly reasonable manner, but the old approach
leaves with two battling routers arguing over the VR
until the problem is sorted out.

In your previous mail, I think you were suggesting
what amounted to an actual two way negotiation.
Personally, I don't think we want to open the protocol
up to that kind of thing, but the central problem to
it is that, in the end, one has to decide whether the
slower value or the faster value is correct. A VR
misconfigured to fail over too slowly would also be
a problem, and one made harder to sort out when the
master router's interval is configured correctly.
As spec'd, we've made the arbitrary but equally
reasonable choice of saying the master's time is
always considered the correct one.

As to the user's understanding of the meaning of the
interval, that's something of an interface issue.
Yeah, if you follow the lead of the spec and talk
about xmit rates, the user will probably miss the
point. But if you document that value as failover
time and highlight the backup system's role in a
failover, the number might be better understood.
After all, the value is what it is, regardless of
how a user might misinterpret it.

By the way, one last thing. You mentioned the fact
that, of course, no one really has multiple tiers
of routers in a VR. Quite true. But I think the most
interesting variation in interval is in that lowest
priority router (i.e., the second router in any existing
deployment): it makes a great deal of sense to configure
this router with a much longer interval since the *only*
effect of its announcements is to train the switch.
Now I probably wouldn't bring this up to a user, since
I don't really want them considering anything other
than setting all the intervals the same except during a
reconfiguration, but I find it an illuminating observation.

-don provan

> From: Steve Bates [mailto:[email-masked]]
> Sent: Friday, January 11, 2008 10:49 AM
> To: 'Don Provan'; 'Stephen Nadas'; [email-masked]
> higher priority

---

From: "Steve Bates" <[email-masked]>
Date: Fri, 11 Jan 2008 14:19:41 -0700

Hi Don,

First of all let me say I appreciate your comments tremendously.  Let me try
to reframe my concern.

Must a backup accept the interval of the master to be considered compliant
with the spec?  

Steve 

-----Original Message-----
From: Don Provan [mailto:[email-masked]] 
Sent: Friday, January 11, 2008 1:43 PM
To: 'Steve Bates'
Cc: 'Stephen Nadas'; [email-masked]
Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues

Hi, Steve,

First, the principle advantage of this change is that it allows the interval
to be changed by reconfiguring routers one at a time. The original spec
forced the user to change all routers at the same time least the network be
confused with two masters during the switch over. For this reason alone, I
consider the change to be a big improvement.

But let's look at the problem case you have brought up:
a router misconfigured with a cripplingly short interval.
The change from rejection to acquiescence has two negative effects on this
problem:

N1. Because the rejected packet is dropped earlier, there's less VRRP
processing done on it than if we accept it for processing. I assume this is
negligible, but perhaps you don't.

On the other hand, acquiescence also has a couple of advantageous effects on
the same problem:

A1. As you pointed out, a misconfigured backup will learn and use the
correct value from the master. In other words, the problem will be resolved.
Without this change, not only will the backup keep spewing at the crippling
rate, it will also continuously seize control of the VR.

A2. A backup facing a misconfigured master will stay out of the way instead
of try to announce its control of the VR at its configured pace.

These advantages are even more useful when the misconfigured interval is
merely different, but not crippling. To me, this is what wins the day. The
much more typical misconfiguration would be forgetting which of a range of
reasonable values was actually selected, something the new approach just
deals with in a perfectly reasonable manner, but the old approach leaves
with two battling routers arguing over the VR until the problem is sorted
out.

In your previous mail, I think you were suggesting what amounted to an
actual two way negotiation.
Personally, I don't think we want to open the protocol up to that kind of
thing, but the central problem to it is that, in the end, one has to decide
whether the slower value or the faster value is correct. A VR misconfigured
to fail over too slowly would also be a problem, and one made harder to sort
out when the master router's interval is configured correctly.
As spec'd, we've made the arbitrary but equally reasonable choice of saying
the master's time is always considered the correct one.

As to the user's understanding of the meaning of the interval, that's
something of an interface issue.
Yeah, if you follow the lead of the spec and talk about xmit rates, the user
will probably miss the point. But if you document that value as failover
time and highlight the backup system's role in a failover, the number might
be better understood.
After all, the value is what it is, regardless of how a user might
misinterpret it.

By the way, one last thing. You mentioned the fact that, of course, no one
really has multiple tiers of routers in a VR. Quite true. But I think the
most interesting variation in interval is in that lowest priority router
(i.e., the second router in any existing
deployment): it makes a great deal of sense to configure this router with a
much longer interval since the *only* effect of its announcements is to
train the switch.
Now I probably wouldn't bring this up to a user, since I don't really want
them considering anything other than setting all the intervals the same
except during a reconfiguration, but I find it an illuminating observation.

-don provan

> Let me explain where I'm coming from on this.  I certainly can't speak 
> for the others on the list, but I suspect almost none of my users 
> share your view on the asymmetry of the advertisement interval.  I 
> would be pleasantly surprised if ten percent of them knew that the 
> advertisement interval was part of the advertisement, and really 
> surprised if any of them thought that the value they configured on the 
> master was intended for the backup.  There are at least two reasons 
> for this.  First, almost all of them run with very symmetric 
> configurations.  Interestingly, they actually use the model we 
> describe in example one for individual LANs (the one the RFC felt was 
> going to be less common), but they run many LANs on a device.  They do 
> load splitting by making the virtual routers for half of the LANs 
> master on one device and half on another.  The two devices are viewed 
> as peers, not as master and slave.  Their virtual router 
> configurations for each device are almost identical, but they usually 
> have some criteria to make the priority higher for half the virtual 
> routers on one device and half on the other.
> It's usually something like the odd VRIDs have higher priority on  
> device A, the even VRIDs have higher priority on device B.  I have 
> never seen a customer setup with multiple backups.  That doesn't mean 
> there aren't any, they're just few and far between.  The second reason 
> is implementation based.  Simply stated, based on the current RFC, the 
> participants in the virtual router must have the same advertisement 
> interval, otherwise VRRP doesn't work.  This is not a fluke.
> 
> values but this leads to the scenario I'm worried about.  My users 
> seldom misconfigure one virtual router - typically they misconfigure 
> all the virtual routers on a device.  Assume a setup like I described 
> above in which the user has twenty virtual routers, and she 
> misconfigures all the virtual routers on one device with an interval 
> of one instead of 100.
>  Upon reboot,
> there may be a burst of advertisements from the 10 virtual routers 
> that are supposed to be in a backup state but eventually they will 
> hear the advertisements from the other device and (thanks to the 
> change we've made in the draft) they will accept the advertised 
> interval and revert to backup.
> The 10 virtual routers with higher priority however do not stop 
> advertising, so the other device instead of receiving the 10 
> advertisements per second it expected and could safely handle, now 
> receives 1000 advertisements per second and not being able to support 
> that additional load it hangs, or crashes.
> 
> protocol doesn't have to require a negotiation step, just be flexible 
> enough to allow it, and I think the draft as written does that.  The 
> question is is
> It *is* a one sided negotiation: the user configures the higher 
> priority router's timeout interval specifically to control when the
> *backup* will
> backup system to actually take over in the configured amount of time. 
> It is just a fluke of the protocol that that amount of time has to be 
> configured on the *failing* system.
> 
> It makes very little sense to me to build into the protocol a 
> procedure to second guess the user's decision about the fail over 
> requirements of the virtual router.
> 
> To me, this all becomes clearer when I consider what it really means 
> when two routers have different intervals configured. The interval of 
> the lower priority router means *nothing whatsoever* to the speed of 
> failover *to* that router: it *only* controls how fast a yet lower 
> priority router will take over from the middle backup. The lack of 
> symmetry in the intervals is easy to overlook, and my guess as to why 
> different intervals weren't considered in the earlier versions is that 
> everyone thought of the intervals as being symmetric.
> 
> -don provan
> 
>

---

From: "Don Provan" <[email-masked]>
Date: Fri, 11 Jan 2008 13:34:18 -0800

Hi, Steve,

My interpretation would be that, yes, to be compliant a backup
has to do its best to take over the VR according to the time
table defined by the master's interval as seen in arriving
announcements. It would clearly not be compliant to ignore the
arriving announcements and start sending its own.

What alternative behavior do you have in mind? Is your concern
the missing alarm, or is there more to it that I'm missing?
-don

> Sent: Friday, January 11, 2008 1:20 PM
> To: 'Don Provan'
> Cc: [email-masked]

---

From: "Steve Bates" <[email-masked]>
Date: Mon, 14 Jan 2008 10:51:43 -0700

Don,

My concern is that badly mismatched intervals can adversely impact the
entire platform on which VRRP is running.  While it may not be desirable to
write the protocol to mitigate this situation completely, it seems
irresponsible to not address the issue at all.  At the very least it would
seem a backup that believes it is about to be swamped could log/indicate the
situation and remove itself from the virtual router by reverting to
initializing.  A hung backup is of no use anyway.

Steve

-----Original Message-----
From: Don Provan [mailto:[email-masked]] 
Sent: Friday, January 11, 2008 2:34 PM
To: 'Steve Bates'
Cc: [email-masked]
Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues

Hi, Steve,

My interpretation would be that, yes, to be compliant a backup has to do its
best to take over the VR according to the time table defined by the master's
interval as seen in arriving announcements. It would clearly not be
compliant to ignore the arriving announcements and start sending its own.

What alternative behavior do you have in mind? Is your concern the missing
alarm, or is there more to it that I'm missing?
-don

> First of all let me say I appreciate your comments tremendously.  Let 
> me try to reframe my concern.
> 
> Must a backup accept the interval of the master to be considered 
> compliant with the spec?
> 
> Steve
> 
> First, the principle advantage of this change is that it allows the 
> interval to be changed by reconfiguring routers one at a time. The 
> original spec forced the user to change all routers at the same time 
> least the network be confused with two masters during the switch over. 
> For this reason alone, I consider the change to be a big improvement.
> 
> processing done on it than if we accept it for processing. I assume 
> this is negligible, but perhaps you don't.
> 
> On the other hand, acquiescence also has a couple of advantageous 
> effects on the same problem:
> 
> Without this change, not only will the backup keep spewing at the 
> crippling rate, it will also continuously seize control of the VR.
> 
> A2. A backup facing a misconfigured master will stay out of the way 
> instead of try to announce its control of the VR at its configured 
> pace.
> 
> These advantages are even more useful when the misconfigured interval 
> is merely different, but not crippling. To me, this is what wins the 
> day. The much more typical misconfiguration would be forgetting which 
> of a range of reasonable values was actually selected, something the 
> new approach just deals with in a perfectly reasonable manner, but the 
> old approach leaves with two battling routers arguing over the VR 
> Personally, I don't think we want to open the protocol up to that kind 
> of thing, but the central problem to it is that, in the end, one has 
> to decide whether the slower value or the faster value is correct. A 
> VR misconfigured to fail over too slowly would also be a problem, and 
> one made harder to sort out when the master router's interval is 
> configured correctly.
> As spec'd, we've made the arbitrary but equally reasonable choice of 
> saying the master's time is always considered the correct one.
> 
> Yeah, if you follow the lead of the spec and talk about xmit rates, 
> the user will probably miss the point. But if you document that value 
> as failover time and highlight the backup system's role in a failover, 
> the number might be better understood.
> By the way, one last thing. You mentioned the fact that, of course, no 
> one really has multiple tiers of routers in a VR. Quite true. But I 
> think the most interesting variation in interval is in that lowest 
> deployment): it makes a great deal of sense to configure this router 
> with a much longer interval since the *only* effect of its 
> announcements is to train the switch.
> Now I probably wouldn't bring this up to a user, since I don't really 
> want them considering anything other than setting all the intervals 
> the same except during a reconfiguration, but I find it an 
> illuminating observation.
> 
> -don provan
>

---

From: "Stephen Nadas" <[email-masked]>
Date: Mon, 14 Jan 2008 12:15:55 -0600

Hi Don & Steve,  

I am a little confused as to what is now needed or wanted here.

1) I think it's straightforward to use the (rsvd) bits as suggested to
signal the granulatity.  No one has commented on this part so I guess
means the list is okay with this (this is a _hint_ to list lurkers).  It
would default to 2 (decimal) meaning 10**-2 sec, i.e., centiseconds.  I
do think perhaps 10**-7 (tenths of nanosecs?) is surely enough
granularity and that still reserves one bit. 

2) re the below discussion.  I don't think the spec, as is, precludes
the clever backup and/or master implementations mentioned by Steve early
in the thread and that may make sense for some implementations.  It
seems to me that adding protocol support for more than this is wandering
into the feature creep area that Bob Hinden was worried about some time
ago; so I don't favor it.  I agree w/Don wrt "to be compliant a backup
has to do its best to take over the VR according to the time table
defined by the master's interval as seen in 
arriving announcements." 

So, does this approach, ie, just "use reserved bits for signaling
granularity" capture the essence?

Thanks,
Steve 

Stephen Nadas                           Ericsson IPI       
[email-masked] (eudstna)    920 Main Campus Dr. 
Voice:  +1-919-472-9935 Fax: x/9999     Suite 500 
Mobile: +1-919-522-0991 ECN: 802 29935  Raleigh, NC 27606

> Sent: Friday, January 11, 2008 4:34 PM
> To: 'Steve Bates'
> Cc: [email-masked]
> My interpretation would be that, yes, to be compliant a 
> backup has to do its best to take over the VR according to 
> the time table defined by the master's interval as seen in 
> arriving announcements. It would clearly not be compliant to 
> ignore the arriving announcements and start sending its own.
> 
> What alternative behavior do you have in mind? Is your 
> concern the missing alarm, or is there more to it that I'm missing?
> -don
> 
> > The change from rejection to acquiescence has two negative 
> effects on 
> > this
> > problem:
> > 
> misconfigured interval 
> this router

---

From: Radia Perlman <[email-masked]>
Date: Mon, 14 Jan 2008 11:36:29 -0800

I don't really understand the issue, so let me say it in different 
words. Are you concerned that a master would have
such a short Hello interval that a backup would be totally swamped 
processing the VRRP messages?

As you just said, a backup doesn't need to do very much -- the only 
thing a backup needs to do is process VRRP messages.
I'd think no matter how fast VRRP messages are coming, if that's the 
router's only job, it ought to be able to keep up.

Also, it seems like if the backup uses a longer "give up" timer than it 
should, that would be OK -- it would mean it would
take longer for the wimpy backup to take over. So if the master says 
"I'm sending Hellos every microsecond" and the backup
says "I can only process one packet a second, so I'll wait for 5 seconds 
before giving up on the master", then even if the
backup loses almost all the VRRP messages from the master, it won't 
mistakenly take over for the master.

The dangerous mismatch is if the backup has a faster timer, i.e., the 
backup things VRRP messages ought to be, say, every second,
and the master thinks they ought to be every 10 seconds. If the backup 
ignores the master's timer, then the backup will keep trying
to become master. In that case the problem is totally solved by having 
the backup use the master's timer.

In the other case (the master being faster than the backup can handle), 
I think the backup should try its best, but it's OK if the
backup is slow to take over, because the backup can't think that fast.

Mostly I'm just confused about what the problem is.

Radia

Steve Bates wrote:
>>> Let me explain where I'm coming from on this.  I certainly 
>>>       
>> can't speak 
>>     
>>> surprised if any of them thought that the value they 
>>>       
>> configured on the 
>>     
>>> describe in example one for individual LANs (the one the 
>>>       
>> RFC felt was 
>>     
>>> going to be less common), but they run many LANs on a 
>>>       
>> device.  They do 
>>     
>>> master on one device and half on another.  The two devices 
>>>       
>> are viewed 
>>     
>>> configurations for each device are almost identical, but 
>>>       
>> they usually 
>>     
>>> never seen a customer setup with multiple backups.  That 
>>>       
>> doesn't mean 
>>     
>>> there aren't any, they're just few and far between.  The 
>>>       
>> second reason 
>>     
>>> is implementation based.  Simply stated, based on the 
>>>       
>> current RFC, the 
>>     
>>> So from my perspective the change in the draft to accept 
>>>       
>> the masters 
>>     
>>> advertisement interval is an effort to "keep it running" in 
>>>       
>> spite of a 
>>     
>>> misconfiguration.  It will also be useful in migrating to 
>>>       
>> new interval 
>>     
>>> seldom misconfigure one virtual router - typically they 
>>>       
>> misconfigure 
>>     
>>> all the virtual routers on a device.  Assume a setup like I 
>>>       
>> described 
>>     
>>> misconfigures all the virtual routers on one device with an 
>>>       
>> interval 
>>     
>>> of one instead of 100.
>>>  Upon reboot,
>>> receives 1000 advertisements per second and not being able 
>>>       
>> to support 
>>     
>>> I realize this is exception upon exception, but I worry 
>>>       
>> that we may be 
>>     
>>> replacing it with a protocol induced problem that's 
>>>       
>> disastrous.  The 
>>     
>>> protocol doesn't have to require a negotiation step, just 
>>>       
>> be flexible 
>>     
>>> enough to allow it, and I think the draft as written does 
>>>       
>> that.  The 
>>     
>>> question is is
>>>> The second issue involves a backup virtual router accepting
>>>>         
>>> a masters
>>>       
>>>> advertising interval.  It would be interesting to know 
>>>>         
>> why RFC 2338 
>>     
>>>> negotiation.  For a backup on a device lacking horsepower
>>>>         
>>> or resources
>>>       
>>>> a master sending advertisements every centisecond might 
>>>>         
>> as well be 
>>     
>>>> initiating a denial of service attack.  A clever backup
>>>>         
>>> might reject
>>>       
>>>> the faster rate and instead become master and send
>>>>         
>>> advertisements at
>>>       
>>>> its maximum acceptable rate.  An equally clever master 
>>>>         
>> would notice 
>>     
>>>> that it keeps getting advertisements from a lower 
>>>>         
>> priority virtual 
>>     
>>>> router and adjust its rate appropriately until the backup
>>>>         
>>> submits.  A
>>> take over. The user's decision has to be based on the 
>>>       
>> abilities of the 
>>     
>>> backup system to actually take over in the configured 
>>>       
>> amount of time. 
>>     
>>> It is just a fluke of the protocol that that amount of time 
>>>       
>> has to be 
>>     
>>> To me, this all becomes clearer when I consider what it 
>>>       
>> really means 
>>     
>>> when two routers have different intervals configured. The 
>>>       
>> interval of 
>>     
>>> the lower priority router means *nothing whatsoever* to the 
>>>       
>> speed of 
>>     
>>> symmetry in the intervals is easy to overlook, and my guess 
>>>       
>> as to why 
>>     
>>> different intervals weren't considered in the earlier 
>>>       
>> versions is that 
>>

---

From: "Don Provan" <[email-masked]>
Date: Mon, 14 Jan 2008 11:40:35 -0800

But the problem you are describing isn't mismatched intervals,
it's an interval that's too short; the problem is the same
even if the master and backup are both configured to the same
interval.
-don

> Sent: Monday, January 14, 2008 9:52 AM
> To: 'Don Provan'
> Cc: [email-masked]
> backup has to do its
> concern the missing

---

From: "Don Provan" <[email-masked]>
Date: Mon, 14 Jan 2008 12:03:52 -0800

I don't have a good feel for the rate issue, but I dislike
unnecessary complication. Historically, the VRRP failover
time has been dominated by the protocol's increased overhead
at smaller times, but at some point the time starts to be
dominated by the time it takes for the infrastructure to
adjust to a failover such as switch learning and spanning
tree. The question is this: "Is the 3 centisecond limit
for failover time approaching the point at which the time
it takes the infrastructure to adjust is more significant?"
Would simply reducing the units to milliseconds or tenths
of milliseconds -- certainly possible within the field,
particularly if we use the reserved bits -- get us down
to that point? If so, I would prefer that to having a
variable/scaled interval. Scaling was proposed earlier,
and my vague recollection is that it was rejected, but
I don't recall who rejected it or why.

Having said that, I don't really mean to argue against
scaling. I'm just raising considerations and will happily
join any consensus.

On the second subject, I'm not sure exactly what you're
thinking of as what Steve proposed as an alternative behavior.
The suggestion I recall involved the backup sending an
advertisement, fully realizing it should be the backup.
I definitely don't support that idea. On the other hand,
if he just wants to make his configuration so that the backup
issues an alarm and then drops out of the VR if the master's
interval is too short for the backup to handle, I don't have
a problem with that.

-don

> From: Stephen Nadas [mailto:[email-masked]]
> Sent: Monday, January 14, 2008 10:16 AM
> To: Don Provan; Steve Bates
> Cc: [email-masked]
> > > correct value from the master. In other words, the 
> problem will be 
> > > resolved.

---

From: "Stephen Nadas" <[email-masked]>
Date: Mon, 14 Jan 2008 15:04:13 -0600

Hi Don, 

1st subject: 

What I think Steve is saying is: "We are seeing more and more requests
to support rates of failure detection this draft addresses but it seems
likely that in another decade, with terabit speed links for example,
that we will see demands for failure detection 100 times faster than we
currently address." 

100x faster than 3 centisec is 3*10-4 (tenths of millisec).  So he
proposed 4 bits to signal 10**0->10**-15, which sure seems like overkill
to me.  Also this doesn't work completely correctly (nor does my earlier
suggestion of 10E-7) bcos Max_Adver_Int needs more bits to signal the
full range.   

Right now we signal 1-4096 centisec, a range of 1 centisec to 40 sec.
If units are 10**-4, the range possible is 1 tenth of ms -> .4 sec (I
don't like that this because it cannot _simply_ signal 1 sec).     

I think WG has been here already (read archives around 27 Jul 2006.)  My
memory is that there was not much enthuasism to make the vrrp header
wider to fully represent, say microsec.  In the end, I think we
concluded that centisec was fast enough for version 3 and if faster was
needed then version 4 would come.  Steve is pushing back on this point.

So, if WG feels centisec is not future proof enough, let me suggest:  

make Max_Adver_Int all 16 bits and fix the the units at 10E-4.  
- Steve has tenths of millisec resolution (100x faster than today) 
- you have 1 unit (no granularity is signalled).
For 10E-4 the possible signalled range is 1*10E-4 sec --> 6.5 sec.  

Or make Max_Adver_Int all 16 bits and fix units at 10E-3
- Steve has millisec resolution (10x faster than today) 
- you have 1 unit (no granularity is signalled).
and signalled range is 1 millisec -> 65 sec.  

I can live with either; if forced, I prefer the latter (otherwise I
prefer original agreement).  Beyond this we need a floating point format
or more bits.

In any case I would like to hear whether from WG whether centisec is not
future proof enough.  

For the list: Please Note That Silence Means No Change Is Needed (ie
centisec granularity is ok).  

2nd subject: 

I completely agree with you. 

Thanks,
Steve  

> Sent: Monday, January 14, 2008 3:04 PM
> To: Stephen Nadas; 'Steve Bates'
> Cc: [email-masked]
> tree. The question is this: "Is the 3 centisecond limit for 
> failover time approaching the point at which the time it 
> takes the infrastructure to adjust is more significant?"
> Would simply reducing the units to milliseconds or tenths of 
> milliseconds -- certainly possible within the field, 
> particularly if we use the reserved bits -- get us down to 
> that point? If so, I would prefer that to having a 
> variable/scaled interval. Scaling was proposed earlier, and 
> my vague recollection is that it was rejected, but I don't 
> recall who rejected it or why.
> 
> I definitely don't support that idea. On the other hand, if 
> he just wants to make his configuration so that the backup

---

From: "Don Provan" <[email-masked]>
Date: Mon, 14 Jan 2008 13:39:53 -0800

> What I think Steve is saying is: "We are seeing more and more 
> requests to support rates of failure detection this draft 
> addresses but it seems likely that in another decade, with 
> terabit speed links for example, that we will see demands for 
> failure detection 100 times faster than we currently address." 

And what I'm questioning is whether this is really true: we are
already into the range where the speed of the links are fast
enough so that the VRRP overhead at any interval would be a
negligible consumption of bandwidth. So the fact that link
rates are likely to keep going up is not particularly
interesting; the failover rate is already approaching the point
where the limiting factor is the infrastructure switchover
speeds, not the bandwidth. And that means the limit starts to
involve speed of light issues more and the limitations of
hardware designs less.

I don't claim to know the answer, I'm just saying that we're
very near the tipping point where we cannot extrapolate based
on past experience. So someone that actually understands the
hardware issues should consider what the limit will be of what
people will demand and what hardware will be able to support.
I don't really have any idea, so I have no reason to favor any
of the proposed units, including scalable.

Can anyone tell me what's going on in routing protocols in
failure recovery? In a "normal" configuration, returning
traffic will tend to go to the dead router until the routing
protocol detects the failure. How long does that take these
days?

-don