►
From YouTube: Network Policy API Meeting 20210628
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
Okay,
hello:
everyone
today
is
june
28
2021.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
of
sig
network.
This
is
a
cncf
certified
meeting,
so
please
be
nice
to
everyone
and
let's
have
a
productive
day.
So
going
ahead
and
getting
started
with
the
agenda.
A
No
new
issues
to
triage.
I
did
highlight
a
pr
involving
well,
I
didn't
put
it
here,
but
I
assigned
jay
of
pr
involving
some
network
policy
tests
that
were
resulting
in
some
flakes
that
we
were
seeing
in
openshift
downstream,
and
I
had
that
link
up,
but
now
I
lost
it
so
I'll
find
it
again
and
add
it
back
to
here,
but
it
doesn't
really
have
to
do
with
anyone
in
this
meeting,
because
we
haven't
been
working
on
the
netfall
test
very
much
lately.
A
Otherwise
the
agenda
is
pretty
open.
As
yang
and
a
couple
of
us
were
discussing
earlier,
we
had
a
big
discussion
in
upstream
sig
network
last
thursday
regarding
ip
block
recommendations
and
that
isn't
concerning
or
concerning
cmp.
So
I
think
it'd
be
good
to
do
that.
Continue
that
here
you
know-
and
I
think
it's
going
to
be
good
just
to
keep
talking
about
cmp
in
this
group,
because
again
we
brought
up
some
things
to
sig
network
and
didn't
get
any
absolutes,
so
yeah,
that's
kind
of
where
we
are
with
cmp.
A
I
think
am
I
missing
anything.
A
Yeah
I
have
that
later
on
in
the
agenda
as
well,
but
I
I
thought
for
now:
let's,
let's
start
with
cmp.
B
Yeah
I
I
was
actually
going
to
put
some
thoughts.
I
have
put
just
the
one
slide
together
if,
if
you
like,
I
can
share,
but
I
was
really
gonna
kind
of
add
some
more
material
for
the
thursday
call,
but
we
can
kind
of
discuss
that
today
as
well.
A
Yeah,
I
don't
think
that'd
be
a
bad
idea
and
just
for
filling
in
the
group
sanjeev
and
I
had
an
out-of-band
meeting
with
dan
winship
and
dan
williams
kind
of
like
about
this
and
about
how
to
come
away
with
or
like
how
to
move
this
forward
at
large.
So
I
assume
that's
what
this
slide
is
about
right,
sanji,
yes,.
B
That's
right,
so
I
just
want
to
kind
of
just
share
a
couple
of
points,
but
we
can
spend
a
little
bit
of
time
on
it
today,
but
it
was
meant
for
the
next
meeting,
but
just
to
introduce
the
concept
so
that
people
can
think
about
it.
Maybe.
C
B
Okay,
so,
as
andrew
was
saying,
we
were
having
some
internal
discussions
within
red
hat
about
this
and
part
of
this
we've
sort
of
had
bits
and
pieces
of
discussion
within
this
group
and
sig
network
as
well,
and
here
are
some
thoughts
right.
B
So
if
we
look
at
the
streams
of
work
for
cluster
admin
network
policies,
maybe
it
would
be
better
to
look
at
these
as
multiple
streams
of
work
right.
So
this
is
a
potential
draft
proposal,
but
we
haven't
fully
documented
it
so
for
now
I
just
mentioned
this,
and
the
proposal
is
to
consider
looking
at
each
stream
of
work
independently,
possibly
via
separate
caps
as
well,
and
one
way
to
break
that
down
could
be
this
now,
I'm
be
talking
specifically
about
cluster
slash
admin
network
policies.
B
Here
this
may
or
may
not
overlap
with
netball
v2,
okay,
and
that's
for
us
to
sort
out
what
intellect
what
overlaps
with
what
so
the
thought
is
that
the
current
kept
the
cluster
network
policy,
because
all
this
debate
around
ip
block-
and
you
know
what
happens
with
nating
and
host
networks-
maybe
limit
its
focus
just
to
intra
cluster
network
policy
for
cluster
admins.
B
Let's
for
now,
I'm
just
calling
it
cluster
director
external
network
policies
which
potentially
could
be
a
new
cap
or
could
be
more
than
one
new
cap
and
focus
this
on
cluster
external
network
protection,
which
is
essentially
not
south
or
ingress
egress
protection.
It
was
about-
and
I
was
actually
literally
writing
this
before
this
call.
So
I
haven't
even
finished
this
slide
yet,
but
basically
this
would
consider
two
kinds
of
things.
B
One
is
ingress,
not
self
protection
where
it
may
have
a
component
that
somehow
is
related
to
the
kubernetes
ingress
as
well,
because
you
want
to
have
a
policy
that
works
with
ingress
or
not
right,
you,
I
think
you
can
have
both
the
options
and
then
on
the
eager
side.
It
does
something
like
many
of
the
cni's
have
a
egress
control
or
eagles
firewall.
B
It
would
sort
of
deal
with
that.
So
then
those
would
also
be
admin,
their
admin
network
policies,
but
we
do
not
need
to
confuse
those
use
cases
with
the
cluster
network
policy
and
then
those
may
need
some
variation
of
ip
block
or
not,
but
we
can
remove
the
ip
block
from
cnp
and
so
cnp
can
move
forward
as
inter
cluster
network
policy
fragments
and
then
cluster
external
network
policies
would
address
ingress
interests.
A
Yep,
so
I
mean
the
main
problem
right
is
cmp
is
not
moving
forward,
so
we
took
a
step
back
and
said:
how
do
we
fix
this?
We
asked
dan
williams
and
dan
winship
this
time
and
you
know
their
viewpoint
after
we
talked
about
it
for
a
long
time
was
like
originally
network
policy
was
made
just
for
intra
instra
cluster
traffic
right
it
was,
it
was
allowing
denying
intra
clustered
traffic
later
on
they
added
ip
block
to
allow
for
ingress,
egress
traffic.
A
You
know
policies,
but
with
cmp
the
problem
say,
space
seems
pretty
wide
and
a
lot
wider
and
it's
it's
almost
like
it's
hard
to
create
a
one
object
solution
to
adequately
handle
both
scenarios.
So
I
don't
know
what
everyone
else
thinks,
but
I'm
not
sold
fully
on
it
yet,
but
I
think
we
should
think
about
it.
So.
D
There's
several
axles,
you
can
split
right,
I
mean
here,
we've
done
intra
and
a
sort
of
extern.
You
can
also
talk
about.
Inter
that
can
be
expressed.
You
can
all
you
could
also
look
sort
of
at
call
it
traditional,
which
is
based
on
addresses,
and
then
I
wouldn't
say
modern,
but
I
mean
this-
that
is
more
sort
of
label
based
a
low
balance
network
policies
and
and
they
don't
make
a
good
fit.
Always
I
mean
I've
been
playing
around
with
okay.
D
That's
a
big
strength,
because
it
those
rules
are
always
what
I
call
locationlessness.
You
can
transport
them
fairly,
simple.
Okay,
you
might
have
to
map
the
namespaces,
but
you're
sort
of
not
dependent
on
any
sort
of
anything
about
from
the
the
local
installation
they
run
on
right.
You
don't
have
to
care
about
what
addresses
have
been
set
and
what
they're
talking
about
to
the
outside
and
so
on.
D
So
from
that
perspective,
I
think
it
makes
a
lot
of
sense
to
to
as
much
as
possible
separate
these
two,
these
two
things,
and
so
that
try
to
really
to
push
on
on
using
labels
and
sort
of
what's
built
in
into
sort
of
the
the
definitions
of
pod
services
and
whatever
we
come
up
with
right
and
base
the
firewalling
as
much
as
possible.
On
that
then
have
a
clear
separation.
D
I
don't
think
there's
a
good
match
between
them
right
now.
We
end
up
with
weird
ways
to
describe
an
ip
blocks.
That
sort
of
does
not
follow
the
normal
way
of
doing
it
in
firewalls.
So
from
that
perspective,
I
think
this
could
make
perfect
sense.
The
question,
then,
is:
how
do
we
take
the
ip
block
out
of
the
the
normal
network
policy?
B
Another
thing
is
that
so
yeah
one
other
quickly
point
I'll
mention
is
that
the
implementation
of
external
network
policies
seems
to
be.
There
is
not
yet
a
consensus
right,
some
people
talking
about
having
an
external
sort
of
gateway
right
through
which
you
have
to
go
through,
and
then
that
does
sort
of
these
netting
operations
and
all
that
some
people
are
talking
about
a
distributed
solution.
D
B
Yeah,
let
me
finish
so
so.
Basically,
the
point
is
that
this
allows
us,
so
we
we
agree
on
the
value
of
the
cmp,
as
it
is
based
on
labels
right
and
this
once
you
take
out
the
north
south
thing,
you
take
out
the
need
for
ip
block
as
well,
so
it
simplifies
the
and
we
can
say
the
use
case
is
primarily
cluster
protection
and
some
tenancy
and
and
that's
it
right,
intra
cluster
protection.
E
I'm
trying
to
understand
what
is
the
relation
between,
inter,
inter
intra,
intra
versus
the
ip
blocks.
B
Because
ipblock
names
the
peer
through
explicit
listing
of
ips,
so
it
with
most,
if
not
all,
of
the
intel
cluster,
you
want
to
name
them
with
labels,
because
if
the
source
is
a
part,
you
know
the
part
can
come
and
go
quickly.
You
don't
really
want
to
hardcode
the
ips,
but
but
external
you
often
do
need
to
hard
code.
The
ips,
because
you're
going
to
specific
destinations,
like
you
know,
going
to
www.russia.com
whatever
right.
B
So
that's
where
and
that's
where
potentially
fqdn
based
policies
also
come
in,
because
fqdn
also
is
largely
on
the
north
south
side,
not
so
much
isotopes.
E
B
And
that's
even
the
history
behind
network
v1,
I
think
andrew
others
who
were
involved
in
that
right
network
v1
added
ip
block,
primarily
because
they
partially
wanted
to
do
that
knots
out
solutions,
but
it
turned
out
to
be
clue
g
and
then
they
added
ip
block
exception,
which
also
causes
problems
with
data
plane.
So
we're
we
want
to
help
all
these
both
have
valid
use
cases,
but
if
we
decouple
them
we'll
be
able
to
move
the
cnp
forward,
we
will
be
able
to
remove
the
ip
block.
B
We
will
have
a
limited,
smaller
set
of
use
cases,
get
agreement
on
those
they're,
basically
inter
cluster
policies
for
targeted
at
the
admin
and
let
it
move
forward.
In
parallel,
we
talk
about,
knocks
out
controls
and
and
really
get
into
details
of
what
the
egress
router
should
be
eagles.
Firewall.
D
With
the
blocks
you
probably
want
to
have
some
sort
of,
I
mean
longest
prefix
setup
right,
so
you
can
make
them
simple
and
then
allow
and
allow
deny
and
so
on
dvd.
Let's
see,
yeah
yeah.
A
Yeah
but
let's
hear
from
yang
and
ivashek,
I
know
you
all
started
this
whole
cup
right.
This
is
your
baby,
so
I
don't
know
what
you
think
here
just
analyzing
ways
to
get
it
to
move.
C
Yeah,
one
of
the
questions
I
have
here
is
that
you
know
for
the
north
south.
I
know
the
north
south
cluster
protection
sounds
like
ip
blockchain,
but
I'm
still
wondering
like
what
will
be
like
a
east
west
case
here,
like
does
east
os
being
like
intra
cluster
traffic,
or
should
we
consider
multi-cluster
basic
use
cases
here
as
well?
Right
because
I
know
I
know
abstract
has
been
sort
of
like
working
on
some.
You
know
multi-cluster
policy
sorts.
So
I
still
see
you
know.
C
Cluster
network
policy
could
just
potentially
solve
those
use
cases,
especially
you
know
when
we
were
looking
at
the
tendency
models
and
we
evolved
the
tendency
models
to
say
that
hey
you
know,
a
tenant
might
be
a
couple
of
name
spaces
in
the
cluster
instead
of
single
name
space
in
the
cluster.
Now
on
the
the
multi-cluster
scenario,
if
the
multi-cluster
scenario
comes
in
does
does
that
fall
into
label
selectors,
or
was
that
used
to
be
solved
by
the
ip
block
that
if
we
remove
ib
block
it
will
not
be
solved
anymore?.
B
B
Firstly,
nothing
that
we
are
saying
here
or
considering
here
prevents
us
from
having
a
multi-cluster
version
of
this
of
each
of
these
network
policies
in
the
future.
But
we
need
to
have
the
single
cluster.
B
B
About
simplifying
it
so
that
it
would
sort
of
you
know,
we
talked
about
lots
of
things
which
we
could
do
in
the
future.
So
multi-cluster
is
another
thing
which
we
could
do
in
the
future,
both
for
cluster
network
policies
as
well
as
for
netpol
v1
slash.
We
do
as
future
api
versions
of
that
same
resource,
so
I
think
we
will
slow
down
tremendously
if
we
kind
of
add
some
multi-use
case,
multi-cluster
use
cases,
but
without
having
a
multi-cluster
architecture
with
a
multi-cluster
architecture.
B
You
have
to
first
decide:
where
are
those
policies
living
which
apply
to
more
than
one
cluster
right?
Is
there
a
central
command
and
control
cluster
and
then
that
distributes
the
policies
to
the
others,
or
is
it
some
kind
of
oss
that
is
sitting
outside
of
the
clusters
that
is
giving
it
to
all
the
clusters?
So
without
having
that
kind
of
model
we
don't
have,
we
will
spend
a
lot
of
time
on
the
multi-cluster
policy.
B
So
what
we're
saying
is
that,
yes,
we
can
do
multi-cluster
for
all
of
these
things,
but
it's
not
necessary
perhaps
for
this
cape
right
now
to
add
multi-cluster
in
order
to
make
it
work
and
also
I
don't
think
what
we
would
be
talking
about
would
involve
ip
block.
Okay
and
finally,
the
point
is
that,
just
because
we're
removing
iv
block
now
doesn't
mean
that,
if
there's
another
use
case
which
absolutely
cannot
work
without
ip
block,
we
can't
add
it
right.
B
A
B
Right
and
then
that
confused
the
not
so
discussion,
also
because
it
doesn't
work
properly
with
you
know,
host
network
and
a
few
other,
not
so
load
balancing
cases
so
simplifying
doesn't
mean
we
can't
add
it
in
the
future,
but
this
allows
us
to
move
it
forward,
saying
that
this
is
for
inter
cluster
policy
and
admin
focused,
and
we
will
address
the
north
south
case
via
external
network
policies
and
and
then
you
know,
we'll
keep
anyway.
I've
spoken
a
lot,
maybe
abhishek
you
have
any
thoughts
or
anybody
else.
F
Yes,
I
do
so,
I
think
fundamentally,
I
agree
on
on
this
division,
especially
I
mean
a
keen
observer
of
the
cluster
network
policy.
Kept
work
would
have
noticed
that
we
haven't
iterated
over
ip
block
since
updating
uploading
the
cap
for
the
first
time,
mainly
because
the
use
cases
there
are
slightly
different
as
compared
to
the
use
cases
for
what
we
are
calling
as
intra
cluster
use
cases
right.
F
So
yes,
it's
something
that
we
always
wanted
to
figure
out,
just
not
just
for
claustrophobic
policy,
but
also
for
network
policy
in
general,
because
it's
it's
something
that
affects
both
both
the
resources.
F
So
definitely
I
would
not
be
averse
to
removing
ip
block
and
I
would
love
to
see
proposals
on
on
the
cluster
external
network
policies,
because
I
think
those
use
cases
are
valid
we,
but
we
need
to
define
them
correctly,
and
perhaps
it
can
be
done
external
or
separately
for
both
network
policies
and
in
the
future
addition
to
cluster
network
policy
or,
however,
it
is
being
introduced.
F
Yeah,
I
I
still
am
not
convinced
on
whether
the
maneuvering
of
traffic
or
routing
of
traffic
should
be
part
of
network
policy
apis,
but
I
I
definitely
feel
like
the.
How
to
define
external
access
to
external
traffic
does
definitely
be.
Is
part
of
the
interior
policy
api.
So
you
know
unless
someone
comes
with
a
proposal
for
this,
and
it
makes
more
sense
for
the
use
cases.
I
guess
I
guess.
Basically,
what
I'm
trying
to
say
is
that
we
need
to
see
the
proposal
to
to
figure
out
whether
this
really
depe.
F
A
And
I
think
you
know
the
main
thing
here
too
is
we
were
looking
at?
How
can
we
move
this
along?
Like
that's
been
the
overarching
question
now
for
a
couple
weeks
and
I
think
there's
more
there's
a
lot
of
agreement
on
the
fact
that
we
need
you
know
some
sort
of
some
sort
of
tenancy
in
in
kubernetes
clusters,
and
we
don't
have
that,
and
this
would
allow
us
to
fully
focus
a
feature
development
of
question
network
policy
on
supporting
that
feature
which
is
desired
by
almost
everybody.
A
A
D
B
Yeah
so
as
it
happens,
I
just
happen
to
have
a
picture
here
which
we
actually
introduced
into
the
use
cases
repo.
This
is
the
proposed
tenancy
model
that
we
would
target
with
the
cluster
metric
policy,
and
the
details
are
in
the
use
case.
B
Please
provide
your
review
comments
there,
but
it's
it's
fairly,
simple
right:
there's
kubernetes
control
system
type,
you
name
spaces,
there's
some
distribution,
specific
namespaces
and
there
are
tenant
namespaces
and
the
tens
can
be
no
more
than
one
namespace
and
mostly
tenants
are
isolated
from
each
other,
except
in
some
cases
under
admin
control.
Some
tenants
can
talk
to
certain
specific
services
and
other
tenants.
B
Yeah,
a
specific
label
in
a
specific
cross
tenant
can
be
exposed
because
this
particular
tenant
is
opening
a
public
service
for
other
tenants,
but
otherwise
tenants
are
isolated
from
each
other
and
then
there
is
limited
control
in
the
system
name
spaces
as
well.
So
this
is.
This
is
all
inter
cluster.
You
see
there's
no
in
north
south
here.
This
is
all
sort
of
intra
cluster
isolation,
so
all
of
this
can
be
targeted
with
a
policy
that
does
not
depend
upon
iv
blocking
right,
but.
D
D
Internal,
I
mean
cluster
name
space
pod,
but
I
mean
the
risk
is
cool.
Yeah.
B
Okay,
so
this
is
already
in
our
use
cases
being
targeted
by
the
current
cap
right.
So
what
we're
saying
is
to
limit
it
to
these
sorts
of
use
cases,
and
maybe
at
least
for
now,
we're
not
saying
permanently,
but
at
least
for
now
remove
the
ones
which
are
related
to
north
south.
They
may
come
back
or
they
may
come
back
in
a
different
resource
and
possibly
again
we
want.
B
I
I'm
happy
to
volunteer
to
do
something
more
on
this.
Some
of
these
egress
firewall
and
sort
of
put
some
draft
proposal
there
and
that's
what
we
maybe
will
share
in
the
next
couple
of
meetings,
but
for
now
these
are
just
some
thoughts
to
share
that
in
order
to
move
the
cluster
network
policy
along,
maybe
focus
it
on
inter
cluster
policy,
take
out
the
ip
block
and
then
have
a
separate
effort
for
external
policies.
B
A
Yeah
cool
thanks.
I
know
it
was
the
last
second
sort
of
thing
but
made
sense
to
bring
it
up
just
so.
We
can
keep
trucking
along
here
and
not
get
stalled
out,
because
I
guess
I
don't
know
if
everyone
was
there,
but
the
discussion
on
last
thursday
kind
of
spiraled
into
nothing
related
to
what
we
started
to
started
wanting
to
discuss.
I
think
right,
yang
and
abushek.
It
was
kind
of
like
we
spiraled
into
a
whole.
Another
problem.
F
Yeah,
I
think
I
saw
cal
sent
out
an
email
on
the
mailing
list
on
his
thoughts,
and
I
think
it's
you
know
it's
it's
something
that
makes
sense,
because
there
is
a
lot
of
ambiguity
when
it
comes
to
how
cnn
has
implemented
this
particular
use
case,
and
I
believe
that
you
know
on
some
sort
of
level
all
cni's
have
done
a
good
job
of
explaining
what
they
have
done.
F
At
least
you
know
for
for
these,
for
the
cases
where
you
want
to
preserve
the
original
source
ips,
they
have
explicitly
either
added
a
new
field
to
preserve
that
and
made
the
assumption
that,
whatever
you
see
as
the
source,
ip
is
what
you
will.
The
traffic
will
be
enforced
on.
I
think,
in
terms
of
that,
I
think
a
lot
of
cnas
are
very
similar
in
in
the
implementation
and
enforcement
of
that.
F
But
but
that's
something
that
you
know
is
is
probably
not
what
is
intuitive
for
a
user.
So
so
there
are
ambiguous
things
and
I
think
this
discussion
kind
of
makes
sense
and
we
definitely
need
to
have
a
good
good
story
or
a
good
definition
of
this
external
cluster
external
traffic
and
I'm
hoping
that
we
can
tackle
that
for
not
just
for
cluster
scope
policies,
but
also
for
network
policies.
A
Yeah
yeah,
I
totally
agree,
I
think
it's
turned
it's
blossomed
into
this
huge
problem,
not
huge
problem,
but
a
thing
that
requires
a
lot
of
discussion.
So
you
know,
makes
sense
to
kind
of
split
up
the
work
items
so
that
you
and
yang,
and
the
main
workers
of
cmp
don't
have
to
you-
know,
take
one
step
forward:
five
steps
back
with
every
little
change,
so
cool
and
yeah
that
google
groups
discussion
that
abhishek
was
talking
about.
I
posted
the
link
in
the
agenda.
A
That
was
also
something
we
don't
necessarily
want
need
to
talk
about
here,
but
I
just
wanted
the
members
of
this
group
to
read
it
and
give
it
a
view,
a
look
over
and
maybe
post
some
thoughts
there.
I
know
I
was
skimming
it
before
this
meeting
and
he
had-
and
there
were
some
interesting
ideas
proposed
for
sure.
A
Awesome
cool,
so
the
only
other
thing
I
had
on
the
agenda
today
was
just
a
call
to
keep
commenting
on
prasada
deems
document
regarding
v2
I
saw
sanjeev
was
able
to
get
some
time
to
poke
around
there
thanks
for
doing
that,
but
otherwise
I
think
we're
still
just
in
the
the
early
stages.
Do
you
have
anything
to
say
there
facade
or
nadim
or
sanji?
Do
you
want
to
talk
about
anything.
E
Yeah,
I
think
you
know
after
this
call
I
will
start
responding
to
it
and
I
have
one
more
question
related
to
v2.
So
today
all
our
network
policies
are
cnp.
You
know
based
on
the
default
pod
networking,
but
kubernetes
also
introduced.
You
know
an
ad
definitions
to
create
virtual
networks.
You
know
parallel
to
power
networking.
E
So
would
these
policies
apply
there
or
how
does
I
mean?
What's
our
you
know,
thought
process
in
that?
That's
another.
You
know
general
question
like
you
know
it
may
not
be,
for
we
want
to
be
to
general
for
any
network
policy.
F
So,
as
far
as
I
know,
the,
if
even
when
the
multi-network
crd
was
being
developed
and
the
assumption
was
that
the
network
policies
only
apply
to
the
primary
interface
of
the
pods
and
not
to
these
additional
interfaces
that
are
attached
to
to
it,
I
do
believe
someone
posted
last
week,
probably
who
posted
a
similar
work
that
is
being
done.
F
They
are
kind
of
trying
to
expand
the
scope
of
network
policy
to
multiple
interfaces
by
the
means
of
annotation,
so
but
I
but
to
to
answer
your
question
about
how
it
how
the
current
set
of
network
policies
affect
these
multi-network
multiple
interfaces
they
should
not
be.
They
are
only
meant
for
primary
interfaces.
B
I
see
there
also.
I
think
we
should
welcome
some
use
cases
which
make
that
clear,
because
one
logic
could
be
that
the
multi-network
use
cases
are
primarily
used
for
nfv
and
in
the
nfv
case
you
have
a
very
more
controlled
network.
Do
you
need
network
policies
like
this
or
your
policies?
Filtering
policies
will
be
implemented
by
the
appliances
themselves,
doing
filtering
so
use
case.
Clarity
for
the
multi-network
network
policy
would
be
good.
E
E
You
know
either,
like
you
know,
lr,
like
you,
know,
logical,
router,
or
something
like
that,
then,
on
top
of
that,
like
you
know,
you
still
apply
the
network
network
policy
likes
things,
so
I
was
trying
to
map
that
construct
here
because
even
in
5g
use
cases
what
happens
is
like
you
know,
you
might
have
you
know
a
red
network
or
green
network,
but
still
you
know
you
wanted
to
have
some
services.
E
B
E
Yeah,
I
I
will
do
that
and
maybe
I
will
should
I
capture
that
in
the
v2
I
know
maybe
put
question
marks
there.
Then
you
know
everybody
start
commenting
on
that.
Should
I
do
that
way
or
or
what
do
you
think
sanji,
I'm?
Okay
with
that
I
mean
whatever
everybody
feels
okay.
So
so
let
me
just
add
it
there.
If
it
doesn't
fit
there,
then
we
can
remove,
but
at
least
like
you
know,
we
have
some
some
place
to
capture.
You
know.
F
D
On
the
previous
separation,
I
mean
you
said
multi-networking.
It
makes
that's
also
much
simpler
right,
the
when
it's
just
labels.
You
have
much
much
less
problems
with
multi-networking,
it
was
there's.
No
networks
mentioned
just
talk
about
instances
that
can
reach
each
other,
not
how
that
is
done
so
yet
another.
E
Okay
got
it
yeah,
so
so
I
I
will
you
know
please
if
I
mean
all
of
us,
if
you
can
keep
going
to
the
v2
document
and
start
commenting,
I
will
respond
and
I
just
saw
a
few
comments
from
sanjeev.
You
know
after
this
meeting
I
will
go
after
them.
A
A
Obviously
we
have
a
pretty
core
group
of
people
who
have
been
coming
into
this
meeting
every
week,
but
I
think
it
would
be
great
if
we
could
foster
you
know
even
more
people
to
join,
because
I
I
mean
we,
we
have
a
lot
of
work
to
do
and
there's
a
lot
of
stuff.
That
needs
to
be
reviewed
and
I
know
we're
all
pretty
busy.
I
don't
know
if
anyone
has
some
good
ideas
for
that.
So.
D
D
The
whole
time
has
just
been
working
on
things
around
network
policies
and
that's
what
I
will
have
them
doing,
what
I
call
the
semantics
of
network
policies
and
sort
of
how
to
break
them
down
how
to
represent
just
the
labels,
how
they
work
with
each
other
without
having
to
keep
track
of
all
the
addresses.
So
basically
you
do
address
to
label,
and
then
you
compare
labels
and
I
mean
he
will
go
to
school
for
years.
So
for
for
long
for
long
term.
D
I
think
he
could
be
a
good
guy
to
get
involved
I'll
invite
him
next
week
because
he's
getting
pretty
interested
in
kubernetes
and
networking
policies
and
sort
of
he
should
be
out
of
school
a
year
or
two
from
now
and
I
plan
to
hire
him
then,
but
we
can
probably
start
pushing
stuff
on
him
before
that.
A
Cool
yeah,
I
think
the
more
the
merrier
here,
especially
the
more
that
are
willing
to
take
on
work
items
right.
So
yeah
sounds
good
to
me
cool.
Well,
that's
all
I
had
on
the
agenda
today.
Is
anyone
have
anything
else
they
want
to
talk
about?
Obviously
we
have
some
more.
A
D
B
One
last
thing
regarding
inviting
other
people:
I
would
definitely
want
to
see
more
practitioners.
I
want
to
see
their
real
world
experiences
with
the
current
network
policy.
You
know
that
will
help
influence
all
of
our
future
work.
So
if
anybody
knows
any
customers
that
are
willing
to
drop
in
for
one
one-off
meeting
or
attend
regularly
and
share
real-world
experiences,
I
think
that
would
be
really
good.
Another
thing
I
would
add
is
that
anything
that
we're
doing
in
the
future.
We
need
validation
from
all
the
cni
vendors
right.
B
So,
for
example,
cnp
we
need
you
know
the
clim
guys
and
the
calico
guys
and
everybody
to
say
yeah.
This
makes
sense.
So
at
some
point
we
need
to
have
a
meeting
with
them
as
well.
Maybe
that's
currently
handled
as
part
of
the
camp.
So
two
points.
One
is
more
practitioners,
of
course,
more
more
people
working
on
the
court
as
well,
but
also
that's
the
first
one
more
practical.
Second
one
is,
you
know,
direct
feedback
from
the
different
cni
vendors.
When
I.
B
F
Regarding
the
second
point,
we've
done
that
in
the
past,
so
both
calico
and
cilium
and
andrea
have
committed
to
absorbing
the
api
when
whatever
is
merged.
So
it's
you
know
if
there
are
more
cni
providers
that
you
would
want
to
get
a
yes
from,
we
can
invite
them
as
well.
So
so
far
I
have
I've
spoken
to
thomas
and
from
psyllium
and
casey
from
calico,
and
of
course
we
are
here
from
andrea,
so
any
anyone
else
who
you
think
we
should
well.
B
Andrew
and
I
and
others
are
from
the
urban
kubernetes
side.
So
yes.
F
B
F
So
I'm
hoping
that
you
both
also
agree
to
whatever
is
agreed
upon.
That's
the
cnp
api.
Definitely
yeah!
Yes,
so
we
have
so.
We
have
four.
B
No,
I
was
actually
into
more
around
a
little
bit
more
details
around
like,
for
example,
you
know-
let's
say
some
cnn
vendor
says
this
is
the
most
common
use
case.
We
see
for
cluster
policy
and
back
it
up
with
some
specific
data,
like
you
know,
even
the
tenancy
discussion.
For
example,
we
still
had
some
debate
about
that.
F
Yeah,
I
think
that's
why
we
continue
to
invite
you
know.
We
definitely
you
guys
are
here
from
our
new
community's
perspective
and
then
we
also
continue
to
invite
folks
from
psyllium
and
calico
to
review
the
api
specs
so
that,
at
the
end
of
the
day
when
we
approve,
when
people
agree
upon
certain
definition
of
the
api,
it
is
based
on
the
the
reviews
of
all
all
different
or
people
from
different
cni
vendors.
B
Just
more
just
more
real-world
data
and
no,
we
are
here
to
address
real-world
issues
and
incorporate
them
into
the
next
versions
of
network
policy,
whether
at
the
cluster
level
or
at
the
network
level.
So
any
of
this
data,
whether
from
practitioners
or
from
vendors,
that's
it's
useful,
that's
that's
all
from
operators
or
from.
E
F
A
A
An
active
piece
of
work-
okay,
I
saw
jay
bring
it
up
the
other
day.
Talking
about.
Is
there
a
way
to
you
know,
test
conformance
for
various
cni's
on
network
policy
and
he
brought
up
cyclonus.
A
I
had
pinked
him
a
while
ago
about
the
possibility
of
getting
cyclonus
incorporated
into
our
new
repo
as
a
central
like
upstream
hosting
place,
because
right
now
I
think
it's
just
under
matt's
personal
repo.
Do
you
have
some
thoughts
on
it.
F
Yeah,
I
think
he
is
running
some
of
those
tests
here
for
us.
The
the
thing
that
I
wanted
to
look
at
was
you
know.
Eventually,
when
we
do
cnp,
we
would
also
want
to
extend
the
tool
or
the
framework
to
be
able
to.
You
know
some
provide
users
a
way
to
figure
out
how
you
know
the
different
policies
in
a
cluster
affect
that
affect
the
traffic
within
the
parts
like,
for
example,
as
a
user.
I
want
to
check
whether
my
pod
one
can
communicate
to
part
two.
F
I
want
to
know
what
network
policies
are
enforced
on
that
and
what
customer
policies
are
enforced
on
and
whether
this
communication
is
allowed
or
not.
So
this
will
kind
of
help
users
in
a
way
to
figure
out
whether
the
policies
that
they
have
written
are
enforced
in
the
way
that
they
expect
they.
It
should
be,
and
also
kind
of
like
a
good
way
of.
D
F
A
B
Yeah
I
wish
one
more
thing.
I
I
added
a
slightly
detailed
comment
on
your
cap,
going
back
to
the
priority
ordering
based
solution
and
I
listed
like
four
or
five
benefits,
which
I
believe.
So
let
me
know
if
that.
Firstly,
that
makes
sense-
or
you
have
any
comments,
but
if
you
want
me
to
move
that
comment
back
to
the
point
in
the
document
where
you're
discussing
the
priority
ordering,
but
I
don't
know
if
you've
seen
it,
but
I
I
feel
like
we
should
strongly
consider
the
priority
ordering,
and
I
give
several
reasons
for
that.