See inline. > On Dec 30, 2023, at 16:47, [email protected] wrote: > >> -----Original Message----- >> From: Acee Lindem <[email protected] <mailto:[email protected]>> >> Sent: Saturday, December 30, 2023 1:13 PM >> To: Dave Thaler <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]>; >> [email protected] >> <mailto:[email protected]>; Last Call >> <[email protected] <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> >> Subject: Re: Intdir telechat review of draft-ietf-rtgwg-vrrp-rfc5798bis-15 >> >> Hi Dave, >> >> Thanks for the review. >> >>> On Dec 27, 2023, at 6:30 PM, Dave Thaler via Datatracker <[email protected]> >> wrote: >>> >>> Reviewer: Dave Thaler >>> Review result: Ready with Issues >>> >>> See https://1drv.ms/b/s!Aqj-Bj9PNivcn-MfckCWPYEAplaCJw?e=5TZtui for a >>> copy with my comments and editorial nits inline. >>> >>> Summary: >>> 1. I am confused by the discussion of "forwarding" packets addressed >>> to the Active Router's address. The Abstract and Introduction seem to >>> talk about doing it but then section 8.3.1 says not to. >> >> The primary purpose of VRRP is to assume “forwarding” responsibility for the >> virtual addresses. >> I don’t see any compelling reason to change this now. I could change “sent to >> these IPv4 and IPv6 addresses” to “routed to these IPv4 and IPv6 addresses” >> to avoid any confusion that this forwarding is tied to the packet header >> destination addresses. However, I don’t even see this as needed. > > I was confused by the wording as noted in my comments, since it appears to > contradict text later in the document.
Section 8.3.1 addresses the specific case of the packets address to the VRRP virtual address. I’ll make this clear. > >>> 2. Missing discussion of DHCPv4. >>> Section 1.3 seems to imply that static configuration of end hosts is >>> the primary mechanism for learning default routes, which is not the >>> case for clients or IoT devices as far as I know... DHCP is the >>> default. I believe VRRP can still be used in a DHCP scenario and the >> document should say so. >> >> Yes - but DHCP is really just another form of static route configuration. >> I’ll >> change this to “manual configuration” and include DHCPv4 [2131] and >> DHCPv6 [RFC8415] as well as static configuration. Any other suggested >> references? > > That sounds sufficient to me at the moment. > >>> 3. Section >>> 4.2's discussion of IPv6 is confusing to me (and I wrote one of the >>> relevant RFCs). If there are two routers sending RA's on the same >>> LAN, then by default all hosts learn _both_ of them. The text implies >>> half learned one and half "are using" the other one. This text needs >>> to be clarified and then probably reference RFC 4191 and RFC 4311 for >>> more discussion. Even better would be to update the text to >>> specifically discuss the interaction between VRRP and 4311 (which I >>> think would be straightforward), and if needed mention different cases >>> for the different host types in RFC 4191 section 3 (it's also possible >>> that the interaction with VRRP is the same for all the types and the >>> types need not be mentioned except to say that the interaction is the same >> for all the host types there). >> >> For IPv6, I could change “learned” to “configured” since the purpose of >> section 4.2 Is to demonstrate load-sharing and not specify IPv6 Router- >> Advertisement behavior. > > Is the intent of the example that half aren't paying attention to IPv6 RA > advertisements and are using manual configuration, or what? I'm still > confused as to what the intent of the text is. The intent is to provide an example of VRRP load-balancing with different groups of hosts using different primary and secondary default gateways. It is not to specify how this is provisioned using IPv6 RAs. > >> Alternately, I could change “learned” to “preferred” with a reference to RFC >> 4311. >> >>> 4. A couple places use "should" in cases where it's unclear whether it >>> means SHOULD or MUST (or even "MAY" when "may" occurs earlier in the >> text). >>> This could adversely affect interoperability if it meant MUST and >>> someone interprets it as optional. >> >> I’ll look at all of these. As long as the statement is specific to VRRP, I >> will >> consider changing these to normative. >> >>> 5. Section 8.3.2 says to log when multiple routers advertise priority >>> = 255, but doesn't say to log when multiple routers advertise the same >>> non-255 priority. It says not to do that, so why wouldn't you want to >>> suggest logging any time the same priority is advertised by multiple >>> routers? I.e., why is the logging recommendation limited to the 255 >>> case? >> >> The VRRP protocol handles this case with a tie-breaker of the VRRP router >> with the VRRP router with the greater primary IP address taking precedence. >> The reason for recommending that VRRP routers have different priorities is to >> minimize the churn do to them having the same advertisement skew time. It >> is not a protocol error. > > My question is why not recommend logging when someone doesn't follow > the recommendation? You mention there is churn, so why not at least log > as a MAY? I guess including it in section 8.3.2 as a MAY wouldn’t hurt. Thanks, Acee > >>> . Various grammatical nits. >> >> I’ll incorporate these. Note that the pseudo-code wasn’t meant to be >> grammatically correct. However, the changes you have suggested may not >> obscure the logic and I’ll consider them. >> >> Thanks >> Acee
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
