To YANG or Not to YANG, That’s the Question
Yannis sent me an interesting challenge after reading my short “this is how I wasted my time” update:
We are very much committed in automation and use Ansible to create configuration and provision our SP and data center network. One of our principles is that we do rely solely on data available in external resources (databases and REST endpoints), and avoid fetching information/views from the network because that would create a loop.
You can almost feel a however coming in just a few seconds, right?
Having said that, we are assessing options on how to maintain our network topology using a descriptive manner. Could be a database using a proprietary schema, but we'd definitely prefer a more standard way. I am not sure if YANG is suitable for this, and hence this message.
As Yannis asked my opinion on using YANG, let’s focus on that challenge first.
YANG is a data model description language – you can use it to describe how your data model looks like, for example what attributes you use to describe a router or IP subnet object.
For example, looking at the data model I used for my fabric:
- The fabric description has five attributes: fabric, interas, asn, services and nodes.
- Fabric and nodes attributes are mandatory, interas, asn and services attributes are optional.
- If the model has interas attribute, it must have asn attribute.
- Fabric attribute is a list of dictionaries (in Python terms, you could also model it as a relational database table);
- Each element of the fabric attribute must have left, right, left_port and right_port attributes. Left_ip, right_ip and cost attributes are optional.
If I had had too much time, I could have created a YANG data model describing these restrictions and used it to validate my data model. Alas, I have better things to do, and it seems there are no tools out there to do that.
YANG is thus not the answer to the question. OpenConfig might be, depending on what data you want to handle. I know customers using OpenConfig with extensions in their automation solutions, and David Barroso is working hard to make it part of NAPALM.
If you’re interested in the technical realities of OpenConfig (as opposed to marketing nirvana), listen to the Software Gone Wild podcast with Marcel Wiget, who was also the guest speaker in the Data Models part of my network automation online course.
http://blogs.cisco.com/sp/simplifying-network-programmability-with-model-driven-apis