Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
You know, it's easy to take for granted that instant connection,
that crystal clear video call, or that lightning fast download.
Speaker 2 (00:08):
It really is.
Speaker 1 (00:09):
But behind that seamless digital experience, there's a constant, silent
battle being fought against complexity, against failure, making sure your
data gets where it needs to go, fast and well
without a hitch.
Speaker 2 (00:22):
Yeah, a lot goes on under the hood.
Speaker 1 (00:24):
Today we're taking a bit of a shortcut. We want
you to be well informed about a fascinating yet often
unseen aspect of modern networking.
Speaker 2 (00:33):
A really crucial one.
Speaker 1 (00:34):
We're embarking on a deep dive into segment reading in
MPLS networks. Now, this is key to understanding how high
performance networks are evolving. We're talking faster, more flexible, and incredibly.
Speaker 2 (00:46):
Resilient, and we're here to guide you through some of
the technical stuff. We'll pull out the most important bits,
the surprising facts, basically help you grasp what's truly important
in this pretty complex field.
Speaker 1 (00:56):
Our mission is clear, let's demystify this journey from say
traditional network setups to the cutting edge solutions that keep
your online experience seamless even when things go wrong. Laying
the groundwork the world of MPLS. Okay, let's unpack this.
Where do we start? I guess with the foundation right,
(01:18):
Multi Protocol label switching MPLS exactly.
Speaker 2 (01:21):
MPLS has been a workhourse for a long time.
Speaker 1 (01:23):
People sometimes call it layer two point five, which is
kind of a neat way to think about it, like
a clever shortcut.
Speaker 2 (01:28):
It is. Instead of traditional IP routing, where every single
router has to look up the full destination IP address,
which takes time, MPLS uses these short, fixed length things
called labels, labels, right, little tags pretty much. And what's
fascinating is how these labels just simplify the whole forwarding decision.
Think of it like a digital sticky note on each packet,
all right. That note tells the router exactly where to
(01:50):
send it next, often without needing to look deep into
the IP header. Again, saves a lot of processing.
Speaker 1 (01:55):
So how does that work in practice? Are there specific actions?
Speaker 2 (01:58):
Yeah? There are three core label switching operations. First, you've
got push. When a packet first enters the NPLS zone,
the first router, the ingress router, it pushes a label
onto it attaches that first sticky note.
Speaker 1 (02:11):
Got it.
Speaker 2 (02:11):
Then, as it travels to the middle the intermediate routers,
they do a swap. They replace the incoming label with
a new outgoing label.
Speaker 1 (02:19):
Why swap it? Whant to keep the same one?
Speaker 2 (02:21):
Ah? Because labels usually only have meaning locally between two
adjacent routers, like changing local road names as you travel
towards a destination city, So you swap the label for
the next hops. Understanding makes sense. And finally, when the
packet gets near the end or leaves the MPLS part
of the network, the label gets popped.
Speaker 1 (02:40):
Removed, so you rise clean at the destination.
Speaker 2 (02:43):
Usually there's an optimization called penultimate hop popping.
Speaker 1 (02:46):
PHP penultimate meaning second.
Speaker 2 (02:49):
To last, Exactly the router right before the final destination
pops the label. This saves the very last router a
bit of work. Let's it focus just on the final delivery.
Speaker 1 (02:58):
Clever. Okay, So labels get pushed, swapped, popped. But how
do the routers agree on what label means? What? How
are these labels these instructions actually distributed?
Speaker 2 (03:10):
Good question. That's where protocols like LP come in. Label
Distribution Protocol LVP YEP. LDP's one of the main ways
routers talk to each other to set up these label
paths what we call label switch paths or LSPs. It
builds those express lanes.
Speaker 1 (03:24):
And LDP doesn't work in a vacuum, right, It needs
to know the network layout.
Speaker 2 (03:27):
First, precisely underneath LP you almost always have an interior
Gateway protocol and IGP something like isis is common?
Speaker 1 (03:35):
Isis okay?
Speaker 2 (03:36):
Think of the IGP as the map maker. It figures
out the entire network topology, all the routers, all the links.
It builds this big map called the Link State Database
or LSDB, the master map, right, and from that map,
each router creates its own route book, the Routing Information
Base IRI. But for super fast lookups, it compiles a
cheat sheet, the Forwarding Information Base the FIB.
Speaker 1 (03:56):
FIB for forwarding.
Speaker 2 (03:57):
You got it. LDP then uses that f that optimized
map to assign its labels and build those fast LSPs.
Speaker 1 (04:04):
So, bringing it back to the listener, why does this
NPLS stuff, even though it's been around, still matter to
you today?
Speaker 2 (04:11):
Because it's still the backbone for so many high speed networks.
It's often the unsung hero behind your fast internet. You're
streaming your work VPN. It's that foundational layer that makes
so much of the modern digital world possible and frankly efficient. Two.
The next evolution segment routing SR mpls.
Speaker 1 (04:31):
All right, MPLS gives us efficient paths, but the tech
world never stands still. Where does segment routing SR fit
into this picture? How does it take things to the
next level?
Speaker 2 (04:41):
SR or segment routing Sometimes you'll hear it called spring
source Packet routing and networking is a really big evolution,
a fundamental shift. Actually. The core idea the source, no,
the very first router that sees the packet decides the
entire path through the network, not just the next topic
in traditional routing or even basic LDP.
Speaker 1 (04:58):
The whole path from the start.
Speaker 2 (05:00):
The whole path. It does this using an ordered list
of segments. Think of segments as instructions like go here,
then go there. These are identified by a segment identifiers
or sids.
Speaker 1 (05:09):
Sids okay, and these sids they get encoded right into
the packet header itself.
Speaker 2 (05:14):
As a packet carries its own map.
Speaker 1 (05:16):
In a way. Yes, A huge advantage of this is
that it effectively reduces the network's statefulness.
Speaker 2 (05:22):
Okay, reduces statefulness. That sounds good, but what does it
mean for the network Practically? Speaking, fewer headaches for the engineers.
Speaker 1 (05:29):
Definitely fewer headaches. Think about it. If the source dictates
the path, the routers in the middle don't need to
keep track of complex path information for every single flow.
They just need to know how to read the next instruction,
the next SID in the packet header and forward it along. Ah.
Speaker 2 (05:46):
So they become simpler, much simpler.
Speaker 1 (05:48):
Less state means less memory usage, faster processing, faster convergence
when things change. It enhances scalability and resilience quite a bit.
It makes the network leaner, more agile.
Speaker 2 (05:59):
Soll how does sr actually work with MPLS. Is it
a replacement or does it build on top?
Speaker 1 (06:04):
That's the clever part. SRMPLS uses the existing MPLS data plane,
the actual packet forwarding, the pushing, swapping, popping labels. That
machinery stays largely the same. Oh interesting, So the hardware
doesn't necessarily need a complete overhaul.
Speaker 2 (06:18):
Often. No, the big difference is in the control plane.
How labels are assigned and distributed in SRMPLS. Those sids
we talked about, they're encoded as MPLS labels. Ah.
Speaker 1 (06:28):
Okay, so sids become labels are they're different kinds of sids.
Speaker 2 (06:31):
Yes, primarily two types you need to know. First, Prefix sids,
which are often called node sids. Think of these as
global segments. They uniquely identify a specific router, usually its
main loop back interface address.
Speaker 1 (06:45):
Global, meaning unique across the.
Speaker 2 (06:46):
Whole network within the sr domain. Yes, they're assigned from
a specific block of labels called the Segment Routing Global
Block or sRGB. On Cisco IOSXR, for instance, that default
range is sixteen thousand to two three nine nine nine.
Speaker 1 (06:59):
M okay a reserved range.
Speaker 2 (07:01):
Exactly, and the specific label value is usually the sRGB
based plus an index. So if the SOGB starts at
sixteen thousand and a node has an index or a
node SID of seven, its label is sixteen thousand and seven.
Speaker 1 (07:13):
Got it? What's the other type?
Speaker 2 (07:14):
The other main type is adjacency sids. These are local segments.
They identify as specific link and adjacency between two directly
connected routers, so.
Speaker 1 (07:22):
Not global just for that one connection, right.
Speaker 2 (07:24):
They're often dynamically allocated, say from a different range like
starting from twenty four thousand on IOSXR, and crucially only
the router originating that SID for its link installs it
in its forwarding table. It's LFIB. It's only meaningful locally.
Speaker 1 (07:39):
Okay, prefixes IDs for nodes, adjacenc sds for links. So
summing it up, what are the big advantages of SRMPLS
why make the switch?
Speaker 2 (07:48):
Well? Number one is that simplified label distribution we touched on.
You mainly just need your IGP like ISIS or OSPF
and maybe BGP. You potentially get rid of LDP maybe
RSVPT For traffic engineers, hearing fewer protocols means a simpler.
Speaker 1 (08:02):
Network, simpler is usually better, Definitely.
Speaker 2 (08:05):
Then there's that truly stateless operation in the core routers.
Less state means less memory, faster convergence, better scalability. It's
a big win. Plus, SR has built in support for
SR Traffic Engineering SRTE. It's designed from the ground up
for steering traffic along very specific paths, which is powerful
for optimizing network resources. More control over the path exactly
(08:27):
and maybe one of the most practical benefits. It often
allows for seamless network migration. Because it can reuse the
MPLS data plane, you can often introduce SR gradually on
existing hardware. You don't necessarily need a massive, disruptive rip
and replace.
Speaker 1 (08:42):
That's huge for large operators. Okay, sounds great, But are
there any downsides, any disadvantages of srmpls to be aware of?
Speaker 2 (08:51):
Yeah, there are trade offs. One is that global segment
allocation those prefix sids. While simpler protocols are nice, assigning
these sids often requires manual configuration and careful planning across
the entire network.
Speaker 1 (09:03):
So more upfront design work, potential for human error.
Speaker 2 (09:07):
Precisely, if you don't plan your sRGB and your node
indexes carefully, you can get conflicts or issues. It shifts
some complexity from the dynamic protocols to the planning phase.
Speaker 1 (09:15):
Okay, what else?
Speaker 2 (09:16):
Another potential issue is label stack deplementations on some hardware.
Remember how the source puts the whole path and the
header as a stack of sids or labels. Well, hardware
has limits on how many labels it can read and
process in that stack. CISCOIOSXR, for example, often supports a
maximum of three labels for this kind of feature, only
three for certain operations. Yes, so if you're trying to
(09:38):
define a really complex multi hop traffic engineered path using SRTE,
you might bump up against that hardware limit. You might
have to simplify your path or use other techniques.
Speaker 1 (09:49):
So hardware capabilities become a factor and how complex your
paths can be.
Speaker 2 (09:52):
They definitely do. It's a constraint you have to design around.
Speaker 1 (09:55):
But overall it sounds like SRMPLS is a major step forward.
More can, more efficiency, even if it brings some new
design challenges, it's clearly changing how high performance networks are built.
Three bridging worlds SR LDP into working. Okay, so networks evolve.
You might have parts running the older LDP and newer
(10:15):
sections running srmpls. How do you get them to talk
to each other during that migration period. You can't just
flip a switch for the whole network overnight.
Speaker 2 (10:23):
No, definitely not. That's where interworking becomes absolutely critical. The
key concept is LSP stitching, essentially connecting an LDP path
to an SR path, usually on the routers that sit
at the border between the two.
Speaker 1 (10:35):
Domains, border routers doing the translation exactly.
Speaker 2 (10:39):
Let's take LDP to SR stitching. Imagine traffic starting in
an LDP area, say from router Pe five, and needing
to go to a destination in the SR area like
Pe one. Okay, the border riders let's say P three
and P seven in a sample network. They can handle
this pretty seamlessly. When an LDP labeled packet arrives, they
can automatically swap that LDPE for the correct SRMPLS label
(11:02):
needed to reach PE one automatically.
Speaker 1 (11:04):
No extra setup for.
Speaker 2 (11:05):
This direction LDP to SR It's often quite straightforward, requiring
minimal extra configuration on those border nodes. It makes migrating
into SR relatively easy for existing traffic flows.
Speaker 1 (11:15):
That sounds pretty smooth. What about the other way around,
Traffic starting in the new SRMPLS domain needs to reach
a destination still in the old LDP world. SR to
LDP is that automatic? Two?
Speaker 2 (11:26):
Ah? That direction SR to LDP stitching is a bit trickier.
It needs an extra helper component, the Segment Routing Mapping
Server or.
Speaker 1 (11:35):
SRS SRMs mapping server. What does that do?
Speaker 2 (11:37):
Okay, imagine a router, maybe P six in our example,
acting as the SRMs. Its main job is to basically
pretend to be the SR representative for the routers that
aren't running SR yet. It allocates and advertises node sids
for non SR routers, so.
Speaker 1 (11:51):
It creates SR identities for the LDP only routers.
Speaker 2 (11:54):
Essentially, yes, it tells the SR capable routers, Hey, if
you want to reach this old LDP router PE five,
I've used this sid that I'm advertising for it. It
maps the LDP world into the SR world's view.
Speaker 1 (12:05):
How does it share that information?
Speaker 2 (12:06):
It typically advertises these mappings using the IGP like isis
there's a specific message type, a TLV typelink value TLV
one forty nine that's specifically designed for these SRMs advertisements.
Speaker 1 (12:18):
TLV one forty nine.
Speaker 2 (12:19):
Okay, So the SRMs allows the SR routers to build
what looks like an end to end SR path, even
if the final destination is actually LDP only. It fills
that control plane.
Speaker 1 (12:28):
Gap and I saw the sources even detail a whole
migration strategy. You start by enabling sr set up the
SRMs migrate services, and then eventually when everything is SR.
Speaker 2 (12:38):
Eight ofve well, you can decommission the SRMs exactly once
all the routers understand SR directly, you don't need the
mapping server anymore, so you can turn off those advertisements.
It provides a clear step by step path that really shows.
Speaker 1 (12:49):
A practical way to evolve these massive complex networks. You
integrate the new tech without a big bang cutover keeping
things running while you upgrade. That's crucial unbreakable networks Fast
reroute FRR with TILFA. So we've talked about MPLS, we've
talked about the evolution tosrmpls, the interworking, but let's bring
(13:10):
it back to the user experience. What's the real payoff
for you using the network? It's resilience, right, making sure
things stay connected.
Speaker 2 (13:17):
Absolutely uninterrupted service is the goal.
Speaker 1 (13:20):
Because when something breaks, a fiber cut, a route or failing,
there's always that moment, that convergence delay while the network
figures out a new route. Even if it's just milliseconds,
that can be enough to drop your call, freeze.
Speaker 2 (13:30):
Your video exactly. Those microblips matter, and that's why fast
reroute or FRR mechanisms are so incredibly important.
Speaker 1 (13:38):
And the sources really highlighted one specific FRR technology TILFA.
Speaker 2 (13:44):
Yes, Topology independent loop pre alternate TILFA. It's a really
powerful advancement in FRR within the SRNPLS world. What makes
it topology independent It means it doesn't rely on specific
network shapes or configurations towards and its big promise is
ensuring one hundred percent backup path coverage whenever a loop
(14:05):
free path exists after the failure. If there's physically a
way to route around the problem without causing a loop,
TILFA aims to find it and use it fast.
Speaker 1 (14:13):
Okay, one hundred percent coverage sounds ambitious. How does it
actually work.
Speaker 2 (14:16):
It's quite clever. It works per prefix, meaning for each
destination network. It proactively calculates backup paths before any failure happens.
Speaker 1 (14:24):
Pre calculates so it's ready to go instantly.
Speaker 2 (14:26):
Well instantly, when a failure is detected locally, the router
the point of local repair or PLR, already knows the
backup path. It encodes this path as a stack of
labels just like SRTE, and immediately reroutes the traffic onto
that backup path.
Speaker 1 (14:38):
How does it find that backup path so reliably?
Speaker 2 (14:42):
It uses concepts like p space and q space. Basically,
p space is all the routers reachable from the PLR
without going through the failed link or node. Q space
is all the routers that can reach the final destination
without going through the failed link or node. Okay, TILFA
looks for a router a release node that's an both
p space and Q space. That node represents a safe
(15:04):
point to route through that dipasses the failure and is
guaranteed not to loop back towards it. It finds that
intersection point.
Speaker 1 (15:10):
Like finding a safe detour exit on a highway closure map.
Speaker 2 (15:14):
That's a great analogy. It precalculates these safety tours.
Speaker 1 (15:17):
So tilfa is the tech making failures almost invisible, keeping
your connection solid. That silent hero again, it really is.
Speaker 2 (15:24):
We can look at a few scenarios. Maybe using router
P two is the PLR protecting traffic going to PE five.
Speaker 1 (15:30):
Okay, let's see it in action.
Speaker 2 (15:32):
Simples case zero segment FRR. Imagine the main link from
P two to P three fails. If P two has
another direct path, say through P seven, that's already loop
free towards PE five according to the post failure view,
then it just uses that path exactly. The backup path
needs no extra labels, no extra sids in the stack,
just the original destination label for PE five. P two
(15:54):
just switches the traffic over immediately, very fast, very simple.
Speaker 1 (15:57):
But what if there isn't such a simple direct alternate? Right?
Speaker 2 (16:00):
Sometimes the dtours more complex. That's where you get single
segment FRR, or even double segment FRR.
Speaker 1 (16:06):
You need extra instructions extra sids.
Speaker 2 (16:08):
Precisely if the P two P three link fails and
maybe the direct P two P seven path isn't viable
for some reason post failure, TILFA might calculate that P
two needs to send traffic first to say router P six.
It would push P six's NOE SID onto the label stack.
That's a single segment go via P six, or in
an even trickier situation, maybe it needs to go via
(16:30):
P eight and then specifically tell P eight to use
its direct link to P four. That might require pushing
P eight's nod SID and the adjacency SID for the
PAP four link onto the stack.
Speaker 1 (16:39):
Two extra labels yep, that's.
Speaker 2 (16:41):
Double segment FRR. And remember that hardware limit we mentioned
like maybe three labels total on CISCOIOSXR. This double segment
repair original label plus two extra sads pushes right up
against that limit. It shows how these mechanisms interact with
real world hardware constraints.
Speaker 1 (16:58):
Okay, so TILFA handles the reroute, but you mentioned convergence
delay earlier. Even if the backup path is found fast,
isn't there still a risk of temporary loops while other
routers are still updating their paths those micro loops.
Speaker 2 (17:11):
Yeah, yes, micro loop avoidance. That's another critical piece in srmpls,
often working alongside TILFA. You're right. During convergence, some routers
update faster than others. For a short time, Router A
might think the path is X, while Router B still
thinks it's Y, and traffic can bounce back and forth
a micro loop.
Speaker 1 (17:28):
Creating a temporary black hole.
Speaker 2 (17:30):
Not good, not good at all. To prevent this, the
or router P two again can use an explicit path.
When it detects the failure and starts the convergence process,
it can temporarily force traffic onto a very specific, pre
calculated loop free path using sid's say P two forces
traffic via P eight then P four to reach PE.
Speaker 1 (17:48):
Five, a guaranteed safe tunnel during the transition exactly.
Speaker 2 (17:52):
It uses this explicit tunnel for a short configurable time,
maybe sixty seconds, called the rebuy update delay. This gives
the rest of the network time to fully converge on
the new topology before P two stops using the explicit path.
It prevents traffic from ever hitting those transient microloops.
Speaker 1 (18:10):
Very clever. Okay, we've covered link failures microlops. What if
an entire router fails, not just a connection, but the
whole node.
Speaker 2 (18:16):
That's TILFA node protection. It's designed for exactly that. If
the primary path goes through node P three P three
itself fails, TILFA calculates a backup path that completely avoids
P three.
Speaker 1 (18:28):
So it routes around the entire dead router correct.
Speaker 2 (18:31):
For example, P two might re wrap traffic to PE
five via P seven and then P four, making sure
it never tries to go near the failed P three.
This often needs a bit more capability, sometimes requiring MPLS
Traffic Engineering MPLSTE features to be enabled to find those
node avoiding paths.
Speaker 1 (18:47):
Makes sense. Now, what about physical risks. Multiple links might
run through the same conduit, same fiber bundle, one back
home takes out several connections.
Speaker 2 (18:55):
Ugh, the dreaded back home fade. That's where shared risk
link groups or SRLG protection comes in. It's about protecting
against failures where multiple links are likely to fail together
because they share underlying physical risk.
Speaker 1 (19:08):
Okay, how does that work?
Speaker 2 (19:10):
There are a couple of flavors. Local SRLG is where
the router P two, for instance, is explicitly configured to know, hey,
my link to P three and my link to P
seven are in the same SRG. They share risk. If
one fails, TILFA assumes the other might fail two or
already has, and calculates a backup path that avoids all
links in that group, so.
Speaker 1 (19:30):
It avoids the whole shared risk zone exactly.
Speaker 2 (19:33):
Then there's global weighted SRLG. This is more complex where
SRLG information is shared across the network, maybe using ISIS
again with a specific TLV like TLV two thirty eight.
This lets routers make decisions based on srlg's they aren't
directly connected to, so.
Speaker 1 (19:47):
The whole network knows about these shared risks.
Speaker 2 (19:50):
Potentially Yes, And here's an interesting detail. If protecting against
an SRLG requires a backup path with say four or
five labels exceeding that hardware stack limit, the system can
automatically signal what's called an auto tunnel. It's like creating
a dynamic temporary LSP tunnel just to encapsulate that complex path,
effectively hiding the extra labels from the hardware that can't
(20:11):
handle them directly. It's a workaround to maintain protection even
with hardware limits.
Speaker 1 (20:16):
Auto tunnels another clever trick. Can you combine these protections
like node and shared risk?
Speaker 2 (20:22):
Absolutely, you can enable TILFA node plus SROLG protection. The
goal then is to find a backup path that avoids
both the failed node and any link sharing risk with
the primary path. Again, if the required label stack gets
too deep, an auto tunnel might be signaled to make
it work.
Speaker 1 (20:39):
Wow. Okay, so you have link protection, node protection, SROLD protection,
micro loop avoidance. With all these options, how does the
router choose which backup path to actually use? If maybe
multiple valid ones exist after a failure?
Speaker 2 (20:52):
Great question that leads to TILFA tyebreaker scenarios. It's common
that after a failure, TILFAA might find several potential free
alternate paths. Maybe one just protects the link, another protects
the node, a third protects the SRLG. Which one wins
the network operator decides. You can contigurer preferences. You might
say I prefer node protection over link protection or SRLG
(21:14):
protection is the most important. Prioritize that the router then
follows these configured tiebreaker policies to select the best available
backup path. According to your priorities. Adding new routers or
links can create these choices. So having explicit tiebreakers is
crucial for predictable fail over behavior.
Speaker 1 (21:30):
So incredible levels of control and customization for resilience exactly.
Speaker 2 (21:34):
It allows engineers to tailor the network's reaction to failures
very precisely.
Speaker 1 (21:39):
These mechanisms TILFA, micro loop avoidance, SRLG protection, the tie breakers.
They really are the quiet heroes, aren't They constantly calculating
ready to reroute traffic in milliseconds to keep your connection,
your data flowing smoothly. It's amazing engineering outro Well, we've
covered a lot of ground today, from the basics of
MPLS labels, push swap pop all the way through segment
(22:01):
routing ASRMs and into this incredibly sophisticated world of TILFA
fast reroute. It's quite a journey, it.
Speaker 2 (22:07):
Really is, and hopefully understanding these concepts helps you appreciate
the sheer amount of engineering that goes into making the
Internet feel so seamless and reliable. It's about designing networks
to be self healing, to provide that uninterrupted service. It's
knowledge applied in a really powerful way.
Speaker 1 (22:25):
This deep dive definitely shows how the folks designing and
running these networks are constantly pushing boundaries, making our digital
world not just faster, but fundamentally more resilient.
Speaker 2 (22:33):
More intelligent, always innovating.
Speaker 1 (22:36):
So here's a final thought to leave you with. As
networks get smarter, more autonomous, using techniques like SRMPLS and
TILFA to self optimize and self heal, what new kinds
of services and applications become possible? Things that demand truly continuous,
absolutely always on connectivity.
Speaker 2 (22:55):
M Yeah, things we maybe haven't even imagined yet.
Speaker 1 (22:58):
How might this shape the future sure of everything from
remote surgery to autonomous transport to immersive entertainment? Something to
think about. Maybe consider how these ideas of proactive resilience
could even apply in your own work or life