►
From YouTube: Kubernetes SIG Network meeting for 20230525
Description
Kubernetes SIG Network meeting for 20230525
A
Foreign
looks
like
it's
recording,
hello
everyone
and
welcome
to
the
May
25th
edition
of
the
Sig
Network
meeting.
A
We
have
a
few
things
on
our
agenda
for
today,
but
as
oh
sorry,
this
meeting,
as
always,
is
governed
by
the
kubernetes
code
of
conduct.
This
boils
down
effectively
to
be
nice
to
one
another
and
also
if
in
general,
when
conversations
are
happening,
if
you
could
try
to
use
the
zoom
Razer
hand
feature
that's
very
helpful
for
us
to
keep
the
conversation
flowing.
A
We
have
a
few
items
on
the
agenda
today.
It
is
an
open,
Agenda,
there's
not
tons
of
stuff
on
there.
If
you
have
something
that
you'd
like
to
add,
please
do
feel
free
to
add
it
now,
while
we're
talking
or
while
we're
going
through
some
of
the
other
agenda
items,
otherwise
we're
going
to
start
off
with
triage
and
then
get
into
our
agenda.
B
C
A
Okay,
cool
all
right,
so
we'll
start
off
with
triage
I've
opened
up
the
issues
that
are
in
triage,
but
don't
have
an
assignee.
Yet
we
can
also
go
through
some
of
the
ones
that
do
have
an
assignee.
If
there's
anything
to
go
over
but
I
at
least
thought
we'd
prioritize,
the
ones
that
weren't
assigned
so
all
right,
Network,
ready
next
Readiness
for
index
job
plus
headless
service
depends
on
presence
of
pod,
see
if
anybody's,
taking
a
look
at
this
one
already.
D
A
E
A
Okay,
all
right
Tim's
got
this
one
in
hand.
Thank
you.
Let's
focus,
then,
on
the
next
one,
Dan
generic
versus
platform,
back-end
specific
options,
incube
proxy.
F
So
this
is
basically
you
know:
I
just
filed
it
to
get
discussion,
so
people
who
have
opinions
on
your
proxy
command
line
options
and
or
config
file
should
go
there
and
comment
specifically.
This
started
about
the
fact
that
some
of
the
stuff
is
not
really
divided
up
well
for
Linux
versus
Windows
and
IP
tables
versus
ipvs
versus
wind
kernel.
F
But
there's
another
issue
open
right
now,
where
there's
discussion
about
the
whole?
Well,
we
shouldn't
be
deprecating
the
command
line
options.
If
the
config
file
is
only
Alpha
anyway-
and
you
know,
maybe
we
it's
time
we
make
the
config
file
be
yeah,
be
beta,
so
anyway,
people
should
discuss.
C
E
A
A
F
Okay
yeah:
this
came
out
of
another
issue
where
somebody
is
trying
to
add
the
new
fancy.
Alpha
logging,
stuff
and
Gordon
complained
that
we
should
not
be
telling
people
that
the
landline
options
are
deprecated
if
the
config
file
is
only
V1,
Alpha
One,
so.
A
F
A
A
D
F
F
D
If
somebody
sent
you
a
pull
request
to
add
IPC
or
somebody
sent
you
a
kept
even
better
to
add
IP
set
support
to
the
iptables
proxier.
Do
you
think
it
would
be
a
good
use
of
your
time
and
the
community's
time
to
review
it?
Think
about
it?
Add
another
feature,
gate
and
roll
it
out.
Then
you
should
probably
just
Knack
it
and
close.
It.
A
Yeah,
so
the
context
that
makes
sense
to
me
the
context
here
is
I
think
Damon
is
kind
of.
What's
the
right
word,
he's
he's
been
rapidly
ramping
up
from
the
kpng
project
into
entry
and
the
fact
that
he
created
this
makes
me
wonder
if
he
would
do
it
because
he's
been
very
hungry
to
do
these
sort
of
things.
So,
just
to
just
to
be
clear,
we
generally
don't
think
it's
worth
our
the
time
of
the
community
to
do
this.
But
if
somebody
was
really
hungry
to
do
this,
it
would
only
be
a
benefit.
F
It
would
not
be
an
ambiguous
benefit
because
when
we
would
need
to
spend
time
reviewing
the
code
and
two
by
the
time
it
reached
GA,
the
NF
tables
proxy
might
be
at
least
Alpha,
if
not
beta.
So
I've
actually
talked
to
Damon
on
slack
and
and
encouraged
him
to
work
on
other
things
and
pointed
out
a
bunch
of
other
things
that
he
could
work
on.
That
that
you.
G
H
F
A
C
D
I
I
a
thousand
percent
support
folks
who
are
interested
in
getting
involved
in
bigger
ways
right,
like
Damon's,
been
involved
enough.
That
I
recognize
the
name
which
is
you
know
at
least
a
signal
that
he's
been
around
I
would
love
to
find
ways
to
harness
enthusiasm
that
we
are
all
agreeing
you
know
aligned
with
the
directional
side
of
things.
So,
however,
we
can
do
that
like
I'm
here.
A
B
A
Yeah,
but
if
it's
not
aligned
with
the
direction,
yeah
I
think
that
it
makes
sense
to
say
thank
you,
but
I.
Don't
think
we're
going
to
want
to
do
this
one.
So
that's
cool
all
right.
A
couple
more
cni
networking
errors
leave
node
marked
ready,
but
unusable
anybody
nobody's
taking
a
look
at
this
one.
Yet
that
was
last
week
when
using
a
cni
for
example,
as
there
were,
it
may
fail,
even
if
the
plugin
correctly
reports
errors
back,
the
node
is
still
marked
ready,
but
it's
unusable
if
the
node
were
not
marked
ready.
A
Roger,
thank
you
for
taking
that
one
forward
last
one
that
doesn't
have
an
owner,
topology
cache
has
populated,
hence,
method
can
attempt
concurrent
map
access.
C
Ing
this-
and
there
was
another
one
that
fixes
this
one
place
here,
so
the
the
this
person,
this
quick
work
or
work.
That
is
a
he
contributed
many
times
and
I.
Think
that
he's
right,
but
I,
don't
know
if
it's
the
same
is
the
version,
the
master,
and
so
he
has
to
fix
too.
This
has
a
put
request
to
fix
that.
C
G
Yeah
I've
been
looking
at
it
too
I'll
tell
you
like
at
his
PR,
but
yeah
feel
free
to
assign
me
to
any
part
of
the.
C
A
A
Do
we
want
to
go
some
through
some
of
the
ones
that
do
but
have
been
sitting
around
for
a
bit
or
should
we
go
into
the
rest
of
the
agenda
and
maybe
come
back
to
those?
If
we
have
time
I
lean
towards
the
second.
A
C
C
The
service
is
the
most
they're
the
biggest
issue,
but
I'm
trying
to
say
instead
of
going
for
the
repeater,
why
don't
you
take
some
particular
thing
of
one
API
and
start
to
describe
it
to
document
it
to
prove
different
things,
and
in
that
process
you
have
it
we
test
and
you
promote
to
conformance.
So
you
can
grow
your
knowledge
of
the
of
the
code
base
from.
B
C
Instead
of
you
know
trying
to
learn
something:
that's
super
difficult
that
will
require
a
lot
of
time
to
review.
That
is
racist.
That
that's
my
point
is
we
have
a
lot
of
gaps
in
in
the
code
in
the
apis,
the
Tesco.
They
are
pick
one
small
fit
to
try
to
a
document
it
describe
it
at
this
or
I.
Don't
know
you
are
going
to
find
bats
for
sure.
A
Yeah
and
I
appreciate
you
reiterating
that
and
I
think
my
point
with
putting
this
back
on
the
agenda
was
making
sure
we
checked
in
on
any
actions
that
we
can
take
as
a
Sig
to
better
support
that
direction.
I
agree
with
that
direction.
Basically,
it's
a
good
way
to
help
hopefully
grow
people
in
a
way
that
will
be
less
painful
and
more
edifying.
So
maybe
there
are
ways
in
which
we
can
I
don't
know
document
this,
this
kind
of
philosophy
a
little
bit
more
I,
don't
know
what
do
you
think?
C
Describe
session
Affinity
how
it
has
to
work,
this
describe
is
sentences.
There
are
a
lot
of
pieces
with
100
comments
and
because
we
move
on
and
nobody
following
this,
but
I
was
talking
with
him
two
weeks
ago.
One
week
ago,
station
Affinity
is
quickly
unders
described
things
like
that.
Just
pick,
one
of
the
apis
that
you
know
that
is
not
well
documented
and
go
deep
on
that
and
document
it
and
test
itself.
D
Verify
so
one
of
the
things
that
I've
thought
about,
but
haven't
really
done
anything
with
we
as
a
community.
We
have
our
API
documentation,
which
is
not
often
very
verbose.
It's
it's
actually
often
very
terse
and
leaves
out
a
lot
of
stuff.
It
doesn't
talk
about
concept,
it
doesn't
talk
about
overviews.
D
We
have
web
page-ish
content,
which
is
pretty
high
level
and
isn't
often
updated,
because
it's
in
a
different
code
base-
and
you
know
most
of
us-
are
not
Tech
writers,
and
so
we
tend
to
forget
about
it.
I'll
at
least
speak
for
myself
or
it's
so
bad.
It
needs
a
total
top
to
bottom
rewrite
and
who
has
the
time
for
that,
and
so
we
don't
have
a
good
place
in
between
to
write
sort
of
technical
docs.
D
Now
Dan
started
this
implementer's
guide
for
cube
proxies
right,
which
is
awesome,
but
it
wasn't
clear
to
me
where
it
goes
where
it
should
live.
How
do
we
actually
share
that
information
with
people?
I
would
like
to
see
us,
especially
as
one
of
the
lower
down
the
stack
cigs,
who
has
a
lot
of
surface
area.
D
I
would
like
to
see
us
explain
more
what
these
things
mean
now
describing
session
Affinity
well,
okay,
that
probably
actually
belongs
in
the
API
docs
and
the
user
facing
public
docs,
but
there
are
other
Concepts
like
that
implementer's
guide.
What
is
what
does
internal
versus
external
traffic
right
like?
Where
do
we
document
that
it's
not
really
related
to
any
one
field?
A
Where
can
we
basically
have
a
better,
a
place
that
isn't
quite
API
docs
or
you
know
just
the
normal
web
content
that
we
have
where
somebody
who
wants
to
get
deeper
into
Sig,
Network
and
onboard
a
little
bit
better,
find
some
guides
related
to
the
technology
and
not
necessarily
have
to
struggle
as
much
to
get
started
and
know
a
little
bit
better
where
they
can
get
started
because
right
now,
if
you
try
to
just
go
to
the
issues
and
look
for
Sig
Network,
it's
a
jungle
out
there.
So
yeah
and.
D
Frankly,
the
API
docs
could
be
a
lot
better
right.
Like
I
I
mentioned
internal
external,
like
we
actually
could
write
a
little
paragraph
around
internal
traffic
policy
and
external
traffic
policy
that
describes
what
internal
and
external
need
right.
I
know
that
not
every
end
user
goes
and
reads
the
API
documentation,
but
written
somewhere
is
better
than
written.
Nowhere.
I
Dude
I
mean,
as
our
sigs
expand,
underneath
Sig
Network,
like
we're
going
to
need
a
commonplace
anyway
to
put
certain
stuff
like,
maybe
even
you
know,
the
conformance
profiles
that
Shane's
working
on
and
other
stuff,
the
Gateway
API
is
kind
of
spearheaded
like
we
could
fairly
would
low
overhead,
have
a
Stig
Network
on
kdocs
website
and
repo
and
six
that
kind
of
houses.
Some
of
this
stuff.
J
Come
on
I'm
gonna
have
to
disagree
on
the
statement
that
not
everybody
reads
that
cluster,
like
traffic
policy,
almost
every
single
customer
I
have
dealt
with
that
had
a
problem
with
the
way
the
traffic
Works
reference
that
paragraph
or
two
paragraph
that
they
talk,
which
are
not
clear
that
they
talk
about.
So
most
people
actually
working
working
trying
to
get
this
to
work.
The
way
they
think
it
should
work
so.
D
D
A
So
we
needed
we
potentially
need
to
take
action,
some
kind
of
like
especially
just
given
how
much
ground
we
cover
and
how
much
is
going
on
these
kinds
of
things
like
docs,
almost
always
kind
of
fall
to
the
Wayside.
It's
just
a
it's
a
natural
matter
of
impetus
for
change.
Right,
like
everything,
technical
is
going
to
get
more
focused.
A
Maybe
there's
some
room
here
to
come
up
with
some
new
incentives
to
improve
these
areas.
I,
don't
know
what
that
would
be
yet,
but
that's.
My
first
thought
is
like
incentivizing
this,
the
area
of
API
docs,
certainly,
although
I
still
very
much
like
the
energy
of
like
having
like
onboarding
guides
and
stuff
like
that
for
the
technology,
I
think
that
sounds
really
good
too.
A
Don't
need
to
take
up
a
ton
of
time
with
this,
but
I
I
like
the
thoughts,
and
it
might
just
be
a
good
one-
that
I
can
kind
of
go
async
with
myself
and
think
about
bringing
this
one
up
again.
Once
I've
had
some
more
time
to
think
about
it
and
think
about
specific
actions
to
take.
Unless
anybody
has
some
specific
actions,
they
would
like
to
see
taken
now.
A
A
Okay,
our
key:
do
you
want
to
talk
about
your
follow-up
for
the
cost
cap
see
here.
K
So,
as
suggested
on
this
previous
meetings
about
well
I
want
activities
Network.
K
And
actually
Marcus
did
representation
about
Qs
classes.
Yesterday,
Patrick
did
representation
about
with
GRE
G.
We
got
some
feedback
like
one
is
like
pretty
much
like
one
hour
or
old
from
Peter
white.
He
wrote
what
he
he
likes
or
some
of
the
aspects
of
Geary
and
it
might
be
usable.
However,
I
think
yesterday
only
making
my
say
mentioned
some
of.
K
How
we
will
be
referencing
them
from
services
like
policy
networks
and
so
on?
So
a
bunch
of
open
questions,
so
discussion
is
ongoing.
We
are
continuing
with
stick
multi-network
and
we
also
review
it
with
cap.
What
signal
to
network
is
preparing?
We
looked
at
all
nine
use
cases
or
stories.
What
what
we
have
I,
don't
know
if,
if
you're
interested
I
can
show
like
one
slide,
what
we,
what
we
think,
how
how
we
came
up
and
and
what
scenarios
what
we
think
about
the
area,
U.S
classes.
A
Gotcha,
so
is
it
mostly
just
kind
of
an
update
that
yeah,
you
guys
are
still
thinking
about
this?
Is
there
anything
we
can
do
to
help
facilitate,
because
it
sounds
like
the
next
step
is
like
soon.
Maybe
you'll
come
back
with
like
here's,
what
we
actually
think
we
want
to
do
now
that
we've
talked
about
it
or
do
you
need
help
with
anything.
K
B
A
I'm,
pretty
pretty
pretty
looking
forward
to
the
next
steps
with
this
and
I
appreciate
you
guys
bringing
it
up.
A
A
Cool
I
would
definitely
encourage
anyone
from
this
group
who's
interested
there's
a
regular
multi-network
meeting
on
the
Sig
calendar
and
the
this
is
one
of
the
main
topics
of
conversation
today,
but
also,
as
we
talked
about
at
the
last
meeting,
or
at
least
last
one
I
was
at
we
talked
about.
We
were
talking
a
lot
about
like
where
options
that
you
could
add
for
network
interfaces
would
live
and
stuff
like
that.
C
C
The
one
that
I
sent
an
email
that
is
I
was
working
on
this
multiple
service
sizes
for
other
multiple
service
to
dynamically
to
the
classes,
and
we
have
this
other
cap
that
is
about
adding
multiple
crash,
the
sizes
to
multiple,
both
Siders
to
the
best
and
we
identified
during
the
reveal
that
is
collides
and
you
can
be
confusing
for
the
users.
So
we
have
this
document
with
different
approaches
have
been
discussing
in
growth
in
one
of
us
in
blue
corn
in
multiple
places,
and
it
seems
that
it
falls
down
to
two
options
right
now.
C
That
is
basically,
we
create
a
Singleton
object
that
allows
us
to
cross-validate
the
network
or
or
we
use
some
more
asynchronous
way.
So
I
have
to
come
up
with
a
smaller
version.
A
summary
of
this
big
document
with
these
two
options
and
I
hope
to
to
get
a
consensus
in
the
next
weeks
to
be
able
to
move
forward
with
these
two
steps.
C
Okay,
so
the
other
is
about
the
cap
of
the
the
quality
are
working.
Is
that
now
is
topology?
We're
writing
and
I
was
talking
with
Rob
I'm
going
to
to
take
on
this
to
try
to
to
finish
it
to
GA,
and
what
we
were
talking
is.
The
big
demand
is
is
preferable
right
people
once
prefer
local
and
right
now
we
have
an
one
heuristic
that
is
not
perfect
and
sometimes
confused.
C
C
So
if
we
can
abstract
the
code
in
a
way
with
a
good
interface
and
with
the
cap
that
is
moving
the
important
slides
to
the
staging,
we
can,
we
can
offer
the
people
a
new,
prefer
algorithm
based
on
hint
with
this
new
interface,
and
they
can
use
it.
You
know
so
we
we
Intrigue,
we
offer
a
way
of
implementing
the
resisting
algorithm
plus
profession,
using
topology
working,
and
we
offer
the
opportunity
to
people
that
want
to
do
more
complex
things
to
run
their
own
internalized
controller
with
their
own
topology
and
a
media
room
for.
G
Foreign
yeah
I
mean
I'll
just
Echo.
What
what
you're
saying
there
I
think
it's
a
great
idea,
I
think
it's
very
clear
that
people
want
something
that
we've
referred
to
as
prefer
local,
but
just
something
that
is
very
predictable
and
there's.
There's
no
magic
involved,
and
so
I'm
excited
to
see
this
happen.
G
I
think
using
hints
you
know,
I
was
not
entirely
sold
on
it
at
first,
but
I
do
like
the
idea
of
showing
both
you
know
what
we
have
right
now,
which
is
a
fairly
complex
heuristic
for
hints,
and
also
a
very
simple
heuristic
for
hints,
which
this
would
be
seems
like
we're,
providing
a
couple
entry
examples
of
how
you
can
build
your
own
heuristic
and
then
you
know
leaving
it
up
to
the
community
if
they
want
to
develop
more
out
of
tree-
and
you
know
I,
think
part
of
this
I'm
not
sure
how
much
will
be
in
scope
for
this
skip,
but
there's
the
related
Gap
that
will
make
it
easier
to
run
endpoint
slice
controller
out
of
tree
cap
I,
keep
on
saying,
Gap,
but
either
way.
G
Yeah
I
I,
like
this
direction
and
I,
think
a
lot
of
people
are
going
to
be
excited
to
see,
prefer
Zone
option
up
here
here.
One
one
detail
that
I
missed
I
think
what
you're
saying
Antonio
is.
This
would
all
be
bundled
in
the
same
cap
right.
C
G
C
G
C
An
API
and
then
points
to
Adkins
has
a
label
that
do
things
with
hints
and
has
a
reference
implementation
on
how
to
do
things
with
him
and
I
think
that
these
are
pretty
is
successful
criteria
to
be
EGA.
You
know
because
it
provides
if
the
big
demand
is
professional,
but
we
want
to
give
people
flexibility
too,
right
and
yeah
and
I.
Think
with
this,
we
have
both
things.
G
Yeah
I
agree:
okay,
just
want
to
make
sure
that
was
good
with
everyone,
but
I'm
fully
on
board.
With
this
approach.
A
G
G
Yeah
this
is
awfully
similar
to
what
I
was
talking
about
in
the
last
meeting,
where
we
had
rc2
ready.
Last
time
we
met
the
Monday
after
that
I
think
we
released
070
full
change.
Log
is
there.
A
couple
features
are
graduating
to
our
standard
channel.
There's
some
gaps
that
made
significant
progress,
including
policy,
including
Gateway,
plus
MCS
yeah.
There's
a
lot
going
on
so
yeah.
G
If
you're
interested
v070
is
out
now
we're
looking
for
a
pretty
short
turnaround
before
we
get
to
v080
and
vo80
is
what
we're
expecting
is
just
going
to
be
a
gamma
focused
release,
and
that
will
state
that
gamma
is
ready
and
Gamma
is
our
mesh
side
of
things
and
that's
ready
to
go
to
experimental.
We
have
multiple
implementations.
Now
our
spec
is
stabilizing
around
that.
So
080
is
probably
I
would
say
one
to
two
months
away.
G
G
So,
let's
Gateway
API,
just
one
other
thing
since
we're
at
an
earlier
meeting
time
right
now,
we're
also
testing
out
earlier
meeting
times
for
Gateway
API
and
so
again.
Next
week,
we're
meeting
at
8
30
a.m,
Pacific,
which
is
half
an
hour
earlier
in
the
day
than
this
meeting,
was
that
is
today
and
it's
on
Tuesday.
H
A
All
right,
I
have
one
little
thing:
I
remembered
that
I
wanted
to
talk
about.
It
is
just
a
tiny
blurb.
We
followed
up
on
this
before
several
weeks
ago.
Andrew
soycos
gave
us
a
cool
demo
about
bpfd,
which
is
a
a
tool
for
loading
and
managing
your
BPF
programs
and
there's
an
operator
for
doing
it.
A
On
kubernetes,
we
talked
a
little
bit
about
the
possibility
that
improving
the
general
ebpf
plus
kubernetes
ecosystem,
partially
with
things
like
bpfd,
but
just
more
in
general,
because
it's
kind
of
a
hard
ecosystem
to
work
in
right
now
with
a
lot
of
rough
edges
was
something
that
we
would
potentially
be
interested
in
doing
so
there
is
a
hashtag
ebpf
Channel
now,
which
I
think
I
mentioned
on
a
previous
meeting,
but
things
have
been
going
pretty
well
there
in
terms
of
like
strong
signal
from
the
community.
A
There
was
we
had
a
meeting
a
zoom
a
few
weeks
ago
that
ended
up
having
a
really
good
turnout
like
I
think
it
was
something
like
25
people
and
it
included
people
like
if
you
know
them:
Bill
Mulligan
who's,
the
community
manager
for
celium
and
Dan
finneran
who's.
Just
well
known
throughout
a
variety
of
development
communities,
we
are
doing
a
follow-up
to
that
which
will
be
next
Monday
if
you're
interested
in
the
general
Improvement
of
abpf,
plus
the
kubernetes
ecosystem.
A
Please
do
join
the
channel
and
potentially
the
meeting,
but
right
now
we're
just
kind
of
checking
in
with
people.
There's
been
a
strong
signal
and
we're
kind
of
seeing
what
we're
doing
there
we're
not
really
sure
exactly
what's
going
to
take
for
them
yet,
but
possibly
there's
room
for
a
working
group
here,
we're
just
kind
of
feeling:
testing
the
water
so.
A
G
A
One
thing:
yeah,
that's
a
great
question.
One
thing
that
we
had
considered
so
like
bpfd
has
a
has
crds
for
BPF
programs
like
ebpf
programs.
Crd,
we
have
considered
whether
something
like
that
is
needed
for
Upstream
again,
we're
not
sure
we're
kind
of
reaching
out
to
the
community
and
starting
to
see
what
people
are
saying.
If
that
was
something
that
we
needed
and
there
were
multiple
implementations
of,
then
that
might
be
one
of
the
goals
not
for
sure
thing.
Yet
it
is.
A
Security
is
kind
of
insane
for
BPF
programs
in
a
kubernetes
context.
A
Right
now,
and
so
one
of
the
goals
is
potentially
trying
to
help
with
that
work
with,
like
other
groups
like
Sig,
node
and
stuff,
like
that
and
security,
to
try
to
make
these
things
safer
for
people,
so
that
might
be
a
target
for
the
working
group
and
then
there's
a
variety
of
other
things
like
just
general
onboarding
for
people
like,
should
we
have
kubernetes
examples
somewhere
in
cases
that
would
kind
of
show
people
how
to
get
started,
doing
that,
probably
mostly
likely
after
we
solve
some
of
these
other
problems.
A
That
kind
of
thing
just
to
make
that
ecosystem
a
little
bit
easier,
because
it's
hard
right
now,
it's
a
difficult
ecosystem.
A
bunch
of
hands
went
up,
go
ahead,
glorified
sysadmin.
E
E
Okay
sounds
good
to
me:
yeah,
okay,
so
Jay
and
I
have
been
working
on,
or
at
least
I
have
been
trying
to
touch
myself
to
the
jpng,
and
especially
the
active
V6
stuff.
E
E
So
my
problem
here
is
that
my
IPS
doesn't
support
IPv6
and
there
seems
to
be
quite
a
large
problem.
So
it's
not
very
popular
right
now
and
Jen
I
discussed
that
it
might
be
a
topic
that
we
can
bring
up
at
the
SAG
Network
meetings.
E
So
in
general
the
approach
would
be
to
find
the
solution.
How
we
can
come
up
work
around
that
right
now
that
we
can
build
the
kind
image,
so
we
can
extend
it
out
of
it
and
that
whatever
we
need,
because
there's
no
connectivity
is
fine
external
with
the
problem
and
James
suggested
that
we
can,
if
you
can
think
of
a
solution,
how
we
can
do
that,
we
can
also
write
some
kind
of
a
guide
or
some
cncf,
post
or
whatever.
E
It
is
for
people
coming
into
this,
because
it
really
it
to
me
seems
a
bit
of
an
Uncharted
Territory
I
couldn't
see
a
lot
of
information
about
the
topic
and
yeah
I
just
wanted
to
bring
that
up
here.
So
maybe
we
can
work
on
that
or
at
least
I
don't
know,
move
it
forward.
Somehow
so
I
don't
know
what
you
guys
think
about
that.
So
I
would
be
glad
to
hear
your
opinion
on
that.
A
Yeah,
what
Antonio
said
in
chat,
I
kind
of
need
to
I
I
started
to
try
to
take
a
note,
I
I'm,
not
sure
I
caught
the
problem.
What
was
the
problem
so.
E
The
problem
is
that
when
I
try
to
remember
this,
so
anything
in
kind
as
a
local
development
cluster
with
IPv6
enabled
everything
inside
the
cluster
is
fine.
So
there
is
interport
connectivity.
Services
are
working.
Fine,
there
is
no
outer
connectivity,
so
I
cannot
pull
anything
from
the
internet.
I
cannot
pull
images,
so
it
might
be
an
issue
related
to
kind
where
it
might
be
the
better
place
to
rise,
but
I
just
wanted
to
bring
it
up
here.
So
maybe
somebody
has
a
workaround
the
sunset:
that's
working
for
them.
Okay,.
C
E
All
right,
okay,
okay,
so
that's
it
then
thank
you.
A
Yeah,
thank
you
so
yeah,
please
do
follow
up
there.
It'll
be
helpful,
appreciate
it
go
ahead.
Bowie.
H
A
A
Yeah
yeah,
it's
going
to
be
a
multi-sig
thing
for
sure,
but
we
kind
of
what
Tim
and
I
had
kind
of
discussed
after
Andrews
we
talked
about
in
several
meetings
back
is
that
we
might
be
able
to
just
kind
of
umbrella
it
under
us.
For
the
moment,
if
we
decide
that
we.
A
We
still
haven't
decided
that
we
need
one
to
be
fair,
we're
still
kind
of
just
reaching
out
to
the
community
and
seeing
what
people
are
doing,
what
people
need
and
where
there
might
be
work.
That
needs
to
be
done
and
people
who
want
to
do
that
work.
But
if
we
get
there,
I
was
kind
of
leaning
towards.
We
could
kind
of
Nest
split
under
a
Sig
Network
for
the
moment,
but
we
definitely
need
to
be
aware
that
this
is
not
a
network.
Only
thing.
H
A
A
Yeah
yeah,
it's
it's!
It's
just
a
it's
a
fair
question,
but
yeah
it's
it's
not
all
taking
form
just
yet
and
that's
why
we're
reaching
out
and
trying
to
find
more
people
who
are
doing
these
things
in
production
and
stuff
like
that,
so
that
we
can
help
facilitate
it's.
A
Interesting
conversations
and
if
you
want
to
check
out
the
the
meeting
notes,
it's
on
the
Sig
Network
calendar
actually
right
now,
there
were
quite
a
few
notes
from
the
last
meeting.
I'm
sure
there'll
be
more
from
the
next
meeting
that
had
a
lot
of
interesting
topics
and
questions
like,
for
instance,
if
we
would
have
a
kublet
type
thing
for
loading.
Ebpf
programs
in
the
kubernetes
cluster
was
an
unexpectedly
interesting
question
that
popped
up
yeah.
B
J
B
A
G
Yeah
I'm,
just
when
are
these
meetings
you
mentioned
they
were
on
the
same
network
calendar,
as
has
it
been
more
broadly
announced
or
discussed.
They've
been.
A
There
they've
been
kind
of
just
in
the
ebpf
channel
and
then
I've
I
think
Andrew
and
I
have
just
reached
out
to
people.
We
know
that
are
like
specifically
interested
and
pulled
them
in.
So
if
you
join
the
EBT
Channel
That's,
where
they've
been
announced
so
far
and
they're,
not
like
official
official
like
we're,
not
recording
them,
we're
kind
of
just
talking
to
people
to
get
to
Grassroots
to
see
if
there's
like
room
here
for
this
kind
of
work
within
kubernetes.
So.
J
A
A
We
have
10
minutes,
left
I
think
we're.
We
can
just
give
everybody
10
minutes
back.
Does
anybody
feel
really
strongly?
They
want
to
go
over
any
of
the
assigned
issues,
or
should
we
convene.