CLEUR, OpFLEX, User Interface and Paradigm Shift
Much has happened so far this year, but one of the key events was attending Cisco Live in Milan. I filled my planner up with every interesting session I could get on, but without any real surprise, most of it focused on onePK, ACI, IPv6 security and EEM. The world of solutions presented a chance to shmooze myself around the various vendors and ask awkward questions. More importantly, a chance to have a beer with on of my hero’s @CloudToad from [Plexxi inc(http://www.plexxi.com/)]. and @NeelaJacques from the OpenDayLight project, whom after a beer induced rant handed me his business card. Sorry Neela Jacques. I took much away from Cisco Live including a vow to code more and spend more time on self development activities. Was it worth going?
A great time was had
So was it really worth going? Despite tourist prices for food and drink, absolutely. What did I really take away from Cisco Live? A message that Cisco and OpenFlow aren’t really going to play ball was one. The other was much more fundamental. A serious skill set shift and expansion is upon us. The vendors that created the most excitement at Cisco Live were those touting control systems such as Tail-F and Anuta networks. They might be termed SDN controllers with analytical engines, but the reality is, these are control systems with feedback loops. Why the excitement? Well, most enterprises would like to be able to control the traditional along with the virtual. Being a little more descriptive, this could be physical switches and routers with network operating systems representing the ‘traditional’, and virtual switching or NFV services representing the ‘new’. Network analytics was a big part of what vendors were pushing. Once you can make sense of how everything looks, overlaying company policy, which could govern the network for cost or performance becomes possible, never mind configuring ports or provisioning VLANs etc. Cisco’s onePK empowered one Cisco employee to do exactly that. Dijkstra’s algorithm was consumed by an application that pulled routing information from a network via onePK. The software could then setup paths based on business logic as opposed to traditional link metrics manually set by the operator. Impressive stuff.
So how unified can we make our network control plane?
Tying together traditional elements and virtual systems which are so different requires a common approach. The only real way to achieve this is to abstract away the configuration from the network elements and network operating systems. Taking the journey further, it involves creating a model from the requirements, then rendering the configuration on to the network via south bound interfaces, which in turn could be OpenFlow, onePK, I2RS, NETCONF, CLI or even SNMP. [Edited and corrected – thanks Jeremy Schulman!] Junos for example can handle SOAP and XML RPC calls. XML is built in to the very core of Junos and you can access a NETCONF XML interface via an SSH sub channel. No screen scraping like you would have to do with Cisco’s IOS (without onePK I hastily add).
As the mental journey progresses, you could ask “Well what generates the requirements for a change?”. A valid and important question. The requirements could come from a virtual compute environment and the need to create a new network resource (a VLAN, subnet etc), or it could come from an orchestration engine. Either way, there is some plumbing work to do which comes in the forms of tying APIs together. To add to this mash up of technologies, on Tuesday (April 2nd – 2014), Insieme (the Cisco spin out/in that bought you ACI) announced OpFLEX at the Las Vegas Interop conference, a technology that appears to sit above what would be typically described as southbound API control mechanisms. OpFLEX takes a slightly different approach and provides a policy abstraction language which then utilises the best technology for the job at hand to enforce the policy. Before diving in to find specific details, I did manage to get this out of Mike Dvorkin (@dvorkinista on the Twitters) from Insieme networks.
Is this an API to rule APIs? Cisco have termed this the SDN killer. Check out this article for more information on OpFLEX and here is the IETF draft. Anyway, before APIs can just be called, it must be known what each API does and what responses are to be expected. This isn’t a coding blog post, so we’ll put this on hold, however, the time of the CLI is coming to an end. I’m a firm believer. I don’t think it will go away, but I do think it will be used less and less. In a few years, newer industry members will view the CLI as an arcane method to debug or access the underlying operating system (providing we’ve not moved to run time containers!). API calls are typically made by by something like an orchestration or automation engine, but let’s not rule out run to completion scripts or software like Cisco’s Process Orchestrator etc.
An off piste closure
Back to the original plot of the post after a jaunt off piste, Cisco Live gave me an opportunity to understand where Cisco are going with the technology, but also a wider feel of what enterprises are asking for. Who wouldn’t want to be able to control physical switching and routing along with virtualised network functionality or NFV as it’s more commonly known? An answer to the question “are we all to become developers to take advantage of this ubiquitous programmability?” came out of Cisco Live too. The answer it seems for now is “no”, but with a caveat of being able to advise and guide developers on where to find the relevant information and development tools. I personally think this is a stage and not the end game. To really take advantage of all of this technology, pick up a language like Python and get stuck in is my advice. If nothing else, you will come to understand and respect the problems developers have when trying to understand how to network rendered code.
I for one think we’re entering a rich and fertile time period of new encapsulations, protocols and imaginative solutions to age old problems. NFV can deliver high performance functionality through optimised x86 instructions (see 6WIND), networks can grow beyond 4094 VLANS via VXLAN, NVGRE and STT and applications are becoming network aware and will be able to request network resources. As more of us look at harvesting operational data from the network and messing things up in automagically new and wonderful ways, IPv6 could have it’s day as NAT could start to be the thread that pulls apart ever increasingly complex tapestry. Here’s hoping.