So now we have to get ready for questions on the certification exam that are about data modeling.
So what in the world is data modeling? Data modeling describes how data is represented,
how it's going to be structured, how it's going to be accessed.
It is something that is well understood and agreed upon. Typically it's going to be something
that's standardized so that way there the whole world would abide by that standard.
And therefore everything would be represented, structured, and accessed the exact same way
no matter what device it's on. That way there we get consistency and we also get scalability.
So if you're familiar with a relational database, if you are chatting yes,
if you are not chatting no, but if you're familiar with relational databases like SQL databases,
there's this thing called the schema with those databases. Your schema is your data model.
Now if you don't know what a relational database is and you don't have any idea what a schema is,
just forget I even said it. But here let me give you an example. So if we were building a database
and one of our tables in our database was the person table, our schema, our data model
defines the things that we have to have, the things that matter. For example, in our person table
we might require gender. And then what are the options for gender? For example, would it be male,
female, X, or not applicable? So you give the person the option not even to fill in their
gender, right? That's something you have to decide. Height, feet, inches, or is it centimeters
or meters? Weight, pounds or kilograms or both potentially, right? Hair color,
what are the options for that? Eye color, what are the options for that?
Date of birth, are you gonna display it as day, month, year, month, day, year, year, month, day?
Your schema has to define this stuff so that way there when data is entered into the database,
the schema can be checked to determine if it is accurate, if it's correct,
right? And what is required, what is not required, what are optional?
Values, meaning that maybe you don't have to put in your date of birth, maybe it's a must.
Do you need your email address or do you not need your email address?
So think about like a bank, the government, Best Buy, Amazon, right? They can use
the data model, that standardized data model, however they so choose, right?
So but the thing is, is that if you're going to identify a person, it's got to be identified
particularly this way. So that's just a simple example, right? So when we're dealing with our
newer paradigm of networking, where we're dealing with JSON formatted data,
we're dealing with NetConf and RESTConf, we are dealing with a new set of protocols,
a new set of services, a new set of features. And the industry came out with the YANG data model,
YANG data model. It's a data modeling language used to model configuration and state data.
So configuration and state data of what? Our routers, our switches, our access points,
our wireless LAN controllers, anything. Now you see here NetConf is listed many, many times. So
when the YANG data model was created, it would be manipulated, the data and the configuration,
all that stuff using NetConf, self-bound API. Remember when we mentioned that? A self-bound
API named RESTConf. But we also have RESTConf. I think I just said RESTConf. NetConf, right?
We have NetConf. That's primary, but we also have RESTConf. So later on, we'll talk about the
difference between NetConf and RESTConf. But both of those were where? Both of those were back here
in our discussion of self-bound APIs. We had NetConf and RESTConf. So the YANG data model
and the data that's contained within whatever it is we have, we can use NetConf and RESTConf
for the transportation, the communication, the different things about that.
So how is this different than our data format?
So here is a data format. In this case, I thought I'd show you XML.
Because typically when you're using NetConf, XML is being used. When you're using RESTConf,
JSON is being used. So this is how our data has been formatted. So a data format.
But what was used to determine what actually goes in here? What was used to determine that we need
in discard packets, out packets, out octets, out error packets, out forward, out this, out that,
in this, in that, in this, in, in, in, in, out, out, out. Who decided that?
That's the YANG data model. So the YANG data model says you need to include this information.
The data format says this is how it's formatted. So in this case, they are all using
a particular module based on a YANG data model. And notice they're all the same, except
they're just being displayed differently. So the YANG data model says this is what you have to
have. This is what you need. And then these are the formats. So for the exam, make sure
if they're talking about, hey, in a software defined networking solution,
what is used to define what is going to be included as part of the information?
Okay, that's your YANG data model. What is going to be used to determine the structure?
That's the YANG data model, right? So structure here says interface type has to be this,
admin status, that, blah, blah, blah, this, blah, blah, blah, that, okay? But how do you
display it? How is it formatted after the fact? JSON, XML, YAML, doesn't matter.
That's the difference between a model and a format. And this is why SNMP failed years ago
to be that amazing protocol that we could use for configuration, verification,
monitoring, et cetera, et cetera, et cetera. SNMP was actually considered
as the protocol for software defined networking solutions.
But because of the lack of consistency, because of the lack of structure, because of the lack
of standardization across vendors, they said, no, can't do it. But they came out with YANG,
the YANG data models. That way there, it doesn't matter who you are
as a vendor of routers and switches and this and that and so on and so forth. Going forward,
the YANG data model says that for this, you need this information. For that,
you need this information. And this is how you structure it.
So, for interfaces, this is what you need. For BGP, this is what you need. For OSPF,
this is what you need. For that, this is what you need. So, there's gazillion models out there,
models for interfaces and VLANs and ACLs and tunnels and dynamic routing protocols and syslog
and even SNMP and MPLS and VRFs and system management and network faults and the list
just goes on and on and on. Let me take you to GitHub where you can find your YANG data models.
So, you'll see here that there's vendor-specific models. So, for example,
I'll go to vendor. There's specific stuff for Cisco in here.
Ciena, Nokia, Juniper, Huawei, Fujitsu. But here, we also have standards.
So, for example, IETF standards, IEEE standards, IANA standards. So, if I click on IETF as an
example, some of them are in draft right now where here are official RFC implementations. So,
these are legit. This is what you're going to find on devices. So, modern-day Cisco equipment,
let's scroll down here, bidirectional forwarding detection models,
connection-oriented models, connectionless
models, datastore models, fabric topology models. I'll keep going down. Some of this
models for the RIB, IGMP, interfaces, IPv4 unicast writing, IPv6 routing,
keychains, et cetera, et cetera, et cetera, et cetera, et cetera, et cetera.
And then under the specific Cisco ones, for Cisco-specific things that aren't standard,
you're going to find the Cisco-specific stuff in there as well.
But let me just grab one of these right now. So, what is a YANG data model? Let's look at it.
So, I like to use the IETF interface one. IETF interface, where are you? There it is right here,
this one. Let me open it up. There you go. So, what is it? It's just a document
that says if you have IETF interfaces and you plan on being part of this futuristic
software-defined networking and you are a vendor of a product, then this is what you are going to
have to provide as information and structure about those interfaces.
But that is just for this particular data model. That's just this one right here. So,
think about it. There's millions of data models out there for all the different parts,
all the different aspects, all the different components. It's a lot. There's a lot going on
here. So, in this particular case, this one is about, this module contains a collection of YANG
definitions for managing network interfaces. So, it doesn't matter whether I'm Cisco, Juniper,
Huawei, et cetera, et cetera, HP, it doesn't matter. I got to follow this. There's a revision,
numbers, et cetera, et cetera, right, for the document. But you'll see here that it starts
getting into the details here. And if we look at our container, so, for example, I have a container
called interfaces here. And it's all about the interface parameters. So, the first thing first is
we can list the interface. So, key is name, right? And so, then the value would be the actual
name of the interface. And so, this list of interfaces for the device, the status of the
interface available, okay? So, leaf, name. So, now we got to get it in leaf itself. So, name.
So, this was about the interface itself. So, list interface. But now, the actual name of the
interface. What does it have to be? It'll tell you what are the requirements for this.
If you go down here, you'll see that it says the description. So,
a textual description of the interface. So, a textual description of our interface
show interface gigabit zero slash zero, right? There's the description right there,
textual description of the interface. So, that is what that particular data model
is referring to right now, the textual description of that particular interface. So, that
is standardized now across all devices throughout the world, no matter who created them.
All right. And it has to be that down here, the type of interface, right? Is it enabled or is it
not? So, it's a Boolean value. It has to be a Boolean value. So, true or false. True, meaning
enabled. False, meaning not enabled. So, the CLI, up, up, is true. Up, down, down, down,
administratively down, that's false. All right. So, in the CLI, it's represented differently
because the CLI is technically a data model in itself, formatted in a certain way, right? So,
that's what we're trying to get you to understand here. It's just describing how everything must be
so we have that standardization across all equipment throughout the entire world when it
comes to this stuff in the future. So, that's all it is, a document. So, that's just one document.
This is the one I just showed you describing the interfaces themselves. So, the data model
says this is what you need to have for the IETF interfaces. And this is what you must do.
And then how we represent that, how, not represent it, but how we see it
can be in the JSON format, the XML format, the YAML format.
So, what I did here to make it easier to understand the data model, folks,
is I imported that data model document that I was just showing you in GitHub. I downloaded and
brought it in on my Python computer. And I installed something called PYANG. And then I
ran this command here. And what it did is it created a tree for that YANG data model for me.
So, that way there we can see it. So, you don't have to know about this for the exam. I'm just
telling you how I did this. So, now you're seeing a tree structure of that data model.
I'm just trying to help you see this better. So, what are we looking at? The module is the IETF
module. That's what it is. So, every single YANG document you see is a module in the world of YANG.
This one is specifically dedicated to IETF interfaces. Then what do you have? Well,
you have all of this. And then sub this, sub this, sub this, sub this, sub this. So, let's
actually see what this is all about. So, what do we have? We have the module, as I said.
So, the module defines the hierarchy of the data that can be used for NetConf-based operations. So,
this specifically is about IETF interfaces. And then from there, you can see you have your
container. So, in this case, this particular data model has two different containers. It does. This
one has two containers. So, if we went back to the actual data model here, we would see it broken up
into two different containers. So, here's container number one. So, I'm closer to the top.
Oh, what did I do? No, I don't want that. All right. Fine, fine, fine. Oh, no. All right. So,
and then, so container number one, if we scroll down, we'll find container number two, and it'll
go from there. All right. So, that's all we've done here is broken that up. So, there's two
containers in this one. And so, a container is about grouping a related node together. So,
this container is called interfaces. And this container is called interfaces state.
So, we have two containers. Now, inside of each container, we have a list.
And the list identifies different nodes that are stored in sequence. So, for this interface
or interfaces, we have a list called interface. For this container down here,
called interface state, we have a list called interface. And that's okay. That's okay. Why?
That's okay. Why? Because the list or, sorry, the container has a different name. You can have
lists with the same name as long as they are in different containers.
And then, when you look at the actual list itself, the list has what in it? Leafs. Leaf one,
leaf two, leaf three, leaf four, leaf five, leaf six, seven, eight, nine, ten. And look at this.
And so, the actual name of the interface, the description of the interface, the type of the
interface, is it enabled or not, link up, down, admin status, operational status, last change,
if index, ooh, that's that SNMP thing, remember? When I said, if index persist, well, there's the
interface index number here as well. MAC address, higher layer interface information, lower layer
interface information, speed, statistics. And likewise, this one down here, name, type,
admin status, last change, if index, physical, right? Actually, does that look the same?
The description is missing there, as well as some other things, all right? And then, so,
those are all the leafs inside your containers. And then, what else do we have here? Every leaf
must have a data type. So, here's our data type. So, this is a string, this is a string, this is a
Boolean value, all right? So, the data model, the YANG data model called IETF interface, it says,
this is how it has to be structured. This is what you have to have. So, it doesn't matter whether
I'm a Cisco device, Juniper device, Huawei device, doesn't matter. If I access the IETF interfaces
module, and I look at the information, it'll be structured like this, in the same type of,
same type of data type, data type. And, therefore, when I access it, and read it,
whether I'm accessing this device, or that device, or that device, from all these different vendors,
and I'm using my favorite format, like JSON, or I have an application that takes that JSON data,
I have an application that takes that JSON data, and then shows it to me in a graphical user
interface instead, in a beautiful way, it doesn't matter what device it is. I can pull that
information and see it. So, does that mean, in the end, we have consistency even across
how we access that information across platforms? Yes, absolutely.
I don't have to learn how to read the CLI of this product versus the CLI of that product
versus the CLI of that product. It's all the same now. Structured the same way,
the same details are going to be there. I can grab it and look at it. So, all I have to know
is the way I access that information on that device,
which is going to be pretty consistent as well, because if you're using NetConf,
doesn't matter what device you're accessing it from, it's going to be the same way.
RESTConf, doesn't matter what device I'm accessing it from, it's going to be the same way.
All right. So, that's why we're doing this. That's why we're doing this. So, again, to remind
you for the exam, the data model, it's all about the structure and what must be there.
And then, your data format is how it's displayed. So, in this case, JSON is how we're displaying.