►
From YouTube: CNCF CNF WG Meeting - 2021-10-25
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
B
B
B
B
Okay,
if
everybody's
cool,
let's
go
ahead
and
get
started,
just
a
reminder
on
these
meetings
are
recorded.
So
if
you
ever
want
to
go
back
and
rewatch
something
you
can
and
then
additionally,
you
know
try
to
keep
our
conversations
civil
and
clean,
so
kubecon
just
passed.
I
apologize
taylor
and
I
we
took
monday
last
monday
off,
so
we
missed
some
stuff.
I
know
there
was
some
security
discussions.
I
don't
know
for
anybody
who
was
here
last
week.
C
B
Sure,
and
if
anybody
like
vineyard
live
are
just
this
is
really
just
a
chance
for
someone
to
like
speak
and
be
like.
Oh,
this
was
really
cool.
I
think
the
group
should
look
at
this
and
then
I
think
frederick
would
be
a
great
idea
to
your
suggestion
that,
once
all
the
videos
are
uploaded
and
available,
maybe
we
just
kind
of
put
like
a
little
miniature
library
together
of
things
that
we
should
like
look
into.
B
Looks
like
taylor's
got
a
cool
list
here,
so
we'll
go
back
and
look
at
those.
Maybe
you
know
we
could
like
discuss
some
of
the
things
that
came
out
in
them.
Another
was
like
the
maintainer
track.
We
had
a
couple
people.
One
thing
we
might
want
to
consider
too
is
you
know
the
maintainer
track
was,
of
course,
on
the
last
day
about
dinner
time,
so
we
did
get
a
lot
of
people
from
the
asia
pacific
region
that
showed
up
to
the
call
or
the
presentation.
B
So
one
thing
we
might
want
to
consider
too
is
obviously
we've
had
a
very
you
know,
western
europe
north
american
friendly
time.
B
We
might
want
to
consider
in
the
future
how
we
get
some
of
our
friends
in
australia,
new
zealand,
china,
korea
et
cetera,
india,
more
involved,
so
taylor's
put
that
list
up.
We
can
add
links
later
once
they
become
available,
and
if
anybody
wants
to
go
back
to
the
notes
and
add
some
sessions
that
they
think
are
awesome,
please
do
I
don't
know.
If
anybody's
got
some
topics
they
want
to
dive
into
too
that
I
kind
of
want
to
look
into.
B
I
don't
know
frederick,
if
there's
anything
from
last
week,
that
we
need
to
continue
to
double
tap
on,
and
I
see
that
randy's
on
here,
but
I
was
actually
thinking
now
that
we're
kind
of
past
most
administrative
stuff
we've
been
talking
around
best
practices.
I
do
think
working
asynchronously
will
help
us
and
we
can
start
flushing
some
stuff
out,
but
I
think
another
topic
that
would
be
really
good
to
look
into
is
randy
had
started
this
discussion
around
dealing
with
nat
and
bgp.
So
bgp
is
a
fact
of
life.
B
Obviously,
in
the
cnf
space
and
nat
is
everywhere,
so
it
might
be
something.
I
thought
it
would
be
like
a
good
discussion,
post
kubecon
to
start
like
digging
into
alongside
some
of
the
least
practic
or
at
least
least
privilege,
security,
best
practices
etc,
and
so
if
anybody
else
wants
to
potentially
add
new
topics
or
say,
let's
look
somewhere
else,
then
by
all
means.
Please
speak
up.
C
Yeah,
I'm
on
the
security
part,
I'm
I'm
going
to
put
together
some
or
I'm
going
to
do
a
little
bit
of
writing
to
discuss
the
software
bill
of
materials
and
with
this
some
of
the
stuff
that's
going
on
there
and
how
we
can
start
to
put
recommendations
towards
people
building
towards
it.
This
is
it's
still
a
very
early
space,
so
the
tools
there
are
very
are
very
immature,
but
there's
a
lot
of
work.
C
That's
going
to
that's
going
to
be
put
into
that
particular
space,
because
one
of
the
requirements
are
seeking
in
the
us
government
is
that
critical
infrastructure
also
follow
also
follow
the
guideline
or
follow
the
requirement.
I
should
say,
and
the
question
then
becomes
how
long
will
telecom
be
considered
to
be
or
service
provider
be
considered
to
be
critical
infrastructure?
C
And
if
so,
when
will
it
be
considered
so
they
may
not
give
they
may
not
initially
define
it,
but
they
may
expand
it
over
time,
so
in
short,
what
defining
for
people
or
describing
for
people
what
it
is
and
where
things
are
are
heading,
even
if
there's
nothing
concrete
that
they
can
do
right
now
because
of
the
maturity
level,
it's
still
useful
for
people
to
to
know
what's
what's
coming
down
the
pipeline,
so
I
have
some
stuff
I'm
going
to
write
on
that
and
I'll
I'll
put
it
inside
of
a
pull
request
later
on.
B
Cool-
and
I
was
looking
at
last
week's
notes,
so
yeah
the
signing
and
verification
of
signatures-
is
this
eventually
going
to
lead
in?
Like
I
know,
I've
talked
to
taylor
about
this.
We
had
some
discussions
about
air
gap
installations,
private
repositories,
etc.
This
is
actually
a
topic.
I've
been
looking
at
internally
myself
recently.
B
Is
this
notion
of
signed
images,
and
you
know
creating
trusted
repos
only
allowing
things
to
deploy
into
production
that
are
signed,
et
cetera,
which
I
feel
like
one
of
the
like
you
know
things
about
cloud
native
and,
like
you
know,
faster,
more
agile,
software
releases
is
sometimes
we
play
things
a
little
fast
and
loose,
and
the
need
to
go
fast
sometimes
outweighs
our
need
to
be
safe.
So
I'm
just
curious
too
frederick.
If
that's
going
to
be
involved
in
this,
I
know
it's
something
near
and
dear
to
my
heart.
B
Is
you
know
if
I'm
working
with
you
know
vendors,
one
two
and
three
like
how
are
we
creating
that
secure
supply
chain
between
them
in
the
microservices
and
ci
space
yeah.
C
It's
it's
part
of
it,
but
excuse
me
it
goes
a
bit
deeper
than
that,
so
it's
actually
looking
at
not
just
what's
the
signed
image
but
looks
at
the
contents
and
tries
to
work
out
what's
within
those
signed
images
and
and
does
so
recursively
throughout
throughout
the
vendors
and
part
of
the
idea.
Is
that
let's
say
that
someone
pulls
in
a
library
that
that
has
a
vulnerability
in
it
and
they
compile
it
in
statically.
C
So
your
your
images,
don't
pick
it
up,
then
you
because
it's
in
the
software
bill
of
materials,
then
you
you
still
have
visibility
into
the
fact
that
this
thing
was
pulled
into
your
system
and
ends
up
giving
you
giving
you
the
ability
to
rely
on
on
tooling.
That
has
information
from
the
source,
as
opposed
to
relying
on
image
scanners,
to
try
to
pick
it
up,
and
so
it's
part
of
it
is
trying
to
move.
C
The
bar
is
trying
to
move
the
bar
further
to
the
left
in
the
build
system,
but
the
other
part
on
it,
which
is
where
I
think
the
the
real
benefit
is.
If,
if
we
can
pull
this
off
properly
as
a
as
an
industry,
is
going
to
be
around
the
additional
tooling,
we
get
which
allows
us
to
determine
what's
in
our
infrastructure,
because
a
large
problem
that
I've
seen
on
on
major
enterprises
is
that
many
many
major
enterprises
have
no
idea
where
things
come
from
or
what's
running.
C
Somebody
leaves
the
company
the
their
server's
there
that
they're
not
sure
if
they
can
shut
them
down
or
not,
because
they
might
be
doing
something
important,
and
this
will
help
give
them
some
of
that
visibility
as
well
into
by
by
maturing
the
entire
tool
chain.
So
a
lot
of
people
will
hide
hyper
focus
on
the
s-font
itself,
which
does
provide
some
utility,
but
I
think
the
real
utility
is
going
to
be
around
the
tooling
that
that
generates
around
it.
B
B
Because,
if
not
rainey,
I
don't
know,
if
you
would,
let
me
put
you
on
the
spot
or
not,
but
I
was
wondering
if
we
could
potentially
talk
about
this
discussion.
You
started.
If
you
wouldn't
mind
you
know
potentially
giving
us
a
little
overview
and
we
could
kind
of
talk
them.
This
is
something
I
know
specifically
as
a
service
provider
is
near
and
dear
to
my
heart,
yeah.
E
Yeah,
it's
been
a
while,
as
you
can
see
february
it's
like
nine
months
ago,
not
sure
I
remember
what
triggered
it,
but
anyway,
I
think
just
there
was
some
discussion
that
reminded
me
of
some
similar
issues
back
in
the
days
from
the
sleep
and
voiceover
ip
days.
I
think
some
of
the
concept
might
be
applicable
here.
E
Basically,
it's
the
idea
of
a
network
function
running
in
the
cluster
and
the
local
ip
address
of
that
the
container
sees
or
at
its
end
of
the
ip
socket
may
not
be
the
actual
public
ip
address,
and
there
needs
to
be
a
way
for
the
network
function
to
know
what
is
the
externally
routable
ip
address,
so
it
can
advertise
it
in
something
like
a
bgp,
so
there
are
several
techniques
out
there.
I
mentioned
a
few
of
them.
E
I
don't
know
how
prevalent
they
are
these
days,
but
stun
and
turn
used
to
be
popular
like
10
years
ago,
so
something
like
that
may
be
used
as
a
best
practice
for
a
network
function
like
a
router
to
discover
its
externally
routable
ip
address
and
use
this
in
the
in
the
application
protocol.
In
this
case,
bgp.
B
Okay,
I'm
just
really
quick
reading
through
you
know.
If
anybody
else
wants
to
chime
in
I
know
ian,
and
I
have
talked
about
this
one
a
lot.
I
think
this
one
is
interesting
like
just
the
concept
of
putting
a
route
reflector
in
containers
inside
of
kubernetes.
You
know
it's
not
as
straightforward
as
you
would
think
it
would
be,
and
specifically
for
the
like
issues
that
randy
just
mentioned.
B
Everyone's
quiet
this
morning,
I
always
talk
a
lot
I
mean,
so
some
of
the
things
that
we
can
look
at
right
is
obviously
there's
some
of
the
things
here.
You've
got
the
any
other
ideas
I
know
too.
There
could
be.
This
is
always
the
dangerous
one,
but
cni
based
approaches
right,
so
I
mean
you
have
certain
cni's
that
you
have
bgp
speakers
blown
those
in
with
them
and
you
can
directly
advertise
pod
space.
So
then,
theoretically,
you
can
go
and
post
your
services
in
a
pod
that
has
an
ip
address.
B
That
is
advertised
and
therefore
is
the
source
address
versus
netting
through
the
host
address.
I
don't
know
if
anybody
else
has
got
any
thoughts
on
this.
I'm
also
curious
too,
like
I've
done
limited
stuff
with
this,
but
if
anybody's
got
an
experience
like
you
know
the
notion
of
putting
lots
and
lots
of
these,
you
know
endpoints
out
there
in
bgp
best
practices
around
where
you
set
your
aggregates
et
cetera,
so
that
you
don't
constantly
have
a
bunch
of
entries
being
added
and
withdrawn.
B
You
know,
as
pods
spin
themselves
up
and
spin
themselves
down.
I
think,
there's
probably
even
just
in
a
generic
context
as
more
and
more
people
look
at
peering
with
their
underlay,
with
both
calco
or
psyllium.
We
could
put
out
some
best
practices
or
work
with
the
network
plumbing
group,
because
I
think
this
would
probably
be
within
their
space
as
well,
but
like
how
do
you
sit
there
and
properly?
You
know.
B
I
don't
know
if
anybody's
got
any
thoughts
on
that,
but
it's
something
we're
like
I've,
seen
where
we've
done
like
limited
context
and
stuff,
but
like
the
way
that
we
handle
our
route
tables
in
some
cases
are
quite
massive
and
having
tons
and
tons
and
pods
come
up
and
come
down
is
not
something
we
want.
So
we,
you
know
basically
set
like
we
use
ebgp
a
lot
more
than
ibgp
for
instances
like
this
to
make
sure
that
we're
like
protecting
the
bigger
route
tables.
F
This
is
a
bit
of
a
connection,
storm
issue.
Basically,
you
know
you
either
do
it
in
the
kubernetes
control
plane
or
you
try
to
do
it
in
the
networking
control
plane,
like
you're
handling
lots
of
equipment
out
there,
I'm
guessing
since
it
is
services
they're
going
to
be
spun
up
together
with
you
know,
the
containers.
D
I'm
in
line
with
the
approach
I
mean
with
the
four
to
three
options
and
the
one
that
I've
seen
use
the
most
basically
is
it's
not
necessarily
advertising
this
pods
base,
but
rather
to
bring
a
specific
interface
to
to
the
pod
being
that
route,
reflector
and
and
leverage
you
know
like
was
mentioned.
You
know,
cnn,
based
approach.
You
could
have
multiple
interfaces
and
attach
a
specific
part.
D
F
Yeah
one
thing
I
just
kind
of
wanted
to
mention
on
that
topic,
since
you
know
we
run
into
some
of
these
issues
when
we're
talking
about
kubernetes
interfaces,
of
course,
that
you
know
everyone
now
seems
to
be
talking
talking
smart
mix
in
one
way
or
another.
So
even
if
you're,
using
cni
and
psyllium
and
whatever
happens,
the
offload
of
larger
larger
pieces
to
the
these
kind
of
smart
things
coming
in
will
probably
be
the
next
step
for
a
lot
of
mentality.
Use
cases,
for
you
know,
cost
reasons
mainly.
B
We're
trying
to
like
catch
up
with
all
these
notes,
the
so
one
I
think
we're
just
like
spitballing
here
and
coming
out
with
discussions
right
so
for
one.
The
smartnick
thing
is
a
completely
tangential
thing.
I
would
say
that
that
side
like
I
was
just
mentioning
cni's,
because
this
specific
topic
right
here
is
around
nap
right
and
so
really
just
bgp.
We
should
probably
start
a
discussion
around
just
like
bgp
best
practices,
which
would,
I
think,
fall
into
like
the
security
or
least
privileges
kind
of
like
top
level
domain.
B
Where
then,
you
would
have
lots
and
lots
of
subdomains
that
we
could
tease
out
so
like
a
cni
is
just
one
way
to
do
it
right,
because
you
can
basically
get
away
from
thating
by
directly
advertising
pod
space,
but
there's
definitely
some
pitfalls
into
that,
especially
around
some
of
the
discussions
that
were
just
managed
on
you
know
who
is
managing
the
control
plane
at
that
point?
Are
we
having
the
cni
talk
to
something?
Are
we
going
to
have
some
kind
of
plug-in?
B
You
know
between
clouds
third-party
controllers,
once
we
start
mapping
this
into
our
underlay
right,
like,
like,
I
said,
we've
done
limited
stuff
where,
like
we'll
peer
like
specific
clusters,
like
a
limited
set
of
pod
space,
so
we
can,
you
know,
advertise
like
cluster
ips,
et
cetera,
but
like
doing
this
at
scale
like
starting
to
like
really
like
populate
this
into,
like
you
know
your
global
routing
tables,
to
where
I
want
service
x
to
just
be
like
finding
findable
within
my
network
and
stuff,
I
mean
there's
much
much
bigger,
implement
implications.
B
B
What
does
that
look
like
if
something
is
constantly
churning-
and
I
mean
it's
doable
right-
we
see
this
with,
like
you
know,
vxlan
and
edp,
and
implementations
and
routing
by
mac,
address,
etc,
but,
like
I
feel
like,
there's,
definitely
like
best
practices
that
are
super
relevant
to
the
cnf
space,
especially
when
we
start
talking
about
putting.
I
mean
I
can
just
you
know
we're
getting
like
vendors
coming
to
us
with.
You
know:
cloud-native
quote-unquote
cloud-native,
like
bngs
broadband
routers,
you
know.
B
Obviously
the
packet
core
is
the
800-pound
gorilla
that
everybody
wants
to
solve,
especially
the
user
plane
side
of
it.
So
I
would
say
you
know:
smartnix
would
be
one
path
where
we
might
do
this,
and
then
we
let
the
smartnic
handle
this,
and
we
pass
that
through
into
a
pod.
There
is
the
concept
of
I'm
going
to
put
something
that
needs
to
understand
and
speak
bgp
within
the
pod.
So
then,
how
do
I
handle
the
nat
issue,
which
is
what
randy
has
up
here?
A
A
A
That
way,
and
I
there's
probably
other
areas
that
that
could
expand
on
like
being
able
to
use
the
smart,
necks
and
anything
else
that
comes
out
so
an
ideal
situation.
What
would
that
look
like
and
saying
here
is
how
we
would
we?
We
would
love
to
be
able
to
describe
our
services
this
way,
the
bgp
and
it
here's
how
it
would
work,
and
some
of
it
may
not
be
there.
But
if
we
could
say
you
know,
8
out
of
10
or
6
out
of
10
pieces
are
ready,
but
these
four
critical
ones
aren't.
A
A
Some
way
of
directly
attaching
that
pod
to
a
smart
neck,
that's
off!
You
know
where
you're
offloading
stuff,
then
you're
gonna
end
up
with
some
type
of
pgp
bgp.
That's
broken
down
further
into
components
where
you're
needing
some
service
level.
I
don't
know
if
that
means
an
operator
or
if
there's
something
else,
that's
more
generic!
That's
expanding
on
the
current
capabilities
for
having
ips
assigned
to
services,
which
you
can
do,
but
it
doesn't
seem
like
that's.
B
Well,
I
I
want
us
to
like
keep
the
sorry.
I
was
talking
to
mute
trying
to
answer
you.
Taylor,
like
there's.
Definitely
some
like
lines
of
response,
but
when
we
talk
about
attaching
an
interface
right
like
if
we
pass
a
smart
nick
into
a
pod,
then
we're
giving
it
the
physical
interface
versus
you
know
a
tap
interface
et
cetera,
but,
like
I
think,
what
we're
really
discussing
here
and
please
correct
me
if
I'm
like
not
thinking
about
this
right-
is
really
the
provisioning
of
said
interfaces.
B
The
provisioning
of
said
services
like
what
are
the
lines
of
demarcation
between
you
know,
potentially
kate's
in
a
generic
cni
like
type
of
exposure,
something
where
we're
actually
passing
forward.
Sorry
passing
through
some
type
of
physical
interface
to
a
pod.
B
F
B
Right
because,
at
the
end
of
the
day
right,
we
have
an
interface
to
a
pod
that,
like
exposes
it
to
the
rest
of
the
network,
right
like
that,
doesn't
go
away.
There's
just
a
lot
of
ugly
ways
to
do
that
right
now
and
exploring
the
best
way
bgp,
because
it's
very
finicky
happens
to
have
some
strong
opinions
on
how
you
should
do
that.
So
then
that's
when
we
have
to
start
figuring
out
like
do
we
just
put
smartnix
everywhere
and
use
node
labels,
and
just
say
you
know
this
is
a
nick.
B
That's
going
to
make
this
a
lot
easier.
It's
going
to
handle
all
of
the
bgp.
You
know
negotiations
here
on
this
discrete
chip
on
the
nick
and
then
it's
going
to
have
an
interface
that
passes
through
directly
to
the
pod
and
all
the
pod
does.
Is
you
know
offload
traffic
to
it,
or
I
mean
I
feel
like
there's
not
going
to
be.
One
like
winner
takes
all
to
you
right
because
there's
going
to
be
cnf
developers
who
are
going
to
develop
software,
that
does
packet
processing
in
pods.
B
That
is
ultimately
going
to
need
to
be
able
to
and
talk
to
the
rest
of
the
network,
which
I
think,
that's
probably
one
of
the
like
things
that
have
been
like
hotly
debated
since
multis
and
everybody
first
showed
up
on
the
scene
right.
But.
F
B
I
think
one
convenient
thing
about
this
use
case
too
versus
some
of
the
other
ones
is,
since
this
is
a
control
plane
exercise
two.
We
don't
have
to
get
super
far
into
the
weeds,
around
data,
plane,
acceleration,
etc.
Right
like
this
is
specifically
around
understanding
how
to
basically
advertise
routes,
withdrawal
routes
and
do
this
within
a
potentially
native
and
containerized
world.
B
B
I
think
if
no
one
else
has
any
topics
they
specifically
want
to
discuss
right
now,
I'm
going
to
start
putting
in
some
pr's
I've
been
kind
of
like
slammed
with
work
and
getting
past
the
conferences,
but
have
some
things
to
discuss
and
I
know
frederick
said
he's
going
to
do
a
write-up,
but
is
there
any
other
topics
that
anybody
would
like
to
add
to
today's
discussion?.
B
Okay,
then,
we'll
give
everybody
25
minutes
back,
oops
so
stuff
in
chat,
there's
just
a
meeting.
That's
excellent!
Okay,
we'll
chat
with
everybody
next
monday,
then.