Architecting Scalable and Production ready Orchestration frameworks for a Digital Business
Part-I
<Telco , Applications and Enterprise domain>
“To achieve great things, two things are needed: a plan and not quite enough time.”
Leonard Bernstein
Subsequent to my talk followed by nice demo of ETSI OSM by Telefonica’s Francisco Javier Ramón Telefonica at the U.S Network transformation congress organized by Layer 1,2,3 Network Transformation Congress one question always nodded me
“when exactly Industry promises around software control and Orchestration will be Production ready with clear use cases and a distinct framework “
Almost after a six month gap I am here at the ONS Open Networking Summit Europe and still I am thinking the same one.
All of us will agree what appear simple on paper in Practice a daunting task. This never dilutes the importance of front runners and practice after all with out delving on this journey also we can not solve the issues .
Therefore, as an active community member in the ETSI NFV NOC , OSM and Linux foundation EUAG I think is important to explain my own point of view where we stand and to apply a focused approach to solve it .
Therefore, the purpose of this paper is to summarize key challenging faced by Telco and IT industry on this domain and thereby defining an architecture based on best of the breed SDO and community frameworks that will ultimately drive a carrier RFP and vendor roadmaps to define the missing Lego of the Future Network.
The part1 of this paper is to enlist the Situation today that really makes it difficult to Automate and orchestrate the networks using a standard modeling framework. If you are reading it make sure you also read Part-2 the Ultimate story to be published in Nov 2019 .
Orchestration market as we know today is full of fragmentation and we are still finding the optimum way to address it . However, our years of working in this domain has made clear that for Orchestration to be successful it must solve both the abstraction view (hide service from underlying network) and automation view (a way to model network as a software program) . Obviously the two are related as automation is deeply stitched on Abstraction and modeling . Low abstraction means difficult to model and difficult to automate
I think our approach of selecting right Orchestration vendor has not been fair where we either tilted towards network vendors or to the BSS/OSS vendors with out setting right criteria hoping vendors will set it correctly. This is why as I recommend to CSP’s to select an automation and orchestration product must consider following five characteristics as a baseline .
- NFVO must be modular in nature and not a full product
- Simple to design (day 0 , Web based , Drag and Drop )
- Should support truly open source with strong community support (e.g instead of ETSI MANO promote ONAP/OSM)
- Intelligent automation (Predictive analysis, Day1 /Day2 automation)
- Operational efficiency (Only domain truly exist now VNF Day1 , FCAPS , RCA , Monitoring)
Further these characteristics are fully endorsed by how industry views it with TMForum projects like NaaS , MEF LSO and ETSI SO frameworks. However, having said this still we find the full abstraction from business layer to underlying layer is not achieved till date by E2E SO or upper BSS layers making the full cycle still a manual and vendor defined way . The situation as existing in TMForum NaaS program and suggestion can be depicted below
NFVO Challenges
Having speak about these two points it is also important how we have deployed our projects anyways. Based on projects experience we believe major setback to Orchestration is coming from bottom up approach where all efforts have been primarily VNF driven with less focus on software control , e.g CSP finds NFVO from vendor X will only deliver value if VIM ,VNF from Vendor Y is selected , issues of standards specially unified meta modeling for VNF are not followed well by all vendors .
So to devise solution first list down issues we need solve .
- Network service is different from VNF /Interfaces and Template standardization [Get Rid of vendor defined VNFDs]
- How to separate NFVI FCAPS solutions from NFVO ?
- Is it possible to use NFVO components / From different vendors to make one NFVO
- How NFVO controls MEC and other / D-Cloud architectures
- One NFVO fits to support MV VIM , MV VNF scnerio , Telco , Enterprise etc and may be PNF/VNF scnerio?
- Service Orchestration like offer VoLTE / Service from portal one click?
A part from above there are some challenges coming from industry itself which can be summed as follows
- ONAP vs OSM
- Rely on vendor or community as most successful companies in IT Cloud /Automation were those who build their own solutions by the power of community
- Can we promote a production ready G-VNFM and remove S-VNFM totally?
- Can Telco and IT workloads can be automated in the same manner (Cloudify vs Rift approach)
NFVO Scaling and Performance Issues
It seems clear what started off as an industry idea and university R&D project is a commercial reality now and it means the solution must deliver a comprehensive TCO and savings if we have to deploy and use it . This is why a company CXO want to visualize Orchestration across the whole network from the Core Cloud to the Edge.
However although all EUAG’s have analyzed the Orchestration solution and know that real value chain exists at the Edge but still are finding the best way to do it at scale . There seems to be some clear challenges.
The real issues of Orchestration around scaling and orchestration can be defined as follows .
- ETSI MANO was good in central DC but a more open and developer API based orchestration means it will have limitations to scale the Edge
- ONAP seems modular, scalar , programmable but same time its complex. If you are not a developer type of company its really hard to keep pace with it
- OSM is good for Operator specially its IM model , VNF/PNF support but will it be really carrier grade at the Edge with too much dependency on adaptors
- Finally, should be deploy a virtualization at the Edge based on VM style (Akraino/StarlingX) or container style (Akraino/Airship).
NFVO and DevOps
Telco Needs DevOps and that is why the Orchestration and automation business is taking a huge momentum, let us understand phases in which we can evolve .
- Phase1: When We believe we have reached a point for Virtual Network automation specially Day1
- Phase2: Next we want focus on Day0 design and Day2 specially VNF configuration automation for 3rd Party VNF’s
- Phase3: Next main idea if build complete CI/CD Pipe line through all artifacts and tools form many vendors including Open source ones
- Phase4 the pure Orchestra: This vision is important to support Play store vision for Orchestration
Knowing this vision is as vital as knowing the road to your destination. For a long journey we all know what matters most is we travel a handsome distance but making sure we know our target .
Defining Business use cases of automation
“ETSI NFV TST006 is still not mature , primarily DevOps in CSP will address Digital service management like ZSM through portal ,Auto Slice management , E2E Closed Loop control , service automation equals (===) Telco DevOps”
To ensure automation and orchestration business takes momentum it is vital to link it with a business use cases , however DevOps is still a fancy buzz word but with ETSI Release 3 (TST 006) we are coming out to define a more clear interpretation for CSP’s however it I still a Early draft and mainly only talks about process and responsibility split between developer (Vendor) and provider (CSP) . It obviously is important because in Telco we work with so many vendors and their responsibilities and management is very important .
However still we want follow direction to introduce DevOps based on a use cases to deliver maximum value for CSP with key use case which are shown below . Below use cases are a good start to ensure the value of automation is indeed delivered to business
Based on experience one can see there are lot of issues but definitely possible solutions and directions to address them .
I will wrap this paper here and will come back soon with Part2 – The Orchestration solution . This is based on our recent work with communities and to come to a conclusion that industry success will be more relied on coalescence and support for hybrid solutions than to take only one direction to solve issue.
This will be the epilogue of the Part2 of this paper and I sincerely hope it will add value to what you are doing irrespective of Telco or IT business .
References:
https://www.onug.net/blog/network-orchestration-and-visibility-for-managed-sd-wan/
ETSI docs
TMForum.org
Cloudify.io
Rift.io