►
From YouTube: CNCF CNF WG Meeting - 2021-01-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
We
get
started
so
thanks
everybody
for
joining
today,
if
you
got
lost
on
your
way
here.
This
is
the
cnf
cloud
native
network
function,
working
group
weekly
meeting,
like
mondays,
so
before
we
get
started
and
jump
in.
Does
anybody
have
anything
they'd
like
to
add
to
the
agenda.
A
Okay
cool,
so
I
guess
we'll
take
taylor's
suggestion
and
we'll
start
not
with
34,
which
is
at
the
top,
but
29
here,
and
so
this
is
a
short
one
from
jeffrey
salins
is.
Is
he
on
the
call
today.
B
He's
so
he's
not,
there
hasn't
been
any
pushback
on
this
one,
though
all
right,
nothing,
unresolved.
B
I
I
think
that
only
one
was
like
me
suggesting
that
we
add
something
else,
so
I
I'll
take
that
back,
because
it's.
A
Okay,
so
basically
jeffrey's
suggestion
here
is
that
we
also
add
a
workload
context
to
the
definition
of
like
a
best
practice,
and
the
idea
is
that
it
should
be
able
to
define
which
type
of
components
it
actually
applies
to,
because
obviously
there's
different
components
and
not
everything
applies
to
every
single
type
of
workload.
A
And
if
we
look
at
kind
of
the
conversation
in
here,
we
can
see
like
obviously
there's
the
infrastructure
that
orchestrating
provisioning
style,
workloads
and
then
there's
also
the
oss
bss.
And
so
this
addition
to
the
proposal
process
would
allow
people
to
specify
the
workload
contacts
that
it
actually
applies
to.
A
So
is
there
any
conversation
around
this
or
would
people
are
people?
Okay,
with
merging
this.
C
We
have
anything
that
applies
to
the
second
part
of
that
comment
up
there
of
as
far
as
a
cnf
being
a
single
container
or
a
suite
of
containers,.
C
B
The
I
think
we
have
it
in
different
places,
but
not
nowhere
concrete
here.
B
B
And
I
I
don't
think
we
have
to
say
it
the
exact
complexity,
but
there's
we
do
have
context
in
other
places
and
that
could
be
pulled
together
and
I
think
that's
a
giant
slack
conversation
from
about
a
month.
I
don't
know
I
guess
that
was
maybe
before
the
holidays.
It's
probably
the
most
con
content
about.
It
would.
D
It
be
fair
to
say
that
it's
a
a
collection
of
containers,
I
mean,
if
you
can
meet
all
the
conformance
rules
with
a
single
container.
Your
job
is
done,
but
if
you
can't
reach
the
conformance
rules,
then
it's
not
that
you
can't
have
a
signal
container,
because
one
container
is
bad.
It's
not
particularly
if
you
can
meet
the
conformance
rules.
It's
just
that.
D
You
know.
If
you
can't
meet
the
conformance
rules,
it's
not
conformant.
It
seems
like
an
odd
thing
to
specify
it's
a
design
choice,
not
a
requirements,
choice.
C
E
Do
we
want
to
consider
defining
the
the
type
of
workloads
I.e,
something
like
control,
plane,
data,
plane
management
plane,
or
is
it
basically
like
a
free-for-all
field.
B
Right
now,
it's
more
of
free-for-all
as
far
as
what
it
where
it
applies,
and
I
would
say
that
context
of
if
you
have
a
networking
application
and
it's
focused
on
control
plane,
then
putting
that
in
there
would
be
good
or
is
it
user
data
plane
and
you're
starting
to
deal
with
potentially
different
network
types
than
the
default.
Then
you'd.
B
A
Yeah,
I
I
think,
that's
actually
probably
maybe
a
good
idea.
Maybe
it's
we
could
like
merge
this
as
it
is
and
then
create
like
a
separate
issue,
basically
where
we
can
discuss
like
what
should
be
in
that
drop
down.
F
B
B
A
D
So
I
think
we
can
do
that
and
obviously
it's
not
actually
going
to
be
a
drop
down,
because
this
is
a
template.
We
don't
it's
not,
but
that's
you
know
the
point
is
it's
a
multiple
choice,
question
and
that
would
be
where
the
choices
live.
D
No,
I
think
it's
quite
good
that
we
need
this
context,
because
it's
completely
fair
that
this
doesn't
apply
universally
to
or
at
least
it
might
apply
more
to
some
things
than
others.
It
should
be
irrelevant
to
others.
It
shouldn't
be
actively
conflicting,
but
that's
we'll
get
there
when
we
get
there
and
we
have
some
proposals.
I
think.
A
And
thanks
for,
however,
was
creating
notes
in
the
sheet
in
the
sheet,
so
anonymous
shrew
and
anonymous
chinchilla.
Thank
you.
So
thanks
for
that
now
for
poll
34.
So
this
is
the
pull
request
from
ravi,
basically
creating
the
initial
framework
or,
like,
let's
say,
like
the
table
of
contents.
For
this
now
this
one's
been
out
for
a
while.
We
also
had
an
extra
week
last
week
since
we
didn't
have
a
meeting
to
like
go
over
this.
A
I
just
wanted
to
check
one
last
time
if
anybody
had
any
comments
or
like
issues
that
they'd
like
to
bring
up
before
we
merge
this,
and
it's
essentially
like
a
table
of
contents.
A
Okay,
hearing
no
more
conversations
or
oppositions,
I
think
it's
time
to
merge
our
table
of
contents.
Obviously
like
everything.
If
you
want
to
change
something,
please
feel
free
to
make
a
pull
request
after
it's
merged
right.
G
Oh
right
before
you
do
that
there
is
this
part
in
here
about
the
stateless.
Is
that
conversation
worked
its
way
out.
A
I
think
it's,
this
is
one
of
the
I
mean
we
can
talk
about
it
right
now.
I
know
this
has
always
been
kind
of
like
an
interesting.
A
Like
point
in
telcos,
because
there
are
some
things
like
especially
around
charging
functions,
I
I
think
oliver
you're
on
the
call
right.
F
I'm
here
I'm
here,
bro
yeah,
I
I
mean
I
I
I'm
not
sure
how
to
to
to
classify
the
conversation.
I
I
don't
think
I
think
we
could
get
into
a
very
long
conversation
about
it
now,
so
I'm
not
proposing
we
have
it
now,
but
I
think
it
you
know
at
least
tom,
and
I
did
talk
a
little
bit.
We
weren't
just
necessarily
in
disagreement.
I
think
it's
a
little
bit
about
putting
some
more
wording
around
it.
F
When
we
just
say
stateless,
I
think
we
need
to
also
need
to
at
least
address
the
fact
that
there
are
cases
where
state
is
being
managed,
and
I
think
you
know
just
to
to
not
just
say
yeah,
it's
being
managed
by
something.
I
think
there
are
cases,
especially
with
intel
telecom
within
networking,
where
you
know
we
have
some
very
specific.
If
we
look
at
5g
there's
some.
If
you've
read
some
of
these
comments
here,
there
are
things
that
there
are
some
network
functions
that
are
responsible
for
maintaining
states.
F
D
And
I
think
you
have
to
be
careful
with
that
word,
stateless
in
the
sense
that
you
know
I
can
run
a
database
in
kubernetes
and
it
isn't
stateless
for
obvious
reasons.
It's
more
a
question
of
tolerant
to
failures
like,
for
instance,
losing
a
pod
losing
a
cluster
node
is
better
or
easier
to
do.
If
there's,
no
persistent
state,
that's
lost
when
that
pod
goes
down.
So
it's
not
that
kubernetes
applications
are
stateless.
D
That's
simply
not
true
again
can't
have
databases
if
that
were
true
and
the
kubernetes
is
built
on
a
database.
So
could
message
itself
is
stateful,
it's
more
a
matter
of
how
you
get
better
performance,
better
behavior.
If
you
can
limit
local
state
local
ephemeral
state
in
your
containers,.
H
And
this
is
something
we're
trying
to
be
a
little
bit
careful
with
as
well,
because
this
is
something
that
we've
spent
a
lot
of
time
debating
and
getting
nowhere
in
the
in
the
cncf
telecom
user
group
in
other
forums
and
the
the
problem
here
is
when
you're
trying
to
design
something
to
be
cube
native
and
to
be
more
exact
if
you're
trying
to
aim
more
towards
getting
a
total
factor
style.
H
So
when
we
start
looking
at
that,
that
doesn't
mean
that
there's
no
state,
but
what
we
try
to
do.
Is
we
try
to
separate
out
things
that
that
perform
certain
types
of
work
from
the
state
itself.
So
a
database
is
still
a
database,
but
the
thing
that
does
the
heavy
lifting
generally.
What
we
try
to
do
is
separate
that
out
from
the
database
itself,
so
that
if
we
lose
it
or
we
need
to
upgrade
it,
we
don't
we
don't
lose
that
state.
H
Instead,
it's
relying
on
this
on
this
data
on
this
database
or
someone
to
actually
hold
that
particular
that
particular
state.
So
when
we
say
that
when
we
say
that
there's
no,
when
we're
talking
about
something,
that's
stateless,
we
don't
necessarily
mean
that
first,
it
doesn't
say
anything
about
ephemeral,
state.
It
means
per
specifically
about
persistent
state.
H
The
second
one
is:
when
we
talk
about.
When
we
talk
about
stateless,
it's
not
a
hard.
There
is
no
state.
There
is
still
state
that
lives
somewhere.
It's
just
a
question
of
where
does
it
live
and
how
do
we
partition
it
in
such
a
way
that
that
we
can
make
the
system
more
robust,
but
it's
not
a
hard
rule
either.
If
you
have
a
system
that
just
absolutely
requires
that
state
to
be
present
because
of
a
performance
reason
or
so
or
so
on.
You
still
have
a
an
exit.
H
B
These
are
best
practices,
so
it's
what
is
the
trade-off
and
you're
we're?
We
want
to
communicate
what
the
value
is
on
these
with
the
caveats
and
then
you're
going
to
make
the
choice.
The
the
easy
thing
for
stateless
is
to
think
handle
your
data
in
a
cloud-native
way.
That's
all.
That
means
it's
a
shorthand
for
saying
that.
Try
to
handle
your
data
in
a
cloud-native
way,
not
you
must
not
use
state.
D
D
C
D
C
Right
but
there's
things
that
so
we
this
is
part
of
the
conversation
that
we
had
in
the
chat
room
right.
There
are
things
that,
if
you
do
x,
you
are
not
cloud
native.
Those
are
fairly,
I
think,
much
easier
to
define
than
what
makes
you
cloud
native,
at
least
that's
the
conversation
we
had
so
the
question
that
becomes
just
because
something's
a
best
practice,
so
in
rfps,
traditionally,
you'll
have
things
that
are,
must
and
things
that
you
know
are
are
optional.
C
D
E
C
E
Maybe
we
just
need
to
define
status
a
little
more
precisely
because
one
can
argue
that
tcp
state
machine
is
very
stable
and
we
know
that
quite
a
few
workloads
are
going
to
have
to
terminate
tcp
sessions
on
them.
So
we
may
need
to
consider
that
for
the
telco
use
use
case,
we
need
to
define
what
do
we
mean?
E
B
F
B
A
table
of
contents
to
say
later
at
some
point:
if
someone
wants
to
talk
about
best
practices
for
how
you
handle
state,
it
would
go
under
this
section
and
then
the
the
way
that
the
proposal
set
up
has
all
these
things
like
caveats
and
problems
with,
if
there's
a
suggestion,
but
this
this
pull
request
that
we're
looking
at
is
not
defining
that
you
must
follow
it
stateful
practices
in
a
certain
way.
It's
just
saying:
that's
a
section.
H
Yeah
this
is
this
is
a
good.
This
is
a
good
example
that
we
do
have
something
that's
an
analogous,
though
so
when
like
talking
about
state
and
connections
and
tcp
sessions
when
or
or
or
flows,
and
so
on.
So
when
you
look
at
a
microservice,
very
likely,
it's
taking
in
a
tcp
connection,
if
that
tcp
connection
were
to
fail
in
the
microservice,
let's
say
it's
a
tls
connection.
H
You
lose
that
connection,
and
so
that
that's
what
I
was
saying
it's
not
about
the
ephemeral
state,
yeah
focus
specifically
on
on
persistent
state
like
when.
If,
if
I'm
running
like
an
sdn
database,
then
that
state
has
to
live
somewhere
and
if
I
lose
it,
then
it's
catastrophic,
but
if
I
lose
a
tcp
connection,
it
goes
off
and
tries
to
reconnect
it's
something.
H
That's
that's
ephemeral
and
so
do
try
to
to
keep
the
two
the
two
separate
when
we
when
we
talk
about
this-
and
we
should
explicitly
call
this
out
like-
and
these
are-
these
are
patterns
that
we
see
in
in
even
enterprise
applications
that
that
it's
not
it's.
It's
not
a
hard,
a
hard
rule
in
that
specific
way,
but
instead
there's
a
there's
a
balance
of
struck
and
the
the
push
is
to
get
that
persistent
state
to
to
live
somewhere
else.
Not
not
in
the
thing
that's
doing
a
heavy
lifting.
A
Yeah,
so
I'm
going
to
pause
the
conversation
here.
I
think
these
are
all
great
conversations,
but
we
kind
of
have
three
separate
threads
going
on
here.
One
is
the
table
of
contents.
The
second
one
is
state
and
third
one's
about
how
we
should
use
best
practices,
and
I
think
I
think,
they're
all
like
super
good
conversations.
So
to
get
this
pull
request
merge.
I
think
we
just
need
to
focus
on
like
are
we
okay
with
this
table
of
contents,
and
then
I
think
the
two
other
discussions
around?
How
do
we?
A
What
does
stateless
mean
and
how
do
we
use
it-
is
another
great
discussion,
but
should
be
in
a
separate
thread
to
kind
of
like
separate
them
out
and
the
other
one
about
how
we
should
use
best
practices
as
another
discussion,
but
that
should
be
in
a
separate
thought
just
that
we
can
kind
of
segment
things
and
we're
not
kind
of
having
all
of
our
conversations
in
one
things.
If
that
makes
sense,.
G
So
as
a
suggestion,
could
you
just
change
the
word
from
stateless
to
state
yeah
yeah?
It
might
just
that
would
go
far
because
then
you
could
talk
about
it
in
the
negative
and
the
positive.
I
agree.
H
I
D
B
Click
edit
on
your
comment
and
then
when
you're
in
the
edit,
it's
just
to
the
right
of
preview.
So
you
have
right
tab,
preview,
tab
and
then
this
little
plus
minus
that.
D
D
This
is
one
again
I'll
take
offline
after
the
meeting,
but
just
to
ask
the
question:
was
there
anything
about
testability
in
the
framework
for
a
given
best
practice?
Yes,
there.
A
A
A
A
A
Great
and
then
so
after
the
meeting
also
create
discussions
around
like
handling
state
net.
Now
that
that's
a
section
and
also
how
to
use
best
practices,
because
I
think
those
are
both
things
that
we
need
to
address
and
provide
guidance
on
great.
So
the
next
thing
is
around
the
user
stories,
and
I
know
ian
you
brought
up
this
on
the
last
call.
D
I
did
and
in
actual
fact
offline
I
think
taylor
has
a
document.
That's
that's
part
of
the
way
there
as
well,
and
I've
been
writing
something.
That's
currently
still
on
my
laptop
that
for
this,
but
this
might
play
back
to
what
we
were
talking
about
in
as
regards
control
and
data
plane
cnfs.
D
One
of
the
things
that's
going
to
make
a
difference
to
how
to
run
a
cnf
is
that
it
runs
in
different
circumstances
than
some
apps.
So,
for
instance,
if
I'm
running
in
aws
as
an
example,
then
there
is
if
I
want
to
basically
make
my
cluster
10
times
bigger
for
30
seconds.
While
I
do
an
upgrade,
then
that's
a
possibility,
but
for
most
cnf
circumstances
that
isn't
likely
to
be
a
possibility.
So
I
think
some
of
these,
whether
you
call
them
user
stories
or
how
you
want
to
phrase
it.
D
D
Yeah,
in
the
sense
that
I
think
you
can
reasonably
assume
that
hardware
acceleration
is
available
which,
again,
if
you
were
to
look
at
a
public
cloud
and
you
wanted
an
intel
m3000
card,
then
you
know
you
ain't
getting
it
out.
Look
so
you
know
expecting
that
hardware
acceleration
is
present
and
enabling
it
in
the
platform
and
having
a
way
to
consume
it
in
the
cnf
and
the
best
practice
for
that
does
make
sense.
D
C
D
Yeah-
and
I
I
I'm
thinking
in
terms
of
of
building
the
house
of
cards
again
so
the
foundation
is
that
there
is
a
reason
that
you're
going
to
want
to
expose
this,
which
is
it's
going
to
be
present
in
some
circumstances,
and
some
cnfs
are
absolutely
going
to
require
it
and
then
a
level
which
is
this
is
how
you
get
it
from
a
cnf
and
then
a
best
practice,
which
is
this
is
the
only
way
you
get
it
from
a
cnf
hard
luck.
If
you
want
to
try
a
different
way.
D
This
is
good
enough
for
you
and
breaking
that
rule
would
be.
D
That's
fine,
I've
been
my
last
week
was
terrible,
so
I
didn't
really
get
much
chance
to
do
this
and
I
know
I'm
slacking
so
I'll
I'll.
Take
it
on.
G
A
B
I've
invited
you
and
I'll
it
may
have
expired,
though
so
I'll
go.
Add
you
again
and
that's.
I
D
A
Get
you
assigned
to
it
once
you
join
the
repo
and
then
kind
of
related
to
that.
There's
two
discussions
going
on
right
now
that
I
just
want
to
kind
of
highlight
for
people
one
is
around
like
defining
the
actors,
and
so
there
is
like
or
the
audiences
there's
like
quite
a
bit
of
stuff
in
here
and
also
I
know
book
made
diagram.
A
I
think
it's
in
the
slack
channel
he's
not
on
it
seems
like
he
dropped
off
the
call,
but
it's
in
the
slack
channel.
So
if
anybody
wants
to
like
work
on
the
actors
audiences,
this,
I
think,
is
also
somewhat
ready
to
go
taylor.
Do
you
want
to
say
anything
on
the
networking
use
cases.
B
Sure
so
this
is
related
to
the
discussion
that
we
were
having.
I
guess
it
was
two
weeks
ago,
the
last
one
we
already
have
a.
F
B
I
added
some
that
different
people
have
put
in
like
ian's
mentioned
something
around
bgb
speakers
and
frederick
talked
about
a
inline
up
in
the
wall
firewall
and
pointing
one
thing
out.
I
put
networking
use
case
and
not
specific
to
telco
use
cases
since
from
a
standpoint
of
the
applications.
There
are
many
of
them
and
maybe
even
the
majority.
F
B
B
A
A
This
is
another
one
that
someone
started
around.
How
do
we
manage
configuration
changes?
What's
the
cloud-native
way
of
managing
it?
So
if
you're
interested
in
this
discussion
feel
free
to
jump
in
here.
D
I
haven't
opened
it
yet,
but
I
think
it
would
also
be
worth
having
a
discussion
on
packaging,
because
internally,
one
of
the
conversations
we
had
is
configuration
is
a
fine
example.
If
you
say
you
will
use
netconf,
then
50
of
the
world
will
hate
you.
If
you
say
you
will
use
rest,
the
other
50
will
hate
you.
So
you
can't
win
on
that
and
somebody
will
come
up
with
a
different
way
of
doing
this.
D
So
when
it
comes
to
packaging,
there's
a
couple
of
things
there
one
is
that
obviously
all
bits,
your
cnf.
Somehow
you
want
to
bundle
up
and
say
this
is
how
you
use
it.
This
is
how
you
deliver
it
and
so
on.
So
that's
one
part,
but
another
part
is
you
know
if
you're
allowed
to
describe
your
configuration
interface
you're,
not
necessarily
ruling
out
that
somebody
decides
to
make
their
newest
cnf
with
snmp,
because
somehow
they
think
it's
a
best
practice,
and
everybody
should
do
this
in
the
future.
D
D
I
see
packaging
is
another
one.
I
just
think
there
are
overlaps
between
the
two,
but
so
I'll
open
a
packaging
discussion.
When
you
give
me
the
power
and
then
we
will
talk
about
both
together.
B
You're
not
able
to
I
didn't
catch
that
earlier,
so
you
can't
just
click
and
start
a
new
discussion
right
now.
D
B
So,
just
to
make
it
clear
for
everybody
on
the
call.
If,
if
you
have
a
topic
that
you
want
to
discuss,
then
please
use
the
discussion
button
and
just
add
it
besides.
Of
course,
anything
in
this
meeting
there's
a
just
like
a
ticket
or
a
pull
request.
You
can
go
in
and
click
the
new
discussion
button
at
the
top
and
and
add
something
and
they
have
it.
Labeled.
F
B
B
A
Also,
if
you
missed
it
in
the
chat,
thanks
tell
for
posting
it
shameless
plug
for
some
of
my
recent
work
on
cloudnative.com
for
us
com
management,
many
link
to
his
github
in
there.
So
if
you
want
to
check
that
out
too,
the
links
in
the
chat.
A
Okay,
is
there
anything
that
anyone
else
wants
to
discuss
today,
or
is
there
any
of
the
discussions
that
people
want
to
dive
into
deeper
right.
A
A
Okay,
hearing
nothing,
it
seems
like
now
that
we've
got
the
table
of
contents
pretty
much
merged
where
we
now
that
we
have
the
table
of
contents
merged,
and
the
proposal
like
template
merged
too
it'd
be
great
to
have
some
people
start
proposing
best
practices
so
that
we
can
start
sparking
the
discussion
around.
What
really
is
a
cloud
native
best
practice
and
like
how
we
can
move
forward?
A
There's
also,
I
think
some
great
discussions
here
and
great
jumping
off
points
that
we
can
have
especially
around
state
and
how
people
can
use
these
best
practices.
The
last
thing
for
today
is.
B
B
And
you
want
to
talk
about
it
and
figure
out
the
best
practices.
Then
please
just
go
and
start
that
way.
So
if,
if
you
don't
have
a
best
practice
suggest
yet,
but
you
want
to
find
that
one
for
a
use
case
or
the
networking
app.
Then
please
add
to
those
discussions
and
then
we
can
say
I'd
like
to
dig
into
it.
So
the
we'll
that
bump
in
a
wall
firewall
is
probably
one
that
we
can
start
breaking
down
and
talk
about.
B
So
you
can
come
from
any
any
different
way
and
then
the
other
thing
is
right.
Now
our
focus
is
on
to
get
it
more
concrete,
we're
saying
cube
native.
So
what
are
the
kubernetes
native
best
practice
around
creating
a
inline
firewall,
so
not
in
general
for
any
different
platform
or
anything
else,
so
that
we
can
have
a
very
focused
discussion?
We
can
expand
from
that
later.
B
So,
if
you
have
an
application
or
a
use
case
then
bring
those
forward
and
we
can
talk
about
it
for
best
practices.
If
you
have
a
kubernetes
best
practice
that
you've
been
seeing,
and
you
want
to
see
how
it
can
be
applied
to
networking
or
telcom
in
general,
then
you
can
bring
that
forward
either
direction.
A
Cool
thanks,
taylor,
yeah
and
the
last
thing
for
today
so
taylor
and
I
help
kind
of
get
this
off
the
ground
and
what
we're
looking
for
right
now
is
people
to
really
lead
the
charge
forward
on
this
working
group
and
we've
had
a
few
people
express
interest
in
becoming
chairs
of
working
group.
A
If
you're
interested
in
becoming
one
of
the
working
group
chairs,
please
feel
free
to
to
reach
out
to
me
and
we
hope
to
have
them
later
this
month
too,
and
then
those
people
it'll
be
community
blood
initiative
more
than
just
taylor,
and
I
sells
taylor
and
myself
and
we'll
also
be
posting
it
to
the
mailing
list.
A
A
Yeah,
that's
all
I
have
for
today.
Thanks
everybody
for
joining
and
for
the
lively
conversation
we
thought
it
was
great
and
looking
forward
to
you
next
week.