1
00:00:00,000 --> 00:00:03,465
[AUDIO LOGO]

2
00:00:03,465 --> 00:00:07,930

3
00:00:07,930 --> 00:00:11,950
So now it's time to jump in
and take a look at sparse mode

4
00:00:11,950 --> 00:00:13,100
operation.

5
00:00:13,100 --> 00:00:16,059
Now as we've said
previously, this

6
00:00:16,059 --> 00:00:19,180
is definitely the preferred
way of doing multicast

7
00:00:19,180 --> 00:00:20,920
for most environments.

8
00:00:20,920 --> 00:00:24,460
Because in most environments,
the majority of devices

9
00:00:24,460 --> 00:00:27,250
are not going to be
multicast receivers.

10
00:00:27,250 --> 00:00:30,490
Therefore, we don't want to make
the assumption that everybody

11
00:00:30,490 --> 00:00:32,110
wants this multicast.

12
00:00:32,110 --> 00:00:35,200
We would rather do
a pull model, which

13
00:00:35,200 --> 00:00:37,900
is what sparse mode
is where we only

14
00:00:37,900 --> 00:00:41,690
forward the traffic to the
devices that actually need it.

15
00:00:41,690 --> 00:00:47,260
So to a certain extent, this is
the opposite of the dense mode

16
00:00:47,260 --> 00:00:49,900
model where we assume
everybody wants it,

17
00:00:49,900 --> 00:00:51,890
and we flood it to the network.

18
00:00:51,890 --> 00:00:54,040
Now in order for
this to work, we

19
00:00:54,040 --> 00:00:56,780
are going to have to add
an additional component.

20
00:00:56,780 --> 00:00:59,060
And that's called
the rendezvous point.

21
00:00:59,060 --> 00:01:01,420
So all of this said,
let's go ahead,

22
00:01:01,420 --> 00:01:04,010
and just jump in, and take
a look at how this works.

23
00:01:04,010 --> 00:01:06,430
We've updated our diagram just
a little bit with some more

24
00:01:06,430 --> 00:01:07,370
information.

25
00:01:07,370 --> 00:01:09,110
So we'll start by
going over that

26
00:01:09,110 --> 00:01:14,110
and then talk about the
sparse mode operation.

27
00:01:14,110 --> 00:01:16,020
So the first thing
that's changed

28
00:01:16,020 --> 00:01:18,270
is, of course, we
have configured

29
00:01:18,270 --> 00:01:22,140
router 2 with a
loopback 0 interface

30
00:01:22,140 --> 00:01:25,860
with the address 100.1.1.1.

31
00:01:25,860 --> 00:01:31,050
And we've configured this to be
the RP or the rendezvous point.

32
00:01:31,050 --> 00:01:34,350
Now one quick thing to
note here as we jump in,

33
00:01:34,350 --> 00:01:37,770
every router in the
multicast environment

34
00:01:37,770 --> 00:01:40,770
has to know where the RP is.

35
00:01:40,770 --> 00:01:44,530
Now, there are several
ways for that to happen.

36
00:01:44,530 --> 00:01:47,590
But that's not part
of this discussion.

37
00:01:47,590 --> 00:01:50,580
We will be discussing
that in a future skill.

38
00:01:50,580 --> 00:01:52,360
So don't worry about that.

39
00:01:52,360 --> 00:01:56,280
But just be aware that all
of the devices know who

40
00:01:56,280 --> 00:01:58,840
or where the RP is.

41
00:01:58,840 --> 00:02:01,230
So there are choices
of how we run the RP

42
00:02:01,230 --> 00:02:03,210
and how we learn about the IP.

43
00:02:03,210 --> 00:02:05,640
And those are
discussions we will have.

44
00:02:05,640 --> 00:02:09,780
But for right now, let's just
go with every router knows who

45
00:02:09,780 --> 00:02:14,950
and where the RP is, in this
case, router 2's loopback 0

46
00:02:14,950 --> 00:02:16,060
interface.

47
00:02:16,060 --> 00:02:20,830
Also note that we have two
different RPF checks noted

48
00:02:20,830 --> 00:02:23,360
on this particular diagram.

49
00:02:23,360 --> 00:02:26,770
We have an RPF check that's
going to be for the source

50
00:02:26,770 --> 00:02:27,880
comma group.

51
00:02:27,880 --> 00:02:30,850
This is, of course, the entry
we've been discussing up

