Learn more about the OneAccess portfolio : an extensive range of physical or virtualized access platforms: multi-service routers, Ethernet access devices, white-box CPE and VNFs for the agile delivery of managed enterprise services
Learn more

WELCOME TO

EKINOPS BLOG

How SD-WAN is Forcing Service Providers to Re-invent Themselves (…as NFV did with vendors)

stone-henge-1566686_1920

Interesting similarities can be observed between SD-WAN and NFV. NFV aimed at ending the reign of monolithic solutions, with software and hardware decoupling, but also with the use of open APIs that facilitate the ability to pick, choose and replace vendors as necessary. The hope was that increased competition and commodity hardware would drive costs down. This is however not a particularly shiny prospect for vendors.

If you think about it, SD-WAN is also about breaking monoliths: service provider offers. From this perspective, the managed service offer is split into discrete components: connectivity, hardware, WAN/LAN devices, VPN/security and operations. Enterprise customers can theoretically source each item independently and benefit from choice and competition. As a result, a large community of SD-WAN advocates aggressively target service providers, accusing them of offering less and charging more; in other words ripping off enterprise customers. This is equally not a shiny prospect for service providers.

The right answer for CSPs is not necessarily to fully embrace the current offerings of the main SD-WAN players. It may be part of the answer, but not the full one. As with vendors for NFV, this turmoil is forcing service providers to reconsider the value and strategy for each individual component of their offer (connectivity, hardware, operations, etc.

Let’s start with connectivity and VPN. Many SD-WAN vendors build their business case on saving MPLS costs. If you are a CSP and can serve your customer with MPLS easily, this is just a bargaining game. Why SD-WAN then? Just call your service provider sales rep! Many commentators now admit that MPLS is not dead but SD-WAN has highlighted how un-ideal it is: if you need to build a global VPN with branches in Mexico, South-East Asia, etc., those MPLS links become awfully expensive and slow to deploy. This is where it makes sense for CSPs to adopt Over-The-Top VPN technologies as proposed by the mainstream SD-WAN solutions. In other words, service providers do not need full-blown SD-WAN technologies to remain competitive so long as the customer demand is limited to “same as before, but lower cost”.

Of course, there is more to SD-WAN than just building a network overlay: such as being able to easily enforce application policies, monitor network and application performance. In my opinion, this should be viewed as another layer of services that can be offered at a premium cost. Historically, service providers have been extremely successful in outsourcing networks for enterprise customers, especially in Europe. The key ingredients were: a one-stop shopping experience and being a price leader for this outsourcing. The contention here is that they can strike back against SD-WAN DIY and System Integrators. Being a price leader implies they need entry-level Over-The-Top offers, but also a rich set of options to upsell so that enterprises remain attracted to their main marketing asset: a one-stop shopping experience.

Why NETCONF beats OpenStack when managing uCPE

site-541197_1920

I know this question reads like comparing apples with oranges. In fact, I want to compare a uCPE managed with NETCONF versus a uCPE managed as an OpenStack compute node. First, it’s worth looking at why people think using OpenStack is a good idea.

OpenStack is THE open-source Virtualization Infrastructure Manager (VIM). As operators virtualize their data centers, OpenStack is pretty much the only solution if they want to move away from VMware. As operators move to OpenStack, they can extend it to manage Virtualized Network Functions (VNFs) in branches. The benefit looks obvious: one team in charge of both data center and branch virtualization and a streamlined software layer to deploy and manage.

In many ways, NETCONF vs OpenStack is a political decision. One that determines whether a combination of DevOps culture and IT teams will take power.

OpenStack: Free as in freedom, not as in price

OpenStack is not a piece of software, but rather a distribution of modules with heterogeneous documentation. More importantly, putting OpenStack into production requires the gathering of a critical mass of skilled experts. You need a good set of experienced architects who know what works, what does not and what will fail if you do things in a certain way. One well-known issue with OpenStack, for example, concerns planning upgrades. This is not a trivial job; VMware still makes a lot of money and Redhat or Mirantis put massive effort into packaging and supporting OpenStack.[1]

OpenStack was conceived for data centers

Using OpenStack for uCPE is about deploying VNFs where it makes sense, i.e. the trade-off between cost, latency and security. It implies VNFs would be seamlessly chained between a datacenter and branches. Extending OpenStack to the branch, however, poses challenges, the biggest of which is security. When VNFs are contained within a data center, the security perimeter is clearly defined. In contrast, deploying VNF in branches means the security boundaries are more open-ended as connections can be made to new customer branches. In this case, openness and security often contradict each other.

See full post

SD-WAN at the CSP: Why gray solutions are slowing success

blue-2137092

It’s striking the number of service providers that have recently started promoting SD-WAN offers, especially given that there is little evidence amongst them of its commercial success. Popularity and perceived demand are high in the telecoms world, but it seems few service providers have yet to really win over end-users.

Just another example of industry hype? Or is there more to SD-WAN than meets the eye?

There certainly is. Or rather, there will be soon. The increasing move towards a true white-box approach will undoubtedly be the driver in realizing SD-WAN deployments at the CSP and generating real value behind the hype. So, why have they lagged?

The SD-WAN romance

The appeal of SD-WAN is its software-based, flexible and fully programmable nature. The premise of a service delivered using Common-Off-The-Shelf (COTS) hardware offers the illusion of freedom. COTS hardware suggests that users are no longer locked into one solution, as new Virtual Network Functions (VNFs) can be added from a broad choice of third-party vendors.

As there is no ‘one-size-fits-all’ solution, the end-user can be critical and selective of the services it chooses, based on its own budget and requirements. In turn, this means they can benefit from competition, as vendors can battle to deliver more innovative, cost-effective services.

See full post

ROI for white-box CPEs: a question of segmentation

ROI

Operators commonly expect that moving to SDN and NFV will enable cost reductions, through efficiency gains in network management and device consolidation. As they get closer to deployment, however, commercial reality is telling a different story, depending on the market segment being addressed.

One area where the ROI for white-box CPEs is easy to justify is appliance consolidation. If you can consolidate a number of proprietary appliances into a single white-box CPE then the CAPEX savings are clear. Chaining, for instance, a vRouter, a WAN optimizer and a next-generation firewall into one single x86 appliance (i.e. a white-box CPE) delivers immediately identifiable cost savings: one appliance instead of three is basically the formula and this is a commonly targeted combination. Combine this with the prospect of increased wallet share from large enterprises, which often run their networks themselves in do-it-yourself mode, and the large enterprise segment looks increasingly attractive for operators.

Let’s be clear, though: this is just a large enterprise play. SMBs and multi-site deployments for government or highly distributed organizations have no need for WAN optimization and little need for a next-generation firewall; the on-board firewall that comes with their router together with a PC-based anti-virus subscription and email antispam service are usually sufficient. As a result, anyone working on building business cases for white-box CPEs for the volume part of the market will attest that ROI a tough nut to crack.

The draw for this market segment is the potential to increase ARPU by making it easier and more flexible to use additional services through automated service delivery via virtualization.

In terms of hardware CAPEX, the cost of white-box CPE deployment outstrips that of traditional CPEs. For the large enterprise segment which often deploys multiple appliances, this cost increase is compensated by reducing the number of appliances. For other market segments, where a single CPE is more typically deployed, savings need to come from OPEX reductions or TCO savings. The latter, however, is notoriously difficult to calculate and is usually irrelevant in a context where staff reductions are difficult to achieve, particularly in a period of technology transition.

See full post

The White-Box CPE: Separating Myths from Reality

the-white-box-cpe-separating-myths-from-reality

In the world of customer premises equipment (CPE), the white-box is a new idea. It should then come as no surprise that misconceptions among operators and CSPs about what constitutes the white-box CPE are common. Here are four of the most prevalent.

Myth #1: The white-box CPE is just commodity hardware.

No. The software-hosting platform is the most important part! Google and Apple have succeeded with smart phones because they created killer platforms, carefully designed to provide a secure environment ready for third party developers to exploit, which enabled their apps base to proliferate. The white-box CPE is no different. Don’t get me wrong, it is still all about using commodity hardware, but this is just the tip of the iceberg. It’s enabling potential stems from the software platform that controls the hardware, not from the hardware itself.

The same goes for the network functions running on the white-box CPE. They need to be installed, chained, activated, run, provisioned, monitored, charged and, of course, done so in a secure manner with maximum efficiency and predictability.We’re not talking about any old software here, either. This is highly specialist, instance-specific software but unlike smartphones the functions are often dependent on each other. There are lots of open-source components that can carry out each of these tasks individually, but they also need to be integrated, managed with homogeneous, standardized APIs and provided with pre-packaged, documented use cases to facilitate their integration. We often see service providers adopting a DIY approach. But this only lasts until they realize the extent of work and the depth of know-how required to assemble all these pieces together. Building a demonstrator is one thing; warrantying the operational lifecycle over the lifetime of a service is another.

Myth #2: White-box CPEs are for everyone.

The whole idea of white-box CPEs is to foster the ability to take VNFs from multiple vendors and have the freedom to mix-and-match them according to the service provider’s desired functions, price and brand.This is all good ‘on paper’. The reality, however, is different. Just like when specifying additional options on a car, the bill soon adds up. In fact, imagine being able to walk into a VW dealer and demand options from BMW, Mercedes, Honda and Ford. Welcome to the world of the white-box CPE!

Large enterprise can afford it because, right now, they are buying single-use network appliances and stacking them up in the customer’s premises. The white-box CPE’s promise of appliance consolidation is so great that the economics allow it to be expensive.

See full post

Do CLI Experts Need to Worry about Their Jobs?

do-cli-experts-need-to-worry-about-their-jobs

Our customers tell us that NETCONF is fast becoming the preferred way to provision virtualized networking devices. Tail-f has been the main advocate of this protocol, with a pitch that goes roughly as follows: “NETCONF provides the toolset to configure an end-to-end service with a single network-wide transaction. OSS programmers spend less time in handling error cases –as the role of transactions is precisely to ensure success and rollback in case of errors. You do not need to pay high-salary CLI experts to handle such rollbacks manually, when the OSS has failed to do it in a proper way. And you can now automate service creation at an unprecedented level.”

The more you automate the less people you need and with the transactional capabilities of NETCONF you do not need them to recover the disaster of accidental automation glitches. That has got to be rather scary for the cohorts of CCIE-certified engineers and other CLI experts, doesn’t it? Does it mean their expertise will become redundant? Do they need to find a new mission in life?

I recently met some CLI engineers. They see the change coming but as they are buried by the demands of their day-to-day activities, they have not yet had the time to study and experiment with NETCONF. So, this protocol along with YANG data modelling remains very abstract, if not confusing to them. Of course they understand quite clearly that NETCONF is about a programmatic approach to the process of service creation. Network engineers thus understand they must acquire new skills in programming but it is certainly not their comfort zone today.

In many cases, an OSS will not manipulate YANG models or NETCONF directly. The likely way to program network services is to use tools that generate an interface code from the relevant YANG models and programmers will use that API to create the services. For IT engineers, service creation is not much more than mapping a Service Abstract Layer (SAL) data model to objects on a set of networking functions or devices, nothing more.

But that is not the starting point for network engineers. Their initial steps are still the same (as before NETCONF): create a network design, prepare a reference setup, elaborate configuration templates, write troubleshooting guides, etc., with the notable difference being that such templates must be written in NETCONF XML. With OneAccess products, this is a fairly natural step: first create the reference configuration using the familiar Command-Line Interface, then use some commands to export it as XML or a set of xpath statements. Using this process, CLI can be mapped to NETCONF pretty intuitively. In other words, an extensive CLI knowledge is still a valuable asset for engineers. Working with NETCONF is then an easy next step and defining XML templates is after all not so difficult.

See full post

Latest News

  • EKINOPS Opens New US Office

    EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of optical transport equipment and router solutions for service providers and telecom operators, today announces the opening of new North America Headquarters in Rockville, Maryland, USA.

     
  • EKINOPS and Passman meet demands of “bandwidth hungry” hospitality customers

    EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading provider of open and fully interoperable Layer 1, 2 and 3 network solutions, and international hospitality digital service specialists, Passman, today announced the availability of true 1Gb services-enabling routers, which will further enhance quality of service (QoS) delivery for Wi-Fi guest access services.

     
  • EKINOPS Centralizes Metro Ethernet SLA Monitoring & Service Activation for CSPs with new 10G Access Device

    EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading global supplier of telecommunications solutions for operators, today unveils a OneAccess 10G Ethernet Access Device (EAD) that will enable operators and communication service providers to offer high-speed Ethernet services to Enterprise and wholesale customers.

     

EKINOPS Worldwide

EKINOPS EMEA & APAC
Telephone +33 (0)1 77 71 12 00

EKINOPS AMERICAS
Telephone +1 (571) 385-4103

 

E-MAIL ALERTS

Receive automatically EKINOPS information in your inbox!