6man's draft-ietf-slaac-renum (Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum)

[Fernando Gont <[e-mail]>]

On 8/4/20 14:57, [e-mail] wrote:
>>>>>>>> We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe?
>>>>>>> No. You are proposing to use the prefix timers for something they were never designed for.
>>>>>>
>>>>>> 1) I'm proposing to use prefix timers... for timing out timers :-)
>>>>>>
>>>>>> The Preferred Lifetime, to deprecate an otherwise preferred prefix.
>>>>>> The Valid Lifetime, to invalidate the prefix.
>>>>>>
>>>>>> Just of curiousity, may I ask what do you think they are meant for? (of course, wasting them by using huge values not being a valid option).
>>>>> They are meant to support renumbering.
>>>>
>>>> Part of renumbering is phasing out prefixes. And this is what we are doing here.
>>> No you are not.
>>
>> Let's agree to disagree.
>>
>> I put a timer for addresses. Unless there's any sort of signal that the configuration is current in a veeery reasonable period of time, I phase out the prefix.
> 
> I think you are mixing what you are proposing in 6man with what you are proposing in v6ops.
> The current draft in v6ops is reasonable, if the review comments I posted are included.

Not sure what the "review comments you posted" are. I had responded with 
proposed text to address your comments. Are you referring to that? If 
so, yes of course that will be incorporated.



> The added text on lifetimes in this document is not.

The text on lifetimes was suggested in the WGLC thread. Please, even if 
you disagree, respond on that thread, because this one has deviated from 
the v6ops document for a while now. Of course I have my own view on the 
topic. BUt I don't mind the outcome -- the point is to have that 
discussed in the separate thread, so that we can agree on *something*. 
Also, whatever you object about the proposed text, please mark it clearly.


Now, going back to the 6man document, it essentially has two parts:
1) Using appropriate lifetimes
2) Inferring stale information.

#1 is similar to the new proposed text for the document you seem to 
object. -- And I don't see what, specifically, you object about it.

#2 Not sure what you don't like about it.



[...]
>>> If that simple operational rule was followed, then none of these tweaks are required. (At least for this purpose).
>>
>> If folks had follow the simple operational plan that everyone enables v6, and then when everyone could simply disable IPv4, we would have deployed v6 20 years ago, and we wouldn't have the ..load of transition/co-existence mechanisms that we have.
>>
>> But hey, engineering is a bit about solving problems in the real world, rather than complaining that the problems are not solvable because the planet should actually be spinning in the opposite direction.
> 
> I take it being condecending is your way of saying you have run out of arguments?

Clearly not. I wasn't being condescending. I was actually saying that 
quite often one need to solve scenarios that, on paper, don't take 
place. But in practice, they do. So you tell me that you have a paper 
that says how to do renumbering -- that's great, and I like it.

But at the same time, we have people telling us, that they have real 
world scenarios that our current protocols, as is, don't handle 
properly. And in many cases (such as a user who's ISP does dynamic 
prefixes, or who has a CPE that announces PIO lifetimes past the PD 
lease), they have no control over the elements that trigger such scenarios.

* In the best interest of v6ops, and in the best interest of 6man, we 
probably want, to the extent that is possible, that our protocols handle 
such scenarios gracefully. -- in a way, you could even frame this in 
Postel's principle. (handle in a gracefully manner scenarios that you 
thing shouldn't happen).

* We do a bad service to the ISP that want to deploy IPv6 and face these 
problems while deploying (this work was indeed triggered by an ISP 
deploying IPv6) -- it's a hassle they have to deal with, and it's calls 
they are going to get. And also, because if they are "lucky", the 
traffic they expected to go over IPv6, will go over IPv4 -- exactly the 
opposite of what they were expecting.

* And we do a bad service to the user, because if as soon as the ISP 
turns on IPv6, his/her connections gets stalled frequently, and the 
users somehow realizes that that happened since the ISP enabled IPv6 
that's another one that goes into the basket of -> disable IPv6.




> The point is that there are many ways of misconfiguring or doing the mechanics of prefix delegation wrong.
> That doesn't mean we should adapt the standards to accommodate who do not do it the way it is specified.

I don't see the point of repeating what a number of operators mentioned 
on this list already: there are multiple scenarios for which 
flash-renumbering may happen.




> Especially when those operational practices have bad implications on end-users, and the mitigations proposed are potentially risky for the majority who will never see a network "operated" this way.

You claim "this is potentially risky". Could you please elaborate what, 
specifically, you think is risky? And what's the scenario where what's 
being proposed would fail?




>>>> A core design principle of the Internet is that as long as there is a working path from source to destination, communications survive possible outages.
>>> Oh, I'm not saying that we shouldn't make host behaviour more robust. Rather the contrary. I'm just saying I don't think the proposed changes are the right ones.
>>> Let me see if I find some spare time to write down how I would like it to work. Don't hold your breath.
>>
>> We have been discussing this problem for over one year now.
> 
> Yes, you have.

No, not "me". We as a group. I understand that you probably have your 
own view on the topic. But I do believe that, ultimately, it is the 
*wg's* decision what to do with documents.

So... why can't the wg be polled about it?

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492