You Need Both Sides of the Equation in Network Management

CommunityWhen doing math, equations include variables on both sides and both sides of the equation have to be equal; i.e., balance out. In essence, you need to add to both sides or subtract from both sides equally. So, both sides of the equation are equally important. When one side changes, the other has to change as well in order to maintain equality. When the equation is network management, the two sides of the equation are the device side and the orchestration or controller side. Just like in math, you need both sides to be equal. For my analogy, what balances out in the equation is the importance of and understanding of each side of the equation. Just like a balanced scale, you must have an understanding of the device and the orchestrator or controller on each side in order to achieve good network programmability and automation.

The device team really needs to understand how orchestrators and controllers work and how to interoperate with them. Equally, those that make the orchestrators and controllers need to know how devices work and how to optimally manage them. If either side works in isolation, programmable network management cannot be achieved. You must know and understand both sides of the equation.

In today’s always on and fast-paced world, it is a fact of life that networks are going to be multi-vendor. This means that it isn’t helpful to do any proprietary management things in the device or the orchestrator/controller. Both sides have to be able to communicate with each other in a multi-vendor world. The result of understanding this equation is both sides of the equation working together cleanly to help meet customers’ needs and ultimately getting and keeping your customers. Here are a few use cases to help highlight how this works:
Device Side Focused: If you are on the device side, you may think it would be a user convenient to auto-configure some things in the device based on other items being configured. From a device-only focused approach, this seems like it is helpful. However, in modern network management, you don’t have people managing these devices via human-machine interfaces such as CLI. The only way to automate networks is to make them programmable and remove the person from the orchestration or controller side. From the viewpoint of the orchestrator or controller, auto-configuring things is a bad thing to do as it will result in the orchestrator or controller having an out-of-sync configuration for the device. Taking a one-sided approach to network management creates chaos. Both sides of the equation must balance out.

Do Your Standards Equate: Standards compliance is another example as network management requires that you rigorously adhere to standards to ensure you are delivering multi-vendor interoperability? If you go and tweak one thing in your device’s implementation of the standard because a customer asks you to deviate from the standard, you have just broken standards-based interoperability. Standards-based interoperability is the bedrock upon which network programmability is built. By following the standards, you ensure your business and offerings are interoperable, programmable, and successful. Deviating from the standards to satisfy one customer is bad business in the long run. This will require telling customers that it is important that you stick with and adhere to the standards so they don’t have any issues down the road. Standards deviation unbalances the equation.

Don’t Define Custom RPCs: When looking at NETCONF and YANG, it is very tempting to define new RPCs (remote procedure calls) by modeling them in YANG. However, best practices show that defining custom RPCs creates significant interoperability issues. Even if what you are doing will deliver a wiz-bang action, just don’t do it. As noted, before, almost all of us live in a multi-vendor network world, orchestrators and controllers won’t know how and when to use this custom RPC because the YANG data model only defines the syntax of the RPC and not the semantics of its use. The knowledge of how and when to use the custom RPC has to be custom programmed into the orchestrator/controller. This ultimately will end up with an RPC that is not usable or require a lot more time to create code to make it work, if even possible. Again, a bad result from not balancing out both sides of the equation.

I could go on and on with examples here, but these are a few that I have seen and experienced in real life. Without taking the right approach and understanding both sides of the equation (Device & Orchestrator/Controller), you will only succeed in causing more challenges and frustration for your customer’s network management process. However, when you look at both sides of the equation and align what you are doing on the device side and the orchestrator/controller side, you ensure a stronger programmable, automated, and interoperable network and happy customers.

I have a couple of recommended options for those looking to better understand both sides of the equation. Take a look at the following resources:

  1. Check out our NETCONF and YANG Automation Testing program that is freely available for anyone to use. This program helps both sides of the equation by showing how to test a device for NETCONF and YANG interoperability as well as automation best practices.
  2. To ensure you are doing programmability right, you must invest not only in the right solution but also in testing so you can prove the results. I recently wrote a blog post on the need to participate in the EANTC MPLS SDN Multi-Vendor Interoperability Test Event 2021. This event has been a must participate for several years to test various network devices and orchestrators/controllers with other vendor solutions.