Hi Tim, Thanks again for the detailed review and digging into the IPv6 operations.
> On Mar 3, 2023, at 4:34 AM, Tim Chown <[email protected]> wrote: > > Hi Acee, > >> On 2 Mar 2023, at 16:45, Acee Lindem <[email protected]> wrote: >> >> [You don't often get email from [email protected]. Learn why this is >> important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Hi Tim, >> >> Thanks for your detailed review. I have some questions and comments on your >> comments. The rest of your comments were clear. >> >>> On Mar 2, 2023, at 9:03 AM, Tim Chown via Datatracker <[email protected]> >>> wrote: >>> >>> Reviewer: Tim Chown >>> Review result: Has Nits >>> >>> Hi, >>> >>> 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. >>> >>> Comments: >>> >>> 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. >> >> The fact that this document obsoletes RFC 5798 is in the abstract and intro. >> RFC 3798 still is the definitive reference for VRRPv2. I don’t think any >> update is needed here. > > It just reads a bit awkwardly for me, where the revision from 5798 isn’t > mentioned in the first two sentences, but it says "It is version three (3) of > the protocol” and then at the end it says " This document obsoletes VRRP > Version 3 [RFC5798].” What’s obsolete is RFC5798, not VRRPv3. > > It might be clearer to delete that last sentence and change the first two > sentences > > "This document defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 > and IPv6. It is version three (3) of the protocol, and it is based on VRRP > (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router > Redundancy Protocol for IPv6”. > > to > > “This document defines version 3 of the Virtual Router Redundancy Protocol > (VRRP) for IPv4 and IPv6. It is based on VRRP (version 2) for IPv4 that is > defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6”, and > obsoletes the prevision specification of this version documented in RFC 5798. This is a good suggestion and one that would improved the abstracts of other BIS documents. I will incorporate. > >>> 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? >> >> I really don’t want to get into a precise IPv6 ND specification in this >> document. How about if I update both of these to say “can take 10s of >> seconds”? > > That’s fine. I don’t have enough experience to know what the figure is. > Saying 38 seconds seems very precise unless there’s a specific reason for the > figure, and it is much more than the 3 seconds indicated in RFC 7048. Saying > “can take a few tens of seconds” seems fine, if that’s operational experience. I believe this originally came from the original VRRP IPv6 draft that was incorporated into VRRPv3. I’m sure the numbers have changed over time. > >>> >>> 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? >> >> I don’t think I have to replace RFC 2464 since RFC 7217 doesn’t even update >> it. I could add it but I think we want to use the physical MAC consistent >> with the RFC 2464 recommendation. > > I’m quite surprised that section 4 of RFC 2464 hasn’t been obsoleted in some > way. > > I’d point you at bullet 5 of section 4 of RFC 7217, and I’d be surprised if > you didn’t draw IESG comments about this when the document reaches that > stage. I think your aim with this review is to catch things before that > stage, hence I’m flagging it. For some it is likely to be a DISCUSS level > comment. > > Whether physical or virtual MAC is an interesting question. I’ll get back to you on this one. I just scanned RFC 7217 the first time. > >>> >>> Section 11: >>> >>> Should the protocol number registry be added here, where VRRP is 112 and >>> cited >>> as RFC 5798? >> >> I agree but the IANA registry should be updated to this document since it >> obsoletes RFC 5798. > > OK, I’m not 100% sure what needs to be captured in the IANA considerations, I > mentioned it as it will need updating, and I’d assumed IANA would check the > IANA sections of new RFCs as part of their process. But happy to defer to > your experience. I’ve added it. > >>> 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. >> >> >> I believe RFC 6527 is wrong. IPv4 and IPv6 virtual routers are always >> treated as separate logical instances. Note that the abstract says: >> >> "Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 >> address families are independent of one another.” >> >> Note that “routers” is plural. I’d disagree with any other interpretation. > > OK, that’s fine. Maybe just add that sentence then, in section 1.2? "IPv4 > and IPv6 virtual routers are always treated as separate logical instances.” > It may be obvious and unambiguous to you, but stating it can do no harm? Sure. We should obsolete RFC 6527 as well - Aditya is taking the lead on that one as Cisco has implemented the MIB. I’m going to update the VRRP YANG model next. Thanks, Acee > > Best wishes, > Tim > >> >> Thanks, >> Acee >> >> >>> >>> Tim >>> >>> >> > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
