On April second, Cisco introduced something that seems to make a lot of sense in its new declarative-based, ACI-led world of software-defined networking: a policy mechanism. The blog post about it was pretty straightforward: it included the obligatory nods toward the Internet Engineering Task Force (IETF) and open-source communities, defined the differences between the traditional imperative and the newer Cisco declarative models, and had snazzy graphics. Cisco laid out the core challenge clearly:
For this declarative model to work across a multi-vendor environment, to translate and map policy definition into the infrastructure, there has hitherto been no standard protocol to do that across physical/virtual switches, routers and L4-L7 network services. This vacuum has led to the development of OpFlex, a new open standard recently submitted to the IETF.
Continue reading OpFlex, Standards-Based Protocols, and Cisco’s Messaging Problem
Despite all of the rapid innovation and the incredible rate of change in technology, there are some things that you can count on. One of those things is that the transition from hardware to software is a cyclical one, and if you look at any one segment of the market long enough, that becomes apparent. We’ve seen it in the move from mainframes to x86 servers, to virtualized servers, to distributed, scale-out systems. We’ve seen it in the move from terminals to PCs to VDI to EUC and even in the move from legacy storage arrays to software layer, scale-out storage aggregation. Now, we can start to see the SDN market following the same pattern, and one of the leading indicators of that comes from a company called Netronome.
SDN is getting a lot of hype at the moment. Coupled with its kissing cousin, network virtualization, it is all the buzz.
So what exactly is it?
At its most basic level, SDN is an approach to networking in which the control plane is decoupled from hardware and given over to a software controller. Continue reading Software-Defined Networking (SDN): What Is It?
Many network virtualization products appear to be aimed at the top 10,000 customers worldwide, accounting for their price as well as their published product direction. While this is a limited and myopic view, many claim it is for the best, their reason being that network virtualization is only really needed by the very large networks. The more I think about this approach, the more I believe it is incorrect. Let us be frank here. Most networking today, within many different organizational sizes, is a hodgepodge of technologies designed to solve the same problem(s) over and over: how to get data quickly from point A to point B with minimum disruption to service. Continue reading Network Virtualization: Not Just for the Service Provider
Recently, I had the opportunity to talk about the shortest path bridging (SPB) protocol with Avaya while at Interop. This conversation was one of many with networking companies. While SPB is a very interesting protocol, my questions were about how deep into the virtual environment the protocol extends. While SPB and other networking protocols are considered by some to be network virtualization, I could not see this within the realm of the virtual network and hence, confusion reigned. Depending on who is talking to whom, the same words can mean many different things. What I found amazing, still, is that most people thinks networking ends at the physical NIC within the virtualization host, and that what is inside, does not matter as much as what is outside. Continue reading Virtual Networking Is Not Network Virtualization
Over the last few weeks I have been struggling with automating deployment and testing of virtual desktops for my own edification. This struggle has pointed out automation weaknesses which need to be addressed for automation and the software defined data center to succeed and to not only be deployed from software, but also to be self-healing and all the great things we associate with SDDC, SDN, etc. But current automation has some serious flaws and weaknesses. In essence, in order to automate something you must have a well known exact image from which to work. Continue reading Automation Weaknesses