►
From YouTube: Network Plumbing WG Meeting 2018-08-30
Description
Kubernetes Network Plumbing Working Group meeting for 2018-08-30
A
A
And
on
that
list,
just
an
update,
if
you
inspect
repository
I'm,
still
working
on
that
and
still
slowly
slowly
converting
things
to
markdown,
I
suppose
I
could
push
the
pdf
version
of
the
spec
earlier
rather
than
later
so,
possibly
that's
what
I
will
do
and
then
the
markdown
version
gets
added
after
that,
so
at
least
there's
something
up
beyond
that
Mike.
Do
you
want
to
talk
about
the
conformance
test
Flynn
before
we
dive
into
the
other
stuff
sure.
B
Yeah
I'm
sorry
didn't
get
to
it
sooner
very
just
recently,
but
I
think
I've
signed
up
to
start
drafting
that
you
did
so
I've
done
so
I,
don't
know
where
to
put
it
so
I
just
put
up
a
random
Google,
Doc
and
so
I
just
outlined
I.
Think
as
we
discussed
before.
I
think
the
place
to
start
is
with
a
binary
that
just
runs
a
test.
It'll
take
command-line
parameters,
including
it
Kubb
config
file,
name
so
that
it
knows
what
cluster
to
test
and
what
credentials
to
use,
and
it
kind
of
punts
to
external
all.
B
B
B
B
A
B
Right
I'll
go
back,
it
look
some
more
comprehensively
anyway,
so
it
took
initial
stab
at
what
would
be
the
likely
ones
to
be
generically
used
mean.
The
goal
here
is
to
come
up
with
a
list
that
you
could
expect
to
work
in
any
ordinary
kubernetes
cluster.
These
would
basically
have
to
add
connectivity
right.
I
mean
we're
not
removing
a
community
here
activity
here
all
right.
These
would
be
things
they
would
be
by
using
the
host
local
I
Pam.
That
is,
you
know
already
I.
B
A
It
probably
wouldn't,
but
then
you've
also
got
I,
expect
it
to
pick
that
up,
because
that
configuration
would
be
specific
to
each
specific
to
the
default
Network
plugin
and
might
not
even
be
used
in
the
certain
default
network.
Plugins
does
that
make
sense,
I
mean
basically
host
local
is
specific
and
it
is
possible
to
pick
up
the
kubernetes
allocated
nodes
subnet,
but
that
requires
that
host
local
be
the
first
or
the
default
plug-in
or
in
the
default
chain.
B
B
B
A
C
B
A
Assuming
that
the
tester
would,
when
it
creates
the
the
network
object
or
the
network
attachment
definition
that
it
would
just
set
a
subnet
in
there
and
then
all
pods
that
get
created
that
are
attached
to
that
network
attachment
or
attached
to
that
network
described
by
the
network,
attachment
definition
that
we
just
wrote
will
get
a
unique
IP
address
on
that
subnet.
The
problem
is,
can
they
communicate?
Can
we
actually
set
it.
B
A
Yeah,
this
is
true.
We
may
just
end
up
having
to
have
a
default
and
allow
that
to
be
overridden
in
some
config
file
or
whatever,
for
the
tester
yeah
I
mean
there's
gonna
have
to
be
a
list
of
requirements,
because
obviously
some
of
this
stuff
needs
to
cooperate
with
the
existing
network.
That
you're
pointing
the
tester
at-
and
you
know,
we'll
probably
just
need
to
create
some
configurations.
B
Right
I
guess
I
was
I
was
trying
to
think
about
just
how
automatic
that
could
be.
I
mean
one
technique
that
I
can
imagine
right.
The
tester
could
start
by
creating
a
daemon
set
or
even
a
single
pod.
We
could
require
that
the
tester
be
authorized
to
make
privileged
pods
and
that
can
actually
go
out
and
read
the
configuration.
B
B
A
B
A
I
guess,
but
if
two
points
there
first,
not
all
clusters
will
have
that
field
populated
because
not
all
of
them
will
actually
use
that
allocation
feature
of
cube.
Yes,
but
then
second,
if
they
have
that
field
allocated,
they
are
probably
already
using
that
field
with
their
default.
Network
plugins.
So
you
add.
D
B
A
A
B
A
B
E
B
C
B
B
A
Or
different
node,
so
my
suggestion
here
is:
let's
just
keep
it
simple
for
the
moment
and
then
get
something
that
actually
works
for
at
least
a
few
minimal
cases
and
then
expand
from
there.
Yes,
I
would
say:
let's
just
assume
for
now
that
we
can
only
assume-
or
let's
just
say
we
can
only
assume
single
node
connectivity
between
pods.
But
that
means
that
we
should
be
able
to
definitely
test
bridge
plus
host
local
with
a
subnet
that
we
define
and
can
be
overridden,
and
that
should
work.
A
B
A
B
Because
it
seems
like
you
know
that
that's
necessary
for
part
of
the
functionality,
yeah
I
I
mean
I
I,
don't
know
how
we
want
to
make
sure
that
no
I
mean
the
section.
2
says
that
network
interfaces
appear
and
I
don't
know
how
to
check
that
the
requested
ones
appeared
unless
I
know,
which
ones
are
requested.
Yep.
That's
true.
A
B
Okay,
I
mean
keeping
it
simple.
That's
the
simplest
thing
to
do
right.
If
you
want
to
get
more
sophisticated,
we
can
write
a
binary
to
running
the
pod
to
do
exactly
what
we
want
and
nothing
less
or
nothing
more
true,
but
keeping
it
simple
just
start
with
a
image.
That's
got
a
shell
in
it
and
exact
commands
into
the
show
I.
A
B
Let
me
be
clear:
we're
taking
four
things
here:
okay,
so
the
tester
you
know
think
drives.
The
test
is
just
a
binary:
it's
not
a
pod!
It's
not
okay,
fair
enough,
but
in
order
to
evaluate
some
of
the
stuff
that
happens,
we're
going
to
specify
some
pods
will
want
to
examine
the
inside
of
the
pod.
Yes
right,
so
to
do
that
I
was
amazing.
The
simplest
thing
to
do
is
to
run
a
pub
that
has
a
shell
in
it,
and
the
tester
will
exec
commands
into
that.
Shell.
A
D
A
B
A
B
C
A
few
general
comments,
I
guess
so
one
is
I,
think
it'd
be
great
to
add
another
section
on
test
setup.
So
you
know
what
what
we
expect
the
state
of
the
cluster
to
be
like
you
know
when
you
start
a
test,
you
know
what
what
do
you
expect
to
be
available?
I
guess
from
the
cluster.
That's
already
set
up
so
I.
B
Did
try
to
address
that?
You
know
it's
it's
it's
pretty
simple
in
generic
right.
We
expect
that
the
the
implementation
of
this
spec
is
in
place
in
the
cluster.
We
expect
that,
do
you
know
the
there's,
a
coop
config
that
can
be
given
to
the
tester
that
enables
it
to
manipulate
the
cluster.
They
don't
have
a
you
know,
user
in
it
that
his
has
sufficient
privileges
to
create
pause
and
create
their
right
definitions,
I
think.
C
C
Think
that's
right:
okay,
yeah
and
I
think
we
can
just
spell
it
I,
it's
not
a
lot.
It's
just
nicely!
Yeah,
okay
and
then
the
other
thing
is
I.
Think
would
be
great
if,
in
this
more
format,
I
think
we
should
get
the
test
cases
to
be.
You
know
you
know
in
a
number
and
then
in
a
procedural
kind
of
format,
so
that
we
say
test
case
one
step,
one
step,
two,
three,
four!
That's.
B
B
G
Okay,
oh
cool
thanks.
Mike
can
hear
me.
Okay,
so
I
hope
the
one
the
question
about
the
so
holiday,
so
there's
some
Siena
Prague
in
May
doesn't
may
not
support
these.
Some
specifications,
such
as
the
IP
address
or
MAC,
address,
I
think,
especially
in
case
of
the
Weber
war,
some
sick,
probably
in
case
at
that
time.
The
IP
should
be.
B
G
B
E
A
A
All
right
sounds
good.
I
will
mark
that
down.
Phung
in
Doug
will
help
make
out
all
right,
you're
committed.
B
A
What
are
people's
thoughts
on
are
everyone's
thoughts
on
exactly
what
we
should
be
discussing
for
the
next
three
months,
with
kind
of
a
target
of
like
a
D
1.5
spec,
just
to
set
the
ground
rules
here,
I
feel
like
they
should
be
fairly
simple
and
fairly
non-controversial
from
a
higher
level,
but
what
we
might
be
controversial
exec,
you
know
like
the
wording
or
the
keys
or
something
like
that.
I
mean
not
controversial,
hopefully,
but
things
to
decide
shouldn't
be
generally
large.
Things
I
had
gone
through
the
doc
and
identified
I.
A
B
One
I
may
be
relatively
simple,
I
think,
there's
an
obvious
idea,
I'm,
not
quite
sure.
What's
the
implementation
looks
like
with
the
latest
thinking
about
this
sort
of
stuff,
but
I
think
the
idea
is
that
we
should
allow
a
pod
to
use
to
reference
a
network
attachment
definition.
If
and
only
if
the
service
account
that
that
pod
is
running
with
is
authorized
to
read
that
network
attachment
definition.
A
Okay,
I
just
marked
down
that
I
thought.
Maybe
this
was
related
to
number
six
I.
Think
they're
sort
of
like
two
approaches
to
the
same
topic
and
I:
don't
see
her
all
on
the
call
right
now
and
he
had
added
the
emission
controller
like
I
thought.
Part
of
the
emission
controller
item
in
number
six
was
potentially
about
security.
I
could
be
wrong.
There.
H
A
B
Yeah
I
think
what
I
said
it
may
not
be
the
entirety
of
the
security
question.
I
think
it's
the
I
think
it's
the
one
that
makes
the
most
sense
to
standardize
on,
though
I
think
the
others
are
more
I
mean
like
the
question
of
Kings,
who
can
write
in
our
context
for
definition
that
reference
as
a
given
Network
that's
a
little
difficult
to
get
into,
because
the
these
networks
are
not
necessarily
kubernetes
objects
anyway,.
B
H
B
A
Network
attachment
definitions
right
and
I
had
thought
that
number
six
was
related,
because
one
of
the
ways
to
implement
those
kinds
of
checks
could
be
with
admission
control.
Well
with
that,
maybe,
though,
the
admission
control
in
the
pods
yeah
exactly
if
the
pot
is
not
able
to
access
or
not
allowed
to
access
a
given
network,
attachment
definition
object,
because
you
know
the
permissions
aren't
there
in
whatever
system
you
have,
or
maybe
it's
in
a
different
namespace,
that
the
user,
who
is
adding
the
pod,
should
not
have
access
to
that
kind
of
thing.
B
E
B
And
I
think
that's
yes,
so
I'm
not
quite
sure
what
is
the
question
there
I
mean
certainly
there's
a
validation.
Well,
let's
see
these
are
CRD,
so
we're
going
to
write.
Have
we
make
sure
that
you've
written
this.
B
A
B
I
think
that,
for
the
question
specifically
of
which
pods
can
reference,
which
attachment
definitions,
that
seems
to
me
like
something
that
we
ought
to
be
able
to
map
on
to
the
question
of,
can
the
pods
security
account
read
the
attachment
definition.
It
seems
to
be
it's
natural
to
have
that
alignment.
The
pod,
you
know
the
reference
that,
if
it's
security
account
can
read
it
I.
A
B
So
I
think
this
is
a
relatively
simple
thing.
It
may
require
some.
You
know
unusually
high
privileges
and
whatever
enforces
it,
but
apart
from
you
know
and
that'll
get
up
back
on
to
generic
questions
of
you
know
excessive
privilege,
which
we
already
have
it
as
a
you
know,
leading
topic
in
kubernetes
anyway.
So
right.
A
A
F
Yeah
totally
and
Suresh
feel
free
to
chime
in
too
on
this
one
saying
first
I'm
talking
about
this
before,
but
basically
the
gist
is
like
right
now
and
we
might
actually
remove
this
from
the
spec
I
feel
like
it.
I'd
alluded
to
it
at
once,
or
whatever
is
that
you
know
when
you're,
using
something
that
you
expect
to
create
an
interface
in
the
pod,
that
you
would
expect
to
have
a
unique
interface
for
each
unique
interface
name
for
each.
F
But
the
idea
behind
this
is
what,
if
you'd
like
a
way
that
you
can
predict
what
each
network
name
will
be,
so
that
maybe
you
know
you
like,
create
a
hash
of
name
or
something
like
that,
so
that
you
could
say:
okay,
I'm,
attaching
a
Mack
VLAN
here
and
I
want
to
know
that
that's
gonna
always
be
Mac
VLAN
at
the
three
3f,
or
something
like
that.
So
you
have
like
some
I,
don't
know
hex
hash
after
it.
So
you
could
predict
what
the
name
would
be.
That
was
kind
of
the
idea
behind
it.
F
A
B
A
B
B
Good
point
good
point
right,
so
it
doesn't
have
to
so.
But
since
this
is
the
spec
I
thought
we
should
test
it.
Yeah.
B
A
D
B
D
F
At
least
to
me,
the
one
thing
that
I
understood
would
be
a
little
bit
tricky
about.
This
is
what
you
know,
something
that
at
least
to
me,
if
I
feel,
like
we
considered
as
a
first
class
consideration
as
hey
you,
it's
a
pretty
likely
use
case
that
you're
gonna
attach
the
same
network
multiple
times
right,
so
I
feel
like
that.
A
F
A
C
A
C
A
C
I
would
expect,
at
this
point,
is
actually
I'm,
hoping
that
we
will
reach
the
conclusion
that
we
make
no
changes
to
the
spec
and
that
any
change
that
that
we
need
to
align
with
device
plug-in
is
purely
a
implementation
that
it
does
not
like.
The
the
thing
we
need
to
discuss
is
does
aligning
with
device
plug-in,
violates
or
require
any
additional
changes
to
the
spec
and
I'm
I'm
hoping
the
conclusion
is
going
to
be
no
okay.
A
C
And
I
think
they
should.
You
know
the
people
on
this
list
right
who
are
in
number
five
should
bring.
You
know
the
the
actual
implementation
that
they're
thinking
about
over
to
this
group
and
say
here
are
the
interactions
not
going
that's
going
to
happen
with
the
implementation?
Do
we
see
you
know
to
do
the
whole
group
see
any
problem
with
this,
and
and
do
we
all
think
there
is
no
impact?
And
hopefully
everybody
agree.
There
is
no
there's
no
impact.
So,
okay.
H
A
And
yeah
he's
not
around
to
talk
about
it
at
this
point,
I
guess
I
just
thought
that
it
would.
If
we
decided
to
make
those
things
optional,
it
wouldn't
be
a
huge
change
to
the
spec
I
think
that's
okay,
though
it
would
or
might
require
more
discussion.
I
think
we
can
put
this
item
for
this
meeting
and
maybe
come
back
in
and
see
if
Peter
can
talk
a
little
bit
more
about
it
because
I
don't
remember
the
whole
scope
of
what
he
was
looking
for
here.
Sure.
B
So
I
remember
some
of
it
and
I
think
the
idea
was
pretty
simple,
but
not
quite
trivial
right.
The
idea
was
to
say
this:
the
spec
really
does
cover
two
things:
it
discovers
how
one
defines
a
way
of
making
network
attachments
in
this
custom
resource,
and
it
defines
how
a
pod
can
request
the
use
of
that
and
the
and
receive
the
results
of
using
that,
and
one
could
imagine
factoring
this
spec
into
two,
and
so
the
part
that
discusses
the
pod
annotations
simply
says
these
annotations
reference
methods
of
making
network
attachments.
B
You
know
without
further
specification
in
this
spec
and
then
leave
it
to
the
other
spec
to
say
this
is
how
we
define
ways
of
making
network
attachments
and
he's
the
reef.
The
motivation
was
right:
he
had
other
ways
of
making
network
attachments.
He
wanted
to
be
able
to
use
the
pod
annotations
with
his
other
ways
of
making
that
specifying
ways
of
making
network
attachments,
I
believe
in
his
case
he
said
it
was
built
into
his
system,
but
I
think
the
generic
idea
was
whether
it's
built
in
or
defined,
usually
defined
in
some
other
way.
A
A
E
A
B
A
B
A
With
some
of
the
network,
readiness
issues
that
we
have,
and
especially
the
alternate
network
readiness
method
that
we
had
added
to
the
spec-
that's
not
as
easily
possible
to
figure
out
what
the
default
network
plug-in
actually
supports
and
thus
advertise
that
to
kubernetes.
So
I
think
we
need
a
little
bit
more
work
around
that.
But
then
also
we
need
to
figure
out
what,
if
anything,
the
sidecar
networks
should
get
passed.
B
A
At
this
point,
so
I
think,
there's
more
to
say
here,
but
I
don't
know
exactly
what
that
would
be
right
now
and
so
I
think
the
item
for
this
we
be
the
immediate
item
would
be
figure
out
what
holes
or
gaps
there
are
in
the
spec,
with
respect
to
capabilities
for
the
default
plug-in,
as
well
as
for
the
sidecars
and
then
come
back
to
the
group
with
some
suggestions
on
how
to
update
the
spec
okay.
Does
that
make
sense?
Yes,
Tomo
and
Doug
since
you're?
A
A
All
right
see
I'll
try
to
run
through
some
of
their
ones.
Pretty
quick
emission
controller
for
network
attachment
definition,
objects,
I
also
had
kind
of
short
term,
because
that
seems
like
a
fairly
contained
task.
I
mean
if,
if
it
is
in
fact
at
this
point
just
for
validating
that
the
config
item
is
valid
Jason
or
whatever,
then
that
seems
pretty
easy.
However,
I
don't
have
time
to
work
on
it
and
Carl's
not
in
this
meeting,
so
I'm
not
sure
if
he
has
time
to
work
on
it
so
I'm
thinking.
A
A
All
right
see:
Peters
II
had
another
one
for
network
attachment
selection,
annotation
with
static
IP.
Doesn't
this
is
number
nine
in
the
dock
by
the
way
doesn't
work
for
replica
sets
and
so
somehow
have
well-known
IP
his
arranges
for
pods
in
a
replica
set
I
think
he
had
brought
this
up
in
one
of
our
meetings
and
also
posted
about
or
posted
on
the
list.
A
Currently
with
the
spec,
we
really
only
support
a
single
static,
IP
or
specific
static
IP
s,
and
that
doesn't
really
work
for
replica
sets
because
right,
like
assets
cannot
matically
created,
and
so
they
would
sort
of
duplicate.
Some
of
that
information
and
possibly
use
the
same
IP
for
multiple
pods.
B
B
Just
like
a
good
argument.
I'll
just
say
you
know
in
in
Coober
days
in
general,
right
we're
not
promising
IPs
and
I.
Don't
know
I'm,
just
not
impressed
that
it's
something
we
should
take
up.
Okay,.
A
A
Okay
and
let's
see
here
the
last
one,
which
might
be
an
easy
spec
change
but
might
generate
more
discussion-
was
number
10,
which
I
also
added
and
I'm
willing
to
be
a
semi
advocate
for
this
one,
and
that
is
parallel.
Implementations
running
in
the
same
cluster
are
not
currently
possible.
Maybe
they
should
be
possible.
What
would
that
look
like?
A
B
Kind
of
but
kind
of
Nod
I
mean
it
seems
like
mixing
relationships,
oddly
I
guess
I'm,
just
not
quite
sure,
I
understand
I
mean
if
we
forget
about
the
multi
for
a
moment
and
just
think
about
the
case
of
the
in
the
one
attachment
right
the
cooperate
is
normally
gives
you
mm-hmm
I
mean
is.
Is
he
thinking
of
a
situation
where
the
wand
attachment
will
be
made
by
a
c
and
I
plug
in
for
some
pods
and
buy
something
based
on
device
manager
for
another?
I
think.
A
I
want
to
say
yes,
if
I
understand,
you
correctly,
I
believe
that
in
his
scenario,
the
default
cluster
wide
network
is
always
attached
by,
in
this
case
Malta's.
But
you
may
have
other
networks
like
sr
io
v
or
something
else
like
that
that
are
actually
handled
by
the
device.
Plugin
and
our
managed
resources,
which
might
be
you
know
like
there
might
only
be
eight
and
the
device.
Plugin
knows
these
things,
and
so
this
one
is
sort
of
in
some
way
as
a
bridge
between
resource
management,
device,
plugin
and
the
specification.
A
B
B
So,
in
fact,
I
mean
most
being
an
imposition
of
this.
It's
not
about
it's,
not
really
that
Malta
is
about
sea
and
I,
accept
that
the
scene
I
plugins
only
ones,
Maltese
knows
how
to
delegate
to
Rex
right.
But
if
we
had
some
more
general
framework,
some
more
general
thing
of
which
they
and
I
was
one
example,
and
something
else
was
something
else
all
right.
Then
we
would
expect
an
implementation
of
this
to
be
able
to
call
out
to
whatever
yes,
yeah
right
so.
B
Yes,
that,
if
both
esteems
to
remain
an
implementation
of
this,
it
would
have
to
unspecified
to
generalize
so
that
it
can
not
only
call
scene,
I
plugins,
but
also
call
the
other
methods.
The.
B
A
It
doesn't
no,
not
not
really,
I
what
you
have
to
add
another
multiplexer.
No,
it
wouldn't
necessarily
be
another
multiplexer.
It
would
just
okay,
let's
I
guess
in
the
zero
minutes
we
have
left
well,
okay,
we
have
zero
minutes
left.
Let
me
try
to
describe
more
what
I
think
he
means
here
and
maybe
get
him
to
actually
well.
Let's
just
do.
A
Of
time
well
come
back
to
it
want
this
one
for
now
yeah
alright.
So
we
have
one
two,
three
four
items
that
we
think
we
can
get
done
in
the
next
three
months
or
so
I
guess
on
the
next
meeting
we
will
look
into
the
longer
term
and
the
next
meeting.
We
will
also
take
a
look
at
some
of
these
items
that
we've
punted
and
try
to
get
their
advocates
to
attend,
so
they
can
talk
about
them
a
little
bit
more
I.