►
From YouTube: Network Policy API Meeting 20210802
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
Awesome
hello:
everyone
today
is
august
2nd
2021.
This
is
a
meeting
of
the
sig
network
policy
subgroup
of
sig
network.
It
is
a
cncf
certified
meeting.
So
please
be
nice
to
everyone
and
let's
have
a
good
meeting
today,
so
going
ahead
and
getting
started.
I
will
share
my
screen
and
I'll
try
to
just
take
notes.
Some
notes
during
this
discussion.
A
Well
actually
yang's
going
to
be
sharing
his
screen
for
the
presentation,
so
I'll.
Just
try
to
take
notes
during
this
discussion.
A
We're
revolving
around
cluster
network
policy
for
people
who
are
just
tuning
in
this
discussion
started
last
week
over
a
presentation,
abashik
and
yang,
spearheaded
and
put
together-
and
you
know
we're
just
trying
to
agree
on
use
cases
as
a
group
and
then
look
at
two
different
implementation
paths.
One
kind
of
push
forward
by
sanji,
then
one's
pushed
forward
by
yang
and
abhishek.
A
Permissions
and
you
should
have
co-host
permissions
and
feel
free
to
present
I'll,
be
taking
notes
along
the
way.
Does
anyone
have
any
questions
before
we
get
going
about
today?.
B
Oh
okay,
thanks
andrew,
so
essentially
what
I
wanted
to
do
first
today
is
that,
as
many
of
you
are
in
the
meeting
last
week,
we
have
been
presenting.
You
know
those
use
cases
for
the
cluster
network
policy
or
I
should
say
you
know
typical
traffic
patterns.
That's
the
the
cluster
network
policy
are
supposed
to
regulate
and
we
try
to
sort
of
like
condense
them
down
to
those
bullet
points
which
is,
you
know,
straight
denied,
spread,
allow
and
blah
blah
blah.
B
But
in
the
last
monday's
meetings
I
hear
a
lot
of
people
find
it.
You
know
really
confusing,
namely
between
the
third
and
the
fourth
item,
which
is
straight
deny,
but
allow
exception
and
straight
deniable
data
gate.
The
term
data
gates
sort
of
like
confused
a
lot
of
people
on
what
they
actually
mean
and
how
you
know
three
and
four
differ
from
one
and
two.
B
So
we
had
a
like
a
internal
cost
now
policy
discussion
on
on
for
on
thursday,
and
I
think
sanjeev
pointed
out
that
a
picture
might
help
clear
a
little
bit
on
the
use
cases
or
at
least
the
traffic
patterns
that
we're
depicting
here.
Otherwise,
you
know
people
can
really
get
confused
on
what
those
things
mean.
So
I've
put
together
a
quick
picture
over
here
to
see
if
it,
you
know,
clears
everybody's
mind
on
what
those
use
cases
are.
So
this
is
following.
B
You
know
a
network
policy,
api
repo.
We
have
a
couple
of
you
know
pr's
on
the
network
policy,
api
repo,
one
of
the
use
cases
was
10
and
iso
10
and
name
space.
Isolation
and
sanjeev
originally
put
up
a
good
depiction
of
the
namespace
tenant
tenant
namespace
model
there
and
I've
done
a
little
bit
of
coloring
and
stuff
and
which
is
you
know,
trying
to
explain
what
the
you
know
strict
deny
and
allow
and
dedicated
what
what
is
all
those
traffic
that
is
going
on.
B
So
essentially,
you
know
we
are
looking
at
the
more
complex
model
of
of
the
you
know.
Cluster
network
policy,
which
is
you
know
with
the
known
overrideable,
denies
already
in
place
for
the
namespace
boundaries.
B
Oh
sorry,
I
should
say
tendon
boundaries,
so
essentially
what
this
strict
deny
and
strict
allowing
first
of
all
is
that
you
know
if
we
have
no
namespace
or
tenant
boundary
isolations,
then
the
traffic
becomes
pretty
easy
right
because
you
would
either
want
to
strictly
deny
on
the
specific
traffic
which,
as
we
listed
here,
is
a
part
carrying
sensitive
data
from
namespace
named,
isolate
me
right,
those
those
are
kind
of
very
specific
parts
or
or
namespaces
or
workloads
that
you
wanted
to
just
deny,
or
you
have
things
you
wanted
to.
B
You
know
strictly
allow,
for
example,
the
core
dns
parts.
Now
those
are
sort
of
like
non-overrideable
rules,
which
basically
just
means
kubernetes
network
policies
should
now
be
override
those
rules,
but
the
tricky
thing
is,
you
know
when
strict
deny
and
strict
law
are
are
together
on
some
of
the
traffic
patterns
which
takes
precedence
right.
So
this
is
a
problem
you
know
very
present
can
be
illustrated
right
here
right,
so
you
have,
you
know
two
tenants.
B
B
Now
the
first
thing
you
wanted
to
do
is
a
known,
overrideable
deny,
which
means
that
in
a
lot
of
cases
you
know
the
cluster
means
may
want
those
tenants
to
be
strictly
isolated
with
each
other,
so
those
non-overrideable
denies
are
depicted
by
in
the
red
border
here
on
the
namespaces,
meaning
that
you
know
for
for
ten
and
one
and
ten
and
two
they
cannot
talk
to
each
other,
and
this
is
a
strict
and
non-overwriteable
deny.
But,
as
you
can
see,
if
you
have
you
know
this
strict,
no
overrideable
deny
around
those
tenant
name
spaces.
B
Then
the
coop
system,
coupe
dns,
will
also
be
denied
if
it's
not
sort
of
like
allowed
on
purpose
right
and
also
there's
another
use
cases.
B
That's
that's
I
think
originally
brought
up
by
sanjeev
is
that
if
you
have
some
public
service,
which
is
a
service
hosted
by
another
tenant-
and
there
may
might
be
cases
where
another
tenant's
part
may
need
to
actually
talk
to
those
services,
so
this
will
be
sort
of
like
an
exception
to
the
known
non-overrideable
denies
that
we
must
need
to
sort
of
capture
so
that
you
know
those
things
are
not
strictly
denied
and
in
some
cases
you
know
it
will
be
allowed.
B
So
this
is
what
we
depicted
here
as
three
different
kind
of
traffic
versus
non-overratable
deny,
which
is
the
red
boundaries
over
name
spaces.
Now
there
are
two
different
kinds
of
like
holes
or
exceptions.
We
wanted
to
provide
to
those
known
override
wood
knives,
and
one
is
what
we
call
the
data
gate
exceptions,
and
this
is
depicted
by
the
by
the
yellow
lines
here.
Essentially,
what
that
means
is
that
you
know
this.
B
So
if
a
tenant
one
namespace
owner
comes
in
and
he
or
she
decided
okay,
we
don't
actually
wanted
to
use
the
service
public
on
another
namespace
and
for
security
reasons.
We
actually
want
to
deny
this
traffic,
so
the
namespace
admin
would
use
a
kubernetes
network
policy
to
isolate
those
parts
in
their
own
namespaces,
so
that
this
yellow
traffic
line
becomes
a
deny.
B
But
on
the
other
hand,
if
the
namespace
of
ming
wanted
actually
to
access
this
service
public
in
another
tenant,
he
or
she
can
still
use
a
kubernetes
network
policy
to
do
so
by
explicitly
allowing
this.
So
we
are
handing
over.
You
know
whether
this
traffic
is
should
be
allowed
or
not
to
the
tenant
name,
spaces
owners.
B
So
this
is
one
flavor
of
the
of
the
exceptions
to
the
strict
denies
and
the
other
flavor
of
the
exceptions
of
the
street
deny
is
what
we
depicted
here
in
green
lines
right.
So
in
those
kind
of
cases
I
know
in
in
most
cases
right,
a
cluster
of
meaning
would
always
want
their
tenants
to
be
able
to
communicate
with
dns
services,
which
is
good
system,
could
dns.
B
Now
you
know
the
tenant
name,
spaces
may
or
may
one
may
not
may
or
may
not
want
to
actually
talk
to
the
group
dns
services
and
that's
totally
fine,
but
for
a
customer
I
mean
more
usual,
more
usually
than
not,
they
will
sort
of
like
have
the
strict
allow
rules
which
is
overriding.
The
default
deny
all
namespace
or
tendency
boundary.
That's
allowing
the
traffic
from
coupe
system
to
the
tenant,
two
namespaces
or
the
tenant
one
namespaces.
B
So,
as
you
can
see,
you
know
the
yellow
and
green
lines
are
the
two
kinds
of
exceptions
to
the
non-overratable
denies.
But
you
know
those
are
two
different
kind
of
like
use
cases
where
a
clustered
mean
sometimes
you
know,
may
want
strong,
allow
stance
for
for
those
exceptions,
and
sometimes
don't
is
there.
A
A
Clear,
so
can
you
pop
back
to
slide
three
yang
yeah
sure
great,
so
I
mean
I
for
me
that
helped
the
diagram
helped
explain
these
use
cases.
I
think
the
one
thing
that
we
still
have
open
to
question
is
number
five
right.
So.
C
C
One
way
to
describe
this
would
sort
of
be
to
have
a
tree
right.
You
have,
I
mean
the
inclusion
trees,
you
have
name
spaces
and
you
have
pods
and
a
pod
sort
of
hangs
under
the
name
space
and
we
can
even
have
a
tenant,
and
then
you
can
express
it.
As
I
mean,
if
you
have
a
namespace
rule,
it
goes
between
the
namespaces
and
then
you
can
describe
an
algorithm
that
will
you
can
have
the
arcs
of
different
types,
sort
of
that
just
say
in
which
order
you
interpret
the
arcs,
then
you
can
have
like.
C
B
Yeah,
the
problem
being
tenants
for
not
a
first-class
citizen
in.
B
C
B
C
D
So
perry
yeah,
we
just
thought
that
this
diagram
would
perhaps
be
you
know
it's
a
networking
diagram.
It
shows
flows.
So
the
thought
was
that
that's
that's
more
a
little
bit
more
clear.
C
You'd
skip
the
tenant,
then
you
can
still
just
have
the
name
space
and
policy
in
order
to
to
better
describe
the
algorithm.
So
if
you
have
different
type
of
arcs
and
then
you
can
have
an
algorithm
that
says,
if
two
parts
can
talk
to
each
other
sort
of
what
is
the
algorithm?
You
check
this.
You
check
this.
You
get
this,
I
think
that's
one
of
the
parts
that's
been
unclear,
sort
of
how
what
is
the
algorithm
and
how
does
it
get
well.
C
C
D
Would
jump
in
here
so
this
this
you
know,
quote-unquote
flowchart
is
for
a
specific
implementation,
which
assumes
an
empower
model
which
assumes
aggregation
across
policies
and
so
on.
So
this
is
not
the
functional
description
of
the
requirements.
Okay,
another
way
of
so
so
the
diagram
is
one
way.
The
diagram
is
still
a
simplification.
There's
actually
a
little
bit
more
detail,
but
maybe
we
don't
want
to
confuse
that
right
now.
D
If
we
are
clear
on
the
diagram,
that's
that's
a
good
step
forward,
but
the
other
way
to
look
at
it
is,
you
know,
look
at
how
requirements
are
expressed
like,
for
example,
it
would
be
worded
like
as
a
cluster
admin.
I
want
a
tenant
to
be
able
to
do
this
as
a
cluster
admin.
I
would
absolutely
you
know
so
that
functional
non-ambiguous
description
I.
C
I
I
agree
with
you
sort
of
that's
where
you
need
to
that's
what
we
need
to
start,
but
in
the
end
you
want
to
come
up
to
an
algorithm
that
capture
that
you
would
want
to
be
able
to
see
cap.
Does
this
algorithm
capture
all
the
requirements
that
we
that
you
start
with
use
cases
100
and
that
you
apply
that
to
some
model
right
and
we
need
to
build
that
model?
And
then
you
have
the
algorithm
or
algorithms
that
that
interpret
these
things.
B
Yeah
we
agree
yeah,
so
yeah,
so
going
back
to
going
back
to
andrew
questions
right
so
in
terms
of
number
five,
which
is,
you
know,
just
default
disposition
and
yeah.
So
this
is
also
a
point
of
confusion.
I
think
you
know
I
haven't.
We
haven't
really
discussed
on
how
or
whether
this
one
should
be
strictly
a
use
case
to
be
solved
for
the
cluster
network
policy
here,
and
we
believe
that
this
is
a
reasonable
use
case.
B
But
definitely
we
wanted
to
you
know,
hear
more
about.
You
know
the
community
on
the
feedback
on
this,
so
the
default
disposition
is
can
kind
of
falls
in
where
you
know
what
happens
when
dedicated
to
traffic
is
not
handled
by
the
name
space
owner
now?
What
should
we
do
in
this
case?
It's
pretty.
If
we
look
at
this
diagram,
you
know
it's
talking
about.
You
know
those
yellow
traffic
lines
right.
So
let's
just
take
the
service
public,
for
example-
and
this
is
a.
B
I
think
this
is
a
pretty
clear
traffic
pattern
here.
So
let's
say:
if
we
have,
you
know
poked
this
hole
through
the
non-overwriteable
denies
and
we
left
the
namespace
owners
to
decide
whether
this
is
you
know,
should
be
allowed
or
denied.
Now
what
I
just
gonna
be
named
says:
owners.
B
Owner
both
sides
need
to
agree
right
to
get
this
to
work.
I
hope
all
right,
all
right,
sorry,
the
tenant
owner,
I
would
say
so
sorry,
sorry
by
the
ambiguity
but
the
tenant
owner.
I
would
say
right
so
so,
essentially
you
know
we.
We
are
deferring
this
to
the
tenant
owner
to
decide
whether
you
know
this.
This
traffic
should
be
allowed
or
denied.
Now
there
are
two
things
that
they
can
do.
First
of
all,
they
can
have
a
explicit
allow
rule,
which
is
you
know,
kubernetes
network
policy,
saying
that
I'm
selecting
this.
B
You
know
this
part
behind
the
service
right
and
I'm
allowing
the
traffic
to
going
to
or
from
you
know,
the
service,
and
the
other
possibility
is
that
it's
the
tenant
owner
basically
isolates
those
parts
further
saying
that
okay,
I
want
those
parts
to
you
know
maybe
talk
to
each
other,
but
I'm
not
listing
this
as
allowed
right.
B
So
this
kind
of
like
rule
this
kind
of
traffic
just
keeps
you
know
hanging
in
there
right,
because
if
you
think
about
you
know,
policy,
evaluation
or
or
in
whatever
implementation
model
of
the
cmp
right.
So
what
we
wanted
to
do
is
that
you
know
cmp
will
be
evaluated
first
and
the
cmp
doesn't
really
capture.
You
know
whether
this
traffic
should
be
allowed
or
not.
B
Now,
on
the
second
on
the
second
layer,
you
know
the
tenants
namespace
owners
also
doesn't
have
a
explicit
network
policy,
saying
that
you
know
whether
this
traffic
should
be
allowed
or
not.
So
this
traffic
was
still
fall
open
to
maybe
whatever
the
default
cluster
traffic
policy
is
which
in
the
native
kubernetes
or
the
vanilla
kubernetes
case
will
be
always
allowed.
B
Now
our
intention
was
to
capture
you
know.
If
that's
something,
that's
happened
right.
If
we,
if
the
cluster
network
policy
writers
explicitly
left
this
traffic
out,
but
the
name
space
owner
doesn't
really
act
upon
it
or
create
any
rules
to
capture
you
know
whether
those
should
be
allowed
or
denied.
Should
there
be
a
default
layer
or
default
position,
layer
of
cluster
network
policy
that
this
dictates.
B
What's
the
you
know,
next
default
disposition
for
this
traffic
and
by
you
know
by
namespace
owners
or
tenant
namespace
owner
not
acting
upon
those,
we
actually
mean
that
there
are
actually
no
kubernetes
network
policies.
So,
for
example,
if
the
tenant
one
namespace
owner
have
a
kubernetes
network
policy
and
says
I'm
applying
the
network
policy
to
all
those
parts
and
I'm
you
know
essentially
isolating
those
parts
which
says
you
know
ingress
and
empty
all
right
and
and
essentially
I'm
not
allowing
any
ingress
or
inquest
traffic.
C
You
probably
want
to
have
in
some
systems,
but
if
we
don't
introduce
sort
of
the
tenant
concept
into
the
cluster
network
policies,
it
becomes
very
hard
to
set
that
up,
because
you
need
to
do
it
explicitly
for
these
groups
of
namespaces
which
might
change
over
time
right.
So
it's
something
that
changes
all
sort
of
you
add
and
remove
from
the
set.
Then
you
have
no
way
really
to
describe
it.
Maybe
you
can
with
the
label,
but.
D
So
per
the
assumption
here
is
that-
and
maybe
this
again
needs
to
be
documented
to
some
extent
but
without
being
over
prescriptive-
is
that
there
is
an
appropriate
labeling
scheme
and
there's
an
appropriate
namespace
labeling
scheme
which
identifies
the
namespaces
to
tenant.
C
We're
mapping
because
then
then
you
should
be
able
to
say
well,
implementation
is
one
thing
right
and
that
is
under
the
control
of
the
cluster.
At
the
expression
level,
you
want
to
be
able
to
say
in
a
understandable
way
right
that
you
set
the
policies
of
the
tenants
name.
Spaces
cannot
talk
unless
someone
explicitly
allow
it
on
both
sides
right
that
a
tenant
can
then
restrict
communication
within
his
own
namespaces.
If
he
wants.
D
Yeah,
so
another
point
here
is
that,
since
we
are
not
the
multi-tenancy
group,
we
are
not
being
overly
prescriptive
on
a
exact
multi-tenancy
model.
We
want
to
allow
the
kinds
of
multi-tenancy
models
that
seem
reasonable,
without
particularly
fixing
one
exact
tenancy
model
right.
So
we
are
the
networking
policy
group.
We
are
not
the
multi-tenancy
group.
We
just
have
to
provide
some
tools
that
can
allow
two
or
three
reasonable
multi-tenancy.
C
D
C
But
I
think,
I
think
the
conclusion
you
sort
of
you
get
if
you're
just
talking
today
about
namespaces,
it's
very
hard
to
do
this
unless
you
have
the
concept
of
a
tenant
and
how
that
is
implemented.
If
that
is
labels,
or
if
it's
a
new
object
that
you
have
relations
to
doesn't
really
matter
the
quest.
The
question
is
yes,
that
you
have
the
expressibility
and
that
you
can
use
them
in
a
way
that
makes
sense
in
in
the
policy.
C
D
We
did
I
I
did
check
with
a
few
other
people,
including
you
know,
solution,
architects
and
so
on,
who
felt
so
there's
in
terms
of
data
points
a
there
are
products
like
rancher,
which
you
know
group
a
group
of
which
group
x
number
of
namespaces
into
a
tenant.
So
there
is
precedent
for
this
right.
Secondly,
you
know
querying
solution.
Architects.
The
feedback
was
yeah.
This
makes
sense.
If
you
have
a
labeling
scheme
for
namespaces.
D
A
A
C
Sort
of,
if
you
think
of
as
a
rule,
three
I've
set
the
rule
and
if
that
rule
says
oh,
this
can
be
overwritten
or
sort
of.
I
can
delegate
it,
but
if
nothing
happens
there
you
still
have
a
rule
to
fall
back
on
and
to
me,
like
you
need
to
set
a
value
you
should.
You
should
not
just
have
have
something
that
says
you
can
go
either
way.
C
C
That
comes
to
me,
that
comes
from
the
the
one
that
says
the
csp.
He
can
say
this
you
have
like
deny
but
override
or
if
you
delegate,
if
no
one
takes,
if
no
one
think
of
object
orientation
when
you
use
delegation
right,
if
no
one
implements
the
the
delegation
method,
you
you
have
always
a
backup
right,
because
if
you
call
otherwise,
you
will
get
the
runtime
exception.
So
you
need
to
have
something
that
you
call.
E
Yeah,
so
I
raised
this
point
last
time
also,
so
I
I
feel
I
mean-
and
this
I
mentioned
last
meeting-
also
the
default
disposition
and
strict,
deny
but
delicate
can
be
combined
into
one
single
use
case
of
like
default
disposition.
So
you
have
your
restrict
denying
default
disposition,
and
if
a
tenant
or
namespace
admin
decides
to
make
some
changes
or
create
a
different
rule
for
part
of
the
traffic,
they
can
do
at
the
at
the
name
space
level,
because
it
is
the
default
disposition.
E
D
So
here's
the
other
thing
right,
the
default
of
a
namespace
is
defender
is
defined
by
two
ways.
Right,
if
you
have
any
policy
matching
a
pod,
it
automatically
goes
into
network
policy
right
and
otherwise,
if
you
have
no
policy
matching
apart
at
all,
then
it's
default
allow.
D
So
I
I
think
it
is
reasonable
to
have
this
default
logic,
be
separate
from
the
main
cnp
either
have
a
separate
crd,
which
I
think
abhishek
and
yang
were
initially
calling
dnp
or
it
could
be
part
of
netball
v2
or
it
could
be
an
extension
to
netball
v1
itself
right
a
new.
So
that's
why
it
is
not
essential
to
have
that
in
the
cnpcrd.
B
Right
right
by,
let
me
try
to
sort
of
like
comprehend
this
right,
so
essentially,
what
we're
trying
to
why
we
separated
into
those
two
use
cases
is
because
we
saw
there
or
basically
there
are.
B
There
can
be
two
cases,
and
one
is
that
you
know
we
what
we
a
cluster
the
mean,
may
poke
a
hole
like
in
the
strict
denies
and
the
cluster
mean
would
actually
don't
care
if
what
the
name
space
owner
actually
what
what
he
does,
whether
he
put
a
kurdish
name,
spaces,
name,
space
policy,
network
policy
to
actually
regulate
those
traffic
or
if
the
namespace
owner
just
doesn't
act
at
all.
B
Like
the
cluster,
I
mean
wouldn't
care
by
that
point
or
there's
another
use
case
where
the
cluster
mean
wants
to
dedicate
this
traffic
to
the
namespace
or
tenant
owner,
but
in
case
a
tenant
owner
actually
doesn't
act.
They
want
a
default
default
disposition.
Now
those
are
the
two
different,
really
subtle,
different
use
cases
that
we
had
in
mind.
So
our
people
agree
that
maybe
one
is
not
usually
the
case
that
we
should
only
consider
two
or
the
other
way
around.
E
B
Also
will
start
the
case
of
default
disposition.
Well,
the
problem
or
problem
is
that
when
you
have,
you
know
a
default
like
a
deny
all
this
higher
priority
denial
sort
of
will
capture
everything,
and
you
know
it-
it
won't
get
until
the
you
know.
The
default
rules
after
the
kubernetes
namespace
network
policy
and
the
default
denial
will
capture
that
and
drop
drop.
The
packet
already.
E
E
Yeah,
so
so
the
first
empower,
which
is
one
which
was
actually
allowing
a
subset
from
a
bigger
deny
that
has
to
be
front
but
yeah,
actually
exactly
the
mirror
image
of
that
is
when
you
have
a
broader
deny,
but
you
want
to
give
a
chance
to
name
space
admin
to
poke
some
holes
in
that
that
can
be
evaluated
later.
So
that's
why
I
was
thinking
that
4a
and
5
can
be
combined.
I
mean
whatever
we
come
up
with
right.
The
use
cases
can
be
combined
into
single
implementation.
B
But
my
I
think
my
confusion
was
still
at.
You
know
how,
if,
if
you
have
you
know
this
rule,
which
is
after
the
kubernetes
network
policy
evaluation
priority,
then
how
would
you
actually
poke
this
holes
for
for
the
for
the
d49?
Sorry,
not
the
d49,
but
the
strict
denies
around
the
tendon
boundaries.
B
E
E
B
Right
right,
I
I
I
think
I
understand
your
point
now,
the
the
problem
being
you
know
if
we
have
a
strict
deny.
That's
that's
depicted
as
something
like
this
right.
If
we,
if
we
wanted
to
have
a
default
disposition,
to
be
act
in
the
end
over
eventually
actually
evaluated,
somehow
we
do
need
to
skip
this
strict
deny
you
know
for
those
default
disposition
group
items
right.
E
To
you,
I
I
didn't
get
it
so
I
I'm
trying
to
still
understand
the
use
case,
difference
between
one
and
four,
a
right,
one
and
four
a
means
see.
For
example,
let's
say
I
I'm
saying
that
everybody
can
talk
and
they
say
nobody
should
talk
to
you.
No,
nobody
should
talk.
Qdp,
for
example,
just
take
a
hypothetical
example
right
and
that,
but
I
I
know
some
some
of
the
namespace
admins
want
to
have
that.
E
Then,
if
I
put
it,
if
I
put
that
rule
in
in
the
fifth
the
use
case
right,
I
create
a
default
policy
which
just
says
nobody,
irrespective
of
which
name
space.
They
belong
to,
cannot
talk
udp,
but
if
some
name
space
for
a
particular
port
or
for
some
parts,
if
they
want
to
create
an
exception,
they
can
create
it
in
kmp.
B
All
right
right
right
that
that
makes
sense,
but
our
problem
is
that
what?
If
somebody,
you
know
what,
if
the
cluster
admin
comes
in
and
he
wants
to
isolate
every
namespace
strongly
strictly
non-overwriteably,
isolate
every
namespace,
then
what
he
or
she
would
do
is
write
a
policy
that
actually,
you
know,
isolate
those
name
spaces.
Now,
with
that
policy
already
in
place,
then
you
sort
of
like
needed
either
modify
that
policy
or
you
needed
some
sort
of
like
exceptions
to
you,
know
those
hard
boundaries
to
allow.
B
At
least
you
know
those
traffic
to
be
not
evaluated
by
those
strict
denies
and
it
can
fall
to
the
default
disposition.
Rules.
A
You
want
no,
it
will
never
make
it
to
any
default
disposition.
Rules
at
that
point
like,
like
the
allow,
will
always
allow
it
at
the
tenant
level
right.
The
main
thing
is
like:
if
you
don't
have
four,
you
can
never
get
to
five
right.
So
yes,
that's.
I
think.
That's
what
I'm
saying,
because
there's
no
way
to
poke
holes
in
the
strict
deny
three
is
poking
holes
that
you
cannot
close
with
five
in
the
strict
deny
four
is
poking
holes
that
you
can
close
with
five
right.
It's
two
different
use
cases.
D
So
if
number
three
says
it's,
it's
a
policy
at
the
receiver,
which
says
strictly
now
strictly
deny
but
allow
these
exceptions
doesn't
mean
that
that
exception
has
to
go
through.
Because
that
can
you
can
force
this
policy
at
the
receiver,
but
the
sender
you
can
still
control
which
senders
are
allowed
to
send.
D
B
Right,
I
I
I
agree
on
that
point,
but
basically,
on
this
picture,
you're
essentially
saying
that
you
know
if
we
have
this
policies
on
the
tenant
name
spaces,
then,
if
the
cluster
network
policy
admin
comes
in
and
sort
of
like
say,
hey,
I'm
applying
a
policy
on
the
coup
system,
crew,
dns
parts
and
I'm
telling
the
dns
parts.
You
know
you
can't
talk
to
any
of
the
tenant
name
spaces.
B
I
guess
that's
something
you
know
the
cluster
needs
to,
you
know,
have
better
knowledge
on,
or
at
least
not
apply
those
kind
of
policies,
because
those
are
actually
the
policy
that
contradicts
with
each
other
right.
So
you
know
we
are
at
least
expecting
the
cost
of
the
means
to
not
apply
those
kind
of
policies
to
make
it
doesn't
work
on
the
other
side.
Does
that
make
sense.
D
Yeah-
and
I
think
there
are
some
assumptions
here
on
the
exact
operational
model
of
this
multi-tenancy-
I
think
let's
keep
going.
I
if
you
have
time,
I
can
share
a
few
updates
that
I've
got
as
well,
but
go
ahead
and
wrap
up.
Okay,.
B
Cool,
I'm
I'm.
Actually.
I
actually
wanted
to
sort
of
still
answer
on
nadeem's
question
if
possible.
So
you
were,
you
were
suggesting
some
sort
of
like
examples
you
had
in
there.
E
Yeah
so
so
I
was
trying
to
understand
like
what
is
the
exception,
which
we
can
achieve
in
four,
which
is
not
possible.
If
we
just
put
a
default,
I
mean
whatever
is
calling
strict
deny
but
delicate
right,
I
mean
we
are
calling
it
a
strict
deny
but
delegate
right,
which
means
we
are
so
so
I
now
understand
the
use
case,
but
I
am
just
not
sure
that
it
is
kind
of
becoming
a
language
within
the
policy
itself,
right,
typically
that
policy
administrators
are
accustomed
to
creating
superset,
subset
kind
of
rolls
right.
E
B
B
So
so,
essentially,
you
know
what
I
would
say
what
the
the
difference
between
four
and
five
is
that
you
know
what
we
depicted
as,
as
I
said,
depicted
in
the
in
the
yellow
lines
here
right,
so
we
we
all
agree.
Do
we
at
least
all
agree
that
you
know
these
yellow
lines
will
be
the
exceptions
to
the
strong
deny?
Otherwise
you
know
there's
no
delegation
or
what
not
happening
it
would
just
be
denied
by
the
stricter.
No
overrideable
demands
right.
B
E
B
Okay,
so
so
essentially,
you're
saying
that
for
for
the
part
for
the
policy
you
you
need
to
write
this
this
way,
essentially
from
here
to
here,
it's
a
strong
deny,
but
for
this
guy
it's
a
weak,
deny
yes,
okay!
So
now
the
now
the
tricky
part
is
that
what
we
mentioned
for
a
really
really
long
time
now
is
that
how
do
you
write
a
rule
that
says
for
here
to
here?
B
This
is
a
strong
deny,
because
you
know,
usually
what
makes
sense
to
people
is
that
we
will
have
something
stacked
on
top
of
it
and
says
you
know,
this
is
the
exception
we
made
to.
You
know
the
the
entire
thing
right.
So
if
we
actually
have
you
know
a
good
mechanism
to
do
to
specify
you
know
this,
then
we
probably
don't
even
have
the
datagate,
and
you
know
all
those
problems,
because
we
can
just
specify
the
policy
that
we
want
exactly
and
let
everything
else
fall
through.
B
So
this
is
a
problem
that
we
are
facing.
But,
yes,
I
agree.
Essentially,
essentially
the
use
cases
can
be
can
be
depicted
that
way.
If,
if
we
can
find
a
really
really
good
implementation,
that's
non-ambiguous
and
we
can
have
a
default,
deny
actually
overriding.
B
You
know
the
the
strong
strict
deny,
but
that
has
been
really
challenging
to
come
up
with,
I
guess
so
so
yeah.
I
guess
this
is
another
way
to
look
at
it.
A
And
nadine,
can
you
throw
some
of
those
opinions
on
slide
three
in
the
comments
possibly
and
we
can
move
forward
from
there
and
maybe
let
yang
just
try
to
run
through
some
of
these
samples.
So
we
can
see
what
those
yamls
would
look
like.
B
B
Chat
all
right
cool,
so
if,
if
we
sort
of
like
can
at
least
understand
you
know
those
use
cases,
I
guess
I'll,
I
I
think
sanjeev
mentioned.
He
also
have
something
to
updates
to
share
so
I'll
I'll.
Stop
there
and
see
if
we
can
get
to
you
know,
maybe
the
example
almost
that
we
prepared
on
the
other
all-in-one
yamos
and
everything
we
prepared
for
those
use
cases
in
the
next
meeting.
D
Either
way
it's
fine
with
me,
because
you
guys
have
asked
me
to
work
on
some
yaml,
so
I've
got
some.
Obviously
we
can
do
more.
So,
okay,.
B
Cool
all
right,
then
I'll
stop
from
there.
B
A
E
D
Sorry
so
so
this
picture
right
here.
Another
point
is
that
yeah,
okay,
I
actually
used
the
picture
that
we
had
in
the
repo,
but
this
is
very
similar
to
yang's
picture
okay,
so
some
thoughts
just
think
about
when
it
comes
to
priority-based
network
policies.
Firstly,
there
are
two
aspects
of
ordering:
okay,
one
is:
how
do
you
order
different
cnps
vis-a-vis
each
other
and
then
what
is
the
ordering
of
rules
within
a
cnp?
So
it's
ordering
is
not
just
one
thing.
D
D
If
there
is
no
priority
number
and
they
happen
to
have
overlapping
matching
criteria
and
conflicting
action
types,
which
is
what
we
would
have,
it
is
not
clear
unless
you
decide
to
aggregate
across
the
cnps,
so
if,
if
otherwise
you
know
so
so
that's
my
point
here
right
number,
one
having
a
priority
allows
you
to
resolve
the
ordering
at
least
across
cnp's
and
possibly
even
within
a
cmp.
So
you
can
have
any
number
of
rules
and
you
know
clearly
which
one
takes
parity
over
the
other.
D
If
you
don't
have
it,
if
you
do
aggregation,
then
a
rule
in
cnpd
may
overwrite
another
rule
in
cnpa,
even
though
there
is
no
explicit
indication
that
cnpa
takes
precedence
over
cmpd
and
this
might
be
confusing
to
some
admins.
So
the
next
point
is
about
network
admin.
Familiarity
right,
admins
are
familiar
with
priority,
based
ordering
that's
because
a
lot
of
equipment
and
clouds
have
it.
D
D
So
it's
not
something
that
they're
familiar
with,
of
course
that
doesn't
stop
us
from
introducing
it,
but
it's
just
a
point
to
know
that.
That's
not
something
that
they're
familiar
with,
and
finally
keywords
like
empower
are
new
keywords,
so
there
will
be
some
ambiguity
right.
So
if
you
want
to
keep
in
mind,
familiarity
and
ease
of
use,
these
are
points
to
consider
right.
So
the
points
are
number
one.
Admins
already
use
priority
based
ordering
number
two.
They
typically
do
not
overload
the
action
type
with
the
priority
right.
D
It's
not
that
deny
is
always
higher
priority
than
allow,
and
things
like
that.
If
we
make
a
rule
that
requires
that
that
that
would
be
unfamiliar
to
network
admins.
And
secondly,
if
we
introduce
new
keywords
that
would
also
be
somewhat
unfamiliar
to
network
admins
that
doesn't
stop
us
from
doing
it
is
just
something
to
keep
in
mind.
D
The
other
thing
is
that
I'm
not
looking
at
this
as
solution
a
versus
solution
b
right.
We,
I
actually
think
that
these
are
not
even
orthogonal,
not
even
opposing
solutions.
So
having
a
priority,
number
is
orthogonal
to
having
additional
actions
like
empower
and
we
could
even
choose
to
have
both.
So
we
could
even
have
priority
numbering
as
well
as
the
empower
keyword
should
we
think
that
that's
appropriate.
D
So
I
don't
want
to
see
position
this
as
priority
numbering
versus
multiple
actions.
These
are
slightly
different
things.
We
could
even
have
both
okay.
The
other
point
is
we're
introducing
the
cnp,
because
we
want
customers
to
migrate
from
current
vendor
seniors
right
and
virtually
all
the
current
vendor.
Cni's
are
supporting
priority
ordering
okay
and
none
of
them
have
a
keyword,
sort
of
like
empower
again.
That
doesn't
mean
we
don't
do
it,
but
it's
all
about
familiarity
and
what
is
the
current
model?
So
if
we
switch
to
a
non-priority
based
model.
C
So
go
ahead,
so
when
is
your
priority
order,
when
you
do
the
cmp
versus
the
standard
right,
you
have
a
priority
order
in
there
between
the
cnp
policies
and
the
normal
network
policies
right.
Do
we
need
more
than
that?
In
that
case,
okay,
we
need
to
specify
how
it
works.
If
we
think
it's
enough,
then
you
only
have
it
based
on
that,
you
already
have
sort
of
a
the
cnp,
the
algorithms,
how
you
apply
the
the
policies
based
on
type
sets,
the
ordering
it's
implicit
based
on
the
proposal.
You're
coming
with
right.
B
I
I
would,
I
would
guess
sanjiva's.
This
point
is
that
if
we
don't
have
those
kind
of
like
priority
orderings,
then
the
cmp
evaluation.
A
C
So
what
you
really
want,
and
I'm
going
to
come
back
and
talk
about
this
in
in
a
couple
of
weeks.
What
you
really
want
is
for
someone
to
separate
the
policies
how
you
define
from
the
algorithm
that
applies.
I
think
implicit
ordering
is
way
better,
because
it's
understandable
and
sort
of
you
set
it.
C
And
if
you
need
a
new
policy
type
well,
then
we
should
add
a
new
policy
type,
and
then
you
can
change
the
ordering
to
just
have
a
flat
sort
of
policy
space
and
then
try
to
set
up
some
ordering
system
that
the
order
within
that
space.
I
think
it's
it's
going
to
be
overly
complicated.
I
think
sort
of
the
whole
idea
with
cmp
is
that
and
others
are
policy
types
that
you
you
get
an
implicit
ordering
by
definition,
defining
how
these
things
relate
to
each
other.
C
To
say
that
there
is
no
such
thing
then
should
should
then
a
normal
user
be
able
to
push
a
network
policy
ahead
of
the
network
of
the
cmps.
It
was
really
weird,
so
so
yeah,
okay,
so
the
goal
here
is
just
you
know.
C
I
think
the
goal
should
be
that
you
should
be
able
to
have
a
policy
system
with
ordering,
but
without
having
to
specify
priorities
based
within
sort
of
each
plane
in
the
the
algorithm
that's
used
to
apply
to
the
to
the
policies
that
I
think
should
be
the
best
can
it
be
avoided.
I
don't
know.
D
Yeah,
so
the
point
here,
the
point
here
is
just
so
that
we
are
making
sure
we
understand
the
pros
and
cons
all
approaches,
and
it's
not
that
these
are
all
a
versus
b.
You
can
have
a
plus
b
right.
So
that's
what
we're
saying
here
that
number
these
are
facts
to
keep
in
mind
right
number
one.
There
are
two
aspects
of
ordering.
D
It
goes
without
saying
that
we
are
talking
about
cluster
admin
policies,
always
higher
priority
than
network
policies
right.
So
that
is
understood.
That
is
true
for
all
these
proposals,
but
even
within
that,
how
do
you
prioritize
within
the
different
rules
of
a
cluster
network
policy
if
they
can
be
overlapping?
D
One
is
you
have
to
make
you
have
to
have
a
agreed
design
for
ordering
across
cnps
and
second
and
agreed
design
for
ordering
within
multiple
rules
of
a
single
cmp,
just
making
sure
we're
just
thinking
through
this
right
and-
and
so
here
are
the
issues
when
you
have
to
handle
multiple
cnps.
Here's
the
issues
with
related
to
network
admin,
familiarity
and
again
reiterating
that
you
can
actually
have
both.
This
is
not
a
versus
b.
It
could
be
a
or
b
or
a
plus
b,
and
then
there
is
the
adoption
issue
for
the
current
vendor
cni's.
D
C
So
so
this
is
maybe
productive.
Does
any
of
the
c
of
the
the
cni
providers
that
they
care
at
all
about?
What's
in
in
kubernetes
network
policy,
they've
done
their
own
right?
D
C
C
D
D
At
least
most
of
the
common
use
cases
that
the
vendors
are
solving,
we
should
be
able
to
solve.
Otherwise
this
will
limit
the
adoption
of
the
cnp
and
people.
C
B
Now
our
our
at
least,
the
the
hope
for
pushing
the
cmp
at
least,
is
to
have
all
the
major
cni
vendors
to
implement
this
cost
network
policy
as
well.
Maybe
in
definitely
you
know
in
addition
to
what
they
already
implemented
as
a
classical
policy,
because
this
will
be
a
standardized
way
across
kubernetes
distributions,
so
that
you
know
when
maybe
we
have
a
sample
cmp,
which
says
that
we
can
use
the
cmp
to
do
blah
blah
blah.
For
example,
you
can
use
this
game.
C
The
the
bullet
3
here
is
like.
Yes,
we
didn't
empower
and
delegate.
You
should
be
able
to
do
this
in
the
same
policy,
but
people
might
not
be
used
to
do
that.
Then
it's
not
always
good
to
open
up
a
policy
all
the
time,
but
if
all
you
want
to
be
able
to
do
right
is
to
to
to
shoot
in
a
delegate
or
in
power,
or
I
mean
those
in
it.
C
We
should
be
able
to
specify
the
priority
orders
in
that
case
that
if
you
want
to
be
able
to
shoot
in
a
power
rule
for
on
top
of
a
call
it
the
default
wider
cnp
policy,
that's
just
one
one
level.
You
need
right.
How
many
levels
you
need
can?
Can
you
add
that
into
the
algorithm
to
say
that,
yes,
you
should
be
able
to
add
delegates
on
top
of
it
or
empower
so
that
overrides
the
default
one
that
to
me
is
two
levels.
You
can
have
a
first
check.
D
Let
me
just
show
one
example
yaml,
so
basically
this
were
the
points
to
keep
in
mind
right
and
you
know:
there's
migration,
flexibility,
all
of
this
network
admin,
flammability.
So
here's
one
example
I
I
was
hoping
to
have
more,
but
I
don't
think
we
have
time
to
do
more
anyway.
So
let's
just
look
at
this
one
here
right.
So
here
is
this
one
yaml
potentially,
which
is
doing
a
multi-tenancy
case
and
the
requirements
are.
D
Block
antler,
entertainment,
ingress
and
egress
must
allow
prom
monitoring
traffic
coming
in
from
the
prometheus.
Namespace
must
allow
egress
to
cube
dns
and
defer
all
the
intratenant
traffic
to
the
namespace.
So
here
the
spec
explicitly
gives
a
priority
order
number
to
this
policy
right.
So
you
know
that
this
is
order
10.
D
D
I
have
enforced
a
label
called
tenant
class
and
all
class
a
tenants
need
to
have
this
behavior
right,
and
so
what
this
behavior
is
that
there
are
two
ingress
rules
which
says
you
must
allow
traffic
to
come
in
from
the
prometheus
service,
because
that's
what
the
cluster
admin
is
using
to
monitor
everybody.
So
he
must
allow
that
traffic
to
come
in
right
and
you
must
deny
traffic
that
is
coming
from
a
tenant.
D
That
is
not
yourself,
okay,
so
these
are
the
two
ingress
rules
ordered
according
to
the
fact
that
the
first
rule
is
is
implicitly
higher
or
higher
priority
than
the
second
rule
right.
So
the
first
rule
is
defining
the
exception,
which
is
must
allow,
and
the
second
rule
is
defining
the
must
deny
on
the
eagles
election
go
ahead.
Was
there
a
question.
B
Yes,
sorry,
I
I
had
a
question,
so
if
I
understanding
this
correctly,
you
were
seeing
that
you
know,
because
we
have
two
ingress
rules
in
the
from
two
froms
and
you
want
this
to
be
an
implicit
priority,
meaning
the
first
from
and
the
first
action
will
be
a
higher
priority
than
the
second
from
and
the
second
action
right.
B
So
I
know
this
is
you
know
very,
and
you
know
unlikely,
but
you
know
that
means
that
if
we
have
another
cmp
of
all
other
10
also.
B
And
the
first,
the
first
ingress
rule
of
that
policy
will
have
a
higher
order
than
the
second
ingress
rule
in
this
policy,
and
that's
what's
implied
here
right.
D
B
No,
I
I
yeah
yeah.
I
don't
want
to
defer
this
conversation
because
we're
over
time
so
yeah.
Maybe
we
can
take
this
discussion
to
the
next
meeting.
Yeah.
A
Let's
pick
up
here
next
week,
I
think
the
one
comment
I
did
have,
though,
is
we
can
narrow
down
this
order
problem?
We
literally
could
make
ingress
section
only
allow
one
policy
to
have
one
rule
like
we
can
make
this.
However,
we
want
like
this
is
a
complicated
problem
and
I
think
it
applies
to
both
scenarios,
and
I
think
we
should
talk
about
it
more,
but
we
are
at
10
503,
so
yeah.
C
Okay,
so
yeah,
so
let's
continue
on
this,
but
also
sort
of
the
specific
case
when
you
have
same
order
and
different
results
right,
that's
something
we
need
to
have
resolved.
I
mean
to
have
a
resolution
for
to
say,
what's
supposed
to
happen,
yeah.
A
D
Yeah,
so,
okay,
we
can
continue
next
time.
A
Great
awesome
thanks
both
of
you
for
putting
together
some
presentations
are
really
awesome
and
please
share
those
links
with
me
or
put
them
in
the
agenda
directly,
so
that
people
can
go
back
and
comment
over
the
next
week
and
we'll
just
continue
this
discussion
care
guys
great.
Thank
you.
Everyone.
Thank
you.