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.
There is also a longer-term concern. Although backed by a large community, the active development projects for OpenStack focus almost exclusively on the data center use case. For example, if you plan to leverage a particular hardware acceleration in your white boxes or want to achieve a resource-optimized solution for them, you will find yourself pretty much alone (poor documentation, unpackaged/untested software, broken features when upgrading…).
Why managing uCPE through a NETCONF API is better
AT&T has considerable experience with OpenStack and yet pushed for NETCONF to manage branch deployments. EKINOPS sees many other CSPs that have adopted similar strategies. From an orchestrator point of view, NETCONF has a great advantage in that it is a single protocol to provision any kind of CPEs (white box or not) as well as VNFs.
Then the questions could be: why bother changing from the current solutions? What about using a REST API?
This is where the key characteristics of NETCONF shine: it is transaction-oriented. With OpenStack, deploying a VNF template will result in a series of calls in Neutron, Nova, etc. If a glitch happens, the changes will not be reverted, thus requiring manual intervention by experts to diagnose and manually fix inconsistencies. If you use NETCONF, the uCPE VIM will guarantee the completion of the provisioning order plus the ability to rollback changes in case of issues. Part of the issues could be addressed by taking an OpenStack controller from someone who packaged it specifically for use with uCPEs. But you would thus lose sight of the initial objective: a single OpenStack implementation for both data center and uCPE.
This is not to say that OpenStack will never work. It does, and if an OpenStack infrastructure is already available, prototyping the solution can be fast. But its challenges should not be underestimated; nor will they be easily overcome. Using a NETCONF API to manage uCPE implicitly solves concerns regarding security, API backward compatibility, solution robustness and maintainability as well as associated design and operations costs. Not only does it require much lower skills in the short-term, it proves a better fit in the long run.
[1] This TCO analysis from Redhat illustrates that deploying OpenStack is far from a minor exercise.
