While talking about rapid deployment of millions of IoT devices per day in his Cisco Live 2017 keynote, Chuck Robbins, CEO of Cisco Systems, said the following:
“We have to change the degree of complexity; complexity is the enemy of everything I just described. Now we have to bring a degree of simplification that allows us to move faster.”
Excellent! That sounds great. I’m all for simplifying the network. I was hopeful that SDN (perhaps via OpenFlow) would be the basis of simpler networks, but it hasn’t fulfilled the initial promise. (Note: Google’s WAN may be one of the few exceptions.) We do a lot of weird things with networking (e.g., PfR and policy-based routing) to make packets go where we want them to go and to prevent them from going places we don’t want them to go (ACLs). Then consider MP-BGP, MPLS, VXLAN, SD-WAN, and all the other technologies we use to make the network more efficient or to work around destination-address-based routing. Back to the keynote, there is a picture at 27:53 about making automation data actionable. It struck me that this is an example of making the network management plane more complex.
However, I just don’t see the industry moving toward simpler networks. As we strive for greater efficiencies, we typically make things more complex, as I described in a blog post on nojitter.com: “Is SDN Like a Fuel Injected Engine?” I don’t see the industry reducing network complexity without doing something revolutionary like SDN had promised (but hasn’t fulfilled). (Note: Perhaps I’m not being patient enough with SDN, and it will eventually provide simplification. Some companies, like NEC and HP, have been using it. There is also Cisco’s involvement in OpenDaylight, as well as the Recursive Internet Architecture (RINA) initiative, which actually seems to simplify the architecture of the IP networking stack. We’ll see how these things turn out over time.)
Simplification Through Abstractions
Software engineering and computer science use abstractions as a method for hiding complexity. We need to apply this mechanism to networking. Scott Schenker mentioned this in his presentation, “A Gentle Introduction to SDN.” This is what I think Chuck meant, because I don’t see us changing the fundamental networking constructs in the near future. In fact, I think we’re going to be adding more complexity in the near term.
So, what do I think Chuck Robbins meant?
The big announcement from Cisco was actually made the week prior to Cisco Live 2017, with their unveiling of “The Network. Intuitive.” (See the keynote at 15:00.) This is something that Gartner is calling “intent-based networking.” This is an approach that can simplify how we think about networks and how we interact with networks.
I see intent-based networking as a way to create new abstractions about networks and relieve us of the details we currently have to handle. I don’t yet have a good handle on the set of new abstractions, but let’s look at some possible scenarios that might give us a hint at some useful abstractions.
- Layer 2 and Layer 3 assignments. We should be able to allow an automation system to control adding systems to the network. If a server is auto-provisioned, why can’t that same system automatically provision the network connectivity, based on a high-level definition (intent)? We shouldn’t have to work with address assignments, vlan definitions, and physical connectivity configuration options (like switchport host).
- Infrastructure link configuration and assignment. We should have automation systems in which we can specify the role of a switch and that it is connected to its neighbors with a certain level of redundancy (be it a three-tier design or an N-level CLOS design). The system should tell us which ports should be connected to the neighbor’s ports, produce a wiring list for the physical install, then automate the validation that the ports are connected properly after the switch is installed. Then automatically update the drawings, using common layout standards.
- Firewall rules. Switch to a white-list model in which connectivity is not allowed unless specified. Then use a database of application communication definitions to drive the creation of firewall rules that allow a high-level definition of the desired connectivity. For example, authenticated clients on the internet are allowed to connect to application X. The automation looks into the database for the connection rules and applies them to the necessary firewalls for that application. Micro-segmentation and NFV service chains could be automatically handled.
Using the above as a starting point, I’m sure you can think of more and better examples. What abstractions would be useful for a multi-home BGP implementation?
As a thought experiment, consider how much effort is involved in doing the above examples with manual processes, with a scripting tool, or with intent-based networking. Which environment would you enjoy the most and would be the most productive?
What About My Job?
Will abstractions and the changes I’m describing replace our jobs as network engineers? No. We will still need people who understand how the network works. It will still break, and we’ll have to know how to troubleshoot it and effect repairs. We’ll still need to know how the network functions at a low level.
Will our jobs change? Yes. We will need to learn these new systems and how they work so that we can troubleshoot them. There will be a new “intent-based network language” that we use to define what we want to have happen. I’ve been thinking about the GUI interfaces that I’ve seen on a number of new tools. These are fine for casual use, but we are going to need a definition language that can be exported, backed up, archived, and examined when things go wrong. Think of it as the CLI for the intent-based network. It may be JSON formatted, or perhaps in some new format that will be invented to represent the relationships in an intent-based network.
This is an exciting time to be in networking. Don’t lose your drive to learn and to stay on top of technology changes.