1
00:00:00,000 --> 00:00:02,904
[MUSIC PLAYING]

2
00:00:02,904 --> 00:00:08,230

3
00:00:08,230 --> 00:00:11,560
So now that we've discussed
why we want MPLS Traffic

4
00:00:11,560 --> 00:00:14,200
Engineering, now it's
time to talk about some

5
00:00:14,200 --> 00:00:17,800
of the things that have to
happen in order for MPLS TE

6
00:00:17,800 --> 00:00:19,370
to actually work.

7
00:00:19,370 --> 00:00:22,240
So the first is we're going to
need a separate control plane

8
00:00:22,240 --> 00:00:23,170
protocol.

9
00:00:23,170 --> 00:00:24,620
We'll talk about that.

10
00:00:24,620 --> 00:00:27,220
And of course, we'll talk
about those changes that

11
00:00:27,220 --> 00:00:31,240
had to be made to
both OSPF and IS-IS

12
00:00:31,240 --> 00:00:35,180
in order to be able to support
MPLS Traffic Engineering.

13
00:00:35,180 --> 00:00:37,360
So let's go ahead and
jump in to talking

14
00:00:37,360 --> 00:00:41,170
about the details of what
we need to get MPLS Traffic

15
00:00:41,170 --> 00:00:43,700
Engineering up and running.

16
00:00:43,700 --> 00:00:48,160
So for the control plane,
MPLS Traffic Engineering

17
00:00:48,160 --> 00:00:53,920
uses Resource Reservation
Protocol, or RSVP,

18
00:00:53,920 --> 00:00:56,820
to exchange labels.

19
00:00:56,820 --> 00:01:00,960
Now, RSVP is not a new
protocol by any means.

20
00:01:00,960 --> 00:01:05,010
We've been using it for
quite some time for QoS.

21
00:01:05,010 --> 00:01:08,220
It's not a popular
option in QoS.

22
00:01:08,220 --> 00:01:10,680
However, it has been
around for a while.

23
00:01:10,680 --> 00:01:14,880
And now we're using it for
MPLS Traffic Engineering

24
00:01:14,880 --> 00:01:16,770
as the control plane.

25
00:01:16,770 --> 00:01:20,730
And we use it to exchange the
labels used for our traffic

26
00:01:20,730 --> 00:01:22,930
engineering tunnels.

27
00:01:22,930 --> 00:01:25,110
Now, these labels
that are created

28
00:01:25,110 --> 00:01:30,180
are used to create an LSP,
or a Label Switch Path, which

29
00:01:30,180 --> 00:01:34,290
is really just another
word for the TE tunnel.

30
00:01:34,290 --> 00:01:42,390
The tunnel is based on
constraint-based SPF, or CSPF.

31
00:01:42,390 --> 00:01:44,250
This is that idea
that we're going

32
00:01:44,250 --> 00:01:50,160
to be using IS-IS or OSPF
to perform the calculation

33
00:01:50,160 --> 00:01:53,040
within certain constraints.

34
00:01:53,040 --> 00:01:56,400
We'll be talking about
this in more detail.

35
00:01:56,400 --> 00:02:02,010
Now, as we mentioned, the tunnel
itself is a Label Switch Path.

36
00:02:02,010 --> 00:02:05,500
Even if you have two
parallel tunnels,

37
00:02:05,500 --> 00:02:08,370
they're going to use
different labels.

38
00:02:08,370 --> 00:02:14,100
Because again, a label is
a path, or is a tunnel.

39
00:02:14,100 --> 00:02:16,200
They're one and the same.

40
00:02:16,200 --> 00:02:20,670
Also keep in mind that these
tunnels can be rerouted.

41
00:02:20,670 --> 00:02:23,320
And this could be for
a variety of reasons.

42
00:02:23,320 --> 00:02:25,500
Maybe our traffic
pattern changes.

43
00:02:25,500 --> 00:02:28,050
Maybe there's a
failure in the network.

44
00:02:28,050 --> 00:02:32,010
Any of these things could cause
the tunnel to be rerouted.

