►
From YouTube: Kubernetes SIG Network Weekly Meeting for 20200422
Description
Kubernetes SIG Network Weekly Meeting for 20200422
A
B
C
So
the
yeah
I,
let
me
talk
about
the
network
status
or
the
apado
notation.
So
currently
the
amount
is
or
the
india
mode
net
spec.
Our
specification
contains
the
ADIZ
for
the
notation,
which
indicates
the
interface
information
is
network
status
and
then,
at
that
time
we
have
the
name,
interface,
IPs
and
Mac
and
Dennis.
At
that
time
they
I'm
wondering
that
the
at
that
time
we
could
not
identify
the
which
next
network
network
attachment
definition
is
used
because
there
is
no
namespace.
C
So
the
arrests
imagine
that
the
Mac
one
network
attachment
definition
to
to
object
in
the
kubernetes
I
mean
that
the
Weinstein
namespace
one
and
then
the
namespace
to
at
that
time,
the
when
they
are
Potter.
When
the
user
is
looking
the
network
status
and
then
they
mock
me
run
one
then
either
is
pretty
hard
to
identify
which
one
is
used
so
I'm
just
thinking
about.
Maybe
we
may
need
two
additional.
C
A
A
C
A
A
A
A
D
A
B
At
least
on
the
multi
side,
we
have
a
good
way
to
kind
of.
We
already
have
like
a
planned
change
regarding
the
network
status
that
I
guess
we've
published
or
had
in
our
meeting
minutes
for
multis
cuz.
We
actually
had
a
mistake
where
we
had
networks-
plural
status,
so
we've
actually
been
holding
on
to
two
fields.
So
I
guess
it
would
give
people
an
opportunity
on
that
change
to
change
any
like,
depending
dependent
stuff,
just
as
a
heads
up
for
how
we
might
handle
it
on
the
multi
side.
With
that.
D
Yeah,
but
on
them
all
on
that
you're.
Actually,
you
kind
of
you're
changing
the
name
of
the
field,
so
you've
deprecated
one
and
moved
to
the
next.
This
one,
the
name
would
stay
the
same.
It's
just
the
content
now
is
gonna,
have
a
namespace
in
front
of
it.
I
mean
I'm,
not
sure
who's,
parsing,
the
name
or
how
they're
using
that
currently.
But
I
was
just
curious.
If
that
was
gonna,
be
an
issue
just
changing
it,
but.
A
A
A
E
F
F
So
we
managed
to
merge
like
in
the
cni
as
the
InfiniBand
good
as
a
standardized,
a
runtime
config
for
see
nice
to
process
the
PR
764
is
just
a
typo,
so
it
will
like
the
naming.
Format
will
match
the
rest
and
I've
just
proposed,
like
the
next
step
would
be
to
update
the
multi
net
spec
for
us
to
be
able
to
use
it
on
secondary
networks.
F
A
You
said
naming
question
yeah,
so
we,
the
convention
of
stream
in
CNI
conventions,
changed
a
little
bit
from
the
naming
in
the
document
the
Google
Doc
that
she
referenced
there.
Let
me
actually
put
a
direct
link
to
that
dock
in
the
agenda
here,
then,
we
won't
have
to
go
through
all
of
the
github
issues,
but.
F
A
F
A
Have
other
examples
of
status
annotations
that
use
an
underscore?
There
are
ones
that
use
a
dash,
so
I
guess
for
consistency.
I
would
suggest
a
dash
for
InfiniBand
gooood
I'm
willing
to
entertain
other
thoughts.
The
options
we
have
are
basically
a
dash
or
we
could
try
to
do
capitalization
in
the
middle.
We
could
try
to
do
like
the
normal
go,
Lang,
Jason,
key
style
format
or
whatever,
where
it's
InfiniBand
all
lowercase
and
then
GUI
D
uppercase,
but
even
that
would
be
inconsistent
with
what
we
currently
have
in
our
spec.
A
G
A
A
Let's
see,
let
me
just
make
sure
I
can
do
that.
No
I,
at
least
it's
not
open
to
me.
Would
you
mind
opening
it
up
to
general
comment
access,
I,
don't
think
you
need
to
do.
Everybody
gets
edit,
but
at
least
view
and
comment:
alright,
ok,
so
yeah,
and
then
we
could
continue
the
conversation,
the
doc
but
I
think
next
time.
Our
next
meeting
we
have
given
that
these
are
pretty
close
I
think
we
should
probably
do
a
formal
vote
on
these
amendments
to
this
back.
F
A
E
C
E
D
E
E
E
Thanks
well
I
I
wanted
to
ask.
Maybe
it's
a
stupid
question
so
apologize
if
it
is
very
simple
or
if
it's
not
the
correct
forum,
but
I
came
through
this
document
about
a
device
identification
in
the
network
status.
I
think
it
was
discussed
in
the
previous
meeting.
I
have
the
link
here
that
I
come
yeah.
A
D
E
So,
looking
at
the
proposal,
I
see
that
the
proposal
is
to
add
that
kind
of
device
identification.
Then
in
the
network
status.
But
as
far
as
I
know
that
that
would
be
written
by
the
C&I,
not
the
device
plug-in
and
I
don't
know
if
there
is
a
way
of
getting
that
information
to
the
CNI
or
if
it
would
have
to
be
in
a
separate
annotation
object
or
if
it
would
have
to
be
a
completely
independent
thing.
And
if
such,
if
that's
the
case,
then
how
you
know
how
will
be
handled
by
the
CNI
can.
E
The
okay,
so
the
flow
is
the
device
plug
in
basically
probes,
the
either
the
kernel
or
or
the
the
kernel
framework
or
the
device
itself
and
approach
the
existence
of
the
presence
of
the
V
DP,
a
DP
DK
framework,
and
it
allocates
using
any
of
those
mechanisms
using
either
the
kernel
or
or
a
DP,
DK
diamond.
It
allocates
a
socket
AV
host
socket.
E
E
E
A
E
A
A
E
E
A
All
right,
sorry,
these
are
all
questions
that
I
and
others
sort
of
had
last
time
in
the
time
before
and
would
inform
any
kind
of
specification
or
solution
that
this
group
might
develop.
So
that's
what
I'm
trying
to
drill
down
a
little
bit
further
into
and
get
all
the
detailing
to
our
agenda
Docs
so
that
we
don't
forget
about
it.
Yeah.
E
E
E
So,
that's
why
the
way
that
information,
for
example,
they
indicate
for
in
the
case
of
deep,
deep
edk,
we
would
expose
a
socket
file
to
the
container.
Now
I
know
that
the
user
you
Toland
or
your
Spacey
and
I
already
does
that
and
it
already
exposes
that
information
inside
the
network
status
annotation.
E
D
A
quick
clarification
there,
so
the
user
space
is
doing
it
in
some
private
non-space
standard
way.
It
does
not
do
the
network
status
at
least
how
the
the
socket
like
the
socket
location
and
stuff
like
that
is
passed
up,
and
so
it's
all
in,
like
a
user
space,
specified
annotation,
it's
not
in
there
today,
it's
not
in
the
in
the
network
status
today.
Now
that.
G
A
A
E
E
A
D
E
So
right
now
I
mean
we
could
overload
the
current
environment
variable
that
the
device
plug-in
uses
the
device
plug-in
currently
ads.
I
mean
you
know,
an
environment
variable
with
the
PC
I
address
that
PCI
address
has
no
use
on
DP
DK.
Sorry,
a
VDP
a
because
there
is
no
such
device
and
a
thing
application
won't
have
access
to
the
device.
E
A
Yeah,
the
something
we
discussed
last
time
was
that,
because
most
of
this
is
basically
control
flow
on
exactly
the
same
node
as
it
will
be
consumed.
At
least
I
thought
it
was
little
odd
to
do
round
trips
to
the
cube
API,
because
then
that
requires
that
the
application
inside
the
pod
also
do
round
trips
to
the
cube
API,
to
figure
out
what
those
annotations
are
and
that
requires
cube.
Permissions
are
back
cube,
config
inside
the
container
which
it
might
have,
but
it
you
know,
might
well.
D
Actually
I
think
we.
We
talked
that
at
least
with
the
downward
API
that
kubernetes
provides.
The
annotations
are
provided
just
in
the
file.
Oh
right,
sorry,
yes,
I
did
for
so
you
are
correct
from
whoever
is
going
to
fill
in
the
annotations,
where
this
device
plug-in
of
the
CI,
which
we're
leaning
towards
flights
plug-in,
would
then
would
need
those
permissions,
but
within.
E
E
A
D
D
A
D
A
D
D
A
A
I
think
it
is
relevant
because
what
currently
happens
is
Malta's.
So
in
my
understanding-
and
somebody
please
correct
me
if
I'm
wrong,
because
I
haven't
worked
here,
I've
in
this
area,
I've
just
looked
at
the
implementation
for
like
10
minutes.
Am
I
understanding
what
happens?
Is
that
the
device
plug-in
allocates?
Let's
use
this
RI
of
e,
for
example,
device
plugin
allocates
those
virtual
functions
and
then
returned
some
information
to
cubelet
and
then
Malta's.
B
A
Thanks
Doug
yeah,
so
that
is
relevant
here,
because
that's
one
way
to
pass
the
device
information
around
and
yeah.
We
had
talked
about
trying
to
standardize
that,
whether
that
was
a
pci
address
or
something
because
right
now,
I
think
that
particular
key
is
malta
specific,
and
so
maybe
it
is
worthwhile
to
standardize
that
key
in
the
spec
so
that
other
implementations
could
use
it.
Or
you
know
that
we
have
some
reference
point
for
it,
but
that
only
affects
us
arrivee
plugin
and
wouldn't
be
reflected
inside
the
container
at
all.
A
A
E
E
Device
plugin
wouldn't
need
to
interact
with
cubelet
through
the
api
cubelet.
The
current
device
plug-in
API,
contains
a
annotations
field
is
returned
by
the
device
plug
in
on
the
annotate
allocate
call.
So
that's
why
I
thought
about
annotations
in
the
first
point
because
it
looked
like
it
was
already
being
considered.
Ok,
the
API.
E
A
Because
that
I
guess
we
should
make
sure
that
whatever
annotations
it
does
return
from
allocate
would
then
get
added
to
the
pod
itself,
because
if
I
mean,
like
you,
said,
I'm
assuming
that
happens.
But
we
should
double
check
that,
because
there
are
a
bunch
of
different
annotation
things
running
around
in
various
places
in
cubelet.
A
So
it's
just
going
off
and
allocating
a
couple
of
things,
one
per
network,
but
it
doesn't
know
which
network
so
those
really
match
up
to
you
and
then
it
is
kind
of
up
to
the
implementation
like
maltose
or
something
else
to
figure
out
what
the
devices
are
that
we're
allocated
and
somehow
match
those
up
with
a
given
net
attached.
Def.
A
So
that's
the
next
big
question,
I
think
I
have
for
anybody.
Who's
worked
in
this
space.
I,
don't
know
if
we
have
answered
that
question.
Yet,
if
there's
a
better
way
than
meltus,
just
randomly
picking
a
device
and
assigning
it
net
zero
and
doing
something
else
like
that,
but
I
I
mean
is
the
device
plug-in
able
to
add
some
kind
of
annotation
that.
D
Yeah,
that
is
a
very
good
question.
You
know.
I
know
the
C
and
I
had
all
that
information,
so
I
could,
when
I
was
doing
all
the
user
space
C
and
I
PRC
I
just
had
the
information
there
in
the
net
attach
definition
by
rate,
but
the
which
are
right,
I'm,
not
sure
the
device
plug-in
has
that
and
I.
Think
in
my
head,
I
was
just
assuming
that
it
did
which
you're
right
I
don't
think
it
does
have
that
all
information
that
it
needs.
C
B
D
A
A
A
Okay,
well,
okay,
so
it
looks
like
the
tie
currently
between
those
two
things
is
that
the
resource
name
from
the
returned
resource
map?
You
can
annotate
a
network
attachment
definition
with
the
resource
name,
and
that
is
the
tie
between
the
attachment
definition
and
the
resource
map
that
it
gets
out
of
cubelet.
So
the
device
plug
in
I
guess
would
have
to
know
information
about
what
the
resource
name
is
and
then
Malta
matches
up
the
devices
based
on
the
resource
name.
Does
that
sound
familiar
I.
A
F
A
Do
we
want
to
try
to
answer
the
other
outstanding
questions
here?
We've
got
a
question
of
Adrian.
You
were
going
to
double
check
that
the
annotations
returned
from
device.
Plugin
are
actually
added
to
a
pot
object
in
the
cube
API,
and
then
we
also
have
the
question
of
multiple
networks.
How
does
the
application
inside
the
container
know
which
socket
is
for
which
network
and
then,
if
we
answer
those
questions,
does
that
give
us
enough
information
to
keep
working
further
through
this
next
time?.
A
D
A
D
And
now
I
doubt
a
lot
of
that
original
work
on
the
user
space
scene,
I,
but
I
do
think
a
lot
of
the
stuff
will
need
to
move
to
the
device
plug
in
a
lot
because
of
the
mounting
of
the
that
of
the
socket
file
or
the
char
device
into
the
container.
So
I
do
think
it
makes
sense
to
move
some
of
that.
So
now
it's
a
question
of
how
does
that
information
get
passed
around
and
how
does
this
additional
config
that
maybe
the
device
plug-in
doesn't
know
about
get
pushed
in?
D
A
D
A
C
C
C
So
some
report
is
I,
create
the
two
Mac
builder
interface.
Why
is
the
essentials
and
then
the
another
is
the
nginx
stuff
and
then
both
using
the
different
I
different
IP
address,
but
also
the
same
interface
lucky
I
stopped
directly
map
kiram
come
from
using
the
Mac
computer
interface
like
mirenkova
to
using
as
well.
G
C
C
Nzxt
here
we
go
so
here
is
known
that
you
can
control
you
control
get
so
currently
I
don't
have
any
policy
yet
so
current
idea
from
the
client
side
I'm
the
elect
terminal
to
get
the
NZXT
contents
here
and
then
the
idea
was,
we
say
we
can
see
the
annoyed
be
tab
was
other
than
the
machina
ingress
and
egress.
So
currently
there,
this
boss
change,
is
pretty
empty.
So
this
is
just
a
ghost
rule.
Then
the.
C
Sample
some
good,
no
policy
policy
here
is
the
a
policy
so
I
I
mix
the
three
tree
complicated.
Why
is
the
ingress
filtering
the
essentials
and
test
the
fault,
the
namespace
sector,
and
then
the
port
80
is
only
accepted
course
and
then
from
for
the
egress
side,
I
using
the
local
port
so
that
the
destination
the
TCP
port
is
allowed
180
or
281.
C
C
There
is
no
response,
because
the
IDS
IP
table
works
to
drop
a
packet
and
then,
of
course,
the
way
stroke
of
both
180.
Then
we
can
get
it
so
so
they
are
currently
the
ingress
and
egress
parameter
is
supported
as
the
usual
kubernetes
and
it
will
precede
us
so
so
and
then
the
so
that's
the
current
status
and
then
the
this
coder
is
pretty
you
just
finished
at
the
last
Friday
was
stuff,
so
it's
it's
pretty
dia
immature
and
of
course
there
is.
G
C
C
D
A
A
All
right,
if
not
see,
we
have
a
couple
of
agenor
action
items.
First,
one
is
to
see
here:
Doug
will
propose
a
spec
change
to
clarify
the
requirements
around
namespace
addition
to
the
net
attach
status,
annotation
network
name
and
Adrien
C
will
update
the
InfiniBand
good
proposal
with
the
naming,
change
and
C
well
answer
some
questions
around
VDP
a
and
device
plug
in
and
discuss
next
week
and
I
think
that's
it
anything.
I
forgot,
sunslice,
okay,
alright,.