►
From YouTube: Network Plumbing WG Meeting 2018-07-19
Description
Kubernetes Network Plumbing Working Group meeting for July 19, 2018
A
B
A
A
It
does
not
affect
the
name
of
the
annotations,
and
that
was
intentional
to
preserve
some
kind
of
simplification
of
the
user
experience
for
pod
creators,
as
opposed
to
the
people
actually
defining
the
networks
in
the
API,
which
are
probably
more
cluster
admins.
So
again,
the
intent
was
to
keep
things
simple
for
the
people
who
are
actually
making
pods
and
perhaps
slightly
more
typing
for
cluster
administrators,
so
I
think
that's
the
biggest
one.
Obviously,
that
is
a
much
larger
API
break
for
the
spec.
A
So
if
you
have
implementations
that
relied
on
the
object
being
named
Network
problem
to
change
that
you
I
updated
all
of
the
CRD
definition
itself,
as
well
as
a
network
object
and
all
the
stuff
in
the
spectra
for
that
there's
a
whole
bunch
of
other
kind
of
small
ones.
If
anybody
is
interested
in
specific
items
in
that
list,
that's
in
the
agenda
doc
and
also
an
email
that
I
sent
to
cig
network
yesterday.
A
A
If
there
are
ones
just
jump
in
and
ask
about
those,
if
not
I
will
start
talking
about
section
six.
That
was
one
I
wanted
to
bring
up
I,
changed
or
added
language
to
say
that
the
cluster
default
cluster
wide
default
network
should
be
started.
First.
Does
anybody
think
that
that
is
controversial
or
too
restrictive?
A
It
seemed
like
that
was
sort
of
what
we
have
been
doing,
or
at
least
the
implementations
that
I've
been
looking
at
I'm
not
dead,
set
on
that
language,
but
it
just
seemed
like,
since
the
cluster
wide
network
was
always
supposed
to
be
attached
to
every
pod.
We
might
as
well
attach
it
first
and
if,
for
some
reason
that
cluster
wide
network
attachment
fails,
then
we
don't
bother
trying
any
of
the
other
attachments.
A
That's
kind
of
how
I
felt
and
I
felt,
like
maybe
that
should
just
be
solidified
in
the
spec
so
anyway,
again
a
we
could
theoretically
revisit
that
if
we
wanted
to.
If
anybody
wants
to
revisit
that,
please
do
so
on
the
sig
network
list,
because
we're
in
this
meeting
of
course,
because
we
ideally
will
not
be
significantly
changing
the
spec
in
the
next
two
weeks
before
we
formally
approve
it
as
a
group.
A
So
that
was
one.
The
other
thing
that
I
did
was
in
response
to
some
comments
in
the
Google
Doc
and
that
was
I
updated.
The
Stannis
excuse
me
status
and
attachment
selection
annotations
to
allow
custom
non-standard
keys.
All
keys
that
are
all
keys
that
are
not
reversed.
Dns
notation
specified
are
reserved
for
the
specification.
The
reason
that
this
was
updated
was
previously
added
so
that
all
keys
are
reserved
other
than
those
defined
in
the
spec
and
I
didn't
based
on
the
comments
from
the
I
think
it
was
11
2
or
whatever
that
person's
name.
A
However,
he
pronounced
that
person,
his
name
that
seemed
potentially
unnecessarily
restrictive,
so
I
figured
I'd
just
opened
that
door
a
little
bit
for
some
other
experimentation
so
that
we
can
kind
of
see
going
forward.
You
know
what
other
plugins
might
want
out
of
the
status
annotation
and
the
attachment
selection
Jason
list
format.
A
A
B
A
D
A
The
file
and
keys
are
defined
for
each
network
attachment
map
in
this
formats
networks
list.
Actually,
this
is
what
I
changed.
All
key
names
that
do
not
include
a
period
character
are
reserved
to
ensure
the
specification
may
be
extended
in
the
future.
Implementations
that
right
keys
other
than
those
defined
in
the
specification
must
use
reverse
domain
name,
notation
to
name
the
non-standard
keys.
Then
I
would
be
like
food
bar
dot,
key
name
mm-hmm.
C
A
A
A
Let's
see
I
added
section,
1
1
6,
stating
the
implementations
which
are
not
C&I
plugins
are
not
currently
covered
by
the
spec
explanation.
There
is
that
we
had
some
questions
last
time,
I
think
around
a
usage
of
this
specification
or
an
implementation
of
this
specification,
which
was
actually
used
in
parallel
with
another
implementation
and
I.
Think
that
was
basically
a
device
plug-in
implementation.
That
Peter
wanted
to
use
is
that
right,
Doug,
yeah.
A
B
A
C
C
A
And
I
mean
again,
it
doesn't
necessarily
well
yeah
I
mean
it
doesn't
prevent
experimentation
where
you
could
have
some
coordination
between
a
plug-in
implementing
this
specification
and
a
device
plug
in
implementing
the
specification
running
in
parallel
that
somehow
have
a
marker
between
them
for
one
to
ignore
the
network
and
the
other
to
ignore
the
network
or
the
other
network
so
anyway,
alright,
so
that
was
I,
guess
kind
of
a
somewhat
controversial
one.
I.
A
B
A
About
there,
but
anyway
yep,
so
they
can
define
the
default
network.
However,
they
wish
and
they
can
define,
readiness
for
that
default
network.
However,
they
wish
and
then
I
updated
304.
Oh
and
602
allowed
cluster
wide
network
to
be
implementation
defined,
which
allows
the
possibility
of
putting
the
cluster
wide
default
network
into
a
network.
Attachment
definition
object.
B
This
one
earlier
in
part
because
I
had
the
question
on
the
agenda
earlier,
so
I
appreciated
this
one,
quite
a
bit
actually
kind
of
both
of
these
two
last
ones,
because
there
was
my
question
about
default
network
and
this
looks
nice
and
clean
there,
because
the
it
was
kind
of
what
I
assumed
we
had
in
there.
What
sort
of
moves
up
to
the
implementation.
But
now
it's
squeaky
clean
that
way
and
then
yeah
I
had
been
working
on
implementing
the
you
know,
alternate
readiness
method
and
the
reference
implementation,
and
this
is
also
looking
good
and.
A
A
Yeah-
and
it
also
kind
of
goes
along
with
one
of
the
goals
that
I
think
Mike
had
comments
that
he
had
for
the
last
meeting,
which
was
to
try
to
make
things
a
little
bit
more
generic,
so
that
in
the
future
we
could
work
with
things
or
implementations
were
not
necessarily
CNI.
Plug-Ins
I
didn't
get
as
far
as
perhaps
Mike
wanted
to
go
with
that.
But
I
did
take
a
pass
through
and
try
to
reduce
some
of
the
dependence
on
CNI
and
process
type
in
vacations
for
implementations.
A
C
E
I
would
say
that
one
yeah,
so
one
question
I
was
about
to
ask-
is
about
the
section
1.16,
enabling
the
network
plugins
that
do
not
use
CNI.
This
one
I
want
to
ask:
is
that
the
one
you
want
to
capture
the
communication
between
ad
base
plug-in
and
this
ami,
or
you
want
to
see
that
this
scenario
is
not
using
see
any
at
all.
Yeah
I.
A
A
C
B
A
E
I
was
just
wondering
like
what
are
the
things
we
have
to
capture
for
the
v2
I
mean
that's
why
my
question
was
previously
just
to
clarify
that,
whether
it's
something
to
do
with
the
device
plug-in
so
I've
much
interested
on
setting
up
some
kind
of
suspect
between
the
device
plug
in
and
the
CNI
communication,
so
I
mean
the
last
week.
There
was
a
lot
of
email
chain
communication.
In
the
sake
about
this
communication
out.
E
Maybe
so
I'm
just
wondering
that
we
should
also
look
at
the
resource
management
working
group,
particularly
in
the
sig
and
the
resource
management,
to
see
what
other
things
going
on
there
and
pick
certain
standards
for
thier
following
and
try
to
incorporate
those
standards
in
our
version.
2
spec
implementation
itself,
because
because
we
don't
have
this
Baker
like
people
are
trying
to
implement
different
models.
Actually.
So,
if
we
capture
this
information
for
version
2,
it
will
be
easier
to
set
a
standard
in
overall
within
the
community.
E
So
this
is
how
we're
planning
to
do
the
communication
between
a
device
plug
in
and
the
cni,
because
if
you
look
at
most
of
the
models,
what
we
are
currently
is
working
is
on
the
it's
already
based
solution:
they're,
also
the
srvv
a
face
I
like
a
common
resource
for
us
another
one.
We
are
trying
to
look
it's
a
user
space
in
this
space,
this
we
host
user
or
the
member
for
like
a
common
resources.
They
are
like
socket
information
that
is
also
a
kind
of
resource.
E
E
E
A
E
A
E
Exactly
as
you
can
see
the
same
objective,
but
it's
implemented
in
for
your
seven
methods,
but
at
the
end
of
the
day
the
objective
of
everything
is
the
same.
Like
multi
networking
did
some
scheduling
thing
from
the
device
plugin.
So
if
you're
going
to
do
is
the
different.
But
if
you
have
a
spec
saying
this
is
how
we
want
to
do
it,
then
it
easy
for
the
people
to
go
and
to
do
their
implementation
there
only,
but
just
follow
the
spec.
E
B
I
mean
that
totally
makes
sense
to
me,
but
I
kind
of
the
big
takeaway
for
me
here
is
that
as
we
solidify
this
version
one,
we
should
probably
start
a
new
dock.
That
says
like
here's,
the
stuff
we
punted
from
the
one
and
here's
the
topics
that
were
interested
in
for
me
too,
and
then
try
to
prioritize
those
and
maybe
come
up
with,
like
a
punch
list
like
here's.
What's
in
scope
for
the
next
iteration,
maybe.
B
A
E
And
the
rest
two
items
is
the
same
thing,
so
there
are
some
kind
of
improvement
we
can
do
in
the
current
spec,
but
we
don't
want
to
put
it
right
now
in
the
spec,
because
we
just
need
to
finalize
this
one.
So
maybe
we
can
take
it
to
the
version
two
so
that
we,
whatever
improvement,
we
want
to
do
in
version
one.
We
can
do
it
in
version
two,
but
we
finalized
this
one
right
now
for
all
that's
true.
E
The
last
one
to
say
that
the
tick
plug-in
cases
it's
for
me
when
I
was
looking
at
this.
There
will
be
some
cases
that
we
are
using
meta
plugins
to
work
with
both
in
plugins
and
thick
plugins.
But
if
you
look
at
the
thick
plugins,
for
example,
in
courier
projects,
they
have
their
own
method
of
doing
multiple
networking.
So
in
this
case
there
will
be
a
confusion
that
which
network
object
belongs
to
which
plugins,
whether
it's
belongs
to
meta
plug-in
or
it's
belongs
to
thin,
thick
plugins
and
how
it
should
implement
it.
E
A
E
A
A
great
question
and
I
haven't
actually
thought
too
much
about
how
that
will
work
it,
at
least
at
a
minimum.
We
would
probably
take
the
current
doc
and
specification
in
Google,
Docs
and
then
I
would,
since
I
was
the
creator
of
that
document,
probably
removed
permissions
for
some
things,
I
think
right
now.
A
Anybody
who
has
the
link
can
actually
edit
the
doc
and
what
I
would
end
up
doing
is
probably
changing
that,
so
that
anybody
who
has
link
and
comment
and
only
a
couple
of
people
can
actually
change
the
doc
and
therefore
kind
of
like
set
it
in
stone
so
that
it
does
represent
the
view
on
spec
and
then
we'll
just
kind
of
continue
on
with
a
v2
spec,
but
yeah
I
will
investigate
seeing
if
we
can
kind
of
post
that
somewhere.
Maybe
that
even
means
like
a
github
repo
under
kubernetes
incubator,
or
something
that
converted.
B
E
E
B
A
A
This
specification
does
not
attempt
to
do
service
chaining.
At
this
point,
it's
been
discussed
in
a
couple
of
places.
I
believe
network
service
mesh
is
trying
to
do
something
similar
service
training
at
a
higher
level
and
I.
Think
that's
the
only
implementation
or
discussion
and
kind
of
spec
stuff
that
I'm
aware
of
is
anybody
else
aware
of
service
function,
chaining
type
stuff,
I
know
also
Tomo
had
a
CNI
plug-in
at
one
point.
That
also
did
some
service
function
chaining
in
a
rudimentary
way.
Nice
and.
C
D
E
A
E
E
D
A
You
know,
maybe
that's
something
we
can
talk
about
addressing
in
a
v2
spec,
maybe
that's
something
that
we
collaborate
with
other
groups.
You
know
like
network
service,
mesh
or
Resource
Management
to
work
on
I.
Think
that
definitely
is
something
a
lot
of
people
are
interested
in,
and
it's
under
discussion
in
a
couple
places
right
now,
and
we
should
continue
that
discussion
and
see
if
the
spec
could
have
anything
to
offer
there
for
v2
really.
B
A
All
right,
in
that
case,
we'll
end
it
please
everybody
do
a
review
of
the
doc
next
time.
Just
to
be
clear,
the
next
meeting
will
be
August
2nd
and
at
that
meeting
I
and
hopefully
everybody
else
would
like
to
make
any
absolutely
final
changes
that
we
need
to
make
and
officially
bless
the
specification
for
v1
and
continue
on
to
v2.