The most critical areas for review are in parts of the network where service deployments require frequent and/or complex chain of changes to multiple network elements, e.g. VPNs for enterprises. These are expensive to fail because they are difficult to rollback to the original state. A typical example of frequent configuration management is when new network elements are required to keep up with explosive traffic demand. All of these configurations are time consuming and could have dramatic service level agreement (SLA) charges to the CSP if there is a failure. Compounding the problem, network engineers routinely access individual network elements and manually change the configuration to update the network or troubleshoot problems. This unsystematic change is typically done without documentation thereby making it impossible to maintain accurate inventory systems. Rollbacks are based on attempting to manually back-step the initial fix. Inventory systems with inaccurate information prevent true automation of service orchestration because there is a breakdown in the view of how the network elements are configured.  

Key challenges:

• Services are defined in specific locations of the network and are tied to specific network elements
• Lack of standards adoption prevents true multi-service and multi-vendor capabilities
• Writing network element configuration to network elements is an after-thought
• Accurate configuration inventories and rollback policies are currently seen as nearly unobtainable

Architecting a new approach: 

Starting fresh with brand new network architecture is a luxury that few established CSPs can afford. Nor does it make sense to adopt a single-vendor solution. Any network configuration management solution must be able to easily fit into the existing network and take advantage of existing northbound interfaces to the BSS/OSS system as well as leverage the existing southbound interfaces for managing the current and future network elements. This enables current staff to quickly adapt to the new technology as well as taking advantage of existing capital investments by leveraging network elements.  

As we have seen, the breakdown in the service delivery process often occurs at the last step of fine-grained network configuration. Any new approach must dramatically reduce complexity and ensure that the entire process is fail-safe. This focus on detail must start at the network element itself to ensure service delivery integrity.

Many attempts and even highly successful products have been created for a service at a single network segment by a specific vendor.  However, these point solutions fail to provide a unified toolkit for a multi-vendor environment, which may lead to vendor lock-in. The goal of any new approach must provide an extensible solution.  It must be architected in a manner that can be used in any area of the network and capable of managing any network element that can be remotely configured – either physical or virtual. There must be a way to handle the complexity of each service, existing or future, that is delivered and of each network element that is management in a scalable, rule-based fashion. 

New approach expectations:

• Leverage the existing network and OSS/BSS infrastructure, including existing northbound and southbound interfaces
• Reduce complexity and make it fail-safe--solve it in the right location, i.e. in the network (not in the higher-layer workflows)
• Provide an extensible solution, i.e. no hard-coded knowledge of network elements or services