Word on the street is that On.Lab executives are scrambling to land sponsors — AT&T and Microsoft among them — for a controller that would compete with the OpenDaylight Project's.

Our sources suggest that the Open Networking Operating System (ONOS) will use OpenFlow and is being positioned as a controller for the WAN to enable increased utilization of WAN links for prospective customers (or, in overly simplistic terms, enable them to catch up to Google for WAN utilization).

On.Lab is reportedly trying to close those deals by the end of 2013.

Here’s what we’ve collaborated from multiple sources:

• On.Lab is rumored to have approached AT&T, NTT, Microsoft, HP, Ericsson, Ciena, and Extreme among others to "sponsor" ONOS at a cost of $500,000 each for 2014.
• On.Lab is reportedly pressuring prospective sponsors to commit funds by Dec. 31, even though the structure of any sponsorship arrangement including ownership rights of the IP, licensing, and project governance are yet to be defined.
• AT&T is rumored to be particularly interested in an open-source alternative controller that 1) is designed for the WAN and 2) provides alterative to its main network suppliers (Cisco and Juniper) — and AT&T is targeting to leverage ONOS in the 2016 to 2017 timeframe, when it's set to roll out its next-generation network using vendors picked for its Domain 2.0 program.
• Microsoft is rumored to be interested in ONOS for its WAN infrastructure with the project as part of the Azure cloud platform
• On.Lab has specifically targeted AT&T and smaller AT&T suppliers, hoping to break Cisco and Juniper’s dominance and gain market share inside AT&T.  We’ve been told that neither Cisco or Juniper has been invited or included in the discussions.
• Google was reportedly approached, though it declined, as it appears Google believes its current SDN WAN more than meets its needs.   (Note:  Google’s WAN controller, Onix, was supposedly born from a similar project with On.Lab founders back around 2010 with Nicira, NTT, and NEC).

While large service providers and MSOs we’ve spoken to who and have heard the ONOS pitch or seen the demo believe that OpenDaylight may be a viable controller alternative within the data center, they all concede that it’s not likely to solve the service-provider WAN use cases any time soon.  In principle, they agree on the need for a non-OpenDaylight open-source controller specifically designed and developed for WAN use cases. However, they are highly skeptical of the ONOS approach for a number of reasons:

• Applicability beyond AT&T and Microsoft’s specific requirements. There’s a feeling from multiple carriers and MSOs that the approach is too singularly focused on a specific use case or carrier network that may not be widely useful across multiple WAN use cases.
• Questions around how much real IP has been created, how much of the ONOS pitch is based on slideware and demoware, and varying perceptions as to how much work has gone into understanding deployment on a real-world network at scale.
• Concerns about code quality. ONOS is being pitched as being developed by SDN experts who are primarily university researchers and grad students, and the history of controllers developed by previous Stanford researches includes NOX, Beacon, and Floodlight, all of which have significant architectural issues which are limiting commercial deployments.
• Unreasonable timeline to production.  Given AT&T’s supposed timeframe, we’ve been told by multiple sources that it highly unlikely an ONOS controller could be production-ready (think: features) and production-grade (scale and operations) to meet AT&T’s Domain 2.0 time frame.  As a frame of reference – the Nicira controller, which was started in 2008, is still experiencing production and scale issues five years later.

As many of you already know, we at SDxCentral have a unique perspective on open-source and open networking for SDN and NFV, driven by our experiences with end customers and bring new technology products to market.  Specifically, when we evaluate "open networking," we consider the customer lock-in and supplier lock-out risks from various open networking approaches and governance models, including:

1. Proprietary SDN masquerading as open-source or open networking (Floodlight or OpenContrail being two examples).
2. Open-source or open networking offerings, like OpenvSwitch, controlled by a singled entity (Nicira/VMware) —  see our posts: vSwitch is the New Battle Ground, Open Source: The Biggest Risk to SDN, and Consider LibOF before Spending Money Building Your Next OpenFlow Implementation.
3. Business risk of engaging in open-source projects (especially for code as fundamental as vSwitches or controllers) outside of foundation-based governance models.

