►
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,
thank
you.
Everyone
for
joining
us
welcome
to
today's
cncf
live
webinar
captain
arm
a
secure
alternative
in
the
5g
space,
I'm
libby
schultz
and
I'll
be
moderating.
Today's
webinar
I'm
going
to
read
our
code
of
conduct
and
then
hand
it
over
to
kyle
freit
principal
solutions,
engineer
at
arm
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
speak
as
an
attendee,
but
there
is
a
chat
box
on
the
right
hand.
A
Side
of
your
screen,
please
feel
free
to
drop
your
questions
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chatter
questions
that
would
be
in
violation
of
that
code
of
conduct
and
basically,
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
A
Please
also
note
that
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
online
programs,
page
at
community.cncf.io,
under
online
programs
they're
also
available
via
your
registration
link
and
the
recording
will
be
available
on
our
online
programs.
Youtube
playlist
with
that,
I
will
hand
it
over
to
kyle
to
kick
off
today's
presentation.
B
I
recently
moved
to
another
team
where
we
focus
100
on
these
hyperscalers,
so
think
of
it,
mostly
as
like
taking
on
projects
that
are
x86
based,
trying
to
focus
them
back
on
to
arm
or
maybe
providing
adjustments,
or
you
know
performance-based
changes
to
them
so
that
way
we
can
perform
in
excel
on
all
the
hyper
scalers.
As
a
reason,
I've
been
mostly
focused
on
5g
and
networking
within
the
arm
technology.
B
B
I
think
they
kind
of
do
it
on
purpose
to
make
it
harder
to
understand,
in
my
opinion,
so
we're
going
to
have
to
go
through
a
lot
of
acronyms
to
understand
kind
of
what
the
importance
of
the
rick
is,
which
is
the
main
topic
of
this
here,
along
with
kata
I'll
talk
a
little
bit
about
oran,
which
is
one
of
many
different
groups
that
are
trying
to
do
this
here,
and
is
everyone
able
to
see
my
slides
by
the
way?
Is
it
moving?
A
B
Screen,
sorry
about
that,
okay,
so
sorry
about
that.
Okay!
So
let's
try
this
one
more
time.
So
let's
go
over
the
agenda
once
more,
so
5g
and
technologies,
and
all
that
aspect
here
so
we're
going
to
go
over
a
lot
of
acronyms.
Unfortunately,
there's
a
lot
of
systems
that
are
all
integrated
in
this
entire
ram,
this
entire
whole
package
of
this
and
then
we're
going
to
talk
a
little
bit
about
arm
and
its
aspects
within
5g.
We'll
talk
about
the
rick,
which
is
one
of
the
platforms
that
I
did
trans.
B
You
know
I
moved
from
x86
over
to
arm
we'll
talk
a
little
bit
more
about
that
performance
requirements
associated
with
it
and
then
from
there
we're
going
to
talk
about
how
the
importance
of
the
rick
is
within
in
the
ran
itself
and
the
security
implications
of
that,
and
then
we're
gonna
talk
about
deploying
the
rick
and
how
that's
currently
done
and
how
we
expect
to
do
that.
And
then
we're
also
gonna
talk
about
a
little
bit
more
about
the
orchestration
life
cycle,
how
it
deals
with
dealing
with
upgrades
and
aspects
of
that.
B
B
Here
on
the
slides
that
way,
people
can
actually
go
through
some
so
that
that
is
the
ran.
Intelligent
controller.
Think
of
this
thing,
as
the
brain
that
can
that
takes
in
decisions
from
other
aspects
of
the
system,
modifies
them
modifies
them
on
the
fly,
and
then
we
also
have
different
components
that
are
also
like
the
non-real-time
rick,
which
takes
in
configuration
things
they
make
changes
but
they're,
not
necessarily
in
real
time
they're,
not
fast,
they're
kind
of
slow.
B
Maybe
it's
configuration
we're
adding
a
radio
or
something
like
that
along
those
lines,
and
then
we
have
the
cu,
the
du
and
the
ru,
so
the
ru
is
basically
the
radio
unit.
That's
that's
the
thing
that
you
see
like
on
the
poles
when
you're
driving
by
on
the
on
the
freeway
or
whatever,
that's
basically
what
connects
to
your
ue
with
your
user
device
user
equipment
and
then
from
there,
the?
U,
the
ru
is
connected
to
this
du,
which
is
basically
digitizing.
B
It's
not
going
to
go
away
instantly
as
soon
as
5g
becomes
a
you
know,
a
mainstream
aspect
of
this
there's
also
that
confusing
thing
as
well
here
so
geno
b's,
which
are
five
g
nodes,
are
also
called
new
radio,
or
you
know,
g
standing
for
next
generation.
So
again,
these
acronyms
are
just
relatively
hard
to
understand.
So
that's
why
I
wanted
to
provide
this
to
you
and
then
some
of
the
interfacing
between
each
other.
B
So
like
the
a1
interfaces,
which
basically
communicates
between
the
non-real-time
rick
and
the
real-time
rick,
then
we
have
eu's
sorry
e1s
and
e2
interfaces
which
communicate
between
aspects
and
then
the
almighty
x2,
which
is
the
interface
between
these
different
node
b's.
These
enob
geno
beats
so
we'll
move
on
here.
B
Here
now
with
2g
and
3g,
specifically,
you
know,
people
were
using
controllers,
it
was
very
fixed
setups.
A
lot
of
orchestration
and
management
was
just
done
basically,
one
time
a
lot
of
people
using
multiple
different
systems
with
4g.
The
idea
was
hey.
If
we
use
these
interfaces
between
each
other
using
these
x2,
we
can
be.
You
know
we
could
purchase
multiple
different
types
of
ru's
different
types
of
systems
and
they
could
all
communicate
with
each
other.
We
thought
of
this
x2
as
kind
of
like
an
open
interface.
B
Well,
what
really
happened
was
a
lot
of
these
vendors
actually
took
their
x2
interfaces
and
kind
of
modified
it.
So
they
said,
oh
ours
does
you
know
x,
y
and
z,
the
other
one.
Does
you
know
x
y,
and
I
don't
know
b
or
something
like
that,
so
really
what
it
did
is
it
caused
a
lot
of
this
vendor
lock-in,
because
then
they
couldn't
really
communicate
with
each
other
now
with
oran,
so
the
o-ran
alliance.
They
kind
of
thought
about
this,
and
I
said:
okay,
we're
we're
going
the
vendor
lock
in
or
out
here.
B
We
need
to
try
to
open
this
up.
So
that
way,
you
know
if
we
want
to
use
a
better
radio
unit
or
we
want
to
use
different
equipment
for
different
aspects.
Maybe
I
want
to
you
know
customize
this
in
some
way
and
not
just
be
forced
to
use,
I
don't
know
eric's
or
nokia
whatever
it
might
be,
and
only
use
that
for
the
entire
system,
this
allowed
one
to
be
more
open,
so
all
of
them
can
communicate
with
each
other.
You
could
reduce
costs.
B
You
know
you
can
enable
different
equipment
in
different
areas
based
off
utilization.
Maybe
it's
you
know
a
farm
town
area
where
there's
a
lot
less
utilization
instead
of
being
in
you
know,
downtown
new
york
city.
Now,
you're,
not
you
know,
you're
not
buying
such
a
large
expensive
machine
for
every
little
aspect
of
this
you
can
kind
of
cut
and
paste
them
together,
and
you
know
all
these
different
people
also
are
part
of
the
oran
alliance.
You're
going
to
see
some
big
names
here
as
well.
B
B
So
let's
talk
about
arm
here
so
where
does
arm
fit
so
previous?
You
know
most
previous
generations,
2g
3
g5.
You
know
4g
by
even
5g
ness
aspect.
A
lot
of
this
is
x86
based,
so
we're
talking
intel
systems
or
proprietary
products,
these
kind
of
systems
that
are
running
major
applications
that
are
you,
know,
behemoths
monolithic.
B
B
You
know
we
want
to
be
in
all
the
different
aspects
of
5g
to
you
know,
provide
our
performance
and
our
optimization
here
now
a
lot
of
times
I
don't
know,
depending
on
I
guess,
where
you're
located
for
me
in
the
united
states,
5g
just
really
didn't
seem
like
that.
It
was
kind
of
like
a
hype.
You
know
it's
people
kind
of
thought
about
it.
They're,
like
oh,
it's
a
little
bit
better
than
4g.
B
You
know
you
had
5ge
coming
out
on
att
and
you
saw
it
on
your
cell
phone
and
you
got
started
seeing
cell
phones
that
had
5g,
but
it
was
just
kind
of
like
I
don't
know
where
I'm
going
to
use
it
or
when
it's
going
to
happen
well,
really
in
general,
it
actually
has
launched
and
it
has
been
really
taking
over
the
systems
here.
So
this
is
a
report
for
june
of
2021
22
000
5g
sites
already
with
under
160
operators.
B
B
I
can
talk
a
little
bit
more
about
that
as
well,
and
you
know
we
have
other
companies
or
other
countries
as
well
that
are
deploying
them
or
heavily
investing
in
them
or
doing
these
soft
launches.
I
think
originally,
when
I
first
read
about
5g,
I
think
it
was
like
korea
that
was
really
pushing
this
here
now
with
with
arm.
You
know
we
want
to
be
in
the
core
systems.
We
want
to
be
part
of
the
5g
core
of
the
lte
core.
Even
we
want
to
be
part
of
the
ram.
B
So
think
of
these
as
two
two
separate
systems
that
are
running
these
are
us
these,
and
you
know
these
radio
units
here,
so
you
get
a
phone
that
has
4g,
it
also
has
5g
and
then
from
there
the
phone
can
communicate
with
both
bands,
so
they're,
basically
doing
4g
and
5g.
Now
most
of
the
systems
may
not
have
the
5g
back
in,
especially
since
it's
still
kind
of
in
the
development
phase.
Right
now,
but
at
this
point
you
know
your
phone
is
able
to
utilize
both
4g
and
5g.
B
It
may
route
those
things
from
the
5g
genobid
to
the
enob
via
like
an
interface
but
either
way
you're
able
to
get
that
kind
of
faster
throughput.
Now
most
connectors
and
most
systems.
You
know
we're
connected
to
the
major
internet,
there's
also
different
applications,
and
things
like
that
that
are
outside
of
that
think
of
that,
maybe,
as
like
an
app
store
or
a
web
server,
those
kind
of
things
so
part
of
the
rm
enablement
here
is
you
got
to
think
of
it
in
kind
of
three
different
aspects.
So,
first,
you
know
we
have
the
system.
B
We
have
to
develop
a
system,
that's
utilized,
to
be
able
to
do
these
5g
these
aspects
of
that.
Then
you
also
have
to
write
the
software
that
enables
these
kind
of
things
acceleration
and
then
you
need
to
also
find
the
the
systems.
You
know
the
people
that
will
create
the
architecture
or
use
this
and
to
deploy
it
further.
So
that's
kind
of
like
the
three-step
process
with
arm.
B
You
know
to
find
something
that
is
utilized
and
takes
on
all
these
things
is
a
very
complex
and
and
hard
problem.
It's
not
something
that
you
can
just
basically
take
off
the
shelf
and
just
get
everything
up
and
running
a
lot
of
times.
This
has
to
be
customized
or
optimized
for
these
kind
of
aspects
now
with
arm.
We
really
wanted
to
target
these
with
a
software
and
a
hardware
vendor.
B
So,
as
you
know,
as
I
mentioned
before,
in
the
previous
slide,
you
know
we
wanted
to
be
in
the
core
network,
the
rick,
the
ran
itself,
the
l1
and
small
cells,
and
you
can
see
that
we
have
it
targeted
with
a
software
and
a
hardcore
company
in
most
cases
are
coupled
together.
So
that
way
we're
able
to
take
on
that
entire
life
cycle
of
the
previous
slide.
B
You
know
providing
the
silicon
for
it,
developing
that
getting
the
software
going
to
it
and
then
integrating
it
and
using
it.
So
we
are
part
of
almost
all
these
different
aspects
here
on
with
an
arm
now,
I
wanted
to
highlight
also
a
couple
other
aspects,
so
you
know
we
are
working
on
system
ready
system
ready
is
to
basically
make
a
system
universally
the
same
across
all
these
different
platforms.
So
there's
not
customized
software,
there's
not
customized
hardware
that
you
have
to
deal
with.
Everything
basically
runs
exactly
the
same.
B
B
So
I
mentioned
before
about
the
rix,
so
the
rick
is
the
near
real
time.
Rick
is
the
one
that
I
worked
on
and
that
I
ported
over
from
x86
to
arm
and
there's
a
couple
different
components:
there's
four
functional
components
of
this
rick.
So
we
have
the
orchestration
layer.
That's
that
non-real-time
rick
we're
talking
about
configuration
management,
maybe
you're,
adding
a
new
radio,
maybe
a
new
duc,
whatever
it
might
be,
and
those
are
basically
doing
non-real-time
slower
actions,
and
then
we
have
the
real-time
rick
itself,
which
is
a
component
between
those
or
sorry.
B
Underneath
this
here,
which
communicates
with
a
non-time.
Sorry
non-real-time
brick
takes
this
data
in
maybe
a
configuration.
Maybe
data
from
the
overall
system
does
something
with
it,
and
then
we
have
the
cu
stacks
and
the
dus
after
that.
Now
the
deployment
within
5g
itself
we're
using
a
lot
of
vnfs
these
virtualized.
You
know
systems
we're
using
containers.
The
idea
is
to
distribute
this
across
it.
It's
no
longer
some
giant
system
that
you
use.
B
That
has
one
piece
of
large
monolithic
software
that
runs
this
and
you
know,
is
dependent
on
this
huge
system
that
has
customized
we're.
Trying
to
open
it
and
we're
trying
to
make
it
so
that
way
we
can
scale
appropriately,
especially
you
know
when
I
mentioned
the
speeds
of
these
things.
You
know
4g
lte,
100
megabits,
5g
we're
going
to
4.7
gigabits
per
second,
I
mean
that's
a
crazy
amount
of
flow
and
performance
that
people
are
asking
for
you
know
and,
as
as
our
lives
become
more
and
more
digitalized
things
cost.
You
know
much
more.
B
B
So
let's
talk
about
the
the
rick
here,
so
real-time
rick,
we
talked
about
before
non-real-time
rick,
so
to
put
a
number
on
it
to
figure
out
how
often
these
things
are
changing
or
how
quickly
they
need
to
be
so.
This
is
the
overall
architecture
of
the
system
here.
So
you
know
we
have
the
non-rick
non-real-time
rick
here,
that's
along
with
the
service
management
orchestration,
that's
sitting
here
it
interfaces
directly
via
that
a1
to
the
near
real-time
rick,
and
then
this
itself
also
has
access
to
all
these
different
other
systems.
B
So
it's
taking
in
this
data.
Maybe
it's
chugging
on
this
and
doing
some
machine
learning
aspects
of
this
and
I'll
talk
a
little
bit
about
further
and
then
it's
modifying
the
behavior
of
all
these
other
systems.
So
with
the
the
rick.
This
is
a
new
aspect
of
5g
versus
4g.
This
is
a
system
that
helps
modify
and
optimize
it
with
4g.
It
was
just
kind
of
like
if
the
system
didn't
work
very
well
or
there
was
a
lot
of
people
utilizing
it
and
it
was
slow,
that's
just
kind
of
the
way
it
worked.
B
There
was
no
real
way
for
you
to
make
these
modifications.
If
you
know
a
good
example
is
like
everyone
goes
into
a
stadium
or
something
like
that,
and
you
have
you
know
thousands
of
the
people,
the
stadium,
you're,
gonna
start
getting
slower
service
and
unfortunately,
that's
not
a
real,
like
common
situation.
You're
going
to
have
them
all
the
time,
so
everyone's
going
to
deal
with
this
kind
of
service
degradation,
whereas
with
this
rick
we
could
say,
oh
hey,
I
see
a
ton
of
people
joining
in
they're
all
going
to
the
stadium
here.
B
Why
don't
we
start
directing
people
to
different
ru's
and
being
able
to
help
support
this?
So
that
way
we
can
get
more
people
on
the
network
and
they
can
get
their.
You
know
a
quality
of
service,
so
I
mentioned
x,
apps
so
x.
Apps
are
these
like
third-party
services
that
are
developed
either
by,
like
maybe,
let's
say
an
operator,
maybe
oran
itself
over
and
has
quite
a
few
applications
that
are
able
to
be
used
right
now
you
can
modify
them.
B
You
can
make
them
yourself
and
again
they're
taking
this
data
in
from
different
components
of
of
the
ran
itself
and
ingesting
that
and
doing
something
with
it.
You
know
in
some
cases,
maybe
you're
not
using
any
x
apps
at
all
and
all
it
is
doing,
is
just
management
aspect
of
it.
That's
that's
perfectly
fine,
but
the
real
kind
of
exciting
part
of
this
is
taking
that
data
in
controlling.
Can
change
things
instantaneously?
B
B
So
we'll
talk
a
little
bit
more
about
this
performance,
so
you
know
this
kind
of
breaks
it
down
a
little
bit
in
a
better
picture.
So
these
are
different
aspects
within
this
rick
and
I'm
kind
of
highlighting
these
different
x
apps.
So
these
are
kind
of
a
few
of
the
major
x
apps
that
are
being
pushed
by
oran,
obviously
again
they're
third-party,
so
you
can
make
them
yourself.
You
can
develop
them
yourself,
whatever
you
want
to
do
and
we're
talking
about
slicing
a
good
example
of
slicing
is,
let's
say
you
know
I
have.
B
I
have
maybe
a
medical
service,
a
bunch
of
different
ambulances
or
something
like
that
that
are
on
a
network
slice
of
5g.
I
have
a
bunch
of
cars,
maybe
smart
cars
that
are
doing
this
and
we're
doing
different
optimizations
for
every
one
of
those
different
things
here.
On
this,
like
slicing
app
here,
radio
connection,
optimization,
maybe
an
example
of
a
phone
that
has
5g
and
4g,
you
can
basically
auto
connect
and
say
hey
this
person's
ue.
B
This
user
equipment
should
go
and
connect
to
both
4g
and
5g
for
optimization,
like
maybe
maybe
this
tower
is
closer
to
here
or
this
radio
is
closer
to
here.
So
maybe
you
should
connect
to
this
one
instead,
so
these
are
very,
very
fast
interactions
with
each
other
and
that's
what
the
real-time
rick
is
doing.
It's
doing
these
modifications
and
decisions
very
very
quickly,
and
that's
kind
of
the
big
highlight
of
this
now.
What
comes
in
an
x-app,
so
an
x-app
can
leverage
lots
of
different
things.
B
This
graphic
here
is
really
good
to
kind
of
explain
what
aspects
these
things
can
do.
You
know
we
can
develop
it
and
go
c
plus
plus
python,
so
it
kind
of
opens
it
up
to
a
lot
of
different
people
to
be
able
to
do
this.
You're
taking
in
interface
data
you're
talking
about
the
a1s,
the
e2s
you're,
taking
the
data
from
all
that
system,
you
can
do
something
with
it
a
good
example.
B
B
You
can
tell
devices
hey,
you
know
we
have
more
people
join
in
our
5g,
so
let's
reject
them
from
using
5g
and
only
push
them
to
4g
if
they
only
have
if
they
are
dual
systems,
lots
of
different
aspects
of
that.
But
again
really
this
comes
down
to
you-
know:
load
balancing
quality
of
service
connectivity
management
hand
over
control.
These
are
all
things
that
this
is
really
important
on
that
aspect
of
this.
B
So
let's
talk
about
some
security
concerns.
I
mean
I've.
I've
mentioned
all
these
cool
things
about
the
rick
and
what
it
can
do
and
we
talked
about
how
it's
taking
these
decisions
and
they're
splitting.
You
know
instantaneous
decisions
on
the
system
and
modifying
them
changing
the
d,
the
cu,
the
ru
and
telling
it
you
know,
do
all
these
different
things.
So
that's
kind
of
a
big
deal,
that's
something!
That's
that
has
quite
a
bit
quite
a
bit
of
implications
with
this,
so
you
know
I'm
sure
a
lot
of
people
are
thinking
already
yeah.
B
Okay,
there's
already
these
problems,
we
get
it.
There's
no
big
deal
here,
but
I
want
to
kind
of
highlight
some
of
these
things
here
that
we've
that
you
know
that
are
concerns
of
this
aspect
here.
So
you
know
we
have
x
apps.
So
the
idea
is
that
this
is
controlling
the
eno
beads,
the
geno
beads,
the
c's,
the
du's.
B
So
a
lot
of
times
these
applications
are
probably
not
vetted
at
all
I
mean
an
operator
will
probably
do
a
good
aspect
of
trying
to
vet
them
themselves.
Maybe
their
motto.
You
know
maybe
they're
having
somebody
write
these
applications
for
them,
but
in
most
cases
people
are
not
probably
you
know
explicitly-
writing
exploits
into
them,
but
maybe
they're
using
older
methods
or
maybe
they're
using
other
packages
that
maybe
have
some
exploitations
on
them.
B
So
you
have
things
that
maybe
necessarily
are
not
dangerous
by
definition,
but
are
are
in
a
case
when,
when
you
know
an
appropriate
situation
comes
up,
the
other
thing
too
is
x.
Apps
are
not
just
a
single
thing:
you
run.
This
rick
can
run
many
many
applications
at
the
same
time.
So,
let's
say,
for
example,
you
know
you're
running
the
slicing,
you
know
application
x,
app
and
maybe
the
the
steering
one,
but
from
there
you
have
a
third-party
x
app.
B
That
also
interacts
with
other
components
of
that,
and
maybe
those
services
are
interacting
with
each
other
in
a
maybe
not
a
a
great
way.
Perhaps
you
know,
maybe
it's
resource
bound
or
there's.
You
know
having
some
issues
with
network
trafficking
or
routing
aspects
of
this,
and
then
you
can
also
have
multiple
of
these.
These
ricks
running
the
same
application
so
think
of
multiple
different
systems.
B
All
running
these
ricks
that
are
all
controlling,
different
d's
and
cu's,
and
perhaps
maybe
those
different
ones
are
interacting
with
each
other
or
those
applications,
don't
necessarily
are
able
to
communicate
or
when
they
do
communicate.
There's
other
problems.
I
think
another
big
aspect
of
this
is
the
process.
Starvation
aspect.
You
know
we
only
have
so
much
limited
resources
on
this
here.
B
B
So
you
know
our
security
policies
rely
a
lot
on
these
security
policies
aspects.
So,
let's
think
about
how
we
can
take
these
kind
of
this
cool
technology
and
then
bring
it
down
and
try
to
make
it
more
secure.
So
really
thinking
about
that
kata,
since
we
you
know
kubernetes
is
along
with
docker,
let's
think
about
kata
here.
So
kata
is
a
good
natural
fit
to
kind
of
secure
the
rick,
and
maybe
the
other
components
within
this
here.
B
So
let's
talk
about
deploying
the
rick,
so
kata
containers,
I'm
not
sure
if
everyone
has
seen
them
or
heard
them
before,
but
we'll
kind
of
go
over
them.
Basically,
here
so
kata
oci
compliant
runtimes,
basically
lightweight
virtual
machines.
So
we're
talking
something
that's
seamless,
I
can
take
a
docker
container,
modify
it
so
that
now
it's
running
kata,
it's
open
sourced
many
many
groups
all
use
this
here,
multiple
architectures.
B
So
that
way
you
know
if
there's
one
system,
that's
armed
one
system
at
66
or
they're,
all
armed
whatever
it
is
they're
all
going
to
be
able
to
work
there.
Then
you
have
multiple
hypervisors
on
this
here.
So
qemu
we
have
firecracker,
that's
a
very
popular
one,
that's
even
more
restricted
down
now
the
community
that
is
using
kata
is
growing.
Obviously
it's
very
large,
but
the
key
takeaway
here
that
I
wanted
to
talk
about
was
these.
You
have
some
intersections
here.
So
you
know
we
have
china,
no
mobile,
china
telecom.
B
Those
are
other
people
that
are
using
the
iran
alliance.
So
you
know
we're
or
china
unicom.
So
you
know
we're
we're
already
using
both
the
technologies.
It
makes
sense
to
just
kind
of
slap
them
together
here
to
kind
of
secure
that
that's
just
kind
of
one
of
the
takeaways.
I
wanted
to
bring
up
here,
so
we've
discussed
docker
containers
before
in
the
past.
I'm
sure
you've
used
them,
I'm
sure
everyone
has
talked
about
them,
but
you
know:
docker
containers
are
typically
used
resource.
You
know
they're
all
shared.
B
B
People
were
basically
running
vms
and
then
running
docker
containers
inside
those
vms,
but
then
we're
talking
about
large
systems
that
require
much
more.
You
know,
resources
that
are
able
to
run
on
this,
just
to
run
your
docker
containers.
The
other
aspect,
too,
was
isolation,
so
we
want
to
isolate
them
by
using
different
systems
completely.
I
mean
I,
I
guess
that
works,
but
at
this
point
you're
also
going
to
be
using
it's
going
to
cost
more
money.
It's
going
to
be
harder
for
maintenance.
It's
going
to
be
harder
for
orchestration
of
this.
B
Maybe
you
want
to
do
upgrades.
Bigger
problems
come
along
with
this.
So
then
we
move
on
to
kata
here.
So
kata
containers
are
basically
isolated
themselves
on
the
system
using
virtualization,
so
think
of
it
as
a
major
vm
but
miniaturized.
So
we're
talking
about
specialized.
You
know
miniaturized
reduced-sized
kernels,
for
each
one
of
these
here
hardware
is
virtualized
for
every
one
of
them.
There
is
no
intersection
between
each
other
here
so
for
the
case
of
kubernetes
vm
isolation
is
provided
at
the
pod
level.
Each
pod
is
booted
and
it's
a
lightweight
vm.
B
It's
a
unique
kernel
instance.
So
the
kernel
itself
can
be
modified
even
reduced
further
for
kind
of
an
attack,
surface
aspect
of
this,
and
now
each
pod
is
now
running
its
own
vm.
It
no
longer
has
access
to
the
host
kernel.
It
cannot
take
something
from
there,
which
is
basically
the
main
concern
of
dockers
in
docker
containers
itself,
and
then
you
get
the
full
security
of
being
that
vm.
B
Now
you
know
the
the
typical
scenarios.
You
know
you
have
a
bunch
of
docker
containers.
One
of
them,
you
know,
gets
maybe
an
exploit
against
it
or
some
issue.
Then
they
spread
across
all
of
them
or
you're,
doing
memory,
poisoning
or
some
aspect
of
that,
and
whereas
here
we're
all
isolated
individually
of
each
other.
B
So
let's
talk
about
orchestration,
so
I
I
haven't
gone
too
depth
up
here,
but
this
is
this
is
the
rick,
so
I
wanted
to
break
it
down
into
many
many
different
components
of
the
rick
itself.
So
as
we
look
at
this
entire
thing
is,
is
the
rick
here?
So
you
know
we
have
the
x
app
and
the
configuration
manager.
B
So
that's
the
thing:
that's
basically
taking
these
x
apps
and
deploying
them
onto
the
system,
they're
deployed
onto
the
x,
app
name
space,
and
you
know
in
this
illustration
we
have
many
many
different
x
apps
that
are
all
doing
different
out.
You
know
doing
different
things,
but
they're
all
within
that
same
name
space,
and
then
we
have.
You
know
the
a1
moderator
which
is
taking
the
a1
interface
that
we
talked
about
before
with
the
non-real-time
rick
those
those
different
aspects.
B
Here
you
know
by
having
them
just
as
single
docker
containers
yeah
there
is
some
inherent
security
that
you're
able
to
get
with
with
kubernetes,
but
just
think
of
the
implications
of
this
app
manager.
So
if
the
app
manager
was
to
be
modified
or
exploited,
perhaps
maybe
versions
of
these
applications
would
be
then
deployed
that
maybe
don't
necessarily
look
malicious,
but
maybe
do
something
more
licious.
Maybe
a
good
example
of
this
is
traffic.
Steering
I
I
always
every
couple
of
milliseconds
tell
them
to
move
to
a
different
system
or
a
different
argue.
B
So
then
the
entire
system
doesn't
work
very
well.
The
customers
are
having
quality
service
problems
or
perhaps
maybe
the
machine
learning
has
a
new
model
that
has
been
deployed
on
there.
That
causes
some
other
aspect
of
the
system
to
no
longer
work,
a
good
aspect
to
or
sorry
a
good
idea
also
is
the
mrr
rmr,
which
is
a
the
messaging
service
which
basically
goes
across
and
talks
to
all
these
different
systems.
So
if
you
were
to
induce
latency
into
that,
then
the
entire
system
that
brings
up
the
rick
no
longer
works
correctly
or
very
slow.
B
So
I
wanted
to
show
a
little
bit
more
about
like
a
kubernetes
kind
of
typical
aspect
of
this.
So
you
know
we
we
try
to
mitigate
these
by
putting
them
on
different
nodes,
maybe
perhaps
you're
running
them
on
vms,
and
you
know
on
the
one
on
the
left,
we're
talking
about
standard
containers,
standard
containers.
You
know
we
have
four
different
systems,
maybe
a
master
along
with
all
these.
These
additional
their
systems
here
and
to
separate
them
is
how
we
do
this
isolation.
B
You
can
run
whatever
run
time
you
want.
So
if
you
want
to
run
without
kata
as
an
example
on
the
far
right
they're,
not
using
cod
at
all.
So
maybe
this
is
just
some
other
application
that
you
have
no
concerns
with,
or
maybe
it's
test
environment.
I
have
no
idea,
but
within
this
here
you
know
each
one
of
them
is
running
on
the
single
node.
B
So
this
is
just
an
example
of
of
the
rick
and
I
wanted
to
talk
a
little
bit
more
about
the
the
different
aspects
of
the
name
spacing
on
there.
So
we
have,
you,
know
the
rick,
the
rick
apps,
so
each
one
of
those
apps
is
all
isolated
by
itself,
no
more
interaction
with
each
other,
and
then
you
know
we're
talking
about
the
rick
plc,
which
is
basically
the
the
the
initial
setup
of
the
system
and
then
the
infrastructure
that
runs
the
rick
itself.
Those
are
all
containerized
in
this
kata
environment.
B
So
how
hard
is
kata
to
orchestrate
and
what's
its
life
cycle
like
so
I'm
sure
a
lot
of
everyone's
like
okay
kubernetes
is
kind
of
hard
to
already
use,
or
maybe
you're
relatively
new
with
it.
It's
already
kind
of
it's.
It's
a
little
bit
mind-boggling
a
little
bit
at
this
point,
so
I
I
understand
the
the
kind
of
hesitance
of
that
I
know
you
gain
a
lot,
but
how
hard
is
it
to
use
and
manage
well
to
basically
get
kata
running?
There's
only
a
few
different
steps
that
have
to
be
done.
B
You've
got
to
install
or
compile
version.
2
of
kata.
You
got
to
modify
your
container
d.
You
got
to
modify
the
runtime
classes
for
kata
and
then
just
modify
your
plugins
from
there.
It's
basically
plug
and
play
you
from
there
are
then
now
using
kata
on
there
and
you
can
change
it
for
different
hypervisors.
So,
let's
say,
for
example,
you
want
to
run
some
as
firecracker
some
as
the
qme,
so
you
have
lots
of
different
options
and
it's
just
a
relatively
modification
of
you
know
a
bunch
of
yaml
files
and
that's
it
so.
B
The
kata
agent
is
running
on
the
guest
system,
that's
basically
supervising
and
managing
these
containers,
so
it
is
a
separate
system.
You
know
compared
to
like
cube
control
aspects.
You
know
you're
not
going
to
want
to
look
at
to
see
which
which
containers
are
running,
kata,
upgrading,
modified
and
modifying
those.
So
there's
a
little
bit
of
upkeep.
That
is
a
little
different,
but
not
by
far
many
many
steps
or
anything
like
that,
and
then
we
can
also
use
the
lib
container
to
manage
the
life
cycle
of
this
container
as
well.
B
So
the
idea
is
that
you
can
reuse
aspects
of
this
and
then
be
able
to
deploy
a
brand
new
pod,
a
brand
new
container,
whatever
you
want
to
do
with
that
here
and
and
then
it's
also
responsible
for
the
entire
life
cycle,
so
kubelet
is
still
taking
care
of
the
entire
system.
It's
not
like.
You
have
an
entire
separate
item
that
does
this,
so
I
want
to
talk
a
little
bit
about
conclusions,
so
we
talked
a
lot
about
5g
a
lot
of
the
aspects
of
it.
B
B
I'm
not
saying
kata
is
the
one
I'll
be
all
that
is
not
the
case
here,
but
the
idea
is
that
it's
a
very
simple
decision
that
can
be
made
to
help
modify
this
and
make
it
more
secure
than
it
inherently
is
currently
and
then
the
complexity
of
solving
this
has
a
combination
of
different
tools
that
are
already
readily
available
right
now,
and
then
it
also
is
supported
by
arm.
So
one
you're
going
to
get
the
the
security
aspects
of
the
oran.
B
So
I
wanted
to
also
mention
too,
that
I'll
be
attending
along
with
a
couple
of
my
other
colleagues
kubecon
hope
to
see
you
guys
there
we'll
also
be
on
the
virtual
and
physically
there
as
well,
and
then
we
also
have
arm
dev
summit,
which
is
coming
up
as
well.
Hopefully,
you
can
also
join
that
and
learn
a
little
bit
more
about
arm
itself
and
how
to
integrate
your
systems
with
them,
and
then
I
also
wanted
to
include
some
of
the
blogs
that
we
have
talking
about
5g
and
the
cassini
project,
and
that's
it.
B
Thank
you
very
much
for
your
time.
I
hopefully
this
was
educational
and
was
helpful.
If
you
have
any
questions,
please
you
know
put
them
in
the
chat
and
I'll
do
my
best
to
talk
to
you
about
those
now,
if
you
have
specific
questions
about
arm
and
about
maybe
it's
roadmap
or
some
questions
like
that,
I
can
definitely
direct
those
to
like
go
to
market
strategy
people
where
they
can
reach
out
to
you
to
provide
more
detail
to
you.
B
B
Okay,
so
what's
the
problems
with
containers
original,
not
not
kata,
so
basically,
the
idea
is
that
the
the
containers
are
using-
let's
say
say:
kubernetes
with
docker,
so
docker
is
utilizing
shared
resources
across
this.
So,
for
example,
if
one
of
the
system
or
one
of
the
docker
containers
is
utilizing
a
piece
of
memory,
perhaps
another
service,
that's
running
the
docker
container
or
on
the
system
itself
can
cause
either.
B
Let's
say
memory
poisoning
you're,
putting
something
in
there
that
the
docker
container
can
read
or
maybe
you're
modifying
another
container,
where
you're
doing
breakouts
from
that
kata
itself
is
able
to
mitigate
that
by
using
the
vm.
I'm
not
saying
the
vm
is
a
hundred
percent.
The
right
answer,
I'm
just
saying
that's
much
easier
by
virtualizing
the
entire
system
and
its
resources
than
to
just
directly.
You
know
share
it
across
so
why
arm
is
only
porting
from
x86.
I
remember
similar
efforts
being
done
by
epc.
B
Why
not
natively
build
a
rick
on
arm
architecture
to
build
more
efficient
solutions,
trying
to
understand
what
maybe
the
limitations
here
on
arm?
So
the
idea
was
that
previously
on
some
of
these
telecom
systems,
they
were
mostly
built
on
specialized
architectures
or
specialized
systems.
You
know
major
throughput
systems
here.
X86
is
just
kind
of
like
the
typical
partner
that
was
done
on
here.
So
most
of
these
systems
were
already
developed
on
x86
in
mind.
B
Arm
itself
is
in
the
pro
you
know,
is
we're
pushing
towards
getting
this
completed
and
moving
forward
on
there.
So
we,
the
porting
process,
is
just
something
that
we
did
this.
You
know
to
bring
it
over
to
here,
but
in
the
future
I
don't
see
a
reason
why
arm
would
not
be
developing
these
these
applications
or
these
architectures
itself
to
help
optimize
them,
but
that's
just
to
answer
why
the
rick
itself
was
ported.
B
So
if
security
concerns,
why
not
use
firecracker,
as
you
mentioned
more
as
restrictive
instead
of
kata,
so
kata
is
the
vm
arc?
Is
the
same
insect?
Is
the
vm
itself,
firecracker
qme?
Those
are
the
hypervisors,
so
you
could
use
firecracker.
It
is
more
restrictive.
That's
that's
perfectly
fine!
A
lot
of
people
do
use
it.
It's
just
much
more
restrictive.
I
guess
it
kind
of
depends
on
what
you
know.
It's
different
flavors.
Whatever
you
choose
to
pick.
B
How
can
we
manage
the
containers
via
openstack
kubernetes,
so
kind
of
containers
are
typically
managed
through
the
the
kata
agent,
but
the
entire
system
is
still
orchestrated
through
kubernetes.
So
there's
not
necessarily
like
one
option
or
all
options,
the
I
don't
know
if
it
works
with
openstack.
I'm
not
I'm
not
completely
sure
on
that.
I
have
not
used
it
in
that
aspect,
but
you
should
be
able
to
be
able
to
utilize
deploy
check
the
status
of
those
containers.
B
B
Okay,
any
performance
impact
detected
on
kata
and
run
c
yeah,
so
there
is
some
inherent
performance
impact
you
know,
always
if
you're
adding
extra
layers,
there's
always
going
to
be
something
that's
going
to
slow
it
down.
So
I
am
not
saying
that
by
switching
from
direct
kata
containers
on
kubernetes
that
you
will
see
the
exact
same
performance.
That
is
not
the
case.
I
mean
you'd
still
see
the
same
exact
impact
done
on
the
previous
mitigation
for
docker
containers
when
you
ran
them
as
a
vm
and
then
ran
the
docker
containers
in
there.
B
One
there's
the
orchestration
aspect
of
that.
But
performance
is
you
know
you?
You
have
an
entire
system
that
has
to
deal
with
all
the
virtualization
of
a
much
larger
system,
all
these
kernels,
this
much
larger
kernel
with
a
lot
of
different
impact
on
that,
whereas
kata
has
a
symbolized
slim
diversion
of
this
of
this
kernel,
so
it
may
not
have
all
of
the
different
aspects
as
a
full-fledged
system,
but
you
know
you're
you're
still
going
to
get
some
impact.
That
is,
100
percent
gonna
happen.
B
B
B
Okay,
supporting
the
legacy
via
vns,
okay
yeah,
so
that's
kind
of
the
big
overlying
thing
with
5g.
Is
you
know
before
with
4g
3g
or
even
previous
technologies?
I
mean
you're
talking
about
proprietary
systems
that
are
running
major
applications
that
do
everything.
These
are
not
configurable
outside
of
like
the
initial
setup
and
run
of
this,
whereas
now
we're
pushing
more
towards
the
container
the
vnfs
to
be
able
to
run
these
systems
independently
scale
them
appropriately
run
them
upgrade
them
very
quickly.
B
That's
kind
of
the
overarching
theme
of
5g
is
to
be
able
to
do
this
much
quicker
much
faster.
Instead
of
you
know
buying.
You
know,
I
don't
know
hundreds
of
thousands
of
dollars
of
equipment
for
each
one
of
them
and
that's
how
you
upgrade
is
by
buying
another
one.
Now
you
can
scale
those
resources
appropriately.
B
Some
5g
setups
have
special
network
requirements
like
okay.
Do
these
apps
adapt
to
this
use
case,
so
the
x
apps
itself
can
be
developed
by
the
operators
they
can
develop
by
third
parties.
So
I
don't
see
a
reason
why
any
of
these
applications
could
not
be
developed
in
a
special
requirements
for
those
operators.
The
idea
is
to
utilize
and
leverage
these
these
x
apps,
to
make
things
much
faster,
to
be
able
to
utilize
and
modify
change
change
system
almost
instantaneously.
So
I
don't
see
reason
why
not.
B
I
guess
the
only
aspect
that
I
can
say
is
that
you
know
the
oran.
The
x-apps
itself
are
relatively
new-ish.
You
know
these
systems
are
being
deployed
as
we
speak.
People
are
utilizing
them
now,
so
there's
always
going
to
be
some
bugs
that
have
to
be
worked
out
for
these
kind
of
systems,
but
I
don't
see
a
reason
why
this
would
not
be
a
direct
replacement
of
of
previous
systems.
The
whole
idea
of
the
oran
alliance
is
to
provide
a
system
that
is
now
more
open
to
reduce
the
vendor
lock-in.
B
B
Again,
if
you
have
other
questions
too,
that
maybe
I
don't
I'm
not
clear
on-
maybe
that's
strategy
wise
where
arm
fits
in
this?
What
arms!
You
know
what
what
they're
planning
to
go
further
on
within
5g!
I
can
always
reach
out
to
or
go
to
market
people,
to,
provide
you
better
details
and
have
them
reach
out
to
you
as
well.
A
Everybody
thank
you
so
much
for
joining
us.
Thank
you,
kyle,
for
a
great
presentation,
just
a
reminder.
This
recording
will
be
online
later
today
and
if
you
have
any
questions,
please
feel
free
to
reach
out
to
us
at
online
programs
at
cncf.io
and
thanks
everyone
for
joining.
Thank
you,
kyle
yeah.
Thank
you.
Have
a.