I’ve been on a learning kick as of late, and at least as of this week I’m concentrating on security and programmability (not necessarily together). I’ve started going through the DevNet modules and got into some interesting labs and reading around YANG and NETCONF. Truthfully, I had kind of avoided these things because they weren’t absolutely necessary to the programmability stuff I had done previously with ACI. But every once in a while I get the urge to get back to fundamentals, or really the foundation of things which brought me to this DevNet module.
There’s some great information in there, but that led me to this amazing Cisco Live session from @scadora. Here’s what I learned…
There are three fairly common network management protocols: NETCONF, RESTCONF, and gRPC. Of course I’m leaving out SNMP on purpose here. I’m really only talking about the protocols we can use with model driven APIs, and from my reading I’ve also learned that SNMP just really can’t keep up with the amount of data we expect these days. Okay, so these three protocols are really about transport…how we’re delivering or communicating the information.
NETCONF
- Uses XML encoding
- Goes over HTTP 1.1
RESTCONF
- Uses XML or JSON encoding
- Uses the same tools as REST, but is not the same as say a REST API
gRPC
- Uses Google Protocol Buffers (GPB encoding)
- Goes over HTTP2
- Allows you to create your own CRUD methods
You’ll notice in the bullets above I suggest which encoding each transport protocol uses. NETCONF can use XML, RESTCONF uses XML or JSON, and gRPC uses GPBs. The encoding is really the format in which the machine can read the calls we are sending it (or some other machine or service is sending it). Machines have trouble just reading human language so we have to send it a format it expects. XML is a bit older and is not very easily read by humans so many people prefer JSON. JSON is still formatted for a machine, but it’s a lot easier for the human mind to comprehend. GPB is really just numbers, no strings. So essentially, as Shelly Cadora describes in her Cisco Live presentation, you would need to have a decoder ring to understand it.
Now that we understand the role of transport and encoding, let’s talk about the data model. YANG (Yet Another Next Generation) has become a standard data modeling language, at least in the world of network devices. What it actually reminds me of is a class in an object oriented programming language. For example if I had a car data model it might look like this:
Car
- Door – 4 door
- Top – convertible
- Engine – 4 cylinder
- Color – blue
The YANG model tells us what the machine is looking for, while the encoding describes the actual information for the specific device or feature. Cadora describes it as the YANG data model would be the cookie cutter, while the encoding would be the cookie itself…the thing which can be consumed.
So who creates these YANG models? Of course standards bodies like the IETF, and open source project committees, but also vendors (like Cisco…disclaimer…I work there). So to give an example, Cisco might create a new switch. If we want the switch to be “programmable” we’ll use Yang models and create APIs so that everything within that switch, like interfaces, software features, etc. can be communicated with using something like NETCONF, RESTCONF, or gRPC. Each interface may have several configurable features, such as speed, duplexing, on/off, etc and we’d have that YANG model to describe what can be configurable programmatically. Of course, we can also use model driven APIs to just gather (GET) information as well.
Another pretty cool tool, which I’ve only seen now a couple times and haven’t really played with is the YANG Explorer. It’s open to everyone on GitHub. It actually reminds me a lot of the API Inspector in Cisco ACI. It let’s you upload YANG models, but will also give you ways to create XML or even convert your calls to simple Python scripts. Definitely worth a look…
More shameless plugs…if you’re interested in learning more about programmability, check out the recent Datanauts podcast I was on chatting about Network Automation and Programmability.
Reach out to me on Twitter if you have any comments, questions, or feedback telling me I’m totally wrong about something! @malhoit