As service orchestration is increasingly applied to the activation of services in the virtualized as well as the physical network, its scope is expanding.
To carry out service activation cost-effectively and provide the service agility that operators want, service orchestration needs to be model-driven. That is, instead of activation based on the never-ending task of workflow definition on a per-service basis, service orchestration should use the concept of state convergence, which requires services and network devices to be modeled in a standardized modeling language by network domain experts. These models can then be declaratively mapped to one another without the need for coding and in a highly flexible way.
Support for data models and state convergence represent the first two pillars of service orchestration. However, as the network is virtualized, it is introducing new domains – the NFV MANO and SDN controllers – that need to be supported when a service is deployed end-to-end across both physical and virtualized network ele- ments. And as services can be deployed more quickly in all types of network – phys- ical, hybrid and virtual – thanks to model-driven automation, they need to be assur- able as soon as they are activated, or the benefits of service agility are lost.
A service orchestration system should thus encompass two further pillars: the ability to orchestrate across both physical and virtual networks, whether devices are con- figured via traditional (CLI/API) means, the NFV MANO or an SDN controller; and support for orchestrated assurance – i.e., the ability to assure both that the activated service has been properly deployed and that it is delivering on its SLA at runtime.
Leading operators are already transforming service delivery times and customer experience through the use of service orchestration based on these four pillars. Those not yet taking advantage of service orchestration should carefully evaluate competing systems to ensure they support all four pillars for a future-proof approach to network service lifecycle management.
I want to create a NSO service that uses grouping from 3rd party YANG model. However, this model uses a lot of absolute leafref path references that need to be changed. Although it could be done manually with substantial effort, I would like to...
Does anybody know what might cause ncs_cli to exit executing commend with: "*** CLOSE TIMEOUT ***" error message.
This might happen executing pretty much any long running command, i.e.:
echo "devices sync-from" | ncs_cli -C --user admin --stop-on-e...
Is there any pre-cooked way to get the size of a list via RESTCONF? For example, I need to get the number of devices in NSO.
I am now using the query API. but I wonder if we could use xpath in any clever way.
curl -X ...
I have an ADVA device for which the NETCONF ned is created using Pioneer package. When I try device sync-from on NSO, I am getting this error:
admin@ncs(config)# devices device AUSDTXIRDAW sync-from
info RPC error towards AUSDTXI...
So, in theory a simple problem, I need to find out what NSO package some python code is running from, not the Yang model or service name, but what the actual package name is in NSO, from the python code, but is seems hard, if not impossible to do. Th...