Re: Opsdir early review of draft-ietf-rtgwg-vrrp-rfc5798bis-02

[Acee Lindem <[e-mail]>]

Hi Tim, 

Thanks again for the detailed review and digging into the IPv6 operations. 

> On Mar 3, 2023, at 4:34 AM, Tim Chown <[e-mail]> wrote:
> 
> Hi Acee,
> 
>> On 2 Mar 2023, at 16:45, Acee Lindem <[e-mail]> wrote:
>> 
>> [You don't often get email from [e-mail]. 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 <[e-mail]> 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
>>> 
>>> 
>> 
>