If you think about it, there really hasn’t been any other technology that has raised the concerns about standards in the way that FCoE has. Suddenly, people are concerned about standards and how complete they are and don’t want to make a move until the standards are “done.”
You’d think people were afraid of salmonella poisoning if you use FCoE before it’s “cooked.”
So how can you tell? How do you know when standards are “done?”
Let’s face it, the standards bodies aren’t exactly up-front about this. It’s not that they’re not transparent; it’s just that they have their own terminology, processes, and jargon and people who just want to find out a simple answer to a simple question are left feeling like they just had a “simple” conversation with Alan Greenspan about macroeconomics. In other words, they’re left scratching their heads and wondering what just happened.
So, let me try to break things down into Plain English™. While the terminology varies depending upon the standards body, the process is pretty much identifiable according to 4 phases, as shown in the graphic below.
It’s easy to get lost in the terminology. “Working Groups” and “Task Groups” are different things between 802.1 and T11. Different votes and ballots also mean different things. For our purposes here, though, the key thing to remember is that the processes are pretty consistent, and that the moment in time we are waiting for in terms of when the standard is technically complete happens when the development group stops arguing.
No, seriously. When the technical group completes its discussion of the proposals and consensus is achieved in Phase 2, the standard document is no longer in technical debate, and is considered stable. From this point it is safe for companies to create products based on that technical document.
The “Approval” phase provides the opportunities for participants to submit comments, change wording or text, but the technological aspects of the standard remain relatively stable.
So as far as FCoE is concerned, where are the standards, as of this writing?
Let’s try to redefine the question so that it’s more useful: What problems need solving and where are the standards in development with respect to solving that problem?
For FCoE there are two problems that you need to solve:
1) Placing Fibre Channel frames onto other media (e.g., Ethernet), and
2) Making the medium lossless
Those are the problems that need solving in order to run FCoE. There are other standards documents that address running FCoE with other protocols at the same time (aka Converged I/O), and those relate to:
3) Bandwidth management, or guaranteeing bandwidth for different types of traffic, and
4) Device configuration, or creating a means where devices can talk to each other and get their settings sync’d up
There are other documents within the DCB that address other problems, but those are unrelated to running FCoE. If you’re thinking about running FCoE in the Data Center and are concerned about standards, those are the problems that you’re concerned about solving.
Fortunately, those problems have been addressed, respectively:
1) FC-BB-5 (also handles the technical problem of multi-hop FCoE!)
2) 802.1Qbb (Priority Flow Control, or PFC)
3) 802.1Qaz (Enhanced Transmission Selection, or ETS)
4) 802.1Qaz (yes, the same document; Data Center Bridging eXchange, or DCBX)
Take a gander at the chart below and you can see that all of the standards documents that address issues relating to running FCoE with Converged I/O are, in fact, complete. All of them have been published, are in the publication phase, or about to go into the publication phase.
What this means is that with respect to FCoE, customers now should look at how the technology fits into their overall strategy from the perspective of value.
But if all you’re waiting for is the standards to be “done,” your wait is over.