►
From YouTube: Network Policy API Meeting 20210809
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,
great
hello,
everyone
today
is
august
9th
2021.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
to
sig
network.
This
is
a
cncf
certified
meeting,
so
please
be
nice
to
each
other
and
let's
have
a
productive
day.
Okay,
so
starting
with
the
agenda,
I
don't
have
it
pulled
up
because
there's
not
much
to
share
my
new
introduced
to
triage.
The
main
goal
of
this
meeting
was
just
to
continue
the
discussion
on
cmp
that
started
two
weeks
ago.
A
A
A
C
I
don't
have
screen
sharing.
I
think
you
need
to
enable
it.
A
C
So
yeah,
so
we
can
get
going
so
nadeem.
I
don't
know
if
you
were
in
the
call
last
thursday
with
you,
we
went
over
some
of
this.
If
you
like,
we
can
just
do
a
quick
recap
to
catch
you
up,
yeah.
That
will
be
helpful.
I
was
not
there
in
thursday,
okay,
so
we'll
just
spend
5-10
minutes
on
that
and
you
know,
and
then
we
can
go
on
to
additional
points
and
abhishek
andrew
yang.
C
I
hope
you
got
a
chance
to
look
at
the
some
of
the
changes
are
made
at
least
to
some
extent,
but
we'll
go
over
it
again
as
well,
and
some
of
this
we
can,
you
know,
there's
always
multiple
ways
of
doing
some
of
these
animals
yeah,
so
we're
just
kind
of
adding
to
the
user
stories
slide
deck
that
abhishek
prepared
some
couple
of
weeks
ago,
we
kind
of
went
through
these
use
cases.
C
There
was
some
amount
of
back
and
forth
on
these.
We
won't
go
through
these
again
yeah.
Some
of
these
wordings
were
updated
in
response
to
the
comments
and
there's
always
a
little
bit
more.
We
can
make
it
cleaner,
but
let's
just
go
straight
to
the
diagram
in
the
yamls,
so
as
shown
in
the
diagram
again,
we
went
over
it
before
when
nadeem.
Do
you
recall,
are
you
comfortable
with
this
description?
C
Yes,
okay,
so
we
just
go
to
now
kind
of
so
kind
of
here's.
A
comparison
we
put
together
on.
You
know
these
two
kinds
of
approaches
that
we've
been
talking
about,
and
maybe
it
helps
to
just
go
over
it
again.
C
So
let's
just
call
approach
a
as
sort
of
the
three
actions
approach
and
approach
b
as
priority
ordering
based
approach.
Okay,
so
there's
a
lot
of
text
here.
Let
me
do
the
following:
let
me
just
give
you
five
ten
minutes
to
go
over
it,
and
then
we
can
go
over
some
of
the
points
here.
So
just
take
five
minutes
and
just
kind
of
read
through
I've,
updated
it
a
little
bit
since
thursday.
C
C
Okay,
so
yeah,
so
you
know.
C
Some
key
points
are
that
in
this
three
action
solutions,
so
far,
we've
been
talking
about
three
kinds
of
actions
empowered
in
our
you
know,
law
and
they
also
sort
of
convey
not
just
the
action
but
a
priority
where
you
know,
there's
a
certain
ordering
empower
is
higher
priority
than
deny
and
which
is
higher
priority
than
allow
in
the
priority
ordering.
You
know,
there's
a
separate
way
of
resolving
priorities,
either
through
an
explicit
priority
number
or
through
ordering
in
the
yaml,
and
the
actions
are
still
to
deny
and
allow
and
they
are
independent
of
priority.
C
The
other
point
is
that
so,
with
the
three
actions
right,
the
rules
are
aggregated
by
action
type
across
the
instances.
So
all
empower
rules
across
all
the
instances
are
clubbed
together
and
they
are
at
a
higher
priority
than
all
deny
rules
across
all
instances
and
then
all
on
our
rules,
whereas
here
there
is
a
way
to
you
know
in
the
approach
b,
there's
a
way
to
resolve
priority,
both
across
cnps
and
within
cnps.
C
C
Then
we've
talked
about
you
know
the
delegation
and
and
sort
of
differing
to
the
network
policy.
So
in
the
approach
a
the
delegation
is
supported
via
a
combination
of
the
empower
action
and
fall
through
from
cnp
to
normal
network
policies,
but
the
empower
also
performs
deny
exception.
It's
an
exception
to
the
denials,
but
that's
also
been
one
of
the
sort
of
wording
confusions
there,
because
sometimes
empower
was
a
deny
exception,
and
sometimes
it
was
delegate.
It
really
is
a
deny
exception.
C
Okay,
and
in
this
case
of
the
priority
kind
of
approach,
the
delegation
is
always
by
fall
through,
so
that's
sort
of
what
it
is
and
then
the
deny
means
deny,
and
if
you
want
to
do
any
exceptions
to
the
deny
you
do
it
with
match
expressions.
You
know
you
can
do
things
like
you
know
this
up.
C
This
deny
applies
to
this
or
matching
this
or
not
matching
this,
and
then
you
just
fall
through,
and
then
that
becomes
your
delegation
to
the
network
policies,
so
the
benefit
of
so
the
syntax
benefit
of
three
actions
is
that
you
don't
have
to
have
explicit
ordering
so
which
sort
of
matches
with
how
network
policy
does
it
today
right,
you
have
whitelist
rules,
a
bunch
of
rules
and
whichever
rule
it
applies
to
it
matches,
so
there
is
some
similarity
there,
which
is
good,
okay
and
that's,
and
then
and
hence
you
can
sort
of
aggregate
those
rules
across
policies
and
you
have
the
order
independence,
but
because
we've
got
denies
you
you
have
to
then
embed
some
priorities
there
and
that
I
think
limits
future
extensibility,
because
every
time
you
overload
an
action
with
a
priority.
C
That
means,
when
you
add
new
actions.
Well,
they
have
to
have
new
priorities.
Like
you
know,
let's
say
we
had
a
logging
action
or
a
monitoring
action.
Is
that
higher
priority
than
deny
or
low
priority?
Well,
you
want
to
log
at
different
points
like
you
want
to
log
before
denying
you
want
to
log.
After
denying
you
want
to
log
before
allowing
so
coupling
actions
with
priorities
does
have
some
kind
of
restriction,
but
it
was
needed
in
order
to
get
that
simplification
right.
So
that's
sort
of
the
pro
and
the
con.
A
Quick
question
for
you:
how
do
you?
Why
do
we
care
about
logging
before
deny,
and
after
deny
don't
we
just
care
about
the
policy
like
saying
what
packet
we've
dropped
or
what
packet
we've
allowed
and
logging
that.
C
Yeah,
so
any
kind
of
action
I
mean
logging
is
just
one,
but
firstly,
you
may
want
to
log
multiple.
I
mean
for
the
papers
for
the
case
of
logging.
Yes,
now
here's
the
point
right.
You
want
to
log
before
and
after,
but
if
you
just
have
one
log,
you
can't
do
it
a
priority
before
and
allow
as
well
as
after
allow
what
is
the
priority
of
the
log.
A
So
is
the
cmp
acting
on
the
packet
now
like
it
doesn't
matter
right
so
cmp
is
a
wall
and
that
wall
is
either
allowing
or
dropping
a
packet.
All
the
log
would
do
is
say.
This
is
what
the
packet
is,
and
this
is
what
we're
doing
to
it,
and
that
is
only
allow
or
drop
right.
But
are
you
saying
one
day
it
may
be?
C
That
could
be
one,
but
I
will
you
know
it's
even
if
you
just
stay
sticking
with
so.
Firstly,
this
applies
to
various
kinds
of
actions
which
we
don't
know
in
the
future.
One
is
logging,
others
could
be
snatting
so
on
right,
but
even
if
it
is
just
you
know,
dropping
a
packet.
You
want
to
be
able
to
see
all
the
packets
before
the
log
before
the
drop,
and
then
you
yes,
if
you
have
a
la
logging,
dropping
rule,
you
can
see
which
are
getting
dropped.
D
So
so
I
think
we
just
just
really
quickly.
I
think
we've
been
through
this
conversation
and
I
think
we
have
some
sort
of
like
a
difference
in
interpretation
of
the
logging
here.
I
think
why
andrew
is
confused
is
that
you
know,
as
we
think
about
it,
the
login
should
only
be
applying
to
you
know
whatever
the
final
jurisdiction
of
the
packet
is,
but
I
think
I
understand,
as
I
understand
from
sanjiv's
point,
if
we
have
this
numeric
priority
model,
for
example
right.
D
So
we
have
a
bunch
of
priority,
which
is
you
know,
500,
400
and
200.
Now,
logging
as
an
action
can
be
imposed
at
a
specific
priority
so
that
we
know
that
at
this
poverty
level
the
pack
is
still
there.
It's
now
being
dropped,
it's
not
being
you
know,
matched
by
any
cmp
rules
and
blah
blah
blah,
but
at
the
other
priority
the
packet
has
been
dropped.
D
So
this
would
act
as
a
sort
of
like
a
debugging
tool
where
we
can
know
you
know
where
in
the
priority
pipeline,
did
the
packet
match
one
of
the
cmps,
or
did
that
did
it?
You
know,
gets
dropped
or
allowed
or
whatever,
by
a
cmp.
So
I
think
this
is,
if
I'm
understanding
this
correctly.
This
is
this
was
some
jeep's
point,
but
you
know
to
to
our
understanding.
D
For
example,
if
we
do
actually
just
have
the
three
action
rules
and
all
the
cmp
rules
are
aggregated
this,
this
priority
of
logging
doesn't
really
make
any
sense
anymore.
I
don't
know
if
I
captured
this
correctly.
C
So
let's
keep
that
particular
use
case
aside
for
the
moment,
but
the
basic
point
is
that
if
you
are
combining
actions,
action,
type
and
priority,
you
are
limited
in
future
actions,
because
then
you
have
to
have
it
at
that
that
action
can
only
be
done
at
a
certain
priority
compared
to
allow
or
deny
right.
That's
the
really
the
core
point:
that
action
type
is
a
different
thing
than
priority
and
you
want
to
be
able
to
have
any
action
at
any
priority.
C
Now
we
can
decide
that
adequate,
it's
adequate
to
always
have
denied
an
allow
or
things
like
that,
but
that
does
you
know
limit
what
actions
you
can
have
in
the
future
as
well.
In
general,
people
want
would
want
independent
controls
on
a
priority
versus
the
action
type.
That's
really
the
bottom
line
in
terms
of
future
extensively,
so
they're
not
equally
future
extensible
in
my
view,
but
we
can
debate
whether
that's
critical
or
not
critical,.
B
And
just
to
add
my
thought
to
this,
this
particular
point.
I
still
feel
the
logging
action
doesn't
have
anything
to
do
with
the
other
actions
and
they
don't
necessarily
logging
should
not
necessarily
be
introduced
as
an
action
I
mean
it
can
be,
but
that's
not
necessary.
It
can
be
introduced.
B
B
So
I
just
want
to.
I
just
want
to
voice
my
opinion
on
the
the
extensibility.
I
think
it's
unclear
for
both
both
the
approaches
I
mean
I
can
see
andrew
has
commented,
and
I
think
I
plus
one
that
comment.
C
Right
sure,
my
view
is
that
when
you're,
the
point
here
is
whether
you
want
to
decouple
action
and
priority
or
whether
you
want
to
keep
these
as
independent
control.
So
the
more
you
have
independence,
the
more
you
can
have
actions
at
any
priority.
That's
that's
the
key
point
and
we
don't.
We
can
debate
about
the
logging
use
case
and
so
on.
C
But
the
point
is
like,
for
example,
here's
another
thing
right,
ip
block
like
let's
say
we
want
to
reintroduce
ip
block
in
some
scenario,
but
with
ip
blocks
you
can
have
overlapping
ciders,
and
sometimes
you
want
to
you
know,
do
an
action
on
a
point
with
an
ip
block
which
either
a
more
significant
or
less
significant
insider.
You
want
to
have
independent
priority
control,
so
this
question
around
ip
blocks.
E
C
B
C
But
it's
possible
that
cni's
are
not
necessarily
checking
to
see
that
ip
block
siders
are
non-cluster
ips.
C
Because
it
is
dependent
on
the
cni
implementation
anyway,
so
yeah
we
can
come
back
to
ip
block
and
things
like
that.
The
point
here
is
about
future
extensibility
when
you
have
independent
controls
of
priority
in
action
versus
the
action
embeds
the
priority
right.
So
that's
that's
sort
of
the
key
point
here.
D
I
think,
for
the
stake
of
time,
we
could
probably
move
on
to
the
to
the
4b
point
where
we
had
the
confusion.
Last
time.
D
Yamas
are
like
really
straightforward
and
we
all
agree
on.
You
know
it's.
Essentially
it's
solvable
by
both
approaches.
Right.
C
Yeah,
so
the
point
about
the
point
about
the
yaml
discussion
was
also
about
usability
or
sort
of
the
cleanness
of
the
ammo
or
the
length
of
the
yama
and
so
on.
Right.
So
should
we
very
briefly
recap
because
I
think
neither
pair
nor
nadeem
were
at
the
thursday
call,
but
we
could
jump
to
4b
if
you
like
and
come
back
either
way.
C
Okay,
so
yeah,
so
you
can,
you
know,
go
over
this
later
as
well,
so
we'll
skip
the
use
cases,
one
and
two
they're.
Basically
just
either
always
a
lie
or
always
deny
so
you
know,
there's
not
a
huge
difference,
one
way
or
the
other.
B
C
B
C
First,
yeah
pretty
significant.
Actually
this
look
I
mean
look
at
this
right.
This
is
quite
a
lot
of
okay.
This
is
a
key
point
and
I'll
come
back
to
that,
but
andrew
go
ahead
and
mention
here.
A
I
just
had
a
question
for
abhishek
and
yang
on
this
one,
I'm
missing
something
I
think
when
we've
talked
about
it,
why
can't
we
just?
Why
do
we
have
to
empower
and
allow
strictly
allow
here
like?
Why
can't
we
just
say
we
want
to
allow
system,
namespace
and
core
dns.
B
So
I
can
take
a
dig
that
in
this
case,
what
we
wanted
to
do
was
so
the
empower
into
a
name,
space,
traffic
right.
We
what
this
is
going
to
be
skipped
from
the
deny
rule.
So
that's
why
we
wanted
to
add
it
into
the
empower
rule
and
the
other
one
is
the
you
know
we
want
to
always
allow
the
core
dns
traffic,
but
the
way
we
are
writing
the
deny
rule
is
to
deny
from
all
namespaces.
B
So
that's
why
we
are
skipping
the
core
dns
traffic
from
the
deny
rule
and
then
explicitly
allowing
the
core
dns
part.
B
So
that's
the
reason
why
so
so
the
empire
is
basically
skipping
the
denies
and
and
then,
if,
if
there
is
no
strict
allowed
to
allow
the
traffic,
then
it
goes
to
the
tenant
as
a
delegate.
But
if
there
is
as
a
clustered
policy
owner
I
or
administrator
I
want
to
strictly
allow
core
dns
traffic,
then
I
will
choose
it.
To
put
it
in
the
allowance.
A
Okay,
that
makes
sense,
and
then
the
last
part
was
the
user
story.
Didn't
say
anything
about
entrance
namespace
and
this
oh
yeah
delegates.
B
We
could
we
could
remove
the
the
internet
space
part
cool.
A
It
was
just
noticing
it
from
the
from
the.
D
Yeah,
just
also
we,
I
have
a
quick
point
on
this.
So
essentially
you
know
I
was
discussing
this
with
a
check
on.
You
know
how,
because
you
can
see
here
and
empower
and
allow
rules
right,
so
we're
duplicating
a
lot
of
stuff
here,
because
the
action
we
wanted
to
do
with
a
lot
of
things
here,
both
and
just
don't
allow
those.
D
We
were
thinking
about
something
like
making
the
actions
a
list
rather
than
just
one
specific
action.
So
we
can
do
something
like
for
those
workloads
we
wanted
to
both
in
and
allow
that
will
make
the
yamu
shrink
in
a
significant
amount,
because
you
know
we're
it's.
D
Essentially
it's
more
logical,
but
again
it's
gonna,
be
you
know
a
little
bit
more
complicated
than
you
know
what
we
have
here,
because
now,
if
that's
the
case
we
needed
to
validate
you
know
in
the
actions
list,
we
can't
have
something
like
allow
plus
deny,
which
doesn't
really
make
sense.
D
So
sinking,
power
and
allow
is
a
is
a
really
valid
use
case
for
for
this
purposes,
but
we
didn't
really
wanted
to
sort
of
like
introduce
another
action
which,
which
means
empowers
plus
allow
that
will
be
a
little
bit
more,
even
more
confusing.
So.
E
D
E
A
So
yeah,
I
think
that
might
I
mean
this
would
be
a
point
of
confusion
like
this
use
case.
Specifically,
I
really
think
would
confuse
people.
Maybe
if
you
did
like
you
said,
make
the
actions
a
list
so
like
empower
allow
to
comma.
Allow
would
make
more
sense
if
you
want
to
have
them
all
right,
but
yeah,
like
I
can't
think
of
a
time.
You
would
have
a
deny
obviously
and
a
deny
and
allow
without
any
power
right.
You
just
said
that
makes
no
sense.
So.
E
B
This
is
actually
good
feedback,
I
mean
you
know
we
we
initially
thought
already.
This
is
my
part
that
this
list
would
need
a
lot
of
validation,
but
if,
if
it
makes
things
clearer
and
more
compact-
and
everyone
agrees
with
that,
so.
C
So
a
couple
of
thoughts
from
my
side
and
and
one
is
sort
of
the
first
point,
which
is
that
duplication
right,
you
have
to
ever
add
a
lot
of
yaml
to
first
empower
it
and
then
that
exact
same
traffic.
Then
you
have
to
put
the
allow,
as
we
said
right.
C
Yeah,
so
the
second
point
is
that
this
basically
empower
is
is
empower,
is
basically
deny
exception.
It's
not
really
delegating.
It
is
just
saying,
skip
the
denies
and
then
continue
doing
what
you're
doing,
because,
if
you're
allowing
then
you're
allowed,
if
you
don't
allow,
then
you
delegate.
So
this
is
not
even
this
is
just
saying
this
is
an
exception
to
the
denial,
in
which
case
it
should
maybe
rationally
be
under
deny
as
a
subcategory.
Okay,
then
I
accept
this
is
basically
a
denying
effect.
C
B
So
basically,
you're
saying
is
that
the
naming
is
something
misleading
and
I
think
that's
a
valid
point.
It's
something
that
you
know
we
don't
really
want
to
get
stuck
with
names,
but
in
the
end,
as
long
as
the
semantics
of
this
reaction
proposal
makes
sense,
I
think
you
know
naming
is
up
for
grabs
all
right.
Yeah.
C
E
Yes,
yes,
one
more
question:
you
have
to
understand
them.
So
let's
say
that
we
have
something:
that's
been
empowered,
let's
call
it
well
some
other
component
x
and
then
there
is
no
anywhere
allow.
Does
it
then
fall
back
on
the
on
the
action
deny
since
yeah,
I
empowered
you,
but
you
didn't
use
the
power,
so
something
that's
been
empowered,
but
there
is
no
allow
action
for
it
anywhere.
What.
B
E
B
If
there
is,
if
there
is
no
rule,
that
is
actually
matching
that
even
a
network
policy,
then
actually
the
cluster
defaults,
and
you
know
kubernetes
cluster
default
display,
so
we
allow
it.
That
is
also
something
that
I
have
added
in
the
initial
slide.
What
should
be
the
default
disposition
of
such
traffic,
where
there
is
no
rule
matching?
But
that's
you
know.
E
E
C
So
it
just
falls
through
to
anything
just
as
foster
through
netball
does
whatever
netball
does
it
can
allow.
You
know
the
default.
The
normal
rules
of
network
apply,
and
so
the
point
is
that
a
empower
is
not
always
in
power.
In
fact,
empower
here
is
basically
deny
exception
and
when
you
deny
accept
you
do
a
deny
exception,
but
don't
have
an
allow
for
it.
Then
it
effectively
becomes
a
delegate.
So
the
point
is
that
was,
I
think
it
can
be
cleaner
than
that,
and
also
that
implies
that
you
have
to
mention
everything
twice.
C
A
That
makes
sense,
I
think
we
had
already
covered
some
of
that.
Should
we
move
on
to
yeah.
C
C
You
want
to
say
so,
firstly
and
again,
just
maybe
for
pair
and
nadeem's
clarification
since
you
weren't
there.
Now
you
have
the
option
of
putting
an
order
field
in
a
cnp
so
rather
than
just
aggregating
across
the
cnps.
C
C
So
here
the
you
know,
whatever
you
had
in
this
rather
long
and
complex
yaml
can
be
done
with
a
much
simpler
and
shorter
yaml,
because
what
you're
saying
is:
okay,
allow
ingress
from
your
mandatory
namespaces
yeah,
like
your
istio
and
monitoring,
and
these
are
your
strong
allows
and,
and
then
these
are,
your
strong
denies
so
deny
everything
that
is
not
in
the
same
tenant
and
everything
else
falls
through.
So
you
don't
have
to
mention
anything
twice:
okay,
you
either
clearly
allow
something
or
you
clearly
deny
it
or
you
fall
through.
A
C
C
Oh
okay,
we
can
we'll
just
have
an
dns,
as
I
know
now,
as
well.
Yeah.
E
C
E
D
Which
yeah
this
is.
This
is
why
we're
mentioning
we
should
jump
to
4b,
which
is
not
another
use
case
yeah.
I
think
4b
colors.
E
Stay
a
bit,
so
I
would
say,
what's
good
with
with
this
one
is
that
you
have
all
the
information
in
here.
I
know
if
I
look
at
this
one,
I
have
everything
I
need
here.
If
I
go
to
the
second
one,
I'm
gonna
start
have
to
scratch
my
head
and
say
how
many
more
borders
are
there.
How
do
I
know?
Is
it
just
one
or
is
it
20,
others
it's
sort
of
an
open
set.
So
how
do
I
know
if
I
have
all
the
information?
E
C
C
Yeah,
but
but
the
difference
here
is
simply
and
again
the
point
about
the
order
is
not
to
use
it
not
to
rely
on
it
right.
This
is
just
a
way
of
conflict
resolution
so
that
you
don't
have
to
encode
the
priority
into
your
allows
and
denies,
and
you
don't
have
to
sort
of
use,
empower
as
a
way
to
get
around
the
deny
right.
C
You're
simply
saying
this
is
what
I
clearly
want
to
allow.
This
is
what
I
clearly
want
to
deny.
Everything
else
falls
through,
so
it's
simpler
and
cleaner,
in
my
view-
and
I
think
it's
pretty
clear
that
it
is
simpler
and
cleaner,
any
other
notes
here.
So
I
have
some
notes
here.
You
can
look
at
it
later.
A
Cool
also
this
this
just
fyi
on
four.
No,
you
can
go
to
four
four.
I
think
we
did
that
backwards
too.
On
slide.
Wherever
we
listed
the
user
stories,
I
think
we
were
4a
was
showing
4b.
A
So
if
you
c4
b
was
strictly
deny
enter
name
space
traffic
but
delegate
intra
name
space
traffic,
that's
what
this
is
doing
right,
it's
semantics,
but
it
was.
C
Yeah
so
basically,
this
is,
you
know
the
normal
tenant
isolation
case
deny
traffic.
A
C
You
only
write
the
ones
that
the
cluster
and
it's
the
ones
that
he
really
wants
to
allow
or
deny
everything
else
falls
through
and
automatically
is
a
delegate
right.
So
so
here
it
basically
says:
okay,
I
just
have
one
deny
rule
okay,
which
is
that
every
traffic
coming
from
a
named
namespace
that
is
not
in
my
tenant
should
be
denied.
That's
it.
C
E
C
So
one
way
to
do
that
is
4b
which
we're
going
to
talk
about
now.
But
the
other
point
to
note
is
that
we
are
making
an
assumption
about
a
particular
tenancy
model,
but
the
admin
may
want
to
have
various
kinds
of
tendency
models.
One
of
it
could
be
that,
okay,
if
you
tenants,
want
to
freely
exchange
within
each
other,
basically
your
one
tenant.
As
far
as
that
means
concerned.
C
Okay,
you
can
decide
that
these
three
name
spaces
belong
to
you
and
these
four
namespaces
belong
to
you,
but
you
want
to
have
no
boundary
between
those
namespaces
so
for
my
purposes
you're
one
tenant,
so
that's
one
more.
The
second
model
is:
don't
you
risk
that
if
you
have
it
open
that
people
can
hijack
and
sort
of
force
themselves
in
no
they
they
want
to.
C
What
I'm
saying
is
that
there
will
be
various
kinds
of
self-service
models,
some
in
which
the
tenants
say
we
want
to
enforce
the
tenancy
boundary,
but
if
we
only
want
this
one
or
this
two
holes,
the
other
one
is
and
then
we
want
to
have
the
admin
configure
those
holes
and
you
know
otherwise
we
want
to
enforce
the
tenancy
boundary.
The
other
one
is
well.
C
We
frequently
expect
to
need
to
access
traffic
from
each
other's
name
spaces,
so
we
will
not
have
a
tenancy
boundary
and
because
so
we
will
allow
it
is
a
self-managed
tendency,
which
is
what
it
is.
What
is
there
today?
So
we
are
not
enforcing
a
exact
tenancy
model.
We
want
to
give
them
the
tools
to
allow
different
kinds
of
tenancy
models,
some
of
which
are
more
namespace
controlled
and
some
of
which
are
more
admin
controlled.
C
So,
okay
and
let's
go
to
4b.
That
also
shows
one
example
of
that,
so
we
saw
this
is
4a.
So,
basically,
again
in
both
these
cases,
we've
seen
that
the
main
point
here
is
that,
with
approach
b,
you
don't
need
to
put
an
empower
just
to
get
around
the
deny
and
then
again
duplicate
that
in
the
allow.
But
you
just
go
straight
through.
If
so,
one
thing
is.
E
C
But
I'm
in
that
camp
right,
but
because
we
don't
have
network
policies
based
on
services
right,
we
have
policies
that
are
eventually
applied
to
pods.
At
the
end
of
the
day,
these
network
policies
are
all
about
ports.
Now,
that's
where
this
is
again
future
extension,
where
you
want
to
match
right,
having
different
kinds
of
match
actions.
Another
action
could
be
match
on
the
service
rather
than
match
on
the
pods
or
the
port
selectors,
and
you
know
that's
an
episode.
Okay.
C
So
now,
let's
talk
about
4b,
so
4b
is
strict,
deny
but
delegate
the
exceptions.
So
if
you
have
the
three
actions
approach
right
now,
there
are
two
ways
to
do
this:
whether
you
want
to
do
it
on
the
server
side
or
the
client
side.
So
here's
one
way.
A
C
C
C
Oh,
you
changed
it
to
eagles.
Okay.
Sorry
then
I
abhishek,
I
thought
you
had
the
english
version
here
as
well.
B
C
You
I
took
your
feedback
and
I
changed
it.
Okay,
so
earlier
there
was
an
english
okay,
so
there
was
an
english
example
here,
so
I
had
so
well
we'll
come
back
to
the
egress
example
in
a
minute.
So
here
is
the
corresponding
english
example
and
then
we'll
look
at
the
egress
example.
So
if
you
want
to
do
it
with
ingress
controls
again,
that
is
an
implementation
choice.
C
As
long
as
the
functionality
is
the
same,
so
with
ingress
controls,
the
approach
could
be
that
okay
either
you
have
a
particular
class
of
tenants
that
are
publishing
services
or
you
know
you
want
to
do
it
for
exactly
one
particular
tenant
and
you
match
accordingly.
C
Right
and
again
it's
it's
very
simple,
because
it
is
simply
saying
the
guy
who's
publishing
this
service
will
say:
okay,
cluster
admin,
please
allow
me
to
publish
this
service
by
not
enforcing
the
tenancy
boundaries
on
this
service,
which
is
exposing
this
public
service.
So
the
cluster
admin
says:
okay,
I'm
going
to
put
the
tenancy
boundary
around
all
your
pods,
except
the
guys
that
are
tell
me
who
are
who
is
allowed.
C
C
E
E
Okay,
I
think
we
should
open
up,
but
let
we
can
do
that
next
week
to
talk
to
services.
It's
not
that
hard
to
do.
Yeah,
yeah,
that's
also
anger
for
ingress
for
ingress
to
that
sort
of
or
egress
two
a
service
is
no
problem.
Ingress
is
a
different
thing
right
when
something
arrives
at
the
pod,
then
then
it's
hard
to
know
if
you
were
addressed
as
a
service
or
not
in
some,
depending
on
how
the
cni
implements
the
the
dna
so
to
speak,
where
it's
done,
but
it's
clearly
doable
yeah.
C
Exactly
so
that
is
one
of
the
things
again,
it's
all
in
the
list
of
possible
future
extensions.
That's
why
adding
different
kinds
of
matches
you,
you
have
to
be
open
to
allowing
future
kinds
of
matches
and
actions
and
matching
on
service
is
a
possible
action
now
in
it
so
happens
that
in
the
case
of
cluster
ip
services,
very
often
the
way
you
define
a
service
is
by
having
a
particular
selector
on
your
parts
right
and
then
your
replica
set
sort
of
looks
for
pods
with
that
selector.
C
C
Oh
on
the
solution,
too
yeah,
so
that's
where
we
are
going
okay,
so
with
the
solution
to
is
this
yours,
okay,
yeah?
So
this
is
again
I
just
repeated
yours.
I
thought
you
had
that
so
here
we
are
doing
it
on
the
egress.
So
if
you
wanted
to
do
it
on
the
egress,
how
would
you
do
it
so
again,
without
necessarily
having
an
empower
action?
C
C
So
basically,
what
we're
saying
is
we
have
an
egress
policy
where,
if
the
destination
namespace
is
not
the
public
namespace
right
and
a
different
tenant
then
denied
okay,
so
deny
traffic
going
to
a
different
tenant,
which
is
not
the
public
tenant
and
also
deny
traffic
which
is
going
to
the
public
or
other
than
the
public
service,
so
deny
traffic
which
is
going
to
another
tenant,
which
is
not
the
public
tenant
and
to
pods,
which
are
not
the
public
polls.
C
So
the
key
point
here
was
that
the
empower
which
is
really
actually
more
more
or
less
a
deny
exception.
If
you
want
a
dinner
exception,
then
you
just
do
deny
exceptions
using
match
expressions
and
so
on.
If
you
want
to
have
a
new
keyword
for
that
fine,
we
can
do
that
too,
but
it's
not
absolutely
necessary
and
you
know
there
are
the
pros
and
cons.
We've
talked
about
earlier.
So
briefly,
a
few
other
points
well
before
we
go
to
that
and
abhishek
you're
any
feedback
or
thoughts.
D
Yeah,
my
sorry
girl
have
abstract
guys.
My
internet
was
really
unstable
today,
but
I'll.
Let
you
finish.
First.
B
Yeah
sorry,
I
think
first
thing
that
I
can
see
here
is
that
we
don't
allow
names,
spaces
and
namespace
selectors
to
be
part
of
the
same,
because
it
doesn't
they're,
not
they're,
mutually
exclusive,
so
yeah.
That
is.
C
D
Here,
you're,
that's
how
that's
that
was
also.
My
point
is
that
you
know,
as
you
were,
explaining
this
yamo
to
us,
I
think
the
assumption
is
that
you
know
for
the
selectors
you
put
here
as
a
match,
expression
or
or
match
labels,
or
whatever
those
are
sort
of,
like
logically
ended
with
the
with
whatever
the
namespaces
that
you
provide.
D
These
keyword
scopes
right
so
essentially
what
you're
saying
that
is
that
we
needed
a
way
to
sort
of
like
union
some
selections,
so
the
namespaces
are
could
be
selected
by
labels
by
expressions,
and
we
also
introduce
this
a
bunch
of
things
that
are
not
in
kubernetes.
D
That
will
policy
right
now,
which
is
you
know,
self
name,
space,
not
self
name
space
and
for
the
tenant
purposes,
now
even
the
same
same
labels
and
not
same
labels
and
plus
we
needed
the
way
to
do
whatever
is
selected
by
those
kind
of
like
mechanisms
we
needed
the
way
to
end
them
together
or
union
them
together.
D
This
is
also
not
a
sort
of
like
a
burst,
observe
the
practicing
upstream
kurinetis
network
policy
right
now,
because
in
network
policy,
usually,
you
know
in
the
same
namespace
selector
you
can
either
do
a
match
expression
or
a
match
labels
there's
no
way
you
can
sort
of
like
union
two
selections
together
is
our
point.
I
guess.
C
So
two
things
one
is
namespaces
is
something
that
we
are
introducing,
so
we
can
do
whatever
works
for
us
and
secondly,
in
in
kubernetes.
Yes,
you
can
match
you,
you
do
logically
and
match
labels
and
match
expressions
from
my
understanding.
C
So
if
I
had
a
match
labels
here,
it
would,
if
I
recall
correctly
so.
B
So,
to
give
to
give
an
example
in
kubernetes
you
cannot
and
name
space
selector
with
ip
block,
because
that's
conflicting
similarly,
the
same
point
here,
name,
space,
selector
and
name
spaces
are
not
mutual.
I
mean
they're
they're,
mutually
exclusive
exclusive
yeah.
The.
B
So
here's
here's
here's
a
question
yeah,
let's
think
about
the
intra
mean
space
traffic
within
the
same
name,
space
for
a
particular
tenant
right.
How
does
this
expression
in
the
two
matches
like
what
is
the
one
that
matches
it?
It's
pretty
ambiguous
to
me
right
now.
So
how
would
you?
How
would
you
define
that?
Let's
talk
for.
C
Yeah
I'm
getting
there.
So
what
are
you
explicitly
denying
you're
denying
traffic
that
is
going
to
a
different
tenant,
which
is
not
the
public
tenant
right,
so
you're?
Basically,
logically
handing
these
two
deny
the
action
is
deny
and
what
are
you
denying
you're
denying
traffic
going
to
a
different
tenant,
but
not
going
to
the
public
tenant.
C
D
So
I
think
what
what
abstract
was
thinking
in
the
terms
is
that
you
know,
because
your
matching
name,
you
have
a
namespace
match,
not
same
labels,
which,
in
plain
english,
we
will
translate
to
match
namespace.
That's
not
our
own
tenant
right.
So
what
if
there
is
a
namespace
that
has
public
ns
in
our
own
tenant,
then
what
will
those
two
union
come
to.
C
That
will
not
be
denied
this.
This
deny
rule
is.
D
So
so,
essentially,
everything
in
our
own
tenant
right,
which
doesn't
have
pub
ns,
will
not
be
selected
by
the
first
expression
and
yeah.
So
so,
essentially,
what
you're
you're
saying
I
I
I
get
you
what
you're
saying.
I
think
what
you're
saying
is
like
a
strict
logical
end
right
so
and
as
long
as
as
long
as
some
names,
it
doesn't
appear
in
any
of
the
selectors,
and
then
I
mean
as
long
as
a
namespace
appear
in
any
of
the
selectors
here
and
then
it
will
be
in
the
final
result.
D
Essentially
it's
just
that
you
know
this
also
needs
some
sort
of
like
clear
definition.
Where
you
know
we
we
needed
to
to
be
really
clear
on.
You
know
how
the
union
of
the
namespace
selection
is
down
here.
C
Okay,
I
mean
I'm
not
sure
exactly
what
you're
saying
so.
Basically,
the
point
is
that
we
are
defining
this
namespaces
structure
right
as
part
of
the
skip,
and
we
are
adding
these
things
like
same
labels
and
self
and
not
self
so
either
you
can
do
the
logical
expression,
logical,
ending
like
this,
because
today
in
a
namespace
selector,
when
you
have
two
expressions,
they
are
logically
handed
or
you
can.
Since
we
are
combine,
we
are
defining
the
name
spaces
structure.
C
We
can
define
this
sort
of
logic
inside
the
namespaces
structure
itself,
and
that
way
we
don't
need
to.
You
know
a
match,
expressions
and
a
namespace
to
define.
So
this
one
is
up
to
us
to
define
one
way
to
do.
It
is
to
do
logical
and
like
this,
but
as
abhishek
said
currently,
the
name
spaces
was
c
seem
to
be
an
alternative
dna
space
selector.
C
C
C
C
I
believe
that
when
you
want
to
have
these
holes,
a
admin
will
take
a
simpler
approach,
which
will
say:
okay,
I'm
going
to
enforce
the
egress
boundaries
either
either
you
want
to
self-control
all
your
holes,
so
I
can
choose
to
only
enforce
the
system
boundaries
like
cluster
dns
and
istio,
and
you
manage
your
holes
or
I
you
want
to
publish
a
service.
C
C
You
can
do
all
these
variations,
but
if
you
really
want
to
have
okay,
the
admin
also
manages
egress,
but
has
a
selective
hole.
So
here's
one
way
to
do
it.
So
the
point
is
that
there
are
a
few
different
ways
to
do
it
and
again
the
delegation
happens
by
whatever
falls
through
whatever
falls
through
gets
delegated.
A
C
A
If
you
look
at
4b
approach
a,
I
mean,
you're
explicitly,
defining
it
and
that's
why
it
is
longer.
That's
the
whole
point
right.
That's
why
it
is
a
little
bit
longer
of
a
yaml
you're,
explicitly
defining
what
you're
delegating
the
that
is
being
done
is,
if
there's
only
a
delegate
or
if
there's
a
delegate
and
an
allow,
that's
explicit
right.
I.
D
I
think
I
think
to
answer
both
of
your
points.
First
to
to
andrew's
point.
I
think
in
this
particular
case,
the
the
4a
first
kind
of
yama
is
shorter,
because
we
are
not
looking
at
the
opposite
of
what
should
be
explicit
tonight.
We
just
poke
holes,
so
the
logical
complement
of
what
should
be
dedicated.
D
It's
a
little
bit
even
it's
a
little
bit
harder
to
express,
as
you
can
see
here
in
the
in
the
second
example
and
to-
and
I
think
what
was
that,
what
was
the
point
sanjiv
that
you
you're
mentioning
about
this.
D
Right
so
so
that
I
agree,
this
is
just
a
a
skip
to
the
denies.
It's
it's
not
so
what
we're
saying
here
is
in
as
in
4b
is
that
we
have
an
empowered
rule
and
we
don't
have
a
strong
allow
rule,
but
obviously
yes,
it
doesn't
stop
other
people
or
the
customer
mean
from
defining
and
allow
ru
and
another
yamo
in
the
cmp,
and
then
it
will
become
a
strong
allow
rather
than
the
data
gate.
Yes,
I
I
I
understand
both
of
the
points.
C
So
since
we're
running
out
of
time,
I'll
just
mention
a
few
quick
thoughts.
Okay,
so
one
thoughts.
If
we
want
to
take
some
ideas
from
all
of
these
or
of
let's,
let's
say
we-
I
still
see
value
in
both
of
these,
but
just
a
few
kind
of
thoughts
about
alternate
simplifications
right.
So
one
is
that
instead,
perhaps
of
the
current
definition
of
empower,
if
we
really
want
to
have
three
actions,
maybe
the
action
can
be
called
skip
or
delegate
and
that,
instead
of
doing
a
deny
exception,
simply
skips
all
the
remaining
cnps.
C
It
goes
straight
to
the
net
poll
right,
so
there
it
is
a
true
delegate,
because
it
is
not
a
deny
exception
anymore
right.
So,
if
you
want
to
you
know,
if
you
want
to
have
three
actions-
and
you
feel
there
is
an
advantage
of
having
that
explicit
action
for
delicate,
then
call
it
a
delegate
and
the
functional
behavior
of
that
should
not
be
a
deny
exception.
It
is
simply
saying
I'm
skipping
everything
else,
I'm
just
going
straight
to
the
network
policy.
It's
it's
a
it's
an
exit
or
an
escape.
C
Okay,
no
don't
process
any
more
cnp's
go
straight
to
network,
so
that's
one
thought.
The
second
thought
is:
if
we
really
want
to
have
a
deny
exception,
which
is
what
empower
is
currently
doing,
then
don't
call
it
empower,
then
it
is
a
deny
exception
right,
so
you
can
either
call
it
a
deny
exception
or
just
place
it
under
the
deny
section,
as
deny
blah
blah
blah
accept
this.
C
So
that
is
what
is
the
deny
exception
so
right
now
we
are
what
we're
doing
is
actually
a
deny
exception,
but
we
are
putting
it
at
the
top
as
an
empower.
So
that's
a
little
confusing
we
can.
We
can
do
that.
We
can
address
that
either
by
calling
it
an
exception
or
just
having
a
skip.
We
just
skips
every
action
exactly.
E
E
Don't
care
about?
You
have
always
said
it's
okay
and
then
on
the
sort
of
on
the
on
the
ingress
side.
You
sort
of
has
accepted
that
these
things
can
set
up
communication
to
me
if
their
egress
rules
doesn't
allow
it.
Okay,
not
my
problem.
C
Right
so
what
we
are
saying,
maybe
we
are
saying
the
same
thing
here,
which
is
that
today
empowered
is
not
yeah,
it's
not
really
empowering.
Okay,
it
just
it
just
makes
it
more
complicated
right.
So
if
you
want
to
have
an
explicit
action,
then
call
it.
You
know
if
call
it
delegate
and
that
just
skips
over
all
the
remaining
cnps,
not
just
the
denies
right
or
if
you
want
to
do
the
deny
exception,
then
call
it
a
deny
exception
and
put
it
under
deny.
So
that's
one
thought.
C
Okay,
the
second
thought
is
if
we
do
feel
like,
we
want
to
overload
the
priority
and
the
action
then
confirm
that
that
is
okay
for
future
extensibility,
but
I
would
also
suggest
that
we
look
at
it
the
other
way
around,
which
is
that,
if
you
want
to
have
static
priorities,
maybe
allow
should
be
higher
priority
than
deny,
because
the
examples
that
I've
played
with
seem
to
work
better
by
making
allowed
to
be
higher
priority.
C
C
Okay
only
have
skip
and
deny.
That
means
that
the
purpose
of
cnp
is
only
to
do
strong
denies.
Everything
else
is
skipped
that
could
be
even
a
further
simplification,
so
we
we
just
skip
all
the
strong
delay.
Strong,
allow
cases
we
just
say:
I'm
going
to
strongly
deny
this
and
I'm
going
to
use,
skip
to
do
deny
exceptions
and
everything
else
is
delegated.
So
that's
a
further
simplification.
H
C
Yeah
so
again,
you're
right
and
we
in
order
to
what
the
the
the
point
here
is.
C
C
So
either
we
decide
we
are
not
going
to
overload
priority
with
action,
which
means
we
have
to
have
a
separate
plan.
Then
either
you
have
priority
ordering
or
something
like
that.
But
if
we
to
collectively
say
no,
we
do
want
to
overload
priority
with
action.
Then,
like
you
said
it
does
limit
the
admins
possibility.
But
our
focus
is
on
simplicity.
At
that
point,
and
we
say:
okay:
either
we
are
going
to
have
allows
to
be
higher
priority
than
denies
or
we
just
have
no
allows
at
all.
C
C
C
I
know
I
mentioned
a
lot
here
without
us
having
the
time,
so
we
can
think
about
it
later,
so
feel
free
to
kind
of
look
at
these
and
send
us
comments.
Go
ahead
andrew
you
had
some
quick
thoughts.
A
No,
I
just
wanted
to
wrap
up.
I
think
these.
This
is
a
good
slide.
Yeah
does
anyone
else
have
any
last
things
before
we
wrap
up
to
this
one?
I
have.
A
Right,
yeah
yeah,
no
totally,
let's,
I
think
something
that
might
help
people
just
kind
of
joining
the
scene
or
if
we
have
to
present
this
to
sig
network
at
some
point,
is
going
to
be
getting
all
these
little
little
reference
things
figured
out
and
like
actually
standardizing
how
we're
making
these
animals.
A
So
when
I
say
that
I
mean
have
the
same
tenant
name
in
every
animal
like
refer
back
to
be
able
to
refer
back
to
the
diagram
for
every
single
animal
because,
right
now,
it's
not
super.
It's
not
super
clear,
at
least
to
me
some
of
those
continuity
things
across
these
various
examples.
That's.
B
A
great
point:
how
do
we
achieve
that?
Like
do
we
I
mean
I
tried
to
add
some.
You
know
concrete
names,
but
they
were
not
really
well
thought
of.
So
you
know
any
suggestions
to
standardize
those
that
would
be
great.
A
I
think
we
just
go
everything
off
that
diagram.
That
yang
made,
I
think,
that's
and
if
we're
missing
anything
like
let's
voice
those
opinions,
asap
and
comments.
If
not,
we
can
use
the
names
that
are
already
on
the
diagram
so
then
literally
like
if
people
are
looking
through
this,
they
can
just
jump
back
to
the
diagram
slide
and
be
like.
Oh
okay,
that's
what
we're
referencing
here.
That
makes
sense.
B
C
C
Learn
so
I
think
yang
used
some
of
these
labels,
which
are
actually
the
same
as
the
labels
in
the
picture
that
I
had
and
then
they
were,
but
you
might
have
skipped
some
of
the
labels
like,
for
example,
this
one
here
you
know
they're
using
service
pub
as
a
tenant,
but
then
so,
which
is
yeah.
So
we
can
just.
C
They're,
more
or
less
they're,
more
or
less
matching,
but
we
can
make
it
even
more
exact.
A
Sounds
good,
okay,
everyone
well
thanks
for
hanging
around
really
really
good
discussion
today,
I
think
we're
moving
forward.
Let's
comment
on
these
slides
and
and
hopefully
try
to
wrap
up
with
this
presentation,
at
least
in
the
next
one
or
two
meetings.
C
And
the
good
thing
is
now:
we
have
a
clear
comparison,
so
if
any
time
somebody
asks
okay,
you
know
actions
versus
priority,
there's
a
bunch
of
material
which
shows
okay.
These
are
the
pros
and
cons
whatever
we
decide
to
go
with
or
we
decide
to
go
with
the
hybrid.
We
have
the
background
documented.
So.