52
00:02:30,850 --> 00:02:32,210
to this point.

53
00:02:32,210 --> 00:02:34,210
But notice we have
a new one here

54
00:02:34,210 --> 00:02:37,600
called the star comma G entry.

55
00:02:37,600 --> 00:02:40,660
This is referred to
as the shared tree.

56
00:02:40,660 --> 00:02:42,760
And this is something
we're going to use

57
00:02:42,760 --> 00:02:44,780
with the rendezvous point.

58
00:02:44,780 --> 00:02:46,900
This will make
sense as we proceed

59
00:02:46,900 --> 00:02:48,380
through this discussion.

60
00:02:48,380 --> 00:02:53,180
So let's start the same
way we did with dense mode.

61
00:02:53,180 --> 00:02:56,710
What happens when the
source starts up and begins

62
00:02:56,710 --> 00:02:59,590
sending traffic to router 1?

63
00:02:59,590 --> 00:03:02,890
Well, just like in
dense mode, as soon

64
00:03:02,890 --> 00:03:07,390
as this traffic shows up,
router 1 does the RPF check.

65
00:03:07,390 --> 00:03:12,400
It passes, and it
creates an S,G entry.

66
00:03:12,400 --> 00:03:17,080
This can create an S,G entry
because it saw the packet.

67
00:03:17,080 --> 00:03:19,820
And it knows where
the source is.

68
00:03:19,820 --> 00:03:22,780
But now, we have
a new job that's

69
00:03:22,780 --> 00:03:26,050
the responsibility of
the first hop router.

70
00:03:26,050 --> 00:03:29,980
Remember in this example that
router 1 is the first hop

71
00:03:29,980 --> 00:03:33,770
router, simply meaning
it's closest to the source.

72
00:03:33,770 --> 00:03:38,410
What this job is is now
that it knows an S,G,

73
00:03:38,410 --> 00:03:44,080
it sends what's called a PIM
register message to router 2.

74
00:03:44,080 --> 00:03:48,880
Now just to be clear,
this PIM register message

75
00:03:48,880 --> 00:03:52,150
is simply this
multicast packet that

76
00:03:52,150 --> 00:03:57,250
arrived on router 1 being
encapsulated into unicast

77
00:03:57,250 --> 00:03:59,680
and sent to router 2.

78
00:03:59,680 --> 00:04:02,080
This is called a PIM
register message.

79
00:04:02,080 --> 00:04:05,590
And it uses a PIM
register tunnel.

80
00:04:05,590 --> 00:04:09,790
This tunnel is used
simply in case--

81
00:04:09,790 --> 00:04:12,670
and, of course, it's not
the case in our diagram

82
00:04:12,670 --> 00:04:15,490
but just in case there
were other routers

83
00:04:15,490 --> 00:04:19,329
in the path between
router 1 and router 2 that

84
00:04:19,329 --> 00:04:22,300
don't know anything
about this multicast yet.

85
00:04:22,300 --> 00:04:27,490
They can, of course, forward
unicast to the RP address

86
00:04:27,490 --> 00:04:29,950
100.1.1.1.

87
00:04:29,950 --> 00:04:32,455
This address has
to be in the IGP.

88
00:04:32,455 --> 00:04:34,280
And it has to be reachable.

89
00:04:34,280 --> 00:04:37,240
So these routers in the
middle could forward

90
00:04:37,240 --> 00:04:39,310
the unicast, no problem.

91
00:04:39,310 --> 00:04:44,340
That's why the register message
is send unicast to the RP.

92
00:04:44,340 --> 00:04:48,360
Now just like on router 1, as
soon as this register message

93
00:04:48,360 --> 00:04:52,380
shows up, router 2
de-encapsulates it

94
00:04:52,380 --> 00:04:57,030
and discovers the
S,G. So once again,

95
00:04:57,030 --> 00:05:02,430
the RP is going to get an
S,G entry, so far so good.

96
00:05:02,430 --> 00:05:06,720
Now as long as this
source continues to send,

97
00:05:06,720 --> 00:05:10,020
we will continue to send
these register messages.

98
00:05:10,020 --> 00:05:14,010
As of right now,
router 2 does not

99
00:05:14,010 --> 00:05:18,160
have any clients or
downstream routers.

100
00:05:18,160 --> 00:05:22,650
And as such, this traffic
is going to go nowhere.

101
00:05:22,650 --> 00:05:27,192
Again, it will occasionally send
a register message to the RP.

