x
VPMarket13134 8/18/2017 | 3:48:52 AM
Cato Networks does "NFV" for the cloud If you sum up the 2 main factors Nolle (and other commentators below) cite for the architectural challenges of NFV they are: sticking to appliance form factors vs built for the cloud service software and waiting for incumbents to build VNFs that conform to the new services architecture and eliminate their telco lock in the process. We decided to achieve all the goals of NFV but without falling into all these traps. We built a converged network and security platform from scratch in software as a multi-tenant cloud service. No appliances, no 3rd party components that need separate management or scaling. It is basically a new carrier operating system and we using it to compete with incumbents. Take a look at https://www.sdxcentral.com/articles/contributed/the-carrier-cloud-needs-new-fabric-not-patched-cloth/2017/04/
Carol Wilson 8/17/2017 | 1:41:10 PM
Re: NFV is Deployed, Stop the Negativity clarkede, 

I understand your frustration but here's mine: I write a lot of articles about NFV deployment, so in the broad scheme of things, there is balance on the Light Reading site. I've probably written more positive articles in the last year than negative. And invariably, someone complains that we're sugar-coating things. 

We are, at the moment, in a period where some are reflecting on how far NFV and virutalization has come, compared to where it could be, and I don't think that's a bad thing overall. it has the potential to inform deployments going forward.

 

Carol
clarkede 8/17/2017 | 1:38:06 PM
NFV is Deployed, Stop the Negativity It is getting very tiresome to see such repetitive and unjustified negative commentary about NFV. Leading operators are deploying, for example BT: https://www.globalservices.bt.com/uk/en/news/bt-accelerates-cloud-with-hosted-riverbed-service. Lets have some balance please.
Kevin Mitchell 8/14/2017 | 9:21:58 AM
Choose Your Own Virtualization Adventure

NFV hasn't been the transformational technology the industry sought.

Where NFV is applied to VoIP, I've been saying this for years on my blog and this LR message board (see Danger of Decomposition as an example). NFV is overly complex, too costly to build, and won't deliver on the promise of feature/market agility. Plus traditional vendors aren't motivated to bring about the desired business outcomes and service providers need a next-gen solution today, not 2025.

For each service or application, service providers should define the desired business outcomes of any network change and examine all the technology paths.

At Alianza, we've argued that for most service providers the best approach for VoIP/UC is to use a turnkey, integrated virtualized software solution delivered via the cloud (vs building your own NFV-based IMS cloud).  

A Heavy Reading study (link to it below) supports a growing inclination to cloud source vs build: 83% of CSP respondents said that it was somewhat or very likely that they'd use a XaaS option for replacing or augmenting network infrastructure.

Read more in my blog posts:


And white papers:
TomNolle 8/14/2017 | 8:57:59 AM
Re: CloudNFV I agree, but the problem that CloudNFV demonstrated is that the network opertors want to have big firms with deep pockets to back them in any new technology initiative.  Network equipment vendors were understandably slow in backing a venture that was designed at the first to reduce capex, which of course meant their own revenues.  The server players were the ones that operators in 2013 were looking to, at least for backing.  They believed for a time that Dell would indeed step up and become the de facto champion of the CloudNFV effort, rather than just being a supplier of servers.  Since they didn't do that, it left the project with no big-company champion.

FYI, there was another company involved in CloudNFV but who declined to make their participation public.  They were another big player, but I think they believed that the risk of alienating some of their customers would be excessive.
Gabriel Brown 8/14/2017 | 4:44:15 AM
Re: CloudNFV "Could the current projects be retroed to take a cloud view?"

Redesiging what exists and then attempting to displace the incumbent network is expensive, and given the revenue and margin opportunity in telco networking, possibly not the most astute business decision. This is a problem for NFV. A lot of work, for not an enormous amount of gain, even if it goes well.

The better investment is in newer systems, new architectures, and new deployments.
Gabriel Brown 8/14/2017 | 4:34:38 AM
Re: CloudNFV Dell wasn't and isn't a telco networking company so didn't / doesn't have chance of driving an NFV vision to reality. It's best bet is to excel in its role as a hardware/server vendor. For the same reason, for the majority of networking vendors, there's no sense in attempting to become server vendors.
TomNolle 8/12/2017 | 10:41:46 AM
Re: CloudNFV Originally, when I was Chief Architect of CloudNFV, it WAS an open project and it at least allowed open-source implementation, though the initial vendor software was not open-source.  Dell provided the test cloud and hosting, but they didn't contribute software functionality to the project at that point.  I don't know what happened beyond early 2014 when my involvement ended.  The open framework did not develop as I had expected/hoped it would.

My concern with the current open projects you cite is less the time/momentum issue than that they followed the ETSI functional model fairly literally rather than taking the cloud-centric view CloudNFV took.  I truly, firmly, believe that a literal functional-model implementation will not scale or perform as operators want.  Could the current projects be retroed to take a cloud view?  Probably, but it would be difficult to turn something around like that at this point.  I think if anyone gets this right, they'll likely start from scratch and follow the cloud-and-intent-model approach CloudNFV took.
James_B_Crawshaw 8/12/2017 | 3:32:32 AM
CloudNFV I understand CloudNFV had a lot of carrier interest and the components and interfaces were generally considered to be good. For some reason Dell, the main vendor behind the PoC, decided not to follow through. Seems like a missed opportunity because they are still active in this space. However, CloudNFV would have been a small ecosystem dominated by one vendor. The open source alternatives that we have today (ONAP and OSM) are arguably more likely to succeed in the long term though they take longer to build momentum. 
Gabriel Brown 8/11/2017 | 10:39:52 AM
NFV Progress Tom's point is well made that if you create a functional diagram, people will build to that. The same risk is there now in 5G standardization (more on that another time).

And we've known for a while that operators are benefiting from lower cost equipment due to the implicit threat of virtualization. You could argue that NFV has achieved one of its goals without without actually being deployed at scale.

And yes, NFV could have made better technical progress, etc. At the same time, you can see progress in many operators. It's not as gloomy as the piece indicates, in my view.

One (the?) fundamental issue is investment cycles. I've argued for years that the big opportunity will not come until big operators are making major refreshes that are architecturally signifcant, or are investing next-gen deployments. If you already have an IMS, or an EPC, or whatever, the motivation to rip and replace is low. You may use a virtual solution for add-on use-cases, but in effect, your cake is baked already.

SDN WAN seems like good example of where there's enough new stuff, and enough operational change, that new solutions are worth pursuing. I don't actually cover SD-WAN, so feel free to correct me on that.

In mobile, 5G is the next obvious upgrade cycle. This is the time operators need to be strategic and make the move to cloud (where it makes sense, etc. etc.). It will be tempting not too, especially with the agressive timescales and technical challenges in a 5G launch. But this is a once-a-decade opportunity
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE