►
From YouTube: Episode IV: A New Network Service Mesh - Frederick Kautz, Doc.ai & Nikolay Nikolaev, VMware
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Episode IV: A New Network Service Mesh - Frederick Kautz, Doc.ai & Nikolay Nikolaev, VMware
It is a time of exploding networking complexity. Members of the Network Service Mesh Community, hacking furiously around the clock, have won their first victory for network simplification. During the development, community members discovered a new way to think about Cloud Native networking with enough power to meet the needs of multi-cloud enterprises and telcos alike. Racing across… Frederick Kautz and Nikolay Nikolaev bring you Network Service Mesh, which can unchain developers from legacy networking and restore freedom to networking. Come learn about Network Service Mesh and get the latest updates on the latest features including Inter-Domain connectivity, identity (SPIFFE) and policy (OPA) support!
https://sched.co/ZevK
A
So
today
we're
going
to
go
over
a
few
topics,
the
first
one
for
those
who
of
you
who
are
unfamiliar
with
what
is
network
service
mesh
and
then
we're
going
to
go
into
a
new
set
of
things
that
we
have
been
working
on.
So
we
have
a
new
sdk.
We
have
a
new
use
case
that
we
have
been
working
on.
We
have
integration
with
multiple
cncf
projects
and
and
we'll
discuss
what
we've,
what
we've
been
accomplishing.
B
Yeah
network
service
mesh
is
different
things
to
different
people
when,
when
it
was
designed,
we
the
project,
was
targeting
the
developers,
operators
and
network
function,
vendors
point
of
view,
so
from
a
developer's
perspective,
it
makes
developers
lives
easier
because
they
just
ask
for
connectivity
and
they
work
with
high
level
primitives.
They
don't
have
to
to
bother
with
the
details
of
networking,
which
usually
is
complex
and
hard
to
to
to
work
with
from
operators
perspective.
B
B
So
that's!
That's!
That's
also
one
of
the
goals
for
network
service
match
when
it
started
and
from
network
function,
vendors
point
of
view.
Here
we
have
an
example
firewall
vendor.
You
can
actually
focus
on
the
functionality
on
the
business
logic
of
your
function.
You
don't
have
to
worry
how
it
connects
to
the
rest
of
the
world,
which
typically
was
was
a
big
problem
back
in
the
days
now,
with
cloud
native
and
with
network
service
mesh.
A
It
also
makes
it
very
easy
for
them
to
come
back
in
and
contribute
because
once
they
understand
how
to
build
a
network
service,
then
they
understand
how
the
internals
of
it
work
and
how
does
the
authorization
work,
of
course,
is
details
that
they
may
have
to
read.
But
it's
a
it's
a
much.
It's
a
much
simpler
pattern
and
they
understand
the
architectural
pattern.
B
A
So
this
is
the
network
service
api,
and
so
we
have
everything
is
that
we
do
is
a
grpc
api,
so
we
start
off
with
at
the
very
top.
What
is
the
network
service
and
it
comes
down
to
two
primary
calls?
We
have
a
request
and
a
close.
A
client
can
make
a
request
for
a
service
and
a
client
can
close
their
service
and
simultaneously.
The
same
thing
is
true
about
responses.
A
It
gathers
context
like
a
snowball
and
once
the
system
has
enough
context
to
complete
the
establishment
of
that
connection,
that
same
connection
context
gets
returned
back
all
the
way
back
to
the
user,
which
includes
information
which
may
have
ip
addresses.
Dns
may
have
ethernet
information
if
you're
dealing
with
l2
may
also
have
information
about
who
you've
gone
through
with
cryptographic,
tokens
that
demonstrate
that
you've
gone
through
a
specific
set
of
firewalls
you've
gone
through
a
certain
vpn
or
so
on,
and.
B
A
B
I
would
like
to
outline
one
very
important
thing
here
in
the
api:
it's
the
path
and
the
paths
segment
on
the
left,
so
this
is
a
relatively
new
concept
that
was
introduced
recently
to
again,
not
so
recently
already,
but
I
was
kind
of
new
to
nsm
it.
It
is
inspired
by
some
of
the
more
lower
level
networking
concepts,
but
this
is
brought
to
this
new
high
level.
B
B
When
you
get
this
parts,
you,
like
the
the
the
implementation
knows
where
it
actually,
this
packet
or
actually
its
connectivity,
is
going
to
pass.
Who
are
the
other
players
in
the
system?
If
you
need
to
know
that
and
for
people
that
have
built
networking
solutions
in
the
virtualization
world
are
familiar
with
the
service
function,
chaining
or
as
we
prefer
to
call
it
service
composition
here
in
nsm.
This
is
this
is
really
really
important,
improvement
and
information
that
you
can
have
at.
A
A
B
A
B
A
The
general
flow
of
how
this
ends
up
looking
you
see
a
request
coming
from
from
the
pod
from
a
client,
goes
to
nsm
and
assemble
for
that
request
to
the
network
service
and
then
we'll
configure
the
data
plane
in
order
to
make
sure
that
the
pod
and
the
network
service
are
capable
of
communicating
with
each
other.
What's
key
here,
though,
is
that
nsm
itself
does
not
sit
in
the
data
plane.
It's
it
sits
in
the
control
plane.
So
nsm
does
not
slow
you
down
in
the
data
plane.
B
Also,
when
we
conceptualize
here
when
we
say
nsm
and
data
plane
when
we
talk
about
control
plane,
it's
a
key
thing
to
mention
that
it
is
a
distributed
one.
It's
not
a
center.
It's
not
like
the
traditional
sdn
software
defined
networking
control
planes.
It's
a
distributed,
one
very
much
in
the
in
the
concepts
and
inspired
by
the
consoles
behind
cloud
native.
The
same
is
for
the
data
plane.
It's
not
a
single
entity,
we're
probably
not
going
to
go
into
details.
B
A
The
connection
goes
through
a
series
of
microservices
that
literally
follow
the
exact
same
grpc
api
that
we
showed
you
before
and
so
each
so
we
have
authorized
as
a
as
a
grpc
service
set
id
and
heal
and
so
on,
but
they
don't
connect
out
to
the
outside
world.
They
simply
reuse
the
api
mechanisms
itself,
the
actual
api
interfaces.
A
The
token
generator
doing
discovery,
and
so
on
and
finally
running
through
the
connect
which
then
itself
goes
through
to
the
endpoint,
which
then
itself
goes
through.
The
entire
set
of
things
that
are
like
authorized,
monitor,
making
sure
that
there's
a
timeout
for
the
connection
and
and
so
on
until
it
finally
reaches
the
additional
the
the
additional
functionality,
which
represents
your
network
service,
which
is
the
thing
that
configures
your
firewall
or
configures
your
data
plane,
and
so
this.
A
So
this
pattern
is,
is
followed
over
and
over
again
and
and
so
when
we
said
that
we
that
we're
normalizing
and
make
and
making
it
follow
the
same
pattern
like
we,
we
really
do
mean
it
like
this
is.
This
is
a
this
is
a
pattern
that
allows
us
to
to
make
sure
that
we
have
things
that
are
easily
isolated,
that
we
can
easily
test.
We
can
reuse
in
other
components.
A
You
can
compose
the
things
that
you
want
or
don't
want
to
leave
out
the
things
you
don't
want
and
build
out
a
network
service
that
that
allows
you
to
also
replace
portions
like
if
you
don't
use
the
same
authorization
that
we
use.
Maybe
you
have
your
own,
your
own
service.
If
you
can
write
that
that
microservice
or
if
your
vendor
provides
one
in
the
future,
then
you
can
plug
that
in
and
off
you
go.
B
B
A
Cool,
so
we
have
here
an
example
of
some
code
that
we
pulled
out
so
this
code.
What
it
is
is
is
journaling
specifically,
so
it's
not
it's
not
ipam.
As
the
example
says,
on
the
top,
it's
journal
link,
and
so
what
we're
doing
is
we're
we're
taking
a
result
from
ipad
and
if
you
look
in
the
first
step,
is
creating
the
new
server
and
that
new
server
is
now
living
within
the
within
your
your
service
or
your
endpoint.
A
A
It
is
evaluating
the
rest
of
the
week
of
the
request
first
and
sending
it
through
the
chain
first
and
when
it
gets
the
response
back,
because
it
itself
is
a
client.
So
when
the
connection
comes
back,
that's
been
resolved
as
a
client.
Then
it's
going
to
look
at
the
information.
It's
going
to
introspect
it
and
say
what
ip
interested.
Yet
what
seeders
were
were
in
there?
A
What
connection
paths
do
you
have
and
it's
going
to
then
publish
that
to
mats,
and
so
this
specific
one
was
designed
so
that
we
could
have
ipam
and
you
could
use
whatever
ipam
you
want,
and
then
you
could
stick
a
journal
on
top
of
it,
so
that
if
your
ipad
ever
fails,
then
you
can
using
yet
another
service
replay
that
set
of
decisions
through
your
ipam
and
get
you
that
resiliency
in
an
easy
way
without
having
to
to
mix
together
the
journaling
and
the
ipam
together.
So
it
makes
them
split
up.
B
B
B
Virtualized
layer,
3
connectivity,
for
example,
for
things,
are
that
you
can
build
a
high
level
like
interconnection
of
higher
level
service
meshes
like
we
have
comma
here
and
this
you
given
as
an
example,
but
not
only.
We
have
seen
examples
with
being
able
to
sync
databases:
crazies,
like
cross
data
center
database
replication,
are
built
on
on
that
and
and
other
other
things.
B
The
basic
idea
is
that
you
build
out
a
set
of
small
network
service
meshes
and
you
have
kind
of
gateway
which
is
not
really
the
gateway
that
you
you
would
see
in
the
traditional
kubernetes
on
or
other
setups.
It
effectively
is
a
very
transparent
one,
but,
as
you
can
see
here
on
the
picture,
okay,
it's
a
router
but
effectively.
The
idea
is
that
it
consumes
the
other
remote
routers
as
services,
so
it's
a
kind
of
like
a
service
machine
or
servicemen.
B
So
you
have
your
own
network
service
messaging
in
your
clusters
and
then
the
inter
connectivity
in
between
them
is
again
a
kind
of
a
network
service
mesh
on
its
own
and
when
all
when
these
two
concepts
bind
together,
you
effectively
get
a
kind
of
a
flat
network,
but
also
a
controlled
lan.
One
like
it's
not
that
every
each
and
every
service
in
cluster
one
will
see
each
and
every
service
in
cluster
two.
It's
only
the
members
of
the
particular
service
mesh
with
the
right
securities
settings,
right,
authentication,
set
and
etc.
B
This
effectively
allows
you
to
build
a
set
of
such
virtual
regulatory
networks
that
can
interconnect
all
these
clusters
and,
in
the
same
time,
they
can
work
in
parallel
as
if
as
if
this
connectivity
doesn't
exist.
So
the
workloads
that
live
in
one
of
these
virtual
layer,
3
won't
see
like
the
the
services,
won't
see
the
other
services
and
this
actually
unlocks
a
lot
of
a
lot
of
other
use
cases.
B
We
have
seen
people
that
are
building
much
more
complex
solutions,
and
I'm
sure
federer
can
can
give
better
examples
here,
but
essentially
everyone
that
was
trying
to
interconnect.
Data
centers
and
distribute
services
have
have
some
autobahn
upon
the
obstacles
of
how
do
you
interconnect?
What's
the
ip
of
this
of
this
data
center?
What's
the
subnet
in
the
other
data
center?
Are
there
conflicts
which
dns
I
use
and
etc?
A
A
That's
designed
to
to
take
multiple
dns
service
servers
and
allows
you
to
make
a
call
to
a
specific
one
and
then
have
them
fan
out
the
request
to
others
and
found
them
back
in,
and
you
can
control
that
dynamically.
So
you
can
add
and
remove
servers,
as
you
add,
and
remove
networks
within
your
within
your
system,
and
so
the
one
of
the
next
steps
that
we
are
going
to
accomplish
in
the
near
future
is
the
injection
of
that
dns
into
information
into
network
service
mesh.
A
So
we
already
have
something
to
pass
the
dns
configuration
in
and
out,
but
making
sure
that
it
works
within
the
vl3
use
case
so
that
we
solve
not
only
the
l2
and
l3
use
case
of
getting
that
connectivity
or
specifically
the
l3
connectivity
in
this
scenario.
But
we
also
solve
for
the
dns
problems
that
or
at
least
give
the
tools
to
solve
those
dns
problems
that
are
part
of
a
complete
l3
solution.
B
One
addition
that
I
would
I
would
like
to
add
here
is
when
we
say
clusters
it:
it's
not
necessarily
only
big
data
centers,
it
could
be
an
edge
the
deployment
of
workloads
etc.
So
it's
a
kind
of
a
way
to
unify
your
distributed
infrastructure.
So
it's
not
necessarily
connecting
big
deployments.
It
can
be
small,
a
large
number
of
small
deployments.
B
I
think
that
it's
a
this
is
a
pretty
revolutionary
use
of
the
whole
spifi
and
spire,
of
course,
there's
a
concrete
implementation
of
a
runtime,
because
we're
actually
mo
the
tradition
when
it
was
designed
and
the
additional
way
that
they
that
that
it's
used
in
other
projects
is
that
you
actually
do
this
authentication
on
the
higher
level.
As
you
said,
layer,
four
and
seven,
but
here
you
we're
actually
doing
a
much
much
lower
level,
the
connectivity
level
and
effectively.
A
A
That
you
have
your
pod,
that
has
your
application.
You
have
your
firewall
endpoint,
that
controls
your
firewall,
your
intrusion,
detection,
endpoint,
that
that
allows
you
to
control
your
intrusion,
detection
system
and
etc,
etc.
As
you
as
you
go
down
for
the
chain,
so
there's
a
separation
between
control,
plane
and
data
plane
that
exists
here.
A
When
we
start
looking
at
how
to
do
this,
how
do
we
integrate
spiffy?
What
it
looks
like
is
something
that
looks
like
this.
Every
major
service
gets
an
identity,
so
the
firewall
has
an
identity.
Your
intrusion
detection
system
has
an
identity,
so
when
the
pod
makes
a
request
for
secure
corporate
internet
access
that
the
these
are
the
identities
that
the
operator
can
say,
the
system
must
traverse
through
in
order
for
that
service
to
be
rendered.
In
order
for
that
service
to
to
be
successfully
connected.
B
B
A
Only
bring
it
down
to
the
hardware
to
for
that
performance,
but
also
in
the
in
the
future.
It
should
be
possible
to
have
if,
if
you're
running
your
network
services
on
in
kubernetes
itself,
you
should
be
able
to
actually
tie
them
down
to
the
tpm
module
until
you
can
verify
the
hardware
that
it's
running
on
that
indeed
came
from
you
as
well.
So
there's
a
lot
of
really
interesting
work.
That's
going
on
in
spiffy
that
that
is
above
and
beyond
this
that's
cutting
edge.
A
So
there's
new
work,
that's
going
on
with
transitive
identity
and
new
work,
that's
going
on
towards
how
to
how
to
federate,
spiffy's
trust
domains
together.
So
there's
a
lot
of
more
interesting
work.
That's
coming
out
of
this
and
we're
hoping
not
hoping,
but
we're
in
the
process
of
helping
them
work
out.
What
some
of
those
things
look
like
as
well
within
those
communities.
A
And
so,
finally,
when
you
do
the
connection,
this
is
what
it
ends
up.
Looking
like
from
a
testation
perspective
perspective,
you
have
your
app
your
vpn
gateway,
those
in
fact
those
have
their
spf
id
entities.
You
have
a
trust
between
the
two
organizations,
so
it
gets
you.
This
gives
you
the
ability
to
multi
organizational
trust
with
spivey
inspire
for
your
for
your
workloads.
A
So
the
the
last
thing
to
really
tie
these
things
together
is
open
policy
agent,
and
so
I
pulled
an
example
from
the
repository
and
was
from
nsm
itself,
and
what
this
policy
is
doing
is
it's
checking.
Is
this
token?
The
tokens
that
come
in
so
a
token
that
represents
the
identity
of
everything
that
it's
gone
through?
Are
the
tokens
expired
so
the?
A
So
it's
not
just
a
connection
on
the
outbound,
but
also
the
connections
on
the
inbound,
like
the
client,
also
has
to
ask
a
question
that
the
server
renders
something
to
me
that
I
did.
I
trust
that
I,
that
that
fits
my
policy.
So
your
policy
from
the
from
the
server
side.
You
have
policy
from
the
client
side,
identity
on
the
server
and
client,
both
validating
each
other
and
ensuring
that
they
that
they
indeed
follow
policy.
A
So
with
that,
we
want
to
thank
you
for
your
time
and
for
hearing
what's
new
within
the
network
service
mesh
community
feel
free
to
come
join
us.
We
have
links
here
on
how
to
join
in.
In
the
community
section.
We
have
mailing
lists.
We
have
slack.
Our
slack
community
is
very
active
if
you
post
a
message
on
the
slack
community,
you're
very
likely
to
get
an
answer
quickly,
and
we
also
just
had
nsmcon
eu,
which
just
happened.
A
The
videos,
if
they're
not
posted
already,
they
will
be
posted
in
this
location,
so
come
find
it
over
here
and
as
of
now,
we
have
all
of
our
weekly
meetings
at
7
30
a.m,
for
the
weekly
developer,
pr
meetings
and
at
8
am
pacific
every
tuesday
for
the
general
nsm
meetings
as
well.
So
please
come
come
and
talk
with
us
join
in
join
us
in
slack
have
conversations
with
us
and
we
will
be
around
for
a
few
more
minutes
to
answer
questions.
So
thank
you
very
much.
A
A
B
A
Let's
see
in
terms
of
the
questions,
so
the
first
question
is
I'd
like
to
write
my
first
app
that
uses
nsm
your
slides
show
sarah's
app.
You
have
sample
code
that
implements
a
simple
app
that
I
can
use
is
the
basis
from
building
my
own
simple,
app
that
makes
use
of
nsm.
Does
such
a
repo
exist
in
github?
A
So
what
I
showed
you
right
now
with
the
sdk
is
something
very
new
that
we've
that
we've
built.
We
have
a
an
older
version
of
nsm,
where
we
have
an
examples
repository
and
I
I
will
post
that
example
repository
in
in
slack
in
a
short
while,
but
there's
some
examples
there
that
that
you
can
follow
that'll,
be
very
close,
so
there's
two
levels
of
integration
that
I
expect
to
see
very
common,
at
least
in
the
kubernetes
space.
A
It
didn't
I'm
expecting
there
to
be
pre-canned
apps
like
if
someone
wants
to
connect
two
things
together
that
are
in
different
clouds.
That's
primarily
a
configuration
thing,
and
so
we
want
to
be
able
to
have
nsm,
basically
do
a
helm,
install
on
it
to
get
the
things
running
that
you
that
you
need,
and
then
you
request
for
the
service
after
you've
done
some
basic
configuration
and
it
just
works.
A
The
second.
The
second
thing
that
we
are
expecting
to
see
is
we're
expecting
to
see
people
we're
expecting
to
see
people
eventually
build
out
their
own
custom
set
of
services
and
the
place
to
look
in.
In
that
I
see
I
don't
think
I
have
a
good
way
to
to
show
this
particular
part
off,
but
I'll
post,
another
link
on
there.
That
shows
the
the
code
that
I
showed
before
that
showed
a
chain
you
you
can
base.
A
You
would
implement
your
network
service
using
the
api
and
then,
when
you
instantiate
that
that
chain,
then
that
chain
will
then
make
use
of
all
the
machinery
that
we
showed
just
now
and
we'll
also
run
your
section
of
code
and
I'll
link
to
where
that
chain
is
as
well,
so
that
you
can
so
you
can
see
that
how
that
works
in
terms
of
the
new
sdk,
we
should
have
it
all
up
and
running
pretty
soon.
There's
a
there's,
a
couple
more
things
that
we
have
to
work.
We
do
have
it
working.
A
A
A
A
A
It
will
stand
by
for
a
minute,
or
so
oh
great
question,
so
next
one.
What
is
the
relationship
to
other
projects,
so
other
projects,
the
the
projects
that
I
showed?
I
assume
you
mean
the
the
ones
in
in
the
video,
so
the
other
projects
that
we
discussed
were
spiffy,
inspire
spiffy,
inspire
spiffy
is
a
specification
on
how
to
rotate
identities
and
to
test
them.
A
They
were
just
they're
they're
loosely
coupled
in
that
they
don't
require
each
other
to
to
run.
In
fact,
nsm
does
not
require
spiffy,
inspire
or
robot
to
actually
run,
but
we've
implemented
them
in
default
implementation,
so
that-
and
so
so
that's
how
that
that
particular
part
is
like
the
relationship
between
them.
Now
there
there
is
another
thing,
so
one
an
additional
question
on
top
of
that
is
what
about
things
like
like
damon
and
multis,
and
similar
so
nsm
is,
has
a
different
set
of
goals
from
from
them.
A
So
groups
like
damen
from
nokia
are
designed
to
create
a
interface
that
is
within
a
pod
like
that
is
their
primary
purpose
is
to
be
what's
called
a
cni
multiplexer
nsm
is
orthogonal
to
cni
and
in
fact
it's
also
unopinionated
about
whether
you
decide
to
use
a
cmi
or
not.
So
you
could
you,
you
could
integrate
an
sm.
A
How
do
I
connect
these
pods
together
or
how
do
I
create
the
service
function
chain
together
across
across
systems,
or
how
do
I
configure
the
sdn
to
do
something
special
based
upon
the
requirements
provided
by
by
the
operator
so
to
to
be
precise?
Damn
is
specifically
about
how
do
I
land
using
a
cmi
plugin,
a
secondary
interface
in
my
pod,
while
for
network
service
mesh,
that's
a
implementation
detail
and
we're
working
to
coordinate
what
happens
around
and
enable
enabling
the
machinery
behind
that
that
interface,
through
the
configuration
of
other
sdns
or
or
other
resources.
A
So
hopefully
that
answers
the
question,
and
I
want
to
thank
everyone
for
your
time
and
feel
free
to
reach,
to
reach
out
to
me
we're
in
channel
two
dash
kubecon
dash
maintainer.
There
is
a
thread
where
we
can
continue
these
conversations
and
simultaneously
also
come
join
us
in
the
nsm
channel
within
within
cncf
slack.