The Self-Publishing Network – What Can it Do for You?
James Crawshaw, Senior Analyst – Service Provider IT and Automation, Heavy Reading
Last November at Light Reading's Software Defined Operations event Carl Moberg, director of technology at Cisco, gave a presentation with the curious title: "The Self-Publishing Network." It was not about a self-help group for struggling authors, instead it concerned "integrating network intent into customer-facing systems." What made it interesting to me was that it dared to span the organizational boundary (often a chasm) between the networking domain and the OSS/BSS domain.
In his presentation Moberg split the "stack" into three layers: the network resources (routing/switching), network orchestration and automation, and (on the other side of the organizational boundary) order management systems (OSS/BSS). According to Moberg, the bottom layer has now evolved from printed work orders (typed into device CLIs), swivel chairs (to switch between different vendor CLIs) and line-by-line scripting to a world of APIs (NETCONF/RESTCONF), database semantics and standard models (YANG-based). Moberg believes the routing and switching platforms being sold today by the major suppliers generally meet this new paradigm of programmability although not all operators are yet taking full advantage of this due to cultural and procedural barriers (people and process).
In the orchestration/automation layer Moberg thinks that the industry is still at the stage of vendor-specific solutions such as domain controllers which are really just glorified (single-vendor) Network Management Systems. He observes that many of the technology choices (e.g. SNMP and CORBA) are "exotic," far away from the mainstream of modern computer science. Moberg sees many of the orchestration/automation solutions in the market today as little more than readers -- "they can show network information really well but when it comes to changing things in the network in flight they come apart or are reduced to line by line scripting, albeit done by software."
The way forward for these orchestration/automation solutions, according to Moberg, is based on abstractions and model mapping: "a joint understanding of what networking is and a means of expressing this using things like YANG service models." NETCONF and YANG have been around for 12 and ten years respectively and have demonstrated themselves to be stable and robust with no obvious contenders. The next step in the evolution of orchestration/automation is full lifecycle management. Rather than simply reading information from the network, these systems should be capable of creating, updating and deleting resources and services in the network.
However, not all service providers have reached this stage. Moberg referenced a European service provider which had recently realized that 40% of the configuration in their network was dead, meaning it referenced interfaces that no longer existed. According to Moberg, "they were struggling with a massive data quality problem due to the lack of a full lifecycle management of their network."
With the evolution of the network layer well on track and the automation/orchestration layer in progress, Moberg foresees a similar development next happening in the OSS (order management) layer of the stack. Currently these systems are based on informal service definitions, proprietary data representations and hardwired integrations. Their evolution will be to formal definitions, standardized data tooling and what Moberg terms the "self-publishing network."
In Moberg's view the service definitions of the TMForum lack the rigor and formality that machines need, which means they need to be enriched by humans to make them useful for real world networking. This usually leads to hard-wired integrations performed by IT consultants. Moberg's alternative proposition is for more formal definitions to be created on top of the more generic TMForum definitions, which should enable standardized data tooling. The self-publishing network concept is based on the idea that each layer in the stack can tell the layer above what it can do for it. The network layer can tell the orchestration and automation layer what its capabilities are without the need for manual intervention. Moberg sees the same thing happening between the orchestration/automation layer and the OSS layer, in a formal and fully specified manner.
Moberg notes that many service providers are building CI/CD pipelines for network provisioning using formal models that require limited human intervention. Some forward-looking service providers are looking to connect their YANG service models directly with their CRM systems such that once a new YANG model is created it can be immediately available in the CRM without the need for the typical six to 12 months of manual integration. The next-generation order management systems will similarly be built to consume these YANG service models instead of the traditional approach of custom integration with the network. In Moberg's words "they can consume the network's capabilities as a first order feature."
So, the self-publishing network concept is essentially about systems being able to communicate northbound to other systems to let them know what they can do for them. Moberg says the self-publishing concept still requires some standards work, some interoperability testing and buy-in from the vendor community, but naturally he is optimistic about its prospects. It will be interesting to see how the concept progresses, and if successful, whether its adoption will be any quicker than that of two of its building blocks, NETCONF and YANG.
To find out more about the self-publishing network, check out this video interview with Moberg at the Software Defined Operations event last November: What Is the Self-Publishing Network?
This blog is sponsored by Cisco.
— James Crawshaw, Senior Analyst, Heavy Reading