Understanding SDN with Cisco Domain Ten
Network switches and protocols aren't the only thing those looking to implement should be concerned with, wrote...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Cisco's Stephen Speirs on his company's blog. Instead, implementing and working with SDN -- and Cisco ONE, Speirs said -- should impact multiple areas of the network, including services such as technical support and consultancy.
Speirs explained SDN in terms of Cisco's Domain Ten, the company's service framework guide. In his blog post, Speirs applied each domain to areas of SDN implementation, including automation and orchestration, security and compliance, and software applications. Cisco Domain Ten, unlike competitors' service frameworks, Speirs said, gives users an analysis of new technology, like SDN, and the challenges that accompany it. Using the framework allows for a broader look at SDN challenges, he said, which is often missing from today's SDN discussions.
Take a look at Speirs' application of Cisco's Domain Ten to an SDN implementation and how SDN challenges are explained within this framework.
With SDN security, focus on the basics
There are two ways to look at SDN and security: how SDN can enable better security and how to secure a software-defined network. To delve into the two areas without getting wrapped up in the "insecurity" of SDN, Jennifer Ellard, Hewlett-Packard's director of product marketing wrote on the company blog that it's best to stick with the basics.
SDN doesn't pose more risk than a traditional network architecture, Ellard said. Instead of fearing what security issues may happen as a result of the new technology, networking pros must recognize that the security of a network is influenced more by the "posture" of the company implementing SDN rather than the architecture itself. Security best practices should also be reviewed and applied when implementing SDN.
Review Ellard's full post for tips on sticking with the basics when it comes to SDN security.
Can stateful, OpenFlow-based network services be implemented in hardware?
That's the question Ivan Pepelnjak answers in a post on his IP Space blog. Pepelnjak explored how realistic it is to implement these services by proposing a scenario that includes Web applications hosted in a data center with a 10 Gigabit Ethernet WAN uplink. Using a series of questions and breaking down a number of facts, Pepelnjak concluded that although OpenFlow has its uses, large-scale stateful services aren't one of them.
Check out Pepelnjak's full analysis of why OpenFlow-based network services can't be implemented in hardware.
Why SDN and OpenFlow aren't one-and-the-same
Although OpenFlow continues to be the favorite southbound protocol among SDN users, it shouldn't be looked at as synonymous with SDN, wrote DevCentral blogger Lori MacVittie. Both the application programming interface and the architecture -- OpenFlow and SDN -- offer separate benefits. For example, organizations looking for automation and management benefits could opt for an OpenFlow-based management framework without adopting a full SDN architecture.
However, MacVittie added that OpenFlow lacks scope and there are a number of reasons why OpenFlow may not be the southbound protocol to use with SDN. The fact that OpenFlow doesn't address Layers 4-7 poses a problem, she said. As SDN matures, MacVittie predicted we'll see more changes to "core assumptions" on which the architecture was based that will require adaptation.
Read MacVittie's full post on why SDN and OpenFlow aren't interchangeable.