102
00:05:27,192 --> 00:05:33,580
The RP will actually reply
with a register stop message.

103
00:05:33,580 --> 00:05:37,770
And again, periodically, this
will be redone just to keep

104
00:05:37,770 --> 00:05:41,280
the S,G entry on router 2 fresh.

105
00:05:41,280 --> 00:05:43,440
So it doesn't time out.

106
00:05:43,440 --> 00:05:49,690
But all of this is just to let
the RP know where the S,G is

107
00:05:49,690 --> 00:05:52,190
in case a client comes along.

108
00:05:52,190 --> 00:05:56,590
So if there were no clients,
this discussion would be over.

109
00:05:56,590 --> 00:05:59,240
But of course,
there are clients.

110
00:05:59,240 --> 00:06:02,690
So let's go down and talk
about the client side now.

111
00:06:02,690 --> 00:06:07,150
So let's say that our
client here off of router 4

112
00:06:07,150 --> 00:06:12,070
sends an IGMP report
message to router 4 asking

113
00:06:12,070 --> 00:06:16,270
for this group, 224.1.1.1.

114
00:06:16,270 --> 00:06:19,850
Well, router 4 doesn't
know where that is.

115
00:06:19,850 --> 00:06:23,200
So what we're going to do is
use this thing called the shared

116
00:06:23,200 --> 00:06:26,350
tree because, again,
everybody knows

117
00:06:26,350 --> 00:06:28,250
where the rendezvous point is.

118
00:06:28,250 --> 00:06:30,010
So what router 4
is going to do is

119
00:06:30,010 --> 00:06:33,490
use the RPF for the
shared tree, which

120
00:06:33,490 --> 00:06:35,500
is this interface right here.

121
00:06:35,500 --> 00:06:42,250
And it's going to send a PIM
join message up to router 2.

122
00:06:42,250 --> 00:06:45,730
It sends it to router 2
because that's all it knows.

123
00:06:45,730 --> 00:06:49,420
Now as soon as router 2
gets this join message,

124
00:06:49,420 --> 00:06:52,150
what it's going to do
is it's going to add

125
00:06:52,150 --> 00:06:55,420
this interface to its OIL.

126
00:06:55,420 --> 00:06:58,330
Once that interface
is on the OIL,

127
00:06:58,330 --> 00:07:03,250
the de-capsulated multicast
from the register message

128
00:07:03,250 --> 00:07:06,820
is going to be sent
down to router 4.

129
00:07:06,820 --> 00:07:09,940
This is going to be coming
down the shared tree.

130
00:07:09,940 --> 00:07:15,760
Therefore, it passes the RPF
check for the shared tree.

131
00:07:15,760 --> 00:07:17,210
And we didn't mention this.

132
00:07:17,210 --> 00:07:20,590
But as soon as we get
the IGMP report message,

133
00:07:20,590 --> 00:07:24,620
router 4 would have added this
interface to its oil as well.

134
00:07:24,620 --> 00:07:29,390
And therefore, router 4 forwards
the traffic down to the client.

135
00:07:29,390 --> 00:07:33,280
Now notice how none of this has
affected routers 3 or 5 yet.

136
00:07:33,280 --> 00:07:35,410
Nobody has this traffic.

137
00:07:35,410 --> 00:07:38,870
Those clients haven't
actually requested it yet.

138
00:07:38,870 --> 00:07:41,410
So we can see that
this is only affecting

139
00:07:41,410 --> 00:07:43,910
the routers that are necessary.

140
00:07:43,910 --> 00:07:46,750
Now, of course, once
this traffic shows up,

141
00:07:46,750 --> 00:07:51,730
router 4 has now also
learned the S,G entry.

142
00:07:51,730 --> 00:07:54,790
Now the next two
things are going

143
00:07:54,790 --> 00:07:57,010
to happen at the same time.

144
00:07:57,010 --> 00:08:00,518
That said, we can't exactly talk
about them at the same time.

145
00:08:00,518 --> 00:08:02,560
So we're going to have to
go one after the other.

146
00:08:02,560 --> 00:08:05,870
But be aware that these
two things happen together.

147
00:08:05,870 --> 00:08:11,140
Now that router 2 actually
has an interface on its OIL

148
00:08:11,140 --> 00:08:17,020
because it's forwarding to
router 4, it realizes, well,

149
00:08:17,020 --> 00:08:18,740
I have a client now.

