►
From YouTube: The Telco Networking Journey to Cloud Native: The Good, Bad, and Ugly - Heather Kirksey
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
The Telco Networking Journey to Cloud Native: The Good, Bad, and Ugly - Heather Kirksey, The Linux Foundation
As telecom SPs re-imagine their large-scale communications networks, they look to embrace cloud native architecture & technologies. The journey from proprietary hardware to agile, scalable, & OSS for implementing internet, edge & mobile services (LTE and 5G), known as NFV, began several years ago using the first wave of virtualization technologies. As organizations like AT&T, China Mobile, & Orange look ahead to next-gen services, they're increasingly looking to implement fully realized cloud native network services, i.e., Cloud-native Network Functions (CNFs) running on cloud native infrastructure such as Kk8s & network service mesh using CI/CD & automated testing. Citing examples from open source communities and organizations migrating network functions to the cloud, this session will review lessons learned challenges faced by telcos today as well as what’s in store for tomorrow.
To learn more: https://sched.co/GrX0
A
All
right
so
anyway,
hello,
everyone
welcome
to
just
about
the
end
of
a
kook
on.
My
name
is
Heather
Kirksey
and
I.
Am
the
VP
of
community
and
ecosystem
for
the
LF
networking
set
of
projects
within
the
Linux
Foundation
and
I'm
gonna
talk
a
little
bit
about
sort
of
how
the
telecoms
are
thinking
about
using
cloud
native.
The
journey
we've
gone
to,
but
I
will
be
really
honest.
I
want
to
have
the
most
of
this
session.
The
Q&A
and
some
interactive
discussion
I
have
been
here
since
9:00
a.m.
Monday
morning.
A
I
have
been
in
sessions
and
I
assume
many
of
you
have
as
well
and
I'll.
Just
be
really
blunt.
My
brain
is
getting
fried
so
I
have
to
imagine
that
y'all's
brains
are
getting
fried
and
the
last
thing
that
you
really
want
at
2:35
on
day.
Four
of
an
event
is
for
a
long
and
dense
lecture
to
be
thrown
at
you.
A
A
All
right
looks
like
I
got
the
entire
telecom
crowd
in
here
then,
because
almost
all
of
you
raise
your
hand
and
I'm
working
on
the
assumption
that
for
the
mainline
attendee
of
coop
con,
that's
probably
not
the
case.
So
you
know,
then
the
sort
of
framing
flights
I
have
are
going
to
be
things
that
y'all
know
but
I
think
they're,
they're
sort
of
worth
throwing
up
anyway.
A
Just
you
know
to
get
us
all
kind
of
on
the
on
the
same
page,
and
you
know
maybe
take
a
little
bit
of
a
walk
down
memory
lane
so
front
ground
and
context.
So
you
know
I
think
most
of
you.
If
you've
been
in
the
telecom
industry,
let
me
do
another
raise
of
hands
how
many
people
here
work
for
network
operators
of
some
description
or
another.
Ok,
it's
about
half
how
many
of
you
worked
for
network
equipment
providers-
okay,
that's
close
to
about
the
rest
of
you!
A
How
many
of
you
work
for
Hardware
chip
companies
or
server
companies?
Okay,
and
how
many
of
you
for
application
or
software
district
endures?
Okay,
all
right,
so
we've
got
sort
of
the
general
mix.
So
my
background
is
has
been
mainly
in
the
telecom
industry.
I
worked
for
alcatel-lucent
for
about
12
years
for
a
while.
A
I
ran
a
standardization
for
one
of
the
business
units
within
Alcatel
and
then
my
last
couple
years,
I
worked
for
our
IP
division,
which
is
the
group
that
makes
the
the
big
iron
routers
and
switches,
and
this
is
actually
a
slide
from
that
time
in
my
career
and
it's
a
bit
of
an
eye
chart
and
that's
sort
of
the
point.
So
this
was
alcatel-lucent
high
leverage
network,
circa,
2010,
with
sort
of
LTE
and
fixed
line.
A
A
A
Moving
to
general-purpose
computer
generates
hardware
with
open
source
software,
providing
the
intelligence
to
run
the
network,
and
this
is
the
diagram
of
the
architecture,
the
Etsy
design,
and
what's
the
first
thing
you
notice
about
it,
it
still
looks
like
boxes.
So
you
know
in
the
telecom
world
that
is
very
much
how
we
tend
to
think
about
things.
We
think
about
things
in
terms
of
network
elements
and
boxes
they
hook
up.
They
deliver
connectivity
services,
we
don't
you
know,
we
have
in
the
past,
not
traditionally
thought
like
software
designers,
that's
one
of
the
things.
A
That's
been
changing
yeah,
so
the
reality
of
that
was
not
so
much
that
it
was
a
series
of
special
boxes,
but
this
was
sort
of
what
the
integrated
stack
sort
of
with
you
know.
You
know
some
of
our
early
attempts
at
virtualization
look
like
right,
so
we
had
hardware
and
we
were
moving
to
more
commodity,
vanilla
hardware.
We
had
the
you
know
things
like
OVS
and
TP,
TK
and
Fido.
A
You
know
performing
vich
virtual
switching
functions.
We
used
initially
OpenStack
very
VM
centric,
with
one
of
your
favorite
Sdn
controllers
in
there
and
I
have
open
baton
on
there.
This
is
a
bit
of
an
older
side,
but
obviously
onap
being
one
of
the
big
orchestration
and
back
office,
OSS
BSS
kind
of
reimagining,
and
so
you
know
we
started
down
this.
A
This
path
of
virtualization
and
one
of
the
things
that
I
think
became
true
for
a
lot
of
us,
was
that
the
applications
were
not
really
cloud
applications
out
of
the
time
they
were
the
code
from
the
existing
network
elements
thrown
into
a
VM,
so
we
weren't
able
you
know
we
weren't
really
getting
a
lot
of
the
value
that
we
could
out
of.
Moving
to
these
cloud
architectures,
you
know
networking
was
so
very
complicated
to
set
up.
A
You
know
modern
development
practices
within
our
open
source
organizations
and
we
actually
started
connecting
our
CI
CD
pipelines.
We
started
doing
things
like
getting
tip
of
Master
from
multiple
projects,
integrating
with
them.
Each
other
and
getting
feedback
and
fixing
bugs
faster.
We
started
inserting
things
like
automated
test
scene
and
automated
gates
and
deploying
to
different
types
of
hardware,
infra
that
mimic
the
different
types
of
things
and
the
service
providers.
Some
of
the
operators
actually
started
implementing
DevOps
principles
and
practices
and
see
ICD
in
their
own
environments.
A
So
if
you
are
an
network
operator,
are
you
implementing
or
using
see
ICD
in
your
network
a
few
a
few
scattered
hands?
I
know
some
of
our
some
of
our
operators
have
actually
started
moving
moving
that
direction
or
actually
seeing
a
lot
of
the
benefits
that
you
have
people
talk
about.
You
know
they're
able
to
get
changes
more
regularly.
A
Things
are
more
stable
because
they're
not
waiting
to
do
big
upgrades,
they're
able
to
actually
start
working
with
their
suppliers
and
actually
getting
their
suppliers
to
send
them
more
frequent
updates
using
sort
of
collaborative
see,
ICD
tool
chains.
So
it's
really
cool.
We
are,
as
an
industry,
beginning
to
move
closer
and
closer
to
some
of
these
cognitive
principles.
A
This
is
a
slide
of
the
testing
projects
from
one
of
the
LF
networking
projects
o
PMF
V,
but
the
testing
projects
have
really
started
investing
in
automated
testing
you
know
and
having
that
in
there
it's
smoke,
testing
and
different
testing
gates
and
things
that
really
start
to
look
like
modern
software.
We've
also
started
partnering
with
CNF
CN
CF
on
a
number
of
fronts,
so
who
is
add
to
the
CNF
boff
yesterday,
all
right
couple
folks,
those
slides
are
uploaded.
A
I,
definitely
encourage
folks
to
look
at
those
so
and
that
sort
of
details,
some
of
the
partnership
that
we're
doing
with
CN
CF,
beginning
to
actually
test.
You
know,
vnfs,
which
are
virtual
network
functions
and
CNF
sort
of
the
cloud
native
counterpart,
seeing
how
that
you
know
kind
of
seen
how
they
work
in
a
number
of
testing
scenarios.
A
You
know
seeing
what
the
advantages
are
if
we
can
really
get
better
performance
from
cloud
native
and
right
now
it
looks
as
though
we
are
so
then
the
question
is,
you
know:
we've
started
doing
some
of
those
proof-of-concept
we've
started
implementing
some
of
the
processes
that
really
support
cloud
native.
But
what
does
it
look
like
if
we
really
want
to
to
really
go
there,
and
so
you
know,
and
this
within
the
LF
networking
set
of
projects
is
really
led
to
work
kind
of
in
different
areas.
A
A
I
have
some
questions
that
I
think
that
are
things
that
I've
started
thinking
about,
but
I
would
love
to
hear
questions
that
you
all
have
and
maybe
actually
start
to
get
some
dialogue
make
sure
we
stay
awake
through
these
last
couple
hours
of
our
conference
and
the
first
one
that
I
sort
of
wanted
to
throw
out.
There
is
because
I
have
done
so
much
work
within
a
fee
I
set
for
the
past
four
years.
A
You
know
what
does
the
cloud
native
in
a
fee
I
look
like
which
CN
CF
projects
do
we
want
to
bring
together,
I
mean
kubernetes,
obviously,
but
what
do
we?
How
do
we
want
to
do?
Networking
there's
been
a
lot
of
talk.
This
conference
about
network
service
smash
things
like
envoy
is,
is
do
a
usable,
a
useful
control
plane
for
a
telecom.
You
know:
are
there
folks
out
there
who've
started
experimenting
with
any
of
that,
so
this
is
the
I'm
going
to
put
y'all
on
the
spot
now.
A
So
if
you
were
hoping
just
to
sit
quietly
I'm
going
to
try
to
push
you
not
to
so,
anyone
have
some
thoughts
and
I
will
just
start
picking
on
people
in
the
audience
that
I
know
that
might
have
thoughts
on
some
of
these
questions.
So
you
know
what
are
you
what
are
folks
thinking
about
for
what
the
cloud
native
n
FBI
needs
to
look
like
what?
What
is
the
right
set
of
infrastructure
components
from
CN
CF
and
by
the
way
we
do
have
microphones
so
they're
in
the
middle?
A
If
you
don't
mind
talking
into
those
or
we
can
just
pass
them
around,
actually
do
one.
Have
you
mind
sort
of
running
microphones
around
unless
they're
wired
into
the,
if
they're
wired
into
the
little
stands
than
not
but
okay,
okay,
cool
that
up
here
at
the
front,
so
I
think
you
were
just
saying
it
depends
on
the
workload.
So
do
you
want
to
talk
a
little
bit
about
your
your?
You
know,
sort
of
things
that
things
that
I
found
so.
B
These
are
other
different
layers
are
gonna
interact
as
far
as,
though,
which
tools
I'm
gonna
pick
like
OpenStack,
tried
this
and
then
failed
at
it,
because
the
first
word
was
open,
but
then
you
had
to
deploy
15
services
that
were
all
interdependent
upon
each
other
and
the
openness
of
that
stack,
sorted
to
diminish,
so
I
would
say.
One
of
the
things
that
we
should
strive
for
is
to
keep
this
actually
open.
So
if
I
am
doing
cable
stuff
with
cloud
cmts
I
can
build
the
stack
that
works
for
cloud
cmts
on
the
flipside.
B
If
I'm
doing
telco
stuff
I
want
to
be
able
to
build
a
packet
core
that
does
what
I
want
it
to
not
what
I've
shoehorned
into
some
buddy
else's
vision
of
what
a
platform
should
look
like
my
question,
for
you
is:
is
own
APIs
design
from
the
legacy
Etsy
framework,
like
it's
very
Manos
centric.
How
do
you
see
onap
evolving
to
adapt
to
the
world
of
CNS
versus
VNS
I.
A
Think
that
is
a
very
good
question
to
which
I
do
not
have
all
the
answers,
but
one
of
the
things.
One
of
these
it
seems
fairly
immediately
obvious
to
me-
is
a
lot
of
what
onap
has
to
do
is
related
to
a
lot
of
the
sort
of
complicated
wiring
amongst
you
know,
to
set
up
to
set
up
the
network
to
do
the
VLANs
to
get
the
vnfs.
You
know
sort
of
properly
configured
to
set
up
all
your
OpenStack
networks,
and
things
like
that.
I
think.
A
You
leverage
the
network
and
focus
really
more
on
the
yo
kind
of
telecom
service
management,
the
application
design
center,
the
getting
lots
of
details
in-
and
you
know,
integrating
with
something
like
panda
to
do
really
interesting.
You
know
AI
and
machine
learning,
around
kind
of
the
network.
Health
network
stats,
how
the
services
are
actually
working,
but
that's
just
sort
of
my
opinion,
but
that
that's
sort
of
how
I
kind
of
see
it
yeah.
C
I
can
I
can
address
one
of
the
questions
there
I
work
in
wound
up
in
the
last
Casablanca
release
and
upcoming
Dublin
release.
We
are
trying
to
I
mean,
as
you
guys
may
know,
that
own
app
today
can
only
talk
to
open
stack,
based
cloud
regions
to
deploy
vm
based
workloads,
but
in
our
for
release,
for
which
we
are
starting.
Our
intention
is
to
support
cuban.
It
is
based
cloud
regions
to
basically
bring
up
both
vm
based
workloads
and
also
container
based
work
loss.
I
mean
the
way
we
are
trying
to
do.
C
D
Have
the
mic,
so
we
read
from
AT&T
I
think
it's
also
important
for
us
to
understand
that
it's.
This
is
more
of
a
comment.
It's
important
for
us
to
understand
that
for
telecom,
not
everything
is
packet
processing
gateway,
so
there
are
control
plane
elements
like
mm
ease
and
PCRs,
which
are
a
lot
easier
to
make
cloud
native,
so
those
might
be
probably
be
better
targets
initially
for
us,
rather
than
always
think
about
high
packet
processing,
VPP,
write
applications
and
Thai
telecom
to
only
packet
processing.
So
there
are,
there
is
a
control
plane.
A
E
Speaking
from
the
operator
space
so
far,
I
felt,
like
the
NFP
approach,
has
not
addressed
any
of
our
network
team's
concerns
at
all.
You
know.
Openstack
looks
like
something
designed
by
a
bunch
of
software
people
that
networking
people
have
no
interest
in
touching
and
spinning
up.
A
bunch
of
VMs
has
nothing
to
do
with
solving
their
problems
of
configuration,
which
is
what
software-defined
networking
is
for
them.
E
A
F
A
Do
you
mind
if
I
pause
you
right
there,
because
I
actually
I
I,
want
to
sort
of
address,
address
kind
of
that
statement
or
question
because
and
I'm
gonna
actually
maybe
look
at
Fredrik,
because
I
know
he
and
I
were
having
a
conversation
yesterday
actually
about
how
you
opened
a
light.
Yo
has
the
strong
ability
to
do
net
comp
and
you
know,
as
we
are
implementing
a
lot
more
things
in
software,
you
know.
A
And
so,
if
you
were
thinking
about
Theo
sort
of
your
router,
as
you
know
your
your
vnf
or
your
application,
you
know
the
ability
to
manage,
configure
onboard
and
deploy.
You
know,
sort
of
that.
Router
application
is
a
lot
of
what
onap
is
actually
sort
of
addressing
there,
but
Frederick
do
you
have
any
thoughts,
because
we,
oh,
we
were
talking
about
kind
of
the
role
of
net
cough
and
a
lot
of
odl
type
things
in
cloud
native
yesterday
or
two
days
ago.
A
G
I
don't
know
what
day
it
is
either
just
I'm
gonna
keep
coming:
don't
no
one's
here,
but
anyways
yeah
to
drive
down
I!
Think
what
you're
saying
is
incredibly
important
like
we.
So
when
you
start
looking
at
most
networking
solutions
that,
whether
it's
open,
OpenStack
or
kubernetes,
or
so
on,
they
make
one
very
important
assumption,
which
is
that
the
underlay
is
already
there.
So
they
already
have
connectivity.
So
they're
gonna
build
a
connectivity
on
top
of
something
that's
already
there.
G
So
if
you
are
a
software
network
developer
in
this
space,
start
thinking
about
that
problem
and
there's
a
lot
of
problems
we
still
have
to
do.
We
have
to
work
through
in
order
to
in
order
to
make
it
possible
for
you
to
implement
what
you
want
through
things
like
NIC
conf
may
be
using
yang
to
model
or
other
well-known
tools.
So
excellent
point:
oh.
F
Yeah
back
talking
about
governance,
so
when
you're
dealing
with
features
within
the
kubernetes
space
and
CN
CF,
there's
a
way
of
determining
things
through
SIG's
and
working
groups
in
a
democratic
fashion
and
the
people
that
have
an
interest
in
certain
features
being
pushed
up.
They
jump
in
on
these
meetings
and
I'm
someone
I'm
hearing
about
pain,
I'm
certain
features
not
being
put
in
the
different
projects.
F
A
So
in
terms
of
how
the
the
governance
works
for
these
projects,
it's
not
dissimilar
from
kubernetes,
although
we
don't
have
the
SIG's
typically
here
and
let
me
go
to
our
our
set
of
projects
just
so
everyone
can
see
them
typically,
the
way
they
work
is.
Each
of
these
projects
has
a
technical
steering
committee
and
then
sub
projects
underneath
it
that
usually
sort
of
come
in
to
address
some
feature
area
or
function
area
that
someone
feels
is
of
an
issue
and
a
lot
of
these
actually
are
started
and
often
led
by
the
end
users
as
well.
A
So
we
drew
try
to
get
them
involved
in
the
developer
community,
even
if
they're
not
necessarily
doing
the
coding
they're
sort
of
driving
the
future
realization.
But
you
know
one
of
the
things
that
I
found
yo
for
being
all
very
honest
here,
is
that
well
sometimes
have
a
gap
in
between
sort
of
the
understanding
of
you
know,
sort
of
a
pain
point
from
an
operator,
and
you
know
maybe
the
software
developers,
implementation
of
the
feature
and
whether
that
makes
sense,
and
we
are
trying
to
think
close
that
gap.
A
We
had
had
one
in
OPN
Fe
and
we
had
had
one
in
open
daylight
before
we
brought
all
these
projects
together
under
the
umbrella
and
sort
of
getting
that
spun
back
up
so
that
we
do
have
a
better
feedback
loop
between
our
end
users
and
what's
getting
implemented
in
the
communities,
is
really
happening,
but
we
do
tend
to
be
pretty
lucky
in
that,
because
a
lot
of
this
is
so
core
to
a
lot
of
our
network
members.
They
tend
to
actually
participate
pretty
deeply
in
our
architecture,
design
plans,
and
you
know,
as
project
technical
leads.
A
You
know
kind
of
across
the
projects
there,
but
it
obviously
can't
be
better
and
things
always
can
be.
You
know
improved
and
I
think
getting
our
end
user
advisory
group
spun
up
and
more
deeply
involved.
The
other
thing
that
happens
too
is
we
tend
to
get
a
lot
of
folks
from
our
operators
here
more
in
the
R&D
side
and
architecture
side.
You
know
kind
of
you
have
more
CTO
office
types
and
we're
definitely
seeing
the
operators
and
I
think
it
goes
to
the
point.
A
The
gentleman
just
made
there
about
sort
of
your
needs
is
that
we
need
to
get
better
about
hearing
from
operations,
people
who
are
actually
deploying
some
of
the
stuff
and
what
pain
points
come
out
of
operations,
as
opposed
to
sort
of
you
were
here.
We
hear
a
lot
from
operators.
You
know
as
we're
designing
and
getting
things
done,
but
you
know
as
it's
true
and
all
big
companies
sort
of
the
sort
of
the
needs
and
desires
for
cool
features
versus
some
of
the
needs
of
the
operations.
Folks
who
actually
use
manage
and
deploy.
A
This
don't
always
marry
up
either
and
so
we're
trying
to
figure
out
how
we
can
get
better
input
from
the
actual
ops
people
within
the
carriers.
As
you
know,
and
not
only
from
kind
of
the
design
people
to
which
is
not
just
anything
bad
about
any
anyone.
But
you
get
different
feedback
right
from
obvious
people
and
we're
we're
trying
to
address
how
to
get
more
information
from
from
that
side
of
the
business
as
well.
A
E
A
So
network
service,
mesh
kind
of
grew
out
of
a
presentation
at
ons,
which
is
kind
of
the
big
summit
that
that
these
projects
tend
to
have
every
year
and
actually
sort
of
came
out
came
from
the
TSC
terrified,
oh
and
sort
of
thinking
about,
as
he
was
looking
at
sort
of
deploying
Fido
as
a
data
plane
in
in
cloud
native
land
sort
of
seeing
the
sort
of
that
gap.
That
was
still
there
so
there's
actually
a
fair
amount
of
overlap
between
opendaylight
development
teams,
the
Fido
development
teams
and
the
network
service
mesh
development
team.
A
So
network
services,
the
project
here
in
C&C
F.
But
it's
actually
a
lot
of
the
similar
developers.
Who've
been
working
on
some
of
these
problems
within
open
daylight
and
within
Fido
for
the
past
several
years,
and
you
actually
have
one
of
one
of
those
who
works
in
open,
daylight
and
and
Fido
just
some
extent
to
know.
Okay,
a
little
bit
of
Fido
and
network
service
match.
So.
A
A
You
know
because
they're
definitely
sort
of
cloud
native
ideas
around
you
know
what
control
planes
look
like
and
things
like
that
that
seem
somewhat
similar
to
the
problems
that
we've
been
addressing
with
things
like
open
daylight
in
Sdn
controllers,
but
maybe
different
approaches
and
I
and
I'm
just
very
curious.
You
know
those
of
you
who've
started
experimenting
with
cloud
native
and
who
maybe
had
implemented
Sdn
with
yo
Sdn
controllers
in
the
past.
How
are
you
beginning
to
think
about
it?
How
are
you
looking
at?
G
So
I'm
being
asked
to
give
a
response,
I
suppose.
So,
let's
talk
about
like
the
mention
about
open
daylight
before
with
like
net
conf
and
and
so
on.
So
when
we
start
looking
at
network
service
mesh,
we
just
one
of
the
things
that
we
realize
is
there's
a
gap
between
like
trying
to
ask
what
you
want.
What
type
of
Cloudant
native
networking
was
was
there
in
terms
of
the
api's,
and
so
we
decided
to
try
to
focus
on
how
to
bring
in
other
things
as
well,
so
suppose
that
you
were
running
open.
G
So
suppose
you
want
you
had
some
fabric
and
you
wanted
to
control
it
with
open
daylight
and
you
wanted
to
set
up.
Maybe
some
cross-site
connectivity
through
a
VPN
using
korea,
Nettie's
api
is
and
what
they
provide
you.
How
do
you
do
that?
So
I'm
gonna
end
up
calling
something
together
yourself,
custom
management,
scripts
and
so
on.
G
Some
try
to
get
tungsten
fabric
pulled
in
trying
to
get
others
as
well
and
part
of
what
we
want
to
do
is
make
it
very
easy
so
that
you
use
whatever
you
want
to
use
the
others
use
whatever
they
want
to
use.
As
long
as
you
can
both
speak
the
same
tunnel
protocol
or
encapsulation,
we
can
find
a
way
to
make
them
work
together,
and
so
so
we're
trying
to
help
with
provide
over
that
overall
theme.
B
So
every
provider
kind
of
tries
to
skin
this
cat
differently
and
I
mean
I,
can
tell
you
just
in
my
space
I
work
with
four
different
Sdn
controllers.
So
one
of
the
things
that
we've
been
trying
to
do
is
actually
simplify.
The
transport
itself,
remove
the
number
of
protocols
that
we're
using
start
looking
at
technologies
like
segment
routing,
specifically
MSR,
MPLS
and
SR
v6,
and
then
also
trying
to
cut
down
the
number
of
encapsulation
types
that
we
use.
B
So
we've
been
looking
at
terminating
in
pls,
directly
on
the
V
switch
or
through
SRV
directly
on
the
vnf
itself,
because
the
thing
that
like,
if
you
don't
come
from
the
service
provider
world,
you
just
don't
understand
the
magnitude
of
crap
that
we
have
to
deal
with
so
true.
Well,
even
if
you're
like
you
know,
there's
like
enterprise
customers
that
have
networks
that
are
probably
close
to
the
size
of
ours.
But
it's
like
a
single
ASN
right
I
mean
in
my
network
alone,
I'm
going
sometimes
across
seven
different
AAS
regions.
B
I've
got
you
know
for
different
encapsulation
types
and
so
like
what
Sdn
controller?
Does
all
that
for
me
like,
when
I
go
from
access
to
my
core
to
my
datacenter?
It's
three
different
networks,
it's
three
different
Sdn
controllers,
because
those
networks
have
unique
needs
and
so
on.
Protocol
consolidation-
and
you
know,
encapsulation
consolidation
is
a
big
thing
and
then
the
other
thing
we're
doing
is
we're
trying
for
two
other
things
is
every
single
vendor
that
comes
to
us.
We
want
them
to
have
some
type
of
data,
modeling
support,
so
I
don't
want
to
like
program.
B
My
network
I
want
to
model
my
network
I,
want
you
know
it's
similar
to
what
kubernetes
tries
to
solve
right
with
its
declarative
models,
but
we
use
Yang
and
Tosca
right
like
it
goes
directly
to
your
point,
is
when
I
bring
up
this
vnf.
If
the
vnf
does
not
support
a
simple
certain
type
of
modeling
template,
we
throw
them
out
because
I've
got
my
models
and
all
I
should
have
to
do.
B
Is
change
like
some
host
names
and
some
interfaces
and
this
and
that
you
should
at
least
be
able
to
take
about
90%
of
what
you
know
vendor
Y
is
doing
in
vendor
X
and
then
the
other
thing
is
is
a
common
northbound
API,
because
we
have
so
many
Sdn
controllers.
We
have
been
working
internally
on
basically
creating
like
an
OSS
layer
where
you
know
we
I
hate
using
the
word
intent,
because
it's
like
the
new
buzzword
in
the
networking
world,
but
that's
kind
of
what
we
try
to
do
like.
B
We
have
all
these
different
controllers
sitting
southbound,
because
every
part
of
our
network
has
a
unique
need.
I
mean
you
showed
it
in
your
Alcatel
slide
right,
like
all
those
different
boxes
existed
because
they're
all
doing
very
different
network
functions,
and
just
because
you
put
it
in
a
VM
I,
now
just
have
30
different
vm's
that
I
have
to
manage
differently.
So
we
try
to
like
force
vendors
to
give
us
this
common
API
on
the
north
side.
B
A
A
Yeah
I
worked
on
AMS
for
a
little
while
too,
so
you
know
the
the
fact
that
we
didn't
get
common
data
models
for
a
lot
of
you
know.
Ems
network
appliances,
I
think,
is
one
of
the
things
that
we
sort
of
failed
as
an
industry
and
I
don't
want
to
see
us
fail
at
it
again.
You
know,
through
software
and
I
actually
said,
I
have
yeah,
where
you're
getting
close
to
time,
but
I
have
one
more
question
that
I'd
like
to
ask
them.
H
I
think
there
is
a
difference
like
for
the
CNS
for
the
telco
world,
and
this
couple
of
things
like
performance
is
one
of
them,
and
access
to
the
packets
is
like
another
one,
so
I
think
the
telco
kind
of
CNS
probably
required
different
level
of
two
packets,
then
the
regular
ones,
I
think
that
the
network's
nice
mesh
I
think
is
the
whole
basis
of
that
is
like
that's
the
thesis
behind
doing
something
different.
Otherwise
we
could
be
just
fine
internal
interfaces.
H
A
I
I'll
argue
on
the
other
side
of
that
comment
that
we
in
telco
we
try
to
always
think
that
our
workloads
are
kind
of
special
and
in
some
cases
they
truly
are.
But,
as
we
were
saying
earlier,
that
in
a
lot
of
control,
plane
workloads,
at
least
if
we,
if
we
give
it
some
effort,
we
can
think
of
the
workloads
as
just
an
application,
as
you
were
saying,
and
and
try
to
work
with
it
in
that
manner.
H
Is
control
plane,
workloads,
I,
understand
they're,
like
any
other
applications,
but
there
is
certain
things
like
which
do
need
unfettered
access
to
packets
specific.
So
her
question
was
like:
do
we
need
anything
different
I
think
the
answer
is
yes
like,
but
in
most
cases
we
can
just
do
with
cloud
native
applications
like
everything
else
and.
I
The
other
point
is
that
if
we
have
to
fundamentally
see
that
kubernetes
is
a
way
to
orchestrate
workloads
and
we
have
to
clearly
define
in
the
telecom
space,
what
is
our
workload?
Is
it
doing
a
session
management
for
us?
Then
that's
the
workload
week.
It
can't
be
all
things
to
all
people
right.
We
can't
let
think
that
kubernetes
can
solve
the
orchestration
problem
of
the
of
the
networking
devices
or
the
configuration
of
different
networking
devices,
because
it's
it's
designed
to
be
a
workload
Orchestrator,
not
anything
else.
That
way.
C
Okay,
more
than
a
question
I
just
want
to
do.
I
mean
I,
feel
that
any
networking
workload
bcnf
right
I
mean,
for
example,
as
I
mentioned,
I
work
in
one
app-
and
you
know
there
is
a
big
despair-
is
something
called
dead
up
there
and
BNF
sorry,
data
pain
CNS,
which
requires
multiple
network
interfaces.
It
need
to
belong
on
multiple
networks
and
then
it
sometimes
it
requires
core
affinities,
core
dedication,
Numa
awareness
and
many
things
which
are
quite
well
thought
about
in
OpenStack
vnf
world.
C
A
Coop
calm
for
the
past
several
days,
so
yeah
on
behalf
of
the
Linux
Foundation,
thanks
for
being
here
and
thanks
for
participating
and
some
of
these
questions,
I'm
asking
I
did
have
a
little
bit
of
a
sort
of
method
to
my
madness
in
that
these
are
some
of
the
questions
that
we
need
to
answer
and
that
we
are
answering
in
these
projects.
So
if
these
are
things
that
you're
thinking
about
things,
you
know
you
have
to
get
answered
things
that
you
know
are
confusing
to.
You
is
you're.