►
From YouTube: Network Policy API Bi-Weekly Meeting for 20221010
Description
Network Policy API Bi-Weekly Meeting for 20221010
A
Awesome:
okay
today
is
October
10th.
This
is
a
meeting
of
the
Sig
Network
policy
API
subgroup
to
Sig
Network.
This
is
a
cncf
certified
meeting,
so
let's
be
friendly
and
have
a
good
one
today,
so
not
too
much
on
the
agenda,
but
I
think
one
topic
that
will
spur
quite
a
bit
of
conversation
right
now
on
the
agenda.
I
just
wanted
to
poke
that
the
URL
for
the
ANP
website's
finally
done
so
we're
Incorporated
with
kubernetes
netlify,
thanks
Ricardo
for
all
the
pointers
there
and
there's
still
some
to-do's
on
the
website.
A
A
That's
my
goal
at
least,
and
I'm
also
going
to
add
a
label
in
the
repo
for
website
issues.
So
if
you
see
anything,
feel
free
to
open
up
an
issue
and
we'll
keep
making
it
better
yeah
and
if
any
folks
want
to
grab
new
issues,
those
are
great
ones
for
new
contributors,
so
help
out
with
the
website.
Let's
make
it
better
and
yeah,
that's
I
think
that's
all
I
have
for
admin.
A
Network
policy
implementations
are
ongoing,
I
believe
Yang
hasn't
been
around
for
a
while,
but
he
should
be
implementing
it
for
Atria
and
I'm
working
on
implementing
it
with
oven,
along
with
some
other
folks,
so
should
have
some
updates
on
that
soon.
Any
other
questions
about
AMP.
What's
going
on
there.
A
Oh,
and
we
have
one
exciting
thing:
we
I
got
a
talks
of
accepted
at
kubecon
in
Detroit
for
the
contributors
Summit
around
adminary
policy,
so
we'll
have
like
a
25
minute
session
exclusively
for
that
and
we'll
be
highlighting
it
in
the
Sig
network,
intro
and
deep
dive
as
well.
So
get
some
noise,
hopefully
get
some
more
contributors
and
more
voices,
cool,
okay
and
I.
Believe
now
we're
gonna
start
brainstorming
about
Network
policy
in
the
multi-network
world.
I
guess
Rahul.
Did
you
add
this
one
to
the
agenda.
B
So
I
mean
I
I'm,
hoping
that,
contrary
to
expectations,
this
isn't
too
crazy,
like
just
to
set
the
stage
of
what
I
was
going
for.
I
I
had
the
realization
or
the
suspicion
that
we're
more
likely
to
see
multi-network
implementations
come
out
before
we
get
any
sort
of
consensus
on
what
a
network
policy
V2,
multi-cluster,
multi-network,
inclusive
thing
looks
like
yeah
and
so
I
thought
was
what,
if
we
just
start
small
and
say,
let's
make
sure
that
the
existing
Network
policy
API
isn't
undefined
in
a
multi-network
world.
C
C
Perfect
yeah
and
sort
of
that
was
part
of
me,
I
mean
Andrew,
knows
about
two
years
ago.
I
had
this
I
didn't
think
that
my
because
I
didn't
think
that
kubernetes
networking
was
going
to
work
with
multi-network
and
everything,
and
then
one
one
day
this
year.
Yes,
it
does
so
what's
cool
with
with
natural
policies.
That's
right.
C
This
puts
some
some
sort
of
questions,
rather
a
multi-network,
and
if
you
follow
the
last
debate,
I
mean
that
in
reality,
Ed
and
I
brought
up.
So
what
one
of
the
problems
sort
of
the
worst
case
scenario
that
you
can
get
to
is
that
someone
strings
one
L2
Network,
that
you
have
a
number
of
Parts
connect
to
it
from
one
cluster.
You
have
another
ports
connected
from
another
cluster
and
then
you
have
external
objects
on
it
right.
C
So
so,
if
you
just
use
what
you
have
in
the
network,
Plumbing
group
and
what
you
can
do
with
nut
multiple,
so
you
can
get
string
l2s
right!
You
cannot
build
any
higher
level
Concepts.
So
what
Ed
brought
in
for
the
different
network
service
mesh
is
that
I
decided
to
talk
about
connectivity
order
and
you
can
put
requirements
on
that.
C
Well,
I
want
the
eye
pan
for
these
pods
to
to
be
built.
This
way,
I
mean
I
would
always
say
that
you
want
to
have
the
pods
from
one
node
chair,
sort
of
an
address
scope
and
you
want
to
Cluster
to
share
an
adverscope,
and
that
would
make
the
implementation
sort
of
have
a
much
better
idea
where
address
has
come
from,
because
otherwise,
you
literally
would
have
to
in
every
part
of
the
system,
know
all
the
addresses
of
all
the
parts
which
is
doesn't
scale
very
well.
C
So
so
I
would
say
that
it
rather
puts
requirements
so
much
the
network
policies
or
output
requirements
back
on
multi-networking
sort
of
to
make
it
possible
to
implement
Network
policies
in
a
decent
way,
and-
and
since
it's
the
well
today,
the
cni
that
does
it
right.
So
if,
if
you
would
Implement
if
it
would
go
sort
of
Ed's
way
and
then
the
way
that
networks
are
set
up
is
can
also
be
decided
and
follow
best
practice
by
the
implementation.
That
also
will
do
the
the
filtering.
C
It's
it's
very,
very
possible,
so
so
I
think
it's
it's.
We
should
push
very
very
hard
on
that.
There
is
no
addresses
in
any
specification
except
for
being
receivers.
That's
also
go
to
multi-network
right.
We
don't
want
to
see
Neutron
built
in
kubernetes
as
Ed
described
it.
That
was
part
of
that
stuff
and
it
went
horrible.
A
Well,
I
mean
what
what
I've
seen
in
this
doc
from
Raul
is
more
like,
not
necessarily
where
we're
going
with
whatever
the
multi-network
you
know
solidifies
on
in
the
future.
It's
more
like
can
we
already
say
like
what
we're
going
to
support
for
what
is
already
there,
which
I
think
is
just
Network
attachment
definitions
right?
Is
that
what
you're,
saying
or
right.
B
Like
yeah,
all
I
want
to
clarify
is:
are
there
any
reasonable
restrictions
we
can
place
on?
This?
Is
our
Network
policy
behaves
or
are
we
deciding
that
hey?
If
you
try
to
mix
Network
policy
and
multi-network?
That
is
bad
news
and
it's
never
going
to
be
supported.
Like
I'm
just
saying
shoot,
we
should
have
a
opinion
solely
on
that
of
network
policy
plus
multi-network.
Does
it
work?
What
does
it
do
or
do
we
just
say?
No,
it's
completely
busted.
There's
there's
no
hope
so.
D
C
At
what
sort
of
this
is
not
enough
for
me,
if
you
look
at
Tomo,
has
been
doing
and
also
Doug
with
Montes
study
started
to
do
multi-networking
multi-network
filtering
right
in
multis,
but
he
made
this
assumption
that
there
is
no
routing
between
networks,
so
that
a
pod
can
only
talk
to
another
pod
sort
of
over
a
specific
Network.
So
all
the
addresses
would
always
come
from
the
network.
C
C
Did
the
sort
of
slides
I
think
it's
almost
two
years
ago
now
that's
sort
of
went
through
this
and
that's
basically
how
our
implementation
will
look,
probably
forced
to
do
a
reduction
address
to
work
load
and
how
that
sort
of
works
in
reality.
If
you
want
to
have
overloaded
addresses,
you
would
have
to
know,
address
domain
and
address
linked
support
and
the
Pod
is
done
linked
to
to
the
workflow
right
and
the
filters
works
like
just
fine,
so
so
I
think
we
should
be
very
careful
with
the
changing
the
semantics.
B
A
D
C
B
Can
you
guys
see
my
screen
yeah
or
yeah
okay,
so
this
is
kind
of
what
I
was
playing
around
with
and
basically
the
the
things
that
I
want
to
talk
about
today
is
just
I'm
not
trying
to
talk
about
extending
the
API
right.
We
just
want
to
talk
about
what
is
the
existing
API
do
and
for
now
we're
going
to
Pretend
We're
single
cluster
only
just
to
keep
matters
tractable
we'll
have
to
deal
with
multi-cluster
eventually,
but
I'm
hoping
we
can.
B
A
B
Probably,
but
my
concern
is
from
what
I've
seen
modifying
the
existing
API
is
tricky
and
like
in
whatever
successor
we
have.
We
almost
definitely
want
that
so
I'm,
assuming
that
the
network
policy
API
as
it
stands,
is
pretty
much
Frozen
like
that.
That
that's
where
this
dock
is
coming
from
is
the
assumption
that
it's
impossible
to
make
any
illegal
changes.
So.
C
C
A
Yeah,
no,
no,
no
I,
I
totally
generally
agree
and
rewriting
to
your
whole
point
like
yeah
I.
Think
we've
seen
as
a
group
over
a
year
and
a
half
getting
stuff
in
an
existing
netball
is
pretty
much
impossible.
So
I
tend
to
agree
the
only
wrench
in
the
iron
there
is
like
I
keep
hearing
stirrings
about
once
for
a
V2
Network
policy,
but
haven't
had
anyone
still
own
it.
A
D
I,
can
a
network
interface
actually
follow
the
same
approach
of
the
rest
of
the
things
in
kubernetes
and
have
like
a
label?
So
when
you
attach
multiple
interfaces
or
something
like
that,
you
know
that
actually,
that
Network
contains
a
label
and
you
use
in
the
network
policy
the
label
of
that
Network.
C
D
C
D
B
D
B
Yeah
no
I
mean
it's
a
good
suggestion.
I
was
I
was
thinking
that
the
whole
point
of
the
network,
the
multi-network
change,
is
to
not
make
it
a
tacked
on
feature,
but
rather
a
first
like
native
support,
and
if
we
did
something
like
having
a
you
know
reserved
label
like
kind
of
like
what
we
did
for
the
namespace
name.
If
we
started
doing
that,
that
might
you
know
undermine
the
efforts
of
the
network
policy
of
the
network.
The
multi-network
cap
was
my
thinking.
I,
don't
know.
C
A
C
C
B
Let's
see
and
the
next
one's
a
little
bit
trickier,
I
guess
I,
don't
know
which
way
to
go
on
this.
This
is
about
the
peer
selectors,
so
the
two
and
the
from
one
tack
you
can
take
is
that
you
enforce
some
sort
of
network
sameness.
You
say
if
I'm
I'm
only
accepting
traffic
from
an
endpoint
on
the
same
network,
I'm
not
I'm,
not
allowing
cross-network
traffic.
B
C
I,
don't
think
you
can
the
first
one
will
be
very
hard
because
you
assume,
when
you
say
something
like
that,
you
assume
that
it's
a
single
L2
that
links
to
poles
and
if
you
look
at
I,
mean
if
you
look
at
how
the
primary
network
is
put
together
on
most
systems,
you're
going
to
have
right
an
L2
per
node,
and
then
you
got
a
route
between
those
level
two
and
it
can
be
a
router.
You
don't
really
just
use
one
big
Network
and
you
put
all
your
notes
on.
C
So
if
you
use
the
first
one
for
the
cluster
Network,
you
have
il3
connectivity,
that's
the
base
for
everything
we
have
so
we
need.
We
should
never
think
of
l2s
so
and
if
you're
L3,
then
what
is
the
network?
Then
you
need
to
figure
out
how
to
identify
that,
because
you're
not
going
to
be
able
to
do
it
just
by
looking
at
them
so
which
interface
you
receive
it
on
and
sort
of,
see
that
and
assume
that
the
other
one
is
on
the
same
network.
C
Wait.
Basically
it's
saying
that
there's
going
to
be
topology
on
these
Network
objects.
It's
not
just
simple
vlans
that
are
the
cameras.
The
whole
cluster
I
think
the
first
one
can
be
hard
to
do.
Okay,
you
can
know
the
iPad
and
sort
of
know.
If
you
know
the
ipam
for
for
a
networking,
it
would
be
easy
to
match
back.
There's
nothing.
Really.
That
says
that
the
iPad
for
a
network
or
sort
of
multi-network
is
known
to
kubernetes.
C
B
Because
the
trick
with
the
second
one
is
somehow
you
need
to
pass
identities
like
regardless
of
network
like
if
I,
if
I
see
traffic
I
need
to
be
able
to
resolve
it
to
I'm,
seeing
identity,
but
workload
like
I
need
to
be
able
to
resolve
arbitrary
traffic
to
a
workload
right
somehow.
So
it's
it's
a
similar
problem
in
either
scenario.
A
A
C
We
have
all
these
end
points
right.
So
are
we
saying
that
the
the
way?
Maybe
it's
not
the
right
way,
that
the
way
firewall
I
mean
the
network
policy
should
work
it's
not
by
sort
of
listening
in
on
the
specific
CMI
and
when
it
talks
to,
because
that
could
be
different,
it's
not
to
assume
things
from
implementation,
but
actually
that
has
to
be
communicated
through
some
sort
of
endpoint
object
and
that's
where
the
the
network
policy
should
get
implementation.
C
C
C
C
And
and
also
it
sort
of
has
to
do
with
when
we
discuss
V6
and
the
multi-networks
that
abysses
can
change.
Basically,
at
any
time
when
you
have
a
self
addressing
that,
the
subnet
can
come
up
on
a
Network
by
a
route
advertisement.
If
you
have
a
single
L2,
so
you
can
get
new,
addresses,
added
or
updated
and
on
any
attachments
at
any
point
in
reality,
and
then
we
would
need
Network
listeners
and
those
would
have
to
update
the
endpoint
object.
So
then,
the.
C
A
C
A
C
Yeah,
it's
it's
becoming
part
of.
Actually,
it
was
started
as
a
group
on
the
side
to
come
up
with
something
that
worked
in
the
existing
framework
and
there's
clearly
promise
with
it.
As
Ed
said
we
what
the
pro
what
it
does
is
that
it
can.
You
can
add
l2s
that
you
then
hang
on
pods,
but
that
would
always
be
the
I
would
say
the
most.
C
It's
not
really
the
right
way.
You
want
to
recommend
someone
to
build
a
network
structure,
and
since
we
don't
want
to
have
routers
and
routing
all
that
stuff,
you
cannot
build
a
structure
that
makes
sense
from
equivalent
standpoint
how
you
would
want
to
have
a
network
topology
to
attach
Networks
to
have
the
networks
that
a
post
would
be
attached
to
in
the
sort
of
most
ideal
way.
It's
impossible
to
specify
it
with
the
plumbing
groups
are.
C
C
B
C
A
Yeah
I
think
it's
really
important
I
think
we're
a
little
bit
ahead
of
the
ahead
of
the
you
know
gun
a
little
bit
but
yeah.
No,
it's
it's
not
a
it's,
not
a
bad
thing
like
all
these.
All
these
docs
you've
started
putting
together
a
whole,
both
the
fqdn
and
this
I
think
will
become
very
important
when
you
know
the
community
starts
highlighting
them
more,
which
they
will
right
have.
C
C
B
B
Yeah
I
think
this
is
these
are
the
only
two
behaviors
that
I
think
really
change
in
a
multi-network
world,
IP
block
is
just
sort
of
Ip
block.
It
comes
with
all
the
good
and
the
bad
that
it
has
already
I,
don't
think
anything,
exciting
changes
and
L4
it's.
You
know
it's
more
of
the
same
udptcp
ports
that
all
seems
to
function.
Just
fine.
A
C
A
Well,
with
IP
block
yeah,
it's
when
you're
talking
about
Ingress
with
IP
block,
you
kind
of
everything
goes
to
right
because
I'm
sorry
bad
word,
everything
goes
away
because
you
know
it
depends
on
the
Ingress
mechanism.
Egress
is
a
little
bit
easier,
but,
oh
anyway,
we
digress
I,
think
from
the
original
Talk
conversation
so
I'm,
starting
to
think
we
need
a
place
to
put
these
working
documents.
Rule
yeah
because
I
don't
want
them
to
just
get
lost
in
the
weeds
and
I
know
we
have
what
we
have
three.
A
We
have
one
on
ftdn.
We
have
one
on
network
policy
V2
that
folks
started
a
long
time
ago.
I'm
sure
is
out
of
date
and
then
now
another
one.
What
do
you
think
is
the
best
way
to
cement
these?
Is
it
to
add
a
readme
in
the
network
policy,
API
repo
with
links,
or
is
it
just
to
put
them
in
the
agenda
somewhere
Central
like?
What
do
you
think
is
easiest
I'm.
B
A
A
I
had
a
customer
meeting
last
week
with
and
fqdn
came
up
like
as
as
a
desire
and
so
I
I've.
It's
been
on
my
list
to
take
those
questions
you
put
in
a
Google
doc
for
us
and
make
them
into
a
form.
You
didn't
do
that
by
chance.
Have
you
I,
I
haven't
yeah,
it's
I
just
wondered
if
you
had
done
it
before
I
tried.
A
That'd
be
awesome
if
you
sent
it
to
me,
I
can
definitely
try
to
push
it
to
the
customers.
I've
been
meeting
with
at
red
hat,
but
like
it's
hilarious
in
the
sense
that
we've
talked
a
lot
about
it
and
from
a
customer's
perspective,
it's
every
customer.
I've
talked
to
it's
so
black
and
white.
It's
like
I
literally
just
want
to
be
able
to
stop
traffic
going
to
this
DNS
name.
C
Is
this
a
sort
of
a
clash
between
I'm,
an
L3
guy
from
the
sort
of
routing
Mac
address
from
the
beginning,
but
I
mean
if
you
look
at
kubernetes,
you
never
talk
about
addresses
and
that's
how
we
specify
all
the
objects
right
and
then
you
you
bind
in
reality
everything
to
DNS
and
that
when
something
gets
created
it
gets
an
address
and
it
gets
the
name
of
the
name.
You
can
sort
of
understand
from
from
what
the
input
limit.
C
A
Oh
yeah,
I
I,
don't
know,
I
just
know
that
people
want
it
and
you
know,
then
it
always
comes
back
to
how
to
how
do
we
get
it
in
I'm
I'm,
almost
thinking
that
what
would
be
cool
if
someone
had
like
a
little
bit
of
time
is
if
we
had
like
an
API
playground
in
the
network
policy,
API
repo,
where,
like
you,
could
go
in
and
like
we
could
just
play
with
physical
API
specs.
So
you
could
make
like
a
really
quick
fqdn
policy
crd
and
try
to
do
an
implementation
for
it.
C
Combined
with
that
put
up
the
because
there's
going
to
be
some
quality
implementation
choices,
and
we
also
know
technology
changes
right,
I
mean
everything
is
getting
encrypted.
So
okay
address
is
still
there,
but
also
when,
when
the
when
the
the
DNS
queries
becomes
encrypted
sort
of,
then
then
it's
going
to
be
really
hard
to
break
in
so
I
mean
make
the
assumptions
that
makes
it
possible
to
implement
it
right.
I'm.
B
C
You
can
come
up
with
different
scenarios
right
did
you
say?
Yes,
it's
possible
to
have
a
dynamic
listener,
then
this
is
how
you
can
build
it,
but
this
is
how
it
would
work.
Yeah
like
I,
say:
no,
there
is
no
Dynamic
listener.
Then
you
will
have
something
else
right.
That
would
have
to
constantly
look
all
up
to
all
these
addresses.
But
since
you
don't
know
what
to
have
the
DNS
server
that
someone
goes
to,
is
you
can
you
will
only
sort
of
get
a
pretty
good
estimate
that
you
covered
at
the
address
yeah.
C
D
B
E
A
A
E
We
we
are,
we
are
sort
of
like
identified
the
work
items
that
needed
to
be
done
in
the
in
a
in
a
project.
So
yeah
I
guess
that's
some
progress
but
yeah.
So
we
already
have
someone
who's
on
the
same
team.
She
is
actually
you
know
starting
to
do
some
implementation
of
the
functionalities,
such
as
you
know,
the
same
labels,
not
same
label
sing.
So
the
plan
is
sort
of
like
to
have
these
functionality
work
in
ancient
Native
policy.
D
E
Nothing
nothing
much
I
I
do
also
have
a
I
I,
don't
think,
there's
any
update
on
there
yet,
because
I
opened
a
PR
against
my
own
repo,
for
you
know
amending
the
original
cap.
So
if
you
you
don't
have
any
sort
of
like
major
comments,
maybe
it's
probably
easier
for
me
to
actually
open
the
cap
against
the
kubernetes.
You
know
you
know
enhancement
repo
and
then
you.
B
D
A
Good,
it's
good
book.
It'll
keep
Tim
happy.
If
we
keep
that
cap
updated
so
good,
bookkeeping,
cool,
yeah,
I,
don't
think
I
really
have
anything
else
to
add
for
today.
If
folks,
again,
that
are
watching
want
to
get
involved,
I
need
help
with
the
website.
I
did
the
beginnings,
but
I
don't
want
to
do
the
rest
of
it.
I
want
folks
to
kind
of
take.
These
are
good
places
to
get
involved.
Good
first
issues,
so
we
have
issues.