►
From YouTube: Network Policy API Meeting 20210712
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
A
Great
got
the
magic
button
working
hello.
Everyone
today
is
july,
12th
2021.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
of
sig
network.
This
is
a
cncf
certified
meeting,
so
please
be
kind
to
one
another
and
let's
have
a
good
meeting
today.
So
the
agenda's
pretty
empty
for
this
week
went
over
the
issues
didn't
see
any
new
issues
to
triage.
Did
anyone
have
any
issues
they
wanted
to
talk
about.
A
Cool,
I
didn't
see
any
pertaining
to
network
policy
that
I
thought
were
not
addressed
or
particularly
important,
so
nothing
really
new
there
abhishek
did
you
want
to
talk
about
api
group
name
suggestions.
I
know
this
has
come
up
a
couple
times
now,
but
it
sounds
like
we
need
to
decide
on
a
name.
B
Yeah,
I
thought,
since
there
was
not
much
on
the
agenda,
I
thought
something
that
pertains
to
the
whole
group
and,
most
recently
I
saw
that
the
ingress
folks
have
agreed
upon
the
gateway
or
networking.case
or
io
name.
B
So
so
so
seems
like
you
know
it
might
be
it's
natural
for
us
to
follow
that
lead
and
have
like
a
some
subgroup
name,
dot,
networking
dot,
k,
it's
not
io,
so
I
put
in
a
couple
of
suggestions
there,
but
you
know
feel
free
to
add
more
and
and
if
there's
something
that
sticks
to
the
group
of
us
and
others,
maybe
we
can
propose
that
so
I
just
wanted.
You
know
others
to
also
think
about
it
once
and
see.
B
A
B
Yeah,
the
only
downside
of
that
suggestion
is
that
it's
very
closely
related
to
netfall
and
net
policy,
so-
and
I
remember
seeing
one
comment
from
tim
hawkin
on
the
original
issue,
where
they
are
discussing
how
to
group
these
api
groups
and
like
how
to
you
know,
vet
or
you
know,
form
like
a
separate
repository
for
these
api
groups
and
subgroups.
I
think
in
there
he
mentioned
something
like
we
should
avoid,
having
the
resource
name
as
a
subgroup.
B
networking
and
they
chose
gateway,
something
which
is
a
little
generic.
So
that's
the
only
thing
that
I
feel
like,
maybe
maybe
something
that
will
be
pushed
back
on
that
fault,
but
still
it
still
doesn't
really
align
one
to
one
with
network
policy
resources
just
a
short
name
for
it.
But.
C
B
C
Yeah
yeah,
I
think
that
makes
sense.
So
we
can
have
you
know:
access
control,
dot,
networking,
dot,
k,
star,
io
or.
A
C
D
C
D
C
D
C
You
have
this
cluster
network
policy,
you
go
to
a
resource
called
cluster
network
policy
under
policy.networking.com
and
then
later
on.
When
you
have
a
networking
policy,
v2
that'll
have
yet
another
name
which
will
not
be,
and
the
policy
word
is
repeated.
It's
not
strictly,
it's
not
strictly
a
conflict.
It
just
seems
like
the
gateway
is
completely
different
from
english.
It's
a
completely
different
word.
They
didn't
say
they
didn't
sort
of
have
a
variation
calling
it
like
english
gateway
or
whatever
right.
The
gateway
is
completely
separate.
Nothing.
D
C
B
B
Security
and
not
just
it,
goes
beyond
networking
also,
but
but
if,
since
it's
part
of
the
networking
subgroup,
I
mean
you
can
think
of
it
as
a
security.
C
C
A
C
A
Yeah
totally
and
just
for
people
who
haven't
been
or
didn't
go
to
the
upstream
meeting,
I
I
actually
missed
it,
but
I
got
filled
on
what
happened.
We
are
asking
some
of
the
ups
head
upstream
guys
to
come
to
next
monday's
meeting,
so
we
can
hash
out
some
stuff
with
cmp
and
more
about
the
stuff.
That's
why
abhishek's
already
added
stuff
for
next
week
so.
B
Yeah
yeah,
I
wanted
to
use
sort
of
update
for
that.
So
I
reached
out
to
tim,
horton
and
casey,
and
tim
mentioned
that
he's
out
of
office
the
whole
of
next
week.
I
think,
he's
on
a
family
vacation.
B
So
you
know
I
asked
him
if
we
can
do
sometime
later
in
this
week
or
sometime
after
the
week
after,
but
he
did
mention
saying
that
friday
in
the
morning
worked
for
him.
So
so
I
was
thinking.
Maybe
we
should
do
that
sooner
rather
than
later.
So
if
we
can
see
whether,
like
dan
dan
and
casey,
can
also
make
it
this
friday
morning
and
then
maybe
we
can
at
least
have
a
quorum
and
try
to
do
it
before
tim
takes
off
for
his
video.
A
Yeah,
okay,
cool.
That
makes
sense
as
long
as
we
record
it,
then
anyone
who
can't
make
it
can
watch
it.
I
think
that'd
be
good.
A
B
The
summer
is
hard,
it's
very
hard
to
figure
a
good
time
for
everyone,
but
if
at
least
you
know,
maybe
dan
vince
or
dan
williams
can
make
it.
Maybe
we
have
enough
quorum
to
discuss
a
bit
at
least
move
forward,
because
if
you
want
to
wait
till
the
end
of
the
month,
then
it
will
be.
You
know
it
will
be
like
stalemate
for
for
a
while.
So
can
you
contact.
B
Thomas,
I
can
talk
to
him
as
well.
Yes,
the
only
problem
is
that
friday
morning
is
gonna
be
is
friday
evening
and
it's
gonna
be
hard
for
him
to
join.
I
know
he
does
join
at
times,
but
I
can
ask
him
if,
if
he
or
some
other
representative
from
syria
community
can
join
but
did.
B
I
think
tim's
calendar
was
not
that
open
this
thursday.
I
think
he
he
mentioned
friday
anytime
in
the
am,
is
good
or
or
the
following
monday.
After
this
video,
which
would
be
20,
sorry
26,
and
I
think
that
also
brings
casey
on
board,
because
I
think
he's
back
so
we
can
have
26th
as
a
option
or
if
you
know
the
dan
mitchum
and
william
can
make
it
this
friday,
then
maybe
we
can
do
it
earlier.
A
Okay,
all
I
dan
winship
was
just
getting
back
so
I'll
reach
out
to
him
after
this
meeting
or
both
of
them.
After
this
meeting,
I
just
hadn't
pinged
them
yet,
but
friday's
usually
easier
as
long
as
neither
of
them
are
on
ptf
so
should
be.
It
should
work.
A
Okeydoke
yeah
and
for
anyone
who
can't
make
it
like,
I
will
try
to
record
that
meeting
because
I
know
it
should
be
kind
of
you
know
informative
and
then
we
can
go
over
kind
of
if
we
get
to
meet.
We
can
go
over
what
happened
on
that
monday
meeting
as
well.
B
B
I
was
thinking,
maybe
10
a.m.
10
30
a.m,
11
a.m,
pacific!
So,
sometime
in
between
of
that
and
take
take
an
hour.
B
I
will
definitely
send
out
a
email
and
to
the
networking,
email,
mail,
mailer
and
also
on
the
sig
network
and
signature
policy
slack
channel,
but
let's
get
confirmation
first
from
the
others
and
then
maybe
we
can.
B
D
A
A
Cool
okay,
awesome:
well,
we'll
keep
everyone
updated
on
that,
like
abstract
said,
and
if
you
need
help,
I
would
check
with
anything
just
think
me.
I
can
help
plan
it
or
send
out
invites
or
whatever
you
need.
B
A
Yeah
I'll
reach
out
to
them
after
this
meeting
cool,
okay.
Well,
we'll
talk
more
about
the
api
group
naming
suggestions
next
week,
then
after
some
talk
with
some
of
those
guys
and
then
give
everyone,
a
second
to
you
know
think
about
what
they
like
the
best
upvote
down
vote,
and
we
should
decide
kind
of
soon.
I
think
so.
C
I
think
you
know,
let's,
let's,
let's
get
the
main
thing:
let's
get
agreement
on
the
cape,
because
the
naming
sometimes
I've
seen
that
these
become
tangential
discussions
and
if
you
end
up
not
discussing
the
main
issues.
So
at
this
point
really
the
main
issue
is
getting
some
version
of
the
cape
approved
once
the
kepler's
approved
agreeing
on
the
name
should
be.
But
if
we
start
debate
on
the
name,
that
becomes
a
tangential
discussion
and
we
don't
end
up
having
time
for
the
core
discussion
of
what
features
the
cap
should
have.
B
Very
nice,
I
think
yeah,
but
I
think
the
name
is
not
just
for
the
cnp,
but
it's
like
a
generic
thing
for
you
so
a
issue,
but
it's
I
mean
I
guess
you
can
work
parallelly
on
it.
It
should
not
be
coupled
with
the
cnp
correct
yep.
Yes,.
A
For
v2
as
well
and
any
other
object,
okay
cool
well
just
keep
thinking
about
it,
feel
free
to
add
to
the
list.
If
you
want
to
open
an
issue
gang
I'll
feel
free,
that's
fine,
too.
Whatever
works
the
best,
so
we
have
that
repo
there
for
anyway
so
works
for
me
cool,
so
v2
working
dock
I've
been
calling
this
out
the
past
couple
meetings.
I
gave
it
a
round
review
today,
prasada
nadim,
do
you
wanna?
We
have
a
lot
of
time
left.
F
Yes,
yeah,
let's
do
that
time
to
I
mean
you
know,
maybe
let's
go
through
some
of
the
comments
and
you
know
maybe
then
you
know
we
can
work.
A
Yeah,
for
sure,
so
do
you
want
to
just
give
a
high
level
like
what
you
two
created,
this
motivation
doc
for
to
what
was
the
main
purpose.
F
Yeah
so
the
initially
we
started
creating
the
use
cases
you
know
along
with
abhishek
and
yang,
then
one
of
the
discussion
came
out
is
first,
let's
capture:
what
are
the
things
you
know
we
wanted
to
go
after
as
part
of
v2
so
that
you
know
it
it
becomes.
If
somebody
takes
a
look,
you
know,
hopefully
they
get
the
picture.
What
is
that
you
know
we're
after
for
v2?
F
So
that's
the
motivation.
So,
but
I'm
sure
you
know
we
haven't
fully
captured.
You
know
what
we
want.
You
know.
Maybe
you
know
that's
where
if
we
guys
can
start
helping,
you
know
we
can
shape
this
document.
F
So
that's
the
you
know,
that's
the
you
know
main
intent.
So
so
here,
basically,
what
are
the
things
you
know
we
wanted
to
go
after
and
you
know
we
try
to
list.
You
know.
For
example,
you
know,
increase
egress
policy
definition
limitations.
F
So
and
you
know
we
try
to
capture
that
like
and
I
I
do
see
comments
from
you
and
you
know
sanjeev,
so
so
here
you
know
we
should.
Should
we
just
you
know
quickly,
walk
through
and
each
you
know.
You
know
each
headline.
F
F
So
one
is
like
you
know.
Natural
way
of
you
know
writing
the
policy.
You
know
when
we
are.
You
know
when
we
try
to
write
a
policy.
You
know
we
typically
say,
like
you
know,
communicate
between
a
to
b
or
you
know
what
you
know.
That
kind
of
you
know
natural
thing.
F
So
so
that's
where,
like
you
know,
we're
trying
to
capture
that
as
one
of
the
you
know
point
to
you
know,
go
after
multiple
endpoints.
So
so
that
is
where
you
know.
We
are
trying
to
give
some
more
details
in
here
and.
A
It's
a
quick
question,
though,
like
how
do
you
do
you
want
this
document
to
flow
like
this
is
what
we
want
to
get
out
of
e2
or
should
it
flow
like?
This?
Is
the
problems
with
v1
and
because
of
those
problems?
This
is
what
we
want
to
get
out
of
v2
like.
Is
it
totally
just
like
a
clean
break?
We
aren't
even
gonna
refer
to
v1,
or
is
it
like
you,
wanna.
F
Yeah,
actually
I
I
would
prefer
the
totally
breakout
way,
but
I
think
sanjeev
and
others
said
hey.
You
know
what
are
the
problems
with
v1?
Why?
Why
are
we
doing
this?
So
actually
that's
a
good
question.
Even
you
know
evs
I
was
contemplating
you
know.
How
do
we
write
like
you
know?
F
You
know,
hey,
we
have
a
clean
breakout
day.
This
is
what
we
wanted
to
do.
So,
actually
I'm
not
sure-
and
I
would
take
you
know
everybody's
suggestion
and
you
know
I
can
morph
into
the
way.
You
know
everybody
agrees,
but
right
now,
here
at
least
you
know
we
try
to
do
like
you
know.
Maybe
I
don't
know
whether
we
are
trying
to
thread
on
both
boats,
but
you
know
one
way
we
are
trying
to
tell
hey.
You
know
this.
We
can't
achieve
through
e1.
F
C
So
in
my,
in
my
personal
view,
right
something
that's
not
in
natural
way
that
I
would
perhaps
consider
it
as
a
secondary
reason.
Right
primary
reason
is
a
functionality
that
is
really
important
but
cannot
be
done
with
v1.
That
would
be
a
primary
reason.
C
F
It
so
so
I
mean
you
know
so
so
in
here
right.
If
you
go
to
the
next
subheading
andrew,
so
you
know
half
you
know
how
halfway
communication,
that's
another
one
and
also
in
the
top
one,
like
you
know,
we
you
you
won't
be
able
to
like.
You
know,
specify
one
policy.
F
F
C
He
if
I
am
responsible
for
service
a,
I
do
not
need
to
figure
out
a
policy
for
service
b.
It
keeps
everybody
every
service
developer
responsible
for
the
policies
of
their
service.
But
if
you
write
an
end-to-end
policy,
then
I
am
writing
a
policy
which
affects
both
my
service
and
your
service.
So
it
includes
it.
It
adds
a
bit
of
friction
between
the
developers
because
you're
adding
service
a
I'm
writing
service
b,
but
I'm
also
writing
a
policy
that
combines
service
a
and
b
so.
F
Yeah,
I
think
that's
a
good
argument,
but
the
I
mean
at
least
one
camp
I
see
is
like
you
know,
when
we
write
policies,
you
know
they
have
to
be.
You
know
you
take
a
name
space
right
in
the
admin
boundary.
You
know
the
policy
has
to
be
clean.
F
You
know,
let's
say
you
give
you
know
authority
to
for
a
service
to
create
his
own
policy
and
the
other
service.
Might
you
know
do
differently?
You
don't
have
a
cohesive
thing
right.
So
that's
where,
like
you
know,
having
having
a
bigger
picture
view
is,
is
generally
a
good
idea,
for
you
know
security
right.
You
know
you
don't
want
to
be
siloed
thing.
C
G
Yeah,
so
send
you
so
my
input
on
that
is
see
there
is
in
kubernetes
at
least
we
don't
have
the
concept
of
service.
I
mean
we
have
a
kubernetes
service,
but
here
I
think
we
are
talking
more
in
terms
of
applications
right
so
that
construct
doesn't
exist.
So
the
only
construct
where
we
have
the
admin
boundary
is
the
name
space.
So
within
a
name
space.
G
Even
if
I
am
a
developer,
I
write
like
let's
say
I
deploy
my
one
application
in
one
name,
space
right,
I
write
my
web
tier
can
talk
to
my
listed
database.
Sorry.
E
G
My
app
or
my
backend
tier
right
and
then
I
say
on
the
back
end
side,
my
back
and
tier,
can
talk
to
the
app
here
right.
So
if
we
keep
the
name
space
boundary
right
in
a
way,
we
actually
control
both
sides
of
it,
but
still
we
have
to
replicate
it
in
two
places.
E
G
Yes,
so
if
you
see
what
I'm
trying
to
say
is
if
they're
in
the
same
name,
space
and
name
space
is
the
only
construct
other
than
the
part
right
which
which
makes
which
is
applicable
here,
then
defining
ones
which
takes
care
of
both
sides
within
the
same
name.
Space
is
more
practical.
If
services
are
deployed
across
name
spaces,
then
even
unless
you
go
to
cnp
right,
even
if
you
define
the
policy,
you
are
still
controlling
only
the
part
of
your
namespace.
So
unless
other
names
they
say,
okay,.
C
Even
so,
I'm
I,
as
a
developer
of
service,
a
the
fact
that
both
service,
a
and
service
b,
are
in
the
same
name.
Space,
doesn't
change
the
fact
that
I
know
service
a
best
and
you
know
service
be
best,
and
we
should
both
be
respectively.
Writing
the
policies
for
service
a
and
b,
so
that
you
can
decide
later
on.
Hey
service
b
was
allowing
port
75.
Now
it
decides
it's
no
longer
allowing
port
75
and
you
do
not
need
to
coordinate
with
me
because
I'm
writing
a
different
service.
C
My
point
is:
it
fits
into
this
philosophy
behind
this
whitelist
model,
where
policies
are
selected
by
certain
parts
and
the
writer
of
that
part
knows
what
that
part
should
accept
and
not
accept.
So
I'm
not
maybe
I'm
being
a
little
bit
of
a
devil's
advocate,
but
my
point
is
that
there
is
valid
reason
for
the
current
design.
F
You
know
I
mean
it's
absolutely
correct.
Essentially,
you
know
there
is
a
valid
reason,
but
it
is
going
to
bring
up
the
limitations
right.
So
that
is
what
we
are
trying
to
highlight
see
you
have
a
viewpoint
from
service
one.
Let's
say
you
know:
web
server
is
then
app
service.
Then
everybody
is
working
in
these
cells.
As
a
you
know,
security
admin
as
a
you
know,
higher
admin.
C
C
F
C
F
Our
just
sick
networks
advocate
true,
true
true,
so
so
so.
Basically,
I
think
you
know
I
mean
at
least
you
know.
If
you
I
mean,
if
I
see
you
know
when
I
work
with
my
my
customers,
what
I
see
is
like
you
know
they
want
to
have
a
cohesive
story
right,
so
there
would
be
one
admin
you
know
who
is
controlling
an
application?
F
They
wanted
to
write
a
policy
for
that
they
typically
don't
give.
You
know
you
know
a
chance
to
a
particular
person
to
write
things,
but
they
would
in
a
given
application.
You
can
have
multiple
policies,
that's
how
I
I
have
seen
where
policy
one
belongs
to
web
and
policy
to
could
belong
to
you
know
app
and
policy
three
could
be
belong
to
db
in
a
given
application.
Like
you
know,
now
you
have
a
cohesive
story.
This
application
will
consist
of
p1,
p2
and
p3.
C
No,
it's
not
a
dead
horse.
I
mean
I
don't
want
to
rat
hole
on
this.
The
point
is,
we
should
have
a
good
explanation
for
justifying
it,
and
maybe
the
answer
would
be
that
we
need
both
sets
of
models,
because
different
developing
models
could
be
different
right
and
I
wouldn't
use
the
word
silo.
The
whole
point
about
microservices
is
each
service.
C
F
Yeah,
I
think
you
know
I
mean
I
mean
I
mean
anyway.
You
know
the
both
sets
of
the
arguments.
If
he
can
help
us,
you
know
articulate
we
would.
You
know,
take
that
input
sanji
for
sure.
C
My
current
thinking
is
that
we
might,
if
we
want
to
justify,
we
can't
say
that
the
current
model
can't
be
supportable.
It'll
have
to
be
in
addition
to
the
current
model.
You
have
to
support
the
case
where
each
policy
is
applied
to
the
service
without
the
end-to-end
view,
and
then
optionally
have
the
end-to-end
view.
F
Okay,
so
so
are
you
saying
you
know
we
have
to
maintain
the
existing
increasing
grace
in
addition
to
what
we
are
going
to
propose,
I
mean
I
think
we
have
to
be
prepared
for
that,
because.
C
If
we're
going
to
say
that
we're
going
to
get
rid
of
the
current
model,
completely
we're
going
to
only
have
the
end-to-end
model,
we'll
need
more
justification.
So
just
prepare
the
justification.
If
you
feel,
if
you
feel
like,
we
only
want
to
have
the
end-to-end
model,
but
I
think
my
current
gut
feel
is
that
there
is
value
in
the
current
model
as
well.
So
you
can't
throw
away
the
current
model.
A
I
mean
what
do
you?
What
do
you
mean
end-to-end
model,
though,
like
doesn't
that
start
going
into
the
cmp
scope,
if
you're
trying
to
totally
block
off
two
endpoints
in
different
name
spaces,
I
get
the
end
model
may
be
isolated
to
a
single
name,
space.
F
Exactly
yeah
because
you
know
and
as
an
application
owner
I
wanted
to
see
what
is
the
you
know
who
is
communicating
to
who
and
how?
F
F
E
C
Here
is
that
if
you
are
going
to
propose
that
we
completely
get
rid
of
the
current
model
in
which
policies
are
attached
based
on
services
like
the
it's,
it's
a
drastic
change,
it'll
it'll
be
a
more
challenging
cell
because
you
are
quite
diverging
from
netball
v1,
so
you'll
have
stronger
arguments.
You
will
need
guys.
G
Wrong,
no,
I
think
this
is
correct,
but
at
the
same
time
there
is
a
concern
that
the
whole
concept
of
end-to-end
policy
right
has
an
impact
on
the
on
the
policy
selector,
the
quad
selector
itself.
Right
because
we
will
be
selecting
the
port
selector
on
on
a
very
different
boundaries,
right,
maybe
we'll
say
we're
app
equal
to
one
particular
app
so
combining
both
models
and
is
still
honoring,
the
port
selector.
I
have
to
go
back
and
see
if
we
are
creating
more
complex
scenarios
than
solving
the
complexity
in
the
existing
model.
G
G
C
Yeah,
so
maybe
that
also
has
a
challenge
so,
but
my
point
is
that
this
a
this
is
a
performance
improvement
over
the
current
I
mean
yeah,
the
one
can
argue,
there's
the
ease
of
use
or
whatever,
but
it's
not
giving
you
new
functionality,
which
you
cannot
do
with
netball
v1.
C
F
But
don't
you
think
you
know
writing
you
know
50
policies
to
versus,
like
you
know,
one
or
two
policies
to
understand
things
is
enough
justification,
because
this.
C
C
Maybe
I'm
not
aware
that
it.
The
difference
is
that
drastic
50
versus
two,
because
eventually,
even
if
the
policy
is
attached
to
each
service,
he
needs
to
just
do
the
minimum
number
that
his
service
accepts
right.
So
I
could
be
wrong,
but
I
feel
like
the
difference
is
going
to
be
more
likely
of
the
order
of
okay.
This
approach
requires
10
policies,
and
this
approach
requires
five.
As
opposed
to
you
know.
One
approach
requires
50
and
the
other
one
requires
five,
but
prove
me
wrong,
and
maybe
I'm
not
seeing
it.
F
No
no,
but
I
think
you
know
the
simplistic
three-tier
application
you
know
we
can
show
that,
like
you
know,
one
policy
versus
three
policy,
six
policies,
but
but
in
reality
you
know
it's
not
a
single
dimension
thing
right.
When
we
choose
the
you
know,
part
selector
as
a
single
dimension,
you're
right
once
once
we
start
choosing
the
parts
electrons
multiple
dimensions.
This
number
is
going
to
grow
because,
let's
say
tier
web
and
you
know
a
location
bangalore.
F
You
want
to
have
one
policy
for
ingress
and
you
know
tier
vaping
locations
and
evil
you're
going
to
have
another
policy,
because
you
know
because
of
you
know,
because
of
the
part
selector
you're
choosing,
but
whereas,
if
I
take
it
to
the
higher
level,
you
know
which
is
the
application,
then
I'm
going
to
say
tier
web
and
bangalore
can
communicate
to
you
know
tier
app,
and
you
know,
location,
bangalore
and
same
thing.
Like
you
know,
I
I
can
go
at
little
higher
level
have
one
policy
so
so
that
is
the
you
know.
F
C
F
F
A
stronger
case,
that's
it
yeah!
No,
I'm
I'm
totally
with
you.
I
think
I'm
I'm
seeking.
Actually
we
are
seeking
input
together.
Actually.
F
Okay,
so
that
is
one
so
we
talked
about
multiple
policies.
So
so
then
the
other
thing
is,
you
know,
deny
rules,
I
think
already.
You
know,
abhishek
and
team
put
the
case
forward.
Why
we
have
you
know
we
need
to
have
the
deny
rules
so
sanji.
We
also
did
that.
F
So
we're
just
you
know
we're
just
taking
that.
You
know
our
deny
rules
also
needed
so
so
then
the
next
one
I
mean
the
other
one
is
like.
You
know.
I
think
you
know
it
might
go
back
and
forth.
On
the
you
know:
half
you
know
half
communication
path,
so
I
think
we
already
talked
on
that.
F
So
then
the
next
one
is
the
policy
explosion.
So
so
so
the
policy
explosion,
you
know
essentially
for
the
given
example.
You
know
it
might
work
for
using
you
know,
customize
or,
like
you
know,
any
other
templating
tools,
but
the
problem
is
you're
going
to
have
the
that
many
number
of
policies
in
the
system.
You
know
once
these
templating
tools
are
done
so
so
that
means
the
number
of
policy
explosion
is
not
going
to
be
changed.
F
Only
the
templating
tools
will
help
you
to
not
to
write
them,
but
you
know
to
make
it
little
easy.
So
that
is
one
point,
and
the
second
point
you
know
is
this:
template
string
tools
doesn't
help
you
in
doing
the
dynamic
things
so
dynamic
things
means.
Let's
say
you
know.
If
I
have
a
location
you
know
initially,
I
started
with
10
locations,
then
I
started
growing
to
15
locations.
F
So
with
the
language
we
are
extending,
you
know
you
don't
have
to
like.
You
know,
do
anything,
because
the
language
itself
takes
care
of
the
policy
explosion.
So
I
I
we
try
to.
You
know,
write
that
and
you
know,
strike
up
some
other
things
which
is
confusing.
C
F
F
F
So
so,
basically,
the
match
condition
will
instantiate
a
different
set
of
dimensions,
cross-cutting
dimensions.
On
top
of
the
you
know,
a
regular,
you
know
endpoint
1
and
0.2.
G
Yeah
and-
and
if
you
see
in
something
even
in
the
current
cnp,
I
think
you
and
young
and
adishik
has
proposed
name
space
equal
to
true
two
to
create
a
condition
where
both
both
end
points
belong
to
the
same
name
space.
So
in
in
this,
we
are
extending
that
idea
to
any
kind
of
a
level,
not
necessarily
only
on
the
name
space
you
can
do
match
equal
to
side.
So,
basically,
both
end
points
have
to
be
part
of
the
same
site
or
part
of
the
same
deployment
like
production
or
testing.
D
And
distinctions
so
for
the
cmp
cap
we
also
have
iterated.
So
initially,
we
sort
of
like
feel
like
the
namespace
could
only
the
namespace
would
be
the
boundary
for
tenants
and
that's
why
we
did
the
match
same
name,
space
and
different
name
spaces
scheme.
But
later
I
think,
if
you
look
at
the
latest
cap,
we've
decided
that
it
can
be
the
case
where
you
know
a
single
attendant
consists
of
different
name
spaces.
D
Now
you
needed
something
similar
to
this,
whereas
you
know
you,
you
wanted
to
sort
of
allow
traffic
from
namespaces.
That
has
the
same.
Maybe
deployment
or
app
tag
as
as
you
are
currently
and
that's
what
we
also
already
support
in
the
cnp
proposal
as
well.
So
there's
not
only
the
match,
names
same
name
space,
but
also
match
namespaces
that
have
the
same
label
as
yourself.
Now
in
the
in
the
cat.
F
Okay,
okay,
I
think
I
think
I
mean
that
at
least
that
gives
the
foundation
to
this
idea
right
so
where
what
we
are
saying
is,
you
know,
match
expression,
initially
start
with
the
match
and
labels.
You
know
you
can
have
a
match
deployment
and
not
site,
or
you
know
it's,
it's
a
really
an
expression
right,
regular
expression.
F
A
B
So
but
I
think
the
deployments
and
other
things
kind
of
like
boil
down
towards
labels
eventually
right,
because
then
your
kind
of
labels
are
kind
of
the
building
blocks
for
all
these
higher
level
constructs.
So
if
you
have
a
deployment
which
has
certain
labels
which
will
be
applied
to
all
of
those
parts
eventually,
I
think
you
can
still
leverage
the
labels
and
what
young
mentioned
like
the
same
label
value
thing
that
we
are
introducing
with
cnp.
B
F
Okay,
so
so
here
when
we
say
deployment
right,
match
deployment
see
the
way.
I
I
I
mean
we
split
the
you
know:
label
right.
You
know
it
has
a
key
and
value.
So
when
we
say
the
you
know
match
in
a
regular
expression,
it's
the
regular
expression
of
the
keys.
B
You
mean
sorry,
do
you
mean
key,
or
do
you
mean
the
resource,
the
kind
of
the
resource
like,
for
example,
the
same
label
value,
is
today
only
introduced
for
name
spaces
and
not
for
like
pod
resources.
B
So
are
you
referring
to
that
or
you're
referring
to
the
the
key
of
a
label
kiki
available,
so
that
you
can
do
so?
Why,
when
we
plan
to
add
the
same
label
value,
we
plan
to
have
it
as
a
list
which
accepts
the
keys
to
which,
whose
values
should
be
the
same?
So
so
you
can
specify
saying
that
you
know
for
for
these
resources,
for
these
namespaces
group
them
based
on
the
label
key
tenant
and
as
long
as
the
value
for
the
key
tenant
is
same,
they
all
become
part
of
the
same
group.
F
Okay
yeah,
so
so
basically
you
know,
I
don't
know
whether
it
is
the
same,
but
here
you
know
you
could
have
a
regular
expression
itself.
You
can
say
deployment
and
not
sight.
Are
I
mean
it's?
It's
just
a
regular
expression.
You
know.
Whatever
the
combination
you
think
is
right.
Can
we
put
in
so.
B
So
what
does
the
site
boil
down
to
what
is
the
site
here,
and
also?
Can
you
clarify
when
you
say
deployment?
Are
you
talking
about
the
deployment
resource
or
you're
talking
about
deployment
as
a
label?
Key
yeah
here
you
know
the
label
key
got
it.
I
think
that
kind
of
confused
me,
because
I
thought
you
were
talking
about
the
deployment
resource
of
communities.
F
Yeah
so
the
reason-
but
I
think
you
have
probably
with
the
example
but
many
yeah
so
because
we
we
use
the
same
example,
and
you
know
we
just
use
that
way.
Yeah
we,
you
know
to
remove
that
confusion.
We
can
change
some
labels
in
in
this
example,
cool
yeah
and
moreover,
moreover,
just
I
mean
it's
not
like
you
know,
you
know,
I'm
trying
to
you
know
push
this
or
anything
so,
but
you
know
we
work
with.
F
F
So
when
I
do,
I
don't
want
to
name
the
customers,
but
they
have
seen
like
you
know.
You
know
a
lot
of
benefits
with
this.
You
know
match
clash.
B
Now,
certainly,
I
think
you
know,
I
think
your
argument
is
valid
in
terms
of
you
know
reducing
the
number
of
policies,
but
perhaps
you
also
want
to
you
know
when
you
next
talk
to
your
customer,
because
the
cluster
network
policy
resource
does
not
exist
today
if
it
were
to
be
existing
in
kubernetes,
and
you
know-
and
I
think
some
of
the
use
cases
that
you
also
mentioned
kind
of
like
the
persona
could
have
been
admin
and
there
is
a
set
of
use
cases
for
a
personal
developer.
B
B
Network
policy
will
also
reduce
the
need
for
redundant
rules
or
policies
across
all
namespaces.
B
And
it
still
is
an
overhead
in
terms
of
a
lot
of
policies.
Then
maybe
we
still
need
to
think
about
evolving
it
in,
in
the
fashion
that
you
are
proposing.
F
Yeah,
I
think,
see
the
reason
I
mean
you
know
when
we
with
our
customers,
so
we
do
have
a
a
global
policy
across
you
know
across
namespaces
in
even
across
clusters.
You
know,
that's
of
you
know
these
definitions,
you
know,
are
working,
but
what
what
I
have
seen
is
some
of
our
customers,
so
they
define
a
tenant
and
the
tenant
boundaries.
The
name
space
under
that,
like
you
know
they
have
an
application
or
multiple
applications.
F
So
so
in
that,
like
you
know
they
want
everything
to
be,
you
know
tenant
scoped,
they
don't
want
anything
in
the
higher
level
construct,
but
there
are
some
customers.
What
we
have
seen
is
like
you
know
they
wanted
to
do
the
other
way,
also
where
they
wanted
to
define
one
policy
which
will
affect
all
their
tenants.
F
So
so
that
goes
into
the
you
know,
cnp
or
the
the
higher
level
global
policy
and
individual
tenant
has
his
own
policies
and
the
top
top
one
always
gets
precedence
and
the
then
the
tenant
policies.
Would
you
know
go
right
after
that,
so
I
mean
in
a
way
you
know
I
I
have
seen
you
know
both
cases
where
in
a
given
a
tenant.namespace,
somebody
wants
to
run
a
application
or
multiple
applications.
C
We
can
talk
a
little
bit
more
about
this
tendency
application,
but
that's
a
side
topic,
so
we
can
continue
because
that
that
kind
of
goes
back
into
how
we
are
justifying
the
cnp
as
well.
Okay,
I
would
be
interested
in
knowing
the
tenancy
model
that
you've
seen
in
the
customers,
meaning
whether
it's
admin
controlled
or
developer,
controlled.
F
Yeah,
I
think
you
know,
I
mean
at
least
the
most
most
of
the
cases
were.
What
I
have
seen
is
admin
controlled.
F
C
C
That
requiring
people
to
have
to
communicate
out
of
band
to
the
admin
to
say,
hey,
I
want
to
create
a
new
tenant.
You
know,
but
anyway,
it's
a
whole
discussion
on
that.
We
can
continue
on.
The
main
point
here
I
think
bottom
line
is
that
my
view
is
that
these
are
all
sort
of
good
points,
but
because
these
are
drastically
different
from
netball
v1,
it
will
require
a
stronger
justification
to
pass
the
sig
network.
F
Agreed
I'm-
and
I
think
you
know
if
he
can,
you
know
sanji
obviously
can
enter
and
everybody
if
he
can
help
us.
I
mean,
of
course,
first
you
have
to
agree.
Then
then,
then
you
know
help
us
articulating
it.
You
know
we
would
take
that
and
that's
why
I
gave
edit
permissions
to
everybody.
You
know
just
please
go
ahead
and
modify
you,
you
don't
have
to
give
comments,
and
just
put
you
know
finish
your
initial
at
the
top
and
you
know
keep
adding
it
then.
E
A
Think
it's
like
a
ongoing
piece
of
work,
but
I
think
thanks
for
starting
it.
I
did
want
to
just
mention
the
we're
almost
out
of
time,
but
this
multi
policies
for
multi-interface
pods,
I
put
in
the
agenda,
but
there's
actually
already
something
like
that
implemented.
So
it
might
be
good
to
take
a
look
and
I
will
grow
with
them
by
the
network
plumbing
working
group
which
they
reached
out,
and
I
went
to
one
of
their
meetings
last
week.
So
just
give
that
a
look
too.
A
A
And
the
writer
of
that
is
actually
based
out
of
china.
So
it's
hard
for
him
to
come
to
this
meeting.
It's
like
a
horrible
time
or
else
I'm
sure
he
would
come
and
talk
about
it
more.
But
as
I
get
more
info
on
it,
I'll
refer
to
the
group.
F
Got
it
got
it
so
so
I
I
think
you
know
so
andrew
and
everybody.
If
you
can
start
editing-
and
you
know
you
know
giving
your
context
there
and
input
there,
then
you
know
maybe
in
the
next
meeting
you
know
we
can
review
together
and
you
know
start
firming
up
before
we
go
to
bigger
audience.
You
know.
A
Yeah
sounds
good,
we'll
keep
it
ready,
okey-doke!
Well
we're
right
out
at
the
top
of
the
hour,
so
we'll
go
ahead
and
wrap
up
unless
anyone
has
any
last
things.
B
Would
you
reach
out
to
the
folks
at
redact
to
see
if
friday
morning
works
for
them
or
morning
bsd,
so
I
don't
know
which
times
when
they
are
in,
but.
A
B
B
B
Cool
all
right-
and
I
think
casey
mentioned
that
he
can
find
someone
from
calico
to
attend.
In
case
we
decide
to
proceed
this
week.