Considerations for network operators interested in joining OpenConfig
Published: June 2015
What is OpenConfig trying to do? What’s the point?
OpenConfig is bringing network operators together to work on the problem of a lack of common interfaces and APIs for managing the complex, heterogeneous networks that all of us manage. This translates into the need for vendor-neutral APIs for declarative configuration, modern, scalable monitoring solutions, and adoption and native support on vendor platforms.
The collaborative strategy ensures that the output of OpenConfig i) reflects a variety of use cases, ii) represents an operational focus on what really matters, and iii) consolidates requirements across multiple customers in order to simplify the support required from vendors.
Please see the OpenConfig FAQ for more discussion.
Who runs OpenConfig?
At this time, there is no formal governance in OpenConfig, i.e., no board, no elections, no bylaws – just a group of engineers and architects trying to get some work done to reach our goals. OpenConfig was initiated by Google and started as a collaboration between a handful of operators (since grown – see the current participant list). Google currently coordinates the activity by organizing weekly meetings, hosting mailing lists, sponsoring the code hosting infrastructure, etc.
What do I need to do to join OpenConfig?
Technically, not much – OpenConfig is an informal working group with no legal agreements or signatures required. We depend on good behavior, transparency, and shared goals and vision.
What we do ask, however, is that engineers participating in OpenConfig ensure the following:
- have the full support of your organization – this should be work you do on behalf of your company, not as an individual interest or private hobby – your company should be willing to be identified as a participant
- be closely involved in operating, designing, or architecting your organization’s networks so that you can represent your operational requirements
- be willing to participate at some level – there are lots of ways to do this, e.g., bring your operational requirements, configurations, etc. to the table, write model code, tools, or documentation, review and test models, push your vendors to support OpenConfig models, evangelize OpenConfig goals inside and outside your organization, …
- understand that the work we do is non-proprietary – OpenConfig model code is published under an Apache 2.0 license, and when published in the IETF or other bodies, also subject to their respective licenses or agreements. Again, since there are no legal agreements, bylaws, CLAs, etc., we depend on all participants behaving transparently in support of the goals.
- agree to keep OpenConfig discussions, code, and materials within the group until there is agreement to publish to the wider community – there are no NDAs, but we expect all participants to adhere to this guideline so that we can develop an operator perspective before sharing our work externally.
If you agree with these guidelines, and would like to join the effort, please join the public OpenConfig mailing list and send a note to the group owners indicating you’ve read this doc and are ready to change the networking world :-)
We support OpenConfig’s goals but we’re not yet ready to consume the output – does it make sense for us to join?
Yes. Every OpenConfig participant is at a different point in evolving their network operations. If your organization has projects planned or in progress to transform your network to be programmable, vendor-neutral, declarative, and scalable, it’s likely you will benefit from what OpenConfig is doing. Similarly, OpenConfig is more likely to succeed when it reflects a wider array of operational use cases, and when we can show vendors that we represent the needs of a larger set of their customers.
We are already working on similar efforts in the IETF and with our vendors – is OpenConfig different?
There are a number of standards organizations, most notably IETF, that are working on developing standard data models for network management. OpenConfig is unique in that our work is driven by operators, and hence represents a user / consumer perspective that is focused on meeting real operational needs. Much of the vendor-driven work in standards organizations proceeds from a motivation to reflect existing implementation considerations, or to expose a complete set of features that may or may not be used in mainstream operations. That said, we do work in partnership with vendors to ensure OpenConfig models can be supported natively on various platforms, and with standards organizations to leverage their work where it meets our requirements. We expect that OpenConfig output will aid standardization efforts - based on its reflection of real operational networks.