Why You Need To Demand Standards, Now

In technology, there is lots of talk about the need for standards for this or that technology. I am an unabashed proponent of standards. There are lots of very smart people who work on standards either as part of their job or on their own  time. The standards get pushed through the working groups, are ratified by the standards bodies, and are published to the world. Then those people move on to other things while vendors scramble to implement the standards in their products and update their data sheets.

Of course, that doesn't mean that products will interoperate, right? If you have been in IT for any length of time, you've witnessed the finger-pointing among vendors about how a competitor's product doesn't conform to the standards while theirs does. In many cases, both vendors are right and wrong.

Any useful standard is likely to be pretty complex. I know that the people who staff the standards bodies work diligently on developing standards and nailing down minutiae, but there is no way to predict all of the possible interpretations of the standards documents. Often times, the confusion is over little things like field interpretations or process flows, and depending on how you read it, you can implement the standard in different, but valid, way.

How does this get resolved? One way is with plug fests. Getting the implementers and engineers in a room where they hook up gear and see what works and what doesn't. Then they ferret out the root cause and figure out the best way to resolve the problem. If all goes well, these problems get resolved and everyone agrees to the same interpretation of the standards and that gets fed back into the product development process. That's what is supposed to happen, at least, but it doesn't always. There were plug fests for IPSec testing, but trying to get vendor A's product to talk to Vendor B's product (I was doing this way back in 98 when IPSec was all the rage) was an impossible task unless the vendors did specific interoperation work outside of the plugfests.

We were destined for the same outcome with Wi-Fi, where various vendors would interpret 802.11 specs differently and the products from different vendors wouldn't work together.  Until the Wi-Fi Alliance was created to perform interoperability testing and a logo program demonstrating significant, functional, interoperation. The Wi-Fi alliance didn't create standards, they just became the defacto interpretation of the standards. The resulting interoperation between vendors demonstrated through the Wi-Fi Alliance logo program is what allowed Wi-Fi to grow astronomically.The same can be said of the Metro Ethernet Forum that brings together all the relevant stakeholders like carriers and vendors, taking the work from the IEEE and providing a uniform interpretation of the standards so that interoperability can take place. Without the work of the MEF, standardization would likely have taken place anyway, since the carriers tend to have dual-source equipment policies and would thus force interoperation, but the MEF moved things along and smoothed the process.

As vendors and IT march along to converged networking, we need to ensure that our next generation networks are going to be interoperable in meaningful ways. Primarily in the area of supporting the protocols and standards for Data Center Bridging (DCB). Granted, the standards are still moving through the task groups and working groups in the IEEE and IETF, so it may be too early to expect interoperable products, but process-like plug fests and other conformance testing needs to be at the forefront of everyone's mind. You, the IT buyer, need to be telling your vendors loud and clear that you want demonstrably interoperable products. In fact, interoperable products should be a requirement.

I have said this before. If you don't make the demands of your vendors, and if you don't make interoperable standards a requirement for your equipment purchases, then you can expect to see an environment around FCoE much like we see with Fibre Channel today: qualified equipment lists that limit you to approved products only. Violation of support contracts if you go off the reservation. And of course, long term lock-in.