Open CLI

Towards a python/yang defacto industry-standard

When I first started working in router startups in the mid-90’s, the command line interfaces (CLIs) were built with some fairly gnarly looking C code. I don’t mean just the backend; I mean the UI as well; not necessarily improved that much by packages that were available on the embedded operating systems of the day.

Image source: SONiC command line interface guide

Fast forward to today, and I know of at least two companies, that overshot the market, by building products without a meaningful CLI, on the premise that CLIs would no longer be required, as NETCONF/RESTCONF became the main interfaces to network equipment.

How long will CLIs be with us? I have no idea, but the conventional wisdom seems to be, a long time. There is nothing like the comfort of getting the lowdown directly from the horse’s mouth. Especially when noodling around in a lab, but even for some operations people.

If CLIs are going to be here for a while, is it worthwhile rethinking where we are as an industry? Even if we do not, is change coming regardless?

Yang has reached critical mass. Definitely in marketing mindshare, but arguably beyond that, especially given the engagement in the market of OpenConfig which has pioneered a repository of Yang models that have the intent of being vendor neutral. The IETF, in many ways the incubator, is also developing Yang models. Python has also reached critical mass. With most of the major networking vendors providing python plugins and python-based CLIs, in addition to providing Yang models, can it be that far into the future when Yang / Python take on a life of their own, and an open industry-standard CLI emerges?

For many networking professionals, and especially those that have Cisco certifications, the Cisco CLI is THE defacto industry-standard. Cisco earned that status by being so successful and pervasive. So, no intent to take anything away from them.

However, there is a tax the industry pays for having a defacto industry standard that is legally protected by a single vendor. Every time a new routing stack/routing company is created, a major decision has to be made. Either adopt the Cisco CLI format and run the risk of being sued by Cisco , or do something different, and run the risk of prospective customers citing the new CLI as a reason not to change. The success of Juniper and Nokia in Service Provider, perhaps suggests that having a different CLI is not an inhibitor to success. There are fewer data points, in the Enterprise Networking market. HPE has some products with Cisco-like CLIs and some without. Regardless of the vendor equation, network operators/managers are learning new CLIs every time they consider a new supplier.

If Yang is sufficiently exposed and capable, is it likely that an industry-standard/vendor-neutral CLI will emerge? It is always hard to predict who is going to throw their energy where and for what reasons. All anyone can do is observe the opportunity. Python and Yang on box create the opportunity for customers if allowed by their suppliers, to play with creating their own CLIs. For a remote CLI, any number of interfaces can be used.

The appeal of staying with the familiar is an inhibitor to change. Of course, before OpenConfig, the same may have been said about Yang models.

An Open, vendor-neutral CLI, would probably have to be an open source effort, by a coalition of the willing. Vendors themselves are probably not going to perceive much upside. The major suppliers have a CLI, so why reinvest in something that already works. This would have to be spearheaded by new industry players and/or network operators/managers.

This feels like something that might naturally emerge, given the conditions are right. There are negative arguments of course. There are Yaml to Yang translators in existence, implying that Yang is not universally loved, or necessarily a cloud-first approach. So, there are always “but” did you consider this. These “buts” have merit. The bigger picture though is Yang and Python have momentum. Let us see if the opportunity is met with energy.