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

dthaler1968@googlemail.com Thu, 04 January 2024 23:40 UTC

Return-Path: <dthaler1968@googlemail.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAD5C14F6E0; Thu, 4 Jan 2024 15:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2DEEwd2qqNr; Thu, 4 Jan 2024 15:40:40 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3CDC14F6A0; Thu, 4 Jan 2024 15:40:40 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-6d9344f30caso53303b3a.1; Thu, 04 Jan 2024 15:40:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1704411639; x=1705016439; darn=ietf.org; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=OhMw5gQmyAlY73M4y4KyXSfyc5qcfSs56IaEiNGqIJo=; b=T28g2+WOCpfL+l+SqX1aX4NTiNaqCaYO0NBst99fkF+X0q8+oKqStLKF2pa+gtBRd3 TmBrCd9qWiNSevFiGBzCHUFEMxhPmElO4ldS6NOGz421DLa9QAtkQszEfFOZic93PzuT H2Z4QXdfvlR5E2Q912jLNexPi3EcQHqDoDTdDx9PS6i1BTiaR7RuMhYeBGXe8oHKVGSO hhWpunV0x35icjp36aae9K60LVX7cEOJTST5OqG6ccKd6dVH+/5N5qWYDPDADODeRqD4 ZPkGCTo/UR+1/kp+aWVa0WWNuo2kQgZJlCuNxwfYbN25Y2DcecWeeSS19fIqyJVNTzZ0 5GtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704411639; x=1705016439; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OhMw5gQmyAlY73M4y4KyXSfyc5qcfSs56IaEiNGqIJo=; b=j5Iuz6jbGlyn5wCpJnF1vxeIH1v1R58TFDWhiy7wsePK4KfuXuOZljJPLi5uGQ8RnG xrqnWsDIBjSL8T7pPXQp7auLz5LYPVnqtKdzdqsGBWZdhIn2J0keIFhdFT/HJxRR3O4b 5pYyB0MUcAHJt8quifNsHyduB72tn/8MsisKB8hR3CPxPOp8bPRyWFX9mzAWj7SRYBPS 6txr7zAKYspEV9abXTs+CIW4V8UJqC/yHctRN+XGj9XQyhrys2LF5zpsH7fuFZ6IeJqg hRkuF/3UJNyVskrWnPtD7uOFVK5nd67TMDKRnzBJK59SWJpvJNHMmHugCgR/pMApggla EtkQ==
X-Gm-Message-State: AOJu0Yy9337hKoX0dgkX+6ye0apaI0p51BZNvr/j7/Lguof0U0uRv1M7 aPBzh4C4PQ6Vz7FzEwXzpOw=
X-Google-Smtp-Source: AGHT+IFKb9F/ycLWRG7eDO0V4LnbX/awEczGEl3ZIzh8y3fngSgEvmakdIVeyEWsWH53xlTJrZ0Dbw==
X-Received: by 2002:aa7:85d6:0:b0:6da:7ba4:544 with SMTP id z22-20020aa785d6000000b006da7ba40544mr1424226pfn.30.1704411639135; Thu, 04 Jan 2024 15:40:39 -0800 (PST)
Received: from ArmidaleLaptop (c-67-170-74-237.hsd1.wa.comcast.net. [67.170.74.237]) by smtp.gmail.com with ESMTPSA id h26-20020a62b41a000000b006d9c216a9e6sm205126pfn.56.2024.01.04.15.40.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2024 15:40:38 -0800 (PST)
From: dthaler1968@googlemail.com
X-Google-Original-From: <dthaler1968@gmail.com>
To: 'Acee Lindem' <acee.ietf@gmail.com>
Cc: 'Dave Thaler' <dave.thaler.ietf@gmail.com>, int-dir@ietf.org, draft-ietf-rtgwg-vrrp-rfc5798bis.all@ietf.org, 'Last Call' <last-call@ietf.org>, rtgwg@ietf.org
References: <170371985819.52401.2042358676642167473@ietfa.amsl.com> <F267AC78-645A-4DF8-B4CF-44A8D2844B84@gmail.com> <00b001da3b69$bc6ebdf0$354c39d0$@gmail.com> <8D0418F4-2769-4A85-9CA8-5652163E4968@gmail.com>
In-Reply-To: <8D0418F4-2769-4A85-9CA8-5652163E4968@gmail.com>
Date: Thu, 04 Jan 2024 15:40:36 -0800
Message-ID: <03a501da3f67$6b63b990$422b2cb0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQC69P/VNUlSJjDHBvwwy1ZfuLFYHwHmj0I8AT/fK8sB9yG4mbLf9ejg
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/lF1KYUAOdDOVzItiq8NGx-2lcuk>
Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-rtgwg-vrrp-rfc5798bis-15
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Thu, 04 Jan 2024 23:40:45 -0000

>>>> 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. 

To me “forwarding responsibility for the virtual addresses” refers to forwarding of packets destined to
(i.e., IP header’s destination address contains) the virtual address.  To me, that phrase makes no sense.
Hence my comment about the Abstract and Introduction being confused.  One doesn't forward
traffic destined for the virtual addresses.  One forwards traffic that isn't destined for the virtual addresses.

One might forward traffic for the _MAC address_ of the virtual router, but not for the virtual IP address.

>>>> 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.  

In IPv6, the term “primary default gateway” doesn’t really exist as such.  That term
assumes that a host uses one default gateway for all packets as long as it’s up, and the
whole point of RFC 4311 is that that isn’t necessarily true.  A host selects a gateway for each
destination address, and so for each destination address one might have a primary gateway
and secondaries.  But the primary for one destination need not be the primary for another
destination.    As such, the wording for IPv6 needs to be changed to make sense, unless
to construct an example where it does make sense.

My 2 cents,
Dave