On Jun 12, 2011, at 4:01 AM, Iljitsch van Beijnum wrote:
On 11 jun 2011, at 17:05, Owen DeLong wrote:
Your doctor doesn't just give you the medicine you ask for either.
You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you are in the field and every bit as capable of making informed decisions about the correct solution for their environment.
It's true that the patient also knows some stuff here.
There's a lot of bitching here on the NANOG list about how operators get no respect at the IETF. But that's a two-way street. There's also tons of people in operations who have no appreciation to what the IETF brings to the table.
Operators tend to see issues in isolation, or at the very least only see the connections that are relevant to their environment. The IETF has to take into consideration all possible environments. Sometimes things that seem a clear win in a constrained environment could be a disaster if they were used all over the internet.
Sure, but, doing that for something that is only locally significant, such as RA/DHCP means that you should implement a true superset of the operational requirements so that operators can choose the tools that best fit their environment, rather than a rag tag set of incomplete tools that require operators to implement ALL of them in order to form a single complete solution and offer no flexibility on which set of solutions is chosen. Guess which one more accurately describes the current state of RA/DHCPv6 from an operator perspective?
You know what they say: a doctor who treats himself has a fool for a patient.
Yes, but, a doctor who accepts the word of another doctor without doing his own analysis is unlikely to be a patient for very long. Death has a way of terminating doctor patient relationships.
Yes, I'm well familiar with your level of arrogance.
Yes, I know I stick out like a sore thumb in these humble parts.
OK... Point taken. However...
BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like).
Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae such as 8+8 vs. GSE?
Judge for yourself:
http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt
I'm sure that got reasonably well shouted down, but, it's close enough to a few pieces of IETF dogma that I suspect it probably didn't result in "fool, go home" style comments from too many places.
Let me wrap up this discussion with the following:
IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. All of this makes it seem like a good idea to tweak stuff to make it better, but in reality that's a mistake: it just means more opportunities for things to fail. What we need is to rethink the host configuration problem from the ground up, starting at the host and what it should do when it sees its interface come up.
I'm fine with that latter idea and it may well yield a better solution. However, in the operational world, we cannot wait for that and what we have today is not sufficiently adequate to meet real world requirements as they exist today. As such, we MUST modify what we have today in ways that extend it to have the capabilities that are required. I understand you find this distasteful. I even understand some of your reasons. I even agree with some of them. However, we do not have the option if we are to make IPv6 deployable in the enterprise of ignoring these requirements. These aren't situations that have existing workarounds and the administrators are simply opposed to doing things differently. These are situations where the fundamental operation of the network cannot be accomplished under IPv6 within the current organizational requirements. Asking organizations to restructure their networks is one thing. Asking them to also reorganize their organizational politics around that network restructuring is, well, "recipe for fail" seems like an understatement.
One model that seems attractive here is the on the iPhone uses, where you can modify the IP configuration on a per-wifi network basis. If we can apply this kind of logic to wired networks, too, then suddenly we're no longer limited to having one monolithic set of client side behavior that must always be followed, but we can be much more flexible.
The real goal should be to have a way (or ways) for hosts to operate across a wide variety of environments with zeroconf. Having to build profiles for different networks is a great workaround for failures in that effort, but, it is not what I would call a good solution to the problem in general. Owen