►
From YouTube: Network Service Mesh WG - 2019-03-07
Description
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
C
It
seems
like
there's
some
weirdness
from
like
what
the
demon
does,
because
it
seems
like
right
now.
The
data
plane
concept
is
very
kubernetes
centric
and
then
it
gets
super
super
weird
when
we
start
moving
into
like
some
of
Maram
keys
use,
cases
etc,
because,
if
I'm
living
in
a
vim
I'm
not
actually
talking
directly
to
the
data
plane.
At
this
point,
at
least
from
like
some
of
the
examples
in
some
of
the
use
case,
documents
that
I've
been
looking
at
it,
it
seems
like
in
this
instance
from
innocence
perspective.
A
Do
you
remember
the
deep
dive
talk
where
I
made
this
point
about
talking
about
the
abstract
architecture
and
then
the
architecture
specific
to
kubernetes,
a
big
part
of
why
I
did
is
because
there
are
certain
aspects
of
the
system
as
currently
written
in
code
that
are
pretty
specific
to
kubernetes.
So,
for
example,
as
you've
pointed
out,
the
the
data
plane
that
we
weren't
in
kubernetes
is
quite
dissimilar
from
the
data
plane
that
we
might
choose
to
run
in
some
other
environment
right
at
the
end
of
the
day.
A
A
Don't
know
how
many
folks
have
ever
had
the
privilege
of
actually
working
on
building
a
real
physical,
router
or
switch,
but
you
end
up
with
some
kind
of
a
control
module
and
it
has
what
it
believes
is
the
control
plane,
because
it's
on
top
and
it
goes
and
it
talks
to
something
below
it-
that
it
thinks
is
the
data
plane
there's
something
below
it
actually
is
the
control
plane
that
then
farms
it
out
to
a
bunch
of
line
cards
and
it
thinks
of
itself?
Is
the
control
plane
and
the
line
cards?
Is
the
data
plane?
A
So
my
experience
has
been
that
the
most
productive
definition
of
a
data
playing
is
one
of
two
things
right
used,
sadly
interchangeably,
but
the
first
definition
would
be
to
say
that
a
data
plane
is
that
thing
which
you
talk
to
when
you
would
like
the
handling
of
packets
to
happen
in
some
way
right.
So
it
may
be
that
internal
to
that
thing,
it's
talking
further
down
the
line,
as
in
the
example
that
I
gave,
but
effectively
from
your
point
of
view,
you
happen
to
sit
in
the
system.
A
That
thing
is
the
data
playing,
because
it's
the
thing
you
asked
to
do
things
that
involve
handling
packets,
that's
one
way
of
defining
data
point.
The
other
way
of
defining
data
playing,
which
is
often
less
useful
but
is
still
valid,
is
to
say
the
data
plane
is
the
thing
that
actually
touches
the
packets.
Now
it's
interesting
to
note
that
Neutron
is
absolutely
not
the
data
plane
in
the
second
definition.
In
fact,
very
things
are
actually
the
data
play
in
the
second
definition,
which
is
why
it's
scope
of
utility
is
less
I.
C
Just
okay,
so
let
me
everything
you
say
it
makes
perfect
sense
to
me
and
let
me
kind
of
then
express
my
concerns
with
like
this
distinction
between
these
two
types
of
concepts
is
in
the
kubernetes
world
and
NSE
seems
to
be
very
tightly
coupled
to
the
data
plane
concepts,
and
I
mean
I'm
we're
not
going
to
try
to
make
neutron
in
NSE.
Are
we
because
an
NSE
tends
to
be
directly
in
this
second
definition
of
a
data
play
and
where
there
is
flow
of
packets
going
in
and
out
of
an
entity?
C
So
in
this
case
it
would
be
a
VM
that
Neutron
is
provisioning
for
you,
but
in
the
kubernetes
space
like
there's,
also
like
a
there's
like
a
fracturing
of
how
we
treat
kubernetes
versus
everything
else
like
say,
I
want
to
go
into
the
PMF
space.
I
can
go
into
the
PMF
space
by
either
having
the
daemon
call
a
controller
such
as
odl
and
in
this
instance
from
NSF's
perspective.
C
So
we're
getting
into
like
this
weird
scenario
and
it's
making
me
a
little
bit
nervous
because
frederick
was
talking
about
his
interactions
at
Mobile,
World,
Congress,
there's
starting
to
be
these
third
parties
that
are
going
to
be
interested
in
building
these
NSCs
and
it
seems
like
there's
going
to
be
a
very
discontented
way
because
it
doesn't
seem
like
everything's
treated
quote-unquote
the
same,
which
is
kind
of
what
we're
trying
to
normalize
here
with
this
glossary
is
like
this
is
a
data
plane.
This
is
an
NSE.
C
This
is
an
NSC
and
the
way
that
it's
set
up
now,
depending
on
like
what
space
I
want
to
work
in,
it
seems
like
we're
running
the
risk
of
having
very
disjointed,
like
implementations
of
an
NSC,
a
data,
plane,
etc,
etc.
So
I'm
just
kind
of
curious
why
kubernetes
isn't
treated
the
same?
Where,
like
I
just
call
the
kubernetes
api
and
ask
for
stuff
other
than
the
fact
that
the
namespace
injection
is
weird
so.
B
There's
a
loved
one
back
there,
so
so
the
first
thing
is,
we
didn't
mention
on
Neutron
so
like
why
you
couldn't
run
not
be
an
NSE,
because
if
you
think
about
what
service
Neutron
provides,
it
provide
things
like
a
rich
domain
or
something
and
those
those
actually
folks
square
into
the
into
being
a
service.
In
the
definition
of
how
network
service
looks
at
that
looks
at
things,
I
didn't
say
that
it
wouldn't.
A
Network
service,
always
right
so
Neutron,
is
providing
a
network
service
full-stop
right,
that's
what
Neutron
does,
and
so
you
could
imagine
having
a
pod
running
in
kubernetes
or
even
some
other
thing
running
someplace
that
would
like
to
consume
the
network
service.
That
is
a
neutron
network
right,
so
you
want
to
specifically
run
Network
that
you
want
an
l2
l3
connection
to,
and
so
at
that
point
you
need
to
basically
look
at
okay.
How
do
I
call
it
connect
that
client
to
something
will
provide
me
with
that
network
service
right
now.
A
If
you,
if
you
look
at
the
neutron
case,
what
that's
going
to
inevitably
look
like
is
provisioning
on
a
V
switch
somewhere,
a
VX,
LAN
or
other
sort
of
port
that
plums
into
the
bridge
domain.
That
is
Neutron
right,
and
so,
if
you
really
would
have
put
a
fine
tack
on
it,
you
can
say
the
service
endpoint,
but
you
are
actually
connecting
the
workload
to
is
actually
a
particular
V
switch.
That
is
part
of
providing
that
Neutron
network.
A
That
you're,
providing
with
say
of
the
explained
connection,
is
the
point-to-point
connection
there
and
that's
how
you
would
problem.
You
would
treat
a
neutron
as
a
network
service
and
then,
when
you
go
track
down
the
concrete
thing
you're
talking
to
for
that,
it's
going
to
be
in
both
some
be
switch
running
on
some
particular
host
node.
A
Does
that
make
sense
yeah
now
one
of
the
things
that
may
be
useful
because
I
get
your
point
about
this.
This
sounds
different
in
lots
of
places
so
picture
this
conceptually
is
a
tree
right.
So
if
you
start
on
a
particular
service
mesh
as
an
abstract
thing,
because
then
you
can
start
at
the
abstract
and
drill
down
to
the
concrete
and
if,
instead
of
looking
side-by-side
to
yours,
you
look
up
to
your
parent
node
and
then
how
that
reflects
down
to
the
siblings.
It's
a
much
more
familiar
game.
Does
that
make
sense.
C
Yeah
no
I
mean
everything
you
say
makes
sense
to
me.
It's
just
like
what
we're
describing
we
do
it
completely
different
in
the
kubernetes
space
like,
instead
of
just
going
through
kubernetes
and
demanding
more
things
from
kubernetes
we're
kind
of
like
supplementing
at
some
of
its
functionality.
I
feel
like
well.
A
You
have
two
options,
basically,
that
you
could
play
in
OpenStack
right.
You
can
either
plug
into
a
neutron
network
as
a
network
service
or,
if
you're,
a
VM
running
in
OpenStack.
You
can,
as
that
VM
simply
act
as
both
the
network
service,
endpoint
and
the
network
service
manager
for
yourself
and
expose
the
remote
API
and
go
register
yourself
at
which
point
Neutron
is
a
happenstance
in
that
path
and
you've
completely
bypassed.
What's
going
on
in
the
networking
for
OpenStack.
C
C
C
You
know,
predefined
data
planes
already
in
place,
and
we
won't
even
call
it
a
data
plan,
we'll
just
say
the
method
that
I'm
in
a
forward
packets,
like
the
actual
flow
of
something
making
decisions
saying
you
know,
forwarded
out
of
this
physical
or
this
virtual
interface,
like
in
sm
with
a
lot
of
these
NS
sees
a
lot
of
times.
You
know
like
and
I.
Don't
think
that
VPP
is
the
default.
A
If
you're
running
a
reflector
effectively,
what
happens
is
you've
got
TCP
connections
coming
in
and
TCP
connections
going
out
right,
you're,
not
actually
programming,
a
data
plane,
you're,
just
doing
reflection
of
the
routes
that
you
receive
as
a
BGP
route.
Reflector,
that's
not
a
super
different,
quite
frankly
from
running
a
web
server.
I
know
that
on
the
telco
sign
they
like
to
talk
about
those
things
as
VN
s,
but
they're
really
from
at
cloud
native
point
of
view,
they're
just
another
application
that
talks
TCP.
A
A
That's
where
things
get
interesting
and
different
than
just
saying:
oh
yeah
just
take
FRR
or
quagga
and
stick
it
in
a
container
and
roll
it
out,
like
any
other
pod.
Just
like
a
web
server
or
a
reticence
or
anything
else,
it's
when
you
actually
need
to
start
hauling
packets
across
virtual
wires,
because
they're
actually
being
processed
by
things,
because
in
the
case
of
a
BGP
route
reflector,
it's
not
actually
dealing
with
l2
or
l3
payloads,
it's
talking
about
them,
but
it
never
deals
with
them
right.
A
A
Does
that
help
make
sense
at
all
or
yeah?
You
know
s.
It's
sort
of
bringing
the
data
player
along
I
mean
medicine
is
only
bringing
you
data
plane
to
the
places
where
the
existing
data
plane
is
is
deficient
for
the
purpose
right
and
please
note
deficient
for
the
purpose.
Is
this
purpose?
It's
not
all
purposes.
The
kubernetes
stuff
is
super
good
for
the
kind
of
application
things
that
people
normally
want
to
write
on
it.
A
If
you're
writing
an
application,
it's
exactly
what
you
want,
but
if
you're
writing
a
C
enough
as
many
people
who
discover
it,
it's
not
great.
Likewise,
if
you're
running
in
OpenStack
right
and
the
neutron,
networking
is
doing
the
things
you
want,
then
probably
you
just
want
to
be.
Allow
other
workloads
to
connect
to
a
neutron
network
and
that's
great,
but
if
Neutron
networks
has
nothing
to
do
with
what
you're
actually
trying
to
accomplish.
A
E
E
So
can
we
say
that
the
data
plane
is
there's
a
connection
and
we
can
like
maybe
define
the
connection,
as
you
know,
maybe
some
type
of
acknowledgment
and
then
some
type
of
sending
of
packets
and
then
there's
the
packet
treatment
portion
of
the
data
plane,
which
is
some
type
of
manipulation
and
changing
headers.
Whatever
seems
like,
there's
two
pieces
that
compose
isn't.
C
Because
in
the
Neutron
example,
it's
not
providing
you
like
it.
Well,
here's
the
thing
it
is
providing
an
SM,
a
connection
or
odl
talking
to
PMF,
that's
providing
a
connection,
but
it
isn't
actually
quote-unquote
in
the
literal
sense
providing
said
connection,
it
is
just
actuate
again
right.
Like
I,
don't
know
this
makinia
network
people's
heads
are
gonna
explode
like,
but.
F
Maybe
because
you're
the
explanation
of
the
neutron
works,
for
example,
right
now
in
any
kind
of
solutions
we
have
like
this.
We
have
the
kind
of
SDM
control
plane
that
comes
in
whether
it's
tungsten,
whether
it's
the
ODL
even
Neutron.
The
way
it
work
is
defining,
as
you
do
gr
e
to
V
Fano.
You
do
so
slowly
you're
bound
to
what
it
thinks
it
should
be
doing.
F
So
that
mean
that
if
I
want
to
run,
for
example,
tungsten
I
have
to
do
the
boxes
that
can
actually
talk
with
tungsten
to
make
it
do
the
overlay
correctly
to
the
node,
if
I
hadn't,
a
kind
of
a
service
plane
under
control
planar,
which
diagnostic
there
I
have.
This
I
need
to
connect
rather
a
to
compute
our
community's
node
B,
and
for
me,
I
decided
it's
gonna
use
a
I,
don't
just
feel
and
then
I
will
use
that
I
will
define
in
that
NSM
mesh.
F
The
the
proper
data
point
I
want
to
use
for
this
if
I'm
other
company,
but
this
I
decided
I'm
gonna
use
IPSec
tunnels,
then
I
can
actually
make
that
work.
I'm
not
bound
to
one
telling
me
out,
because
I
decided
religious
is
going
to
be
GRE
and
everybody
needs
to
be
Jerry,
which
is
right
now
the
problems
we
always
have.
F
You
want
to
build
something,
but
because
you,
you
kind
of
forced
design,
your
network,
based
on
what
the
solar,
the
software
vendor,
decided
to
be
doing
versus
going
the
other
way
around,
be
able
to
create
a
mesh
and
decide
underneath
what
kind
of
protocols
I
need
to
make
working
with.
Because
of
the
my
AM
network,
all
of
us
have
MPLS
networks,
which
is
the
first
burden
we
got.
Is
we
need
to
find
a
gateway
we're
going
to
centralize?
We
build
everything
I
flat
out
across
networks.
We
remove.
F
So
if
I'm
able
to
do
with
MSM
that
abstraction,
let's
say
I,
have
a
physical
box
I
decide
it's
going
to
be
this
I'm
going
to
use
that
kind
of
tunneling
or
that
kind
of
overlay
or
packet
measure
and
I
kept
encapsulation
to
go
to
wherever
I
need
to
be
I.
Think
that
that's?
Why
I
think
it's
a
valuable
point,
a
desirable
solution
or
vision,
maybe
I
rented
them
if
I
rent
it.
A
Which
is
effectively
you're
in
this
world
you're
held
prisoner
by
whatever
the
SDN
controller
thought
it
was
due
because
he
wants
to
own
the
world
and
you
want
a
world
look.
I've
got
these
different
things
and
I
want
to
collect
yoke
together
with
wires
and
I
will
decide
how
the
hell
the
world
work
so
I
don't
have
to
go.
Revamp
my
entire
damn
network
to
hack
around
the
limitations
that
I'm
getting
from
my
my
virtual
life,
virtualization
Sdn
provider,.
F
C
F
The
same
way
now
means
maybe
I
should
have
stayed
this
way
because,
and
the
cool
things
would
see
are
these
and
things
like
this
I
can
still
make
it
happen
and
make
it
look
like
an
umbrella
of
api's
which
are
standardized
but
I,
don't
have
to
recode
everything
to
make
it
work,
which
is
one
a
big
challenge.
We've
had
I
mean.
C
I
agree
partially,
but
like
ml,
two
has
two
different
types
of
drivers
right
and
it's
usually
a
specific
type
of
driver.
That's
saying
from
an
orchestration
standpoint:
I
am
outsourcing
all
of
this
from
Neutron
to
you
know,
tungsten
to
VTS,
to
ODL,
whatever
right
and
then
I'm
going
to
bring
in
my
own
agents,
etc.
But
I
mean
it
still
doesn't
change
the
fact
that
they're
specific,
like
device
type
ml
to
plugins
inside
of
Neutron,
that
like
enables
the
ability
to
do
VLANs
to
do
VX
plan
to
do
GRE.
A
A
But
again,
look
at
the
domain
of
control
now
you're,
turning
over
your
entire
Neutron
Network
and
everything
that
happens
in
your
Neutron
cluster
to
a
particular
opinion
about
the
world
we
do
here.
That's
quite
current
is
that
we
essentially
allow
you
to
connect
pieces
together,
so
there
can
be
multiple
opinions
about
the
world
going
on
simultaneously,
it's
not
our
problem.
Now,
after
the
question
of
whether
we
ever
bypassed
Neutron
and
OpenStack
I,
honestly,
you
know
that
that's
a
question.
A
If
someone
wants
to
go
to
the
investigation
for
how
that
might
be
doable
and
doing
that
work,
I,
don't
honestly
know
what
the
appetite
is
in
the
OpenStack
world
for
that
I
know
that
OpenStack
has
historically
taken
actions
to
prevent
anything
that
is
neutron
from
happening.
That
is
not
a
neutron
from
a
happening
with
networking.
You
know,
maybe
their
opinions
will
be
different
now
but
effectively
from
a
know,
from
a
broader
network
service.
Special
point
of
view
is
something
that
talks
the
end
network
service,
mesh,
ERP,
C
api's
and
we're
good
to
go.
A
So
if
somebody
were
to
go
and
do
something
like
this
for
Neutron,
where
it
basically
will
do
the
direct
wires
into
VMs
in
Neutron
like
that
would
be
something
we
would
be
okay
attaching
to,
because
it's
not
something
that
you
know
that
differs
from
the
way
the
world
looks
to
us.
The
little
world
still
looks
like
somebody
advertised
a
network
service
endpoint.
We
can
reach
out
to
someone
who
could
help
us
connect
to
it,
and
that's
someone
ensures
that
that
end
of
the
connection
happens.
A
B
When
one
major
thing
that
I
think
is
gonna
have
to
happen,
for
people
to
adopt
network
service,
mesh
and
I,
don't
think
it'll
be
it'll,
be
difficult,
but
it'll
be
a
change.
Rather.
Is
that
the
the
view
that
most
people
have
of
the
networking
world
is
usually
centered
around,
like
centered
around
bridge
domain
or
centered
around
a
PMF
or
some
bigger
thing?
That's
that's
occurring
and
what
we're
doing.
C
B
Gonna,
be
a
change
in
how
people
think
about
networking,
as
they
start
to
use
that
word,
service,
mesh
and
I
think
it's
something
that'll
come
it'll
come
naturally
like
the
people
here
in
this
conversation
are
already
going
through
that
transition
to
a
significant
degree,
and
so
so
I
think
that
guys
are
starting
to
expand
out
like
will
will
see
more.
That
happened,
but
I
think
part
of
what
we
need
to
do
is
work
out
like
how
do
we?
C
C
A
A
C
Here's
my
only
thing
on
that
I
know
that,
like
kubernetes,
doesn't
have
this
concept
of
l2,
but
it
doesn't
change
the
fact
that
there
is
a
virtual
switch
or
a
pass-through
technology
with
something
doing
like
something
is
looking
up.
Mac
addresses
and
making
decisions
on
what
courts
to
forward
things
out
of
like
just
because
kubernetes
wants
to
ignore
all
that
and
I'm
completely
supportive
of
the
idea
that
we
continue
to
like
abstract
that
from
them.
C
A
C
E
C
Going
to
do
any
l2
stuff
in
NSM,
because
I
have
this
giant
commercial
network
where
all
we
do
is
sell.
You
know
private
circuits
to
people
all
l2.
You
know
your
VPLS
or
evpn.
You
know
some
variant
of
MPLS
is
going
on.
There
then,
like
I
mean
maybe
we
just
say
kubernetes
doesn't
fit
in
this
space.
Then
I
guess.
A
A
D
If
we
get
into
the
service
protocol,
we
probably
need
to
get
a
mechanism
or
all
be
where,
and
we
can
say.
Ok
here
is
the
non
cloud
native.
All
here
is
what
I
would
probably
help
you
to
define
the
entities
until
you
migrate
to
that
of
cloud
native
and
probably
definitions
or
some
steps
or
exercise
that
would
essentially
help
embrace
the
non
cloud
native
all
right.
So.
A
D
Absolutely
right
it,
but
only
thing
is
what
we're
trying
to
do
is
ok.
So
let
me
tell
you
one
of
the
things
in
cloud
network.
You
can
in
fact
have
networks.
I
have
apps
or
have
any
of
it.
Without
the
data,
the
data
playing
playing
any
important
role,
it
can
just
be
an
IPC
or
an
RPC
between
endpoints
and
then
the
data
plane
programming
does
not
play
an
important
role
right.
It's
just
l3,
endpoints
or
everywhere,
and
then
do
it.
But
when
we
come
to
that
of
service
provider,
you
have
MPLS
endpoints.
D
You
have
those
endpoints
which
not
not
really,
but
still
you
need
to
address
it
so
so
I
mean
I
sincerely
feel
that
probably
we
would
need
to
put
in
that
effort
and
exercise
in
order
to
define
those
definitions
or
try
to
do
a
mapper
type
of
thing
so
that
what
we
can
do
is
we
can
essentially
go
on.
Tell
too
summers
or
tell
to
some
of
the
folks.
Hey
I,
like
I
know
that
you
are
using
Neutron
world,
but
in
Neutron
world
I
know
that
you
are
talking
about
bridge
domain.
A
Yeah
there
we
go,
so
you
can
absolutely
do
that.
I
think
that's
actually
exactly
the
right
first
step
because,
as
I
think
Jeffrey's
pointed
out,
there's
a
lot
of
legacy
in
the
world
and
it
will
be
a
lot
of
legacy
for
a
long
time
and
so
I
think
that
first
step
of
okay
great,
how
do
I
offer
my
Neutron
networks
as
network
services
to
the
broader
universe,
some
of
which
is
going
to
be
cloud
beta
native
in
kubernetes
I.
Think
that's
an
important
first
step.
It's
just
not
the
last
step.
D
A
A
Cluster
I
have
a
pod
that
I'm
probably
talking
to
something
that
looks
roughly
like
the
VPP,
did
agent
data
playing
right
now,
even
though
it
may
or
may
not
be
driven
by
PPP
agent
right
and
it
just
produces
cross
connects
if
I
am
over
on
the
OpenStack
side
and
I
am
exposing
Neutron
networks
as
a
network
service,
I'm,
probably
something
that
talks
the
NSM
remote
API
and
that
basically
picks
a
V
switch
instance
and
6e
VX
Leon.
In
pointed
that
instance,
and
configures
it.
A
Even
though
there's
no,
you
know
VM
on
the
other
end
and
passes
that
back
as
the
remote
into
the
connection.
To
ever
talk
to
me,
I
don't
have
to
have
a
single
unified
data
plate
for
the
whole
world.
This
is
I,
think
part
of
where
we're
actually
in
a
post,
Sdn
world
Sdn,
basically
presumed
it.
You
had
a
single
entity
to
control
all
things
and
we're
an
NSL
or
in
a
world
where
that
doesn't
have
to
be
true,
which
means
that
we
can
actually
collaborate
with
all
the
things
which
was
not
possible
in
the
Sdn.
A
What
it
comes
down
to
is
something
has
to
arrange
for
the
connection
to
whatever
is
providing
the
network
service,
and
it
may
be
different,
some
things
at
different
points
in
the
architecture
right,
so
it
may
be
data.
You
know
data
plane
on
it,
communities
node,
where
the
pot
is
running,
but
it
may
also
be
something
that
is
twiddling
switches
in
OpenStack
to
expose
what
OpenStack
pick
up
a
support.
D
A
A
I
tend
to
think
abstract
the
concrete
personally.
Well,
that's
not
true,
I
think
both
but
but
I
know
that
people
have
different
tastes.
There
are
lots
of
very
smart
people
who
think
from
the
concrete
up
to
the
abstract
and
I
know
lots
of
very
smart
people
who
think
from
the
abstract
out
of
the
concrete
and
I
know
a
few
very
smart
people
who
start
in
the
middle
and
think
out
where
those
guys
are
really
interesting
and
to
talk
to.
But
you
know,
I
I,.
C
Think
we
just
need
more
definitions
and
I
think
to
Watson's
point.
We
need
to
unpack
some
of
these
things
that
are
just
too
complicated
to
get
under
a
single,
bold
little
statement
there
right,
like
I,
mean
in
the
NSM
context.
A
data
plane
is
just
anything
that
you
can
request
to
Ford
packets,
whether
there's
a
layer
of
abstraction
between
you
and
that
forwarding,
plane
or
not
like
in
essence,
going
to
go
and
say.
Neutron.
C
Give
me
this
tuber
Nettie's
give
me
this
kubernetes,
you
don't
give
me
what
I
need
so
I'm
gonna
go
around
you
and
make
a
request
for
a
kernel
interface
on
my
own,
but
like
unpacking
those
things
and
then
talking
about,
like
you
know,
separating
in
making
it
granular
enough.
So
it's
obvious
that,
like
okay,
this
is
at
the
highest
level.
How
the
developer
is
going
to
look
at
this
and
then
here's
these
sub
considerations
for
the
developers
who
are
going
to
be
writing,
Network,
Service,
endpoints
and
writing
network
services
themselves,
because
I
mean
I
know.
C
We
keep
saying
we
want
to
like,
like
appeal
to
the
application
development
community,
but
Sarah
is
gonna,
write
her
app
and
then
request
a
network
service
by
name
right
like
that's
how
it
works.
Well,
who
wrote
the
network
service
that's
sitting
behind
that
namespace
like
I'm,
sorry
that
domain
name
like
it
wasn't
Sarah
more
than
likely
I
guarantee
you
because
she's
not
going
to
know
that
I
should
do
a
mimic
on.
A
Situations
because
the
roles
and
situations
are
going
to
vary
somewhat
depending
on
the
environment.
You're
in
you
really
are
trying
to
do
the
same
thing.
You
may
do
it
a
slightly
different
way.
So,
for
example,
if
you
ask
me
to
go
and
write
a
C
enough
to
do
something,
I
would
go
out
and
write
a
C
enough
that
consumes
mif
and
call
today
right
because
that's
super
easy
and
simple
and
it
actually
performs
super
well.
A
If
you
asked
me
to
go
and
write
U
of
V
enough
that
participant
network
service
mash
probably
write
that
what
I
would
do
is
I
would
have
the
remote
API
I
would
have
it
register
itself
and
I
would
have
it
terminated
some
couples,
because
the
things
that
make
it
super
nice
and
easy
to
write
under
my
F
based
CNF
simply
don't
exist
in
Neutron,
and
so
that's
probably
what
I
would
choose
to
do
in
that
circumstance.
In
both
cases
you
have
something
that
is
terminating.
A
That
is
advertising
that
it
provides
a
network
service
and
that
is
accepting
requests
for
connections
to
that
network
service
from
various
clients.
Just
in
the
latter
case,
the
mechanisms
you
would
use
would
be
some
variety
of
tunnel
types
as
opposed
to
you.
Nice
can
be
in
Mel
AF
and
putting
the
structure
take
care
of
the
cell
types
for
you.
C
C
B
It
may
not
be
an
optimal
negotiation,
but
it'll
be
as
optimal
as
those
two
and
I
can
communicate
with
each
other,
though
there's
also,
there
is
also
a
response
of
potential
responsibility
of
the
operator
who's,
providing
the
services
on
behalf
of
Sarah
to
make
sure
that
he
or
she
validates
and
insures
that
the
components
right
if
there
are
any
performance
requirements
or
so
on,
match
the
the
needs
of
the
user
as
well.
So
it
doesn't.
C
B
Doesn't
eliminates
or
obviate
the
need
for
or
those
choices
to
be
made,
but
it
does
make
it
easier
so
that
when
you
make
those
choices
that
they
that
those
items
can
get
wired
up
based
upon
the
ago,
she
ation
and
has
a
nice
prem
premise
as
well.
We're
supposed,
if
you
have
like
I,
have
to
memorize
connection
for
most
of
them.
But
would
you
run
out
of
capacity
on
your
local
system?
Then
you
don't
just
say:
okay,
we're
fail
the
connection
its.
F
D
F
Rather,
problems
before
no
oh
I
need
a
VPN
connection.
I
need
this.
I
need
that
kind
of
network
service.
They
normally
don't
know.
So
that's
a
second
I
think
it's
a
future
threat.
That
is
how
to
make
that
kind
of
intent
simpler
for
an
app
developer.
Who
wants
to
consume
network
services
to
make
it
simple
for
her
to
act
this
the
second
one
is,
you
won't
be
able
to
normal
and
you
won't
be
able
to
say
everybody
needs
to
another
same
thing,
because
vnf
is
not
pretty
around
my
decide.
F
F
If
you
need
an
attempt
to
be
able
to
adapt
to
it
and
that's
that's
the
same
burden,
we
value
Etienne
X
and
it's
we've
been
fighting
for
this
for
five
years
now,
so
I
don't
think
NSM
will
completely
solve
the
way
people
who
badly
or
goodly
you
know
good
way,
create
those
their
code.
I
think
that's
overall
us
having
that
thick
and
beating
them
up.
C
A
A
B
A
So
I
was
thinking
yes,
so
definitely
so
that
the
using
really
really
bad
choices
of
mechanisms
is
also
one
but
kernel
interfaces
are
so
slow
that
anybody
who's
writing
a
V
enough.
The
C
enough
that
uses
kernel
interfaces
isn't
even
going
to
get
to
the
point
of
evaluation
right
because
it's
gonna
be
how
much
traffic
in
your
CNF
pass
Oh
dot
less
than
one
percent
of
what
you
mean.
A
You
know
we
do
say.
This
is
how
you
would
have
people
request,
connections
to
your
CNF,
and
you
know,
and
we're
orienting
this
towards
wires
and
payloads,
right
and
I
think
that's
a
super
helpful
way
to
approach
the
problem,
because
it
limits
the
amount
of
stuff
at
the
edge
when
you
have
different
CNS
chained
together,
but
they
can
screw
up
as
long
as
I
can
basically
tell
you
as
a
CNF,
please
advertise
what
you're
doing
with
this
name
and
please
you
know
this
logical
next
step
that
you
want.
A
C
Okay,
so
what
other
like
sub
definitions
within
the
data
planet?
Maybe
we
like
tab
dozen
or
whatever,
because
if,
if
I'm
Sara
all
I
care
about,
is
that
top
definition,
this
logical
construct
that
provides
me
connections
right,
but
then
for
the
people
that
are
writing.
Nsc.
Is
writing
network
service
network
services
themselves,
etc?
We
need
to
like
make
sure
that
they
know
definitively
alike
when
you're.
C
Considering
your
forwarding
element,
you
have
these
considerations
and
maybe
the
forwarding
element
doesn't
even
exist
as
part
of
this
network
service,
because
you're
actually
going
to
call
something
else
that
does
it
for
you
you're
just
looking
for
forwarding
right
like
we
don't
need
to
define
it
right
this
second,
because
we're
pretty
close
to
the
top
of
the
hour,
but
we
need
to
give
people
as
little
rope
to
hang
themselves
as
possible
through
these
definitions.
So
when
they
come
in,
they
have
a
clear
and
concise
understanding
of
what
they
should
be
coding.
D
C
Right,
like
a
roadmap
of
how
you
take
your
legacy
stuff
into
the
cloud
native
world,
like
my
so
my
personal
goal
for
this
glossary
is
that
they
can
take
this
glossary
and
Nikolai's
SDK
and
start
working
on
things
right
like.
Hopefully
they
do
more
research
than
that,
but
at
a
bare
minimum
they
know
it
like
the
definition
of
an
individual
component
in
this
space
is,
and
then
they
can
use
Nikolai's
SDK
to
like
hack
around
with
some
stuff,
and
we
give
them
some
guardrails
via
set
definitions
to
keep
them
from
getting
themselves
into
trouble.
H
A
C
A
H
C
C
Don't
know
what
to
call
these
type
of
calls,
but
just
trying
to
like
puzzle
and
inform,
and
maybe
just
get
down
to
like
I
mean
I,
don't
feel
like
a
network
service
registry
is
gonna,
be
too
controversial.
Defining
so
try
to
knock
out
a
bunch
of
these
definitions
next
week
and
get
as
much
stuff
you
know
done
so
that
way,
em
you
know
Edie
and
Frederick
and
friends
can
start.
You
know,
refining
this
document
and
looking
to
push
it
out.
G
A
C
No
but
I
mean
I
feel
like
the
people
that
attend
this
call
are
getting
a
better
understanding
of
what's
actually
going
on
and
I
think
we're
getting
pretty
close
to
now,
where
we
can.
Just
like
you
know
the
network
service
manager
domain,
we
just
need
to
go
into
the
spec,
pull
out
the
information,
put
it
into
two
or
three
sentences
and
drop
it
anyway.
I
think
we're
getting
pretty
close
in
this
document.