[AUDIO LOGO]
So let's begin by talking about why we want MPLS traffic
engineering.
What does this bring to the table
that we don't normally have?
Well, we've discussed it a little bit in previous skills,
but keep in mind that MPLS normally
follows the IGP when determining where
to forward the packets to, in other words, the next hop.
Well, IGPs, such as OSPF and ISIS,
although technically you could use other protocols,
they don't support traffic engineering.
So we won't be discussing those.
But OSPF and ISIS, of course, have their own path selection
criteria.
OSPF is a little bit more complicated,
but just in a general sense, they both sort of
come down to lowest cost.
Of course, it's a little more complicated than that.
But generally speaking, that's good enough
for this discussion.
Whatever their criteria, they choose a best path
to get to a destination.
Now, if there are multiple paths that are completely equal,
we of course support ECMP or equal
cost multipathing, in which case, even MPLS can still
use both of those paths and send traffic along both paths.
That's not what traffic engineering is for.
What traffic engineering is for is
what happens when we don't have equal paths.
Just as an example.
What if I had a 10-gig circuit and a 1-gig circuit
that I wanted to use?
Now, obviously, OSPF and ISIS should
choose the 10-gig circuit to be our best link, our best path.
And it would be.
But if that 10-gig circuit is running at 90%,
well, it only has one gig left, anyway.
So now, you have two equal paths again.
But your IGP, normally is not going to keep track of that.
Where traffic engineering comes into play is where it can say,
yes, the IGP says this is the best path.
However, in the right circumstances,
maybe this other path, which is perfectly fine, perfectly
viable, there's no loops, it's just
not the best, that doesn't make it not usable.
Traffic engineering actually allows
us to use those other paths.
So let's jump in and talk a little bit more detail
about why we want this and how it fits into everything.
And well, some of the things we need to do to support it.
And then in our future videos here, we're
going to be taking a look at how it actually functions.
So let's get in and look at some of the things that make traffic
engineering worth running.
So the main reason that we want traffic engineering
is to get better usage of what would be potentially
underutilized resources.
So like we said during the introduction, maybe
that 1-gig link that's sitting there not being used at all
because the IGP simply says it's not the best path.
Now, to ensure that we can use these other paths
and that they are, in fact, loop-free,
we need a routing protocol that actually
has a database with a view of the whole network
or the topology.
That, of course, is going to require a link
state routing protocol.
It also requires extensions.
We call them, of course, the TE extensions.
But these allow it to also help keep
track of the load on that link, not just
the available bandwidth, which is what
these protocols normally track.
Now, given that it has to be link state, as we mentioned,
there are only two choices for this.
Of course, we can either run OSPF or ISIS,
which is why these are, of course, the two main protocols
that we use under MPLS.
Keep in mind, even if we're not using MPLS traffic engineering
right now, we may at some point in the future.
So generally speaking, if you're going
to build an MPLS environment, it makes the most sense
to build it on either OSPF or ISIS.
And of course, most service providers have done just that.
This is more of a discussion for enterprise core.
Because again, a lot of enterprises
also use MPLS in their core and they may not
be using traffic engineering right now,
but they may want to in the future.
Again, from a service provider perspective,
we are probably already running one of these two protocols,
and while your environment is probably already running
traffic engineering as well.
To put this another way, what we're doing
is we're actually mapping the traffic to the network.
We're not just routing down the best path.
Again, that's what your IGPs normally do,
that's just standard IP-based forwarding.
TE allows us to use other paths rather than just the best.
And we are going to be mapping that traffic.
So as we said, what the IGP, of course, will normally do,
is it routes traffic based on the best path.
Whatever that means to that particular routing protocol,
that's, of course, going to be based entirely
on the destination address where the traffic is going.
And of course, the most important thing
in this whole discussion really is
that it does not change based on the traffic load.
These routing protocols don't track load,
they just look at the speed of the circuit.
Overall, the cost.
This, of course, is where traffic engineering
steps in and allows that traffic to be
mapped based on other criteria.
Not just the criteria for the IGP, which, again, is usually
going to be lowest cost.
We might want to do this based on traffic type.
Maybe I want to send voice traffic
down a particular circuit.
Just as another example, I did some work
with a company that did stock trading.
And they had two remote offices that
were rather far apart, they needed
to get those stock, quotes, "to the other location as quickly
as possible."
In doing so, they had put in this very elaborate, very
direct line of sight, low speed but incredibly low
latency circuit to get those stock quotes through.
It was like 3 milliseconds faster
than their normal circuit.
Doesn't sound like much.
But apparently, in the stock trading market, that's a lot.
Because they spent a lot of money for this circuit
that was only 3 milliseconds, less
latency than their other circuit.
But the point is, that circuit was also low bandwidth and very
high cost.
So we use traffic engineering to ensure
that the only thing that went over that special circuit was,
in fact, the stock trading information, all other traffic
was sent across the normal circuit.
Now, in truth, that particular environment,
we were not using MPLS traffic engineering,
we were doing it a slightly different way.
But it's still the same concept.
We may want to do this to send a certain type of traffic
down a certain circuit for a particular reason,
whatever that may be.
Of course, another very popular reason,
as we've mentioned numerous times now, is the traffic load.
Again, this other alternate circuit may not be the fastest,
it may not be the best, but it's still perfectly fine.
I always like to use the analogy of a GPS.
If you're trying to find your way somewhere,
the GPS will most likely route you on to the highway.
However, if there's a lot of traffic on the highway or maybe
an accident, it'll find an alternate route
and send you around the accident on what's potentially maybe
side streets or secondary roads.
Normally, those wouldn't be the best way to go.
But they're certainly the best way
to go when the best way to go is all backed up.
So again, we're talking about using those links that
normally would not be utilized.
So again, maybe those side streets.
You probably wouldn't normally take the back way
to get somewhere, but if the highway is backed up,
it's a great choice.
And ultimately, what does this do?
It certainly helps the end user experience,
because we're getting use of all of our available bandwidth,
maybe a particular circuit type, that sort of thing.
And ultimately, it's going to save us money because why?
Well, we're using circuits that we're paying for.
If we're paying for them, we should be using that.
Now, one thing to keep in mind is, in this environment,
if there is a failure.
And of course, we're really talking
about a failure of these secondary circuits or possibly
even the primary circuit.
But either way, that remaining traffic
is still going to have to traverse the remaining
path, whatever that may be.
And another cool thing with traffic engineering
is we can actually put priorities on our tunnels.
And certain tunnels can bump lesser priority tunnels.
So we can choose, in the event of lesser bandwidth available,
which tunnels stay up and which tunnels--
may be something like a tunnel we
built for TestDev or something like that
or non-mission critical information
can go down rather than our mission critical.
It's essentially QoS for traffic engineering tunnels.
Now, just to put this out there-- and hopefully,
it's sort of obvious.
But this is only beneficial, of course,
if there are resources available, which
are, in fact, underutilized.
If there's no resources that we're not using,
well, this isn't really going to help us much.
Because this is helping us use those underutilized resources.
This is really designed to solve long-term issues, not
short term problems like traffic bursts.
This would be more of an issue for say, QoS or quality
of service.
QoS and doing things like traffic prioritization
and having egress buffers, things like this,
those are more to help short term traffic burst problems.
This is a long term, always going
to be using these back up underutilized paths.
And truth be told, we want this to be a long term solution,
because we always want to be using underutilized resources.
We don't want to just use them temporarily.
The point we're really trying to make here
is these tunnels have to be built and set up.
And traffic has to be steered into these tunnels and so on.
This is not a quick thing we're going
to do just to resolve 30 milliseconds or even
500 milliseconds worth of traffic congestion.
This is something we're going to set up for the long term.
That's really the point we're trying to drive home
with this particular point.
Now, just for subject completeness here,
there are, in fact, other ways that we could accomplish,
the same thing.
We're doing with traffic engineering.
That company I mentioned earlier with the stock trading.
What we had actually done there for them
is policy-based routing.
We did their solution with PBR.
And that worked fine in their environment.
It's not going to be so good in a service provider environment,
because policy-based routing has the same problems
as source-based routing and static routing.
All of these have the same issue, which
is they don't scale very well.
And one of the biggest things, of course,
we need to be concerned with in a service provider environment
is scalability.
Source-based routing, just to add insult to injury,
not only does it not scale very well,
it also introduces some security concerns.
In this video, we just took a look
at why we want traffic engineering, what
it brings to the table that we don't get
from normal routing solutions.
The next thing to do is going to be
to take a look at some of the more detailed information
about how traffic engineering actually functions
and some of its core components.
And that's exactly what we get to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.