►
From YouTube: Network Service Mesh WG Meeting - 2018-09-14
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
Okay,
so
let's
go
ahead
and
get
started,
so
we
have
a
couple
upcoming
events.
We
have
ons
Europe
coming
up
in
Amsterdam
from
September
25th
27th.
We
have
a
main
presentation
that
is
going
to
be.
This
is
going
to
be
done
by
both
me
and
Kyle.
So
if
you
were
going
to
be
in
ons
Amsterdam,
we
would
we
would
love
to
have
you
there.
A
The
information
that
we're
going
to
be
covering
is
is
all
information
that
you
are
all
probably
familiar
with,
but
I
think
it
would
also
be
a
good
opportunity
to
further
discuss
and
clarify
and
and
so
well
yeah.
We
would
love
to
see
ya
and
anyone
who
who's
present.
Here
we
would
love
to
see
you
there
thanks.
A
And
in
terms
of
theirs,
there's
also
an
opportunity
for
for
speaking
at
the
FDI
o
mini
summit
as
well.
So
if
you
want
so,
we
have
a
team
con
China
coming
up,
I
I,
don't
know
if
we
have
any
talks
in
there
and
should
know
and
that'll
hop
on
in
a
short
while,
so
we
can,
we
can
ask
them.
We
have
cube
con,
see
Seattle
coming
up,
we've
put
in
some
some
talks
there.
A
We
won't
know
until
a
little
while
whether
the
talks
have
been
accepted,
but
we
have
a
few
talks
that
have
been
submitted
by
various
people
and
finally
running
is
at
the
same
or
ripe
at
the
same
time
as
cube
con
Seattle
at
a
coupon.
Seattle
is
the
FDI
o
mini
summit,
and
so
the
call
for
papers
closes
on
October
5th.
So
if
you
would
like
to
talk
about
a
Fido,
related
integration
and
looking
at
you
Tom,
please
please
go
ahead
and
submit
so
I.
C
A
A
A
First
and
then
we
can
follow
up
with
the
action
items
on
the
important
ones
so,
and
I
would
like
to
have
Edie
here
for
one
of
the
conversations
so
I'm
going
to
put
that
at
the
end,
so
that
pewter
one
is
going
to
be
on
so
we're
reviewing
the
the
api's
and
our
texture.
So
just
if
so
just
a
bit
of
background,
so
the
initial
set
of
API
is
that
we
created
were
literally
like
the
first
thing
that
we
had.
We
added
to
the
project.
A
C
C
A
C
I'm
being
relatively
new
with
this
and
I
realize,
I
actually
got
a
question
on
the
chat
about
how
far
are
gone
and
whether
there
was
a
dev
branch
or
a
pull
request.
Yet
does
not
yes,
I
at
this
point
and
carefully
watching
the
discussion
about
the
protocol
between
the
NS
NSM
endpoint
and
the
extended
or
NS
m
to
see
exactly
how
how
this
will
fit
in.
A
A
Yeah,
just
to
just
make
it
clear
one
of
our
one
of
our
goals
with
that
architectural
review
is
that
we
want
to
create
a
document
or
some
literature
that
describes
the
architecture
and
more
detail
and
with
more
con
with
with
some
of
the
patterns
that
we
expect
to
see.
So
because,
right
now,
a
lot
of
it
is
is
in
the
heads
of
me
and
Edie,
and
so
so
even
other
people
who
are
working
intimately
in
the
in
the
project
need
more
context
as
well.
In
order
to
be
successful.
A
Okay,
well,
we'll
buy
my
time
just
just
so.
You
know
my
times:
gonna
be
a
little
bit
limited
up
to
awareness
demo,
but
after
the
after
the
ons
time
of
rather
sorry
for
the
us
conference.
But
after
the
ons
conference,
then
my
time
should
free
up
a
lot
and
let's
work
closely
together
and
iterate
on
this
as
well.
A
So
you
order
to
get
the
VPP
cross-connect
done
this
something
good
plan
agreed
cool,
so
hello
ad,
so
we
shuffled
around
a
few
things
in
the
agenda
so
that
we
can
make
sure
that
you're
that
you're
here
for
four
things
so
we're
just
finishing
up
the
discussion
on
TPP
cross-connect.
That's
that
tom
is
heading
up
so.
A
E
A
C
E
A
Are
cool
yeah,
so
it
could
be.
It
could
so
there's
a
challenge
that
we
have
and
that
we
only
worse
in
the
interest
of
trying
to
create
more
presentations,
Lots
in
a
limited
amount
of
time
the
the
organizers
have
reduced
has
over
time
the
size
of
their
car
of
the
talks.
So,
for
example,
the
talks
used
to
be
an
hour
and
then
add
at
hope,
it's
or
summit
talk
that
I
gave
was
40
minutes.
This
talk
is
gonna,
be
thirty
minutes,
and
so
so
we
have
to
get
all
effectively
we're
gonna
end
up.
A
A
We
also
have
a
varying
degrees
of
of
expertise,
so
so
we're
also
to
take
that
into
into
account,
but
I
think
what
we
should
do
is
as
Kyle
and
I
can
give
the
initial
basic.
This
is
what
it
is
maybe
go
over
one
of
the
one
of
the
use
case
during
architecture
diagram
showing
what
it
looks
like
could
drive
into
one
of
the
use
cases
and
discuss,
or
maybe
the
other
way
around
driving
use
cases
like
Sarah
or
so
on,
with
the
VP.
A
And
then
direct
them
find
a
way
to
direct
people
to
help
find
a
network
service
champion.
Who
can
go
more
in
detail
which
doesn't
have
to
be
me
or
Kyle
anyone
who's
there?
Who's
in
this
conversation
can
help
with
that
as
well,
but
effectively
we
want
people
to
work
out
how
to
how
to
find
us
and
how
to
get
involved.
A
I
think
like
to
me:
that's
the
most
important
part
is:
how
do
we
get
people
involved,
because
the
more
people
that
we
have
typing
than
the
more
people
that
we
have
understanding
and
developing
network
service,
endpoints
or
or
en
SMS
or
so
on
the
better?
So
in
fact
we
want
to
try
to
build
that
community.
D
A
B
D
So
I'll
just
I'll,
just
summarize
it
so
Fredrik
guys
just
briefly
bringing
it
back,
I
was
going
to
agree
with
with
everything
you
were
saying
in
30
minutes
is,
is
tight
and
I
like
the
idea
of
the
main
kind
of
the
main
point.
Being
you
know,
here's
what
it
is
and
here's
where
to
find
us
to
continue
the
discussion.
A
G
A
G
E
E
A
Cool
well,
in
that
particular
scenario,
I
think
from
the
ONS
Amsterdam.
We
don't
have
any
other
special
special
sessions
or
like
there's
no
cloud
native
site,
a
presentation
or
anything
like
that.
So
so
I
think
we
can
probably
keep
Amsterdam
simple
and
then
the
focus
after
that's
gonna
have
to
be
on
getting
a
proof-of-concept
done
with
the
after
after
ons
Amsterdam
and
then
really
having
something
that
we
can
hit
out
of
the
park
with
over
it
Yukon.
So
this
is
like
a
message
we're
coming.
A
E
A
So
we
have
removing
channels
from
the
API,
so
that's
part
of
the
API,
our
review
and
in
the
architecture
review.
This
is
the
we're
already
actively
working
on
so
I
thought,
I'd
single
it
out.
So
just
some
context.
If
and
when
we
were
going
through
the
various
to
the
various
scenarios.
One
of
the
things
that
we
discovered
was
that
we
would
often
every
time
that
we
would
come
up
with
a
network
service.
A
After
the
fact
when
we
started
discussing
removing
channels,
one
of
the
things
that
I
thought
was
well,
if
you
want
a
data
channel
for
a
specific
thing
or
a
controller
management
channel,
those
could
individually
be
network
services
themselves
as
well.
So
you
would
so
if
you
need
access
to
the
management
plane,
you
would
explicitly
ask
for
that
as
run
that
scenario
and
not
get
it
as
a
channel,
and
so
so
I
think
it.
In
this
scenario
we
don't
break
any
use
cases,
it
would
just
be
a.
B
E
B
B
E
It
is
actually
really
so
thank
you
for
asking
any.
What
are
the
things
the
network
service
mesh
does?
Is?
It
leaves
completely
alone
the
kubernetes
networking,
because
all
the
other
proposals
to
date
make
a
real
mess
of
the
kubernetes
networking
in
the
process
of
trying
to
get
the
things
that
we
need
for
nfe
and
so
network
service.
Mesh
just
leaves
that
alone
right
and
we
bring
in
the
l2
l3
connections
for
the
CNS
you
want
to
talk
to,
and-
and
it
is
most
people
when
they
look
at
deploying
CNF
Cindy
Cooper
Nettie's.
E
E
So
if
you're,
just
talking
about
the
interface
that
provides
you,
your
normal
kubernetes
networking,
your
kubernetes
metropoliz
Leuven
any
services
that
kind
of
stuff
right,
we
leave
that
completely
alone,
that's
being
provided
to
you
by
kubernetes.
It
doesn't
really
well.
They
don't
actually
want
to
add
anything
to
that
talks
about
interfaces
or
sub
next,
and
so
we
leave
that
be.
B
It
no
no
make
sense
yeah
yeah
yeah.
This
is
perfect.
Now
I
was
actually
even
further
delineating
among
the
interfaces
which
network
service
mesh
wants.
Is
that
a
special
treatment
and
management
that
that
I
was
actually
there
already?
So
among
I
mean
not
the
kubernetes
management
interface?
But
let's
say
you
how
pull
up
interfaces
and
then
you
know
you
may
use
one
for
your
external
management
of
the
CNF
and
other
is
actually
the
CNF
data
plane.
Is
there
any
special
treatment
on
that?
Cnf
management
interface,
which
network
service
mesh
wounds,
looks
like
yeah.
E
C
This
is
this
is
what
I
was
thinking
and
tell
me
if
I'm
thinking
this
is
too
convoluted,
but
to
me
I
thought
it
was
fairly
straightforward
that,
for
example,
in
this
cross-connect
project
or
this
or
call
it
a
bridge
domain
provider
that
the
MSM
would
just
requested
it,
the
Ennis,
the
NSM
endpoint,
would
arrange
for
the
in
effect
the
virtual
physical
connections.
C
You
know,
whatever
is
underneath
that
layer
to
provider
and
they
and
the
standing
up
the
actual
data
playing
demons
itself
and
things
like
that,
but
the
management
could
be
you
log
into
you,
you,
you
know
you
just
talk
that
you
get
an
SSH
into
that
container
in
the
issue
of
VPP
cuddle
commands
or
the
management
could
just
be
that
that
container
has
an
IP
and
the
management
traffic
goes
through
the
IP,
and
it
was
some
gnaw
on
that.
Copper,
restaurant.
That's.
A
A
So
anyways
so
we've
so
we're
in
the
process
of
removing
channels
from
the
API.
So
when
you
request
a
specific
service,
you're
ooh,
there's,
there's
no
longer
gonna
be
the
concept
of
a
channel.
It's
just
gonna,
be
you
request
the
service
and
you
and
then
that
what
you
get
delivered
is
a
cross.
Connect
to
that
service
does.
Does
that
make
sense.
G
G
E
E
G
So
basically,
I
was
just
saying
that
the
actual
management
interface
you
are
talking
about
it
can
be
considered
as
a
service.
So
your
application
requests
give
me
management
interface,
which
is
a
network
service
and
you'll,
have
your
extra
interface
in
your
board
and
then
you
just
use
it
for
your
management
purposes.
C
E
Here's
where
you've
been
incredibly
helpful
to
this
romkey
with
your
question,
all
the
examples
that
we
currently
show
show
a
network
service
endpoint
just
as
something
that
that
pods
connect
to
to
get
a
network
service.
What
they
don't
show
is
that
network
service
endpoint
could
be
consuming
network
services
from
other
places
like
consuming
a
management
interface
networks
of
us,
and
so
that
you
will
close
that
gap
in
what
we
talk
about.
So
thank
you
so
much.
Okay,.
B
E
Who've
got
experience
with
VPP,
so
you'll
definitely
see
some
vidi-vidi
to
play
into
the
mix,
but
effectively
what
ends
up
with
starting
to
emerge
is
the
network
service
manager
will
have
a
G
RPC
API
that
it
speaks
to
whatever
the
data
plane
is
and
ask
that
local
data
playing
to
set
up
whatever
has
to
be
set
up,
and
so,
if
you
have
a
non
VPP
data
playing,
you
just
need
your
data
playing
to
expose
that
interface
to
the
network
service
manager
and
everything
should
follow.
Fine,
okay,.
E
G
E
That
document,
right
now
you
know,
but
one
thing
I
do
want
to
be
really
clear
about,
is
if
you
have
interest
in
other
data,
Flynn's
plugging
in
here,
none
of
this
stuff
is
set
in
stone
yet,
and
so,
if
you
look
at
it
and
say,
okay,
I
don't
quite
understand
how,
when
we
do
this
thing
that
I
care
about,
please
bring
those
things
up
right
because,
generally
speaking
often,
they
involve
discovering
that
a
little
bit
more
about
what
we're
doing.
Does
that
make
sense.
Yep.
A
A
A
A
The
guidance
is
incredibly
important,
so
we
want
to
make
sure
that
that
everyone
like
right
now,
we
each
person
will
have
a
different,
slightly
different
view
as
to
what
network
service
meshes,
and
so
we
want
to
reduce
those
those
differences
as
much
as
we
can.
So
we
can
get
more
effective
communication
and
more
effective,
more
effectively
implement.
But
what
do
we
want
to
implement
so
so
with
with
that
as
the
the
context
as
well,
so
the
the
first
area
that
we
started
to
look
at
was
was
specifically
the
G
RPC
endpoints
themselves.
E
So
one
of
the
things
that
let
me
actually
you
buy
at
the
risk
of
showing
up.
Finally,
we
were
just
scribbling
kind
of
deck,
but
you
know
me:
I,
find
pictures
of
almost
everything
we
were
trying
to
figure
out.
We
were
trying
to
sort
of
say,
okay.
Well,
what
are
the
different
reference
points
in
the
system
and
you
know,
and
what
do
they?
What
kinds
of
api's
do
we
have
with
them?
So
give
me
just
a
second
I
will
share
this
back.
I
do
apologize.
It
is
not
actually
need
for
presentation.
E
Can
everyone
see
the
shirt,
yeah
awesome
so
and
let
me
stick
the
link
to
the
slides
in
the
chat,
real
quick,
so
that
folks
can
get
to
it.
Generally
speaking,
I
do
all
of
my
decks
in
a
way
that
lets
everybody
get
to
them
right
off
the
bat.
So
sometimes
even
looking
up,
you
said,
but
if
you
look
here
the
components
you
have
are
you
have
on
every
node,
you
have
an
NS
m
and
then
you
know,
we've
got
also
the
kubernetes
api
server.
Whatever
the
data
plane
is,
this
would
be
gets
your
question
wrong.
E
Key.
We
don't
much
care
what
the
data
plane
is,
quite
frankly
as
long
as
it
people
work
with
across
connecting
and
then
you
have
whatever
pod
you
have,
that
wants
to
connect
to
a
network
service,
and
then
you
have
a
network
service,
endpoint
overhearing,
though,
to
the
NSC.
So
the
API,
the
pod
uses
over
G
RPC
to
ask
to
connect
whatever
service.
We
should
have
tentatively
named
the
pod
to
NSM
API,
because
it's
how
Apollo
talks
to
the
SM
and
that's
also
how
an
NSC
would
talk
to
its
NSM
to
expose
whatever
service
it
provides.
E
Obviously,
we've
talked
about
having
series
for
network
services,
Network,
Service,
endpoints
and
network
service
wirings.
Those
are
just
normal,
CR
DS
that
you
get
from
the
kubernetes
api
server.
If
you're
an
unsung,
we
talked
about
the
fact
that
to
an
SMS
have
to
negotiate
peer-to-peer
for,
certainly
what
is
the
remote?
What
are
the
remote
parameters
were
dealing
with
here?
What
kind
of
tunnel
what
kind
of
tunnel
parameters
and
that's
been
currently
creatively
named
the
MSM
to
NSM
API?
E
These
know
better
names
are
always
welcome,
and
then
this
was
the
API
was
talking
about
romkey,
where
that
every
service
manager
it
talks
to
whatever
data
playing
to
handle
the
cross-connect
and
that's
an
assembler
plate,
and
one
thing
they
don't
care
by
the
way
is
never
service.
Mention
only
really
deals
with
cross
connects
right,
so
you
want
a
virtual
bridge
domain.
That's
a
network
service
from
our
point
of
view
and
we're
perfectly
delighted
to
connect
you
to
that
network
service.
E
If
someone
is
providing
it,
but
but
because
it's
cross
connect
oriented,
it
ends
up
being
hyper
hyper
simple,
you
know,
so
you
wouldn't
have
to
configure
for
a
whole
bunch
of
machination
in
the
data
plane
about
this.
You
would
basically
just
have
to
give
enough
information
to
get
start.
The
cross
card
make.
B
E
With
the
data
playing
to
do,
is
it
absolute
to
create
an
interface?
Is
it
acid,
it's
local
side
of
the
tunnel
right,
so
Edison
one
would
create
this
interface
to
pop
the
pod.
It
would
create
its
side
of
the
tunnel
and
I
send
2
over
that
same
interface
to
whatever
it's
is
creates.
It
injects
the
interface
of
the
network
service
endpoints
and
creates
it's
at
all
and.
E
Most
most
holes
are
sort
of
B.
Do
we
have
the
parameters
matching
right?
Am
I
sending
the
excellent
to
the
right?
Ip
address
all
right
work,
great,
the
I.
You
know
and
then
the
same
is
true
Bo's
tunnel
thanks.
There
are
some
exceptions
like
gtp
that
are
much
more
complex,
but
but
for
most
total
times,
that's
really
what
you're
dealing
with.
E
Oh
so,
the
second
one
that
we
talked
about-
and
this
is
just
showing
the
API
enumeration-
we
talk
sometimes
out
of
the
e
NS
m
or
the
external
Innes
M-
and
this
is
just
sort
of
during
that
example.
The
way
the
e
NS
n
works,
isn't
just
a
network
service
manager
that
manages
some
aspect
of
something
that
is
not
on
in
your
cluster.
In
this
case
a
piece
of
your
physical
network,
and
so
all
the
API
is
stayed
the
same
and
NS
m.
E
One
would
still
talk
to
the
e
NS
m,
with
the
same
and
ascend
to
n
sm
e
RPC
api,
and
then
your
EMS
m
will
talk
whatever
it
is
that
it
has
to
do
to
your
physical
network
function
in
order
to
set
up
its
into
the
cross
connect.
You
know
that
might
be
met
cup
yeah,
it
might
be
whatever
I
mean
you're
out.
E
E
Cool
the
next
example
that
we
had
here
was:
you
can
also
use
the
n,
SMS
or
multi
cluster
behaviors,
because
from
the
point
of
view
of
cluster
1,
cluster
2
is
just
something
that's
out
there
in
the
world
right,
it's
external
to
cluster
1,
and
so
you
can
have
an
en
SM
that
allows
you
to
from
Clinton
that
would
advertise
some,
maybe
all
of
the
network
service
in
points
from
cluster
2
into
cluster
1.
And
then
you
know,
cluster
1
could
then
look
them
up.
E
You
could
actually
do
that.
That's
actually
you
would
need
something
we
do
the
advertisements
but
you're
right.
Someone
talk
directly
to
innocent
to
and
from
you
know,
Edison
once
point
of
view.
Ns
m2
is
an
external
yes,
but
yeah.
We
should
definitely
rework
that
in
this
direction.
Thank
you
for
being
that
off.
G
E
E
Cool
and
then
the
last
example
we
sort
of
showed
was
the
proxy
NSM
and
a
proxy
Aniston
is
an
interesting
beast,
because
essentially
it's
the
realization
that,
using
that
room
service,
wiring
I
can
actually
have
a
proxy
NSM
that
doesn't
actually
have
the
network
service
endpoint
at
all,
but
it
is
being
wired
into
the
middle
of
the
conversation,
so
that
I
could
bring
in
additional.
I
can
basically
put
my
thumb
on
the
scale.
E
Basically,
the
PN
SM
sitting
in
here
as
a
proxy
can
do
an
enormous
Lea
wide
range
of
things.
It
is
incredibly
powerful.
I
we
will
often
talk
about
it
as
being
the
light
saber
of
network
service
mesh
because
they
can
cut
through
anything.
But
if
you
were
not
strong
in
the
forest,
you're
likely
to
cut
your
own
damn
arm
off
I.
A
So
yeah
one
of
the
things
with
the
proxy
innocent
as
well
is
so
our
understanding
of
these
at
this
point
is
that
most
use
cases
will
be
able
to
be
solved
with
the
standard
network
service,
endpoint
or
the
external
NSM
for
controlling
something
that's
out
of
the
cluster,
so
so
the
p
NS
m.
When
someone
says
I
want
to
bring
in
the
p
NS
m,
to
use
a
phrase
that
that
uses
that's
an
indentation
is
to
think
more
of
your
problem
before
you
reach
for
it,
because
it
has
a
lot
of
power.
C
E
E
F
E
While
but
they're
hopeful
cool,
let's
see
what
else
do
we
have
here?
I
think
these
were
just
sliced
that
were
copied
and
in
case
we
were
going
to
use
them,
and
then
we
had
some
notes
here
where
Sergey
was
sort
of
talking
through
some
of
this
stuff.
Do
you
want
to
talk
through
some
of
your
notes?
Your
sergey.
G
Well,
I
guess
these
notes
are
less
relevant
since
most
of
the
stuff
now
is
in
the
document.
Api
review
document
and
I
encourage
people
to
go
through
and
make
sure
that,
let's
say
if
you
are
interested
in
some
applications,
make
sure
that
the
current
ia
API
gives
you
a
necessary
tools
to
pass
that
information
around
between
the
application
and
the
user
of
that
application.
So
please
review
and
comment
in
the
P
R,
which
is
in
the
document
yeah.
A
So
I
think
so
the
only
thing
that
I
think
in
terms
of
the
PMS
M
so
like
in
the
context
of
the
discussion
that
we
had
I,
think
it
makes
a
lot
of
sense
when
it
comes
down
to
actually
so
at
the
end
of
the
day.
Something
that
I
would
love
to
have
come
out
of.
This
is
something
that
is
something
a
little
bit
more
formal
than
the
than
the
brainstorming
deck.
So
after
we're
done
with
your.
A
On
you
know,
I'm
happy
to
spend
time
documenting
all
of
this,
the
same
way
that
we
did
see
what
is
NSM
document
before
mm-hmm.
You
know
and
follow
the
same
pattern,
but
say
this
is
the
architecture
and
describe
the
the
outcomes
of
it
and
describe
in
detail.
These
are
the
messages,
and
these
are
the
this-
is
the
pattern
and
we're
through
various
various
problems
and
something
that
would
be
absolutely
fantastic
and
we'll
tie
this
into
what
you're
doing
tom
is
one
of
the
examples
that
we'll
use
in
that
in
that
architecture.
A
Path
as
well,
we'll
be
going
through
what
we
did
in
order
to
make
the
VPP
example
work
after
we've
gone
through
all
of
the
all
of
the
documents,
and
that
can
turn
into
a
tutorial
effectively
for
people
who
want
to
implement
their
own
cross
connects
as
well.
So
it
ties
all
the
stories
together.
So
I
think
like
this
is
the
beginning
of
that
of
that
journey.
Yes,.
C
Exactly
and
everybody
please
and
I
heard
a
comment
understand
that
this
that
this
is
not
VPP
is
just
low-hanging
fruit.
The
way
I
see
it
and
and
my
own
approach
to
this
to
get
facts
on
the
ground
initially,
but
I,
don't
see
any
reason
why
you
couldn't
do
it
with
VSD
PDK,
for
example.
It's
just
that
the
that
the
demon
set
and
the
endpoint
or
the
external
NSM
has
to
manage
the
kinds
of
stuff
that
you
would
use
the
foot.
To
put
you
know,
oh
they
get
over
yes
running
in
a
you
know,.
C
And
that
it's
that's
it's
just
different
stuff
to
do
and
I
would
assume
that
once
we
have
one
done,
we
could
extrapolate
that
to
another
two
others,
there's
parallel
work
done.
The
people
who
are,
for
example,
are
working
on
Baltus
have
are
looking
at
this
all
differently,
because
they're,
of
course,
messin
with
thee
with
the
kubernetes
networking
api,
but
one
thing
they
have
in
the
common
is
they're
trying
to
generalize.
C
The
API
are
generalized
the
connections
of
the
data
plane
underneath
and
and
that's
the
ideas,
I
think
once
we
once
we
get
one
done,
then
we
can
go
back
and
make
sure
that
everything
sufficiently
generalized.
You
could
literally
unplug
one
day
to
plane
and
plug
in
another,
even
on
an
operating
system
or
on
a
bus
in
and
operate
network.
One.
E
Of
the
other
things
that
we
talked
about
a
little
bit
is,
there
may
be
more
than
one
data
plane
running
on
a
particular
because,
for
example,
you
know
not
every
data
plane
is
used
to
support
everything,
so
you
may
have
you
know
a
big
data
plane
that
is
very
smart
about.
How
do
you
plug
SRA
Phoenix
in
to
your
pods,
and
then
you
may
have
a
data
plane.
That's
very
smart
about
removals
cross,
connects
and
all
right.
A
C
C
B
E
E
You
know
the
story
is
that
narrative
detects
that
the
Pope
is
talking
about
showing
you
the
next
hour.
It
turns
out
that
nobody
actually
wants
a
necesario
v-neck,
like
that's
a
meaningless
request.
What
you
really
want
is
a
necesario
v-neck
that
provides
something
the
network
service
you
care
about
it's
plugged
into
some
network.
Maybe
it
has
some
ACLs
or
some
boss
applying
to
it.
It
has
it
meets
a
certain
kind
of
bandwidth,
etc
and
so
network
service
mesh
expresses.
E
E
That
is
actually
doing
the
thing
you
want
it
like.
If
you
want
a
particular
network
service
you
should
be
getting
at
and
that
network
service
is
some
combination
of
your.
The
bandwidth
of
the
network
is
connected
to
the
features
that
are
applied
to
that
port
in
terms
of
loss,
and
you
know
ACL
other
kinds
of
things.
All
of
that
is
sort
of
a
beginning
of
all.
Of
those
things
is
your
network
service,
and
this
is
one
of
the
big
realization
of
network
service
meshes.
Nobody
actually
wants
any
one
of
those
things
in
isolation.
E
A
F
A
The
last
item
is
which
are
so
next
next
week:
I
will
not
be
around
because
I'll
probably
be
on
an
airplane
or
on
my
way
to
an
airplane,
because
I
have
to
be
there
for
the
audio
DDF
as
well.
So
if,
if
anyone
so
so,
I
assume
that
people
still
want
to
run
the
meeting
next
week,
so
I'll
need
someone
to
to
step
up
and
run
the
meeting
for
next
week.