►
From YouTube: CNCF Telecom User Group 2021-04-05
Description
CNCF Telecom User Group 2021-04-05
A
A
B
A
A
A
C
They're
still
trying
for
it
to
be
in
person,
you
know
it's
a
lot
of
variables.
You
know
current
plans,
I
believe
from
the
agenda.
You
know
the
events
team
is
to
have
it
in
person.
I
think
it's
october,
12th
or
15th
ish
sometime
during
that
week
in
la
so
wear
masks
can
get
vaccinated,
we'll
see
what
happens
but.
B
A
E
E
A
A
A
A
D
D
I
don't
know
if
there's
interest
in
us
like
kind
of
pushing
it
forward.
I
think
felipe
has
interest
if
we
wanted
to
try
to
start
working
on
another
document
within
the
telco
user
group.
I've
kind
of
just
been
using
it
as
a
dumping
ground
for
thoughts,
but
I
put
in
real
work
if
other
people
were
interested
and
thought
there
was
value
in.
E
D
Yeah,
just
in
general,
I'm
kind
of
curious
where
we
want
to
head
as
part
of
the
tug
when
I
think
of
user
groups,
I
kind
of
think
of
more
like
people
within
a
specific
user
group
looking
for
help
with
something
I
think
the
challenges
paper
could
be
a
way
for
us
to
kind
of
put
some
information
out
like
I
said
it's
really
just
a
collection
of
thoughts.
So
getting
a
little
bit
more
specific.
I
think
that
there
is
challenges
that
maybe
have
arrived
arisen.
D
D
D
It
seems,
like
you
know,
it's
an
entry
level
use
case
until
you
realize
that,
like
green
blue
deployments
become
really
really
challenging,
depending
on
how
restrictive
or
permissive
your
firewalls
are
coming
in
and
out
of
your
data
centers.
So
you
know,
suddenly
you
have
to
like
start
looking
at
a
higher
level
of
workflow
if
you
want
to
grab
an
entirely
new
subnet
for
the
new
node
you're
provisioning,
to
do
a
fresh,
install
things
like
that.
D
D
Yeah,
I
think
it's
really
whatever
this
group
wants.
Like.
I
said
it's
really
just
a
collection
of
notes.
I
mean
that
act
was
just
like
a
placeholder
and
it's
super
out
of
date
at
this
point,
it's
like
almost
two
years
old
or
something
so
we've
kind
of
done-
a
lot
of
work
in
the
cnf
working
group
around
identifying
actors.
D
So
I
I
would
think
that
it'd
probably
be
more
valuable
to
potentially
write
a
paper
where
we
give
multiple
actors
points
of
view,
because
you
know
challenges
are
not
just
it's
hard
to,
like
lifecycle,
manage
a
cnf
right
like
something
as
simple
as
I've
got.
My
own
monitoring,
stack
and
tal
wants
to
provide
me
a
better
monitoring,
stack
or
integrate.
You
know
his
stack
into
my
stack.
How
does
that
work?
G
G
Now
I
mean
you're
absolutely
right.
There
is
a
lot
of
focus
on
kubernetes
in
applications,
but
at
the
end,
when
you
start
you
know
putting
this
in
a
production
or
in
a
commercial
operation,
once
you
have
some
kind
of
interaction
between
all
these
applications
and
provide
service
or
services,
and
this
is
in
a
way
already
specified
in
the
3gpp
and
now
because
of
different
roles.
G
G
But
what
is
the
purpose
of
this?
Isn't
that
the
services-
and
there
are
certain
specifications
that
are
you
know
indicating
if,
again
sorry
to
repeat
myself
on
the
latency,
I
can
give
you
some
of
the
requirements,
and
you
know
most
of
the
mobile
network
operators
are
actually
co,
complaining
that
you
know
from
0
to
11
milliseconds
that
delay.
You
cannot
provide
it.
So
just
give
me
50.,
but
that's
the
third.
If
you
look
at
the
subscriptions,
that's
more
or
less,
you
know
the
silver
subscription.
G
G
I
mean
I'm
a
little
bit.
You
know
surprised
that
there
is
almost
none
of
reference
towards
the
three
gpp
specifications
on
the
services,
because
also,
as
you
see
even
again,
sorry
to
be,
you
know
refer
to
the
5g,
but
in
the
network
functions
related
or
applications
related
to
network
functions.
The
context
is
separated
from
the
business
logic.
You
can
go
deep
down
on
this.
Compute
and
storage
is
actually.
There
is
a
particular
functionality
where
this
is
separated
and
this
is
stored
in
separate
places,
but
again,
sorry
to
repeat
myself.
G
G
H
G
F
G
H
G
A
So
if,
if
you're
saying
out
there
there's
already
a
lot
of
the
concerns
that
have
been
written
in
specifications,
that's
what
we
want
to
pull
out
we're
not
interested
in
saying
that
a
specific
technology
is
solving
it
somewhere
else.
That
could
be
another
document,
but
what
jeffrey's
saying
is?
Should
we
write
out
the
underlying
concerns?
So
if,
if
you
have
some,
you
know
knowledge
or
there's
papers
that
can
be
sourced
from
or
whatever,
then
it
sounds
like.
There's
interest
in
this
writing
out
the
concerns.
D
Yeah,
I
don't
think
we
have
to
stick
to
one
paper
too,
like
observability,
you
know
we
talk
about
that
being
like
one
of
these
pillars
of
things
going
forward.
Anybody
who's
ever
tried
to
like
get
true
observability
and
a
super
heterogeneous
environment
knows
that
that
can
be
a
struggle.
I
mean
we
could
do
like
a
macro
level
paper.
We
could
find
people
who
you
know
specialize
to
be
fair.
D
Ike
too,
it's
called
the
telco
user
group,
but
those
of
us
on
the
service
provider
side
have
just
gotten
used
to
everybody,
calling
everybody
generically
telcos,
regardless
of
whether
or
not
they
have
a
mobile
network
or
not,
but
the
I
mean
I
think,
for
the
most
part
taylor
correct
me.
If
I'm
wrong,
this
is
really
kind
of
yeah,
like
the
csp
user
group
in
the
cncf,
we
just
all
get
the
telco
label.
A
And
to
your
point
earlier
on
getting
input
from,
I
think,
there's
some
questions.
Maybe
victor
you
had
asked
about
vendor
versus
service
provider
side.
So
the
end
and
jeffrey
responded
that
we
want
different
voices,
maybe
with
the
multiple
papers,
whether
it's
multiple
papers
or
at
least
different
chapters.
I
think
it
would
be
good
to
have
one
actor
one
voice
for
a
section
so
that
it's
very
clear
when
someone's
reading
that
what
perspective
are
they
coming
from
it's?
A
A
D
I
think
to
start
guys,
maybe
we
set
up
a
second
complimentary,
google,
doc
and
kind
of
go
into
the
original
one
pick
and
choose
some
of
the
topics
I
mean
unless
we
want
to
write
like
a
really
long
document,
which
is
fine.
If
not,
I
think
we
should
kind
of
pick
a
couple
actors
and
then
pick
a
one
or
two
challenges
that
those
two
actors
face
together
and
then
you
know
we
could
maybe
do
like
a
series
of
things.
D
Finished
exactly
so,
I
I
think
yeah
just
picking
a
focus
like
we
could
pick
something
like,
like
you
said,
like
observability
or
software
delivery,
or,
I
would
say,
like
one
of
the
big
ones
that
always
comes
up
right.
Is
we
do
a
paper
just
on
the
relationship
between
a
provider,
an
app
vendor
and
a
platform
vendor
or
provider
right,
and
I
mean
it's
just
talking
about
like
figuring
out
the
actors
and
that
can
be
challenging
right.
Sometimes
the
provider
builds
and
maintains
its
own
platform.
D
Sometimes
it
builds
part
of
the
platform
and
outsources
the
other
part,
but
like
that's
something
that
in
almost
all
these
groups
that
I'm
in
we're
always
like
having
discussions
around.
What
is
the
platform
responsible
for?
How
do
you
manage
the
life
cycle
of
the
platform
same
thing
with
the
application?
How
does
the
provider
stitch
those
two
worlds
together?
I
think
that
could
be
like
a
potential
interesting
one
to
start
with.
I
don't
know
just
because
it
keeps
coming
up
a
lot,
but
we
always
have
these.
G
Jeffrey
the
may,
I
just
suggest
a
slightly
different
approach,
because
I
mean
you're
absolutely
right.
It's
not
that
I
disagree.
I
just
would
like
to
you
know,
lift
up
slightly
different
approach
because
of
the
shift
that
we
are
seeing.
I
mean
traditionally
that
has
been
very
much
as
all
the
services
had
been
deployed.
You
know
there
is
a
network.
There
is
a
platform,
there
is
an
applications,
but
now
there
is
an
evolving
towards.
You
know,
shift
from
the
process
centric
to
data
centric.
D
I
D
Look
for
alternatives
to
kubernetes
when
you
say
data
centric.
Are
we
talking
about
like
looking
at
different
underlying
hardware?
Like
you
know,
memory,
centric
architecture
versus
compute
centric,
you
know,
processing,
centric
architecture
like
I'm,
not
100,
sure
what
you're
you're
specifically
referencing
here.
G
A
So
right
now,
there's
no
suggestion
from
jeffrey
to
look
at
technology.
It's
it's
talking
about
what
are
the
underlying
drivers
before
you
pick
any
technology,
so
the
looking
at
relationships
between
actors
is
not
a
focus
on
what
technology,
a
service
provider
and
a
vendor
and
an
integrator.
It's
not
talking
about
that.
It's!
What
are
the
underlying
business
reasons,
so
are
you
suggesting
some
different
way
of
getting
to
this
goal?
G
Well,
I
mean
in
a
way
this
is
very
much
related
to
business,
but
I
mean
there
is
some
kind
of
a
new
frameworks
where
you
can
discover
resources
very
much.
You
know
nodes
that
are
using
or
generating
or
processing
particular
type
of
data
and
data
characteristics,
and
then
you
can
discover
and
then
you
can
connect
it,
but
instead
of
looking
at
the
applications,
the
the
starting.
The
key
point
is
semantics,
and
the
data
characteristics,
for
instance
temperature
temperature
of
the
room.
You
know
different
classes.
G
Currently
you
cannot
use
multi-typing
and
then
you
cannot
sub
classify
whether
this
room
is
a
kitchen
or
a
bathroom
or
a
living
room,
but
there
the
temperature,
then
are
you
measuring
the
sense
that
are
you
providing
the
the
data
of
the
sensors
in
the
room,
or
are
you
providing
the
temperature
of
the
room?
Now,
if
you,
if
we're
gonna,
focus
on
the
applications,
which
is
perfectly
okay,
we
will
be
most
likely
providing.
You
know
as
a
as
an
example
the
applications
information
that
is
on
the
particular
units
that
are
providing
the
data
or
of
you.
A
I'm
clear
on
what
what
you're
suggesting
so
we're,
what
we're
actually
doing
is
stepping
lower
than
that.
So,
if
we,
if
we
were
just
going
to
put
a
stack
and
say
here's
a
particular
application,
and
then
you
say
what
is
it
providing
us?
Well,
you
could
go
lower
and
say
here
are
maybe
data
points
and
statistics
on
on
what's
being
used
and
what's
necessary,
we're
actually
going
below
that
and
saying
what
are
the
business
needs
now
you?
A
If,
if
you
want
to
point
to
any
studies
out
there
that
say
general
needs
of
a
s,
you
know
of
a
service
provider
and
csps
in
general,
then
that
would
be
great,
but
we're
not
talking
about
applications.
Jeffrey
is
not
suggesting
that
we
study
the
current
applications
available
for
kubernetes
or
any
other
platform.
G
D
I
don't
think
that
we
necessarily
have
to
limit
ourselves
to
one
paper
too.
You
could
just
drop
your
name
below
mine
and
let's
get
a
second
initiative
going
to
taylor's
point,
though
I
mean
when
you
start
talking
about
like
iot
sensors
and
how
I'm
extrapolating
data
like
the
specific
challenge
I'm
talking
about,
is
I
have
three
vendors
each
offering
me
a
sensor.
D
I
have
a
business
requirement
that
drives
all
three.
How
do
I
actually
like
consume
this
without
creating
completely
separate
tool
chains
for
everything
like
how
many
layers
of
abstraction
is
appropriate
to
like
get
some
kind
of
point
of
commonality?
Before
I
have
so
many
layers
of
abstraction
that
I
can't
actually
troubleshoot
anything
so
like
to
taylor's
point,
I'm
kind
of
like
a
level
removed
to
what
you're
talking
about,
but
there's
nothing
that
would
prevent,
like
the
tug
from
looking
at
two
topics
at.
I
Once
so,
I
allowed
my
two
cents
here,
I'm
confused,
I'm
looking
at
the
document
and
trying
to
understand
what
what
the
goals
would
be.
You
know
it's,
obviously
one
level
removed
from
the
technologies,
but
how
far
are
we
really
removing
ourselves
from
the
problem?
It
seems
like
it.
You
know:
if
we're
talking
about
challenges
we
have
to,
we
have
to
go
back
to
the
whole
idea
of
nfv
and
what
was
trying
to
be
achieved
by
combining
telco
with
cloud
technologies.
Some
of
this
a
lot
of
this
stuff.
I
These
challenges
predate
kubernetes
and
kubernetes,
isn't
mentioned
right
right.
If,
if
we,
if
we
want
to
create
a
document
like
this
specifically
within
the
cncf
telecom
user
group
context,
I'm
trying
to
understand
what
is
very
special
and
specific
about
it.
Well
cloud
native
kubernetes,
so
should
the
paper
be
specifically
about
I,
I
can
see
it
going
into
two
separate
directions:
one
which
is
very
kubernetes
centric.
I
Another
direction
this
can
go
is
not
kubernetes
specifically,
but
cloud
native,
specifically,
that
is
taking
the
cloud
native
concepts
which
could
work
on
openstack
could
work
on
legacy
clouds.
They
are
not
kubernetes,
specific
and
think
about
those
approaches
and
what
challenges
they
might
have
for
for
business
reasons.
So
right
now,
I'm
not
sure
which
direction
we're
going
exactly,
and
it
seems
a
little
bit
vague
to
me.
A
Al
one
of
the
things
that
you
said
in
there
seems
to
me
to
be
behind.
It
would
be
a
goal
that
jeffrey
is
trying
to
put
forward.
I'm
going
to
say
it
and
jeffrey.
Tell
me
if
I'm
wrong,
you
said
tal
that
nfv
and
other
efforts
predating
kubernetes
have
tried
to
solve
many
of
the
problems
that
have
been
seen.
A
The
first
thing
that
we
want,
which
is
not
documented
in
this
group
fully
anywhere-
and
I
don't
see
it
publicly
everywhere
anywhere
within
the
cncf
and
kubernetes
community-
is
what
are
those
problems
so
what
problems
that
did
nfv
try
to
solve
that
we
can
see
outside
the
technology
right
now.
All
I
see
is
solutions
being
put
forward,
but
no
information
about
what
is
it
trying
to
solve,
and
I
think
jeffrey
is
wanting
to
underline.
I
I
that
that
sounds
good.
If
that's
true
jeffrey,
I
mean
this
is
a
very
ambitious
document
and
in
a
way
I
think
it's
it's
we've
reached
that
point
that
we
need
to
rethink
our
our
initial
problems
right,
because
a
lot
of
what's
happening
right
now,
with
the
move
to
cloud
native,
you
know
from
vnf's
to
cns,
depending
on
who
you're
asking
it
is
an
evolution
right
you're
with
vns.
We
did
things
one
way
with
cns
we're
doing
things,
maybe
in
a
better
way,
but
I,
I
think,
there's
a
reckoning
that
needs
to
be
done.
I
You
know
before
just
evolving
and
moving
forward.
It
is
worth
going
back
to
the
original
problems
that
nfe
was
trying
to
solve.
What
were
our
challenges
then,
and
maybe
look
at
how
we're
trying
to
solve
them
right
now,
with
with
our
new
understanding
of
what
a
cloud
can
be
right
so
in
a
way
leapfrogging
all
over
the
history
of
nfv
and
rather
than
seeing
it
as
an
evolution
of
what
happened
before,
maybe
going
back
to
the
drawing
table,
and
this
would
be
the
drawing
table
and
and
reconceptualizing
what
are
our
challenges?
I
D
Right
well,
and
so
your
initial
question
tal,
the
answer
is
generic.
Yes,
this
is
also
why
I
was
saying
we
might
need
to
split
this
up
like
get
very
specific
focuses,
but
to
me
there's
what
you
were
just
describing,
which
I
would
think
is
kind
of
the
initial
journey,
and
then
the
second
journey
is,
you
know
what
shortcomings
does
kubernetes
have.
The
thing
is,
though,
is
how
are
we
measuring
kubernetes
shortcomings
right?
There's?
D
Yes,
your
point
of
like
not
assuming
that
we're
already
doing
everything
right,
because
we
keep
driving
along
like
we
are,
but
then
everybody
says
they
don't
like
how
things
have
gone
up
to
this
point
and
to
your
point
like
really
when
it
comes
to
down
to
it,
is
a
you
know,
a
vm,
a
container,
etc.
We're
just
like
discussing
packaging,
really
right,
like
how
coarse
or
how
fine
is
this
packaging?
How
am
I
like
carving
up?
D
You
know
the
measurable
unit
of
code,
I'm
delivering
etc,
but
there's
things
like
you
know
like
self-healing
networks
right
like
way
before
kubernetes
came
around,
we
had
talked
about
like
vnfm's
like
respiting
up
vms
that
have
gone
down
and
auto
healing
and
this,
and
that
did
it
ever
really
pan
out
no
does
slapping
kubernetes
in
the
middle
of
it.
You
know
help
things.
No,
so
I
mean
like
when
we
say
we
want
something
to
like
self
heal.
What
does
that
actually
mean,
and
is
it
feasible
horizontal
scale?
D
Is
that
feasible
like
do
we
actually
want
it?
There's
just
all
these
things
right,
like
these
generic
assumptions
that
someone
put
on
a
document
once
upon
a
time
and
we
keep
dashing
our
heads
against
the
wall
and
coming
up
with
new
ways
like
do
I
really
care
if
we
use
tosca
versus
yang
versus
ammo,
not
really
the
question
is:
is:
can
I
actually
model
the
network
service
or
the
network
device
that
I
need
appropriately
with
it
right?
So
I
would
say
that
it's,
the
latter.
D
Sorry,
the
former
is
the
first
goal,
but
I
think
you
know
subsequent
things.
You
would
start
to
look
at
well
now
that
we've
identified
what
we
actually
want.
Can
we
actually
meet
those
needs
with
the
tools
that
we
have
today,
and
if
not,
what
tools
do
we
lack?
What
tools
could
potentially
be
retrofitted,
etc?.
I
Okay,
that
that
makes
a
lot
of
sense
to
me.
I
I
think
it
would
be
ambitious
and
I
think
we'll
eventually
have
to
break
down
these
challenges
into
into
areas
right.
Some
of
them
are
more
technological,
we're
not
speaking,
maybe
about
specific
technological
solutions,
but
specific
technological
challenges
in
terms
of
networking
and
and
hardware
and
and
support
for
that.
I
But
some
of
them
are
really
architectural
right
things
like
orchestration
and,
as
you
said,
modeling
and
you
know
we're
not
we're
going
back
to
basics
to
an
extent,
but
we're
also
learning
from
what
we
did
learn
the
lessons
that
we
did
learn
from
nfv.
What
worked
and
didn't
work
as
well,
so
I
think
you
know
we
don't
have
to
go
completely
down
back
to
a
starting
point.
That
knows
nothing,
because
we
we've
learned
a
lot
in
the
last
five
to
ten
years.
Trying
to
do
this.
A
I
A
Now
I
do
think
we
should
go
back
to
the
very
basics
and
breaking
it
down
into
the
smallest
component
that
our
challenge
breaking
the
challenges
down
to
where
we
can
focus
and
when
you
say,
there's
a
technological
or
an
architectural
challenge,
whatever
it
is.
What
is
underneath
that,
where
we're
saying
orchestration
is
important?
Okay,
why
are
you
doing
it?
It
seems
perfectly
normal
to
anyone,
that's
managing
or
doing
orchestration
management
on
a
day-to-day
basis.
The
problem
is
you're
stuck
in
the
middle
and
you're
not
going
to
step
back
and
go.
A
Is
there
a
different
way
for
me
to
handle
the
underlying
reason?
Why
I'm
doing
this,
and
this
this
paper
right
here
or
the
paper
that
we
had
up
from
jeffrey?
That
was
the
ask:
what
are
those
underlying
things?
Why
are
we
saying?
What
are
we
doing
with
orchestration,
and
just
a
moment
ago,
jeffrey
was
naming
a
few
things
he's
actually
saying
here
are
some
of
the
underlying
things
that
we
want,
and
over
and
over
in
the
communities.
A
I'm
hearing
that
the
other
side,
specifically
within
the
large
csp
networking,
it's
the
we
already
have
a
lot
of
background.
We
don't
need
to
talk
about
it,
we
don't
need
to
go
back,
but
there's
an
ask.
I
mean
jeffrey's
asking
and
I've
heard
other
other
people
in
this
community
that
are
asking
so
that
on
this
particular
paper,
the
idea
is:
let's
go
as
far
back
as
we
can
with
the
basics.
I
Yeah,
I'm
I'm
absolutely
fine
with
that.
My
the
point
I'm
trying
to
make
is
that
if
we
do
it
honestly,
if
we're
very
honest
about
going
back
to
those
basics
20
years
before
then
we're
opening
up,
we
really
have
to
open
up
us
ourselves
up
to
the
idea
that
maybe
cloud
native
is
not
the
solution.
Right
kubernetes
cannot
be
the
if
we're
setting
kubernetes
as
the
goal
that
we're
trying
to
put
well,
then
we're
not
honest
about
examining
the
problems
right.
I
A
Disagree
with
you,
we
absolutely
shouldn't
think
cloud
native
is
the
end
goal.
Whenever
we're
looking
at
this,
we
also
should
not
say
nfv
is
they've
solved
it.
We
shouldn't
look
at
any
of
it.
You
can
go
further
back
and
go.
Oh,
there
was
actually
pretty
amazing
hardware
solutions.
Let's
go
back
to
vms
on
mainframe.
Well,
that's
a
lot
of
the
software
technology
we
have
today
is
literally
from
vm's.
The
the
hardware
redundancy
in
mainframes
is
now
in
your
vm
and
software,
so
that
the
point
is
not
those
any
of
those
installations.
A
It's
what
was
underlying
driver
and
that's
the
when
jeffrey
was
saying
the
relationships
between
the
parties
for
getting
the
data
from
these
data
centers.
What
is
that's
an
underlying
challenge
which
we
may
come
to
a
technological
solution?
The
next
papers
after
that
that
someone
could
build
on
in
this
group
or
maybe
a
totally
different
group?
A
I
Yeah,
I
think,
that's
all
true.
I
think
the
the
complexity
here
that
it's
really
not
going
to
be
one
paper,
because
the
challenges
are
it's
a
tree
structure
right,
a
challenge
would
depend
on
what
solution
you
chose
to
meet
an
earlier
challenge
right.
So
if
you
think
that
the
flexibility
that
you
need
to
solve
your
networking
solutions
involves
using
off-the-shelf
cloud
software,
such
as
openstack
or
or
kubernetes,
and
that
presents
challenges
according
to
the
choice
that
you
made
there
right,
for
example,
orchestration.
I
D
How
do
we
make
this
stuff
work
in
kubernetes
and
that's
kind
of
come
over
a
few
months
of
debate
and
this,
and
that
this,
though
right
ism,
I
would
argue
that,
through
some
of
my
experiences,
I
should
probably
still
be
using
way
more
use
case
specific
hardware,
I
mean
what
was
I
trying
to
solve.
I
was
trying
to
solve
for
uptime.
You
know
more
agility
with
like
getting
services
out,
not
waiting
like
four
years
for
a
freaking
firewall
to
be
installed.
D
D
We
we
took,
you
know
the
vnf
model
and
now
we're
probably
doing
it
with
the
cnf
model,
where
we're
still
coming
at
this,
like
it's
an
appliance
and
so
then
my
my
question
becomes.
Why
wouldn't
I
just
run
an
actual
appliance
pick
and
choose
the
things
such
as
you
know
like
infrastructure.
As
code
like
I
could
model,
you
know,
I
can
even
model
like
the
topology
of
my
physical
network.
D
Something-
and
you
know
they
give
me
like
the
are
you
crazy
look
you're
the
cloud
guy,
but
I'm
just
like
look
all
it's
going
to
do
is
add
complexity
and
you're
not
going
to
get
any
of
the
benefits
that
we
keep
claiming
come
with
like
a
cloud
native
or
a
virtual
shift
right,
so
I
mean.
Was
there
a
lot
of
great
stuff
that
came
out
of
you
know
the
move
to
vmware
and
openstack
and
then
eventually
kubernetes
absolutely,
but
to
your
point,
does
kubernetes
solve
everything?
D
I
So
you
know
one
of
the
it's
really
interesting.
This
is
an
interesting
conversation
there's
if
we're
going
back
to
the
actual
business
drivers
right
as
you,
as
you
say,
some
of
our
problems
is
that
our
our
business
goals
themselves
are
are
contradictory
right.
We
want
to
have
the
cake
and
our
cake
and
eat
it.
We
want
portability,
but
we
also
want.
I
We
want
open
standards
and
we
don't
want
to
vendor
tie-in
lock-in,
but
at
the
same
time
we
want
all
the
integration.
The
powerful
integrations
that
come
together
with
you
know
using
a
specific
vendor
and
specific
standard.
So
so
a
lot
of
the
history
of
this
is
that
telcos
right.
If
we're
talking
about
the
business
value
coming
from
the
telco
specifically,
which
give
the
requirements
for
for
vendors
to
provide
solutions.
Well,
they
want
to
have
their
cake
and
eat
it.
I
So
it's
an
interesting
starting
point,
because
if
we,
if
we
go
by
these
challenges,
then
we
you
know
we
we
will
come
with
contradictory
solutions
and
difficult
solutions.
Sometimes
so
it's
part
of
it
too,
and
and
again
I
think,
if
we're,
if
we're
asking
these
questions
very
honestly
with
good
faith
which
it
sounds
like
we
are,
and
I
think
that's
a
good
place
to
start
noting
those
conflicts
right.
I
I
We
want
layers
of
abstraction,
but
then
at
the
very
high
level
we
want
to
define
things
like
cpu
pinning,
so
we're
constantly
shooting
ourselves
in
the
foot.
I
think
in
the
in
the
history
of
nfe,
in
terms
of,
on
the
one
hand,
using
things
that
are
off
the
shelf,
but,
on
the
other
hand,
doing
hacky
solutions
that
outside
of
the
telco
world,
you'll
never
see
right
and
in
the
enterprise
world
they
wouldn't
dream.
I
think
of
doing
some
of
the
things
that
we
want
to
hear
in
the
in
telco.
I
So
this
is
fine.
This
is
all
great.
I,
I
think
jeffrey,
I'm
really
glad
that
you're
leading
this,
I
think
you're
the
right
person
to
do
this.
I
think
it's
going
to
be
challenging
and
I
think
it
will
be
very
interesting
to
see
how
we
continue
working
on
this
document
and
I'll
look
into
it
too.
I'm
happy
to
step
in
and
also
do
some
work.
I
I
feel
like
my
goal
here
is
to
keep
us
honest,
so
I'll
try
to
do
that.
D
No,
I
try
to
be
honest
too.
I
would
say
calling
out
those
contradictions.
Tao
should
be
like
some
of
the
challenges
that
we
dress.
Like
here's
the
thing
right,
I
will
tell
you
not
me
specifically,
but
you
know
big
tier
1
csp
moving
to
kubernetes
is
a
business
driver
for
me
right.
So
here's
this
baseline
business
driver
that
I've
just
set
forward.
That
then,
might
contradict
with
all
these
other
things,
because
certain
things
don't
work
good
in
kubernetes,
so
yeah,
I'm
very
much
in
the
same
mindset
as
you.
D
I
kind
of
want
to
just
call
this
stuff
out
if
nothing
else,
if
we
could
just
address
this
stuff
so
that
we
could
start
with
like
a
neutral
point
to
you
know
at
least
open
up
the
opportunity
to
look
at
other
things
where
it
makes
sense.
I
think
that
would
make
my
life
at
least
a
lot
easier
when
I'm
talking
to
other
executives
and
architects
within
my
company.
A
E
I
would
just
like
to
add
that
I,
like
the
way
jeffrey
framed
it.
This
is
gonna
need
to
be
broken
down,
and
you
know,
starting
with
the
actors
and
the
ecosystem,
because
I
think
that
is
one
big
change.
That's
really
happened
in
the
last
20
years
in
terms
of
the
ecosystem
and
how
telecom
approaches
some
of
these
things.
So
I
think
that's
a
really
good
place
to
start.