150
00:08:18,740 --> 00:08:23,590
So I don't want to keep getting
these messages through unicast,

151
00:08:23,590 --> 00:08:25,300
through the register message.

152
00:08:25,300 --> 00:08:27,670
Because this is supposed
to be multicast.

153
00:08:27,670 --> 00:08:30,370
It's not supposed to be
partially unicast and then

154
00:08:30,370 --> 00:08:31,780
the rest multicast.

155
00:08:31,780 --> 00:08:34,400
It's supposed to
be all multicast.

156
00:08:34,400 --> 00:08:37,419
So essentially router
2 says, OK, we're

157
00:08:37,419 --> 00:08:38,530
really going to do this.

158
00:08:38,530 --> 00:08:40,330
I've got clients now.

159
00:08:40,330 --> 00:08:44,590
So what it does, it
sends a PIM join message

160
00:08:44,590 --> 00:08:48,490
to router 1 to
actually form a tree.

161
00:08:48,490 --> 00:08:51,400
Well, once it gets
that, router 1

162
00:08:51,400 --> 00:08:56,680
is going to add this interface
to its OIL for this traffic.

163
00:08:56,680 --> 00:08:58,990
As soon as it does
that, it's going

164
00:08:58,990 --> 00:09:02,680
to start forwarding the
multicast to router 2.

165
00:09:02,680 --> 00:09:07,480
As soon as router 2
receives the multicast,

166
00:09:07,480 --> 00:09:11,020
it's then going to
send a register stop

167
00:09:11,020 --> 00:09:17,080
message to router 1 to tell it
to stop sending the unicast.

168
00:09:17,080 --> 00:09:19,390
And at that point,
all of this is

169
00:09:19,390 --> 00:09:22,790
going to stop, so far so good.

170
00:09:22,790 --> 00:09:26,170
However, there's another thing
that happens at the same time

171
00:09:26,170 --> 00:09:29,410
that I mentioned, which is
something called the SPT

172
00:09:29,410 --> 00:09:30,490
switch over.

173
00:09:30,490 --> 00:09:34,150
And this is shortest path tree.

174
00:09:34,150 --> 00:09:38,890
Router 4 is going to initiate
an SPT switch over as soon as it

175
00:09:38,890 --> 00:09:43,840
gets the first packet and
generates this S,G entry.

176
00:09:43,840 --> 00:09:46,900
Router 4, now that
it knows the source,

177
00:09:46,900 --> 00:09:51,850
is going to send a join
message towards the source.

178
00:09:51,850 --> 00:09:56,750
That's going to be out the
RPF interface for the source,

179
00:09:56,750 --> 00:10:02,098
meaning that join is going
to go this way to router 1.

180
00:10:02,098 --> 00:10:05,230
Router 1 gets this join
message and just like it

181
00:10:05,230 --> 00:10:09,220
did for router 2, it's now
going to add this interface

182
00:10:09,220 --> 00:10:10,630
to the OIL.

183
00:10:10,630 --> 00:10:13,570
Once that interface
is on the oil then,

184
00:10:13,570 --> 00:10:18,730
of course, the multicast starts
going this way to router 4.

185
00:10:18,730 --> 00:10:21,430
This is done because
it's more efficient.

186
00:10:21,430 --> 00:10:25,330
If we look at this router
2, the rendezvous point

187
00:10:25,330 --> 00:10:28,630
should not really be
in this data path.

188
00:10:28,630 --> 00:10:29,830
Can it be?

189
00:10:29,830 --> 00:10:30,670
Yes.

190
00:10:30,670 --> 00:10:32,440
Is it the most efficient?

191
00:10:32,440 --> 00:10:33,460
No.

192
00:10:33,460 --> 00:10:38,120
So the SPT switch over is done
so that our traffic follows

193
00:10:38,120 --> 00:10:40,140
the most efficient path.

194
00:10:40,140 --> 00:10:43,290
So here's the follow
up to all of this.

195
00:10:43,290 --> 00:10:46,130
So as we mentioned, the tree
to router 2 and the tree

196
00:10:46,130 --> 00:10:49,320
to router 4 are built
at the same time.

197
00:10:49,320 --> 00:10:52,580
But as soon as router 4
starts getting the traffic

198
00:10:52,580 --> 00:10:57,510
on the S,G-RPF
interface, guess what?

199
00:10:57,510 --> 00:11:00,690
It doesn't need the traffic
from router 2 anymore.

200
00:11:00,690 --> 00:11:03,410
So it sends a prune.

