►
From YouTube: CNCF Telecom User Group Meeting - 2021-01-04
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
Okay,
I
think
we
can
get
started
now.
So
thanks
everybody
for
joining
today.
This
is
the
telecom
user
group.
Monthly
call
just
a
reminder
that
this
call
switches
between
more
apac
friendly,
which
is
this
call,
which
is
at
11
utc
and
next
month.
It'll
be
the
more
us
friendly
time
at
1500
utc
before
we
get
started.
A
A
A
Okay,
it
doesn't
seem
like
they're
they're
on
the
call
today
they,
even
though
they
list
they
listed
themselves
in
the
attendees.
So
I
guess
we'll
just
skip
that
point
so
upcoming
events
that
we
want
to
point
out.
There's
the
etsy
plug
fest
in
february
and
the
cnf
test
suite
developed
by
the
cncf.
A
It
will
also
be
there
to
test
out
the
cloud
nativeness
of
cloud
native
network
functions,
and
so,
if
you're
planning
on
attending
look
forward
to
testing
out
how
cloud
native
your
cnf
is,
and
then
we
have
kind
of
two
things
coming
up
today
or
two
things
on
the
agenda
for
today.
The
first
is
a
white
paper
that
was
originally
started
by
jeffrey
selins,
around
telecommunications
challenges
and
drivers,
and
this
is
something
he
kind
of
wants
to
move
forwards
on
in
the
new
year.
A
And
so,
if
we
look
into
this
stock,
it
was
originally
started
in
2019
and
kind
of
the
goal
of
this
white
paper
is
to
dive
into
kind
of
what
is
driving
cloud
native
transitions
in
telecommunications
and
also
kind
of
what
the
problem
statements
or
what
the
problems
are.
A
As
telcos
try
to
go
more
cloud
native,
and
so
what
we're
looking
for
is
people
to
contribute
to
this
and
continue
to
like
develop
some
of
the
ideas
in
here
so
he's
kind
of
laid
out
the
initial
framework
of
different
challenges
and
different
drivers
for
the
cloud
native
transition,
and
what
he's
looking
for
right
now
is
people
that
are
interested
in
helping
write
up
different
sections.
A
So
if
anybody
on
the
call
today
wants
to
kind
of
like
volunteer
for
one
of
these
sections
say
for
the
generic
telco,
one
of
the
challenges
and
going
cloud
native
is
integration
into
existing
systems
tool
sprawl
operation,
I
operate
relationalizing
new
tech
layer,
two
layer,
three
integration,
there's
lots
of
different
things
on
here.
If
there's
anything
else,
please
feel
free
to
jump
in.
B
Hello,
yeah,
hello,
my
name
is,
and
today
the
first
call
I'm
attending
the
user
group.
So
I
would
like
to
ask
the
question
the
challenges
mentioned
in
the
document
are
taken
from
the
vendor
perspective,
or
it's
just
the
user
group
like
they
have
come
up
with
the
requirements
from
like
from
the
past
experiences
or
taking
the
cloud
native
journey
to
forward
like
so.
A
Yeah,
so
this
yeah,
absolutely
so
jeffree
stalin
is
at
charter
communications,
so
he's
an
operator.
So
I
think
this
is
focusing
on
the
operator
perspective.
So
as
service
providers
and
operators
go
more
cloud
native,
what
challenges
do
they
have
and
part
of
it
is
kind
of
understanding,
the
hurdles
that
we
need
to
get
over
and
learning
from
the
nfv
transition.
Okay,.
B
And-
and
the
other
thing
like,
can
we
introduce
more
challenges,
or
is
it
just
have
to
be
like
we
have
to
work
on
these
challenges
itself?.
A
B
Because,
like
what
I
see
in
the
generic
telco
and
nfp,
section
like
these
are
more
towards
the
wired
infrastructure,
like
it's
more
towards
the
core
network
side
or
more
towards
the
like
the
transport
network.
Basically,
it
looks
like
that
way,
but
it
doesn't
capture
the
rank
specific,
like
operations
or
the
what
goes
into
ran
or
in
order
like
in
the
more
importantly,
the
protocol
stuff
of
like
a
node
b
or
g
node
b.
In
that.
A
Okay,
is
there
something
specific
that
you
want
to
put
down
in
the
document.
B
Right
now,
no
no
right
now
I
won't
put
it
down
anything,
I'm
just
asking
like:
can
you
introduce
more
challenges
or
like?
Can
we
introduce
a
new
category
of
like
making
a
rant
section
for
the
for
the
nfv
like
cloud
native
journey
for
diran,
also
not
from
the
just
nfb
perspective
or
the
transport
network
yeah?
B
A
B
A
B
A
Okay,
so
if
you're
interested
in
adding
more,
please
feel
free
to
start
contributing
to
the
doc.
Obviously
anybody
can
start
writing
in
there.
The
second
part
is
so
tal
from
red
hot
is
currently
sleeping,
because
it's
about
5
a.m,
for
him
right
now
in
the
us.
So
I'm
going
to
give
a
brief
presentation
of
something
that
he's
interested
in
talking
about.
So
apologies
tall.
A
If
I
don't
do
it
full
justice,
but
so
what
he's
interested
in
kind
of
talking
about
or
starting
up
is
kind
of
a
group
to
talk
about
kubernetes
networking
orchestration,
and
I
guess
when
we
say
networking
this
isn't
like
layer,
seven,
it's
more
layer,
two
layer,
three,
it's
it's
because
obviously
there
already
are
there's
already
sig
networking
in
the
cncf
and
the
kubernetes
networking
sig,
but
those
are
more
a
little
bit
different
than
what
he
wants
to
talk
about
in
this
and
so
starting.
A
I
guess
the
starting
point
is
like
kubernetes.
Networking
is
too
bare
because
there's
really
only
one
layer,
three
network
for
all
the
pods
one
of
the
fundamental
concepts
within
kubernetes
is
that
all
pods
can
talk
to
all
the
pods
on
the
local
network
and
you
can
also
create
services,
but
that's
not
the
the
complete
way
to
do
it,
and
so
there's
currently
four
different
parts:
they're
corded
kubernetes
networking,
which
is
the
cmi
plugin,
which
is
in
charge
of
ipam
and
internode
connectivity.
A
This
problem
is
being
worked
on
in
the
multi-cluster
sig,
but
it's
not
a
solved
problem
or
has
a
known
like
a
really
good
solution.
Yet,
and
the
real
problem,
especially
for
this
group,
is
that
this
isn't
quite
good
enough
for
telcos
or
for
network
functions.
This
really,
this
single
l3
network
is
pretty
insufficient
for
telecom
needs.
A
A
lot
of
telcos
have
wishes
for
special
types
of
network,
including
layer,
2,
hardware,
acceleration,
lan
ram
and
other
exotic
networks.
Let's
say
people
have
tried
to
kind
of
go
around
these
shortcomings
with
different
types
of
solutions
like
multis,
nsm
or
dan
m.
A
But
the
problem
is:
is
each
of
these
have
to
be
configured
more
at
like
the
platform
level,
and
so
there
therefore
deploying
a
network
function
actually
begins
like
way
way
way
before
it
really
starts
when
you're
deploying
the
platform
too,
because
it's
so
so
tied
to
that,
and
so
a
cnf
can't
be
just
packaged
as
a
kubernetes
workload,
because
reliant
so
much
on
how
the
platform
is
is
set
up
too,
and
so
it
can
be
challenging
to
orchestrate
network
services
at
scale
across
these
platforms.
A
And
so,
if
we
go
back
to
previously
previous
clouds
like
openstack
one
of
the
key
focuses
there
was
isolation
and
portability
between
environments,
and
so
the
the
really
big
difference
there
is
that
layer,
three
ip
networks
and
subnets
are
actually
resources
owned
by
the
workloads
and
it's
actually
included
in
the
platform.
And
so
a
virtual
machine
can
connect
to
any
number
of
networks
rather
than
just
the
the
one
main
one.
A
And
so,
therefore,
like
the
networking
providers,
like
neutron,
actually
do
the
heavy
lifting,
rather
than
having
to
rely
on
the
actual
network
function,
and
so
what
tall
wants
to
discuss
is
how
we
can
kind
of
bridge
the
gap
between
these
two
systems
in
kubernetes,
and
so
one
idea
that
he
had
is
to
bring
back
kind
of
the
portability
so
allowing
us
to
move
cns
from
platform
to
platform.
And
so
the
idea
is
what.
If
a
cnf
could
request
the
type
of
network
that
it
needed
through
a
kubernetes
crd.
A
Then
the
the
platform
provider
could
know
what's
available
and
can
handle
the
provisioning
and
configuration.
And
thus
the
provider
can
give
visibility
into
how
networking
is
being
used
by
the
app
by
the
node
or
by
the
cluster.
And
so
in
a
way
to
make
this
cloud
native
in
declarative.
Like
automated
fashion
is
we
they
could
be
themselves
become
kubernetes
workloads.
A
But
one
of
the
problems
is,
a
lot
of
providers
would
need
to
have
privileged
access
to
hosts
capabilities,
and
so
one
thing
that
tal
kind
of
pocs
was
this
project
knapp,
which
enables
like
cloud
native
providers
for
multis,
and
so
what
tal
wants
to
do
is
set
up
a
group
that
is
interested
in
discussing
these
problems
within
kubernetes,
and
so
what
he
wants
to
set
up
is
a
little
kubernetes
networking
orchestration
task
force,
and
so
what
he's
going
to
do
is
have
a
meeting
to
discuss
this.
A
One
of
the
first
ideas
is
to
have
a
white
paper
under
this
telecom
user
group
to
discuss
kind
of
what's
missing
and
what
should
be
done
and
figure
out
the
exact
configuration
of
this
group.
So
one
idea
is
to
have
it
fall
under
the
telecom
user
group
or
create
a
new
sig
within
cncf,
and
so
I
think
this
is
kind
of
like
a
walk.
Crawl
runs
this
stuff
or
sorry,
crawl,
walk
run,
and
this
is
still
very
much
in
the
crawl
phase.
It's
the
the
initial
things.
A
This
is
he's
kind
of
stated
what
the
problem
statement
is,
and
now
the
idea
is
to
bring
together
a
group
of
people
that
are
interested
in
it
to
discuss
what
the
potential
solutions
might
be.
So,
if
you're
interested
in
being
more
involved
in
this,
please
contact
tal.
A
A
Okay,
that's
it
is
there
anything
anybody
else
wants
to
bring
up
today
before
we
we
close.
A
Okay,
thanks
everybody
for
joining
today.
Just
a
reminder.
The
next
meeting
is
next
month
on
february
1st
at
1500
utc
thanks
for
joining
today,.