►
From YouTube: Kubernetes SIG Network 20170427
Description
Kubernetes SIG Network Meeting April 27th, 2017
A
And
things
that
depend
on
kubernetes
and
depend
on
the
release
kind
of
be
present
in
the
external
dependencies
tab.
So
when
we
go
towards
release
and
go
towards
code
freeze,
we
can
kind
of
make
sure
that
everything
works
and
if
it
doesn't
work
who
to
contact
and
so
forth,
so
I
think
the
best
way
to
do
this
is
I'll,
send
us
out
on
cig
network
and
then
solicit
responses
via
email,
and
then
we
can
go
from
there.
Okay,.
C
D
C
B
Okay,
multi
networking
so
obviously
Georgie
intended
document
out
there
for
a
while.
That's
gotten
a
ton
of
review
in
questions
Tim
took
a
look
at
that
the
other
day
and
dumped
a
bunch
of
questions
in
as
well,
and
there's
been
some
conversation
going
back
and
forth
on
those
things
Tim
at
this
point.
What
and
maybe
joking
what
do
you
guys
hear
the
mean
outstanding
issues:
I
could--but,
attica,.
E
Heather's
yeah,
you
still
list
of
six
issue
that
I
sized
based
on
the
comments,
so
I
didn't
get
but
I
think
just
first
issues
about
our
laughing
IDs,
so
I
think.
Without
that
thing,
services
is
not
be
able
to
allow
or
laughing
Ivy,
because
it
will
it
will
certain
Iranian
behavior,
which
services,
because
we
could
have
service.
In
addition,
it
would
return
point
clicking
a
different
network
and
a
client
trying
to
access
it.
They
get
in.
E
It
will
get
magical,
come
from
ideas
in
all
11
ability
to
placate
IV,
and
it
could
end
up
going
to
the
wrong
racket.
So
there
are
issues
there
that
that's
not
addressed
at
this
point
so
consider
our
plan
to
keep
the
visitor
business,
but
for
now
I
think
we
have
it
a
the
Standard
Oil
is
not
allowed
I.
Think.
F
You
know
we
talked
a
little
bit
at
docker
con,
but
I
get
the
sense
that
other
people
have
very
different
goals
for
this,
and
as
such,
we
can
quibble
about
the
details
of
the
dock.
You
know
all
day,
but
I'm
not
sure
that
we're
going
to
get
anywhere
because
I
think
we're
all
speaking
in
different
languages.
F
B
Just
kidding
I
was
going
to
send
a
response,
but
I
didn't
have
too
many.
Besides
your
original
forward,
Tim
I
thought
I
was
for
work
more
or
less
valid
for
us.
Okay,
all
four
were
valid.
Well,
some
of
those
we
are
interested
in
Groban
shift,
some
of
them.
We
aren't
necessarily
going
to
pursue
at
this
time,
but
I
was.
F
B
G
Tim
Michael,
Payne
and
I
know
I
work
for
a
big
enterprise,
most
of
or
some
of
you
know
who
that
is,
you
know
as
we
discuss
the
dokkan
I
I,
don't
think
we
would
want
to
use
multiple
network
in
our
clan
tomorrow.
So
but
we've
made
a
conscious
choice
to
try
and
create
a
new
environment
following
sort
of
more
cloud
native
principles.
We
don't
want
to
get
into
different
interfaces
for
different
networks.
G
B
I
guess
I'd
point
out
here
that
I
have
never
necessarily
thought
of
multi
network
as
restricted
to
subnets,
and
that
kind
of
thing
necessarily
to
me.
It's
always
seemed
like
a
little
bit
above
that
more
of
a
logical
split
that
could
be
implemented
via
subnetting
or
could
be
implemented
via
filtering
or
that
kind
of
thing
I
guess
I've,
never
thought
of
it,
as
you
know,
specifically
in
the
way
that
you
were
talking
about
it.
E
F
H
Right
is
yeah;
this
is
this
is
Chris
yeah,
I
know.
If
you
wanted
to
do
you
know,
I
can
do
agree
through
Tim
in
the
heads
being
talked
about.
If
he
wanted
to
do
multi
network
as
policy,
you
know
it
and
render
that
as
policy
as
something
you
could
do
today.
So
to
me
this
seems
like
it's
much
more
about
you
know,
creating
extra
spigot
and
and
separating
those
in
classful
networking
terms
and
that's
where
I
sort
of
have
some
of
those
same
concerns.
Other
people
have
here
so.
I
I
Okay
for
my
corner
of
IBM
I
decide
whether
I
want
to
answer
in
terms
of
Tim's
number
three
or
number
four
I
don't
want
to
ask
too
much,
of
course,
I'm
thinking.
We
can
probably
live
with
number
three,
but
yeah
I
totally
agree.
We
need
to
be.
You
know,
agreeing
in
high
level
timber
we're
talking
about,
and
so
I
answered
his
question
in
terms
of
sort
of
user
facing
functionality.
I
want
to
look
at.
You
know
we're
talking
about
making
a
multi-tenant
cloud.
K
Think
the
only
valid
use
case
is
you
right
now
is
use
gate
number
one
I
could
probably
live
verse
3.
But
to
me
it's
not
good
enough
to
use
case
to
introduce
all
of
this
complexity.
Given
the
talk
that
we
had
on
a
proposal,
it
adds
a
ton
of
complexity,
the
user,
it
doesn't
fill,
doesn't
simplify
things
and
to
me
it
loses
a
lot
of
the
benefit
benefits
that
we
upgrade
it.
It's
a
simple
community
model.
L
F
F
Is
this
is
the
the
taxonomy
that
I
was
thinking?
I
was
right.
Number
three
years
sort
of
I
was
thinking
as
the
eighth
tenant
network.
So
say
your
your
coke
and
you
get
a
coke
network
and
all
of
your
coke
stuff
shares
the
coke
network
and
that's
it
and
number
four.
It
is
I'm.
Coke
and
I
want
to
create
a
fubar
Network
and
a
bar/bat
network
and
a
quacks,
Network
and
I
can
then
go
to
do
those
things
as
an
application-level
construct.
That's
the
different
vessel,
I.
B
Need
to
perhaps
make
a
distinction
between
networks
that
do
you
need
to
be
exposed
to
communities
and
networks
that
don't,
for
example,
thinking
of
a
storage
network
case
on
the
storage
network
case.
It
seems
very
unlikely
that
you
would
care
about
having
services
on
that
network
or
that
kubernetes
really
need
to
know
that
much
repair
that
much
about
getting
packets
into
that
Network
I.
Just
wonder
if
that
kind
of
distinction
being
the
one
to
make
or
not.
Yes,.
E
E
N
When
probably
most
of
those
requirements
could
be
met
today
with
the
existing
API
so
and
I
don't
claim
they
all
can
because
I'm
dead,
don't
you
understand
the
minor
but
I
know
they're,
always
a
business.
Multiple
people
have
done
a
CNI
plug-in
that
can
call
on
to
other
see
in
my
plugins
and
connect
multiple
interfaces
to
a
containing
about
even
a
keys
knowing
about
it
and
the
only
concern
I've
had
with
those
is
well.
They
don't
know
which
networks
they're
supposed
to
attach.
N
Well,
you
could
just
use
an
annotation
on
the
pod
and
then
and
then
you're
done
and
you've
met
that
that
use
case
that
you
might
have
for
say
some
pods
need
Fri
every
and
who
they
want
to
give
them
to
everything.
Yeah.
You
know
in
a
way
that
allows
people
really
care
about
that
too,
to
leverage
those
there's
more
niche
hoodies
but
doesn't
create
general
t29
for
the
kind
of
95%
consumer.
The
cumulative
use
so.
M
F
All
right,
I
think
that's
actually
what
a
big
distinction-
and
this
is
the
part
that
I
think
it's
just
really
unclear
what
people
want
right
now,
so
very
concretely,
right
having
tenant
networks.
Might
what
I
call
number
three.
He
is
much
more
akin
to
what
AWS
does
or
what
GCP
does
with
you
get
a
whole
virtual
network
with
your
whole
space
and
it's
yours
to
subdivide
and
and
if
you
want
to
traverse
outside
of
your
network.
That's
a
special
thing
and
you
go
the
other
extreme
and
like
docker,
with
docker,
with
live
network.
F
Lets
you
and
sort
of
it
encourages
application,
specific
networks
where
the
application
developer
specifies
the
driver,
burr
and
the
connectivity
between
the
networks
and
services
map
into
which
networks
they're
present
in,
and
that
is
reflected
in
your
dns.
And
it's
reflected
in
your
routing
and
it's
reflected
in
your
number
of
interfaces
and
it's
an
incredibly
complicated
thing.
It's
very
powerful,
but
it's
incredibly
complicated
and
I'm.
That's
the
part
that
I'm
really
scared
about
yeah.
M
Right
and
that's
within
a
tenant.
So
in
that
in
in
that
sense,
but
that
does
not
necessarily
mean
that
a
single
pub
would
be
attached
to
more
than
one
again.
That
may
or
may
not
be
the
case.
We
have
an
address
that,
but
that
clearly
clearly
spelled
case
was
that
within
a
tenant
that
may
be
different
pods,
that
we
are
especially
a
special
lamentation
they're
attached
to
custom
networks,
which,
if
that
implies
the
inner
tenant,
there
will
be
multiple
networks
with
different
characteristics
at
the
abstract.
That
we'll.
L
M
Back
to
you
on
that,
but
to
complete
another
completed
example
was
that
there
might
be
application
that
we
need
to
connect
to
Oracle
racks.
That
is
space
which
is
outside
the
specific
the
network
when
this
universe,
and
that
has
a
logistics
unmapped
attached
to
what
that
that's
routed
to
left
auricle,
run
with
in
ways
that
we
may
or
may
not
know,
Oh.
H
G
Again
is
looking
circular,
so
just
just
to
explain
exactly
how
we're
doing
that
in
our
financial
services
organization.
So
we
wouldn't
put
that
stuff
in
the
same
subnet
fact.
We
want
them
a
different
subnets
and
different
networks,
but
the
way
we
handle
that
is
through
some
sort
of
external
dependency
broker,
which
is
essentially
a
permission
to
proxy.
That
allows
secure
things
running
in
the
context
of
say,
a
Cuban,
Eddy's
environment
or
a
Mesa
or
some
sort
of
container
environment
and
then
have
to
be
permission
through
that
external
dependency
service.
H
Yeah
I
think
there's
multiple
ways:
I've
seen
people
solve
that
solution
met
that
that
requirement
other
ways
as
well,
and
those
are
mechanisms
that
are
available.
As
Alex
said
earlier
in
the
existing
API
I.
Just
I
really
don't
want
to
see
us
drop
a
whole
bunch
of
complexity
in
here
to
handle.
You
know,
use
cases
that
we
can
solve
other
ways
and
that
over
time
will
probably
be
deprecated
anyway.
You
know
the
assumption
that
a
specific
IP
address
has
long
lived,
meaning
in
this
world
is
hopefully
rapidly
coming
to
a
close.
H
I
He
already
say
he
doesn't
need
the
you
know
the
the
containers
to
be
on
the
same.
Subnet
is
Oracle
RAC.
So
we're
already
not
talking
that's
already
out
of
the
discussion
right.
He
doesn't
need
the
Oracle
RAC
that
he
doesn't
need
separate
network
interfaces
or
attachments
to
restore
back.
He
just
need
to
have
some
IP
connectivity
and
his
firewall.
So
right.
O
From
Intel's
I
already
commented
by
yeah,
so
I
already
commented
one
of
the
recommends
we
had
that
we
have
a
container
a
spinner
fan.
So
we
need
this
V
enough
application
to
getting
in
to
containers
in
apart
and
each
word
request
a
different
network.
One
is
like
a
sort
of
E
Network
which
and
another
one
is
D
and
they
are
playing
like
a
duplicate
or
something
and
the
another
one
is
some
management
in
which
we
can
use
overlay
Network
like
final
B
or
any
network.
O
So
this
is
what
other
requirements
we
have
a
part
which
have
like
two
or
three
containers
which
are
which
should
be
connected
to
three
different
networks.
For
example,
I
be
used
as
avi
has
one
of
the
physical
network
for
the
control
plane
so
that
we
can
able
to
send
the
priority
traffic
says
in
s
or
IV
and
50k
packages
in
data
plane.
So
this
is
one
of
the
recommence
we
are
pushing
forward
for
multiple
network,
so.
O
B
B
O
O
We
already
are
chewing
it
using
the
node
future
discovery,
so
in
notes
feature
discovery.
We
already
have
their
sort
of
a
so
it
we
already
find
which
notice
has
SOE
and
that's
it's
not
a
problem
for
us
actually,
okay
and
the
problem
really
what
we
were
facing
currently
is
we
already
achieved
what
I
explained
that
using
multics,
CNI
and
I
sort
of
a
CNA
and
DD
KCNA,
which
we
developed
ourselves,
but
the
problem
which
we
facing
with
kubernetes
right.
We
can't
expose
these
network
access.
O
Services
for
kubernetes
is
just
to
know
only
one
network,
for
example.
If
if
we,
if
we
use
multics
CNI
it
just
written
one
IP
address,
so
it
just
knows
only
one
services,
for
example.
It
just
know
final,
so
I
can
run
only
one
services
over
that
if
I
want
to
run
s
or
IV
services
network
service,
that
I
can't
do
it
in
current
kubernetes
thing
like
it
supports
only
once
of
network
services,
because
you
have
only
one
cluster
IP
address
and
it's
never
going
to
support
multiple
services
actually
so
again,.
N
F
Think
the
answer
unfortunately,
right
now
to
this
question
is
yes,
the
answer
is
yes,
we're
discussing
all
of
those
things.
Yeah
I
want
to
point
out
something.
You
know
I
mean
I
hate
to
fall
back
on
this
old
folk,
but
the
way
that
Google
works.
We
don't
have
a
single
horn
cluster
that
handles
all
of
our
work
and
we
do
have
needs
for
segregated
work,
for
reasons
like
regulation
or
for
reasons
like
extra
high
security
and
in
those
cases
we
have
separate
clusters
for
those
things.
E
E
B
E
B
I
mean
I
feel
like
that.
That
is
the
core
of
the
issue
that
we're
all
talking
about
is.
Yes,
we
can
do
all
these
things.
We
can
hack
all
these
things
into
our
single
T
and
I
plug-in,
but
how
much
of
this
do
we
want
to
make
available
through
a
cube
API
and
make
available
through
whatever
management
is
built
on
top
of
cube
control
and
all
the
other?
You
know,
applications
that
talk
to
the
API
servers
right.
I
So
on
that
topic,
let
me
ask
a
question
for
the
network
function.
Virtualization
use
case.
Is
that
really
a
matter
of
you're
trying
to
influence
some
network
plumbing
depths
really
below
the
level
of
saving
kubernetes
services?
Or
do
you
actually
need
to
be
able
to
reflect
that
network
functionality
as
kubernetes
services.
O
I
Next
question
that
is
going
to
be:
do
you
need
to
reflect
all
sides
of
it
as
if
you're,
in
a
service
or
is
it
for
example?
I?
You
know
if
you've
got
say
a
filtering
function?
Do
you
need
to
only
reflect
one
side
of
it
as
a
service,
and
so
you
can
get
away
with
you
know
telling
carré's
about
only
one
side
of
it.
O
I
We're
talking
about
you
want
to
implement
some.
You
want
virtual
network
virtualization,
they
want
where
it
is
multiple
network
connection.
If
this
pod
implement
a
kubernetes
service
on
multiple
of
those
connections,
or
does
it
only
one
of
those
need
to
be
elected
as
an
endpoint
or
endpoints
in
community
services,
so.
O
K
K
O
L
H
H
Large
multi
pendent
components
that
this
replicated
basically
service
provider,
kit,
I
I'm,
not
even
convinced
that
that's
the
right
way
to
offer
an
NF
e
type
of
service
in
a
new
cloud
native
kind
of
environment.
You
know,
if
you
have
a
micro
services
environment,
is
that
even
the
right
way
of
doing
it,
so
you
know,
are
we
wrapping
ourselves
around
an
axle
to
try
and
bring
over
a
model
where
that
model
may
not
even
be
the
appropriate
approach
to
take
in
the
containerized
world?
If
you
wanted,
he
keep
that
model.
H
H
B
That
far
with
it,
I
think,
there's
still
a
lot
of
applicability
of
the
stuff
that
communities
has
to
offer
to
some
of
those
use
cases.
But
a
lot
of
those
use
cases
about
basically
not
micro-service
use
cases.
They
would
depend
more
on
the
scheduling
on
the
orchestration
and
the
container
management
parts
of
community,
as
opposed
to
ingress
micro
services.
That
kinda
agreed.
H
But
I
guess
it's
just
it's
even
a
question
of
you
know
how
much
do
we
want
to
you
know
how
much
do
we
want
to
Alex
complex'?
Do
you
want
to
add
four
things
that
you
might
decide
might
be
doable?
You
might
be
doable
part
efficiently
in
some
other
model
in
a
given
Eddie's
world.
But
you
know
it's
a
point,
I'm
not
saying
it's.
We
shouldn't
do
it
because
that
it's
something
to
think
about
those
work
and
we're
very
far
because.
K
K
I
Well,
I
want
to
page
nine
and
yeah.
It's
just
redrawing
a
VM
oriented
picture
without
explaining
why
you
need
it
speak
so
I
think
what
Tim
was
asking
for
is:
what's
the
actual
concrete
example,
while
you
need
it
for
the
rest,
I'm
not
quite
sure,
I
understand
the
point
of
view
here.
I
mean,
if
you
want
to
say
cobranet
is,
is
only
good
for
implementing
micro
services.
You
can
say
that,
but
I
don't
believe
it
I.
Don't
think
uber
des
even
believes
it
right.
I
H
O
O
Ahead
but
I
think
we
have
already
Evan,
but
I
already
ate
solutions.
Actually,
so
it's
not
like
it's
not
that
header
is
not
there,
so
it
the
the
customers
or
the
technology
is
not
that
improved
that
you
can
put
the
again
of
whichever
they're
in
a
VM
to
a
container.
People
are
already
trying
it.
So
it's
not
that
it's
not
that
or
it's
like
abstract
or
the
people
are
already
trying
hang
out.
That's
why
they
are
putting
it
there
I
agree.
I
Actually,
I
kind
of
support.
What
you're
saying
I'm
just
saying
to
really
make
your
argument:
it's
not
enough
to
draw
a
blank
picture
with
you
know
nothing,
but
you
know
V
ends
and
networks.
We
have
to
talk
about
a
more
concrete
example
and
I
think
once
we
should
talk
about
some
we'll
see
the
knee.
So
let's
do
about
it.
Okay
just
propose
a
particular
network
function.
Let's
talk
about
whether
there's
a
more
cloud
native
way
to
do
it.
Yeah.
N
D
N
N
Isolation
right
and
then,
when
you
explained
this,
nothing
magical
about
those
bits
in
the
packet
not
with
a
VLAN
ID
rather
than
the
IP
address
people
started
to
drop
that
then
we're
able
to
move
to
simpler
and
more
flexible
models
that
were
more
compatible
with
the
general
direction
their
cabinet
is
going
on
and
at
the
moment
I
don't
feel
like.
I
grok,
where
these
requirements
are
coming
from
well
enough
to
be
able
to
to
really
kind
of
spot
those
links
and
suggest
where
there
might
be
simplifications
so
and.
M
That
does
only
do
that
I'm,
again
I'm,
sorry
to
bring
in
a
wishy-washy
somewhere
in
the
middle,
but
I
think
pushing
back
on
just
just
a
fork,
lifting
stuff
in
the
VM
and
dropping
you.
Wouldn't
this
and
expecting
yes
make
an
implementation
elegant,
it's
the
wrong
thing
to
do
and
which
is
absolutely
push
back
on
that,
on
the
other
hand,
I
think
we're
all
in
agreement
that
once
we
boil
down
to
something
that
to
som
something
that
we
all
agree
that
that's
lacking
that
cannot
be
done
already,
can
be
done.
M
It's
too
cumbersome
to
be
done.
What,
with
what
we
have
today,
that's
something
we
should
consider
I
think
we
should
be
somewhere
in
the
middle
very
completely.
It's
plus
one
the
requirements
to
have
this
far
more
sort
through
in
terms
of
what
exactly
it's
missing,
what
it's
very
cumbersome
to
do.
What
we
have
today,
rather
than
for
placing
a
diagram
and
dropping
in
here,
is.
B
M
So
then,
just
+1
on
that!
That's
exactly
getting
to
the
earlier
comments
just
splitting
this
into
little
interfaces
that
pop
per
pod,
this
multiple
networks,
pertinent
for
example,
or
whatever
just
zooming
out
one
of
those
cases
and
agreeing
on
one
or
two
of
them,
would
be
much
more
useful
otherwise
than
just
throwing
everything
in
the
bucket,
because
we'll
be
ending
up
moving
in
circles,
yeah.
B
One
of
the
things
I'm
thinking
of
here
is
with
the
small,
discrete
Network.
These
case
you
know,
is
there
a
way
that
we
could
implement
it,
a
way
that
we
can
reduce
the
scope
of
the
specs
on
what
skips
services
say
that
for
now,
every
pod
has
to
be
on
a
default
network
and
the
services
will
only
work
on
that
default
Network,
which
is
essentially
how
kubernetes
way
it
works
now.
But
then
you
can
add
these
other
networks
Peapod,
if
you
want
for
the
storage
case
or
whatever
other
case
and.
B
K
Not
understanding
why
we
need
any
of
the
complexity
at
all
big.
If
we
ask
something
small
in
then,
it
makes
sense
to
add
the
next
small
chunk
at
the
next
small
chunk
when
we
obviously
are
not
good,
like
OpenStack
Neutron.
No,
that's
not
us
whether
I'm
showing
the
wire,
so
it
repeated
the
mistakes
that
have
been
done
in
neutral
and
just
a
lots
of
complexity,
because
it
kind
of
makes
sense,
and
eventually
you
end
up
with
this
hugely
complex
computable
thing
that
could
do
everything
but
is
very
complex
or
very
complex
to.
I
B
B
O
Which
I
discovering
not
suited
discovering
it's
a
kubernetes
incubator
project
which
is
developed
it
in
Maine
till
I
think
out
which
I
discovery,
which
you
helped
you
to
identify
the
disk
of
the
network
resources
or
those
in
the
notes
to
discover
the
things
and
put
them
on
the
labels
and
using
those
labels.
You
can
make
the
part
to
sit
in
a
particular
node.
So
that's
how
we
are
implementing
in
both
HIV
and
duplicate.
Currently
in
our
setup.
Just
that.
O
You
have
like
three
nodes,
and
you
don't
know
in
which
no
today's
or
every
support
is
there.
The
notes
feature
discovery
will
help
you
to
find
the
HIV
node
and
using
those
labels
you,
for
example,
if
you
want
you
have
we
just
mentioned,
as
are
we
equal
to
true
and
then
the
particular
pod
will
sit
in
the
particular
node.
We
tell
only
the
answer:
IV
future,
those.
N
Are
laughing
like
that
person?
Well,
there's
another
way
of
doing
it.
Somebody
was
discussing
at
the
face-to-face
Sigma
meeting
that
what
was
it
before
just
before
Keep
Calm,
when
we
all
met
I,
forget
what
our
mechanism
was,
but
that
that
was
more
rather
than
just
labels
and
true
and
false.
That
was
more
about
actually
counting
resources
as
well
right.
N
F
O
F
B
C
D
F
B
F
I
B
I
mean
currently
this
can
happen
today.
I
think
adapters
in
kubernetes
was
not
aware
of
any
other
things.
You
cannot
manipulate
them
cream
FBI,
and
the
great
question
for
me
is:
is
it
we're
doing
this
previously
API
I
guess
I
tend
to
think
yeah
I,
don't
think
that
there's
some
massive
confidence
they
cover
so.
K
E
I
Right
I've
got
one
of
this
cake
maps
will
think
two
things
number
three
you
can
make
in
a
different
direction.
This
network
function
virtualization.
Maybe
we
can
finish
that
conversation
is
not
someone
right
up
to
example,
how
to
give
the
soft
firewall
with
the
existing
kubernetes
or
why
it
can't
be
I.
B
Would
say
can
be
done
with
the
existing
kubernetes?
You
just
have
to
write
a
whole
bunch
of
other
tooling,
outside
of
kubernetes,
to
manage
all
that
kind
of
stuff,
and
so
you
know
if
it
works
out
worse
for
plugin
authors
and
worse
for
users,
because
they
have
to
deal
with
two
separate
completely
different
sets
of
tooling
to
get
what
they
weren't
done.
F
There's
always
going
to
be
things
that
kubernetes
can't
express
that's
all
sort
of
above
or
below
the
bounds
in
as
much
as
they're
defined
if
they're
not
but
there's
full,
always
things
that
are
going
to
be
below
right.
We
don't
handle
creation
of
nodes,
for
example.
So
the
question
is,
you
know:
can
we
find
something
that
is
nice.
B
And
I
mean
I,
guess:
I
bought
a
very
generic
abstract
notion
of
network
that
essentially
just
represents
a
logical
network
that
the
plug
in
over
here
somehow
knows
to
hook
up
was
going
to
be
that
general
abstraction
that
we
could
all
sort
of
get
behind.
But
it
seems
like
there
may
be
disagreements
on
that.
I.
F
Mean
even
within
the
CNI
space
like
it's
complicated
because
the
CNI
layout
is
complicated
on
IPAM
could
be
before
or
after
the
primary
plugin
and
there's
the
chains
they're
coming
and
Casey
was
just
responded
earlier
today
saying
you
know
changing
even
more
important
in
CNI
and
I'm,
not
sure
what
that
means.
But
you
know,
like
I'm,
worried
that
whatever
we
described
here
eventually
devolves
into
a
arbitrary
JSON
structure,
so.
B
L
Just
for
some
clarification
here
do
I
think
there's
two
things
we
are
discussing.
One
is
to
have
multiple,
whether
to
have
or
not,
multiple
interfaces
for
a
single
cause
and
the
other
one
is
the
abstraction
that
Dan
is
talking
about,
which
is
the
logical
networks.
So
no
matter
we
have
the
logical
network
or
not
having
multiple
IP
addresses
designed
to
a
pause
can
still
be
beneficial
for
a
number
of
applications
such
as
the
NFA
that
we
were
discussing
just
wanted
to
see.
If
there
of
we
all
agree
on
this
or
not
yeah,.
F
F
B
F
I
Yeah
but
I
think
that
I
thought
the
problem
you're
referring
to
is,
if
kubernetes
just
records
a
list
of
IP
addresses
or
a
pod,
then
the
consumer
of
that
pod
doesn't
know
which
one
to
use
for
what
correct
you
have
to
give
in
every
DN
I
plug
in
to
return
a
clue.
We
don't
need
to
have
I,
don't
think
we
have
to
store
what
that
we
can
at
the
moment
sterilize
what
the
clues
mean,
but
we
have
to
have
a
space
where
a
clue
can
be
well.
I
I
think
that's
tying
two
things
together
that
are
quite
separate.
One
is
what
am
I
using
this
for
and
the
other
is
what
made
it
yeah.
That's
correct,
yeah,
I
think
from
the
consumers
point
of
view.
He
doesn't
really
care
where
they
came
from
or
he
doesn't.
We
don't
want.
The
consumers
have
to
know
how
these
things
are
made
or
where
they
come
from
right.
B
So
where
does
that
leave
us
I?
Think
to
to
your
point
Tim
yeah?
That
would
be
great,
and
maybe
that
is
a
great
base
to
start
them
is
just
to
make
sure
that
committees
can
report
multiple
IP
addresses
from
even
a
single
plugging
indication
like
we
currently
have
right
now,
but
to
Mike's
point
we
do
need
to
figure
out
some
way
of
saying
how
those
IP
addresses
are
important
for
different
things.
Otherwise,
there's
no
point
in
reporting
two
or
three,
because
you
have
no
idea
what
to
do
with
them.
I
acknowledge.
F
That
I
I
think
the
most
practical,
short-term
thing
that
people
can
do
is
respond
to
be.
What
are
you
trying
to
do
with
it
thread
concrete?
The
more
concrete
people
can
get
the
more.
We
can
ask
questions
to
try
to
get
to
the
root
of
things
and
try
to
think
through
what
currently
exists
and
what
needs
to
exist
to
satisfy
these
things.
B
Man,
I
was
going
to
say
that
you
know
if,
if
it
turns
out
that
half
the
people
on
this
call
like
they're
saying
Tim,
are
working
around
this
particular
feature.
Even
if
it's
not
something
that
we
would
necessarily
expect
kubernetes
to
do.
Is
it
worth
trying
to
find
out
how
to
accommodate
that?
Because
enough
people
are
trying
to
do
it?
I.
B
F
Great
I
would
love
to
hear
your
creative
plans,
because
you
know
sometimes
a
good
workaround
is
just
good
enough,
but
I'm
certainly
sensitive
to
the
fact
that
there's
lots
and
lots
of
people
are
trying
to
solve
the
same
problem
like
you
know,
may-maybe,
there's
something
real
there.
I
also
want
be
really
careful
that
we
don't
slip
into
the
this.
Is
we
know
how
to
ask
for
so
that's
what
we're
asking
right
and.
G
It's
Michael
here,
I,
don't
know
whether
this
is
relevant
or
should
be
taken
into
consideration,
but
as
people
are
filling
in
that
that
information,
it
may
be
interesting
to
know
is
the
use
case
like
an
R&D
effort
that
is
supporting
just
purely
R&D,
and
so
there's
not
a
typical
enterprise
deployment.
Or
is
it
an
enterprise
deployment
or
is
it
a
something
that
that
a
vendor
is
trying
to
work
on
for
their
product
again,
I'm,
not
sure
if
that's
important,
it
is
to
me,
but
that
may
help
in
terms
of
assessing
the
use
case.