Re: [v6ops] draft-ietf-6man-grand : saving lookups

Jen Linkova <furry13@gmail.com> Wed, 12 August 2020 03:54 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425613A0EE1; Tue, 11 Aug 2020 20:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb3b47he3aUJ; Tue, 11 Aug 2020 20:54:29 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D033A0EDE; Tue, 11 Aug 2020 20:54:29 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id k18so565115qtm.10; Tue, 11 Aug 2020 20:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WPqx0q9UXjzDsLQY/T885T2eoDCKaBdN2RfSRHBiTMY=; b=SgTBhQu3hzHZpT+ZVXfB9yje1Vf/Llob1lLJvSsx23hBNcfjxMJZT0i+bYqIIgEhT2 QuigjAdpRhw7kiiZodbtsmgnUKDokD2cDAhrNTr3GrtPSoqrgZO46EwQwxAjaNcU8KWr S3jn9gdvQBqiottFwxgQN0UphdFQ07rb4x+EQ3JSTiW261F3ZorSx9SjkA8q9Rz31ECn FAo8MlSGTYVS7NbVAyyU8qDcyIWysMsws1/MLfh8g1AP6vTkXizC6bA7GZYtcW6G76QM SaKj00RynphA+JteXYc1Y94dWgGPLEAa2J+DfmvSgLUWu1OV32YhF58WazCGfMl8oGu7 sO+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WPqx0q9UXjzDsLQY/T885T2eoDCKaBdN2RfSRHBiTMY=; b=LRxZSaL+PdUO/KlvU4DQ+WGy00veml8BEQEGedBHHX+3MheuXHC4jbjP1J8gumiWa9 /tLnXlGejGLLbOUEyppYqtvefd4+G7GrIQ3S6vpCZzMgFOqOJOzG88nRweaxDoYf5YUs vP4+EAElDG7G5Z5shFWm1dfAEcsc+h0vo1kXLuMfaXBnn6O4IV6X7oAoJuVC5/aTEMtJ MxAnNgGcqFGur/LFNkvP2YEvw7Yyj1JWznHyqXZMq2BsXejnVLKjym3gsp2zSQ5j26ST +axFkKJzyPKl6AamL5zTTcoE6SzP0vLSU+uNlA3hef2QuNLx44lR6t9shqkwSMCwckdC 3c9g==
X-Gm-Message-State: AOAM533znc/SYyaBp9+fwq8LhujyVFN3b/OrW15i62IptuGGcaktFMEo wO/M5CAC7orHvy9pbmCjkNoLQej41WexGf4qI3g1Yw==
X-Google-Smtp-Source: ABdhPJzS7loTD5zbST41SzgoL7hST4AlfxCxt47L/qnTeTJLXiGgoU6k5NJA419v/mC3LT0se/SW1I8jqMiWb0lm0yQ=
X-Received: by 2002:ac8:6f22:: with SMTP id i2mr4479469qtv.384.1597204468675; Tue, 11 Aug 2020 20:54:28 -0700 (PDT)
MIME-Version: 1.0
References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <CAFU7BARePzdeU5DFgoOWyrF0xZCj67_xkC2t8vMN2nH0d8aUig@mail.gmail.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <CAKD1Yr1BJTAfp4PE+DY1yxeMm64kHetqBGYc5iaqZd3u0XrWpA@mail.gmail.com> <E176B084-24E1-434D-B15C-F364F64807BB@cisco.com> <CAFU7BASpHVTQ5SuNsdNu70ejZDnpVuPUaig+0_C=6q+mDQDFXA@mail.gmail.com> <BYAPR11MB355844AED3BA019B671797DDD8490@BYAPR11MB3558.namprd11.prod.outlook.com> <CAFU7BATuCN1rE=H9v0vv84UKKE7zD+LtRqh48Zf7hHN+sSGQJw@mail.gmail.com> <8B923F28-899B-4CE5-A3EB-B82E9E74A9B8@cisco.com> <CAFU7BATNnY3tYTc+woqypiu7VDtTghSsOnihGHw9bS0923Z+Vw@mail.gmail.com> <m1k5Pdd-0000KfC@stereo.hq.phicoh.net>
In-Reply-To: <m1k5Pdd-0000KfC@stereo.hq.phicoh.net>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 12 Aug 2020 13:54:16 +1000
Message-ID: <CAFU7BAQHUmuNAB97iZrn2oK=ZiZBpv_xPpt+ESf6j90tOKeZcQ@mail.gmail.com>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Cc: V6 Ops List <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_Lw9TzQtKYyd2_BmZcEOwLCPKTc>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2020 03:54:31 -0000

On Tue, Aug 11, 2020 at 6:28 PM Philip Homburg
<pch-v6ops-9@u-1.phicoh.com> wrote:
>
> In your letter dated Sun, 9 Aug 2020 19:28:51 +1000 you wrote:
> >I guess we can add to the very end of the Section 4.1.2 (the new text):
> >"A node MAY send unsolicited NAs for its preferred addresses
> >periodically to refresh the Neighbor Cache on the first hop routers."
> >
> >On the other hand it might pollute the router NC with entries for
> >addresses which the node has configured but is not going to use.
> >
> >What does the WG think?
>
> A few thoughts:
>
> 1) It has to specified how often the host has to refresh entries

Yes, and it would be very tricky because (as I've mentioned in another
email in this thread) finding the useful interval requires knowing the
timers for NC garbage collection on routers.

> 2) I think MAY is too weak to rely on. One possibility to deal with 1)
>    and 2) is to have an RA option that specifies the interval. Then we
>    can make sending the NAs if the option is present a SHOULD or MUST

I'm not convinced we shall be doing it in the first place ;) And MUST
or even SHOULD look like a very strong requirement on all hosts just
to cover the very special case of sleeping devices.

> 3) What happens if there are more entries then fit in the router's NC?

I guess the same thing which happens in other scenarios when  the
router is trying to create an entry and there is no free space.

> 4) It has been argued against DHCPv6 IA_NA that hosts may need more
>    addresses than can be handled by the DHCP server. There is an RFC
>    that says something to that effect. If so, then we can expect
>    more address than can be handled by the router NC as well. I think
>    we need to be consistent here. Or is this only for some special
>    networks where host have only few addresses?
>    can also expect hoss

Yes, I agree. Normally when a host *assigns* an address it's very
likely that the host is going to use it soon.
Periodic announcements for all preferred addresses does look like an
overkill to me.

> 5) Hosts have to inform all routers, so this would require hosts to track
>    all routers and just a few of them

I'm not sure about this - ff02::2 should work.

> 6) It seems to me that this would something for a new draft

i totally agree.

-- 
SY, Jen Linkova aka Furry