Re: Yet another vendor riskThere are, of course, service providers who have designed, built and deployed their own networks... google is the example. But the business culture within google is certainly different than the business culture within a traditional telco SP.
google had more of a vested interest in designing/buidling their own networks - rapid service delivery - that traditional telco SPs are not good at. While TSPs promote an interest in very rapid service delivery their ultimate execution has been non-existent.
There are progressive teams within these traditional TSPs that are hell-bent on avoiding their own internal ops team 24-36 month NPI service deployment cycles... but these are fighting a battle with powerful and ascendant operations orgs in the same TSP who REQUIRE the longer introduction cycle to be able to identify, manage and predict operational cost and reduce cost risk due to unknown or ill-formed operations.
Re: SPIT IS IT!!Ray -- If you are referring to OSS standards (like TMN) then I would agree that the process is broken and it is hard to call those standards -- because they are hardly widely used. On the other hand if you intend to include Ethernet in the "standards" then I would disagree because the process works and works well. Ethernet is -- for example, the most broadly adopted telecom standard (along with other IEEE and IETF standards).
What's (at least in part) broken about the "OSS" standards is that they have been industry vertical (telco, etc.) and the concepts of "management" that come out of lower level standards (like Ethernet and IP -- aka IEEE and IETF) are relatively blind to the problems of service providers.
A great example is automation in Ethernet. Over the years various Ethernet ammendments have added automation and the IEEE and worked closely with service provider forms like MEF to better understand operators needs. Nonetheless the models do not essentially include basic functions like signaling security (authenticating devices before signaling requests are accepted), accounting (and I don't mean statistics, I mean accounting for billing purposes which distinguishes traffic by customer), and service activiation and testing.
As I said, organizations like MEF have accomplished alot to balance the input to standards to support service providers, but the world of OSS remains highly customized and lacks succesfull, broad, multiservice standards.
Re: Yet another vendor risk"At least one, maybe two, larger network operators are also warning vendors that if they don't deliver the NFV solutions quickly, the network operators will do themselves, in house."
SPIT IS IT!!General comment - in February 2010 Light Reading first published the Service provider IT (SPIT) manifesto and said this was the BIG change that needed to be addressed.
Guess what? We were right. SDN and NFV is, essentially, the offspring of a telco + IT union/convergence, whatever you want to call it. And the biggest threat to all established players in this industry is to ignore the input of experts from the IT world, to whom the concepts of SDN and NFV are much easier to grasp.
As far as I am concerned, it's official - SPIT Is IT!
It's OSS Jim but not as we know it....The thing that strikes me from having talked with various parties engaged in the development and testing of SDN-related and NFV-related tech is that the current/legacy concept of an OSS will not be so relevant and that the current concept of 'standards' -- most particularly the current telecom standards processes -- will not be 'fit for purpose'.
That's the change that I don't see being taken on board by the current providers of OSS systems. And that's the part of the process that will, most likely, end up going inhouse or be outsourced to a managed services provider.
What does success mean ? Calling an old dog a new name ?Operators have been talking about complete automation of their OSS for years. Certainly, having a different interface (I would hardly call most of them APIs) into each system or box (router, switch, DNS, accounting, etc.) makes that difficult -- and having a uniform set of APIs (standardized) would be useful. Such an approach -- is not what Software Defined Networks is aimed at. It might be what's left when the other pie in the sky visions fall aside (as some of them have begun to do) and further when there is a realization that you cannot gather data from a box in a network, deliver it to a controller, make a decision, and expect that to get back in anything even close to or remotely related to forwarding, real time, etc. Sure, you can create a policy that says X and automate distribution of that policy -- but (a) that has already been done before and (b) that is not what SDN is 'supposed to be.'
As for NFV -- it's just a fancy name for what we've called L4-7 and has been around for decades - literally. "NFV" will be successful because all of the vendors will take their existing products and rebrand them "NFV!" Brilliant. That accomplishes alot. It's like rebranding hosting "cloud." Gee -- it was on a remote server hosted by an SP before and now it is is on the same server doing the same thing and it is "cloud." Ohhh -- ahhh.
The REAL developments that are going on are standardized API's not only for cloud services, but also for network appliances to that the services can talk to those appliances. A simple example of this is the setup of "cloud" services that requires -- for example, server load balancing (SLB) or so called global server load balancing (GSLB) which just means location based rather than simply load based. In order to do this as VM's are spun up, we need a simple API to allow the cloud services controllers to signal to the SLBs to create new instances. This used to be done either by hand, but more likely by script. The real problem being that the scripts were custom for each SLB box (Brocade, A10, et. al.). If a simple standardized API -- were made availble (example NETconf was supposed to do this and still could in theory), the problem would be solved. If anyone wants to call that NFV -- that's fine, but 100% of the technology to do that and the idea existed before the term NFV -- which appears to me to be marketing tactic more than a technology.
All that said, the real job these organizations can do is to take the leverage and interest and develop and publish standard APIs for specific network functions. While this exists for services like DNS, web (HTTP), it does not for services in lower layers (session and transport) such as handled by SLB. This is only one example, clearly other APIs would be useful for security, etc. Still the problem remains, when a new technology arises, a new API will have to be developed -- leading to a delay in the market while the API is published ... But at least it will be better than the legacy API -- MIBs.
I wasn't talking about the network operators building routers and switches, but I am refering to software and other things related to making NFV work and automating the processes.
You raise some good points about the danger of centralizing control, but the reality for today's network operators is that they must find ways of developing services faster and make their network resources more flexible.
Moving to virtualized functions, and separately the data and control planes of their networks do represent one way to meet these challneges. I don't think any approach is unassailable but I don't think you can just dismiss NFV/SDN as the future of networks.
Re: Yet another vendor riskIn response to Carol - I highly doubt that "network operators" will build network gear (routers and switches) themselves. It requires engineering skills that differ very much from the skills required to design, build, and run networks. The only "network operator" I know of that would consider this has a show and tell network operation, but is not a "telecommunications service provider". It is the same operator that used to run around with VGA monitors to manage its co-lo gear because they didn't want to spend the $ on KVMs. (Note -- I'm sure spending money on labor is far more cost effective than a KVM -- sarcastically of course).
As for the article -- glad to see some acknowledgement of the GAPING holes in not only technology (the ideas), but the products, and the theory of opertions. I'd go further and dispute your claim that the logic is unassailable. In fact I'd argue it's guit the opposite. It's extremely easy to attack and poke holes at the logic of NFV and SDN. In an environment where is EXTREMELY EVIDENT that centralized control can be and IS ABUSED (aka by governments, corporations, competitor corporations, users, and hackers) -- centralized control is the LAST thing you would want.
I'm all for centralized policy and automating the distribution of those policies, but that should be held in check with distributed routing, switching, and a subscription based model that allows distributed devices to subscribe to (or not) various 'centralized' policies. But centralized forwarding control cannot in theory even respond fast enough to changes in the network to meet the needs of fast re-routing and dynamic changes to state for applications like security.
It seems to me that a serious lack of understanding of the history of technology, mistakes made, and of control systems are conspiring for another terrible mistake (if anyone even recalls what that is).
Re: Yet another vendor riskIf they do it in-house, carriers also can probably stall these projects if needed without much blood loss. If they hire vendors and later slam on the brakes, there will be blood.
(Sorry, had to take the opportunity to throw in a movie reference where I could.)
Yet another vendor riskAt least one, maybe two, larger network operators are also warning vendors that if they don't deliver the NFV solutions quickly, the network operators will do themselves, in house.
That's not an option for eveyr network operator, certainly, but the biggest players could do it, and they are certain showing impatience.
google had more of a vested interest in designing/buidling their own networks - rapid service delivery - that traditional telco SPs are not good at. While TSPs promote an interest in very rapid service delivery their ultimate execution has been non-existent.
There are progressive teams within these traditional TSPs that are hell-bent on avoiding their own internal ops team 24-36 month NPI service deployment cycles... but these are fighting a battle with powerful and ascendant operations orgs in the same TSP who REQUIRE the longer introduction cycle to be able to identify, manage and predict operational cost and reduce cost risk due to unknown or ill-formed operations.