Balloons, Bags, and SDNs

8 August 2012 by 5 Comments

“It won’t scale.”

These words have become an almost reflexive habit, haven’t they? Particularly in relation to SDNs, “it won’t scale,” is the mantra of an entire industry.

I have a problem with this assessment, though. There are a number of problems confronting SDNS on the scaling front. There are limitations on the number of flows that can be controlled by any particular switch, or in forwarding hardware. There are problems with an off box controller monitoring the local state of network devices —can the control path keep up with state changes, and what happens when it can’t?

But before we rush to judgment, let’s look at the other side of the scale. SDNs can’t be compared to the perfect network, they must be compared to the networks we actually have and use.

Do the networks we’re building today actually scale?

Let’s consider the data center environment. Some vendors are now building data centers with 250,000 physical devices, designed to support millions of individual customers. For each customer, there must be a separate virtual network. Each of these virtual networks must handle each flow with care, making certain to get quality of service and delivery right. Do millions of VLANs really scale? Can we really manage millions of VLANs well, can we understand the traffic flow in the network, can we understand the quality of service on a per flow basis well enough to really build a network that works well for every one of a million customers?

What about wide area internetworks? Routing exceptions are legion, security checkpoints abound, and manual tweaking of routing metrics beset our lives. WAN optimizers and edge opitmizers and flow optimizers and metric optimizers and…

The question isn’t whether or not SDNs will be complex. The question isn’t whether or not SDNs will scale infinitely. The question is will they scale enough to work in the real world, and will they simplify or complicate real world networks?

The answer to that question is the answer to Don Slice’s famous question about the number of EIGRP neighbors a router can handle, “How many balloons fit in a bag?”

It depends.

In some situations, SDNs are going to make life much simpler. In others, they’re going to make the network harder to run. The quicker we come to see SDNs as another tool in our box, the sooner we’ll be able to realistically evaluate where they’re useful, and where they’re not.

But comparing an SDN to a simple spanning tree network without the complexities of thousands (or millions!) of VLANs, or a simple OSPF network without the complexities of redistribution, optimization, tuned timers, and all the rest, simply isn’t going to lead us to an honest evaluation of the technology, nor to a good understanding of where and how they can be used.

A simple rule of thumb is this: Before you say, “it won’t scale,” ask, “compared to what?”

Filed Under: Blogs, SDN Tagged With: ,
About Russ White

Russ White is a Network Architect who's currently looking for a new challenge. He's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. If you want letters, well... BSIT/MSIT (Capella University), CCIE #2635, CCDE 2007:001, CCAr. So there.

  • http://marathon-networks.com/ Dan Shechter

    There are several questions about SDN which I feel haven’t been answered:

    1. How would the SDN network interact with other networks, SND or not? Today we have set of protocols and rules (OSPF or MAC learning), what is planed for SDN?
    2. If I am not a mega hosting company, but just running a DC with 4000 servers, how would SDN help me? 10G MLAGs and 4000 VLANS are just fine/works/thank you very much… ;)
    3. What happens if in the lifespan of my SDN network I don’t like the controller vendor. How to I switch to another vendor?
    4. IMHO most ITs enjoy the decoupling of network and application. I try my best for the network to be transparent to the applications. The applications’ admins/opers/programmers got enough on their hands. Assuming that part of SDN is that applications (not controllers) will program the network to optimize it for their need complicates my life and theirs to no ends.

    Now, if SDN just means easier APIs to configure the devices, than everything that we could do with SNMP/netconf/expect will be just easier to program. That’s it.

    My 0.2

    • riw777

      1. Interaction with other protocols, or at boundaries, isn’t handled today through MAC filtering or OSPF, it’s handled through redistribution, which is always a messy venture (virtually every network melt I’ve ever worked on involved, in some way, the interaction of two different control planes). I don’t think this will change with SDNs in any meaningful way.

      2. It’s hard to say at this point –it depends on the scale points, doesn’t it? If I had a campus of 20 buildings with a total of 1000 hosts, and a single server room with 2 or 3 rack mounted servers, I probably wouldn’t care much about VLANs, either. So the answer goes back to, “how many balloons fit in a bag?”

      3. One of the points of SDNs is to separate the hardware from the software to some degree or another (depending on the model you’re working with). What happens if you don’t like your OSPF implementation today? There aren’t simple solutions here no matter how you slice it.

      4. Maybe, maybe not. Right now your applications are tied to your network through you, the network engineer. In other words, when the applications change, you must react by modifying QoS throughout the network, deploying new security policies at every hop/choke point, considering state verses stretch (aggregation) in terms of this specific application, etc. How is that different than what an SDN might offer, other than providing tools in the space that aren’t available today?

      Whether or not SDNs mean “just an easier way to configure devices,” is up to you. If it’s just a replacement for SNMP, then let’s all just deploy YANG, and be done with it. But there’s more here that has potential, I think.

  • http://www.ipspace.net/ Ivan Pepelnjak

    Russ, I’m positive there have been people parroting “it won’t scale” argument without having a clue what they were talking about.

    However, we both know networking industry has a long history of lessons learned from failures (including large-scale bridging, large-scale RSVP, LANE, ATM-to-the-Desktop and a few other experiments) that most of the SDN/OpenFlow crowd seems to be ignoring so far.

    My latest “discovery”: Floodlight OpenFlow controller actually installs microflow entries in all OpenFlow-controlled switches in the path. Do we have to discuss whether that approach will scale or not?

    In my opinion, we’re not yet at the point where we could be asking “as compared to what?”, we’re at the point where we have check the architecture and implementation details of OpenFlow/SDN solutions to ensure there aren’t any obvious gotchas.

    Example: NEC Univerge PF5820 which seems to be the same as BNT G8264 has 80K L2 flow entries and 750 (yes, that’s seven-hundred-and-fifty) 12-tuple entries. I have to wonder how they’ll implement L3 forwarding in any reasonably-sized network with 750 12-tuples.

    • riw777

      In the long run, I think such questions will be answered through various aggregation options, as they always have been… Routing protocols didn’t scale when they first hit the street either –I can well remember the discussions over how many OSPF routers you could have in an area (and was instrumental in having the 40 limit taken off CCO when we outgrew it). EIGRP failed miserably when it first deployed because some “obvious gotchas” weren’t handled right, and the SPF implementations in OSPF and IS-IS were really naive for a long long time…

      So, yes, there are problems in current implementations. But saying, “it won’t scale,” as a technology because of problems in current implementations isn’t precisely long term thinking. The principles behind SDN are solid, what we need are the right models, and the right implementations. The models we’re working on (I’m writing a chapter on it right now for a new book, and others are working in the same space), the implementations are going to take time. That’s just the nature of the software/hardware world we live in.

      SDNs will grow, mature, and scale, before it’s all over with.

      • http://www.ipspace.net/ Ivan Pepelnjak

        “SDNs will grow, mature, and scale, before it’s all over with.”

        … or we’ll figure out it’s just a marketing cloak for something we’ve been doing (or not been doing) for years.

        So far, I’ve failed to see a use case where OpenFlow or SDN would be the mandatory enabling technology. Nicira’s NVP is architecturally very similar to Nexus 1000V, and NEC’s Programmable Flow Controller is not much different from various Virtual Chassis solutions.