[Int-dir] Intdir telechat review of draft-ietf-rtgwg-vrrp-rfc5798bis-15

Dave Thaler via Datatracker <noreply@ietf.org> Wed, 27 December 2023 23:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32588C151096; Wed, 27 Dec 2023 15:30:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dave Thaler via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-rtgwg-vrrp-rfc5798bis.all@ietf.org, last-call@ietf.org, rtgwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170371985819.52401.2042358676642167473@ietfa.amsl.com>
Reply-To: Dave Thaler <dave.thaler.ietf@gmail.com>
Date: Wed, 27 Dec 2023 15:30:58 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/oMUvKx5sREDJMbF7al_qT-pmtr0>
Subject: [Int-dir] Intdir telechat review of draft-ietf-rtgwg-vrrp-rfc5798bis-15
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Dec 2023 23:30:58 -0000

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. 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. 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). 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. 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? 6. Various grammatical nits.