►
From YouTube: Network Policy API Meeting 20210719
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
july,
19th
2021.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
of
cignetwork.
It
is
the
cncf
certified
cncf
foundation
meeting.
So
please
be
nice
to
each
other
and
let's
have
a
good
meeting
today.
So
let
me
go
ahead
and.
A
Pull
up
the
agenda
here,
that's
why
it
made
me
log
out:
okay,
so
not
much
to
talk
about
today
on
the
agenda.
I
just
thought
we
would
run
over
and
could
even
continue
the
discussion
that
came
out
of
friday's
meeting.
If
you
could
not
make
it,
I
went
ahead
and
added
the
kind
of
what
we
ended
up
talking
about.
A
Does
anyone
have
any
questions
from
that
meeting,
abhishek
or
yang?
Do
you
want
to
talk
about
anything?
You
know
try
to
maybe
put
together
a
list
of
what
we
do
now
or
what
do
you
think.
B
Yeah
so
abstract
just
meshes
messaged
me
saying
that
he's
joining
maybe
10
minutes
late.
So
I
kind
of
like
from
last
meeting
as
as
far
as
I
remember,
you
know,
we
basically
spent
a
huge
amount
of
time
discussion
in
the
discussing
in
the
community
on
that
whether
we
should
have
you
know
those
two
three
actions
which
sort
of
have
power.
B
These
amounts
themselves,
or
we
should
actually
do
the
numeric
priority
in
the
cluster
network
policy
and,
from
my
point
of
view,
I
feel
like
the
community
still
has
a
sort
of
like
divided
opinion.
Some
people
still
think
you
know
the
the
poverty.
The
action
enums
would
have
their
benefits
and
a
lot
of
other
people
also
think
that
the
numerical
power
in
cnp
will
be
more
familiar
to
a
lot
of
currency
and
cluster
network
policy,
implementations
now
the
cni's.
B
So
I
think
from
from
what
I
remember
in
that
meeting
sanjivas
we
were
also
talking
about
you
know.
Maybe
we
can
discuss
some
of
the.
I
don't
know
the
experiences
I
had
in
implementing
something
like
a
numerical
priority
in
cmp
in
the
mcat
implementation
and
to
see
you
know
where
I'm
coming
from.
So
I
I
just
gotta-
maybe
you
know
talk
briefly
on
that
front
and
see
how
everybody
thinks
on
that
then.
B
So
the
reason
I
wasn't
really
fond
of
having
the
numerical
priorities
in
cmp
is
that,
to
be
honest,
this
is
what
we
have
in
yentra
and
in
andrea.
We,
the
reason
why
we
need
to
have
the
numeric
priorities
is
that
there
are
some
other
vmware
solutions
internally
that
uses
those
kind
of
numerical
priorities,
as
a
lot
of
people
in
the
community
also
mentioned
right.
B
So
there
are,
you
know,
network
access
lists
like
legacy
applications
stuff,
like
that
they
all
use
this,
this
kind
of
numeric
poverty
and
it's
very
familiar
to
people.
So
we
kind
of
like
wanted
to
confirm
to
that
standard
and
to
develop
a
solution
that
is
interchangeable
with
those
those
kind
of
things.
B
But
you
know
a
major,
a
major
setback
or
complexity
that
we
found
out
is
that
you
know
once
we
introduce
numerical
priorities,
the
the
problem
comes
in
the
cardinality
of
the
priorities
that
we
are
trying
to
introduce
to
the
solution.
B
Right
now
in
the
in
the
enter
cluster
network
policy,
the
cardinality
is
essentially,
I
wouldn't
say,
infinite,
but
it's
a
lot
like
it's
tens
of
thousands
of
priorities
in
theory
that
you
can
insert
for
cluster
network
policy
rule
the
reason
we
decided
to
do
that
is
that
you
know
from
a
user
perspective
right
when
you
create
a
rule.
That
is
priority.
Let's
say
five
and
another
rule,
that's
power
d6.
B
Now,
somehow
you
realize
that
you
know
in
between
those
rules.
You
wanted
to
exert
something.
So
the
our
reasoning
is
that
for
a
kubernetes
sort
of
like
resource
the
the
way
you
do,
that
shouldn't
be
that
you
have
to
change
one
of
the
priorities.
That's
already
established
right.
So
if
you
have
two
cmps
one
is
priority.
Five,
and
one
is
six:
when
you
wanted
to
insert
something
you
should
do
something
to
create
a
rule.
That's
probably
5.5.
B
Instead
of
having
to
move
a
certain
rule
back
or
up
in
order
for
another
to
fit
in
that,
doesn't
really
you
know
make
sense,
because
you
have
to
do
a
lot
of
like
manual
things
right
and
you
have
to
change
the
in
the
existing
state
of
things
in
the
cluster.
B
For
you
to
be
able
to
do
something
like
that,
so
the
re
so
based
off
that
sort
of
like
principle,
we
introduced
the
priority
to
be
sort
of
like
a
float
number,
and
because
of
that,
the
power
of
these
essentially
can
be
really
infinite
infinite
because
you
can
do
pi
for
5.5
and
then
once
you
wanted
to
insert
another
priority
into
the
rule,
you
can
do
5.56
or
something
like
that.
You
can
basically
carve
a
you
know
arbitrary,
precise
power.
C
B
D
B
But
but
anyway,
I
guess-
I
guess.
Let
me
you
know
finish
real
quick
on
on.
You
know
what
the
problem
introduced
by
this,
so
so
because
we
wanted
to
have
you
know
all
those
power.
These
are
arbitrary
priorities
that
we
do.
We
have
in
the
in
the
cmp.
Now
the
problem
actually
comes
in
the
data
path.
We
wanted
to
user
to
basically
be
able
to
arbitrary,
insert
a
priority
between
the
two
existing
priorities.
B
Now
the
problem
is
in
data
path,
a
lot
of
times
when
we
are,
you
know
reconciling
these
rules
right,
so
there
are
already
some
other
data
path
level
priorities
that
we
assign
to
the
current
priorities
that
creates
a
like
one-to-one
mapping.
So
the
rules
are
realizing
in
that
regard.
Now,
if
we
have
a
actually
a
bunch
of
new
rules
inserted
in
between
the
current
existing
priorities.
Now
the
problem
is
on
the
data
path.
B
If
the
original
parities
are
not
assigned
properly
or
smartly
a
lot
of
times,
what
you
would
need
to
do
in
datapass
is
that
you
need
to
sort
of
like
move
the
original
rules.
That's
how
I
originally
already
realized
on
beta
pattern.
So.
B
C
B
That
I
I
definitely
agree.
This
is
very
implementation
specific,
but
my
point
being
you
know
if,
if
you
know
on
the
other
cni's
right
and
we
needed
to
we
needed
to
evaluate,
if
you
know
introducing
this
kind
of
arbitrary
large
number
of
priorities
can
al
and
also
cause
churn
in
the
data
path.
And
if
so,
my
point
being,
if
we
do
wanted
to
introduce
power,
is
by
any
sort
we
needed
to
sort
of
like
put
a
cap
on
the
power
in
numbers
that
can
be
introduced.
B
Otherwise
it's
just
just
gonna,
be
you
know
this
incredibly
complex
problem
where
you
can
have
you
know
as
many
priorities
as
you
want
and
the
power
is,
can
you
know
we
can
insert
priority
in
between
the
current
powers
and
whatnot?
There
will
be
a
lot
of
chaotic,
chaotic
behavior
in
the
data
path
to
sort
of
like
rearrange
the
current,
so
the.
C
C
I
mean
there's
a
way
to
describe
a
graph,
and
there
are
many
ways-
and
there
are
many
tools
for
this,
so
it
really
depends
on
what
you're
using
ipa
tables
is
one
thing
if,
but
if
you
use
a
dedicated
firewall,
it
has
very
that
is
set
up,
for
these
sort
of
things
is
less
of
a
problem,
so
I
think,
with
I
mean
I
have
no
problem
saying
that
we
shouldn't
do
it
because
it
creates
problem.
Let's
say
with
the
most
common
used
tool
that
we
use
for
this.
C
A
That's
a
that's
a
super,
complex
problem
and
it's
looking
at
that's
in
a
super
explicit
case
right
when
you
the
way
you
all
define
network
policy
in
andrea
now,
the
flip
side
of
that
problem
is
looking
at
how
that's
explicit
for,
like
the
whole
picture,
you
can
figure
out
based
on
priorities,
how
your
network
security
stance
looks
in
kubernetes,
but
in
like
the
flip
side
of
things,
where
you
only
have
a
couple
actions
now
the
problem
is
a
little
abstracted
to,
rather
than
how
do
you
implement
it?
It's?
C
C
E
Yeah
yeah,
but
but
I
still
yeah,
I
just
want
to
go
back
a
little
bit
and
understand
in
your
initial
proposal.
There
was
only
two
priorities:
right
denies
was
executed
much
before
the
allows
so
deny
block
was
completely
separate
and
it
was
in
a
way
a
higher
priority
than
the
allow
block.
So
so,
and
that
was
solving-
I
mean
at
least
I'll
say
unless
you
create
a,
I
mean
some
some
impractical
condition.
It
was
solving
all
the
practical
problems
of
the
of
the
security
space
right.
So
why?
E
Why
did
the
discussion
move
from
these
two
explicit
priorities
to
this
kind
of
like
infinite
priorities
between
rules.
B
First
of
all,
I
don't
think
we
sort
of
wanted
the
the
priorities
to
be
infinite.
This
is
you
know
the
whole
point
I'm
trying
to
make
now
the
the
second
thing
is,
you
know
we
had
a
discussion
last
friday
on
the
current
state
of
the
cmp
cap,
with
a
lot
of
you
know,
other
people
from
you
know
different
cni's,
and
you
know
from
from
catechol
cedium
and
other
things
and
we
are
presenting.
You
know
this
three
actions
which
is
in
power.
B
Basically,
a
randomly
chosen
word,
for
example,
and
you
know
deny
and
allow
for
the
three
actions
to
see
if
those
three
actions
can
capture
all
the
use
cases
that
that
we
have
presented
for
the
cnp
problem
now,
a
lot
of
not,
I
would
say
there
are,
there
are
sanji
for
who's
in
the
car,
and
there
are
also
someone
if
I
remember
crackers
from
cateco
feeling
that
you
know
the
the
empower
keyword
is
sort
of
like
a
ad
hoc
keyword
and
it's
it's
a
little
bit
confusing
to
to
a
lot
of
like
new
users
or
existing
users.
B
For
for
that
matter,
because
they're
used
to
the
power,
the
numbering
and
not
to
those
keywords,
so
those
three
keywords
introduces
a
hard-coded
sort
of
like
poverty
or
precedence
model,
and
they
will
be
not
you
know
friendly
for
for
those
users
to
use.
B
But
I
I
see
also
there
are
people
who
are,
you
know,
liking
the
three
actions
proposal
which
sort
of
like
they
think
the
empower
can
sort
of
like
act
as
a
as
like
a
data
gate
action
to
tell
to
basically
say
for
the
cluster.
I
mean
I
don't
care
about
this
one
delegating
this
to
the
cross
out
to
the
kubernetes
network
policy
to
decide
what
should
be
the
denial
or
a
lot.
B
So
so
we
are
kind
of
like
still
debating
and
exploring
on
which
sort
of
like
approach
would
be
better
to
a
solve
all
the
use
cases
and
b
few,
as
is
user-friendly
for
all
the
users
across.
You
know
the
kubernetes
community
to
think
it
is
user-friendly.
F
Yeah
so
I'd
like
to
add
a
few
things.
Firstly,
thanks,
jan
for
explaining
the
issue
that
you
guys
had
to
deal
with,
and
that's
very
reasonable.
That
makes
sense.
F
I
think
the
way
we
ended
up
going
this
way
was
if
we
only
have.
Firstly,
we'll
come
back
to
empower,
but
if
we
just
have
deny
and
allow
either
we
have
to
decide
that
deny
is
always
higher.
All
deniers
are
always
higher
priority
than
all
allows,
or
all
allows
are
always
high
priority
than
organized
now.
F
If
we
take
the
approach
that
all
denies
we'll
come
back
to
empower,
but
let's
say
that
we
didn't
have
priority
numbers,
but
we
have
what
we,
I
think
we
more
or
less
agreed
that
there
should
be
more
actions
than
allow
and
the
first
action
would
be
deny.
So
if
you
have
deny
and
allow,
then
you
have
to
have
some
rule
as
to
whether
deny
takes
priority
or
allow
allow
take
priority
or
deny
or
there's
a
priority
number.
F
If
you
take
deny,
is
higher
priority
than
allow.
There
are
some
cases
that
don't
work.
Now
we
can
decide
whether
those
are
popular
common
or
not.
I
think
the
and
there
can
be
more
cases
one
example
would
be.
I
want
to
drop
all
udp
traffic,
except
when
it
comes
from
sources.
G
F
G
We
will
have
to
talk
about
empower,
it
has
to
be
a
reaction
in
order
to
action,
but.
C
E
Yeah
so
yeah,
so
so
sanjeev.
I
I
understand
that
see
I'll
tell
you
like
how
I
mean
we
had
a
similar
use
case
right.
How
we
did
it
is
like,
like
we
have
a
something
which
we
I
can
closely
relate
to
empower
deny
allow,
but
we
don't
really
call
it
empowered
denial.
So
we
basically
had
three
three
different
buckets
of
deny
allow
right.
E
You
have
a
top
level
deny
followed
by
allow
which
is
kind
of
equal,
so
I'm
talking
about
the
legacy
firewall,
but
I
think
that
will
apply
to
I
mean
I
think
the
use
cases
might
be
very
similar
in
this
kubernetes
environment.
So
we
have
a
top
level
deny
allow,
which
is
like
a
in
our
case,
the
the
like
a
cio,
so
top
admin
is
deciding.
This
is
my
deny.
I
don't
want
anybody
to
exclude
this,
so
you
have
three
blocks
of
deny
allow.
E
So
you
have
a
deny
allow
which
block,
which
is
called,
must
right.
Nobody
can
change
it,
and
then
you
have
another
deny
block,
which
is
very
close
to
your
empower.
That
is
recommended.
So
you
have
a
recommended,
allow
block,
which
is
which
is
always
at
the
bottom
and
in
between
the
local
administrators
are
free
to
add
their
deny
allows.
E
So
so
that
way
you
don't
have
priorities.
I
mean
you
have
a
priority
in
buckets,
but
you
don't
have
like
infinite
priorities
and
in
each
bucket
you
have
deny
followed
by
allow
I
mean
I,
I
know
we
can
simplify
a
lot
from
there,
but
I
think
we
need
to
take
a
middle
ground
somewhere
from
infinite
possibility
of
priority,
because
that
becomes
very
difficult
for
the
users
to
look
into
each
and
every
policy
to
understand
really
what
is
happening.
G
G
Actually
I
do,
but
it's
not
the
focal
point,
but
I
do
care
about
the
complexity
in
creating
policies
from
a
user's
perspective
and
and
that's
why
we
wanted
to
find
a
middle
ground
between
simply
allow
and
whitelist
isolation
policy
that
network
policy
has
and
infinite
priorities.
So
I
think
that's
why
we
came
up
with
this
three
priority
solution,
which
kind
of
addresses
all
use
cases.
G
So,
with
the
three
actions
we
we
think
that
it
will
be
much
easier
for
you
know
once
user
understands
what
these
prior,
these
three
three
separate
priorities
are,
for,
I
think,
creating
or
crafting
policies
which
will
be
much
easier
as
compared
to
and
much
more
maintainable
over
the
long
run
as
compared
to
single
priorities,
and
I
think
we
also
mentioned
that-
probably
that
I
don't
know
if
young
already
mentioned
this
not,
but
with
the
single
with
infinite
priorities,
I
think
doing
something
like
name
space
isolation
and
you
know
not
explicitly
allowing
intra
namespace
becomes
a
bit
of
hard
to
manage
that.
G
F
So
it's
having
things
like,
you
know,
multiple
blocks
of
denial.
All
of
those
are
tied
to
different
personas.
We
we're
here,
firstly
we're
talking
about
the
number
of
actions
that
is
single
persona
in
this
case,
we're
talking
about
just
the
cluster
admin
right,
all
those
other
scenarios
like
okay,
I
can
have
three
blocks.
The
first
block
is
for
the
admin
the
second
block
is
for
the
tenant.
The
third
block
is
for
the
developer,
whatever
all
those
are
slightly
orthogonal,
because
they
are
applying
to
different
personas
right.
F
So
we
have
already
decided
that
this
we're
talking
about
the
single
person
called
cluster
admin.
The
cluster
admins
policies
take
higher
priority
over
the
developer
or
the
tenant
tenant
level
person's
priorities.
So
we
do
have
that
block
level
thing
now
within
a
block.
Okay,
I'm
just
putting
out
the
point
that
if
you
statically
have
just
organized
priority
overall
allows
or
all
allows
priority
one
to
realize
there
will
be
cases
that
don't
work
okay
and
we
can
decide
whether
those
are
sufficient
to
you
know
limit.
F
We
can
live
with
those
or
not,
and
that
is
why
most
other
acl
vendors
they
take.
F
If
you
look
at
benign
allow
you
are
assuming
that
you
are
always
all
your
denies
are
equivalent,
so
they
can
be
in
any
order
and
all
your
allows
are
equivalent.
They
can
be
honored,
so
you're
sort
of
avoiding
the
issue
by
just
saying
defining
your
policies
by
just
you
know,
all
denies
are
equal
and
all
the
laws
are
equal
and
all
denies
are
higher
priority
than
all
allows.
F
So
the
point
was
that,
firstly,
yes,
I
I
do
appreciate
the
point
that
young
is
saying
which,
which
makes
sense
and
as
far
as
okay
so
now
coming
back
to
empower.
F
The
first
thing
is
that
I
thought
that
we
may
have
interpreted
empower
slightly
differently.
At
least
I
may
have
slightly
interpreted
differently
before
the
friday
call,
so
I
want
to
be
clear
on
the
meaning
of
empower
right
now.
Okay,
if
the
meaning
of
empower
is
this,
this
should
be
decided
by
the
network
policy
right.
That
means
this
is
that
means
we
haven't
really
done
anything
from
the
cluster
network
policy.
Perspective
empower
is
not
giving
you
a
third
action
within
cluster
network
policy.
F
It
is
saying
admin
doesn't
care,
let
the
net
the
name
space
handle
it.
The
admins
actions
are
still
denies
and
allows
only
empower
is
not
a
third
action
for
the
ad
well,
it
is
sort
of
third
action
for
the
admin,
but
it's
not
a
third
action
for
the
deny
allow
rules.
Admin
can
still
do
only
denies
and
allows
so
he
still
has
to
have
some
logic.
F
B
Yeah,
I
I
I
think
I
understand
your
point
century.
I
think
you
know
the
the
the
question
on
the
question
on
the
empower
thing
is
that
you
know
empower,
doesn't
really
serve
as
a
strong
allow.
That's
above
deny,
so
we
have
two.
F
Sorry
to
interrupt,
let
me
just
say
we
were
using
the
third
key
word
differently
in
the
past,
and
now
we
are
using
it
like
a
delegate
right,
empower
equals
delegate.
Okay,
that
admin
doesn't
care
about
it,
but
he
he
lets.
I
mean
he
sort
of
cares
about
it,
but
he
lets
the
name.
Space
developer
do
what
he
wants
with
it,
but
that
hasn't
really
solved
the
deny
exception
problem.
What
we
were
doing
with
the
third
action
in
the
past
was
a
deny
exception,
so
that
then
you
can
have
a
super
allowed
deny
and
allow.
G
So
here's
here's
what
I
wanted
to
say
on
the
friday
call,
but
we
didn't
have
enough
time.
You
know
there
were
two
school
of
thoughts
for
the
empower
one
is
where
some
people
understood
it
as
a
way
to
delegate
policy
or
rules.
G
The
other
set
of
people
understood
it
as
a
way
to
provide
exceptions
to
the
denial,
and
the
answer
is,
it
is
actually
doing
both
it
is.
It
is
trying
to
empower
the
namespace
administrator
or
sorry
namespace
developers
by
you
know,
skipping
or
providing
exceptions
to
to
the
admins
deny
rules.
So
you
know
I
have
this
whole
set
of
deny
block
that
I
don't
want
the
traffic
to
be
accepted
or
you
know
going
to,
but
here's
a
piece
of
that,
a
big
block
which
I
want
the
administrators
to
decide.
G
Oh
sorry,
in
the
name
space
owners
to
decide
for
themselves,
so
it
is
providing
an
exception
to
the
whole
deny
by
providing
the
ability
to
or
giving
the
ability
to
to
the
developers
by
deciding
for
themselves
whether
they
want
to
explicitly
allow
it
or
they
want
to
isolate
it
using
some
default
denies
on
those
parts.
So
it
is
kind
of
both,
and
I
I
that's
what
I
wanted
to
bring
bring
it
up.
G
The
only
thing
that
it
doesn't
do,
which,
which
I
agree
and
which
you
know
something
that
we
need
to
work
on,
is
that
if,
if
the
namespace
owner
does
not
decide
to
take
any
action,
it
is
always
an
allow.
We
may
want
to
also
make
sure
that
you
know
if
the
administrator.
Sorry,
if
the
namespace
developer
is
not
allowing
or
is
not
acting
upon
that
exception,
then
perhaps
there
is
a
use
case
where
we
would
also
want
to
deny
it
and
not
just
do
a
plain
allow
as
the
default
rules.
G
Initially,
we
thought
that
default
network
policy
could
satisfy.
It
could
be
used
for
that
use
case,
but
you
know
again
that's
a
different
conversation
where
we
want
whether
we
want
to
have
two
separate
crds
or
not
so
so,
but
I
think
there
is
room
for
for
us
to
clarify,
empower
and
maybe
extend
it
so
that
we
don't
need
a
dnp,
and
we
use
this
particular
action
field
to
to
do
something.
Something.
B
G
Sort
right
where,
where
the
disposition
is
kind
of
taken
like
is
configurable,
I
haven't
thought
through
this,
and
you
know
to
be
honest
after
the
friday
call
towards
the
end
of
the
around
evening.
G
On
friday
evening
tim
and
I
tim
horton
and
I
had
a
chat
and
we
we
kind
of
like
I
think
he
laid
out
this
particular
half-baked
idea
around
clarifying
the
empower
use
case
wherein
you
know
which
may
lead
us
to
not
needing
dnps
and-
and
I
think
you
know
when
sanjiv
was
trying
to
say
that
it
was
not
clear
whether
empower
is
exception
or
whether
empower
is
a
way
to
delegate.
I
think
it's
both
and
I
think
we
should
clarify
that.
G
So
maybe
you
know,
one
of
the
things
that
I
want
to
do
this
week
is,
with
the
team,
sit
down
and
kind
of
clarify
this
empower
block
a
bit
and
and
see.
If
we
can,
you
know,
take
tim's
idea
and
kind
of
like
fully
bake
it
and
if
it
makes
sense-
and
we
can
see
if,
if
that
can
be
altered
and
added
to
the
proposal.
E
Okay,
I
appreciate
so
so
in
in
at
least
in
some
part
of
the
v2
discussion
and-
and
we
took
sanjeev's
example
of
udp,
in
consideration
right
so
based
on
that
we
actually
in
the
video
we
had
written
a
proposal
which
andrew
has
just
pasted
on
this
slide.
I
have
requested
you
to
see
this
because
we
thought
of
all
those
scenarios,
and
at
least
we
think
that
it
solves
those
scenario
without
introducing
too
many
cardinalities
in
the
priority
space.
F
E
F
B
C
E
Yes,
so
so
the
idea
was
pretty
simple
and
I
think
cnp
actually
captures
a
lot
of
things
you
see
we
want
from
from
the
cnp
perspective
or
the
cluster
admins
perspective
right,
a
definite
behavior
in
certain
aspect
right
as
a
cluster
admin.
I
want
to
deny
certain
traffic
and
I
want
to
allow
certain
traffic.
E
Let's
say
I
want
to
allow
traffic,
because
I
am
monitoring-
and
I
want
to
allow
traffic
that
all
board
should
be
reachable
to
the
monitoring
thing,
whether
you,
whether
there
is
a
case
or
not,
but
I
think,
as
a
cnp
admin,
I
want
some
traffic
to
be
always
allowed
as
some
traffic
to
be
always
denied.
That
goes
in
the
must
block.
That
is
non-negotiable.
E
After
that
I
have
some
recommendation
like.
If
I
want
to
put
my
monitoring
block
in
the
recommendation,
I
can
say:
okay,
all
pods
should
be
able
to
go
to
the
monitoring
block,
but
if
one
network
name
space
admin
does
not
want
that
they
can,
they
can
override
that
what
they
cannot
override
is
the
must
block,
but
last
block
which
we
call
recommended
block,
is
very
similar
to
empower.
But
it's
like
a
recommendation.
G
Yeah
so
name,
I
think
your
bottom
block
is
what
we
have
proposed
as
default
network
policy.
So,
and
not
really,
an
empower
empower
is
actually
part
of
the
stricter
rules,
which
is
the
top
block
where
you
you
have
your
deny
rules,
but
you
don't
want
certain
certain
traffic
within
those
deny
rules
as
sorry,
you
have
deny
rules
and
you
have,
like
certain
exceptions
to
those
denials.
So
your
empower
is
kind
of
like
that.
The
exception
to
that
denial,
which
is
kind.
A
G
E
No,
we
were
actually
denying.
First,
I
mean
we
were
having
all
the
denies
first
and
then
allowed
okay,
so.
G
How
how
do
you
propose
to
do
certain
exceptions
to
tonight?
For
example,
you
might
say
that
you
know
deny
every
traffic
from
cube
system,
name,
space
or
tooltube
system
ninja,
and
just
this
might
be-
is
a
very
hypothetical
scenario,
but
deny
every
traffic
from
cube
system
game
space,
but
allow
the
core
dns
spots
to
be
able
to
talk
from
cube
system
dangerous.
How
would
you,
how
would
you,
how
would
you
write
that
rule
with
your
denial
and
that.
F
F
F
G
Specialized,
I
think
the
cnp
case
is
like
a
simplified
version
of
what
nadeem
is
trying
to
propose.
Nadim
is
doing
it
for
many
personnels,
but
if
you,
if
you
just
you
know,
say
that
they're
in
my
cluster
there
are
only
two
personas,
which
is
the
cluster
admin
and
the
namespace
owner.
Then
it
kind
of
like
boils
down
to
the
cnp
approach,
which
is
what
we
are
trying
to
propose.
G
So
if
we
and
then
you
know
v2,
maybe
I
have
not
looked
at
that
document
yet,
but
maybe
you
know,
but
at
least
based
on
the
discussion
it
seems
like
you
know,
this
is
like
the
simplified
version
of
nadeem's
proposal,
but
with
the
ability
to
provide
exceptions
to
deny.
F
Yeah,
so
I
think
the
key
point
here
again
just
to
make
sure
we
are
on
the
same
page,
is
that
cluster
admin,
the
cluster
network
policy
right
now.
Our
primary
discussion
is
everything
to
do
with
the
cluster
admin
persona
and
the
cluster
admin
persona
without
having
to
depend
upon
what
the
name
space
guy
might
or
might
not
do
wants
to
have
these
capabilities.
He
wants
to
be
able
to
strongly
strongly
deny
and
make
exceptions
without
knowing
what
the
namespace
guy
might
or
might
not
choose
to
do,
because
he
has
no
control.
F
G
Right
so
now,
so
this
is
the
use
case
and
you've
covered
correctly
summarized
it
so
denying
all
traffic
can
be
done
with
the
denial
allowing
all
traffic
can
be
done
within
allow
room
and
providing
exceptions
to
the
deny
can
be
done
with
an
empower
rule,
and
that
is
what
I
want
to
is
meant
to
provide
exceptions
to
that,
to
those
deny
rules
and
by
by
you
know
the
basic
waterfall
model.
G
Okay,
if
you
don't
really
have
an
allow
for
the
that
particular
exception,
then
you
know
it
kind
of
falls
to
the
waterfalls
through
to
the
name
space
owner,
whether
he
wants
to
deny
or
allow
it,
and
if
he
doesn't,
then
it's
you
know
whatever
the
default
policy
for
the
cluster.
What.
F
G
G
F
G
F
G
F
Let's
dig
into
it
again:
empower
means
you're,
letting
the
name
space
guy
do
something
for
you.
No.
G
No,
no,
no
I'm
saying
if
we
go
to
the
precedence
diagram,
I
don't
know
who's
sharing
it.
G
I
have,
I
have
always
been
saying:
the
empower
is
a
way
to
provide
exceptions
and
to
delegate
now
we
can
look
at
the
andrew
if
you,
if
you
want
to
you,
can
share
these
so
so,
essentially,.
B
I
guess
our
point
is
for
the.
G
B
For
the
same
part
of
traffic,
if
there
is
no
allowance,
then
empower
is
essentially
a
data
gate.
But
if,
in
the
specific
case
that
you
just
mentioned,
we
have
it
in
power
and
allow
on
specific
traffic,
which
is
utp
from
b
and
c,
then
it's
a
strong
allow.
Does
that
make
sense,
so
the
dedication
only
happens
when
you
don't
have
a
allowed
run
the
same
thing
and
you
have
it
in
power.
Now
it
basically
just
falls
into
the
namespace
kubernetes
policies.
Sorry
delegation
happens
when
you.
F
B
B
G
Can
we
can
we?
Can
we
go
through
this
precedence
model?
So
let's
say
your
traffic
matches
your
exception
rule
right,
which
is
you
want
to
say
it's
an
you
know.
Any
traffic
coming
from
app
role,
sorry
app
db
should
be
allowed.
Let's
say
for
simplicity
right
is:
is
that
a
fire
assumption.
G
G
Got
it
so
now
you
have
a
you
know,
a
very
wide
rule,
which
is
a
cnp
deny
root
which
drops
traffic
from
all
labels,
and
you
would
create
an
empower
rule
to
provide
that
exception,
which
is
from
this
particular
label.
So
now
that
that
empower
rule
becomes
an
exception
to
your
you
know,
catch-all
deny
rule
so
what
it
does.
If
you
look
at
the
flow
chart,
does
it
match
to
the
empower
rule?
Yes,
so
it
goes
to
the
next
action,
which
is
the
allow
rule
now
here.
G
I
just
don't
want
it
to
be
denied,
as
per
my
right.
That
was
your
second
intention.
In
that
case,
you
do
not
create
such
an
allowance
and
then
it
will
not
match.
So
it
will
go
to
the
network
policy
and
let's
say
you
don't
have
any
rules,
it
just
keeps
on
going.
No,
no,
no!
No!
No
all
the
way
to
the
cluster
default.
F
F
G
G
That
way,
that's
not,
I
think,
the
strict
way
of
doing
it,
the
the
most
common
way
of
doing
this
would
be
namespace
isolations
wherein
or
the
tenancy
isolation
model
wherein
the
namespace
sorry,
the
administrator
will
have
like
these
boundaries
for
tenancies,
within
which
the
traffic
may
or
may
not
be
allowed,
but
at
least
inter
namespace
boundaries
or
inter
tenant
c
boundaries
will
definitely
not
be
allowed.
So
that's
the
main
use
case
I
feel,
like
the
users
will
use
this
one.
F
G
F
F
G
Ask
the
group
whether
what
I'm
trying
to
say
is
was
that
totally
gibberish,
or
you
know
why
this
procedure
is
first
of
all,
is
this
precedence
model
not
clear
if
we
take
an
example,
and
we
will
definitely
work
on
this
diagram.
B
So
so,
if
you,
if
you
guys,
look
at
what
I
posted
on
the
chat,
I
I
listed
out
for
sanjeev's
specific
case.
What
will
happen
if
we,
for
there
were
two
cases
right?
One
is
that
we
wanted
to
deny
udp
traffic
from
everywhere,
except
for
amb.
I
wanted
to
ensure
those
udp
traffic
are
always
allowed,
and
the
second
case
is
that
I
wanted
to
deny
all
udp
traffic,
except
for
udp
traffic
from
a
and
b,
and
I
don't
care
right.
So.
B
So
so,
if
we
have
those
three
three
rules
for
the
strong
allow.
One
is
for,
first
of
all,
for
a
and
b
for
a
and
b
udp
traffic,
we
empowered
meaning
that
we
go
surrounded,
deny
and
the
rule
three
strongly
allows
that
so
there's
no
way
namespace
users
can
override
this
allow
rule,
because
it's
on
a
higher
presence
than
the
namespace
rules.
B
Now,
for
the
other
udp
traffic,
it
will
hit
the
two
number
two
rule
which
will
be
denied
on
the
set,
on
the
other
hand,
for
the
dedication
problem
right,
we
haven't
denied
all
udp
traffic,
but
we
have
a
empower
udp
amb,
so
those
traffic
will
go
to
the
kubernetes
names
now,
policy,
precedence
level
and
then
that
namespace,
that
means
can
do
whatever
they
want
on
the
udp
traffic
on
amb,
because
that's
a
dedication,
it's
literally
saying
that
I
don't
care
because
I've
empowered
it
and
I've
not
allowed
it
specifically.
B
So
that's
a
delegation,
so
I
guess
the
only
confusion.
Part
now
is
that
when
an
a
when
a
cluster
admin
wants
to
explicitly
strong,
allow
something-
and
there
is
a
actually
a
denial
in
place-
he
or
she
will
need
to
do
an
empower
and
a
strong
allow
at
the
same
time,
in
order
for
him
to
do
that,
but
other
than
that
you
know,
the
president's
model
feels
like
really
straightforward
to
me.
A
F
A
Like
a
total
is
is
maybe
based
on
the
current
spec,
the
yemel
examples
of
both
these
cases,
with
the
current
you
know,
readout,
so
that
you
could
see.
Is
this
going
to
be
too
complicated
for
me
like
I,
I
have
a
the
diagram
president's
model
makes
total
sense.
I
have
a
hard
time.
You
know
really
talking
about
complexity
of
use
until
I'm
writing
ammo.
That's
just
me
so
yeah.
F
A
G
Do
it
yeah
so
so
sanji
can
I
can
I
ask
you
whether
these
four
use
cases
are
everything
that
requested
administrator
would
do
a
strong,
deny
a
strong,
allow,
a
deny
but
exception,
and
it
deny
but
delegate
are
these
four
broad
topics
covering
all
the
things
that
an
administrator
would
want?
Is
that
is
that
fair.
G
F
E
C
B
For
example,
or
maybe-
or
maybe
it's
just
something
that
you
know
as
a
compliance
reason
required
right,
so
I
wanted
to
strong,
allow
everything
from
from
and
to
promise
use
namespace
and
the
users
cannot
do
a
kubernetes
network
policies
to
say.
Okay,
I
want
don't
want
to
talk
to
the
promises
name
space.
They
cannot
do
that.
That's
when
we
actually
needed
a
strong
allow,
but,
but
so
with
the
the
reason.
The
the
only
time
when
we
needed
a
strong
allow
paired
with
an
empower
is
when
we
have
a
deny
or
rule
right.
C
E
Yes,
so,
and
so
one
question
I
have
I'm
still
not
clear:
why
do
we
need
this
delegate
if
we
already
have
the
dnp
covering
the
the
allows
which
can
be
denied
by
name
space,
admin.
B
We
are
essentially
hoping
that
you
know
with
some
turk
in
in
this
keywords:
we
can
actually
ditch
the
dmp,
so
I
I,
as
I
understand
this,
is
what
app
shack
is
saying
all
of
the
discussion
with
tim
last
week.
A
G
So
I
can
maybe
give
a
stab
at
this,
essentially
the
the
reason
why
you
would
want
to
delegate
certain
things
so
think
about
name
space
isolation,
where
you
want
to
provide,
inter
name
space,
isolation,
basically
saying
that
coke
should
not
be
allowed
to
talk
to
pepsi,
but
you
don't
necessarily
want
to
make
the
decision
for
the
coke
itself.
So,
for
example,
if
you
are
going
to
say,
I
want
coke
not
to
talk
to
pepsi,
but
everything
within
coke
to
talk
to
each
other
by
strong.
G
Allow,
then
a
network
policy
owner
of
that
coke
name.
Space
cannot
write
isolation,
rules
within
his
own
name
space
because
it
will
never
be
matched
because
an
allow
strong
allow
will
always
allow
this
intra
name
space
traffic.
In
this
case,
you
would
want
the
name
space
owner
to
maybe
you
know
what,
within
my
code,
boundaries,
I
want
to
have
certain
parts
which
needs
to
be
isolated,
and
I
will
use
my
kubernetes
network
policies.
E
Yeah,
so
if
we
replace,
I
mean
the
dnp
at
the
bottom
block
I'll
call
it
something
like
a
week.
G
Yeah,
so
I
think,
as
young
mentioned,
the
dnp
is
something
I
think
some
folks
in
the
community
also
are
kind
of.
You
know
on
the
fence
when
it
comes
to
supporting
two
crds.
So
so
that's
why
you
know
the
the
core
of
there
are
a
few
things
that
I
spoke
to
tim
about,
and
one
of
this
was
the
dn.
Sorry,
the
the
ability
to
maybe
extend
and
power
to
also
provide
some
sort
of
default
rule
so
that
we
don't
need
a
dnp
or
maybe
we
can
we
can.
G
G
Also
wanted
to
bring
up
quickly,
because
we
have
only
three
minutes
is
that
we
have
decided
to
remove
ip
blocks
from
this
proposal.
External
traffic
for
for
very
good
reasons,
but
I
think
tim
was
kind
of
very
you
know
not
so
happy
about.
One
particular
aspect
of
that
is
that
it
allows
so
we
are
propositioning
this
cluster
network
policy
as
a
guard
rails
to
developers
right.
You
know
we
kind
of
like
want
to
make
sure
that
developers
don't
overstep
or
create
these
security
rules,
which
could
be
a
security
hazard.
G
So
the
cluster
network
policy
should
encompass
this.
Now
the
clust,
the
the
default
network
policy
is
able
to
sorry
not
default.
The
the
kubernetes
network
policy
has
ipv
blocks
and
if
a
cluster
network
policy
cannot
lock
down
those
external
traffic
name,
space
owners
can
write
an
ip
block
rule
and
bypass
this
traffic
and
still
be
able
to
talk
to
outside
world.
G
F
G
Mainly
for
ingress
or
egress,
doesn't
mostly
it
will
be
for
egress
because
you
know,
but
you
know
that's.
G
A
Administration
but
hear
me
out,
I
I
think
you
know
this
is
an
unfortunate
situation
where
the
mistakes
of
network
policy
are
being
thrown
at
us
and
I
think
it
can
be
solved
by
either
making
this
cluster
network
policy
kept
more
complicated
and
confusing
or
segmenting.
The
problem
like
it
should
be
done.
This
should
have
been
done
originally
into
another
object.
That's.
G
So
I
proposed
to
him
something
which,
without
com,
making
our
cnp
more
complex
was
that
we
have
a
way
to
differentiate
between,
in
you
know,
intra
cluster
traffic
versus
cluster
external
traffic
by
doing
like
an
empty,
selector
or
sorry,
not
an
empty
selector,
but
an
empty
egress
rule
or
an
empty
ingress
rule.
So
essentially,
if
we
have
something
like
that,
where
we
we
have
the
ability
to
say
that
an
empty
ingress
rule
or
a
negros
rule
means
all
traffic,
not
just
intra
cluster
traffic.
G
On
the
other
hand,
if
you
want
to
just
talk
about
intra
cluster
traffic,
you
have
an
empty
game,
space
selector,
and
that
would
only
mean
that
you're
talking
about
only
internet,
so
here
it
means
we
can
do
all
or
nothing
external
infrastructure,
and
I
think
he
was
okay
with
that.
But
I
also
wanted
to
bring
this
up
to
the
group,
and
you
know
I
was
going
to
further
propose
this
during
the
thursday
meeting.
A
G
G
Yeah,
so
I
think
that's
where
andrew
was
trying
to
say
that
it's
unfortunate
that
kmp
does
support
it
without
having
had
too
much
of
thought
into
it.
But
you
know
a
couple
of
weeks
ago
in
the
sig
network
meeting.
I
think
there
was
a
lot
of
discussion
around
how
to
handle
ingress
traffic,
which
is
cluster
external,
because
what
happens
is
there
is
a
lot
of
netting
that
will
happen
before
the
packet
actually
reaches
your
cluster,
so
you're,
essentially
losing
out
onto
that
original
source.
G
Ip
and
the
behavior
is
not
defined,
and
because
of
this,
it's
it's
a
bit
of
you
know
we
are
to
support
ip
blocks
in
cnp,
because
we
don't
want
to
make
the
same
mistake
and
we
are
hoping
that
we
can
come
to
a
good
agreement
in
terms
of
what
the
expectation
should
be
for
ip
blocks
with
v2
and
cnp.
G
A
At
least,
let's
talk
about,
let
I'll
add
that
to
the
agenda
for
next
time
in
the
game.
I
think
it's
something
cool
which
we
can
talk
about.
I
know
we
are
a
minute
over
time.
A
One
thing
that
may
help
at
least
resolve
the
discussion
we
were
going
over
today
with
actions
is
how
about
sanjeev
makes
attempt
of
a
proposed
yaml,
for
you
know
a
priority
implementation,
while
avocet
comes
back
with
a
proposed
yaml
with
this
three
action
implementation,
and
we
can
kind
of
look
at
it
from
a
user
pov
right
and
say
what
is
more
intuitive
for
a
user
to
write
and
to
read
right
and
we
can
narrow
it
down.
Just
on
this
one
case
we
were
talking
about
like
throughout
the
meeting
today.
F
A
F
Yeah,
so
that
that's
where
I
was
trying
to
sort
of
bring
out
this
point
about
the
exceptions
versus
the
delegation
and
all
that
and
that
that
that
discussion
was
a
little
bit
mixed,
so
I
can
just
sync
up
with
abhishek
a
little
bit
because
you
know
looks
like
he's,
had
some
more
follow-up
after
that.
So
maybe
we'll
try
and
converge
to
some
level
of
commonality
offline,
and
we
can
summarize
that
in
a
follow-up
call,
whether
that
means
yaml
or
whether
that
means
something
else,
let's
not
predefine
that
right
now.
F
I
definitely
appreciate
all
the
points
that
young
and
abhishek
makes.
So
it's
all
good
stuff.
So
here's
a
sign
and
we'll
summarize
it
in
the
following.
G
So
here's
is
what
I
plan
to
do.
Maybe
in
the
next
couple
of
days
I
will
update
this
agenda
with
some
use
cases,
because
that
was
anyways
on
our
action
item.
Just
to
have
more
specific
use
cases,
I
will
try
to
bring
up
at
least
a
few
specific
use
cases
and
then,
by
monday
meeting
I'll
also
try.
You
know
me
young
and
others
will
satish.
Also
we
will
try
to
come
up
with
the
sample
specs
for
those
use
cases
and
sanji.
G
We
can
come
up
with
the
priority
based
and
also
feel
free
to
add,
more
use
cases
you
know
for
those
which
I
have
missed,
keep.
F
Of
the
priority
case-
and
you
guys
we
are
all
the
owners
of
this
whole
thing
right,
the
point
is,
but
someone
someone
has
to.
I
would
love
to
work
on
that
as
long
as
it
addresses
the
issues
right,
I
mean
whatever
three
priorities.
We
will
only
know
once
we
write
some
samples
right,
I
mean
unless
we
don't
write
it,
we
don't
know.
G
G
F
A
A
F
I
gave
one
example,
but
we
I
I'll
I'll
think
about
it,
some
more
and
also
if,
if
it's
okay
with
abhishek
young
singapore
offline,
because
I
think
there's
also
two
or
three
confusing
threads
here-
one
is
the
overloading
of
the
delegation.
One
is
the
strong
allow
with
exceptions
so
yeah
we
will
sort
it
out,
but
but
in
terms
of
ordering
I
mean
that's
pretty
clear,
I
mean
people
know
what
it
is.
F
F
A
Right-
and
I
think
the
last
point
I'd
like
to
like
leave
on
for
everyone
is
dan
winship-
did
bring
up
an
interesting
idea
that
was
kind
of
an
intersection
of
these,
which
was
you
know,
a
priority
ordering,
but
with
predefined
priorities
that
could
be
extended
upon.
So
you
start
with
just
maybe
zero
and
one
as
the
only
priorities
that
are
allowed
and
then
in
the
future.
If
we
need
to
extend
them,
we
can't
extend
them.
So
that
was,
I
thought,
an
interesting
middle
ground
in
between
these
two.
You
know
yeah.
F
A
F
Always
say
that
you
know
we
allow
10
priorities
and-
and
if
you
want
to
further
insert
something
in
the
middle
too
bad
you'll
have
to
just
equal
to
one
of
the
existing.
I
mean
what
we're
doing
with
buckets
is
also
priorities,
just
three
priorities,
so
yeah
again
not
to
harp
too
much
on
the
priorities.
But
I
think
we
there's
two
or
three
different
points
here
about
the
delegation
versus
the
super
law
and
exceptions.
So
we
will
sort
it
out
offline
by
the
end.
Also,
by
the
time
of
next
week's
call.