Re: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

"xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn> Mon, 29 June 2020 06:51 UTC

Return-Path: <xiechf@chinatelecom.cn>
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 6C32A3A08F9 for <ipv6@ietfa.amsl.com>; Sun, 28 Jun 2020 23:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 rDKHKOfvTLOo for <ipv6@ietfa.amsl.com>; Sun, 28 Jun 2020 23:51:23 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id F3C323A08F6 for <ipv6@ietf.org>; Sun, 28 Jun 2020 23:51:21 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.92:20738.8026580
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.77?logid-d3c34ab4ba2c44fc919551fb9f84a106 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 79B6C280114; Mon, 29 Jun 2020 14:51:06 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([172.18.0.92]) by App0021 with ESMTP id d3c34ab4ba2c44fc919551fb9f84a106 for brian.e.carpenter@gmail.com; Mon Jun 29 14:51:14 2020
X-Transaction-ID: d3c34ab4ba2c44fc919551fb9f84a106
X-filter-score: filter<0>
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 172.18.0.92
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Mon, 29 Jun 2020 14:51:05 +0800
From: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fernando Gont <fgont@si6networks.com>, Gyan Mishra <hayabusagsm@gmail.com>
Cc: "bob.hinden" <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>
Subject: Re: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
References: <CC295D49-5981-41C3-B4DB-E064D66616CE@gmail.com>, <adddbd07-2262-b585-68a1-00fc28207a84@gmail.com>, <CABNhwV0MFe-d6-DL2SuhuyPSq7Mn0-TS=poDn9ynAqn1ZWXOKA@mail.gmail.com>, <3f1c62de-1e58-f063-3907-6e139ada6504@si6networks.com>, <23914f04-b29d-4834-4aa7-b30b9fc18ba5@gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.16.188[cn]
Mime-Version: 1.0
Message-ID: <2020062914510527206819@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart840417538366_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0eBBt2xzjPsbFkY6AqRgr244hp0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 29 Jun 2020 06:51:26 -0000

As an access approach, ADSL has nearly vanished due to being replaced by optical access in some countries. Since the electrical characteristics of optical access is stabler than that of copper line, I think the resets with optical rarely happens in rainy days. :-)

Chongfeng Xie

From: Brian E Carpenter
Date: 2020-06-29 10:10
To: Fernando Gont; Gyan Mishra
CC: Bob Hinden; IPv6 List
Subject: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
On 29-Jun-20 13:48, Fernando Gont wrote:
...
 
>> Since the flash renumbering is such a corner case I think we really have 
>> to vet the impact of changes in all other scenarios.  Also the fact that 
>> users at home are causal users not business critical that can result in 
>> revenue loss I think that would be a consideration.
>>
>> Also maybe having a v6ops draft that talks about corners case issues 
>> which below does exist.
> 
> Would you mind elaborating on what you mean by "corner case"? Operators 
> have repeatedly noted on the v6ops list that these scenarios do happen. 
> And as noted in another email, work on this topic was indeed triggered 
> by an ISP that asked for guidance while dealing with this issues.
 
I'll repeat something I think I said many months ago. While I was in an
apartment that had a defective POTS twisted pair (eventually traced to
water ingress to a defective junction point under the road), I had multiple
ADSL resets every rainy day for months, and because of my ISP's policy
that led to multiple flash renumberings per day.
 
Yes, OK, it shouldn't happen but it does happen.
 
    Brian


 
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum should make it 
> evident that this is a general issue with SLAAC, as opposed to a "corner 
> case" that happens in one particular scenario.
> 
> Thanks!
> 
> Cheers,
> 
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------