On accents, colloquialisms and proprietary extensions

Published On 2013/06/19 | By Kurt Bales | Rant

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.

Like this Article? Share it!

About The Author

Kurt is a Network Engineer based out of Sydney Australia. He a the Senior Network Engineer at ICT Networks where he spends his time building Service Provider networks, and enterprise WAN environments. He holds his CCNP and JNCIE-ENT, and currently studying for his JNCIE-SP and CCIE R&S. Find out more about Kurt at http://network-janitor.net/ and you can follow him on Twitter.
  • Hey Kurt,

    I would have posted via Twitter but intensedebate wants far more rights that it really needs (like posting on my behalf). You might want to look at Disqus.

    Onto the subject of the article, avoiding incompatible proprietary extensions (or other vendor lock in techniques) is never going to be easy. I found trying to trunk VLANs between Extreme and Cisco switches, both running 'standard' RSTP, a few years ago impossible and that was without 'extensions' being involved. The vendors don't like standards, they are not good for business.

    If we want this to change I've a few suggestions that would help us all if we just had the will;
    1) Don't blindly buy kit from a single vendor (only the vendor benefits)
    2) Don't use any feature that's proprietary (only the vendor benefits in the long run)
    3) Don't buy kit that isn't interoperable (following 1) makes this necessary anyway)
    4) Favour anything that's open or open source and/or runs Linux
    5) Especially with new sites/projects and any use of SDN, push hard for for open products
    6) Standards tracks need to catch up with the rest of the world and work much, much faster