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