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

Jen Linkova <furry13@gmail.com> Mon, 10 August 2020 08:24 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 A742C3A145F; Mon, 10 Aug 2020 01:24:44 -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 84c8rezg9txL; Mon, 10 Aug 2020 01:24:43 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 EA86E3A0DDC; Mon, 10 Aug 2020 01:24:42 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id 77so7599418qkm.5; Mon, 10 Aug 2020 01:24:42 -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:content-transfer-encoding; bh=8oJOtUIhRfn0zk+2KIcRnKK7jQZ7KrnmCmIgFfjMRcI=; b=myEMG0vnSXwnG0uToAkbCLGJIVfCx1I/gmVV2YbqKl6tTst530JUVovCNvwbcY/rbn Hr9J61Z3fIOqlo0ScQal2IWDg6ZV6iDIiTSyD64s0GgDxU4m6+Y3Svq8LVum0wrS+3y7 Dl2N6cks3RYmfIdV7DHs6YHvF7Lq9n/E78yye+rfd+zwfBi9CNvg7/uJshvbY2h5yfIL mqukuCKpRglwCUA+x3AiI8EqeBRLrV/Fm8k0uhuQJjuam62ArmK9n63JXC+VHfmYzXQe JDu/JTn0L628T6Tdhw9Rh4tqebwTVG6CZ4djeQZKC1U4TlyUiZTVnKzxD04idIXsfuh0 fe0w==
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:content-transfer-encoding; bh=8oJOtUIhRfn0zk+2KIcRnKK7jQZ7KrnmCmIgFfjMRcI=; b=Vu5n1DyOS/ViQy8Xx5ENwAulc/ec2T5nHVbrQDtxfD2Zv7CAnZlTdoQjpKbOcG2ka8 aiWqmIUbNL92dlHVvzVb4hBkdcCdunVtqi7LS//vgi82XsC0GKceH/T9lGrBZmMS6PCR y/hUNx7E3V28+DiQj8EhQMt7xOMSc93LCUuydp4OZI4VdUxyf/Gke4EJYRUPDIk3v4qp 6Rz04EkKgJprCjo70YGlXYdFVX9z0N1DQiVlYH7Ym4+zELiivxIZWXn+TinpCYAESE0x 2xWF2yMUCwsCiTrNazF8WBwfAxRoKfdvFlBGCYRIrM5oI4+TLfwPWg15UidUkQzL6Jbk azPg==
X-Gm-Message-State: AOAM530kliMA7GTMbV/ft6e+SXtLAqtzZQybMoNzY5OrRhjYxAL6GZZs VRnEGzbMVe32g/zQ/EsDs17IzOsXDc9RsqVwLj4=
X-Google-Smtp-Source: ABdhPJxzL5NJn6S+H3Oa0tn0/NA8UWmYav8cGd+8QMSulkhZkcoSpjHX9L+OnLHLu6xcglvxoKmHrwxYVR7BzSzjdws=
X-Received: by 2002:a05:620a:a05:: with SMTP id i5mr23799591qka.444.1597047881834; Mon, 10 Aug 2020 01:24:41 -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> <CAO42Z2zE3qb=3e07se+XjhK+pT-btTJgZZbKbk7-01yCDfjkjQ@mail.gmail.com> <6DD43215-8059-46F7-86A0-33722205B4F4@cisco.com> <20e805fc75314e7b9388242fbc59759e@huawei.com>
In-Reply-To: <20e805fc75314e7b9388242fbc59759e@huawei.com>
From: Jen Linkova <furry13@gmail.com>
Date: Mon, 10 Aug 2020 18:24:30 +1000
Message-ID: <CAFU7BAQ6HUNh7esYynwx0khw_pz3cwbHrA=sMLSwaG9Y7C_KQQ@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, Mark Smith <markzzzsmith@gmail.com>, Jen Linkova <furry@google.com>, IPv6 Operations <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/X8n8L4OQXodYGnoS7eOd2qB1w_c>
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: Mon, 10 Aug 2020 08:24:45 -0000

