Maybe we should say that everything old was renamed again, or perhaps that all the old names were given to new things. Scott Raynovich’s piece in Fierce Telecom makes that point; SDN and NFV won’t die but just rise as different (perhaps totally different) concepts under the same name. He also says SD-WAN is the sort-of-fusion of the concepts, reborn. It makes sense, don’t you think? You get something that garners great ink but (shall we say) falls short technically, and as the faults become clear and solutions are proposed, the old stuff rises from its ashes because the name is recognizable. Or we rebuild a new concept from the old ones.
Well, maybe that’s a bit cynical in this particular case. There’s no question that SDN was a launch point for almost everything that’s really new in networking. It was the first technology that aimed at giving us services of old without infrastructure of old. You could argue that stuff like P4, the flow programming language, evolved from the concept. NFV was arguably the launch point for the notion that a network could be created by deploying feature instances on generalized hosting resources rather than by connecting purpose-built devices. Combining the two gives us a model of virtual networking, something useful even if the details of SDN and NFV have proved lackluster.
What about SD-WAN? The term, I think, was totally opportunistic. As the market inevitably applied the SDN term to things further from the original SDN concept, it eventually swept into the WAN space, where it met overlays. We’ve had overlay networks for literally decades, and the first real virtual network models from companies like Nicira were really not SDN as they claimed, but overlay networks. SD-WAN implementations are, like Nicira, generally based on an overlay concept. But there are a few (perhaps three) SD-WAN vendors who actually do virtual networking, who actually build network-as-a-service connectivity.
What’s behind all of this, the common thread? Separation. SDN was designed to separate services from traditional adaptive infrastructure used in IP networks. NFV was designed to separate network features from purpose-built devices. SD-WAN was designed to separate the service of connectivity from physical networks, from transport connectivity. In a way, what we’re seeing is not a convergence on SD-WAN but a convergence of goals. If you can define “separation” as a goal, of course.
Why would we want it? The answer is that physical networks constrain us. Boxes fail, or get overloaded, and so do trunks. Addresses that are based on a global system aren’t always suitable for local needs, particularly when those addresses are linked to a specific physical place, a network service access point. We, in the Internet age, are increasingly non-physical, virtual. An application is wherever it runs, we’re whatever device we choose at the moment. Relationships of two totally elastic things aren’t well served by fixed networks.
The question, perhaps the big question, is not whether separation is good, but whether we’re separated enough. We still have IP addresses, and we’ll have them in future virtual networks that don’t have a shred of IP functionality as we’ve come to know it. We’ll probably call feature instances that provide connectivity “routers” even if most of the code that’s currently found in routers isn’t inside those instances any longer. Can we really be virtual with one of our feet still in the physical, the IP, world?
The big question for all of us in networking is whether “virtual networking” is an end, or maybe it’s just a step toward the ultimate goal, which we could call “logical networking”. Think about it. I’m connected to an IP network as I write this, and when I post it, I’ll be using the Internet, as will those of you who read it will do when you access it. But do you know your IP address, or the IP address of my blog site? It’s possible to find both, but I’m pretty confident that the great majority of Internet users would have no idea how to do that, or what those addresses even mean. Fewer would know anything about the protocol we call “TCP/IP” or the header fields and message formats.
My point is that we’re really not consumers of IP by choice, we’re consumers of logical networking that we’ve mapped to IP because IP happens to have been in the right place at the right time. When business networking got really hot in the early ‘90s, it had evolved for most enterprises on IBM’s System Network Architecture (SNA). SNA had “nodes” that did “routing”, which they called “PU Type 4” nodes, big boxes as large as a rack of servers, costing a hundred grand or more. A smug little Silicon Valley company named “Cisco”, who we all knew as a character in a TV western whose companion was named “Poncho”, offered these router things that cost a tenth as much and could move as much traffic. The rest is history.
The Internet itself evolved from a combination of the invention of the notion of hypertext formatting, the TCP/IP protocol from the defense/university world, and the need of telcos to come up with some reasonable way for regular people to consume data services so they could use up the bandwidth that things like optical transport were creating. But SNA and the Internet are just carriers for the logical networks that we really wanted.
You want to read an online resource like this blog. You want display text, and you neither know nor care what kind of magic transports that text to you from wherever it happens to be hosted. That’s the start of everything, and that’s the end-game for our separation, I think. We’re going to eventually be not only transport independent, device agnostic, and open-modeled, we’re going to be oblivious to all of that stuff at the technical level, because we never cared about it at the point of use, and never will.
Transport resources and data formats are matters of negotiation, just like a group of multi-lingual people will find a common language for a discussion. A connection is an information relationship that exchanges information in the format it needs to be in, over something we shouldn’t be caring much about.
A logical network isn’t about protocols, but rather about discovery and negotiations. We find what we want, and we negotiate for it, not only for the rights to acquire it (pay TV) but also for the framework that will be used to deliver it. Or, rather, our systems will negotiate that, because you’ll recall that we don’t care about the plumbing.
The real innovation of SD-WAN, in at least some of its implementations, is that it’s a step toward the logical and not the physical. A user is not an IP address, they’re a person. An application is an information resource. The first step to a true future, the ultimate degree of separation or freedom in networking, is to stop talking about people and resources like they were network elements. They are who we are, or what we want. The rest is plumbing.
SDN didn’t make that connection. NFV didn’t make that connection. Not all of SD-WAN has made it either, but you can find some SD-WAN products that have taken that first critical step. That, to me, means that SDN and NFV aren’t somehow fulfilled in SD-WAN, but that SD-WAN has finally relegated them to the place they belong—the dustbin. They’re aspects of the mapping of logical to physical, accommodating what’s now available while we prepare for what will come.
It’s that future we need to be thinking about. Virtual IP networking is still constrained. Logical networking inevitably will shrug off constraints, and so it’s very important that we understand the difference between the real goals of connectivity and the artifacts of our implementations. We’re starting to separate the two, starting to break out of the mold, but until we start with the goals and build in the direction of negotiating and accommodating, we don’t have a structure that can evolve because we don’t have one that fits the mission at the top, where we and our resources all connect.
Do you want your vendors to be visionaries, or plumbers? See where they stand on these points and you’ll have your answer.