►
From YouTube: CNCF Telecom User Group Meeting - 2020-11-02
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
Yeah
sorry
for
joining
late,
I
completely
mixed
up
the
time
zone
and
it
was
in
the
there's
an
hour
from
now
on
my
calendar,
so.
A
Yeah,
I
guess
so
thanks
everyone
for
joining
today.
I
guess
we
kind
of
have
a
short
agenda
today,
but
I
think
there
are
some
kind
of
important
things
that
I
want
to
kind
of
highlight
on
the
agenda
before
we
get
started.
Is
there
anything
that
anyone
would
like
to
add
or
discuss
on
the
meeting
today?
That's
not
already
on
the.
D
D
I
think,
just
before
you
joined
we
had
a
quick
talk
about
the
cnf
working
group.
I'm
thinking
we
could
just
add
the
link
to
that
pull
request
to
the
agenda
as
well.
So
people
have
a
chance
to
look
at
it
as
well.
A
Yep,
so
I
have
the
link
in
the
like
under
the
upcoming
events,
but
I'll
also
add
it
in
the
agenda
section
too.
So
I'm
doing
that
right
now,
oh
yeah.
A
Okay
and
if
everybody
just
wants
to
add
their
name
to
the
attendees
that'd,
be
great
too
so,
under
the
upcoming
events,
section
daylight
saving
times
ends.
I
think
everybody
knows
that
and
that's
why
my
calendar
was
a
little
bit
off
today.
So
apologies
again
for
that
also,
once
again
for
future
talk
meetings,
we
do
them
once
a
month
and
it
switches
between
apac,
friendly
and
us
friendly,
also
geargate.
Thank
you
for
posting.
A
The
notes
and
agenda
I
want
to
highlight
also
upcoming
towards
the
end
of
the
month
is
kubecon
from
the
17th
to
the
20th.
This
is
once
again
a
virtual
event.
I
hope
everybody
can
join
us
for
that.
There's
two
sessions
that
I'd
like
to
highlight
the
first
one
is
the
introduction
to
cncf's
telecom
initiatives.
A
That's
one
recorded
by
taylor
carpenter,
talking
about
how
we
all
the
different
initiatives
that
the
the
cncf
has
around
the
whole
telco
space
and
the
second
one
is
the
cloud
native
network
functions,
community
meeting
or
really
the
kickoff
for
the
cnf
conformance
working
group,
and
so
maybe
I'll
dive
into
that
in
a
second
here,
and
so
what
the
cnf
conformance
working
group
is
trying
to
do
is
to
really
help
companies
better
understand
what
cloud
native
means
for
telecommunications
workloads
and
help
build
a
consensus
around
industry,
adoption
of
cloud
native
technologies,
and
so,
if
you
go
to
this
linked,
pull
request
in
here,
it'd
be
great
to
start
to
have
people's
feedback
on
the
structure
of
it.
A
Because
the
problem
that
we
see
right
now
in
the
industry
is,
we
originally
went
from
physical
network
functions
in
specialized
hardware
boxes
to
virtualized
network
functions
vnfs
and
we
kind
of
took
the
stuff
in
the
physical
boxes,
put
them
into
vms
and
called
it
good
now,
as
tradition
transitioning
from
vnf's
and
and
virtualized
infrastructure
towards
more
containerized
cloud
native
infrastructure.
A
A
And
so
what
we're
trying
to
do
is
to
create
a
certified
cnf
program
similar
to
the
certified
kubernetes
program.
You
can
think
of
it
almost
like
the
certified
kubernetes
program
works
at
the
infrastructure
layer,
defining
what
a
cloud-native
kubernetes
infrastructure
is
and
what
conformance
is
and
now
we're
going
to
also
transition
and
do
that
at
the
application
layer
too.
A
So
thinking
about
what
does
cloud
native
mean
for
the
application
when
we're
running
in
a
taco
setting
and
our
goal
is
to
create
a
conformance
program
that
allows
us
to
determine
what
cloud
native
is
for
running
telco
applications,
and
this
will
consist
of
kind
of
like
two
different
parts.
So
one
is
kind
of
the
spec
and
you
can
think
of
it
and
the
other
is
kind
of
like
the
implementation,
and
so
the
cnf
working
group
is
going
to
define
what
cloudant
native
means
and
like
what
areas.
A
What
areas
need
to
be
defined-
and
this
is
similar
to
the
kubernetes
conformance
working
group
and
the
second
part
is
going
to
be
the
cnf
conformance
test
suite
and
that
will
be
the
actual
like
implementation,
so
the
test
that
will
test
the
cloud
nativeness
of
the
actual
applications
you
can
think
of
this
similar
to
the
kubernetes
and
end
tests
and
projects
on
a
boy,
and
so,
if
you're
interested
in
learning
more
about
this
initiative
and
the
thoughts
please
feel
free
to
review.
A
C
Bill
a
question
with
regard
to
your
comment
about
you:
know:
people
taking
network
functions,
virtualizing,
putting
them
into
containers
and
calling
them
cloud
native
as
part
of
this
process.
Do
you
intend
to
come
up
with
some
kind
of
a
revision
of
the
existing
definition
of
cloud
native
computing
technologies
on
github?
You
know
talking
about
scalable
applications.
A
So
I
think
a
little
bit
about
our
goal
with
this
group
is
to
actually
right
the
thing
about
this
definition
is
it's
great
when
you're
looking
at
it
from
a
30
000
foot
in
the
air
type
of
view,
and
it
provides
a
really
broad
overview
of
what
cloud
native
means,
but
the
the
problem
that
we
see
is
as
people
go,
to
try
to
actually
implement
and
architect
cloud
native
applications.
A
It
really
is
kind
of
like
a
wild
west
right
now,
where
everybody
has
their
own
idea
of
what
cloud
native
actually
means,
and
so
part
of
what
we're
trying
to
do
with
this
working
group
is
to
help
people
be
able
to
implement
applications
in
an
actual
cloud-native
way,
and
so
by
defining
what
cloud
native
is
at
the
application
level
and
providing
a
test
suite
around
that.
What
we
hope
to
enable
people
to
do
is
to
really
determine
if
they
are
developing
applications
in
a
cloud-native
way.
C
Now
I
mean
when
you
put
this
test
environment,
would
you
in
a
way
somehow
use
the
existing
infrastructure
architectures,
like
5g,
the
storage
layer,
the
separation
of
the
business
logic
from
the
session
context
of
the
applications
in
a
way
using
the
integration
of
the
mac
and
where
how
mac
applications
can
actually
invoke
some
of
the
capabilities
change?
The
upf
I
mean.
C
Would
you
in
a
way,
also
use
at
the
bottom,
these
capabilities
of
this-
and
you
know
also
management
and
orchestration,
because
you
have
also
support
in
mac
for
alternative
virtualized
technologies,
where
actually,
the
management
and
orchestration
on
the
platform
and
virtualized
technology
and
the
application
is
on
the
host
on
the
system
level.
It's
the
you
know,
map
orchestrator
and
the
oss
bss,
primarily
tm
forum.
C
You
know
oda
what
your
test
environment,
what
kind
of
capabilities
or
existing
architecture
simulations
you
have
in
order
to
show
or
certify
these
applications
or
these
functionalities
to
be
cloud
native
I
mean.
Also,
if
you
take,
I
mean
right.
I
mean
taylor
is
not
here,
he
was
presenting.
You
know
turin
dot
on
kubernetes,
but
it's
actually
working
on
the
ims.
Ipmmm,
you
know
with
the
sip
protocol,
while
in
the
5g
on
the
slicing
you
know,
ue
terminal
actually
can
support
simultaneously
eight
udps,
so
you
actually
can
be.
C
You
know
having
s
nss,
ai,
eight
from
the
you
know,
radio
resource
control
manager,
and
then
you
can
run
eight
slices
simultaneously
on
the
udp,
which
means
that
you
can
actually
support
eight
different
use
cases
simultaneously.
I
mean
sitting
in
your
car
and
you
know
using
this
as
a
slice
and
then
having
a
wearable
also
and
then
getting
simultaneously
data
from
your
home
appliances.
Security.
This
can
be
done
actually
simultaneously
on
the
user
equipment
terminal
that
if
it
is
supporting
5g
now
my
question,
I'm
sorry
if
it's
a
little
bit
too
long.
C
So
I'm
sorry
if
it's
a
little
bit
too
long,
but
just
to
give
you
an
idea
so
in
your
test
environment
to
certify
these
applications
as
cloud
native,
because
also
etsy
mech
is
also
integrated
with
the
5g.
C
C
A
Yeah,
so
what
we're
going
to
do
is
run
it
on.
Our
goal
is
to
have
this
work
on
any
certified
kubernetes
distribution,
and
what
we're
trying
to
do
is
define
just
like
how
cloud
native
the
application
is,
and
I
think
what
you're
like
looking
for
more
is
actually
something
that's
coming
out
of
our
sister
organization,
linux
foundation,
networking
their
work
in
the
cntt,
which
is
the
cloud
infrastructure,
telco
task
force,
which
is
defining
a
reference
architecture
and
reference
implementation
and
reference
conformance
for
the
infrastructure
and
how
the
infrastructure
interacts
with
the
application.
A
And
so
what
they'll
be
using
is
they're
already
implementing
some
of
the
tests,
like
the
kubernetes
end-to-end
test
suite,
and
hopefully
some
of
the
tests
from
the
cnf
conformance
to
actually
test
the
infrastructure
in
the
application
and
how
they
work
together.
But
for
actually
looking
like
for
a
reference
architecture.
That's
going
to
be
coming
from
lf
networking,
but
we're
a
little
bit
upstream
of
that.
A
Just
looking
at
the
cloud
nativeness
of
the
infrastructure
and
the
application
through
certified,
kubernetes,
conformance
and
cnf
conformance
and
then,
like
kind
of
like
you
can
think
of
it
like
downstream.
For
actually
like
reference,
architectures
and
implementations,
that
would
be
like
other
groups
outside
of
cncf.
C
B
I
would
have
also
two
questions.
One
is
that
what
is
about
like?
How
do
you
think
that
this
working
group
will
interact
with
with
cnp?
So,
as
you
mentioned,
tmtp
is
also
like
defining
some
kind
of
a
reference
infrastructure
for
the
echo
workload
and
in
cnp
we
have
this
la2
and
rc2,
which
are
for
the
kubernetes
based
infrastructures
and,
and
there
are
plans
to
define
workflows
environments
there.
Also.
So
where
do
we
draw
the
line
between
cnpt
area2
and
rt2,
and
the
students
working
group
in
cntt.
A
Yeah,
absolutely
so
what
we
see
ourselves,
as
is
kind
of
like
upstream
of
cntt
like
r2,
and
actually
this
is
also,
if
you
scroll
down
in
in
the
polar
request.
It's
a
little
bit
addressed
there,
and
so
what
it
says
is
cntt
r2
is
focused
on
kubernetes
based
platforms
and
basic
interoperability
between
the
platform
and
the
workloads,
and
so
that's
actually
something
that
the
cnf
conformance
program
actually
isn't
working
on
either
of
those
aspects.
Either.
A
The
the
platform
is
definitely
outside
of
scope
and
we're
not
looking
at
the
interoperability
between
the
platform
and
the
workload.
So
that's
kind
of
where
we're
a
little
bit
different,
but
where
we
can
collaborate
is
like
kind
of
like
the
cloud
native
requirements
of
the
actual
like
workloads.
A
So
I
think
a
subset
of
the
tests
will
be
used
in
the
r2
work
stream,
and
so
you
can
think
of
the
work
in
the
cnf
conformance
working
group
to
be
upstream
of
cntt,
r2
and
they'll
be
using
some
of
the
tests
and
also
extending
beyond
just
what's
in
the
cnf
conformance
to
meet
their
exact
requirements.
A
Yeah,
exactly
I
mean
all
we're
going
to
be
focusing
on
in
cnf
conformance
is
the
cloud
native
aspect.
Is
our
application
implemented
in
the
cloud-native
way
where
cntt
r2
is
also
looking
at
interoperability
between
like
the
platform
and
the
workload,
and
there
is
some
overlap
there?
But
it's
not
exactly
the
same
thing
and
the
other
thing
that
cng
team
might
be
looking
at.
Is
that
the
actual
the
management
and
orchestration
aspect
too,
which
is
also
outside
of
the
scope
of
the
cnf
conformance
working
group,.
B
Okay,
that
that
makes
sense
we
just
have
to
make
sure
that
we
we
are
working
along
these
lines,
the
other
other
question
and
very
from
my
side
as
I'm
working
for
a
telecom
vendor.
How
much
does
this
working
group
want
to
define
the
internal
architecture
of
the
cns,
and
how
much
do
you
want
to
certify
like
what
is
like?
How
much
do
you
like
consider,
cns
black
box
or
white
box?
B
A
Yeah,
so
I
think
they'll
treat
it
more
like
a
black
box,
but
be
honest.
We
see
this
working
group
is
coming
up
with
the
definition
of
what
cloud
native
is
and
how
far
the
working
group
believes
that
should
be
taken,
and
so
we
think
this
should
be
kind
of
like
an
industry-wide
decision
too.
D
E
One
question:
so
is
it
all
about
computing?
Let's
say
a
cnf
fits
into
the
category
of
design
defined
like
containers,
cloud
native
features,
but
what
if
it
has
a
dependency
on
a
particular
sdn
like
a
reference
like
a
service
function,
chaining
is
there
are
some
cnns
that
require
service
function
to
happen
on
the
sdn,
so
if
it
meets
us
all
the
computing
requirement,
but
our
slide
dependence
and
particular
sdn
model,
can
we
say
that
it's
certified.
A
So
once
again,
I'd
actually
leave
this
up
to
like
the
working
group
to
help
define
that.
I
don't
want
to
make
statements
about
what
is
and
isn't
like
cloud
native
at
this
point,
because
I
think
I
I
could
say
something,
but
other
people
have
different
opinions,
and
I
think
this
is
something
that
we
should
have
as
a
debate.
So
I
think
the
first
step
is
to
look
at
the
working
group
charter
and
to
really
help
get
your
feedback
and
help
us
like
scope.
A
The
group
correctly
for
what
you
think
is
cnf
conformance
and
then
going
from
there
really
defining
what
we
see
as
in
scope
and
out
of
scope
for
cloud
native.
A
Yeah,
so
we
our
goal
would
be
to
have
this.
This
pull
request
merged
by
the
kickoff
meeting
at
cubecon.
So
that's
two
weeks
does
that
seem
like
enough
time
for
you.
A
Yeah
we
we,
I
mean
we
could
also
do
it
after
that,
but
we'd
like
to
kind
of
go
into
the
kickoff
meeting,
with
kind
of
like
a
clear
structure
about
how
we'd
like
to
set
things
up
and
kind
of
what
our
goals
and
non-goals
are.
E
One
more
clarification:
if
you
don't
mind,
maybe
I
missed
it
so
you're
referring
to
container.
So
if
cnf
is
based
on
what
letter
cube
word,
which
is
container
native
virtualization,
can
we
still
consider
it
cloud
native
or
it's
only
for
containers.
A
No,
so
it's
it's,
we
actually
specifically
don't
call
it.
A
container
network
function
like
a
virtualized
network
function.
It's
it's
cloud
native,
because
cloud
native
is
kind
of
like
a
best
practice.
It's
not
a
specific
implementation.
So,
if
it
meets
you
can
have
I
mean
you
could
have
like
a
cloud
native
physical
device,
and
so
what
we're
really
trying
to
embody
here
is
like
what
are
the
best
practices
around
it,
not
looking
at
the
specific
implementation,
okay,
thanks
yeah.
A
E
E
Not
sure
if
it's
related
is
there
a
community
for
cloud
native
networking,
I
think
we're
all
talking
about
cloud
native
computing
in
general,
but
I
think
this
is
also
a
topic
that
would
soon
be
addressed.
I
mean
I
can
say
in
virtualized
world
we
have
different
implementation,
that
based
on
sdn
and
you
need
a
specific
sdn
to
work
but
kubernetes
in
general,
though
it
gives
for
the
for
the
cni
to
do
this,
but
I
think,
especially
in
telecom,
there
are
some
use
cases
that
a
specific
stain
can
only.
E
A
Yes,
there's
a
couple
different
groups
that
are
working
on
this
right
now,
so
under
the
cncf
there's
networking
that
is
looking
at
how
networking
works
in
the
cloud
native
space
and
also
in
kubernetes
directly,
there's
also
a
sig
networking
too.
So
there's
two
different
ones,
looking
in
kubernetes
and
also
outside
kubernetes,
too.
A
A
Okay,
yes,
I'd
like
to
thank
everyone
for
joining
today
and
just
once
again
a
reminder
that
the
next
tug
meeting
will
be
monday
december,
7th
at
1,
500
utc.
So
that's
the
america
or
like
u.s,
friendly
or
north
america
friendly
time
and
also
in
the
meantime,
please
attend
cubecon
check
out
the
intro
session
and
please
join
our
first
kickoff
meeting
for
the
cnf
working
group
and
I
look
forward
to
having
everyone's
input,
feedback
and
discussion
on
the
github
issue.
In
the
meantime,.