►
From YouTube: Network Service Mesh WG Meeting - 2019-02-12
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
A
Welcome
to
the
call
so
again
the
folks
who
are
just
joining
a
reminder
of
the
meeting
is
recorded
and
automatically
posted
to
YouTube.
We
usually
start
about
five
out
when
folks
have
turned
up
I've
linked
into
the
chat
again,
so
folks
can
go
add
themselves
to
the
attendee
page
on
the
meeting
minutes
or
add
anything
to
the
agenda
they'd
like
them
great.
A
B
A
C
Okay,
so
yes
again,
please
out
your
names
here.
If
you
didn't
do
so
already
so
agenda
bashing,
I,
guess
that
we
have
added
a
couple
of
items
already.
If
there
is
anything
that
you
want
to
bring
up
to
our
attention
now
now
is
the
time
or
you
can
just
start
it
on.
The
bottom
doesn't
doesn't
change
much
okay.
C
C
C
C
Nope
they
they
actually
updated
the
date.
So
first
of
March,
oh
yeah,
there
is
still
still
time.
So
if
someone
is
interested,
it's
in
San
Francisco,
so
someone
is
there
and
wants
to
join
could
be
interesting
to
to
participate
there.
From
any
sane
point
of
view,
then
we
have
the
open
network
submit
in
North
America
cover
paper
already
closed.
A
C
C
C
C
Don't
think
we
have
promised,
we
know
okay
yeah.
Maybe
it
would
be
interesting
to
to
see
what
what
was
accepted
there
and
the
week
event
for
NSM,
at
least
to
my.
You
would
be
coop
con.
You
barcelona,
where
we
target
to
announce
our
first
release.
I
hope
that
we'll
be
able
to
to
do
a
good
good
impression
there
and
yeah.
C
C
C
So
if
somebody
is
attending
there,
please
notice
that
we
can
record
here
the
the
fact
of
the
event,
or
at
least
the
application,
and
the
last
thing
here
on
the
list
from
the
events
that
we
have
is
the
open
network
summit,
which
is
which
will
be
in
September
and
core
purpose,
is
still
not
opening.
It's
still
not
open,
but
we
are
intending
to
to
apply
there
for
sure.
C
C
C
A
C
B
C
C
C
So
that's
that's
the
current
state.
Of
course,
there
will
be
a
lot
more
to
add
just
that
this
is
what's
going
on
today
and
I
hope
that
the
specs,
which
are
due
to
be
reviewed
in
this
meeting,
console
by
it,
we
will
have
a
chance
to
also
generate
more
also
another
interesting
topic
that
that
will
need
to
be.
That
will
actually
make
their
way
here
in
the
backlog.
C
A
Yeah
I
think
we
sort
of
come
to
the
conclusion
there
were.
Basically
there
were.
There
was
a
small
number
of
things
that
actually
needed
to
be
decided
fairly
swiftly,
and
these
are
sort
of
the
things
we
need
to
agree
on.
One
of
them
was
the
the
dates
right.
What
date
are
we
going
to
pull
the
throttle
branch
or
the
release,
and
at
what
date
are
we
gonna?
A
So
two
folks
have
any
thoughts,
opinions
or
comments.
It
looks
like
effectively
we're
pulling
the
throttle
branch
about
a
week
before
we
would
do
the
initial
zero
release
and
then
another
week
before
the
dot
one
and
the
dot.
One
is
time
so
that
we
would
have
a
working
about
one
release
going
into
cube.
Connie
you
with
looks
like
you,
allowed
about
a
week's
worth
of
slack
in
the
schedule
for
the
inevitable
things
to
go
wrong.
Nicholi.
A
F
E
A
I
mean
I,
don't
think
we
have
that
right
now,
I
think
you've
got
some
stuff
Nicolai
you've
put
together
on
the
board
of
stuff
that
we're
actually
targeting
getting
it
yeah,
but
but
part
of
it
is
you
know,
people
have
to
actually
come
and
do
the
work
and
projects
don't
centrally
donate
Lee
sort
of
centrally
managed,
quite
like
that
you
can
come
to.
Consensus,
looks
like
that,
but
my
sense
was
probably
what
we're
looking
at
is
this
particular
moment
is
sort
of
stability
in
that
kind
of
stuff.
E
A
E
I
mean
just
in
general,
right,
like
I,
mean
you're
gonna
be
able
to
set
up
these
services
and
an
NSC.
You
know
you
be
able
to
write
these
services
or,
whatever
you
know,
the
SDK
that
Nikolai's
been
working
on.
Has
this
availability
just
I
mean
I,
guess
unless
you're
saying
that
hey
look,
this
is
a
dev
kit
and
here's
dot,
one
of
this
dev
kit
and
it's
bring
your
own
code
type
of
model,
yeah.
A
Service
wish
itself
and
that's
that's
something
you
just
compute
control
apply
and
there
you
go
right
and
then
there
is
the
things
you
might
deploy
on
top
of
the
network
service
mash,
which
would
be
various
entities,
and
then
there
is,
as
you
put
it
out,
the
sdk
which
would
be.
This
is
how
we
make
it
super
easy
to
write
their
own
network
service,
endpoints
yeah,
trying.
A
That
sounds
good
and
you
guys
it's
a
lot
of
them,
because
it
turns
out
when
you,
for
example,
talk
to
the
nfe
folks,
like
you
Jeffrey
the
use
cases
I
usually
show
the
cloud
native
guys
are
not
so
much
than
once
you're
interested
in,
but
look
at
them
and
you're
like
yeah
I.
Don't
care
about
this
use
case,
but
I
absolutely
see
where
you're
going
right,
because
you're
a
network
guy.
A
C
So
here
we
have
the
list
of
the
release
materials.
It's
not
really
a
feature
list,
the
way
that
you
asked
Jeffrey
but
still
I
think
that,
based
on
this,
you
know
we
will
have
whatever
we
release.
So
at
least
my
approach
for,
for
the
time
being,
is
to
try
to
have
as
more
tests
as
possible
different
test
scenarios.
C
Proof
stability
of
the
basic
functionality
like
defining
the
same
different
network
service
deployed
within
a
single
cluster,
and
if
you
know
being
able
to
to
change
it
at
runtime,
all
these
you
know
kind
of
basic
things
that
you
feel
like.
You
should
be
able
to
hear
from
up
something
that
claims
to
be
stable.
Now,
all
the
other
good
things
about
you
know,
inter
intercoastal
communication
in
the
sames
mix
and
all
the
other
things
that
we're
talking
about
in
the
specs
I,
guess
that
these
things
probably
won't
make
it.
E
Even
if
it's
super
limited
in
scope,
I
think
it
always
comes
back
to
the
documentation
thing.
I
guess
is
just
having
like
a
an
intro
dev
guide.
Then
right
like
if
it's
hey,
we're
going
to
show
you
how
to
build
your
own
network
services
than
just
and
there's
a
exhaustion.
Old
data
plane
implement
a
terse
guide,
but
that
there
should
probably
be
like
I'm
like
a
pretty
robust,
like
document
around
your
SDK
Nikolay
on
look.
If
you're
gonna
come
it,
the
underpinnings
are
stable.
A
D
E
D
F
What
can
I
do?
It's
probably
you
know,
even
if
it's
targeted
aims
of
what
you
know,
I
know
you're
saying
really
it's
an
open
source
community
to
do
what
he
does,
but
that
you've
got
a
plan
for
to
come.
If
either
it
reaches
a
threshold
and
you
release
it
or
it
doesn't
reach
threshold
new
the
supposed
so
having
that
threshold
in
mind,
I
think
is
component.
Okay,.
A
Certainly
at
least
the
dates
right
which
are
or
I
think
the
rest
of
it
will,
if
often
improve
like
you
know,
we've
got
bullets
the
documentation,
sure
we'll
do
better
that
overtime.
That
sort
of
thing,
but
the
key
point
in
my
mind,
is
the
the
dates
at
which
we're
going
to
pull
the
throttle
branches
and
do
the
dot
zero
and
not
one
really
say,
I,
think
those
are
the
really
important
things
we
have
to
agree
on.
C
E
C
E
E
It's
probably
you
know
a
good
one
to
call,
but
I
feel
like
architecture
calls
a
loaded
term,
which
then
implies
that
we're
actually
going
to
argue
about
how
the
architecture
should
work
on
that
call,
and
that's
not
the
purpose
of
this
one
that
one
should
be
relegated
to
like
one
off
so
a
couple
things
though,
that's
like
for
the
whole
group,
I
added
a
few
more
bullets
here
is
so
the
recordings
in
meeting
minutes
that
makes
sense
so
yeah,
Ian
and
I
we've
started
a
rough
draft
on
a
glossary,
I'm,
pretty
sure.
E
C
E
Perfect
so
Nikhil
I've
been
I
think
tomorrow.
What
we
want
to
do
is
this
is
like
the
bottom
layer
of
our
you
know
as
the
foundation
of
our
houses.
We
need
to
get
all
of
these
terms.
Satisfied,
there's
a
couple
of
things
that
you
know
and
some
of
the
specs
I've
called
out.
Like
you
know,
we've
got
data
plane
there,
but
depending
on
which
you
know
spidery
spikes
slide
deck
you're
looking
at
in
in
SMD,
sometimes
refers
to
the
demon
and
other
times
it
refers
to
the
data
plane.
Things
like
that.
E
A
Things
will
have
abbreviations
that
we
use
and
getting
them
along
with
the
terms
is
also
super.
Helpful
I
also
want
to
be
really
really
really
really
clear
that
some
of
the
choices
of
abbreviations
have
evolved
a
little
bit
so
like.
A
If
you
look
at
the
very
very
early
decks,
the
network
service
manager
was
abbreviated,
NSM,
which
turns
out
to
have
been
a
terrible
idea,
and
then
the
one
the
next
I
presented
a
cute
con
I
was
calling
it
an
SMD
because
that's
what
the
process
was
named,
that
turns
out
to
be
also
less
confusing,
but
has
some
confusion,
points
and
I
think
Nikolay
proposed
abbreviating
at
NS,
M
gr,
which
I
think
is
a
better
abbreviation,
so
don't
feel
bound
by
the
well.
It's
named
this
way
in
the
back.
E
And
this
goes
back
to
the
the
dot
0.1
released
to
write
is
when
you're
definitely
like
going
full-bore
releasing
this
out
to
the
great
blue
yonder.
We
want
a
little
bit
of
solidity
around
what
things
are
so
that
way
when
people
are
asking
questions
are
coming
to
the
community
and
stuff,
it's
clear
for
them,
but.
C
E
A
E
E
C
A
To
that
in
the
chat
and
you'll
see
like
a
bunch
of
the
collateral,
is
there
there's
a
subdirectory
for
specifications?
There's
a
subdirectory
where
collateral
for
the
SF
logo
has
been
put
so
that
folks
can
get
that
so
that
does
exist
there.
If
there's
anybody
whom
write
access
to
be
able
to
add
files
to
that
folder,
please.
A
Let
me
know
the
folder
permissions
by
default,
make
everything
that's
put
in
that
folder
visible,
but
not
necessarily
world
writable,
and
for
some
things
you
want
world
write
ability
and
for
some
things
you
don't
right
and
and
I
think
probably
Google.
Docs
is
an
awesome
place
to
marshal
documentation
because
it
makes
it
super
easy
to
collaborate.
A
But
as
things
actually
settle
out,
we'll
probably
then
want
to
transition
them
to
markdown
where
they
can
go
on
the
website
or
in
the
repo
or
whatever,
and
we
seek
to
figure
out
where
and
how
we
want
to
put
those
things
you
know
so
that
become
you
know,
do
we
want
it
to
be
just
a
sub
page
on
the
network
service
mesh
page?
Do
we
want
to
have
a
Doc's
done
that
works
service
mission
at
I/o
URL?
We've
got
a
lot
of
options
that
we
just
have
to
kind
of
figure
out
what
works
for
us.
F
A
Stroke,
Spears
are
very
likely,
oh
come,
but
whatever
ends
up
working
for
the
community
working
on
the
docs.
It's
probably
the
Duster.
No,
the
reason
I.
C
E
Cool-
and
we
don't
have
to
solve
that
right
now
in
this
call,
I
just
wanted
to
call
it
out
that
documentation
is
kind
of
scattered.
This
drive
definitely
helps
I'm,
not
about
recreating
work
that
I
don't
have
to,
and
then
the
final
bullet
is
I'm
just
going
to
throw
this
question
out
there
for,
like
the
official
documentation,
do
we
want
to
come
up
with
some
kind
of
like
consistency,
or
is
it
just
shooters
choice
as
we
submit
documents
and
I
put
lucidchart
there
as
an
example,
it
doesn't
have
to
be
it.
E
You
can
get
a
free
account
and
you
know
open
up
files,
it's
kind
of
like
Google
Docs.
It
has
a
lot
of
the
same
challenges
that
was
just
called
out
with
Google
Docs,
because
anybody
can
go
in
and
mess
around
with
it
I
mean
you
can
deal
with
permissions,
but
then
that
becomes
a
full-time
job
in
itself,
managing
it
but
I.
A
Know
our
each
way
yo
common
will
conceal,
which
is
an
important
consideration.
I
think
you
also
want
to
make
sure
that
whatever
imagery
we
have
is
something
that
somebody
can
come
back
and
edit
and
revise
easily.
So
one
of
the
things
I've
tried
to
do,
for
example,
is
when
I
draw
a
diagram,
so
I'm
not
suggesting
this
is
the
right
way
to
diagram
right.
E
And,
like
I
said,
if
you're
not
a
Photoshop
master,
then
you
can
also
just
like
sit
there.
There
are
online
tools
that
are
just
like
actual
modeling
and
flow
diagram
tools
that
we
could
all
use
and
you
can
share
the
permissions
and
at
some
point
you
want
to
lock
it
down,
but
you
could,
like
you,
know
the
equivalent
of
like
an
online
Visio
or
something
right,
just
so
you're
not
trying
to
force
some
type
of
you
know:
PowerPoint
type
application
to
do
stuff
that
it
wasn't
really
intended
to
do
to.
A
Be
super
clear,
I.
Don't
personally
have
strong
opinions
as
to
what
that
tool
should
be.
My
my
strong
opinions
are
about
characteristics
of
that
tool.
In
terms
of
anybody
can
access
it
free.
We
can
provide
the
ability
to
share
and
get
to
the
originals
for
things
that
are
being
embedded
in
our
pages,
so
the
next
guy
who
edits
it
can
easily
do
that.
Those
are
characteristics
of
a
solution,
a
particular
choice
of
a
solution,
I'm
pretty
agnostic
about
I'm.
E
A
E
All
I
had
Nikolai
so
I'm,
but
just
so
everyone
knows
I
forgot.
The
very
first
thing
you
asked
me
to
talk
about
was
the
poll,
so
most
of
us
wanted
Thursday,
but
most
of
the
key
players
couldn't
make
Thursday's
and
so
the
next
highest
one
was
Wednesday
morning,
8
a.m.
Pacific
time,
and
just
for
those
who
haven't
been
tracking
it.
It's
basically
going
to
be
document
review,
call
so
we'll
cover
like
high-level
architectural
concepts,
definitions
things
like
that
with
either
Nikolay
Eid
or
Frederick.
E
A
There
we
go
yeah
I'm,
not
necessarily
a
deep
dive
on
these
specs
here
in
this
call,
unless
there
are
people
who
feel
strongly
that
there's
aspect
than
what
a
dive
into
in
which
case
I
think
that's
awesome.
What
I
wanted
to
do
was
continue
to
draw
attention
to
the
kinds
of
things
where
the
community
is
trying
to
work
out
specs
for
things
so
that
we
can
sort
of
things
often
end
up
better
when
there's
a
cup
there's
the
possibility
of
conversation
around
them
and
I
do
want
to
be
really
clear.
A
The
specs
process
we
have
is
not
a
gating
process
right.
You
don't
have
to
go
and
file
us
back
and
write
us
back
and
debate
a
spec
in
order
to
actually
make
a
contribution
at
all.
That
said,
you'll
often
I'm.
You
will
often
find
that
the
process
is,
is
helpful
and
putting
the
other
a
contribution.
So
if
you
feel
it
serves
you
please
do
and
know
that
there's
a
good
way
to
do
that.
There's
a
board
where
we
can
add
the
cards.
We
typically
have
been
filing
them
as
issues
they.
A
Those
issues
will
typically
link
into
a
Google
Doc
for
collaboration
and
then
once
settle
we'll
copy
that
into
the
issue.
So
we
get
a
record
of
what
we
think
we're
going
to
do
the
current
stuff
that
we
have
right
now.
We've
got
a
couple
around
doc.
You,
the
NSE,
request,
documentation
and
high-level
component
document
that
Frederick
put
in
that.
Don't
have
associated
issues
yet
I
think
that's
been
a
role
in
some
of
the
documentation
things.
A
We
do
have
a
spec
that
Daniel
Bernier
had
started
around
SRB
six
for
remote
mechanisms.
So
if
you're
interested
in
not
that's,
probably
a
good
one
to
go
and
comment
on,
because
I
think
I
can't
begin
to
explain
to
the
folks
who
are
not
networking
people,
how
amazing
segment
writing
v6
is.
If
you
love
ipv6,
you
should
be
using
signet
writing
v6.
A
That
said,
it's
just
one
of
many
things
that
network
service
will
support
other
respects
that
are
sort
of
in
process.
There's
a
spec
that
started
up
about
sessions
payload
so
think
of
this.
This
way,
if
I
want
to
interpose
like
an
envoy
pod,
you
want
to
make
sure
you
get
the
right
same
load
for
that
and
you
look
at
the
existing
payloads.
A
We've
had
they've
been
things
like
Ethernet
or
IP,
etc,
and
none
of
those
are
really
quite
the
right
payload
for
scooped
up
all
the
TCP
UDP
connections
that
are
going
out
this
interface
and
deliver
them
to
a
proxy
port
on
a
proxy
and
so
that
the
sessions
payload
type
was
an
attempt
to
semantically
specify
what
that
payload.
What
that
kind
of
payload
would
look
like,
because
good
semantics
are
super
important
and
it's
super
helpful.
A
Then
we've
got
the
spec
that
Nikolai's
got
underway
for
the
innocent
release
process,
there's
a
spec
that
Fredrik
started
for
doing
envoys
and
network
service,
which
is
part
of
what
prompted
the
sessions
payload
type
spec.
There's
an
ongoing
conversation
that
Matthew
Ron
kicked
off
about
metrics
for
monitoring,
cross,
connects
and
monitor
connections.
This
has
been
kind
of
super
interesting
like.
Where
do
we
put
them?
What
measures
can
we
collect?
A
How
we
might
we
use
them
and
then
we've
got
a
bunch
of
things,
sort
of
if
it's
out
there
and
more
or
less
in
a
good
position
but
being
reviewed
like
reading
this
probes.
We
just
currently
being
worked
on,
there's
a
really
interesting
one
on
creating
a
proxy
NSM
for
doing
creating.
For
those
of
you
seen
the
talks
and
seeing
us
talk
about
the
create
verb.
A
One
of
the
things
we
came
to
realize
is:
we
don't
actually
need
a
create
herb
in
the
network
service
policy
because
you
can
do
the
create
activity
with
a
proxy
NSM.
So
it
was
a
really
good
example
of
the
network
service
mission
architecture
getting
simpler
and
more
powerful.
At
the
same
time,
we've
almost
actually
got
a
complete
implementation
now
on
the
mutating
admission
controller,
which
is
super
helpful,
but
is
it's
good
to
go?
A
Take
a
look
at
that
and
we've
got
some
really
interesting
discussions
happening
around
inter
domain
network
service
mesh,
how
we
handle
crossing
different
domains
and
then
also
sort
of
as
a
shoot
out
about
his
approach
to
having
network
service
mesh
deal
with
physical
NICs,
including
sr
iove
and
physical
networks.
So
particularly
for
folk
just
interested
in
that
efi,
these
are
going
to
be
super
fascinating
topics
and
then
under
very
active
discussion.
A
Yeah
I
think
that's
a
super
good
idea
because,
as
we
sort
of
point
out,
Google,
Docs
or
a
great
way
for
to
collaborate
on
this
sort
of
thing,
they're
great
for
things
like
meeting
minutes
that
are
kind
of
our
running
log,
but
they're
they're,
not
a
fantastic
archival,
medium
for
specs.
So
yes,
let's
go
these
things
moved
over
and
at
least
into
the
issues,
if
not
into
the
repo
okay.
A
What
do
you
think
I
do
want
to
be
really
clear
about
like
if
folks
have
things
they
would
like
to
try
and
figure
out
specking
do
the
mechanics
of
github.
If
you
want
to
add
a
card
to
this,
it
requires
a
certain
level
of
privilege.
This
is
not
generally
available.
C
A
Of
all
right,
I
intended
my
general
preference
but
frankly,
is
to
operate
by
consensus
in
all
circumstances
in
which
that's
a
workable
method
of
figuring
things
out,
so
I
think
you're
actually
probably
had
a
really
good
a
really
good
heuristic
there,
which
is
when
something
would
have
converged
to
the
point
where
we've
got
the
implementation
coming
in
we're
really
not
talking
at
that
point
about
debating
this
back
we're
talking
about
reviewing
the
code
and
it's
possible
that
in
reviewing
the
code,
we
discover
that
there's
something
about
the
spec.
That
was
suboptimal.
A
F
B
Even
implemented,
like
I,
think
I
like
theirs,
we
might
have
a
spec
that
we
we
create,
but
then
no
one
in
the
no
one's
ready
to
take
it
on
yet
and
may
not
be
able
to
get
let's
stay
for
like
six
months,
because
we
all
have
things
just
from
a
time
perspective.
You
know,
and
then
it
ended
up
sitting
in
this
queue
for
taking
up
space
for
all
that
time.
B
So
if
we
so,
if
we
end
up
so
that's
one
risk
with
with
I
expect
implemented,
it
may
actually
be
able
to
miss,
saw
misleading
we're
actually
implementing
it
yet
or
maybe
it's
only
pretty
suspect
we
decided
in
the
long
run.
Well,
we
actually
don't
want
to
implement
this
thing
yeah,
so
it's,
but
it
was
still
got
able
to
have
that
information
and
that
discussion
somewhere,
you
know,
so
we
can
still
show
it
off
somewhere.
So
that's
why
I
was
thinking
that
the
end
result
of
it
would
be
marked
down
in
the
code.
B
E
So
ed
I
feel
like
you're
gonna,
regret,
throwing
this
out
there,
but
you
said
maybe
do
a
deep
dive
on
one
of
the
specs,
with
you
mind,
clicking
on
inner
domain
and
SM.
Since
we
have
fourteen
minutes.
D
A
Well,
sometimes,
you
discover
as
you're
going
along,
but
what
you
thought
you
were
gonna
do
turns
out
to
be
a
terrible,
terrible
idea.
So
there's
back-and-forth
there
definitely,
but
at
the
end
of
the
day,
what
would
actually
use
in
the
repo
and
what
we
say
is
the
specification
of
what
should
be
in
the
repo
we're
gonna
go
put
that
on
the
repo.
Those
two
should
damn
well
match
right,
so
you
would,
if
you
have
a
spec,
and
this
is
what
we
all
thought
we
should
do
and
you
went
and
tried
to
do
it.
A
E
A
I
talked
about
the
deep
diving:
we
have
a
network
service
registry
right,
we
have
a
place
with
network
service,
endpoints
register
that
they
will
provide
services
and
so
that
they
can.
You
know
somebody
can
go,
look
those
off
and
we're.
Also
we
keep
the
network
service
records
in
the
network
service
manager
records.
That's
basically
a
registry.
We
happen
to
do
that
in
the
Carreras
api
server.
Right
now,
with
your
that
is
cluster.
The
way
the
architecture
is
built
that
doesn't
have
to
be
bad.
It
just
happens
to
be
a
convenient
way.
A
A
A
A
A
You
know,
then,
I've
got
some
other
kind
of
domain
with
its
own
register
network
service
registry
and
its
own
network
service
managers
managing
their
own
clients
and
their
own
Damons,
and
this
could
be
another
cluster,
another
crew,
but
have
these
cluster
this
other
domain
could
be
a
physical
network.
This
other
domain
could
be
a
fin.
That's
running
a
bunch
of
the
ends
that
are
providing
network
services
can.
E
We
talk
that
real,
quick,
that
the
physical
network,
or
also
like
the
concept
of
of
them,
so
like
so
I,
have
this
registry
right.
You
know
I'm
just
kind
of
curious
like
since
right
now
it
is
somewhat
coupled
with
like
the
kubernetes
api
server
like
how
is
the
daemon
getting
put
on
all
these
nodes,
that
would
say
be
in
a
VMware
or
an
OpenStack
environment,
and
then,
when
you
put
it
out
there,
what
is
preventing
NSM
from
competing,
you
know
or
having
state
issues
with
say,
Neutron
or
NSX.
A
The
first
one
is,
it
turns
out
when
you
look
at
network
service
mesh.
What
we
have
defined
is
a
4
in
terms
of
the
registry
is
a
G,
RPC
API
and
let
me
go
ahead
and
actually
G
RPC
API
right
now,
because
it's
going
to
make
it
super
easier
to
talk
about.
So
we
have
defined
a
G,
RPC
API
for
registries
and
that
GRP
api
for
the
registries
basically
has
a
network
service
registry,
then
register
and
a
ceiling
fund
a
little
bigger.
A
It
has
a
register,
NSC
call
and
a
removing
a
seek
all
right,
and
it
has
a
5
network
service
call
for
doing
discovery,
and
this
is
this
is
actually
the
way
network
service
measured,
rocks
with
things
like
the
network
service
registry,
so
every
network
service
manager.
This
is
the
api
that
it's
talking
to
talk
to
its
network
service
registry.
Now
we
have
a
tiny
little
container
that
exposes
these
api's
and
then
goes
and
stores
the
information
and
looks
up
the
information
in
the
kubernetes
api
server.
A
But
that's
see
literally,
that
containers
probably
a
hundred
lines
of
go
code,
and
so
none
of
the
network
service
manager
itself
is
not
actually
talking
to
the
kubernetes
api
server.
It's
talking
these
g
RPC
api's
to
that
little
tiny
container.
That's
getting
us
to
that!
So
if
I
wanted
to
have
a
different
kind
of
registry
that
was
going
to
go
right
in
my
vin.
For
some
reason,
then
all
I
have
to
do
is
expose
these
api's
brettly
and
I
am
a
network
service
register.
A
E
So
would
say:
I
hit
these
years
jeers
from
this
sorry,
I
can't
talk
your
pc
api's
and
I
make
a
request.
You
know
the
other
registry
there's
at
that
point.
It
make
an
API
call
to
Neutron,
as
opposed
to
trying
to
directly
program
the
data
plane
and
the
NS
sees
itself
or
like
what
does
that
interaction.
Look
like
okay,.
A
So
you're
talking
to
the
registry,
all
you're
really
saying
to
the
registry
is
either
hey
I'm
in
networks,
I
have
a
network
service
in
point
or
please
remove
it
as
well
or
you're.
Saying
find
me
a
network
service
right.
Those
are
the
conversations
you
have
with
the
registry,
so
in
that
your
registry
doesn't
actually
do
anything
that
provides
you
with
information
or
store
information
for
you.
So
we
have
to
walk
a
little
further
ago
story
to
get
to
this
point.
I
think
you're
really
curious
about.
A
So
could
you
give
me
a
real
quick
second
and
we'll
get
we
get
a
little
further
down?
We
can
revisit
it.
So
basically
the
you
know.
Basically,
so
if
I've
got
a
crewman
in
this
cluster
or
some
other
domain
and
there's
some
domain,
that
I
would
like
to
get
a
network
service
from
the
current
proposal
is
to
say
look
previously,
you
might
have
asked
for
secure
Internet
connectivity
and
if
you
want
it
from
the
example.com
domain,
ask
for
secure
Internet
connectivity
example.com
and
then
we
will
interpret
the
example.com
portion
as
oh
wait.
A
This
comes
from
outside
the
domain
of
the
recurrent
request
right.
So
at
that
point
and
I
want
a
bunch
of
briefly
the
Nikolai's
put
it
out.
This
doesn't
have
to
be
welded
to
DNS
I
agree
with
him,
but
we'll
talk
about
it
for
Deanna's,
because
it's
easy
at
that
point.
Dns
has
a
marvelous
mechanism
called
SRV
records
and
you
could
simply
look
up
the
SRV
record
for
the
network
service
registry
for
example.com
in
DNS
you
get
back
a
port
and
a
domain
name.
A
So
now
you
know,
as
the
network
service
manager
in
the
first
domain
you
now
you
know
how
to
find
the
network
service
registry
in
the
second
domain,
which
means
you
can
use
the
find
network
service.
G
RPC
call
to
ask
that
network
service
registry-
hey
man,
I've,
been
told
I.
Someone
wants
secure,
Internet
connectivity
got
example.com
your
nerve,
the
registry,
for
that
tells
me
about
secure
Internet
connectivity
in
your
domain.
A
A
If
you
want
to
set
up
a
connection
with
them,
and
so
in
that
case,
you
would
use
the
same
remote
network
service,
not
request
that
you
use
inside
your
domain
for
intro
domain,
you
would
use
to
talk
to
a
network
service
manager
from
a
different
domain
and
then
effectively
you
end
up
negotiating
the
connection
in
exactly
the
same
way
you
would
for
inter
domain.
It
just
happens
that
the
network
service
manage
you're
talking
to
is
not
anger,
domain,
it
somewhere
else,
and
then
the
building
out
of
the
tunnel
is
also
very
much
the
same.
A
The
network
service
manager
in
the
other
domain
will
you
know
plumb
or
interface
into
the
network
service
endpoint
that
he
manages
set
up
his
into
the
tunnel.
The
network
service
manager,
your
domain
does
the
same
thing
and
and
so
effectively
other
than
this
one
step
where
you
realize.
Oh
we're
going
to
a
different
domain.
I
have
to
find
the
service
registry
for
that
domain
other
than
that
I'm
stopped.
The
steps
are
pretty
much
the
same
as
if
you
were
in
dealing
in
the
same
domain.
A
Does
that
make
sense,
and
so
what
you're?
Getting
to
your
question
that
you
asked
Jeffery
about
the
the
network
service
manager
for
a
vim,
but
never
service
manager
refer
them
would
simply
be
a
set
of
code.
That's
specific
to
that
vim
that
if
someone
came
in
and
said,
I
would
like
to
be
connected
to
a
network
service
and
Neutron
network
63
or
whatever
would
know
how
to
arrange
for
a
tunnel
that
would
connect
you
to
that
Neutron
network.
E
Does
this
is
definitely
something
I
would
like
to
dive
deeper
into
with
you
for
sure
to
his
I?
Think
in
the
near
term,
which
you're
going
to
see
letters
like
my
company
do?
Is
we've
already
got
a
bunch
of
OpenStack
out
there?
We've
got
a
bunch
of
vmware
out
there,
we're
running
virtual
firewalls
we're
running
virtual
whatever,
but
maybe
all
of
my
web
app
developers
on
the
back
end
for,
like
you
know,
video
experience.
A
A
C
So
Fred
yeah
this
would
definitely
be
interesting
to
be
put
in
a
spec
where
we
can
collaborate
and
discuss
about
all
these
things,
because
at
least
up
till
now
the
specs
seem
to
be
the
the
best
way
to
exchange
the
information
there
and
everyone
can.
You
know
just
process
it,
his
own
lands
and
express
his
opinion.
Okay,
I
guess
that
that
we
should
wrap
up
the
call
with
this.