OpenConfig is about standardizing the management interface, or northbound API, to network elements, regardless of data-plane function. Like the broader OpenConfig project, WiFi models are both vendor and architecture agnostic. Distributed and centralized Data-plane are both in-scope; whether that means a Wireless LAN Controller, Virtual Controller, Cloud Controller, or no “Controller” at all.
Being able to configure network elements (APs, Controllers, etc.) in the same manner, regardless of vendor, changes the paradigm of vendor lock-in and promotes innovation. This translates to the capability of on-boarding a new vendor without:
- Building and learning a new stack of monitoring tools.
- Training/learning how to operate a new interface, be it API, GUI, CLI or SNMP.
- Re-writing tooling and scripts that often ‘glue’ a network together.
With an abundance of optional and varying levels of support for portions of the 802.11 specification, there still remains a majority of both configuration and telemetry which is agnostic to the Vendor or architecture in use. For example:
- Channel, Channel-width, Transmit-power, Allowed channel sets for DCA, Basic Data-rates, 802.1X, WMM, 802.11v, WPA2, etc.
- 802.11 Retries, Channel utilizations, Rx/Tx Frame distributions, client-counts and capabilities, etc.
- See YANG models or HTML representations for full details.
These are just a few examples to highlight that how you configure and monitor a wireless network need not be proprietary to each vendor. It then becomes more approachable for Wireless Engineers to align hardware capabilities, or architectures, to particular use-cases.
With 802.11 being predominantly an Access technology, operating in unlicensed spectrum, there are countless dynamics to interpreting the health of the network. Client and Access Point capabilities, regulatory-domain and spectrum availability, channel-planning or WiFi Design, and many other factors including the state of the surrounding RF itself, all contribute to the importance of radio-data. Baselining a network, automatically reacting to environmental conditions, alerting thresholds; these are all complex and long-standing problems. It is expected that the solutions will often be unique to the network (or operator), however regardless of vertical, Streaming Telemetry of radio-data gives us the ability to monitor and react to all these varying conditions.
Programmatic access, automation, network modelling, Streaming Telemetry, predictable user experience; none of these are new terms or paradigms. What makes OpenConfig revolutionary is the goal of being vendor and architecture agnostic and completely driven by us, the Network Operators, who are building and maintaining these networks.
This shifts the focus from “Operating WiFi networks by Vendor X” to “Operating WiFi networks”. In short: A vendor’s ability to differentiate should not be based on their proprietary CLI or MIB tree, nor should it be the format of their API.
For those that see value in programmatic access to network elements or simply Radio Telemetry, consider the following, and see here for joining OpenConfig.
- Allowing us, the Engineers, to signal our requirements to Vendors in an open way.
- Allowing Vendors to easily gain visibility into operator requirements that they may, or may not, otherwise have access to.
- Promoting operational innovation, and removing the management-plane as a barrier to entry for vendors.
- Not removing vendors capability to provide vendor-specific knobs, or differentiate in any way. Sometimes these specific knobs are valuable and necessary.
- Not suggesting vendors stop providing their own NMS or innovate with their own solutions.