IETF Logo Mail Archive

RE: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages

Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 10 June 2022 07:38 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 AE1F2C159488; Fri, 10 Jun 2022 00:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 w9HbU3iEPHLx; Fri, 10 Jun 2022 00:38:28 -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 82FEBC157B40; Fri, 10 Jun 2022 00:38:28 -0700 (PDT)
Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LKCPV0sgsz686H8; Fri, 10 Jun 2022 15:33:34 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 10 Jun 2022 09:38:19 +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, 10 Jun 2022 10:38:18 +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, 10 Jun 2022 10:38:18 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fernando Gont <fgont@si6networks.com>, "ipv6@ietf.org" <ipv6@ietf.org>
CC: "draft-ietf-6man-slaac-renum@ietf.org" <draft-ietf-6man-slaac-renum@ietf.org>
Subject: RE: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages
Thread-Topic: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages
Thread-Index: AQHYe9drwJMJuHbSY0+HxAicV2izeK1HN7iQ///PtwCAATgjAA==
Date: Fri, 10 Jun 2022 07:38:18 +0000
Message-ID: <fc8ef78521664e96b590a1b52fb0c587@huawei.com>
References: <971cee77-6cf5-513f-c72b-458b1f0b581c@si6networks.com> <07637e195f2b43d7a38890ca697e91eb@huawei.com> <dd154578-2e93-25c8-8623-fe16cbea9b10@si6networks.com>
In-Reply-To: <dd154578-2e93-25c8-8623-fe16cbea9b10@si6networks.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.170.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KywktyvvtWqtULnxMiVAov4DB9c>
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, 10 Jun 2022 07:38:29 -0000

Hi Fernando,
OK. More openly: your solution does not work.
You have forgotten to introduce a timer of a flag or something else to inform the host that it is the last RA in the chain was received
Then host could start concluding what are discrepancies with his states and what to deprecate.

Another option is to depreciate the capability to send many RAs.
Request that all information MUST be in one RA only.
Then it would be easy to understand that host received everything and could make conclusions.

As you specified currently, you would create PIO flapping in some corner cases (chain of RAs) that have a low probability to happen
But it would happen.

In our draft we have proposed a flag to inform the host could start making conclusions.
https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02

Eduard
-----Original Message-----
From: Fernando Gont [mailto:fgont@si6networks.com] 
Sent: Thursday, June 9, 2022 6:51 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; ipv6@ietf.org
Cc: draft-ietf-6man-slaac-renum@ietf.org
Subject: Re: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages

On 9/6/22 12:45, Vasilenko Eduard wrote:
> Hi Fernando,
> How long host should wait next/last RA to make sure that all information was received?

That's completely orthogonal to this question, isn't it?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email