Network Automation: Just Do It!
On the very same day that I published the CLI is Not the Problem post I stumbled upon an interesting discussion on the v6ops mailing list. It all started with a crazy idea to modify BGP to use 128-bit router ID to help operators that think they can manually configure large IPv6-only networks without any centralized configuration/management authority that would assign 32 bit identifiers to their routers.
The discussion quickly deteriorated into you really need a provisioning system and in one of the responses Jared Mauch provided a link to a NANOG presentation by Shawn Morris from NTT.
You should spend a few minutes going through the presentation; here are my cynically biased highlights:
- The project was started by engineers who decided to make their own job easier. There were no grand plans, announcements or press releases.
- They didn’t lament the lack of tools, started an industry consortium or frequented Open * Summits; they took whatever tools were available (SSH and FTP) and got the job done.
- They have three people working on the product. That’s peanuts for any large networking team (most large organizations have more people doing manual configurations that NTT doesn’t have to do due to their tool).
One has to ask the obvious question: Why does the wheel have to be reinvented by every single operator or IT organization (hint: NIH syndrome)? Why don’t we have an open-source solution (there is a pretty good commercial implementation)? Just imagine what we could get if the vendors investing in Open Daylight decided to invest comparable amount of funding and resources into an open-source tool that would actually help their existing users manage their existing installed base.
Of course that will never happen; such a tool is not sexy and would not attract industry press attention, or result in conferences and summits one could attend. Obviously the only way to get such an open-source tool is to build it ourselves.
Fortunately there are people pushing things forward: building adaptation layer libraries and network-wide device configuration generators (video). Maybe it really is time to get on Kickstarter and fund an open-source equivalent of Tail-f’s NCS.
Hint: this is the point where you start writing a comment telling me such a tool already exists ... at least I hope you will. Thank you!
However, having such proxies might make things complicated.
I am a user of OpenWrt(not Cumulus) that supports "python-mini" as an optional package. It would be interesting to standardize "python-mini profile" (like Java MIDP) for other networking devices, so that "light-weight Salt Minion" and Salt modules can run directly on them.
I think you might be confusing our ConfD software, which is integrated into network elements and NCS, which is used to automate the management of large networks.
While the venerable RANCID toolkit certainly has its place for certain issues, I'd venture to say that it's more narrow in scope than what NCS is trying to do.
It's true that the "new shiny stuff" tends to attract more press and it's fun to get into debates about these topics that might not impact a lot of folks (at least not yet).
My hope is that more folks from these customer environments get into ODL and start contributing, because that's where the opportunity is right now. The power is in those little scripts and hacks that made their way into production environments because they solved a real problem right away. Others want to use them too!