on 03-28-201306:20 PM - last edited on 10-28-201309:33 PM by bcm1
Warning! "Peak summit season" is upon us!
Sure, “peak” and “summit” are synonyms, but I didn't mean to be redundant. Last week I was at the SDN Summit in Paris (with side trips to Italy and Germany), next week I’ll be speaking / chairing / organizing at the Ethernet Technology Summit, and then in mid-April I’ll be attending the Open Networking Summit. For variety, I’ll finish at the ONF Member Workday(s) right after ONS. Besides a surfeit of “conference chicken” and a dearth of business cards, what will be the upshot? Well, I’m seeking a richer sense of the networking market zeitgeist, and Paris did not disappoint in that regard. There was a good range of talks from academic to actual-doers, as well as from numerous vendors (including one by Brocade’s Dave Meyer). One that particularly amused me was by Kireeti Kompella of recent notoriety for his Juniper-Contrail-Juniper travels. His talk was titled “SDN: OS or Compiler”, and he advocated an altered viewpoint in SDN: We see SDN as an operating system, but we should think of it as a compiler. We should tell the system “what we want” from the system, but instead we often prescribe “how it should do it”.
I may not always agree with Kireeti, he’s right on the “what, not how” point of view. My first point of amusement derives from the fact that, entre nous, this what-not-how approach was central to the grassroots movement within the ONF in October of 2011 which led to the creation of the Forwarding Abstractions Working Group.
A second point of amusement is that the compiler question is partly a bit of prestidigitation, suggesting that the problems are now gone when in fact we’ve merely tucked them up our sleeve. Suppose we agree on this compiler notion. The next round of questions is, what is the language we will use for describing our SDN needs? For the real issue is, what are the abstractions that we’ll be dealing with? And at some level that’s another sleight of hand, because then we will need to define what we mean when we say “connection” and “endpoint.” (E.g. if tunnel endpoints exist in a device, does that mean the device is an endpoint?) And once we have bashed out some language, then we’ll have arguments about where the compiler resides. Because it’s the compiler’s job to translate the “what” into the “how”. At which layer does this translation occur? Is there only a single layer of translation? Etc.
Don’t get me wrong; these are important questions. And I’m actually glad that Kireeti used his 25 minutes to articulate the what-not-how notion, prompting some good discussion. And yet, we should not pause in our development of SDN to iron out these questions, because pausing won’t improve the outcome. Better to build on the SDN momentum by delivering incrementally and iteratively better solutions over time. In a way, this topic sets the stage for my talk at ETS next week, which I’ll give a mini-preview of here.
This “compiler” discussion is relevant to OpenFlow in part because many consider OpenFlow to be “the x86 instruction set for the network.” What a great idea!! Why didn’t we think of this before! Well, actually, attractive as it is, unfortunately we didn’t “think of it before,” since it turns out that our networks have no x86-equivalent platform. Often when this minor detail comes up, voices (basso profondo1, typically) are raised that “we’d be better off with common platforms, like the compute industry has!” Possibly... But strident appeals merely distract from the reality that our deployed network silicon has a myriad of “instruction sets”. So. Here we are. We’ve created an instruction set, and it doesn’t quite match our “network computers”, the devices that constitute our networks. What do we do?
Well, if we had the ideal alternative in place, I would say that we should flush everything and switch to this new ideal. But we don’t yet have a better answer. Or, more accurately, there’s nothing close to a consensus on what the better answer is. And so I recommend that we move forward with what we have and improve as we go. Is it perfect? No. Is it better than sitting and complaining? Yes. Not only that, there are historical precedents. RISC architectures were arguably better (more efficient, whatever) than x86, but x86 has been a heck of a workhorse and served as a solid platform. Through beaucoup tweaks and enhancements, IPv4 has far outlived many predictions of its demise until address depletion is finally forcing the adoption of IPv6 (which, nota bene, had its own detractors, of course). So the idea that we might make do with the “OpenFlow x86 instruction set” for the time being might just work out, in the same way that we just managed to squeak by with that instruction set in the compute world.
What happens when we “compile” our network desires into an instruction set that’s out of sync with our underlying platforms? Well, what happens is that those instructions become the new “high level language”, and we need new compilers, or perhaps interpreters (easily built on servers or NPUs), to execute the requested functions. As it happens, FAWG (my ONF working group) is also addressing how to map OpenFlow to ASICs. My talk at ETS next week, entitled “Bringing OpenFlow’s Power to Real Networks” visits how we can deal with this.
My apologies to all you CS majors (those who reached nostalgically for your copy of the dragon book on compilers) for merely tickling the surface of compilers in this post. I’ll happily engage with y’all at the expert table next Wednesday night. But if you come, you’ll be the compiler expert; as a Physics major, I stalled out in Chapter 2.