Re: [v6ops] Flash renumbering

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 22 September 2020 13:20 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 550A93A0DEB for <v6ops@ietfa.amsl.com>; Tue, 22 Sep 2020 06:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 AMaTL40AL3zj for <v6ops@ietfa.amsl.com>; Tue, 22 Sep 2020 06:20:02 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95843A0CDC for <v6ops@ietf.org>; Tue, 22 Sep 2020 06:20:01 -0700 (PDT)
Received: from lhreml748-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CDF6F89A76A040E08B3E; Tue, 22 Sep 2020 14:19:59 +0100 (IST)
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml748-chm.china.huawei.com (10.201.108.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 14:19:59 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 16:19:59 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 22 Sep 2020 16:19:58 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Flash renumbering
Thread-Index: AdaLlIyewLCjExjqRk+nNQVH29wmCwAzUPGAABOUmgAAGqqFAAAbuXfAAAxRMoAADNTJAP//1BmA///IPECAAEoYgP/7tcFAgAiApID//6SnYAA3P8+A///L4qD//3hW6f/+7aFw
Date: Tue, 22 Sep 2020 13:19:58 +0000
Message-ID: <7080ee174bdc4ddbb800778f4707d442@huawei.com>
References: <8f964b8650cd4b619ff47aed5b07bc67@huawei.com> <7ef6cbcc-164f-383c-658b-b3c0df859535@go6.si> <1af87e24-1410-8f89-b50d-9c61694e4644@foobar.org> <f97b7ac2-0b36-2fae-58fd-eddee6f8b408@gmail.com> <76f10fa7030044c4a0b71443fde92f24@huawei.com> <CAHL_VyC7u7bNJD9pUzbFTrBtifbCVmQtPn4YHHs5g7T6omKwLQ@mail.gmail.com> <2e11a0315196499c81b72c171e014650@huawei.com> <EB3611C3-8849-4670-AFAD-4924AC79E26A@fugue.com> <93e01391b78b4c19be87f58f68281cbf@huawei.com> <CAHL_VyDhUO9mMTXEB1Z53-sA4KtHMu4-vdB0zb-oukanmEdARw@mail.gmail.com> <5b2f71a95a7944f0bcda368c11c6d7a2@huawei.com> <CAHL_VyDP-w9LzQTCkQM-tyjVo+T982aazFJTWeNPvGqHSHRtgQ@mail.gmail.com> <6f5fabd632fb4954adc13ea805be3c0b@huawei.com> <CAHL_VyDO_DTtE2Uj-T2f=a4wdJ2QtNrtO8YwMS88rZtcit5MrQ@mail.gmail.com> <b18832ca2efb44d59d2186863f56481b@huawei.com> <m1kKgil-0000LLC@stereo.hq.phicoh.net>
In-Reply-To: <m1kKgil-0000LLC@stereo.hq.phicoh.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.92]
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SFpL5Is2TUeo2goimS0vkCS990g>
Subject: Re: [v6ops] Flash renumbering
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 Sep 2020 13:20:03 -0000

Hi Philip,
Your comments are always very deep. Thanks!
Could we assume that "IPv6 link" is never disjoint? See in-line.
Eduard
> -----Original Message-----
> From: pch-b9D3CB0F5@u-1.phicoh.com [mailto:pch-b9D3CB0F5@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: 22 сентября 2020 г. 14:44
> To: v6ops@ietf.org
> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>
> Subject: Re: [v6ops] Flash renumbering
> 
> >    We are talking about the situation of uplink lost, then Router
> >    could continue sending old PIOs, but inform hosts that this
> >    router is not default anymore (router lifetime 0).
> 
> If it is a simple router with one uplink and one downlink it makes sense to do so.
> If it isn't already in the CPE requirements then it make sense to do so.
[Ed: ] It is in CPE requirements from Dec 2013 (requirements G-4 and L-3). It is very low probability that any CPE does not support RFC 7084.
> 
> If there are multiple downstream subnets and the router announces a ULA, then
> it becomes more complex because for the ULA, the router is still a default
> router.
[Ed: ] Good comment. But sorry it is even more complicated. I propose to simplify a little.
1. Following this logic we would come to the situation when default router announcement should be related to the fact that routing table has some particular route. It means: ND would become involved into routing. IMHO: it is too much.
2. I propose to disable "default router" in RA only If all uplinks are disconnected (the router could not play router primary role anyway). On-link ULA (or GUA) communication would not be affected (if L flag was set).
You would probably say in response that router is not just forwarding traffic to outside - it is additionally redirect and switch locally for the case when prefix was announced with L bit cleared.
Well, it is possible to fix by small ND update: 
- it is not prohibited by current ND specification to redirects and forward local traffic for the state when router announce 0 default router lifetime - probably should work for many current implementations.
- but host would probably not send traffic to router that is not default (even for traffic inside PIO).
What if we add the rule: host could always send traffic to the router (irrespective to router lifetime) if traffic is destined to node that is inside prefix announced by this router.
It is effectively different definition of "local": "router is always local for all hosts in the prefix announced by this router". Or in another way: "link is never disjoint"
?????
Then would be the nice solution for router that lost global connectivity. Irrespective: ULA or GUA.
> 
> One option would be to change the priority of the router, but that would make
> address section more complex in the case of a multi-homed network.
> 
> One option would be to move away from default routers and only have Route
> Information Options (RFC 4191).
[Ed: ] I am hesitant to qualify: was it right or wrong.
But I would like to point that this ND extension was not included into the current ND specification.
[Ed: ] It means that there were 6man consensus in 2007: it is too much to inject routing information into ND.