SDN - Killer Apps
Hi, I am trying to understand how SDNs can dramatically change the networking paradigm and this is my understanding. Yahoo, Google, etc applications are running on one server and each application could be theoretically associated with a unique VXLAN tag. This way service providers will be able to provide QoS per application (by effectively providing QoS to the VXLAN carried in the pkts). So now Youtube for example, can get unique QoS treatment from our desktops to the edge of the network. Form there on core routing will pick up - which remains largely unaffected by VXLANs. OpenFlow is useful because it provides a common CLI/SNMP with which all routers from all vendors can be provisioned and monitored. As an example, VPLS configuration in Juniper, CIsco and AlaLu routers will be very different. So, provisioning a VPLS service in a network that comprises of these 3 vendors would require the admins to know the CLIs of all these routers. If these routers support OpenFlow, then theoretically, one configuration would work on all routers. OpenFlow would like say Provision a LSP and each router will internally provision an LSP. The admin remains oblivious to the internal CLIs of these boxes. The SDN controller is a SW that can again theoretically be made aware of the entire network. It can look at SNMP traps, etc and can figure out the exact topology of the network. Based on the SNMP traps, messages it can determine all failures in the network. It can run routing protocol simulations and figure out the best topology in the network. This can, using OpenFlow, be programmed on all routers. So, all heavy CPU processing task is taken over by the SDN controller. The controller can also take in requests on what network aware applications require and feed that to the routers/switches in the network and thus you have an application aware network provisioned. I understand that this is just some bit of what we can do with SDN. The amount of what all can be done is limitless. So, a question to all out there - Is my understanding of what can be achieved with SDN, is correct? Glen
Re: SDN - Killer Apps
Le 2013-02-25 09:23, Glen Kent a écrit : Yahoo, Google, etc applications are running on one server and each application could be theoretically associated with a unique VXLAN tag. This way service providers will be able to provide QoS per application (by effectively providing QoS to the VXLAN carried in the pkts). So now Youtube for example, can get unique QoS treatment from our desktops to the edge of the network. Form there on core routing will pick up - which remains largely unaffected by VXLANs. Uh? I'm pretty sure that QoS is *not* SDN's killer app. Simon
Re: SDN - Killer Apps
On (2013-02-25 13:53 +0530), Glen Kent wrote: I understand that this is just some bit of what we can do with SDN. The amount of what all can be done is limitless. So, a question to all out there - Is my understanding of what can be achieved with SDN, is correct? Frankly I don't think there is single answer. From my point of view I don't see much use for it as general purpose SP. Already second most common reason to outage is software defect, SDN will just reduce software MTBF and can potentially break lot really fast. I don't want to run some HP OV SDNd magic black box process deciding what happens to the network and I don't have the resources (or motivation) to custom develop the software. For researcher it seems really invaluable, you can test new protocols in real equipment. For GOOG/FB et.al. I can also see value, as I imagine their software stack is already very specialized, very home-grown. SDN can allow them to tie in network to their current VM/service orchestration tools, essentially making sure network and services share synchronous view of what should happen. -- ++ytti
Re: SDN - Killer Apps
On Mon, Feb 25, 2013 at 3:23 AM, Glen Kent glen.k...@gmail.com wrote: Yahoo, Google, etc applications are running on one server and each application could be theoretically associated with a unique VXLAN tag. This way service providers will be able to provide QoS per application (by effectively providing QoS to the VXLAN carried in the pkts). So now Youtube for example, can get unique QoS treatment from our desktops to the edge of the network. Form there on core routing will pick up - which remains largely unaffected by VXLANs. OpenFlow is useful because it provides a common CLI/SNMP with which all routers from all vendors can be provisioned and monitored. As an example, VPLS configuration in Juniper, CIsco and AlaLu routers will be very different. So, provisioning a VPLS service in a network that comprises of these 3 vendors would require the admins to know the CLIs of all these routers. If these routers support OpenFlow, then theoretically, one configuration would work on all routers. OpenFlow would like say Provision a LSP and each router will internally provision an LSP. The admin remains oblivious to the internal CLIs of these boxes. The SDN controller is a SW that can again theoretically be made aware of the entire network. It can look at SNMP traps, etc and can figure out the exact topology of the network. Based on the SNMP traps, messages it can determine all failures in the network. It can run routing protocol simulations and figure out the best topology in the network. This can, using OpenFlow, be programmed on all routers. So, all heavy CPU processing task is taken over by the SDN controller. The controller can also take in requests on what network aware applications require and feed that to the routers/switches in the network and thus you have an application aware network provisioned. Glen Hi Glen; You've got a bit of buzzword bingo going on in those three paragraphs... Perhaps I can steer you in the right direction by categorizing and pointing you to some search topics.: VxLAN -- This is in the category of Overlay Networks. Check out the draft RFC, and search for terms like VxLAN tutorial or VxLAN primer. Think encapsulation and segmentation beyond 4k vlan tags. Don't confuse OpenFlow with VxLAN, although there's more than one use-case where either could theoretically be used. Note that VxLAN is just one of a few OLN protocols out there, and none of them have reached very far beyond the hype curve yet. OpenFlow vs. OpenStack -- The actual OpenStack project documentation is a great place to start here. Orchestration is another category with several competing efforts, so read as much as possible! SDN -- Consider this the broad category, but avoid overly broad terms like SDN Controller in favor of specific controller until you have the big picture filled in. For example, OpenFlow Controller: There are plenty of docs to read on that specific subject, and there was a stellar tutorial for first-timers at the start of NANOG57. ...and lastly, the killer apps: Don't bother researching this until you've covered the basics above. There are plenty of vendors and researchers out there doing the legwork on killer SDN apps, but you'll want to understand all the underlying technologies first. -Jeff
Re: SDN - Killer Apps
On Mon, Feb 25, 2013 at 2:10 AM, Saku Ytti s...@ytti.fi wrote: On (2013-02-25 13:53 +0530), Glen Kent wrote: I understand that this is just some bit of what we can do with SDN. The amount of what all can be done is limitless. So, a question to all out there - Is my understanding of what can be achieved with SDN, is correct? Frankly I don't think there is single answer. From my point of view I don't see much use for it as general purpose SP. There is potential for balancing to be a killer application for SDN in the service provider space: http://blog.sflow.com/2013/02/sdn-and-large-flows.html What do people think?
Re: SDN - Killer Apps
On Mon, 25 Feb 2013 13:53:13 +0530, Glen Kent said: Yahoo, Google, etc applications are running on one server and each application could be theoretically associated with a unique VXLAN tag. This way service providers will be able to provide QoS per application QoS is, when you get down to it, a way to decide who gets screwed when your network capacity is insufficient. And it's unclear that you're going to get a killer app out of that, because most of the 800 pound gorillas are instead spending their dollars making their network work right at their end. And no amount of QoS at the server end is going to fix things when the real problem is bufferbloat in the CPE router at the other end or other issue not under the control of those participating in the QoS (in other words, if you don't do it end-to-end, it won't buy you much). pgpR12rwrImoP.pgp Description: PGP signature
Re: SDN - Killer Apps
Hi Glen. Here's some thoughts how Networking can learn from SDN: http://forums.juniper.net/t5/The-New-Network/Decoding-SDN/ba-p/174651 /Pelle
