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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 10 August 2020 07:59 UTC

Return-Path: <vasilenko.eduard@huawei.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 2592A3A07B9; Mon, 10 Aug 2020 00:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 WCrd1arIy_RR; Mon, 10 Aug 2020 00:59:38 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B03E3A1456; Mon, 10 Aug 2020 00:59:38 -0700 (PDT)
Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 071702C79586B0262680; Mon, 10 Aug 2020 08:59:35 +0100 (IST)
Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 10 Aug 2020 08:59:34 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 10 Aug 2020 10:59:34 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 10 Aug 2020 10:59:34 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "Mark Smith" <markzzzsmith@gmail.com>, Jen Linkova <furry@google.com>
CC: 6man <ipv6@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-ietf-6man-grand : saving lookups
Thread-Index: AQHWZ1a/pXlTW2isS0uZz3jAApjDoKkrvR+AgABsmQCAAcAAgIAABj+AgAFuDICAAAMeAIAARf0AgAFe3pA=
Date: Mon, 10 Aug 2020 07:59:33 +0000
Message-ID: <20e805fc75314e7b9388242fbc59759e@huawei.com>
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>
In-Reply-To: <6DD43215-8059-46F7-86A0-33722205B4F4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.200.103]
Content-Type: multipart/alternative; boundary="_000_20e805fc75314e7b9388242fbc59759ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/d7YFcVFXG3SP4zla4CFNWPAKja4>
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 07:59:40 -0000

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