Join us as we gather around the hedge,
where we dig into technology,
business, and culture with the finest minds in
computer networking.
Good morning, Tom.
Good morning, Russ. First of two today.
Mhmm. We know we're gonna be a good
day. Two. It's gonna be a long day.
Lots of recordings. You have to put up
with me a lot. Yep. So I hesitate
to ask, but what's on the floor in
front of your
this is,
it's a little step ladder thing to make
it so you can put a ladder on
your stairs. We have a tall tall window.
Okay. I see. I see. I thought it
was like, you know, something to do with
your rockets or something.
Nah. Nah. This is an invitation to fall
and have a really, really bad injury.
Yeah. Yeah. Oh, yes. Yes.
Anything around stairs is really painful.
Yep. It just is. It's gonna be great.
Yeah.
We
painted the walls and the stairs, and, you
know, this is one of those stair sets
where
or one of those one of those stairs
where the ceiling is a 10 foot ceiling
on the Second Floor and an eight foot
ceiling on the First Floor. So by the
time you get to the bottom, you're looking
at 18 feet
to get to the ceiling or 20 feet
to get to the ceiling. It's actually more
than that because you have the floor itself
between, which is like a two by 12
or something like that. So it's like
it's it's really tall.
Yeah. Yeah.
It's really hard to paint. I'm just saying.
Yep.
So yeah.
So the plant's doing okay.
Yeah. The plant's thriving. Everything looks okay back
there.
I was,
at
a relative's house, and I found an old
electronics book,
which was really cool,
from way, way back. Like, it was published
in the nineteen forties, and it was really
cool to find that. So maybe I'll read
through it and see if we find anything
interesting to talk about in that someday.
So today, we're talking to Hemant Sharma. Now,
Hemant
Hemant,
you just finished a book on SRMPLS.
What was the publisher? Because I don't remember
if it was That.
Okay.
That's what I thought. I just couldn't remember,
what publisher you had gone with for this.
So today, we were just gonna talk about
SRM PLS, TILFA,
and those types of topics. So maybe,
first of all, I might just give us
some sense of SR.
I know that Tom and I already know
it kind of, but there are people out
there listening who probably
don't completely understand SR
and and what the game is.
Yeah. So segment routing,
I have only cover covered the MPLS part
of it, so that's what I where I
would like to,
keep this conversation to because I still haven't
dwelled into SRV six.
So it it starts
many years ago, I had this discussion with
one of the Cisco engineers in Cisco office,
and he asked me this question that,
hey, man. You're working in service provider, and
you run link state routing protocols.
On top of it, how do you run
MPLS? And I said, we have LDP. We
have RSVPT.
And he said, but,
for the majority of your forwarding,
you don't need
so many labels which LDP advertises, and what
RSVP does is mostly for fast rerouting.
And it made sense. And he said, how
about if we could advertise the labels
along with the link state routing protocols?
At that time, segment routing, he was,
going towards segment routing, but he didn't give
me the full details.
So I came back home and I started,
doing some research of my own, and I
found a couple of articles,
some drafts.
And that's where I thought that, okay. So
this is what the concept of segment routing
is. It's basically
that you
have segment routing in an MPLS network. It
talks about having MPLS forwarding base.
And instead of getting the labels advertised through
a dedicated label distribution protocol such as LDP
or RSVP PPE,
how about you distribute the labels using the
link state routing protocols itself?
And it would get programmed into the, hardware
in the same manner, and you would have
the same label forwarding operations and label switching
operations push,
swap, and pop.
So it the benefit is that you don't
have to do a lot of,
upgrade in terms of hardware.
And in terms of software, you don't have
to,
make a lot of changes. If you're running
ISIS, it's just a matter of adding another
TLV.
And a few set of TLV,
can
enhance the link state routing protocol to a
label distribution protocol as well.
So that's how it started with segment routing.
So, basically, the difference between
standard MPLS TE
and SR MPLS
is,
just to make sure that we have this
right, is that
in
in in MPLS TE,
you don't really have a label stack. You
have an in what we call a label
stack is an inner and an outer. And
that's pretty much you only get to two
labels.
And every router does a pop.
Not every router, but every label router
does a pop
and,
push.
Like, it swaps the labels at every at
every hop,
in theory. That's I mean, there are games
we play with the labels so that you
don't actually swap the labels. But that's the
theoretical way that it works.
Whereas with SRv6,
because it's basically
a source routed technology, which people don't always
understand, or SR MPLS,
SR itself, segment routing itself, is a source
routed technology.
Somewhere along the path close to the source,
in theory,
you push the entire stack of labels
to get you from source to destination. So
you don't actually swap
labels at every hop.
You just pop the label, exposing the next
label
whenever you process that that particular
situation.
So there are there are couple of things
here. So when it comes to segment routing
in terms of creating the whole stack, basically,
the original name was spring source packet Internet
routing.
So
in
LDP,
the IGP routing protocol when the route populates
in the routing table, the LDP then add
advertises
generates a label and distributes it to its
upstream
peers. And
the
all the routers in the neighbor, in the
network, they have all the labels available, but,
the label which is applied
to a packet which enters the MPLS domain,
there's only one pack one label applied and
every hop intermediary hop,
makes decisions, swap or pop decision based on
that incoming label.
In segment routing,
segment routing
can create the entire label stack at the
source. But because the hardware forwarding mechanism has
remained the same because you haven't upgraded the
hardware, so the hardware knows how to forward
MPLS. So although the label remains the same,
the incoming label and the outgoing label because
in segment routing, there are two types of
label. One is statically
advertised label,
which
signifies the
segment out, a prefix
set or the node set, which defines the
router as in a unique loopback address or
unique label.
And then for each adjacency, there is a
dynamically allocated or can be manually allocated, dynamically
allocated adjacency set. In LDP, everything is dynamic.
But in segment routing, since the,
node set is static,
you can have the entire label stack and
and created at the source.
And you'll if if there is no other,
traffic engineering mechanism happening and if it if
there is no backup path, the
on the primary path,
your incoming label and the outgoing label would
be the same because the label denotes the
destination or router.
But, because the hardware is still working on
the principles of MPLS,
it is swapping the incoming
label with the outgoing label. It is the
same label,
but it is still doing the swapping mechanism.
And then we have the same penalty made
hop popping,
as in as in traditional MPLS. So the
penalty made hop pops the last, the final
label and sends the IP traffic.
So that's why segment routing is very easy
to adapt to, coming from traditional MPLS because,
your protocols
are are upgraded, enhanced.
Many TLVs have been add added in ISIS
and OSPF has been upgraded.
IDF RFCs are available.
I have worked with multiple vendors who are
running segment routing, Juniper, Nokia, Cisco.
In fact, multi vendor labs also I have
tested.
They all work very well.
Okay.
So why MPLS
instead of v six?
That's always gonna be the first question is
who if anybody who's familiar
with segment routing,
I know why
I often go towards
v six
is just because
of the hardware problems you run into. And
deploying if you don't already have MPLS deployed,
deploying MPLS in a network from the ground
up
depending on the size of the network. But
it can be quite challenging,
just to get MPLS deployed, get things configured,
get your labels set up,
just just to do stuff. So why why
MPLS?
Just out of curiosity.
I I believe MPLS has been there for
long and every
like, every project, it takes a considerable amount
of effort and resource to move to something
new, which is drastically different.
When we had a requirement to forward I
p v six based traffic, customers who wanted
I p v six reachability,
we simply implemented six v p. So the
customer p to c connection was I p
v six based, but we were simply
forwarding based on our MPLS traffic. And
there was no more there there has been
very little motivation to move to,
I p v six,
natively if you do not have a very
strong requirement as a product.
I believe
SR v six is going to change it
because SR v six,
enables you to connect end to end data
center to data center using the same,
segment stack.
So that could be a strong motivating factor.
Other than that, I believe
it's just a lot of effort which people
are thinking,
let's not fix it if it's not broken.
So Yeah. I think product if it can
be if it cannot be productized,
then there's no motivation.
I I I think that it it is
true, Russ, to go from no label switching
at all, just like IP routing with devices
that cannot do label switching to move that
into MPLS. Yeah. Absolutely. That's a lift. You
gotta upgrade a bunch of stuff. But if
you already run a network that does label
switching,
it's not like v six is gonna give
you some new magical capability. But I I
I I see it I guess it depends
on where you're coming from. If you're already
running an MPLS network, then you're already doing
MPLS.
So but there are networks out there, I'm
sure, that they never did that. They never
started on that. And now they wanna do
they wanna take advantage of these capabilities and
let's put it in IP v six. You
don't have to change out your silicon. Like,
I can I can see it both ways?
Well, it's not just silicon. It's also the
routers in the middle.
To the routers in the middle, SRV six
is just v six.
Then I mean, they don't actually see anything.
Right? Yeah. And maybe you maybe you run
over a public network. Maybe you don't control
the bits. Yeah. I mean Yeah.
Now I would say the neg the the
flip side of that is primarily gonna be
MTU from my side
when I think about it, is that
SR v six without micro SIDs,
in particular without micro SIDs, is a much
larger packet. Right? Now, when you get into
micro SIDs,
you can play games with, like, well, it's
only an extra SRv6 header. It's only one
IP. It's only 128
bits.
But
without micro SIDs, like, if you get more
than a couple of labels, you're adding a
lot of data,
header data, to your packet to get the
packet through your network. So that's why,
things can get into it. I think it
would also depend on whether
the network is doing SR
or whether the applications are doing SR.
This is something that not a lot of
people think about when they get to SR,
is that
if the application is doing SR,
writing an application that is native MPLS
is far beyond the kin
of
most
application developers. I mean Right. I'm not you
know, it's just not what they do, right?
It's not
they focus on databases and user interfaces and
they don't focus on, like, networking technologies.
So you give them these weird MPLS labels
and say, you've got to figure out this
label stack. And they're like, oh, no. Go
away. I got other stuff to do. Whereas
with SRv6, you just say,
all you do is you put this header
on the front end of it and put
the packet on the wire.
And it's just it's just v six. Just
just ignore everything else. It's just IP and
IP.
Right?
I think it it it kind of works.
But, with native MPLS, there are in my
experience, we we already struggle a lot when
we
switch the traffic from one carrier to another
carrier over interiors option b.
So the if they have ready redundancy,
they would like to have redundancy based on
IP
and, have BGP attributes. But the label that
they have
is I mean, their traffic is switched over
the label. So regardless of what BGP attribute
they they are receiving,
they have less control over it. So I
think natively writing an MPLS
based application,
I I'm coming from that point,
that there's already a lot of challenging scenario.
I p v six and micro set based
network programmability,
makes things a lot easier,
in my opinion.
So I'm I'm curious, Russ, on the other
side. Do
are there commercial applications that do this that
can actually take advantage of us? Or I
never heard of one myself. It was always
just the network people trying to provide a
reliable overlay.
But, are there are there applications where the
application developer's like, yeah. I wanna get into
the network and figure out how to move
my packets.
Yeah. In fact, I would say
the vast majority of my SR v six
deployment is on the application side.
And then and the network is just playing
along.
I mean, it's just providing
basically, the the network is providing
service chaining
and such. Really, it's just providing routing
between the service chain points
and
exits and stuff like this,
it's not really like, we're
not planning to do a lot of end
cap, pushing the SRv6 label stack
on a router.
Most of the SRv6 label stack is going
to be pushed
by applications.
So
that's
and that's probably the main reason that I'm
not really looking at MPLS,
is because I go to the app developers,
and I go, we'd really like MPLS, and
they're like, yeah. Go away.
And that is precisely why I mentioned that
SR v six could be a very strong
motivator for the providers to switch to native
SR v six, and native IP six six
based networks, if not already, and turn off
MPLS.
Probably not turn off, but, yeah, SR v
six is better.
Well,
again, there's trade offs. Right? There's always trade
offs. And
the the the cool thing about about MPLS
is it is a smaller label.
In theory, it's faster to switch. I don't
know if that's true with modern forwarding engines.
I mean, that's why it was invented in
the first place. It came out of ATM.
And ATM was all designed to have fixed
cell sizes
and fixed headers
so that you wouldn't have all this garbage
that you're switching on.
And so you start looking at SR v
six with microsids, and you're like, yeah. But
now I've got to actually read parts of
the v six destination address
and use those parts. Wow. That's that's that's
very complex code.
Right? That's not simple as look at a
look at a label, flip the label, or
pop the label, and look at the next
label to do whatever the next label says.
So there there there's always trade offs in
these things, and I don't wanna make one
sound better than the other. I just was
curious why MPLS
in your particular case because
it seems
like most people are SRV six. That's all.
Yeah. I I believe it's it's about how
much value you're getting for that effort that
you're putting into,
comp processing that complexity.
So so him
the MPLS makes sense. Yeah. I'm I'm wondering
what, so what what pushed you to write
the book? What was your what was your
motivation there?
So
I started doing segment routing,
for my
own
organization many years ago. And,
after doing this little bit of testing in
the lab because we had to test the
products,
the virtual
images,
in what code, how much functionality is available,
especially around PILFA,
because we had our SCPT based FRR,
already.
So we wanted to know how much work
has been done by the vendors, in terms
of fast reroute.
So I started testing, and
then we created a few documents in terms
of how much we can,
deploy in the network today.
Did a a few rounds of training internally,
and, it was received very,
very well,
across multiple teams.
And, finally, I put this on on GitHub
because I was trying to get, some more
audience for it.
And, I looked into multiple options, perhaps could
create
a sandbox lab for everybody to access as
a pay as you go model. I couldn't
figure these things out, so I finally settled
down on publishing it as a book.
Oh, very cool.
So and and I kept it to it
was it was a difficult
method because
I was doing
two types of training. First, I was covering
the entire theory in one go and then
the labs.
But,
in the in the book, I I have
kind of mixed them together. So there is
sufficient amount of theory, and then there is
a good
amount of lab hands on lab so that
you don't feel disconnected that there is a
small amount of lab, and then you have
to go through a big a big chunk
of theory.
So I've tried to strike the right balance.
Interesting. So yeah. So talk so the the
you said a lot of this book is
about TILFA.
So maybe we ought to talk a little
bit about TILFA.
I don't know. Tom, did you have other
SR stuff you wanted to talk about before
we get to
Oh, no. I was just I was just
gonna say I that I love the premise
of that that it's a it's a way
to help people get up to speed in
a practical way.
I think we need more books like that.
I I it sounds sounds really cool. I'm
glad you published it.
Yeah.
The labs, by the way, are they available
on GitHub by them standalone, or are they
only, like are they published as as through
a gateway? Or or is it just what's
one thing I don't like about books with
labs
is that when they put the books the
labs printed
in the book, there's no digital copy, and
you're spending fourteen hours trying to type all
the commands in.
So I have I have put the entire
configuration
used in the book, in the books, GitHub
repository. So the publisher packed. They have a
GitHub account, and they have created a repository
for the book. Okay. Cool. What I have
done, chapter wise, I have copied the code
as well as because the the book that
I have,
written
is designed in a sequence.
So if you're going to go to chapter
eight, lab seven,
then you must have all the previous labs
completed. Now if you, tomorrow, want to simply
go and,
access,
okay. I want to see how lab 10
goes. Now you don't want to spend a
lot of time in configuring the previous lab
nine. So I've also written an Ansible playbook
and public, updated to the GitHub repository.
So you can
simply run the playbook tail up to,
lab nine, and then get your hands dirty
on lab 10.
And, I have tested it on Cisco ISXR
as
well as, Juniper Junos,
separately. I wanted to do,
a single lab multi vendor, but,
the way I had designed this whole topology,
it didn't work out. I had to make
trade offs. So what I did, I just
for the sake of simplicity,
I kept the entire book on Cisco ISXR.
Most of you people are familiar with it.
And, for the Juniper part, I have uploaded
the configuration
in another branch of the same repository.
And there is an Ansible playbook for XR,
and then there is a
simple configuration
branch process for XR.
Excellent. Yeah. Cool. Awesome. Okay. So tell us
a little bit about t I l f
a. Because you said you spent a lot
of time in the book on t I
l f a.
Yeah.
So because the book
has
ISIS and LDP as a foundational,
routing and label distribution,
protocol,
After introducing segment routing and
working with segment routing and LDP interworking lab,
segment routing was kind of
not going anywhere. I had to introduce either
I had to think about either introducing Flexalgo
or SRT
or simply go with TILFA. So I I
chose TILFA because it was simpler.
Plus that is what we went with, initially,
when we deployed segment routing.
So we had
to make a lot of decisions around TILFA's
implementation
because we had I I was always comparing
it with what RSVPT
offers today and what we provide
in terms of fast route to our customers.
So
many years ago, the
softwares did not the operating systems did not
have the same level of protection available,
in all the vendors.
Cisco did, pretty well in
in, I think, 06/2005
onwards,
I o '6 r.
So in TI LFA, we we,
use SRLG protection and node protection both,
pretty much what we use for RSVPT.
It's a different way of using it, because,
originally, even the SRLG protection
was not that well in in Cisco's implementation
of TILFA.
It was only local SRLG.
So
in like, any provider network, if a link
goes down, which in a worldwide network always
some incident would happen, you need fast reroute
mechanism to reroute your traffic
to avoid the downtimes of fifty millisecond, you
know, fast rerouting.
So TILFA
does that by
creating a backup route.
There are two methods of
implementing TILFA. The most popular, and I think
that's what everybody goes for is
per prefix backup route. So for every route
in your routing table, there is a
backup
route. And it's not just a route in
your routing table or routing information base. It's
also installed in the forwarding information base and
your label forwarding information base so that your
label traffic could be switched over to the
backup route.
And,
it does so by I mean, TI LFA
has also had a journey from right from
classic LFA then remote LFA.
And TI LFA is
works with SR because it it calculates the
post convergence path. So if
for on on a particular router,
for a particular route, the next hop
is a. And if that'll
if a link towards that a goes down,
what would be the post convergence path? And
that post convergence path becomes
your backup route in TILFA.
And
that makes sense because, eventually, this is what
happens in RSVPT.
So in RSVPT,
even if you create a manual bypass tunnel,
taking a longer path,
to avoid any common transmission equipments,
eventually, after the RSVP retry timer expires,
it switches over to the next best path
calculated by your link state routing protocol. That's
where it tries to resignal your LSP. So
the ILF, it does so,
beforehand and by default.
So that makes sense. And
incorporating that with SRLG and node protection,
it it offered everything that we were doing
with RSVPT.
Originally, with Cisco's implementation, we were not getting
remote SRLG protection,
which was available in in RSVPT.
But later on, they implement they updated
it, and it can do both now. So
So it's not really just calculating the next
best path, though. Right? Is it can add
calculating a remote LFA,
or is it only calculating an LFA?
No. So it is
it is calculating remote LFA and classic LFA
both. Okay. And this was implementation. It is
both because if your
classic LFA calculation is very simple. So Right.
It takes a little bit of CPU time.
Yeah. So if if Can I say classic
LFA?
Classic LFA is basically
EagerP feasible successors for people who don't know
it. Although, it's a little bit looser than
feasible successors. Fee feasible successors actually
are a little more strict
than classic LFA. Right?
So Yeah. Remote LFA
is I'm gonna tunnel through
the router next to me, my neighbor, who
would normally
route back to me
because I'm their best path right now. So
I'm gonna actually use
a tunnel to get through somebody who thinks
I'm their best path to get beyond them
to some place in the network where I
know the traffic will be forwarded the correct
direction. You can express this as p q
space. You can express this as there's, like,
five different mathematical models you can use to
talk about this, which is part of the
confusion for people is they get into all
the math models and you're like, it's actually
really simple. I'm just looking for some place
in the network that I can terminate a
tunnel that's gonna continue the traffic towards the
destination.
That's all I'm
doing. So, anyway, continue. I'm sorry. So it
already does LFA.
Yeah. So it it does so the Cisco's
implementation has classic LFA and TI LFA both.
So for a backup path, if TI LFA
and classic LFA are the same path, then
classic LFA takes precedence.
And for the TI LFA,
yeah, as you said, in remote LFA, you
have p space and q space, and the
overlapping p q node
becomes your
point of local repair for to which you
create the tunnel. And TILFA takes it one
step further because if your p space and
q space are not overlapping,
then TILFA, because it computes the post convergence
path, it forces it directs that,
additional link even if it is not IGP,
best path cost link,
to use that,
adjacency
set,
to direct between p space and jump from
p space to q space. And in my
book, the topologies that I have created and
the labs that I have taken from,
basic implementation of t I l f a
right from the introduction.
In every lab, I have tried to create
a a topology diagram
where the p
space and q space are demonstrated, then I
have shown the calculation
and based on how what the link costs
are. So the end to end metric,
is the reason behind having this these many
routers in one p space and these many
routers in q space.
And,
the end to end path cost, the post
convergence path cost, which is why TILFA chose
to redirect,
I mean, jump from piece space to queue
space.
This this is all I have tried to
cover.
And, the reason for covering this in the
because
if you if you do not have backup
path and if you do not have segment
routing,
the,
segment routing traffic engineering,
then it it wasn't becoming very clear
how these how the label stack is getting
created at the source.
So with the introduction
of TILFA in the lab, because the
backup path would have a stack of labels,
and the point of local repair had to
create the entire label stack
to the destination for the backup path. And
through that, I have tried to demonstrate that
this is how segment routing in MPLS network,
manifests.
So rather so what you're saying is is
that in TILFA,
instead of just creating
so so if I have a stack of
three labels
already on the packet, and I get to
some point in the network where
I see that I need to follow a
backup path,
rather than just adding more labels to get
me to the next hop, you're saying we
actually recreate the path from that point forward
all the way to the same destination
using the backup path. Is that correct? Or
are we just adding
okay. I'm gonna add a new label. I'm
gonna push a new label that gets me
to a to a point where I won't
loop. And then when that person when that
router pops it, it's gonna be the original
label stack to get them back to where
they need to go.
That might be problematic because if it takes
you
how do you avoid the loop in that
case? Right? If it happens that
the device is You already have a stack
of label coming from label edge router Mhmm.
To a label switch router in intermediary,
path.
And on that path, the next hop goes,
let's say, for the next hop to go
down, a TILFA backup path has been calculated
from the label switch router.
So that path would include
that TILFA backup path would include
a set of labels.
Now the the incoming set of label
would simply become the inner label so that
the top labels would be,
the transport path to avoid the loop. Okay.
And then normal forwarding would take place. Right.
So you're just adding on another layer of
labels. You're not,
like,
redeveloping the entire path from the Yes. From
okay. Right. Just making sure I understood how
that worked. Yeah.
So how different is this,
would you say, than standard other than it
being SR?
So you're add so in standard MPLS,
if you do
reroute like this,
because you're pushing and popping,
you actually push to the next, you know,
to the next hop or whatever that's beyond
the beyond the loop.
And then you take over forwarding from there.
But in the case of SR,
you have to still have the full stack
of labels,
I guess. I mean, I'm trying to figure
out, like, what specifically
is different about this than standard? I have
covered, there there is a chapter in this
which is about micro loop avoidance, which covers
one such scenario
where
if you,
for any reason, forward the stack of labels
to a to the next hop, which you
believe is the backup.
Right. Right. But but that next hop doesn't
have any router to the destination,
and the next stop thinks you you yourself
are the are the next stop. So that
next stop will trap forward it back to
you, and that will create a micro loop.
Right. Now to avoid that, you enable micro
loop avoidance in in ASR, and what it
would do, it would detect change in topologies
as such.
And for every change in the topology, it
would create an explicit tunnel.
Now this is not a tunnel for your
backup path. Now this tunnel is for your
primary path. We had a label stack
to a router,
which
will not send it back to you.
And you're not none of your intermediary hops
will think that to that destination,
the traffic needs to be sent back to
you because they are all in the p
space.
And from there,
the label pop mechanism would happen because the
destination
is the node set.
So it would pop its top label. The
penalty made for router would do it, but
it would,
get the remaining stack of the label, and
it would carry on with the forwarding
to avoid the micro loop.
Okay. That's interesting. Okay.
And so you have labs for this as
well where people can actually set this up
and see it happen
in the network
based on failures? Okay.
Yeah. So I've I've uploaded the Cisco CML
topology definition file and e v n g
definition file.
The e v n g is uploaded for
the Juniper as well as Cisco.
So all they have to do is just
import it in the even g, and if
they have the right image,
they can simply spin it up in no
time.
Cool.
Of course, you have to have all the
right images,
which is which is always I don't know.
Yeah. That's always really painful,
getting all the images and making sure they're
all working. And
and even g, what are you running on
that you're running even even g? Are you
running this, like, in the cloud on a
high powered box? Because I every time I
try to run even in g, it's, like,
slow.
So,
I tested it because for the benefit of
everybody, I had to test the hardware requirement.
The server I have is a very big
server. It is 96 vCPU cores and one
terabytes of RAM. So
I I had all the resources available.
But for everyone's benefit, I created my Google
Cloud Platform account, and even g website has
a very good documentation on how to set
this up on GCP.
Mhmm. And all you have to do is
just follow those, few steps, and in no
time, you have even g running, up and
running.
So with 32
vCPU cores and 28
GB RAM in Google Clyde Cloud platform, I
could get this up and running in no
time. And in fact, I included
container lab as well. Okay.
So Nice. I created another server and
containerized the iOSXR
v nine k image
and tested it with that,
container lab platform
and all worked out with 30 c 32
CPUs.
Okay.
Cool. That's nice. Good.
Okay. I don't have any other questions unless
you do, Tom.
No. It's been a great conversation. Thank you,
Himans. Yeah. And thank you for coming on.
I'm a lot of it. For having me.
And,
we'll put a pointer to the book, I
suppose, in the show notes so people can
find it if they want to.
And
I'll actually try to scare up some documentation
on TILFA
because that's a new thing that not many
people are talking about yet.
And it's actually a very interesting topic. I've
I've run into it a couple of times
in my travels.
I'm not particularly thinking about deploying it right
now.
So, you know, it's one of those things
that that you just gotta go learn because
it's something new that's going on out there.
Okay. So, Hemant, any way for people to
get in touch with you? Do you blog
someplace? Do you have a blog? Do you
write on some social media
network such as it is?
I I have stopped blogging for for a
while now. I did have a blog on
GitHub pages, but, not anymore.
I try did try to have multiple social
media accounts, but very difficult to manage. So
I'm available on LinkedIn,
and that's where I'm most active on, and
people can connect me on that. In fact,
a few people who did buy the book,
they had,
appreciated my work on LinkedIn through messages, and,
I in fact offered them to,
clarify any doubts if I could not cover
them properly in the book. And
Yeah. Yeah. Yeah. They have the Awesome. Good.
That's great.
And, Tom,
should I just answer it for you?
No answer. I'm on LinkedIn.
I have solidarity finally. I have their thank
you, Iman. We have a we have a
guest that sees things the way I do.
Oh, Twitter. Just just LinkedIn.
Just LinkedIn. Wow. Okay.
Actually, I haven't logged in to my
into that in the routing geek account in,
like, a week. I probably need to go
do that because I just haven't been over
there to look at x in a week
or so.
I've been very busy. I'm doing a lot
of recordings and other stuff. So, wow, it's
it's crazy.
Alright.
So I'm Russ White. You can always find
me here at the hedge. You can find
me on rule11.tech,
on x whenever I get over there, LinkedIn
whenever I get over there,
not always on social media, but,
available when those are there.
And so, anyway, we know we live in
a detention driven economy, and we thank you
for listening to this episode of The Hedge
all the way to the bitter end, and
we will catch you next time.