See inline.
On Dec 30, 2023, at 16:47, dthaler1968@xxxxxxxxxxxxxx wrote:
-----Original Message-----
From: Acee Lindem <acee.ietf@xxxxxxxxx>
Sent: Saturday, December 30, 2023 1:13 PM
To: Dave Thaler <dave.thaler.ietf@xxxxxxxxx>
Cc: int-dir@xxxxxxxx; draft-ietf-rtgwg-vrrp-rfc5798bis.all@xxxxxxxx; Last Call
<last-call@xxxxxxxx>; rtgwg@xxxxxxxx
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 <noreply@xxxxxxxx>
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 tocontradict 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 RAadvertisements and are using manual configuration, or what? I'm stillconfused 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 followthe recommendation? You mention there is churn, so why not at least logas 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
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
