AT&T’s ECOMP platform is in production but needs more maturation. Without that progression, the carrier won’t be able to make its goal of virtualizing 75 percent of its network functions by 2020.
That’s why AT&T committed ECOMP to open source. It can’t get to 75 percent all by itself.
The carrier formally handed the ECOMP project to the Linux Foundation yesterday. It was one of several announcements at a small press event held in San Francisco, at AT&T’s flagship retail store — a place where consumers can browse exhibits about possible futures enabled by connectivity and the Internet of Things (IoT).
ECOMP doesn’t have that same tourist appeal, but it’s vital to AT&T’s plans. The carrier developed ECOMP because it needed management and orchestration to go with its virtualization plans. Unable to find a suitable commercial option, AT&T chose to build one of its own.
That was a start. But AT&T, as a solo act, has taken the project as far as it can. And that goal of 75 percent virtualization is looming, said Mazin Gilbert, AT&T’s vice president of advanced technologies, platforms, and architecture.
“It’s easy to get to 5 percent. Thirty-four percent was a stretch. Now you see the target for this year [55 percent], and to get to the 75 percent in 2020 — it’s extremely difficult,” he told SDxCentral yesterday.
“Without having the brainpower, the developer ecosystem, across these providers and service integrators, we are all working together, we can’t get there,” said Gilbert.
AT&T’s hope is that an open source ECOMP can tap the minds of vendors, integrators, and other providers. It’s already happening. Amdocs helped steer the direction of three of the 11 modules that make up ECOMP. All three were classic cases of open source code going in a direction that the originators didn’t think of, Gilbert said.
(Side note: AT&T calls ECOMP a platform for network automation. It’s commonly referred to as an orchestrator, but that’s only one of the 11 modules. “I hate it when people say it’s an orchestrator,” Gilbert said with a smile.)
Of ECOMP’s roughly 8.5 million lines of code, only about 5.5 million are being made available as open source, Gilbert said. The rest is specific to AT&T’s network — connections to the carrier’s particular OSS, for instance, or a proprietary component that handles data collection and analytics.
In addition to ECOMP itself, AT&T is open sourcing tools to go with the platform. At yesterday’s event, for instance, one demo station showed a self-service validation portal where vendors can check how well their virtual network functions (VNFs) work with ECOMP. The fundamentals of that platform will be available in open source form through the Linux Foundation.
The code isn’t available just yet. What happened yesterday was the official handoff of the code and the project responsibility to the Linux Foundation. The foundation is putting some finishing touches on the code before releasing it, AT&T officials said.
AT&T can’t wait for that to happen.
“I can tell you what I tell my team. We cannot mature ECOMP fast enough. The needs of our consumer business outweigh any resources we might put down,” Gilbert said. “There’s a lot we’re finding that we just don’t know how to do.”
8.5M lines of code?!? Latest Linux kernel with all std drivers, interfaces and arch packages is only 16M lines. This thing is a monster.
Yes that big, but we can discount 3M lines of code which is AT&T specific.
ECOMP is a literal software monster.
ECOMP is also over kill.
Here is what carriers are not addressing in their lust to reduce OpEx: Highly Reliable Services and Service Assurance.
Why?
Well, because of two missing components:
(1) Automated “Services Certification”
(2) Automated Fault Isolation
Services Certification:
ECOMP provides service design and creation tools, but it currently does not model the operating environment of the service. Therefore, services will go out the door with sub-par qualification. This means defects will arise in the field as the services run and SLA payouts and churn will increase. It is no longer enough simply to certify a pNF..all elements that comprise a service must be included in certification cycles, including vNFs, pNFs, vProbes, cloud software, NOS on whiteboxes, the service parameters, the compute and storage node OSs, software storage, such ad CEPH, and any and all other software that comprises the service. This is a much bigger challenge than pNF-based services. By default the certification intervals will be longer, defeated the pupose of elastic services orchestration.
Automated Fault Isolation:
ECOKP/ONAP is BIG AND COMPLEX, not just in terms of lines of code, but also in the messaging and transaction processing, such as directed graphs, that take place. For example, just to instantiate a Layer3 service, the designer must first create the service using service design and creation tools, then the services orchestrator conducts a detailed process including multiple flows using possibly several different engines, including perhaps BPEL, Neutron HEAT templates, and other protocols and interfaces. Once orchestrated, service events may occur which require closed loop event processing, which can trigger additional orchestration and stitching via an SDN controller. This means that field defects related to orchestration and stitching, closed loop processing, and other management functions will forever and always be immediately escalated to development (Tier4). For example, packets may be dropping within a hypervisor, or they may be dropping in a softswitch, or there may be a “dangling” configuration left over by the services orchestrator. Tier2 operations will not have the development experience to adequately troubleshoot, and hence developers will be endlessly paged. This is distinct from a legacy network model, where isolating a data plane problem is normally a “binary search” (e.g., problem exists between Node X and Node Y), and a management or control plane problem can be investigated by first looking at the primary controller card.
If the Services Certification problem and Service Assurance problem are not solved in NFV, then the OpEx gain from using systems like ECOMP/ONAP will be negated by lengthy service delivery intervals, SLA payouts to enterprises, and significant customer churn. Carriers may feel good about their OpEx reduction through automation, but in the end the customer really doesn’t care if the network service is NFV-based…they want the same reliability and resiliency that they have grown accustomed to. You just can’t “spin up” a new instance of a VNF, some of which takes 10s of minutes to fully instantiate to a working level.