Many thanks for making the changes in versions 08 and 09. On Fri, 2023-07-28 at 18:53 -0700, Acee Lindem wrote: > Hi Quentin, > > Thanks much for your detailed review!!! See inline. I’m posting version -08. > > Thanks, > Acee > > > On Jul 28, 2023, at 09:03, Quentin Armitage <[email protected]> wrote: > > > > > > 29. Section 5.2.4 third paragraph add sentence at end "Note, each Virtual > > Router for a > > VRID > > should be configured with different priorities (unless there are more than > > 254 non > > address- > > owner virtual routers) since if two (or more) Backup Routers are configured > > with the same > > priority, when the Active Router fails, both Backup Routers will transition > > to be an > > Active > > Router simultaneously, both sending VRRP advertisements and gratuitous > > ARP/unsolicited ND > > messages, causing confusion for learning bridges (see section 3)". > > > Nope. The primary address is used as a tie-breaker.
I understand that the primary address is used as a tie-breaker, but it is highly undesirable for two or more Backup Routers to transition to be Active Router simultaneously, which is what happens if the Active Router shuts down or fails and there is more the one Backup Router with the next highest priority. In my proposed additional sentence "virtual router" should be "Virtual Router" and "should" should be "SHOULD"; it is advice on how to avoid problems (as set out above) when the Active Router stops operating and two or more Backup Routers promote themselves. My view is that it is a configuration error to configure the same Priority on more than one Virtual Router, but the primary address tie-breaker is a work around to the problem the enables the VRRP protocol to continue functioning. > > > > > 52. Section 6.4.1 after (775) add "(778) @ Send an advertisement" (the > > reason for this is > > to > > update/correct any learning bridges caches and to make the lower priority > > Active Router > > revert to Backup state. This is a change in procedure but not a protocol > > change). > > I don’t think the virtual router transitioning to Backup Router should send > an advertisement > here. (775) is in the else block of the if check at (725) to (735), and so applies to the higher priority (or equal priority and higher IP address) Active Router, and is therefore the router that remains in Active state. I believe it is important for the Active Router remaining in the Active state to send an advert immediately after receiving a lower priority advert, otherwise learning bridges will forward packets to the wrong router until the Adver_Timer expires on the higher priority Active Router. I have the following comments regarding version 09. 1. Section 1.7 Virtual Router MAC Address change "ethernet" to "Ethernet". 2. Section 3 I think if "configurable to < 1 second" is changed to "configurable to < 1/25 second" gives a better impression of how quickly VRRP can operate (1/25 is 4 * 10ms - minimum Advertisement_Interval). I incorrectly specified 1/64 in my previous email since for some bizarre reason I had in mind that the minimum Advertisement_Interval was 1/256 second). 3. Section 6.5 (455) delete newly inserted "and Skew_Time" - it duplicates the new (452) and Skew_Time must be calculated before Active_Down_Interval. 4. Section 7.1 penultimate paragraph the first "Max Advertisement Interval" should be "Max Advertise Interval" since it is a field in the received VRRP packet, and the second "Max Advertisement Interval" should be "Advertisement_Interval" since it is a parameter of the Virtual Router. 5. Section 8.3.2 second paragraph delete ", especially if preemption is set" since it implies that more than on Virtual Router may be configured with priority 255, which not only contradicts the proceeding paragraph, and due to the definition of Priority implies that more than 1 Virtual Router is the address owner (apologies - I should have included this in my previous email). With regards, Quentin Armitage _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
