One CLI to rule them all? It’s more than that.

Previous to the Tail-f Networking Field Day presentation, I had done some research on who Tail-f were and generally understood how their NCS product worked, but after sitting with Carl Moberg and his team and listening to what this device can offer, I was immediately drawn in. It would seem they’ve developed an appliance that can effectively, as Nick Buraglio wrote in his post here, the Rosetta Stone for all of the vendor NOSes that exist today.

Carl started the presentation with the phrase “hopefully we’ll show you something that will make you really upset, in a very good way”. And I think he did just that. He proceeded to tell us how Tail-f was founded and what they were up to for the first few years of their existence. There is a good chance that if you’ve used any current generation networking kit from the large names we all know and love, you’ve used Tail-f software and just haven’t been told you’re doing so. He then pointed out the pain point of configuring multiple OSes within an environment and handling the operational load of configuration management, service provisioning, revision control, etc.

It’s cumbersome to have to configure a mixed vendor environment between all of the syntax that most vendors pride themselves in maintaining. This has always been a pain point for operators and running a few mixed vendor networks in the past has always been a pain point for me. Especially jumping quickly between devices and having to switch gears into either OS. Even in the network I’m in today jumping between IOS-XR, IOS-XE, IOS, and now Junos, I find myself mixing up syntax all the time.

Enter NCS. Tail-f offers an appliance that can bring some simplicity to the idea of running multiple NOSes in today’s networks. But it can also do more than that. It allows you to model your services within the appliance and then deploy it throughout the network while also maintaining integrity of that service across your infrastructure through the transaction modeling done by the appliance when applying configurations to devices. This allows for change tracking and validation when rolling services out to network OSes that don’t offer any type of two phased commit process. Once a command is entered we all know there is no turning back on those platforms. This brings a certain level of sanity check to the process as well allowing the NCS to validate configuration before rolling it out to the device. Think about it like this, NCS knows about point A, the current state of the devices within your network and you describe to NCS point B, the service you want to instantiate, and NCS will handle getting you there along with making sure you don’t lose any limbs in the process.

Though NCS offers a lot of functionality through the use of their transaction process, I don’t think this is the biggest feature that NCS has to offer. The biggest thing that I have to say Tail-f offers with their NCS platform is the use of the YANG modeling language to model services within their product. YANG is a language that was written for use with modeling NETCONF. Since Tail-f utilized both NETCONF and YANG to build their service modeling platform on, along with other southbound protocols, I would say that they’re not your typical American Hustle(see what I did there Stephen?) tech company like we have here in the US, and I should add that Tail-f is a Swedish based company. Their service is built using completely open standards allowing possible future portability to other platforms, such as OpenDaylight (shameless plug). OpenDaylight’s entire Model Driven Service Abstraction Layer (MD-SAL) architecture will be operating on YANG modeling and what is built within NCS could possibly be ported into ODL. However, I’m starting to write some modules in YANG and I’m nowhere near expert in the language and still have a lot to learn, but the potential is definitely there.

The Tail-f product no doubt offers a ton of functionality in the way of faster operational application throughout the network, along with full fledged service modeling within their NCS solution. The ability to apply two phased commits is also quite the addition to the network devices today as we don’t have that functionality within the monolithic network OSes today. Being able to apply the two phased logic to something like Cisco’s IOS and IOS-XE bring a better version control along with operational flexibility to roll a change back should any problems present themselves. Along with all of this functionality is the fact that Tail-f has decided to build their solution on the use of YANG modeling. An open source modeling language developed for use with NETCONF, and that fits with the ability to possibly port service models through different products in the future. This would eliminate a HUGE operational burden to organizations that use lock-in products much like Infoblox’s NetMRI, etc.

Pay attention to Tail-f, I think you’ll see some pretty cool things come down the pipe, especially speaking with the team on their plans with ODL (shameless plug again). Pay attention to my blog as well as I saddle up my YANG Unicorn (YANGicorn?) and ride it around a while as I definitely see a future in spending the time to learn the intricacies of a language such as YANG.