45
00:02:32,010 --> 00:02:35,700
If that happens, there
will be a new Label Switch

46
00:02:35,700 --> 00:02:39,510
Path, and therefore a
new label for the tunnel.

47
00:02:39,510 --> 00:02:42,660
Once our tunnel is
up, network engineers,

48
00:02:42,660 --> 00:02:46,050
that would be you, then
direct the traffic--

49
00:02:46,050 --> 00:02:48,510
or we call it traffic steering.

50
00:02:48,510 --> 00:02:53,370
We steer the traffic
into these TE tunnels

51
00:02:53,370 --> 00:02:57,060
using, most commonly, the IGP.

52
00:02:57,060 --> 00:02:59,640
We'll talk about traffic
steering in more detail

53
00:02:59,640 --> 00:03:00,370
as well.

54
00:03:00,370 --> 00:03:03,690
This is an introduction
to most of these topics.

55
00:03:03,690 --> 00:03:05,880
Now, we have
mentioned a few times

56
00:03:05,880 --> 00:03:08,700
that the only routing
protocols we can use here

57
00:03:08,700 --> 00:03:11,760
are OSPF or IS-IS.

58
00:03:11,760 --> 00:03:17,290
And both of those need
extensions in order to work.

59
00:03:17,290 --> 00:03:20,250
The reason we need
these extensions is it

60
00:03:20,250 --> 00:03:23,970
has to carry this
resource information,

61
00:03:23,970 --> 00:03:27,580
such as available bandwidth.

62
00:03:27,580 --> 00:03:30,330
So that's essentially
tracking load.

63
00:03:30,330 --> 00:03:33,090
Again, this is not something
these routing protocols

64
00:03:33,090 --> 00:03:34,960
normally do.

65
00:03:34,960 --> 00:03:37,920
We can also use these
extended routing protocols

66
00:03:37,920 --> 00:03:39,330
to direct the traffic--

67
00:03:39,330 --> 00:03:41,580
or again, we call it
traffic steering--

68
00:03:41,580 --> 00:03:45,370
into these TE tunnels once
they're up and running.

69
00:03:45,370 --> 00:03:48,660
This will create
additional FIB entries,

70
00:03:48,660 --> 00:03:54,000
and is accomplished by applying
the correct label stack.

71
00:03:54,000 --> 00:03:56,700
And of course, the other
thing these extensions do

72
00:03:56,700 --> 00:04:01,380
is they implement that
constraints-based SPF.

73
00:04:01,380 --> 00:04:05,160
Meaning, it can look at things
like the load on the interface,

74
00:04:05,160 --> 00:04:07,060
and things like that.

75
00:04:07,060 --> 00:04:08,490
So just to add more detail.

76
00:04:08,490 --> 00:04:10,800
What does SPF consider?

77
00:04:10,800 --> 00:04:12,430
Well, the first
thing, of course,

78
00:04:12,430 --> 00:04:17,100
is the information in the
traffic engineering database,

79
00:04:17,100 --> 00:04:19,110
or the TED.

80
00:04:19,110 --> 00:04:22,050
This would be that
information that we got above,

81
00:04:22,050 --> 00:04:24,690
such as things like the
available bandwidth,

82
00:04:24,690 --> 00:04:27,450
and things associated with that.

83
00:04:27,450 --> 00:04:32,790
Also, policies put in place
by the network engineers.

84
00:04:32,790 --> 00:04:36,600
And this, honestly, really
is the key factor here.

85
00:04:36,600 --> 00:04:38,490
This is something that
we, as the engineers,

86
00:04:38,490 --> 00:04:42,660
want to do, hence why it's
called traffic engineering.

87
00:04:42,660 --> 00:04:46,710
If we were to do all of this
without any kind of a policy--

88
00:04:46,710 --> 00:04:49,770
well, at that point, it's
basically just regular

89
00:04:49,770 --> 00:04:50,820
routing again.

90
00:04:50,820 --> 00:04:54,070
There's really no point in
going to traffic engineering.

