At the same time, from the first ONS it was always very, very clear; SDN is not OpenFlow, OpenFlow is not SDN. What we're really trying to do is change the industry and introduce the opportunity to have all different types of new thought and figure out what works best in OpenFlow will be part of that. I think, from my perspective, that seems to me to be one of the sources behind some of the terminology confusion. I hope today that that's getting a little better. I was just wondering if you saw similar currents over these past few years?
[Rob] Absolutely. It's worth going back to the article where the term SDN was first coined. I was actually interviewed for that article.
[Art] Yeah, yeah, the MIT Tech Review. I remember that one.
[Rob] Basically the thinking from the other side was, "Well it's a little bit like software defined radios because you can maybe change some of the networking things so I'll call it software defined networking." I always tell people the term started out imprecise and didn't really get much better from then.
[Art] That's interesting that you mention that because I have been thinking the opposite, right? Software defined radio access network - I thought they pulled that term from SDN, fascinating thing to learn.
[Rob] The thing that's a little bit confusing is that networking has always been about hardware and software in combination. If you look at how a router or a switch is made, there's a lot of absolute dedicated hardware there in terms of an ASIC or different types of forwarding memory and what not but there's also a lot of software. If you went to a traditional vendor and said, "Okay, we're now going to make the network software defined." They're like, "Well, we have a huge software team. We actually write a lot of software, what does that mean?" The definition that I like and the one that the ONS supports, and the ONS supports it based on that is there's actually a controller involved. There's a remote controller making and receiving calls down to the individual switches. What those RPC calls are, are they OpenFlow, is it OpenFlow like? I think that is almost an irrelevant implementation detail. That is the idea of providing some sort of abstracted view of the network via a hierarchy.
[Art] The interesting thing about that definition is, is I just wonder what is the line between management, automation, orchestration platform and a controller?
[Rob] There's a critical difference, I apologize if I get too technical. Much of those configuration things will actually say configuration parameters in the individual switches but aren't actually ... Those might indirectly affect forwarding decisions, whereas in my mind a controller actually affects the forwarding decisions directly by actually populating the forwarding memory directory. The analogy that I always make is if you look at a multi-linecard switch, these are the big iron boxes that everybody has. They almost always have a couple of supervisor modules, some linecards, and some fabric backplanes. If you look at the protocol between those supervisor modules and the linecards, there actually is a protocol inside that box for if a new route comes in, how do we program the linecards. I call that protocol closed flow because its just like OpenFlow, the supervisor cards are just like controllers. It's the idea that you could do this in at least a somewhat open way, that's the thing that's fundamentally different. It's not architecturally different, it is just that something that was closed is now open, that's the difference.
Sign up for MIS Asia eNewsletters.