WEBVTT 1 00:00.000 --> 00:04.240 So let's see this from an end-to-end perspective and really drill into some of 2 00:04.240 --> 00:04.960 the differences 3 00:04.960 --> 00:06.840 in our terminologies here. 4 00:06.840 --> 00:10.240 So let's say that we have some subnets come online. 5 00:10.240 --> 00:11.600 We've got this router up here. 6 00:11.600 --> 00:16.520 We'll call these routers 1, 2 and 3. 7 00:16.520 --> 00:19.560 And router 1 has learned that it has three subnets. 8 00:19.560 --> 00:25.480 Well, router 1 is going to register these and the registration message actually 9 00:25.480 --> 00:26.080 goes to 10 00:26.080 --> 00:27.560 the MS. 11 00:27.560 --> 00:33.600 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 11 00:27.560 --> 00:33.600 So this is the value of the map server if it's a different node compared to the 12 00:33.600 --> 00:35.200 map resolver. 13 00:35.200 --> 00:38.040 So this is the register message. 14 00:38.040 --> 00:42.280 I'm registering that A, B and C are all attached to me. 15 00:42.280 --> 00:47.920 So I know that again A, B and C EIDs. 16 00:47.920 --> 00:53.420 These are going to be mapped to router 1 where once again these are the EIDs 17 00:53.420 --> 00:54.360 and router 18 00:54.360 --> 00:59.240 1, it's going to have some IP address that we're using as the RLoc. 19 00:59.240 --> 01:04.480 So I now have an EID to RLoc mapping here on the MS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:59.240 --> 01:04.480 So I now have an EID to RLoc mapping here on the MS. 20 01:04.480 --> 01:06.840 Meanwhile router 2 also needs to register. 21 01:06.840 --> 01:12.770 It's going to register subnets D and E. And likewise with router 3, we won't 22 01:12.770 --> 01:13.160 draw the 23 01:13.160 --> 01:18.600 whole line all the way across, but we're going to send that register to the MS 24 01:18.600 --> 01:19.280 for subnets 25 01:19.280 --> 01:21.280 F and G. 26 01:21.280 --> 01:25.390 So that's the first step because the database that we're building needs to have 27 01:25.390 --> 01:26.000 all of the 28 01:26.000 --> 01:27.000 mappings. 29 01:27.000 --> 01:28.200 Now, here's the thing. 30 01:28.200 --> 01:31.800 These mappings actually get stored here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:28.200 --> 01:31.800 These mappings actually get stored here. 31 01:31.800 --> 01:37.250 So the map resolver is actually going to have all of the mappings because it's 32 01:37.250 --> 01:37.760 going 33 01:37.760 --> 01:43.610 to handle the element that allows these edge routers to pull the information 34 01:43.610 --> 01:44.280 out on an 35 01:44.280 --> 01:46.160 as needed basis. 36 01:46.160 --> 01:49.280 And so we're going to use different message types for this. 37 01:49.280 --> 01:55.240 So let's say that a packet arrives on router 1 and it's destined for subnet F. 38 01:55.240 --> 02:00.920 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 38 01:55.240 --> 02:00.920 Well, router 1 is at this point going to be considered the ingress tunnel 39 02:00.920 --> 02:01.840 router. 40 02:01.840 --> 02:03.840 So the ITR. 41 02:03.840 --> 02:08.200 And it is going to need to figure out where to send this packet. 42 02:08.200 --> 02:15.210 So now we're going to send a special type of message that's going to request 43 02:15.210 --> 02:15.280 this. 44 02:15.280 --> 02:20.100 And this is known as a map request message. 45 02:20.100 --> 02:25.750 So this map request message is saying, hey, I need to figure out where to send 46 02:25.750 --> 02:26.480 a packet 47 02:26.480 --> 02:28.320 to subnet F. 48 02:28.320 --> 02:33.120 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 48 02:28.320 --> 02:33.120 Now assuming that we did all of our registration, which we've said we have, we 49 02:33.120 --> 02:34.320 know that subnet 50 02:34.320 --> 02:37.760 F is mapped to router 3. 51 02:37.760 --> 02:42.760 So again, our endpoint identifier here and our RLoc over here. 52 02:42.760 --> 02:48.430 Now we might expect that we're just going to send the response back from the MR 53 02:48.430 --> 02:48.640 . 54 02:48.640 --> 02:52.880 And the default operation for Lisp actually doesn't do this. 55 02:52.880 --> 02:57.880 Instead, the MR is going to forward this map request. 56 02:57.880 --> 02:58.880 Where's it sending it? 57 02:58.880 --> 03:03.990 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 57 02:58.880 --> 03:03.990 Well, believe it or not, we're going to send it all the way over here to what 58 03:03.990 --> 03:04.520 is the 59 03:04.520 --> 03:09.200 ETR in this topology and the specific traffic flow. 60 03:09.200 --> 03:13.800 So I actually forward this map request over here. 61 03:13.800 --> 03:18.360 So this is our map request. 62 03:18.360 --> 03:21.560 And the reason for this, there's actually a few reasons. 63 03:21.560 --> 03:25.600 But one of them is just to make sure that it's still valid because router 3 won 64 03:25.600 --> 03:26.120 't reply 65 03:26.120 --> 03:30.320 to this if it doesn't actually have that mapping anymore. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 03:26.120 --> 03:30.320 to this if it doesn't actually have that mapping anymore. 66 03:30.320 --> 03:35.670 And so at that point, maybe that subnet moved or we lost the route, there could 67 03:35.670 --> 03:36.360 be all kinds 68 03:36.360 --> 03:38.560 of issues happening in here. 69 03:38.560 --> 03:43.840 Who knows, maybe there's a better path to get to subnet F at this point. 70 03:43.840 --> 03:50.200 But assuming all goes to plan, we now know to send our response back over to 71 03:50.200 --> 03:50.960 the ETR. 72 03:50.960 --> 03:56.960 And this takes the form of a map reply. 73 03:56.960 --> 04:00.040 And now we know the same information. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 03:56.960 --> 04:00.040 And now we know the same information. 74 04:00.040 --> 04:05.590 We know that F is attached to router 3 and we can actually cache this 75 04:05.590 --> 04:07.080 information. 76 04:07.080 --> 04:10.570 Now we don't want to replicate the problem of having the full internet routing 77 04:10.570 --> 04:11.080 table, 78 04:11.080 --> 04:14.440 but I can cache some amount of these entries. 79 04:14.440 --> 04:17.760 And hey, I can also remove those entries from my cache. 80 04:17.760 --> 04:21.700 If I continue to get packets destined for subnet F, then I would want to keep 81 04:21.700 --> 04:22.160 that in the 82 04:22.160 --> 04:23.160 cache. 83 04:23.160 --> 04:25.280 So I don't have to go through this whole process again. 84 04:25.280 --> 04:30.970 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 84 04:25.280 --> 04:30.970 But if the traffic dries up and I don't have more traffic going out to subnet F 85 04:30.970 --> 04:31.280 , then 86 04:31.280 --> 04:34.640 eventually I will remove that entry from the cache. 87 04:34.640 --> 04:38.410 So that's just a way that we can improve the operations without, again, 88 04:38.410 --> 04:39.040 creating the 89 04:39.040 --> 04:44.160 same problem we had before and storing every single EID to our lock mapping. 90 04:44.160 --> 04:49.680 That is the job again of the MR and the MS is to maintain that database for us. 91 04:49.680 --> 04:54.710 Now remember, from a data plane perspective, we are going to encapsulate that 92 04:54.710 --> 04:55.600 into a list 93 04:55.600 --> 04:58.040 tunnel. 94 04:58.040 --> 05:06.590 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 94 04:58.040 --> 05:06.590 And that's going to be encapsulated IP in IP/UDP and it's going to be forwarded 95 05:06.590 --> 05:08.200 out wherever 96 05:08.200 --> 05:12.840 it needs to go, ultimately through the network to get to router 3. 97 05:12.840 --> 05:16.090 So most of what we're talking about here is control plane operation, the data 98 05:16.090 --> 05:16.480 plane at 99 05:16.480 --> 05:19.880 the end of the day just fires it off inside of a tunnel. 100 05:19.880 --> 05:22.760 And so there's not as much to talk about there. 101 05:22.760 --> 05:26.720 Now there's a couple of other scenarios to be aware of here. 102 05:26.720 --> 05:30.350 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 102 05:26.720 --> 05:30.350 Or maybe I should say there is another scenario to be aware of and that is what 103 05:30.350 --> 05:30.920 happens if 104 05:30.920 --> 05:35.600 I get a packet in here that's once again destined for subnet W. 105 05:35.600 --> 05:40.400 Well we don't have subnet W list here inside of the list environment. 106 05:40.400 --> 05:45.460 Each one of these locations is known as a list site and that subnet has to 107 05:45.460 --> 05:46.240 exist in a 108 05:46.240 --> 05:50.440 list site otherwise it's not part of our domain. 109 05:50.440 --> 05:51.960 And so what do we do? 110 05:51.960 --> 05:54.440 Well what we do is the exact same process. 111 05:54.440 --> 05:58.940 I'm going to send, oops not a registration message, but I am going to send a 112 05:58.940 --> 06:00.280 map request WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 05:58.940 --> 06:00.280 map request 113 06:00.280 --> 06:01.920 to the MR. 114 06:01.920 --> 06:08.450 The difference here is the MR is going to send a response that we call a 115 06:08.450 --> 06:12.440 negative map reply. 116 06:12.440 --> 06:16.710 This says I don't know where that is and if I don't know where it is then he no 117 06:16.710 --> 06:17.240 one knows 118 06:17.240 --> 06:18.240 where it is. 119 06:18.240 --> 06:20.480 That's the rule of the list I guess. 120 06:20.480 --> 06:25.390 So instead what we're going to do is we are still going to use the data plan 121 06:25.390 --> 06:26.800 for encapsulation 122 06:26.800 --> 06:32.360 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 122 06:26.800 --> 06:32.360 but I'm going to send it to the nearest PETR as we explained in the previous 123 06:32.360 --> 06:33.200 video. 124 06:33.200 --> 06:39.690 I'm going to see that packet arrive here and get forwarded out into the non-l 125 06:39.690 --> 06:41.080 isp domain. 126 06:41.080 --> 06:44.440 Hoping that the routing tables that exist out there will get me to my 127 06:44.440 --> 06:45.160 destination and 128 06:45.160 --> 06:48.120 further most part that's exactly what's going to happen. 129 06:48.120 --> 06:52.490 Now what's interesting about this is there has to be return traffic and if 130 06:52.490 --> 06:53.420 there's return 131 06:53.420 --> 06:57.980 traffic that means that the routers out here that they have routes to subnet's 132 06:57.980 --> 06:59.200 a and b 133 06:59.200 --> 07:01.680 and c and d and e and f and g here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 06:59.200 --> 07:01.680 and c and d and e and f and g here. 134 07:01.680 --> 07:04.240 Like we've got to have all of these routes. 135 07:04.240 --> 07:09.240 Well how do these routes know or how do these routers beyond the list domain 136 07:09.240 --> 07:09.560 know where 137 07:09.560 --> 07:11.360 all these subnets are? 138 07:11.360 --> 07:15.280 Well how else do we propagate routes but with a routing protocol. 139 07:15.280 --> 07:23.040 So our PETR here is going to be sending our list routes. 140 07:23.040 --> 07:26.760 It's going to advertise them up into this domain up here. 141 07:26.760 --> 07:31.720 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 141 07:26.760 --> 07:31.720 So this edge router is going to be responsible for learning routes and exch 142 07:31.720 --> 07:32.800 anging routing 143 07:32.800 --> 07:36.270 information with the rest of the world which means not only is it sharing our 144 07:36.270 --> 07:36.560 list 145 07:36.560 --> 07:40.120 routes but it's also learning non-lisp routes. 146 07:40.120 --> 07:43.680 Now importantly I never register. 147 07:43.680 --> 07:47.250 And never do a registration for the non-lisp routes that goes against 148 07:47.250 --> 07:48.280 everything we're trying 149 07:48.280 --> 07:49.600 to accomplish here. 150 07:49.600 --> 07:53.000 Furthermore I can't tunnel list outside of the list domain. 151 07:53.000 --> 07:55.600 So I'm not going to advertise those internally. 152 07:55.600 --> 08:00.510 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 152 07:55.600 --> 08:00.510 I'm going to keep those to myself and I'm going to rely on this proxy concept 153 08:00.510 --> 08:01.200 as we said 154 08:01.200 --> 08:03.560 essentially be the default route. 155 08:03.560 --> 08:06.760 So I don't need to know where all of those routes are. 156 08:06.760 --> 08:10.790 I just need to know what to do with a packet that arrives if I don't know where 157 08:10.790 --> 08:11.240 else to 158 08:11.240 --> 08:14.880 to send it and that's going to take me to the proxy XTRs.