1 00:00:01,360 --> 00:00:03,359 Join us as we gather around the hedge, 2 00:00:03,359 --> 00:00:04,740 where we dig into technology, 3 00:00:05,040 --> 00:00:07,759 business, and culture with the finest minds in 4 00:00:07,759 --> 00:00:08,740 computer networking. 5 00:00:20,574 --> 00:00:21,714 Good morning, Tom. 6 00:00:22,254 --> 00:00:25,074 Good morning, Russ. First of two today. 7 00:00:25,934 --> 00:00:27,250 Mhmm. We know we're gonna be a good 8 00:00:27,250 --> 00:00:29,289 day. Two. It's gonna be a long day. 9 00:00:29,289 --> 00:00:30,890 Lots of recordings. You have to put up 10 00:00:30,890 --> 00:00:33,469 with me a lot. Yep. So I hesitate 11 00:00:33,530 --> 00:00:35,369 to ask, but what's on the floor in 12 00:00:35,369 --> 00:00:36,009 front of your 13 00:00:37,289 --> 00:00:37,850 this is, 14 00:00:38,655 --> 00:00:40,574 it's a little step ladder thing to make 15 00:00:40,574 --> 00:00:42,655 it so you can put a ladder on 16 00:00:42,655 --> 00:00:45,134 your stairs. We have a tall tall window. 17 00:00:45,134 --> 00:00:46,975 Okay. I see. I see. I thought it 18 00:00:46,975 --> 00:00:48,734 was like, you know, something to do with 19 00:00:48,734 --> 00:00:50,034 your rockets or something. 20 00:00:51,490 --> 00:00:53,570 Nah. Nah. This is an invitation to fall 21 00:00:53,570 --> 00:00:55,350 and have a really, really bad injury. 22 00:00:55,729 --> 00:00:57,829 Yeah. Yeah. Oh, yes. Yes. 23 00:00:58,689 --> 00:01:01,189 Anything around stairs is really painful. 24 00:01:01,890 --> 00:01:03,489 Yep. It just is. It's gonna be great. 25 00:01:03,489 --> 00:01:03,989 Yeah. 26 00:01:04,334 --> 00:01:04,834 We 27 00:01:06,094 --> 00:01:08,814 painted the walls and the stairs, and, you 28 00:01:08,814 --> 00:01:10,575 know, this is one of those stair sets 29 00:01:10,575 --> 00:01:10,734 where 30 00:01:11,375 --> 00:01:12,974 or one of those one of those stairs 31 00:01:12,974 --> 00:01:15,775 where the ceiling is a 10 foot ceiling 32 00:01:15,775 --> 00:01:17,694 on the Second Floor and an eight foot 33 00:01:17,694 --> 00:01:19,450 ceiling on the First Floor. So by the 34 00:01:19,450 --> 00:01:21,290 time you get to the bottom, you're looking 35 00:01:21,290 --> 00:01:22,510 at 18 feet 36 00:01:23,049 --> 00:01:24,810 to get to the ceiling or 20 feet 37 00:01:24,810 --> 00:01:26,090 to get to the ceiling. It's actually more 38 00:01:26,090 --> 00:01:27,930 than that because you have the floor itself 39 00:01:27,930 --> 00:01:30,090 between, which is like a two by 12 40 00:01:30,090 --> 00:01:32,109 or something like that. So it's like 41 00:01:32,915 --> 00:01:34,375 it's it's really tall. 42 00:01:35,795 --> 00:01:36,855 Yeah. Yeah. 43 00:01:37,715 --> 00:01:40,295 It's really hard to paint. I'm just saying. 44 00:01:41,314 --> 00:01:41,814 Yep. 45 00:01:42,515 --> 00:01:43,334 So yeah. 46 00:01:44,034 --> 00:01:45,974 So the plant's doing okay. 47 00:01:46,939 --> 00:01:49,420 Yeah. The plant's thriving. Everything looks okay back 48 00:01:49,420 --> 00:01:49,920 there. 49 00:01:50,379 --> 00:01:51,439 I was, 50 00:01:51,980 --> 00:01:52,480 at 51 00:01:52,859 --> 00:01:54,780 a relative's house, and I found an old 52 00:01:54,780 --> 00:01:55,840 electronics book, 53 00:01:56,140 --> 00:01:57,280 which was really cool, 54 00:01:57,659 --> 00:01:59,739 from way, way back. Like, it was published 55 00:01:59,739 --> 00:02:01,659 in the nineteen forties, and it was really 56 00:02:01,659 --> 00:02:03,734 cool to find that. So maybe I'll read 57 00:02:03,734 --> 00:02:05,094 through it and see if we find anything 58 00:02:05,094 --> 00:02:07,115 interesting to talk about in that someday. 59 00:02:07,734 --> 00:02:11,495 So today, we're talking to Hemant Sharma. Now, 60 00:02:11,495 --> 00:02:11,995 Hemant 61 00:02:12,855 --> 00:02:13,355 Hemant, 62 00:02:14,615 --> 00:02:16,474 you just finished a book on SRMPLS. 63 00:02:17,939 --> 00:02:20,099 What was the publisher? Because I don't remember 64 00:02:20,099 --> 00:02:21,319 if it was That. 65 00:02:21,699 --> 00:02:22,199 Okay. 66 00:02:22,819 --> 00:02:24,580 That's what I thought. I just couldn't remember, 67 00:02:24,900 --> 00:02:27,560 what publisher you had gone with for this. 68 00:02:27,780 --> 00:02:29,959 So today, we were just gonna talk about 69 00:02:30,180 --> 00:02:31,824 SRM PLS, TILFA, 70 00:02:33,084 --> 00:02:35,745 and those types of topics. So maybe, 71 00:02:36,444 --> 00:02:37,965 first of all, I might just give us 72 00:02:37,965 --> 00:02:39,424 some sense of SR. 73 00:02:39,724 --> 00:02:41,405 I know that Tom and I already know 74 00:02:41,405 --> 00:02:43,164 it kind of, but there are people out 75 00:02:43,164 --> 00:02:44,849 there listening who probably 76 00:02:45,389 --> 00:02:47,409 don't completely understand SR 77 00:02:47,789 --> 00:02:49,409 and and what the game is. 78 00:02:51,310 --> 00:02:53,330 Yeah. So segment routing, 79 00:02:54,030 --> 00:02:57,229 I have only cover covered the MPLS part 80 00:02:57,229 --> 00:02:58,750 of it, so that's what I where I 81 00:02:58,750 --> 00:02:59,389 would like to, 82 00:03:00,165 --> 00:03:02,985 keep this conversation to because I still haven't 83 00:03:03,205 --> 00:03:04,745 dwelled into SRV six. 84 00:03:05,284 --> 00:03:06,905 So it it starts 85 00:03:07,205 --> 00:03:09,205 many years ago, I had this discussion with 86 00:03:09,205 --> 00:03:11,865 one of the Cisco engineers in Cisco office, 87 00:03:12,580 --> 00:03:14,759 and he asked me this question that, 88 00:03:15,539 --> 00:03:18,659 hey, man. You're working in service provider, and 89 00:03:18,659 --> 00:03:20,520 you run link state routing protocols. 90 00:03:21,860 --> 00:03:23,379 On top of it, how do you run 91 00:03:23,379 --> 00:03:25,620 MPLS? And I said, we have LDP. We 92 00:03:25,620 --> 00:03:26,520 have RSVPT. 93 00:03:27,645 --> 00:03:28,924 And he said, but, 94 00:03:29,324 --> 00:03:31,264 for the majority of your forwarding, 95 00:03:31,884 --> 00:03:32,784 you don't need 96 00:03:33,245 --> 00:03:36,044 so many labels which LDP advertises, and what 97 00:03:36,044 --> 00:03:38,625 RSVP does is mostly for fast rerouting. 98 00:03:39,564 --> 00:03:42,000 And it made sense. And he said, how 99 00:03:42,000 --> 00:03:44,740 about if we could advertise the labels 100 00:03:45,439 --> 00:03:47,699 along with the link state routing protocols? 101 00:03:48,400 --> 00:03:50,400 At that time, segment routing, he was, 102 00:03:51,520 --> 00:03:53,280 going towards segment routing, but he didn't give 103 00:03:53,280 --> 00:03:54,260 me the full details. 104 00:03:55,205 --> 00:03:57,145 So I came back home and I started, 105 00:03:57,605 --> 00:03:59,365 doing some research of my own, and I 106 00:03:59,365 --> 00:04:01,064 found a couple of articles, 107 00:04:01,844 --> 00:04:02,665 some drafts. 108 00:04:03,205 --> 00:04:05,444 And that's where I thought that, okay. So 109 00:04:05,444 --> 00:04:07,365 this is what the concept of segment routing 110 00:04:07,365 --> 00:04:08,719 is. It's basically 111 00:04:09,259 --> 00:04:10,400 that you 112 00:04:10,860 --> 00:04:13,259 have segment routing in an MPLS network. It 113 00:04:13,259 --> 00:04:15,439 talks about having MPLS forwarding base. 114 00:04:15,979 --> 00:04:19,439 And instead of getting the labels advertised through 115 00:04:19,740 --> 00:04:22,939 a dedicated label distribution protocol such as LDP 116 00:04:22,939 --> 00:04:24,115 or RSVP PPE, 117 00:04:24,894 --> 00:04:27,214 how about you distribute the labels using the 118 00:04:27,214 --> 00:04:29,154 link state routing protocols itself? 119 00:04:29,615 --> 00:04:32,495 And it would get programmed into the, hardware 120 00:04:32,495 --> 00:04:34,175 in the same manner, and you would have 121 00:04:34,175 --> 00:04:36,894 the same label forwarding operations and label switching 122 00:04:36,894 --> 00:04:37,955 operations push, 123 00:04:38,334 --> 00:04:39,389 swap, and pop. 124 00:04:41,150 --> 00:04:43,069 So it the benefit is that you don't 125 00:04:43,069 --> 00:04:44,370 have to do a lot of, 126 00:04:44,910 --> 00:04:46,290 upgrade in terms of hardware. 127 00:04:46,910 --> 00:04:49,310 And in terms of software, you don't have 128 00:04:49,310 --> 00:04:49,810 to, 129 00:04:50,270 --> 00:04:51,949 make a lot of changes. If you're running 130 00:04:51,949 --> 00:04:54,350 ISIS, it's just a matter of adding another 131 00:04:54,350 --> 00:04:54,850 TLV. 132 00:04:55,615 --> 00:04:57,314 And a few set of TLV, 133 00:04:58,014 --> 00:04:58,514 can 134 00:04:59,615 --> 00:05:01,935 enhance the link state routing protocol to a 135 00:05:01,935 --> 00:05:03,875 label distribution protocol as well. 136 00:05:05,694 --> 00:05:08,754 So that's how it started with segment routing. 137 00:05:09,069 --> 00:05:11,170 So, basically, the difference between 138 00:05:11,870 --> 00:05:13,490 standard MPLS TE 139 00:05:13,870 --> 00:05:15,170 and SR MPLS 140 00:05:16,430 --> 00:05:16,930 is, 141 00:05:18,189 --> 00:05:19,629 just to make sure that we have this 142 00:05:19,629 --> 00:05:20,529 right, is that 143 00:05:21,194 --> 00:05:21,694 in 144 00:05:22,714 --> 00:05:24,014 in in MPLS TE, 145 00:05:24,555 --> 00:05:26,555 you don't really have a label stack. You 146 00:05:26,555 --> 00:05:28,235 have an in what we call a label 147 00:05:28,235 --> 00:05:30,154 stack is an inner and an outer. And 148 00:05:30,154 --> 00:05:31,754 that's pretty much you only get to two 149 00:05:31,754 --> 00:05:32,254 labels. 150 00:05:32,954 --> 00:05:35,850 And every router does a pop. 151 00:05:36,170 --> 00:05:38,509 Not every router, but every label router 152 00:05:39,449 --> 00:05:40,670 does a pop 153 00:05:41,209 --> 00:05:41,709 and, 154 00:05:42,730 --> 00:05:43,230 push. 155 00:05:43,770 --> 00:05:46,250 Like, it swaps the labels at every at 156 00:05:46,250 --> 00:05:47,149 every hop, 157 00:05:47,610 --> 00:05:50,305 in theory. That's I mean, there are games 158 00:05:50,305 --> 00:05:51,985 we play with the labels so that you 159 00:05:51,985 --> 00:05:54,384 don't actually swap the labels. But that's the 160 00:05:54,384 --> 00:05:56,084 theoretical way that it works. 161 00:05:56,544 --> 00:05:57,685 Whereas with SRv6, 162 00:05:58,944 --> 00:06:00,245 because it's basically 163 00:06:00,784 --> 00:06:04,500 a source routed technology, which people don't always 164 00:06:04,500 --> 00:06:06,120 understand, or SR MPLS, 165 00:06:06,579 --> 00:06:08,979 SR itself, segment routing itself, is a source 166 00:06:08,979 --> 00:06:09,879 routed technology. 167 00:06:11,300 --> 00:06:13,860 Somewhere along the path close to the source, 168 00:06:13,860 --> 00:06:14,600 in theory, 169 00:06:15,485 --> 00:06:18,384 you push the entire stack of labels 170 00:06:19,245 --> 00:06:21,884 to get you from source to destination. So 171 00:06:21,884 --> 00:06:23,185 you don't actually swap 172 00:06:23,564 --> 00:06:25,345 labels at every hop. 173 00:06:25,724 --> 00:06:28,925 You just pop the label, exposing the next 174 00:06:28,925 --> 00:06:29,425 label 175 00:06:30,250 --> 00:06:32,589 whenever you process that that particular 176 00:06:33,050 --> 00:06:33,550 situation. 177 00:06:34,729 --> 00:06:36,409 So there are there are couple of things 178 00:06:36,409 --> 00:06:38,569 here. So when it comes to segment routing 179 00:06:38,569 --> 00:06:41,129 in terms of creating the whole stack, basically, 180 00:06:41,129 --> 00:06:43,689 the original name was spring source packet Internet 181 00:06:43,689 --> 00:06:44,189 routing. 182 00:06:44,569 --> 00:06:45,069 So 183 00:06:45,404 --> 00:06:45,904 in 184 00:06:47,084 --> 00:06:47,584 LDP, 185 00:06:48,925 --> 00:06:51,884 the IGP routing protocol when the route populates 186 00:06:51,884 --> 00:06:54,204 in the routing table, the LDP then add 187 00:06:54,365 --> 00:06:54,865 advertises 188 00:06:55,245 --> 00:06:57,245 generates a label and distributes it to its 189 00:06:57,245 --> 00:06:57,745 upstream 190 00:06:58,285 --> 00:06:59,345 peers. And 191 00:07:01,339 --> 00:07:01,579 the 192 00:07:03,100 --> 00:07:04,939 all the routers in the neighbor, in the 193 00:07:04,939 --> 00:07:07,500 network, they have all the labels available, but, 194 00:07:07,899 --> 00:07:09,919 the label which is applied 195 00:07:10,220 --> 00:07:12,639 to a packet which enters the MPLS domain, 196 00:07:12,754 --> 00:07:15,074 there's only one pack one label applied and 197 00:07:15,074 --> 00:07:16,935 every hop intermediary hop, 198 00:07:17,875 --> 00:07:20,274 makes decisions, swap or pop decision based on 199 00:07:20,274 --> 00:07:21,574 that incoming label. 200 00:07:22,514 --> 00:07:23,735 In segment routing, 201 00:07:24,595 --> 00:07:25,495 segment routing 202 00:07:26,009 --> 00:07:28,250 can create the entire label stack at the 203 00:07:28,250 --> 00:07:31,849 source. But because the hardware forwarding mechanism has 204 00:07:31,849 --> 00:07:34,250 remained the same because you haven't upgraded the 205 00:07:34,250 --> 00:07:36,810 hardware, so the hardware knows how to forward 206 00:07:36,810 --> 00:07:40,029 MPLS. So although the label remains the same, 207 00:07:40,285 --> 00:07:43,165 the incoming label and the outgoing label because 208 00:07:43,165 --> 00:07:44,764 in segment routing, there are two types of 209 00:07:44,764 --> 00:07:45,985 label. One is statically 210 00:07:46,285 --> 00:07:47,245 advertised label, 211 00:07:48,045 --> 00:07:48,545 which 212 00:07:48,925 --> 00:07:49,985 signifies the 213 00:07:50,605 --> 00:07:52,144 segment out, a prefix 214 00:07:52,444 --> 00:07:54,944 set or the node set, which defines the 215 00:07:55,439 --> 00:07:58,160 router as in a unique loopback address or 216 00:07:58,160 --> 00:07:59,139 unique label. 217 00:07:59,680 --> 00:08:01,839 And then for each adjacency, there is a 218 00:08:01,839 --> 00:08:05,300 dynamically allocated or can be manually allocated, dynamically 219 00:08:05,360 --> 00:08:08,579 allocated adjacency set. In LDP, everything is dynamic. 220 00:08:08,954 --> 00:08:10,634 But in segment routing, since the, 221 00:08:11,115 --> 00:08:12,654 node set is static, 222 00:08:13,115 --> 00:08:16,574 you can have the entire label stack and 223 00:08:17,274 --> 00:08:18,814 and created at the source. 224 00:08:19,194 --> 00:08:21,534 And you'll if if there is no other, 225 00:08:22,100 --> 00:08:24,180 traffic engineering mechanism happening and if it if 226 00:08:24,180 --> 00:08:25,939 there is no backup path, the 227 00:08:26,660 --> 00:08:27,879 on the primary path, 228 00:08:28,660 --> 00:08:31,060 your incoming label and the outgoing label would 229 00:08:31,060 --> 00:08:33,139 be the same because the label denotes the 230 00:08:33,139 --> 00:08:34,679 destination or router. 231 00:08:35,075 --> 00:08:38,035 But, because the hardware is still working on 232 00:08:38,035 --> 00:08:39,495 the principles of MPLS, 233 00:08:39,875 --> 00:08:41,654 it is swapping the incoming 234 00:08:42,035 --> 00:08:43,875 label with the outgoing label. It is the 235 00:08:43,875 --> 00:08:44,615 same label, 236 00:08:45,154 --> 00:08:47,315 but it is still doing the swapping mechanism. 237 00:08:47,315 --> 00:08:49,154 And then we have the same penalty made 238 00:08:49,154 --> 00:08:49,815 hop popping, 239 00:08:50,450 --> 00:08:53,490 as in as in traditional MPLS. So the 240 00:08:53,490 --> 00:08:55,809 penalty made hop pops the last, the final 241 00:08:55,809 --> 00:08:57,669 label and sends the IP traffic. 242 00:08:59,410 --> 00:09:02,309 So that's why segment routing is very easy 243 00:09:02,815 --> 00:09:06,514 to adapt to, coming from traditional MPLS because, 244 00:09:07,214 --> 00:09:07,954 your protocols 245 00:09:09,774 --> 00:09:11,154 are are upgraded, enhanced. 246 00:09:11,695 --> 00:09:14,195 Many TLVs have been add added in ISIS 247 00:09:14,414 --> 00:09:16,115 and OSPF has been upgraded. 248 00:09:18,429 --> 00:09:19,970 IDF RFCs are available. 249 00:09:20,990 --> 00:09:23,070 I have worked with multiple vendors who are 250 00:09:23,070 --> 00:09:25,250 running segment routing, Juniper, Nokia, Cisco. 251 00:09:26,029 --> 00:09:28,509 In fact, multi vendor labs also I have 252 00:09:28,509 --> 00:09:29,009 tested. 253 00:09:29,549 --> 00:09:30,929 They all work very well. 254 00:09:31,470 --> 00:09:31,970 Okay. 255 00:09:33,585 --> 00:09:35,044 So why MPLS 256 00:09:35,345 --> 00:09:36,884 instead of v six? 257 00:09:37,504 --> 00:09:39,424 That's always gonna be the first question is 258 00:09:39,424 --> 00:09:41,205 who if anybody who's familiar 259 00:09:41,825 --> 00:09:43,285 with segment routing, 260 00:09:44,225 --> 00:09:45,205 I know why 261 00:09:45,970 --> 00:09:47,350 I often go towards 262 00:09:48,129 --> 00:09:48,789 v six 263 00:09:49,169 --> 00:09:50,230 is just because 264 00:09:50,690 --> 00:09:53,250 of the hardware problems you run into. And 265 00:09:53,250 --> 00:09:55,830 deploying if you don't already have MPLS deployed, 266 00:09:56,450 --> 00:09:59,250 deploying MPLS in a network from the ground 267 00:09:59,250 --> 00:09:59,410 up 268 00:10:00,304 --> 00:10:01,904 depending on the size of the network. But 269 00:10:01,904 --> 00:10:03,125 it can be quite challenging, 270 00:10:03,824 --> 00:10:06,304 just to get MPLS deployed, get things configured, 271 00:10:06,304 --> 00:10:07,764 get your labels set up, 272 00:10:08,625 --> 00:10:11,184 just just to do stuff. So why why 273 00:10:11,184 --> 00:10:11,684 MPLS? 274 00:10:12,144 --> 00:10:13,204 Just out of curiosity. 275 00:10:14,519 --> 00:10:17,159 I I believe MPLS has been there for 276 00:10:17,159 --> 00:10:18,519 long and every 277 00:10:18,919 --> 00:10:21,240 like, every project, it takes a considerable amount 278 00:10:21,240 --> 00:10:23,820 of effort and resource to move to something 279 00:10:23,960 --> 00:10:25,980 new, which is drastically different. 280 00:10:27,225 --> 00:10:30,105 When we had a requirement to forward I 281 00:10:30,105 --> 00:10:32,585 p v six based traffic, customers who wanted 282 00:10:32,585 --> 00:10:33,805 I p v six reachability, 283 00:10:34,504 --> 00:10:37,384 we simply implemented six v p. So the 284 00:10:37,384 --> 00:10:39,705 customer p to c connection was I p 285 00:10:39,705 --> 00:10:41,725 v six based, but we were simply 286 00:10:42,160 --> 00:10:44,899 forwarding based on our MPLS traffic. And 287 00:10:45,759 --> 00:10:47,360 there was no more there there has been 288 00:10:47,360 --> 00:10:49,379 very little motivation to move to, 289 00:10:50,000 --> 00:10:50,980 I p v six, 290 00:10:51,840 --> 00:10:54,480 natively if you do not have a very 291 00:10:54,480 --> 00:10:56,419 strong requirement as a product. 292 00:10:57,544 --> 00:10:58,284 I believe 293 00:10:58,904 --> 00:11:00,985 SR v six is going to change it 294 00:11:00,985 --> 00:11:02,445 because SR v six, 295 00:11:03,544 --> 00:11:05,464 enables you to connect end to end data 296 00:11:05,464 --> 00:11:07,144 center to data center using the same, 297 00:11:08,345 --> 00:11:09,404 segment stack. 298 00:11:10,039 --> 00:11:13,019 So that could be a strong motivating factor. 299 00:11:13,079 --> 00:11:14,459 Other than that, I believe 300 00:11:15,000 --> 00:11:17,000 it's just a lot of effort which people 301 00:11:17,000 --> 00:11:17,659 are thinking, 302 00:11:18,679 --> 00:11:20,519 let's not fix it if it's not broken. 303 00:11:20,519 --> 00:11:22,519 So Yeah. I think product if it can 304 00:11:22,519 --> 00:11:24,139 be if it cannot be productized, 305 00:11:24,455 --> 00:11:25,914 then there's no motivation. 306 00:11:26,615 --> 00:11:28,294 I I I think that it it is 307 00:11:28,294 --> 00:11:30,534 true, Russ, to go from no label switching 308 00:11:30,534 --> 00:11:33,115 at all, just like IP routing with devices 309 00:11:33,174 --> 00:11:35,174 that cannot do label switching to move that 310 00:11:35,174 --> 00:11:37,414 into MPLS. Yeah. Absolutely. That's a lift. You 311 00:11:37,414 --> 00:11:39,289 gotta upgrade a bunch of stuff. But if 312 00:11:39,289 --> 00:11:40,889 you already run a network that does label 313 00:11:40,889 --> 00:11:41,389 switching, 314 00:11:41,769 --> 00:11:43,610 it's not like v six is gonna give 315 00:11:43,610 --> 00:11:46,409 you some new magical capability. But I I 316 00:11:46,409 --> 00:11:48,169 I I see it I guess it depends 317 00:11:48,169 --> 00:11:49,689 on where you're coming from. If you're already 318 00:11:49,689 --> 00:11:51,610 running an MPLS network, then you're already doing 319 00:11:51,610 --> 00:11:52,110 MPLS. 320 00:11:53,115 --> 00:11:55,035 So but there are networks out there, I'm 321 00:11:55,035 --> 00:11:56,875 sure, that they never did that. They never 322 00:11:56,875 --> 00:11:58,675 started on that. And now they wanna do 323 00:11:58,875 --> 00:12:01,535 they wanna take advantage of these capabilities and 324 00:12:01,675 --> 00:12:03,035 let's put it in IP v six. You 325 00:12:03,035 --> 00:12:04,634 don't have to change out your silicon. Like, 326 00:12:04,634 --> 00:12:06,179 I can I can see it both ways? 327 00:12:06,339 --> 00:12:08,019 Well, it's not just silicon. It's also the 328 00:12:08,019 --> 00:12:09,240 routers in the middle. 329 00:12:09,940 --> 00:12:12,019 To the routers in the middle, SRV six 330 00:12:12,019 --> 00:12:13,399 is just v six. 331 00:12:14,019 --> 00:12:16,200 Then I mean, they don't actually see anything. 332 00:12:16,259 --> 00:12:17,700 Right? Yeah. And maybe you maybe you run 333 00:12:17,700 --> 00:12:19,460 over a public network. Maybe you don't control 334 00:12:19,460 --> 00:12:21,080 the bits. Yeah. I mean Yeah. 335 00:12:22,264 --> 00:12:24,105 Now I would say the neg the the 336 00:12:24,105 --> 00:12:26,425 flip side of that is primarily gonna be 337 00:12:26,425 --> 00:12:27,805 MTU from my side 338 00:12:28,345 --> 00:12:30,684 when I think about it, is that 339 00:12:30,985 --> 00:12:33,085 SR v six without micro SIDs, 340 00:12:33,909 --> 00:12:37,210 in particular without micro SIDs, is a much 341 00:12:37,269 --> 00:12:39,509 larger packet. Right? Now, when you get into 342 00:12:39,509 --> 00:12:40,409 micro SIDs, 343 00:12:40,710 --> 00:12:42,950 you can play games with, like, well, it's 344 00:12:42,950 --> 00:12:45,110 only an extra SRv6 header. It's only one 345 00:12:45,110 --> 00:12:46,549 IP. It's only 128 346 00:12:46,549 --> 00:12:47,049 bits. 347 00:12:47,429 --> 00:12:47,929 But 348 00:12:48,504 --> 00:12:50,745 without micro SIDs, like, if you get more 349 00:12:50,745 --> 00:12:52,824 than a couple of labels, you're adding a 350 00:12:52,824 --> 00:12:54,125 lot of data, 351 00:12:54,745 --> 00:12:57,065 header data, to your packet to get the 352 00:12:57,065 --> 00:12:59,245 packet through your network. So that's why, 353 00:13:00,500 --> 00:13:02,259 things can get into it. I think it 354 00:13:02,259 --> 00:13:03,959 would also depend on whether 355 00:13:05,379 --> 00:13:07,559 the network is doing SR 356 00:13:08,100 --> 00:13:10,600 or whether the applications are doing SR. 357 00:13:12,019 --> 00:13:13,459 This is something that not a lot of 358 00:13:13,459 --> 00:13:15,399 people think about when they get to SR, 359 00:13:15,745 --> 00:13:16,404 is that 360 00:13:17,345 --> 00:13:19,605 if the application is doing SR, 361 00:13:20,225 --> 00:13:22,884 writing an application that is native MPLS 362 00:13:24,304 --> 00:13:26,085 is far beyond the kin 363 00:13:26,625 --> 00:13:27,125 of 364 00:13:27,585 --> 00:13:28,085 most 365 00:13:28,465 --> 00:13:31,740 application developers. I mean Right. I'm not you 366 00:13:31,740 --> 00:13:33,980 know, it's just not what they do, right? 367 00:13:33,980 --> 00:13:34,720 It's not 368 00:13:35,259 --> 00:13:38,460 they focus on databases and user interfaces and 369 00:13:38,460 --> 00:13:40,879 they don't focus on, like, networking technologies. 370 00:13:41,259 --> 00:13:43,580 So you give them these weird MPLS labels 371 00:13:43,580 --> 00:13:45,285 and say, you've got to figure out this 372 00:13:45,285 --> 00:13:47,365 label stack. And they're like, oh, no. Go 373 00:13:47,365 --> 00:13:50,024 away. I got other stuff to do. Whereas 374 00:13:50,165 --> 00:13:52,024 with SRv6, you just say, 375 00:13:52,404 --> 00:13:54,804 all you do is you put this header 376 00:13:54,804 --> 00:13:56,165 on the front end of it and put 377 00:13:56,165 --> 00:13:57,545 the packet on the wire. 378 00:13:58,139 --> 00:14:00,220 And it's just it's just v six. Just 379 00:14:00,220 --> 00:14:02,379 just ignore everything else. It's just IP and 380 00:14:02,379 --> 00:14:02,879 IP. 381 00:14:03,899 --> 00:14:04,399 Right? 382 00:14:04,940 --> 00:14:06,700 I think it it it kind of works. 383 00:14:06,700 --> 00:14:10,059 But, with native MPLS, there are in my 384 00:14:10,059 --> 00:14:12,620 experience, we we already struggle a lot when 385 00:14:12,620 --> 00:14:13,120 we 386 00:14:14,554 --> 00:14:17,355 switch the traffic from one carrier to another 387 00:14:17,355 --> 00:14:19,455 carrier over interiors option b. 388 00:14:19,835 --> 00:14:21,695 So the if they have ready redundancy, 389 00:14:23,035 --> 00:14:25,115 they would like to have redundancy based on 390 00:14:25,115 --> 00:14:25,615 IP 391 00:14:26,059 --> 00:14:29,179 and, have BGP attributes. But the label that 392 00:14:29,179 --> 00:14:29,919 they have 393 00:14:30,299 --> 00:14:32,620 is I mean, their traffic is switched over 394 00:14:32,620 --> 00:14:34,860 the label. So regardless of what BGP attribute 395 00:14:34,860 --> 00:14:36,000 they they are receiving, 396 00:14:36,860 --> 00:14:38,699 they have less control over it. So I 397 00:14:38,699 --> 00:14:40,720 think natively writing an MPLS 398 00:14:41,674 --> 00:14:42,574 based application, 399 00:14:43,834 --> 00:14:45,595 I I'm coming from that point, 400 00:14:46,154 --> 00:14:48,495 that there's already a lot of challenging scenario. 401 00:14:48,794 --> 00:14:50,714 I p v six and micro set based 402 00:14:50,714 --> 00:14:51,534 network programmability, 403 00:14:53,274 --> 00:14:54,495 makes things a lot easier, 404 00:14:55,595 --> 00:14:56,495 in my opinion. 405 00:14:58,039 --> 00:14:59,960 So I'm I'm curious, Russ, on the other 406 00:14:59,960 --> 00:15:01,179 side. Do 407 00:15:01,960 --> 00:15:04,919 are there commercial applications that do this that 408 00:15:04,919 --> 00:15:06,600 can actually take advantage of us? Or I 409 00:15:06,600 --> 00:15:08,200 never heard of one myself. It was always 410 00:15:08,200 --> 00:15:09,799 just the network people trying to provide a 411 00:15:09,799 --> 00:15:10,700 reliable overlay. 412 00:15:11,144 --> 00:15:14,264 But, are there are there applications where the 413 00:15:14,264 --> 00:15:16,105 application developer's like, yeah. I wanna get into 414 00:15:16,105 --> 00:15:17,465 the network and figure out how to move 415 00:15:17,465 --> 00:15:18,125 my packets. 416 00:15:18,504 --> 00:15:20,524 Yeah. In fact, I would say 417 00:15:21,705 --> 00:15:23,945 the vast majority of my SR v six 418 00:15:23,945 --> 00:15:25,919 deployment is on the application side. 419 00:15:26,799 --> 00:15:28,639 And then and the network is just playing 420 00:15:28,639 --> 00:15:29,139 along. 421 00:15:29,839 --> 00:15:31,139 I mean, it's just providing 422 00:15:31,759 --> 00:15:33,779 basically, the the network is providing 423 00:15:35,200 --> 00:15:36,100 service chaining 424 00:15:36,799 --> 00:15:39,459 and such. Really, it's just providing routing 425 00:15:39,934 --> 00:15:41,955 between the service chain points 426 00:15:42,575 --> 00:15:43,075 and 427 00:15:43,615 --> 00:15:45,235 exits and stuff like this, 428 00:15:45,774 --> 00:15:47,955 it's not really like, we're 429 00:15:49,774 --> 00:15:52,575 not planning to do a lot of end 430 00:15:52,575 --> 00:15:55,394 cap, pushing the SRv6 label stack 431 00:15:56,070 --> 00:15:56,889 on a router. 432 00:15:57,990 --> 00:16:00,070 Most of the SRv6 label stack is going 433 00:16:00,070 --> 00:16:00,809 to be pushed 434 00:16:01,269 --> 00:16:02,090 by applications. 435 00:16:03,110 --> 00:16:03,610 So 436 00:16:03,990 --> 00:16:04,490 that's 437 00:16:04,950 --> 00:16:06,950 and that's probably the main reason that I'm 438 00:16:06,950 --> 00:16:08,250 not really looking at MPLS, 439 00:16:08,790 --> 00:16:10,470 is because I go to the app developers, 440 00:16:10,470 --> 00:16:12,725 and I go, we'd really like MPLS, and 441 00:16:12,725 --> 00:16:14,585 they're like, yeah. Go away. 442 00:16:17,684 --> 00:16:19,684 And that is precisely why I mentioned that 443 00:16:19,684 --> 00:16:21,285 SR v six could be a very strong 444 00:16:21,285 --> 00:16:24,165 motivator for the providers to switch to native 445 00:16:24,165 --> 00:16:26,590 SR v six, and native IP six six 446 00:16:26,590 --> 00:16:28,750 based networks, if not already, and turn off 447 00:16:28,750 --> 00:16:29,250 MPLS. 448 00:16:30,110 --> 00:16:33,549 Probably not turn off, but, yeah, SR v 449 00:16:33,549 --> 00:16:34,289 six is better. 450 00:16:34,909 --> 00:16:35,409 Well, 451 00:16:35,789 --> 00:16:38,029 again, there's trade offs. Right? There's always trade 452 00:16:38,029 --> 00:16:39,250 offs. And 453 00:16:40,205 --> 00:16:42,305 the the the cool thing about about MPLS 454 00:16:42,365 --> 00:16:43,904 is it is a smaller label. 455 00:16:44,285 --> 00:16:47,004 In theory, it's faster to switch. I don't 456 00:16:47,004 --> 00:16:49,185 know if that's true with modern forwarding engines. 457 00:16:49,325 --> 00:16:50,685 I mean, that's why it was invented in 458 00:16:50,685 --> 00:16:52,384 the first place. It came out of ATM. 459 00:16:53,100 --> 00:16:55,500 And ATM was all designed to have fixed 460 00:16:55,500 --> 00:16:56,320 cell sizes 461 00:16:56,860 --> 00:16:58,159 and fixed headers 462 00:16:58,620 --> 00:17:00,539 so that you wouldn't have all this garbage 463 00:17:00,539 --> 00:17:01,919 that you're switching on. 464 00:17:02,299 --> 00:17:03,980 And so you start looking at SR v 465 00:17:03,980 --> 00:17:06,255 six with microsids, and you're like, yeah. But 466 00:17:06,255 --> 00:17:08,255 now I've got to actually read parts of 467 00:17:08,255 --> 00:17:10,275 the v six destination address 468 00:17:10,894 --> 00:17:13,775 and use those parts. Wow. That's that's that's 469 00:17:13,775 --> 00:17:15,154 very complex code. 470 00:17:15,455 --> 00:17:17,819 Right? That's not simple as look at a 471 00:17:17,899 --> 00:17:20,380 look at a label, flip the label, or 472 00:17:20,380 --> 00:17:21,899 pop the label, and look at the next 473 00:17:21,899 --> 00:17:24,079 label to do whatever the next label says. 474 00:17:24,619 --> 00:17:27,019 So there there there's always trade offs in 475 00:17:27,019 --> 00:17:28,539 these things, and I don't wanna make one 476 00:17:28,539 --> 00:17:30,619 sound better than the other. I just was 477 00:17:30,619 --> 00:17:32,000 curious why MPLS 478 00:17:32,855 --> 00:17:34,555 in your particular case because 479 00:17:34,934 --> 00:17:35,755 it seems 480 00:17:36,695 --> 00:17:39,035 like most people are SRV six. That's all. 481 00:17:39,494 --> 00:17:41,414 Yeah. I I believe it's it's about how 482 00:17:41,414 --> 00:17:43,654 much value you're getting for that effort that 483 00:17:43,654 --> 00:17:44,615 you're putting into, 484 00:17:45,494 --> 00:17:47,115 comp processing that complexity. 485 00:17:48,130 --> 00:17:49,285 So so him 486 00:17:50,121 --> 00:17:53,250 the MPLS makes sense. Yeah. I'm I'm wondering 487 00:17:53,250 --> 00:17:55,329 what, so what what pushed you to write 488 00:17:55,329 --> 00:17:56,929 the book? What was your what was your 489 00:17:56,929 --> 00:17:57,829 motivation there? 490 00:17:58,929 --> 00:17:59,429 So 491 00:17:59,809 --> 00:18:01,750 I started doing segment routing, 492 00:18:02,609 --> 00:18:03,269 for my 493 00:18:03,605 --> 00:18:04,105 own 494 00:18:04,404 --> 00:18:06,664 organization many years ago. And, 495 00:18:07,605 --> 00:18:10,164 after doing this little bit of testing in 496 00:18:10,164 --> 00:18:11,765 the lab because we had to test the 497 00:18:11,765 --> 00:18:12,265 products, 498 00:18:12,805 --> 00:18:13,945 the virtual 499 00:18:14,325 --> 00:18:14,825 images, 500 00:18:15,365 --> 00:18:18,089 in what code, how much functionality is available, 501 00:18:18,150 --> 00:18:19,450 especially around PILFA, 502 00:18:20,470 --> 00:18:23,130 because we had our SCPT based FRR, 503 00:18:23,829 --> 00:18:24,329 already. 504 00:18:24,710 --> 00:18:26,549 So we wanted to know how much work 505 00:18:26,549 --> 00:18:28,549 has been done by the vendors, in terms 506 00:18:28,549 --> 00:18:29,414 of fast reroute. 507 00:18:29,815 --> 00:18:31,434 So I started testing, and 508 00:18:32,695 --> 00:18:34,855 then we created a few documents in terms 509 00:18:34,855 --> 00:18:35,994 of how much we can, 510 00:18:36,855 --> 00:18:38,475 deploy in the network today. 511 00:18:39,015 --> 00:18:41,275 Did a a few rounds of training internally, 512 00:18:42,179 --> 00:18:43,940 and, it was received very, 513 00:18:44,740 --> 00:18:45,480 very well, 514 00:18:46,339 --> 00:18:47,799 across multiple teams. 515 00:18:48,899 --> 00:18:51,700 And, finally, I put this on on GitHub 516 00:18:51,700 --> 00:18:53,940 because I was trying to get, some more 517 00:18:53,940 --> 00:18:55,079 audience for it. 518 00:18:55,654 --> 00:18:58,534 And, I looked into multiple options, perhaps could 519 00:18:58,534 --> 00:18:59,034 create 520 00:18:59,575 --> 00:19:02,534 a sandbox lab for everybody to access as 521 00:19:02,534 --> 00:19:04,134 a pay as you go model. I couldn't 522 00:19:04,134 --> 00:19:06,375 figure these things out, so I finally settled 523 00:19:06,375 --> 00:19:07,994 down on publishing it as a book. 524 00:19:08,774 --> 00:19:10,220 Oh, very cool. 525 00:19:10,599 --> 00:19:12,679 So and and I kept it to it 526 00:19:12,679 --> 00:19:13,900 was it was a difficult 527 00:19:15,720 --> 00:19:16,779 method because 528 00:19:17,240 --> 00:19:18,220 I was doing 529 00:19:18,519 --> 00:19:20,679 two types of training. First, I was covering 530 00:19:20,679 --> 00:19:23,494 the entire theory in one go and then 531 00:19:23,494 --> 00:19:24,154 the labs. 532 00:19:24,694 --> 00:19:25,194 But, 533 00:19:26,054 --> 00:19:27,815 in the in the book, I I have 534 00:19:27,815 --> 00:19:30,214 kind of mixed them together. So there is 535 00:19:30,214 --> 00:19:32,214 sufficient amount of theory, and then there is 536 00:19:32,214 --> 00:19:33,275 a good 537 00:19:33,734 --> 00:19:36,279 amount of lab hands on lab so that 538 00:19:36,279 --> 00:19:38,440 you don't feel disconnected that there is a 539 00:19:38,440 --> 00:19:40,279 small amount of lab, and then you have 540 00:19:40,279 --> 00:19:41,640 to go through a big a big chunk 541 00:19:41,640 --> 00:19:42,380 of theory. 542 00:19:43,240 --> 00:19:45,500 So I've tried to strike the right balance. 543 00:19:48,954 --> 00:19:51,994 Interesting. So yeah. So talk so the the 544 00:19:52,075 --> 00:19:53,514 you said a lot of this book is 545 00:19:53,514 --> 00:19:54,335 about TILFA. 546 00:19:55,115 --> 00:19:56,634 So maybe we ought to talk a little 547 00:19:56,634 --> 00:19:57,615 bit about TILFA. 548 00:19:58,714 --> 00:20:00,234 I don't know. Tom, did you have other 549 00:20:00,234 --> 00:20:02,075 SR stuff you wanted to talk about before 550 00:20:02,075 --> 00:20:02,554 we get to 551 00:20:03,340 --> 00:20:04,779 Oh, no. I was just I was just 552 00:20:04,779 --> 00:20:06,619 gonna say I that I love the premise 553 00:20:06,619 --> 00:20:08,460 of that that it's a it's a way 554 00:20:08,460 --> 00:20:09,820 to help people get up to speed in 555 00:20:09,820 --> 00:20:10,880 a practical way. 556 00:20:11,180 --> 00:20:12,860 I think we need more books like that. 557 00:20:12,860 --> 00:20:15,019 I I it sounds sounds really cool. I'm 558 00:20:15,019 --> 00:20:16,160 glad you published it. 559 00:20:16,619 --> 00:20:17,119 Yeah. 560 00:20:18,704 --> 00:20:20,464 The labs, by the way, are they available 561 00:20:20,464 --> 00:20:22,865 on GitHub by them standalone, or are they 562 00:20:22,865 --> 00:20:25,585 only, like are they published as as through 563 00:20:25,585 --> 00:20:27,984 a gateway? Or or is it just what's 564 00:20:28,544 --> 00:20:30,224 one thing I don't like about books with 565 00:20:30,224 --> 00:20:30,724 labs 566 00:20:31,025 --> 00:20:32,944 is that when they put the books the 567 00:20:32,944 --> 00:20:33,924 labs printed 568 00:20:34,359 --> 00:20:37,720 in the book, there's no digital copy, and 569 00:20:37,720 --> 00:20:40,519 you're spending fourteen hours trying to type all 570 00:20:40,519 --> 00:20:41,819 the commands in. 571 00:20:43,480 --> 00:20:45,500 So I have I have put the entire 572 00:20:45,880 --> 00:20:46,380 configuration 573 00:20:46,919 --> 00:20:49,500 used in the book, in the books, GitHub 574 00:20:49,865 --> 00:20:52,184 repository. So the publisher packed. They have a 575 00:20:52,184 --> 00:20:54,744 GitHub account, and they have created a repository 576 00:20:54,744 --> 00:20:57,065 for the book. Okay. Cool. What I have 577 00:20:57,065 --> 00:21:00,445 done, chapter wise, I have copied the code 578 00:21:00,825 --> 00:21:02,984 as well as because the the book that 579 00:21:02,984 --> 00:21:03,384 I have, 580 00:21:04,025 --> 00:21:04,525 written 581 00:21:05,849 --> 00:21:07,150 is designed in a sequence. 582 00:21:07,849 --> 00:21:10,190 So if you're going to go to chapter 583 00:21:10,410 --> 00:21:12,029 eight, lab seven, 584 00:21:12,410 --> 00:21:14,170 then you must have all the previous labs 585 00:21:14,170 --> 00:21:16,730 completed. Now if you, tomorrow, want to simply 586 00:21:16,730 --> 00:21:17,470 go and, 587 00:21:17,769 --> 00:21:18,269 access, 588 00:21:19,075 --> 00:21:20,994 okay. I want to see how lab 10 589 00:21:20,994 --> 00:21:23,235 goes. Now you don't want to spend a 590 00:21:23,235 --> 00:21:25,634 lot of time in configuring the previous lab 591 00:21:25,634 --> 00:21:28,275 nine. So I've also written an Ansible playbook 592 00:21:28,275 --> 00:21:30,695 and public, updated to the GitHub repository. 593 00:21:31,154 --> 00:21:31,815 So you can 594 00:21:32,149 --> 00:21:34,409 simply run the playbook tail up to, 595 00:21:34,869 --> 00:21:37,029 lab nine, and then get your hands dirty 596 00:21:37,029 --> 00:21:37,849 on lab 10. 597 00:21:38,309 --> 00:21:40,889 And, I have tested it on Cisco ISXR 598 00:21:40,950 --> 00:21:41,450 as 599 00:21:41,909 --> 00:21:43,529 well as, Juniper Junos, 600 00:21:44,309 --> 00:21:46,089 separately. I wanted to do, 601 00:21:46,674 --> 00:21:48,515 a single lab multi vendor, but, 602 00:21:49,154 --> 00:21:51,335 the way I had designed this whole topology, 603 00:21:51,875 --> 00:21:54,195 it didn't work out. I had to make 604 00:21:54,195 --> 00:21:55,595 trade offs. So what I did, I just 605 00:21:55,714 --> 00:21:56,855 for the sake of simplicity, 606 00:21:57,555 --> 00:21:59,575 I kept the entire book on Cisco ISXR. 607 00:22:00,099 --> 00:22:01,619 Most of you people are familiar with it. 608 00:22:01,619 --> 00:22:04,579 And, for the Juniper part, I have uploaded 609 00:22:04,579 --> 00:22:05,319 the configuration 610 00:22:05,700 --> 00:22:07,639 in another branch of the same repository. 611 00:22:08,179 --> 00:22:10,980 And there is an Ansible playbook for XR, 612 00:22:10,980 --> 00:22:12,119 and then there is a 613 00:22:13,144 --> 00:22:14,044 simple configuration 614 00:22:14,825 --> 00:22:16,605 branch process for XR. 615 00:22:18,505 --> 00:22:21,464 Excellent. Yeah. Cool. Awesome. Okay. So tell us 616 00:22:21,464 --> 00:22:23,065 a little bit about t I l f 617 00:22:23,065 --> 00:22:24,744 a. Because you said you spent a lot 618 00:22:24,744 --> 00:22:26,585 of time in the book on t I 619 00:22:26,585 --> 00:22:27,325 l f a. 620 00:22:28,169 --> 00:22:28,669 Yeah. 621 00:22:29,289 --> 00:22:30,669 So because the book 622 00:22:31,130 --> 00:22:31,630 has 623 00:22:32,329 --> 00:22:35,069 ISIS and LDP as a foundational, 624 00:22:36,169 --> 00:22:37,869 routing and label distribution, 625 00:22:38,809 --> 00:22:39,309 protocol, 626 00:22:40,105 --> 00:22:42,605 After introducing segment routing and 627 00:22:42,984 --> 00:22:46,125 working with segment routing and LDP interworking lab, 628 00:22:48,105 --> 00:22:49,724 segment routing was kind of 629 00:22:50,184 --> 00:22:52,224 not going anywhere. I had to introduce either 630 00:22:52,345 --> 00:22:54,605 I had to think about either introducing Flexalgo 631 00:22:54,984 --> 00:22:55,644 or SRT 632 00:22:56,400 --> 00:22:58,400 or simply go with TILFA. So I I 633 00:22:58,400 --> 00:23:00,180 chose TILFA because it was simpler. 634 00:23:00,559 --> 00:23:02,900 Plus that is what we went with, initially, 635 00:23:03,840 --> 00:23:05,700 when we deployed segment routing. 636 00:23:07,279 --> 00:23:08,340 So we had 637 00:23:08,644 --> 00:23:10,585 to make a lot of decisions around TILFA's 638 00:23:10,884 --> 00:23:11,384 implementation 639 00:23:11,764 --> 00:23:13,865 because we had I I was always comparing 640 00:23:13,924 --> 00:23:15,464 it with what RSVPT 641 00:23:16,004 --> 00:23:18,345 offers today and what we provide 642 00:23:18,804 --> 00:23:20,744 in terms of fast route to our customers. 643 00:23:21,284 --> 00:23:21,784 So 644 00:23:22,884 --> 00:23:24,345 many years ago, the 645 00:23:26,539 --> 00:23:28,779 softwares did not the operating systems did not 646 00:23:28,779 --> 00:23:30,720 have the same level of protection available, 647 00:23:31,740 --> 00:23:32,880 in all the vendors. 648 00:23:33,180 --> 00:23:35,359 Cisco did, pretty well in 649 00:23:36,220 --> 00:23:37,740 in, I think, 06/2005 650 00:23:37,740 --> 00:23:38,240 onwards, 651 00:23:38,539 --> 00:23:39,600 I o '6 r. 652 00:23:41,085 --> 00:23:43,345 So in TI LFA, we we, 653 00:23:45,644 --> 00:23:48,625 use SRLG protection and node protection both, 654 00:23:49,325 --> 00:23:51,184 pretty much what we use for RSVPT. 655 00:23:51,884 --> 00:23:54,339 It's a different way of using it, because, 656 00:23:54,339 --> 00:23:56,679 originally, even the SRLG protection 657 00:23:56,980 --> 00:23:59,779 was not that well in in Cisco's implementation 658 00:23:59,779 --> 00:24:00,599 of TILFA. 659 00:24:01,940 --> 00:24:03,399 It was only local SRLG. 660 00:24:04,099 --> 00:24:04,599 So 661 00:24:04,980 --> 00:24:07,619 in like, any provider network, if a link 662 00:24:07,619 --> 00:24:10,055 goes down, which in a worldwide network always 663 00:24:10,055 --> 00:24:12,295 some incident would happen, you need fast reroute 664 00:24:12,295 --> 00:24:14,154 mechanism to reroute your traffic 665 00:24:14,535 --> 00:24:16,695 to avoid the downtimes of fifty millisecond, you 666 00:24:16,695 --> 00:24:17,674 know, fast rerouting. 667 00:24:19,494 --> 00:24:20,154 So TILFA 668 00:24:20,775 --> 00:24:21,755 does that by 669 00:24:22,134 --> 00:24:23,595 creating a backup route. 670 00:24:24,740 --> 00:24:26,679 There are two methods of 671 00:24:27,139 --> 00:24:29,700 implementing TILFA. The most popular, and I think 672 00:24:29,700 --> 00:24:31,720 that's what everybody goes for is 673 00:24:32,099 --> 00:24:34,899 per prefix backup route. So for every route 674 00:24:34,899 --> 00:24:36,599 in your routing table, there is a 675 00:24:37,035 --> 00:24:37,535 backup 676 00:24:37,914 --> 00:24:39,515 route. And it's not just a route in 677 00:24:39,515 --> 00:24:42,154 your routing table or routing information base. It's 678 00:24:42,154 --> 00:24:44,555 also installed in the forwarding information base and 679 00:24:44,555 --> 00:24:47,195 your label forwarding information base so that your 680 00:24:47,195 --> 00:24:49,994 label traffic could be switched over to the 681 00:24:49,994 --> 00:24:50,894 backup route. 682 00:24:51,195 --> 00:24:51,434 And, 683 00:24:52,549 --> 00:24:55,369 it does so by I mean, TI LFA 684 00:24:55,990 --> 00:24:58,150 has also had a journey from right from 685 00:24:58,150 --> 00:25:00,809 classic LFA then remote LFA. 686 00:25:01,990 --> 00:25:03,509 And TI LFA is 687 00:25:04,924 --> 00:25:07,804 works with SR because it it calculates the 688 00:25:07,804 --> 00:25:09,984 post convergence path. So if 689 00:25:10,605 --> 00:25:12,544 for on on a particular router, 690 00:25:12,845 --> 00:25:15,265 for a particular route, the next hop 691 00:25:15,644 --> 00:25:17,565 is a. And if that'll 692 00:25:17,964 --> 00:25:20,065 if a link towards that a goes down, 693 00:25:20,480 --> 00:25:22,400 what would be the post convergence path? And 694 00:25:22,400 --> 00:25:24,180 that post convergence path becomes 695 00:25:24,640 --> 00:25:26,019 your backup route in TILFA. 696 00:25:26,880 --> 00:25:27,380 And 697 00:25:27,680 --> 00:25:29,759 that makes sense because, eventually, this is what 698 00:25:29,759 --> 00:25:30,900 happens in RSVPT. 699 00:25:31,440 --> 00:25:32,259 So in RSVPT, 700 00:25:32,559 --> 00:25:34,820 even if you create a manual bypass tunnel, 701 00:25:35,595 --> 00:25:36,894 taking a longer path, 702 00:25:37,434 --> 00:25:39,694 to avoid any common transmission equipments, 703 00:25:40,394 --> 00:25:43,295 eventually, after the RSVP retry timer expires, 704 00:25:44,234 --> 00:25:46,555 it switches over to the next best path 705 00:25:46,555 --> 00:25:48,929 calculated by your link state routing protocol. That's 706 00:25:48,929 --> 00:25:51,649 where it tries to resignal your LSP. So 707 00:25:51,649 --> 00:25:53,029 the ILF, it does so, 708 00:25:54,369 --> 00:25:55,669 beforehand and by default. 709 00:25:56,129 --> 00:25:57,509 So that makes sense. And 710 00:25:58,289 --> 00:26:01,029 incorporating that with SRLG and node protection, 711 00:26:02,454 --> 00:26:04,694 it it offered everything that we were doing 712 00:26:04,694 --> 00:26:05,355 with RSVPT. 713 00:26:06,294 --> 00:26:09,274 Originally, with Cisco's implementation, we were not getting 714 00:26:09,494 --> 00:26:10,875 remote SRLG protection, 715 00:26:11,414 --> 00:26:13,914 which was available in in RSVPT. 716 00:26:15,089 --> 00:26:17,429 But later on, they implement they updated 717 00:26:17,809 --> 00:26:20,150 it, and it can do both now. So 718 00:26:21,329 --> 00:26:23,410 So it's not really just calculating the next 719 00:26:23,410 --> 00:26:25,809 best path, though. Right? Is it can add 720 00:26:26,289 --> 00:26:28,309 calculating a remote LFA, 721 00:26:28,875 --> 00:26:31,134 or is it only calculating an LFA? 722 00:26:32,795 --> 00:26:34,015 No. So it is 723 00:26:34,474 --> 00:26:38,174 it is calculating remote LFA and classic LFA 724 00:26:38,555 --> 00:26:41,515 both. Okay. And this was implementation. It is 725 00:26:41,515 --> 00:26:43,055 both because if your 726 00:26:43,480 --> 00:26:46,000 classic LFA calculation is very simple. So Right. 727 00:26:46,119 --> 00:26:47,720 It takes a little bit of CPU time. 728 00:26:47,720 --> 00:26:50,759 Yeah. So if if Can I say classic 729 00:26:50,759 --> 00:26:51,259 LFA? 730 00:26:51,960 --> 00:26:53,579 Classic LFA is basically 731 00:26:54,679 --> 00:26:57,640 EagerP feasible successors for people who don't know 732 00:26:57,640 --> 00:27:00,134 it. Although, it's a little bit looser than 733 00:27:00,134 --> 00:27:03,275 feasible successors. Fee feasible successors actually 734 00:27:03,894 --> 00:27:05,515 are a little more strict 735 00:27:05,894 --> 00:27:07,755 than classic LFA. Right? 736 00:27:08,134 --> 00:27:09,755 So Yeah. Remote LFA 737 00:27:10,230 --> 00:27:12,250 is I'm gonna tunnel through 738 00:27:12,549 --> 00:27:15,269 the router next to me, my neighbor, who 739 00:27:15,269 --> 00:27:16,009 would normally 740 00:27:16,390 --> 00:27:17,609 route back to me 741 00:27:18,150 --> 00:27:20,230 because I'm their best path right now. So 742 00:27:20,230 --> 00:27:21,529 I'm gonna actually use 743 00:27:21,910 --> 00:27:23,990 a tunnel to get through somebody who thinks 744 00:27:23,990 --> 00:27:26,705 I'm their best path to get beyond them 745 00:27:26,705 --> 00:27:28,865 to some place in the network where I 746 00:27:28,865 --> 00:27:31,265 know the traffic will be forwarded the correct 747 00:27:31,265 --> 00:27:34,305 direction. You can express this as p q 748 00:27:34,305 --> 00:27:36,785 space. You can express this as there's, like, 749 00:27:36,785 --> 00:27:39,105 five different mathematical models you can use to 750 00:27:39,105 --> 00:27:40,859 talk about this, which is part of the 751 00:27:40,859 --> 00:27:43,259 confusion for people is they get into all 752 00:27:43,259 --> 00:27:45,259 the math models and you're like, it's actually 753 00:27:45,259 --> 00:27:47,019 really simple. I'm just looking for some place 754 00:27:47,019 --> 00:27:48,940 in the network that I can terminate a 755 00:27:48,940 --> 00:27:51,500 tunnel that's gonna continue the traffic towards the 756 00:27:51,500 --> 00:27:52,000 destination. 757 00:27:52,515 --> 00:27:53,414 That's all I'm 758 00:27:53,875 --> 00:27:55,634 doing. So, anyway, continue. I'm sorry. So it 759 00:27:55,634 --> 00:27:56,934 already does LFA. 760 00:27:57,714 --> 00:27:59,875 Yeah. So it it does so the Cisco's 761 00:27:59,875 --> 00:28:02,434 implementation has classic LFA and TI LFA both. 762 00:28:02,434 --> 00:28:04,515 So for a backup path, if TI LFA 763 00:28:04,515 --> 00:28:06,595 and classic LFA are the same path, then 764 00:28:06,595 --> 00:28:08,214 classic LFA takes precedence. 765 00:28:08,759 --> 00:28:10,220 And for the TI LFA, 766 00:28:10,680 --> 00:28:12,599 yeah, as you said, in remote LFA, you 767 00:28:12,599 --> 00:28:15,080 have p space and q space, and the 768 00:28:15,080 --> 00:28:16,700 overlapping p q node 769 00:28:17,160 --> 00:28:18,059 becomes your 770 00:28:18,599 --> 00:28:20,775 point of local repair for to which you 771 00:28:20,775 --> 00:28:23,654 create the tunnel. And TILFA takes it one 772 00:28:23,654 --> 00:28:25,654 step further because if your p space and 773 00:28:25,654 --> 00:28:27,195 q space are not overlapping, 774 00:28:27,734 --> 00:28:30,795 then TILFA, because it computes the post convergence 775 00:28:30,934 --> 00:28:33,434 path, it forces it directs that, 776 00:28:34,455 --> 00:28:37,130 additional link even if it is not IGP, 777 00:28:37,830 --> 00:28:39,210 best path cost link, 778 00:28:39,670 --> 00:28:40,390 to use that, 779 00:28:41,509 --> 00:28:42,009 adjacency 780 00:28:42,630 --> 00:28:43,130 set, 781 00:28:43,830 --> 00:28:46,390 to direct between p space and jump from 782 00:28:46,390 --> 00:28:49,190 p space to q space. And in my 783 00:28:49,190 --> 00:28:51,744 book, the topologies that I have created and 784 00:28:51,744 --> 00:28:53,105 the labs that I have taken from, 785 00:28:54,865 --> 00:28:57,184 basic implementation of t I l f a 786 00:28:57,184 --> 00:28:58,164 right from the introduction. 787 00:28:58,704 --> 00:29:00,724 In every lab, I have tried to create 788 00:29:00,785 --> 00:29:02,164 a a topology diagram 789 00:29:02,545 --> 00:29:03,880 where the p 790 00:29:04,180 --> 00:29:06,740 space and q space are demonstrated, then I 791 00:29:06,740 --> 00:29:07,880 have shown the calculation 792 00:29:08,500 --> 00:29:10,580 and based on how what the link costs 793 00:29:10,580 --> 00:29:12,360 are. So the end to end metric, 794 00:29:13,220 --> 00:29:15,380 is the reason behind having this these many 795 00:29:15,380 --> 00:29:17,700 routers in one p space and these many 796 00:29:17,700 --> 00:29:19,000 routers in q space. 797 00:29:19,515 --> 00:29:20,015 And, 798 00:29:20,394 --> 00:29:22,555 the end to end path cost, the post 799 00:29:22,555 --> 00:29:25,115 convergence path cost, which is why TILFA chose 800 00:29:25,115 --> 00:29:25,775 to redirect, 801 00:29:26,474 --> 00:29:28,315 I mean, jump from piece space to queue 802 00:29:28,315 --> 00:29:28,815 space. 803 00:29:29,835 --> 00:29:31,355 This this is all I have tried to 804 00:29:31,355 --> 00:29:31,855 cover. 805 00:29:32,640 --> 00:29:35,380 And, the reason for covering this in the 806 00:29:35,759 --> 00:29:36,259 because 807 00:29:36,960 --> 00:29:38,559 if you if you do not have backup 808 00:29:38,559 --> 00:29:40,160 path and if you do not have segment 809 00:29:40,160 --> 00:29:40,660 routing, 810 00:29:41,119 --> 00:29:41,619 the, 811 00:29:42,080 --> 00:29:43,539 segment routing traffic engineering, 812 00:29:44,160 --> 00:29:46,974 then it it wasn't becoming very clear 813 00:29:47,434 --> 00:29:49,994 how these how the label stack is getting 814 00:29:49,994 --> 00:29:51,214 created at the source. 815 00:29:51,755 --> 00:29:52,815 So with the introduction 816 00:29:53,274 --> 00:29:55,615 of TILFA in the lab, because the 817 00:29:55,994 --> 00:29:58,609 backup path would have a stack of labels, 818 00:29:58,829 --> 00:30:00,589 and the point of local repair had to 819 00:30:00,589 --> 00:30:02,289 create the entire label stack 820 00:30:02,750 --> 00:30:05,250 to the destination for the backup path. And 821 00:30:05,710 --> 00:30:07,789 through that, I have tried to demonstrate that 822 00:30:07,789 --> 00:30:10,609 this is how segment routing in MPLS network, 823 00:30:11,150 --> 00:30:11,650 manifests. 824 00:30:12,484 --> 00:30:14,484 So rather so what you're saying is is 825 00:30:14,484 --> 00:30:15,465 that in TILFA, 826 00:30:17,045 --> 00:30:18,424 instead of just creating 827 00:30:19,045 --> 00:30:20,884 so so if I have a stack of 828 00:30:20,884 --> 00:30:21,625 three labels 829 00:30:22,085 --> 00:30:24,744 already on the packet, and I get to 830 00:30:24,805 --> 00:30:26,664 some point in the network where 831 00:30:27,419 --> 00:30:29,419 I see that I need to follow a 832 00:30:29,419 --> 00:30:30,319 backup path, 833 00:30:31,179 --> 00:30:33,500 rather than just adding more labels to get 834 00:30:33,500 --> 00:30:35,579 me to the next hop, you're saying we 835 00:30:35,579 --> 00:30:38,399 actually recreate the path from that point forward 836 00:30:39,019 --> 00:30:40,799 all the way to the same destination 837 00:30:41,775 --> 00:30:43,855 using the backup path. Is that correct? Or 838 00:30:43,855 --> 00:30:44,914 are we just adding 839 00:30:45,535 --> 00:30:47,855 okay. I'm gonna add a new label. I'm 840 00:30:47,855 --> 00:30:50,095 gonna push a new label that gets me 841 00:30:50,095 --> 00:30:51,934 to a to a point where I won't 842 00:30:51,934 --> 00:30:54,335 loop. And then when that person when that 843 00:30:54,335 --> 00:30:56,869 router pops it, it's gonna be the original 844 00:30:56,869 --> 00:30:59,190 label stack to get them back to where 845 00:30:59,190 --> 00:31:00,169 they need to go. 846 00:31:00,869 --> 00:31:02,950 That might be problematic because if it takes 847 00:31:02,950 --> 00:31:03,109 you 848 00:31:03,990 --> 00:31:05,509 how do you avoid the loop in that 849 00:31:05,509 --> 00:31:07,605 case? Right? If it happens that 850 00:31:08,404 --> 00:31:11,044 the device is You already have a stack 851 00:31:11,044 --> 00:31:13,804 of label coming from label edge router Mhmm. 852 00:31:13,924 --> 00:31:16,025 To a label switch router in intermediary, 853 00:31:17,204 --> 00:31:17,704 path. 854 00:31:18,164 --> 00:31:20,424 And on that path, the next hop goes, 855 00:31:20,730 --> 00:31:22,250 let's say, for the next hop to go 856 00:31:22,250 --> 00:31:24,809 down, a TILFA backup path has been calculated 857 00:31:24,809 --> 00:31:26,269 from the label switch router. 858 00:31:26,650 --> 00:31:28,750 So that path would include 859 00:31:29,049 --> 00:31:31,390 that TILFA backup path would include 860 00:31:31,769 --> 00:31:32,829 a set of labels. 861 00:31:33,194 --> 00:31:35,454 Now the the incoming set of label 862 00:31:35,994 --> 00:31:38,714 would simply become the inner label so that 863 00:31:38,714 --> 00:31:40,255 the top labels would be, 864 00:31:40,714 --> 00:31:43,835 the transport path to avoid the loop. Okay. 865 00:31:43,835 --> 00:31:46,850 And then normal forwarding would take place. Right. 866 00:31:46,850 --> 00:31:49,009 So you're just adding on another layer of 867 00:31:49,009 --> 00:31:50,309 labels. You're not, 868 00:31:50,690 --> 00:31:51,190 like, 869 00:31:51,490 --> 00:31:54,289 redeveloping the entire path from the Yes. From 870 00:31:54,370 --> 00:31:56,529 okay. Right. Just making sure I understood how 871 00:31:56,529 --> 00:31:57,509 that worked. Yeah. 872 00:31:59,835 --> 00:32:01,535 So how different is this, 873 00:32:02,474 --> 00:32:05,195 would you say, than standard other than it 874 00:32:05,195 --> 00:32:06,015 being SR? 875 00:32:07,595 --> 00:32:10,255 So you're add so in standard MPLS, 876 00:32:10,955 --> 00:32:11,855 if you do 877 00:32:12,315 --> 00:32:13,615 reroute like this, 878 00:32:14,019 --> 00:32:15,640 because you're pushing and popping, 879 00:32:16,900 --> 00:32:19,619 you actually push to the next, you know, 880 00:32:19,619 --> 00:32:22,179 to the next hop or whatever that's beyond 881 00:32:22,179 --> 00:32:23,640 the beyond the loop. 882 00:32:24,579 --> 00:32:26,819 And then you take over forwarding from there. 883 00:32:26,819 --> 00:32:28,359 But in the case of SR, 884 00:32:29,144 --> 00:32:31,065 you have to still have the full stack 885 00:32:31,065 --> 00:32:31,724 of labels, 886 00:32:32,265 --> 00:32:34,265 I guess. I mean, I'm trying to figure 887 00:32:34,265 --> 00:32:35,884 out, like, what specifically 888 00:32:36,184 --> 00:32:38,904 is different about this than standard? I have 889 00:32:38,904 --> 00:32:41,465 covered, there there is a chapter in this 890 00:32:41,465 --> 00:32:43,625 which is about micro loop avoidance, which covers 891 00:32:43,625 --> 00:32:44,525 one such scenario 892 00:32:45,039 --> 00:32:45,539 where 893 00:32:46,079 --> 00:32:46,740 if you, 894 00:32:47,200 --> 00:32:49,920 for any reason, forward the stack of labels 895 00:32:49,920 --> 00:32:52,160 to a to the next hop, which you 896 00:32:52,160 --> 00:32:53,619 believe is the backup. 897 00:32:54,400 --> 00:32:57,519 Right. Right. But but that next hop doesn't 898 00:32:57,519 --> 00:32:59,255 have any router to the destination, 899 00:32:59,634 --> 00:33:01,795 and the next stop thinks you you yourself 900 00:33:01,795 --> 00:33:03,875 are the are the next stop. So that 901 00:33:03,875 --> 00:33:05,555 next stop will trap forward it back to 902 00:33:05,555 --> 00:33:07,394 you, and that will create a micro loop. 903 00:33:07,394 --> 00:33:09,714 Right. Now to avoid that, you enable micro 904 00:33:09,714 --> 00:33:11,954 loop avoidance in in ASR, and what it 905 00:33:11,954 --> 00:33:14,359 would do, it would detect change in topologies 906 00:33:14,580 --> 00:33:15,320 as such. 907 00:33:15,700 --> 00:33:17,859 And for every change in the topology, it 908 00:33:17,859 --> 00:33:19,640 would create an explicit tunnel. 909 00:33:20,099 --> 00:33:22,340 Now this is not a tunnel for your 910 00:33:22,340 --> 00:33:24,420 backup path. Now this tunnel is for your 911 00:33:24,420 --> 00:33:26,920 primary path. We had a label stack 912 00:33:27,299 --> 00:33:28,200 to a router, 913 00:33:28,964 --> 00:33:29,464 which 914 00:33:30,164 --> 00:33:31,785 will not send it back to you. 915 00:33:32,244 --> 00:33:34,565 And you're not none of your intermediary hops 916 00:33:34,565 --> 00:33:36,184 will think that to that destination, 917 00:33:36,644 --> 00:33:38,244 the traffic needs to be sent back to 918 00:33:38,244 --> 00:33:40,005 you because they are all in the p 919 00:33:40,005 --> 00:33:40,505 space. 920 00:33:40,884 --> 00:33:42,025 And from there, 921 00:33:42,720 --> 00:33:45,599 the label pop mechanism would happen because the 922 00:33:45,599 --> 00:33:46,099 destination 923 00:33:46,480 --> 00:33:48,099 is the node set. 924 00:33:48,400 --> 00:33:50,720 So it would pop its top label. The 925 00:33:50,720 --> 00:33:52,720 penalty made for router would do it, but 926 00:33:52,720 --> 00:33:53,200 it would, 927 00:33:54,160 --> 00:33:56,640 get the remaining stack of the label, and 928 00:33:56,640 --> 00:33:58,634 it would carry on with the forwarding 929 00:33:59,174 --> 00:34:00,714 to avoid the micro loop. 930 00:34:01,974 --> 00:34:03,994 Okay. That's interesting. Okay. 931 00:34:05,734 --> 00:34:07,414 And so you have labs for this as 932 00:34:07,414 --> 00:34:09,574 well where people can actually set this up 933 00:34:09,574 --> 00:34:11,190 and see it happen 934 00:34:11,650 --> 00:34:12,469 in the network 935 00:34:12,849 --> 00:34:14,469 based on failures? Okay. 936 00:34:15,170 --> 00:34:17,969 Yeah. So I've I've uploaded the Cisco CML 937 00:34:17,969 --> 00:34:20,530 topology definition file and e v n g 938 00:34:20,530 --> 00:34:21,590 definition file. 939 00:34:22,769 --> 00:34:24,210 The e v n g is uploaded for 940 00:34:24,210 --> 00:34:25,750 the Juniper as well as Cisco. 941 00:34:26,744 --> 00:34:27,944 So all they have to do is just 942 00:34:27,944 --> 00:34:29,704 import it in the even g, and if 943 00:34:29,704 --> 00:34:30,844 they have the right image, 944 00:34:32,264 --> 00:34:34,184 they can simply spin it up in no 945 00:34:34,184 --> 00:34:34,684 time. 946 00:34:35,545 --> 00:34:36,045 Cool. 947 00:34:36,505 --> 00:34:37,625 Of course, you have to have all the 948 00:34:37,625 --> 00:34:38,284 right images, 949 00:34:39,150 --> 00:34:41,150 which is which is always I don't know. 950 00:34:41,150 --> 00:34:43,329 Yeah. That's always really painful, 951 00:34:43,869 --> 00:34:46,349 getting all the images and making sure they're 952 00:34:46,349 --> 00:34:47,409 all working. And 953 00:34:47,949 --> 00:34:49,710 and even g, what are you running on 954 00:34:49,710 --> 00:34:52,224 that you're running even even g? Are you 955 00:34:52,224 --> 00:34:54,224 running this, like, in the cloud on a 956 00:34:54,224 --> 00:34:56,304 high powered box? Because I every time I 957 00:34:56,304 --> 00:34:58,565 try to run even in g, it's, like, 958 00:34:59,264 --> 00:34:59,764 slow. 959 00:35:05,025 --> 00:35:05,264 So, 960 00:35:06,289 --> 00:35:08,130 I tested it because for the benefit of 961 00:35:08,130 --> 00:35:10,389 everybody, I had to test the hardware requirement. 962 00:35:11,250 --> 00:35:14,050 The server I have is a very big 963 00:35:14,050 --> 00:35:16,769 server. It is 96 vCPU cores and one 964 00:35:16,769 --> 00:35:18,389 terabytes of RAM. So 965 00:35:18,984 --> 00:35:21,005 I I had all the resources available. 966 00:35:21,385 --> 00:35:25,065 But for everyone's benefit, I created my Google 967 00:35:25,065 --> 00:35:27,545 Cloud Platform account, and even g website has 968 00:35:27,545 --> 00:35:29,625 a very good documentation on how to set 969 00:35:29,625 --> 00:35:30,605 this up on GCP. 970 00:35:31,139 --> 00:35:32,739 Mhmm. And all you have to do is 971 00:35:32,739 --> 00:35:34,900 just follow those, few steps, and in no 972 00:35:34,900 --> 00:35:37,380 time, you have even g running, up and 973 00:35:37,380 --> 00:35:37,880 running. 974 00:35:38,500 --> 00:35:40,119 So with 32 975 00:35:40,260 --> 00:35:42,099 vCPU cores and 28 976 00:35:42,099 --> 00:35:44,385 GB RAM in Google Clyde Cloud platform, I 977 00:35:44,385 --> 00:35:45,905 could get this up and running in no 978 00:35:45,905 --> 00:35:47,364 time. And in fact, I included 979 00:35:47,744 --> 00:35:50,085 container lab as well. Okay. 980 00:35:50,785 --> 00:35:53,285 So Nice. I created another server and 981 00:35:54,465 --> 00:35:55,844 containerized the iOSXR 982 00:35:56,144 --> 00:35:57,445 v nine k image 983 00:35:57,890 --> 00:35:59,250 and tested it with that, 984 00:35:59,730 --> 00:36:00,949 container lab platform 985 00:36:01,250 --> 00:36:03,570 and all worked out with 30 c 32 986 00:36:03,570 --> 00:36:04,070 CPUs. 987 00:36:04,530 --> 00:36:05,030 Okay. 988 00:36:05,410 --> 00:36:06,949 Cool. That's nice. Good. 989 00:36:07,730 --> 00:36:09,730 Okay. I don't have any other questions unless 990 00:36:09,730 --> 00:36:10,545 you do, Tom. 991 00:36:11,264 --> 00:36:12,944 No. It's been a great conversation. Thank you, 992 00:36:12,944 --> 00:36:14,464 Himans. Yeah. And thank you for coming on. 993 00:36:14,464 --> 00:36:16,005 I'm a lot of it. For having me. 994 00:36:16,065 --> 00:36:16,464 And, 995 00:36:17,025 --> 00:36:19,184 we'll put a pointer to the book, I 996 00:36:19,184 --> 00:36:21,744 suppose, in the show notes so people can 997 00:36:21,744 --> 00:36:23,605 find it if they want to. 998 00:36:24,199 --> 00:36:24,699 And 999 00:36:25,159 --> 00:36:27,099 I'll actually try to scare up some documentation 1000 00:36:27,239 --> 00:36:27,980 on TILFA 1001 00:36:28,359 --> 00:36:30,599 because that's a new thing that not many 1002 00:36:30,599 --> 00:36:32,219 people are talking about yet. 1003 00:36:32,839 --> 00:36:35,480 And it's actually a very interesting topic. I've 1004 00:36:35,480 --> 00:36:37,260 I've run into it a couple of times 1005 00:36:37,480 --> 00:36:38,380 in my travels. 1006 00:36:38,815 --> 00:36:41,295 I'm not particularly thinking about deploying it right 1007 00:36:41,295 --> 00:36:41,795 now. 1008 00:36:42,894 --> 00:36:44,335 So, you know, it's one of those things 1009 00:36:44,335 --> 00:36:46,094 that that you just gotta go learn because 1010 00:36:46,094 --> 00:36:48,034 it's something new that's going on out there. 1011 00:36:49,054 --> 00:36:51,659 Okay. So, Hemant, any way for people to 1012 00:36:51,659 --> 00:36:53,019 get in touch with you? Do you blog 1013 00:36:53,019 --> 00:36:55,039 someplace? Do you have a blog? Do you 1014 00:36:55,659 --> 00:36:57,599 write on some social media 1015 00:36:58,139 --> 00:36:59,760 network such as it is? 1016 00:37:02,139 --> 00:37:04,139 I I have stopped blogging for for a 1017 00:37:04,139 --> 00:37:05,819 while now. I did have a blog on 1018 00:37:05,819 --> 00:37:08,135 GitHub pages, but, not anymore. 1019 00:37:08,755 --> 00:37:10,594 I try did try to have multiple social 1020 00:37:10,594 --> 00:37:12,755 media accounts, but very difficult to manage. So 1021 00:37:12,755 --> 00:37:14,135 I'm available on LinkedIn, 1022 00:37:14,434 --> 00:37:17,074 and that's where I'm most active on, and 1023 00:37:17,074 --> 00:37:19,155 people can connect me on that. In fact, 1024 00:37:19,394 --> 00:37:21,840 a few people who did buy the book, 1025 00:37:21,920 --> 00:37:22,579 they had, 1026 00:37:23,680 --> 00:37:26,719 appreciated my work on LinkedIn through messages, and, 1027 00:37:27,360 --> 00:37:29,219 I in fact offered them to, 1028 00:37:29,840 --> 00:37:31,760 clarify any doubts if I could not cover 1029 00:37:31,760 --> 00:37:33,380 them properly in the book. And 1030 00:37:33,840 --> 00:37:37,094 Yeah. Yeah. Yeah. They have the Awesome. Good. 1031 00:37:37,094 --> 00:37:37,835 That's great. 1032 00:37:38,775 --> 00:37:39,914 And, Tom, 1033 00:37:40,454 --> 00:37:42,074 should I just answer it for you? 1034 00:37:42,454 --> 00:37:43,994 No answer. I'm on LinkedIn. 1035 00:37:45,735 --> 00:37:48,215 I have solidarity finally. I have their thank 1036 00:37:48,215 --> 00:37:49,574 you, Iman. We have a we have a 1037 00:37:49,574 --> 00:37:51,434 guest that sees things the way I do. 1038 00:37:51,735 --> 00:37:53,289 Oh, Twitter. Just just LinkedIn. 1039 00:37:53,590 --> 00:37:55,530 Just LinkedIn. Wow. Okay. 1040 00:37:56,230 --> 00:37:57,929 Actually, I haven't logged in to my 1041 00:37:58,309 --> 00:38:00,309 into that in the routing geek account in, 1042 00:38:00,309 --> 00:38:01,750 like, a week. I probably need to go 1043 00:38:01,750 --> 00:38:03,750 do that because I just haven't been over 1044 00:38:03,750 --> 00:38:06,230 there to look at x in a week 1045 00:38:06,230 --> 00:38:06,889 or so. 1046 00:38:07,684 --> 00:38:09,204 I've been very busy. I'm doing a lot 1047 00:38:09,204 --> 00:38:11,284 of recordings and other stuff. So, wow, it's 1048 00:38:11,284 --> 00:38:12,025 it's crazy. 1049 00:38:12,724 --> 00:38:13,224 Alright. 1050 00:38:13,684 --> 00:38:15,525 So I'm Russ White. You can always find 1051 00:38:15,525 --> 00:38:16,885 me here at the hedge. You can find 1052 00:38:16,885 --> 00:38:18,425 me on rule11.tech, 1053 00:38:18,565 --> 00:38:21,224 on x whenever I get over there, LinkedIn 1054 00:38:21,284 --> 00:38:22,744 whenever I get over there, 1055 00:38:23,099 --> 00:38:25,200 not always on social media, but, 1056 00:38:25,820 --> 00:38:27,280 available when those are there. 1057 00:38:27,660 --> 00:38:29,500 And so, anyway, we know we live in 1058 00:38:29,500 --> 00:38:31,739 a detention driven economy, and we thank you 1059 00:38:31,739 --> 00:38:34,140 for listening to this episode of The Hedge 1060 00:38:34,140 --> 00:38:36,394 all the way to the bitter end, and 1061 00:38:36,394 --> 00:38:37,934 we will catch you next time.