Skip to main content

Early Review of draft-ietf-rtgwg-vrrp-rfc5798bis-02

Request Review of draft-ietf-rtgwg-vrrp-rfc5798bis-02
Requested revision 02 (document currently at 18)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2023-03-04
Requested 2023-02-13
Requested by Yingzhen Qu
Authors Acee Lindem , Aditya Dogra
I-D last updated 2023-03-02
Completed reviews Rtgdir Early review of -12 by Russ White (diff)
Rtgdir Early review of -13 by Donald E. Eastlake 3rd (diff)
Secdir Early review of -13 by Mališa Vučinić (diff)
Genart Last Call review of -14 by Vijay K. Gurbani (diff)
Intdir Telechat review of -15 by Dave Thaler (diff)
Secdir Early review of -03 by Mališa Vučinić (diff)
Opsdir Early review of -02 by Tim Chown (diff)
Rtgdir Early review of -02 by Ben Niven-Jenkins (diff)
This draft updates RFC 5798 to use inclusive terminologies, as well some technical changes. We'd like to request early reviews before moving the document forward.
Assignment Reviewer Tim Chown
State Completed
Request Early review on draft-ietf-rtgwg-vrrp-rfc5798bis by Ops Directorate Assigned
Posted at
Reviewed revision 02 (document currently at 18)
Result Has nits
Completed 2023-03-02

This draft is not yet submitted to the IESG. Comments and reviews were
solicited before taking the document further.

This draft is an update to RFC 5798, VRRP v3 for IPv4 and IPv6. It changes
terminology to be more inclusive, applies errata, makes a small number of
technical changes, and extends the security considerations.

Overall, the draft seems to be progressing well as an update, and I would
encourage the authors to continue that process, while also taking on board the
comments below, some of which are general or open but others more specific.  I
would say it’s Ready with Nits.

The document remains well-written, with an easy to read style.


Abstract and first para of Introduction:
The second sentence should reflect that 5798 is now in the past.  It can
mention 3768 but that’s now a previous version.

Section 1.4:

“Hosts will learn the default routers in a few minutes” - in practice it is
faster as hosts will send an RS when their interface comes up?

Is it really 38 seconds to determine a router is unreachable?  RFC 7048
suggests it’s 3 seconds, and that that is (by the title) too impatient?

Are router preferences relevant here as per RFC 4191?

Section 1.7:

Maybe add VR ID to the definitions

Section 4.2:

Should H3 and H4 here have IPvX B rather than A?

Section 7.4:

I think 2464 should be replaced by RFC 7217?  If so, maybe mention that the Net
Interface element of the algorithm should maybe be the virtual MAC not the
physical one?

Section 11:

Should the protocol number registry be added here, where VRRP is 112 and cited
as RFC 5798?

Finally, I did stumble across some comments in section 7 of RFC 6527 while
reading around the topic, on ambiguities for multi-stack VRRP operation. Should
this draft bring those into scope, or leave them out?  If the latter, perhaps
state this in the document.