RE: draft-ietf-vrrp-unified-spec-00 issues

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 protected]] 
Sent: Friday, January 11, 2008 1:43 PM
To: 'Steve Bates'
Cc: 'Stephen Nadas'; [email protected]
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.

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

> -----Original Message-----
> From: Steve Bates [mailto:[email protected]]
> Sent: Friday, January 11, 2008 10:49 AM
> To: 'Don Provan'; 'Stephen Nadas'; [email protected]
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> 
> 
> 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 protected]]
> Sent: Thursday, January 10, 2008 4:54 PM
> To: 'Steve Bates'; 'Stephen Nadas'; [email protected]
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> 
> > 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.
> 
> 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
> 
> 
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/vrrp


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