Thanks to all who joined us for the InfoVista ABCof APIs Webinar: SDN+NFV-Driven Evolution of Performance Assurance Architectures, where the award-winning multi-vendor discussed API, and proof of concept for multi-operator networking-as-a-service featuring LSO concepts within the context of SDN and NFV. After the webinar, we took questions from the audience but unfortunately ran out of time before we could answer everybody’s questions. You can read the full Q&A below.
Which SDO or open source project is most critical to this evolution you’ve described?
What is most critical is for the industry to work together, rapidly and effectively, to agree on the language – that is, the information models – used to navigate the intent-to-actualization lifecycle. That agreement is essentially equivalent to a standard or set of standards, which simplify and truly enable interoperability among suppliers, and more importantly, CSPs. This is beyond just service assurance.
The second nuance of this answer is the debate between open source-based solutions and SDO-based solutions. SDOs aim to achieve agreement, while Open Source initiatives aim to build solutions with code. Both are necessary to assure what’s agreed to works, and therefore one approach cannot enable network nirvana better than the other.
I do recognize the MEF as leading the charge of creating a framework for establishing this lifecycle, which they term Lifecycle Service Orchestration (LSO). This framework has two key traits; first is that it uses a framework that sits at the subscriber level of a service, thus, embodying intent to actualization, and addresses the key element of multi-operator services. Additionally, MEF focuses on the heritage of assets in an operator’s network as opposed to solely NFV or SDN technologies. They’ve also been very active in uniting the various SDOs and open source projects towards this common goal. It won’t eliminate duplication of effort but it certainly helps minimize it, and helps the industry have a good chance at making network nirvana a reality – not just within a single operator but for everyone.
What’s the difference between LSO and OSS?
LSO covers the business applications as well as the software orchestration functionality (fulfilment, assurance, etc.). Thus, LSO is an evolved OSS/BSS framework. However, you will always see both in architectural diagrams as the OSS ‘box’ represents the existing operational support functions and systems. Over time as a service provider adopts LSO, you may presume the existing OSS will eventually be redundant (likely over many years) and then decommissioned.
I see the term analytics used a lot lately, how do you define it and how is it related to assurance?
Analytics, referring to data analytics, is a process of taking a large set of data, often disparate data, and providing post-analysis on that data to provide new information, and infer conclusions that can best aid decision making. These days, its implication is real-time analytics, which means the post-data-set analysis happens in real time so that the conclusions made by the analysis are provided almost immediately, and is performed on-going as opposed to one-off batches. Analytics is a wide topic; in service assurance, it most often addresses closed-loop automation such as the virtual PE use case presented in the Proof of Concept and covered in the webinar.
Do you see performance assurance as a functional stack, that is operators should have a single assurance stack be it their own, or a supplier’s like yourselves?
No. And the reason is simple: Since packet-based networking was introduced, performance became unpredictable and thus most if not all providers have made investments in a performance assurance function stack of some sort over the last 30 years. No CFO wishes to approve investments that merely duplicate functionality. Therefore, it’s more and more critical to disaggregate the elements to deliver the most optimized value in each environment. Flexibility is critical, including being able to adapt to existing systems as best as possible while delivering the new elements of performance assurance. Open systems, with APIs and agreement on information models, should work to make this approach more and more simple, cost effective and rapid.
What’s critical is to have holistic assurance across the service lifecycle addressing multiple-operators and all the existing network elements, along with the newly implemented SDN- and NFV-based technologies.
I thought MEF was focused on Carrier Ethernet but I didn’t see a lot of that in the earlier section, is the third network based on Carrier Ethernet?
The MEF has been very successful over the last decade-plus creating a Carrier Ethernet service specification, again from the perspective of the subscriber, and standardizing the language and attributes used for that service to accelerate that adoption of CE service worldwide. Now, however, they have taken that expertise of service standard specifications and adoption along with the industry need for ubiquitous, assured services to take on LSO and generate the common information models, APIs, and certifications that can accelerate the evolution to network nirvana – in essence what MEF terms “Third Network Services”.
How much telemetry-style support is there in today’s network equipment? Do we still need SNMP?
There are several suppliers that are introducing telemetry-based methods into their equipment. The addition of NetConf, SNMPs successor, is rather prevalent as well. However, when you go down to the level of specific hardware models, virtualized network functions and controllers, they likely still require a pull-based data acquisition model that uses polling of some sort, including SNMP. Also, since there is a vast amount of legacy network assets within the operator that are part of existing services but may also be involved in newer services as well, any performance assurance solution needs to handle both the older methods and the new, and normalize them accordingly.
What are the challenges and barriers with OSS/BSS integration with SDN and NFV?
The full answer would likely require something closer to a novella, however some interesting challenges are: the flexibility of existing systems to communicate across technology domains, the ability to rapidly update each components view of a network service given that SDN and NFV begin to not only automate service delivery, but to enable real-time, dynamic changes to those service and components, which places pressure on processing scale; the ability to understand the new components and to provide information (i.e. feedback) in a timely manner to the new functions like a VIM or SDN controller to make effective decisions in their real-time jobs of controlling and provisioning the underlying network functions. Furthermore, there are many OSS and BSS processes that mandate manual intervention. The ability to remove that intervention can pose challenges, though it is not by definition impossible in all cases.
Back to the CFO; consider a micro-services approach where you address the individual use cases necessary to support a particular SDN-enabled function, look to address that use case rapidly with new software (commercial and open source) and iterate, while linking to the heritage OSS/BSS as necessary to achieve the desired automation. Over time, elements of the OSS/BSS should evolve such that the challenges fade. Big Bang approaches are possible too but are often far more time consuming, costly, difficult to adapt along the way, and are hard pressed to ever achieve the CFO’s approval.