91
00:04:54,070 --> 00:04:58,920
So again, even if we're talking
about the load on the circuits,

92
00:04:58,920 --> 00:05:00,900
we still have to
put that together

93
00:05:00,900 --> 00:05:03,570
with this policy
in order to tell it

94
00:05:03,570 --> 00:05:07,510
what we actually want it to do
under these certain conditions.

95
00:05:07,510 --> 00:05:11,100
So the policy really is key
for all of this to work.

96
00:05:11,100 --> 00:05:12,870
And that policy, of
course, is what's

97
00:05:12,870 --> 00:05:18,330
being engineered by us
network administrators.

98
00:05:18,330 --> 00:05:20,340
Now, we do have
some special names

99
00:05:20,340 --> 00:05:24,240
that we've set aside for the
Label Switch Routers that

100
00:05:24,240 --> 00:05:27,390
are involved in the TE LSP.

101
00:05:27,390 --> 00:05:30,840
First, we have the headend LSR.

102
00:05:30,840 --> 00:05:34,200
This, of course, is the
beginning of the tunnel.

103
00:05:34,200 --> 00:05:36,930
Keeping in mind, as we
go over these terms,

104
00:05:36,930 --> 00:05:39,600
all tunnels are unidirectional.

105
00:05:39,600 --> 00:05:43,140
So even if we're going to have a
tunnel for return traffic going

106
00:05:43,140 --> 00:05:44,200
the other way--

107
00:05:44,200 --> 00:05:46,050
well, that's a separate tunnel.

108
00:05:46,050 --> 00:05:48,550
It would have its own headend.

109
00:05:48,550 --> 00:05:50,880
So think about it
from the perspective

110
00:05:50,880 --> 00:05:53,490
that all of these
tunnels are one way.

111
00:05:53,490 --> 00:05:56,310
Makes these terms
make a lot more sense.

112
00:05:56,310 --> 00:05:59,760
Tail-end, of course, is the
opposite of the headend.

113
00:05:59,760 --> 00:06:01,650
This would be the
end of the tunnel

114
00:06:01,650 --> 00:06:03,660
where the traffic
comes back out.

115
00:06:03,660 --> 00:06:07,270
And then a midpoint
LSR is, of course,

116
00:06:07,270 --> 00:06:12,070
just any router that's in the
middle of this particular path.

117
00:06:12,070 --> 00:06:14,280
Now, keep in mind
these tunnels can

118
00:06:14,280 --> 00:06:18,150
be based on many different
criteria, some of which

119
00:06:18,150 --> 00:06:22,440
we have the ingress point for
the traffic, the egress point,

120
00:06:22,440 --> 00:06:26,820
what class of service or QoS
marking that traffic has.

121
00:06:26,820 --> 00:06:28,620
So there's quite a
few different things

122
00:06:28,620 --> 00:06:32,650
that we can do for the
criteria for the tunnel.

123
00:06:32,650 --> 00:06:35,310
Another very important
point, particularly

124
00:06:35,310 --> 00:06:37,230
for the network engineer.

125
00:06:37,230 --> 00:06:41,010
In order for us to
properly configure TE--

126
00:06:41,010 --> 00:06:43,690
and this goes with other
things as well, of course,

127
00:06:43,690 --> 00:06:46,710
like Quality of Service,
things along those lines.

128
00:06:46,710 --> 00:06:51,030
We really, really do have to
understand the traffic that's

129
00:06:51,030 --> 00:06:52,180
on the network.

130
00:06:52,180 --> 00:06:54,660
If we don't understand
the traffic properly,

131
00:06:54,660 --> 00:06:57,570
then how can we
manage it properly?

132
00:06:57,570 --> 00:07:00,820
Keep in mind, we're not talking
about just standard routing

133
00:07:00,820 --> 00:07:01,320
here.

134
00:07:01,320 --> 00:07:03,900
We're not just talking about
getting traffic from point A

135
00:07:03,900 --> 00:07:06,090
to point B. We
honestly don't have

136
00:07:06,090 --> 00:07:09,180
to know much about the traffic
in order to just deliver it

