WEBVTT 00:00:00.000 --> 00:00:06.240 So now we have to get ready for questions on the certification exam that are about data modeling. 00:00:07.680 --> 00:00:14.560 So what in the world is data modeling? Data modeling describes how data is represented, 00:00:15.200 --> 00:00:19.360 how it's going to be structured, how it's going to be accessed. 00:00:21.440 --> 00:00:26.080 It is something that is well understood and agreed upon. Typically it's going to be something 00:00:26.080 --> 00:00:30.959 that's standardized so that way there the whole world would abide by that standard. 00:00:31.920 --> 00:00:35.759 And therefore everything would be represented, structured, and accessed the exact same way 00:00:35.759 --> 00:00:41.599 no matter what device it's on. That way there we get consistency and we also get scalability. 00:00:42.720 --> 00:00:46.240 So if you're familiar with a relational database, if you are chatting yes, 00:00:46.240 --> 00:00:50.880 if you are not chatting no, but if you're familiar with relational databases like SQL databases, 00:00:51.200 --> 00:00:58.240 there's this thing called the schema with those databases. Your schema is your data model. 00:00:59.279 --> 00:01:03.360 Now if you don't know what a relational database is and you don't have any idea what a schema is, 00:01:03.360 --> 00:01:10.000 just forget I even said it. But here let me give you an example. So if we were building a database 00:01:10.000 --> 00:01:17.519 and one of our tables in our database was the person table, our schema, our data model 00:01:17.760 --> 00:01:25.440 defines the things that we have to have, the things that matter. For example, in our person table 00:01:25.440 --> 00:01:30.480 we might require gender. And then what are the options for gender? For example, would it be male, 00:01:30.480 --> 00:01:35.279 female, X, or not applicable? So you give the person the option not even to fill in their 00:01:35.279 --> 00:01:40.800 gender, right? That's something you have to decide. Height, feet, inches, or is it centimeters 00:01:41.760 --> 00:01:47.120 or meters? Weight, pounds or kilograms or both potentially, right? Hair color, 00:01:47.120 --> 00:01:49.839 what are the options for that? Eye color, what are the options for that? 00:01:50.959 --> 00:01:55.120 Date of birth, are you gonna display it as day, month, year, month, day, year, year, month, day? 00:01:56.080 --> 00:02:01.599 Your schema has to define this stuff so that way there when data is entered into the database, 00:02:01.599 --> 00:02:05.599 the schema can be checked to determine if it is accurate, if it's correct, 00:02:06.400 --> 00:02:09.759 right? And what is required, what is not required, what are optional? 00:02:10.479 --> 00:02:14.320 Values, meaning that maybe you don't have to put in your date of birth, maybe it's a must. 00:02:15.199 --> 00:02:17.839 Do you need your email address or do you not need your email address? 00:02:18.800 --> 00:02:25.199 So think about like a bank, the government, Best Buy, Amazon, right? They can use 00:02:25.839 --> 00:02:31.839 the data model, that standardized data model, however they so choose, right? 00:02:32.240 --> 00:02:36.720 So but the thing is, is that if you're going to identify a person, it's got to be identified 00:02:36.720 --> 00:02:41.520 particularly this way. So that's just a simple example, right? So when we're dealing with our 00:02:42.800 --> 00:02:49.199 newer paradigm of networking, where we're dealing with JSON formatted data, 00:02:49.759 --> 00:02:57.600 we're dealing with NetConf and RESTConf, we are dealing with a new set of protocols, 00:02:57.679 --> 00:03:06.080 a new set of services, a new set of features. And the industry came out with the YANG data model, 00:03:07.360 --> 00:03:16.399 YANG data model. It's a data modeling language used to model configuration and state data. 00:03:18.080 --> 00:03:22.639 So configuration and state data of what? Our routers, our switches, our access points, 00:03:22.639 --> 00:03:30.240 our wireless LAN controllers, anything. Now you see here NetConf is listed many, many times. So 00:03:30.240 --> 00:03:36.320 when the YANG data model was created, it would be manipulated, the data and the configuration, 00:03:36.320 --> 00:03:40.960 all that stuff using NetConf, self-bound API. Remember when we mentioned that? A self-bound 00:03:40.960 --> 00:03:47.520 API named RESTConf. But we also have RESTConf. I think I just said RESTConf. NetConf, right? 00:03:47.520 --> 00:03:52.639 We have NetConf. That's primary, but we also have RESTConf. So later on, we'll talk about the 00:03:52.639 --> 00:03:58.960 difference between NetConf and RESTConf. But both of those were where? Both of those were back here 00:03:58.960 --> 00:04:07.199 in our discussion of self-bound APIs. We had NetConf and RESTConf. So the YANG data model 00:04:08.160 --> 00:04:16.160 and the data that's contained within whatever it is we have, we can use NetConf and RESTConf 00:04:16.880 --> 00:04:19.519 for the transportation, the communication, the different things about that. 00:04:26.480 --> 00:04:29.920 So how is this different than our data format? 00:04:31.839 --> 00:04:36.959 So here is a data format. In this case, I thought I'd show you XML. 00:04:40.160 --> 00:04:45.519 Because typically when you're using NetConf, XML is being used. When you're using RESTConf, 00:04:46.559 --> 00:05:03.679 JSON is being used. So this is how our data has been formatted. So a data format. 00:05:04.160 --> 00:05:14.959 But what was used to determine what actually goes in here? What was used to determine that we need 00:05:16.799 --> 00:05:22.640 in discard packets, out packets, out octets, out error packets, out forward, out this, out that, 00:05:22.640 --> 00:05:27.279 in this, in that, in this, in, in, in, in, out, out, out. Who decided that? 00:05:27.679 --> 00:05:42.000 That's the YANG data model. So the YANG data model says you need to include this information. 00:05:43.519 --> 00:05:53.200 The data format says this is how it's formatted. So in this case, they are all using 00:05:54.000 --> 00:06:06.399 a particular module based on a YANG data model. And notice they're all the same, except 00:06:08.399 --> 00:06:14.880 they're just being displayed differently. So the YANG data model says this is what you have to 00:06:15.839 --> 00:06:22.720 have. This is what you need. And then these are the formats. So for the exam, make sure 00:06:23.279 --> 00:06:28.480 if they're talking about, hey, in a software defined networking solution, 00:06:31.359 --> 00:06:39.519 what is used to define what is going to be included as part of the information? 00:06:39.519 --> 00:06:44.160 Okay, that's your YANG data model. What is going to be used to determine the structure? 00:06:44.160 --> 00:06:49.679 That's the YANG data model, right? So structure here says interface type has to be this, 00:06:49.679 --> 00:06:54.640 admin status, that, blah, blah, blah, this, blah, blah, blah, that, okay? But how do you 00:06:54.640 --> 00:07:01.359 display it? How is it formatted after the fact? JSON, XML, YAML, doesn't matter. 00:07:03.040 --> 00:07:10.079 That's the difference between a model and a format. And this is why SNMP failed years ago 00:07:10.799 --> 00:07:19.200 to be that amazing protocol that we could use for configuration, verification, 00:07:19.760 --> 00:07:25.119 monitoring, et cetera, et cetera, et cetera. SNMP was actually considered 00:07:26.720 --> 00:07:32.079 as the protocol for software defined networking solutions. 00:07:32.079 --> 00:07:41.279 But because of the lack of consistency, because of the lack of structure, because of the lack 00:07:41.279 --> 00:07:51.279 of standardization across vendors, they said, no, can't do it. But they came out with YANG, 00:07:51.279 --> 00:07:58.160 the YANG data models. That way there, it doesn't matter who you are 00:07:59.679 --> 00:08:07.279 as a vendor of routers and switches and this and that and so on and so forth. Going forward, 00:08:08.799 --> 00:08:14.880 the YANG data model says that for this, you need this information. For that, 00:08:14.880 --> 00:08:17.839 you need this information. And this is how you structure it. 00:08:18.799 --> 00:08:25.839 So, for interfaces, this is what you need. For BGP, this is what you need. For OSPF, 00:08:25.839 --> 00:08:33.039 this is what you need. For that, this is what you need. So, there's gazillion models out there, 00:08:33.039 --> 00:08:38.080 models for interfaces and VLANs and ACLs and tunnels and dynamic routing protocols and syslog 00:08:38.080 --> 00:08:45.840 and even SNMP and MPLS and VRFs and system management and network faults and the list 00:08:45.919 --> 00:08:53.440 just goes on and on and on. Let me take you to GitHub where you can find your YANG data models. 00:09:01.359 --> 00:09:04.400 So, you'll see here that there's vendor-specific models. So, for example, 00:09:04.400 --> 00:09:07.440 I'll go to vendor. There's specific stuff for Cisco in here. 00:09:08.000 --> 00:09:14.799 Ciena, Nokia, Juniper, Huawei, Fujitsu. But here, we also have standards. 00:09:16.799 --> 00:09:22.000 So, for example, IETF standards, IEEE standards, IANA standards. So, if I click on IETF as an 00:09:22.000 --> 00:09:26.799 example, some of them are in draft right now where here are official RFC implementations. So, 00:09:26.799 --> 00:09:33.440 these are legit. This is what you're going to find on devices. So, modern-day Cisco equipment, 00:09:34.000 --> 00:09:40.640 let's scroll down here, bidirectional forwarding detection models, 00:09:42.400 --> 00:09:44.719 connection-oriented models, connectionless 00:09:45.919 --> 00:09:51.280 models, datastore models, fabric topology models. I'll keep going down. Some of this 00:09:54.320 --> 00:10:01.359 models for the RIB, IGMP, interfaces, IPv4 unicast writing, IPv6 routing, 00:10:01.359 --> 00:10:04.799 keychains, et cetera, et cetera, et cetera, et cetera, et cetera, et cetera. 00:10:04.799 --> 00:10:10.159 And then under the specific Cisco ones, for Cisco-specific things that aren't standard, 00:10:10.159 --> 00:10:12.320 you're going to find the Cisco-specific stuff in there as well. 00:10:13.520 --> 00:10:18.559 But let me just grab one of these right now. So, what is a YANG data model? Let's look at it. 00:10:19.200 --> 00:10:26.239 So, I like to use the IETF interface one. IETF interface, where are you? There it is right here, 00:10:26.239 --> 00:10:33.359 this one. Let me open it up. There you go. So, what is it? It's just a document 00:10:35.039 --> 00:10:43.039 that says if you have IETF interfaces and you plan on being part of this futuristic 00:10:43.039 --> 00:10:49.599 software-defined networking and you are a vendor of a product, then this is what you are going to 00:10:49.599 --> 00:10:56.000 have to provide as information and structure about those interfaces. 00:11:00.080 --> 00:11:06.400 But that is just for this particular data model. That's just this one right here. So, 00:11:06.400 --> 00:11:11.039 think about it. There's millions of data models out there for all the different parts, 00:11:11.039 --> 00:11:16.000 all the different aspects, all the different components. It's a lot. There's a lot going on 00:11:16.000 --> 00:11:22.239 here. So, in this particular case, this one is about, this module contains a collection of YANG 00:11:22.239 --> 00:11:27.039 definitions for managing network interfaces. So, it doesn't matter whether I'm Cisco, Juniper, 00:11:27.039 --> 00:11:32.320 Huawei, et cetera, et cetera, HP, it doesn't matter. I got to follow this. There's a revision, 00:11:32.320 --> 00:11:37.200 numbers, et cetera, et cetera, right, for the document. But you'll see here that it starts 00:11:37.200 --> 00:11:43.280 getting into the details here. And if we look at our container, so, for example, I have a container 00:11:43.280 --> 00:11:48.960 called interfaces here. And it's all about the interface parameters. So, the first thing first is 00:11:48.960 --> 00:11:54.559 we can list the interface. So, key is name, right? And so, then the value would be the actual 00:11:55.280 --> 00:12:00.000 name of the interface. And so, this list of interfaces for the device, the status of the 00:12:00.000 --> 00:12:04.799 interface available, okay? So, leaf, name. So, now we got to get it in leaf itself. So, name. 00:12:04.799 --> 00:12:09.919 So, this was about the interface itself. So, list interface. But now, the actual name of the 00:12:09.919 --> 00:12:18.960 interface. What does it have to be? It'll tell you what are the requirements for this. 00:12:21.840 --> 00:12:25.440 If you go down here, you'll see that it says the description. So, 00:12:25.440 --> 00:12:29.440 a textual description of the interface. So, a textual description of our interface 00:12:29.440 --> 00:12:39.520 show interface gigabit zero slash zero, right? There's the description right there, 00:12:39.520 --> 00:12:43.679 textual description of the interface. So, that is what that particular data model 00:12:44.400 --> 00:12:50.960 is referring to right now, the textual description of that particular interface. So, that 00:12:51.599 --> 00:12:56.239 is standardized now across all devices throughout the world, no matter who created them. 00:12:56.239 --> 00:13:07.599 All right. And it has to be that down here, the type of interface, right? Is it enabled or is it 00:13:07.599 --> 00:13:12.719 not? So, it's a Boolean value. It has to be a Boolean value. So, true or false. True, meaning 00:13:12.719 --> 00:13:20.080 enabled. False, meaning not enabled. So, the CLI, up, up, is true. Up, down, down, down, 00:13:20.080 --> 00:13:26.320 administratively down, that's false. All right. So, in the CLI, it's represented differently 00:13:26.320 --> 00:13:33.520 because the CLI is technically a data model in itself, formatted in a certain way, right? So, 00:13:33.520 --> 00:13:39.200 that's what we're trying to get you to understand here. It's just describing how everything must be 00:13:39.200 --> 00:13:43.760 so we have that standardization across all equipment throughout the entire world when it 00:13:43.760 --> 00:13:49.280 comes to this stuff in the future. So, that's all it is, a document. So, that's just one document. 00:13:49.280 --> 00:13:55.840 This is the one I just showed you describing the interfaces themselves. So, the data model 00:13:56.960 --> 00:14:03.760 says this is what you need to have for the IETF interfaces. And this is what you must do. 00:14:04.799 --> 00:14:09.039 And then how we represent that, how, not represent it, but how we see it 00:14:10.400 --> 00:14:15.760 can be in the JSON format, the XML format, the YAML format. 00:14:19.280 --> 00:14:30.400 So, what I did here to make it easier to understand the data model, folks, 00:14:31.200 --> 00:14:39.039 is I imported that data model document that I was just showing you in GitHub. I downloaded and 00:14:39.039 --> 00:14:45.919 brought it in on my Python computer. And I installed something called PYANG. And then I 00:14:45.919 --> 00:14:53.039 ran this command here. And what it did is it created a tree for that YANG data model for me. 00:14:53.599 --> 00:14:56.239 So, that way there we can see it. So, you don't have to know about this for the exam. I'm just 00:14:56.239 --> 00:15:03.280 telling you how I did this. So, now you're seeing a tree structure of that data model. 00:15:03.919 --> 00:15:11.440 I'm just trying to help you see this better. So, what are we looking at? The module is the IETF 00:15:11.520 --> 00:15:18.400 module. That's what it is. So, every single YANG document you see is a module in the world of YANG. 00:15:19.919 --> 00:15:26.080 This one is specifically dedicated to IETF interfaces. Then what do you have? Well, 00:15:26.080 --> 00:15:32.000 you have all of this. And then sub this, sub this, sub this, sub this, sub this. So, let's 00:15:32.000 --> 00:15:37.919 actually see what this is all about. So, what do we have? We have the module, as I said. 00:15:38.799 --> 00:15:43.599 So, the module defines the hierarchy of the data that can be used for NetConf-based operations. So, 00:15:43.599 --> 00:15:49.599 this specifically is about IETF interfaces. And then from there, you can see you have your 00:15:49.599 --> 00:15:56.640 container. So, in this case, this particular data model has two different containers. It does. This 00:15:56.640 --> 00:16:03.919 one has two containers. So, if we went back to the actual data model here, we would see it broken up 00:16:03.919 --> 00:16:08.320 into two different containers. So, here's container number one. So, I'm closer to the top. 00:16:12.400 --> 00:16:19.919 Oh, what did I do? No, I don't want that. All right. Fine, fine, fine. Oh, no. All right. So, 00:16:19.919 --> 00:16:23.280 and then, so container number one, if we scroll down, we'll find container number two, and it'll 00:16:23.280 --> 00:16:26.880 go from there. All right. So, that's all we've done here is broken that up. So, there's two 00:16:26.880 --> 00:16:33.919 containers in this one. And so, a container is about grouping a related node together. So, 00:16:36.640 --> 00:16:43.679 this container is called interfaces. And this container is called interfaces state. 00:16:45.760 --> 00:16:51.039 So, we have two containers. Now, inside of each container, we have a list. 00:16:52.000 --> 00:17:00.479 And the list identifies different nodes that are stored in sequence. So, for this interface 00:17:03.039 --> 00:17:11.119 or interfaces, we have a list called interface. For this container down here, 00:17:12.640 --> 00:17:17.920 called interface state, we have a list called interface. And that's okay. That's okay. Why? 00:17:18.400 --> 00:17:24.479 That's okay. Why? Because the list or, sorry, the container has a different name. You can have 00:17:24.479 --> 00:17:28.239 lists with the same name as long as they are in different containers. 00:17:31.040 --> 00:17:37.680 And then, when you look at the actual list itself, the list has what in it? Leafs. Leaf one, 00:17:37.680 --> 00:17:42.239 leaf two, leaf three, leaf four, leaf five, leaf six, seven, eight, nine, ten. And look at this. 00:17:42.239 --> 00:17:46.719 And so, the actual name of the interface, the description of the interface, the type of the 00:17:46.719 --> 00:17:52.239 interface, is it enabled or not, link up, down, admin status, operational status, last change, 00:17:52.239 --> 00:17:58.560 if index, ooh, that's that SNMP thing, remember? When I said, if index persist, well, there's the 00:17:58.560 --> 00:18:04.479 interface index number here as well. MAC address, higher layer interface information, lower layer 00:18:04.479 --> 00:18:09.280 interface information, speed, statistics. And likewise, this one down here, name, type, 00:18:09.280 --> 00:18:13.920 admin status, last change, if index, physical, right? Actually, does that look the same? 00:18:17.520 --> 00:18:22.160 The description is missing there, as well as some other things, all right? And then, so, 00:18:22.160 --> 00:18:27.119 those are all the leafs inside your containers. And then, what else do we have here? Every leaf 00:18:27.119 --> 00:18:31.680 must have a data type. So, here's our data type. So, this is a string, this is a string, this is a 00:18:31.680 --> 00:18:41.439 Boolean value, all right? So, the data model, the YANG data model called IETF interface, it says, 00:18:41.439 --> 00:18:47.040 this is how it has to be structured. This is what you have to have. So, it doesn't matter whether 00:18:47.040 --> 00:18:55.040 I'm a Cisco device, Juniper device, Huawei device, doesn't matter. If I access the IETF interfaces 00:18:55.040 --> 00:19:02.560 module, and I look at the information, it'll be structured like this, in the same type of, 00:19:03.439 --> 00:19:13.680 same type of data type, data type. And, therefore, when I access it, and read it, 00:19:15.119 --> 00:19:19.520 whether I'm accessing this device, or that device, or that device, from all these different vendors, 00:19:21.359 --> 00:19:28.560 and I'm using my favorite format, like JSON, or I have an application that takes that JSON data, 00:19:28.560 --> 00:19:34.000 I have an application that takes that JSON data, and then shows it to me in a graphical user 00:19:34.000 --> 00:19:44.160 interface instead, in a beautiful way, it doesn't matter what device it is. I can pull that 00:19:44.160 --> 00:19:49.199 information and see it. So, does that mean, in the end, we have consistency even across 00:19:49.760 --> 00:19:55.199 how we access that information across platforms? Yes, absolutely. 00:19:56.079 --> 00:20:00.239 I don't have to learn how to read the CLI of this product versus the CLI of that product 00:20:00.239 --> 00:20:07.280 versus the CLI of that product. It's all the same now. Structured the same way, 00:20:07.280 --> 00:20:14.560 the same details are going to be there. I can grab it and look at it. So, all I have to know 00:20:15.119 --> 00:20:22.719 is the way I access that information on that device, 00:20:25.280 --> 00:20:29.760 which is going to be pretty consistent as well, because if you're using NetConf, 00:20:29.760 --> 00:20:32.800 doesn't matter what device you're accessing it from, it's going to be the same way. 00:20:33.680 --> 00:20:37.760 RESTConf, doesn't matter what device I'm accessing it from, it's going to be the same way. 00:20:37.760 --> 00:20:48.959 All right. So, that's why we're doing this. That's why we're doing this. So, again, to remind 00:20:48.959 --> 00:20:54.479 you for the exam, the data model, it's all about the structure and what must be there. 00:20:55.439 --> 00:21:02.000 And then, your data format is how it's displayed. So, in this case, JSON is how we're displaying.