& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 5   >   >>
brooks7
brooks7
4/28/2017 | 12:17:34 PM
Re: Its Not Virtualization -- but the Foundation
@Duh!,

Good one. 

seven
Duh!
Duh!
4/27/2017 | 6:57:21 PM
Re: Its Not Virtualization -- but the Foundation
"Lets go back to 1993, and reimagine how IP routing could and should work."

We did.  It was called ATM. The Betamax of networking technologies.
Kevin Mitchell
Kevin Mitchell
4/26/2017 | 9:21:54 PM
Focus on Business Outcomes in Choosing Your Virtualization Path
If the goal is more revenue and lower cost by implementing "the best and most popular (and most profitable) mix of services by picking and choosing from an online marketplace chock full of 'best in class' services and applications", then buying NFVI this and integrating VNF that isn't necessarily the way to do it. 

We've been saying for years that operators need to look at business outcomes and evaluate the various paths to virtualization. Cloud building or cloud sourcing are the choices; look at the application in question and which path best maximizes the chance at realizing those outcomes. In many cases it will make sense to build a new virtualized network to support multiple applications.

Given the state and future direction of voice and UC we believe that, for the vast majority of operators, that cloud sourcing is the best way forward (yes, the global top 100 will build an NFV IMS network and complete that in 2023 or thereabouts). Why cloud source virtualized VoIP? It's lower cost (and no CAPEX) with a success-based business model, operationally simple, and it's tremendously most agile than software on premises. Oh, and CSPs get to spend dollars and people focus on other initiatives while still owning and delivering a modern communications services for its customers.

Yes, this CSP VoIP cloud sourcing is what we do (and first to do it). But the traditional VoIP players are getting into this game too (BroadSoft BroadCloud is the fastest growing part of its business, GENBAND is a KANDY junkie and Metaswitch has joined the club).

A Heavy Reading study confirmed this too: 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. And, along with building VoIP, cloud voice platforms was a top voice network evolution path. Read more here -> Heavy Reading: Cloud Defines a New Voice Strategy.

 

 
gregw33
gregw33
4/26/2017 | 12:36:26 PM
Gaming Open Source and SDO's
Standards Development Organizations (De Jure and De Facto) are extremely easy to "game" ...

I hope readers don't think Open Source Software initiatives cannot be "gamed" as well...

They are...

GW

 
scanlanavia
scanlanavia
4/26/2017 | 9:42:41 AM
Frustrated Analyst .. there
No doubt the author fell out the wrong side of the bed when this was written.

However I tend to agree with most of what was said. Four years down the road and nothing much achieved except plethoras of white papers and marketing hype.

Can you tell me what on earth is the issue with poor old HPE .. They are not alone in stonewalling the exercises.

DevOps, DevOps. Devops..... this is the mantra  .. being showered at CSPs.

I agree entirely CSPs will NEVER successully put Devops in place... it's like the promise of the Agile Manifesto which likewise never worked for large organisations.. It's fine if you're making a small consumer app... But you cannot scale DevOPS likewise and hope that the daily update is going to smoothly avoid the occasional HLR meltdown for instance once in a while..  ( a catastrophe in otherwords )

CSPs cannot afford happy clappy failures..

I actually thing ETSI/NFV got off to a good start with their NFV showcases , usecases and proof of concepts...... but seemed to run out of inertia to finish the job off..

The Open Source is a like a  hamper of shiny chocolote wrappers each offering their own distinct piece of the jig saw. However the ecosystem is now so complex that even the PHD's can't quite figure out where to start anymore..

Well done for waking up the industry a bit... but I think it will take more than this to steer the industry from going over the cliff...
rommelb
rommelb
4/25/2017 | 2:42:24 PM
Interesting article, but....
Disclaimer: This is my view.  I am constantly learning, and would love to understand other thoughts.

Interesting article, and I do have to agree there is a culture mismatch  But there are things that can be done today.  Just like ATT in its early inception, google had a journey as well.  ATT built analog switches to move away from cord boards, because there was nothing there to help them grow and optimize.  Just as the OTT players had to use software to build more efficiently optimized networks and services because there was nothing there to shore up their growth.

Building blocks for changing how to optimize business and operational process are there, just as interface standards are there for interop.  Can it be better? yes, but there are areas to start.  Boiling the ocean of orchestration across a full customer facing service stack is difficult if the small successes of automating anything done twice, hasnt been built as foundation on the infrastructure. Automated outage recovery is difficult without understanding how the network is modeled and an understanding of types of outages and blast radius of those types.  Abstracting and automation of resource facing services on the network both PNF and VNF has to be done in order to orchestrate the NF relationships.  This all has to be done before one can even activate services on that infrastructure for customer consumption

My bottom line recommendation; Understand the processes, risks and impacts, automate everything, abstract the information so that automation is reusable,  orchestrate lifecycle where it makes sense, understand your data and optimize with that data using the automated tools built.  A meal like that is best taken in bite sized chunks.  

Start with training courses on software like Ansible, maybe get programs in place like automation of the month or quarter for the network engineers that create something with some gains.  The simple win of creating a culture of automation and optimization can lead to operations efficiencies that can pay back.
reimagine_networking
reimagine_networking
4/25/2017 | 9:49:42 AM
Its Not Virtualization -- but the Foundation
You are correct that we need standards for VNF's to inter-operate, but the problems are in the routing plane. We are relying on tunnels, ethernet and broadcast domains for security (L2) instead of L3. We need to rethink how IP networking works. The correct foundation for IP services is not L2, but rather L3. VLANs are not routable, are not accessible at the application layer, and do not scale. VxLANs are advisory, and utilize waseful encapuslation. I agree there should be a call for standards. Lets go back to 1993, and reimagine how IP routing could and should work. Lets end layer violations by always resorting to ethernet solutions.
mhhf1ve
mhhf1ve
4/24/2017 | 7:14:23 PM
Re: Diagnosis
> "The model used in Telcos is that nobody can be fired for screwing up except at the bottom.  Committtees make decisions.  Those committees do detailed studies.  They debate fine points.  Nobody can be blamed for a bad decision.  The accountability is too diluted."

That's the stick.. Where's the carrot? If smaller telcos had the incentives to actually try to do new things (ie. there was an upside in sight), there might be organizations that could avoid committee-decisions and just go. But when municipal telcos can't even get off the ground, and smaller telcos are struggling to cobble together contiguous networks... perhaps there's a larger problem at hand?
Voluntee24126
Voluntee24126
4/21/2017 | 5:15:35 PM
Re: Diagnosis
The issue the Telcos have is that if Facebook or Google have an outage, it might hit the internet news if it is big enough.  A major outage by a Telco hits all of the news outlets and if it is a multi-region one, their CEO and/or CTO end up testifying before Congress.  The stakes are much higher for the Telcos than Facebook and Google.  Fault recognition and switch to protect time in the core telecom network is 51ms.  As you have noted, there are few specifications in the Facebook/Google world.  The ones that I have seen reported are 5 or more minutes for fault recognition.  I have run across no time limit specs for protection switching for the social media or even cloud vendors. 

The key here is competing with the OTT application vendors while maintainng the basic reliability of the core network.  Not an easy task.

 
creynolds32701
creynolds32701
4/21/2017 | 9:22:05 AM
Re: Diagnosis
Hi Carol - Please reach out to me. I want your advice on some new products we are introducing to help in this area. 

thanks

 

www.cloudasafile.com

 
Page 1 / 5   >   >>


Featured Video
Upcoming Live Events
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events