201
00:11:03,410 --> 00:11:07,040
As soon as this prune
message hits router 2,

202
00:11:07,040 --> 00:11:08,450
router 2 says, OK.

203
00:11:08,450 --> 00:11:10,520
And it removes the
interface from its OIL,

204
00:11:10,520 --> 00:11:12,950
stops sending the multicast.

205
00:11:12,950 --> 00:11:14,630
And, of course,
that pruned message

206
00:11:14,630 --> 00:11:16,504
only has to be sent once.

207
00:11:16,504 --> 00:11:22,310
Once that's done, guess what
router 2 doesn't have anymore?

208
00:11:22,310 --> 00:11:25,500
Router 2 no longer
has any clients.

209
00:11:25,500 --> 00:11:28,400
So it doesn't need
the multicast tree

210
00:11:28,400 --> 00:11:30,930
from router 1 anymore either.

211
00:11:30,930 --> 00:11:32,150
So what does it do?

212
00:11:32,150 --> 00:11:35,050
It also sends a prune.

213
00:11:35,050 --> 00:11:38,470
Router 1 removes that
interface from its oil,

214
00:11:38,470 --> 00:11:40,630
stops sending the multicast.

215
00:11:40,630 --> 00:11:44,710
And router 2 is now
out of the data path.

216
00:11:44,710 --> 00:11:49,900
But router 2 still has the
S,G. So understand that as soon

217
00:11:49,900 --> 00:11:52,490
as another client comes online--

218
00:11:52,490 --> 00:11:56,050
so this client off of
router 3 makes a request,

219
00:11:56,050 --> 00:11:59,200
router 3 is going to go
through the same process.

220
00:11:59,200 --> 00:12:03,910
It sends a star comma
G join up to router 2.

221
00:12:03,910 --> 00:12:07,540
Router 2 adds the
interface to its OIL,

222
00:12:07,540 --> 00:12:10,270
begins sending the
multicast down to router

223
00:12:10,270 --> 00:12:14,110
3 who, of course, added
this interface to its OIL,

224
00:12:14,110 --> 00:12:17,440
forwards the multicast
down to this client.

225
00:12:17,440 --> 00:12:20,500
Now we don't have to talk
about all of it again.

226
00:12:20,500 --> 00:12:23,920
Yes, the rendezvous point still
would have built its tree.

227
00:12:23,920 --> 00:12:25,720
All that other stuff
would have happened.

228
00:12:25,720 --> 00:12:27,550
But we'll skip that part.

229
00:12:27,550 --> 00:12:29,300
I think we get the idea.

230
00:12:29,300 --> 00:12:33,130
But once again, as soon as
router 3 gets this traffic,

231
00:12:33,130 --> 00:12:36,650
it again, gets the S,G.

232
00:12:36,650 --> 00:12:41,150
As soon as it gets the S,G, it
looks at its best path to get

233
00:12:41,150 --> 00:12:44,990
to the source, realizes that
it's directly to router 1 out

234
00:12:44,990 --> 00:12:46,820
that RPF interface.

235
00:12:46,820 --> 00:12:49,970
Because that's the
RPF for the S,G,

236
00:12:49,970 --> 00:12:52,355
sends the join to router 1.

237
00:12:52,355 --> 00:12:56,010
Router 1, of course, adds
this interface to its OIL

238
00:12:56,010 --> 00:12:59,901
and start sending the
multicast down to router 3.

239
00:12:59,901 --> 00:13:05,100
Router 3, once again, prunes the
traffic coming from router 2.

240
00:13:05,100 --> 00:13:08,460
Router 2, again, removes
this from the oil and tears

241
00:13:08,460 --> 00:13:11,820
down the tree that, again,
it would have just built.

242
00:13:11,820 --> 00:13:16,440
But the point in all of this,
remember PIM's two jobs;

243
00:13:16,440 --> 00:13:19,470
find the source, build the tree.

244
00:13:19,470 --> 00:13:23,130
Finding the source is done
by building the shared

245
00:13:23,130 --> 00:13:24,910
tree to the rendezvous point.

246
00:13:24,910 --> 00:13:27,330
The rendezvous point
forwards the traffic

247
00:13:27,330 --> 00:13:28,860
down the shared tree.

248
00:13:28,860 --> 00:13:33,360
The end routers or the last
hop routers get the traffic,

249
00:13:33,360 --> 00:13:38,670
learn the S,G, and then
initiate an SPT switchover.

