Light Reading has reported that on one of the OFC panels, both vendors and operators expressed concern about the “hype” and even the number of standards bodies associated with SDN. You all know my view about hype and any new technology; we seem to live in a “bandwagon” age where anything that has momentum gets more support and attention. That breeds the “piling on” notion that many in the industry believe is creating problems for us all.
Any group of people tends to acquire a kind of self-preservation mindset, and if you happen to be your company’s representative on the HotOpticalForum, you’re probably always casting about to find new and publicized things for that group to do. Not only does this create a lot of competition and collision among bodies, it also often introduces topics or issues in a way that’s far from constructive, and sometimes buries issues that are important. Some examples from the current OFC event are helpful here.
We’re hearing a lot about the integration of SDN and optical, usually in the form of integrating OpenFlow and optical. The framework for this is a set of optical enhancements to OpenFlow that allow a forwarding rule to be defined as a pairing of port/wavelength combinations. OK, I admit that you could use this to cross-connect optical paths, but what about TDM (no wavelengths there) and in any case aren’t we already interconnecting optical using everything from TL1 to GMPLS?
Why use OpenFlow here? There is no “forwarding table”, no mask-and-match process. When a packet arrives at an OpenFlow switch and finds no forwarding rule, it can be kicked to the controller for handling instructions. We can’t kick a wavelength to a controller and we can’t examine the contents for insight either. Optical cross-connect is also much more likely to be determined by transport policy than by application needs. You can let an application control a VPN but not your underlying fiber network; you can imagine what chaos would result from sharing control of resources that support multiple applications, services, and users.
Then we have service chaining. About half the SDN aficionados think that “orchestration” in NFV can be done by SDN. Wrong. SDN could be used by NFV to make connections in a service chain, but so could any sort of tunneling protocol. Most chaining-dependent services are business services with long-term contracts. If we wanted to create a chain of software elements on which to base such a service today, in any Ethernet or IP network, we have the tools already. No SDN need apply. I’m not saying that SDN couldn’t do the job, but that it’s not necessary for the job, and to drive SDN deployment it has to add something to what we already have.
One specific comment in the LR piece that I particularly empathize with is the one that says we’re focusing so much on “northbound” and “southbound” APIs for SDN controllers that we’re forgetting about “east” and “west”, meaning inter-controller or SDN federation. Federation is important because SDN domains can’t be enormous or current technology limits on performance and availability for central controllers will be hard to accommodate. You’re likely to have a bunch of SDN domains, much as you have IP subnets. Are subnets in the IP sense a suitable SDN federation strategy? If “Yes!” then we need a controller per subnet. Does that make cost and management sense? If “No!” then we need to know what we think links SDN domains.
But the big question raised by all of this is management. Yes, you know that there’s no shortage of standards groups looking at “SDN management” but let me assure you that there’s a fundamental disconnect because we don’t have an SDN management problem. We have a management problem, period. Network and service management practices and processes are unsuitable for the current notion of what a service is and how that service is created through a community of cooperative resources. There is a critical need for a top-down approach to network and service management as a category. That approach should decompose management practices down to the level of service/network technology, and that’s where the notion of SDN management rightfully belongs.
OK, who among all the alphabet-soup-united-nations collection of management bodies is responsible for this? We have “liaison” between the bodies but the fact is that a given body tends to be assigned a role by virtue of being there first. I’d argue that the TMF is the right place to build these high-level standards, but what happens if new lower-level technologies evolve and the TMF hasn’t put a high-level model in place? We then have a high-level model evolving in a way that’s either constrained by piece-part thinking or we have a high-level model that does everything it needs but doesn’t work with any of the technology choices coming online.
The biggest casualty of the multiplicity of standards is the top-down approach because it’s never clear who’s supposed to be at the top. And without top-down definitions of what a network service is, what a resource pool is, what a management model is, we have absolutely no clear path to connect network evolution to an optimized business case, and therefore we have little chance of making our revolutions as big and powerful as they could be.