Re: [v6ops] Flash renumbering

[Ole Troan <[e-mail]>]

> On 19 Sep 2020, at 03:29, Ted Lemon <[e-mail]> wrote:
> 
> 
> That’s all you can really do. 

That’s incorrect. 

Ole


> 
>>> On Sep 18, 2020, at 21:16, Ole Troan <[e-mail]> wrote:
>>> 
>> 
>> 
>> 
>>>> On 19 Sep 2020, at 02:44, Ted Lemon <[e-mail]> wrote:
>>>> 
>>> 
>>> ISTM that there is already quite a bit of good work going on in this space, which I support. I may have more to offer later, but it requires running code to test. 
>> 
>> OK, I wasn’t aware of any work to support flash renumbering. Only to mask some the worst effects of it. 
>> 
>> Ole
>> 
>> 
>>> 
>>>>> On Sep 18, 2020, at 20:30, Ole Troan <[e-mail]> wrote:
>>>>> 
>>>> 
>>>> Ted,
>>>> 
>>>> Why don’t you write a draft on how you would like flash renumbering to work. 
>>>> 
>>>> Ole
>>>> 
>>>>>> On 19 Sep 2020, at 00:15, Ted Lemon <[e-mail]> wrote:
>>>>>> 
>>>>> On Sep 18, 2020, at 5:21 PM, Ole Troan <[e-mail]> wrote:
>>>>>> Corner case because Service Providers generally do not flash renumber their customers. 
>>>>> 
>>>>> Just saying that way implies so many assumptions that really aren’t general. E.g.:
>>>>> 
>>>>> - The ISP can never have a reason to flash renumber, or so rarely that if it blows up your network that’s fine (when is that ever fine?)
>>>>> - All of the boxes between you and your ISP are carefully curated so that nothing ever goes wrong that results in a theoretically-preventable flash renumber event.
>>>>> - The network topology is completely stable.
>>>>> - Your uplink is wired, so there’s no possibility of RFI forcing a renumbering event
>>>>> - It’s not many hops to the backbone, and all of the intermediate links are reliable and stable
>>>>> - Reliability in the on-site infrastructure is nice-to-have, not required (light switches don’t have to work)
>>>>> 
>>>>> Etc.
>>>>> 
>>>>> I think that when this position is put forward as a sort of universal ground truth, it is actively harmful to end users.
>>>>>