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