A few years before MPLS/VPN was invented, I’d worked with a service provider who wanted to offer L3-based (peer-to-peer) VPN service to their clients. Having a single forwarding table in the PE-routers, they had to be very creative and used ACLs to provide customer isolation (you’ll find more details in the Shared-router Approach to Peer-to-peer VPN Model section of my MPLS/VPN Architectures book).

Now, what does that have to do with OpenFlow, SDN, Floodlight and Quantum?

The Big Picture

Big Switch has recently released a plug-in for Quantum that provides OpenFlow-based virtual network support with their open-source Floodlight controller, and they use layer-2 ACLs to implement virtual networks, confirming the infinite wisdom of RFC 1925:

Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

How does it work?

The 30K foot perspective first:

• OpenStack virtual networks are created with the REST API of the Quantum (networking) component of OpenStack;
• Quantum uses back-end plug-ins to create the virtual networks in the actual underlying network fabric. Quantum (and the rest of OpenStack) does not care how the virtual networks are implemented as long as they provide isolated L2 domains.

And a quick look behind the scenes:

• Big Switch decided to implement virtual networks with dynamic OpenFlow-based L2 ACLs instead of using VLAN tags.
• The REST API offered by Floodlight’s VirtualNetworkFilter module offers simple methods that create virtual networks and assign MAC addresses to them.
• The VirtualNetworkFilter intercepts all new flow setup requests (PacketIn messages to the Floodlight controller), checks that the source and destination MAC address belong to the same virtual network, and permits or drops the packet.
• If the VirtualNetworkFilter accepts the flow, the Floodlight’s Forwarding module installs the flow entries for the newly-created flow throughout the network.

The current release of Floodlight installs per-flow entries throughout the network. I’m not particularly impressed with the scalability of this approach (and I’m not the only one).

Does it make sense?

Floodlight controller and its Quantum plug-in have a very long way to go before I’d use them in a production environment:

• The Floodlight controller is a single point of failure (there’s no provision for a redundant controller);
• Unless I can’t read Java code (which wouldn’t surprise me at all), the VirtualNetworkFilter stores all mappings (including MAC membership information) in in-memory structures that are lost if the controller or the server on which it runs crashes;
• As mentioned above, per-flow entries used by Floodlight controller don’t scale at all (more about that in an upcoming post).

The whole thing is thus a nice proof-of-concept tool that will require significant efforts (probably including a major rewrite of the forwarding module) before it becomes production-ready.

However, we should not use Floodlight to judge the quality of the yet-to-be-released commercial OpenFlow controller from Big Switch Networks. This is how Mike Cohen explained the differences:

I want to highlight that all of the points you raised around production deployability and flow scalability (and some you didn't around how isolation is managed / enforced) are indeed addressed in significant ways in our commercial products. There’s a separation between what's in Floodlight and the code folks will eventually see from Big Switch.

As always, I might become a believer once I see the product and its documentation.