►
From YouTube: WG Network Plumbing 20200827
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
Yeah
I've
got
two
sections
here
that
are
about
the
governance
proposal,
but
the
first
one
I
wanted
to
talk
about
was
that
it
was
brought
to
my
attention
and
I
agree
that
currently
for
the
github
org
ownership,
dan,
it's
you
and
I
and
mike
spritzer-
and
I
think
that
probably
so
when
this
first
happened
mike
is
part
of
ibm
at
the
time
red
hat
was
not
part
of
ibm,
but
now
it's
kind
of
all
under
one
rooftop,
and
we
should
definitely
make
sure
that
that's
addressed
and
so
that
we've
got
org
ownership.
B
A
Yeah
I
mean
I
think
that
would
be
a
good
idea.
What
is
the
criteria
for
somebody
to
become
an
org
owner?
A
B
Yeah,
hopefully
I
mean
I
would
just
like
to
assure
everybody
that
that
you're
in
good
hands
here-
and
you
know-
and
I
hope
that
dan
and
I
are-
are
showing
good
faith
on
this
one.
But
you
know
we
we
don't
want
it
to
to
be
this
way.
So
let
me
try
to
come
up
with
some
language
for
this
to
see
how
we
can
handle
it
and
then.
B
Yeah
all
right
so
anyways.
I
guess
it's
good
to
make
people
aware
of
this
and
to
let
people
know
that
we
want
to
take
care
of
it.
So
I
will
I'm
just
going
to
add
a
stub
in
the
governance,
dock
and
I'll.
Try
to
put
some
thought
into
this.
One.
B
B
Five
members
to
change
the
governance
document
is
what
I
put
in
here
and
then
I
added
an
example
to
show
you
know
what
it
looks
like
if,
in
order
to
balance
the
representation
between
companies
and
their
employees,
to
just
make
that
clear,
basically
to
show
you,
you
know
hey
if
there's
a
bunch
of
people
from
one
organization,
but
only
a
few
from
another,
then
some
people
have
to
abstain
is
essentially
what
I've
got
there.
Those
were
really
the
only
major
changes.
B
But
that's
it
so.
That
being
said,
I
wanted
to
open
the
floor
to
see
if
there's
any
major
concerns
that
people
have,
and
I
also
wanted
to
get
a
sense
from
people
about
how
close
they
are.
We
think
we
are
to
voting
on
this.
I
you
know,
as
it
tends
to
go
with
a
lot
of
the
proposals
that
we
have
in
this
group.
B
We
we
tend
to
get
a
lot
of
rapid
changes
right
off
the
bat
which
is
awesome,
and
then
we
get
a
bit
of
a
slowdown
and
I'm
starting
to
feel
that
you
know
it's
starting
to
stabilize
a
little
bit.
So
anyone
have
comments
on
those.
C
So
adrian
I
was
trying
to
remember,
I
think
it
was
in
the
srv
meeting.
You
brought
up
the
concern
somewhere
and
I
have
to
have
to
dig
through
the
document
about
vendor
neutral
code
and
with
some
of
the
srv
stuff
part
of
the
reason
to
move.
It
was
so
that
some
vendor
specific
with
the
correct
api
could
be
added.
Do
we
need
to
address
that
at.
D
In
the
mission
statement
that
it
should
be
like
vendor,
neutral
technologies,
I
did
state
something
about
the
fact
that
the
srve
device
plugin
has
some
some
code,
which
is
vendor
specific,
which
would
kinda
challenge
mission
state
and
the
statement
we
will
need
to
to
handle.
D
So
I
mean
it,
that's
basically
I
mean
I
don't
I
I
don't
want
the
it
to
affect
the
mission
statement.
I
feel
that
we
should
define
something
and
then
find
a
way
when
we
migrate
a
project
to
for
them
to,
let's
say
hold
up
to
that
mission
statement
given
it's
like
and
of
course
we
don't
want
to
be
too
specific
in
it.
So
right
so
I
mean.
C
I
think
in
general
we
want
vendor
neutral
code,
but
when
there's
something
that's
implemented,
two
different
ways
by
two
different
vendors:
we
need.
No,
I
don't
know
if
the
right
word
is
an
exception
or
a
right
way
to
handle
some
vendor
specific
implementation.
If
needed-
or
I
mean,
are
you,
do
you
feel
comfortable
with?
What's
there
or
is
there
anything
that
needs
to
be
amended
to
make
sure
that
we
can?
We
can
still
make
progress
and
get
stuff
in
that
we
want
to
get
in.
I
guess
is
the
right
word
wording.
D
So
my
engineering
take
would
be
that
this
should
be
like
under
neutral.
So
it
means
that,
ideally,
we
need
to
have
like,
in
general,
like
one
implementation
of
stuff
like
of
features
right,
so
there's
a
standard
way
and
not
every
everybody
cooks
their
own.
So
I
mean
this
kind
of
sieves
down
from
you
know
from
whether
or
not
from
the
kernel
api
upwards
right
right.
D
I'm
just
saying
that
having
it
like
vendor
neutral
technology,
here
I
mean
it
will
pose
some
challenges
when
we
move
this
or
every
device
plug-in.
That's
all
when
we
discussed
about
you
know
the
that
we
want
to
move
it
right.
So
like
the
cni
and
the
device
plug-in
so
right,
it
was
just
more
as
a
heads-up
whether
we
want
to
change
the
mission
statement
to
fit
that
I'm
not
sure
like.
Maybe
we
can
get
some
inputs
from
other
people
here.
D
Overall,
I
have.
I
have
no
specific
objection
of
having
let's
say:
if
we
have
a
stable
api
that
you
know
each
vendor
wants
to
implement.
I
mean
you
know
sure
it
could
work,
but
then
you
know
down
the
road
I
mean
it
might
get.
You
know
cumbersome
so.
C
No,
I
totally
agree,
but
I
mean
I
think,
part
of
the
I
mean
for
other
people
that
don't
attend
this
rv
meeting.
I
think
you
know.
One
of
the
issues
that
was
coming
up
previously
was
something
like
the
vlan
trunk,
where
the
kernel
basically
rejected
and
said
we
don't
want
this
in
the
code.
So
now
we
have,
you
know
two
different
implementations
of
vlan
trunk
that
aren't
necessarily
common,
but
we
want
to
support
it
in
the
cni.
C
So
I
mean
I
think
our
solution
was
to
to
have
a
common
api
and
then
it
kind
of
potentially
forks
off
to
just
some
vendor
specific
stuff,
since
you
can't
call
to
a
common
kernel
to
implement
it.
So
I
mean
is
something
like
that
going
to
be
rejected
now
in
if
we
move
this
over
to
the
network,
plumbing
working
group
or
is
the
you
know,
the
mission
statement
and
the
governance?
Okay
to
somehow
work
out
a
solution
for
that.
B
I
guess
the
way
that
the
governance
dock
is
written.
Now
I
have
some
verbiage
in
there
that
says
you
know:
hey.
The
maintainers
of
a
given
project
can
work
together
to
iron
out
problems.
B
If
they
can't
come
to
a
consensus,
it
comes
back
to
this
meeting
for
a
vote
to
guide
the
the
direction
of
it.
So
if
like
say
it's
right
now
and
there's
no
way
to
come
to
a
consensus,
it
come
to
the
group
and
maybe
there
would
be
a
proposal
on
how
to
handle
it
to
say:
hey.
We
can't
come
to
a
consensus,
there's
code
here,
that's
not
vendor
neutral,
it's
vendor
specific
and
then
maybe
there's
a
proposal
to
say:
hey.
B
We
have
a
way
to
make
this
extensible
and
then
each
vendor
can
talk
to
this
api,
for
example,
or
here's
a
way
that
we
can.
You
know
change
the
object
oriented
paradigm
of
this,
so
that
we
can
make
two
different
objects
that
you
load
in
the
code
and
each
vendor
can
have
like
their
own
module
that
implements
a
interface
in
the
code
or
whatever,
which
I
guess
is
just
also
another
way
to
say,
api.
B
But
anyways,
I
digress.
That's
the
way
it
would
work
today
now
so.
C
B
Yes
and
well,
I
think
everyone
should
work
towards
the
the
mission
statement.
B
I
think
that
if
you
know
it's
the
there's,
also
language
in
there
about
pull
requests
that
they've
got
to
be
accepted
from
you
know,
diverse
vendors,
then
I
you
know,
I
would
say
that
that
kind
of
implies
a
vendor
neutrality
in
a
way,
so
I
would
say
that,
although,
by
the
same
token,
I
am
not
opposed
at
all
to
adding
language
in
here,
I
try
to
find
the
right
place.
That
says
you
know
in
the
case
where
you
can't
have
a
b
vendor
neutral.
B
You
have
to
work
towards
extensibility
that
allows
a
vendor-specific
implementation
that
doesn't
preclude
you
from
using
another
vendor's
technology
or
methodology.
B
C
D
Yeah,
I
think
it
was
mainly
I
mean
I
mean
the
I
mean
the
concern
here
was
that
some
of
the
render
specific
stuff
would
be
problematic
to
move.
Here
I
mean
specifically,
like
I
mean
I
think
it
should
have
been
more
concern
to
the
intel
folks
right
in
general,
not
mine,
but
yeah,
but
I
raised
it
anyway,
so
so
I'm
guessing
that
like
we
are
giving
it
like
this.
Let's
say
we
are
giving.
D
We
are
leaving
some
leeway
for
the
project
maintainers
to
find
a
compromise
here
right,
that's
what
we
are
saying.
So,
although
the
statement
depicts
and
let's
say
an.
D
Here
you
know,
you
know
the
individual
project
may
like
derive
from
it
as
long
as
they
are
keeping
things
like.
Let's
say,
extensible
like
to
allow
other
implementation
to
satisfy
the
api.
B
B
So
I
appreciate
that
a
lot
but
yeah,
basically
the
languages,
it's
under
the
maintainer
responsibilities
and
the
language
reads:
maintainers
may
meet
and
make
decisions
regarding
a
given
repository.
However,
if
consensus
cannot
be
reached
on
a
given
topic,
maintainers
must
bring
these
topics
to
the
network.
Plumbing
working
group
bi-weekly
meeting
for
discussion
and,
if
necessary,
about
it.
B
C
So
did
we
answer
the
question?
Are
we
gonna
try
to
vote
next
session
or.
B
Nope,
I
that's
what
I
proposed
is
to
have
a
vote
in
the
in
the
next
session.
So
I
will
make
another
pass,
especially
for
just
correctness
in
general,
however,
and
I'll
try
to
add
the
stanza
about
github
organization
ownership
and
what
I'll
try
to
do
is
get
that
done
on
the
earlier
side
of
this
two-week
period
and
give
people
a
chance
to
read
it
over
and
also
what
I'll
do
is
I'll.
B
Send
a
mail
out
to
the
group
saying
last
call
for
comments
we'd
like
to
vote
on
this,
and
also
to
make
sure
to
publicize
that
to
give
people
time
to
make
space
in
their
calendar
if
they
can't
regularly
attend.
A
B
I
think
that
I
think
that's
a
great
a
great
question
and
I
would
it's
such
a
chicken
and
egg
thing
that.
B
But
I
would,
I
would
save
it
to
to
kick
to
get
started
on
the
right
foot.
B
I
say
we
should
vote
under
the
new
under
the
new
paradigm
and
and
what
we
can
do
is,
I
guess
we
just
assume
assume
a
membership
based
on
the
lists
that
we
have
here
and
the
notes
in
the
doc
that
basically
says
that
you
participate,
which
is
only
as
complex
as
adding
your
name
to
the
list
or
having
your
name
anywhere
in
the
notes
and
yeah
and
we'll
go
with
the
you
know,
balanced
organization
paradigm
and
we'll
go
from
there.
B
C
B
Yeah,
so
I
guess
what
we
would
do
when
we
so
say
it's
next
week.
Let's
just
assume
it's
the
same
people
on
the
on
the
call
we
would
just
go
through
and
be
like:
hey
dan
I'll,
just
use
dan
as
an
example
be
like
dan.
Would
you
like
to
vote?
We
have
you
here
as
showing
your
participation
in
the
group.
You
can
vote
on
this
and
then
we'll
we'll
take
it
from
there.
Do
that.
You
know,
member
by
member
and.
B
Yeah,
I
guess
that
that's
probably
good.
I
I
I
guess
also
in
case
there's
yeah
I
mean
it's,
it
is
just
chicken
and
eggs.
A
But
you
know
we
don't
have
to
don't
have
to
discuss
too
much
about
it.
You
know,
even
that
is
better
than
perhaps
our
old
rules,
so
let's
just
go
with
that
as
long
as
everybody's
happy
with
it.
As
long
as
we've
addressed
the
comments
on
the
governance
doc,
you
know
I.
B
Think
we'll
be
okay
cool
and
my
goal
here
is
to
have
a
unanimous
vote.
If
there's
people
who
descend,
I
want
to
make
sure
their
concerns
are
addressed.
That's
that's
my
goal
with
the
document
for.
B
A
All
right
anything
else
in
government's
proposal,
I'd
request
that
everybody
please
read
and
review
that
document,
one
more
time
we've
got
two
weeks
to
do.
It
should
be
plenty
of
time
to
address
any
further
concerns
and
can
vote
on
that
in
two
weeks.
A
All
right,
I
added
the
item
to
the
agenda
about
update
on
device
information
proposal.
I
was
just
looking
for
a
quick
update
there,
since
we
didn't
talk
about
that
last
time,
and
I
don't
want
to
forget
about
it.
Is
there
anybody
on
the
call
who
can
address
that.
C
B
B
C
So
where
this
one
stands
adrian
from
red
hat,
has,
is
the
main
driver
of
this,
and
I
kind
of
help
him
and
support
him.
But
up
to
this
point
he's
been
the
main
one
driving
I
have
recently
pulled
off
of.
I
haven't
pulled
off
my
other
project,
but
I
am
going
to
pull
my
full
attention
on
this
now,
so
I
have
an
update.
C
It
hasn't
been
updated
in
maybe
two
or
three
weeks,
so
nothing
there's
nothing
new
in
the
document,
however,
going
forward,
I
would
like
to
start
getting
this
finalized
and
maybe
in
in
a
two
or
three
meetings
start
to
have
be
ready
for
vote
on,
maybe
spec
changes
and
that
sort
of
thing.
So,
if
there's
people
have
comments
or
have
kind
of
like
not
spending
time
on
it,
but
you
keep
meaning
to.
I
think
now
is
about
the
time
to
start
doing
that,
because
I
would
like
to
move
this
forward
if
possible.
C
I
think
where
we
stand
at
least
the
last
I
remember
is
we're
going
to
try
to
update
the
spec
to
specify
changes
needed
for
the
network
status
field
annotation.
However,
we
were
going
to
have
more
of
a
best
practice
document
describing
how
to
some
of
the
data
that
is
being
passed
around
like
device.
Plugin
should
write
a
file
and
multis
should
be
able
to
read
this
file
and
pull
this
information
and
write
it
into
the
annotation.
C
A
Yeah,
I
think
so.
I
noticed
that
the
current
proposal
does
have
proposed
spec
modifications,
so
that's
a
a
great
start
and
that's
more
or
less
what
we
need
to
look
for
there.
I
think
there's
a
couple
of
comments
on
the
dock
in
that
section.
That
probably
should
be
clarified,
and
everybody
who
is
interested
in
this
should
review
those
modifications
to
make
sure
that
we're
happy
with
them
and
then
we'll
see
what
cleanups
changes
etc
happen.
C
Yes,
that
would
be
awesome
and,
like
I
said
I
apologize,
I
haven't
really
had
a
chance
to
work
on
it,
but
this
is
gonna
get
some
of
my
full
attention.
So
I
would
like
to
you
know
if
there's
bigger
items
like
you
know
like
at
a
higher
level,
this
just
won't
work
or
you
know
this
doesn't
belong
here
then.
Hopefully,
we
could
have
addressed
that
by
now
or
really
soon,
so
that
we
can.
C
F
Okay,
hi
hi
billy:
this
is
perry
from
ericsson.
F
Regarding
this
network
status,
annotations
like
I,
was
also
working
with
adrian
like
for
the
park
development
yeah,
if
you,
if
you
need
any
help
like
I
can
also
pitch
in
in
preparing
any
pull
request
or
testing
any
changes.
C
Okay,
good
good
yeah,
I
thought
adrian
has
said:
you'd
been
working
with
you,
so
that's
that's
great
part
of
what
I
need
to
do
this
week
is
kind
of
catch
up
on
where
adrian
is
on
the
some
of
the
poc
changes
in
in
the
different
projects
and
kind
of
start
building
them
locally.
I've
kind.
C
Right
right,
yeah,
I
think
my
first
passes
to
try
to
get
this
back
into
a
place
where
we
can.
We
can
start
talking
about
votes
and
stuff,
so
that's
really
the
the
next
step.
I
think.
Okay,
okay,
good.
F
G
F
C
Okay,
I
guess
one
of
my
action
items
will
be
to
in
this
section
is
to
add
links
to
those
in
those
forks
to
where
the
updates
are
just
so.
You
know
it's
in
a
common
place,
so
everyone
knows
where
they
could
poke
and
look
at
some
of
the
code.
C
A
Okay,
thanks
over
to
tomo,
then.
E
Yep,
let
me
update
the
multi-network
policy
so
that
this
is
the
previously
we
are
called
about
the
magpul
network
policy,
so
the
so
I
in
the
agenda
doc.
I
also
attach
in
the
new
github
name
so
the
so
currently
this
is
this
network
process
uses
the
ip
table,
so
they
are
not
only
for
the
mac
prompt.
Also,
the
ipv
run
is
also
target,
so
they
I'm
changing
their
repository
name
as
the
multi-network
policy,
and
then
they
are
in
code.
E
There
is
lots
of
the
macbeth
term
is
used,
so
I'm
the
simply
replaced
as
the
most
network
policy
and
then
the
ap
version
is
now
the
b1
beta
one,
and
then
I
hope
that
in
the
future
we
may
add
several
features
and
then
update
this
stuff
and
then
the
so
currently.
This
is
the
kind
of
the
incubation
level
the
product
I
mean
this,
the
try
to
make
it
product,
but
to
the
steel,
the
I
need
the
any
feedback
for
this
stuff.
E
So
if
you
are
interested
in
the
network
policy
for
modus
interface,
please
take
a
look
into
it
and
then
the
try
to
that,
and
then
please
give
me
any
feedback
and
not
only
the
issue
ticket
also
the
I'm
in
the
the
truck
channel
of
the
motor
stuff
and
then
the
also
the
github
contains
the
my
email
address.
So
please
ping
me
anyway.
F
All
right,
thanks
tomorrow,
so
tomorrow,
like
I,
have
a
question
letter
to
this
multi-network
policy
so
like
so
when
we
are
going
to
do
it
via
multus
right
so
like
we
could
have
like
a
different
kind
of
cna
plugins,
maybe
like
we
have
something
like
vlan
or
ovcni.
So
how.
B
F
B
F
E
So,
okay
got
it
so
so
the
so
currently
as
so.
Currently,
I'm
just
targeting
the
as
the
the
more
the
most
generic
the
method
to
fill
it
do
a
pocket
filtering.
I
mean
that
that's
the
ip
tables
and
then
the
and
then
the
using
diabetes,
the
almost
cni
we
I
I
could
saying
that
the
as
long
as
the
interface
is
under
the
linux
kernel
and
that
time
packet
flow
is
intercepted
as
by
the
ip
table
as
the
nf
net
filter
framework.
E
So
that
is
the
current
stuff
and
then,
but
on
the
other
side,
if
the
some
customer,
like
the
telecom
or
the
some
company,
which
requires
the
high
speed
networking
at
that
time,
the
user
may
use
the
non-kernel-based
interface.
I
mean
that
the
dpdk,
with
the
apollo
driver
directory
to
connect
the
physical
nic
over
the
ebpf
or
af
xtp
at
that
time,
the
maybe
that
the
pocket
filtering
must
need
to
be
done
in
the
application
side,
because
iptable
does
not
the
intercept.
E
They
are
processing
so
there
that
is
still
in
the
each
challenges
and
then
the
and
then
the
I'm
as
a
part
of
the
the
community.
E
So
this
should
be
the
bender
neutral
stuff,
so
the
I
so
at
that
time,
I'd
like
to
start
a
discussion
about
the
the
some
the
software
vendor
of
the
dpdk
app,
as
well
as
the
avpf.
F
E
So,
according
to
the
yeah,
so
the
this
con,
this
multi-network
policy
provides
the
the
kubernetes
crd
schemer
and
then
this
is
pretty
same
as
pretty
same
as
the
kubernetes
network
policy,
so
the
so
the
of
course
you
can
use
this
cld
to
use
your
secondary
interface
of
the
open
b
switches,
obs
based
one,
okay,
okay
and
then
yeah.
E
If
the,
if
you
you
you're,
going
to
use
this
stuff,
then
please
let
me
know
I
I
also
add
the
some
the
reference
to
the
readme
file,
all
this
stuff,
okay,
yeah
sure.
Thank
you.
Thank
you
for
your
comments.
No
yeah.
I
appreciate
it.
Yeah.
B
F
E
So
so
the
yeah-
this
should
be
the
the
pretty
interesting
topic
to
discuss,
because
the
so
the
pocket
return
mechanisms
is
depends
on
the
its
framework
right.
I
mean
that
the
ebpf
case
they
need
to
implement
in
the
the
yeah
evpf
the
virtual
machine
code
and
then
the
and
then
another
iptable
based
one
is
should
be.
E
The
different
must
be
different,
as
well
as
the
nf
table,
so
so
the
I'm
I'm
just
thinking
about
the
we
should
they
provide
some
initial,
the
crd
okay,
to
sharing
the
this
cld.
The
schemer
is
used
for
the
network
stuff
and
then
the
the
many
implementation
can
read
via
this,
the
crd
from
the
aqua
next
cluster
and
the
interpret
that
is
there
my
thoughts
so
yeah.
E
Well,
maybe
the
after
the
pod
launched
user
may
create
the
network
policy
okay.
So
at
that
time,
of
course,
the
some
controller
is
watching
to
creation
or
the
changes
of
the
network
policy,
and
then
they
change
it
via
each
the
filtering
inside
the
plot
or
some
stuff.
Somehow
so.
F
E
Evp
side,
the
yeah,
it
depends
on
the
implementation,
but
it's
a
lot
of
challenges.
It
exists
and
then
the
so
currently
the
maybe
that's
the
why
the
kubernetes
upstream
is
just
a
provider
cld
for
network
policy.
E
So
so
so
still
the
this
is
the
controversial
topic.
A
All
right,
if
not
everybody,
please
take
a
look
at
the
governance
proposal
for
one
last
time
with
the
intent
of
voting
on
that
proposal
in
two
weeks
at
the
next
meeting
and
also
address
or
add
any
more
comments
to
the
device
information
proposal
and
also
please
take
a
look
at
tomo's
multi-network
policy
update
and
give
any
feedback
you
have
on
that
thanks
everybody
and
hope
to
see
you
in
two
weeks.