250
00:13:38,670 --> 00:13:43,470
Now just for the record, the
SPT switchover can be disabled.

251
00:13:43,470 --> 00:13:46,080
You don't have to do
the SPT switchover.

252
00:13:46,080 --> 00:13:48,990
But it is enabled by
default on Cisco routers.

253
00:13:48,990 --> 00:13:52,620
And it will do this as soon as
it receives the first multicast

254
00:13:52,620 --> 00:13:53,730
packet.

255
00:13:53,730 --> 00:13:57,640
And just one final takeaway
just so we're very clear,

256
00:13:57,640 --> 00:14:03,070
the RPF check to the address
of the rendezvous point is used

257
00:14:03,070 --> 00:14:06,050
for the star comma
G. And, of course,

258
00:14:06,050 --> 00:14:11,200
the RPF check to the source is
used once we know the source

259
00:14:11,200 --> 00:14:13,300
and we have the S,G.

260
00:14:13,300 --> 00:14:16,420
So these could possibly be
two different interfaces.

261
00:14:16,420 --> 00:14:19,180
If we look at
routers 3 and 4, they

262
00:14:19,180 --> 00:14:20,980
are two different interfaces.

263
00:14:20,980 --> 00:14:23,620
Of course, in the
situation of router 5,

264
00:14:23,620 --> 00:14:25,660
those would be the
same interfaces

265
00:14:25,660 --> 00:14:29,890
because it only has one tie-in
to the multicast environment.

266
00:14:29,890 --> 00:14:33,970
But overall, this is how
PIM sparse mode operates

267
00:14:33,970 --> 00:14:36,770
in our multicast environment.

268
00:14:36,770 --> 00:14:41,410
So in this video, we evaluated
sparse mode operation

269
00:14:41,410 --> 00:14:42,650
in our environment.

270
00:14:42,650 --> 00:14:47,830
And as we can see, this is very,
very different from dense mode.

271
00:14:47,830 --> 00:14:51,820
By using a rendezvous
point and the shared tree,

272
00:14:51,820 --> 00:14:55,750
the main goal here is notice
that, for example, router 5,

273
00:14:55,750 --> 00:14:58,940
since its client never
actually came online,

274
00:14:58,940 --> 00:15:01,555
it never learned the S,G entry.

275
00:15:01,555 --> 00:15:02,680
It doesn't have to know it.

276
00:15:02,680 --> 00:15:03,890
There's no need.

277
00:15:03,890 --> 00:15:07,090
So we're not forwarding
traffic everywhere

278
00:15:07,090 --> 00:15:08,860
like we did in dense mode.

279
00:15:08,860 --> 00:15:12,430
We're only forwarding it to
the devices that request it.

280
00:15:12,430 --> 00:15:16,090
Now going through this whole
process, you may look at it

281
00:15:16,090 --> 00:15:20,410
and say, well, that whole
initial setup, going to the RP

282
00:15:20,410 --> 00:15:23,110
and then switching over with
the SPT switch over and all

283
00:15:23,110 --> 00:15:26,290
that, that seemed like maybe
it was a little inefficient.

284
00:15:26,290 --> 00:15:29,230
Well, arguably, you
could make that there's

285
00:15:29,230 --> 00:15:32,140
a bunch of moving parts there
with the register messages

286
00:15:32,140 --> 00:15:33,910
and the register stop messages.

287
00:15:33,910 --> 00:15:36,100
But at the end of the
day, even though there's

288
00:15:36,100 --> 00:15:39,260
a little bit of
multiple steps, we'll

289
00:15:39,260 --> 00:15:42,890
say, for the setup of
this tree, ultimately

290
00:15:42,890 --> 00:15:45,890
it's going to be more efficient
than dense mode in most

291
00:15:45,890 --> 00:15:46,980
environments.

292
00:15:46,980 --> 00:15:49,700
So that pretty much
sums up everything we

293
00:15:49,700 --> 00:15:52,250
need to discuss in this skill.

294
00:15:52,250 --> 00:15:56,870
That said, we just have a
review in the form of a quiz.

295
00:15:56,870 --> 00:15:58,860
And that's what we're
going to do next.

296
00:15:58,860 --> 00:16:02,300
Until then, I hope this has
been informative for you.

297
00:16:02,300 --> 00:16:05,410
And I'd like to thank
you for viewing.

298
00:16:05,410 --> 00:16:09,000