►
From YouTube: Antrea Community Meeting, 02/28/2022
Description
Antrea Community Meeting, February 28th 2022
A
Thanks
for
joining
this
instance,
industrial
community
meeting
today
is
tuesday
march
the
1st,
or,
if
you
are
in
the
united
states
or
on
the
west,
on
let's
say
on
the
west
side
of
the
atlantic,
it
will
still
be
february
the
28th.
A
So
thanks
for
joining
this
meeting
for
today,
we
have
two
topics
in
the
agenda.
Initially,
we
communicated
three,
but
we
actually
have
a
slightly
shorter
agenda.
So
first
we
have
this.
We
have
seen
some
follow-up
questions
from
the
last
meeting
and
these
questions,
as
you
remember,
are
around
the
multicast
network
policy
enforcement
and
I
think
that
bean
and
roachen
are
here
to
provide
an
answer
to
these
questions
and
then
vinci
is
going
to
present
a
design
for
the
node
selector
for
entry
and
network
policies.
A
This
is
a
feature
that
will
apply
to
both
network
policies
and
cluster
network
policies.
So
without
I
think
I
don't
have
to
talk
anymore,
I
can
just
let
everyone
else
in
the
meeting
talk.
So
maybe
we
can
start
resuming
the
conversation
on
multicast
network
policy
enforcement,
so
I
will
lend
it
over
to
bean
and
roachen
for
that.
B
B
This
variable
and
extend
to
values
for
hmp
and
multicast
agmp
is
for
smp
protocol
and
multicast
is
for
multicast
traffic.
In
fact,
it's
not
a
real
protocol,
but
there
is
a
difference
between
the
igmp
and
the
normal
multicast
traffic
and
the
second
for
the
app
address
I
found
there
is.
There
is
a
from
in
ingress
and
the
two-year
egress
and
so
far
we
do
not
have
the
request
for
multicast
ingress.
So
for
multicast
egress
we
can
use
the
epi
block
in
two
to
indicates
the
multicast
address.
B
Yeah
since
matagas
is
based
on
udp,
but
so
it's
different
from
ignp.
I
want
to
distinguish
better
the
rules
for
ignp
or
for
normal
multicast
traffic.
B
C
C
Actually,
I
did
go
to
a
slide.
Maybe
you
can
also
talk
more
flat,
but
I
at
least
I
face
looks
strange
to
to
put
igmp
under
ports,
so
I
was
thinking
I
should
add
a
new
new
field.
B
C
Eve
said
he
doesn't
want
his
name
services
yeah,
but
maybe
you
can
say
about
some
other
name.
I
don't
know
okay.
He
I
think
his
point
is
like
a
service
he's
determined
radius.
D
E
No
there's
no
services,
I
I
think
tim
hawkins
also
also
wasn't
liking
the
idea
of
services
when
we
proposed
it
for
admin
network
policies.
D
So
how
how
do
we
plan
to
support
something
like
smp
being
upstream
or
it
will
never
support
it?.
E
We
actually
haven't
get
this
discussion
about
icmp
upstream,
I
feel
like
I,
I
don't
recall
there
are
any
requesting
in
upstream
for
for
icmp
or
igmp
for
that
matter.
So
I
I
do
feel
like.
This
is
a
conversation
we
haven't
had
before.
E
But
but
to
to
the
point
of
whether
we
can
reuse
the
ports,
forgive
my
ignorance,
but
does
it
not
make
sense
to
provide
a
port
number
for
igmp?
Is
that
just
not
the
thing.
C
C
E
Right
right
right,
I
understand
that
part.
There
there's
like,
I
feel
like
there's
two
I
wouldn't
say
issue,
but
things
to
look
for
for
for
that.
First,
first
of
all,
if
we
actually
rename
the
ports,
we
know
we're
looking
at
a
backward
compatibility
issue
right
and
and
second
you
know,
it
is
usually
not
a
good
idea
to
just
leave
it
to
some
sort
of,
like
admin.
Sorry
admission
controller
to
validate
that.
E
If
it's
igmp
protocol
then
don't
allow
to
don't
allow
people
to
report
underneath
the
protocol,
and
otherwise
you
allow
that
I
I
do
feel
like.
If
you
know
igmp
or
icmp,
are
grassland
different
than
ptcp
or
udp,
then
we
might
be
better
off.
You
know
putting
up
some
other
fields,
just
like
you
just
suggested
in
the
latest
email
thread.
That's
that
that's
just
my
opinion.
E
C
D
So
there
are
still
two
choice:
two
choices
right,
one
is
groove
protocols
together,
but
how
different
fields
for
different
protocols,
for
example,
tcp
udp
port-
will
be
used
for
smp,
I'm
not
sure
which
field
it
needs,
but
for
snp
I
think
maybe
something
like
code
will
be
used
in
the
same
struct,
but
they
are
the
other
than
the
protocol.
Other
fields
are
optional
right
and
another
way
is
maybe
keep
tcp
udp
sdp
as
sap
as
they
are,
and
having
another
some
something
similar
to
ports,
to
specify
itemp
or
smp
specific
attributes.
D
E
Yes,
but
just
as
a
reminder
that
if
we
decided
to
go
with
the
former,
we
probably
needed
this
back
bump
because
right
now
we're
using
the
upstream
ports
section
to
as
the
as
the
ports
for
acmp
and
there's
no
additional
structure
supporting
that.
So
we
needed
to
create
our
own
ports,
quote
unquote,
section
and
and
uses
backbone
to
update
this.
C
C
Orange
I
was
thinking-
maybe
we
can
add
a
new
new
new
field
here
that
one
I
was
thinking.
You
can
also
specify
tcp
or
udp
there,
but
we
still
keep
the
pause,
but
I
know
that
then
you
have
two
way
to
define
the
same
thing
now.
So
I
I
don't
have
a
very
good
idea:
user
yeah,
I
was
thinking-
maybe
still
good,
to
take
the
course
since
the
qrs
user
are
more
familiar
with.
A
Seems
not,
can
I
just
ask
you
what
is
the
consensus
of
this
conversation?
Then
it
seems
that
we
have
not
yet
made
a
call
on
what
should
be
the
way
forward
right.
C
I
said
at
least
we
conclude
for
multicast.
We
don't
need
a
new
flag
or
type.
We
just
use
ip
block
to
distinguish
multicast
ip
address
and
the
for
ignpi
snps.
We
should
consider
that
I
guess.
A
That
makes
sense,
I
agree
and
are
we?
I
guess
we
are
all
in
agreement
on
this
and
unless
someone
has
any
other
comment,
I
would
like
to
move
to.
I
think
now,
next
topic,
I
think
there
are
also
some
are
watching.
Do
you
have
anything
else
to
add
for
multicast
enforcement.
A
Yeah,
so
if
there
are
no
other
questions
regarding
the
api
design,
we
can
move
to
the
next
topic
about
network
policy
enforcement,
multicast
network
enforcement-
let's
just
wait
a
few
seconds.
F
Yeah,
I
will
show
the
updates
for
the
multicast
policies
test,
design.
F
Yeah
there's
some
questions,
but
I
always
showed
basically
how
api
looks
like
first
so-
and
this
is
a
very
simple
demo
live
demo.
So
we
have.
I
would
like
to
introduce
cuddle
command
called
the
multicast.
F
F
Please
check
the
you
know,
extract
the
format
here
and
also
there's
a
in
the
cartel
commander
running
for
the
entry
engine.
F
So
so
this
command
shows
the
number
of
multicast
packets
that
has
sent
or
received
for
each
part
each
part
in
the
node
and
so
for
the
previous
discussion
and,
I
suggest
add
another
kubocado
command
called
part,
multicast
stats
that
that
will
show
the
number
of
number
of
multicast
packets
sent
or
received,
and
the
number
of
igmp
packets
a
lot
of
our
job
and.
F
There's
a
suggestion
that
whether
these
numbers
could
fit
into
our
already
defined
network
policy
stats
api.
F
Well,
I
would
say
this
is
a
good
idea
to
do
that,
because
thematically
neuropolitic
stats
commands
can
represent
these
numbers,
so
I
will
give
you
a
simple
example
for
that.
F
Network
policies,
entry
network
policies
that
come
on
here
you
can
see
that
this
camera
will
show
pre
network
policies,
stat
stats
and
if
we
add
iphone
or
json
there's
a
you
can
get
even
more.
You
can
see
the
rule
stats
here.
F
F
And
it
has
an
ingress
rule
named
jobs
not
receive
multicast,
and
after
applying
this
cluster
network
policy,
the
users
could
check
the
stats
from
get
entry.
Cluster
network
policy
stats.
F
There
is
never
policy
with
multicast
rule
I
already
applied
and
find
the
rule
name
with
job
receive
multi
multicast.
So
so
we
we
can
thematically
we
can
get
all
the
all
these
full
requirements
from
the
already
defined
the
already
defined
network
policy
stats
api.
So
we
don't
need
to
add
another
one
here
and.
F
A
F
So
in
the
previous
presentation
I
introduced
two
two
avocado
public
api
one
is
one
is:
where
is
what
tca
support
multicast
group
on
members
that
shows
this
mapping
and
another
one
is
paul
automatically
stats
that
shows
the
stats
for
each
part,
but
so
I
I
think
this
one
is
not
necessary
because
we
can
represent
this
using
already
already
created
network
policy,
stats
and.
A
D
Okay,
so
we
still
have
two
commands
and
apis
for
multicast.
One
is
a
group
member
query
right.
Another
one
is
the
per
port
traffic
stats,
but
it's
it's
it's
only
available
in
agent,
not
from
the
aggregated
api
and
cube
cutter.
D
F
The
aggregation
is
necessary
because,
just
maybe
we
have
maybe
different
parts
in
different
nodes
that
have
joined
the
same
multicast
group,
so
the
aggregate
view
looks
more.
You
know
reasonable
to
me.
D
D
Parts,
if
we
don't
have,
we
only
have
a
single
kind
of
members
parts.
Then
maybe
we
could
remove
members.
If
we
have
multiple
kinds,
then
maybe
remove
ports.
I
think
we
only
have
parts
right.
We
don't
have.
If
we
don't
record,
we
don't
have
how
external
clients
information
in
this
api
right
yeah.
We
we
don't.
F
Plan
to
yeah,
we
don't
need
to
show
the
install
and
then
it
doesn't
looks
if
we
don't
need
to
implement
this.
For
now,
at
least
so
I
think
the
members
here
are
only
refer
to
pots
and
I
think
your
suggestion
is.
F
A
All
right,
so,
I
would
like
to
thank
rochen
and
bean
for
continuing
their
discussion
of
multicast
network
policy
enforcement
and
it's
time
to
move
to
the
next
topic.
The
second
topic
on
our
agenda,
as
anticipated
early
norm
earlier
on,
will
be
eventually
providing
an
overview
of
the
design
for
node
selectors
in
anthria
network
policies.
D
H
The
nodesnet
in
network
policy
of
anchor
small
future
is
different
from
the
host
of
our
hot
hot
naval
network
policy.
It
cut
and
a
structure
an
increase
from
section
or
or
equals
to
section.
Node
selectors
like
the
particular
nodes
in
the
cluster,
the
the
the
snarty
knows
eyepiece
will
be
set
as
associacy
for
no
selector
certain
in
english
section
or
as
destination
civil
setting.
H
We
can
see
the
the
another
policy
yeah
that
in
the
in
the
equally
section,
the
two,
the
in
the
two
sections.
There
is
no
snack
which
will
will
will
select
the
control
panels
and
you
will.
H
The
world
only
applies
to
the
to
the
node
ip.
D
If
it
currently
only
includes
node
ips
for
ingress
case,
most
of
the
scenario
will
not
be
covered,
because
if
I
want
to
isolate
that
the
control
plane
for
specifics,
I
don't
want
to
specific
nodes
to
access
some
ports.
I
use
node
selector
to
select
them,
but
the
nodes.
When
the
nodes
want
to
talk
to
these
ports,
they
will
use
other
eyepiece
and
they
will
not
be
dropped.
H
I
I
think
it's
it's
good.
In
other
c
c
eyes
such
as
cinema
and
conical,
they
both
has.
H
To
define
the
interface
of
the
hosting
cluster
in
such
cases,
I
think
the
knowledge
that
needs
to
need
to
add
an
interface
controller
to.
H
H
D
We
also
make
agent
report
the
gateway
ip
as
an
annotation,
then
in
their
policy
controller
it
could
extract
it
could
get
the
the
gateway
ip
from
its
annotation,
but
it
can
only
cover
this
case
cannot
and
cannot
cover
other
multiple
interfaces
case,
and
maybe
I
mean
I'm
not
sure
if
he's
if
this
is
very
reliable,
but
since
we
have
using,
we
have
used
this
approach
for
not
macro.
Yes,
I
guess
it
should
be.
Okay,.
C
A
Okay,
I
want
you
just
a
quick
question
at
the
moment
you
have
just
a
design
or
you're
also
preparing
a
poc
for
this
feature.
A
Okay,
thanks
thanks,
I'm
sorry
I
was
not
aware
of
it.
I
thought
it
was
like
a
new
feature.
Okay,
thanks
a
lot
and
right,
so
I
don't
have
any
additional
questions
as
well.
Is
there
anything
else
that
you
like
to
ask
when
she
regarding
this
feature.
A
A
Should
we
just
move
to
some
other
thing
and
not
do
entry
anymore,
yeah,
just
jokes
aside,
I
don't
know
if
there
is
any
other
question,
please
any
other
question
or
other
topics
that
you'd
like
to
bring
up.
Please
go
ahead
with
a
way
to.
G
A
Okay,
so
since
we
have
plenty
of
time
I'll
go
ahead
with
something,
and
just
since
we
are
approaching
the
time
for
the
1.6
release,
we
already,
we
just
discussed
actually
the
status
of
the
node
selector
for
1.6
inch
applicability
to
this
upcoming
release.
A
Do
we
have
any
other
feature
which
might
be
worth
discussing
for
the
1.6
release
in
terms
you
know
prs
that
may
need
urgent
reviews
or
features
which
might
actually
be
a
little
bit
of
a
risk
for
1.6,
so
we
might
want
to
move
and
move
them
to
the
next
release.
Are
we
are
you
curious
about
any
of
the
prs
which
are
currently
under
review
for
1.6.
A
G
G
But
the
good
news
is
is
working
hard
on
that
and
I
think
fixing
most
of
the
comments.
But
today
we
still
got
some
bitcoin,
maybe
not
big,
but
we
still
got
some
comments
from
chuan
and
the
jinjin,
and
today
we
also
have
internal
discussion
to
discuss
yeah
just
to
discuss
how
to
fix
it.
G
So
I
think
the
good
news
is,
we
got
a
conclusion
and
how
to
finalize
the
pr-
and
I
hope
by
this
week
we
can
merge
the
huge
page
that
we
can
unblock
some
dp
related
implementation
from
multicast
and
from
flexible
ipam
related
features.
Then
I
think,
after
that
we
get
insurers
and
21.6
in
a
good
shape.
A
Okay,
it
seems
that
there
is
no
additional
questions,
so
I
think
that
we
exhausted
all
the
topics
for
today's
meeting.
I
would
like
to
thank
everyone
for
attending.
As
usual,
it's
been
a
great
presentation,
so,
most
importantly
thanks
to
bin
rochen
for
the
presentations
and
looking
forward
to
more
great
presentations
in
the
next
century,
community
meeting
thanks
everyone
for
joining
and
talk
to
you
in
two
weeks
time.