[AUDIO LOGO]
So in this video, let's take a closer look at the differences
between normal shortest path first,
which of course, is what OSPF and IS-IS normally use,
and constraint-based shortest path first, which is what we're
using for traffic engineering.
Specifically, we want to look at what some of those constraints
are, how we can change them, how it influences the path
selection, and ultimately, how we
choose the path that our tunnel is going to use.
So let's go ahead and jump in and get started
looking at those details.
So we already know that traffic engineering uses CSPF.
But what does that actually mean?
Well, it modifies regular shortest path first
so that it's not just looking at the shortest or the best path.
It's the shortest or best path within defined constraints.
Now, we have already mentioned that the use of CSPF
does require a link-state routing protocol.
So of course, that's only OSPF and IS-IS.
And just for terminology's sake, another name for this
is Constraint-Based Routing, or CBR.
Now, the way that CBR differs from regular link-state routing
is, of course, in a few different ways.
So first, it modifies the use of the link cost
to actually consider a few things that we normally
don't consider, the first of which
is bandwidth availability.
Traditionally, we just look at the total bandwidth.
This is actually looking at how much of that
bandwidth is currently available as opposed,
of course, to being in use.
It also looks at link attributes.
We'll be covering those more in an upcoming video.
And of course, it looks at the priority
of the tunnel, zero to seven, as we discussed
in our previous video.
Now, CBR is generally going to be used on the edge of the MPLS
network--
again, generally on the PEs.
And it's going to calculate the path to another edge.
So again, this is normally an edge to edge type technology.
And what it's going to do is give us
a series of next-hop addresses instead
of just a single next hop.
This is going to be used to create that entire path.
Now, there are two types of tunnels possible.
The first and probably the most common is dynamic.
This is one that's going to be calculated, again,
by either OSPF or IS-IS--
in other words, your IGP.
The other one is explicit, where you as the administrator
manually configure a particular path.
This will probably more likely be
done if we're talking about setting up
a tunnel for a specific type of traffic.
Now, another interesting thing to note here,
tunnels do not do multipathing.
Now, understand, MPLS itself can, of course,
do multipathing if we have an IGP tie, which of course, we
mentioned earlier, is equal-cost multipathing.
So MPLS itself can.
The tunnel itself will not.
So if there is equal-cost multipathing,
we're going to break that tie.
The way we're going to do it is using this criteria.
First, we'll look at the highest minimum bandwidth on the path.
Basically, we're looking for the bottleneck.
So whatever the smallest link is,
we're going to choose the best of those.
Next, it's going to go to lowest hop count.
Just between us, we're not going to say that that
sounds an awful lot like RIP.
We're just not going to say that.
But the fact of the matter is it's quite a bit like RIP.
But of course, that's still a little bit better
than the final tiebreaker, which is just really random.
So it's just going to pick a path
to use if there's no other tiebreakers here.
The point is it will only use one path.
And that's fine because it's a single tunnel.
Now, two key factors here of the TE tunnel,
this is not considered an interface to the IGP.
If it was, we could have some issues.
And by not doing so, we prevent them.
First one is we prevent a recursive lookup problem,
where all of a sudden, the tunnel
itself might look like a really good way
to get to the tunnel destination.
And of course, that's a recursive lookup problem.
So that's not going to be allowed.
It also prevents triggering an SPF calculation.
We don't want SPF to have to reconverge
every time a tunnel comes up.
So these are both really good things
that happen because it's not actually
treated as an IGP interface.
And another big thing that changes with CSPF
and the changes to our routing protocols
is we pick up this feature called autoroute.
Now, we're going to talk about traffic steering
in a little more detail coming up.
But for now, let's just say that the tunnel actually
appears in the routing table.
So yes, it's an interface.
It's just not an interface in the IGP.
It does have its own IGP metric, however.
And it, of course, can be used to forward traffic.
All of that said, again, it is still
not used in link-state updates.
Again, that's going back to the statement up here,
where it's not actually an interface to the IGP,
so that we prevent these other problems.
But autoroute does give us a method
to get traffic to go into this tunnel.
We'll talk about that more in an upcoming video.
So in this video, we looked at the things
that had to change between normal shortest path first
and constraint-based shortest path first in order for it
to work for traffic engineering.
We talked about how it will actually not
use equal-cost multipathing.
But it will come down to a tiebreaker,
even if that's just randomly choosing a path.
And we talked about how it doesn't use this tunnel
as an actual IGP interface, therefore preventing some,
well, rather catastrophic problems that could occur.
Now, we've spent a lot of time talking
about how this tunnel is built, how it's set up,
the different protocols and decisions that have to be made.
But at the end of the day, the tunnel
won't do any good unless we get traffic
to go through the tunnel.
And that we call traffic steering.
And that's what we get to cover next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.