Hi Quentin, et al, I think this Errata should be rejected. Trying to handled a misconfiguration rather than logging it as an error is not an errata change but something that could be proposed in a draft (along with any other such proposed changes).
Thanks, Acee > On Feb 17, 2025, at 10:25, Quentin Armitage <quen...@armitage.org.uk> wrote: > > Further to the following, section 8.3.2 explicitly allows there to be more > than one VRRP > router to be configured with priority 255, by virtue of the use of SHOULD > rather than MUST): > > 8.3.2. Recommendations Regarding Setting Priority Values > > A priority value of 255 designates a particular router as the "IPvX address > owner" for the > VRID. VRRP Routers with priority 255 will, as soon as they start up, preempt > all lower- > priority routers. For a VRID, only a single VRRP Router on the link SHOULD be > configured > with priority 255. If multiple VRRP Routers advertising priority 255 are > detected, the > condition SHOULD be logged (subject to rate-limiting). > > With apologies for not including this in the original report. > > Quentin Armitage > > On Mon, 2025-02-17 at 06:05 -0800, RFC Errata System wrote: >> The following errata report has been submitted for RFC9568, >> "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid8298 >> >> -------------------------------------- >> Type: Technical >> Reported by: Quentin Armitage <quen...@armitage.org.uk> >> >> Section: 7.1 >> >> Original Text >> ------------- >> It MUST verify that the VRID is configured on the receiving >> interface and the local router is not the IPvX address owner >> (Priority = 255 (decimal)). >> >> If any one of the above checks fails, the receiver MUST discard the >> packet, SHOULD log the event (subject to rate-limiting), and MAY >> indicate via network management that an error occurred. >> >> Corrected Text >> -------------- >> It MUST verify that the VRID is configured on the receiving >> interface. >> >> If any one of the above checks fails, the receiver MUST discard the >> packet, SHOULD log the event (subject to rate-limiting), and MAY >> indicate via network management that an error occurred. >> >> It SHOULD verify that the local router is not the IPvX address owner >> (Priority = 255 (decimal)) and log the event (subject to >> rate-limiting) and MAY indicate via network management that a >> misconfiguration was detected. >> >> Notes >> ----- >> Although it is clearly a configuration error, if two (or more) VRRP routers >> are configured >> as the address owner for the same VRID, if received VRRP packets are just >> dropped (as >> specified in section 7.1), all such routers will remain in Active state, >> will continue >> sending VRRP adverts, and will respond to ARP/ND requests. This will make >> communication >> with any VIP unachievable, or at best unreliable. >> >> If the VRRP packets are not dropped, but processed in the normal way, in >> section 6.4.3 - >> "Active", following "If an ADVERTISEMENT is received", then: >> . If the Priority in the ADVERTISEMENT is greater than the >> local Priority or the Priority in the ADVERTISEMENT is equal >> to the local Priority and the primary IPvX address of the >> sender is greater than the local primary IPvX address (based >> on an unsigned integer comparison of the IPvX addresses in >> network byte order), then: >> ... >> Transition to the {Backup} state >> >> will cause all except one of the VRRP routers to revert to Backup state, and >> the VRRP >> instance will be stable. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". (If it is spam, it >> will be removed shortly by the RFC Production Center.) Please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> will log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC9568 (draft-ietf-rtgwg-vrrp-rfc5798bis-18) >> -------------------------------------- >> Title : Virtual Router Redundancy Protocol (VRRP) Version 3 >> for IPv4 and >> IPv6 >> Publication Date : April 2024 >> Author(s) : A. Lindem, A. Dogra >> Category : PROPOSED STANDARD >> Source : Routing Area Working Group >> Stream : IETF >> Verifying Party : IESG > _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
