►
From YouTube: CNCF TAG Network and Service Mesh Working Group Deep-Dive - Lee Calcote, Ken Owens, Ed Warnicke,
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
CNCF TAG Network and Service Mesh Working Group Deep-Dive - Lee Calcote, Layer5; Ken Owens, Fiserv; Ed Warnicke, Cisco
With the increasing prevalence of microservice-based distributed systems, this is true: the network, as a discipline, has never been so critical in the efficient operation of cloud-native deployments. Network primitives including load balancing, observability, authentication, authorization, policies, rate limiting, QoS, mesh networks, traditional infrastructure bridging, and so on are now being developed and invested by the entire industry, and are the focus of the Service Mesh Working Group withing the CNCF TAG Network. Listen to our introduction and get an in-depth understanding of the service mesh projects being managed within the working group.
A
Good
afternoon,
everyone
at
kubecon
in
europe,
I'm
sorry
to
not
be
there
today,
but
I'm
really
looking
forward
to
talking
to
you
about.
What's
going
on
in
the
tag
network
and
service
mesh
working
groups,
my
name
is
ken
owens.
I
am
a
vice
president
of
cloud
security
and
engineering
at
fisa,
a
financial
services
company.
B
A
A
A
We
want
to
collaborate
with
individuals
and
we
really
want
to
attract
developers
and
engineers
that
are
coming
up
with
great
ideas
in
the
network
space
gaps
that
you
uncovered
as
you've
looked
at
going
cloud
native
as
you
deployed
kubernetes,
as
you
find
you
know,
networking
enhancements
that
are
needed.
We'd
love
you
to
bring
those
to
us
whether
it's
service
mesh
related,
whether
it's
you
know
firewall
related.
A
We
don't
really
have
a
have
a
you
know,
a
negative
opinion
about
any
of
these
technologies
that
are
in
use
today,
and
we
know
they
all
need
to
evolve
and
get
better.
So
we
definitely
want
to
invite
you
and
we
try
to,
for
the
most
part,
you'll
see
that
the
tag
network
group
is
very
impartial
right.
We're
not
trying
to
to
take
over
projects.
We
don't
want
to
own,
but
we
have
our
beliefs
come
from
the
cncf
beliefs
that
we're
not
going
to
make
any
kind
of
kings.
A
Our
goal
is
to
just
really
work
with
with
you
and
to
help.
You
know
stewart
your
project
through
the
the
different
gates
and
phases
of
the
cncf
project,
which
used
to
be
easier
than
they
are
today.
It's
a
lot
more
complicated
today
to
get
a
project
through
the
cncf,
and
so
we
are
here
to
kind
of
help
help
you
do
that.
A
And
just
like
I
mentioned
before,
you
know
lee,
and
I
have
been
doing
this
for
quite
a
long
time.
We
were
the
original
chairs
for
the
for
the
cncf
working
group
way
back
in
2019
before
the
pandemic
hit
us
right.
We
had,
you
know,
started
with
the
cloud
native
cloud,
networking
interface,
cni,
and
so
we
were
very
involved
in
getting
cni
and
helping
stuart
cni
into
this
in
the
cncf.
A
As
you
can
see,
we
were
pretty
busy
that
year
we
got
a
lot
of
different
projects
in.
We
didn't
stop
as
we
rolled
into
2020.
We,
we
continued
working
with
projects
and
you
can
see
you
know.
Service
mesh
interface
was
sort
of
one
of
the
that
was
one
of
the
big
projects
we
had
for
that
year,
as
we
went
in
through
the
rest
of
the
year,
we're
doing
chaos
smash
and
open
service
mesh.
As
we
look
at
you
know,
going
into
2021,
we
brought
in
some
emissary
ingress
and
the
kgb.
A
Other
things
that
we
like
to
do
is
lee
and
I
are
very
active
in
the
community
right,
and
so
we
had
an
opportunity
to
to
provide
a
white
paper
to
one
of
the
the
nice
one
of
the
bigger
ieee
instrument.
Electrical
electronics
engineers
committees
had
a
special
session
on
cloud
native
networking,
so
we're
able
to
provide
a
really
nice
paper
into
that
bridge
magazine.
A
The
bridge
is
part
of
ada
kappa
new,
which
is
a
part
of
ieee,
and
it's
an
honor
society
for
electrical
and
computer
engineering,
and
we
are
hot
off
the
presses.
We
are
continuing
that
effort
and
the
research
that
lee
is
working
with
university
and
we're
continuing
to
evolve
and-
and
we
have
some
more
research
we
probably
will
be
presenting
in
that
ieee
publication
as
soon
as
possible.
So
if
you
wanted
to
add
anything
to
that.
B
Optimization
so
is
the
the
current
one
under
study,
and
actually
I
think
we
have
a
slide
on
mesh
mark
a
little
bit
later
in
this
talk,
and
so
part
of
the
reason
that
ken
is
is
stepping
through
each
of
these
is,
if
you
can't
hear
it
in
his
voice,
there's
an
implicit
call
to
participate,
and
so
the
yep
this
next
research
paper
is
well.
It's
a
doozy.
A
Cool
okay,
so
we'll
get
into
some
of
our
our
projects
right.
So
we
we've
been
working
with
a
couple
of
different
specifications
and
in
this
environment
it's
really
important
to
to
define
specifications
and
be
very
clear
about
what
it
is
you're
trying
to
accomplish
right,
and
so
one
of
the
first
things
that
we
did
was
a
service
mesh
interface,
smi
and
that's
a
standard
interface
for
service
meshes
on
kubernetes.
A
As
you
know,
trying
to
standardize
anything
is
across
a
evolving
technology
like
kubernetes
was
not
an
easy
thing
to
do,
and
this
was
a
big
body
of
work
that
we
did
a
lot
of
kudos
to
to
lee
and
a
lot
of
the
work
that
he
helped
coordinate
across
the
community.
To
get
that
going,
then
we
published
the
smp
last
year
as
a
standard.
That
kind
of
just
helps
describe
a
common
terminology
around.
A
We
really
feel
like
apis,
give
us
that
common
playing
gun
right,
so
if
we
can
kind
of
start
with
a
set
of
standards
around
apis
that
enable
the
services
that
would
then
help
us
really
build
that
federation
model
from
day
one
versus
you
know
waiting
six
or
seven
years
and
not
having
a
model
and
then
trying
to
create
a
new
model
from
scratch.
So
we're
trying
to
go
after
this
problem
very
quickly.
A
So
on
that,
on
that
topic
of
standards
right,
we
thought
it'd
be
good.
To
talk
about
you
know,
patterns
and
patterns
are
similar
to
standards,
in
that
it's
it's
sort
of
trying
to
outlay.
What
are
the
steps
to?
What
are
the
components
and
what
are
the
set
of
like
common
controls
or
common
behaviors
or
common
set
of
configurations
that
would
be
needed
to
support
different
types
of
use,
cases
right
and
and
whether
you
want
to
say
use
case
or
pattern.
We
like
we
like
to
term
pattern.
A
We
think
it's
more
of
an
engineering
discipline
to
think
about
patterns
instead
of
you
know,
other
other
common
terms
you
could
use
here,
but
we
have
this
github
site
service
mesh
patterns.
The
the
value
here
right
is
that
we're
trying
to
look
at
enabling
the
business
language
around
service
mesh
adoption
right,
and
so
you
have
the
behavior
you're,
trying
to
capture
and
you're
trying
to
look
at
it
from
a
user,
which
is
an
application
developer,
usually
right,
how's
that
application
developer
going
to
get
to
take
advantage
of
these
patterns.
A
A
We
should
be
able
to
deliver
the
same
experience
to
to
our
development
user
community,
the
end
user
community,
without
having
to
specify
what
the
parameters
are
for
that
technology
and
then
the
most
important
piece
of
this-
and
this
is
something
that
that
lee
and
I
have
been
tackling
with
in
the
industry
for
a
decade
or
more.
It
has
to
be
reusable
right.
A
The
real
definition
of
how
good
your
pattern
is
is:
is
it
defined
in
a
way
that
can
be
picked
up
by
a
group
of
different
groups
of
individuals
and
they
can
use
it
without
having
to
re-customize
it
for
their
use
case
if
they
do
want
to
add
to
it?
If
there
is
a
you
know,
lee-
and
I
are
great
with
super
smart
people
right,
but
we
may
have
forgotten
something.
Whoever
was
working
with
us
on
these.
A
These
these
are
living
and
breathing,
and
they
they
change
over
time,
and,
as
you
can
see
on
here,
we
we
call
them
building
blocks
right,
they're,
basic
building
blocks
and
as
new
things
come
out
as
new
integration
patterns
come
out,
we'll
be
able
to
modify
those
with
the
community's
involvement,
not
not
just
leo.
I
do
it,
but
it'll
be
a
community
effort.
B
Answering
questions
like:
are
we
doing
it
right
and
by
it
that
could
be,
and
ken's
probably
going
to
talk
about
these,
but
that
could
be
using
a
function
of
the
surface
mesh
in
this
case,
so
a
circuit
breaker,
potentially
the
setting
retries
and
you
could
set
a
thousand
retries.
You
could
set
one
retry,
what's
the
common
practice
and
maybe
more
importantly,
what
are
the
considerations
to
account
for
as
you're
trying
to
find
that
magic
number
for
how
sensitive
your
circuit,
breaker
is
or
the
security
posture
of
the
the
mesh?
B
B
These
inevitably
end
up
having
best
practices
built
in
and
to
what
ken
was
saying
before
you
know.
If
you
taken
to
rationalize
over
a
service
mesh
pattern
and
a
service
mesh
specification,
one
is
a
lot
more
formal
and
can
take
quite
some
time
to
define
those
apis
that
ken
was
talking
about
and
in
these
patterns,
we're
looking
at
templates
we're
looking
at
best
practices,
things
that
are
reusable
just
like
ken
was
saying
and
so
yeah
anyway.
A
We're
really
excited
about
right,
because
lee
presented
last
year
at
in
china
uconn
that
we
had
a
few
of
these
service
patterns
right.
So
we
had
circuit
breaker,
we
had
retries,
I
think
we
might
have
had
manual
tls,
we
didn't
have
multi-cluster,
yet
we
didn't
have
a
lot
of
filters
created.
Yet
I
think
we
might
have
talked
about
like
the
jwt
transformer,
and
so,
as
you
can
see,
we've
we've
been
adding
and
formalizing
these
patterns.
B
A
We're
doing
next
right,
so
that's,
okay!
You
can
put
it
back
up.
You
know
it
and
with
this
it's
exciting,
because
we
we
know,
there's
a
lot
of
use
around
ebpf
and
a
lot
of
stuff
around
opn.
If
you,
if
you're,
not
familiar
with
opa,
that
that's
okay,
right
opa
is
open
policy
agent,
it's
it's
really
critical.
When
you
get
to
a
service
mesh,
especially,
but
in
my
opinion,
just
the
cloud
native
pattern
itself
policy
and
declaring
those
policies
become
so
critical
and
so
important.
B
B
Yeah,
the
of
the
of
the
current
patterns
that
are
there
they
are
well
when
a
pattern
is
first
described.
It
is
for
certain,
like
compatible
with
a
given
service
mesh.
The
goal
of
each
of
the
patterns
is
to
be
surface
mesh
agnostic,
to
the
extent
that
you
know
that
particular
service
mesh
is
capable
of
that
of
the
given
function
of
the
patterns
that
we're
seeing
on
the
screen
here,
you
know
nearly
any
mesh
that
you
could
well.
B
Actually,
I
should
so
of
circuit
breaking
of
retries
and
a
mutual
tls,
like
all
the
surface,
meshes
that
I
can
think
of.
That's
they've
got
that
covered,
and
so,
as
these
patterns
are
being
defined,
while
each
mesh
generally
has
mutual
tls
circuit
breaking
and
retries,
they
have
that
capability.
They
don't
they
don't
all
implement
it.
The
same
way,
which
is
what
ken
was
speaking
to
about
service
mesh
interface
and
the
service
mesh
performance.
B
The
specifications
to
try
to
get
each
of
the
service
meshes
well
to
try
to
be
able
to
define
patterns
like
this
in
a
uniform
way
is
really
reinforced
by
standard
specs
standard
apis,
and
so
they
don't
all
implement
these
capabilities
in
the
same
way.
So
as
the
patterns
are
worked
on
verifying
their
compatibility
is,
is
part
of
the
current
ongoing
work.
B
Since
last
we
met
or
since
last
week,
we'd,
given
it
a
deep
dive
into
the
service
mesh
working
group,
there
have
been
a
number
of
additional
web
assembly
filters
that
have
been
brought
in
and,
like
ken
was
saying
these
are
you
know
these
are
open
source.
These
are
available
to
all
the
webassembly
filters.
I
was
just
talking
about
compatibility
of
the
patterns
to
individual
service
meshes,
if
you
think
about
the
web
assembly
filters.
B
If
you
there's
a
lesser
number
of
service
meshes,
that's
well
that
like
are
natively
cognizant
of
ebpf
and
utilize
ebpf
as
a
foundational
data
plane
traffic
filter,
some
some
of
them
support,
eppf,
optionally
and
some
of
them
like
I
was
going
to
say
some
of
them
only
support
ebpf.
But
I
don't
think
that
that's
true
ken
had
said
that
that
psyllium
had
come
into
the
cncf.
Since
last
we
met
or
last
we
gave
an
update
at
kubecon,
and
I
don't
think
that
it's
true
that
psyllium
service
mesh
only
supports
ebpf
as
its
cni.
B
B
Normally,
I
I
have
to
expect
as
people
think
about
opa
and
policies
that
you're
generally
thinking
about
authorization
use
cases
securing
things.
The
logo
kind
of
intimates
that
to
you
that
it's
you
know,
things
are
secure
behind
here,
right
that
there's
a
sentinel
or
but
at
its
core
of
its
capability,
oppa
is
well.
It
allows
you
to
define
rules
and
evaluate
those
rules,
those
policies
and
those
policies,
don't
necessarily
have
to
do
with
authorization
so
to
ken's
example.
B
If
you
want
to
make
sure
that
you
know
that
your
environment
is
ready
to
go
it's
possible
to
define
that
what's
the
right
word
that
but
attest
that
that
attestation
in
a
policy
it
codify
what
it
means
to
be
ready
and
then
eval
use
the
engine
to
evaluate
it
and
so
kind
of
some
interesting
things.
So
we're
yeah,
we'll
see
we'll
see
what
happens
in
six
months
when
we
we
speak
again
if
they're
coming
soon.
B
A
B
And
and
well,
and
so
that
there's
service
mesh
performance,
it's
a
cncf
project,
it
is
it's
currently
sandbox
level
ken
was
highlighting
one
of
its
sibling
projects,
smi
and
so
surface
mesh
performance
is
well.
I
guess
you
know
in
some
respects
much
to
my
continued
surprise
kind
of
a
popular
project
like
so
many
people
have
this
question
around
the
overhead
of
a
service
mesh.
A
lot
of
people
get
the
fact
that
the
service
mesh
can
provide
a
lot
of
value
and
that
it's
becoming
commonplace
kind
of
where
you
find
a
kubernetes.
A
B
Metrics
of
how
many
shopping
carts
are
open.
How
many
are
actually
being
successfully
closed?
How
many
are
being
impacted
by
your
infrastructure
and
to
help
give
people
language
to
speak?
To
about
those
two
things?
Overhead?
You
know
performance
in
context
of
overhead
and
performance
in
context
of
value.
B
The
value
being
derived
meshmark
is
born
as
a
cloud
native
value
measurement
index,
and
so
meshmark
falls
under
the
service
mesh
performance
umbrella
as
a
as
a
component
of
that
project,
and
it
is
well,
it's
actually
the
subject
of
a
talk
this
week
at
servicemeshcon
and-
and
I
believe
that
would
have
already
happened
as
as
everyone
is
getting
this
update
I'll.
So
I
kind
of
described
the
effort
that
ken
and
I
have
spoken
to
about
mesh
mark
and
I'll
I'll
peel
back.
B
There
are
many
utilization
classes
to
quantify
to
to
measure
and
to
understand
how
well
the
infrastructure
is
running
some
of
those,
so
some
of
those
class,
the
classes
themselves,
tend
to
focus
on
a
particular
type
of
resource.
So
if
the
network
is
being
measured,
that
would
be
a
utilization
class,
because
the
network
is
a
resource.
B
You
can
measure
the
network
in
a
number
of
different
ways:
you're
measuring
latency,
maybe
you're
measuring
throughput
or
maybe
you're,
measuring
number
of
errors
or
like
an
on
and
on
and
on
and
on-
and
maybe
some
of
those
are
more
important
to
you
than
the
next.
So
maybe
as
that
util
that
utilization
efficiency
number
is
being
calculated.
B
Maybe
that's
really.
Maybe
the
one
for
latency
is
really
important
to
you
or
not,
and
so
you
can.
The
mesh
mark
itself
allows
for
you
to
assign
a
weight
or
a
discount
a
positive
or
a
negative
weight,
and
so
there's
a
fair
bit
more
to
this.
Ken
has
been
involved
in
the
service
mesh
performance
project
in
meshmark
for
some
time
and
intel
or
a
collection
of
folks
at
intel
have
really
been
I'm
helping
push
this
forward,
and
so
so
real.
A
Quickly
on
that,
you
know
lead
in
touch
on
it,
but
you
can
also
use
things
like
cost
right.
Cost
can
be
one
of
the
utilization
classes
right,
so
the
utilization
classes
are
generic
by
nature,
because
you
can
kind
of
select
the
different
parameters.
You
know
like
in
my
case
where
I
work
security
would
be
a
very
important
utilization
class
right
and
there's
different
aspects
that
we
would
that
we
would
add
to
these
to
the
mesh
mark
performance
for
that
and
weights,
and
so
it's
it
sounds
complicated.
A
It
looks
complicated,
but
when
you
apply
it,
it
makes
a
lot
of
sense
and
and
you're
kind
of
doing
this
in
your
job.
You
just
don't
realize
it
you're
kind
of
inherently
applying
a
a
couple
of
metrics
and
your
own
weights
in
your
head
to
what
you
think
should
be
there.
The
issue
is,
you
probably
don't
apply
it
equally
and
in
the
same
way,
every
time-
and
you
probably
forget
other
things
that
are
important
at
the
time,
but
maybe
another
time
you
remember
them,
and
so
this
sort
of
gives
you
a
what's
nice.
A
Like
the
legal
saying
gives
you
a
standard
way
of
doing
it
and
it's
it's
backed
by
you
know
real
information
that
you
can
show
to
your
leadership
hey.
This
is
why
we
picked
this
choice.
We
looked
at
these
parameters.
We
gave
them
these
weights.
If
they
disagree
with
the
weights,
you
can
change
the
weights
and
re-run
it
and
show
them.
It
doesn't
change
the
result,
but
it
at
least
they
see
why
and
what
you're
doing
so,
it's
a
really
important
effort.
So
so
I
just
want
to
kind
of
throw
that
in
lee.
B
Totally
the
financial
aspect-
yeah,
that's-
that
is
a
great
example
and
the
security
aspect
of
how
it
isn't
just
about
speeds
and
feeds
in
some
respects.
I
guess
you
could
consider
dollars,
speeds
and
feeds,
but
their
dollars
are
definitely
a
resource.
You
can
spend
them
in
different
ways:
opex
capex
and
yeah
yeah
we're
anyway.
The
two
of
us
are
both
excited
about
it,
so
you
know
check
out
the
service
mesh
contact.
B
One
of
the
other
initiatives
that
gets
stewarded
under
the
service
mesh
working
group
is
nighthawk.
Nighthawk
is
well,
I
don't
wanna,
it
is
a
load
generator.
It's
a
layer,
seven
performance,
characterization
tool.
It
was
born
in
the
same
petri
dish
as
envoy.
It
was
born
kind
of
adjacent
to
envoy
written
in
c.
Plus,
it's
been
quite
helpful
as
we
do
a
lot
of
performance
related
analysis.
B
A
A
B
B
Different
types
of
service
meshes
and
deploy
sample
workloads
generate
load,
do
a
performance,
characterization
and
retrieve
the
results
of
those
tests,
and
those
have
been
run
for
a
little
while
so
we're
about
up
to
40
000
test
results
collected,
some
analysis
is
being
performed
and
some
of
those
results
are
being
published
at
on
the
dashboard.
There.
B
Ken
was
mentioning
the
the
past.
The
patterns
about
60
patterns
defined.
Now
I
suspect
there
are
others
like
ken
was
saying,
please
come
and
contribute.
Please
come,
and
you
know
sift
through
the
catalog,
probably
missing
some.
You
might
have
some
that
you'd
like
to
define
so
the
initiate.
While
it
might
not
seem
that
way
up
front.
The
initiatives
are
definitely
well
intermeshed.
B
And
and
as
we
go
to
wrap
up
ken
we
we,
if,
if
we
didn't,
do
it
already,
we're
calling
for
participation,
we're
calling
for
people
to
come
and
join
us
join
us.
You
know
if
you
can
make
the
meeting
times
we
meet
twice
a
month.
So
that's
a
that's
a
great
place
to
to
come
over,
participate,
be
impactful
or
if
the
meeting
time
isn't
conducive
to
your
sleep,
there's
a
slack
and
there's
also
the
mailing
lists,
so
don't
hesitate
if
you
saw
something
that
sparked
your
interest.
A
A
You
know
interesting
topics
for
the
meetings.
We
get
a
good
set
of
individuals,
a
core
group
that
we've
we've
put
together
over
the
last
several
years
and
happy
to
have
you
join
us
and
and
get
involved.
It's
at
any
point
we're
happy
for
that
participation
and
you
can
learn
more
about
us
with
those
mediums
and
kind
of
what
we
talk
about
and
then
who's
involved.
So.
B
Ken
good
question
for
you:
I
get
this
a
fair
bit,
but
you
were
saying:
hey,
there's
the
meeting
minutes
come
jump
in
clarification.
Do
do
individuals,
people
that
want
to
come
participate.
Do
they
have
to
belong
to
a
cncf
member
organization
to
have
a
seat
at
the
table
to
to
come
and
add
to
the
agenda.
A
No,
absolutely
not
we,
we
are
very
open
to
participation
from
anyone
who's
interested.
You
don't
have
to
be
a
member
company.
You
don't
have
to
you,
know,
sign
any
any
blood
with
the
scene
with
the
linux
foundation
to
come
in
and
join
us,
and
we
do
we
do
ask
though
there
is
a
I
don't.
I
don't
think
we
have
access
to
might
get
in
trouble
for
pulling
this
up,
but
we
do
have
in
the
cncf.
A
We
do
have
like
a
code
of
conduct,
and
so
we
we
do
is
you
know
we
do,
expect
you
to
follow
the
code
of
conduct
and
if
you're,
not
a
member
organization,
you
should
treat
everyone
with
respect,
and
you
know
that
kind
of
all
that
really
good
stuff
that
we
we
want
to
make
sure
we're
doing
as
people
as
humans
on
this
earth.
We
don't
want
to
be.
You
know
we
have
enough
mess
to
deal
with
without
having
to
be
mean
to
each
other
right.