We have strived hard to make Open-mul (and Pro version) one of the best performing SDN platforms in the world. Control plane performance and scalability is critical for SDN as there are so many things to manage and administer. But, MuL is not only about performance and newer openflow version support. We have focused on a few areas where we believe we can excel and bring real value :
1) Openflow based ethernet fabrics :
With advanced topology discovery and Openstack integration, it becomes very easy to have an Ethernet fabric up and running in a matter of few hours (if not minutes). Fabrics which are fast, which, are free from any vendor lockin makes a lot of sense to lot of people. It is unfortunate to see technology like TRILL still being pushed when Openflow can do far far better. Many commercial vendors (barring few) have given up Openflow based fabric. The main reasons being a) Lack of decent OpenFlow gear b) Lack of decent Software that makes up SDN c) Solid orchestration and network visibility/tools d) Last but not the least, effort by big vendors to push Openflow off-track and promote their own version of SDN
Ok, but how do we solve performance/scalability issues with Openflow and controllers ?? The answer is simple – By knowing what are limits of Openflow and engineering solutions based on collective understanding of Openflow and legacy systems. Control plane performance/scalability is not a problem for us because of our grounds up design to meet those requirements.
Some other myths debunked :
– Openflow switches are not up to the mark
This has also been one of our biggest pain points so far. We simply could not find a device to hook up with our software which could instill confidence in the market. But with recent announcements from Broadcom regarding more robust Openflow support and vendors using Ezchip have stepped up the game. With a million flows up for the grab at line rate it is exciting time for sdn software.If that is not enough for software, better dump whatever sdn controller you are considering to use.
– Openflow needs learning. Switches cannot support greater than X flows per sec.
Yes that’s true but we are living in times of orchestration. With careful orchestration with Openstack (or other equivalent management platform) the needed paths can be stitched before hand. Dynamic learning is not what Openflow needs. If your controller does that, then your design is already broken.
– Controller is a central point of failure.
With Openflow 1.3 and greater, controllers can run in active-active, active-standby or n:1 . This simply rules out “central point” debate. Has any one experienced a switch breakdown in a legacy L2 network and seen its aftermath ?? Central point of failure is not the end of the world. There are quite a few other situations that lead to catastrophic failures in the network.
– There is no need to re-invent the wheel. Why need Openflow ?
People re-invent (or replace) the wheel when wheel has broken down. Same has been the case with SDN. Legacy based stretched L2 networks simply can not scale and SDN provided a perfect platform to solve these new-age problems. But many folks have taken a shortcut. People did not want to touch big guys hardware market hence engineered solutions around VxLAN. MPLS would have been a far better choice than VxLAN in the first place. So, there is a definite need to re-invent the wheel and Openflow with smart controller design can overcome many issues in a clean manner.
– Switches can’t support more than X complete-match (Openflow) flows. It can’t scale.
Firstly, Openflow does not need complete-match flows. With better control plane design we may use IP address/mask or MAC address combination. Many Openflow switches can now provide significant table space by optimizing and accommodating such partial-match flow in different (legacy forwarding) tables like MAC table, route table etc
Secondly, we really don’t need to maintain end-host flow state in the complete network. Maintain state at the edge. By edge, we mean virtual switch which can support much larger number of flows than in physical switch. The core switches only need to maintain information regarding how to reach each other. A design which many legacy systems use (eg mpls) and SDN can definitely benefit from it. In fact many SDN gurus have advocated this approach.
In the upcoming days, we will be releasing software which will try to stand tall and deliver on the unfulfilled SDN promise. SDN is not S(Still) D(oes) N(Nothing) but indeed Software defined networking.
In upcoming Part II of this blog, we will talk more about MuL’s target audience and areas.
This article was contributed by :
Director of Software Solutions,