►
From YouTube: Webinar: Network Service Mesh – An Introduction
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
Network Service Mesh (NSM) is a community-driven CNCF Sandbox project that is rapidly gaining momentum because of its ability to simplify connectivity between workloads, independent of where they are running. It extends an IP reachability domain to workloads running in multiple clusters, legacy environments, on-premises, or in a public cloud, communicating with the protocols they are currently using.
NSM does this at the granularity of individual workloads. Your workloads have connectivity to just the workloads they need – nothing more, nothing less. NSM brings the useful features of a Service Mesh from the lofty heights of HTTP all the way down to IP itself. Applications and Application Service Meshes, such as Istio, run unaltered on top, leaving the hybrid/multicloud IP connectivity to NSM.
View this webinar to get an introduction to what NSM is all about, how it works, and see a demo of NSM in action!
Presentation Slides: https://docs.google.com/presentation/d/1aG56Oqv7I1JpNsY4VPNpyoKppT-BRyOdYE43fr9ylNs/edit?usp=sharing
A
But
a
quick
introduction
to
myself:
I'm
Lee
Cal
coat
I'm
a
CNCs
ambassador
I'm,
also
the
founder
of
layer,
five,
which
is
a
service
mesh
community.
So
certainly
today's
topic
has
a
vested
interest
for
me
as
we
get
started.
I
do
want
to
note
that
the
Q&A
box
is
should
be
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
in
your
questions
there
as
we
go.
I
did
toss
out
the
challenge
earlier.
That
we've
got
some
seasoned
intellect
to
present
to
you
today.
A
Please
don't
leave
them
bored
bring
your
questions.
This
is
an
official
web
webinar
of
the
CNCs,
and
so
as
such,
it
is
governed
by
the
CNCs
Code
of
Conduct.
So
please
don't
edit
into
the
chat
or
questions
that
would
be
in
violation
of
that
code.
You
know,
basically,
you
know
please
be
respectful
of
your
fellow
participants
today,
if
you
would
so
with
that.
I
welcome.
Some
familiar
faces,
I
think
out
there
in
the
crowd.
So
is
that
Kwan
it's
been
a
couple
of
years,
but
good
too
good
to
see
you
on
the
call
today.
A
I
do
want
to
introduce
our
distinguished
speakers
I'm.
Some
of
what
you
do
actually
literally
carry
that
title
so
with
us
today
to
represent
an
introduction
to
network
service.
Mesh
is
Ed,
Warren,
achill,
distinguished
consulting
engineer
at
Cisco.
Frederick
counts,
ahead
of
edge
infrastructure
at
Daria
and
Nicolai
Nicola
open-source
networking
team
lead
at
VMware
and
with
this
I'd
like
to
hand
it
off
to
them
to
teach
us
about
network
service
much
today.
C
A
little
bit
so
it
often
helps
people
to
understand
where
you're
going
in
the
generic
sense,
and
so
we
thought
we'd
do
a
little
bit
of
an
agenda
here
to
start
out,
we've
got
a
little
bit
of
housekeeping
up
front
of
our
own.
Then
we'll
talk
a
bit
about
the
the
vision
for
NSM.
In
other
words,
what
problem
are
we
trying
to
solve
what
central
insight
have
we
had
that
differs
and
the
way
people
thought
about
that
problem
in
the
past
and
therefore,
what
that
allows
us
to
do?
In
other
words,
what's
different?
What's
new?
C
Then
we'll
well
then
we'll
go
on
to
the
state
of
the
NSM
will
tell
you
sort
of
where
we
stand
right
now
we
do
have
running
code
as
it
stands.
A
pretty
vibrant
community
we'll
talk
a
little
bit
about
some
of
the
cool
things
that
we're
gonna,
be
hopefully
doing
in
the
new
in
the
not-too-distant
future
and
then
we'll
sort
of
do
a
deep
dive
into
some
of
the
more
detailed
aspects
of
network
service
mesh.
As
there
is
time.
C
So
in
terms
of
housekeeping
for
folks
who've
seen
our
talks
before
we're
a
little
bit,
qr-code
crazy.
So
if
you're
watching
this,
you
can
haul
out
your
phone
and
point
to
the
QR
codes
that
will
get
you
to
our
website.
There's
a
QR
code
in
the
bottom
corner
of
every
slide.
That
will
take
you
to
this
slide
deck
directly
and
then,
finally,
we're
extremely
excited
to
be
having
an
ascent
co-located
with
kubernetes
on
November,
8th
with
Duke
on
it
on
November
18th.
So
if
you
follow
that
link,
you
can
get
to
that
page.
C
B
Sure
so
NSM
vision,
so
we'd
start
off
with
some
of
the
the
problems
that
we
have
so
she'll
be
able
to
hit
next
slide
so
part
of
the
partner
we
look
at.
Is
we
look
at
what
at
a
runtime
domain,
so
I
think
of
like
kubernetes
as
being
a
as
being
a
runtime
domain,
where
you
run
your
your
applications
next,
so
one
of
the
that
would
same
concept.
Is
you
also
have
this
concept
of
a
connectivity
domain,
so
connectivity
domain?
B
Think
of
it,
like
you,
use
your
CNI
and
it
connects
your
to
your
connectivity
domain
if
you're
in
you're
in
the
OpenStack.
Well,
you
trying
to
connect
to
your
connect,
your
connectivity
domain
and
so
in
communities
we're
looking
at
an
l-3.
So
looking
at
something
gives
you
a
nike.
You
use
that
IP
to
to
gain
connectivity
to
other
things.
B
B
Move
horde
to
the
a
to
the
next
and
again
so,
when
you
start
to
take
a
look
at
that
part
of
the
problem,
is
that
you
have
all
these
various
applications
that
need
to
talk
to
other
applications
and,
typically,
what
ends
up
happening?
Is
each
you
end
up
having
this
perimeters
and
each
of
them
have
their
own
subnets.
They
have
their
own
things
that
they
bits
of
information
they
need
to
be
shared
in
order
to
properly.
C
You
know:
we've
solved
this
isolation
problem
within
a
specific
cluster
for
the
intra
cluster
networking
for
kubernetes,
and
it
solves
it
well
with
the
level
of
Dyna
Missa
tee
with
pods
coming
and
going
and
so
forth.
But
when
you
start
trying
to
get
things
talking,
we're
close
talking
to
workloads
and
other
clusters,
they're
they're,
not
terribly
great
solutions
for,
inter
cluster
workload,
isolation
for
workloads
that
dynamically
come
and
go
very
quickly.
C
B
And
make
make
matters
even
worse.
One
one
thing
with
kubernetes
is
kubernetes
keeps
track
of
its
service
like
a
range,
but
it
does
not
keep
track
of
of
the
pod
IP
range.
That's
actually
lived
as
an
exercise
for
the
for
the
C&I
plugin
that
you're
using
so
when
you're
trying
to
work
out.
What
do
I,
what
can
I
share
or
what
should
I
conflict
with
or
not
conflict
with,
and
you
start
adding
more
and
more
clusters
and
need
to
communicate
with
each
other.
B
You
end
up
with
this
combinatorial
problem
with
a
lot
of
information
that
needs
to
be.
There
needs
to
be
aligned
with
each
other
and
in
many
scenarios
you're
not
going
to
be
able
to
resolve
the
conflicts
between
them.
So
this,
this
full
mesh
of
connecting
network
to
net
work
ends
up,
ends
up
becoming
very
problematic
and
is
not
an
easy
problem
to
solve.
Without
a.
C
Particularly
when
you
look
at
public
clouds,
where
you
may
have
different
levels
of
isolation,
those
clusters-
and
they
may
have
different
api's
for
you-
how
you
manage
that
isolation
and
different
kinds
of
activities
that
you
do
to
set
up
direct
linkage
between
things.
You
can
get
very,
very
messy,
extremely
quickly
and.
B
C
Even
worse,
the
the
sort
of
dips
that
you
get
for
deployment
between
different
servers
as
deployed
in
different
clusters,
those
urban
any
services,
are
only
good
within
a
specific
cluster
or
exposed
out
to
the
broader
world.
If
you
want
to
say,
share
services
between
these
various
clusters,
that's
that's
a
difficult
problem
and.
C
C
Okay
I
mean
so
like
people
that
have
stepped
forward
and
said,
okay.
Well,
we
get
all
these
problems.
We
you
know,
let's,
let's
do
Federation
right,
so
Federation
is
the
thing
and
it
turns
out
Federation's
a
good
solution
for
certain
problems,
but
it's
actually
not
a
terribly
good
solution
for
this
one.
C
It
kind
of
hides,
rather
than
fixes
the
inter
cluster
linkage
problem
that
you
have
so
it
also
doesn't
scale
particularly
so,
as
you
scale
up
to
large
clusters,
you
start
running
into
all
kinds
of
limitations
in
terms
of
propagating
services
propagating
your
network
policies,
getting
all
the
things
that
support
them
to
scale
up
to
handle
them
properly,
and
so,
as
you
add,
more
clusters
that
you're
trying
to
add
fine-grain
pass
this
information
between
different
clusters
that
may
be
geographically
isolated.
Those
combat
atronics
and
complexity
get
much
much
worse.
Next
slide.
C
And
so,
in
addition,
the
semantics
of
kubernetes
networking
could,
in
principle
be
federated
across
multiple
clusters.
But
again
what
you
care
about
is
your
applications
and
the
ability
of
your
workloads
to
talk
to
each
other,
and
so,
if
you've
got
workloads
that
are
running
as
pods
they're
used
to
getting
pod
semantics.
But
if
you
have
workloads
running
as
VMs
and
most
people
do
or
you
even
have
things
running
on
bare
metal
servers
on
Prem,
then
those
are
used
to
connecting
to
connectivity
domains
that
have
entirely
different
semantics.
C
So
and
then
you,
finally,
when
you
look
at
sort
of
service
mesh,
there
are
lots
of
people
who
have
basically
taken
the
position
service
mesh
is
going
to
save
us.
You
know
just
deploy
a
bunch
of
history
on
a
bunch
of
gateways
and
those
tools
are
fabulous
at
layer
seven,
but
they
don't
actually
do
anything
for
the
l-3
nature
of
this
problem.
The
IP
stuff
right.
C
So,
first
of
all,
you
wind
up
with
the
same
full
mesh,
combat
atronics
problem,
but
you
also
get
the
fact
that
you
still
have
to
pick
up
these
l3
links,
because
what
everyone
presumes
out
of
the
gate
when
they
talk
about
service
mesh,
is
they
presume,
when
you're
up
at
layer
7
that
there
is
some
flat
layer,
3
living
under
you,
where
you
can
reach
everyone
conveniently?
And
you
don't
have
various
weird
math
games
going
on
and
so
forth?
B
But
something
that
that
also
adds
to
a
problem
as
well.
So
you
consider
the
the
cloud
environments
like
the
number
of
times,
where
I
needed
a
cluster
to
do
something
so
I
just
hop
onto
gke
or
or
AWS,
which
ek
has
to
just
spin
up
another
cluster
to
handle
some
set
of
workloads
and
I
wanted
to
connect
into
to
some
to
some
other
service.
That's
that's
out
there.
By.
B
If
you're
spinning
up
isolated
environments,
then
it
becomes
easy,
but
if
you
want
the
system
to
to
interact
with
other
with
other
kubernetes
clusters
that
are
running
along
long,
we
have
services
on
your
behalf.
But
you
want
to
create
that
isolation.
You
know,
and
as
part
of
your
operational
modeled
and
like
these
types
of
problems,
and
they
end
up
occurring
much
more
often
because
of
how
people
tend
to
use
kubernetes
and
and
how
they
tend
to
spend
things
up
in
the
cloud.
C
Cool,
so
this
is
sort
of
the
central
realization
of
network
service
mesh
right.
So
we
a
lot
of
people
been
looking
at
this
problem.
It's
been
very
painful
for
a
long
time
and
so
the
central
realization
for
network
service
mesh
came
down
to.
Why
are
we
welding
our
connectivity
domain
to
our
runtime
domain?
Why
is
it
that
every
workload
in
a
particular
cluster
only
gets
access
to
networking
that
makes
sense
within
the
context
of
that
cluster?
C
You
know
it's
a
very
strange
presumption
when
you
think
about
it,
because
we're
a
thing
runs
and
the
kinds
of
things
that
needs
to
talk
to
are
not
necessarily
intrinsically
related.
It's
an
accidental,
a
historical
accident
in
the
system
that
puts
in
this
place
next
slide,
and
so,
when
you
really
think
about
it,
what
you
realize
is
what
you
really
care
about.
Is
workload
workload
connectivity,
independent
of
where
those
workloads
are
running
right.
C
So
if
I
have
a
collection
of
things
that
need
to
talk
to
each
other,
then
they
should
be
able
to
talk
to
each
other
with
whatever
kinds
of
stuff
the
network
is
supposed
to
do.
If
it's
doing
the
based
load.
Balancing
if
it's
providing
some
policy
based
isolation,
whatever
whatever
those
things
are
they're
not
supposed
to
do
as
it
talks
to
its
peer
workloads,
those
should
happen,
no
matter
where
the
workload
is
running,
not
only
if
that
workload
is
running
in
the
same
cluster
in
the
same
yo
virtual
machine
zone
in
the
same
data
center.
C
All
of
those
are
things
that
developers
don't
care
about.
They
care
about
their
workloads.
Communicating
next
slide,
so
this
is
kind
of
our
network
service.
Mesh
comes
in,
so
we've
rethought
the
problem
entirely
right.
So
we
said:
okay
leave
the
intra
cluster
networking
alone
right
that
works,
let
it
be
so.
What
network
service
semester
on
this
does
is
completely
orthogonal
to
CNI.
We
don't
interfere
with
Siena.
C
You
don't
have
to
run
a
special
CNI
plugin
we
take
great
care,
is
not
to
mess
with
the
inter
cluster
networking
you're
used
to
so
it's
harmless
to
your
existing
kubernetes
networking,
but
what
it
does
is
it
allows
the
workloads
that
you
have
running
to
connect
to
new
connectivity
domains
and
those
connectivity
domains
can
provide
whatever
connectivity,
security
and
observability
features.
You
need
to
connect.
You
need
for
that
connectivity
domain,
so
we've
got
a
couple
of
examples
here
so
say.
For
example,
I've
got
pods
that
are
running
databases
that
do
some
kind
of
database.
C
Replication,
say
I
decide
that
I
want
to
have
read
replicas
per
cluster
and
the
replication
protocol
is
not
running
over
HTTP.
It's
some
weird
thing
your
database
vendor
put
together,
so
you
need
l3
reach
ability.
The
connectivity
domain
you
logically
want
is
a
database
replication
connectivity
domain
that
gives
you
pure
l3
connectivity
between
the
database
replicas
wherever
they
may
be,
and
when
new
database
replicas
come
up,
you
want
them
to
also
be
plugged
into
that
connectivity
domain.
C
Even
if
it's
the
case
that
they're
coming
up
in
things
that
are
not
proven
in
these
clusters,
that
are
say,
legacy
VM
or
bare-metal
environments
at
another
example
here
would
be
sto
connectivity
domains.
The
in
SKU
issue
as
a
tool
is
brilliant
at
what
it
does
at
layer
7,
but
these
layer,
7
service
meshes
tend
to
presume
a
flat
l3
under
them.
So
why
not
just
give
them
one?
You
could
run
a
single
sto
instance
over
an
l3
domain
and
how
the
different
pods
from
different
clusters
connect
into
it
and
reach
each
other.
D
So,
to
add
to
this
the
beauty
of
it
and
I:
don't
I,
don't
know
if
we'd
be
able
to
get
to
how
he
cooperates
today
within
kubernetes,
but
the
beauty
of
it
is
that
is
actually
you
can
ask
for
these
services
at
runtime,
so
you
don't
have
to
press
set
up
your
pots
before
before
they
get
instantiated
with
all
these
connections
inserted,
set
it
sometime
in
the
middle
of
their
lifetime.
They
can
just
say:
oh
I
need
to
replicate
my
dental
base
database
somewhere.
D
C
So
if
you
have
some
giant
Oracle
database
running
on
a
piece
of
hardware
out
in
the
middle
of
god-knows-where,
and
you
would
like
it
to
be
able
to
feed,
read
replicas
running
in
your
clusters
in
various
public
clouds,
that's
exactly
the
kind
of
use
case
that
we're
aspiring
to
with
things
like
our
database
replication
domain
and
as
far
as
the
workload
running
on
the
server
knows,
life
is
normal.
It
doesn't
have
to
do
anything
weird
or
funky,
and
the
same
is
true
with
the
pods.
B
Yeah
just
to
finish
that
concept
of
as
well.
So
one
thing
you
don't
see
in
this
scenario
is
you
have
a
comp
remand
you
might
have
like.
Let's
say
your
kubernetes
is
on
in
a
cloud
environment.
So
one
thing
that
you
don't
see
in
the
CLO
or
this,
this
peach
colored
line
is
the
what
it.
What
goes
into
building
that
that
connection,
so
you
have
to
go
through
firewalls,
VPN
or
other
similar
things
to
to
reach
to
your
to
your
cloud
environment.
B
So
all
of
that
is,
it
still
exists,
but
it
gets
abstracted
into
into
that
connection,
and
so
what
important
part
of
MSM
is
to?
Is
it
from
the
point
of
view
of
the
application
developer?
Do
you
you
asked
for
the
thing
that
you
want
to
connect?
You
like,
please
give
me
axes
a
database
or
please
give
me
access
to
the
sto
environment,
but
from
the
from
the
point
of
view
of
the
operator
the
operator
says:
well
what
does
that
really
mean?
B
That
means
I
have
to
go
through
this
intrusion
detection
system,
this
firewall
and
drive
it
all
through
through
policy.
So
there's
a
lot,
there's
there's
something
goes
on
here:
they
don't
necessarily
see
but
from
an
application
developer
perspective,
and
so
it
ends
up
simplifying
your
your
your
life
for
this
scenario,
because
you
get
to
you
get
to
abstract
those
away
and
there's
they're
still
there
they're
still
important,
but
they
they're
the
complexity
is,
is
controlled
for
you
and
that's
big,
clear,
a
path
by
by
your
by
your
operator.
B
C
One
of
the
quick
thing
I
think
we
could
come
at
at
the
beginning.
You
know
I
didn't
come
in
at
the
beginning
that
you
guys
should
ask
questions
as
you
go,
we're
perfectly
comfortable
asking
questions
that
I
know
we
had
one
attendee
who
raised
their
hands.
If
you
could
add
any
question,
you
have
the
Q&A
box.
We
also
had
a
really
interesting
comment
about
think
of
it
then
ascend
as
ethnicity
and
controller.
C
That's
a
super
astute
way
to
think
about
it,
but
with
one
really
fascinating
twist
network
service
mesh
is
in
the
business
of
handling
virtual
wires,
not
virtual
switches.
So
we
sort
of
made
a
very
fundamental
error.
When
we
went
virtual,
we
had
these
switches,
we
were
used
to
pricing
by
the
port,
and
so
we
we
had
these
Knicks
that
we
were
buying
that
were
very
expensive
for
our
servers,
and
so
we
internalized
the
notion
that
wires
were
expensive,
but
once
you've
paid
the
purport
cost.
Well,
you've
already
got
the
switch.
C
It
does
all
the
switching
features,
but
it
turns
out
in
the
virtual
world
virtual
switching
is
extremely
expensive
and
complicated
to
manage
and
you
don't
want
to
make
that
the
central
element,
but
virtual
wires
are
incredibly
cheap
and
so
network
service
mesh.
You
can
think
of
in
some
ways
as
an
SDN
controller
for
virtual
wires
and
we
leave
as
an
exercise
to
the
people
providing
the
network
services,
what
kind
of
network
services
they're
providing
and
how
they're
going
to
manage
them.
So
there's
a
huge
amount
of
flexibility,
Thank
You,
Mohammed,
Atta,
Luka
chat.
B
C
There
are
intermediate
elements
that
we
call
proxy
networks
service
managers
that
can,
when
they
get
a
request
from
for
any
new
virtual
wire
from
this
workload,
they
can
tweak
whatever
knobs
have
to
be
tweaked
for
the
particular
environment
you're
in
to
allow
you
to
get
that
virtual
wire
strung
between
the
workload
and
environment,
a
runtime
environment,
a-and,
the
workload
and
runtime
environment
B,
and
so
that
architectural
e
gives
us
the
flexibility
such
that
for
any
environment.
You're
in
that
literally
has
the
capacity
to
you
connect
to
another
environment.
C
D
So
quickly,
what
this,
what
is
the
status
of?
What
is
the
state
of
any
sample
a
so
back
in
April,
I,
believe
and
I,
say
most
accepted
as
a
sandbox
project
within
the
cognitive
computing
foundation?
We
are,
you
know,
receiving
the
other
needed
support
being
such
project
and
we
are
kind
of
reviewing
and
aspiring
to
become
proper.
D
D
So
within
the
this,
the
CNF
test,
beds,
old
CNF,
is
essentially
called
native
networking
functions
for
those
that
are
not
familiar
with
this
term.
This
is
essentially
the
considered
to
be
the
next
level
of
next
networking
function.
Virtualization
concept
developed
like
six
seven
years
ago,
we
started
with
virtual
machines,
are
now
a
lot
of
telco
parts
and
service
providers
are
looking
into
this,
as,
as
the
next
step
stepped
into
the
evolution
of
the
networking
virtualization.
This.
A
D
Essentially
something
that
it
has
been
announced
last
week
at
the
open
networking
submitters
initiative
that
is
going
to
become
much
more.
We
make
a
lot
more
sense
within
the
telco
world.
The
table
domain
we're
proud
to
be
there
and
to
be
part
of
there
after
there
are
a
couple
of
use
cases
already
in
Ableton
and
we
are
working
with
them
closely
and
continue
to
do,
but
more
and
more
use
cases.
D
C
B
Yeah,
so
one
of
the
things
with
MSM
is
NSM
itself
doesn't
actually
provide
the
data
plane
itself,
but
rather
we
interact
with
with
data
planes
so,
for
example,
the
initial
reference
architecture
that
we
built
used
VPP,
which
is
also
part
of
the
final
project
which
is
under
the
elephant.
So
we
are
talking
with
people
from
tungsten
fabric
to
to
do
the
same
thing
with
with
them
as
well,
so
one
option
is
to
use
them
as
a
potential
data
plane.
B
The
second
thing,
as
well
is
tungsten
fabric,
has
a
set
of
network
functions
that
that
we
may
be
able
to
to
connect
people
to
or
connect
services
or
applications
to
so
so
part
of
the
idea
would
be
to
how
to
how
do
we
expose
those
network
functions
and
help
them
become
more
cognitive
in
their
in
their
design
and
NSM
can
help
connect
things
to
it
and
help
foster
some
of
some
good
practices
towards
towards
those
goals.
So
there's
some
ensured
it's
it's
not
really
like
an
apples
to
apples
comparison.
It's
more.
B
C
One
thing
that
might
help
curb
some
of
the
confusion
is
network
surface
mesh,
straightens
virtual
wires
between
workloads
and
network
services,
connectivity
domains,
if
you
will,
but
it
doesn't
actually
provide
the
network
services
itself
right.
That's
something
that
you
have
lots
of
people
with
lots
of
different
things,
and
someone
just
asked
if
you
elaborate
more
on
the
virtual
wire
concept.
C
So
if
you
think
fundamentally,
what
a
wire
is
about
a
wire
is
literally
something
where,
if
you
shove
packets,
in
one
side,
they
come
out
the
other,
and
if
you
show
packets
in
the
other
side,
they
come
out,
you
know.
So,
basically
you
show
them
one
side
that
comes
off
the
other
and
that's
effectively.
C
What
network
service
mesh
does
is
if
you've
got
a
workload
like
a
pod,
we
will
drop
an
interface
like
object
into
your
pod
and
take
care
of
all
the
niceties
so
that,
if
you
say,
try
and
reach
something
that
happens
to
be
available
from
the
network
service
that
that
interface
goes
to
your
packets
will
go
out
that
interface.
It
will
travel
over
the
virtual
wire
and
it
will
arrive
at
whatever
is
providing
your
network
service.
That
might
be
another
pod,
that's
doing
user
space
packet
processing.
C
It
might
be
some
VM
running
somewhere
else
than
the
in
your
new
world.
It
might
even
be
physical
network
gear,
that's
being
managed
by
an
SDN
controller,
but
all
network
service
mesh
does
is
it
allows
the
workload
to
ask
for
and
get
routed
to,
someone
providing
that
network
service,
its
request
for
outage
somewhat
variety,
the
network
service,
and
it
allows
the
someone
providing
the
network
service
to
say.
C
Okay,
here's
how
you
connect
a
virtual
wire
to
the
network
service,
I've
prepared
for
that
requester
and
then
an
SM
will
see
to
it
that
we
string
up
the
virtual
wire
so
that
packets
get
where
they
need
to
go.
And
so
that's
why
I
know
I
think
it's
actually
incredibly
complimentary
to
more
sort
of
traditional
Sdn,
because
we
don't
do
something
like
trying
to
configure
all
of
your
network
switches
for
you
so
that
they
do
some
complicated
routing,
switching
behavior.
C
C
D
That
we
can
say
that
in
general,
this
we
from
NSF
point
of
view.
This
would
be
a
networking
function
which
runs
on
top
of
anything.
We
just
provide
the
functionality
for
it.
So
if
you
want
to
do
any
traffic
polishing,
it
will
need
something
that
that
is
a
matter
of
implementing
it
as
a
function.
I
just
want
to
add
something
to
whatever
it
was
saying
on
the
previous
question,
so
probably
one
of
my
favorite
in
sweet
NSM
is
the
fact
that
we
don't
care
about
the
type
of
the
payload.
D
So
if
I
were
to
invent
my
own
type
of
payloads
and
I
I
like
that,
there's
nothing,
nothing
binding
me
within
NSF
to
any
particular
Protocol
or
IP,
or
a
teammate
or
whatever.
If
I
won't
be
bad
I,
don't
protocol
I
should
be
able
to
connect
both
worlds
out.
Both
work
clothes
sitting
on
both
ends
of
the
virtual
wire,
and
they
should
be
able
to
talk
their
own
protocol
whatever.
So
this
is
I
think
that
is
one
of
the
fundamental
things
that
NSF
is
introducing.
D
C
So
cool
so
getting
back
to
things
and
I
know
we're
getting
some
very
detailed
questions.
I'd
encourage
folks
with
more
detailed
questions,
if
also
dropped
by
the
network
service
mesh
time
network
server
special
on
the
CNCs
slack.
We're
delighted.
To
put
you
guys,
we
have
lots
of
collateral
on
some
of
the
details
so
getting
back
to
the
CI.
This
is
actually
something
we're
very
proud
of.
You
know
service
mesh.
We
run
for
every
PR
that
comes
in.
C
We
run
our
CI
on
a
KSDK,
sgk
and
vanilla
kubernetes
running
on
packet,
and
we
the
reason
we
do.
That
is.
We
want
to
make
sure
that
we
ubiquitously
run
everywhere,
and
there
are
some
tiny
little
nips
between
these
environments.
Then
we
just
want
to
make
sure
that
we're
not
getting
stuck
on
any
of
them
and
we
currently
run
449
tests
across
this
clusters
to
ensure
that
everything
is
actually
still
working
all
the
time
and.
D
A
C
Let
me
go
ahead
and
see
if
you
think
so,
we've
got
this
thing,
we
call
resiliency.
Do
you
want
and,
as
you
might
imagine
it's
because
we've
had
smarter
ideas
since
then,
we
would
like
to
do
and
effectively
what
this
comes
down
to
is,
if
you
could
imagine
stringing
these
virtual
wires
that
connect
your
workload
to
some
network
service.
C
You
know
if
you
were
running
an
application
service
mashup
at
layer,
seven-
and
you
know
some
replicas,
that's
providing
the
yos
some
micro
service
somewhere,
that's
a
replica
providing
the
service
you
want
goes
down,
you
just
get
routed
to
another
one
and
you
get
what
you're
supposed
to
get.
We
do
that
kind
of
Auto
healing
right
now
in
network
service
mesh.
So
all
the
many
elements
can
can
go
away
one
by
one,
so
you
could
lose
the
local
Ford
or
on
your
crouppen,
never
surface
mesh
for
it
or
on
your
node.
You
could
lose.
C
You
lose
any
of
the
network
service
managers
in
the
process.
You
could
even
lose
the
thing,
that's
providing
your
network
service
and
it
becomes
a
blip
right
as
soon
as
that
piece
comes
back.
We
will
reestablish
your
connectivity
to
your
network
service
and
you're
back
in
business,
so
you're
looking
at
you
know
a
few
seconds
of
outage,
as
opposed
to
a
oh
wait.
Your
workload
is
screwed
and
that
kind
of
resiliency
is
super
important
because
things
fail
right.
We
know
they
do
and.
D
D
C
So
Dennis
is
interesting
because,
obviously
you
need
DNS
right
but
effectively
what
it
comes
down
to
is
that
we
need
to
make
sure
that
you
get
what
you
expect
from
your
kubernetes
DNS
in
your
pod
all
the
time.
But
it's
also
true
that
when
you
connect
to
a
network
service,
it
may
also
have
DNS
that
it
needs
to
provide
you.
C
So
if
you've
met
a
database
replica
domain,
you
might
want
to
be
able
to
look
up
by
name
whoever
the
master
is
for
your
database
replication
in
that
domain,
and
so
that
that
ends
up
being
a
super
interesting
problem.
The
good
news
is
the
DNS
protocol
is
super
well
done
for
the
most
part
for
this
kind
of
problem,
and
so
we
literally
have
a
little
DNS
sidecar
that
will
fan
out
and
multiplex
your
DNS
requests.
So
when
you
make
a
DNS
request,
we
will
send
it
to
the
kubernetes
theosophy
yeah.
C
They've
got
a
brilliant
job
of
issuing
authentic,
a
double
identities
so
that
when
your
workload
comes
up-
and
it
says
I
want
to
connect
to
your
database
replication
domain,
you
can
actually
know
who
that
workload
is
at
a
semantic
level
and
know
that
authoritative
lis,
and
what
that
allows
you
to
do
is
to
be
able
to
add
a
very
fine-grain
say.
Instead
of
go
and
configure
a
bunch
of
firewall
rules
with
IPS
which,
given
the
pods
coming
to
an
IP,
shift
all
the
time,
it's
a
really
hard
problem.
C
You
know
verging
on
impossible.
You
could
use
spiffy
inspire
to
issue
a
deputies
to
workloads
such
that
when
those
workloads
come
up.
You
know
semantically,
who
they
are,
and
you
can
make
policy
decisions
about
whether
they
should
be
able
to
connect
to
that
connectivity
domain
at
a
semantic
level.
Instead
of
trying
to
lunge
a
bunch
of
IPs
and
ports
around
so
real
quickly,
we
do
have
some
questions.
C
Midi
so
I
think
what
you're
asking
one
is:
could
I
use
the
identity
of
the
workload
to
decide
whether
it
can
access
a
connectivity
domain
rather
than
having
to
have
something,
try
and
look
at
its
traffic
to
figure
it
out?
If
that's
what
you're
asking
then
absolutely
you
could
do
that.
In
fact.
That's
that's
part
of
the
whole
point
about
this
50
spire
stuff
and
then
we've
had
question
from
Scott.
That
said,
as
an
employee,
I
suppose
I
have
to
say
aw
darn.
C
It
sounds
like
you
don't
test
this
stuff
and
IBM
cloud
cover
any
service
so
Scott.
What
I
would
say
is
we
would
love
to
if
IBM
wants
to.
You
know
donate
some
time
for
us
to
do
so
and
have
someone
come
in,
you
know,
come
out
and
help
us
get
it
working
we're
actually
in
favor
of
testing
this
any
and
everywhere
we
can.
So
if
you
have
a
kubernetes
environment,
that's
not
being
covered,
yet
we
would
love
to
work
with
you
dropped
by
the
slack
channel.
We
would
love
to
that
going
cool.
C
It
seems
like
one
remote
has
indicated
that
his
question
was
answered
cool.
There
was
a
question
about
on
the
chat.
Is
it
correct
to
imagine
this
is
a
double
overlay,
or
does
it
complement
existing
CNI?
So
no
none
of
our
traffic
actually
runs
over
CNI
we're
completely
orthogonal
to
CNI.
We
leave
CNI
alone.
We
do
not
mix
with
CNI.
We
take
great
care
to
make
sure
that
CNI
is
unharmed
in
the
course
of
all
of
this.
So
we
are
not
running
over
CNI.
B
In
fact,
the
fact
that
we
hook
in
with
VMs
on
Prem,
like
she
and
I,
actually
becomes
a
limiting
factor
in
that
scenario
and
see
and
I
also
focuses
primarily
on
El
through
tunnel
3
connectivity
domains.
So
when
you
serve
people
in
l2
domains
or
more
esoteric
systems
like
MPLS
or
Saund
and
CNI,
the
inner
fit,
the
actual
interface
itself
is
is
limited.
In
that
scenario,.
C
Cool
yeah
awesome,
yes,
I
mean
we
have
another.
One
here
is
from
Nomura
Nura.
What
about
caseworker
ribcage
turns
over
VMs
and
what
I
would
basically
say
there
is
I,
cannot
save
you
from
any
sins.
You
might
be
committing
underneath
the
covers
for
your
nodes.
So
if
you're
running
over
k,
eights
and
your
case,
nodes
are
running
in
VMs
and
your
whatever
is
connecting
your
VMs
is
doing
all
kinds
of
crazy
and
cap
stuff.
I.
Don't
even
have
visibility
into
that,
and
so
there's
nothing.
We
can
do
to
save
you
from
that
now.
C
If
you
wanted
to
do
something
that
would
punch
past
that
we
do
have
mechanisms
in
the
architecture
for
you
to
introduce
a
network
service
manager
that
could
signal
it.
So
we
also
have
something
from
Mohammed.
What
it
went
is
the
planning
for
the
official
release.
We
do
have
a
0.1
release
that
we
put
out
a
few
months
ago.
It's
definitely
sort
of
a
pre-alpha
stage,
we're
hoping
be
good
as
0.2
release
out
before
Q
Khan
and
NSM
Khan
in
November,
and
you
know
so
that
that's
sort
of
where
in
timeline
time
what
timeline-wise
on
this.
B
You're
great
yeah
lemme:
can
he
helped
if
people
are
willing
to
give
as
well
to
help
us
progress
that
we
would
more
than
we
more
than
appreciate,
and
even
if
that,
that
help
could
even
be
in
regards
to
like
the
previous
example,
with
IBM
time,
you
know
like
we'll,
find
things
through
that
integration
that'll
help
us
improve
the
overall
stability.
So
you
know
it's
yeah
feel
free
to
help
us
get
there
as
well.
If
this
is
something
useful.
C
So
future
stuff,
resiliency
v2,
so
I
mentioned
resiliency
v1
earlier,
where
you
could
lose
any
one
aspect
of
the
system
and
bring
it
back.
We've
got
a
smart
idea
and
I
won't
go
into
the
details
with
resiliency
v2,
where
we
think
we
can
get
to
a
place
where
you
could
lose
basically
everything
except
the
workload
simultaneously,
and
we
would
still
be
able
to
restore
your
connectivity
and
just
have
it
be
a
blip.
That's
going
to
be
super
cool.
C
So
we've
also
got
some
folks
working
on
SEO
on
top
of
NSF
I
mentioned.
This
is
an
example
of
having
an
sto
domain
R
on
top
of
a
network,
surface
mesh
network
service
or
connectivity
to
main
we
do
have
people
poking
at
that
in
the
community
to
get
that
up
and
working
next,
so
I
mentioned
spiffy
inspire
earlier
for
being
able
to
give
you
authenticate
able
identities.
C
This
is
all
super
cool,
but
the
last
next
piece
we're
hoping
to
bring
in
is
open
policy
agent
to
allowing
you
to
bring
in
very
flexible
policy
as
to
admission
control
into
a
network
service.
So
what
a
workload
connects?
You're
gonna
fairly
involve
policy
about
whether
it
should
be
allowed
to
connect
to
that
Network
Service,
there's
another
one
that
we've
had
some
people
mulling
over
and
this
this
one's
going
to
be
cool
when
it
comes
together.
There's
been
some
interest
in
packet
capture,
observability
so
having
a
network
service,
the
connectivity
domain.
D
C
Now
you
know
this
is
clearly
not
something
that
should
happen
by
default,
but
if
you're
really
explicitly
asking
for
it,
there
are
a
lot
of
interesting
things
you
could
do
with
this,
and
so
we
have
people
looking
at
what
it
would
take
to
make
this
possible
with
every
service
mesh.
We
don't
currently
have
that,
but
a
good
example
of
this
would
be
right.
C
Now
most
people
insert
an
envoy
sidecar
into
the
pod,
with
the
workload
which
means
that
it
life
cycles
with
the
workload
for
mystia,
but
we've
had
people
who
sort
of
mused
that
it
might
be
nice
to
be
able
to
insert
that
envoy
sidecar
as
a
network
service,
because
then
you
can
lifecycle
it
independently
for
the
workload.
So
if
you
have
a
long-running
workload-
and
you
discover
there's
an
issue
with
your
envoy,
you
can
upgrade
your
envoy
way
to
something
that
doesn't
have
issues
without
having
to
disturb
your
long-running
workload.
C
A
Over
there,
a
couple
of
questions
that
maybe
we'll
all
raise
up
just
to
make
sure
the
complete,
but
the
I,
think
virtual
wire
concept
and
how
it
was
being
explained
that
NSM
is
the
facilitator
of
the
connector
of
different
domains
and
of
the
right.
You
know
establishing
signaling
for
the
right
connectivity,
but
that
edit
describing
before
I
think
is
a
little
bit
of
you
would
help
us
you.
We
articulated
how
it
is
that
the
actual
connectivity
happens.
B
B
B
C
But
if
you
sort
of
think
about
this,
when
you
talk
about
any
kind
of
a
service
match
at
any
level,
most
of
the
time
when
people
talk
about
as
much
as
they're
talking
about
application
service
meshes
which
live
up
at
layer
seven,
but
we're
talking
about
a
network
service
mesh,
it
does
many
of
the
same
things
you're
used
to
in
a
service
mesh
only
it
does
them
for
payloads
that
are
layer
two
earlier
through
payloads,
IP,
packets,
etc.
And
so
you
anytime,
you
have
a
certain
mesh.
C
C
Cool,
so,
if
you
think
about
this
in
the
kubernetes
context
right,
so
if
you've
got
a
node,
what
we're
calling
a
network
service
manager
domain
here
when
a
pod
comes
up
and
says,
hey
I
need
this
network
service,
then
it
indicates
that
with
an
annotation,
the
network
service
manager
sends
a
message.
That's
to
the
registry
essentially
saying
find
me
a
network
service
endpoint
that
provides
that
network
service.
C
It
gets
back
a
bunch
of
interesting
information
that
tells
that
what
network
service
in
points
will
provide
it,
and
also
you
know
how
you
know,
what
policies
it
should
apply
in
terms
of
selecting
from
the
candidates.
It
then
turns
around
and
asks
its
peer
network
service
manager
for
the
one
that
it's
the
network
service
input
it
selects
hey,
I
really
do
want
a
virtual
wire.
If
you
will
to
this
network
service
endpoint
service
manager,
there
doesn't
work
at
that
point.
C
Now
this
particular
interface
like
thing,
if
you're
a
normal
application,
that's
going
to
be
a
kernel
interface,
but
if
you're,
actually
a
sophisticated
packet
processing,
machine,
you're
gonna
get
something
better
than
a
kernel
interface
or
you
should
be
asking
for
something
like
meh,
my
F
or
something
of
that
nature,
because
kernel
interfaces
are
very
slow
if
you're
a
packet
processing
machine
and
you
sort
of
get
that
virtual
wire
in
place
there
again.
This
is
a
very
abbreviated
description
of
the
process.
C
C
So
we've
got
question
from
Pierre
Luiz.
How
do
you
ensure
symmetry
with
redundancy
with
these
virtual
wires
when
you
connect
pawns
to
a
centralized
stateful
service?
Okay,
so
effectively?
This
is
an
interesting
question.
Pierre
you're
sort
of
asking
something
like
do
we
do
we
connect
up
two
virtual
wires
and
the
answer
is
not
by
default.
By
default,
we
will
fall
back
to
auto
key
line,
but
then
your
second
question
is
about
stateful
services.
C
What
happens
if
you're
connected
to
one
instance
of
a
stateful
service-
and
that
goes
away-
and
we
need
to
reconnect
you
to
another
one,
and
the
answer
is
the
problem
of
sharing
state
between
different
and
different
network
service.
Endpoints
that
are
providing
a
network
service
is
the
responsibility
of
the
person
who
writes
that
network
service,
those
network
service
endpoints.
C
We
don't
enforce
any
particular
way
that
you
do
it
on
them,
so
that's
really
up
to
them
to
handle
in
the
way
that
makes
sense
for
the
network
service
they're
providing
and
there
are
a
bazillion
we
network
services
people
want
to
provide.
So
we
really
can't
effectively
pick
one
true
whether
they're
cool,
so
we've
talked
a
little
bit
about
this
already
inter
domain,
so
we've
got
a
bunch
of
examples
of
domains
when
we
talk
about
these
and
these
are
sort
of
network
service
registry
domains.
C
These
are
places
where
you
might
have
network
services,
so
you
can
imagine
having
two
different
public
clouds.
Each
of
them
have
different
clusters
and
you
might
treat
each
of
those
clusters
as
a
network
service
domain
and
every
service
registry
domain,
and
you
give
them
different
names,
and
these
intentionally
look
a
lot
like
DNS,
because
we're
used
to
thinking
in
DNS.
You
could
also
imagine
in
an
enterprise
having
network
services
or
clients
for
network
services
running
in
a
virtual
manager.
That's
running
a
bunch
of
ems.
C
You
can
imagine
it
running
in
a
physical
network
that
might
have
a
bunch
of
DC
things
happening
with
physical
servers.
All
of
these
are
network
service,
mesh
domains,
and
so
the
question
is:
how
do
you
connect
them
in
network
service
Mash?
Then
again,
this
is
going
to
be
highly
abbreviated,
so
I
do
apologize
a
little
bit
of
time
and
so
effectively
what
ends
up
happening
in
is
you
you
get
the
clients
coming
up
in
the
normal
fashion.
C
The
network
service
manager
goes
and
looks
things
up
in
the
normal
fashion,
and
it
ends
up
making
its
request
to
what
we
call
a
proxy
network
service
registrar
within
its
cluster.
We've
got
a
reference
implementation
of
that
they
can
fall
back
to
DNS
in
order
to
find
via
service
record.
Whoever
the
network
registrar
is
for
that
domain.
Please
note
this
is
not
the
only
way
you
can
do
it.
It's
just
the
reference
implementation.
We've
done.
That
then
proxies
that
request
to
the
network
service
registry
registrar
and
then
the
other
domain
gets
back
its
response.
C
The
network
service
manager
can
then
go
and
we're
showing
the
simple
version
here.
It
can
make
its
request
to
its
peer
and
set
up
the
connection,
so
I
think
we're
running
up
against
time,
so
we
probably
won't
start
diving
into
the
next
topic.
Are
there
any
final
questions
before
we
hit
the
wall
on
time?
C
So
we've
got
a
question
from
vucic
deck:
can
one
span
of
service
across
domains
and
how
the
endpoints
be
picked
based
on
client
proximity
to
the
domain
of
origin?
That
is
indeed
our
intention.
The
sort
of
topological
selection
we're
still
working
through
some
of
the
details
on,
but
that
is
definitely
on
the
list
of
intentions.
A
Well,
this
is
great,
we
are
at
times
and
we
had
no
lack
of
people
trying
to
take
on
the
gauntlet
that
we'd
lay
down,
which
is
to
break
one
of
the
three
of
you
with
a
question
and
I'm
not
I'm,
not
sure
that
we've
been
successful,
but
there
are,
or
some
unanswered
questions
happening
already,
and
so
there's
already
a
request
for
a
round
two
of
today's
topic.
So
today
was
the
intro
to
NSM
sounds
like
we've
got
an
encore
request
for
iiii,
dare
I
say
a
deep
dive
into
NSF?
A
C
We
didn't
even
get
to
be
able
to
get
to
some
of
the
you
know.
We
didn't
even
touch
on
things
like
how
we
bring
the
hardware
next
semester.
I
obvs,
if
you
care
about
that
stuff
in,
if
you
don't
care
about
that,
you'll
never
know.
If
you
do
care,
you
probably
care
a
lot
and
we
do
have
a
direction
we're
going
for
solving
that
problem
as
well.
A
B
There's
a
couple
ways,
and
so
the
ones
you
described,
we
have
a
very
active
slack:
that's
pound
NSM
in
the
CN
CF
slack
group.
We
have
a
mailing
list
and
you
can
send
messages
to
it
gets
a
little
less
activity
than
than
some
of
the
slack
we
we
are
available
to
people
can
ask
question
on
Twitter.
We
also
every
every
Tuesday
at
8
a.m.
Pacific.
We
also
run
the
MSM
community
calls.
B
So
that's
a
place
if
you
want
to
get
involved
with
MSM
in
a
more
in
in
more
detail
that
want
to
help
us
build
or
want
to
tell
us
what
your
use
cases
are.
That's
a
fantastic
place
to
to
jump
in
and
let
us
know-
and
and
if
you,
if
you
want
to
know
whether
or
not
your
what
things
that
you're
building
will
work
with
an
SM,
a
lot
o
how
it
works
within
SM
feel
free
to
to
connect
with
us
and
we'll
we'll
help
we'll
help.
B
We
could
use
to
help
with
that,
including
the
aspects
board
and
that
where
you
can
describe
what
problem
you're
trying
to
solve-
and
we
have
people
in
the
community
who
look
at
those
and
we'll
we'll
help
answer
those
questions
so
get
a
hold
of
us
and
we'll
we'll
help
you
with
with
any
questions
that
you
that
you
have
oh
and
YouTube
channel
with
all
of
our
meetings
as
well,
which
Taylor
posted.
Thank
you
for
reminding
us
about
that.
A
Okay,
awesome:
well,
we
are
at
time
n
Frederick
Nikola.
Thank
you
for
a
great
presentation
today
and
I
do
want
to
remind
the
attendees
that
the
webinar,
recording
and
slides
will
be
online
later
today
we
look
forward
to
seeing
you
all
at
a
future
webinar
and,
of
course,
an
attempt
on
yeah
all
right
thanks
everyone.
Thank
you.