RAD isn’t exactly a household word in SDN, but their CTO did a blog on SDN that raises some interesting points, particularly given that another vendor (Juniper) is scheduled to do an SDN announcement tomorrow.
The first point in the RAD blog is that “SDN returns to centralized control as compared to a distributed control plane”. This is important because it captures the distinction between the “strict-construction” model of SDN and the “loose construction” favored by the router vendors. Forget the idea of “separating” control and data plane; that’s shorthand for saying that the network continues to forward based on adaptive discovery and not central control. I’m not opposed to a loose-construction vision of SDN, but I am opposed to dodging the differences.
Which the blog does a nice job of identifying. Strict-construction, central-controlled, SDN has a traffic and topology management process that collects information about the network and makes global decisions on routing, which are then communicated (in some way, OpenFlow for example) to the devices that actually handle the traffic. This makes the process of forwarding much more cohesive (“consistent” in the blog’s terms). It also creates the potential for a single point of failure, which is the tip of the iceberg of the second point.
Why only the tip? I believe that SDN is justified by the cloud, and one of the cloud’s primary requirements is that new resources (servers) be able to “boot from bare metal”, meaning to commission themselves from a hardware install through OS and middleware to becoming a full member of the resource pool. My view is that SDN has to do the same, meaning that we have to be able to install a device and have it “boot from bare metal” to become part of the network. We also have to be able to recommission the network after a failure, but the fact is that in SDN the two are related. OpenFlow is the control protocol to set forwarding, right? OK, then, how do we deliver OpenFlow control packets without the forwarding entries that OpenFlow sets up? How complicated will it be to restructure connectivity around a failure when you need to be connected to every device that’s to receive a forwarding-table change through the entire process? How does a node that’s isolated become “un-isolated?”
The router guys have/will say that they have the answer, which is to “separate” the control plane but keep it in the device. That does in fact fix the problem of booting from bare metal since every device discovers connectivity as before, but it doesn’t move the ball much in the way of network complexity or cost since it’s really not changing anything. So these loose-construction players have to be more articulate about just what value they do bring to the table. You can’t claim central-control value without doing something centrally, and you have to explain not only how that works but also how it’s different from today’s routing or switching.
Then there’s the issue of network functions virtualization, the operator effort to host more network functionality on servers. Loose-construction SDN would seem to be taking a step away from complete NFV because it doesn’t dispense with local adaptive discovery processes. SDN’s central control of routing seems conformant to NFV principles. But what would NFV mean to SDN? If you presume that an SDN switch is a forwarding engine under central control, what is an NFV appliance? I’m looking at that issue in detail in our January issue of Netwatcher, but for now let me say that we have to think beyond OpenFlow and beyond forwarding to get to NFV. And I contend that we have to get to NFV because 1) the buyer wants to and 2) SOMEBODY will listen and give them what they want, forcing others to conform.
This sets the stage for Juniper’s SDN session at its partner event tomorrow. Bob Muglia’s “Seven Myths of SDN”. You can read a lot of defense-of-routing-business into these points, of course, but the fact is that there is an element of myth in each of the four areas. We do have to think of SDN in a broader way than a cloud data center, we do need hardware to move packets, we do need operations and performance benefits in addition to capex benefits, centralization isn’t the only answer nor is OpenFlow, and getting to SDN is complicated but not insurmountable. The challenge for Juniper will be to make real, useful, points in each of these areas and not just blow marketing smoke. Cisco is clearly going to take a loose-construction view of SDN. Juniper is likely to do the same, and being the second guy to paint “SDN” on an existing box isn’t going to impress anyone (or at least it won’t impress me). So say something useful tomorrow, Juniper. RAD, after all, said something useful today.