OpenConfig FAQ for operators

Considerations for network operators interested in joining OpenConfig

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.