►
From YouTube: Network Plumbing WG Meeting 2018-08-16
Description
Kubernetes Network Plumbing Working Group meeting for 2018-08-16
A
B
So
yeah
I
can't
deny
the
fact
that
the
first
thing
that
I
would
test
is
multix
cuz,
I'm
involved
with
creating
it.
So
you
know
I'd
want
to
I'd
want
to
test
that,
but
by
the
same
token
I
would
be
you
know,
there's
a
reference
implementation
moving
along
with
courier
and
then,
if
Peter,
you
know,
starts
to
further
implement
the
specification
in
knitter.
You
know,
I
would
love
to
test
it
against
that.
You
know.
I
in
this
case
I
think
it's
a
more
the
merrier
kind
of
thing.
So
you.
C
B
C
C
C
C
C
A
C
Now,
that's
what
surprised
me?
Okay,
I
thought
the
whole
point
of
a
conformance
test
was
you
can
apply
it
to
different
implementation?
Yes,
yep
right,
so
the
conformist
heads
is
not
going
to
be
built
to
Malta.
It's
not
gonna,
be
built
to
Korea
right.
It's
gonna
be
a
thing
that
we
can
apply
to
multiple
site
apply
to
courier
deployment.
Yeah.
B
C
A
C
I
guess
the
other
question.
Maybe
maybe
this
is
what
you're
trying
to
get
a
good
question.
I
have,
is
it's
there's
really
a
product
versus
service,
but
the
question:
are
we
simply
defining
a
conformist
test
as
a
piece
of
code
that
somebody
could
run?
Are
we
defining
it
as
a
CI
pipeline
that
we
stand
up
somewhere?
That
could
continually
test
something
well.
B
That's
certainly
better
than
I
was
I
was
assuming
it
would
be,
an
application
that
somebody
could
run
and
they
could
put
it
in
their
their
own
CI
pipeline.
But
if
we
could
get
it
to
the
point
where
you
know
we
could
toasted
somewhere
and
offered
that
service
to
whatever
implementation
and
I
I
think
that's
even
better.
But
that
would.
A
A
C
I'd
be
willing
to
put
some
time
into
writing
it.
I'm
not
really
familiar
with
writing
things
in
a
way
I've
written
tests
that
are
that
I
run
in
my
own
totally
unique
way.
I
expect
there
may
be
some
expectations
here:
I'm
not
quite
sure
what
they
are
or
how
to
meet
them.
I
mean
do
I
just
get
to
make
up.
You
know
any
kind
of
code
I
want.
C
I
guess
what
I
would
need
is
all
it
really
means
is
I
need
some
code
that
is
given
a
coop
config
file,
and
it's
going
in
my
code,
like
my
conformance
test,
is
going
to
create
some
pods
and
go
create
some
of
these
objects.
These
network
attachment
description
objects
and
then
create
some
pods
that
reference
them
and
I
guess
using
image
in
those
pods
that
I
can
actually
exercise
to
do
that.
A
Yeah
and
it
could
even
be
based
off
like
hack,
local
up
cluster,
or
something
like
that.
You
know
such
that
hack,
local,
up
cluster
is
part
of
the
script
that
runs
and
kicks
off
the
test,
and
then
you
would
give
cube
the
C&I
plugin
of
the
thing
you're
going
to
test,
and
then
you
know
which
would
be
supplied
by
the
user,
because
that's
their
implementation,
and
then
you
know
your
the
script
or
whatever
framework
it
doesn't
have
to
be
a
script
IVIS
and
whatever
framework
is
running.
A
C
A
A
C
C
A
Sorry
you're
right,
I
think
in
that
case
you
know,
then
not
that
we
have
to
design
it
here,
but
the
inputs
basically
be
an
API
server
and
some
directories
potentially
in
which
we
could
drop
the
config
files
that
we
might
write
and
then
that
test
you
just
run
the
test
and
the
test
goes
off.
Add
some
objects
to
the
in
existing
kubernetes
server
or
kubernetes
cluster.
A
Given
that
API
server
it
might
write
some
config
files
to
the
given
directory
and
then
it
would
test
wait
the
appropriate
amount
of
time
after
creating
a
pod
make
sure
the
pot
is
up
and
then
after
the
pod
was
up.
You
know
kind
of
pole
for
the
status
annotation,
for
example,
and
then
you
know,
5
minutes
have
passed
and
there's
no
status.
Annotation
failed.
Maybe
something
like
that
would
be
the
simplest
case
right.
A
C
A
C
A
Have
a
service
account
or
something
like
that,
or
these
permission
right
it
could
be
just
something
that
runs
into
clusters,
so
you
wouldn't
need
a
coop
config
parameter.
No,
it
wouldn't
you're
right
because
it
could
pull
the
API
server
address
out
of
the
per
container
environment
right
it
would.
It
would
need
a
service
account
with
sufficient
authorization
yep.
It
would
probably
also
need
a
V
container
would
need
different
mappings
for
host
directories,
depending
on
where
the
implementation
would
look
for
config
files
if
it
used
those
well.
C
A
B
A
A
A
We
can
impose
some
restrictions
on
the
configuration
of
kubernetes,
for
example,
you
know
there's
like
a
CNI
bender
option
for
cubelet
and
we
could
potentially
require
that
that
option
is
pointed
towards
a
given
directory,
or
at
least
that
we
know
that
of
that
directory
and
that
we
could
install
given
CNI
plugins
in
there
I
think
we
could
do
some
gymnastics
with
the
plugins
such
that.
If
we
have
access
to
that
directory
from
the
container
you
know
we
can
to
make
sure
that
we
don't
conflict
with
existing
plugins.
A
We
could
copy
those
into
the
host
directory,
that's
map
from
the
container,
with
a
different
name,
and
then
you
know
use
that
and
the
config,
so
I,
better
I
feel
like
in
my
mind,
there's
ways
around
some
of
these
problems.
But
we
should
just
start
simple,
and
you
know-
maybe
just
you
know
even
just
make
sure
the
default
network
comes
up
and
adds
the
status
annotation,
and
then
we
can
kind
of
grow
organically
from
there.
C
D
Lot
Mike
before
we
talk
about
the
mechanics
of
that
this
test
itself,
I
would
think
you
want
to
come
up
with
a
actual
test
plan
and
description
of
what
are
the
tests
you
actually
want
to
test
for
right.
So
I
think
that
that's
the
the
first
effort
that
would
imagine
so
yeah
to
get
idea
to
and
I
would
think
you
can
probably
win
when
even
include
that
as
part
of
the
spec
or
a
separate
document.
C
B
Totally
understand
I
also
well.
I'll
probably
have
some
more
bandwidth
here
as
we
move
into
the
fall,
but
yeah
I'd
be
more
than
happy
to
pitch
in
with
you
there.
But
if
you
have
some,
you
know
opinions
on
how
you
like
to
get
it
started.
If
that
won't
make
it
more
appealing
to
work
on
I'm,
just
happy
to
jump
in
and
write
some
of
the
tests
or
prove
the
framework
with
you,
etc.
A
A
contribute
there
are
some
cube
directory
or
cube
projects
we
could
use.
I
was
gonna,
put
the
speck
in
the
kubernetes
community
repo,
but
I.
Don't
think
that's
necessarily
the
right
place
for
a
test
suite
like
this
another
alternative
is.
We
could
still
create
a
project
in
CNI,
a
completely
separate
repo
in
CNI
for
the
test
suite
and
the
self
yeah.
A
E
B
E
Yeah
so
I
see
Doug's
best,
put
some
good
documentation
on
the
number
of
futures
we
can
take
up
for
this
break
to
discussion,
so
I
just
want
to
get
the
community
opinion
that
what
are
the
futures
you
guys
looking
into
actually
to
be
there
actually.
So
if
we
go
into
the
documentation,
we
can't
see
that.
A
E
Own
15
items
so,
but
as
possible,
we
can't
take
at
least
6
items
or
something
to
be
put
in
the
spec
or
I
think
the
most
of
them
are
kind
of
implementation
or
the
spec
details.
That's
my
second
topic:
whether
we
want
to
separate
the
spec
and
the
implementation
separately
and
to
be
able
to
specify
that
what
is
the
spec
scope
and
what
is
the
implementation
scope
or
on
the
version
2.
A
Fairly,
not
contentious
items
and
cleanups
that
you
know
hopefully
wouldn't
take
a
lot,
but
then
we
also
have
some
much
larger
items
that
would
require
some
more
research
POCs.
That
kind
of
thing,
and
my
personal
feeling
is
that
it
would
be
good
to
get
those
cleanups
in,
but
at
the
same
time
we
kind
of
want
a
balanced
turn
in
the
spec
and
not
continuously
releasing
versions
of
the
spec
that
make
changes
against
getting
features
out
or
getting
things
added
to
the
spec.
A
A
Any
thoughts
from
the
group
historical
perspective.
We
only
started
this
effort
about
six
to
eight
months
ago,
and
so
you
know
looking
at
where
we've
come
in
six
to
eight
months.
It
seems
like
it's
taken
longer
than
that,
but
it
really
hasn't
been
a
lot
of
time
I.
You
know
when
you
put
it
in
perspective
yeah,
so.
D
A
And
I'm
thinking
about
three
months
now,
I
feel
like
maybe
that's
a
little
too
quick.
All
right,
as
you
know,
we're
talking
about.
If
we
release
a
new
version,
the
speck,
how
many
people
are
going
to
be
able
to
update
to
that
speck?
You
know
in
three
months
and
roll
that
out.
We
don't
want
this
to
necessarily-
or
at
least
I,
don't
want
this
to
necessarily
be
a
treadmill
where
the
speck
is
constantly
changing.
A
I
want,
you
know
a
pretty
good
spectra
convey
to,
but
that
said
you
know,
since
this
is
our
first
version,
are
there
things
that
our
pain
points
right
now
that
we
could
fix
in
the
speck
or
small
things
we
could
add
to
the
speck
and
maybe
roll
out,
like
you
know,
a
1.5
or
call
it
v2.
You
know
I,
don't
think
version
numbers
mean
everything
in
the
world,
but
that
you
can
face
some
information,
so
you
kind
of
have
to
manage
some
of
the
expectations
around
them.
A
If
that
makes
sense,
I
guess
I
have
made
my
mind
up
I'm
kind
of
looking
for
guidance
from
the
group
here
around
what
everybody
feels,
especially
people
who
have
worked
on
implementations
of
this.
You
know
what
you
think
the
cadence
should
be,
how
often
we
should
add,
updates
to
the
spec
you
know
or
if
there
are
specific
things
that
are
really
blocking
you
from
implementing
parts
of
this
you
know.
How
can
we
fix
that
and
how
quickly
should
we
do
that?
I.
B
Certainly
am
open
to
hearing
other
people's
needs,
but
I
will
say
you
know
it
does
take
a
fair
amount
of
work
to
implement
this
stuff,
and
you
know
there's
part
of
me:
that's
like
excited
to
work
on
some
of
this
upcoming
stuff,
but
then
there's
another
part
of
me
that
says:
hey
you
know.
Development
is
only
a
small
percentage
of
what
you
do.
The
other
half
is
stabilizing
and
maintaining
you
know
what
you
do
or
better
than
half
I
should
say
so.
B
B
E
B
A
A
We
should
probably
go
through
this
list
and
identify
the
things
that
we
think
are
kind
of
small
cleanups
and
you
know
maybe
target
those
talked
about
one
or
two
of
those
every
meeting
and
see
if
we
can
make
some
progress
on
the
small
things,
but
then
also
you
know,
leave
perhaps
the
bulk
of
the
time
for
the
meetings
to
discuss
issues.
People
have
when
they're
doing
POCs
or
other
experimentation
with
the
larger
things
here.
F
See
go
ahead,
commit
you
to
the
version
policy
like
kinetic.
Dad
I
mean
a
kubernetes
api
that,
for
example,
we
will
use
the
we
to
our
way
and
we
to
repeat
her
something
like
that
and
the
are
far
the
alpha
version
would
be
optional
for
the
implementation
and
the
beta
would
be
mandatory
or
something
like
that.
B
Yeah
I
think
that
Peters
idea
there
is
pretty
reasonable
to
say
like
hey.
This
is
the
stuff
that
you
know
you
is
a
must
and
the
other
stuff
is
in
a
but
yeah
I
think
that
probably
yeah
the
next
thing
for
the
group
to
do
is
yeah.
Let's
see
what
the
low-hanging
through
is
here,
and
definitely
people
should
speak
up
if
there's
stuff
that
they're
like
it
was
just
too
late
to
get
that
and
we
won,
and
you
know
we
can
kind
of
check
out
the
scope
on
it
and
yeah.
D
It
almost
feels
like
if
we're
gonna,
do
that
fine
grades.
It's
way
too,
you
know
I,
don't
know
that
we
have
that
many
things
to
to
really
indicate
for
each
one.
This
is
alpha
or
beta
feature.
You
know,
I
almost
feel,
like
you
know
your
original
suggestion.
That
was
just
fine.
If
we
let's
say
if
we
just
release,
let's
say
three
months:
we're
gonna
release
a
dot
release
and
then,
in
six
month
we're
gonna
release
the
next
merchant
major
version.
D
C
I
think
we're
speculating
too
much
here.
Let's
go
ahead
and
try
doing
some
of
the
work
and
see
what
Kings
we
think
we
can
actually
sustain
I'm
concerned
it's.
You
know
it
would
be
easy
to
just
pick
off
small
things
and
I've
shed
them
for
a
long
time.
I
think
we
should
probably
ask
ourselves
to
spend
part
of
our
time
on
the
small
things
as
part
of
our
eternity
big
things.
Otherwise
they
think
something
would
happen.
A
D
B
D
A
Think,
given
that
people
have
been
adding
like
six
more
new
items
to
the
considerations
for
v2,
we
should
probably
take
the
next
two
weeks
and
you
know
just
make
sure
that
you
know
every
unicorn
anybody
wants
is
on
the
list.
Okay,
obviously
within
reason,
and
then
at
the
next
meeting,
actually
sit
down
and
try
to
put
things
into
buckets
of
you
know.
We
think
this
is
a
short-term
feature.
We
think
this
is
a
long-term
feature
for
some
of
the
long-term
features.
A
We
should
probably
have
some
discussions
about
whether
anybody's
done
experiments
or
Pio
sees
with
it
to
get
some
real-world
experience
because
I
feel,
like
you
know,
we
probably
shouldn't
be
adding
things
to
the
spec,
unless
somebody
has
a
really
good
idea
of
the
issues
around
it
or
what's
required
with
it,
and
then
you
know,
hopefully,
at
that
point
in
two
weeks,
we'll
have
a
good
idea
of
you
know
what
the
next
three
months
of
work
is.
If
that
makes
sense,
nice.
D
E
What
I
was
thinking
that
we
should
prioritize?
What
are
the
items?
I
mean
the
next
action
item
for
two
weeks
right,
so
we
have
currently
I
put
a
lot
of
items
actually
there
right
now.
So
whatever
comes
coming
to
my
mind,
so
it's
currently
like
20
items
is
there,
so
we
can't
do
all
these
items
or
I
just
want
to
have
some
discussion
on
certain
items.
It's
not
that
it
should
be
part
of
the
spec,
but
just
a
discussion
or
the
idea
how
it
could
be
in
kubernetes.
E
So
I
just
want
to
know
what
are
the
action
item
we
have
to
take
for
next
two
weeks
in
order
to
take
up
this
document,
whatever
that
gets
put
into
a
list
of
something
like
prioritizing
these
things,
how
we
can
do
it?
Actually,
that's
what
I
want
to
ask
you
guys
you
want
to
put
some
kind
of
holding
mechanism,
or
this.
A
Looking
at
the
list,
I
mean
just
picking
two
off
of
it.
You
know
I
feel
like
bandwidth
capability.
Flags,
for
example,
is
something
that's
going
to
be
a
fairly
uncontroversial.
You
know
fairly
short
term
thing,
you
know,
whereas
what
about
network
service
mesh
is
definitely
going
to
be
a
much
longer
topic,
I've
I
feel
like
it
would
be
good.
You
have
a
section
or
given
that
we
were
going
to
probably
want
discussion
for
these.
Maybe
we
should
either
use
Google
Doc
comments
or
we
can
add
sub
points
below
them,
and
people
can
tag.
A
A
A
A
A
You
don't
necessarily
need
to
put
it
down,
but
if
you
are
willing
to
work
on
these
items
or
if
you
have
experiments
or
POCs
that
implement
them,
or
even
better,
maybe
presentations
that
describe
work
that
you've
done
in
this
kind
of
thing
in
the
past,
please
link
those
from
those
items
in
the
v2
document
so
that
you
know
everybody
can
follow
those
links
and
ideally,
we'll
have
a
better
idea
of
what
these
items
are.
So
when
we
discuss
them
on
the
30th.
A
Then
Koral
you
had
asked
about
a
place
for
the
view
on
spec.
I
was
still
going
to
put
it
in
the
Cuban
community
repo
for
now
under
sig
Network,
and
do
that
PR.
But
I
was
in
the
middle
of
cleaning
up
the
conversion
to
markdown.
We
had
talked
about
trying
to
have
a
markdown
copy
online,
so
be
easier
to
view
and
easier
to
look
stuff
up.
A
I
used
a
markdown
converter
that
converted
other
things
and
also
kind
of
collapsed.
Some
of
the
pre
formatted
things
that
I
now
have
to
clean
up
so
I
was
working
through
that
about
half
done.
I
will
try
that
link
that
you
suggested
and
see
if
that
does
a
better
job
than
the
one
I
used,
but
I'm
expecting
that
in
the
next
week
or
so,
I
will
have
that
PR
up
and.
E
E
The
last
one
is
about
dick
plugins
us
and
the
demons
it's
about
the
version
two
specs,
so
you
guys
have
any
idea,
because
so
for
all
the
implementation,
we
had
done
it
on
the
CNA
right.
So
we
thought
it's
a.
It
should
be
a
CNI,
but
in
most
of
the
gates
it
can
be
a
nikon
vs
enemy
and
it
can
be
a
diamond
setter.
It
could
be
a
process
which
can
do
this
work
actually
right.
So
what
is
your
idea
on
that?
What
are.
A
E
Not
delegate
to
what
the,
for
example,
if
you
take
both
career
and
mulches
right
so
multi
to
do
the
multi
networking
certain
way
create
as
it
insert
away,
but
if
I
want
to
use
both
there
was
them
in
OpenStack
ironic
right.
So
what
will
be
the
model
there?
So
it's
the
same
spec,
so
multis
implementation
will
think
its
own
network
and
Korea
will
think.
Okay,
that's
my
network,
so
you
could
differentiate.
We
had
two
different
reference:
implementation
working,
try
to
work
together
right,
so
it's
very
difficult
at
the
time.
Yeah.
A
A
A
It
my
fault,
but
yeah
good
point.
You
know
I,
think
you're,
the
second
or
third
person
who's
brought
that
up.
So
it's
something
that
we
should
definitely
discuss
and
potentially
address
for
v2
or
potentially
even
sooner
than
that.
But
it's
probably
a
lot
of
discussion
around
that.
So,
let's
just
see
where
we
land,
okay.