IETF Logo Mail Archive

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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 18 August 2022 06:34 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 EE57CC1526F1 for <ipv6@ietfa.amsl.com>; Wed, 17 Aug 2022 23:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 p0_7urIqEJhC for <ipv6@ietfa.amsl.com>; Wed, 17 Aug 2022 23:34:17 -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 84A28C1526EC for <ipv6@ietf.org>; Wed, 17 Aug 2022 23:34:17 -0700 (PDT)
Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M7Zlc3sSJz67yfJ for <ipv6@ietf.org>; Thu, 18 Aug 2022 14:31:08 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 18 Aug 2022 08:34:15 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 18 Aug 2022 09:34:14 +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; Thu, 18 Aug 2022 09:34:14 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ted Lemon <mellon@fugue.com>, Fernando Gont <fgont@si6networks.com>
CC: "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/yntINti0SV8vOTyqLOdK2zwZOAgABwB6A=
Date: Thu, 18 Aug 2022 06:34:14 +0000
Message-ID: <ad055c420ec147c2acabf25cec168a31@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>
In-Reply-To: <CAPt1N1n5BuDiNPsqZi23CXZryopO8eKiscSsw+u7=UtwnWj4Kg@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.45.146.105]
Content-Type: multipart/alternative; boundary="_000_ad055c420ec147c2acabf25cec168a31huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6e2hAwBoroVUHMPl4BN566OueMs>
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: Thu, 18 Aug 2022 06:34:19 -0000

>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]
Sent: Thursday, August 18, 2022 5:46 AM
To: Fernando Gont <fgont@si6networks.com>
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>; 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

v2.23.0 | Report a Bug | By Email