Cisco Live 2017: Simplifying the Network

Terry Slattery
Principal Architect

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 “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.

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.