►
From YouTube: Multi-Network community sync for 20230510
Description
Multi-Network community sync for 20230510
A
This
meeting
is
being
recorded,
hello,
everyone
and
welcome
to
the
May
10th
edition
of
the
multi-network
community,
sync
as
a
general
reminder
for
all
these
meetings.
This
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
to
please
be
nice
to
one
another.
So
please
do
be
nice
to
one
another.
A
Raise
your
hand.
If
you
want
to
ask
questions
or
add
something
using
the
zoom
raise
your
hand
feature.
We
do
have
an
attendees
list.
It
is
usually
helpful
for
these
groups
to
know
who's
showing
up
that
helps
to
gauge
interest
and
all
kinds
of
other
things.
So
if
you
wouldn't
mind
adding
yourself
there,
that
would
be
appreciated.
A
I'll
put
the
doc
in
the
chat
as
well,
just
in
case
nobody.
People
can't
get
to
it
fast,
I'm
kind
of
standing
in
for
mache,
who
is
out
I,
think
this
week
and
next
week
and
usually
runs
these
calls.
I
I
think
most
of
you
know
who
I
am,
but
for
those
of
you
who
don't.
A
My
name
is
Shane
I
work
at
Kong
on
kubernetes
networking
I
am
a
Sig
Network
chair
and
a
maintainer
of
Gateway
API
I,
always
I
always
come
to
these
meetings,
but
candidly
I
don't
know
if
I'm
gonna
be
able
to
run
this
very
well
so
so
I'm
gonna
need
some
help.
So
as
I'm
going
I'm
going
to
basically
be
asking
for
volunteers
to
kind
of
help
me
along
the
way
here,
I'll
try
to
drive
a
little
bit.
We
have
agenda
for
today,
only
a
basically
one
thing
and
then
talk
about
the
cap.
A
I
would
definitely
it's
an
open.
Agenda
I
would
definitely
invite
people
to
go
drop
things
into
the
agenda
for
today
for
discussion
yeah.
So
with
that
help
me
out,
but
we'll
start
with
the
first
agenda.
Item:
I,
don't
know
the
name
here,
but
present
Dynamic
resource
allocation
could
be
used
as
API
for
additional
network
interfaces
instead
of
a
pod
go
ahead.
If
you're
here.
B
Unfortunately,
Patrick
is
not
yet
here
and
okay
I
really
I
really
hope
that
it
he
will
be,
and
there
is
another
person
from
the
same
team,
Marquis,
Marcus,
lectin
and
who
is
working
on
qos
cap.
B
A
Think
I
remember
now:
I
I'm
Marquis,
because
I
recently,
cc'd
myself
and
I
have
been
looking
at
this
one.
B
B
So,
at
after
playing
visuals,
we
decided
also
to
add
something
related
to
the
network
to
it,
and
Marcus
was
demonstrated
in
on
Sikh
network
scenario,
when
viscos
classes
can
be
used
as
a
like
to
supply
the
parameters
to
bend
this
plugin
through
a
cni
interfaces.
B
C
B
Of
some
of
functionalities,
what
montus
is
doing
is
potentially
can
be
represented
as
Qs
classes.
Even
though
it's
it's
a
bit
as
I
say,
like
misuse
of
things
well
actually,
I
see
marbles
is
already
digital
in
it.
Yeah
sorry.
B
Ahead,
so
that's
one
like
one
part
of
a
story.
Second
part
of
a
story
is
we
feature
what
my
colleague
Patrick
and
several
other
colleagues
implemented
in
kubernetes,
126
and
127.
It
was
some
improvements
about
it.
Well,
so
what
thing
is
practically
enabling
to
a
more
complicated
users
for
devices
like
all
kinds
of
accelerators?
In
you
know,
kubernetes
kind
of
like
next
generation
of
device,
plugins
and
demonic
resource
allocation
also
is
very
flexible
thinking
and
that's
during
some
of
again
discussion
with
Stephen
Hawking.
B
Here
he
was
saying
what
it's
very
close
to
what
visig
is
trying
to
implement
and
we
came
here
to
discuss
actually
scenarios
if
we
can
cooperate
with
things
because
for
us
like
making
to
a
dynamic
resource
allocation
as
a
pod
level
resource
and
when
passing
down
parameters
to
cni.
B
It's
not
really
a
big
problem,
so
we
can
easily
extend
the
feature
what
we
already
have
and
to
like
to
use
it
as
a
secondary
network
interface.
Potentially.
B
So
we
we
came,
we
came
to
discuss
to
see
where
we
have
a
common
points
and
where
we
can
like
help
each
other,
Patrick
I
see
you
joined
and
Matt
Marcus.
Please
go
ahead.
If
you
want
to
say
something.
A
If
somebody
else
is
capable
of
taking
notes,
so
I
can
drive,
I
would
appreciate
it.
Let
just
let
me
know,
but
yeah
I
was
trying
to
capture
kind
of
the
notes
from
what
you
were
saying
there,
but
it
pretty
much
boiled
down
to
you're
trying
to
find
the
overlap
between
these.
The
thing
that
you're
doing
and
this
and
try
to
find
the
where
these
things
converge
right.
D
Hey
this
is
Doug
I
just
want
to
chime
in
quick
that
I'm
really
happy
that
you're
bringing
this
up,
because
this
is
something
that
I
believe
is
one
really
important
to
this
effort
as
a
whole.
I'm,
pretty
sure
it's
one
of
our
top
use
cases
that
we
stack
ranked
was
for
enabling
you
know,
Hardware
resources
for
like
SRI
LV
or
your
networks
right.
So
this
is
something
that,
as
part
of
network
Plumbing
working
group,
we're
definitely
also
in
consideration
of.
D
However,
I
agree
strongly
that
the
way
that
this
works
with
the
device
plugin
and
using
multis
with
the
net
attached
stuff
method,
there's
it's
more
complicated
than
it
needs
to
be.
D
It's
really
difficult
to
debug
I
think
that
there's
a
lot
of
kind
of
glue
there
that
could
be
organized
so
I'm,
just
really
I
I'm
not
familiar
with
this
quas
resources,
cap,
which
I'll
take
a
look
at
but
yeah
I
think
this
is
really
important
to
the
group
and
I
think
that
it's
something
that
could
definitely
be
better
organized
as
we
move
forward
so
just
wanted
to
say
that
yeah
I
think
it's
important
and
I'm
glad
you
brought
it
up.
That's
it
cool.
C
C
I'm
I'm,
sorry
I,
yes,
I'm
gonna
admit
that
I
couldn't
find
the
raise
hand,
button.
Okay,
no
worries
and
I
will
look
for
it
more
comfortably
next
time,
so
yeah.
So
let
me
let
me
explain
my
perspective
on
this,
so
the
issue
that
I'm
interested
in
is
that
we
say:
have
a
cni
plug-in
setting
a
network
interface,
something
like
that.
That
might
require
a
bunch
of
parameters
that
are
specific
to
this
particular
interface,
or
this
particular
pod
and
I've
been
trying
to
think
about.
Well.
C
How
would
you
pass
that
it
feels
like
this
is
very
much
that
and
you
can
have
some
quas
resource
that
is
opaque
to
kubernetes,
that
you
could
put
some
kind
of
information
in
and
have
a
link
to
it.
Does
that
cover
the
same?
Is
this
answering
that
that
requirement?
Do
people
see
those
as
being
compatible
the
same
thing
or.
E
E
So
with
with
the,
if
you
specify
certain
class
for
this
code,
then
it
will
deliver
some
admin
specified
parameters
to
the
CNR
plugin,
so
I
I,
guess
that's
exactly
the
kind
of
use
case
that
we've
kind
of
demonstrated
there
with
the
Qs
class
work,
Network
integration,
but
then
I,
guess
dra
is
more
like
managing
managing
kind
of
interface
of
devices
and
and
for
more
complicated
use
usage
scenarios
scenarios
with
with
possibly
kind
of
allocating
multiple
interfaces
for
for
put
or
something
like
that,
but
I
I
would
say
this
qos
mechanism
more
more
like
a
passing
yeah
parameters
and
capabilities
into
the
CNR
plugin
questions.
F
E
E
Yeah,
so
it's
it's,
the
qos
is
mechanism
is
what
we're
proposing
is
sort
of
in
a
very
high
level
like
attaching
sort
of
identifiers,
the
pods
and
containers,
and
then
then
the
kind
of
lower
level
knows
what
to
do
with
the
with
with
this
pot
has
been
assigned
to
let's
say,
Network
and
then
class
identifier
fast,
and
then
then.
A
By
the
way,
I
am
taking
notes,
while
also
trying
to
drive
I
may
not
get
things
right.
So
please
do
if
you
see
that
my
note
doesn't
really
reflect
what
you're
trying
to
say
go
change.
My
note
pressure.
You
had
your
hand
up.
First,
go
ahead.
H
Yes,
hi
just
curious,
I
I
haven't
had
a
chance
to
read
through
the
cap
yet,
but
so
is
it
fair
to
say
that
the
way
you're
thinking
about
this
now
is
to
just
ask
for
a
new
type
of
resource
for
the
part
spec
through
the
Pod
spec?
Is
that
the
high
level
summary
and
then
someone
pass
it
to
a
cni,
okay,
yeah.
E
Yeah,
if
you're
well,
if
you
have
time
in
the
I,
have
a
kind
of
short
demo.
I
could
show
at
some
point
if
you
have
time
so
how
it
would
look
like
from
the
user
point
of
view
and
how
it
kind
of
maps
the
CNR
config
and
like
how
it
looks
like
in
practice
the
implementation.
So
that's
might
be
like
a
good
good
way
to.
E
A
H
Then
maybe
let
me
just
ask
my
follow-up
question
so
so
then,
and
and
when
we
say
cross
classes,
are
we
talking
about
like
DHCP
bits
being
set
in
the
packet
somehow
or
are
we
just
talking
about
Q
priorities
like
like?
How
far
are
we
going
here?
I
mean
again,
you
know,
disclaimer
I
haven't
read
through
the
cap,
so.
B
I
will
probably
try
to
answer
what
so
we
webcam
doesn't
actually
specify
what
this
qos
classes
means.
What
what
we
are
trying
to
do
is
to
have
a
universal
way
of
discovering
of
qos
resources
and
when
announcing
it
to
equivalate
and
like
always
like
scheduling,
accounting
quarters
or
always
functionality
what
it
actually
means
it
depends
on
like
from
where
we
are
discovering
those
qos
classes,
so
example,
this
cache
it's
a
configuration
file.
B
What
we
like
runtime
discovers
same
with
block
IO
so
like
runtime,
tells
to
the
kublet
what
we
have
like
block
IO
classes
like
gold,
silver,
bronze
and
something
in
default,
and
what's
it
Google
doesn't
know
anything
about
it?
So
the
same
applies
to
to
the
network,
us,
what
like
how
we
are
Envision
it.
So
we
can
from
cni
configuration
file.
They
can
discover
what
kind
of
POS
classes
are
present
and
what
it
actually
like,
which
parameters
to
which
plugins
it
needs
to
be
set.
B
So
when
we
see
Ni
plugins
will
be
called,
we
will
get
the
vowels
parameters
passed
down,
but
based
on
on
Qs
classes,
which
was
requested
and
what
it
will
be
doing,
like
DHCP
flux
or
whatever
it's
up
to
cni
plugins
to
decide.
Well
what
what
should
be
done,
what
Marcus
have
he
has
an
example
of
Bend
this
plugin
so
like
just
engine
injecting
we're
traveling
parameters,
but
again
it's
up
to
the
bottom
levels
to
decide
what
what
classes
actually
mean.
H
Okay,
I
have
a
few
more
but
we'll
just
you
know:
I'll
wait
for
seeing
everyone
else's.
B
A
Okay,
we'll
try
to
come
back
around
you
Daniel.
Let
us
know
in
the
chat
if
it's
a
problem
go
ahead.
Zappa.
F
I
lost
a
little
bit
as
I
was
a
little
distracted
over
here.
I
lost
track
of
the
conversation.
I
was
trying
to
just
see
if
this
was
potentially
scope.
Creep
from
the
you
know
the
spirit
of
the
multi-network
cap
of
just
defining
the
Pod
Network
resource,
and
then,
where
did
we
leave
off
here?
This
is
where
I
got
confused.
Sorry.
B
It's
part
of
like
the
reason
of
what
confusion
is
me
because,
as
I
mentioned
like
we
have
two
things
what
our
teams
are
developing
like
one
is
the
array
Dynamic
resource
allocation
and
this
one
is
actually
more
related
to
a
multi-network
scenarios
and
qos
cap
is
more
about
like
quality
of
service
or
throttling
parameters.
But
us
one
of
the
feedback
from
Tim
Hawking
is
what
it
can
be
misused
to
implement.
B
Multi-Network
like
like
most
is
doing
right
now,
there's
annotations,
like
Motors,
can
represent
or
something
similar
using
qos
classes.
It's
not
a
major
scenario,
or
it's
not
a
Target
where
we
wanted
to
use,
but
I
just
wanted
to
put
it
on
the
table,
but
like
both
of
those
features,
somehow
overlap
with
what
this
group
is
doing.
F
B
Well,
I'm,
just
speaking,
we
don't
know
what
is
currently
discussed
in
in
the
Sig
and
like
it's
first
time
we
are
joining
this
so
I,
don't
know
answer
to
the
question.
A
Okay
is
somebody
who
was
I
was
trying
to
help
and
stuff
with
a
couple
of
things.
So
I
was
a
little
disconnected
if
somebody
who's
tuned
in
could
put
the
notes
down
for
that
conversation.
So
we
can
capture
that
on
the
dock.
I
would
appreciate
that
Daniel
has.
Did
you
need
to
go?
Did
you
have
more
that
you
wanted
to
say
there
Zappa
yeah.
I
F
Sorry,
nope
I'm,
all
good
Daniel
go
for
it.
Okay,
yeah.
I
Okay,
so
it's
already
almost
in
the
same
line
as
what
Michael
was
saying
is
that
if
we
keep
the
cap
actual
to
multi-network
definitions
and
attachments
the
question
with
qos,
it
would
be
the
same
if
I
want
to
enable,
for
example,
lfrs
or
any
other
kind
of
profile.
I
To
just
be,
should
it
not
be
outside
into
a
different
kind
of
resource
definition
that
you
can
then
assign
to
a
network
or
the
default
network,
but
independent
on
them?
If
it's
multi-network
or
not
so
I
could
have
a
default,
a
new
network
with
no
Pro,
no
specific
parameters,
and
then
I
will
have
another
one.
I
Then
I
can
specify
I
can
now
assign
that
network
profile,
for
example,
which
is
either
qos
or
some
higher
level
and
then
like
make
it
called
low
latency,
and
that's
it
that
that's
why
I'm
kind
of
afraid
of
the
scope
creep
I,
don't
think.
It's
part.
It
was
part
of
the
initial
discussion
for
that
that
current
Gap.
B
I
think
like,
if
you
look
at
the
qos
feature
scenarios
like
something
what
will
select
the
default
Network,
let's
say
like
low
like
low
latency,
Network
or,
let's
say
like
storage
class
network
and
so
on.
So
this
fits
quite
nicely
in
with
semantic
of
Qs
resources.
But
if
you
have
scenarios
where
you
want
to
say,
I
want
a
network
interface
with
villain
XYZ
when
probably
GRE
is
the
better
abstraction
so
practically
like
this
Dynamic
resource
allocation
abstraction
already
present-
and
it's
like
it's
not
hard-coded-
for
something
some
implementation.
I
Yeah,
so
the
question
is,
let's
say:
I
say
to
a
product:
I
say:
I
need
to
have
specific
qos
resource
and
because
of
that
qos
resource,
it's
forced
into
a
network
that
maybe
that's
what
Tim
was
saying,
is
you're
kind
of
bypassing
a
bunch
of
rules
say
well,
you
need
that
Qs
resource,
so
you
need
to
be
attached
to
that
network.
Is
it
in
that
in
that
frame
of
mind.
I
I
B
Why?
No?
No!
It's!
It's!
Not!
No!
It's
not
like
easy,
like
what
so,
okay,
first
of
all,
first
of
all
like
if
we
look
what
what
we
have
currently
have,
you
have
a
move
to
do
with
these
things,
and
you
have
connotations
and
annotation
is
like
Wild
Wild
West
right,
so
everybody
can
use
it
in
case
of
qos
classes.
It's
not
like
wet
so,
first
of
all
like
where
runtime
is
responsible
to
announce
it
to
a
couplet.
B
What
was
added
by
by
one
of
our
feedback
from
where
red,
hot
people,
so
practically
you
can
say,
not
more
than
five
support
accessing
per
node
to
a
fast
Network,
although
latency
network,
if
you
say
and
third
thing,
is
in
proof
of
concept,
what
Marcos
have?
What
is
implementation
about
the
quota
and
default
values?
B
F
B
And
another
thing
about
with
the
array,
so
gear
is
a
bit
different
approach.
So
it's
like
again,
it's
it's
also
quite
a
pack
to
the
kubernetes,
so
kubernetes
doesn't
really
know
what
is
behind
it,
but
the
main
difference
is
what
Dre
driver
is
like
a
vendor
logic
which
handles
the
allocation
and
well
actually
attachment
of
a
particular
device
to
a
container.
So
if,
with
flexibility,
what
we
did
with
qas
is
not
fitting
model
when
probably
like
gear
Ray
provides
more
flexibility
but
for
different
set
of
use
cases
yeah.
J
So
for
things
that
really
are
logic
or
vendor
specific
I
think
the
array
may
be
the
right
solution.
If
you
look
at
the
maltose
API,
which
I
I
bitly
haven't
I,
haven't
done,
the
things
that
it
does
with
annotations
probably
will
be
a
good
fit
for
dra,
where
those
annotations
get
turned
into
fields
in
a
custom,
resource
definition
and
custom
resource
definition
would
be
owned
by
Malta,
so
it
wouldn't
be
standardized
any
any
third-party
vendor
could
Define
its
own
thing
and
dra
will
just
handle
the
logic.
The
integration
into
kubernetes.
A
A
Cool,
thank
you.
Unless
anybody
has
any
more
to
add
on
that,
we
have
Pete
and
then
Prashant
have
their
hands
up.
C
Yeah,
it's
just
a
pretty
quick
thing
in
terms
of
scope,
I
think
what
is
in
scope
here
is
the
API
that
we're
using
that
we're
specifying
for
how
a
pod
indicates
what
networks
it
wants
to
be
on
and
I
think
by
extension,
any
parameters
it
wants
to
pass
to
those
networks,
and
maybe
the
and
I
don't
want
to
get
intimate
implementation
I
think
it's
perfectly
reasonable
to
say:
there's
some
implementation,
we
wash
our
hands
and
we
don't
know
about
that.
But
there
has
to
be
some
way
of
a
pod
passing
some
parameters
and
I.
C
A
No,
that
makes
to
me
personally,
as
somebody
who's
a
little
on
the
outside
of
this,
because
again,
I
am
I'm
here
to
help
facilitate,
but
I
don't
have
a
dog
in
this
hunt
right
now
the
the
idea
that
we
need
to
come
up
with
a
kind
of
a
clear
and
defined
way
to
do.
This
is
something
that
I
think
should
be
a
cat
blocker
if
it
is
not
already
like
to
pass
parameters
specifically
go
ahead.
Prashant
yeah.
H
Yeah
sure,
just
to
follow
up
on
the
last
comment,
I
haven't
kept
up
with
the
evolution
of
the
Gap,
the
don't
we
have
a
params
field
in
the
cap
already
for
any
sort
of
vendor
specific
stuff.
H
G
H
Right,
okay,
so
my
my
question
was
actually
about
so
from
a
networking
perspective.
I
mean
a
course
parameters
for
all
the
non-networking
stuff.
You
know
whatever
block
IO
whatever
it
is
that
we
have
in
mind
keeping
that
aside
and
just
looking
at
the
networking
stuff
I
I
mean
with
multi-network
my
the
way
I'm
seeing
it
is
that
we're
trying
to
give
a,
not
a
Singleton
model
anymore
right
today
there
is
nothing
called
a
smarty
Network,
it's
just
one
network
whatever.
H
If
you
want
to
call
it
the
default
Network,
so
be
it
right
and
with
a
non-singleton
mode
and
networking
cost
parameters,
we
would
need
a
way
to
define
like
which
network
are
we
talking,
I
mean
when
we
say
you
know,
DHCP
or
whatever
it
is
that
is
sort
of
network
specific
cost
configuration.
H
We
need
a
way
to
call
out
which
network
are
we
are
talking
about,
or
are
we
talking
about
because
you
know
each
part
could
have
a
management
Network,
an
airplane,
Network
High
Speed
network,
whatever
you
want
to
call
it
versus
a
pod,
trying
to
say
I
just
need
to
be
able
to
send
I,
don't
know
10
gigs
of
traffic
right,
that's
one
definition
of
the
course
or
whatever
it
is
across
all
networks,
which
seems
a
bit.
You
know
not
fitting
very
clearly
into
well,
then
you
know
which
network?
H
Are
you
really
trying
to
talk
about
like
what
are
you
trying
to
Define
in
those
Network
capabilities?
So
should
this
really
be
something
we
should
consider
in
the
Pod
attachment
or
pod
Network
object,
so
that
we
can
specify
which
network
is
trying
to
provide
what
kind
of
cost
qualities
versus
a
pawn
asking
for
I
just
need
this
course.
Quality
for
my
network
right,
I,
I,
hope,
I'm,
making
some
sort
of
sense
in
that.
A
A
H
B
I
H
H
That's
one
option
that
we
leave
it
to
the
provider
to
say
if
you
know
what
cost
means
you
know
put
some
fields
in
your
object
and
you
can
parse
them
right
and
the
bot
only
says
I
want
to
connect
to
a
you
know:
Network,
a
b
or
c.
The
other
option
is
to
make
it
part
of
the
main
pod
Network
to
say
here
is
here:
are
some
generic
definitions
of
what
causes
right,
dsap
fields
or
some
bandwidth
amount
or
something
of
that
sort?
H
That's
just
from
an
API
perspective.
What
does
semantically
stand
for
if
you
were
to
put
ordered
inside
the
common
part
of
the
part?
Network
object,
I
wouldn't
know,
because
what
does
it
mean
to
kubernetes?
It's
really
more,
a
vendor
specific
thing
or
a
platform.
Specific
thing
right
and
I
always
felt
that
whatever
we
want
to
keep
kubernetes
to
be
aware
of,
and
it's
like
kubernetes
the
general
core
control
plane,
part
of
kubernetes,
you
know
part
controller
deployment,
controller,
etc,
etc.
H
Whatever
they
need
to
be
aware
of
is
what
you
would
keep
in
the
general
part
of
the
spec
and
anything
when
the
specific
platform
specific,
you
would
put
it
in
this
provider
reference
and
there
might
be
some
platform,
so
some
cnis
that
don't
understand,
cause
or
cannot
have
that
capability
or
don't
have
the
capability.
So
you
know,
which
is
why
I'm
leaning
towards
the
provider
reference
having
you
know
up
to
the
vendor
to
decide
whether
they
want
to
support
costs
with
whatever
fields
that
they
have.
C
G
Yeah
I
also
have
the
feeling
I
mean
that
I
think.
If
you
look
today
with
multi-networking,
what
we
are
trying
to
do
is
bring
the
multi-network,
let's
say:
definitions
inside
of
kubernetes,
whereas
the
dra
and
the
Qs
solution,
as
far
as
I
can
I
understand
so
I
haven't
read.
The
cap
is
more
looking
at
the
scheduling
and
how
these
parameters
then
are
taken
into
account.
Well
scheduling
a
pot
to
a
certain
note
and
stuff
like
that.
B
We
already
saw
what
things
related
to
like
how
to
pass
the
parameter.
How
handle
was
scheduling,
how
to
extend
reports
back
to
to
reference
all
of
this
and
how
what
to
do
with
Google
it.
So
this
mechanism,
what
was
implemented
it's
flexible
enough,
so
it
can
be
expanded
not
only
for
like
accelerator
devices,
but
also
for
something
like
pod
Network.
If
you
would
like
I,
can
show
Patrick's
blog
post,
where
you
will
see
where
like
put
yaml
example,
so
you
can
get
by
understanding
a
bit
how
a
parameters
are
passed.
B
What
I'm
saying
about
overall
jira
and
multi-network
use
cases?
What
like
there's
always
high
level
API
things
already
sorted
out
for
the
array
for
us,
it
would
be
quite
easy
to
extend
to
handle
the
network
interfaces
as
well
onward,
like
couplet
and
runtime
side.
If,
if
you
are
interested
in
that,
so
we
can
help
your.
G
Your
cap
moment
that's
my.
My
comment
is
actually
they
are
complementary
in,
as
we
said
so,
I
think
it
would
be
good
to
see
what
you
have
done
for
the
dra
side
and
see
how
we
can
let's
say,
potentially
unite
the
approach
or
reuse.
Some
of
the
components
that
you
have
and
and
I
should
try
to
to
cover
both
cases.
So
I'm
yeah,
I'm,
saying
the
same
thing
as
you.
Let's
have
a
look.
What
the
details
are
that
you
have
implemented,
and
then
we
can
see
how
we
can
converge.
J
If
you
can
base
it
on
the
existing
fields
for
a
pod
re,
a
pod
resource
claim,
then
your
cap
becomes
simpler.
That's
that's
I,
think
that
is
our
point
and
then
what's
what
happens
under
under
the
hood?
With
that
particular
resource
claim,
is
up
to
you.
You
could
have
a
dra
driver
that
doesn't
influence
scheduling
by
always
saying:
okay
well
just
go
ahead
and
then
cubelet
will
do
whatever
you
had
in
mind
for
Port
Network
attachment
when
it
detects
such
a
special
resource
claim.
A
Yeah,
thanks
again
just
continue
to
help
me
with
notes,
if
I,
if
you
feel
like
I've,
messed
up
any
of
these,
but
these
are
great
conversations.
Next,
we
had
tomofumu
Hayashi.
B
A
Sure,
where
is.
K
No
problem,
man,
I'm,
sorry
that
this
may
be
offline.
The
this
is
not
to
related
to
the
multi-network
community
stuff,
but
also
related
to
maltes,
so
yeah.
Tomorrow,
the
we
have
the
American
Community
have
the
maintenance
meeting
and
then,
at
that
time
the
we
are
also
talking
about
the
the
area,
the
implementation
stuff
in
the
amount
of
site.
So
if
someone
is
entered
so
this
is,
of
course
not
related
to
your
matches
this
one
and
that
we
have
more
latest
implementation
of
the
mountains.
K
But
if
someone
is
interested
in
then
please
join
this
call
I'm
putting
in
the
this
meeting
information
in
the
chat
window
just
about
it.
So
tomorrow's
the
9,
30
USD
I,
think.
A
Sorry
give
me
a
minute,
my
stuff
loads,
so
slow,
okay,
so
the
malta
cni
maintainers
are
having
a
meeting
tomorrow,
where
there
may
be
some
relevance
to
the
topics
at
hand.
Here,
I'll,
post,
the
doc
in
here
it's
been
a
while
I
actually
contributed
to
maltes.
Some
years
ago
again,
I
know
I
haven't
had
a
recent
dog
in
this
hunt,
but
thanks
for
jumping
in
here
and
being
involved
in
this
process,
obviously
there's
reason
for
there
to
be
conversations
going
on
between
the
two
groups.
H
Thanks
so
so,
I
mean
one
of
the
goals
as
I
understand
it
from
my
network.
Is
that
make
Network
a
first
class
citizen
in
kubernetes
right
I
mean
we
could
like
Marcus,
and
you
know
other
ways
using
device
plugins.
They
can
already
use
a
resource
request
and
say:
I
want
to
request
this
resource,
which
is
supported
by
some
sort
of
device,
plugin
SRI,
whatever
be
the
case
right,
and
so
what
does?
H
It
really
mean
to
make
it
a
first
class
citizen
like
like
storage,
where
we
have
a
volume
piece,
and
you
know
like
compute.
We
would
like
to
see
this
is
my
understanding
today.
So
please
correct
me:
the
Forum.
If
this
is
not
what
has
been
discussed
lately,
network
has
a
special
meaning
in
the
bot
spec
and
the
meaning
there
is
because
well
we
need
such
a
meaning
there,
or
some
some
semantic.
That's
special
for
the
word
network.
H
That's
assigned
to
a
bot
is
because
there
are
a
bunch
of
native
networking
Concepts
in
kubernetes,
like
Services.
You
know
Gateway
Network
policy
whatnot
that
today
I
assume
that
there
is
only
one
network,
so
I
don't
need
to
specify
which
network
I'm
going
to
talk
about
versus.
Well,
I
want
to
create
a
service
for
the
red
Network
or
the
blue
Network,
or
the
green
Network
right.
H
So
if
we
were
to
generalize
the
concept
of
a
network
as
hey
it's
just
another
resource
for
the
pod,
then
those
services
will
need
to
start
calling
them
out
as
I'm
talking
about
this
resource
versus
the
other
resource
which
really
doesn't
make,
or
maybe
we
I'm
finding
it
hard
to
see
how
it
fits
to
say
that
Service
A
is
for
resource
X
versus
Service.
A
is
for
Network,
X,
right
and
sure.
I
do
see
that
you
know
I
that
there
is
a
the
scheduling
piece.
H
So,
in
the
dra
case,
I
assume
that
there
is
a
mechanism
to
say
well,
this
part
and
this
node
can
provide
this
resource,
therefore
schedule
if
you're
looking
for
this
resource,
I
you're
free
to
schedule
the
spot
on
this
route
right.
So
there
is
the
scheduling,
overlap
and
so,
in
my
mind,
I
feel
that
there
is
an
implementation
piece
that
we
could
reuse.
H
Perhaps,
but
the
API
semantics
I
feel
that
the
goal
was
to
say
the
network
actually
means
something
special
in
the
kubernetes
world
now
and
all
the
networking
stories
that
you
can
find
with
kubernetes
need
to
be
a
bit
more
specific
and
not
assume
that
there
is
only
one
of
these
type
of
resources
that
make
sense.
I'm.
H
A
A
I'll
come
right
back
to
your
point,
but
I
wanted
to
go
back
and
just
kind
of
characterize,
so
the
conversation
has
mostly
been
about.
There
are
a
couple
of
different
thoughts
on
different
ways
to
add
parameters
to
network
interfaces,
because
the
kept
that
we're
working
on
is
ultimately
trying
to
do
exactly
what
Prashant
just
said,
or
at
least
this
is
my
opinion.
Please
stop
me
anytime
if
I'm
mischaracterizing,
anything
but
I
see
it
as
this
we're
trying
to
make
the
network
for
a
pod
kind
of
a
more
we'll
call.
A
It
I'll
just
go
with
first
class
citizen
for
now.
In
addition
to
then
allowing
you
to
have
multiple,
so
one
of
the
things
that
seemed
to
be
a
theme
going
through
this
is
that
the
cap
may
not
be
and
I
have
to
I
am
not
deeply
involved
in
this
cup
again,
because
I,
don't
I'm,
not
working
on
the
implementation
or
anything
right
now.
I'm,
not
I,
don't
have
a
a
a
horse
in
the
race,
but
I.
A
Maybe
the
action
item
that
I'll
propose
is
we
need
to
go
back
to
that
cap
and
say
we
need
to
make
an
emphasis
on
network
having
special
meaning,
and
then
we
also
need
to
make
an
emphasis
on
having
a
very
good
plugable
kind
of
generic
way
to
plug
in
parameters
and
different
network
specifications.
Generic
ones
as
well
as
kind
of
implementation,
specific
ones
for
these
network
interfaces.
Does
that
sound
right?
G
But
I
think
Russian
said
it
as
well.
Right
I
mean
the
the
fact
that
the
implementation
under
the
hood
would
be
reusable
right.
So
there
is
I
agree.
It
was
counted
to
the
representation
of
the
network
is
is
important
right
because
otherwise,
if
you
have
like
a
genetic
construct,
it's
hard,
but
it
doesn't
mean
that
the
implementation
that
sits
on
the
meat
that
interact
with
the
public
and
stuff
like
that,
we
could
use
some
of
the
array
stuff.
That's
what
I
was
trying
to
say
before
as
well.
J
Yeah
I
think,
if
you
don't
invert
cap,
you
definitely
need
to
explain
whether
you
want
this
port
Network
attachments
field
or
whether
you
can
reuse
the
existing
field
for
resource
claims.
Because
if
you
don't
explain
that
in
the
cap,
you
will
get
a
position
from
Tim,
Hawkins
and
Antonio
from
seek
networking,
because
they
are
aware
of
the
array
and
they
strongly
suggested
that
we
should
talk
to
you
guys
about
this
and
not
add
another
New
Field
to
the
Pod
spec.
J
A
Yeah
so
you're
just
I
may
have
because
I
was
typing
and
my
mind
was
a
little
lost
you're,
basically
just
putting
an
emphasis
on
you
know
we're
going
to
need
to
not
do
try
to
push
jump
jam
this
into
the
Pod
spec.
We
need
to
do
this
as
some
kind
of
like
I.
J
A
Yeah
as
I'm
digging
deeper
into
this
and
I
think
I'd
be
interested
to
hear
Zappa's
perform
frame
reference
too,
because
we're
both
leads
it's
it
makes
what
you
said
makes
perfect
sense
to
me.
We
would
like
to
avoid
jamming
all
this
stuff
into
core,
because
if
we
do
that,
it'll
be
there
forever
and
like
and.
A
A
J
A
So
I'll
try
to
incorporate
your
point
into
my
I
think
I'm
going
to
take
this
action
unless
somebody
else
is
dying
to
I
would
love
to
have
somebody
else
take
the
section,
but
my
intention
was
to
take
this
action
and
I
would
incorporate
your
extra
point
about.
We
need
to
do
this
in
some
way
that
doesn't
make
us
have
to
live
with
it
forever
as
part
of
core,
if
possible,
so
I
didn't
see
the
order
in
which
the
hands
went
up.
So
please
do
just
if
you
were
first
go
ahead.
H
I
think
Patrick
maybe
was
first
on
this
Patrick.
Have
you
ever
come
in
okay?
H
So
so
the
first
statement
and
the
again
you
know
the
question
is
like
well:
why
does
it
need
to
be
a
first
process?
Why
does
it
need
to
have
a
special
semantic
I
mean
in
theory.
We
could
have
everything
else
like
storage
CPU
is
a
resource
network,
is
a
resource,
etc,
etc,
and
if
kubernetes
again,
this
is
my
viewpoint.
Kubernetes
did
not
care
about.
A
H
Of
these
natively
and
says,
okay,
everything
is
a
plug-in
model
based
on
the
resource
or
the
source
type.
You
could
trigger
some
plugin
somewhere
import
component
area
right
that
says,
go
deal
with
this
type
of
resources,
the
storage
or
CPU,
but.
H
It
is
not
the
case.
I
mean
I
thought
the
API,
provided
this
was
to
make
things,
make
commonly
used
things
a
bit
easier
to
use.
We
know
that
every
part
needs
a
compute
needs
storage
and
we
also
know
it.
H
H
Why
should
networking
be
a
first
class
or
really
call
out
as
a
first
class
thing
and
I'm,
making
I'm
trying
to
make
my
point
here
to
say
that
hey
it's,
because
it
is
a
core
thing
that
is
needed
for
a
part
to
run
right,
unlike
the
other
ones
that
are
sort
of
optional
and
because
it
is
a
core
thing
and
because
we
want
to
make
core
things
to
be
easily
manageable.
We
came
up
with
these
kubernetes
I
assume.
This
is
sort
of
me
extrapolating
why
we
landed
up
here.
H
We
came
up
with
this
kubernetes
networking.
You
know
Concepts
like
services
and
whatnot,
because
we
know
that
that's
how
they're,
probably
going
to
customers
are
probably
going
to
use
pods
in
a
kubernetes
cluster
right
and
we
want
to
make
it
easier
for
them
to
use
it
so
that
you
know
adoption
written
what
not
so
again,
I
think
the
high
level
point
that
hey.
We
need
to
be
more
clear
about.
Why
should
this
be
a
first
class
citizen,
sure
I
think
I'm?
H
A
I
have
some
questions
and
maybe
some
confusion,
but
I'll
go
second,
because
Pete
put
his
hand
up
first
go
ahead.
Pete.
C
Yes
and
we
are
running
low
on
time.
Let's
keep
that
up
sure
this
is
a
very
short
but
maybe
important
technical
point.
The
the
dra
stuff
for
here
is
a
custom
resource.
Here's
some
stuff
I
need
and
then
that
can
do
some
magic,
whatever
that
magic
might
be,
that
we
don't
have
to
worry
about.
That
is
great,
except
that
it
is
not
pair
interface
and
some
of
what
we
want
here
is
going
to
be
pair
interface,
and
so
that
might
change
things
now.
C
Maybe
we
can
work
our
way
around
that
annotation
somewhere
or
something
like
that.
I
don't
know,
but
it
feels
like
that's
a
difference
in
what
we're
doing
here,
because,
apart
from
multiple
interfaces,
and
they
will
have
different
resource
claims
for
them,
so
we
need
some
way
of
figuring
that
out
and
that's
me.
A
Okay
and
we're
just
about
at
time,
I'll
try
to
keep
mine
short,
but
basically
I'm,
seeing
both
prashanths
and
Patrick
Ollie's
viewpoints
as
compatible,
but
I
might
have
missed
something
so
push
jump.
It
sounded
like
if
I
got
this
right,
you're
kind
of
like
you
were,
you
were
thinking.
We
need
to
have
more
of
this
stuff,
be
core
did
I
get.
That
was
that
what
I
was
getting
it
right?
A
How
implementations
and
users
ultimately
do
all
these
things,
but
personally
I
also
agree
I,
so
I
agree
with
that
that
it
needs
to
be
like
an
emphasis,
but
I
also
agree
with
Patrick's
Point
that,
ideally,
we
are
not
jamming
it
into
core
if
there's
a
good
way
not
to,
and
my
reasoning
for
that
again
comes
from
kind
of
wearing
my
chair
hat,
the
less
we
can
put
in
core
is
ultimately
going
to
be
the
better
because
we've
we've
been
burned
by
like
putting
things
in
core.
A
Just
look
at
the
service
API
like
just
like
this
is
just
it
can
be
a
a
a
a
big
problem
to
put
things
in
court
at
the
time.
We
think
is
something
that
everything
should
be
doing.
We've
had
a
better
experience
so
far
with
doing
things
as
I'll
call
it.
Satellite
like
with
Gateway
API,
we
made
a
very
explicit
Choice.
The
Gateway
API
would
be
a
a
core.
It
would
be
like
a
core
kubernetes
API
and
that
it's
kind
of
hey
this
is
a
kubernetes
API.
A
A
I
I
I
personally
kind
of
lean
towards
modular
for
this,
but
I
would
very
much
invite
you
to
kind
of
make
more
of
a
case
for
your
point.
I
just
don't
know
if
I'm
getting
it
yet
does
that
make
sense.
H
Sure
yeah
we
can,
you
know
we
can
again
Machi
and
I
have
been.
You
know
looking
at
this
for
a
while
and
I'm
just
stepping
in
for
him,
while
he's
out,
but
I
will
give
this
feedback
to
Machi,
and
you
know
we
can
totally
make
more
of
a
case
as
to
why
we
feel
making
in
the
core
make
sense.
Now
again,
this
is
coming
from.
Perhaps
an
implementation
reality
perspective
more
than
we
need
to
do
this.
H
If
you
want
to
achieve
the
kind
of
outcome
we're
trying
to
achieve
with
multi-network,
we
feel
that
from
what
we
have
seen,
what
we've
discussed
and
what
so
far
Machi
and
myself,
we
probably
need
it
in
core.
Maybe
there's
a
way
around
it,
and
if
there
is
one
we're
more
than
happy
to
do
that,
but
you
know
it
feels
like
okay,
I,
don't
think,
there's
a
way
around
us,
that's
that's
where
we're
Landing.
Hence
the
question.
A
Yeah,
okay,
so
I'm
gonna
put.
We
are
at
time
or
we've
got
one
minute,
so
we
do
got
to
wrap
it
up.
I'm
gonna
go
ahead
with
the
action
of
like
starting
to
make
some
of
these
points
in
the
cap.
Please
be
on
the
lookout
for
my
comments
so
that
you
can
join
in
and
like
talk
to
your
friend
and,
like
basically
argue
with
me
in
there
and
we'll
have
the
conversation
because
I
think
it's
a
good
conversation
to
have,
but
yeah
that'll
be
my
follow-up
to
take
that
action.
A
So
we
I
think
we're
good
we're
at
time.
Please
check
out
the
cap
and
some
of
the
updates
that
should
be
inbound
for
review
and
stuff
like
that.
A
F
H
Before
everyone
drops
off
quick
comment,
did
we
bring
up
the
recent
announcement
about
Network
function,
optimizers
and
whatnot
from
Google?
That
could
give
more
context
about
my
networking.
Multi
networking
is
a
big
piece
in
there.
I
don't
know
if
this
is.
These
are
things
that
typically
get
discussed
in
this
forum.