The SDN industry probably considers me an old and grumpy naysayer (and I’m positive Mrs Y has a special place in their hearts after her recent blog post), so I tried really hard to find a real-life example where OpenFlow could be used to solve mid-market innovator’s dilemma to balance my usual OpenFlow and SDN presentation.

Internet Exchange Points (IXP) seemed a perfect fit – they are high-speed mission-critical environments usually implemented as geographically stretched layer-2 networks, and facing all sorts of security and scaling problems. Deploying OpenFlow on IXP edge switches would results in standardized security posture that wouldn’t rely on idiosyncrasies of particular vendor’s implementation, and we could use OpenFlow to implement ARP sponge (or turn ARPs into unicasts sent to ARP server).

I presented these ideas at MENOG 12 in March 2013 and got a few somewhat interested responses … and then I asked a really good friend with significant operational experience in IXP environments for feedback. Not surprisingly, the reply was a cold shower:

I am not quite sure how this improves current situation. Except for the ARP sponge everything else seem to be implemented by vendors in one form or another. For the ARP sponge, AMS-IX uses great software developed in house that they’ve open-sourced.

As always, from the ops perspective proven technologies beat shiny new tools ;)

On a somewhat tangential topic, Dean Pemberton runs OpenFlow in production in New Zealand Internet Exchange. His deployment model is totally different: the IXP is a layer-3 fabric (not a layer-2 fabric like most Internet exchanges), and his route server is the only way to exchange BGP routes between members. He’s using Quagga and RouteFlow to program Pica8 switches.

A note from a grumpy skeptic: his deployment works great because he’s carrying a pretty limited number of BGP routes – the Pica8 switches he’s using support up to 12K routes. IPv4 or IPv6? Who knows, the data sheet ignores that nasty detail.