A few years back, I remember greeting the news of the OpenDaylight project (ODL) with enthusiasm. Here was an open-source project backed by an interesting amalgam of vendors and customers that was going to result in an SDN controller anyone could use.
At last, the industry would have a rallying point for software defined networking. Here, in ODL, the hard work of hammering out what we could really do with SDN would get done. With all of those big brains, developers, and large-scale end users involved in the project, we’d figure this SDN thing out. ODL would be that point of commonality that would make SDN real.
This is the part where you imagine a rainbow-maned unicorn galloping through a field of lollipops. Enjoying the moment? Fabulous. Reminiscing is fun.
What It’s Become
Years on, ODL has become a reflection of the networking industry and the state SDN as a whole. As SDN has fared, so has ODL.
The industry never quite rallied around ODL. We didn’t end up with a point of commonality for what works and what doesn’t in software defined networking.
Instead, we’ve ended up with a myriad of software-defined solutions so disparate that SDN as an idea no longer has a clear definition. Vendors have gone off and built their own, usually proprietary, solutions with SDN inside. Big-time operators have created their own SDN solutions to solve their own problems, occasionally sharing their somewhat inscrutable achievements with the rest of us.
In this light, we can view the OpenDaylight project. Like SDN more broadly, ODL still exists. There are plenty of success stories and “ooh-aah” moments to point to. But at the end of the day, SDN–and ODL–are what you make of them. The experience is a little different for everyone.
With the 6th release of ODL, Carbon, we see a maturing SDN platform. As ever, ODL is the potential centerpiece of your software defined future, if you want it to be. ODL offers lots of modules and boasts of a growing ecosystem. Thus, you can roll your own definition of SDN; using ODL, you can make SDN according to your own imagination.
This is a reflection of the state of SDN in the marketplace. No longer is SDN a radical shift in thinking destined to displace networking as we know it. Instead, SDN is a set of tools that allow network operators to create forwarding schemes that traditional routing protocols don’t allow for.
What’s interesting is that these forwarding schemes haven’t displaced traditional protocols. I believe that SDN is primarily just a tool to enable unusual forwarding, where specific flows are moved along a network with a set of criteria as diverse as you can imagine. Got metadata? You can build a forwarding scheme based around it.
Put another way, if you want to do plain old boring routing, use a plain old boring routing protocol. If you want to do something out of the ordinary, then use SDN.
Think of ODL as Tinkertoys. Using ODL as your base, you can build the solution you’re looking for. Do you prefer OpenFlow as a southbound protocol? ODL speaks that. Would you rather speak PCE or BGP? ODL speaks that. Would you rather use your own app to define network-y things, and have your app tell ODL what it’s looking for? There are northbound interfaces at your service.
Can’t build it yourself? There are systems integrators who would be delighted to work with you. And if your favorite SI can’t quite get you where you need to go, they likely can bring in a specialist SI that can.
Interesting Bits Of Carbon
Carbon is the latest release of ODL. Like OpenStack, this release focuses more on stability and usability, and less on new features. And that, perhaps, is why ODL has felt less newsworthy than it was when it was shiny and new, and each release brought MOAR NEW FEATUREZ ON A TACOCAT-DRAWN SLEIGH OF MAGIC.
Less tacocat. More grown up features aimed at making ODL solid, reliable, and boring in your production environment. I mean “boring” in a good way here. In production environments, boring is good. Fire is exciting, but it’s not something we’re looking for in our data centers.
Reportedly, the biggest work has been done around virtual network functions and service chaining, which suits me just fine. As I think about software defined networking, service chaining is one of the more interesting applications.
Service chaining means that I don’t have to build my network in a way that forces traffic through a chokepoint of a physical load balancer or firewall. Instead, I can run as many virtual load balancers, firewalls, etc. as I like, and stand them up wherever I want.
Then I can define a service path for specific flows that moves the traffic through whatever VNFs are required. I end up with total VNF placement flexibility because service chaining gives me total routing flexibility.
Colin Dixon, ODL Technical Steering Committee chair, suggests that ODL sees the network it governs as a service function chaining fabric now. Your network is viewed as one big switch, with all apologies to the vendor of that name well-known to the Packet Pushers audience.
To move traffic around this SFC fabric, two key tools are employed. One is Network Service Header (NSH). We’ve talked about NSH before on Packet Pushers, on Priority Queue podcast episode 50.
There has been some standards work done on NSH, and Colin says that from where he sits, NSH is gaining mindshare. NSH is not simply a Cisco brainstorm, but rather a tag type that’s gaining acceptance because it’s actually working as field testing progresses. Service function chaining is working, in part, because of NSH.
That said, NSH is not a tag that’s understood by all devices. To chain traffic through devices that are not NSH-aware, VXLAN encapsulation is used. This feels to me like a temporary situation, but it could be a long sort of temporary, as for some use cases, NSH has a silicon problem.
I read through a good deal of ODL’s SFC documentation, and found a couple of other interesting features. One is service function scheduling algorithms. This means that there might be more than one set of VNFs that can satisfy the requirements of a specific service chain. As such, there are different algorithms that can decide which service path is the best one for a given flow. Four algorithms exist in Carbon: random, round-robin, load balancing, and shortest path.
Another interesting SFC feature is proof of transit. Imagine an auditor to whom you need to prove that sensitive traffic is being pushed through a firewall and L7 inspection engine. You could point to a policy and say, “See? Look. The policy says the flow is supposed to go that way.” To which the auditor might choose to respond, “Sure, sure. Now prove it’s working.”
SFC PoT is about demonstrating that a flow followed a specific service chain in a non-refutable way. The essence of the idea is by retrieving pieces of a secret at each hop along the way. Each new piece allows retrieval of the next piece. Missing a piece because the flow is going the wrong path? The next retrieval of the secret piece fails, which then means the PoT fails. Get to the end of the chain and have all pieces of the secret? PoT has been satisfied.
The bits to do with the secret are stored as metadata. That metadata can be stored in a new TLV for segment routing, as NSH type-2 metadata, in an IPv6 extension header, and more.
The View From The Hot Aisle
OpenDaylight has settled into a role as an SDN platform made use of by carriers, over the top providers, managed service providers, and yes, even large enterprises. In addition, many organizations have downloaded ODL and used it as the basis for commercial products that have found their way in to various companies.
There are folks using ODL code or benefitting from OpenDaylight without even knowing ODL is in the picture. The OpenDaylight project estimates that over 1 billion people are consuming services that were delivered to them, at least in part, by a network using OpenDaylight. 700 million of those are in China—TenCent customers specifically using WeChat.
The impact of OpenDaylight and software defined networking more broadly is, therefore, undeniable. Even if ODL is not a package you as a network operator ever download, it has a place in this world.
In that sense, ODL matters to everyone. Okay, so it never became the one SDN controller. And SDN never became the new way we put networks together, displacing traditional methods. But OpenDaylight proves from a platform perspective what’s possible with a modular controller platform and some developmental elbow grease.
Whatever you might think of SDN, you can’t deny that networking will never be the same.