& cplSiteName &

SDN's Killer App: More Network Control

Phil Harvey
The Philter
Phil Harvey
3/21/2013
50%
50%

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

(15)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 2   >   >>
dwx
50%
50%
dwx,
User Rank: Light Sabre
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
50%
50%
mark-r,
User Rank: Light Beer
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
50%
50%
dig_deeper,
User Rank: Light Beer
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
50%
50%
Phil Harvey,
User Rank: Light Beer
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
50%
50%
febi85,
User Rank: Light Beer
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
50%
50%
Parsimony in Networking,
User Rank: Light Beer
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
100%
0%
Parsimony in Networking,
User Rank: Light Beer
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
50%
50%
Parsimony in Networking,
User Rank: Light Beer
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
50%
50%
buraglio,
User Rank: Light Beer
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
50%
50%
dig_deeper,
User Rank: Light Beer
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   >   >>
More Blogs from The Philter
There's an interesting tension between how much SDN can benefit service providers and how it could threaten their established businesses
OneAPI may provide developers a reason to build apps and content for networks, not just mobile operating systems
Ericsson CEO Hans Vestberg defends his company's managed services deals and says he'd rather invest in R&D than make expensive acquisitions
Use our message boards to share photos from your Barcelona experience this week
Featured Video
From The Founder
Light Reading founder Steve Saunders grills Cisco's Roland Acra on how he's bringing automation to life inside the data center.
Flash Poll
Upcoming Live Events
February 26-28, 2018, Santa Clara Convention Center, CA
March 20-22, 2018, Denver Marriott Tech Center
April 4, 2018, The Westin Dallas Downtown, Dallas
May 14-17, 2018, Austin Convention Center
All Upcoming Live Events
Infographics
SmartNICs aren't just about achieving scale. They also have a major impact in reducing CAPEX and OPEX requirements.
Hot Topics
Project AirGig Goes Down to Georgia
Dan Jones, Mobile Editor, 12/13/2017
Here's Pai in Your Eye
Alan Breznick, Cable/Video Practice Leader, Light Reading, 12/11/2017
Verizon's New Fios TV Is No More
Mari Silbey, Senior Editor, Cable/Video, 12/12/2017
Ericsson & Samsung to Supply Verizon With Fixed 5G Gear
Dan Jones, Mobile Editor, 12/11/2017
Juniper Turns Contrail Into a Platform for Multicloud
Craig Matsumoto, Editor-in-Chief, Light Reading, 12/12/2017
Animals with Phones
Don't Fall Asleep on the Job! Click Here
Live Digital Audio

Understanding the full experience of women in technology requires starting at the collegiate level (or sooner) and studying the technologies women are involved with, company cultures they're part of and personal experiences of individuals.

During this WiC radio show, we will talk with Nicole Engelbert, the director of Research & Analysis for Ovum Technology and a 23-year telecom industry veteran, about her experiences and perspectives on women in tech. Engelbert covers infrastructure, applications and industries for Ovum, but she is also involved in the research firm's higher education team and has helped colleges and universities globally leverage technology as a strategy for improving recruitment, retention and graduation performance.

She will share her unique insight into the collegiate level, where women pursuing engineering and STEM-related degrees is dwindling. Engelbert will also reveal new, original Ovum research on the topics of artificial intelligence, the Internet of Things, security and augmented reality, as well as discuss what each of those technologies might mean for women in our field. As always, we'll also leave plenty of time to answer all your questions live on the air and chat board.

Like Us on Facebook
Twitter Feed