IETF Logo Mail Archive

Re: [v6ops] Thoughts about wider operational input

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 22 March 2022 16:58 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADB03A0AA6 for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 09:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJcJ2cN3qHob for <v6ops@ietfa.amsl.com>; Tue, 22 Mar 2022 09:58:26 -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 EB73E3A0AA7 for <v6ops@ietf.org>; Tue, 22 Mar 2022 09:58:25 -0700 (PDT)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KNHht1DQcz67M6M for <v6ops@ietf.org>; Wed, 23 Mar 2022 00:57:18 +0800 (CST)
Received: from mscpeml100001.china.huawei.com (7.188.26.227) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 22 Mar 2022 17:58:22 +0100
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.2308.21; Tue, 22 Mar 2022 19:58:22 +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.2308.021; Tue, 22 Mar 2022 19:58:22 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Gert Doering <gert@space.net>
CC: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Thoughts about wider operational input
Thread-Index: AQHYPWL+5ay9cZSrXUWG+DzsIaGQi6zKIZgAgAAMoQCAAA6FAIAApH4AgAALFICAABB9AIAAUtEQgAACLQCAAEnGkP//zu8AgAAzNpD//8+NgIAAMxGQ
Date: Tue, 22 Mar 2022 16:58:22 +0000
Message-ID: <b9fcb588be894715aaa3ca691997a812@huawei.com>
References: <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com> <YjmJQMNgnJoSInUw@Space.Net> <D75EF08F-6A41-41B2-AFB2-649CBCC1D83E@consulintel.es> <YjmgYA2Wee8f2HAY@Space.Net> <27655a220efb416198d11d5652f45c96@huawei.com> <YjnnrPr5zqAkXoLg@Space.Net> <763e5ec7e18c465a8af81a0cd64eb0c4@huawei.com> <Yjn8ZoGlOEynKN4b@Space.Net> <82a76edffbc9497891ad4bd1b577dbbe@huawei.com> <Yjn+t0ng/BH9LTFX@Space.Net>
In-Reply-To: <Yjn+t0ng/BH9LTFX@Space.Net>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.192.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TC-iXvCjTW0OCIHEumiUzRgaPDM>
Subject: Re: [v6ops] Thoughts about wider operational input
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 16:58:31 -0000

Subscribers tend to fix everything by reloading.
CPE would not know what to deprecate after the reload.
Even 15min for a preferred lifetime is not a good solution (telephony had 50ms in 1970),
Less than 15min would be risky for some environments.

"Flash renumbering" should not be resolved by timers. It should be logic of events that would be much faster.
https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02

Ed/
-----Original Message-----
From: Gert Doering [mailto:gert@space.net] 
Sent: Tuesday, March 22, 2022 7:52 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Gert Doering <gert@space.net>; JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>; v6ops@ietf.org
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

On Tue, Mar 22, 2022 at 04:47:31PM +0000, Vasilenko Eduard wrote:
> > This is purely a question of RA parameters used by the LTE router towards the LAN.
> 
> No. It is not possible to achieve fast convergence by timers.
> The current preferred timer is especially big by default, But it is 
> not possible to put it small enough.
> ND protocol change is needed.

There is nothing in ND protocol that prevents setting timers lower than
1 week.  Nothing.

"Big by default" is a pure implementation decision in your LTE router - it could be announcing "12hour" instead of "1 week", and would be perfectly in line with ND standard.

Prefix depreciation by announcing "preferred lifetime = 0" works.

Please read the documents I've referenced.

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

v2.23.0 | Report a Bug | By Email