Re: [v6ops] Flash renumbering

[Ted Lemon <[e-mail]>]

That’s all you can really do. 

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