SDN architectures

SDN's Killer App: More Network Control

ANAHEIM, Calif. -- OFC/NFOEC 2013 -- Everyone here has a software-defined networking (SDN) story. They all seem to point to a future of simpler networks that, with the help of virtualization, are much easier to control. But how hard will network equipment vendors really work for that goal when they have huge installed bases of routers and switches to protect? The status quo for those firms commands bigger margins now than if all or part of their networking functions were suddenly being handled on standard servers. Stanford University professor Nick McKeown says a lot of the vendors that say they're on board with SDN are only adding more code to support SDN-like interfaces and functions to specialized control planes inside of vertically integrated, proprietary routers and switches and gateways. In the hallways, after his plenary talk here, he was even more fired up. "I'm feeling sorry for the service providers who have to wade through that garbage," McKeown says. SDN, if done correctly, doesn't change the functionality of the network -- it moves those functions around. And, when the transport network's control and forwarding plane are separated, innovation can happen more quickly and less expensively, McKeown says. When I pressed him for a real-life application that could be the result of the simpler networks that SDN promises, he didn't disappoint. "You know how you have network neutrality now," he asked. "What if the customer could flip it around and tell the service provider: 'I'd like to give preference in my home network to Netflix.'" It would be interesting to see a service provider offering its network as a service and trusting its customers to provision network tasks via some portal or app that controls some virtual abstraction of its physical network. Indeed, it'd be nice to be billed for what you provision and use on that network, not just for the privilege of connecting to it and hardly using it. The general idea of a more services-oriented and software-defined telco is appealing. Some optical networking vendors here are getting on board with discussions to see how SDN-enabler OpenFlow will work in optical networks. McKeown, in his plenary presentation slides, says that SDN will get to simpler, more innovative networks, but first the big router and switch makers have to agree to get out of the way: "Networks will be in service of the owner, the operator, the customer and the application rather than just the high-margin vendor." — Phil Harvey, Editor, Light Reading
Page 1 / 2   >   >>
dwx 3/22/2013 | 5:14:35 PM
re: SDN's Killer App: More Network Control I agree. -áA provider I worked for allowed customers to change their WAN Frame-Relay BW via a web portal 8 years ago now. -á It also allowed Ethernet connected customers to turn up new VLANs between sites within a pre-built VPLS. -á Of course this required proprietary tools to do so, but I don't think that changes with OpenFlow at all. -áAre service providers going to allow a customer to turn up a pipe to Netflix at a whim which then provisions network resources on intermediate devices? -áUnlikely. -á And that isn't even bringing in security ramifications for devices which carry sensitive traffic like PCI data, which they do today. -á
mark-r 3/21/2013 | 10:59:32 PM
re: SDN's Killer App: More Network Control Network as a service a new thing? What would you call, say, a classical wide-area-network (WAN) service by a network service provider to a multi-sited enterprise or ASP customer, to connect the customer's sites (offices/data centers/POPs) and external network access points? What new does SDN/OF enable?

E.g. if the classical WAN service is packet-layer transparent, the customer equipment (whatever they are, even custom built) will be in full control of the WAN service. The network SP does not need SDN/OF for that. How the customer manages its own systems interconnected by the WAN service is up to the customer (within what is supported by the customer premise technologies, which, as mentioned, can even be proprietary if needed).

What we need is better service layering architecture, not more control by itself or new protocols (much can be accomplished by less rigid, smarter use of existing protocols).
dig_deeper 3/21/2013 | 8:31:05 PM
re: SDN's Killer App: More Network Control Parsimony, if you read my comment again, you will see that I referred to OpenFlow and how Nick and team advocated so much for OpenFlow as the savior and driver for capex reduction for top of the rack and other switching and routing equipment. -áThats was a big mistake.

Openflow would never be able to provide that capex reduction value proposition that got pitched by them for many years and drove ridiculous an wasted R&D investments on OpenFlow.-á
Phil Harvey 3/21/2013 | 8:18:17 PM
re: SDN's Killer App: More Network Control -áThat's why I'm careful to point out that even though folks are discussing SDN, what they're really talking about is the idea of service providers being able to offer the network as a service. That's not happening now but it could, as you point out.
febi85 3/21/2013 | 7:49:29 PM
re: SDN's Killer App: More Network Control Verizon uses ForCES and it deployed in the field. I agree it has less interest, but some showing interest to it and many turning towards it,
Parsimony in Networking 3/21/2013 | 7:46:17 PM
re: SDN's Killer App: More Network Control Nice association fallacy, but ultimately spoken like someone who hasn't actually thought much about this problem, and who certainly hasn't actually implemented one of these protocols. -á:)-á

No I don't think that the ~20 RFCs that make up the core internet protocol suite are simple, especially in composition. -á-á

But that doesn't make abstract-ámodeling-á/ negotiation of arbitrary forwarding hardware any simpler either.-á
Parsimony in Networking 3/21/2013 | 7:35:54 PM
re: SDN's Killer App: More Network Control dig_deeper: -áI'm not sure I agree that Nick has pointed the "whole industry in the wrong direction". -áI do believe that SDN in general and OF specifically,-áshoddily-ádesigned protocol that it is, are ENORMOUSLY over hyped. -áI also think it's likely that OF will, after the bubble bursts (or gradually deflates), be relegated to the protocol graveyard along with COPS and GSMP.-á

Having said that, I think that Nick, or rather, Scott and Nick, have opened up a very interesting area of inquiry. -á

Saying that OF is the one SDN protocol to rule them all, and the ultimate culmination of the SDN concept, is obviously ridiculous (I put this down to an aggressive ONF marketing campaign; that IS what they do after all). -áSaying that SDN itself has no value is almost equally absurd.
Parsimony in Networking 3/21/2013 | 7:26:00 PM
re: SDN's Killer App: More Network Control Interesting... -áAs much as I like the people who work on ForCES, and believe that their design is more mature than OFs, they have zero vendor adoption AFAIK and almost no customer interest. -á
buraglio 3/21/2013 | 7:11:00 PM
re: SDN's Killer App: More Network Control The ONF isn't *totally* transparent. -áFollowing the WGs is much easier but even then that is not enough. -á"Vendor agnostic forwarding abstraction is all OpenFlow is." is one of the most elegant descriptions of OpenFlow I've heard, ever. -áThere are certainly ways to accomplish many of the tasks but most of those-ámechanisms, while possibly well documented,-áare clunky at best. -áProgrammatically-áadapting the network in a proactive manner is one of the huge advantages that OpenFlow brings to the table and large entities are going to embrace it. -áMaybe not now, but they will. -á-áIs it scary to the network vendors? -áAbsolutely. -áWas it productized too early? -áMaybe. -áIs it going away? -áHighly doubtful.-á
Was dynamic routing scary when it was originally deployed? -áYup. -áNow it's the norm. -á
dig_deeper 3/21/2013 | 7:06:24 PM
re: SDN's Killer App: More Network Control Brent, Please enlighten us why only a "vendor agnostic" solution is required to -áprovide on-demand bandwidth for netflix, as asked by you? -áYou are confusing two different things. -áTo provide on-demand bandwidth for netflix, you simply need a programmatic way to configure the existing network equipment. -á -áIt's a network orchestration problem, and there are practical ways to accomplish it.

If configuration level APIs are provided on top of existing equipment, it provides the agility of quick re-configuration and programmability. -áWith open REST APIs available, the orchestrator can be from a 3rd party, making the automation and orchestration piece "vendor agnostic"The "vendor agnostic" argument for Openflow is what people use for cost reduction of networking equipment, which is close to hallucination.-á
Page 1 / 2   >   >>
Sign In