Hi, That all sounds good, thanks Acee.
Tim > On 3 Mar 2023, at 13:48, Acee Lindem <[email protected]> wrote: > > 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
