►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CNCF Network SIG Intro & Deep-Dive - Lee Calcote, Layer5 & Matt Klein, Lyft
“It’s the network!” is the cry of every system administrator, every developer. With the increased prevalence of microservice-based distributed systems, it’s true - networking as a discipline has never been more critical in the efficient operation of cloud native deployments. Networking primitives, including load balancing, observability, authentication, authorization, policy, rate limiting, QoS, mesh networks, legacy infrastructure bridging, and so on are now receiving substantial development and investment throughout the industry and are the subject of focus of the CNCF Network SIG. Join this talk for an intro to the SIG, its charter and a deeper discussion of current cloud native networking topics being advanced in this SIG. Current CNCF projects in-scope: CNI, CoreDNS, Envoy, gRPC, Linkerd, NATS, Network Service Mesh.
https://sched.co/WDzj
A
All
right
welcome
to
what
I
didn't
think
would
be
this
type
of
a
turnout.
I,
don't
know
that
I've
ever
seen,
Matt
Klein
even
mildly
nervous,
but
but
you
get
so
we're
we're
appreciative
of
the
of
the
interest.
We're
gonna
have
a
discussion
today.
My
name
is
Lee
Cal
coat.
This
is
Matt
Klein,
hello,
well
we're
here
to
in
some
respects.
Well,
this
is
a
bit
tongue-in-cheek,
but
almost
have
the
inaugural
cig,
Network
meeting
the
CN
CF
sig
Network
meeting
who's
familiar
with
SIG's.
A
A
They're
very
good,
so
SIG's
themselves
and
in
part
I
call
out
that
this
is
a.
This
is
a
sig
because,
historically
inside
of
the
scenes,
yet
there
have
been
working
groups
specific
to
this
focus
area.
There
had
been
a
networking
working
group
that
maybe
arguably
the
mouth,
not
arguably
probably
the
most
notable
thing
that
that
networking
working
group
had
done
is
helped
steward
CNI
container
network
interface
sort
of
through
the
process
of
onboarding
into
the
CNCs,
and
then
it
did
some
other
things.
A
It
was
a
forum
for
vendor,
neutral
discussion
and
understanding
of
some
cloud
native
networking
things
in
the
time
that
he
and
I
had
come
into
the
scenes.
Yet
many
many
months
and
a
year
in
something
had
has
passed,
and
so
now
the
scene
CF
has
taken
a
step
back,
has
grown
by
more
projects
than
I,
have
fingers
and
and
is
now
now
has
special
interest
groups.
And
so,
while
CN
CF
sig
network
is,
will
take
on
some
of
the
same
area
of
focus
that
the
networking
working
group
has
had.
A
A
My
lord
that's
a
mouthful
on
to
its
own
and
part
of
what
we're
part
of
what
we're
hoping
to
do
is
with
cigs
in
general,
is
to
help
more
impactfully
scale.
The
scene
CF
technical
oversight
committee
so
of
this
cig,
Matt
Klein,
is
our
TOC
liaison,
so
SIG's
themselves
don't
exist
outside
of
governance
of
the
CN,
CF,
TOC
and
and
Matt.
A
A
These
verbs
were
chosen
explicitly
for,
as
opposed
to
things
like
dictating
and
governing
those
convey,
a
different.
You
know
sense
of
what
what's
trying
to
be
accomplished.
They
was
trying
to
be
accomplished.
Is
you
know
something
of
a
community
and
a
vendor
neutral
forum
for
open
discussion
around
potentially
conflicting
interests,
potentially
conflicting
ideas?
A
We
can
you
know
Matt
and
I
can
sit
and
meet
and
talk
about
some
things
maybe
make
some
decisions
and
and
not
really
have
those
go
anywhere.
If
there
isn't
participation,
there's
a
reason
why
matt
is
holding
a
microphone
and
that's
because
he's
gonna
be
soliciting
your
thoughts,
feedback
input
things
that
that
you
consider
that
you
would
expect
that
this
sig
would
take
on
challenges
and
topics
that
it
might
address.
Be
thinking
about
that
in
the
back
of
your
mind
as
we
go
forth
here,
so
so
we're
intending
to
collaborate.
A
B
B
There
are
some
basic
things
that
we
can
do
and
we'll
definitely
do
those
and
if
that's
the
only
thing
that
people
want
to
get
out
of
this,
that's
that's
fine,
too,
but
if
there
are
other
other
activities,
whether
those
be
new
projects
that
need
to
get
developed,
whether
those
be
white
papers
to
clarify
complex
topics
that
people
don't
understand,
I
think
we're
open
to
many
different
types
of
projects.
But
we
would
need
feedback
in
terms
of
what
what
would
be
asked
for
is
that
fair,
yeah.
A
Yeah
it
to
reinforce
that,
if,
if
folks
don't
come
to
participate,
it's
gonna
be
a
bust,
pretty
quick.
So
these
are
the
existing
projects
that
are
sort
of
within
focus
to
Matt's
point.
The
Cadis
that
that
we're
hoping
to
establish
is
probably
a
every
couple
of
weeks
to
get
together
on
a
Thursday
to
have
these
discussions.
The
there
is
it's
kind
of
the
status
of
how
the
sig
is
being
formed
and
the
the
the
links
to
the
mailing
lists.
A
B
But
I
I
think
at
this
point
we
can
just
open
it
up.
So
if
with
her,
you
want
to
just
ask
questions
about
what
the
group
would
actually
do,
if
there's
things
that
you
would
like
to
talk
about
that,
we
would
discuss
at
future
meetings.
I
think
we
would
like
your
feedback.
So
does
anyone
want
to
ask
a
question
or
open
the
discussion?
I
can
bring
the
mic
around.
B
B
A
I
think
that's
a
about
right
in
part.
The
answer
is
we're
not
quite
sure
just
yet
in
part,
because
if,
if
there's
an
influx
of
discussions
and
topics
that
folks
are
looking
to
have
within
the
group,
that
will
also
help
dictate
how
frequently
we
meet
and
whether
or
not
there
there
are
even
subgroups
to
to
discuss
some
of
those
things
more
in
depth.
A
B
No
I
mean
at
a
at
a
basic
state,
I
think
again
what
this
group
will
do.
It
will
mostly
be
static
until
the
TOC
need
some
input
on
either
new
projects
or
on
project
reviews
like
I.
Think
that's
the
that's
the
basic
case
of
this
group
and
I
think
that's
a
really
obvious
thing
that
people
need
to
do,
but
I
think
that
again,
we'll
be
looking
for
people
to
bring
other
topics.
You
know
that
we
can
work
on
or
help
drive.
A
While
you're
thinking
of
your
next
question,
one
of
the
things
that
things
have
begun
to
do
is
begun
to
be
a
forum
for
early
review
of
upcoming
projects.
There's
a
sig
sig
application
delivery
that
is
beginning
to
review
sandbox
project
proposals
so
as
such,
so
is
a
sig
network,
a
potential
place
to
review
some
of
those
things.
A
A
There
was
more
recently
an
announcement
of
a
different
service,
mesh
abstraction
and
its
purpose
was
much
more
and
it's
called
hamlet
and
it's
much
more
for
purposes
of
specifying
a
common
way
of
federating
heterogeneous
service
meshes
not
to
get
into
the
particulars
of
those,
but
to
bring
about
an
example
of
this
network.
Are
the
this
sig
network
providing
a
forum
for
discussion
and
potentially
a
forum
for
those
specifications
to
come
through
and
potentially
come
into
the
CNC
F?
If
that
makes
sense,.
D
So
I'm
actually
actually
sure
if
my
question
is
correct
for
this
vineyard
or
not,
but
I
came
to
this
mostly
because
I
had
not
previously
been
involved
with
sig
network,
but
in
the
role
that
my
company
plays
in
the
kubernetes
ecosystem.
One
of
the
key
things
that's
important
to
us
is
the
performance
Delta
between
bare
metal
and
running
applications
inside
of
kubernetes
and
network
performance
in
particulars,
rather
critical
to
that.
D
So
what
is
the
best
pathway
for
our
company
or
myself
personally,
to
get
involved
in
helping
to
drive
performance
as
a
key
factor
in
the
community
that
people
think
about
I?
Think
at
least
in
this
community?
Most
of
the
focus
has
been
on
interoperability
and
performance
has
taken
a
backseat
and
I
think
that's
a
barrier
of
entry
for
people
migrating
applications
into
kubernetes.
So
you.
A
A
Well,
in
that
you
know
what
we
all
need
is
another
foundation.
I
say
that
mostly
jokingly
and
that
there's
I'm
currently
a
new
proposed
Linux
Foundation
sub-project.
It
currently
goes
by
the
name
of
workload,
profile,
definition
and
measurement,
and
it
is
for
purposes
of
well
initially
defining
describing
how
you
would
characterize
a
workload,
how
you
would
characterize
the
environment
in
which
it
runs,
and
then
the
manner
in
which
you
would
do
performance
testing
of
the
workload
end
of
the
infrastructure
that
it
runs
on.
A
A
For
my
part,
it's
my
intention
to
go:
take
a
service,
mesh
performance,
benchmark
specification
into
that
new
project
and
have
that
discussed
and
worked
on
as
a
specific
area
of
focus,
but
it's
one
that
I
would
desire
for
to
be
highly
discussed.
You
know
this
is
this
is
on
the
list
of
like
relationships
to
maintain
and
and
and
topics
of
discussion,
to
have
that
you
know
again
what
Matt
will
chime
in
here,
but
but
for
my
part,
like
that's
a
signet
work,
is
a
wonderful
and
highly
appropriate
place
to
discuss
your
network
performance
yeah.
B
I
I
think
purpose,
something
that
we
should
definitely
tackle.
The
caveat
that
I
would
say
with
perf
is
that
in
my
own
experience,
it
requires
a
extremely
large
time
investment
to
do
in
a
way
that
is
not
didn't.
There's
not
disingenuous
and
I
would
want
to
make
sure
that
any
artifacts
that
we
produce
that
we
can
be
that
we
can
be
proud
of
those
artifacts
and
it
doesn't
become
finger-pointing
mess
of
numbers
that
can't
be
reproduced
and
don't
have
a
lot
of
value.
B
So
so
yes,
I,
think
perf
is
a
great
thing
that
we
should
be
talking
about,
and
I
would
love
to
get
some
people
together.
That
can
start
actually
working
on
that
to
figure
out
what
we
need
to
measure.
Most
importantly,
how
can
we
measure
it
reproducibly,
which
costs
money
so
there's
a
funding
element
but
yeah
I
think
this
is
a
very
ripe
ripe
area
of
investigation.
B
Yeah,
sorry
yeah,
so
the
the
comment
was
that
they've
done
something
similar
and
sick
storage.
How
can
we
bring
it
into
cig,
Network
I
think
you
should
just
come
to
our
next
meeting
and
we
can
discuss
it.
I
think,
there's
a
there's!
A
mailing
list
I
had
already
sent
an
email
asking
people
what
they
would
want
to
work
on.
B
A
A
Actually,
you
know
not
done
well,
it
could
be
kind
of
a
sensitive
thing
to
go.
Tell
a
project
that
you're,
slow
or
you're
fast
or
relative
to
this
you
know
they're
just
but
then
it
needs
to
be
done
in
a
transparent
way
accurately.
It
needs
to
be
done
and
the
thing
is
is
like,
while
it
might
provide
value
at
a
point
in
time.
A
B
Also
have
to
make
sure
that
we're
actually
comparing
apples
to
apples
and
that's
the
other
big
problem
with
these
types
of
endeavors
is
sometimes
it's
hard
to
actually
take
two
projects,
because
they
don't
do
the
same
things
so
again,
I
mean
I,
think
we're
all
in
agreement.
This
is
something
that
we
should
look
into
for
sure.
Anyone
else
have
any
thoughts
or
comments.
A
Well,
while
you're
thinking
that
here's
another
section
of
the
Charter
that
talks
about
responsibilities
and
deliverables,
boy,
I,
hope
I
hate
to
sign
us
up
for
a
bunch
of
work,
but
that's
kind
of
what
with
us,
what
we're
doing
that's
what
we're
here
for
part
of
that
is,
if
you've
looked
at
other
working
groups
or
other
SIG's
they've
put
out.
Some
of
them
have
put
out
white
papers
that
hopefully
help
explain
either
a
few
newfangled
terms
that
are
in
relative
to
that
technology.
Space
or
they've
helped
helped
it
just
give
context
to
the
area.
A
So
if,
for
those
that
have
spent
time
in
the
server
lists,
working
group
or
in
I,
think
sig
storage
or
before
they
were
six
doors,
I
put
out
a
white
paper,
there's
a
potential
there.
A
potential
appetite
for
that
inside
of
the
sig
Network,
also
a
potential
appetite
for
kind
of
a
sub.
So
there's
the
CNC
F
landscape,
potentially
a
sub
landscape
of
that
that's
expands
a
bit
with
respect
to
networking
and
traffic
and
those
things
so
other
SIG's
have
taken
on
white
papers,
landscapes.
A
A
Maybe
if
you
know
a
similar
question
around
a
white
paper
like
so
the
white
paper
that
I
described
is
just
it
one
that
that
characterizes
this
base,
then
the
need
for
discussions
that
the
reasons
why
it
is
that
there
are
projects
focuses
in
the
space
sort
of
what
it
is
that
differentiates
cloud
native
networking
as
a
TM
as
a
as
a
term
and
as
a
space,
you
know
maybe
potentially
different
from
a
term
like
Sdn
or
or
from
physical
network.
Is
it
did
so?
A
A
E
A
You
know
hit,
for
my
part,
I
think
that
those
are
highly
interesting,
that
we
had
aspired
to
focus
on
trying
to
help
facilitate
some
some
producing
some
best
practices
and
and
taking
some
use
cases
into
context
and
just
describing
how
those
can
could
be
approached
in
context
of
the
cloud
native
principles.
From
my
part
that
fit,
though,
that
feels
appropriate.
F
A
A
From
my
perspective,
I
considered
highly
complementary
and
potentially,
and
certainly
a
group
to
have
a
relationship
with
and
as
something
of
a
potentially
of
a
subgroup
in
part
because
well
in
part,
because
you
can
have
a
lot
of
Network
centric
discussions
with
if
you
put
on
a
developer
hat
or
an
operate
an
op
set
and
you
could
have
a
whole
different
set
of
discussions
about
networking.
If
you
put
on
a
network
engineer,
hat
and.
A
United
to
I,
don't
know
how
so
Saturday
my
point
is
is
like
networking
is
deep
and
wide
and
that
it
just
even
within
the
context
of
the
projects
that
will
be
within
this
SIG.
If
you
take
a
look
at
network
service
mesh,
you
take
a
look
at
link
Rd,
just
as
two
examples,
what
they
taught.
They
talked
about
service
mesh
in
dramatically
different
ways
and
that's
in
by
and
large,
because
the
folks
are
wearing
different.
B
I
think
what
I
would
say
is
that
these
these
groups
can
be
nimble.
You
know
they're
they're
being
formed
to
hopefully
help
the
ecosystem
not
make
it
more
confusing.
So
I
think
that
you
know
if
we
find
over
time
that
there's
a
ton
of
overlapping
between
the
telco
group
in
this
group,
we
can
potentially
emerge
them.
So
I
think
we
just
need
to
see
how
things
evolve.
G
So
I'm
just
kind
of
jumping
in
so
it's
an
interesting
conversation
about
wearing
between
wearing
the
dev
dev
ops,
slash
network
engineer:
where
do
you
see
this
group
playing
out
because
I
guess
I
come
from
that
network
engineering
background
network
architecture?
I
want
to
be
a
part
of
this,
and
I
want
to
be
able
to
help
at
the
same
time,
I
have
no
dev
anything.
G
No
software
engineering,
background
and
I
want
to
have
people
at
my
organization
be
able
to
participate
and
help
out
as
well,
but
we're
just
learning
and
starting
our
whole
journey
with
dev
dev
ops,
so
we're
trying
to
figure
out
how
do
we?
How
do
you
incorporate
people
who
don't
have
necessarily
that
background
to
further
this
journey?
To.
A
Be
that's!
That's
a
super,
exciting
question.
Actually
because
you're,
one
of
you
know
nine
million
others
that
are,
you
know,
have
that
same
perspective
and
story
that
yeah
be
my
that
there's
a
bit
of
a
bridge
or
but
there's
a
bit
of
a
gap
to
bridge
and
that
I'm
excited
about
that
that
bridge
potentially
being
I'm.
A
Sorry
that
gap
be
being
bridged
in
so
much
as
a
lot
of
a
lot
of
things
that
we
are
discussed
within
the
CNC
F
are
at
their
center
may
be
discussed
from
a
width
from
matter
how
I
don't
want
to
be
put
buckets
on,
but
but
it
from
a
DevOps
or
from
a
developer,
centric
or
a
software.
You
know
software
engineering
centric
perspective,
but
that
yeah
we're
it's
an
exciting
thing
to
me,
because
it
seems
like
we're
missing
out
on
that
there's
a
whole
other
world.
A
B
I
mean
I
would
go
even
further
and
say
that
people
with
your
perspective
are
very
valuable
to
this,
because
this
landscape
is
incredibly
confusing
and
fast-moving,
so
I
think
actually
having
people
to
come
into
the
ecosystem
and
better
help
us
understand
what
are
the
understanding
gaps
like?
Where
is
the
documentation
that's
needed
and
potentially
to
help
with
the
documentation
like
as
part
of
the
learning
process?
I
think
that's
actually
very
useful.
So
that's
that's.
What
I
would
suggest
is
just
join
the
group
and
actually
help
us
understand
what
you
don't
understand.
C
G
A
H
A
A
Yeah
so
there,
hopefully,
this
isn't
contentious
or
doesn't
isn't
in
conflict.
I
think
what
was
some
so
Matt
hasn't
you've
been
giving
great
responses.
I've
been
trying
to
give
you
specific
ones
and
Matt's
been
saying
well
in
part,
we're
not
quite
sure
yet
that
that
will
unfold
over
time.
That
yeah.
If
you
consider
that
many
of
the
folks
that
show
up
for
discussions
have
come
from
us,
then
how
should
I
say
there
aren't
necessarily
there
are
too
many
of
the
same
minded
same
focused
folks.
A
A
You're
speaking
to
certainly
networks
don't
function
in
Leicester
or
none
of
us,
the
software
runs
unless
is
running
on
physical
things.
I
think
what
was
trying
to
be
articulated
here
is
that,
if
we're
talking
about
the
next
ASIC
design
may
be
that
that's
appropriate
to
discuss,
because
because
it
could
be
a
connection
between
if
we're
and
if
we're
talking
about
speeds
and
feeds-
maybe
that's
you
know
less
of
interest
but
Matt
you.
Would
you
characterize
that.
B
Yeah
I
I
think
that
I
mean,
what's
obviously
in
scope,
are
the
projects
that
we
have
in
the
CNC
off
already
and
those
areas.
So
obviously,
that's
server
smash,
RPC,
low
level,
networking
adapters,
those
types
of
things,
but
you
know
based
on
this
discussion
again
honestly,
what
is
in
scope
is
going
to
be
the
people
that
show
up
and
what?
What
is
the
passion
of
people
that
are
actually
going
to
do
the
work,
because
this
ultimately
is
all
volunteer
work.
So
if
what
is
in
scope
ends
up
being
perf,
that's
great.
B
If
what
is
in
scope
ends
up
being
application.
Programming
patterns
for
networking
I
think
that's
great
too
so
I
I,
just
don't
know
that
we
can
be
actually
super
prescriptive
about
in
scope
out
of
scope
right
now,
when
all
of
the
SIG's
are
just
being
formed,
and
we
don't
really
know
what
work
people
are
going
to
want
to
do
and
what
questions
people
actually
have.
So
my
preference,
just
speaking
for
myself,
is
I,
would
rather
see
the
work
that
people
are
passionate
about
actually
doing
and
who
shows
up,
and
then
we
can
evolve.
B
G
So
daisy-chaining
offer
that
it
just
seems
to
be
a
very
interesting
conversation
because
network
engineering
things
like
that
we're
cloud,
but
then
we're
starting
to
bleed
into
core,
which
is
on
Prem
and
the
things
like
that,
and
then
we
start
looking
at
like
okay,
we
need
a
program
stuff.
We
start
looking
at.
How
do
we
have
like
open
source
routers?
How
do
we
do
virtualization?