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

Hi Jen,
About this new idea (not yet incorporated into your GRAND): to send unsolicited NA after wake-up. What is wake-up? IMHO: it is timer only.
I hate additional timers. Could you choose any existing timer from RFC 4861? (even if it would be not very optimal)
Then "send unsolicited NA to routers if traffic has not been sent from preferred address to off-link for timer T"
Eduard
-----Original Message-----
From: Jen Linkova [mailto:furry13@gmail.com] 
Sent: 10 августа 2020 г. 11:25
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>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

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