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

Fernando Gont <fgont@si6networks.com> Fri, 19 August 2022 00:35 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 4F9A8C14CE47 for <ipv6@ietfa.amsl.com>; Thu, 18 Aug 2022 17:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 Gl7g1HL7giXK for <ipv6@ietfa.amsl.com>; Thu, 18 Aug 2022 17:35:33 -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 056CCC14F72F for <ipv6@ietf.org>; Thu, 18 Aug 2022 17:35:30 -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)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 26B972802D5; Fri, 19 Aug 2022 00:35:22 +0000 (UTC)
Message-ID: <d1e30732-7902-72cb-48ed-cf98eea108f6@si6networks.com>
Date: Thu, 18 Aug 2022 21:35:20 -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> <4558887a-d5ab-4ca3-3541-dec7f0ffc070@si6networks.com> <CWXP123MB516377B0428BDEA6606CABF2D36D9@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: <CWXP123MB516377B0428BDEA6606CABF2D36D9@CWXP123MB5163.GBRP123.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ziD5ndAv3J-exg5BlawEQ8wnYbU>
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 00:35:35 -0000

Hi, Loba,

On 18/8/22 20:15, Loba Olopade wrote:
> Hello Fernando,
> 
> Kindly check my email again. I never said it doesn't work.

You're right. (my bad!)


> I'm suggesting we are not going far enough. While I agree that some
> changes might take longer to implement, that shouldn't make it a
> non-starter, if it is the more robust way to go.

I believe our algorithm *is* robust. At the end of the day, robustness 
is in asking the router to confirm the assumption -- and also note, that 
that of the information split into multiple packets is a theoretical 
case allowed by the standard, as opposed to something that happens in 
practice.

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