Re: [v6ops] Flash renumbering

[Ole Troan <[e-mail]>]

> 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.
>>>