x
SDN architectures

Two Stray Thoughts About Cisco & SDN

SANTA CLARA, Calif. -- Ethernet Technology Summit -- During the past two days of sessions here, two interesting points came up about Cisco Systems Inc.'s relationship to software-defined networking (SDN). 1. Cisco isn't necessarily the "bad guy" in SDN. Peter Christy, an analyst with 451 Research, brought this up during a panel I moderated Tuesday morning. When you talk to the OpenFlow pioneers, they often get into a rant about the proprietary nature of network equipment. They've got a point. The network stands in the way of progress sometimes, because it can't be programmed easily. But in a way, that's everyone's fault, "everyone" meaning the community that developed the Internet during the past few decades. The Internet's strength is that there's no one overseeing mechanism. As long as you follow the routing rules, you can add whatever-it-is-you've-done to the Internet and talk to the world. Specifically, there's no centralized configuration mechanism. It's that lack of standardized management and configuration that's now starting to be an obstacle. I don't think that's something to be sorry about. It's the tradeoff we face for the distributed nature of the Internet, and it's only now starting to get in some people's way. Having said that, I do think some network operators wish they could do away with Cisco certifications and the like. 2. Here's a compelling argument against the commoditization of hardware, as presented Wednesday by David Yen, senior vice president of Cisco's data center business. He believes switches will continue having a control plane, even in cases where SDN centralizes that function. Think of it like a backup -- like the police who get deployed when a stoplight goes out, he said. Deploying police is not as scalable as deploying stoplights, but the police are nice when big exception cases come up (such as the traffic that'll pour into that San Francisco 49ers stadium, right near Cisco, on certain Monday nights). So, the control plane can stay in the switch. "But now, the control plane needs to go beyond the sheet metal ... so that the application can interject its characteristics and the user can inject [his/her] business objectives. Then the two control planes can cooperate [to determine] who's best to do the job." I'm not sure that's what most people have in mind when they talk about separating the control and data planes, but it's a believable outcome for SDN and another argument against white-box switches taking over the world. (See Big Switch Fuels Ethernet Revolution.) For more — Craig Matsumoto, Managing Editor, Light Reading

HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE