On accents, colloquialisms and proprietary extensions

I may not be the most “travelled” person in the world, but over the past couple of years I have managed to find myself in several places across Asia, the Pacific Islands and also the US. One thing has always stood out – Speaking the same language is the hardest part of travelling! Now when I travel to parts of Asia and Im dealing either in hand gestures or with somebody trying their very best speak English (Their English is 1000x better than my Cantonese or my Khmer), and we both make allowances for the difficulty of not speaking the same language.

Sadly, when I travel to the United States and we both attempt to speak “English” nobody can ever seem to understand me. Sometimes its my accent, and other times its the colloquialisms I am using that do not translate effectively, and I am treated by blank stares on the other person trying their hardest not to say “Huh?”.

I’ve learned to deal with this by talking slower and thinking carefully about the words I use to ensure that they dont have some local significance. Anybody who has met me in person knows that I talk loudly, quickly and for a long time, but put me on a call (or a podcast) with guys from the US and I have to slow it right down (and trust me, its painful listening back to it!).

So what does this have to do with networking? Well I was reading this post by Mrs. Y over on the Packet Pushers blog, and it started to resonate with some thoughts I had been having problems putting into words. In the article she mentions how the various wireless vendors implemented the CAPWAP “standard”, but the actual implementation of the standard with accompanying “extensions” means that solutions did not allow for cross vendor integration. I read this post about 30 seconds after reading this post from Ivan Pepelnjak where he mentions about NEC needed to implement certain features to their ProgrammableFlow controller to provide better stability, but at the potential cost of not being compatible with other vendors – the very thing OpenFlow was designed to support.

It may also be of note that I spent most of my day today working on some integration testing between Juniper MX and Cisco ASR9k routers to facilitate Multicast across Point-to-Multipoint MPLS LSPs. Part of todays work involved finding out exactly which parts of the “standards” were best supported across both vendors while not taking advantage of either vendors “nerd knobs” and “enhancements”. Sometimes each vendor had implemented different solutions to get around an “on the ground problem”, and it was partly my job to which ones played nicely across both – and with the least downtime.

So my thoughts (and I dont have any answers… just thoughts), come down to “What is better? Implement a standard, then put fixes and extensions on top of it to do what I need, or to build a new protocol?”. To a degree having “some form” of integration between vendors is very important, but if the 95% use case is making use of proprietary extensions then have we really achieved that? People ask “Why did Cisco come out with onePK instead of OpenFlow?”, but then I question “Well if they wanted to provide more functionality than OpenFlow provides, why extend the model with non-interoperable parts and pretend to still be OpenFlow?”.

Just like speaking the same language but still not understanding each other, how should we ensure better communication while not causing unneeded long term pain? Maybe the answer is to implement extensions, then work with the community / standards bodies to allow cross vendor in the future (and still provide first mover advantage for the innovator). Obviously commercials around this make this a less attractive option for the big players, but this is how standars get retroactively created.

I would be really curious to know your thoughts.