RE: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 15 August 2022 10: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 D134AC1522AB for <ipv6@ietfa.amsl.com>; Mon, 15 Aug 2022 03:14:11 -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 Ixo7zIIGWO_C for <ipv6@ietfa.amsl.com>; Mon, 15 Aug 2022 03:14:07 -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 551D1C14F743 for <ipv6@ietf.org>; Mon, 15 Aug 2022 03:14:07 -0700 (PDT)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M5qkj3vhNz67sVK; Mon, 15 Aug 2022 18:09:17 +0800 (CST)
Received: from mscpeml100001.china.huawei.com (7.188.26.227) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 15 Aug 2022 12:14:04 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100001.china.huawei.com (7.188.26.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 15 Aug 2022 13:14:03 +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; Mon, 15 Aug 2022 13:14:03 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ted Lemon <mellon@fugue.com>, Fernando Gont <fgont@si6networks.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information
Thread-Topic: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information
Thread-Index: AdiloFhLa8BjnlR+QA+N8dfMFruYnwAA02igAAD0bmAAAHJb8AIqYm0AAAOW9YAAANZtAAAF4jYAAAEkEAAAg3AOoA==
Date: Mon, 15 Aug 2022 10:14:03 +0000
Message-ID: <07eb6d50ed254a06a5c1f75b079c0e46@huawei.com>
References: <21348.1660329329@localhost> <D9257BFF-5480-4280-A8CA-598B1388B639@fugue.com> <936589fe-e7ab-9e90-97f7-4d54cfb0c507@si6networks.com> <CAPt1N1msi2M4rZmJQSHVBUE7Lmgqa4WgVw=+4n=Z-P1oVLoMBw@mail.gmail.com>
In-Reply-To: <CAPt1N1msi2M4rZmJQSHVBUE7Lmgqa4WgVw=+4n=Z-P1oVLoMBw@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.202.180]
Content-Type: multipart/alternative; boundary="_000_07eb6d50ed254a06a5c1f75b079c0e46huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GmxmbDYs8unW-6z-LgLmNY4kYjc>
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: Mon, 15 Aug 2022 10:14:11 -0000

You are discussing here yet another corner case that I have not discussed:
If a new router appeared while the old router is temporarily down.

According to the presented Heuristic by Fernando:
RS would be initiated, old router outage would be discovered, old PIO would be disconnected from the old router,
If it was the only router that advertised this PIO then PIO would be un-preferred (no me, not Fernando propose to change valid lifetime).
As soon as the old router would finish reload – it would announce RA, and PIO would be refreshed and preferred again.

I do not see a problem in this corner case. Nor for my draft, neither for Fernando.

Eduard
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Saturday, August 13, 2022 1:21 AM
To: Fernando Gont <fgont@si6networks.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; ipv6@ietf.org
Subject: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

Right. I think this is the correct behavior.

On Fri, Aug 12, 2022 at 17:48 Fernando Gont <fgont@si6networks.com<mailto:fgont@si6networks.com>> wrote:
Hi, Ted,

On 12/8/22 15:59, Ted Lemon wrote:
> Actually the case I’m thinking of is where the router goes down, and
> another router just announces another prefix. In this case,
> following Eduard’s heuristic, hosts on the link would immediately
> stop using addresses on the old prefix. Although actually I think he
> said they’d deprecate that prefix, not unconfigure it, so maybe I’m
> worried over nothing. In that case, existing connections would
> continue to function, and when the router came back, the prefix would
> be un-deprecated.

I believe that:

* while a router is still valid (i.e., Router Lifetime >= 0) (if the
   advertised Router Lifetime was != 0), then hosts should keep the
   addresses

* When a router becomes unreachable (NUD), Next-Hop determination should
   be performed again, *and* anything advertised by this router should be
   unpreferred/deprecated (unless the same info has been advertised by
   another on-link router)

Thoughts?

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