YANG, NETCONF, RESTCONF Demos. Which Cisco devices are supported? (Part 1)

everyone it's David bumble coming to you from Oxford in the United Kingdom I'm gonna call again with Hank Preston who's based in the US Hank and I have been discussing based on your questions topics to discuss and we've got a long list of topics to talk about but in this video hank is going to hopefully talk about young models you know what what is that and net conf so Hank welcome to the call again it's great to have you absolutely David things for having me back really looking forward to this because a lot of people seem to struggle with net conf and yang models and yang seems really complicated so I'm hoping that you can kind of shed some light on it and you know explain it to a network engineer top of person yeah no I I'm looking forward to it's it's one of my favorite topics to talk about partially because it was the first topic and network programmability that I jumped into when I joined the definite team it's actually it's a bit of an interesting story that like my first week I was in a training and one of the topics was net comp in yang and rest comp and so I went through the training that was being that was going through and going into it and I just didn't feel like I understood it as well as I wanted to um I had a ton of questions we were I was engaging in dialogue and chatter with the other engineers and folks that were in the room and and it was one of those that I was like I just I felt like we could do a better job at explaining kind of how these topics go together and like any good comment like that it was assigned to me as my first job kind of as I came in to Deb net it was like we'll see what you can do with it and so that was the the first one I drove into and so I'm I've kind of really fallen in love a little bit with kind of explaining and talking about kind of all of this model driven programmability which is kind of the the generic term for these types of interfaces where there's there's a data model and we'll talk exactly about what a data model is and then you use that model to actually kind of interface with the device or the devices that are there other than kind of just particular API calls like everything is focused around this data model and for the network yang is the the term that kind of dives into what when we see here the word yang that's what we referred to or all these data models these representations of what the devices have and what you can do with them on that side and so I think will be a good discussion you're really looking forward and I believe you've also got a demo where you can show us practically how this works I'm assuming it's another dev net demo yeah it is yeah well we'll go through so we can we can jump over to start out here and so what I've opened up here is just a terminal window and we'll spend probably a lot of today in terminal windows and an interactive Python pieces as we dive through and so sometimes we always talk about Netcom thing kind of in that format net comp yang net comp yang but one of the first things I realized as I was diving into it is it makes more sense to start with the yang side of it because yang is where we're talking about the types of data what it is we're looking through and I've used the word data model a couple of times and so if I do like a quick LS dash L what we see here are a handful of dot yang files and so what these dot yang files are Alex I highlight this one because it's the one we'll be talking a bunch about is yang at its heart is an IETF standard and it's a standard for a modeling language to write data models and so before we look at the yang let's make sure we're on the same page about what a data model is I describe data models as this kind of intuitive way that we all understand some object that's out there and so I leave networking behind usually when I introduce this and the idea is let's think about the concept of a person or a people or a group of people and by and large everybody out there has an it has just kind of baked into their psyche what a person is right a person is has a height here in the States we do feet and inches everywhere else in the world pretty much does does meters and centimeters as it goes through but people have height people have hair color and eye color or lack of hair if they don't have it people have ages there's genders there's there's skintone there's all of these things and so because everybody in the world kind of understands the concept of a person basically the same way we can give descriptions to folks and say you know what go find Hank write Hanks about almost six feet tall he wishes he was six feet but he's not quite six feet tall he's got brown hair he's got brown eyes a little bit of facial hair going on and he's Caucasian and so with a description like that pretty much everybody in the world can understand in general what Hank is right and because we all have this built in data model we can describe and talk about people does that make sense yeah so it's like attributes or descriptions of something right exactly and so when we talk about yang what yang is yang was this standard that was written in the ITF and it is a language to build and describe data models for kind of computer programming and now you can use yang to describe a data model for anything and in fact if you go look at the RFC which I don't necessarily recommend to everybody but sometimes it's good to go back to the RFC's you'll find that the the data models that they use in the examples have nothing to do with networking because they didn't want to tie the yang language to networking however the vast majority of practical uses of Yang are for data models related to the network and so what a yang model is is it's a very descriptive way to describe some elements of the network and so I highlighted here the ietf interfaces yang file and so that is a text file will open in just a second that is the IETF description of a standard way to talk about what an interface looks like and so you'll also find yang models for what is the way to describe an access control list an ACL or a routing protocol or or anything else you can think about you might want to describe and talk about in the in the network and so the importance of having these data models is if the vendors of the equipment say okay we're gonna use this data model this is how we're going to describe an interface and then network engineers like you and I can say okay we know what the interface is we're all kind of on that same page about what an interface is and then software vendors people building network management systems can use those samyang models and say okay that's what a network interface is and so there's this very strong consistency we all agree upon what an interface looks like and that seems so obvious right we all know what it interfaces but if you think about it the way an interface is configured and described even within Cisco's portfolio across iOS iOS X C and X OS X are these of pieces traditionally the data model that we had was a very kind of loose data model focused on the Cisco configuration and CLI commands that went in and that's okay if the person using it is kind of you or I and we're just kind of reading and interfacing with a CLI but when you're writing interactive programs or Python scripts or a network management system it's really important to have a very strong and consistent data model for these things that go across and so that's really what yang is is it's this way to say okay everybody is going to agree very wholeheartedly and this is what the data models look like and I'm gonna start out before we look at the actual yang language I'm gonna we're gonna show it this data model in the way that I typically work with it as an operator which is in kind of a formatted function and I'm going to use a Python program called peeing or PI yang depends on how you want to say it to go ahead and represent this I'm gonna use PA - f that's for format and I'm going to format it in just a text tree and we're going to look at the ietf interfaces yang file and so what P Aang does is it reads through the yang language file and then represents it in a format that we asked for and in this case I asked for it to represent it in this text-based tree format and so what we see here is this is the yang model for the ietf interfaces and we can kind of start to dive into what the yang models include um at the top level we see these things here we see this plus indication and then our W interfaces and then at that same level in the tree down here is this plus and then ro interfaces state and what these indicate these are top-level container objects inside of the data model because if we think about an interface most network devices have more than one of them and so the yang has this concept of a container object and so we've got an interfaces container that container will contain one or more interface objects and so we can see here we've got the interface object that goes through each interface needs to be able to be uniquely identified and so inside of a container every item there has to be some attribute that is considered the key attribute kind of that unique attribute and that's what this name inside of square brackets indicates this says that every interface will be uniquely identified by its name that's what the where it goes through on that and then underneath the interface we see it each interface will also have a series of attributes or properties and so an interface has a name a description a type an enabled status and then kind of trap enable pieces and from the IITs perspective this is what an interface configuration would look like now I use the word configuration because this RW indication at the beginning of this everything inside of this container indicates that these are readwrite attributes and if we think about it a readwrite attribute that's something we can configure down below we see all of these ro attributes ro are read-only attributes and those would be operational status and so that's the other piece that yang models give us these yang models give us the ability to not just deal with configuration of the network device but also kind of the current state the statistics information about it and so in this ro area called interface state right so it's the state of a particular interface we see it also has interfaces and they're keyed off of by name just like the interface configuration and then we see the RO attributes the operational attributes and some of them seem similar right name so we'll have a read-only status or a name we'll have type admin status operational status and then we can see all the counter statistics information that are in there and so the data model gives us this ability to say okay we can configure an interface we can set its description we can set its type we can set its name things like that and then we can also read the status of this interface using the interfaces State element of this model that goes through a pause for a second see if you've got any questions on that bit so far yes so I mean just as an analogy I think we mentioned this before this is like a mob in SNMP was that too far a jump no no that's a perfect one and that's actually the the best example of kind of where yang came from and where net comp came from is it's the evolution of our our standard protocols for managing the network and what we typically have had have been SNMP as kind of the way we connect and talk to a device and then MIBs have been kind of that data model for the SNMP world and so the yang is definitely the best analogy you can think about is to emit and it's a description that goes through on that side am I joke sometimes that that net comp fin yang would have been called like SNMP v4 if we didn't think that that would have just ticked people off and kind of given everybody the wrong taste of it on that side but in general that's really what we're looking at is this next generation update of kind of the SNMP style of interfacing with the device but what I noticed she has it's a lot easier to read because mob saw her ringed us exactly yeah for me that's one of the things I I mean I've used SNMP for years I there were certain moobs I know how to go into but to be honest right I didn't know how to find the specific mid for a particular attribute I kind of relied on network management tools to kind of do a mid walk figure out what was there go figure something out what I like about dealing with the yang data models is they are fairly consumable right I can read this I know what an interface is I don't have to know the 1 dot 2 dot right it's much easier to say it's ITF interfaces and then interfaces state that's how I get the statistics and it's also read write read only similar to kind of like SNMP kind of set up yeah yep absolutely so while we're looking at this one of the other things I want to talk about is some of the terminology that goes into the eating models and so I already used the word container right so we've got the containers and we've got two of them in this model we've got an interfaces container and then we've got the interfaces state container now all of these attributes that are here the name the description the type inside of yang those are referred to as Leafs and so every attribute every property that's inside of the data model that will hold some piece of data yang refers to those as Leafs and this is one of the other things that super confused me when I first started working with net comp yang is I would hear the term leaf and by that point I had already kind of figured out in the context of networking what a leaf was and a leaf represented kind of an edge switch in a spine leaf topology and so I mean it it took me forever to realize that when when talking about Yang and hearing the word leaf it had nothing to do with a leaf node in a topology it was just this attribute and so that's the other big piece to kind of recognize as we dive in is that you'll hear these terms leaf sore when we talk about accessing or going into a leaf with a yang model all we're talking about is just one piece of data one attribute one one element of information that we're interested in so we would say the name leaf or the in octet sleeve these are pieces of information and that's that's another big one I think having some of these just terminology and how to work with it will help people get miles ahead as they kind of dive into some of these new protocols agreed I mean when you mentioned containers I was thinking docker which has got nothing to do with it yeah and then leaves yes finally leave so it's got nothing to do with this planet leaf architecture all right so what I like about this view and using the p-n tool is this is what I like to call kind of the network operators you are the consumer of the yang model and I would say that this is where most network engineers probably should stay is using something like PN to investigate it this way but it's also interesting to kind of look at what the native yang language looks like so let's go ahead and look at what the actual text file for this looks like so remember I was able to show the the interesting bits of this model basically on my screen here all by itself I can everything I'm interested in I can see what's there but if I go ahead and instead I'll use the just the the tool-less to print out the the raw text and so we'll say IETF interfaces yang and there so now what we've dope into is I'm just looking at the raw text and so now what we're seeing is the yang language and this is what the IETF standard really is the IETF standard is not about what an interface looks like or what a routing protocol is the yang standard is just how we write these text files and if you are a software vendor if you are a hardware vendor and it's your responsibility to kind of build a yang model to share with operators to on how to go through these are the folks that are actually working in the yang language to write these and it's not that these aren't readable right it's pretty easy to go through and say okay this is the IETF interfaces module and a module in the yang framework is is is one of these models right model a modular are loosely interchangeable as terms as they go through and so this is the module or the model from the ITF about the interfaces we see this reference to namespace what a namespace is and we'll see more about namespaces when we dive into net conf as we're working with the a models but this is how inside of net comp we can distinguish between different yang models that a device might support because ever any one network switch or router will likely support dozens if not hundreds of different yang models for different aspects of the configuration from different sources and so there needs to be a unique way to identify a particular yang model and that's this namespace concept and so we can see this is the way that this will be named spaced and we'll see that in other areas we'll see the organization so there's all this metadata contact information kind of who was responsible for writing this model and if I scroll down we'll see the description we'll see revision information so this this version of this model happened to be the 2014 from may revision and there's been other revisions that have gone through if I scroll down a little bit farther we'll see type definition I didn't mention it before but it's we saw them in there if you were looking at the peeing output every leaf had a type that was either a string or a date time might have been an interface type and the yang language the standard states that every leaf needs to have a very specific type associated with it and so as a developer or user you know what to expect so when you request something about an IP address it's going to come back and it's gonna look like an IP address and there's a very specific way that those IP addresses will be represented same thing with physical addresses on that side and so we'll see types that are in here we'll see identities and features these are all elements of kind of how these models go through and then finally way down here and I don't know what line I'm on but I'm quite a bit down we finally get into this reference to container interfaces so everything above this from an operator's perspective we don't have to pay that much attention to those details we get into the container interfaces which is what we are interested in and now we see all of this extra detail we see the description that goes in we'll see okay there's inside the container there'll be a list of interfaces we see the key of name we scroll down some more and we'll see all of the the Leafs that are there my my personal opinion is that this type of a layout from a general network operators you is probably way more information and way more verbose than a typical network engineer trying to consume a young model needs great time that's why I always go back to that PN because it makes it so much easier it hones in on the specific information that I'm after but you can always go back and you can look at the details that are inside of the yang file so we can see leaf name we see all these pieces we can see the very specific descriptions and details about every leaf just couldn't go in here but in general a network operator probably doesn't have to deal with the raw yang files that often that make sense yeah so I mean just for comfort we don't as network engineers we don't have to create a yang model Cisco's doing that and you doing that using the yang language so a developer at Cisco or someone he's using the yang language if I if I'm saying that right to create a yang model for a Cisco some router is that right yet actually in that yeah that's perfect and that's actually a good place good segue into the next topic we should go through is is who creates the yang models and where do we get them um you mentioned Cisco creates them and so indeed we do and every every software hardware network vendor out there is likely creating a models specific for their their devices but if you'll note the one that we've been looking at so far is called IETF interfaces and so that's the other thing that's really nice about this this kind of moved to net comp and yang and these standard models is that cisco in addition to writing our own models we also support the ones that are coming from the standards community and so the IETF has written and provided yang models for representing network concepts and so this was the interfaces one there's also an organization called open config and open config isn't an official standards body like the IETF is what open config is is kind of a consortium of network operators service providers software vendors hardware vendors who are coming together in saying okay let's figure out effective models of effective descriptions for network pieces that we can use commonly across vendors that are there and so that some of the members of opening figure companies like AT&T and Verizon BT Telecom Cisco's in their junipers in there and so everybody's coming together and saying okay we need to describe what a vrf looks like what a virtual routing and forwarding fabric looks like and cisco has their way of doing a Juniper as their way of doing it each operator each service provider may have their own way they think about what a vrf looks like and so what they do inside the open config is they say okay let's come together and let's agree upon what a vrf looks like or what bgp routing looks like and so they create a yang model and says ok this is a yang model out of the open config and it's our description of how we want to deal an interface with with this type of a network thing like a vrf or something like bgp and then it gets put out there and then vendors like Cisco can say ok we're going to support the open config models in addition to the IETF models that go through because we because in general the open config models are far more complete than what you might get out of the IETF I like the IETF models for things like teaching concepts and kind of understanding the basics of how something like net copying and rest kind of work but fundamentally most folks are not going to find all of the flexibility that they want or work through the IETF models more often they're going to use a model from open config which are very common or the other source and we started here is is they're often called kind of native models and a native model would be a model from the software or hardware vendor themselves and so cisco has native models for iOS XE and nx-os and that what you'll find in the native models are the things that are unique to those platforms from those from those vendors or inside of that software and so open config is going to support I always like to say that's that's the common aspects of something like BGP but those those specific innovations those things that that make Cisco's implementation and BGP kind of their kind of value add or specific way that they look at it and the specific way that juniper does it and everybody else odds are good we're not gonna see those things make it into a standard model from the IETF or open config but we still want to make sure that customers can consume those capabilities through yang models like this and that's where the native models come through on that side does that make sense yeah it does so I mean you mentioned iOS XE as an example and they would be what you would just to summarize native models are Cisco models that we can interrogate or use by net confer to change something or just pull back stats and then you've got open config which is like a consortium of vendors and people and then you've got the IETF so one of the first things as the network engineer that I would need to find out about if I want to use net conf is which models some device supports so to be the cynical network engineer that I am Cisco IOS Rada from five years ago isn't gonna help me kind of thing is that right yep so you're so on that one so you definitely one of the first steps you want to do when working with the device through Netcom of these models is to understand what they support and that loosely will call those capabilities and so what are the capabilities what are the what are the data models that are supported and so we'll talk in a minute about how you can figure that out and so the question about something from five years ago does it support it it's a very valid question and we have to go through on this so if we think about inside of iOS space so is our routers catalyst switches ASR routers that type of portfolio the Netcom yang features came in inside of what we call the kind of the denali release code and in general this means 16 to 16 3 and higher and so if you do have a bunch of 3750 v2s or 36 50 so the the older switches out there that are running code and they can't be upgraded to the to the the newer iOS XE ma software versions then yes unfortunately you're not gonna be able to take advantage of these pieces there because the interfaces weren't there yeah that doesn't mean 5-year old stuff wasn't isn't supported if you go back and you look at some of the Nexus portfolio um one of the things that's interesting is some of the data center equipment and the largest service provider equipment has been supporting some of these protocols for for many many years from the get-go the initial shipping of some of the nx-os switches they had net comp support actually a net comps support before the yang standard and the hanging models were there and so we've seen a lot of these protocols out there for years but you definitely do need to make sure that what's supported where I wasn't let me bring up real quick how you can figure out what some of those details are or is it so I'm gonna go to a page I'm up on definite developer dat cisco.com slash net Kampf net comp there it goes and I'm gonna make the page a bit bigger so we can read it and so this is a page we maintain up on dev net around model driven programmability and so you'll find details on this page for all of the things that fall in so this is in addition to yang and net comp you'll also see references to rest comp which is a rest api version and way to consume the egg models and then gr PC which is Google RPC it's another transport protocol in addition to net comp and rest comp that you can use with yay models but on this page down near the bottom and I'll scroll down whoops here it is we've put together a chart that shows kind of which platforms what software versions support the different protocols and things that are there oh this is great and so from a net right yeah and and the reason that we don't say yang called out here is because the yang models and the capabilities list those are easy to find in another location we'll jump to in just a second but what's more important to understand is when are the transport protocols how we actually communicate with a device and so if yang is like mid Netcom 4s conf and G RPC are like SNMP versions that are there and so this chart says okay these iOS XE has supported net comp and here's the RFC version of net comp on the catalyst 4500 since iOS XE 3.91 on iOS XE across these these platforms since 16.3 on the catalyst 9 k 16 6 which is actually the first version of software that the catalyst 90k shipped with on that side and so you can see from there if you you leverage the iOS XR platform it's actually had it for quite a long time here so you can see when it's been supported there and then the same thing on an X OS and so you'll notice down here we've got support across the portfolio for those and then on the yang model support and so we'll look in a minute when we actually get into kind of the Netcom area how you can you Net Kampf itself to ask a device what models are supported but one of the things that I really like about working with net conf and yang is how easy it is to find some of these details so I'm make this bigger so we can see it easier so up on github there's an organization called yang models and then in in there there's a repo yang and this is a location where you can find the ietf as well as vendor specific models from Cisco as well as a lot of different vendors that are there and so for example if I come down here and we'll start with the standard so I can go into the standard folder and then I can see that the ietf the I Triple E MEF ODP these are where you can find these standard organizations what their models look like and what their definitions are and so if I go into the IETF and then I can see that they've got draft and RFC versions of these and then if I look will actually find there it is right there IETF interfaces yang so this is that model we were looking at so we can find the yang file right up on github and we can find these across the standards if I go back to the top of the repo and I look in the vendor 4 folder we'll see that Cisco huawei juniper and Sienna all post their models and their models support up in the same place that goes through so we'll dive into the Cisco folder in here I can see that I've got NX OS x CX r and so we'll stick with XE for a moment so I'll look at XE I'll see in here that we've got folders based on software versions and so this is the 16 3 version 16 dot 3.1 16.3 dot-to-dot 4.1 and so we'll be working I think the demo will be going on today is on 16 but when I go into this folder now I can see them all of the models that are supported in their references that are there from the native perspective and so here what we're seeing these references are the Cisco IOS XE Triple A yang that is the Cisco native model to describe Triple A authentication that's there that's great I can see a CL ARP and all of these and so it's very it really is quite simple to find out what are the models that are supported and then get access to them so that you can use a tool like P yang to actually inquire and navigate through them as they go through you'll notice on Cisco IOS here we'll see quite a few models that are there because the way that the the native model structure is done for Cisco IOS is we've we've modularized the yang models and so the one that you actually start out with is a model called native and let me find it in the list here there it is and so the the top-level model is this one that's called native and that's where you start out with and then native then kind of imports all of these other ones and it makes it easier for the software developers the yang developers to say you know what I only want to work on the mpls portion and so they can MPLS gets pulled out into a zone yang model they focus in on that they can make changes there without having to change the one gigantic model that's there and there are different different approaches to dealing with the models and in the iOS XE team decided to use this kind of modular fashion so that they can say okay we're gonna have MPLS defined here we're gonna have nat defined here we're gonna have ntp to find here rather than having one one model that defines them all inside it you'll actually see the opposite approach was taken by the nx-os team there's a single nx-os native model that kind of has everything in it rather than these other ones that go through i'm having worked with both there I can see pluses and minuses on both side of those it just kind of comes down to what the what the the particulars in the models decides on that side for that that makes sense so I had one question I had is on that list of devices I didn't see Cisco CSR virtual routers if I was if I wanted to use Gianna 3 or something else to practice this or is that supported it is I'll flip back it should have been listed probably missed it right there yeah yeah that's what that's what he's acting for so that's great I know it is because all of our learning labs actually use a CSR 1000v in a sandbox so when I jump to the the live demo I'll be using our public CSR to make all the queries against so but that's great so I mean that means if I wanted to practice this I could I could use the dev net labs or I could have a CSR and just play with that yeah and that's that's one of the things that I really like about working with these things today is it's so much easier than the old days of having to hit eBay and trying to find a switch so many things are available through different virtual platforms and that it's it's so easy to go through and the from a production network perspective the question about old gear is super valid but from a learning about it perspective it is so easy to say ok you know what you want to learn about this go go grab the csr version or go grab the nexus 9000 v version or nearly every vendor is providing virtual versions of their pieces and so the csr 1000v is a great way to explore and learn about and in fact it's it's what we use in all of our learning labs that I wrote on these topics that's great mm-hmm all right so that hits some of those pieces on that side let's I'm going to jump back over here to the the terminal window and so that's that's the yang pound ation that's there the next thing I want to talk about is let's talk about where does net comp fit into this and so the yang standard the a models are just a description of these different types of things we want to talk about it's a data model that says okay an interface is going to look like this writing protocol looks like this net comp is what I call the transport protocol side of this net comp has no idea what it interfaces but net conf knows how to connect to a device securely it knows how to authenticate it knows how to package up a request and send a request to retrieve information or send configuration details in there and so net comp is the protocol that we actually use to reach out and communicate with some device that's out there on that side now net comp is one protocol rest comp is another protocol and so net comp will talk and we'll see in a minute net comp runs over the top of SSH it's kind of built in that typical kind of network framework moving over the SSH protocol leverages XML under the hood rest comp kind of in the vein of rest api style so rest comp runs over HTTP it leverages REST API standards like headers and authentication pieces that are in there but both Metcalf and rest comp points and leverage the exact same yang models that are there and so if a device supports for example this IETF interfaces model I can communicate with the device over either net comp or rest comp and get access to all of the same details that are there that part makes sense yeah that's great so I mean I wanted to ask you that's and you've you've explained it so that's great just to summarize net conf is better than SNMP because it's more secure well one of many benefits because it's leveraging SSH risk on basically uses REST API so kind of is it correct to say that's kind of like HTTP HTTPS type of REST API swears net confuses SSH yes yes yep yeah so Nick and will see this and I'm actually gonna grab my notes and will show how we can actually use a typical SSH interface to send neck kind of commands and then we'll look at the real way we'll do it after that and then with rest comp will go over HTTP okay it is a it's a it's a rest based protocol but with the standard for rest comp the decision was made when they finally standardized it to not support clear text HTTP and so some of the early drafts of rest comp actually let you go over port 80 without having to do any kind of security and encryption and all those other pieces when they finally standardized it they said you know what why even bother supporting the clear text it doesn't make any sense in this day and age and so standard rest comp requires HTTPS for security on that side that's the one piece to go through and kind of keep in mind as you see that that make sense yeah sorry I don't want to keep popping it too long but quickly why would I use one over the other you mean rest comp versus Netcom yes so if if the devices support both it comes down to I would say two factors the first one is personal preference if you prefer to use rest conf as a rest api then there's a great reason to use it a lot of people and I'm just getting myself prepped here for a second a lot of people use rest comp because they prefer the REST API interaction and so that's a great one and personally I'm in that same bucket if given the choice I'll use a REST API over using an on REST API because they're simply use the interfaces are super easy they kind of match a lot of the patterns we're going in other places the other reason you might use go to net Kampf is net comp was the first transport protocol that was standardized by the standards bodies it is more mature and so you'll actually find lots of devices actually most networked devices today don't support standard rest conf and I usually caution folks about kind of spending a lot of time on draft versions of rest half because you may find the things that we're done in draft got changed later on and it's it's not it can be confusing because you you thought you learned it one way and now it's changed to something else and so I caution on that side and so device support is one reason why you may not be able to use rest conf and the other one is is rest con finet comp from a basic configuration and operational details perspective are pretty at parity if I want to configure an interface or get details on a protocol I can do that from both in that confident rest cough but when we start to look at some of the other types of use cases things like streaming telemetry when you want to subscribe to something or fee details in some of those more advanced use cases around model-driven programmability aren't supported in a rest comp they're only supported in net comp so it's kind of it's a long and complicated answer if I had to shorten it down to two pieces the first one is most people will start with with rest kalfa fits supported if it's not supported go to neck go to Netcom you have to learn that comp because that is the one that is supported on most of the devices today and then the second piece is if you're trying to do something more advanced you may find yourself needing to use neck cuff on that side I actually don't know if that was any shorter an explanation than the first one I did but but that's kind of that's great I mean rather more details better so that that's great so moving forward which one do you thinks gonna win if you like you know so that's an opinion question I my when we look out when we have robust and kind of support all over the place for rest comp I think we'll find most network engineers application developers are are going to rest comp because the rest api syntax that's there however I think network management software vendors folks like SolarWinds or even Cisco are platforms that do network management will probably prefer net Kampf because of some of the efficiencies that it offers because of some of the things that it does under the hood and so I honestly don't think one will win out over the other there they're both be supported but may be used by different people for different types of purposes that's great and I don't want to diverge too much but you mentioned a Google protocol as well like you had three in that that list is that is that like a new emerging supposedly good thing replacement or just another option so today it's it's definitely emerging I would say that today it's a it's another option G RPC for Google RPC it came out from the guys at Google because they wanted a standard and common way to interface with basically everything in their data center so whether it was a switch a router a server a micro service they wanted everything to be able to kind of run over the same type of transport protocol and so they created this this G RPC protocol to do for that I'm it's a great point I totally agree with Google on the side being able to kind of consume and work with everything using the same protocols makes it ton of sense and so I think we'll see it up to go through however what we're actually finding is most of the use cases for G RPC are not for the typical configuration or operational queries if you want to configure an interface you're not ghost people aren't you're not using G RPC for that if you just want to go out and reach hey what are the current statistics or stats about this particular routing protocol G RPC is probably not for use for that we're GRP see fits in is what what I you what I usually call these days model driven telemetry and the reason I hesitated for a second there is some of these things don't haven't really settled in on a specific name that is kind of gonna be what what the industry agrees on yeah um it's sometimes also called streaming telemetry and it's this concept of an idea of rather than going out and pulling your device for telemetry or health or statistics every five seconds or 30 seconds or rather than setting a device up to send traps based on some sort of a piece streaming telemetry or model driven telemetry say okay we're just gonna set up kind of this this connection between the the collection system and then the devices that are there and then any any piece of information as soon as that piece of information happens out at an edge we're going to stream that kind of is near to real-time as possible up to the collection devices that use case of the streaming or this model driven telemetry is where G RPC really is used today and I honestly think we're it's its primary use case is going to be around those types of pieces not not these these kind of configuration use cases or like the query based operational use cases that are there though that again some of that's just my opinion based on what I'm seeing today and talking with folks that could change over time kind of as these different protocols mature more so well that's great it's always nice to get your opinion and I don't have muddied the waters so at some point either now or later will you tell us you know if I'm new to this where to start so I'm assuming we should start with Yang and net conf enlight on moving to these other things but yeah sorry I've kind of took taken us on a tangent here sorry Hank oh no they were there great dialogue I will say well definitely so one of the things we'll probably end is with this discussion and then we'll make sure that the links are included with the video our recommended places to get started and so I mentioned at the very start of the video that the first project I undertook when I joined the Divinity noit's to try to make it easier to understand and go through these and so I've written and then updated a handful of learning labs on yeah Netcom Andres Kampf and those are great places to start they talk through the fundamentals you get the chance to interact live with our sandbox equipment there's code samples that walk through and explain how they all work I always tell start there I've also done some video lessons as part of the video course that we've talked about in previous videos that kind of walk through more of these pieces I think that's another great spot for folks this is a good introduction go watch those videos you kind of get to see me work through some slides some more demo examples on the topics and then the learning labs that are there so we'll make sure links to all those resources are included in the video correct [Music]

Channel: David Bombal

Views: 29,812

Rating: 4.9357944 out of 5

Keywords: YANG, NETCONF, RESTCONF, Python, Python or CCNA, Python or Ansible, NetDevOps, Net-DevOps, DevOps, Cisco Python, Python Cisco, Cisco Ansible, Cisco NETCONF, Cisco RESTCONF, Cisco Automation, Network Automation, Network Programmability, Cisco DevNet, DevNet, Learn Python, Learn Ansible, Learn NETCONF, Cisco APIs, APIs, Cisco API, Cisco API Router

Id: cooE3wZ7O4I

Length: 44min 50sec (2690 seconds)

Published: Sun Sep 02 2018