NFV group is creating specifications, and not standards. The specifictions will point to standards developed by various standards organizations. In addition, NFV will identify gaps that are not covered by any standards today, and will advocate addressing such gaps. The specifications process is going well, but it is under a tight time line. The risk here is to end up with incomplete specification or one that is not aligned between one domain and other domains (infrastrucutre, software, management). Extra focus is needed on joint domains activities can make this process more complete.
I'm pretty good with networking, but there exists a culture of spec-writing that speaks a unique and unrelated language, and this is a great example. I read this article and the linked whitepaper, and while it clearly uses English words in conventional grammar, it makes absolutely no sense.
What, exactly, is NFV supposed to do? It's really, really easy to understand networking because it all ties down to tangible behavior: ARP, MAC tables, routing, etc. This seems to be totally unmoored from what is normally meant by "networking" - it doesn't even seem to have anything to do with higher-level ideas like BGP or OpenFlow.
Perhaps this calls for a "why should anyone care about NFV" article, or "three ways NFV will change your life".
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by