►
From YouTube: CNF WG Meeting 2021-09-20
Description
CNF WG Meeting 2021-09-20
A
A
A
B
A
A
A
A
A
A
A
A
D
D
A
B
A
A
C
B
B
Maybe
just
put
some
placeholder
discussions
around
some
of
the
best
practices
that
we
think
we
could
potentially
start
exploring
same
thing
with,
like
least
privilege.
I
think
that
there
was
multiple
potential
best
practices
or,
additionally,
we
could
talk
about
use
cases
that
would
map
to
least
privilege.
B
I
can
tell
you
onboarding.
Cns
is
an
area
where
obviously
least
privilege
is
important
right
as
I'm
bringing
things
into
my
system,
ensuring
that
they
have
the
appropriate
amount
that
or
the
life
cycle
management
one
that
look
put
up.
So
if
I'm
on
boarding
a
cnf
into
my
cloud
infrastructure,
you
know
how
am
I
doing
that
safely?
B
How
do
I
establish
trust
between
me
and
cnf
providers
so
that
you
know
hey?
My
platform
is
something
that
can
be
trusted,
but
then,
additionally,
within
a
heterogeneous
environment
of
cns,
how
do
I
ensure
that
the
cns
are
trusted,
etc?
So
I
know
this
privilege
we
had
talked
about.
We
didn't
have
a
defining
use
case
driving
it
just
yet,
but
I
would
say
this
would
likely
be
one
of
them.
A
B
Yeah,
actually
that
brings
up
a
good
topic,
though,
while
we
have
everybody
here,
I
know
that
people
get
like
a
little
bit
exhausted
with
the
bogged
down.
Can
we
go
over
some
of
these
pull
requests
and
just
want
to
point
out
that
as
long
as
there's
five
check
marks
on
the
reviewer
side,
there
it's
technically,
according
to
our
rules,
you
know
allowed
to
be
merged,
so
just
out
of
band.
You
know
we
don't
have
to
wait
till
these
calls
and
I
need
to
go
back
in
and
approve.
B
Sometimes
it's
like
a
little
annoying.
If
you
approve
it
and
then
there's
an
update
made
and
you
have
to
reapprove
it,
but
to
avoid
like
some
of
the
fatigue
we
can,
you
know,
have
this
call
more
focused
on
brainstorming,
new
use
cases,
best
practices
etc.
If
you
know,
people
asynchronously
between
mondays,
just
go
in
and
drop
their
approvals,
because
if
it's
got
the
five,
then
that's
the
magic
number.
B
A
I
I
know
at
least
just
glancing
at
who's
on
right
now,
there's
at
least
a
good
number
of
the
folks
who've
seen
this
one,
because
this
has
been
around
for
a
while
since
book
at
dt
put
it
in
and
made
updates
based
on
requests
that
came
in
like
from
victor
and
other
folks.
Can
we
get
some
plus
ones
on
this
come
in
and
to
the
I'll
drop
it
into
the
zoom
chat.
A
A
A
A
A
A
E
E
A
A
A
A
So
there's
some
thoughts
in
here.
As
far
as
the
platform
is
already
gonna,
be
there.
This
csp
is
already
going
to
have
one
it's
going
to
have
kubernetes
based
on
kubernetes
at
the
core,
wouldn't
be
a
special
fork,
we're
thinking
of
vanilla-
or
I
I
don't-
I
won't
say,
vanilla,
kubernetes,
a
cl,
a
platform
that
could
pass
the
conformance
test
for
kubernetes,
so
it
should
be
compatible
so
different,
cns
that
are
going
to
be
running
on
it
should
be
able
to
run.
A
B
B
B
Which
is
tough
because
there's
a
lot
of
work
that
has
to
happen
in
advance
to
this
right
and
then
from
a
provider
side.
That
means
that
you
need
to
have
the
appropriate
private
repository
mechanisms
to
you
know,
pull
everything
in
and
then
make
it
available
internally,
but
like
depending
on
what
kind
of
cnf
we're
talking
about.
B
B
There's
things
inside
of
helm,
charts
that
are
calling
like
public
repos
and,
like
you,
don't
really
find
out
the
pain
until
the
first
time
you
try
to
go
and
install
everything
in
a
completely
internet-less
environment,
and
I
mean
some
of
this
is
just
my
own.
Lessons
learned
at
you
know
both
where
I
work
now
and
places
I've
worked
in
the
past,
where
other
service
providers
were
like
yeah
we're
not
letting
anything
pull
directly
from
the
internet.
B
It
gets
into
like
security
and
compliance
and
stuff
right.
Like
do
you
allow
images
before
you
scan
them
to.
You
know
even
be
built
in
a
sandbox
environment
yeah.
This
is
one
of
those
things
I
would
say
from
an
onboarding
perspective
is,
can
I
you
know,
build
a
vnf
or
sorry
cnf
by
getting
all
the
artifacts
pre-positioned
in
an
internal
repo,
so
whether
it's
you
know
lineage
package,
linux
packages,
helm,
charts,
container
images,
etc,
etc,
etc.
B
B
B
So
that's
one
of
my
thoughts
contributions
and
I'd
be
willing
for
people
to
argue
saying
that
you
shouldn't
do
things
air
gapped
and
then
you
know
we
could
try
to
tease
out
like
what
is
the
actual
best
practice
and
like
look
at
some
of
this
stuff
and
sas
is
an
aas
software
service.
One
of
those
buzzy
acronyms
like
they
want
to
provide
some
type
of
like
centralized
cloud
monitoring
solution
or
whatever,
like
remote
from
the
air
gap,
install.
E
So
I
I
did
end
up
reading
it
just
now.
I
think
it's
a
fine
start,
oh
to
add,
to
this
brainstorming.
You
know
more
than
just
the
hidden
dependencies.
It's
the
topic
we
discussed
a
bit
in
the
past
is
the
the
big
platform
requirements
I
mean
there
are
also
dependencies,
but
but
that's
actually
where
it
gets
interesting.
How
do
we
actually
define
them?
E
For
example,
if
you're
deploying
on
openshift
versus
others
and
you're
expecting
a
certain
systems
to
be
in
place
specifically,
operators
right,
openshift
uses
a
lot
of
operators
and
then
the
question
is
well.
If
you
also
need
operators
for
the
cnf,
the
question
that
ian
keeps
raising,
are
they
part
of
the
platform
or
are
they
part
of
the
cnf,
and
we
don't
really
have
any
rules
of
thumb,
even
let
alone
best
practices?
For
that?
I
think
this
is
really
new
new
terrain.
B
Not
just
operators
right
and
so
for
the
record
too.
We
started
with
cns,
but
the
whole
air
gap
thing
puts
a
lot
of
requirements
on
the
cst
as
well.
Right
so
to
this
exact
point
say:
tao
wants
to
you
know,
use
fluent
d.
I
think
other
discussions
with
onboarding
and
life
cycle
management
will
like
talk
about.
Like
you
know.
How
do
we
deal
with
like
versioning
between
you
know
two
different
parties
maintaining
things
but
like?
B
Ultimately,
if
the
cnf
is
expecting
certain
packages
too
right,
so
it's
not
just
the
csp
is
like
you
need
to
provide
me
vendor
a
all
of
your.
You
know,
sub
components
and
dependencies
inside
your
stuff,
like
if
it's
common
infrastructure
right,
like
is
the
provider
within
the
private
repositories,
providing
all
the
necessary
dependencies
for
the
cnf
for
things
that
probably
aren't
specific
to
their
cnf.
But,
as
you
know,
common
tooling,
such
as
log,
forwarders
or
operators,
you
know
just
generic
helm
charts
that
we
all
use
ubiquitously
across
the
board.
So
I
don't.
B
E
Yeah,
the
the
list
of
requirements
is
quite
big.
I
just
gave
operators
an
example,
there's
of
course
cni
plug-ins,
but
also
sometimes
storage
redundancies.
There
are
certain
expectations
from
the
platform,
and
you
know
another
aspect.
I'm
just
brainstorming
here
relating
to
last
week's
presentation
on
certification
right,
so
part
of
onboarding
is
also
going
through
some
sort
of
test,
suites
certification,
suites
that
might
come
from
a
few
different
sources
right.
It
could
be
from
the
platform
it
could
be
from
the
the
telco.
E
C
And
regard
hi,
everyone
alex,
is
speaking
regarding
the
platform
requirement.
Specifically,
I
think
there
is
a
project
aniket
in
the
linux
foundation,
networking
that
is
aiming
to
provide
a
reference
architecture
for
specifically
telco
cloud,
so
whether
it's
container
based
reference
architecture
or
virtual
based
reference
architecture.
E
B
So,
like
you
know,
theoretically,
like
you
know,
one
of
the
reference
architecture
components
is
like
the
concept
of
providing
like
a
c9
multiplexer
or
something
right.
Well,
if
cnfender
says
cool,
this
is
going
to
be
in
there,
but
they
build
everything
around
multis
and
then
I'm
you
know
deploying
denim.
Do
I
just
expect
it
to
work?
B
Potentially
you
know
taylor
said
we're
already
working
with
etiquette,
but
like
not
just
consuming
the
reference
architecture,
but
actually,
especially
at
the
implementation
layer,
where
we're
like
uncovering,
like
the
pain
points
and
like
the
actual,
like
I
can't
do
x
unless
y
is
satisfied,
is
something
we
should
probably
try
to
push
back
up
as
well,
and
then,
ultimately,
that
could
lead
into
like
test
cases
in
the
cnf
testbed
and
then
some
of
their
test
suites
as
well.
You
could
validate
things.
A
Reference
architecture
and
then
what
we're
trying
to
do
within
the
tug
and
cnf
working
group
and
all
of
the
these
cncf
initiatives
is
create
something
that's
a
more
higher
level.
So
it's
a
lot
of
the
stuff
that
we're
doing
can
end
up
being
best
practices
that
aniket
would
follow,
but
aniket
may
choose
one
path
so
that
they
have
a
reference
that
can
actually
be
utilized
directly
in
code
there.
We
could
end
up
talking
with
extravela
directly,
which
we
have
had
them
on
calls.
In
the
past,
it's
been
a
while
on
the
tug
calls.
A
The
best
practices
that
we
come
up
with
could
end
up
going
to
both
aniket
next
juvela
and
maybe
other
places.
I
know
frederick.
You
were
talking
to
folks
at
tip
telecom
mantra
and
other
other
places.
You
know,
maybe
even
on
f,
do
we
have
any
other
best
practices
that
folks
can
think
of
as
far
as
adding
them
in
here.
Brainstorming
on
this,
or
maybe
this
making
you
think
of
something
other
than
onboarding.
A
F
Yeah,
taylor,
I'm
not
sure
this
is
oliver,
I'm
not
sure
we
had
it
on
there
a
while
back.
It
may
have
just
kind
of
slipped
off
the
radar
again,
but
the
you
know,
handling
of
state
state
would
be
something
interesting
to
work
on
those
best
practices
as
well,
I'm
not
sure
the
right
forum
for
it,
but
you
know
we
have
a
use
case
for
it
today.
F
B
B
Where
they're
you
know
declaring
things
and
rebuilding
things
etc.
Like
is
my
state
resilient?
Am
I
willing
to
lose
the
state
like
you
know,
do
I
replicate
state?
Do
I
do
things
to
get
me
in
trouble
where,
like
I
have
my
volume
in
you,
know
az1,
but
then
it
redeploys
an
az2,
and
I
get
confused.
Why
I
can't
mount
my
container
to
my
volume.
Like
there's
a
lot
of
cool
stuff,
you
can
tease
out
with
managing
state
correctly.
B
A
C
C
E
Another
point
to
add
it
might
be
very
obvious,
but
just
a
a
big
part
of
onboarding
is,
of
course,
the
orchestration
platform
inventory
management
packaging.
So
whatever
is
done
at
the
level
of
the
cnf
provider
would
then
maybe
need
to
be
repackaged
or
modified,
depending
on
the
exact
orchestration
solution
used
by
the
telco
that
includes
middleware,
descriptors,
etc.
So
again,
nothing
I.
I
don't
think
this
is
about
us
providing
best
practices
for
that,
but
just
another
point
to
add
to
the
list
of
what
is
incorporated
in
onboarding.
B
Well,
I
I
would
say
we
do
want
to
explore
this
from
a
best
practice.
Standpoint
total
because,
like
I
mean
a
our
operator,
is
a
best
practice
right,
like
some
people
are
going
to
provide
operators
and
then
give
you
the
ability
to
provision
the
cnf
through
kate's
api.
Others
are
going
to
stick
a
you
know,
restomp
pod
inside
of
there
and
then
provide
a
you
know.
Third
avenue
of
approach.
For
you
know
configuring
and
managing
so
like
just
this
like
notion
around
like
interfaces
right
like
is
it
consumable?
B
Can
I
run
it
like
this
gets
into
the
life
cycle
management
use
case
too?
Not
just
the
onboarding
one,
but
like
can
I
actually
consume
the
cnf
or
every
time
I
do
a
cns,
and
this
is
kind
of
what
happened
in
the
cns
or
sorry
the
vnf
spaces.
Do
I
need
a
unique
like
orchestration
suite
for
every
cnf
I
want
to
deploy,
and
if
the
answer
is
yes,
then
we
probably
want
to
figure
out.
Why
that's
the
case
and
if
there's
ways
to
minimize
that
tool,
sprawl.
E
Oh
you're,
absolutely
right,
it's
it's
actually
the
packaging
that's
very
complex
and
that's
where
we
see
telcos
and
others
pushing
to
adopt
etsy
descriptor
standards,
with
the
hope
that
you
would
have
a
generally
accepted
standard
that
various
orchestrators
would
be
able
to
onboard,
as
is,
but
I
think
we
all
know
that,
even
when
you
adhere
to
standards,
nothing
ever
just
works
out
of
the
box.
So
that's
why
onboarding
is
a
process
right.
E
It's
not
a
and
a
long
process
for
that
matter,
but
but
yes,
you're
right,
it
is
something
that
we
should
think
about
and
explore
at
some
point
I
would
put
it
under
the
general
rubric
of
packaging
packaging,
a
cnf.
What
does
that
mean?
What
are
we
intending
to
achieve?
How
far
can
we
go
in
terms
of
making
it
generic
or
or
open
or
documented,
or
it's
it's
a
huge
huge
topic.
A
E
Tosca
helm-
and
you
know
etsy's
extensions
to
those.
I
I
mean
topics
to
discuss,
I'm
not
saying
that
these
are
things
that
should
be
best
practices,
but
these
are
these
are
used
in
the
industry,
so
if
they
are
being
used
well,
we
can.
We
can
give
some
best
practices
for
each
one
without
necessarily
having
an
opinion
of
which
way
to
go.
E
For
tosca,
yes
for
helm,
I
would
say
no
and
that's
its
problem,
but
I'm
not
a
big
fan
of
helm
as
people
famously
know
here
I
think,
but
yeah
modeling
is
part
of
it,
but
then
modeling
kind
of
goes
even
beyond
packaging
and
really
talks
about
orchestrated
orchestration
generally,
and
that's
where
you
have
the
advantage
of.
If
you
package
your
cnf
with
declarative,
modeling
type
information,
then
it
could
be
better
orchestrated
right
as
part
of
a
topology
that
includes
other
network
functions,
and
you
know
network
services
right
chaining
together,
so
yeah.
C
And
regarding
the
state,
you
brought
up
a
great
point
earlier
tal
and
I
was
wondering:
do
we
want
to
delineate
the
state
we
care
about?
Do
we
care
about
the
state
of
elements
within
the
inventory
or
do
we
care
about
the
state
of
the
network
element
themselves
or
the
cnf
or,
and
we
care
about
the
state
of
the
platform
itself,
because
I
probably
it's
it's
more.
The
latter,
like
I
know
it's
more,
the
the
cnf
themselves,
not
the
platform,
but
the
delineation
could
be
blurred.
E
Oh,
that's
a
very
good
point.
You
know
it
really
depends
again
on
which
orchestration
platform
you're
using
inventory
management
can
be
combined
together
with
site
management
right.
So
it's
not
just
information
about
which
network
functions
with
their
licenses,
etc.
Right,
if
you
look
at
something
like
one
app,
but
also
you
onboard
sites
right
onboarding,
a
site
is
outside
of
our
scope,
of
course,
but
it
might
actually
have
a
very
similar
process
to
to
onboarding
cnf.
E
A
The
one
way
to
narrow
this
down
some
would
be
we're
looking
for
practices
that
are
kubernetes,
specific
cl
or
cloud
native
best
practices,
so
not
practices
in
general
for
implementation.
When,
if
we're
looking
at
implementing
a
solution,
you
may
go
with
best
practices
that
have
nothing
to
do
with
cloud
native.
What
we're
talking
about
here
is
what
is
the
most
efficient
way
to
utilize?
A
How
can
you
most
efficiently
and
effectively
utilize
kubernetes
services
and
the
framework
which
may
or
may
not
be
in
conflict
with
other
practices,
so
with
regards
to
stuff
like
a
platform
or
site
state
or
other
areas
where
you're
bringing
it
on?
You
would
be
thinking.
How
do
I
extend,
or
how
do
I
add,
to
the
platform
that
I'm
using
in
a
way
that's
cloud
native,
and
there
are
projects
within
kubernetes
that
are
looking
at
extending
directly
like
expanding.
A
Can
you
add
new
nodes
clusters,
multi-cluster
type
things,
and
how
do
they
become
part
of
it
and
there's
practices
around
that?
Some
of
them
are
trying
to
make
it
more
integrated
into
the
way
you
would
even
use
like
cube
adm
for
spinning
up
a
small
set.
But
how
do
you
actually
add?
New
physical
machines
quote
unquote
around
the
physical,
so
that
that's
where
you
want
to
think
for
this
sort
of
thing.
A
C
C
I
yeah
I
mean
we
don't
we
haven't
covered
much
about
day
two
and
the
operations,
I
think
most
of
the
things
written
there
are
to
help
with
that,
but
there
is
definitely
a
shift
in
how
the
operations
are
done.
When
we
do
things
cloud
native
leveraging,
some
of
the
kubernetes
construct-
and
I
don't
know
whether
there
is
best
practices
we
should
well
yeah.
I
think
we
should
have
best
practices
into
providing
how
not
necessarily
explaining
how
the
operations
are
going
to
change,
but
at
least
helping
with
here
here
are.
C
You
know
things
that
will
help
you
be
successful
in
operating
in
a
cloud-native
landscape
for
the
network
function
because
that's
definitely
an
area
that
is
a
big
shift
into
how
it's
done
today
and
I'm
thinking
about
yeah
yeah
anyway.
So
operations,
I
think,
is
a
very
broad
topic
and
and
and
can
be
filled
with
a
lot
of
practices
that
we
can
help.
Csp
follow.
B
C
A
Yeah
love
love
to
have
your
help
directly
alexis.
If,
if
that
scenario,
where
you'd
like
to
work
with
us,
whether
it's
we
can
expand
and
have
other
use
cases
that
are
related,
that
get
even
more
specific
to
like
day
two
challenges
or
diving
into
maybe
some
practices
that
you
think
we'd
look
at.
But
if
you're
interested
in
that,
then
let
us
know
I'm
going
to
just
drop
it
here
under
the
onboarding
but
day
two
challenges
and
I'm
also
going
to
drop.