Cisco Wants to Kill SDN - VirtualizedGeek Tech Talks Episode 5

10:37 · Watch on YouTube ↗

Transcript 1,485 words · about 10 min to read

Auto-generated captions from YouTube, not hand-corrected, so names and technical terms may be imperfect. The video is authoritative.

hi this is Keith Townson from virtualized Geek today is Monday March 18th 2013 you're listening to episode five of virtualized Geeks Tech talk this is the fifth straight week in a row that I've done virtualized geek Tech talk again the whole dozen you dozen of you that watch the podcast I'm extremely appreciative uh it seems like from the kind of a carryover from pot from the podcast or to the podcast from my blog has been the topic of uh software defined networking you guys seem to

not be able to get enough of software defined networking or whether I'm writing about it or even talking about it seems like those are the topics that you are most interested in uh outside of uh the lab stuff so tonight's topic is all about sdn uh few weeks ago I kind of post poed this topic on what I felt was Nirvana for Network as a service based on sdn Technologies so we'll continue a little bit of that conversation and talk about vwes uh NXX NSX project

or offering that will soon be released and sdn in general so kicking off the conversation let's talk a little bit about my kind of vision for sdn longterm sdn is a uh I think is a very exciting topic for the Enterprise if it can be used to deliver Network as a service network in a service not in any form that I've seen it so far so the basic concept is that you can get a gab bid access layer link let's say if you're in Kansas City

and you get Google Google Fiber you get the one gigabit connection to to uh the Google backbone having that one gigabit connection to the Google backbone then allows you to leverage sdn technology between different service providers to uh have the ability to have point-to-point Solutions within kind of a virtual Network or a um Network as a service offering I've talked to some of my peers about this and one of the questions I've gotten from them is what's the difference between that in just a regular VPN

well if you think about a regular VPN you're establishing a pretty much a unreliable Connection in the sense of quality service between two points over the Internet or some other network you really don't have any insight into the path that it's going to take and Hance the quality of service and the latency and everything that you will get in that connection so while it's a private connection while while it's a point-to-point connection it's a point to point connection with no quality of service now just think

if you could from your application or your data center control plane say that you want a uh 50 megabit connection from two points point a being let's say a remote office that has a Google Fiber connection and point B being your data center that obviously has a a plenty of bandwidth to accommodate that connection the application can request that connection a 50 megabit connection over that one gigabit transport and then put quality of service requirements around that saying that there should only be five milliseconds of

latency uh voice should have this priority over whatever priority within the physical Network and now you have a point to connect Point connection with a quality of service that can be brought up and torn down as just like in the case of a VPN but with much more control so that's kind of uh Nirvana for me when it comes to sdn and network as a service there's some challenges in that because what really has to happen is that from uh the providers from Google all the

way to the providers on the other end of the network have to agree to honor the sdn control controls between the two points so when the application makes the connection request all these vendors have to come together and agree to uh those qu those terms of service or quality of service requirements for the connection and then on top of that billing needs to take a take place how does the trans how does that trans Network traffic get builded and how do vendors get compensated for t

tring carrying that traffic with those specific quality of service attributes ideally um it would be you know a similar to Rackspace providing you a cloud service Rackspace could CL provide you uh well similar to rack space providing you a cloud compute service Rackspace could provide you a network as a service uh offering that also takes care of all that behind the scenes building and as you as a customer from the front end you have one throat to choke and one contact for managing all those different

relationships that's kind of networking n n Nirvana but the question is how do we get there from where we're at today uh right now you have vendors like Cisco Cisco just recently published an article I'm sorry uh there was Network world just recently published a blog post talking about how Cisco is a little bit reluctant to that uh softwar defined networking model that's been preached that programing programmable control plane that gets removed from the hardware and gets put into X potentially x86 virtualized data centers if

you have VMware have their say to it versus on the traditional uh 6509 Nexus switch whatever Cisco selling at that date Cisco's approach according to the network world are would be to uh have programmed networks based on uh either existing protocols or to be developed protocols so in that scenario you'd have that same control but instead of the control plane being some uh plane that's run on within your data center Cisco's Network or Cisco software defined data I'm sorry mware softwar defined data center for example

it would be across your traditional Cisco gear that just has apis into the network and you can create those similar connections but the vendor relationship is much different I got to thought thinking about this for a little bit and I thought well you know what what's the stop sdn a true sdn deployment from leveraging that capability if you think about it it's still that programming API is still a offering that's controlled by the hardware or provided by the hardware sdn abstracts all of those features away

from the hardware and allows you to uh have uh make calls into your control plane which then communicates with the networking equipment so I don't think Cisco is really deterrent from a true sdn Network I think it's just a uh a possibility for Cisco to kind of s rail the sdn movement and allow them to use their leverage to continue to control the the Enterprise data center if they can get enough customers to believe in that programming API and to their Hardware based control planes you

know what why why change why Why move to s end if I'm getting all that functionality out of my existing uh Cisco gear or my existing relationship with my Enterprise networking vendor so that's kind of the Cisco angle and then we have the VMware angle with their NSX uh project again uh more of the same from kind of the Nera Network world that we've heard the past couple of years which is basically to create a x86 based control plane that allows you to interface with your

network via some centralized control plane and then have the uh physical control plane at the hardware level Cisco announced I'm sorry VMware announced their NXX platform which is pretty much the foundation of the model which has the five different layers which we're more importantly concerned with tonight is that control plane so those are the two different approaches the Nirvana that I want to achieve one day and where the market is today you know what today we're still buying Hardware we're still dealing with bgp we're still

dealing with uh errp we're still dealing with all these protocols right at the application um dated one at the at at the data center layer and someday we'll move away from those protocols may still be in the background but from data center providers perspective we will no longer uh care about that stuff and we'll just care about being able to make the calls uh make the connections to the endpoints that we want with the type of security with the type of quality of service and with

the type of latency that we require for our applications that's another episode of virtualized GE te Tech talks strictly on sdn hope you guys enjoy enjoyed it hope it stimulates a lot of conversation within the blog talk to you guys next week thanks