I really enjoyed attending Cisco Live this year — especially meeting and networking with people. A significant part of why I attend the event is simply for networking in the Cisco community. I appreciate the opportunity to renew old friendships as well as meet folks who have read my blogs or interacted with me and my company in other ways. I also value the opportunities to chat with the speakers after sessions, as well as the product and program managers at Cisco. (I did make a few suggestions….) It is also fun to bounce ideas back and forth about where the world of networking is going. These are interesting times!
I’ve been to multiple Cisco Live conferences (back to the Networkers days), and now I try to delve into a specific topic each year. (OK, except for maybe that one year when I may have signed up for any session where the speaker was from Belgium…because they have such cool accents!)
This year my intent was to focus on data center, network automation, and DevNet, looking for processes and tools to help my customers implement and operate their networks. I scheduled and attended multiple of these sessions and received a wealth of information. Looking back, I feel that my schedule ended up being too data-center focused. I think we are seeing a lot of initial effort in the data center arena, maybe because it seems to get technology refreshes more often than the legacy network.
I’ve been reflecting on my week at Cisco Live, and I find that the most significant take away for me was the intent-based networking discussions. The promise of intent-based networking is that it will allow network personnel to define/describe their intentions for the network, and some magical box/application/software will translate this intent into an automated policy that is propagated across the network.
I see intent-based networking as what SDN (software-defined networking) will evolve into. I think it will be extremely helpful to have a way to abstract the details of policy and resulting configuration so that networks are easier to configure and operate.
For example, I am very interested in Apstra and its self-operating network. Again, I think it is too data-center focused. I really want its leaf-spine model to expand out of the data center and allow me to support existing legacy networks. (Perhaps it could, if I write my own cartridges….)
Since going to Cisco Live, I’ve been inspired to get more immersed in network programmability. I’m trying to expand my mental models of networking to integrate the possibilities of programmability and intent-based networking. I’ve just completed Cisco’s online Designing and Implementing Cisco Network Programmability course. I have been doing an immersive dive into RESTCONF and NETCONF APIs, using Postman and Python and YAML, reviewing Ansible playbooks, and validating YANG models. I’ve done constructed API requests during APIC-EM and APIC labs. Now I am trying to parse this into my mental models of how we configure and operate networks, and how we might someday configure and operate networks.
I believe some of these tools can help organizations immediately; some in the future.
There is a plethora of tools, but I don’t necessarily want to be a programmer. I’d like to be a consumer of higher-level tools that abstract some of the network and underlying details (such as the very exact spacing needed for some programming tools).
Some ideas:
- What if we could define a desired cabling plan, and have the network validate whether the topology was cabled as planned? What if we could do this without need to correlate show cdp | ldp neighbor results across a network full of devices?
- What if we could ensure that the new member on the network team remembered and implemented all the steps in adding a new VLAN to a vPC environment, while avoiding pitfalls known to more experienced personnel?
- Actual use case: Monday night at Cisco Live, I was listening to some new friends discuss a recurring network meltdown problem that they and TAC could not resolve over weeks of troubleshooting. After a bit of discussion, I suggested the possible root cause was they might have routing protocol peering across the vPC VLANs — and that this is not a supported configuration for Nexus 7Ks.
- What if the network could pipe up during misconfigurations with a “Danger, Will Robinson — that is NOT a supported configuration, and could lead to serious future issues”-type message?
Networks — they are changing! I look forward to the future availability of intent-based networking tools across the enterprise.