►
From YouTube: SIG Network Bi-weekly meeting for 20220217 - Part 1
Description
SIG Network Bi-weekly meeting for 20220217 - Part 1
B
A
I
swear:
there's
been
some
ux
done
on
this
in
the
in
the
90s
hi
everybody
welcome
to
the
sig
network,
bi-weekly
call.
It
is
february
17th
a
thursday.
It
is
two
in
the
afternoon
california
time
as
usual,
the
sig
the
kubernetes
code
of
conduct
applies
here,
which
boils
down
to
be
excellent
to
each
other.
A
A
Can
anybody
see
yep
all
right,
so
we
have
only
a
few
today,
and
most
of
them
are
not
particularly
new.
So
there's
this
one
long
delay
creating
endpoints
when
periodic
service
resync
happens,
I
read
it
over.
It
sounds
like
a
fun
but
legitimate
bug
and
there's
a
pull
request
already
open
to
it.
So
I
don't
know
if
tnqn
is
on
the
call
or
not
but
sounds
like
they
have
it
under
control.
D
A
I
had
a
chat
with
him
a
little
bit
on
slack
yesterday
too
next
deprecating
ips,
with
leading
zeros
antonio
picks
up
the
ball
and
runs
with
it.
This
is
a
a
great
issue,
it's
more
of
a
to-do
list
than
an
issue.
Antonio,
do
you
intend
to
carry
forward,
or
do
we
gonna
try
to
find
volunteers
to
help
do
all
these.
F
A
A
I'm
not
sure
I
can
make
that
argument,
because
all
my
efforts
at
phoning
home
have
met
fallen
on
on
negative
responses.
If
you
wanna,
we
can
debate
the
the
real
risk
versus
reward
on
this.
We
can
do
it
on
this
issue.
I
haven't
honestly
like
gone
and
scoured
all
of
the
gke
clusters
to
see
if
there's
anybody
who's
done
this,
I
could
I'm
not
sure
that
that
alone
is
compelling.
F
H
A
J
K
A
You
on
that,
yes,
so
so,
let's
take,
we
can
carry
the
conversation
in
this
issue,
but
basically
this
issue
proposes
that
we
over
several
releases
first
complain
about
people
who
are
doing
this
and
then
try
to
fix
it
up
on
the
fly
for
them.
Although
jordan's
less
convinced
that
that's
a
good
idea
such
that
we
can
eventually
in
like
four
to
six
releases,
actually
undo,
antonio's,
sloppy
parsing
and
and
go
back
to
the
strict
parsing.
H
J
Ahead,
kyle,
no,
no!
I
was
just
leaning
in
and
say
I
support
the
statement
that
they
met
and
we
cannot
break
a
behavior
that
we
allowed
they.
Just
there
is
always
some
guy
without
with
with
a
small
pc
where
this
chronic
cooper
has
close
features.
I
mean
you
just
get
deprecated
right,
that's
yeah,
but
this
is
a
predictable
life
cycle
right.
We
can't
we
can't
we
can
duplicate
the
behaviors.
The
problem
is
undocumented.
Behavior
has
always
been
that
the
undocumented
behavior
that
that's
so.
C
J
A
E
A
Couldn't
api
another
option
here
could
be
that
we
allow
updates
to
ip
fields
like
we
allow
it
in
service,
but
only
if
you're
translating
it
from
like
0
1
1
to
11..
If
you
change
it
from
0
1
1
to
9,
you
get
an
error,
but
if
you
change
it
to
11,
then
we
allow
it
and
then
we
put
this
tool
out
there
and
we
tell
people
if
you,
if
you
hit
this
error,
run
the
run
this
tool
and
it
will
fix
your
service
for
you.
L
B
A
Yeah
I
mean
I
don't
know,
let's,
let's
take
the
discussion
to
this
issue,
but
it
is
an
issue.
I
don't
think
we
should
keep
the
sloppy
parsing
forever.
I
think
the
first
step
is
to
make
sure
that
we
all
agree
for
any
net
new
api
that
adds
an
ip
field
anywhere.
We
should
use
non-sloppy
parsing
and
just
not
allow
the
problem
to
get
worse,
like
first
stop
digging.
A
A
H
A
G
D
E
G
A
F
E
A
N
A
N
All
right
so
yeah,
this
is
a
follow-up
from
two
weeks
ago,
when
we
were
talking
about
advocating
policies
in
the
interim.
Thank
you
to
everyone
who
commented
on
the
doc.
It's
still
open
so
feel
free
to
throw
your
comments.
If
you
haven't
already,
there
was
a
couple
of
things
I
wanted
to
go
through
just
clarifications
for
things
that
came
up
as
comments
and
then
also
an
open
question
for
folks
to
discuss.
The
first
has
to
do
with
the
behavior
of
what
we're
proposing.
N
So
I
just
wanted
to
clarify
that,
since
I
think
it
didn't
come
through
properly,
the
behavior
that
I
think
I've
heard
from
users
that
they
want
to
enforce
is
a
data
path
block.
So
when
they
say
allow
traffic
to
wikipedia.org
they
really
they
really
want
to
make
sure
that
hard-coded
ips
can't
you
know
egress
and
somehow
exfiltrate
data.
So
this
isn't
it's
not
sufficient
for
the
customers.
I've
spoken
to
to
just
have
dns
filtering.
N
They
really
do
want
a
data
path,
protection
and
that's
really
central
to
what
they're.
Looking
for
the
corollary
to
that,
essentially,
is
that
and
dan
did
a
really
good
job
of
explaining
this,
and
I
copied
his
text
is
that
we
need
to
use
the
allow
list
with
implicit
deny
model
for
any
of
the
fqdn
matches.
N
N
Yeah,
that's
that's
one
of
the
things
that
also
came
up,
and
my
thinking
is
that's
how
it
has
to
be
there's
like
reverse
lookups
are
not
reliable.
Is
this
the
consensus,
and
so
I
think
you
have
to
require
that
a
dns
lookup
be
made
before
you
try
to
send
out
ip
send
out
traffic,
which
I
know
it
runs
into
issues
with
you
know
caches
or
if
users
are
doing
something
funky,
it
might
be
problematic,
but
I
don't,
I
think,
that's
the
only
way
to
reasonably
enforce
this
policy.
I
I
I
E
It's
one
question
because
it
took
me
a
while
to
understand,
because
the
proposal,
and
because
of
the
comments
you
clarify
it,
my
question
is
for
conceptually
is
clear
right
now
to
me
what
I
don't
know
if
it's
realistic
that
you
can
do
that,
I
mean
for
for
github
wikipedia
or
these
people.
Maybe
you
can
assume
you
know
then
dns
when
I
pee.
My
question
is:
what
happens
with
people
use
this
gear
then
see
the
ends
or
multicasting
all
these
kind
of
things.
I
mean
false
positive
on
something
that
blocks
traffic
is
risky,
so
the
concept.
E
E
N
Yeah
yeah,
so
would
it
be
sufficient
in
this
case
to
add
that
as
one
of
the
requirements
like
alongside
we
don't
support
tls
right
now?
The
second
point
is:
if
your
fqdn
is
going
to
resolve
to
a
cdn
or
a
shared
ip,
we
can't.
We
can't
do
any
better
than
allow
listing
that
ip
and
whatever
is
behind.
That
is
all
allowed.
I
Have
you
looked
over
the
semantics
that
it
really
works
for
v6
as
well
right?
Okay,
if
you
look
up,
you
get
the
full
v6,
but
I
think
it
I
don't
see,
really
any
problems,
but
for
for,
like
I
said
for
outgoing,
but
for
incoming
definitely
right.
The
address
has
changed
all
the
time
on
on
a
non-statically
configured,
machines
and
services.
G
If
you're
getting
stuff
behind
a
cdn,
it's
http,
you
could
use
an
http
proxy,
in
which
case
you
can
restrict
it
to
specific
hosts,
even
if
they're
all
on
the
same
cdn
and
like
people
are
saying
that
they
want
this
at
the
l4
level,
because
we
provide
them
with
all
four
solutions,
but
a
lot
of
them
really
wanted
at
the
l7
level
I
think
like
and
and
if
we
could
just
make
it
easy
for
them
to
set
up
an
http
proxy.
That
would
do
the
filtering
that
they
want.
G
B
J
G
J
J
I
J
I
I
G
A
A
A
You
know
I'm
trying
to
figure
out
if
there's
a
smaller
primitive,
that
we
need
to
enable
these
sorts
of
things
without
necessarily
becoming
one
right
like
we
don't
have
a
service,
chaining
api
that
says,
guarantee
me
that
all
the
output
from
this
pod
goes
to
this
other
pod.
First
right,
maybe
that's
the
api
that
we
need.
J
The
first
half
so
somehow
that
the
the
the
bot
template
will
have
a
flag
that
says
this
spot
is
proxied
to
a
service
ip
or
we
need
to
figure
it
figure
it
out
and
then
not
the
cni,
not
the
same
eye.
The
same
eye
is
not
responsible
because
the
same
eye
doesn't
know
if
which
part
is
what
and
then
that's
what
we
do
from
our
side.
That's
the
only
thing
we
do
initially,
then
people
can
build
the
egress
around
that
they
can
deploy
jay
proxy,
configure
it
whatever,
whatever.
J
M
M
N
N
A
Well,
I
think
the
challenge
that
dan
was
offering
is
for
those
customers
who
are
asking
for
this.
What
percentage
of
them
are
actually
sending
http
after
they
do
all
this
right?
If
it's
90
of
them,
then
what
they're
really
asking
for
is
better
served
by
a
proxy.
If
it's,
if
they're
saying
no
really
we're
doing
non-http
stuff,
you
know
some
other
tcp
protocol
or
something
then
yeah,
then
we
have
to
not
that
that
isn't
a
good
solution.
A
M
J
It's
kind
of
unfair
to
assume
that
the
kind
of
the
proxies
works
well
with
http
just
because
they
are
well
specified.
People
do
proxies
for
all
other
things,
such
as
caching,
but
bringing
cash
to
close
up
to
that
consumers
and
then
so
even
the
custom
custom
custom
implemented.
Custom
pcb
protocol
can
can
have
its
own
proxy
in
the
method
right.
G
O
So
I
think
ralph
one
thing
that
would
help,
because
I
think
what
I'm
hearing
from
the
discussions
is,
it
ranges
over
people
are
like
well
what,
if
the
target
cdm,
maybe
if
we
can
follow
it
up
with
like
some
understanding
where
the
users
are
coming
from
like
what
is
their
use
case,
because
I
think
it
sounds
like
from
the
conversation
here
that
there
are
a
ton
of
different
use
cases.
Some
make
sense,
some
don't
make
sense
or
well.
O
Maybe
we
can
clarify
on
that
and
I
have
to
say,
like
it's
clear
given
if
you
look
at
the
major
implementations
out
there
like
they
do,
support
this
all
of
them
in
some
form,
and
clearly
users
want
this.
They
may
be,
you
know,
kind
of
doing
the
wrong
thing,
but
they
definitely
want
to
express
something.
N
A
N
Go
ahead,
I
guess
my
question
was:
would
we
fit
to
the
least
common
denominator
like
if
I
come
back
with
one
example
of
someone
who
says
I
want
a
full
l7
proxy
one
example
of
someone
who
says
I
want
to
do
like
you
know,
udp
traffic
and
one
example
of
someone
who
says
I
have
a
special
tcp
protocol
like
what's?
What's
the
threshold
of
you
know?
Yes,
we'll
do
this
at
l4
versus
no?
No,
we
really
want
to
make
a
l7
proxy.
I
For
tcp
I
mean
the
question
is:
really:
are
you,
okay,
with
running
with
two
connections,
basically,
that
the
proxy
would
break
it
and
copy
between
two
connections,
or
do
you
require
a
non-transparent,
no,
a
transparent,
tcp
proxy?
Basically,
where
you
transfer
there's
only
one
transport
connection
and
you
have
a
proxy
in
the
middle
that
basically
breaks
this
up,
which
is
doable,
but
it
has
a
lot
of
side
effects.
I
mean
so,
but
I
agree
with
you
figure
out:
what
are
the
use
cases?
A
I
mean
I'm,
I'm
really
reluctant
for
us
to
take
on
putting
a
service
proxy
in
the
data
path,
on
the
user's
behalf.
That
feels
like
a
step
too
far
for
the
core
of
kubernetes
like
psyllium.
Does
it
and
that's
cool
and
calico?
Does
it
and
that's
cool,
but
those
are
things
that
the
users
are
signing
up
for
specifically
right,
I
I
for
something
about
it.
Just
doesn't
feel
like
it's
the
right
thing
to
be
normalizing
but
yeah
to
make.
A
Yeah-
and
we
have
a
hard
time
making
anything
mandatory
at
this
point,
but
the
the
the
other
side
of
it,
though,
is,
is,
if
all
the
use
cases
really
point
down
to
we'd
like
to
force
inject
something
on
the
data
path
like.
Maybe
that
is
really
what
we
should
be
looking
at
is
some
sort
of
service
chaining
api,
that
plug-ins
can
implement
and
then
chained
to
an
l7
or
chained
to
a
custom,
proxy
or
or
you
know
whatever,
that
api
would
look
like.
I
don't
really
know,
but.
J
J
Wouldn't
it
be
nice
if
I
can,
as
I
say,
okay,
this
group
of
pots,
regardless
how
they
are
identified,
can
I
must
have,
must
use
this
proxy
for
auditing
for
routing.
For
yes,
I
don't
know
now
now
the
wind,
the
only
way
people
do
that
now
is
emit
containers,
and
then
they
force
the
traffic
side.
Cars
all
right.
So
we're
not
we're
not
saying
that
everybody
should
use
a
proxy,
but
I'm
a
strong
believer
that
all
the
l7
by
nature
is
traffic
inspection.
I
J
I'm
a
big
believer
of
value
versus
versus,
like
the
value
of
the
same
versus
the
thing
I'm
asking
for
like
I
want
little
I
use
letter.
I
want
more,
I
use
more
right
so
right
now
I
want
little
ip
ll4
and
all
the
routing
stuff.
That's
the
system
gives
you
that
you
want
more,
then
you're
gonna
have
to
do
more.
I
configure
more
so
just
the
effort
equal.
P
A
N
N
Q
When
we
originally
brought
this
up,
somebody
brought
this
up
like
about
two
years
ago
and
they
brought
it
to
the
original.
Those
remember
those
old
network
policy
working
groups
where
all
we
did
was
just
like
argue
about
stuff
like
before,
and
I
remember
like
nobody
cared
about
this
then
or
like
somebody
proposed
this
or
some
version
of
it.
Nobody,
I
don't
know,
and
then
there
was,
I
think,
a
mailing
list
thread
about
it,
but
I
don't
know.
A
A
Meshes
better,
oh,
I
I'm
I'm
actually
fairly
convinced
that
having
such
an
api
is
the
right
thing
to
do.
I'm
not
sure
it's
the
right
thing
for
this
particular
problem
yeah,
but
I
think,
having
seen
what
I've
seen
service
meshes,
do
it
feels
like
some
sort
of
service
chaining
mechanism
could
could
actually
open
a
lot
of
doors
for
us.
I
We're
implementing
a
security
solution,
I
mean
basically
a
network
policy
on
and
in
there,
in
the
policy
enforcement
point,
you
can
send
it
to
a
dpi
solution
that
can
scan
the
stream
for
a
while
and
so
on.
It's,
like
you,
say
it's
very
possible
to
do
with
service
training.
The
question
is
really
is
that
there
needs
to
be
more
way.
I
mean
more
than
one
way
to
implement
things
right
and
not
force
anyone
to
go
down
that
path.
J
That's
right:
let's
take
it
to
the
mailing
list.
I'm
gonna
go.
Ask
a
few
of
the
people.
I
know
are
big
on
using
kubernetes
for
similar
things
all
right,
and
I
know
that
that
even
cloud
providers
like
us
they
provide
like
proxy
solution
and
firewall
solution
for
eagles
traffic.
So
maybe
it's
maybe
we'll
see.
Let
me
let
me
go,
ask
and
I'll
share.
Whatever
I've
heard,
I
think
bridget
was
saying.
J
J
No,
I
just
have
this
pr
that
was
so
hot
during
that
days
about
people
were
complaining
about
the
toast,
changing
ips,
so
folks,
running
on
non-cloud
environment,
typically
speaking,
and
the
host
changing
ip,
the
the
pot
status,
the
host
ip
doesn't
change,
so
we
came
up
with
this
pr
and
then
it
got
hot
and
then
the
discussion
was
dropped.
You
other
priorities,
so
I
just
wanna
like.
Should
we
carry
it
on
or
just
close?
It.