On Mon, Aug 10, 2020 at 6:00 PM Vasilenko Eduard
<vasilenko.eduard@huawei.com> wrote:
> I have not understood why you have concerns on this: “even though hosts may not be actively using them” and “old privacy addresses that the host does not plan to use anymore”.

My understanding is that Mark's comment about 'even though hosts may
not be actively using them' was about the assumption that the router
would perform NUD for existing STALE entries so they would be
refreshed. So there is no reason to periodically send NAs.

> Jen did mention clearly in her quote “preferred addresses”. I believe that it is the terminology of RFC 4862: preferred and deprecated addresses.

Indeed.

> If address is deprecated by host, then host would stop cache refreshment (logical assumption).
> Hi Jen, may be to avoid such misunderstanding in the future you could change statement to:
>
> "A node MAY send unsolicited NAs for its preferred addresses periodically to refresh the Neighbor Cache on the first hop routers.
> A node SHOULD refrain from unsolicited cache refreshments for address in deprecated state"

If we want to do this I'd change "SHOULD refrain from" to "MUST NOT send".
Personally I'm not convinced we shall be adding this text.
However the main question would be: how often does the device need to
send those NAs?
The frequency would actually depend on the NC garbage collector/clean
up timer on the router side. It means that node can not know it.
As the main use case is to help nodes waking up after a period of long
inactivity (long ==  long enough for the default routers to remove
their addresses from their NCs),
the node would need to send the unsolicited NA right after wake up and
before sending any traffic. Not sure how complicated it would be from
the host implementers PoV.


> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
> Sent: 9 августа 2020 г. 16:51
> To: Mark Smith <markzzzsmith@gmail.com>
> Cc: Jen Linkova <furry@google.com>om>; 6man <ipv6@ietf.org>rg>; IPv6 Operations <v6ops@ietf.org>
> Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
>
>
>
> We are facing 2 issues in the field that hurt especially in distributed fabrics with spanning L2 emulation (think eVPN and VxLAN)
>
>
>
> One is with old privacy addresses that the host does not plan to use anymore. If the router NUDs them to check if they still exist, we create activity that gives a false sense of liveliness and renews the state indiscriminately with addresses that are really in use. A better NCE management could be achieved if we knew the intent of the host; but the current protocol does not expose that.
>
>
>
> The second is with silent nodes like printers. Such a node has a fixed address but very rare connectivity. The printer may live a long time without any ND traffic and the network may forget the guy. The only way to find him is the multicast which as you know means broadcast.
>
> If the host volunteers a periodic refresh of its active addresses at a period that the router can fathom then both issues can be avoided.
>
>
>
> Ideally the period would depend on the usage to the address and the type of device. So it should also be suggested by the device.
>
>
>
> Obviously we can do better than that but that’s a start...
>
>
>
> Pascal
>
>
>
> Le 9 août 2020 à 11:40, Mark Smith <markzzzsmith@gmail.com> a écrit :
>
> 
>
>
>
> On Sun, 9 Aug 2020, 19:29 Jen Linkova, <furry13@gmail.com> wrote:
>
> On Sat, Aug 8, 2020 at 9:38 PM Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> > Maybe the host should renew the NCE in the router periodically ?
>
> GRAND currently focuses on 'a new address being added to the
> interface' scenario. It does not solve the case of a node starts using
> an already configured address after a long period of inactivity.
>
> 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.
>
>
>
>
>
> Won't NUD probes keep those entries current in the routers' cache, even though hosts may not be actively using them?
>
>
>
> I've thought that something like GRAND + NUD is starting to approach an address registration protocol, or at least, makes the routers' cache the "active addresses on a link" database.
>
>
>
> Regards,
>
> Mark.
>
>
>
>
> What does the WG think?
>
>
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--
SY, Jen Linkova aka Furry