►
From YouTube: Kubernetes SIG Network meeting 20200730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
All
right
cool,
so
this
is
related
to
the
current
suite
of
changes
that
I've
got
for
the
government
documents.
So
thanks
everybody
for
the
last
round
of
comments,
they're
very
helpful.
B
I
spent
some
time
with
josh
burkus
who's,
also
a
red
hatter,
but
he
is
involved
in
the
cncf
governance
working
group.
So
he
was
able
to
look
at
this
with
me
and
I
took
another
pass
given
some
of
his
comments
as
well.
B
Kind
of
the
big
change
is
that
I
tried
to
use
this
kind
of
new
structure
where
I
said
all
right:
here's
how
we
define
how
you
become
a
member
and
here's
how
you
become
a
maintainer
of
code
in
the
group
so
that
we
can
kind
of,
simplify
and
use
those
constructs
here
in
so
that's
kind
of
the
overall
gift.
However,
there
are
some
specifics
where
I
think
we
can
well
where
I
really
need
input
from
the
group,
and
these
are
things
that
I'm
like
you
know.
B
I
could
try
to
propose
something
but
really
needs
input,
especially
there's
a
there's,
a
new
section
in
here
the
section
d,
that's
meetings
and
voting,
and
I
really
wanted
some
input
on
how
we
want
to
define
quorum
and
another
place.
That
probably
needs
some
more
you
know,
group
think
on
is
how
we
approve
pull
requests.
B
A
Yeah,
it's
kind
of
interesting
at
this
point
that
we
don't
really
know
what
quorum
looks
like,
because
we
don't
really
have
a
formal
list
of
membership.
B
A
B
I
guess
yeah
yeah.
C
A
Yeah
it
also
the
representation
and
involvement
in
this
group
has
changed
over
time
as
it
does
for
most
projects.
You
know,
there's
been
a
couple
core
people
that
have
been
around
for
a
while
and
then
you
know
other
contributors,
you
know
come
and
contribute
go
off.
Do
something
else
for
a
little
bit,
perhaps
come
back
so
it'd
be
interesting
to
explore.
A
Are
you
still
a
member?
If
you
don't
have
any
contributions
or
you
don't
come
to
a
meeting
for
a
year
or
something
like
that?
Do
you
still
get
a
vote
at
that
point?
And
then
you
know
in
terms
of
quarrel,
go
ahead.
B
A
Yeah,
like
how
do
you
you
know
not
not
get
demoted
or
or
kicked
but
yeah,
it
just
seems
like
there
should
be
some
kind
of
yeah
time
and
not
time
out
but
expiration
date
or
something
like
that.
B
C
B
And
so
philly,
for
example,
just
to
give
a
quick
example
of
how
I
tried
to
define
elise
member,
whereas
I
guess
maintainer
is
a
little
bit
different.
But
for
example,
I
tried
to
say
with
a
member,
you
know
to
become
a
member.
You
need
to
have
some
documented
interaction
so
like,
for
example,
in
your
case
you
know
with
the
device
id
stuff
you
know
I
could
show
you
know.
B
Hey
billy
has
been
an
active
participant
by
this
documentation
over
the
year
period
of
the
last
three
months,
and
I
mean
I
I
know
just
from
knowing
that
you've
been
involved
for
a
long
time,
but
it's
it
would
be
really
easy
to
show,
and
in
that
particular
case,
just
as
an
example
right.
C
So
do
we
need
to
add,
like
a
one-liner
to
the
agenda
like
attendees
for
each
meeting
just
as
a
because
I
may
not
bring
something
up
in
the
meeting,
so
I
may
not
have
like
a
dog
in
brackets
government
document
section
in
the
agenda.
But
I
was
here-
and
maybe
I
talked,
but
my
name
doesn't
show
up
anywhere
in
the
agenda.
C
B
Yeah,
that's
a
good
point.
You
know
what
I
think
an
attendee's,
a
like
roll
call
kind
of
thing
I
think,
is
really
good
and
then
that
way,
for
example,
the
way
I
have
it
written
is
like
you
need
to
have
a
documented
thing
in
the
agenda
and
we
don't
want
necessarily
people
to
populate
the
agenda
with.
C
C
So
I
I
mean
I
don't
know
if
you
need
to
put
it
in
there,
but
maybe
in
the
I
mean
I
wouldn't
put
it
in
the
government
governance
document,
but
in
the
agenda
document,
maybe
as
a
bullet
item
at
the
top.
That
says
you
know
for
like
the
attendees,
it's
kind
of
up
to
you
to
put
your
name
in
there,
because
I
know
for
the
srv
community
meeting
I
started
adding
attendees
and
then
honestly,
I
would
have
trouble
finding
people's
names.
C
You
know,
I
don't
necessarily
know
everyone,
so
I
tried
my
best
to
put
them
in
there
and
I
always
at
the
end.
You
could
always
say:
hey
make
sure
you
update
it,
but
I
think
it
would
be
up
to
the
individual
make
sure
their
is
on
the
attendee
list.
So
I
don't
think
it
needs
to
be
in
the
governance,
but
maybe
just
a
note
in
the
agenda
document
on
how
the
agenda
document
works
to
say,
you
know
if
you're
want
to
prove
you're
a
member.
A
Taking
notes
which
we
don't
have
a
designated
note
take
or
anything,
but
even
so
whoever's
taking
notes,
doesn't
have
to
go
scrape
the
list
of
attendees
and
monitor
for
changes
and
that
kind
of
thing.
C
C
So
kind
of
a
question,
so
if
so
we're
talking
about
moving
the
srov
underneath
the
network
plumbing
working
group,
but
the
srv
has
its
own
meeting.
So
does
that
meeting
count
as
like
a
maintainer
for
that
particular
repo
like
sub,
you
know,
repo
under
the
network,
plumbing
working
group
repo,
or
how
does
that
work?
C
B
Asking
so
I
I
mean,
I
think
that
it's
completely
reasonable
that
if
you've
got
a
particular
project
of
a
big
enough
scope
that
you
need
to
have
maintainers
meetings
that
you
know,
participation
could
be
gauged
based
on.
You
know
those
meeting
notes
as
well.
Maybe
I
can
make
a
note
here
about
maybe
in
the
maintainer
section
saying
you
know
also
whatever
project
specific
notes
or
something
like
that
or.
C
Yeah,
I
don't
want
to
overly
complicate
it,
but
if
you
know
I'm
like
becoming
a
member
and
distributing
you
know
showing
that
you've
either
put
code
in
or
you're
attending
meetings.
So
if
I'm
only
attending
the
srov
meeting
like
let's
say
abdul,
for
example,
he's
only
going
to
the
srv
meetings
he's
not
necessarily
coming
to
this
one.
He
should
still
have
his
rights
under
the
srv
repo.
B
I
guess
in
part
you
know
what
I
I
guess,
there's
part
of
me
that
thinks
that
there's
this
I
kind
of
leave
some
wiggle
room
here,
where
I
say
stuff
like
here's,
our
usual
ways
that
you
interact
and
then
I
say
to
become
a
member.
One
must
have
demonstration,
demonstrated
contributions
to
the
group
documented
in
the
meeting
agenda,
github
or
any
other
place.
Where
contribution
is
possible.
C
And
then
do
we
say
it's
yeah,
it's
subject
to
the
maintainers
to
decide
membership
or
you
know
I
guess
it
gets
to
the
end.
You
have
some
vote
and
you
know
you're
trying
to
determine
who
has
membership?
Is
it
up
to
the
maintainers
to
decide
if
someone
has
a
voting
right
because
they
they
attended
one
meeting
or.
B
So
yeah
so-
and
I
guess
important
distinction
here-
is
that
we've
got
becoming
a
member
right
and
right
now
it
says,
demonstrated
contributions
to
the
group,
and
I
think
that
we
can,
you
know,
make
that
a
little
more
distinct
with
the
like
attendees,
as
you
mentioned,
and
so
anyone
who's
a
member
so
but
basically
right
now.
B
The
way
it
reads
is
you
have
demonstrated
contributions
to
the
to
the
group
and
then
you
ask
to
become
a
a
member,
and
basically
anyone
with
voting
rights
can
reject
a
proposal
to
become
a
member,
but
the
default
is.
If
nobody
rejects
you
become
a
member,
then
you
have
the
right
to
vote.
Okay,.
C
B
Then
and
then
further
from
that,
then
there's
the
other
role,
which
is
maintainer
and
you
have
to
be
a
member
first
to
become
a
maintainer
and
then
same
kind
of
rules
as
well.
So
it's
like
you
add
your
name
to
the
agenda.
You
propose
that
you
want
to
be
a
maintainer
of
x,
y
and
z
and
then
basically
the
gist
is,
I
guess.
B
Well
I
guess
this
is
so
right
now
I
have
it
saying
that
you
would
become
a
maintainer
accepted
as
by
majority
vote,
but
there's
part
of
me
that
likes
this
kind
of
you
get
it
by
default.
If
nobody
disagrees,
I
yeah
there's.
B
That
that
likes
that
so
maybe
I
should
just
copy
the
same
kind
of
pattern
here.
C
Yeah,
that's
probably
good,
so
does
that
mean
we're
going
to
have
an
official
list
of
members?
So
when
voting
time
comes,
we
like
is
it
in
the
agenda.
C
B
Plus,
I'm
going
to
make
a
stub
here
to
define
where
our
members
document
it:
okay
and
I'm
happy
to
take
any
suggestions.
There.
There's
part
of
me
that.
C
B
B
So
I
guess
along
this
agenda
item
you
know
definitely
looking
for
any
further
ways
to
improve
this
daw,
but
something,
I
guess
that's
worth
covering
right
now-
is
kind
of
the
impetus
for
this
documentation,
which
is
creating
the
appropriate
or
repository
for
the
srlv,
cni
and
device
plug-ins
and
whatever
auxiliary
tooling,
is.
Is
this
something
that
we
want
to
start
working
on?
I
know
last
meeting
we
did
determine
that
we
could
go
in
parallel
with
creating
those
repositories.
While
we
work
towards
this
governance.
A
B
As
far
as
I'm
aware,
it's
just
srlv
and
I'm
not
sure
if
all
of
the
components
are
necessary
there,
but.
B
That's
the
way
I
understand
it
and
when
I
talk
to
zengui
who's,
you
know
one
of
the
active
participants
of
the
srbc
and
I
device
plug-ins.
Those
were
the
two
that
he
brought
up.
So
so
that's
the
one
I
know
and
I've
been
entitled
in
tell
as
well
about
this.
I
am
not
sure
if
there's
anyone
from
intel
on
the
call
today,
sometimes
I
think
they
have
conflicts
here,
but
so
anyways.
B
The
intel
interaction
that
I
had
you
know
they
are
willing
and
happy
to
move
forward
on
this
and
they're
just
figuring
it
out
whatever
internals
they
have
to
figure
out
on
their
side
and
at
least
the
way
I
understood
it
was
is
their
internals
was
repository
by
repository,
so
they
currently
have
whatever
they
need
to
do
for
the
cni
plug-in,
and
I
made
them
aware.
It
also
needs
to
be
the
device
plug-ins
so
they're
doing
whatever
they
need
to
do.
B
But-
and
I
bring
that
up
only
because
you
know,
I
think
that
it's
important
to
have
you
know
a
diverse
set
of
organizations
contributing
to
the
project.
So
hopefully
we
can
retain
their
contributorship
along
with
everybody
else,
but
I
think
the
the
bottom
line
is
this.
Is
these
are
open
source
projects?
We
can
fork
them
and
create
repos
at
any
time
that
you
know,
as
members
of
this
group
that
were
we're
ready
to
to
go
ahead
with
that
and
intel
can
a
synchronously
do
what
they
need
to
do
to
ensure
their
contribution.
C
Yeah
that
sounds
good.
Have
you
talked
a
long
way
about
like
when
to
do
when
that
would
be
a
good
time,
for
example,
do
they
want
to
like
set
a
tag
or
a
label
so
that
when
they
move
it
that
you
know
we
know
where,
like
a
like?
A
after
like
release,
I
have,
I
have
to
look
at
the
release
schedule,
but
or
release
numbering,
but
after
a
particular
release.
That
is
the
time
we
want
to
fork
or
that
we
just
gonna
pick
it
up
midstream
and
move
it.
B
And
you
know
so
I
silly,
I
think
that
you've
hit
on
something
really
important
is
that
we
need
the
srlvcni
and
the
vice
plug-in
domain
experts
to
get
such
details
there,
which
I
only
have
kind
of
at
a
high
level.
To
be
honest,.
C
Yeah,
so
that's
why
I,
I
guess
we
have
the
meeting
on
monday,
so
I
will
bring
it
up
there
and
and
see
I
mean
I'm
I'm
active
in
that
I'm
active
and
since
I
go
to
the
meetings,
but
I'm
not
a
huge
contributor,
I'm
doing
it
more
from
the
vdpa
point
of
view.
So
it
will
be
have
to
sync
it
up
with
zongway
and
abdul
and
see
what
they
think.
B
Okay,
let
me
see
if
I
can
make
it
to
that
call
too,
and
I
can
bring
well,
I
mean
also
you're,
just
as
capable
of
getting
that
yeah
silly.
Actually,
since
you
since
usually
make
it
to
that
meeting,
maybe
yeah
you
can
just
let
us
know
about
that
outcome,
to
see
if
there's
any
specific
date
or
release
or
whatever,
that
that
they're
ready
to
to
move
ahead
with
that
yeah.
C
B
All
right
cool,
so
at
least
from
my
perspective,
that
covers
what
I
wanted
to
cover
with
the
governance
doc
and
then
the
repository
move.
I
have
the
next
item
on
the
agenda.
D
That
wanted
to
ask
about
the
other
brief
peoples
that
are
currently
under
the
kubernetes
network.
Plumbing
working
group
github
are
those
like
automatically.
D
Are
they
do
they
join
automatically
this
governance
model
or
or
is
it
going
to
be
another
group
of
reposs.
B
I
think
that's
an
awesome
question
and
I
think
what
I
would
propose
is
that
we,
we
would
put
those
repos
basically
through
the
same
process
that
we
have
that
we
would
agree
on.
So
that,
like
say,
for
example,
I'm
just
going
to
use
the
reference
deployments
repo
as
an
example,
so
at
least
currently
the
way
that
that
works
is
it's
basically
been
tomo
and
I
taking
care
of
it,
and
I
guess
what
we
would
do
is
we'd
put
it
on
the
agenda
and
we'd
say
reference
deployments.
Does
this
match
our
mission
statement?
B
D
Yeah,
that
makes
sense-
and
maybe
even
we
could
start
with
those
or
if
the
cni
and
the
device
plug-in
need
more
time
to
figure
out
their
schedule
with
regards
to
maybe
releases
or
anything.
Maybe
we
could
use
those
ones
as.
B
I
love
that
yeah,
I
think
all
the
better
if
yeah.
This
is
something
I
feel
like
we're
awesome
at
with
this
group
is
to
come
up
with
a
process,
apply
it
and
then
use
that
as
feedback
adrian.
I
think
that's
a
great
way
to
do
it.
B
Awesome
thanks
adrian
any
other
input
here
before
the
next
one.
A
So
I
think
the
the
governance
doc
said
that
we
were
going
to
put
like
a
code
of
conduct
or
whatever
into
each
repo.
Should
we
have
a
little
bit
more
guidance
around,
have
a
maintainers
file
and
list
maintainers
in
the
repo
and
actually
have
a
more
formal
idea
of
you
know
who
the
maintainers
for
each
repo
are.
B
That's
an
awesome
call.
Let
me
make
a
note
here
in
the
doc,
because
I
think
that,
let's
see
you
know,
we.
A
You
well
corresponding
to
that.
Are
we
going
to
have
anything
that
says
here's
a
list
of
members-
I
guess
maybe
that
was
covered
in
the
doc
and
I
just
didn't
see
it.
But
how
do
we
actually
record
official
membership
as
well.
B
Yeah
and
so
billy
brought
this
up
briefly,
and
I
put
a
stub
in
about
the
list
of
members
but
yeah.
That
definitely
also
needs
to
be.
A
C
Official
list,
I
see
that
now
I
think
we
said
that
probably
the
agenda
document
was
okay
to
have
that
list.
Since
we
have
a
history
in
there,
so
people
with
somewhere
to
magically
just
put
their
name
in
there.
You
could
look
at
the
history.
I
mean
it'd,
be
up
to
us
to
rex
recognize
that
and
say
hey
that
got.
I
don't
remember
him
showing
up,
but
I
think
we
said
the
agenda
document
may
be
a
good
place
for
it.
A
Well,
I
mean
that
that's
a
good
place
for
recording
each
meeting
and
stuff
like
that.
But
I'm
wondering
if
we
should
have
like
an
official
list
of
members
since
the
agenda
doc
would
just
show
who'd
up
who
showed
up
to
a
given
meeting.
C
And
that's
fine
too,
I
think
that's
part
of
what
doug
was
where
our
members
documented.
One
of
the
suggestion
was
the
agenda
doc
and
I
guess
I
was
thinking
like
at
the
top.
Above
the
you
know
the
the
weekly
meetings,
not
necessarily
in
the
weekly
meetings
in
themselves,
but
up
above
an
official
section
that
would
change.
But
if
you
want
another
document,
that's
only
that
it's
read
only
to
the
world
and
only
is
read
write
to
the
maintainers.
I
think
that
would
be
acceptable
too.
A
Yeah
I
mean
we
could
put
it
in
something
like
the
community
repo
as
well.
Have
a
you
know
like
where
the
all
the
official
docs
and
governance
policy
and
stuff
like
that
is,
you
could
just
get
it
there
as
well.
A
B
Yep
yeah,
so
the
next
one
here.
Hopefully
this
is
a
fairly
short
item,
but
generally
the
gist
is
when
I
was
talking
to
josh
from
our
open
source
program
office
at
red
hat.
He
you
know
he's
asking
about
the
history
of
the
group,
and
you
know
I
explained
and
I'm
like
well,
you
know
we've
kind
of
been
off
on
our
own
it
had.
You
know.
I
think
some
interest
was
generated
initially
through
rusig
network,
but
we've
kind
of
been
our
own.
You
know
splinter
cell.
B
If
you
will
and
josh
said
hey,
you
know
it's
not
really
a
big
deal
to
become
an
official
working
group
and
essentially
the
way
that
I
understood
the
process
and
maybe
get
some
more
clarification
from
josh,
but
the
gist
was
that
to
become
an
official
kubernetes
working
group.
B
So
in
terms
of
the
like
benefits
or
non
benefits
of
that
is
josh
thinks
that
it,
that
would
be
a
nice
path
forward
for
us,
potentially
getting
repositories
in
as
part
of
the
cncf,
as
he
additionally
described,
that
the
requirements
for
a
sandbox
project
under
the
cncf
have
loosened
greatly
over
the
last
couple
months,
and
it's
it's
like
previous.
The
way
I
understood
it
is
that
previously
you
needed
to
have
some
kind
of
trajectory
that
was
towards
you
know
like
a
ga
style
release.
B
A
B
B
I
know
that
mike
from
ides
was
concerned
about
this
before,
and
I
think
that
you
know
it
may
be
nice
to
have
that
framework
and
to
have
another.
B
You
know
set
of
governance
to
fall
back
on,
although
he
did
say
that
that
working
group
status
doesn't
necessarily
come
with
any
like
out
of
the
box
governance.
So
this
effort
that
we
have
ongoing
would
actually
be
will
still
be
useful
for
us.
So
I
wanted
to
bring
that
up
and
see
how
people
felt
about
that
and
then
maybe
think
about
the
possibility
of
next
death
along
that
one,
which
may
be
me
getting
more
clarification
from.
B
A
I
think
it's
probably
a
good
idea
to
restart
these
kinds
of
discussions
around
becoming
a
more
formal
group.
Cncf
seems
like
a
good
option.
I
just
dropped
a
note
in
there
wondering
about
cncf
versus
kubernetes,
of
course,
understanding
that
kubernetes
is
already
a
project
of
the
cncf,
but
the
other
possibility
we
had
discussed
in
the
past
every
now
and
again
and
never
gotten
around
to
investigating-
was
a
official
kubernetes
working
group
which
has
a
different
set
of
definitions
and
entry
criteria,
and
things
like
that.
A
B
I
personally
would
be
either
he
was
either
route
there
and
I
think
that
it
would
be
easy
to
make
a
case
on
either
side
of
it,
and
I
mean
I
agree.
We
have
had
a
lot
of
kubernetes
focus,
but
we
have
also
have
a
lot
of
cni
expertise
in
this
group,
and
cni
is
intrinsically
not
kubernetes,
specific
right,
so
yep,
I
think
it'd
be
easy
to
make
the
argument
either
way.
Let's
try
to
get
some
more
clarification
from
josh
on
the
process
for
one
versus
the
other.
A
Yeah
maybe
get
his
opinion
on
that
too.
If
he
has
one.
A
The
other
thing
is
that,
like
the
annotation
namespace
that
we've
chosen
was
explicitly
under
oh,
I
mean
what
is
it
like,
cni.cncf.io
or
something
like
that,
so
we've
already
sort
of
made
some
decisions
around
where
the
project
is
name-spaced,
even
if
they
weren't
explicit
at
the
time.
B
Yeah,
I
think
that
that
does
kind
of
speak
to
the
like
breath
that
we
were
trying
to
cover
with
this
as
well
for
sure.
B
All
right
so
I'll
get
josh's
opinion
I'll,
get
any
clarifications
on
the
process
and
then
maybe
from
there.
Then
we
can
figure
out
the
next
steps
for
how
we
want
to
handle
that
proposals
of
technical
oversight
committee.
Does
that
sound
like
a
reasonable
next
step?
Folks.
B
All
right,
cool,
nice
yeah
that
covers
it
for
me,
unless
there's
any
other.
E
Right
over
to
tomo
okay,
so
so
currently,
as
you
know,
the
I'm
working
on
the
macbeth
network
policy,
which
implements
the
network
policy
for
models
interface,
so
that
this
the
component
utilizes
the
ip
tables
in
the
port
namespace
site
and
then
do
this
stuff.
So
this
means
iptable
is
not
not
only
used
in
the
mac
beta
ipv,
of
course
uses,
and
the
alberta
is
not.
I
mean
that
the
point
to
point
cinema,
plugin
and
the
bridge
cni
also
works
with
the
ip
tables.
So
so
there
I
name
it.
E
I
I
named
the
wrong
component
for
that
actually,
so
that
this
should
be
the
not
the
mark
bitter,
not
only
for
macbeth.
So
I'm
just
thinking
about
the
changing
the
repository
name
and
also
the
in
in
the
code
to
modus
network
policy.
So
currently
this
the
component
is
pretty
incubation
phase.
So
then
they
are
not
so
major
stuff.
So
I'm
just
thinking
I'm
it
should
be
okay,
but
also
I'm
I'm
just
a
double
check
with
other
guys
and
then
your
forks.
B
What
about
calling
it
yeah
a
multi-net
network
policy,
possibly.
B
E
Not
the
amount
of
specific,
I
only
use
the
fork
related
to
the
network
management
definition,
so
so
yeah,
maybe
the
amount
network,
multi-net
network
policy
or
yeah.
Maybe
the
amount
net
network
policy
could
be
feasible.
B
B
I
really
like
multinet
policy,
it's
the
last
redundant.
I
like
that.
E
Yeah
yeah
yeah
net
net
is
the
a
little
bit
so
so
yeah
yeah
I'm.
If
you
do
not
mind
the
I'm,
I'm
the
thinking
about
this
stuff
and
then
I'm
I'm
going
to
change
it.
It's
the
next
week,
yeah,
I'm
just
thinking
about
the
multi-network
policy
could
be
a
candidate
because
the
amounts
net
network
policy
is
a
little
bit
hard
to
say.
E
C
More
tomorrow,
I
do
like
that
you're
changing
it,
because
I
was
a
little
confused
that
when
it
said
macvlan,
if
it
was
strictly
mac
vlan,
it
wasn't
more
generic
solution.
So
I
do
like
the
fact
that
you're
changing
it-
and
I
agree
that
probably
multis
shouldn't
be
in
there,
even
though
under
I
probably
I'm
horrible
at
names,
and
that's
probably,
I
would
have
come
up
with
something
similar,
so
yeah
yep
got
it.
Thank
you.
Thank
you
for
your
comment.
D
Yeah,
well,
I
had
a.
I
have
a
question
for
you
tomo.
So
is
this
network
policy
specific
to
ip
tables
and
if
there,
if
we
were
to
envision
another
way
to
enforce
network
policies,
would
that
be
implemented
in
this
network
policy
in
this
project
or
it
would
it
be
like
another
kind
of
a
plug
another
another
network
policy
plugged
into
into
a
multi,
for
example,.
E
This
is
good
question,
so
so
the
I'm
so
currently
the
multi-net,
the
most
little
policy
utilizing
ip
table,
but
of
course,
I'm
also
the
targeting
as
the
next
candidate
as
the
ebpa
for
some
other
stuff,
the
ebpf
fund
and
the
yeah,
maybe
there's
some
specific
stuff
for
dpdk
stuff
anyway,
the
so
the
at
that
time
should
we
implement
another
component
or
the
should
we,
they
put
the
evp
of
code
into
the
mulch
network
policy.
E
This
is
a
pretty
a
trade
off
you
know,
so
they
are
adding
the
several
features
in
the
one
comma
component.
This
makes
the
insanely
complex
stuff.
You
know
the.
If
you
see
the
acute
proxy
we
can
easily
seeing
the
one
example
you
know
the
the
ip
tables
and
then
the
vm
then
so
that
this
makes
the
very
complicated
and
they're
hard
to
maintain.
So
so
I'm
I'm
still
I'm.
E
I
have
these
two
questions
about
the
whether
I
should
implementing
the
in
current
component
or
creating
the
another
component
only
for
the
ebpf
network
policy.
So
this
and
then,
of
course
the
if
the
summer
is
thinking
about
utilizing
the
tc
offloading
for
the
network
policy.
Maybe
this
could
be
the
candidate,
but
I
don't
know
yet
so.
D
E
Yeah,
so
so
the
yeah.
So
currently,
I'm
I'm
the
yeah
I'd
like
to
keep
this
stuff
as
the
question,
because
the
yeah
so
currently,
of
course,
we
only
have
the
one
implementation
and
then
the
the
maybe
the
once
we
implemented
the
another
implementation
ebpa
for
this
stuff
and
then
the
I'd
like
to
think
about
it
again
again.
E
D
Identification
proposal.
Okay,
so
it's
my
turn.
So
I've
put
a
link
there
to
the
document.
I
did
a
bit
of
cleanup
and
I
put
a
change
log
at
the
beginning
of
the
document
to
ease
the
review.
D
So
what
has
changed
since
the
last?
D
Since
the
last
meeting
is
we
have
tried
to
simplify
the
path,
the
paths
in
order
to
make
sure
that
the
resource
the
file
cleaning
is
easier,
so
the
old
path,
the
where
the
files
the
device
files
were
going
to
be
stored,
was
basically
a
directory
hierarchy
like,
for
example,
a
device
plugin
would
create
a
directory
with
the
resource
name
and
then
a
subdirectory
with
the
device
id
and
then
a
device
and
then
just
a
file,
so
that
hierarchy
it
it's
clean,
cleaner
to
to
to
see
in
the
file
system.
D
But
it's
not
as
easy
to
to
then
do
some
kind
of
garbage
collection
because
of
the
different
levels.
D
So
the
current
proposal
is
to
have
a
more
flat
file
system
hierarchy,
so
we
would
have
like
a
direct
a
base
directory
for
the
device
plugin
and
another
base
directory
for
the
cni
and
all
the
files
were
will
be
in
that
directory
and
the
name
of
the
file
will
be
composed
of
the
resource
name
and
device
id
the
same
way
that
that
that
they're
used
to,
but
instead
of
you
know
instead
of
using
directories
just
using
the
file
name,
that
makes
it
cleaner
for
yeah.
D
So
that's
one
of
the
changes
any
comments
on
this.
A
I
wasn't
clear
on
what
the
reason
was
for
having
two
different
directories
like
the.
D
Oh
yes,
so
I
I
didn't
go
into
that.
That
is
one
of
the.
That
is
one
of
the
comments
that
we
have
the
pending
to
resolve.
So
yeah
we
can,
we
can
yeah,
we
can.
A
D
Okay,
I
I
really
don't.
I
really
don't
mind
and
now
that
the
it's
flat,
everything
is
flat,
it's
even
it
is
yeah,
maybe
maybe
it
makes
more
sense
to
have
just
one
directory
for
everything
I
yeah,
but
we
can
discuss
it
in
the
document
sure
so
another
change
and
that
I
would
like
to
get
your
feedback
about
is
putting
the
this
directory
instead
of
in
var,
slash
var,
slash,
run
moving
to
slash
run.
D
The
reason
is
that
in
most
distributions,
slash
run
is
temp
fest.
D
So
that
means
that,
because
one
of
the
the
one
of
the
problems
here
is
on
the
cni's,
the
cni's
that
create
the
files,
they
delete
the
files
when
they
are
called
when
the
pot
is
deleted.
But
that
might
not
happen.
D
For
example,
when
there
is
a
crash
in
the
node
and
the
node
unexpectedly
is
rebooted
in
that
case,
if
there,
if,
if
the
directory
we're
using,
is
backed
by
a
a
storage
that
is
persistent,
then
then
we
would
be
leaving
files
behind
and
that
would
be
complicated
to
clean.
D
We
would
need
some
kind
of
garbage
collector
booting
up
before
anything
else
and
it
makes
it
complicated
if
we
move
it
to
a
temper
fest,
then
we
don't
have
the
problem,
and
since
this
is
inherently
dynamic,
I
guess
it
makes
sense.
So
what
do
you.
A
Think,
at
least
on
fedora
and
rel
var
run
is
basically
a
sim
link
to
run
anyway.
So
I'm
not
sure
that,
like
the
difference
between
var
run
or
just
slash,
run
makes
a
difference
on
those
platforms,
but
you
know
I
think
it's.
The
other
thing
we
can
do
is
say
that
this
directory
should
be
cleaned
up
by
the
implementation
or
something
on
reboot
and
that
could
be
through
like
attemptfiles.d
file.
It
could
be
a
mount
point
that
is
on
a
temp
fest
or
something
like
that.
A
I
don't
know
if
we
want
to
necessarily
specify
here
exactly
how
that
is
done,
but
at
least
if
we
intend
that
behavior,
then
we
can
strongly
suggest
that
the
implementation
make
sure
that
these
things
are
cleaned
up
in
the
right
way,
and
here
are
a
couple
of
ways
that
you
could
do
that.
D
Okay,
yes,
that
makes
perfect
sense,
so
just
leave
it
as
a
suggestion
or
our
us,
our
recommendation
and
and
let
the
implementation
make
yeah
because
you're
right
there
are
many
ways
to
do
this.
You
can
yeah.
A
C
C
D
Okay,
perfect,
so
then,
I've
also
added
a
section,
which
is
the
modifications
that
we
that
we
would
have
to
add
to
the
network,
plumbing
working
group
spec,
and
they
are
at
the
bottom
of
this
document,
and
I've
tried
to
make
them.
D
As
spec
ish
as
possible,
so
please
have
a
look
and
with
regards
to
the
comments,
I've
put
two
links
there
to
the
current
open
comments.
One
of
them
is
the
one
that
you've
mentioned
then
about
the
directory.
So
if
you
agree,
if
we
all
agree
that
we
can
put
everything
under
the
same
directory
and
just
ensure
that
the
name
of
the
files
don't
clash,
then
yeah
we
can
put
all
of
them
into
the
same
directory.
A
D
You
yeah
so
there
this
the
the
document
is
written
in
a
way
that
should
ensure
that
for
the
cni's
there
is
no
name
clash
and
for
the
device
plugins
there
is
no
name
clash,
but
whether
there
is
a
a
possible
conflict
between
a
device,
plugin
and
acni.
That
is
not
I.
I
did
not
have
that
in
mind,
but
I
think
it's
very
com.
D
It's
very
rare
I'll,
give
it
another
thought,
but
if
in
any
case
it
would
be
as
simple
as
doing
the
same
thing
and
replacing
the
directory
with
a
with
a
with
a
file
name
that
is
composed
of
you,
know,
dp
and
then
the
resource
name
and
the
device
id
and
for
the
cni's
cni
hyphen,
the
network
name
and
the
whatever,
and
that
would
keep
those
collisions
away
in
the
same
in
the
same
way
and
and
have
the
same
flat
high
directory.
D
So
I
think
I
think
I
think
we're
good.
I
don't
think
it's
it's
very
problematic.
D
Okay,
so
I'll
change
that-
and
I
will
clear
up
that
resolve
that
comment.
D
The
last
comment
I
have
is
with
regards
to
the
network,
plumbing
working
group,
spec
modifications,
and
I
found
that
there
is
no
reference
to
the
resource
name
annotation.
D
This
resource
name
annotation,
is
very
widely
used,
or
at
least
for
the
cni
device,
plug-in
and
c
and
sorry
for
the
sr
iov
device,
plug-in
and
cni,
and
at
least
multus,
which
is
the
implementation
that
I
have
looked
at
a
bit.
It
has
this
mechanism
of
dynamically
injecting
the
device
id
reading
it
from
the
cubelet
resource
api.
D
So
all
this
process,
including
the
resource
annotation,
it's
there-
is
no
reference
to
that
in
the
spec.
D
So
and
it's
it
will
be
so
in
order
to
write
these
spec
modifications
properly
and
clearly,
I
would
have
to
make
reference
to
that.
So
is
there
anywhere
where
this
is
documented
or
specified
somehow,
or
should
I
or
should
we
put
it
into
the
network?
Plumbing
working
group
spec.
A
A
However,
then
that
spec
could
change
independently
of
the
plumbing
working
group
spec,
and
how
do
you
make
sure
that
implementations
are
compatible
with
both?
So
I
think,
there's
an
argument
for
both
ways
as
long
as
it's
not
that
complicated,
it
might
be
good
to
try
adding
a
section
to
the
plumbing
spec
to
lay
out
the
at
least
the
json
format
of
the
files
I
mean
it.
D
Okay,
I
can
try
to
write
it
up
and
we
can
discuss
it
in
the
next
meeting,
see
if
it
is
too
much
and
we
should
have
it
an
independent
document
or
if
it's
good
enough
to
put
it
into
the
spec.
I
can
do
that
and-
and
we
can,
you
know,
discuss
it
next
time.
A
Okay
sounds
good
thanks
for
all
your
continued
work
on
it
by
the
way
sure
alright,
we
are
out
of
time,
so
see
everybody
next
time
in
two
weeks,.