Network Programmability

Why Network Programmability?

To simplify the task involved in configuring, managing and operating new equipment, network topologies, network services and network connectivity. The main aim is to minimise the amount of manual interactions with network.

Benefit - Operational inefficiency and Improve productivity.

Traditional methods — snmp, cli and other Manual means. As Network grows, managing NW via command line is bit more complex and harder to manage as we continue to use CLI as the number one mechanism to make changes on the network. Due to inefficiency of trying to manage a large number of network devices manually, new solution is needed to evolve away from manual to more programmatic and robust means - API or application programming interface.

For several years, operations team has been using commercial tools — VMware vcenter, Microsoft center and open source tools such as puppet and chef. Cisco has already started to build programmability options into their platforms. Now its in the form of API(application programmable interface). Particular API depends on individual platform as of now. But as development continues you will see uniformity among various platforms.

You will see the evolution of device management and programmability and how we come to this next generation programmatic interface, which is a model driven solution.

Model driven programmability stack along with its four components — data models, transport, encoding and protocols.

Data model is the important aspect within the API. Data model defines syntax and semantics including constraints of working with api. YANG is a data modelling language(it is protocol independent, but originally designed for netconf).

Encoding - 2 formats used in API are - XML and JSON.(structured way to send data between 2 computer systems).

Transport - Model driven APIs support one or more transport such as SSH, TLS and HTTP.

Protocols - Netconf, Restconf, GRPC.

Next generation configuration management requirements:
1. API’s need clear and well defined ways to interact with them. They should be also able to leverage custom and open source tooling to easily consume the apis.
2. Support client side validation and error checking.
3. Separate configuration and operational data - there is a delineation between configuration state and operational state and it needs to reflected in the api. Any attribute, configuration parameter or statistics should be accessible via the API.
4. Contain a built in or backup restore capability.
5. Be both human and machine friendly.