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

Hi Mark, Hi Pascal,
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”.
Jen did mention clearly in her quote “preferred addresses”. I believe that it is the terminology of RFC 4862: preferred and deprecated addresses.
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"
And maybe it make sense to copy “deprecated” and “preferred” from 4862 to 1.2 (Terminology).

Eduard
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>; 6man <ipv6@ietf.org>; 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<mailto:markzzzsmith@gmail.com>> a écrit :

On Sun, 9 Aug 2020, 19:29 Jen Linkova, <furry13@gmail.com<mailto:furry13@gmail.com>> wrote:
On Sat, Aug 8, 2020 at 9:38 PM Pascal Thubert (pthubert)
<pthubert@cisco.com<mailto: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<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------