►
From YouTube: [SIG Network] Network Policy API Meeting 2020-11-23
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
So
this
is
sig
network
network
policy.
Super
project
meeting
today
is
november
23
2020..
A
This
is
a
an
official,
an
official
community
meeting.
So
please
be
nice
with
each
other.
We
have
the
code
of
conduct
running
here
and
let's
get
it
started.
So,
first
of
all
we
have
some
new
folks
here.
Do
you
want
to
present
yourself
vomsi
and
vinai
rich?
I
think
you
are
new
also.
I
know
I
know
you,
but
are
you
new
in
this
meeting.
B
Yeah,
I
can
introduce
myself
ricardo.
My
name
is
vinay
vinebenai,
I'm
with
google
and
I'm
I'm
a
technical
lead
manager
for
some
other
aspects
of
kubernetes
and
one
of
my
team
members
was
involved,
bang
was
involved
and
she
is
more
to
do
other
things.
So
I'm
substituting
in
her
place.
B
A
B
B
Yep
I
can
go
next.
My
name
is
wamsi.
I
am
part
of
azure
container
networking
interface.
I
recently
joined
this
team
and
started
to
learn
so
I'm
here
to
learn
more
yeah
and
I'm
I'm
also
working
on
azure
network
policy
manager.
A
A
C
Sure
yeah,
my
name
is
rich
renner.
I
work
at
sunder
networks
and
I've
been
hanging
around
with
these
guys
on
a
couple
of
different
areas,
which
is
how
I
ended
up
in
this
meeting.
Thanks
for
having
me
ricardo.
A
Great
okay
welcome
folks
so
before
starting
to
pass
through
the
the
ftd
and
policy
doc
and
the
cap
reviews-
and
I
hope
this
is
going
to
be
a
a
soft
meeting.
We've
had
a
meet
with
tim
hawking
last
friday
me
jay,
andrew
abhishek
and
tim.
I
I
don't
think
we
forgot
anyone,
because
I
asked
him
some
some
directions,
so
we
could
move
forward
with
the
namespace
by
name
selector,
because
we
have
some
some
problems
between
the.
If
we
were
going
to
change
the
namespace
selector
or
how.
A
How
could
we
move
that
forward
and
team
suggested
that
that
suggested
us
that
we
move
with
the
api
name
space
labels?
That's
that's
a
cat
that
suggests
that
any
new
namespace
got
subverted
label
or
reserved
label.
That's
a
kubernetes
dot,
io,
slash
metadata
dot
name.
So
the
cat
is
here.
I'm
gonna
share
my.
B
A
One
more
cat
for
you
yeah,
so
this
is
the
cat
that
tim
and
jay
started
writing
on
friday
and
I've
put
some
some
other
stuff.
I've
just
made
some
some
small
corrections
on
on
sunday
and
the
idea
of
this
cat
is
basically
that
we
propose
that
namespace
have
an
immutable
label
when
created
created
by
the
api
server.
That
represents
the
mega
data
dot
name
of
the
object
and
turns
name
space
selectable
by
the
name.
A
D
Please
be
clear,
as
the
whole
point
here
is
that
every
namespace
from
now
on,
we'll
have
a
label
on
it.
So
for
those
of
you
that
don't
understand
the
overall
problem
that
are
new,
people
have
been
complaining
since
for
a
very
long
time
that
they
want
to
just
write
a
network
policy
against
a
namespace
without
having
to
know
what
the
labels
are
and
nobody's
been
able
to
do
that.
So
we
wrote
this
big
cap
about
how
we
could
change
the
api
so
that
cni
providers
have
some.
So
you
could
write
a
network
policy
gamble.
D
That
said,
like
namespace,
as
name
problem
with
that,
once
we
started
going
down
the
logic
of
it
was
that
tim
was
a
little
concerned
that
older
policies
would
be
by
default
less
secure
than
what
users
wanted,
because
of
the
the
way
that
the
top
level
primitives
are
logically
combined.
So
the
simplest
solution
to
this
is
like:
why
don't
we
just
label
every
namespace
forever,
so
that
every
namespace
is
guaranteed
to
have
one
label?
D
That's
predictable,
so
that
anybody
that
wants
the
right
policy
against
the
namespace
can
very
easily
do
so,
even
if
they
have
no
idea
what
labels
are
in
the
namespace,
because
they
know
that
every
single
namespace
has
a
default.
Chaot,
k8,
dot,
io,
slash
my
namespace
name
and
then
the
name
name
of
the
namespace
right.
D
A
F
F
But
then
you
can
do
multiple
namespace
selection
with
match
expressions
right,
like
you
can
say,
kubernetes,
dio,
metadata
name
and
then,
like
that's
the
key
and
then
operator
in
values
like
a
list
of
namespaces.
So
this
also
accounts
for
a
selection
of
namespaces
by
name
without
having
to
use
like
like,
without
having
to
use
labels
like
by
just
collecting
its
names
right.
A
F
Yeah,
I
guess
yeah,
I
guess
what
I
was
saying
was
like
one
of
the
one
of
the
requirements
that
we
were
talking
about
is
like.
I
don't
just
want
to
select
one
namespace.
I
want
to
be
able
to
select
like
a
group
of
namespaces
that
have
well-known
names,
but
they
may
not
have
labels,
so
it
does
sound
like
this
can
be
done
with
match.
F
D
Yeah
you're
right:
I
think
we
can
deprecate
that
other
cap
or
withdraw
it
ricardo.
Let's
wait
for
this
to
get
approved,
but
yeah.
Absolutely.
D
A
Unless
you
want
to
write
that
write,
a
cap
just
update
the
docs,
but
I
don't
think
this
is
like.
No,
I
don't
want
anymore.
I
know
you,
you
love
capturing,
I'm
going
to
get
owner
of
everything,
oh
man,
so
let's
move
forward.
Okay.
So
the
next
next
item
here
is
the
is
to
continue
about
the
ftd
and
policy
dog
with
gobind.
B
A
If
he
arrives
later,
we
can
ask
him
so:
okay,
next
one
we
have
left
cluster
scoped
because
I've
said
told
us
that
that
probably
today
he
was
going
to
present
the
template
policies.
B
G
Yeah
last
week
I
think
week
I
mentioned
that
we
were
working
on
the
user
stories
and
we
documented
all
of
them,
and
this
past
week
we
had
a
follow-up
on
that
and
we
we
have
a
proposal
and
based
on
that,
we
wrote
some
templates
example
policies
which
satisfy
those
use
cases
and
the
team.
You
know
we
all
was
a
part
of
that.
G
We
all
went
through
the
the
existing
user
stories
and
the
proposed
example
templates
for
for
each
of
those
user
stories
which
satisfy
those
requirements,
and
I
think
we
all
we
got
only
halfway
through
the
through
all
the
user
stories
and
because
of
all
the
discussion
that
went
wrong.
G
So
I
think
after
the
thanksgiving
break,
we
will
fully
complete
all
the
proposals,
or
rather
we
will
go
through
all
the
proposed
templates
and
examples
for
the
use
cases,
and
once
we
have
satisfied
all
the
use
cases,
I
think
we'll
have
an
art
in
proposal
and
based
on
the
discussions
last
week,
we
kind
of
tweaked
a
little
bit
on
on
the
on
the
semantics
on
the
select
selectors
in.
G
The
use
cases,
so
I
think
I've
already
shared
the
google
document
with
the
team.
Maybe
we
can
pin
that
in
this
document
somewhere
so
that
if
anyone
wants
to
take
a
look
at
the
proposal
and
the
sample
examples,
can
you
know
take
a
look
at
that
document,
but
yeah?
That's
the
that's
the
status
so
far.
G
Hopefully
I
I
think
you
know,
based
on
the
timelines
this
week,
we're
going
to
cancel
the
meaning.
So
it's
going
to
be
next
week
in
the
first
week
of
december,
when
we
finish
up
all
the
proposals,
or
rather
the
examples
and-
and
then
I
think,
maybe
midweek
of
december
is
when
we
come
here
with
a
proposal
or
some
sort
of
a
sketch
which
we
can
discuss
on
the
broader
team
meeting.
A
A
So
no
goal
india,
no
yeah,
so
about
the
cap
review,
so
we
got
abhishek's
one.
The
port
range
I
think
that's
moving.
I've
I
have
I've,
got
some
feedback
from
team
and
also
from
sean
from
from
helico
taguera
team
about
dropping
the
exception
and
team
also
proposed
that,
instead
of
creating
a
new
part
range
stripped
only
inserting
an
import
integer
field
inside
the
network
body
support
structure,
so
the
cni's
could
could
see.
If
you
have
a
an
import,
then
you
could
consider
that
as
a
range
instead
of
a
single
port,
I
have
updated.
A
Let
me
here,
I
have
updated
the
cat
to
reflect
teams
and
and
and
sean
suggestions.
Also,
then,
when
she
in
a
best
comment,
told
that
exceptions
might
be
an
overkill,
also
sean.
So
let's
take
a
look
folks,
I
did
some
updates.
I
think,
was
yesterday
the
the
old
commit
is
here.
I
am
not
squashing
anything,
so
you
can
take
a
look
into
what
I
have
changed
before
squashing
stuff
and
see.
If
this
is
enough
for
you,
I
think
that's
a
that's
a
simple
proposal,
but
yeah,
that's
a.
A
I
think
that
solves
also
the
problem
like
having
the
the
new
field,
the
new
import
field,
and
just
that
and
like
not
having
exceptions,
I
think
that's
that
might
be
problematic
for
a
future.
If
you,
we
will
not
add
exceptions
and
the
cni's
doesn't
know
about
the
exceptions,
but
on
the
other
hand,
I
don't-
I
don't
know
if,
like
we
have
a
strong
user
case,
that
exceptions
would
make
the
their
part
here.
So,
let's
take
a
look.
F
I
think
the
whole
thing,
with
the
exceptions,
kind
of
goes
back
to
like
the
user
stories
and
requirements.
Do
you
do
we
remember
like
back
when
we
were
kind
of
chatting
about
this
were
some
of
the
requirements
that
folks
mentioned
were
like
asking
for,
like
many
exceptions
within
a
large
port
range,
or
is
it
usually
just
like
one
port,
because
I
think
if
it's
just
one
port,
then
I
agree
like
the
exception's
overkill.
D
That
was
like
what
I
was
kind
of
thinking
of,
but
then
cody
brought
up
another
user
story
around
vms.
Right,
like
you,
want
to
run
a
vm
as
a
pod
and
to
me
the
vm
as
a
pod
is
also
a
no.
I
don't
think
that's
an
exceptional
either
like
I
think
they're.
Both
the
the
big
thing
is
the
range
and
the
exception
is
not
really.
D
D
F
A
I
think
that
we,
we
would
not
have
like
just
single
parts
like
the
natural,
the
security
policy
of
my
company.
It's
it's
blocked
like
the
part
map
and
the
samba
parts,
so
you
can
allow
any
traffic
to
any
parts,
but
zumba
parts
and
and
and
port
maps
and
nfs
parts.
But
I
think
that's
few.
If
you
have
like
a
small
number
of
exceptions,
it's
it's
viable
to
do
with
the
with
multiple
part
ranges,
instead
of
like
creating
exceptions
and
having
problems
with
the
cni
providers
right.
F
A
I
think
that
I
have
two
scenarios.
The
first
one
is
that
I
would
be
more
secure
because,
instead
of
of
allowing
the
traffic
for
any
any
any
place
and
blocking
these
on
my
edge
firewall
or
like
or
like
asking
for
the
security
focus
on
a
security
exception,
I
would
or
like
having
a
a
six
sixty
five
thousand
parts
described
and,
and
only
that,
the
the
ones
that
I
don't
want
remove
it.
I
would
have
like
a
bunch
of
part
ranges.
A
I
still
think,
in
my
opinion,
that
that
the
network
policy,
the
way
that
it
was
made
it's
difficult
for
the
end
user
to
read
even
with
if
we
have
or
not
like
the
the
exceptions
field,
but
in
my
opinion,
I
think
that
if
we
wanna,
we
wanna
evolve
this
better
than
just
putting
an
exception.
I
think
that
this
way
we
we
we
would
need
like
a
v2
network
policy
nowadays
is
still
hard
to
to
read
the
network
policy.
So.
F
Yeah,
I
don't.
I
don't
disagree
with
that.
I'm
just
I'm
just
trying
to
figure
out
like
what
are
the
use
cases
behind
exceptions
and
like
on
average.
How
many
exceptions
are
we
are
we
thinking
right
because
like
to
me,
if,
like
the
the
usual
exception,
is
like
one
or
two
or
three
ports
then
like
that
totally
seems
fine.
F
A
C
Yeah,
I
was
just
gonna
add
I
think,
that's
a
good
heuristic.
By
the
way
I
was
looking
at
some
firewall
rules
here
on
the
other
screen
and
and
the
quantity.
C
I
guess
it
just
the
idea
of
having
these
exceptions,
I
think,
is
attractive
and
certainly
folks
are
happy
to
talk
about
it,
but
I
just
haven't
seen
a
case
where
folks
have
had
more
than
10
specifics
in
any
one
independent
flow.
Now,
if
you
took
like
all
the
firewall
rules
that
I
took
some
from
like
a
consulting
engagement,
then
I
would
have
a
list
that
is
significant
enough.
I
guess
my
only
comment
was
that
I,
like
your
new
rule
of
thumb,
I
think.
C
A
steering
yeah
because
certainly
10
is
a
good
number,
do
not
have
to
make
11.
because
we
keep
coming
back
to
it.
So
I
guess
I'm
plus
one
on
this
pseudo
heuristic
as
we
go
forward.
It's
valid.
F
Yeah,
I
was
actually
going
to
say
that
10
is
where
I
think
it's
too
much,
but
yeah
I
mean
if
we're
saying
like
10
is
the
most
and
anything
above
10
becomes
too
much,
but
anything
below
10
is
like
reasonable
and
a
user
can
grop.
That
then
yeah
like,
I
think,
that's
a
decent
turning
point.
So.
C
A
A
I
think
that's.
Does
anybody
want
to
take
a
look
into
that
and
discuss
about
that
or
that's
a
a
no-go
for
now?
What
do
you
think
about
that?
Anybody
took
a.
G
Look
into
that,
so
I
took
a
look
at
that
kept
last
week
on,
but
I
did
not
look
into
you
know
very
specifics
of
each
of
the
cases
that
he's
trying
to
address
or
on
a
high
level.
I
quite
agree
with
the
status
part
of
the
cap,
but
I'm
not
quite
sure
about
the
versioning
part
that,
whether
it's
that
useful,
I
was
a
little
confused,
also
as
to
how
he
wants
to
version.
Is
it?
G
Is
it
the
user
who's
going
to
be
adding
versions
to
the
or
the
main
version
field
to
their
policies,
or
is
it
the
cni
plugins
who
are
going
to
be
updating
some
sort
of
a
min
version
that
they
support?
And
if
it's
on
the
user
side,
I
don't
know
whether
it's
a
great
user
experience
to
be
adding
versions
to
their
policies,
in
addition
to
all
the
things
that
they
have
to
add
into
their
policies.
G
A
Think
that
about
the
versioning,
what
the
original
proposal
of
them
was
that
when
you
use
specific
fields
from
specific
network
policy,
the
api
mutated,
the
the
object
to
insert
the
mean
version,
so
the
cni
would
know
also
about
if
the
mean
version
from
the
cni
was
the
same
of
the
mean
version
from
the
from
the
api
from
the
api
object.
But
I
think
that
I
think
that
about
this
was
a
no-go
from
from
team
and
and
other
folks,
because
they
don't
want
to
mutate
the
the
object.
A
G
Yeah,
the
other
thing
was
that
you
know,
let's
say
the
cni
provider
supports
certain
advanced
features,
but
does
not
support
http,
which
was
like
an
older
version.
G
So
now,
if
the,
if
the
policy
is
created
with
the
main
version,
which
is
advanced
and
also
has
a
sctp
protocol
in
there
now,
it's
kind
of
like
a
you
know
from
a
cni's
perspective,
it
sees
that
okay,
I
do
support
this
advanced
feature.
G
Then
I'm
going
to
support
this
policy
because
the
main
version
matches
with
its
one-man
version,
but
it
does
not
support
an
older
feature
which
is
the
http
protocol
and
now
so
it's
kind
of
partially
supporting
this
policy,
which
would
then
reflect
a
partial
status,
and
I
think
dan
does
capture
this
kind
of
a
scenario,
but
it's
still
a
bit.
You
know
it's
not
really
entirely
solving
the
problem.
G
I
think
the
problem
can
be
solved
just
by
putting
a
status
where,
in
the
cni
provider
inputs,
you
know
or
reports,
a
good
enough
clear
error
message
saying
that
why
this
policy
was
not
realized
without
the
need
for
main
versions.
F
Yeah,
like
on
the
whole
user
side
of
things
like,
I
think
the
intention
was
that
the
api
server
adds
the
min
version
and
the
client
or,
like
the
cni,
is
expected
to
read
it
and
like
yeah
like
implement
it
based
on
the
main
version.
But
the
problem
is
that,
with
that
we
run
into
the
same
problem.
We
would
run
with
other
api
fields,
form
inversion.
G
A
A
Okay,
so,
let's
hope
at
least
the
status
part
gets
cheated
and
we
can
provide
the
users
feedback
about
the
network
policies.
Yes,
so
the
last.
The
last
item
here
in
the
agenda
is
about
this
services
selector.
I
think
that
we
have
voted
into
the
this
services.
A
A
So
if
someone
wants
to
to
get
this
cap
and
start
writing
a
document
like
we've
made
to
other
to
the
other
proposals
and
also
the
the
document
that,
like
the
same
f
as
gobind
made
to
ftdn
policy,
it
would
be
great,
so
please
take
a
look
and
and
reach
us.
The
idea
of
this
is
like
having
a
services
selector
for
the
egress
policy,
so
you
can
select
a
search
instead
of
selecting
a
a
pod
or
a
namespace
and
and
having
the
the
rooms
created.
A
D
D
We
really
would
love
for
someone
to
take
that
services
cap,
I'm
I'm
maxed
out
for
sure.
I
think
ricardo
is
too
so
for
me,
I
I
think
I
probably
will
not
be
taking
any
more
network
policy
caps
on
for
for,
for
the
time
being,
I'm
doing
some
other
stuff
in
the
in
the
windows
space
right
now.
So
I'm
gonna
keep
babysitting
all
my
stuff,
but
I
can't
take
anything
else
on
ricardo's
saturated,
so
we
really
need
someone
to
potentially
own
that
services.
Cap
abhishek.
You
might
know
some
folks
right,
but.
E
But
if
anyone's
interested
from
my
team,
who
wants
to
take
this
forward,.
D
Yeah
cool
I
mean
it
would
be
cool
if
it
wasn't
another
vmware
person
but
like
if
nobody
else,
I
think
at
vmware.
We
definitely
have
potentially
people
who
might
want
to
take
one
of
these
on.
But
if
anyone
else
I
know
there's
a
lot
of
people
from
different
companies
here,
so
sleep
on
it.
Let
us
know
next
week,
if
you
feel
like
you,
want
to
get
and
and
we'll
help
you
right,
because
we've
kind
of
been
through
this
and
we've
asked
a
lot
of
dumb
questions,
or
at
least
I
have.
D
I
know
and
learned
a
lot
so
we'll
totally
help
anybody
who
wants
to
do
this
for
sure
right,
and
so
you
won't.
You
won't
be
going
out
alone
and
it's
totally
something
a
beginner
can
do.
You'll
have
the
whole
group
here
to
support
you
work
on
it
with
you.
Whatever
you
want.