Questions on draft-ietf-vrrp-ipv4-timers-02.txt

Hi Bob,

I've posted these comments before but I'll rephrase them based on the 02
draft.

1) Back in early December there was a flurry of comments about mismatched
advertisement intervals causing multiple masters.  The consensus seemed to
be that virtual routers of a lower priority would ignore a mismatch if the
higher priority interval was less than their configured interval and make
the higher priority interval their own operational value when it was greater
than their configured interval.  I was under the impression, based on
Radia's response to your original December 2nd post, that this would be
reflected in the draft.  Other than the omission of the phrase "the receiver
MUST discard the packet" in the final paragraph of section 4.1 I don't see
anything about this.  

2) This may become a greater issue with the addition of advertising interval
granularity.  It's conceivable that one implementation might not be able to
support as fine(?) a granularity as another, while both are type 2 virtual
routers.  For example, suppose a higher priority virtual router A is
configured with adver_cnt = 3, aig = 1, and adver_int = 1, while a lower
priority virtual router B is configured with adver_cnt = 3, aig = 2, and
adver_int = 1.  Virtual router B MUST accept virtual router A's values to
avoid flapping - unless it discards the FAST ADVERTISEMENT and creates a two
master situation.  Conversely, if the priorities are reversed B's values are
useless to A if A is incapable of supporting the finer granularity but at
least A will maintain it's backup state.  Am I mistaken?

3) The two bit granularity field seems a bit shortsighted.  A) There are
some RTOSes where a "tick" is defined as 1/60th of a second.  This makes
achieving centisecond granularity difficult.  A decisecond value would be
nice.  B) But if we do that we've used up all the values in the field.  Ten
years from now we'll be on terabit networks and someone may want microsecond
granularity.  Another bit might be a good idea.

4) I don't dispute the desirability of  a configurable advertisement count
but I'm not sure we gain much passing it in the advertisement.

5) For the VRRPv3 packet there are only 4 bits available since the
advertisement interval uses 12.  Do you have an idea how to migrate this
draft to the IPv6 case?


Steve Bates


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