RE: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)

Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 19 August 2022 07:14 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2793AC152587 for <ipv6@ietfa.amsl.com>; Fri, 19 Aug 2022 00:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9KXZwGbiHe9 for <ipv6@ietfa.amsl.com>; Fri, 19 Aug 2022 00:14:27 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F86C14CE2E for <ipv6@ietf.org>; Fri, 19 Aug 2022 00:14:27 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M8Cfm3PJ1z6897Z for <ipv6@ietf.org>; Fri, 19 Aug 2022 15:14:08 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 19 Aug 2022 09:14:24 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 19 Aug 2022 10:14:23 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Fri, 19 Aug 2022 10:14:23 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ted Lemon <mellon@fugue.com>
CC: Fernando Gont <fgont@si6networks.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)
Thread-Topic: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)
Thread-Index: AQHYsqwCe/yntINti0SV8vOTyqLOdK2zwZOAgABwB6CAAEZEAIABWBwg
Date: Fri, 19 Aug 2022 07:14:23 +0000
Message-ID: <41a004e8800845f095967b01bc9bc469@huawei.com>
References: <0f93a951ee174382803bea2729e8e605@huawei.com> <83C838D4-8741-4643-9809-4EAE500F6DE7@fugue.com> <ff718a0b4dad49c9a9e895c52b4869e5@huawei.com> <baba87f1-5446-1d67-6a83-18fd22fb71e2@si6networks.com> <CAPt1N1n5BuDiNPsqZi23CXZryopO8eKiscSsw+u7=UtwnWj4Kg@mail.gmail.com> <ad055c420ec147c2acabf25cec168a31@huawei.com> <CAPt1N1m53-K95LiWc=Dddcr-80kFUb7upgFiue=GPAXyaHWa1A@mail.gmail.com>
In-Reply-To: <CAPt1N1m53-K95LiWc=Dddcr-80kFUb7upgFiue=GPAXyaHWa1A@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.207.41]
Content-Type: multipart/alternative; boundary="_000_41a004e8800845f095967b01bc9bc469huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ji9NqNdzGcecYC72WsMD7LjIQnE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 07:14:30 -0000

Hi Ted, see in-line.
Ed/
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Thursday, August 18, 2022 4:38 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Fernando Gont <fgont@si6networks.com>; ipv6@ietf.org
Subject: Re: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)

I summarized because I'm just repeating things we've already discussed. When a new router shows up, we use that as a signal that the link may have changed. We probe our old routers using unicast RS. If they answer, great, if not, we deprecate their information. That takes care of the problem of continuing to use stale information.
[EV] Looks like the explanation for Fernando’s proposal. I have compared it to another option in a response to Fernando. It has advantages and disadvantages. My conclusion: less robust than the competitive proposal, but possible – not very bad.
Secondly, the draft already places constraints on how long we will consider a router to be alive if we haven't heard from it. If we don't hear from it over that time period, then we flush its information.
[EV] I hate timers that are possible to avoid. It greatly influences robustness.
So the problem that you described of the table growing without bound is taken care of as well. I suppose we could add a heuristic that if the table exceeds an implementation-dependent size limit, the oldest router may be flushed to make room for a newer router. Perhaps that's already in the spec—I'd have to go look.
[EV] I still do not understand why we need to keep stale information.

On Thu, Aug 18, 2022 at 2:35 AM Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
>1. if we see evidence that the old router isn't there, prefer the new router.
How?
>2. Don't keep stuff around forever, even if the router tells us to.
Do not understand the use case.

I do not understand these too general statements.
If you would propose what exactly you have in mind (ND modification)
Then I would be capable to judge:

1.       Is it useful?

2.       Is it related to “flush renumbering”?

Reminder, we have stale information that we need to deal with. The problem that we are not aware that the information is stale.
RFC 6059 proposes to keep even more stale information. Hence, RFC 6059 is not related to the “flush renumbering”.

Eduard
From: Ted Lemon [mailto:mellon@fugue.com<mailto:mellon@fugue.com>]
Sent: Thursday, August 18, 2022 5:46 AM
To: Fernando Gont <fgont@si6networks.com<mailto:fgont@si6networks.com>>
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; ipv6@ietf.org<mailto:ipv6@ietf.org>
Subject: Re: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)

Right. Combining these two mechanisms should synergize well. To oversimplify:
1. if we see evidence that the old router isn't there, prefer the new router.
2. Don't keep stuff around forever, even if the router tells us to.

On Wed, Aug 17, 2022 at 10:41 PM Fernando Gont <fgont@si6networks.com<mailto:fgont@si6networks.com>> wrote:
On 17/8/22 06:57, Vasilenko Eduard wrote:
> Hi Ted,
> I still do not agree that it makes sense to collect the big table of stale ND information.
> Because after PIO preferred has been put to 0. PIO validity may be still 1 month.

Well, part of the issue there is that the PIO lifetimes should be
sensible. -- that's why we have a recommendation in that regard.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<mailto:fgont@si6networks.com>
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494