137
00:07:09,180 --> 00:07:10,270
properly.

138
00:07:10,270 --> 00:07:14,280
However, it is very important to
understand what the traffic is,

139
00:07:14,280 --> 00:07:16,980
if we want to put it
into a particular tunnel,

140
00:07:16,980 --> 00:07:20,400
treat it a certain way, send
it across a certain circuit.

141
00:07:20,400 --> 00:07:21,490
That sort of thing.

142
00:07:21,490 --> 00:07:24,060
So that's why understanding
the actual traffic

143
00:07:24,060 --> 00:07:29,200
is so critical when
it comes to MPLS TE.

144
00:07:29,200 --> 00:07:31,490
Now, we did already
mention this point.

145
00:07:31,490 --> 00:07:36,740
But make sure we remember that
all tunnels are unidirectional.

146
00:07:36,740 --> 00:07:40,210
So if you need traffic
to go in both directions,

147
00:07:40,210 --> 00:07:44,770
you're going to need a tunnel
in both directions as well.

148
00:07:44,770 --> 00:07:47,950
All traffic is one way
through the tunnel.

149
00:07:47,950 --> 00:07:51,650
Again, flowing from the
headend to the tail-end.

150
00:07:51,650 --> 00:07:53,860
Now, this could be an issue.

151
00:07:53,860 --> 00:07:56,620
What we mean by that is,
of course, scalability,

152
00:07:56,620 --> 00:07:59,290
the number of tunnels
that we're going to have.

153
00:07:59,290 --> 00:08:01,640
But it's not usually the case.

154
00:08:01,640 --> 00:08:05,800
And the reason we say that
is, headends are normally

155
00:08:05,800 --> 00:08:07,210
at the network edge.

156
00:08:07,210 --> 00:08:10,690
So probably the PE routers.

157
00:08:10,690 --> 00:08:14,200
We're not generally going to
have these set up on the core.

158
00:08:14,200 --> 00:08:19,180
Most traffic also would
not require a full mesh.

159
00:08:19,180 --> 00:08:23,060
If it did, yes, scalability
could start becoming an issue.

160
00:08:23,060 --> 00:08:28,220
However, a star topology
would be far more likely,

161
00:08:28,220 --> 00:08:31,670
particularly in a
service provider core.

162
00:08:31,670 --> 00:08:35,770
So again, scalability,
not usually an issue here,

163
00:08:35,770 --> 00:08:38,500
because of how these
are normally used.

164
00:08:38,500 --> 00:08:40,659
It is however,
something that we want

165
00:08:40,659 --> 00:08:44,080
to keep in mind if our
environment starts getting more

166
00:08:44,080 --> 00:08:47,380
complex, and these rules
that we just talked about

167
00:08:47,380 --> 00:08:50,280
don't necessarily apply.

168
00:08:50,280 --> 00:08:53,300
So in this video, we
got an introduction

169
00:08:53,300 --> 00:08:57,530
to the moving parts of
MPLS Traffic Engineering.

170
00:08:57,530 --> 00:09:01,910
We talked a bit about
RSVP, how we're using that

171
00:09:01,910 --> 00:09:06,920
from the QoS world to be our
control plane for MPLS Traffic

172
00:09:06,920 --> 00:09:07,890
Engineering.

173
00:09:07,890 --> 00:09:11,090
We also talked about the
extensions and the changes

174
00:09:11,090 --> 00:09:15,290
that have to happen to our
IGPs in order to support this.

175
00:09:15,290 --> 00:09:20,150
Now, as we dig deeper in,
there are six TE processes

176
00:09:20,150 --> 00:09:21,500
that we need to talk about.

177
00:09:21,500 --> 00:09:24,110
And that's exactly what
you and I get to do next.

178
00:09:24,110 --> 00:09:26,250
We'll do that in the next video.

179
00:09:26,250 --> 00:09:29,600
Until then, I hope this has
been informative for you,

180
00:09:29,600 --> 00:09:32,650
and I'd like to thank
you for viewing.

181
00:09:32,650 --> 00:09:36,000