So let's see this from an end-to-end perspective and really drill into some of
the differences
in our terminologies here.
So let's say that we have some subnets come online.
We've got this router up here.
We'll call these routers 1, 2 and 3.
And router 1 has learned that it has three subnets.
Well, router 1 is going to register these and the registration message actually
goes to
the MS.
So this is the value of the map server if it's a different node compared to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is the value of the map server if it's a different node compared to the
map resolver.
So this is the register message.
I'm registering that A, B and C are all attached to me.
So I know that again A, B and C EIDs.
These are going to be mapped to router 1 where once again these are the EIDs
and router
1, it's going to have some IP address that we're using as the RLoc.
So I now have an EID to RLoc mapping here on the MS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I now have an EID to RLoc mapping here on the MS.
Meanwhile router 2 also needs to register.
It's going to register subnets D and E. And likewise with router 3, we won't
draw the
whole line all the way across, but we're going to send that register to the MS
for subnets
F and G.
So that's the first step because the database that we're building needs to have
all of the
mappings.
Now, here's the thing.
These mappings actually get stored here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
These mappings actually get stored here.
So the map resolver is actually going to have all of the mappings because it's
going
to handle the element that allows these edge routers to pull the information
out on an
as needed basis.
And so we're going to use different message types for this.
So let's say that a packet arrives on router 1 and it's destined for subnet F.
Well, router 1 is at this point going to be considered the ingress tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, router 1 is at this point going to be considered the ingress tunnel
router.
So the ITR.
And it is going to need to figure out where to send this packet.
So now we're going to send a special type of message that's going to request
this.
And this is known as a map request message.
So this map request message is saying, hey, I need to figure out where to send
a packet
to subnet F.
Now assuming that we did all of our registration, which we've said we have, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now assuming that we did all of our registration, which we've said we have, we
know that subnet
F is mapped to router 3.
So again, our endpoint identifier here and our RLoc over here.
Now we might expect that we're just going to send the response back from the MR
.
And the default operation for Lisp actually doesn't do this.
Instead, the MR is going to forward this map request.
Where's it sending it?
Well, believe it or not, we're going to send it all the way over here to what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, believe it or not, we're going to send it all the way over here to what
is the
ETR in this topology and the specific traffic flow.
So I actually forward this map request over here.
So this is our map request.
And the reason for this, there's actually a few reasons.
But one of them is just to make sure that it's still valid because router 3 won
't reply
to this if it doesn't actually have that mapping anymore. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to this if it doesn't actually have that mapping anymore.
And so at that point, maybe that subnet moved or we lost the route, there could
be all kinds
of issues happening in here.
Who knows, maybe there's a better path to get to subnet F at this point.
But assuming all goes to plan, we now know to send our response back over to
the ETR.
And this takes the form of a map reply.
And now we know the same information. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now we know the same information.
We know that F is attached to router 3 and we can actually cache this
information.
Now we don't want to replicate the problem of having the full internet routing
table,
but I can cache some amount of these entries.
And hey, I can also remove those entries from my cache.
If I continue to get packets destined for subnet F, then I would want to keep
that in the
cache.
So I don't have to go through this whole process again.
But if the traffic dries up and I don't have more traffic going out to subnet F WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if the traffic dries up and I don't have more traffic going out to subnet F
, then
eventually I will remove that entry from the cache.
So that's just a way that we can improve the operations without, again,
creating the
same problem we had before and storing every single EID to our lock mapping.
That is the job again of the MR and the MS is to maintain that database for us.
Now remember, from a data plane perspective, we are going to encapsulate that
into a list
tunnel.
And that's going to be encapsulated IP in IP/UDP and it's going to be forwarded WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's going to be encapsulated IP in IP/UDP and it's going to be forwarded
out wherever
it needs to go, ultimately through the network to get to router 3.
So most of what we're talking about here is control plane operation, the data
plane at
the end of the day just fires it off inside of a tunnel.
And so there's not as much to talk about there.
Now there's a couple of other scenarios to be aware of here.
Or maybe I should say there is another scenario to be aware of and that is what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or maybe I should say there is another scenario to be aware of and that is what
happens if
I get a packet in here that's once again destined for subnet W.
Well we don't have subnet W list here inside of the list environment.
Each one of these locations is known as a list site and that subnet has to
exist in a
list site otherwise it's not part of our domain.
And so what do we do?
Well what we do is the exact same process.
I'm going to send, oops not a registration message, but I am going to send a
map request WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
map request
to the MR.
The difference here is the MR is going to send a response that we call a
negative map reply.
This says I don't know where that is and if I don't know where it is then he no
one knows
where it is.
That's the rule of the list I guess.
So instead what we're going to do is we are still going to use the data plan
for encapsulation
but I'm going to send it to the nearest PETR as we explained in the previous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but I'm going to send it to the nearest PETR as we explained in the previous
video.
I'm going to see that packet arrive here and get forwarded out into the non-l
isp domain.
Hoping that the routing tables that exist out there will get me to my
destination and
further most part that's exactly what's going to happen.
Now what's interesting about this is there has to be return traffic and if
there's return
traffic that means that the routers out here that they have routes to subnet's
a and b
and c and d and e and f and g here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and c and d and e and f and g here.
Like we've got to have all of these routes.
Well how do these routes know or how do these routers beyond the list domain
know where
all these subnets are?
Well how else do we propagate routes but with a routing protocol.
So our PETR here is going to be sending our list routes.
It's going to advertise them up into this domain up here.
So this edge router is going to be responsible for learning routes and exch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this edge router is going to be responsible for learning routes and exch
anging routing
information with the rest of the world which means not only is it sharing our
list
routes but it's also learning non-lisp routes.
Now importantly I never register.
And never do a registration for the non-lisp routes that goes against
everything we're trying
to accomplish here.
Furthermore I can't tunnel list outside of the list domain.
So I'm not going to advertise those internally.
I'm going to keep those to myself and I'm going to rely on this proxy concept WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to keep those to myself and I'm going to rely on this proxy concept
as we said
essentially be the default route.
So I don't need to know where all of those routes are.
I just need to know what to do with a packet that arrives if I don't know where
else to
to send it and that's going to take me to the proxy XTRs.