►
From YouTube: Network Service Mesh BoF Meeting - 2019-03-20
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
All
right,
good
morning,
everyone
just
a
quick
reminder:
these
meetings
are
recorded
and
they
eventually
make
their
way
onto
YouTube.
I've.
Put
the
meeting
minutes
link
into
the
chat,
if
you
could
add
your
name
to
the
attendees
list
and
we
can
go
ahead
and
get
started
so
real
quick.
Is
there
anything
documentation
related
that
anybody
would
like
to
add
to
today's
agenda?
A
A
A
No,
okay:
next
up
before
we
dive
into
the
glossary
and
into
the
definitions,
deck
I
wanted,
to
kind
of
start,
to
figure
out
what
our
next
steps
are.
I
think
we're
getting
pretty
close
to
the
glossary
being
finished
and
I
think
the
next
step
would
be
to
actually
write
like
documentation,
specific
to
components,
documentation
for
the
SDK
for
the
nsmb.
A
A
A
So
ed
is
sick
today
to
everyone.
I,
don't
know,
I
know
he's
not
gonna
be
here.
I
haven't
heard
from
Frederick,
but
so
I
think.
Adding
to
the
fact
is
a
very
good
idea,
like
there's
tons
of
misconceptions
like
VPP.
Is
the
data
plane
for
all
NSM
things
like
that,
so
capturing
that
knowledge,
when
we
just
lost
J
but
capturing
that
knowledge,
I
think
would
be
a
great
idea.
We
lost
Nicolai
to
his
people
having
trouble
with
zoom
this
morning,
seen
like
3
or
4
people
pop
off
and
jump
back
on.
A
C
A
A
All
right,
then,
I
guess
we'll
jump
into
the
glossary.
F
A
So
let
me
show
you
I
kind
of
touched
on
it
a
little
bit,
but
obviously
the
glossary
isn't
going
to
be
just
something
that
people
pick
up
and
consume
easily.
So
I
have
been
working
on
this
and
for
the
things
that
I
feel
like
are
a
little
bit
tougher
to
understand.
I've
been
trying
to
sticking
with,
like
the
graphics
that,
like
theme
and
Frederick,
nickel
I
have
used
in
the
past,
I've
tried
to
kind
of
keep
it
consistent,
but
I'm
trying
to
like
build
this
out
in
parallel
and
Watson.
A
I
could
definitely
use
your
artistic
eye
for
some
of
this
type
of
stuff,
but
trying
to
figure
out
ways
to
you
know
for
those
of
us
who
can't
just
like
read
a
sentence
and
instantly
understand
what
something
is
provide.
Visuals
and
I
think
we
could
probably
even
build
out
these
definitions
and
more
detail
as
we
go
along,
but
I
agree:
100%
Taylor
that
I'm
just
handing
off
the
glossary.
It's
going
to
be
good,
for
you
know
the
development
crowd
and
just
sticking
it
next
to
the
code.
A
So
they
can
quickly
reference
a
term,
but
for
people
who
just
want
to,
like
general
knowledge
and
consumption,
on
like
what
are
the
components
in
this
and
that
I
don't
think
the
glossary
is
gonna,
be
too
appealing
to
them
so
trying
to
build
this
in
parallel.
A
You
know
trying
to
keep
it
consistent
with
the
class
rates.
This
link
right
here
for
those
that
want
to
look
at
it.
It
should
be
fully
shared,
so
people
can
edit
it
as
they
need
to
but
yeah,
just
as
we
kind
of
refine
things,
and
we
start
working
on
the
use
case,
documents
with
the
other
group,
I'd
like
to
kind
of
incorporate
some
of
their
stuff
in
here,
to
give
examples,
etc.
Just
so,
people
really
have
like
a
warm
and
fuzzy
on
what
something
means
when
they
dive
into
it.
A
E
Think,
starting
from
the
idea
of
NSM
developer
our
perspective
and
then
working
our
way
out
to
other
audiences,
which
seems
where
you're
going
it
sounds
good
and
that,
as
far
as
consumption,
this
type
of
format
is
I
think
a
good
place
to
start
and
then,
if
someone's
more
interested
there
may
be,
you
know
more
reference
documents
or
stuff
that
they
can
dig
in.
But
we
need
the
broader
audience
and
I
think.
Definitely
the
first
place
what
you
have
every
size,
cool.
A
And
you
know
I
try
to
put
this
into
some
kind
of
order,
but
this
is
literally
just
a
collection
of
thoughts
and
pictures
right
now,
so
we
can
mix
and
match
this
I
feel
like
the
toughest
concepts,
so
far
have
been
around
forwarding
elements:
data
planes
like
what
a
connection
is
and
stuff,
and
so
I
specifically
want
to
dive
into
that
today,
because
I
think
we're
actually
very
very
close
to
having
the
core
NSM
terms
for
the
glossary
done.
I
put
this
here.
These
aren't
specific
to
innocence.
A
A
We
finally
kind
of
got
our
heads
around
that,
but
the
the
data
plane
has
just
really
kind
of
straw,
I'd,
say
flummoxed
all
of
us,
because
we
all
have
a
slightly
different
idea
in
our
mind,
so
I've
kind
of
taken
the
approach
that
well,
you
know
we
were
working
on
last
week,
where
we
break
it
up
into
sub
components
and
then
saying
that
the
data
plane
is
something
that
gives
us
all
of
these
things.
A
And
so
we
talked
about
calling
this
guy
a
channel,
a
micro
wire,
like
all
these
different
things,
I
found
in
one
of
the
decks
so
there's.
Actually
this
thing
in
the
code
called
a
local
mechanism
and
mechanism
was
one
of
the
words
I
can
even
change
this
to
be
local
mechanism.
If
we
want
just
so,
it
stays
exactly
consistent
with
the
code
or
if
we
want
to
change
this
and
I
know.
A
You
had
mentioned
this
last
week,
Taylor
that
we're
kind
of
at
a
an
interesting
spot
right
now,
where
we
could
come
up
with
human,
readable
documentation
and
then
try
to
you
know
course
the
code
to
match
the
terminology
that
makes
sense
a
human
being
so
I'm
open
on
this.
But
basically,
we've
got
these.
What
are
called
at
the
moment,
cool
mechanisms
that
provides
these
shim
interfaces
to
the
data
plane
right
like
it
makes
them
mif
attachment.
It
makes
a
kernel
interface.
A
You
know
if
we're
going
with
Ed's
concept
of
it's
whatever
provides
these
things,
regardless
of
whether
or
not
it's
an
SDN
controller
such
as
ODL
or
Neutron,
or
it's
an
actual
physical
appliance
that
I'm
putting
an
agent
on,
and
you
know,
making
direct
requests
to
it
doesn't
matter
as
far
as
NSM
is
concerned,
because
we're
just
making
a
request
for
functionality
right.
So
yesterday's
call
obviously
there's
a
lot
of
strong
feelings
on
this
exact
topic.
I
know
prim
ROM
Qian.
They
all
really
really
really
want
to
solve
this
piece
right
here.
A
It
sounds
like
we
are
finally
coming
to
the
decision
that
that's
not
going
to
be
solely
an
SMS
responsibility
that
maybe
we
build
a
library
in
parallel
that
NSM
can
consume
to
take
advantage
of
these.
You
know
data
plane,
accelerators,
but
I'm
just
curious.
Now,
I'll
shut
up
for
a
second,
these
three
definitions
right
here:
do
they
make
sense
to
people
and
does
the
goofy
little
picture
at
the
bottom
kind
of
at
least
give
some
type
of
visualization
of
what
they're
trying
to
imply
I.
A
Been
putting
in
because
I'm
kind
of
open,
we
can
hand
this
off
to
you.
Nico,
Frederick
and
Edie
today
is
like
our
first
rough
draft
of
the
grout
glossary,
but
so
I
I
try
to
make
sure
that
the
deck
the
deck
is
eventually
gonna
expand
down
because
I
want
it
to
be
Taylor's,
point
way
more
human,
readable,
like
with
examples
and
stuff,
but
at
the
moment
definition
wise.
It's
for
one
match.
A
So
originally
we
just
had
this
I
pulled
this
out
of
some
of
the
other
human
tation
and
slide
decks
where
it
actually
calls
out
the
local
mechanism
in
the
code,
etc,
etc,
and
so
I
kind
of
tried
to
massage
this
into
our
glossary
definition.
That
also
fits
in
with
what
we're
calling
you
know
how
it
feeds
into
the
whole
concept
of
a
wire
and
a
connection.
A
G
A
A
Okay,
so
we
have
a
wire,
we
beat
that
one
to
death
pretty
hard.
Last
week
we
have
a
connection
so
now
the
data
plane.
Let
me
do
it
with
the
picture:
I
try
to
give
two
examples
of
a
data
plane
that
stretches
two
nodes
versus
a
single
node
right,
but
that
basically
the
data
plane
is
the
sum
of
all
of
this
right.
It's
it's
the
mechanisms,
it's
the
wires
and
it's
the
engine
in
connection.
A
It's
how
I
get
my
packets
from
point
A
to
point
B
and
I'm
careful,
because
we're
kind
of
going
with
we're
going
after
the
developers.
First
I
try
not
to
get
too
into
the
weeds
in
this
core
definition
of
implying
that
there's
some
kind
of
forwarding
plane
or
this,
and
that
because,
in
the
Neutron
instance
right,
if
we
go
into
the
OpenStack
world,
Neutron
will
will
give
me
mechanisms
via
V
host
user
or
whatever
it'll
set
up
the
wires
via
Neutron
networks
and
then
at
the
end.
A
F
A
Yeah,
you
know
so
I
mean
most
of
the
early
development.
Work
has
been
done
with
PvP,
but
this
comes
to
Jay's
point
that
he
made
at
the
very
beginning
that
one
of
our
next
documents
needs
to
be
working
on.
The
fact
right,
like
the
frequently
asked
questions,
because
there
is
because
a
lot
of
Frederick's
early
demos
around
like
setting
up
a
bridge
domain
and
stuff,
they
used
VPP
as
a
means
of
achieving
that.
A
But
in
reality-
and
this
is
where
that
big
discussion
yesterday
around
this
right
here
and
really
there
being
a
library
that
we
can
use
and
call
so
that
innocent
becomes
our
common
API.
You
know
interface,
but
if
I
want
an
SRO,
V
interface
as
opposed
to
VPP
right,
like
I,
want
to
inject
a
virtual
four
door
directly
into
a
pod
namespace,
there's
a
lot
of
contention
on
whether
that's
just
baked
directly
into
the
source
of
in
SM
itself,
or
if
that's
an
external
entity
that
NSM
just
leverages
in
them.
A
It
seems
like
yesterday's
consensus
and
I
know
that
I'm,
Ian
and
Ed
have
talked
about
this
on
the
inside
of
Cisco,
because
there's
some
people
inside
of
Cisco
who've
been
working
on.
This
is
the
local
mechanism.
Part
will
kind
of
be
like
a
standalone
library
for
in
a
seven
to
call
when
it
wants
a
virtual
four
door
when
it
wants
the
kernel
interface.
But
VPP
is
just
the
first.
You
know
set
of
tools
that
they
try
to
tackle
around
like
the
VPP
agent
and
stuff,
but
in
a
Sims
data.
A
Yeah
and
so
like
I
said,
we
definitely
need
that.
You
know
QA,
because
I
had
the
exact
same
assumption
gunner
when
I,
you
know,
first
encountered
an
SM
and
I've
seen
at
least
in
the
Google
Groups
three
other
people
asked
that
exact
same
question.
So
that's
definitely
something
we'll
want
to
clarify
is.
F
G
Currently
the
data
plane
is,
we
said
so
many
times
is
VPP.
Oh,
there
is
a
PR
which
we
are
working
on
our
side
to
decouple
the
common
called
the
common
data
plane
code
from
the
actual
implementation,
and
the
target
is
to
provide
means,
and
eventually
we
are
going
to
try
something
with
obvious
or
little
bridges.
A
It's
supposed
to
stretch
multiple
cloud
environments,
but
since
all
of
the
early
development
workers
in
kubernetes
and
kubernetes
has
some
quirks
on
how
it
interacts
with
DP
dks
ROV
other
data
plane
enhancement,
you
know
tools
and
functionality,
we're
having
to
go
to
Intel
in
the
kubernetes
community
upstream
to
ask
for
some
fixes
to
take
advantage
of
some
of
these
tools.
It
just
so
happens
that
VPP
already
works
very
very
nicely
in
a
kubernetes
world,
and
that's
why
you
know
it's
kind
of
the
50-meter
target
to
get
an
easy
win.
If
you
will.
G
Sounds
sounds
right
to
me:
I
mean
they
hit.
It
reflects
whatever
you
you
just
I
mean
we
were
just
discussing.
I,
don't
find
any.
C
G
C
C
A
In
in
this
slide
deck,
we
absolutely
can
put
that
in
Watson.
So,
let's
add
some
of
these
suggestions,
the
glossary.
We
just
want
it
to
be
the
bare-bones
definition,
but
this
this
document
is
for
exactly
capturing
those
points
and
I
like
I
said:
I
could
really
use
everyone
else's
help
in
all
the
other
definitions
of
us
fleshing
this
stuff
out.
A
Because
I
think,
if
they
can
see
that
there's
multiple
data
plane
options
that
you
just
described
right
here,
Watson
that
will
also
kind
of
help
with
like
the
early
questions,
I
hadn't,
the
one
that
gunner
just
raised.
Well,
you
know
it's
like
okay.
This
is
more
than
just
a
control
plane
for
VPP
and
kubernetes
right
right.
C
And
for
me,
when
people
are
talking
about,
why
do
we
even
need
a
service
mesh
from
the
dev
side
from
people
who
aren't
really
on
the
networking
side
at
all
the
whole,
adding
in
things
like
VPP
and
OBS
and
saying
their
way
to
do
packet,
forwarding
that
are
like
faster
than
Lennox
bridges
or
faster
than
what
just
comes
almost
Linux
or
whatever?
That
part
is
important.
You
know
it's
always
lost
on
the
programmer
side.
So
that's
why
I
think
it's
important
to
put
it
I.
A
C
E
A
Know
Taylor
called
it
out
is
that's
why
we
need,
and
it
doesn't
have
to
be
this
slide
deck,
but
there
needs
to
be
something
like
that.
We
just
have
like
a
document
that
we
can
just
hand
someone
and
if
they
were
just
like
what
is
an
SM
and
I,
don't
want
to
go
through
the
whole
journey
and
sales
pitch
of
you
know:
here's
Sarah
yada
yada
I,
just
what
are
the
components
and
what
does
this
thing
do
like?
A
We
need
that
document
for
certain
and
then
the
glossary,
I'm
kind
of
thinking
and
like
I
said
this
is
just
my
random
word.
Vomit
here
is.
The
glossary
is
just
some
bare-bones
definition
that
we
stick
and
get
right
next
to
the
code
so
like
when
it
developers
sees
local
mechanism
pop
up
inside
the
code
right
and
he's
like.
Oh,
you
know,
I'm
gonna
do
mimic.
What
is
this
local
mechanism
thing
is
like
okay,
it's
this
thing
right
here
right
and
it's
gonna
eventually
help
you
build
these
two
things.
B
Just
could
you
please
turn
to
the
to
the
last
patient
yeah?
Yes,
actually,
according
to
the
picture,
it
seems
that
my
intuition
is
that
the
data
plane
does
not
include
interface
internals,
because
because
you
label
that,
because
these
two
are
separate
part
separated
by
colors,
so
I
don't
know
whether
that,
because,
because
you
put
pictures
on
the
side,
you
definitely
you
will
want
to
indicate
they
which
actually,
which
components
does
there's
a
data,
bring
contain.
So
I'm,
not
sure
whether
a
data
plane
will
include
these
two
things
so
easily.
G
A
A
A
G
A
A
None
we
don't
need
a
sneaky
Network
person,
definition
anymore,
okay,
so
service
mesh.
This
is
pretty
industry
standard,
I,
just
pirated
this,
so
there's
not
a
whole
lot
of
controversy.
Here
same
thing:
I
ripped
this
off
of
this
DEA's
website
network
service,
mesh,
carry
and
pay
loads
which
are
l2
and
l3
network
service.
A
A
A
G
G
A
Yeah
I,
don't
know
see
like
I
said
that
I'd
put
this
in
here
and
I
think
he
was
just
giving
examples
so
I'm
with
examples
being
in
a
couple
of
these.
Just
because
you
know
to
Watson's
point
I
think
the
moment
you
read
this
line
right
here.
If
you
didn't
get
what
the
data
plane
was
from
up
here,
this
will
make
sense
to
you
right.
A
A
G
A
A
G
So
back
to
the
to
the
point
of
proxies
and
told
bosses,
I
just
just
want
to
do
this
a
little
bit,
because
we
we
get
a
lot
of
questions
about
this
and
I.
Guess
that
purpose
that
it's
actually
put
it
here
is
to
just
explicitly
say
that
a
lot
balancers
are
not
part
of
the
data
plane
right
I
mean
it
is
something
that
you
have
to
implement
on
top
of
NSM.
D
D
F
A
A
C
D
C
I,
don't
I
forget
where
okay
there,
it
is
right.
So
this
thing
is
what
makes
things
reachable
right.
A
A
C
A
Kind
of
like
workload
here
so
I
added
workload
and
edited
reachable
resource
I
I
think
these
are
meant
to
be
just
more
once
again
kind
of
going
with
the
come
up
with
the
components
of
some
of
these
more
you
know,
all-encompassing
definitions,
so
I
mean
an
endpoint
is,
could
be
both
a
workload
and
a
reachable
resource
right
and
endpoints
are
unique
in
the
fact
that
it's
going
to
accept
connections.
But
if
it's
midway
in
a
chain,
then
it
might
also
request
connections
right.
C
A
What
if
I
say
you
know
instead
of
saying
a
container
pod
or
physical
fort
or
since
we
call
out
a
workload
up
here
saying
these
things?
What
if
I
say
a
network
service
endpoint
is
a
a
workload
providing
a
network,
reachable
resource
to
clients
and
just
use
their
own
definitions
like
have
them
build
upon
each
other?
Would
that
be
better
Watson?
A
H
We
need
to
be
a
bit
careful
on
this
as
well,
so
a
network
service
endpoint
does
not
have
to
be,
does
not
actually
have
two
homes
either
resource
it
has
to
just
provide.
Can
connectivity
parameters
to
allow
you
to
connect
to
it?
So
sort
of
words
is
like
suppose
you
have
some
hardware
device
and
you
second
an
endpoint,
and
that
was
the
ride
was
ran
in
a
pause.
A
C
G
A
G
A
Well,
that's
what
it
I
think!
That's
what
the
original
line
saying
it
offered
a
network
service.
So
maybe
we
just
need
to
say
is
it
come
help?
Is
a
component
of
the
network
service?
I,
don't
know?
What's
we
don't
have
that
now
and
that's
kind
of
what
the
last
one
was
saying,
but
I
think
it
might
have
been
a
little
overzealous
and
what
it
was
promising.
So.
A
All
right
guess
we'll
circle
back
around
on
these
guys.
So
since
we
now
have
Frederick
prim
Lonnie
on
here,
we
kind
of
covered
these,
give
you
guys
a
real
quick.
What
I've
highlighted
with
the
cursor
here,
we
kind
of
talked
these
out
I.
Think
we
kind
of
have
a
semi,
warm
and
fuzzy
on
these
concepts
right
here.
I'll
give
you
guys
just
a
couple
seconds
to
review
them.
H
A
H
Learn
it
say
that
again,
you're
chopping
up,
so
it
doesn't
always
get
injected
into
the
interfaces.
You
don't
always
get
injected
into
the
positive
work
namespace.
So
like
is
if
it's
shared
memory,
for
example,
then
it's
actually
attached
to
the
file
system
and
has
nothing
with
the
the
network.
Eventually
yeah.
H
H
A
A
And
so
the
other
thing
too,
we
discuss
so
you
know
yesterday,
I
think
most
everybody
was
on
yesterday's
call,
but
this
one
is
kind
of
like
the
hot-button
topic
for
myself,
prim,
Vani
and
cetera,
and
this
is
likely
what's
gonna,
have
the
parallel
library
built
around
it
right.
Is
all
these
local
mechanisms
for
innocent
to
call
so
that
way,
I
can
get
a
virtual
for
der
injected
into
a
pod
when
I
need
it
right,
but
we're
defining
what
these
are,
and
there
is
in
the
code.
A
You
know
this
construct
right
here
that
you
know
says
like
I
want
this
MMF
interface
with
VPP
I'm
under
the
impression
for
right
now
we're
saying
that
like
when
we
look
at
the
actual
core
forwarding
elements
and
how
we
are
going
to
do
this
in
the
kubernetes
space
that
this
is
going
to
be
a
standalone
library.
Are
we
still
kind
of
thinking
that.
H
A
We
said
yesterday
look
much
like
DP
DK
obnoxious.
Service
providers
like
myself,
can
decide
how
much
mutability
and
pain
we
want
to
bring
upon
ourselves
and
those
that
don't
want
all
that
nonsense,
don't
have
to
import
the
libraries
right
and
also
just
so,
you
guys
are
tracking,
because
we
cover
this
at
the
beginning,
so
I'm
trying
to
build
like
a
human
consumable
like
document
that
we
can
give
to
people
in
addition
to
what
we're
doing,
and
so
these
definitions
and
actually
let
me
make
sure
that
this
stays
congruent.
A
So,
as
you
can
see
here,
I'm
trying
to
build
out
pictures
trying
to
use
the
same
graphics
that
ed
and
Frederick
have
been
using
and
some
of
their
other
decks
like
mechanism
right,
sro,
V,
MSC,
host
user,
etc.
When
you
stitch
these
things
together,
you
get
a
wire
and
that
ends
in
data
flow.
That's
your
connection
right
so
trying
to
build
some
visuals
around
this
same
thing
like
the
data
planes.
A
But
trying
to
separate
some
stuff
out,
like
we've,
got
those
definitions
on
this
previous
slide.
On
number,
seven,
let's
say:
here's
a
wire,
here's,
a
mechanism,
here's
a
connection,
yadda
yadda
and
from
innocence
perspective,
the
data
plane
is
anything
that
gives
it
those
things
so,
whether
it's
directly
going
into
you
know
affording
element
and
programming
rules
like
you
know,
going
into
OVS
and
making
table
entries
or
I
just
go
to
Neutron
and
I'll
rely
on
Neutron
to
do
that.
J
A
A
A
A
J
G
Guess
you
have
some
layer
to
means
layer,
three
means
and
some
to
link
means
I,
don't
know
I
mean
it
depends
on
what
the
audio
I
guess,
what
audio
components
you
you
know
do
deployment
and
what
you
can,
what
I
mean
I
can
easily
imagine
that
you
have
a
special
audio
configuration
that
actually
can
just
terminate
at
an
O,
and
then
you
directly
route
it
to
the
to
the
router
in
the
in
the
neutron
opus
truck
didn't
appointment.
There.
J
So
one
thing
is
I
mean
I,
don't
want
to
probably
digress
a
lot,
but
just
half
a
second
explaining
what
I'm
doing
great
so
pretty
much.
What
we
have
done
is.
We
have
figured
out
a
call
from
OD
l
to
MSM,
which
was
straight
forward
button.
We
just
use
the
gr,
PC
client
and
the
new
things.
No
Deal
is
just
a
client
right,
but
the
reverse
direction
went
in
as
some
wants
to
use
open
daylight.
It
would
essentially
be
open.
J
F
J
G
But
we
have
fixed
in
our
definition
for
data
plane
that
we
have
fixed.
Is
it
a
physical
I
mean
anything
good,
physique
or
not
I
think
can
actually
in
our
examples
we
have
specific
puto,
gon
Neutron,
just
to
kind
of
explains
the
fact
that
that
you
can
have
an
external
and
not
say
data
playing
providers
which
can
actually
connect
and
form
the
connection,
because
I
think
that
the
critical
I
Jeff
can
you
can
you
show
the
previous
slide
because
it
really
gives
so.
Essentially,
the
connection
is,
as
you
see
end
to
end
so
I
mean.
A
H
A
Reworded
that,
because
I
think
proxy
is
probably
the
right
word,
this
may
you
achieve
by
provisioning
mechanisms
and
configuring
or
affording
elements
directly
being
a
physical
or
virtual
right.
It
could
be
a
nexus
switch
or
could
be
VPP
or
were
by
making
requests
to
an
intermediate
control
plane,
acting
as
a
proxy
capable
providing
the
four
components
needed
to
realize
the
network
service
mm-hmm
right.
A
A
You
yep,
okay,
we've
got
just
a
couple
minutes
left
so
I
put
a
note
here.
These
ones
I
think
we're
90%
of
the
way
there,
but
we
do
need
to
kind
of
incorporate
how
they
fit
into
the
network
service
themselves.
Now
that
we
remove
those
other
things,
this
part
we
just
did
so
I
think
next,
Tuesday
I'm,
hoping
you
know
we
get
through
these
last
few
things.
These
are
pretty
vanilla
on
this.
One
I
think
we
kind
of
finalized
last
week
together.
A
So
these
guys
I
pulled
them
right
out
of
the
specs,
we'll
just
talk
them
over
real
quick
they're,
not
nearly
as
sexy
or
controversial
as
things
like
data
planes
and
mechanisms
and
wires.
But
I
think
after
that
we
can
go
ahead
and
push
our
first
draft
of
the
glossary
to
get
and
start
letting
the
rest
of
the
community
beat
us
up
and
tell
us
that
our
grammar
sucks
and
that
we
don't
know
what
we're
doing.