In part one of this Q&A with Facebook's Frank Frankovsky, vice president of hardware design and supply chain operations, and Facebook's Najam Ahmad, director of technical operations, we explored how the Open Compute Project's open source switch will allow users to run any OS they see fit on open hardware.
In part two of our conversation with Facebook, TechTarget explores how the Open Compute switch will affect the software-defined networking industry. Facebook also reveals that the Open Networking Foundation had urged Open Compute to start the switch project.
Has Facebook already started building its own switches? Will you be sharing any research or prototypes that you've already developed for this project?
Najam Ahmad: We have one that we are testing today and putting some software on it. We will absolutely share it as we get to the point where it makes sense and feel comfortable that it is usable. [Usually with Open Compute projects,] we build technology that we actually contribute. In this case, the project is slightly ahead. We've chosen to start the project now and have the industry get together primarily because we were getting a lot of [requests] from lot of different avenues, including from the ONF [Open Networking Foundation]. [The ONF] reached out to [the Open Compute Project] and wanted to start a project to build a switch.
Najam Ahmaddirector of technical operations, Facebook
The SDN industry has produced some switch software, such as Intel's DPDK, Flow Forwarding's LINC and Big Switch Networks' Switch Light. Are those the firmware platforms you envision for these Open Compute switches?
Ahmad: Those are definitely in the mix, but we're not precluding anybody or any specific operating system. We spoke to two companies that I can't name just yet, but both of them yesterday were offering, 'Hey, what if we packaged our operating system to run on this thing?' So, I think we're already starting to see the Open Compute advantage of people thinking about this project and saying, 'OK, great, we'll make the OS available.' I think we'll have a lot of choices both from OEMs and from open-source-type environments.
Are you trying to build the ideal SDN switch?
Ahmad: Yes, obviously we want to run SDN-type applications on it. I don't know if 'ideal' is the right word, because it depends on what problem you're trying to solve. We're going focus primarily on the large data center folks and what specific requirements a large data center has. Then, over time, the community will pull it in the directions that make sense.
Is OpenFlow an important consideration in the design?
Ahmad: We totally expect the switch to be able to run OpenFlow.
I ask only because engineers have said the majority of switches supporting OpenFlow today have limitations that affect their ability to deploy scalable production networks.
Ahmad: That would be the intent, to build a switch that's more robust and versatile. But it doesn't mean we're focusing solely on OpenFlow as such. A lot of that stuff is software-centric, and that is work that needs to be done in software. We're not really trying to improve the OpenFlow stack as such. There's a lot of work to be done on the stack side to make OpenFlow scale.
The other thing happening in the industry is that there are not true pure OpenFlow switches. [OEMs] are using a hybrid mode that is running a bunch of protocols. You're burning resources that you could use for pure OpenFlow. Having disaggregation of hardware and software will allow you to use the type of protocols you want to run. That will lead to better OpenFlow scalability as well.
How can the mainstream enterprise use this switch?
Frank Frankovsky: The right way to think about this is as an open source building block that people can modify. There may be a variant that is just the right, demystified design for Facebook. And there may be another variant that a mainstream IT consumer chooses.
We've seen a similar phenomenon on storage and server and rack designs. Open Rack is a great example of something we've done that only some of the largest enterprises are interested in today.
But then we have this other rack design called 'Ash Rack,' and we call it that because it's in our collocation site in Ashburn, Va. It's more of a mainstream design that is more popular for the mainstream IT consumer. Hopefully we'll see something similar emerge in this network switch project, where the first contributions are maybe specially designed for massively scaled, east-west traffic. Over time I think we'll see derivative works. That's one of the powers we see of open source. You can give someone a building block that's 80% correct and they can modify the last 20% without having to start over and reinvent the wheel.
Will today's mainstream network admin even know how to use this switch? Server guys are more accustomed to disaggregation of hardware and software, but networking professionals have trained on these 'black-box switches,' as you have described them.
Frankovsky: I think about it almost similarly to the way a Solaris or HP-UX admin thought about Linux when it first came out: 'Oh my goodness, I'll never run business-critical applications on Linux because it was written by kids with crayons. And I really like my relationship with IBM or Sun because that's what I know and they abstract all that complexity from me.'
Over years we've seen a lot of engineers embrace that flexibility [of Linux] and the complexity that can come with it. I think we'll see a similar trend happening in networking as well.
Ahmad: I think the trend is already there. So many shops are using Linux on their servers that you already have a lot of expertise. It's just not applied to networking today. [Facebook has] an army of people that work on x86-based Linux boxes all over the place. We have a lot of software in that domain as well, and so do a lot of other players. It's more common than you think.
Frankovsky: The other thing is that new businesses that are being created around Open Compute -- Open Compute solution providers. These businesses [such as Hive, Avnet and Penguin Computing] are distributing, modifying and supporting open source hardware. [They are helping] customers modify the open source hardware, put it into the configuration they want and manage all the back-end supply chain complexity. I suspect we'll see similar things emerge in the networking business as well.
It's likely that hardware design and test engineers from well-stocked companies like Facebook and OEMs and ODMs [original design manufacturers] will be heavily involved in this project. How can the mainstream network admin or engineer get involved?
Frankovsky: One easy way is to visit the Opencompute.org website. We tend to post a lot of specs and standard documents out on the site, so that's a pretty lightweight way to just consume the information. Then they can also sign up for distro lists, where they can follow all the notes out of the meetings and a lot of the email dialogues that occur.
If they are really passionate and want to get really engaged, then each project lead in Open Compute runs project team meetings. Najam is the project lead for the networking project. Once he establishes a cadence for conference calls and face-to-face meet-ups, project leads are always seeking new contributors who can show up on these conference calls or meet-ups. And we have engineering summits as well, where all contributors can get together and do the face-to-face work.
Who was at that first engineering summit to talk about the switch?
Ahmad: It was a fairly large team with lots of participants from pretty much every segment of the ecosystem. There were several chip manufacturers. We had ODMs and OEMs, including Cisco. And we had a bunch of people who are pure SDN players in the software domain. We also had several end users or consumers of this technology including the financial sector, which was fairly well represented.
Let us know what you think about the story; email Shamus McGillicuddy, news director.
With OpenDaylight, vendors shoot for open source SDN
How will OpenDaylight stay truly open?
Big Switch's open source switch software
Understanding OpenFlow configuration protocols
Just how open is OpenFlow?