►
From YouTube: Five Cool Things You Can Do with Network Service ... Ed Warnicke, Nikolay Nikolaev & Frederick Kautz
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
Five Cool Things You Can Do with Network Service Mesh - Ed Warnicke, Cisco Systems; Nikolay Nikolaev, VMware; & Frederick Kautz, Doc.ai
Network Service Mesh enables hybrid/multi-cloud IP Service Mesh at the granularity of individual workloads. This expands the realm of connectivity options to include things never before possible. After seven months in the CNFC Sandbox, the core project contributors are gathering together to share their insights on the status and future plans of the project They will provide a brief grounding in Network Service Mesh followed by a tour of five of these new possibilities. The session will include sharing concepts and ideas as well as showing Kubernetes deployment strategies, excerpts of Go code and lots of console typing.
https://sched.co/Uakb
A
B
So,
from
a
housekeeping
point
of
view,
we
have
up
here
two
QR
codes,
the
one
on
the
far
left.
There
is
actually
going
to
take
you
to
the
network
service
mesh
website.
So
if
you
take
out
your
iPhone,
your
phones
and
you
point
them
out
it'll,
take
you
there.
The
other
one
we
have
up
here
is
actually
the
link
to
the
NSM
Con
event
page.
We
had
a
co-located
event
this
year
for
a
network
service
mash
and
a
semca.
It
was
our
first
go
out.
B
It
went
really
really
well
a
lot
of
really
amazing
talks,
very
full
room
and
there's
a
lot
of
collateral
from
those
talks
there,
and
in
particular
this
is
sort
of
the
0
out
of
6
of
5
cool
things
for
NSF.
When
you
actually
have
a
community,
that's
doing
a
lot
of
cool
and
interesting
things.
You
can
actually
borrow
some
of
their
content
for
your
5
cool
things
to
do
with
NSM
talk.
B
It
solves
a
tremendous
number
of
problems
that
people
have,
but
you
need
a
vision
to
tie
it
all
together
and,
as
we've
evolved
forward
as
a
project,
we've
figured
out
more
and
more
about
what
the
fundamentals
of
what
we're
doing
are,
and
so
we've
sort
of
summarized
some
of
that
here,
for
you
in
NSF
vision
and
to
begin
with
I
want
to
talk
to
you
about
runtime
domains.
So
when
you
have
a
workload,
you
have
to
run
it
somewhere,
there's
some
place
that
you
run
it
back.
B
In
the
old
days,
we
run
the
workload
on
a
server
sitting
in
the
data
center.
That
was
our
runtime
domain.
The
VMS
came
in
and
we'd
have
some
virtual
machine
manager
where
you
would
go
and
you
would
run
a
system
of
VMs
on
it
and
that
would
be
your
runtime
domain
and
now,
as
we
move
forward
with
the
cloud
native
revolution,
kubernetes,
a
single
kubernetes
cluster
is
the
runtime
domain.
B
That's
the
place
that
you
run
your
workload
and
then
running
things
is
good,
but
how
many
of
you
actually
have
workloads
that
are
interesting
if
they
can't
talk
to
anything
wow,
we
actually
have
one
quit.
I'm,
really
curious.
What
workload
to
you,
how
that's
interesting,
when
it
can't
talk
to
anything.
B
So
you
have
to
talk
to
it
to
configure
it
correctly.
Yeah
so
I
mean,
generally
speaking,
any
or
close
you
want
to
run
is
completely
uninteresting
if
it
can't
talk
to
things
and
the
domain
of
things
that
it
can
connect
to.
Is
the
connectivity
domain
for
that
workload?
So
an
example
here
would
be
kubernetes
networking.
If
you're
at
a
single
cluster
clusters
a
runtime
domain,
then
you
have
a
connectivity
domain,
which
is
the
intra
cluster
networking
that
kubernetes
gives
you
and
that
networking
gives
you
some
nice
things.
B
It
gives
you
pure
l3
connectivity
to
all
the
other
workloads
in
that
connectivity
domain.
It
gives
you
the
ability
to
do
service
discovery
with
community
services,
gives
you
the
ability
to
isolation
with
number
policies,
and
you
can
optionally
bring
in
an
l7
service
mesh
for
that,
but
it's
still
welded
to
your
runtime
domain.
B
B
And
so
the
problem
with
this
is
kubernetes.
Networking
is
great
if
you're,
within
a
single
cluster,
if
you
have
microservices
that
have
to
go
east-west,
if
you
have
databases
that
need
to
be
available
across
multiple
clusters,
now
you've
got
a
problem
because
you
have
this
really
cool
connectivity
domain
within
a
cluster
intra
cluster.
But
there's
not
any
one.
Good
simple
solution
like
that
for
running
between
connectivity
domains-
and
this
is
where
a
really
central
realization
came
to
us
for
network
service
mesh
and
that
central
realization
was.
B
Why
are
we
welding
our
connectivity
domains
to
our
runtime
domains?
I
mean
when
you
write
an
application.
You
have
a
bunch
of
micro
service
workloads
that
make
up
that
application.
What
you
really
care
about
is
being
able
to
communicate
with
the
workloads
in
your
application.
You
don't
really
care
where
they're
running
you
care,
who
you
need
to
be
able
to
talk
to,
and
so
it's
actually,
when
you
think
about
it
kind
of
a
natural,
well,
the
connectivity
domain
to
a
runtime
domain.
The
way
we
have.
B
And
what
you
really
would
like
to
see
in
the
system
is,
you
would
like
to
be
able
to
the
ability
for
workloads
to
connect
to
the
other
workloads
that
they're
interacting
with
no
matter
what
public
cloud
they're
running
in
if
they're
running
on
Prem
or,
if
they're
running
in
different
clusters,
wherever
they
may
be,
and
so
NSM
provides
the
solution
to
this
problem.
Now,
first
off
we
leave
the
inter
cluster
networking
completely
alone
right.
We
do
not
have
a
CNI.
We
do
not
touch
your
CNI.
We
leave
all
that
alone.
B
B
So
you
can
run
whatever
weird
protocol
that
you
run
in
order
to
replicate
data
between
your
databases,
which
is
not
going
to
be
HTTP
most
of
the
time
that
all
works
and
the
only
people
talking
on
this
domain
are
things
that
have
been
authorized
to
connect
to
the
database
replication
domain.
And
then
we
also
have
an
example
with
a
single
instance
is
CL.
But
we'll
talk
more
about
that
as
we
get
to
the
examples
cool,
so
I'm
going
to
hand
off
to
Nicolai
now
so.
B
B
Okay,
so
we
don't
actually
have
slicing
this
but
I'm
happy
to
answer
so
the
question
was
he
sitting
to
do
the
NSM?
How
do
you
guys
hosters?
How
do
you
host
yourselves
and
the
answer
is
that
from
NSF's
point
of
view,
there
is
something
somewhere
that
provides
the
network
service,
often
that
something
may
be
a
pod
or
actually
mini
pods
running
in
various
different
clusters.
B
So
one
thing
you
might
imagine
if
you
have
a
virtual
l3
domain
and
we'll
see
this
example
is
that
you
actually
have
what
we
call
a
network
service
endpoint
running
to
each
cluster.
That
allows
you
to
have
that
virtual
l3
domain.
So
all
the
things
within
the
cluster
connect
to
that
virtual
l3
and
their
cluster,
the
virtual
l3
and
different
clusters
connect
to
each
other
and
they're,
morally,
just
routers,
but
we
don't
really
focus
on
the
router
a
bit,
because
how
many
of
you
actually
care
about
routers?
B
D
C
Okay,
so
when
we
say
network
service
mesh,
it's
essentially
network
service
and
then
mesh,
so
it's
not
on
surface
mesh
with
networking,
so
network
service
is
essential
concept
for
us
and
we
have
a
special
way
to
describe
it.
Okay,
not
so
special
traditional
communities
based
on
customer
service,
definitions
and
I'm,
going
to
show
you
how
it
like
a
little
bit
of
deep
type
of
how
it
works
and
then
we're
going
to
demo
it.
C
So
this
is
the
first
coding
that
we
are
going
to
show
you
I'm,
echoing
corinto,
okay,
so
essentially
the
lateral
service
descriptor
is
a
C
or
D
of
kind
network
service.
It's
from
our
own
network
service,
mention
of
the
API,
and
it
has
a
few
essential
components.
It
has
a
name
of
the
network
service,
it
has
a
payload
type,
which
we
are
really
proud.
C
That
is
not
bound
to
a
specific
protocol,
so
we
are
showing
IP
here,
but
it
could
be
virtually
anything
like
it
can
very
easily
be
internet
or
some
other
strange
exotic
things
like
there
are
people
on
it,
and
then
we
have
the
matches.
So
these
are
essentially
label
marching.
What
we
are
showing
here,
what
we're
using
clip-on
matching
techniques?
We
have
two
sections
here:
one
is
the
source
selector
and
then
the
other
one
is
under
the
route,
which
is
called
the
destination
selector.
So
I'm
going
to
explain
how
these
things
work
out.
C
C
So,
let's
start
with
how
the
clients
can
connect
the
request.
So
this
is
a
dump
of
the
connection
request
as
sent
by
the
conductor,
client.
So
I,
don't
know
how
many
of
you
know
more
about
the
details
of
how
many
same
works
and
we
have
clients
endpoints
things
like
that.
But
essentially
the
clients
are
requesting
network
services
and
then
they,
this
request
goes
to
network
service
manager.
Network
service
manager
finds
the
endpoint
that
implements
that
service,
or
at
least
up
best
matching
one.
So
this
is
what
you
see
here
is
a
dump.
C
C
You
can
see
it
on
the
screen
and
then
there
is
a
map
of
key
and
value
which
we
call
the
labels.
So
these
are
the
up
and
proxy
I'm
up.
The
up
label
is
proxy
now
and
the
color
rainbow
is
red,
so
it
seemed
like
whatever
we
have
here.
It's
similar
not
just
sent
as
a
request.
So
this
is
some
I.
Don't
know
this
structure
is
it
sent
over
the
wire?
It's
a
G
RPC
call,
so
we're
just
dumping
the
structure
here
and
to
see
that
then
effectively
what
networks,
what
network
service
manger?
C
Actually
our
distributed
control
plan
what
it
does,
which
is
request.
It
gets
these
fields,
the
the
name
of
the
web
service.
It
looks
to
the
catalog
of
all
the
hydro
service
that
are
defined
in
his
domain.
It
finds
that
proper
service
that's
requested.
In
this
case.
This
is
a
web
service
and
then
it
starts
marching
the
source
selector.
So
the
source
selector
is
essentially
the
source
of
the
request.
C
C
That
that
help
the
labels
declared
as
a
subset
of
what
was
requested.
So
in
this
case
the
client
was
requesting.
The
canary
clients
request
was
labeled
with
two
labels,
a
proxy
and
call
rate,
but
we
have
only
a
proxy
as
a
song
so
later
here,
so
this
disk
is
so
much
now.
The
next
thing
that
that
we
need
to
to
do
actually
what
network
service
major
this
is
try
to
find
where
actually,
this
request
should
be
routed
to
how
to
find
the
endpoint.
C
And
then,
here
we
have
a
little
bit
of
discussion
how
the
destination
selector
works.
It's
effectively
the
same
as
the
source
selector
works.
It
tries
to
find
a
specific
destination.
Actually
the
end
point
that
his
up,
because
nginx
at
least
and
because
this
specific
end
point
has
announced
itself
that
it
is
an
engine
X
application
and
it
has
color
red
it
has
at
least
up
and
engineering,
so
it
matches.
So
that's
that's
how
how
the
things
work
more
or
less
I
mean
there
are
a
lot
of
more
details.
C
We
are
not
going
deep,
just
like
a
pair
of
overview
of
the
selection,
so
you
discussed
the
specific
example
that
that
I'm
going
to
show
how
it
works.
It's
a
live
demo,
so
fingers
cause
that
is
going
to
work
yeah
as
an
effect
of
all
this
discussion,
essentially
on
the
right
here,
you
see,
a
full
description
of
the
network
service
is
a
very
basic
one.
C
It
essentially
says:
okay,
there
is
a
network
service
called
web
service,
it's
going
to
be
a
stripe
payload
and
it's
going
to
select
all
the
end
points
that
are
labeling
themselves
as
nginx,
at
least,
and
this
is
going
to
happen
for
every
quest
that
comes
from
the
proxy
or
at
least
request
itself
is
labeled
as
proxy
just
to
slide
the
versions
of
the
slides.
Here
we
have
a
little
bit
of
in
the
works
authentication
initiative
which
is
based
on
PC
spire
technologies
and
ideas.
So
these
two
slightly
change
how
this
works
in
practice.
C
This
is
a
slightly
more
complex
example
where
actually
we
have
too
much
sections.
So
the
first
section
here
on
the
right
is:
if
the
request
requests,
also
specific
color,
it
says:
ok,
I'm,
the
proxy
and
I
would
like
to
get
to
a
service
that
is
labeled
with
red,
and
then
we
are
trying
to
find
a
service
that
actually
say
about
with
red.
And
it's
it's
not
it's
not
about
having
the
specific,
exact,
specific
names
here.
C
C
So,
based
on
this,
how
this
works
in
practice-
let's
look
slightly
more
interesting
pictures
here,
so
this
is
the
overall
picture
of
how
the
web
service
architecture
that
I'm
going
to
show
you
how
it
works.
So,
essentially,
there
is
a
proxy
sitting
in
front.
It's
a
reverse:
HTTP
proxy.
It
sits.
There
accepts
requests,
we'll
discuss
a
little
bit,
how
it
works
like
how
its
implemented,
but
effectively
from
Network
Service.
C
My
point
of
view:
it
generates
a
request
which
says
which
says
I
would
like
to
connect
to
the
service
called
web
service
and
I'm
sending
I'm
labeling
my
request
with
these
two
label
sub
proxy
intolerant.
Then
of
course
this
will
pass
through
the
matching
engine
as
as
we
have
just
discussed
by
in
which
is
implemented
in
network
service
major,
and
they
need
to
select
one
of
the
three
services
which
are
labeling
themselves
as
engine
X's
and
then
different
cars,
and
all
these
three
are
bound
by
the
same
web
service.
C
B
C
C
D
C
C
C
See
it
so
what
actually
happens
is
that
if
you
send
a
request
that
is
not
labeled
or
has
a
label
that
cannot
be
found,
it
will
find
a
set
of
n
points
that
are
implementing
the
same
service
and
have
the
application
engineering.
So
this
is
the
so-called
wildcards
selector
that
we
were
not
that
we
hit
in
the
end
of
network
service.
So
what
happens?
Is
that
effectively
network
service
manger
this
around
Robyn
across
the
services?
C
C
C
Okay,
so
before
we
close
with
this
example,
just
a
slight
explanation
of
how
the
so-called
proxy,
how
it
works,
what
it
does
so
essentially
it's
a
normal
bar
native
service.
It
is
their
resource
at
port
8080.
It
implements
a
reverse
proxy
as
part
of
the
standard
HTTP
to
single
for
people
that
are
using
this
language
to
develop
their
applications,
essentially
what
it
does
when
we
sent
a
coracle
request.
C
It
looks
like
this:
there
is
HTTP
header
is
HTTP,
header
gets
translated
into
a
label,
and
then
this
label
gets
to
the
to
our
SDK
to
the
client,
and
then
we
get
the
remote
IP.
We
put
it
into
the
request,
and
this
is
how
the
whole
thing
works
so
effectively.
What
happens
now?
What
you
are
seeing
here
when
I
refresh
the
page
each
time
so
I
refresh
refresh
it
like
this.
The
HTTP
proxy
received
my
requests,
which
are
labeled,
because
you
know
the
browser
doesn't
send
the
same
exact,
specific
tables.
C
B
E
B
A
As
well
is
so
where
all
of
the
connections
that
you're
saying
that
we're
performing
with
NSM
are
at
the
l2
and
l3
layer,
so
normally
these
type
of
things,
when
you
see
them
application
meshes,
are
generally
at
the
at
the
TCP
level.
And
so
the
reason
for
this
particular
demo
is
specifically
just
to
demonstrate
how
this
particular
component
works.
B
Right
so
next
example
multi-cloud
debe
replication,
so
how
many
of
you
use
databases
awesome
cool?
How
many
of
you
at
least
like
the
option
of
running
in
more
than
one
cloud?
Okay?
So
now
you
intrinsically
kind
of
have
a
problem,
because
your
data
lives
somewhere,
and
you
got
to
be
able
to
get
your
data
to
where
you
actually
want
to
use
it.
But
most
databases
don't
actually
use
HTTP
for
their
synchronization
for
data
replication.
They
use
some
bespoke
protocol
on
top
of
IP.
B
So
here's
the
basic
use
case.
You've
got
your
Google
Cloud
AWS
and
maybe
even
something
on
Prem
and
you've
got
some
MySQL
database
pod
in
each
of
your
clusters
on
those
particular
public
clouds
and
what
you
really
want.
The
network
service
that
represents
the
thing
that
you
want
is
you
want
these
database
pods
and
only
these
database
pods
to
be
able
to
do
replication
securely
between
them
and
so
the
way
this
ends
up
looking
at
network
service
mesh
is
we
have
a
very
simple
example
of
a
network
service
that
you
can
use
to
do
this.
B
We
call
it
the
virtual
layer,
3
or
the
VL
3
domain.
So
how
many
you
guys
remember
that
in
kubernetes,
every
pod
can
talk
to
every
other
pod
with
an
IP
address
over
l3.
So
this
is
exactly
the
same
principle,
except
in
this
case.
It's
every
pod
that
is
connected
to
that
connectivity
domain,
no
matter
where
they're
running
they
can
be
in
completely
different
cloud
providers
and
the
way
you
actually
do
this
if
you're
deploying
the
database
pod
is
very
simple.
B
You
simply
add
a
very
simple
annotation
that
says:
I
would
like
the
network
service,
VL,
3
service,
you
ask
for
what
you
want
by
name
now.
Please
note.
This
is
just
an
example.
You
can
have
any
kind
of
a
network
service
that
meets
your
needs,
so
what
ends
up
happening
under
the
covers-
and
this
gets
to
your
excellent
question
before-
is
that
you
have
communication
that
goes
on
between
the
network
service
registries,
for
control
playing
pieces
and
then
in
every
single
cluster.
B
You
end
up
spawning
a
virtual
l3,
which
you
can
literally
just
think
of
as
a
router.
That's
willing
to
dynamically
accept
virtual
wire
connections
from
workloads
as
they
asked
to
access
this
service
in
a
particular
cluster,
and
that
can
string
virtual
wires
to
its
peers
to
route
them
traffic,
and
this
is
all
handled
by
the
network
service
mesh
data
plane.
It
dynamically
negotiates
any
necessary
tunnel
types.
It
deals
with
problems
about
figuring
out
where
these
things
are
and
how
they
come
together.
B
B
They
both
say
they
want
to
connect
to
the
VL
free
service,
and
now,
if
I
were
to
do
something
like
in
Google
cloud,
run
a
book
info
app
I'd
like
it
to
be
doing
its
read
from
a
local
slave,
because
that's
gonna
go
a
lot
better
for
me,
but
I
might
have
my
master
off
in
AWS
and
so
I
may
be.
Writing
data
to
the
database
in
AWS.
B
B
Both
of
these
clusters
start
out
empty.
We
don't
have
anything
running
on
them
and
we've
got
the
cube
config
variable.
So
we
deploy
to
the
network
service,
mash
infrastructure
network
service
measures,
an
infrastructure
it
as
far
as
kubernetes
concerned
as
an
app,
but
it's
a
layer
of
infrastructure
you
can
put
on
top
of
any
kubernetes
it
gets
installed,
doesn't
take
very
long
to
install
it.
B
So
you
wait
for
it
to
come
up
and
be
ready.
Essentially,
this
is
just
pods
getting
downloaded
and
coming
up
cluster
1
and
cluster
2.
Now
it's
up
and
going
you
deploy
the
virtual
l3
service.
This
is
just
a
CRT
and
it's
exactly
like
what
Nicolai
just
showed
you.
It's
got
a
name.
It
has
some
matches
that
kind
of
stuff,
and
now
what
you
want
to
do
is
to
pull
your
database
pods.
So
you
go,
deploy
your
MySQL
database
pods
on
cluster
1
in
AWS.
B
And
we
just
give
you
a
little
information
about.
What's
going
by
there,
you
can
see
that
it's
got
the
annotation.
That
says
it
wants
the
VL
three
service.
That
means
that
it
gets
an
extra
interface
dropped
into
the
pod
that
has
a
set
of
IPs
and
routes
that
are
compatible
with
your
local
cluster.
We
take
great
care
to
do
that
so
that
you
have
basic
IP
connectivity
and
when
you
try
and
reach
between
these
two
databases
at
IP,
it
will
go
out
that
extra
interface.
B
And
again
now
you
install
the
replica
slave,
it
becomes
very
much
the
same
game.
You
go
and
install
this,
but
now
you're,
just
following
the
replica
slave
on
gke.
So
it's
a
totally
different
cluster
in
a
totally
different
cloud
provider
and
again
all
you've
done
is
add
that
one
annotation
to
the
pod
to
express
what
it
is.
You
want.
B
See
yeah,
we
can
do
all
the
label
matching
things
absolutely
so
effectively
we
go
through
here.
We
wait
for
the
slave
to
come
up.
These
are
set
up
to
be
master
and
slave
to
each
other,
and
now
we
can
see
the
database
replication
in
action,
so
we're
going
to
split
screen
and
we're
going
to
show
you,
the
MySQL
master
in
AWS
and
a
slave
in
gke
you'll
be
able
to
see
as
we
go
through,
that
they
are
mastered
and
slave
to
each
other.
B
B
B
And
you
can
create
database
entries
for
book
info
in
the
AWS
on
the
master
and
then
see
that
they
actually
get
replicated
over
to
the
slave.
So
stuff
just
works.
All
you
did
was
add
an
add,
an
annotation
to
your
pod
and
now
you've
got
working
database
replication
between
two
different
cloud
providers,
giving
you
two
different
clusters.
B
D
B
B
And
if
we
go
back
to
the
book
info
now
we
reload-
and
we
see
that
in
the
book
info,
that's
pulling
from
the
read
slave.
We've
got
the
three
star,
so
we've
just
demonstrated
to
you
successfully
adding
an
annotation
to
your
pod
and
having
databases.
They
can
replicate
between
two
clouds
and
we're
now
going
to
show
you
five
star
change,
I
changed
to
five
star
review
and
see
it
again.
B
D
B
We
don't
even
know
what
you're
doing
with
the
dl3
domain.
Dude
you,
you
are
our
entire,
so
network
service
meshes
entire
purpose
in
life.
Is
someone
said
they
would
give
you
a
VL
3?
You
asked
to
be
connected
to
them
and
we
strung
a
virtual
wire
Network
service,
meshes
purely
in
the
business
of
virtual
wires.
B
B
So
network
service
mesh
actually
has
the
ability
to
do
discovery
of
service
registries
using
DNS
to
look
for
a
service
record,
so
you
can
have
different
domains
and
find
different
service
registries.
Once
you've
got
the
service
registry,
you
can
figure
out
who
can
provide
that
to
you,
etc,
etc,
and
you
can
basically
make
the
request
get
to
the
right.
Vl
3
in
your
pod,
the
VL
3s,
are
talking
amongst
themselves,
so
all
network
service
mesh
knows
is
that
you
ask
for
some
virtual
wires.
B
All
the
virtual
l3
knows
is
that
it's
getting
IP
packets
that
it
needs
to
route
somewhere
and
then
the
fact
that
you're
running
database
slaves
and
that's
what
you're
replicating
is
actually
none
of
our
business.
We
don't
know
or
care
yeah
I
mean
it
is
the
thing
you
actually
care
about
as
a
developer,
but
there's
no
point
in
polluting
us
with
semantic
information.
We
don't
understand.
F
B
So
your
third
Lucy
bring
one
up
in
Essaouira
right
and
a
cluster
in
Essaouira
aks,
and
you
would
put
an
annotation
on
it.
That
says
you
want
to
connect
the
same
network
service,
the
same
connectivity
to
remain
deal
free
service.
You
would
come
up
and
connect
to
VL
three
service,
and
now
it's
able
to
reach
all
of
those
other
things.
Now
when
you
get
to
the
real
world,
we
do
have
the
ability
for
a
network
service
like
deal
three
to
provide
DNS.
B
We
don't
show
that
in
this
example,
so
you
could
do
things
with
running
DNS
on
that
virtual
l3
and
we
have
the
technology
to
allow
us
to
multiplex
in
parallel,
so
that
when
you
do
a
look-up
on
a
DNS
name,
you
get
what
comes
from
your
kubernetes
cluster,
just
like
you're
used
to
or
quite
honestly
whatever
it
is.
You
configure
DNS
in
kubernetes
to
be
right,
because
you
have
options
plus
any
DNS
coming
from
any
network
services,
your
workload
is
attached
show
and
so
that
just
seamlessly
happens
for
you
as
a
developer.
A
A
We
use
DNS
to
work
out
where
that
end
point
is,
and
then
we
connect
to
it
use
G
RPC
to
to
to
work
out
where,
where
is
that
network
service,
then
I
do
results
in
another
G
RPC
request
of
the
other
thing
that
works
with
the
controller
in
order
to
to
actually
materialize
the
the
requests
itself,
and
so
we're
able
to
bootstrap
on
existing
on
existing
infrastructure
and
use
it
as
a
control.
In
order
to
establish
the
the
connections
that
you
that
you
want
to,
then
you
want
to
establish
so.
B
We
have
other
questions
really
quick.
I
do
want
to
point
out.
We
have
a
cure
code
up
here
right
now
that
will
take
you
to
the
full
talk
from
NSM
con.
The
slides
are
up
there
very
shortly.
The
videos
will
be
up
there,
and
so,
if
you
want
to
go
and
follow
up
and
get
much
more
detail
than
we
have
here,
it's
there
so
other
questions.
Yes,.
G
B
You're
very
astute
question,
particularly
when
you're
dealing
with
the
problem
of
on-prem
right
so
in
the
public
clouds.
They've
got
a
relatively
well
defined
way
that
these
things
work
out
in
terms
of
in
most
in
GA
in
AWS.
When
you
have
a
node,
it
has
an
internal
IP
e,
that's
private.
It
has
an
external
IP,
that's
public,
and
so
the
various
magic
that
happens
into
the
covers
can
manage
to
to
work
to
move
along
with
that.
B
We
know
that
it's
not
just
you
have
a
network
team
that
has
to
do
firewall
rules,
it's
literally
that
those
firewalls
are
going
to
different
enterprise
to
enterprise
and
so
the
internal
to
how
we're
doing
this.
The
system
is
sufficiently
modular
that
you
can
go
to
your
firewall
vendor
and
say
you
need
to
write
the
500
lines
of
code
to
expose
this
API.
So
my
firewall
will
let
this
out
or
hell.
B
You
could
do
it
yourself
if
your
firewall
API
has
it
as
it
has
an
API,
and
because
what
you're
dealing
with
is
a
tunneling
of
this
information,
and
you
have
the
ability
to
authenticate
individual
workloads
and
authorized
based
upon
the
cryptographically
authenticate
of
a
workload
identity.
You
don't
have
to
go
play
with
IP
addresses
every
time
you
just
have
to
say
I'm
going
to
let
the
damn
tunnel
through
and
then
you
can
actually
do
the
secure
ending
on
a
semantic
level
instead
of
merging
IPs
and
port
numbers.
Does.
B
But
you
can
even
set
it
up,
so
the
tunnel
gets
the
the
firewall
will
get
set
dynamically.
So
if
you
had
a
new
cluster
someplace
new,
it
would
be
possible
to
set
it
up
so
that
when
you
go
to
join
that
the
firewall
gets
poked
by
a
component
that
speaks
the
NSF
API.
So
you
don't
have
to
go
and
deal
with
your
net
ops,
team,
yeah,
yes,
I'm!
Sorry!
What
oh.
B
It
still
has
a
very
complicated
system
of
gateways.
You
have
to
stand
up
and
peer
with
each
other
and
press
service
routes
around,
for
we
actually
can
effectively
figure
that
out
automatically
the
way
we
put
the
system
up.
So
there's
the
one
real
advantage
to
coming
from
a
network
mindset
is
that
you're
used
to
the
notion
of
having
peers
and
you're
used
to
the
notion
of
discovering
how
you
get
from
A
to
B
dynamically
and
automatically,
and
we
brought
some
of
that
mindset
into
what
we're
doing
here.
B
C
B
E
D
B
D
B
B
B
So
this
is
a
really
good
question
because,
as
we
all
know,
as
the
number
of
clusters
go,
the
question
was:
do
we
have
to
worry
about
pod
signers
between
clusters?
As
we
all
know,
as
the
number
of
clusters
goes
up,
the
problem
that
your
private
IP
ranges,
conflict'
approaches
one
right,
that's
really
what
you're
getting
at,
and
so,
if
you
were
to
build
a
full-blown
production-ready,
VL
3,
you
would
want
to
be
able
to
provide
not
win
necessary
and
you
would
want
to
be
able
to
do
the
the
DNS
fixing
parts
for
that.
B
But
here's
the
difference
right.
If
I
try
and
do
cluster
a
cluster
networking
and
I
have
that
problem.
I
have
a
full
mesh
between
the
clusters
and
I've
got
to
deal
with,
not
between
everybody's
different
cluster
domain.
It
becomes
a
very
complicated
problem.
By
having
a
single
VL
3
domain,
I
can
have
a
set
of
IP
addresses
on
that
VL
3
domain.
If
they're
compatible
with
your
cluster,
we
just
pass
them
right
through
and
if
they're
not,
then
only
for
that
cluster
do
we
do
the
NAT,
and
so
it
vastly
simplifies
that
problem.
B
It's
sort
of
similar
to
doing
hub-and-spoke
versus
full
mash
and
be
the
way
the
network
service
mission
protocol
works
every
time.
The
request
goes
to
the
network
service
endpoint.
It
knows
what
prefixes
it
can't
play
from
play
with
from
that
cluster
and
it
either
behaves
itself
and
doesn't
try
and
tell
us
to
use
those
or
it
does,
and
we
reject
its
its
response.
Right
did
I
answer
your
question
cool,
excellent,
any
other
questions.
Before
we
move
on.
We
got
one
more
question
and
then
we're
gonna
move
on
to
the
next
demo.
Oh.
B
Not
yet
now
the
network
service
API
is
literally
like
three
soon
to
be
two
super
short
G,
RPC
api's,
so
I
wouldn't
be
hard,
there's
not
a
lot
there.
You
know
if
there
were
a
standard
body
that
wanted
to
take
it
up.
That
would
be
fine.
If
there's
a
fine
tradition
of
things
getting
worked
out
at
open
source
and
going
to
standards,
bodies
and
the
we
would
love
that
yeah.
A
To
to
add
to
that
as
well,
so
our
API
is
that
we
have
so
we
have
like
the
top
global
NSM
API
that
things
user
connect
with
each
other.
We
also
have
a
set
of
API
as
we
Devine
for
our
reference,
kubernetes
architecture
that
are
not
exposed
to
that
top-level
part.
So
the
area,
if
you're,
looking
at
standardization,
my
recommendation
is
to
look
at
that
top
level
global
API,
because
if
you
conform,
that's
to
that
top
level,
API
do
you
should
be
able
to.
B
Mean
cool
so
we're
gonna
move
on
to
the
next
example,
so
this
is
multi
cloud
sto
without
Gateway
configuration,
so
how
many
of
you
configure
you
have
you
how
many
of
you
have
done:
multi-cloud
sto
cool?
How
many
clouds?
How
many
clusters
do
you
connect
together?
How
many
clouds
for
awesome,
so
you
had
to
configure
a
bunch
of
gateways
for
those
four
clusters
right,
I'll
tell
them
how
to
find
each
other
talk
to
each
other
etc.
So
how
was
that
experience
for
you.
B
Very
what
yeah
exactly
no,
it
would
not
be
good
experience
and
and
so
effectively.
What
we
did
for
that
is,
we
said,
look
never
serve
especially
give
you
a
common
VL,
three
virtual
layer,
three
under
the
system,
which
means
that
you
can
run
a
single
in
steal
instance,
on
top
of
that,
VL
3
and
topologically
simplify
your
life
right,
so
this
is
sort
of
showing
the
baseline
topology.
You've
got
various
four
clothes.
B
They
have
virtual
wires
that
connect
themselves
to
the
network
service
endpoints
than
each
cluster
for
each
of
those
workloads,
and
then
you
can
layer
on
is:
do
it
exactly
the
way
you're
familiar
with
right.
You
run
an
envoy
pod
as
a
sidecar
in
your
workload
and
you've
got
this
additional
virtual
l3
domain
and
you
have
your
Co
control
playing
controlling
that
now,
there's
actually
a
second
way.
You
could
do
it.
We
call
this
the
alternate
approach.
B
This
is
not
the
one
we're
going
to
demo
and
that
is
to
say
you
could
literally
make
the
Envoy
sidecar
a
separate
pod
that
is
itself
a
network
service
endpoint
that
lifts
up
as
an
ingress
to
your
service
mesh.
The
nice
thing
about
this
one
compared
to
the
first
one
that
we're
gonna
actually
see
the
demo
is
that
if
you
have
a
pod
that
you
want
to
connect
to
more
than
one
service
mesh
say
that
I
am
a
large
company
with
many
parts
suppliers
and
I
have.
B
It
is
to
you
a
service
mesh
that
I'm
going
to
expose
on
activity
domain
to
my
partners,
and
each
of
those
partners
wants
to
participate
in
that
SEO,
but
they
also
may
have
the
same
pod
willing
to
participate
in
the
parts
suppliers
sto.
With
this
kind
of
an
approach
you
could
participate
in
multiple
service
meshes
that
are
mutually
ignorant
of
each
other
at
the
same
time.
But
it's
a
little
harder
to
talk
through.
So
we
went
with
a
simple
one
for
the
first
pass
through
but
effectively.
C
B
Do
have
some
examples
as
well,
so
in
terms
of
what
happens
in
the
application
pod,
this
is
sorta
a
little
bit
of
the
structure.
We
showed
you
a
little
in
the
previous
demo
that
you
wind
up
with
a
network
service,
managed
interface.
The
number
service
mesh,
managed
interface
for
connecting
to
the
VL
3
domain
and
network
service
smash,
has
the
ability
for
the
VL
3
domain
to
pass
back
routes
as
long
as
they're
compatible
with
what
we
told
that
the
clusters,
using
that
it
says
what
should
go
out
that
interface.
B
So
then,
your
envoy
sidecar
in
the
normal
way
your
application
comes
up.
It
sends
stuff,
iptables
kidnaps,
it
sends
it
to
envoy
envoy.
It
goes
ahead
and
sends
it
out
and
it
hits
the
route,
and
at
this
point
it
either
takes
the
default
route.
It
goes
out
your
CNI
interface
or
it
hits
a
route
that
matches
something
for
the
network
service,
mesh,
managed
interface.
It
goes
out
that
interface,
and
so
this
gets
to
sort
of
your
point.
B
C
B
B
B
B
We
can
log
into
one
of
those
client
pods,
so
now
we're
inside
the
client
pod.
You
have
to
be
inside
the
client
pod
to
still,
you
see,
really
see
the
magic
of
what
we've
done
here,
because
not
every
pot
in
kubernetes
can
reach.
This
is
do
necessarily
you
can
go
through
and
curl,
and
you
will
see
that
we're
being
load
balanced
by
sto
among
the
various
hello
worlds
that
are
running
in
different
clouds,
so
we've
strung
a
single
sto
domain
across
multiple
public
clouds.
B
B
So
this
was
the
question
we
got
before,
which
is
the
vol
3,
if
you're
doing
a
full
production
ready,
vol
3,
when
some
client
can
win
some
workload,
ask
to
connect
to
it.
It
will
be
told
these
are
the
prefixes
you
can't
play
with
if
those
conflict
with
the
subnets,
the
prefixes,
because
again
we're
not
l2
here
you've
got
a
bunch
of
IP
addresses
for
the
vol
3.
Then
it
will
have
to
respond
with
something
that
is
compatible
and
it
will
have
to
not.
B
But
you
only
have
to
do
not
for
the
clusters
that
are
incompatible
with
your
vol
threes
IPs
and
it's
clustered
to
central
things.
So
it's
a
hub-and-spoke
instead
of
having
to
do
the
full
disaster
of
not
among
potentially
a
full
mesh
of
clusters,
because
again
we
actually
aren't
doing
cluster
to
clustered
connectivity,
we're
doing
workload
to
workload
connectivity
with
connectivity
domains
that
have
now
been
divorced
from
having
any
underlying
runtime
domain
cool.
B
So
our
reference
implementation
has
been
done
for
kubernetes.
However,
the
baseline
architecture
is
completely
independent
of
kubernetes.
This
is
why
we
use
gr
FEC
api's.
We
actually
took
great
care,
so
you
saw
CR
DS
in
the
demo
that
that
was
done
by
nicolai.
The
reason
is
because,
when
the
actual
components
of
network
service
mesh
use,
the
G
RPC
calls
to
register
themselves
or
do
a
lookup.
The
thing
that
catches
is
just
storing,
CRTs
and
kubernetes
to
make
it
comfortable
for
kubernetes,
but
it
could
store
them
at
anything.
A
B
Had
a
talk
that
went
by
it
at
a
seminary
to
the
many
many
other
cool
things
that
went
by
the
speaker,
nonchalantly
mentioned
that
he
had
turned
top-of-rack
white
box
into
a
network
service
endpoint
in
a
couple
hundred
lines
of
go
code,
didn't
even
spend
a
full
sentence
on
it.
I
was
so
disappointed.
He
was
doing
other
cool
things.
D
A
A
B
So
one
important
thing
that
we
should
probably
mention
here
is
that
it
turns
out
writing
network
service
endpoints
things
that
do
network
services
is
insanely
repetitive,
because
everybody's
got
to
plug
the
incoming
connection
into
whatever
the
data
plate
is
that
they
have
internally.
Everybody's
got
to
you
know,
do
a
whole
variety
of
toss
and
there's
no
point
in
having
to
write
it
again.
B
So,
if
you're
trying
to
figure
out
what
code
it's
going
on,
you
can
say:
well,
okay,
I
got
into
my
network
service
endpoint
and
when
I
got
to
I,
Pam
I
Pam
had
an
error
and
that's
the
part
of
the
thing
that
had
an
issue.
So
this
makes
it
super
easy
to
figure
out
not
just
which
micro
service
broke,
but
which
SDK
component
broke
in
this
system
and
perceived
from
there
and.
A
So
the
ends
so
in
this
particular
in
this
particular
system,
so
we're
able
to
to
collect
and
aggregate
all
of
the
information
across
multiple
system.
So
it
gives
you
a
tremendous
amount
of
power
of
visibility
into
the
into
the
actual
request.
When
you
have
an
error,
then
you
depend,
depending
on
your
logging
system.
It'll
show
those
those
errors
in
a
in
a
very
clean
way.
A
We,
these
particular
systems,
typically
use
UDP.
So
if,
if
a
message
is
lost
you
traditionally,
you
don't
want
to
try
to
to
resend
the
message
you
want
to
fire
it
off
and
and
forget
about
it,
and
the
reason
for
this
are
primarily
from
the
performance
side,
because
these
type
of
tracing
logs
can
get
quite
quite
extensive
and
you're
better
off
shedding
load
rather
than
trying
to
absorb
it
all
and
with
with
TCP,
you
reuse
throughout
resets,
and
so
so
that
helps
protect
your
system
from
from
too
much
from
too
much
information.
A
But
these
particular
systems
that
I've
been
built
in
the
cloud
native
space
have
amazing
scalability
and
we
and
they'll
continue
to
get
better
over
time
as
people
spend
more
time
building
them
out.
Another
thing:
I,
don't
have
a
demo
of
it
at
the
moment,
but
we
also
have
monitoring
so
it
all
major
events
in
NSM
arm
honorable.
A
So
when
you
make
a
connection
or
request,
you
can
monitor
that
particular
connection
and
that
connection
will
tell
you
a
significant
quantity
of
information
about
the
connection,
the
condition
you
have
access
to
see
that
information,
and
so
what
this
allows
us
to
do
is
that,
because
we
can
see
both
sides
of
the
connection
and
we
can
like
we
can
send
a
packet
in.
We
see
on
the
other
side
that
the
other
side
received
it
receive
it
properly.
A
So
we're
not
in
the
business
here
of
trying
to
resem,
but
when
you're
trying
to
debug
a
system,
it's
like
Oh
has
a
link
failed,
while
I'm
seeing
a
thousand
packets
on
this
side
and
zero
on
this
side.
Well,
we
can,
we
can
say
well,
something's,
probably
failing
them
in
that
in
that
environment.
We
also
are
able
to
use
that
to
work
out
the
overall
topology
of
the
various
connections
that
you're
that
you're
using.
So
you
can
work
out
where
they've
gone.
What
connections
have
been
made?
A
Is
this
thing
taking
a
path
that
I
expect,
like
perhaps
you're
a
vendor
who
or
you're
an
operator
and
you
care
about
what
path
like
I
have
some
systems
that
I'm
that
I
have
a
good
legal
agreements
with
it's
actually
really
important
in
a
medical
industry?
You
have
certain
groups,
you
may
have
legal
agreements
with
and
some
something
you
that
you
don't
for
for
like
HIPAA
requirements,
so
as
you're
starting
to
as
you're
starting
to
change
them.
A
You're
able
to
get
a
list
of
all
those
things
you're
connecting
through,
and
then
you
can
say
is
this.
Is
this
a
chain
that
I
that
I,
like?
Is
that
I
that
I
agree
with
and
to
be
able
to
to
say
yes
or
no
and
reject
the
entire
chain
and
the
chain
is
cryptographically
signed
by
each
of
the
components
and
what
and
including
what's
came
before
that
component
and
what
they
think
they're
connecting
to
to
next.
A
A
We
expose
an
event
on
it,
so
this
gives
you
a
tremendous
amount
of
observability
and
we
do
it
in
a
way
that
that
does
not
centralize
all
the
information
all
at
once.
Instead,
you
can
install
components
in
and
monitor
the
things
that
you
care
about,
so
this
is
really
important
in
terms
of
scaling,
because
when
you're
look
when
you're
looking
at
expand
at
large
scale,
you
don't
want
to
have
a
central
system
where
all
of
your
events
end
up
in
that
single
place,
because
you
will,
you
will
overload
that
system.
This.
B
Is
super
important
because
it's
important
to
remember
that
Network
server
special
as
a
system
was
designed
to
scale
internet
scale
right.
It
was
designed
so
that
you
could
come
in
and
say,
I've
got
a
workload.
I
need
to
connect
to
a
VL
3
domain
from
a
partner
of
mine
that
I've
never
heard
of
before.
But
hopefully
we've
got
some
Federation
of
authenticate
able
identity
between
us,
because
when
I
come
up,
I'm
gonna
be
able
to
get
a
request
to
him
to
join
his
VL
3
without
having
to
necessarily
go
talk
to
them.
B
A
In
addition,
one
direction
we're
also
taking
this
on
the
observability
is
we're
also
using
that
as
the
core
components
to
our
auto
healing.
So
one
of
the
ways
that
you
get
your
system
to
become
more
stable
and
more
and
more
effective
is
you?
Is
you
use
the
components
that
you've
built
yourself,
so
our
auto
healing
is
set
up
so
that
we
can?
A
We
can
pull
up
information
through
the
monitor
and
work
out
like
if
your
NSM
Manager
crashes,
you
ask
your
you
ask
your
clients,
who
would
what
am
I
connected
to
and
then
you
go
ask
those
peers.
You
agree
with
this.
Do
I
have
a
connection
with
you?
If
you
do,
then
you
can
re-establish
that
state.
If
the
component
that
manages
the
forwarding
element
goes
down,
you
can
do
the
same
thing
as
the
NSI
manager.
A
B
Know
it
turns
out
that
when
you're,
when
you're
talking
about
connections
for
virtual
wires,
right
or
pieces
of
virtual
wires,
which
is
what
we
call
connections,
there's
always
at
least
two
sides-
and
that
means
there's
always
at
least
two
places
the
state
exists.
And
so,
if
something
restarts
or
dies,
you
can
get
by.
With
a
little
help
from
your
friends
and.
A
Those
two
places
are
predictable
exactly
because,
if
you
don't
know
where
the
other
ones
that
you
can
ask,
one
would
school
and
if
your
data
plane
crashes
so
you're.
Actually
the
thing
that
is
actually
shuffling
the
packets
ends
up
crashing,
and
so
you
reboot
it
and
and
that
we
have
enough
information
that
we
can
then
reprogram
the
the
data
plane
and
then
continue
moving
things
on
the
few
packets
are
lost,
but
you
but
you're
able
to
to
recover
so
that
observability
actually
builds
into
our
auto
shilling
story
that
we're
that
we're
building
within
NSM.
Yes,.
D
B
Many,
what
so
in
in
kubernetes
in
the
reference
implementation
kubernetes
each
node
has
exactly
one
network
service
manager
of
time.
Oh,
like
like
how
many
dl
three
inputs
yeah,
there's
a
lot
of
flexibility
there,
including
some
of
the
stuff
we're
looking
at
of
the
future
for
dynamically
spawning
them
on-demand,
because
it's
probably
helpful
to
have
your
VL
3
in
point
be
on
the
same.
B
Node
is
the
guy
who
asked
to
connect
to
the
VL
3,
but
you
don't
want
to
do
that
if
you've
got
a
five
thousand
nodes,
you
know
what
I
wrote
a
Dame
instead
on
five
thousand
nodes,
but
if
you
can
and
we're
looking
at
stuff
to
do
this,
when
a
request
comes
in,
you
can
say:
okay,
he
asked
for
this.
It
falls
through
the
system,
creates
it
on
the
same
node
and
then
even
hook
it
up
to
it.
B
You
can
literally
get
it
so
you're
just
dealing
with
a
scale
from
zero
problem,
which
is
where
we're
trying
to
take
it
because
you
you're
gonna
have.
But
the
goal
is
to
make
it
so
that
people
end
up
wanting
to
do
a
ton
of
different
connectivity
domains
to
meet
their
particular
needs,
and
so
you
can't
just
in
the
long
term,
just
be
deploying
things
willy-nilly.
Statically
you
got
to
deal
with
it.
Dynamically
yeah.
A
One
last
thing
on
the
observability,
so
we
don't
want
to
pretend
like
we
know
what
all
stats
and
everyone's
gonna
care
about.
So
it's
also
set
up
in
such
a
way
that
you
can
create
your
own
metric
and
then
be
able
to
to
capture
that
metric
as
well.
So
if
your
data
plane
has
something
it
really
cares
about,
and
it's
important
for
you
to
know
what
that
number
is,
there
is
a
way
to
expose
it
into
into
this
API
we're
fairly
flexible
there,
because.
B
We've
already
seen
in
the
Edison
community
people,
thinking
of
things
that
never
ever
occurred
to
us,
that
are
kind
of
awesome.
In
fact,
quite
a
few
of
them
are
things
you've
seen
them
out
here,
right
stuff
that
did
not
occur
to
us
when
we
started-
and
somebody
said
oh,
this
is
actually
pretty
easy
to
do
and
when
to
produce
these
things,
which
became
at
a
Sun
Khan
talks.
A
Yeah
and
finally,
if
one
of
your
network
services
crashes,
so
the
thing
that
is
actually
providing
you,
that's
a
little
balancing
or
the
firewall
or
so
on.
Well,
if
it
crashes
were
able
to
identify
that
we
identify
the
crashes
and
reroutes
you
to
something
else
or
if
the
connectivity
between
the
services
drops,
as
I
mentioned
before,
we
can
track
activity
on
one
side
and
see
if
it
matches
activity
on
the
other
and
then
use
that
to
to
determine
if
we're,
if
we're
losing
information,
that's
being
passed.
A
There's
some
failures:
where,
if
you
have
a
failure,
you
have
to
fail
the
entire
at
that
entire
chain
and
allow
that
that
an
originating
system
to
make
a
decision
on
what
it
wants
to
do.
So
it
gives
you
a
lot
of
flexibility
on
on
how
you
want
to
I,
don't
want
to
perform
that,
but
that's
stuff
that
we're
currently
building.
So
we
can't
you
can't
use
all
the
auto
healing
stuff
we've
spoken
about
just
yet,
but
that
observability
is.
That
first,
is
that
first
major
step
that
we.
B
We're
working
on
v2,
we
usually
talk
about
it,
who
here
is
sort
of
chaos,
monkey
where
you
just
have
something
randomly
killing
things.
So
we
have
sort
of
chaos,
monkey
level,
auto
healing,
but
we
think
we
see
our
way
clear
to
what
I
generally
refer
to
as
chaos,
gorilla
love,
a
lot
of
healing
which
is
restart
all
the
things
yeah.
A
B
The
same
time-
and
it
becomes
a
blip-
that's
where
we're
trying
to
go.
Yes,
can
you
do
what
so
here's
here's
the
interesting
thing
you've
got
to
a
very
sort
of
networking
place
and
that's
good!
Oh!
No!
That's
fine!
That's
fine!
So
network
service
mesh
is
just
giving
you
the
virtual
wires.
So
let's
say
I
was
doing
VL,
3
and
I
didn't
want
to
do
costs
on
the
connections
that
are
going
so
I'm
a
vol
3
router
I
got
a
bunch
of
clients
connecting
to
me.
I've
got
a
bunch
of
connect.
B
G
B
That's
an
interesting
discussion.
We
we've
had
a
bunch
of
discussions
about
how
to
augment
the
selection
process,
so
you
would
think
of
the
matches
as
giving
you
a
set
of
candidates
right
things
that
would
be
ok
to
connect
to
and
then
the
question
is:
how
do
you
select
among
those
candidates
and
right
now
we're
doing
a
super
primitive
round-robin?
But
there
are
a
number
of
people
in
the
community
who
are
interested
in
having
conversations
about
allowing
more
sophisticated
approaches
and
for
some.
What
for
the
reasons
that
you
should
described,
yeah.
A
That's
an
area
that
that's
it
that's
interesting
to
you,
one
of
the
things
that
we
would
enjoy
like
we
don't
have
to
jump.
Excuse
me,
you
don't
have
to
jump
in
and
write
code
or
anything
like
that.
If
you
can
follow
up
with
us
afterwards
and
we
can,
we
would
love
to
get
a
use
case
on
on
that
set
up
and
we
can
make
sure
that
what
we're
developing
matches
it.
So
one
of
the
things
we
do
in
the
community
is
we
have
most
of
our
specs
are
online
and
we'll
post
like
here's.
D
A
B
Could
be
all
kinds
of
things
right?
No,
no,
that
that's
that's
absolutely
a
thing
and
I
guess
that
the
point
is
you
you
could
handle
it
in
a
number
of
ways.
One
of
them
is
the
costing
you
described
on
selection.
The
other
could
just
be
put
the
intelligence
for
that
in
your
VL
3
right,
that's
another
place.
B
To
put
it
we're
actually
really
humble
in
this
space,
there's
a
whole
lot
of
innovative
stuff
going
on
and
we're
actually
rethinking
entirely
we're
in
the
cloud
one
auto
everyone
thought
about
these
switches
now
we're
thinking
about
virtual
wires
and
network
services,
and
it's
amazing
the
things
that
this
very
simple
shift
in
thinking
opens
up,
but
the
really
both
exciting
and
humbling
part
of
it
is
is
that
we
don't.
We
have
an
incredible
space
of
what's
mechanically
doable,
but
we
don't
yet
know
what's
wise
and
figuring
out.
What's
wise
is
super
exciting
yeah.
D
B
B
So
what
is
quality
experience
so
basically,
a
quality
experience
is
if
I
got
two
workloads,
probably
in
different
clusters,
because
that's
mostly
what
we're
bread
and
butter
is
for
network
service.
Mash
and
I've
got
some
communication
that
has
to
happen.
I
may
want
different
kinds
of
quality
of
experience.
Maybe
I
want
lowest
latency
they're
a
whole
bunch
of
use
cases
where
latency
is
super
important.
It
means
huge
numbers
of
dollars.
Maybe
I
want
you.
Let's
use
least
utilization,
maybe
I
want,
as
you
put
it
out
before,
lowest
cost
right.
B
There
are
all
kinds
of
things
you
can
sort
of
optimize
for
in
that
regard.
Now,
when
you
get
down
to
the
networking
brasstacks
mostly
we've
talked
about
stuff
is
super
familiar
from
a
developer
point
of
view.
We're
gonna
get
a
tiny
bit
networking
here.
When
you
talk
about
this
in
the
networking
world.
B
They
are
not
kidding
much
smaller
segments
of
time
need
money
to
that
and
so
being
able
to
say,
I
want
to
connect
to
the
lowest
latency
connectivity
network
service,
for
this
is
really
important
to
them,
certainly
with
telemedicine,
you
have
all
kinds
of
similar
constraints
for
certain
telemedicine
applications
on
latency,
so
how
this
looks
at
network
service
mesh.
This
is
this
pictures
probably
looks
super
familiar
by
now,
so
NSM
provides
these
v
wires
to
connect
workloads
to
network
services,
and
in
this
case
they
just
happened
to
be
network
services
that
do
whatever
magic.
B
It
is
that
causes
you
to
get
the
quality
of
experience.
You
need
there's
a
whole
set
of
hard
problems
for
various
people
to
sell
it.
I
to
solve
and
I
suspect
vendors
will,
in
some
cases,
in
some
cases,
open
source
projects.
Well
about
writing.
These
network
services
there's
a
huge
space
there,
so
maybe
some
applications
connect
to
the
low
level
the
low
latency
connectivity
Network
service,
maybe
some
connect
to
the
low
cost
connectivity
network
service
and
again
I
didn't
want
to
get
to
network
II.
B
Here
we
do
have
a
whole
talk
that
gets
into
the
nitty
gritty
details
of
how
this
works
in
terms
of
quality
of
service
at
NSF
Cod.
If
you
follow
that
link
it'll,
take
you
to
the
talk
page.
The
slides
are
there
for
the
talk
as
soon
as
the
video
processing
finishes,
we'll
get
the
videos
up
in
exactly
the
same
link,
so
you
can
go
and
watch
the
videos
of
those
talks
that,
in
this
eMCON
yeah.
B
All
the
talks
and
then
back
to
sort
of
the
housekeeping
you
can
get
to
the
number
service
mesh
IO
page.
There's
a
community
tab.
There
that'll
show
you
how
find
our
weekly
meetings
it'll
show
you
how
to
find
our
social
media
it'll
show
you
how
to
find
our
code,
our
issues.
You
know
all
the
sorts
of
things
you
need
to
get
plugged
in
and
then,
if
you
want
these
slides
there
at
the
bottom
quarter
there
with
their
QR
code
and
we
have
the
link
to
the
full
at
a
semcon
agenda.
B
F
F
B
That's
great
news.
Thank
you
cool
any
other
questions.
Then
we've
covered
an
incredible
amount
of
material
over
a
very
wide
array
of
cool
things.
You
can
do
so
before
we
close
do
we
have
questions
and
of
course
afterwards,
if
you
want
to
go
talk,
we're
happy
to
go
out
of
the
hallway
and
talk.
That's
always
almost
the
most
fun
part
of
the
talk,
and
we.
G
D
F
G
B
That's
we
didn't
dig
into
this
here.
There
are
other
slides
where
we've
talked
about
it,
so
we
use
spiffy
inspire
to
issue
authenticate
ability
we're
in
the
process
of
integrating
with
OPA,
so
that
you
can
actually
do
policy
on
admission
to
a
connectivity
domain
and
it
turns
out
there's
a
lot
of
stuff.
That's
interesting
in
that
area,
because
it's
not
just
oh
I
got
the
identity
of
your
workload.
I
would
admit
you.
B
You
wind
up
with
some
interesting
questions
like
how
do
you
handle
the
authorization
distribution
problem
on
the
policy
right
and
and
for
some
aspects
of
the
system?
That's
pretty
trivial!
If
I'm
a
network
service
endpoint,
that's
offering
a
network
service,
I
know
I
need
to
get
the
policy
for
the
network
service,
but
if
I'm
a
client
looking
to
see
did
the
response
I
get
back
actually
is
my
willing
to
accept
the
network
service
from
you,
where
I
could
be
asking
for
any
number
of
network
services.
That
gets
to
be
a
much
more
interesting
problem.
B
So
we've
got
a
whole
bunch
of
stuff
we're
looking
at
around
handling
the
sort
of
scale
of
policy.
We've
got
a
whole
bunch
of
discussions,
we're
having
with
spiffy
inspire
about
Federation
because
ideal.
If
you
want
to
do
this
at
internet
scale,
you
want
to
be
able
to
Fedder
eight
the
identity
spaces
with
your
peers.
B
We've
you
been
bounced
around
for
those
of
you
who
are
in
network
e,
we've
sort
of
thought
about
how
you
distribute
these
things
and
bounced
around
ideas
around
trust,
reflectors
and
policy
reflectors,
basically,
just
allowing
you
to
have
a
way
to
just
actually
officially
distribute
these
to
the
possible
people
that
might
ask
for
them.
So
it
gets
to
be
a
super
interesting
space.
But
now
we're
very
aware:
this
is
a
super
important
problem,
so.
A
If
fewer
in
the
San
Francisco
Bay
Area
on
December
3rd
I'm
going
to
be
giving
a
talk
on
all
right,
so
I'm
scheduled
to
be
giving
a
talk
on
on
identity
and
policy
using
spiffy
inspire
open
policy
agent
with
a
5g
context
to
it.
So
if
you're
in,
if
you're
in
town
on
that
period
of
time,
if
you're,
not
in
town,
we,
if
you
want
to
know
more
about
it,
I'm
willing
to
talk
to
you
as
well,
but
yeah.
That's
that's
something
that
we
wanted
to
tie
into
into
innocence.
B
Well,
the
other
thing
we
kind
of
get
excited
about
about
this
is
being
able
to
have
a
single
spiffy
identity
that
controls
your
admission
to
a
connectivity
domain
that
can
that
can
be
used
for
your
micro
service
requests
to
the
other
micro
services
that
you
can
reach
over
it.
Basically,
all
the
way
up
and
down
the
stack,
a
common
identity
and
then
a
way
to
express
policies
about
these
things
gets
to
be
super,
exciting
and
interesting.
Yeah.
D
A
A
A
A
Have
one
last
thing
to
make
sure
if
you're
interested
in
the
project
every
Tuesday
at
8
a.m.
Pacific
time
we
have
a?
We
have
a
meeting
on
on
zoom,
so
you
you
can
find
us
on
every
service
mission
of
I/o
and
come
come
join
us.
We
have
mailing
lists
and
we
are
very
active
on
slack.
In
fact,
our
users
complain
about
how
fast
we
are
on
slack
because
they
prevents
them
from
playing
video
games
or
something
anyway.
So
please
come
join
us
we're.
B
Definitely
a
little
late
and
see
network
service,
so
thank
you
so
much
you've
been
a
fantastic
audience.
I
appreciate
all
the
really
excellent
questions
and
I
personally
appreciate
you
guys
actually
participating
in
the
process
and
we
hope
to
see
you
in
the
network
service
mission
community.
Thank
you
and.