|
Contributors | Messages | Polls | Resources |
|
Level 3's Scola Discusses SD-WAN for NaaSSD-WAN offerings are reshaping the competitive landscape for both service providers and enterprises. Programmable SD-WANs are possible now and they don't have to wait for a complete virtualization of networks. Adapters enable integration, and network visibility and control. Customers need the cloud-like network-as-a-service (NaaS) now for intermittent traffic flows. Telco Transformation recently spoke to Claudio Scola, director of global product marketing for Core Network Services at Level 3 Communications Inc. (NYSE: LVLT), about the migration of SD-WAN to an on-demand NaaS. Scola is also an active and certified member of MEF, the defining body for Carrier Ethernet, where he regularly speaks at industry events promoting the adoption of Lifecycle Service Orchestration which brings dynamic flexibility and agility to network services. In 2016 he won an Active Contributor award from the MEF. Telco Transformation: Are specific uses of SDN controlled WAN transportation so compelling that they could help overcome the inertia experienced in implementing them? Are the risks of evolving still immature SDN standards low enough to start phasing out legacy WAN? Claudio Scola: The promise and progress in SDN-WAN were palpable when I was at the recent SDN World Congress in The Hague both in the standardization and technology vendor offerings. Programmability of the legacy infrastructure is possible with adapters and the compelling use case driving the move towards virtualization is network or WAN-as-a-service. We can have an abstracted view of our network, including WAN, adding control and orchestration and build the application layer. We have had programmability of an API-driven abstracted view of our Ethernet platform for over five years now thanks to our Level 3 Adaptive Network Control SDN platform. We now have over 81,000 network elements under Adaptive Network Control, the absence of API standards notwithstanding. The standards will help with vendor and Telco interoperability, which is critical for subsequent stages. Meanwhile, we can ensure that important tasks such as product definitions, workflows and critical systems for inventory are ready. SDN does not necessarily require the immediate retirement of dedicated MPLS and replacing them with virtualized commodity hardware. Digital transformation at customer sites can happen with real-time visibility and control of the service by controlling dedicated MPLS hardware, sometimes with the help of API to CLI adapters if your vendor supports it. For southbound data flows, standardized APIs are a means to gain interoperability of vendors' equipment and simplify the development cycles needed to bring the infrastructure under automated control. A great deal of the industry development, today, is on the east-west API interface that allows orchestration to span across partner networks such as the service provider and at the "last mile" access provider or cloud service provider -- critical for the future of orchestrated end-to-end services. TT: We've been hearing a lot about network-as-a-service lately. What's driving it? CS: The need for network-as-a-service has risen with the proliferation of clouds. Enterprises are increasingly using a combination of public and private clouds to form hybrid clouds that need intermittent network connections. Similarly, disaster recovery needs network connection sporadically or when an application migrates from one environment to another. We offer the dynamic cloud-like experience of our Carrier Ethernet services called Adaptive Network Control Solutions. Customers get a private connection, which is called Cloud Connect, to avoid the public Internet for such connections and the attendant security risks. The advantage of using dedicated network elements is that they are trusted and accredited with the MEF standards, but they do not have the benefit of hyper-scalability such as the evolving open source standards and commodity hardware platforms. By adding programmability of the dedicated hardware -- sometimes through API to CLI adaptors) -- we can create the dynamic services required to allow customers to build and connect hybrid clouds. Many of our customers require hybrid clouds for compliance reasons (such as PCI compliance) or to sweat physical assets. So we do see a common use case where the application, bifurcated into public and private infrastructure, seeks dynamic connectivity to improve agility and efficiency. The Open LSO and Open Connectivity Services initiatives are standardizing the APIs for the orchestration to happen. These initiatives are playing an especially important role in enabling partner networks to talk to each other for east-west flows of data. TT: In a hybrid environment of legacy equipment and emerging programmable networks, a mediation layer facilitates migration from legacy environments connecting applications with network resources and the control/management plane. Are the costs of a mediation layer worth the benefit realized from them? CS: Yes, when you orchestrate legacy equipment you need another controller to talk to that infrastructure. Your controller may need to have a software adaptor for CLI access -- all that costs the industry substantial amounts of money. We do not want to pay for that adaptor because we believe the hardware vendors should be supporting open APIs. We want the equipment to support a southbound API like Netconf/Yang. The key message here is that dedicated equipment can support APIs or have adaptors for APIs and can, therefore, operate in a programmable dynamic LSO environment. There is no need to sunset dedicated hardware. In fact, hybridization is often a very rational balance whether you are talking about hybrid Internet/MPLS WAN, hybrid private/public cloud or hybrid dedicated/virtual. In all cases, you blend hyper-scale agility with the trust, assurance, and quality of service of dedicated platforms. It is not necessary to virtualize every function over the next few years -- over the long term, they will be. As we move to new virtualized infrastructure, it will allow hyper-scale with a more elastic capex model and will hopefully allow us to roll out new services quicker. That infrastructure will better support the future digital economy when IoT and big data are heavily relied upon to run a business. However today, dedicated hardware platforms under the software orchestration are making a significant leap forward in the agility afforded for enterprise digital transformation.
— Kishore Jethanandani, Contributing Writer, Telco Transformation |
In part two of this Q&A, the carrier's group head of network virtualization, SDN and NFV calls on vendors to move faster and lead the cloudification charge.
It's time to focus on cloudification instead, Fran Heeran, the group head of Network Virtualization, SDN and NFV at Vodafone, says.
5G must coexist with LTE, 3G and a host of technologies that will ride on top of it, says Arnaud Vamparys, Orange Network Labs' senior vice president for radio networks.
The OpenStack Foundation's Ildiko Vancsa suggests that 5G readiness means never abandoning telco applications and infrastructures once they're 'cloudy enough.'
IDC's John Delaney talks about how telecom CIOs are addressing the relationship between 5G, automation and virtualization, while cautioning that they might be forgetting the basics.
On-the-Air Thursdays Digital Audio
ARCHIVED | December 7, 2017, 12pm EST
Orange has been one of the leading proponents of SDN and NFV. In this Telco Transformation radio show, Orange's John Isch provides some perspective on his company's NFV/SDN journey.
Special Huawei Video
Huawei Network Transformation Seminar The adoption of virtualization technology and cloud architectures by telecom network operators is now well underway but there is still a long way to go before the transition to an era of Network Functions Cloudification (NFC) is complete. |
|
|
||
Telco Transformation
About Us
Contact Us
Help
Register
Twitter
Facebook
RSS
Copyright © 2024 Light Reading, part of Informa Tech, a division of Informa PLC. All rights reserved. Privacy Policy | Cookie Policy | Terms of Use in partnership with
|