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

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