And as a result, SDxCentral is a big advocate for open networking and open-source software with viable organization structures that drive innovation; enable and empower a wide and diverse ecosystem; have consistent and transparent rules of engagement for sponsors and contributors, and clear criteria for source code to be accepted or rejected; and a clear, open, and transparent governance model.

There’s not enough information for SDxCentral to render an opinion about how "open" On.Lab or ONOS are or will be.

On the On.Lab website, ONOS is described as a controller designed to “run on multiple servers to support a scale-out design, high availability, and a unified network map abstraction for controller and management applications to use.”

To us, this sounds like an application developed in C/C++ that uses some in-memory database like MongoDB, Memcached or Cassandra) for distributed, high-performance state. (Much like the applications we designed, developed, and shipped for a number of our Wiretap Ventures clients).

On.Lab is a SDN research organization founded by Nick McKeown and Guru Parulkar at Stanford and Scott Shenker from UC Berkeley.  They were co-founders of, and Parulkar an early investor in, Nicira, which was acquired for $1.26 nillion in July 2012 by VMware.  According to the On.Lab website, On.Lab is administered by the ONRC (Open Networking Research Center), which is an industry affiliates program administered by Stanford University that spun out of the Stanford Clean Slate Program.

ONRC (and presumably On.Lab) is financed through corporate sponsors such as CableLabs, Cisco, Ciena, Ericsson, Google, HP, Huawei, Juniper, NEC, NSF, NTT, Texas Instruments, and VMware, as listed on the ONRC website, who each pay $150,000 annually to sponsor ONRC and, indirectly, On.Lab.

If this is true, there are a number of open questions, including:

• What other customers are participating?  Who are other potential sponsors?
• What does this mean for organizations' commitments to OpenDaylight when they also consider ONOS?
• Who owns what?  How can people contribute?  What’s the process for non-sponsors to contribute to the code base?
• What’s the licensing and IP structure?
• Who leads development?  How are priorities determined?  How does product management operate?  What is the governance structure?
• Why is a research organization whose goal is research, not product development or commercialization, developing an open-source project targeted for a specific customer needs?

Again, if true, there are potentially significant implications for the SDN ecosystem including:

• Prospective Customers
  • Understand your use case and your options to solve that use case.  There many options to solve the new controller and management problems; take the time to investigate open-source and proprietary options.
  • Remember: Just because a solution is open-source does not mean you are protected from vendor lock-in.
  • Look for vendors and partners that can develop SDN solutions tailored for your specific needs and environment
  • Figure out if ONOS is really uniquely suited and designed to solve your use case and whether the goals of ONOS will change over time based on who’s driving it — how will conflicting sponsor goals be resolved?
• Prospective Sponsors
  • $500K is a lot of money that could be allocated to product development. Ensure that you receive clear articulation around governance, IP, and licensing.
  • Push for a Foundation or at least an open and transparent governance model.
  • Learn from Onix, which was a controller code base that was supposed to be open source and wasn’t.  Identify ways to protect your interests in the event the open-source intentions behind ONOS become circumvented.
• OpenDaylight (and its sponsors)
  • Understand what ONOS is bringing to the table and why OpenDaylight is viewed as not being able to meet those needs.
  • Look for ways of accommodating the ONOS use cases in new OpenDaylight projects and modules in future revisions.
• On.Lab
  • To gain traction with the open community, "open" needs to be open in every sense of the definition.  Transparency around governance, licensing, and funding sources will go a long way toward gaining acceptance in the community.
  • Be transparent around project guiding principles, who the individuals and principals are in ON.Lab, and other existing relationships which might influence the future of ONOS (university, other open-networking organizations, startups, etc.)
  • Communicate to the community how they can be come involved with ONOS to win the hearts of developers (don’t make the mistake that OpenContrail initially made).

If all of this is true, ONOS has potential to ignite SDN for the WAN and create a robust developer community — or it could be diversion that buys time for the executives of On.Lab to create Nicira 2.0 off the backs of the very vendors (sponsors) they are expecting to finance ONOS. Perhaps that’s just too conspiracy-theorist, but stranger things have happened.

We’ll share more as we learn more publicly available data.