►
From YouTube: Community Stream #13: Categorization of Automation Tasks
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
Did
I
ate
a
lot
of
food
I
drink?
A
lot
of
beer
I
went
saw
this
comedy
folk
singer
guy
that
was
actually
very
humorous
outside
we
have.
My
town
is
right
on
Lake,
Michigan,
Lake,
Michigan
and
there's
different
pubs
and
bars
that
are
sort
of
like
right
on
the
lake,
and
one
of
them
had
this.
This
live
band
that
was
playing
was,
it
was
very
entertaining,
was
fun.
B
Yeah
we
we
went
to
there's
a
there's,
a
Science
Center
here
in
Portland
that
I've
been
meaning
to
go
to
our
since
we
moved
here.
Just
never
I,
don't
know
for
4
years,
never
never
know
just
never
met
it
called
OMSI.
It
turns
out
it's
a
little
more
kids
focus
than
I
expected
growing
up
in
the
Midwest
we
have
like
cosig
out
there,
like
you
know,
highly,
probably
have
something
near
you
like
that
I
mean
kosai
is
like
all
over
the
eastern
half
the
United
States
by
now,
so
I
think
I'm.
Not
sure
about
that.
A
B
I
believe
it's
like
a
trial
almost
like
at
ragging.
There
are
some
permanent
locations,
but
I
think
it
also
travels
any
way.
I
expected
it
to
be
kind
of
like
that,
and
it
wasn't
it
was.
It
was
a
lot
more
kids
focused.
There
were
definitely
non
kids
portions,
but
the
it
was
mostly
kids.
Anyway,
we
stopped
by
The
Gift
Show.
We
so
we
went
to
the
observatory.
A
B
B
B
And
I
don't
know
this
about
me,
but
I
actually
have
like
80
hours
in
the
cockpit,
but
it
was
all
when
I
was
like
16
or
17,
so
I,
more
or
less
know
what
I'm
doing
like
conceptually
I
just
am
obviously
very
way
out
of
practice,
and
also
those
hours
are
like
beyond
not
good.
So
it
doesn't
only
matter
that
I
have
that
many
hours,
because
we
have
to
do
everything
all
over
again
anyway,
but
I
do
have
the
advantage
of
knowing
that
I
like
flying.
A
Yeah,
you
should
definitely
you
should
definitely
do
that.
That's
pretty
cool,
that's
something!
I've
always
wanted
to
do,
and
I
I'm,
probably
not
that's.
Probably
a
thing
I
won't
do
on
the
list
of
all
the
things.
I
could
do
it
so
I'm
always
like
really
I,
don't
know,
I'm
always
a
little
bit
jealous,
but
also
like
man.
You
should
totally
go
to
that.
That
would
be
awesome
and
take
videos
and
share
because
it's
got
a
they.
Have
you
one
of
the
greatest
feelings
in
the
world.
B
So
you
should
not
be
repeating
anything
if
you're
gonna
go
for
it,
go
for
it
like
within
a
few
weeks
and
get
it
done,
and
that's
not
what
we
did
when
I
was
a
kid
we
we
went
very
intermittently,
so
you
don't
need
eighty
hours.
You
need
way
less
than
that,
but
because
most
of
it
was
real,
we
had
to
repeat
a
lot
of
stuff.
A
Alright
wait.
Actually
we
have
some
viewers,
so
we
should
probably
start
start
the
conversation
we're
gonna
have
yeah
yeah
I,
don't
know
how
long
this
will
go
this
this
particular
session.
I,
don't
I,
don't
know
if
it
needs
to
go
all
hour,
but
I
don't
know
this.
Let's
see
what
happens.
Let's
see
if
people
got
questions
and
chat,
you
know
during
the
conversation
but
welcome
to
the
stream
everyone.
This
is
the
energy
labs,
I
think
episode,
13
or
14
livestream.
A
Okay,
so
we're
live
stream
number
13
I
am
I,
am
Jeric
winkworth,
otherwise
known
as
at
cloud
toad
on
twitter,
CL,
o
UD
TOA
d,
and
this
is
my
co-host
matt
Oswalt
known
as
mere
Dhin
at
m
IE
r
di
n
on
twitter.
So
you
know
please
follow
us.
There
also
follow
the
official
Energy
labs.
Twitter
crowd,
add
energy
labs.
A
A
B
A
A
A
A
We
should
definitely
have
this
conversation
and
we-
and
you
know
we
will
freeform
it
here
and
we'll
see
what
comes
of
it,
because
I
think
this
could
be
a
whole
series
of
blogs.
Actually,
this
topic.
Well,
you
know
given
specific
examples
and
things
like
that,
and
you
know
one
of
the
things
I
was
thinking
about
when
you
know
how
I
would
explain
this
is
you
know,
look
at
the
categories
that
are
on
the
nrla
website.
We
have,
we
have
fundamentals,
we
have
tools
and
we
have
workflows
and
I.
A
A
You
know
specification,
I'm
sure
it
exists
right.
You
don't
have
to
know
all
those
things
in
in
excruciating
detail,
but
you
should
know
the
fundamentals
and
and
the
basics
like
the
key
ideas.
You
know
you
know
that
go
into
each
of
those
things
and
then
you
take
those
fundamentals
and-
and
you
have
a
given
set
of
tools
in
your
work
in
your
environment,
in
your
production
environment,
at
work
or
in
a
lab
environment.
A
The
network
is
I
was,
and
you
can
interrupt
me
at
any
time
because
I'm
just
gonna
rant
if
you
have
a
thought,
but
the
network
is
kind
of
already
automated.
We
have
dynamic
routing
protocols,
for
instance,
everything
is
dynamic
right
like
when,
if
you
well,
presumably
this
assuming
there's
no
bugs
when
you
do,
you
know
bonded
Ethernet
and
a
link
goes
down.
Then
it's
taken
out
of
the
you
know,
out
of
the
hashing
algorithm
for
for
distribution
of
flows
across
the
remaining
links
and
then
when
it
comes
back
up,
it's
automatically
added.
A
If
with
V
RRP
right
when
the
primary
or
master
or
whatever
it's
called
goes
down,
the
secondary
will
detect
that
and
automatic.
You
know
some
amount
of
time
automatically
come
up
and
we
have
all
kinds
of
things
like
that
PFD
you
know
and
then
of
course,
all-around
BGP.
You
know
most
PF
and
all
that
stuff
which
will
automatically
automatically
route
around
failures
and
stuff
like
that
fast
reroute
will
do
then
so
a
lot.
B
I
mean
the
important
thing
to
call
out
is,
like
everybody
assumes
that,
because
you
have
a
controller
now
you're
at
the
next
stage
of
things,
but
guess,
but
but
Sdn
controllers
have
the
same
paradigms:
they're
just
a
little
more
complicated
and
used
like
new
terminology,
but
they
have
the
same
kind
of
mechanisms
built
in
you
know
like
they.
They
know
to
look
for
certain
criteria
on
edge
devices
and
respond
accordingly,
just
like
any
other
routing
protocol
would
like
where
it
says.
Ok,
I've
received
a
message
from
a
peer
I
need
to
update
this
table.
B
Same
thing
happens
with
an
SDN
controller.
It's
just
the
the
difference
is
in
its
implementation.
Yeah
it
no
matter
what
it
doesn't
really
matter
from
a
technical
perspective.
Those
technologies
are
built
within.
This
is
the
important
thing
within
their
domain
to
do
the
things
they
need
to
do
to
work,
so
this
isn't
about
filling
in
any
sort
of
like
technical
gaps
within
one
of
those
domains.
The
question
I
think
that
people
need
to
ask
themselves
are
ok,
you
know
everything.
Every
time
you
interact
with
any
network
device
or
controller,
the
the
broader
task
at
hand.
B
Does
that
start
and
end
all
within
the
controller
like?
Do
you
get
instructions
from
the
Sdn
controller
to
make
a
change?
And
then
the
SDN
controller
emails
you
and
says
I
need
to
make
this
change
and,
oh
by
the
way
you
need
to
update
this
other
table
within
the
Sdn
controller?
No,
you
might
do
like
one
or
two
tasks
of
that
workflow
within
the
controller
or
within
you
know,
a
specific
router
or
switch
but
you're
the
source
of
that
of
that
workflow.
The
thing
that,
where
you're
we're
not
even.
B
It's
always
it's,
not
it's,
not
in
Schad
domain,
which
is
what
I
would
consider
like.
A
routing
protocol
with
you
yeah
but
like,
but
like
it's
actually
inter
domain
things
that,
like
outside
of
the
bounded
context
of
a
product,
things
that
no
one
product
ever
will
frankly
solve,
and
it's
our
job.
That's
why
we're
engineers
we're
it's
our
job
to
solve
those
those
problems
outside
of
those
products
which
we've
done
for
a
long
time.
We
just
need
to
do
it
in
a
different
way.
Yeah.
A
When
we
talk
about
stuff,
we
always
say
servers
and
whatever
laptops
and
tablets
or
phones
and
things
that
people
actually
you
know
things
that
run
actual
applications,
that
people
would
would
recognize
anywhere
in
the
business
and
things
that
people
interact
with
when
they're,
when
they're
doing
stuff
on
the
network
or
on
the
Internet.
But
it's
really
it's
it's
everything
around
their
rights.
There's
like
storage
rays
and
there's
kubernetes
clusters
and
VMware
clusters
and
there's
you
know,
firewalls
and
IPS,
is
and
voice
over
IP
systems.
A
There's
like
there's,
there's
so
many
things
that
are
around
the
edges
there
and
when
you're,
any
kind
of
workflow
that
you
want
to
do.
You
know
if,
in
order
to
be
complete,
will
probably
start
or
end
with
one
of
those
systems
around
the
network
and
that
doesn't
include
you
know
a
whole.
Second,
set
of
systems,
which
is
all
this
sort
of
management
domain
stuff
that
you
have
to
interact
with
so
like
I,
said,
like
log
servers
and
ticketing
systems
and
that
kind
of
thing
right.
A
network.
B
Like
you
might,
you
might
need
to
start
your
workflow
just
by
learning
how
to
parse
a
CSV
file
with
Python?
We
talked
about
Interop
with
Jeremy
Shulman.
He
brought
that
up.
We,
we
were
actually
helped
kickstart,
a
little
bit
of
a
debate
where
we
talked
about
I.
Think
I
mentioned
this
on
the
stream
where
we
talked
about
Interop.
B
B
The
problem
is
it's
it's
it's
hard
to
it's
hard
to
say
like
what
everyone's
first
step
will
be,
so
I
think
that
the
change
in
in
mentality
has
to
be
one
of
kind
of
like
how
the
example
I
like
to
give
in
this
case
is
like
when
you're
learning,
how
to
you
know
be
a
painter.
For
instance,
do
you
go
to
a
bunch
of
museums
and
like
memorize,
how
they're
painted
so
that
you
can
like
perfectly
replicate
them?
Pixel
perfect,
like
no,
you
might
go
there
for
inspiration,
certainly
and
you'll,
know.
B
B
The
point
is
to
understand
the
fundamentals
and
build
a
repertoire
of
seemingly
seemingly
in
applicable
skills
for
later,
basically
like
you're
building
this
repertoire
of
fundamental
skills
that
that
you,
you
know
you
you
sort
of
put
on
the
back
burner
until
you
need
them,
but
then,
when
you
need
them,
you
have
them
and
and
and
I
think
people
expect
that
you
know
from
day
one.
You
should
be
able
to
paint
the
Mona
Lisa,
but
that's
just
not
the
case.
B
It's
it's
I
think
it's
very
important
to
look
at
the
the
breadth
of
what
people
are
doing.
Part
of
what
we've
done
with
NRI
Labs
is
help
help
get
the
word
out
about
what
people
are
doing
so
you
go
there
and
you
say:
oh
cool
people
are
building
things
in
this
way,
use
that
for
inspiration,
but
when
it
comes
to
actually
building
the
skills
yourself
focus
on
those
fundamentals
is
easily
the
best
way
to
ensure
that
you're
gonna
have
success,
because
then
you're
gonna
be
able
to
build
your
own
solution
and
that's
that's.
B
A
And
and
without
some
grasp
of
what
can
be
automated
it
that
tends
to
escalate
very
quickly
in
people's
minds
to
you
know
these
aspirations
of
building,
something
like
you
know,
networked
Skynet
and
that
which
always
fails
right
so
and
then
you're
it's
it's
really
from
for
me,
I,
like
the
approach
that
we
have
because
it's
you
know,
opera
operationally
rooted
right.
We
both
come
from
operations,
kind
of
backgrounds,
and
for
me,
it's
much
more
about
you
know
doing
that.
A
End-To-End
workflow,
like
hey,
I'm
gonna,
you
know
I
have
a
spreadsheet
as
some
things
that
need
to
change
or
some
information
that
has
to
be
collected
and
then,
when
it's
done,
collecting
I
needed
to
have
it
posted
the
results
posted
you
know
in
slack
or
in
a
ticket
or
in
a
Google,
Doc
right
and,
and
you
know,
and
then
shared
with
everyone
or
whatever,
and
that
you
know
that's
the
kind
of
workflow
data
that
I
have
in
mind
when
I
think
about
Network
automation.
Not
these!
A
If
those
some
of
the
things
that
people
say
could
be
built,
they
would
be
built
and
successful,
but
you
know
there's
there's
a
reason
why
there
isn't
a
controller
that
just
you
know
completely
and
totally
automates
everything
in
your
network.
It's
it's
lots
of
people
have
tried
and
failed.
It's
not
gonna
happen.
At
least
you
know,
maybe
maybe
it
will
but
I,
don't
think
anytime
in
the
next
ten
years.
Even
it's
gonna
happen.
Yeah.
B
A
Yeah
I,
so
let's
talk
a
little
bit
about
some
examples
right,
like
one
of
the
my
if
I
had
to
think
about
what
I
actually
spent
most
of
my
time
doing
when
I
was
running,
production
networks
or
I
worked
in
managed
services
for
a
long
time
when
I
was
when
I
was
doing
work
in
those
shops.
What
was
I
as
a
network
engineer
like
if
I
were
to
time
myself
and
then
categorize
my
activities?
You
know
configuring
configuration
was
actually
was
a
tiny
sliver
of
my
time.
Like
you
just
said
it
was
like.
A
Maybe
it
was
during
a
change
window
right,
sometimes
you
know
I
what
ever
you
update
a
banner
or
you.
You
know
log
in
banner
or
something
like
that
interface
descriptions.
You
know
things
like
that.
You
could,
but
even
even
when
you
add
that
outside
of
that
change
window,
we're
talking
about
you
know
very
very
little
amount
of
time
you
spend
actually
in
the
act
of
configuring
and
even
leading
up
to
that
configuration
change.
A
And
then,
after
the
configuration
change
it,
you
collect
information
right
and
you
put
it
together
and
you
format
it
so
that
it
you
can
status
on
it
or
you
can.
You
know
surmised.
You
know
the
state
of
the
network,
you
know
in
a
way
that
captures
whether
or
not
that
change
was
successful,
and
so,
when
I
wasn't
collecting
information
for
the
purpose
of
making
changes.
B
This
is
also
kind
of
humorous
because
you
know
those
have
come
some
of
the
hyper
skill
like
network
operations,
people
like
Google
Facebook
kind
of
folks
like
that
and
the
that
percentage
is
not
different.
There,
like
everybody,
assumes
that,
because
it's
Google
and
Facebook
that
they
just
all
to
change
their
network
all
the
time
and
because
their
networks
are
like
massive,
like
sure
the
number
of
changes
that
they
have
if
you're
bounding
it
my
life,
you
know
you
know
changes
per
week
like
it's
gonna,
be
harder
than
like.
B
So
don't
you
know,
don't
get
wrapped
up
on
this
like
well,
you
know,
because
of
my
scale,
I
don't
make
a
lot
of
changes.
It's
like
hyper
scale
is:
don't
change
a
lot
either
they
they're
they're,
pretty
simple,
and
then
they
try
to
make
things
as
cookie
cutter
as
possible
when
they
do
make
changes
it's
for
like
basic
policy
stuff.
It's
not
like
I'm
gonna
change,
like
all
of
my
switches.
Now
like
this
yeah.
That's
it's
just
not
it's
not
a
realistic
thing
to
expect.
B
I
think
it's
funny
I
most
of
the
folks
that
are
listening,
probably
kind
of
implicitly
already
know
this,
and
in
fact,
most
of
the
people
that
need
to
learn.
This
lesson
probably
are
like
on
the
vendor
side,
because
they
are
these
this.
This
idea
that
their
customers
do
nothing
but
configure
things
like
no
yeah.
A
That's
crazy
and
that's
that's
a
true
statement
like
they
when
they
imagine
what
the
user
does
with
this
product.
They
they
imagine
they're
just
furiously
adding
routes
and
fee
lands
and,
like
all
that
stuff,
right,
they're,
just
constantly
adding
you
know
to
the
config
or
removing
from
the
config
and
and
changing
the
way
the
network
behaves
and
that's
actually
that's.
That's
a
like
it's
a
tiny
percentage
of
the
time.
A
B
Just
talk
just
think
about
the
things
that
you
as
a
as
a
as
a
network
engineer,
do
in
the
course
of
a
week
and
then
and
then
consider.
Could
automation
help
me
with
whatever
that
task
is
doesn't
matter.
What
it
is
could
automate
should
help
me
with
that
task?
The
answer
is
almost
almost
always.
Yes,
the
the
question
then
becomes.
Is
it
worth
it
like?
Is
it
gonna
save
me
some
time
or
whatever?
B
What
is
the
value
of
that
which
that's
gonna
vary
wildly
based
on
the
task,
but
the
question
that
you
start
with
is
very
important
because
you're
not
you're,
not
framing
it
as
oh
I
need
to
automate
the
network
or
I'll
be
out
of
a
job
or
or
that's
just
the
thing
to
do
like
that's
not,
and
so
that's
that's
a
false
premise:
you're
starting
off
on
the
wrong
foot.
However,
if
you
start
off
on
the
foot
of
you
know,
I
have
the
current
way
of
doing
things.
B
Could
automation
augment
that
operational
model
of
things
that
I
actually
required
to
do
day
to
day?
The
answer
is
almost
always
yes,
and
then
you
just
have
to
go
figure
out
how
to
do
it,
how
to
apply
it
to
yourself,
which
then
I
think
goes
back
to
learning
the
fundamentals,
because
you'll
have
to
make
that
sort
of
application.
You
know
yourself,
like
you,
have
to
map
those
fundamental
skills
to
the
things
you
do
during
the
day,
but
I
think
it's
important
stuff
to
start
off
on
that
foot.
B
People
always
get
wrapped
around
the
idea
that
automation
is
all
about
just
like
controlling
their
switches
and
routers
or
like
or
like
the
hello
world
that
we
keep
either
explicitly
but
often
implicitly
telling
people
which
is
that,
like
your
first
step
of
network
automation,
is
to
is
to
make
it
so
that
no
one
logs
into
network
devices
and
all
changes
are
done
through
get
like
that's
step.
One
know
you
ever
get
that
done:
you're,
never
gonna
prove
first
off.
B
No
one
no
network
manager
I
ever
worked
for
would
be
on
board
with
that
as
a
first
step,
so
never
mind
the
political
aspect
of
this,
but
honestly,
that's
not
only
unrealistic
as
a
first
step,
but
it's
also
not
valuable
like
what
do
you
sit?
What
are
you
doing?
You
gotta
do
I
think
the
value
of
what
you
and
and
I
don't
think
the
value
proposition
is
quite
there
for
that
kind
of
stuff.
Yeah.
A
Yeah
I
think
you
know
the
the
kind
of
things
I
would
automate
if
I
was,
you
know,
let's
say:
I
left
and
I
started
working,
someplace
else
on
a
real
production
network.
Again
the
things
that
I
would
automate
our
anything.
That's
very
time-consuming
and
I
don't
mean
that,
like
you
know,
and
you
know,
in
order
to
go
faster
order,
ordered
you
know
to
get
more
work
done
in
less
time.
It's
it's
the
same
amount
of
work,
but
we're
spending
less
time
doing
it
and
spending
more
time.
A
You'd
have
to
log
in
to
multiple
devices.
You
know
to
see
what
the
state
is
and
to
validate
that
each
device.
You
know
it
has
the
right
view
of
the
world,
so
you
have
to
know
where
those
devices
are
in
the
first
place
and
then
you
have
to
with
that
information
you've
now
taken
from
multiple
devices,
you
have
to
assemble
that
into
an
easily
consumed
model.
A
You
know
if
you
have
a
bunch
of
different
burp
demeans,
because
people
do
have
they
run
verbal.
You
know
on
the
sand
on
trunks
or
on
VLANs
right.
You
could
have
hundreds
of
burp
domains
and
it'd
be
cool.
If
you
could
make
a
report,
you
know
what
is
what
is
the
state
of
verb
you
you
could
log
in
and
look
at
all
those
stats
for
every
VLAN
yourself
or
you
could
write
sort
of
the
logic
you
use
to
understand.
A
A
B
A
A
B
Like
the
Canadian
accent
for
American
years
anyway
is
very
like
proper.
They
pronounce
their
T's
very
intentionally
like
like
I,
would
say
about
yeah.
You
can't
like
don't
really
pronounce
the
T
at
the
end,
no
forgetting
that
they
say
like
a
boot
but
I'm
talking
about
the
T
portion
where
they're
like
where
they're
like
about,
and
they
like
very
intentionally,
say
the
T
at
the
end,
whereas
we
would
just
sort
of
say
like
about
no
I,
don't
say
it.
Yeah.
A
They're
actually
Wisconsin's
accent
it's
very
similar
to
Canadian
accent,
especially
as
you
go
north
of
where
I'm
at
so
I'm
kind
of
used
to
it
and
I,
don't
know.
I,
don't
plus
I
grew
up
in
the
Canadian
border,
so
I'm
I,
I,
guess
I
am
used
to
it.
I,
don't
I,
don't
really
notice.
I
love,
Canada
little
dude,
I
love
going
to
Toronto
anyways.
B
A
Fine
right
like
and
then
but
it
wasn't,
it
was
like
a
salad
monstrosity,
so
gross
yeah
go
to
my
Twitter
and
you
can
see
it's
disgusting.
They
was
like
crab
salad
and
it
was
like
nacho
cheese
on
it
or
Velveeta.
I,
don't
know
what
it
was.
It
was
I
couldn't
eat
it.
Yeah
I
got
about
halfway
through
and
I
gave
up
anyways,
so
that
verb
thing
is
like
it's.
So
that's
one
kind
of
workflow.
A
It's
very
time-consuming
it
to
collect
a
lot
of
information
for
a
lot
of
different
like
things
and
then
you
have
to
you
know
you
have
to
put
that
information
together,
just
to
make
sure
that
things
are
working
as
expected,
right,
yeah,
then
there's
so
that's
time
consuming
and
then
there's
what
I,
what
I
would
call
error-prone,
but
not
necessarily
high-risk,
workflows,
meaning
it's
you
might
like
put
a
VLAN
on
the
put
the
wrong
VLAN
on
a
port
or
you
know
that
doesn't
already
have
a
VLAN
configured.
Haven't
you
know
descriptions
like
you
put.
A
You
have
a
typo
in
a
description.
You
know
there's
there's
like
things
like
that,
where
they
can
or
you're
doing
many
of
the
same
changes
like
you're,
adding
your
this
VLAN
to
a
thousand
ports
or
now
a
thousand.
But
let's
say
well:
yeah
I
mean
yeah
act
on
that
before
I've
added
a
VLAN
to
a
thousand
ports
I.
Guess
it's
possible
right
or
different
VLANs
across
those
ports.
And
then
you
know
when
you
do
something
like
that
over
iteratively
over
and
over
it's
easy
to
make
mistakes
above
and
beyond.
B
That's
kind
of
where
the
source
of
truth
is
we're
like
here's,
here's
who
to
contact
and
like
here's,
the
contact,
email
address
and
all
kinds
of
things
like
that
and
and
yeah,
and
that
data
you
you'd,
be
surprised
how
easy
well,
you
wouldn't,
but
a
lot
of
people
might
be
surprised
just
how
easily
that
data
would
would
get
very
invalid
very
quickly.
So
you
really
got
to
stay
on
top.
Just
data
management
itself
is,
is
tough.
B
I
do
want
to
backtrack,
though
the
two
the
first
use
case
that
you
talked
about
with
the
whole
vrrp
mapping.
We
talked
a
lot
about
the
task
itself
and
like
what
might
be
useful
and
how
you
do
that.
But
but
you
also
have
to
take
a
step
back
and
think
about
why
you
would
want
to
do
that
like.
Why
would
you
want
to
get
a
get
a
sort
of
bird's
eye
view
of
the
state
of
even
just
one
protocol
like
vrrp
in
this
case?
B
B
In
fact,
I'm
thinking
about
I
think
I
might
need
to
write
some
additional
tests
for
that
in
the
lesson
that
we
have,
because,
unlike
BGP
a
lot
of
people
when
they
when
they
look
at
vrrp
neighbor
ships,
if
there's
a
if
there's
a,
if
there's
a
difference
there,
you
kind
of
have
to
go
looking
for
it
because
VRP
like
the
redundant
layer,
three
interfaces
kind
of
work
until
they
really
don't.
You
know
what
I
mean
like
you
could
have
so
many
like
soft
failures
all
over
the
place,
but
you'd
never
know
about
it.
B
A
good
example
is
like
neh
a
system
really,
this
isn't
even
just
networking
until
you
test
failover
like
you'll,
know
for
sure,
if
it's
actually
working-
and
this
is
a
really
good
way
of
knowing
like
how
many
unknowns
are
out
there
like
if
you,
if
your
VoIP
situation,
isn't
what
you
expect.
That's
that's
a
problem
because
then
you
don't
have
redundancy
at
all.
You
have
single
points
of
failure
anyway.
B
A
Is
you
know,
okay,
I'm
gonna
will
harp
a
little
bit
more
on
that
first
example.
There's
another
reason
why
youyou
kind
of
building
automation
for
that
purpose
like
collecting
and
correlating
information,
is
useful
for
the
purposes
of
completely
like
completeness,
so
it
could
be.
It
could
be
I've
made
this
kind
of
mistake
when
I
was
a
younger
network,
engineer
and
I've
seen
this
mistake
happen
so
many
times
people
think
you
know
they
have
a
basic
idea
of
how
something
like
verb
works,
right,
ERP
works
and
and
so
they
decide.
A
A
It's
been
stable
frame
and
that
what
they
don't
grasp
is
that
it's
possible
for
two
things:
to
think
that
their
master
at
the
same
time
and
or
two
actually
for
some
reason
end
up
not
having
the
same
timers
right
like
one
will
say:
I've
been
matched
for
24
hours,
but
the
another
one
would
say:
well,
I've
only
seen
him
as
a
master
for
12
hours,
right
and
and
unless
you're
collecting.
All
of
that
information
you
know
completely
and
then
specifically
looking
for
those
discrepancies.
A
It
can
be
very
easy
to
make
the
wrong
assumptions
or
to
look
over
those
things
and
and
to
miss
something
and,
and
so
writing
automation
for
the
further
it
can
can
help
you
be
more
thorough
and
and
more
accurate
when
you're,
when
you're
doing
those
when
you're
trying
to
figure
out.
What's
going
on
in
your
in
your
network
and.
B
That's
not
in
your
head,
like
that's,
that's
so
valuable
but,
like
I
said
no
one,
you
need
to
ask
anyone's
permission
to
do
that.
You're,
not
changing
anything
on
your
network,
so
it's
just
a
read-only
operation
so
like
that,
there's
no
risk
there.
It
or
it
automatically
immediately
provides
value
to
you,
because
you're
effectively,
sharing
through
an
executable
means
what
should
be
with
the
rest
of
your
team
and
so
now
everybody's
on
board
of,
like
oh
yeah
VR.
B
If
he
should
be
configured
this
way
and
we
we
should
be
running
this
on
all
of
our
devices
the
same
way
and
and
you
haven't
made
any
configuration
changes
yet
like
you
already
reaped
all
of
this
value
out
of
automation,
but
you
haven't
change
in
anything
and
and
so
when
we
talk
about
automation,
not
being
limited
to
configuration
management.
This
is
the
kind
of
stuff
we're
talking
about
because
in
many
ways
it's
more
valuable
than
doing
the
art
of
doing
the
config
change
in
an
automated
fashion.
B
A
B
A
The
information
into
something
that's
useful,
'hey
consumable
and
it's
both
sorry,
useful
and
consumable
and-
and
I
think,
if
we
do
any
labs
right
in
the
long
run-
that's
the
workflows
that
we
have
in
and
there
should
by
a
majority
over
time.
They
should
be
mostly
about
correlation
picking,
finding
information
and
correlating
in.
B
Honestly,
probably
a
little
bit
of
me
being
unhappy
with
everything
like
everything
that
I
do
I
might
have,
but
the
the
categories
on
energy
labs
just
understand
that
that's
meant
to
be
fluid
like
we're.
Not
you
know,
that's
gonna
change,
as
especially
as
we
get
more
workflows
in
there.
The
nature
of
the
workflows
are
gonna,
be
very
different
between
each
other.
We're
gonna
have
we're.
B
A
You
know
we
should
automate
things
that
are
that
are
risky.
You
know
we
didn't
give
an
example
of
that,
yet
we
should
automate
things
that
are
error-prone
and
we
should
automate
things
that
are
time-consuming
and
those
are
really
the
three
things
that
we
should
be.
Those
are
the
three
kinds
of
workflows
that
you
should
do
so
we
gave
the
VRP
example
that
can
be
very
time-consuming,
then
you've,
error-prone.
A
The
vrrp
example
can
also
be
error-prone
if
you're
doing
all
that
by
hand,
if
you
have
thousands
of
VLANs
all
running
VRP
and
you're
manually,
collecting
the
ERP
State
across
all
those
VLANs,
then
you're
making
a
mistake.
It's
easy
to
make
a
mistake
in
that
process.
The
Miss
Avilan
to
miss
read
the
numbers
to
you,
know
that
you're,
seeing
in
the
state
etc,
and
then
you
know
the
last
thing
is
our
things
that
are
risky
right.
The
error-prone
doesn't
necessarily
mean
risky,
but
risky
means
you
know.
I'm
gonna
make
this
change.
A
B
A
You
know
there
are
tools
that
can
add
additional
sort
of
dynamic
behavior
on
top
of
the
network,
and
you
know
those
those
are
like.
Those
are
products
right.
They
have
a
UI
and
on
the
and
and
then
you
you
interact
with
the
UI
and
then
on
the
back
end.
They
go
and
they
drive
things
in
the
network
and
that
kind
of
automation
is
different
than
what
we're
talking
about,
because
what
we're
talking
about
never
goes
away.
A
They'll
never
be
a
tool
that
does
literally
all
the
things
not
just
for
the
network
but
for,
like
I,
said
all
those
other
things,
systems
that
are
external
systems
that
are
attached
to
the
edge
of
the
network
systems
in
the
management
domain.
No
tool
will
ever
be
integrated
with
all
those
things
not
automatically
do
all
the
things
in
exactly
the
way.
That's
right
for
your
organization,
so
those
are
really
two
different,
two
different
things
and,
and
so
the
yeah
I
mean
I.
A
B
Ask
yourself:
how
can
automation
help
me
in
everything
that
I
do
in
a
given
week?
That's
that's
what
you
have
to
start
with
the
answers.
Gonna
be
different
for
everybody,
but
if
you're
starting
off
on
that
premise,
I
think
you're
in
a
lot
better
shape.
Then
how
can
I
automate
the
network
today
you're
kind
of
constraining
yourself,
if
you
think
about
it
that
way,
yeah.
A
And
you
know,
there's
something
else
too.
I
want
to
point
out
we
sort
of
hit
on
this.
We
said
we
spend
so
little
time.
Actually
configuring
it's
kind
of
crazy
that
there's
so
much
effort
goes
into
automating
configuration
for
because
it
because
in
the
end,
even
if
something
perfect
came
out,
it's
gonna
save
you
an
hour
a
week
of
time,
and
it
that's
not
a
compelling
argument
for
me.
A
So
you
know
one
of
the
things
that
comes
up
and
I
tell
people
all
the
time
is
so
so
you
have
a
workflow
that
you
want
to
automate.
You
know
that
workflow
can
be
broken
down
into
effectively
a
pre-check
some
activity
in
a
post
check
right
and
that
activity
may
or
may
not
be
a
configuration
change.
In
fact
it
and
like
we
were
saying
in
most
cases
it's
probably
isn't
a
configuration
change
and
that
you
know
those
are
three
possible
stages
and
they,
you
know
the
pre
check
might
not
exist.
A
But
the
the
first
things
that
you
should
automate
are
the
things
you
know
as
all
the
checking
and
the
correlation
that
happens
before
and
after
those
activities
that,
because
that's
what
automation
should
be
about
doing
things
more
reliably,
not
and
being
more
informed
when
you
do
those
things
versus
just
automating,
some
change
which
in
retrospect
might
end
up
being
a
very
bad
mistake.
You
know
now
you've
automated
that
change
across
100
devices,
instead
of
just
one.
B
But
it
was
just
like
a
lower
time,
so
like
middle
of
the
night
weekends,
like
generally
speaking,
pretty
low
low
impact
time
relatively
speaking,
and
we
would
lift
the
whole
network
out-
and
you
know,
rien
playa-
you
know
put
in
some
new
switches
or
whatever,
whatever
we
did
and
then
and
then
we
would,
we
would
have
it
all
configured
the
way
we
know
it
needs
to
be
configured.
We
would
start
doing
pain,
tap,
hey
like
if
you
try
to
do
that.
Just
understand
that
you
don't
like
that's,
not
gonna
really
cut
it.
B
It's
not
like
the
times
have
changed
like
we
were
just
flailing
about
at
what
we
thought
was
useful,
but
inevitably,
when
Monday
rolled
around
and
all
the
doctors
came
back
into
work,
you
know
in
full
like
there
would
always
be
problems,
and
we
knew
that
so
I
think
it's
just
time
to.
We
acknowledge
that
and
stop
trying
to
fix
the
thing.
That's
not
the
actual
constraint,
like
the
speed
at
which
changes
are
happening
is
not
a
constraint.
You
might
think
it
is.
But
it's
not
it's
it's
it's
it's
it's
it's
it's
just
not!
B
A
B
A
B
A
On
on
our
YouTube
channel,
which
is
its
energy
labs
on
on
YouTube
I
mean
you
can
watch
every
one
of
these
streams
that
we've
done
up
to
this
point
and
and
every
one
of
our
community
stand
up
so
which
I
some
of
them
it's
worth
watching.
So
please,
you
know
subscribe
to
that.
Youtube
channel
and
you'll
be
notified
when
new
videos
get
posted
and
there'll
be
additional
content
happening
within
before
the
end
of
the
year.
Not
just
this
in
the
in
the
community
stand
up.
A
A
A
It's
like
encapsulated
automation
where
you're
interfacing,
you
know
through
some
GUI
or
you
know,
a
CLI
could
even
be,
and
you
you
declared
you
know
you
have
some
declarative
way
of
saying
how
you
want
the
network
to
work
and
then
and
then
that
tool
goes
rheostat
and
then
goes
and
it
pushes
configs
or
whatever
it's
gonna
do
down
to
to
some
portion
of
the
infrastructure
that
it
drives.
And
if
you
delete
that
intent.
A
B
I
mean
there
are
ways
you
can
conceptually
think
about
that.
If
you
think
about
so
Damien
Damien
over
at
to
roblox,
he
actually
gave
this
talk
at
in
Ralph
and
he
talked
actually
on
packet
pushers.
When
he
was
on
that
referred
well,
they
they
don't
they're,
not
they
didn't
talk
about
any
like
intent
based
product,
but
what
they,
what
they
do
is
when
they
rent
when
they
create
configurations
for
their
network
devices.
B
They
do
so
from
a
source
of
truth
outside
the
outside
of
the
network
itself,
and
then
they
they
effectively
what
they
do
is
they
overwrite
the
entire
config
so
that
there's
no
portion
of
the
config
that
could
possibly
be
outdated
because
it's
generated
in
full
somewhere
else
and
then
applied
in
full
on
the
device.
There's
no
chance
of
anything
aging
out.
I've,
never
yeah
I
mean
Derek.
B
You
might
know
this
better
than
I
do,
but
I
would
imagine
that
the
easiest
way
to
do
that
in
an
intent
based
networking
like
product
is
is
the
same
kind
of
thing
where,
instead
of
like
trying
to
figure
out,
oh
did
this
policy
change.
This
portion
the
config
versus
this
portion,
rather
than
doing
that
it
just
simply
overrides
the
entire
config
that
way.
Yeah.
A
B
Just
too
challenging
to
even
try
to
like
figure
out,
what's
true
I'm
like
what
what
you
know.
First
go
get
the
config
and
like
parse
through
it
and
like
the
operational
State
and
see
how
things
are
and
then
and
then
like
come
up
with
some
sort
of
a
diff
that
that
gets
to
where
you
need
to
go,
and
it's
just
too
messy
start
with
the
source
of
truth,
generate
the
full,
config
and
overwrite
it,
which
you
can
either
do
with
an
intent
based
networking
product
it
does
it
that
way
or
you
can
do
it
yourself.
B
Like
you
know
the
folks
over
at
roblox
have
done
I'll
see
they
can
find
a
link
to
that.
That
pack
could
push
a
show
cuz.
That
was
a
good
show.
He
talks
about
that.
Not
everybody
can
do
that.
They.
They
have
a
few
things
in
place
that
allow
that
allow
them
to
do
that
safely,
but
it
seems
to
be
working
for.
A
Them
there's
also
a
lot
of
reused
configuration
inside
of
a
device
and,
like
classic
example,
is
you
know
a
VLAN
or
whatever
is
created
on
a
device
and
multiple
ports
uses
VLAN?
So
if
you
want
to,
you
know,
remove
the
VLAN
from
a
port,
at
which
point
is
it
safe
to
remove
the
VLAN
itself
from
the
config
so
that
it
doesn't
exist
anymore
at
all
on
the
device?
There's
like
lots
of
sort
of
hierarchical
information
that
can
that
can
exist
that
way
right,
you
have
policies
that
reference,
ask
access,
lists
and,
and
so
on.
A
So
you
you
know,
that's
one
of
the
challenges.
I!
Guess!
If
you're
going
to
build
your
own
intent-based
system,
is
you
have
to
understand
what
those
dependencies
are
so
that
you
don't
blow
away
configuration
that
you
didn't
intend
to
so
to
speak?
Yeah?
That
would
be
that's
an
interest
says.
That
makes
a
lot
of
sense,
but
it's
hard
to
do
on
Cisco,
for
example,
as
PF
config
could
be
a
lot,
but
deletion
only
takes
no
router
OSPF,
but
then
configuration
itself
can
never
have
a
no
version
of
config
lines.
So
you're
not
hijacking
the
show.
A
It's
fine,
you
know
what
we
could
do.
A
whole
show
like
if
you
wanted
to
I
mean
that
it
I
mean
a
lot
of
people.
Do
build
I
want
to
say,
like
intent,
based
solutions,
they
they
leverage
the
concept
of
intent
in
the
tooling
that
they
have
or
build,
and
that
and
there's
got
to
be
considerations
around
that
I.
B
Because
he
they
built
it,
that's
a
that's
literally.
What
they've
done
is
they've
built
an
intent
based
system,
but
it's
not
built
into
a
product.
They
just
kind
of
made
it
part
of
their
operations.
Okay,
good
he'd,
be
a
good
guest,
he'd
loved,
it
I'm
sure
he'd
love
to
come
on.
You
should
ask
him.
Oh.
A
A
One
well,
let's
summarize
real,
quick
right,
so
the
idea
behind
the
categories
that
we
have
is
that
you
know
you
should
be
automating
workflows
that
you
actually
do
as
a
network
engineer
and
not
worried
about
adding
more
dynamic
behavior
to
your
network
and
and
the
actual
things
you
should
automate.
They
should
be
things
that
are
kind
of
risky
or
time-consuming
or
error
prone
and
then
and
then
even
with
those
tasks.
The
first
thing
you
should
automate
is
that
is
either
pre
task,
validation
or
a
post.
A
Ask
validation,
those
that
should
be
like
the
priority
of
how
you
know
the
kind
of
automation
we're
talking
about.
That's
that
should
be
how
you
do
it
right,
that's
that
that
should
be
the
goal,
and
it's
and-
and
it's
always
with
this
reliability
thing
in
mind
like
how
do
I
do
things
more
effectively,
more
reliably?
How
do
I
you
know?
A
A
Is
that
that's
how
we
differentiate
ourselves
from
like
products
that
talk
they
have
you
know
that
are
sold
as
that
they
do
automation,
but
it's
encapsulated
and-
and
you
don't
really
touch
it-
you
don't
have
to
know
how
any
of
that
works
versus
what
what
we're
talking
about,
which
is.
You
know,
you
know
how
do
I
not
just
interact
with
the
network,
but
the
systems
around
the
network,
the
systems
and
the
management
domain,
and
you
know
how
do
I?
How
do
I
automate?
A
A
B
Because
there's
no
way
I'm
gonna
be
able
to
get
into
into
enough
detail
right
now,
anyway,
it's
at
the
end
of
Street.
Basically
one
of
the
things
that
came
up
last
week
on
last
week's
stand
up
was
the
need
for
more
documentation
and
I
I've
tried
to
spend
a
lot
of
time
on
Docs,
but
it's
kind
of
hard
to
like
really
really
build
it
out,
because
you
know
you
have
to
keep
this
balance
of
like
moving
the
platform
forward,
while
also
moving
the
docs
forward.
B
We're
at
the
point
now,
where
I'm
like
kinda,
desperate
for
help
with
the
platform
and
so
I'm
just
forced
effectively
to
like
really
really
really
invest
in
all
of
the
things
around
the
right.
You
know
everything
about
everything
around
and
not
including
like
platform,
to
help
other
folks
get
on
board
with
how
it
works
one
of
those
it
one
of
those
things
is
documentation.
A
B
Documented
and
it
it's
in
a
PR
that
I'm
going
to
be
merging,
hopefully
today,
I
also
built
a
new
page
for
like
if
you
don't
know
anything
about
get
like
you
can
go
to
this
page,
and
it
explains
everything
you
need
to
contribute
to
an
energy
labs
or
an
antidote,
get
repository
or
not
even
contribute
to
like
anything
that
you
might
possibly
want
to
do
with
the
repository.
It's
not
really
meant
to
be
a
gift
101.
B
There
are
links
to
other
tutorials
for
like
really
really
fundamental
get
stuff,
but
if
you,
if
you
want
to
like
figure
out
how
we
have
things
organized
and
like
what
it
looks
like
like
fork,
something
and
things
like
that,
there's
a
whole
page.
Just
for
that,
like
just
forget
stuff
and
then
there's
a
totally
new
documentation
on
me,
I'm
contributing
to
the
antidote
plaque.
We
already
have
kind
of
architecture,
dots
which
I'm
going
to
be
updating
later,
but
one
thing
we
didn't
have
was
like:
okay,
I
want
to
start
contributing
to
the
antidote
platform.
B
How
do
I
even
start
doing
that
so
I
have
a
doc
on
that.
There's.
So
there's
just
a
and
then
oh
yeah
I
fell
on
how
to
contribute
to
the
docs
I
built
a
whole
page
focused
on
like
okay
cool,
like
a
lot
of
people,
a
lot
of
projects,
including
ours.
One
of
the
things
that
we
tell
people
is
you
know
if
you
want
to
get
started
with
this
project.
B
One
of
the
easiest
ways
to
get
started
is
to
start
contributing
to
the
docs
like
read
the
docs,
find
typos
and
find
things
that
don't
make
sense.
You
know
ask
questions
figure
out
what
what
the
answer
is,
and
then
you
know
contribute
that
back
to
the
docs,
but
we
don't
let
people
know
how
to
do
that.
So
that's
what
I
wanted
to
do.
I
wanted
to.
Let
people
know
how
to
do
that.
B
So
I
built
a
page
focused
on
how
to
contribute
to
the
dogs,
so
in
all
kinds
of
new
documentation
changes,
hopefully
gonna
be
dropping
tomorrow.
We
won't
obviously
be
done.
There's
still
lots
more
to
do,
but
it's
gonna
be
a
nice
big
addition
that
I
think
is
long
overdue,
so
stay
tuned
for
that
we'll
be
talking
about
it
and
hopefully
showing
it
tomorrow.
Yeah.
A
So
every
single
Tuesday
at
8
a.m.
Pacific.
We
have
it
it's
it's
at
that
time
because
it's
you
know
it's
it.
That
makes
the
meeting
doable
for
people
who
are
in
Europe.
It's
it's.
You
know
it's
it's
the
time
we
chose
to
try
to
get
as
much
people
as
many
people
as
we
can
on
those
stand
up
calls
it's
8
a.m.
Pacific,
the
details
for
which
are
located
on
our
community
forum
site
community
network
reliability
that
engineering
it
should
be
the
banner
the
banner
posts
on
the
top
of
every
page.
There's
a
link.
A
You
can
click
tomorrow
and
please
join
even
if
you
don't
have
anything
to
say
you
you'll
be
present
and
counted,
and-
and
you
know,
you'll
you'll
see
how
the
kind
of
the
conversation
goes
and
then
maybe
next
time
you
know,
you'll
you'll
have
you'll
be
more
confident.
You
know,
speaking
up
and
and
yeah,
you
know
expressing
your
ideas.
So
please
please
come
to
the
to
the
community,
stand
up
and
tomorrow
at
8
a.m.
and
we
hope
to
see
you
there
also.
You
know
every
single
week,
Monday
at
10
a.m.