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

Fernando Gont <fgont@si6networks.com> Thu, 18 August 2022 20:18 UTC

Return-Path: <fgont@si6networks.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 59266C14CF01 for <ipv6@ietfa.amsl.com>; Thu, 18 Aug 2022 13:18:10 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 I-UXhJ32Wf5C for <ipv6@ietfa.amsl.com>; Thu, 18 Aug 2022 13:18:09 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC04C14F736 for <ipv6@ietf.org>; Thu, 18 Aug 2022 13:18:07 -0700 (PDT)
Received: from [IPV6:2001:67c:27e4:c::1001] (unknown [IPv6:2001:67c:27e4:c::1001]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DE78C2803F5; Thu, 18 Aug 2022 20:17:59 +0000 (UTC)
Message-ID: <4558887a-d5ab-4ca3-3541-dec7f0ffc070@si6networks.com>
Date: Thu, 18 Aug 2022 17:17:55 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: Loba Olopade <loba.olopade@virginmediao2.co.uk>, Ted Lemon <mellon@fugue.com>, Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
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> <CWXP123MB51639A0445ACD9C0567301B7D36D9@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
From: Fernando Gont <fgont@si6networks.com>
Subject: Re: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)
In-Reply-To: <CWXP123MB51639A0445ACD9C0567301B7D36D9@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XboYjmazLFZvWJIu1tb_Qu-d820>
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 20:18:10 -0000

Hi, Loba,

I had changed the Subject line because the discussion had deviated from 
the original thread: reviewing the algorithm that I posted.

Comments in-line....

On 18/8/22 16:47, Loba Olopade wrote:
> I think the algorithm as suggested works, under the current ND 
> specifications.

Are you referring to the algorithm that I posted? (the one in the 
message that started this thread).

If so, could you comment/describe specifically why you think "the 
algorithm doesn't work".?



> That said, I believe the current specifications should be expanded to 
> enhance both the host and router side heuristics. For instance, a new 
> option in RA indicating that the complete information has been sent by 
> the router would simplify the algorithm.

But in order for that to work, all routers would need to be updated. -- 
and that's a non-starter.

Aside: Why, specifically, do you think the algorithm is complex?
It is seems super simple: "Keep track of the info you have received from 
a router. If you receive partial information, refresh/validate the 
information with a unicasted RS".



> The host could be definite when 
> it has a complete set of information, rather than waiting for a random 
> period. 

The only "random period" we wait is simply to have the possible RSes 
spread over time -- i.e., if you have a network of 100s/1000s of nodes, 
you'd probably prefer that hosts spread their queries over a few 
seconds, rather than have all of then query the local router at the same 
time.



> On the router side (aware that Fernando mentioned that the draft doesn’t 
> address this side, but wanted to put my thoughts down), the question for 
> me is how they detect that hosts are using stale information and then 
> initiate some clean ups. The possibility of hosts including previously 
> received information in their RS could serve as a feedback mechanism, 
> allowing for this router side heuristics.

The idea is simple: we need to address the problem on the basis that the 
hosts should do the magic. Routers, and specifically CPEs, will probably 
take ages to be updated.

And the worst of all possible options are those that need implementation 
in both the host and the router -- since they require changes on both 
sides to be able to see any improvements.

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