We’re obviously not going to get to the network of the future by having some pretty genie wiggle her nose to create an instant transformation. No matter how radical things like the cloud, SDN, and NFV might be in the end-game, they’re going to get to that point one small step at a time. Most enterprises and network operators believe that legacy technology will still dominate networks in 2018, in fact. Which means we need to be thinking about how you introduce new technologies in a way that works both financially and technically.
Nearly everyone who looks at this problem, including everyone who has actually faced it, believes that the answer is domains. We’re going to have little enclaves of new stuff that will appear in the midst of the old-model technology, and these will increase in number and size over time. It’s likely this model will in fact prevail, but it generates some questions that have to be addressed quickly or our evolution may end up stalled in a drying puddle somewhere.
The primary reason for a domain model of network evolution is the fact that a given network technology is likely to develop its benefits unevenly and present uneven cost gradients. That means that there will be places where cost is modest, benefits are high, and so ROI is strong. That’s where something new can be done. Nearly everyone believes that SDN will start in the data center, for example, because the cost/benefit relationship is better there.
When you have a domain model, you introduce the natural issue of interworking, which is different from “federation” because it is aimed at making “in-network” cooperation work between domains rather than in codifying their separation. Looking at the interworking angle you quickly see a logical substructure of the domain model emerging, with some interesting alternatives to be addressed.
If you view a network as a connected set of domains you get a picture that’s not unlike the model of IP networks where we have subnets (within which one set of connection rules apply), AS domains, and networks. Each of the domain types has a boundary condition and a mechanism for communication within themselves. As a baseline, it would be logical to assume that services based on SDN would be applied in domains that map to IP network domains today, and that is in fact happening with datacenter SDN and with Google’s core-SDN model.
This kind of domain model is good, evolutionarily speaking, because the domains are selected in part to preserve the interconnection rules of the legacy network you’re evolving away from. We have things like default gateways, OSPF, and BGP already, so what we end up with is a set of “new” domains that look like old, traditional, ones at the edges. This means SDN (or NFV, or other) domains might be considered abstractions, black boxes. We virtualize our networks going forward by creating new models for what’s inside existing black boxes.
This approach works pretty well when new domains are sparse, but as the plot thickens, domain-wise, you end up with a potential issue. Imagine for example that we have two SDN-based domains adjacent to each other. Traffic that moves between them could still be represented through the old interdomain model, but if these new domains have other capabilities you’d like to be able to consider them to be logically fused in at least one sense. Yes, you could actually fuse them (presuming they were from the same owner) but for ownership reasons and because some traffic might not be able to take advantage of new-age SDN-driven connection models, you’d probably not do that. Instead you would create what was effectively a second domain model that extends the old one and runs in parallel. In protocol or API terms, the boundary conditions and exchanges of this new model are a superset of the older interworking model. But you might want to do the same thing if you had traffic that was traveling over legacy domains between two new SDN domains. Why not pass along some SDN-centric stuff?
The point here is that while the current SDN vendors haven’t made the case for their decision very well, the fact is that there’s a good reason to extend existing protocols like BGP to carry SDN-specific information as a step toward SDN. My gripe with these guys (Alcatel-Lucent, Juniper, for example) is that they need to do a better job of explaining what the new interworking model or models might be. Show me the future before you evolve me into it and it takes me by surprise, a buyer might think.
If we presume that there’s an SDN controller involved in all of this, we could visualize the new interworking models as being created among controllers, since the controller understands the connectivity rules of its domain(s). Controller federation is then an evolution of traditional internetworking, one that is promoted more as SDN domains expand (in number, size, or both) or as new service models are created within domains that can’t easily be exploited across domains using legacy interworking rules. At some point, this likely creates a situation where a supercontroller owns all the controllers in all the domains and acts as a mediator for interworking exchanges.
I’d like to see vendors talk about this structure explicitly and apply it to their own SDN solutions, because I think we need a common model. Right now that’s not happening, so there are things everyone needs to be demanding relative to SDN implementations.
You might wonder how NFV fits into this. In my view, you can visualize NFV as being either an extension to the current domain interworking model, a domain within that overall model, or a new layer. If SDN connectivity is applied end-to-end (overlay SDN) and it’s universally available, then SDN could create a connectivity fabric that has essentially no topology. Anything can go anywhere in an overlay network (as long as some “underlay” goes there). With NFV or even with hosted switching/routing, you can host nodes where you like which means you can build layers of virtual topology on top of the real infrastructure and within that topology apply any set of connection and interworking rules you like. You can add features by making them virtual elements of all of this. If the scope of SDN is universal then the range of the virtual NFV model is likewise; otherwise it becomes another domain enclave in a legacy sea.
I think it’s clear at this point why we need to think about all of this stuff at a higher level. This is a pretty interesting model and one that could let us enjoy more SDN benefits even when “infrastructure” SDN doesn’t have full play yet. It’s also a model that doesn’t require SDN, or OpenFlow, to work, only overlay networking and virtual network elements. That gives us another set of options to sort out as we try to visualize what the future of our new technology waves might be.
