Earlier in the chapter, we looked at the possibility of expressing the network using data modeling language YANG. Let's look into it a little bit.

First off, we should know that YANG only defines the type of data sent over NETCONF protocol, and NETCONF exists as a standalone protocol as we saw in the NX-API section. YANG, being relatively new, has a spotty supportability across vendors and product lines. For example, if we run the same capability exchange script that we have used before to a Cisco 1000v running IOS-XE, this is what we will see:

    urn:cisco:params:xml:ns:yang:cisco-virtual-service?module=cisco-
    virtual-service&revision=2015-04-09
    http://tail-f.com/ns/mibs/SNMP-NOTIFICATION-MIB/200210140000Z?
    module=SNMP-NOTIFICATION-MIB&revision=2002-10-14
    urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-
    hash&revision=2014-04-04&features=crypt-hash-sha-512,crypt-hash-
    sha-256,crypt-hash-md5
    urn:ietf:params:xml:ns:yang:smiv2:TUNNEL-MIB?module=TUNNEL-
    MIB&revision=2005-05-16
    urn:ietf:params:xml:ns:yang:smiv2:CISCO-IP-URPF-MIB?module=CISCO-
    IP-URPF-MIB&revision=2011-12-29
    urn:ietf:params:xml:ns:yang:smiv2:ENTITY-STATE-MIB?module=ENTITY-
    STATE-MIB&revision=2005-11-22
    urn:ietf:params:xml:ns:yang:smiv2:IANAifType-MIB?module=IANAifType-
    MIB&revision=2006-03-31
    <omitted>

Compare this to the output that we saw; clearly IOS-XE understands the YANG model more than NX-OS. Industry wide network data modeling for networking is clearly something that is beneficial to network automation. However, given the uneven support across vendors and products, it is not something that is mature enough to be used across your production network, in my opinion. For this book, I have included a script called cisco_yang_1.py that shows how to parse out the NETCONF XML output with YANG filters called urn:ietf:params:xml:ns:yang:ietf-interfaces as a starting point to see the existing tag overlay.