WEBVTT 1 00:00:00.120 --> 00:00:03.359 You know, it's easy to take for granted that instant connection, 2 00:00:03.799 --> 00:00:08.359 that crystal clear video call, or that lightning fast download. 3 00:00:08.640 --> 00:00:09.279 It really is. 4 00:00:09.759 --> 00:00:13.960 But behind that seamless digital experience, there's a constant, silent 5 00:00:14.039 --> 00:00:18.239 battle being fought against complexity, against failure, making sure your 6 00:00:18.320 --> 00:00:21.399 data gets where it needs to go, fast and well 7 00:00:21.839 --> 00:00:22.480 without a hitch. 8 00:00:22.760 --> 00:00:24.239 Yeah, a lot goes on under the hood. 9 00:00:24.800 --> 00:00:27.640 Today we're taking a bit of a shortcut. We want 10 00:00:27.679 --> 00:00:30.839 you to be well informed about a fascinating yet often 11 00:00:31.039 --> 00:00:33.560 unseen aspect of modern networking. 12 00:00:33.200 --> 00:00:34.359 A really crucial one. 13 00:00:34.439 --> 00:00:37.280 We're embarking on a deep dive into segment reading in 14 00:00:37.399 --> 00:00:41.119 MPLS networks. Now, this is key to understanding how high 15 00:00:41.159 --> 00:00:47.119 performance networks are evolving. We're talking faster, more flexible, and incredibly. 16 00:00:46.520 --> 00:00:49.000 Resilient, and we're here to guide you through some of 17 00:00:49.039 --> 00:00:51.240 the technical stuff. We'll pull out the most important bits, 18 00:00:51.240 --> 00:00:55.240 the surprising facts, basically help you grasp what's truly important 19 00:00:55.240 --> 00:00:56.640 in this pretty complex field. 20 00:00:56.799 --> 00:01:01.439 Our mission is clear, let's demystify this journey from say 21 00:01:01.719 --> 00:01:05.159 traditional network setups to the cutting edge solutions that keep 22 00:01:05.200 --> 00:01:11.920 your online experience seamless even when things go wrong. Laying 23 00:01:11.920 --> 00:01:16.040 the groundwork the world of MPLS. Okay, let's unpack this. 24 00:01:16.079 --> 00:01:18.079 Where do we start? I guess with the foundation right, 25 00:01:18.560 --> 00:01:21.599 Multi Protocol label switching MPLS exactly. 26 00:01:21.719 --> 00:01:23.840 MPLS has been a workhourse for a long time. 27 00:01:23.920 --> 00:01:26.159 People sometimes call it layer two point five, which is 28 00:01:26.200 --> 00:01:27.319 kind of a neat way to think about it, like 29 00:01:27.359 --> 00:01:28.319 a clever shortcut. 30 00:01:28.480 --> 00:01:31.519 It is. Instead of traditional IP routing, where every single 31 00:01:31.599 --> 00:01:34.200 router has to look up the full destination IP address, 32 00:01:34.239 --> 00:01:37.879 which takes time, MPLS uses these short, fixed length things 33 00:01:37.920 --> 00:01:41.079 called labels, labels, right, little tags pretty much. And what's 34 00:01:41.120 --> 00:01:44.359 fascinating is how these labels just simplify the whole forwarding decision. 35 00:01:44.400 --> 00:01:47.439 Think of it like a digital sticky note on each packet, 36 00:01:47.480 --> 00:01:50.000 all right. That note tells the router exactly where to 37 00:01:50.040 --> 00:01:52.280 send it next, often without needing to look deep into 38 00:01:52.280 --> 00:01:55.040 the IP header. Again, saves a lot of processing. 39 00:01:55.159 --> 00:01:58.040 So how does that work in practice? Are there specific actions? 40 00:01:58.280 --> 00:02:02.560 Yeah? There are three core label switching operations. First, you've 41 00:02:02.560 --> 00:02:06.359 got push. When a packet first enters the NPLS zone, 42 00:02:06.359 --> 00:02:09.199 the first router, the ingress router, it pushes a label 43 00:02:09.240 --> 00:02:11.080 onto it attaches that first sticky note. 44 00:02:11.159 --> 00:02:11.479 Got it. 45 00:02:11.960 --> 00:02:14.759 Then, as it travels to the middle the intermediate routers, 46 00:02:14.800 --> 00:02:17.840 they do a swap. They replace the incoming label with 47 00:02:17.919 --> 00:02:19.400 a new outgoing label. 48 00:02:19.479 --> 00:02:21.240 Why swap it? Whant to keep the same one? 49 00:02:21.639 --> 00:02:25.719 Ah? Because labels usually only have meaning locally between two 50 00:02:25.919 --> 00:02:29.800 adjacent routers, like changing local road names as you travel 51 00:02:29.840 --> 00:02:32.479 towards a destination city, So you swap the label for 52 00:02:32.599 --> 00:02:35.319 the next hops. Understanding makes sense. And finally, when the 53 00:02:35.360 --> 00:02:38.240 packet gets near the end or leaves the MPLS part 54 00:02:38.280 --> 00:02:40.840 of the network, the label gets popped. 55 00:02:40.840 --> 00:02:42.800 Removed, so you rise clean at the destination. 56 00:02:43.199 --> 00:02:47.199 Usually there's an optimization called penultimate hop popping. 57 00:02:46.919 --> 00:02:49.840 PHP penultimate meaning second. 58 00:02:49.520 --> 00:02:53.039 To last, Exactly the router right before the final destination 59 00:02:53.159 --> 00:02:56.080 pops the label. This saves the very last router a 60 00:02:56.120 --> 00:02:58.800 bit of work. Let's it focus just on the final delivery. 61 00:02:58.960 --> 00:03:03.439 Clever. Okay, So labels get pushed, swapped, popped. But how 62 00:03:03.479 --> 00:03:06.360 do the routers agree on what label means? What? How 63 00:03:06.400 --> 00:03:10.360 are these labels these instructions actually distributed? 64 00:03:10.560 --> 00:03:14.800 Good question. That's where protocols like LP come in. Label 65 00:03:14.840 --> 00:03:18.520 Distribution Protocol LVP YEP. LDP's one of the main ways 66 00:03:18.599 --> 00:03:20.599 routers talk to each other to set up these label 67 00:03:20.639 --> 00:03:23.120 paths what we call label switch paths or LSPs. It 68 00:03:23.120 --> 00:03:24.319 builds those express lanes. 69 00:03:24.400 --> 00:03:26.240 And LDP doesn't work in a vacuum, right, It needs 70 00:03:26.280 --> 00:03:27.919 to know the network layout. 71 00:03:27.560 --> 00:03:31.080 First, precisely underneath LP you almost always have an interior 72 00:03:31.120 --> 00:03:35.280 Gateway protocol and IGP something like isis is common? 73 00:03:35.520 --> 00:03:36.280 Isis okay? 74 00:03:36.319 --> 00:03:38.879 Think of the IGP as the map maker. It figures 75 00:03:38.919 --> 00:03:41.680 out the entire network topology, all the routers, all the links. 76 00:03:41.800 --> 00:03:44.439 It builds this big map called the Link State Database 77 00:03:44.520 --> 00:03:47.759 or LSDB, the master map, right, and from that map, 78 00:03:47.840 --> 00:03:50.719 each router creates its own route book, the Routing Information 79 00:03:50.840 --> 00:03:54.000 Base IRI. But for super fast lookups, it compiles a 80 00:03:54.080 --> 00:03:56.800 cheat sheet, the Forwarding Information Base the FIB. 81 00:03:56.800 --> 00:03:57.680 FIB for forwarding. 82 00:03:57.840 --> 00:04:01.080 You got it. LDP then uses that f that optimized 83 00:04:01.120 --> 00:04:04.240 map to assign its labels and build those fast LSPs. 84 00:04:04.439 --> 00:04:07.280 So, bringing it back to the listener, why does this 85 00:04:07.400 --> 00:04:10.439 NPLS stuff, even though it's been around, still matter to 86 00:04:10.520 --> 00:04:11.000 you today? 87 00:04:11.159 --> 00:04:14.240 Because it's still the backbone for so many high speed networks. 88 00:04:14.280 --> 00:04:17.519 It's often the unsung hero behind your fast internet. You're 89 00:04:17.519 --> 00:04:21.360 streaming your work VPN. It's that foundational layer that makes 90 00:04:21.399 --> 00:04:26.399 so much of the modern digital world possible and frankly efficient. Two. 91 00:04:27.000 --> 00:04:31.240 The next evolution segment routing SR mpls. 92 00:04:31.279 --> 00:04:34.240 All right, MPLS gives us efficient paths, but the tech 93 00:04:34.279 --> 00:04:38.199 world never stands still. Where does segment routing SR fit 94 00:04:38.240 --> 00:04:40.759 into this picture? How does it take things to the 95 00:04:40.759 --> 00:04:41.319 next level? 96 00:04:41.439 --> 00:04:44.040 SR or segment routing Sometimes you'll hear it called spring 97 00:04:44.279 --> 00:04:47.319 source Packet routing and networking is a really big evolution, 98 00:04:47.519 --> 00:04:51.120 a fundamental shift. Actually. The core idea the source, no, 99 00:04:51.279 --> 00:04:53.720 the very first router that sees the packet decides the 100 00:04:53.879 --> 00:04:56.560 entire path through the network, not just the next topic 101 00:04:56.600 --> 00:04:58.879 in traditional routing or even basic LDP. 102 00:04:58.839 --> 00:05:01.079 The whole path from the start. 103 00:05:00.839 --> 00:05:03.279 The whole path. It does this using an ordered list 104 00:05:03.279 --> 00:05:05.720 of segments. Think of segments as instructions like go here, 105 00:05:05.759 --> 00:05:08.519 then go there. These are identified by a segment identifiers 106 00:05:08.600 --> 00:05:09.839 or sids. 107 00:05:09.759 --> 00:05:13.279 Sids okay, and these sids they get encoded right into 108 00:05:13.319 --> 00:05:14.639 the packet header itself. 109 00:05:14.399 --> 00:05:16.160 As a packet carries its own map. 110 00:05:16.240 --> 00:05:19.199 In a way. Yes, A huge advantage of this is 111 00:05:19.240 --> 00:05:22.399 that it effectively reduces the network's statefulness. 112 00:05:22.480 --> 00:05:25.800 Okay, reduces statefulness. That sounds good, but what does it 113 00:05:25.879 --> 00:05:29.600 mean for the network Practically? Speaking, fewer headaches for the engineers. 114 00:05:29.680 --> 00:05:33.519 Definitely fewer headaches. Think about it. If the source dictates 115 00:05:33.560 --> 00:05:36.000 the path, the routers in the middle don't need to 116 00:05:36.079 --> 00:05:39.000 keep track of complex path information for every single flow. 117 00:05:39.399 --> 00:05:41.600 They just need to know how to read the next instruction, 118 00:05:41.720 --> 00:05:46.079 the next SID in the packet header and forward it along. Ah. 119 00:05:46.120 --> 00:05:48.079 So they become simpler, much simpler. 120 00:05:48.399 --> 00:05:52.879 Less state means less memory usage, faster processing, faster convergence 121 00:05:52.879 --> 00:05:56.879 when things change. It enhances scalability and resilience quite a bit. 122 00:05:57.040 --> 00:05:59.519 It makes the network leaner, more agile. 123 00:05:59.800 --> 00:06:02.560 Soll how does sr actually work with MPLS. Is it 124 00:06:02.600 --> 00:06:04.399 a replacement or does it build on top? 125 00:06:04.519 --> 00:06:09.319 That's the clever part. SRMPLS uses the existing MPLS data plane, 126 00:06:09.360 --> 00:06:12.920 the actual packet forwarding, the pushing, swapping, popping labels. That 127 00:06:13.079 --> 00:06:16.199 machinery stays largely the same. Oh interesting, So the hardware 128 00:06:16.199 --> 00:06:18.240 doesn't necessarily need a complete overhaul. 129 00:06:18.399 --> 00:06:21.000 Often. No, the big difference is in the control plane. 130 00:06:21.000 --> 00:06:25.079 How labels are assigned and distributed in SRMPLS. Those sids 131 00:06:25.079 --> 00:06:28.160 we talked about, they're encoded as MPLS labels. Ah. 132 00:06:28.199 --> 00:06:31.439 Okay, so sids become labels are they're different kinds of sids. 133 00:06:31.680 --> 00:06:35.639 Yes, primarily two types you need to know. First, Prefix sids, 134 00:06:35.680 --> 00:06:38.360 which are often called node sids. Think of these as 135 00:06:38.439 --> 00:06:43.079 global segments. They uniquely identify a specific router, usually its 136 00:06:43.120 --> 00:06:45.240 main loop back interface address. 137 00:06:45.040 --> 00:06:46.839 Global, meaning unique across the. 138 00:06:46.759 --> 00:06:49.759 Whole network within the sr domain. Yes, they're assigned from 139 00:06:49.759 --> 00:06:52.360 a specific block of labels called the Segment Routing Global 140 00:06:52.360 --> 00:06:57.040 Block or sRGB. On Cisco IOSXR, for instance, that default 141 00:06:57.120 --> 00:07:00.879 range is sixteen thousand to two three nine nine nine. 142 00:06:59.959 --> 00:07:01.959 M okay a reserved range. 143 00:07:01.680 --> 00:07:04.920 Exactly, and the specific label value is usually the sRGB 144 00:07:05.000 --> 00:07:07.800 based plus an index. So if the SOGB starts at 145 00:07:07.839 --> 00:07:10.160 sixteen thousand and a node has an index or a 146 00:07:10.160 --> 00:07:13.560 node SID of seven, its label is sixteen thousand and seven. 147 00:07:13.600 --> 00:07:14.600 Got it? What's the other type? 148 00:07:14.680 --> 00:07:17.839 The other main type is adjacency sids. These are local segments. 149 00:07:17.920 --> 00:07:21.079 They identify as specific link and adjacency between two directly 150 00:07:21.079 --> 00:07:22.319 connected routers, so. 151 00:07:22.360 --> 00:07:24.600 Not global just for that one connection, right. 152 00:07:24.600 --> 00:07:27.600 They're often dynamically allocated, say from a different range like 153 00:07:27.639 --> 00:07:31.959 starting from twenty four thousand on IOSXR, and crucially only 154 00:07:32.000 --> 00:07:35.560 the router originating that SID for its link installs it 155 00:07:35.560 --> 00:07:39.079 in its forwarding table. It's LFIB. It's only meaningful locally. 156 00:07:39.000 --> 00:07:43.040 Okay, prefixes IDs for nodes, adjacenc sds for links. So 157 00:07:43.360 --> 00:07:47.160 summing it up, what are the big advantages of SRMPLS 158 00:07:47.199 --> 00:07:48.040 why make the switch? 159 00:07:48.160 --> 00:07:51.199 Well? Number one is that simplified label distribution we touched on. 160 00:07:51.319 --> 00:07:54.399 You mainly just need your IGP like ISIS or OSPF 161 00:07:54.399 --> 00:07:57.839 and maybe BGP. You potentially get rid of LDP maybe 162 00:07:58.160 --> 00:08:03.040 RSVPT For traffic engineers, hearing fewer protocols means a simpler. 163 00:08:02.680 --> 00:08:04.839 Network, simpler is usually better, Definitely. 164 00:08:05.319 --> 00:08:08.399 Then there's that truly stateless operation in the core routers. 165 00:08:08.519 --> 00:08:12.160 Less state means less memory, faster convergence, better scalability. It's 166 00:08:12.160 --> 00:08:15.720 a big win. Plus, SR has built in support for 167 00:08:15.920 --> 00:08:19.519 SR Traffic Engineering SRTE. It's designed from the ground up 168 00:08:19.560 --> 00:08:23.160 for steering traffic along very specific paths, which is powerful 169 00:08:23.399 --> 00:08:27.000 for optimizing network resources. More control over the path exactly 170 00:08:27.040 --> 00:08:29.519 and maybe one of the most practical benefits. It often 171 00:08:29.560 --> 00:08:33.399 allows for seamless network migration. Because it can reuse the 172 00:08:33.519 --> 00:08:37.399 MPLS data plane, you can often introduce SR gradually on 173 00:08:37.519 --> 00:08:41.519 existing hardware. You don't necessarily need a massive, disruptive rip 174 00:08:41.600 --> 00:08:42.080 and replace. 175 00:08:42.320 --> 00:08:46.360 That's huge for large operators. Okay, sounds great, But are 176 00:08:46.440 --> 00:08:51.039 there any downsides, any disadvantages of srmpls to be aware of? 177 00:08:51.519 --> 00:08:54.559 Yeah, there are trade offs. One is that global segment 178 00:08:54.600 --> 00:08:58.600 allocation those prefix sids. While simpler protocols are nice, assigning 179 00:08:58.679 --> 00:09:02.600 these sids often requires manual configuration and careful planning across 180 00:09:02.639 --> 00:09:04.039 the entire network. 181 00:09:03.679 --> 00:09:07.080 So more upfront design work, potential for human error. 182 00:09:07.240 --> 00:09:09.799 Precisely, if you don't plan your sRGB and your node 183 00:09:09.840 --> 00:09:13.000 indexes carefully, you can get conflicts or issues. It shifts 184 00:09:13.000 --> 00:09:15.879 some complexity from the dynamic protocols to the planning phase. 185 00:09:15.919 --> 00:09:16.559 Okay, what else? 186 00:09:16.679 --> 00:09:20.320 Another potential issue is label stack deplementations on some hardware. 187 00:09:20.559 --> 00:09:22.720 Remember how the source puts the whole path and the 188 00:09:22.720 --> 00:09:26.240 header as a stack of sids or labels. Well, hardware 189 00:09:26.279 --> 00:09:28.200 has limits on how many labels it can read and 190 00:09:28.240 --> 00:09:32.639 process in that stack. CISCOIOSXR, for example, often supports a 191 00:09:32.639 --> 00:09:35.799 maximum of three labels for this kind of feature, only 192 00:09:35.840 --> 00:09:38.759 three for certain operations. Yes, so if you're trying to 193 00:09:38.799 --> 00:09:43.200 define a really complex multi hop traffic engineered path using SRTE, 194 00:09:43.399 --> 00:09:45.559 you might bump up against that hardware limit. You might 195 00:09:45.600 --> 00:09:48.799 have to simplify your path or use other techniques. 196 00:09:49.159 --> 00:09:51.919 So hardware capabilities become a factor and how complex your 197 00:09:51.919 --> 00:09:52.440 paths can be. 198 00:09:52.639 --> 00:09:55.120 They definitely do. It's a constraint you have to design around. 199 00:09:55.279 --> 00:09:59.360 But overall it sounds like SRMPLS is a major step forward. 200 00:09:59.559 --> 00:10:02.360 More can, more efficiency, even if it brings some new 201 00:10:02.399 --> 00:10:06.360 design challenges, it's clearly changing how high performance networks are built. 202 00:10:06.679 --> 00:10:13.000 Three bridging worlds SR LDP into working. Okay, so networks evolve. 203 00:10:13.200 --> 00:10:15.639 You might have parts running the older LDP and newer 204 00:10:15.639 --> 00:10:19.000 sections running srmpls. How do you get them to talk 205 00:10:19.039 --> 00:10:21.320 to each other during that migration period. You can't just 206 00:10:21.559 --> 00:10:23.440 flip a switch for the whole network overnight. 207 00:10:23.679 --> 00:10:28.320 No, definitely not. That's where interworking becomes absolutely critical. The 208 00:10:28.399 --> 00:10:32.200 key concept is LSP stitching, essentially connecting an LDP path 209 00:10:32.279 --> 00:10:34.720 to an SR path, usually on the routers that sit 210 00:10:34.759 --> 00:10:35.960 at the border between the two. 211 00:10:35.919 --> 00:10:38.679 Domains, border routers doing the translation exactly. 212 00:10:39.039 --> 00:10:43.039 Let's take LDP to SR stitching. Imagine traffic starting in 213 00:10:43.080 --> 00:10:46.720 an LDP area, say from router Pe five, and needing 214 00:10:46.759 --> 00:10:48.799 to go to a destination in the SR area like 215 00:10:48.840 --> 00:10:51.639 Pe one. Okay, the border riders let's say P three 216 00:10:51.679 --> 00:10:53.919 and P seven in a sample network. They can handle 217 00:10:53.960 --> 00:10:57.960 this pretty seamlessly. When an LDP labeled packet arrives, they 218 00:10:58.000 --> 00:11:02.360 can automatically swap that LDPE for the correct SRMPLS label 219 00:11:02.480 --> 00:11:04.679 needed to reach PE one automatically. 220 00:11:04.720 --> 00:11:05.879 No extra setup for. 221 00:11:05.840 --> 00:11:09.480 This direction LDP to SR It's often quite straightforward, requiring 222 00:11:09.559 --> 00:11:13.039 minimal extra configuration on those border nodes. It makes migrating 223 00:11:13.080 --> 00:11:15.639 into SR relatively easy for existing traffic flows. 224 00:11:15.720 --> 00:11:17.879 That sounds pretty smooth. What about the other way around, 225 00:11:18.159 --> 00:11:21.080 Traffic starting in the new SRMPLS domain needs to reach 226 00:11:21.080 --> 00:11:24.559 a destination still in the old LDP world. SR to 227 00:11:24.679 --> 00:11:26.480 LDP is that automatic? Two? 228 00:11:26.759 --> 00:11:30.759 Ah? That direction SR to LDP stitching is a bit trickier. 229 00:11:31.039 --> 00:11:34.399 It needs an extra helper component, the Segment Routing Mapping 230 00:11:34.480 --> 00:11:35.200 Server or. 231 00:11:35.320 --> 00:11:37.559 SRS SRMs mapping server. What does that do? 232 00:11:37.720 --> 00:11:40.440 Okay, imagine a router, maybe P six in our example, 233 00:11:40.480 --> 00:11:43.320 acting as the SRMs. Its main job is to basically 234 00:11:43.360 --> 00:11:45.639 pretend to be the SR representative for the routers that 235 00:11:45.679 --> 00:11:49.960 aren't running SR yet. It allocates and advertises node sids 236 00:11:50.000 --> 00:11:51.759 for non SR routers, so. 237 00:11:51.759 --> 00:11:54.399 It creates SR identities for the LDP only routers. 238 00:11:54.519 --> 00:11:57.360 Essentially, yes, it tells the SR capable routers, Hey, if 239 00:11:57.360 --> 00:11:59.960 you want to reach this old LDP router PE five, 240 00:12:00.000 --> 00:12:02.639 I've used this sid that I'm advertising for it. It 241 00:12:02.679 --> 00:12:05.080 maps the LDP world into the SR world's view. 242 00:12:05.120 --> 00:12:06.279 How does it share that information? 243 00:12:06.600 --> 00:12:10.399 It typically advertises these mappings using the IGP like isis 244 00:12:10.799 --> 00:12:14.759 there's a specific message type, a TLV typelink value TLV 245 00:12:14.799 --> 00:12:18.039 one forty nine that's specifically designed for these SRMs advertisements. 246 00:12:18.039 --> 00:12:19.200 TLV one forty nine. 247 00:12:19.240 --> 00:12:21.919 Okay, So the SRMs allows the SR routers to build 248 00:12:21.919 --> 00:12:24.159 what looks like an end to end SR path, even 249 00:12:24.159 --> 00:12:27.159 if the final destination is actually LDP only. It fills 250 00:12:27.159 --> 00:12:28.240 that control plane. 251 00:12:28.000 --> 00:12:31.200 Gap and I saw the sources even detail a whole 252 00:12:31.240 --> 00:12:34.080 migration strategy. You start by enabling sr set up the 253 00:12:34.159 --> 00:12:38.240 SRMs migrate services, and then eventually when everything is SR. 254 00:12:38.200 --> 00:12:41.720 Eight ofve well, you can decommission the SRMs exactly once 255 00:12:41.759 --> 00:12:44.200 all the routers understand SR directly, you don't need the 256 00:12:44.200 --> 00:12:46.559 mapping server anymore, so you can turn off those advertisements. 257 00:12:46.639 --> 00:12:49.919 It provides a clear step by step path that really shows. 258 00:12:49.600 --> 00:12:53.559 A practical way to evolve these massive complex networks. You 259 00:12:53.600 --> 00:12:57.159 integrate the new tech without a big bang cutover keeping 260 00:12:57.159 --> 00:13:01.600 things running while you upgrade. That's crucial unbreakable networks Fast 261 00:13:01.639 --> 00:13:06.480 reroute FRR with TILFA. So we've talked about MPLS, we've 262 00:13:06.480 --> 00:13:10.559 talked about the evolution tosrmpls, the interworking, but let's bring 263 00:13:10.559 --> 00:13:13.200 it back to the user experience. What's the real payoff 264 00:13:14.320 --> 00:13:16.919 for you using the network? It's resilience, right, making sure 265 00:13:17.000 --> 00:13:18.279 things stay connected. 266 00:13:17.960 --> 00:13:20.240 Absolutely uninterrupted service is the goal. 267 00:13:20.080 --> 00:13:23.000 Because when something breaks, a fiber cut, a route or failing, 268 00:13:23.080 --> 00:13:26.240 there's always that moment, that convergence delay while the network 269 00:13:26.240 --> 00:13:28.639 figures out a new route. Even if it's just milliseconds, 270 00:13:28.799 --> 00:13:31.039 that can be enough to drop your call, freeze. 271 00:13:30.720 --> 00:13:34.879 Your video exactly. Those microblips matter, and that's why fast 272 00:13:34.919 --> 00:13:38.720 reroute or FRR mechanisms are so incredibly important. 273 00:13:38.759 --> 00:13:43.720 And the sources really highlighted one specific FRR technology TILFA. 274 00:13:44.120 --> 00:13:49.639 Yes, Topology independent loop pre alternate TILFA. It's a really 275 00:13:49.720 --> 00:13:54.519 powerful advancement in FRR within the SRNPLS world. What makes 276 00:13:54.559 --> 00:13:57.879 it topology independent It means it doesn't rely on specific 277 00:13:58.039 --> 00:14:01.720 network shapes or configurations towards and its big promise is 278 00:14:01.879 --> 00:14:05.080 ensuring one hundred percent backup path coverage whenever a loop 279 00:14:05.120 --> 00:14:08.480 free path exists after the failure. If there's physically a 280 00:14:08.480 --> 00:14:10.960 way to route around the problem without causing a loop, 281 00:14:11.240 --> 00:14:13.879 TILFA aims to find it and use it fast. 282 00:14:13.919 --> 00:14:16.159 Okay, one hundred percent coverage sounds ambitious. How does it 283 00:14:16.200 --> 00:14:16.799 actually work. 284 00:14:16.919 --> 00:14:19.480 It's quite clever. It works per prefix, meaning for each 285 00:14:19.519 --> 00:14:24.200 destination network. It proactively calculates backup paths before any failure happens. 286 00:14:24.279 --> 00:14:26.240 Pre calculates so it's ready to go instantly. 287 00:14:26.240 --> 00:14:28.840 Well instantly, when a failure is detected locally, the router 288 00:14:29.000 --> 00:14:31.879 the point of local repair or PLR, already knows the 289 00:14:31.879 --> 00:14:34.399 backup path. It encodes this path as a stack of 290 00:14:34.480 --> 00:14:38.039 labels just like SRTE, and immediately reroutes the traffic onto 291 00:14:38.039 --> 00:14:38.759 that backup path. 292 00:14:38.960 --> 00:14:41.840 How does it find that backup path so reliably? 293 00:14:42.159 --> 00:14:45.759 It uses concepts like p space and q space. Basically, 294 00:14:45.879 --> 00:14:48.639 p space is all the routers reachable from the PLR 295 00:14:48.759 --> 00:14:51.960 without going through the failed link or node. Q space 296 00:14:52.080 --> 00:14:54.159 is all the routers that can reach the final destination 297 00:14:54.240 --> 00:14:57.440 without going through the failed link or node. Okay, TILFA 298 00:14:57.639 --> 00:15:00.399 looks for a router a release node that's an both 299 00:15:00.440 --> 00:15:03.960 p space and Q space. That node represents a safe 300 00:15:04.039 --> 00:15:06.559 point to route through that dipasses the failure and is 301 00:15:06.600 --> 00:15:09.639 guaranteed not to loop back towards it. It finds that 302 00:15:09.799 --> 00:15:11.039 intersection point. 303 00:15:10.919 --> 00:15:13.960 Like finding a safe detour exit on a highway closure map. 304 00:15:14.039 --> 00:15:17.519 That's a great analogy. It precalculates these safety tours. 305 00:15:17.559 --> 00:15:21.080 So tilfa is the tech making failures almost invisible, keeping 306 00:15:21.120 --> 00:15:24.559 your connection solid. That silent hero again, it really is. 307 00:15:24.919 --> 00:15:27.240 We can look at a few scenarios. Maybe using router 308 00:15:27.320 --> 00:15:30.840 P two is the PLR protecting traffic going to PE five. 309 00:15:30.919 --> 00:15:31.960 Okay, let's see it in action. 310 00:15:32.159 --> 00:15:36.879 Simples case zero segment FRR. Imagine the main link from 311 00:15:36.919 --> 00:15:39.360 P two to P three fails. If P two has 312 00:15:39.399 --> 00:15:42.279 another direct path, say through P seven, that's already loop 313 00:15:42.360 --> 00:15:45.039 free towards PE five according to the post failure view, 314 00:15:45.120 --> 00:15:48.120 then it just uses that path exactly. The backup path 315 00:15:48.200 --> 00:15:51.080 needs no extra labels, no extra sids in the stack, 316 00:15:51.240 --> 00:15:54.200 just the original destination label for PE five. P two 317 00:15:54.360 --> 00:15:57.440 just switches the traffic over immediately, very fast, very simple. 318 00:15:57.679 --> 00:16:00.320 But what if there isn't such a simple direct alternate? Right? 319 00:16:00.440 --> 00:16:03.440 Sometimes the dtours more complex. That's where you get single 320 00:16:03.480 --> 00:16:06.080 segment FRR, or even double segment FRR. 321 00:16:06.200 --> 00:16:08.679 You need extra instructions extra sids. 322 00:16:08.840 --> 00:16:12.120 Precisely if the P two P three link fails and 323 00:16:12.159 --> 00:16:15.080 maybe the direct P two P seven path isn't viable 324 00:16:15.200 --> 00:16:18.759 for some reason post failure, TILFA might calculate that P 325 00:16:18.879 --> 00:16:22.000 two needs to send traffic first to say router P six. 326 00:16:22.240 --> 00:16:25.519 It would push P six's NOE SID onto the label stack. 327 00:16:25.600 --> 00:16:28.000 That's a single segment go via P six, or in 328 00:16:28.039 --> 00:16:30.480 an even trickier situation, maybe it needs to go via 329 00:16:30.519 --> 00:16:32.759 P eight and then specifically tell P eight to use 330 00:16:32.759 --> 00:16:35.240 its direct link to P four. That might require pushing 331 00:16:35.279 --> 00:16:37.720 P eight's nod SID and the adjacency SID for the 332 00:16:37.720 --> 00:16:39.440 PAP four link onto the stack. 333 00:16:39.559 --> 00:16:41.279 Two extra labels yep, that's. 334 00:16:41.159 --> 00:16:44.759 Double segment FRR. And remember that hardware limit we mentioned 335 00:16:44.799 --> 00:16:49.840 like maybe three labels total on CISCOIOSXR. This double segment 336 00:16:49.919 --> 00:16:53.360 repair original label plus two extra sads pushes right up 337 00:16:53.360 --> 00:16:56.159 against that limit. It shows how these mechanisms interact with 338 00:16:56.320 --> 00:16:58.120 real world hardware constraints. 339 00:16:58.679 --> 00:17:02.759 Okay, so TILFA handles the reroute, but you mentioned convergence 340 00:17:02.799 --> 00:17:05.559 delay earlier. Even if the backup path is found fast, 341 00:17:05.920 --> 00:17:08.519 isn't there still a risk of temporary loops while other 342 00:17:08.599 --> 00:17:11.240 routers are still updating their paths those micro loops. 343 00:17:11.319 --> 00:17:15.400 Yeah, yes, micro loop avoidance. That's another critical piece in srmpls, 344 00:17:15.680 --> 00:17:20.119 often working alongside TILFA. You're right. During convergence, some routers 345 00:17:20.160 --> 00:17:22.759 update faster than others. For a short time, Router A 346 00:17:22.880 --> 00:17:25.200 might think the path is X, while Router B still 347 00:17:25.200 --> 00:17:27.359 thinks it's Y, and traffic can bounce back and forth 348 00:17:27.400 --> 00:17:28.240 a micro loop. 349 00:17:28.119 --> 00:17:29.599 Creating a temporary black hole. 350 00:17:30.000 --> 00:17:32.279 Not good, not good at all. To prevent this, the 351 00:17:33.000 --> 00:17:35.519 or router P two again can use an explicit path. 352 00:17:35.880 --> 00:17:38.400 When it detects the failure and starts the convergence process, 353 00:17:38.440 --> 00:17:41.359 it can temporarily force traffic onto a very specific, pre 354 00:17:41.480 --> 00:17:45.599 calculated loop free path using sid's say P two forces 355 00:17:45.599 --> 00:17:48.519 traffic via P eight then P four to reach PE. 356 00:17:48.359 --> 00:17:51.799 Five, a guaranteed safe tunnel during the transition exactly. 357 00:17:52.160 --> 00:17:55.519 It uses this explicit tunnel for a short configurable time, 358 00:17:55.559 --> 00:17:59.920 maybe sixty seconds, called the rebuy update delay. This gives 359 00:18:00.119 --> 00:18:02.599 the rest of the network time to fully converge on 360 00:18:02.640 --> 00:18:06.400 the new topology before P two stops using the explicit path. 361 00:18:06.640 --> 00:18:09.960 It prevents traffic from ever hitting those transient microloops. 362 00:18:10.039 --> 00:18:13.640 Very clever. Okay, we've covered link failures microlops. What if 363 00:18:13.640 --> 00:18:15.880 an entire router fails, not just a connection, but the 364 00:18:15.880 --> 00:18:16.480 whole node. 365 00:18:16.559 --> 00:18:21.519 That's TILFA node protection. It's designed for exactly that. If 366 00:18:21.519 --> 00:18:24.039 the primary path goes through node P three P three 367 00:18:24.119 --> 00:18:28.359 itself fails, TILFA calculates a backup path that completely avoids 368 00:18:28.359 --> 00:18:29.000 P three. 369 00:18:28.839 --> 00:18:31.160 So it routes around the entire dead router correct. 370 00:18:31.720 --> 00:18:34.359 For example, P two might re wrap traffic to PE 371 00:18:34.440 --> 00:18:37.319 five via P seven and then P four, making sure 372 00:18:37.359 --> 00:18:39.480 it never tries to go near the failed P three. 373 00:18:39.880 --> 00:18:43.000 This often needs a bit more capability, sometimes requiring MPLS 374 00:18:43.039 --> 00:18:46.640 Traffic Engineering MPLSTE features to be enabled to find those 375 00:18:46.680 --> 00:18:47.640 node avoiding paths. 376 00:18:47.920 --> 00:18:51.079 Makes sense. Now, what about physical risks. Multiple links might 377 00:18:51.160 --> 00:18:54.079 run through the same conduit, same fiber bundle, one back 378 00:18:54.119 --> 00:18:56.119 home takes out several connections. 379 00:18:55.920 --> 00:18:59.480 Ugh, the dreaded back home fade. That's where shared risk 380 00:18:59.519 --> 00:19:03.000 link groups or SRLG protection comes in. It's about protecting 381 00:19:03.000 --> 00:19:06.319 against failures where multiple links are likely to fail together 382 00:19:06.319 --> 00:19:08.440 because they share underlying physical risk. 383 00:19:08.759 --> 00:19:09.839 Okay, how does that work? 384 00:19:10.200 --> 00:19:13.240 There are a couple of flavors. Local SRLG is where 385 00:19:13.279 --> 00:19:17.359 the router P two, for instance, is explicitly configured to know, hey, 386 00:19:17.440 --> 00:19:19.039 my link to P three and my link to P 387 00:19:19.119 --> 00:19:22.200 seven are in the same SRG. They share risk. If 388 00:19:22.240 --> 00:19:25.720 one fails, TILFA assumes the other might fail two or 389 00:19:25.799 --> 00:19:29.599 already has, and calculates a backup path that avoids all 390 00:19:29.640 --> 00:19:30.839 links in that group, so. 391 00:19:30.759 --> 00:19:33.200 It avoids the whole shared risk zone exactly. 392 00:19:33.359 --> 00:19:36.519 Then there's global weighted SRLG. This is more complex where 393 00:19:36.680 --> 00:19:40.400 SRLG information is shared across the network, maybe using ISIS 394 00:19:40.440 --> 00:19:43.519 again with a specific TLV like TLV two thirty eight. 395 00:19:43.799 --> 00:19:46.640 This lets routers make decisions based on srlg's they aren't 396 00:19:46.640 --> 00:19:47.960 directly connected to, so. 397 00:19:47.880 --> 00:19:49.960 The whole network knows about these shared risks. 398 00:19:50.079 --> 00:19:53.799 Potentially Yes, And here's an interesting detail. If protecting against 399 00:19:53.799 --> 00:19:56.720 an SRLG requires a backup path with say four or 400 00:19:56.720 --> 00:20:00.119 five labels exceeding that hardware stack limit, the system can 401 00:20:00.200 --> 00:20:03.400