►
From YouTube: CNCF Telecom User Group Meeting - 2019-11-04
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
A
Okay
and
that's
five
after
the
hour,
so
this
is
Dan
Cohen
executive
director
of
Cinzia
and
I
am
actually
in
Paris
today,
closer
I
think
to
a
lot
of
our
regular
participants.
We
have
made
good
progress
on
this
first
chapter
or
preamble
to
the
cloud
native
telecom
user
group
white
paper.
So
I
wanted
to
thank
everybody
for
their
involvement
so
far
and
see
if
we
could
try
and
talk
through
what
are
some
of
the
open
issues
that
folks
are
aware
of.
I,
don't
think
Alex
sulk
ever
couldn't
make
it
on
this
call.
A
A
So
that
was
the
main
thing
that
I
was
looking
to
do
on
a
call
today.
Our
hope,
if
we
can
reach
a
rough
consensus
on
this,
is
to
be
able
to
publish
this
white
paper
and
a
preamble
and
announce
it
in
time
for
Q,
Khan
and
two
weeks.
The
other
topics
is
that
we
do
have
this
a
joint
tug
and
see
NTT
meeting.
That's
there's
two
of
them.
A
A
A
There
we
are
so
I
previously
had
a
past
present
future
version
of
this,
and
it
was
specifically
linked
to
some
ideas
about
functionality
and
onap
amsterdam
versus
onap
Casablanca,
where
might
be
in
the
future,
and
so
I
really
tried
to
simplify
all
that
away
and
just
talk
about
this
CNF
Architecture
and
are
there
other
yeah?
So
we
need
to
talk
about
agenda
items
for
the
joint
Tugg
CNT
tea
meeting
Taylor,
where
there
are
other
topics
that
you
wanted
to
discuss
on.
This
call
I.
C
B
Guess
I'll
just
I'm
repeating
that
we're
wanting
to
get
feedback
before
Wednesday
and
we're
planning
on
setting
the
agenda.
So
this
is
a
LF
wiki.
If
you
have
an
LF
ID,
then
you
should
be
able
to
update
the
wiki,
add
items
to
the
brainstorming
and
we
have
kind
of
a
tentative
skeleton.
We're
thinking,
flattening
talks
on
the
first
day
and
maybe
some
more
in-depth
working
session
on
the
second
day
and
potentially
a
panel.
But
and
if
you
have
ideas,
please
add
them
to
that.
B
Maybe
one
thing
to
follow
up
on
the
definition
specifically
Dan
and
to
try
to
help
people
pull
that
are
in
different
parts
of
the
world
and
may
not
be
able
to
attend
just
suggestion
to
have
a
follow
up
to
today's
discussion
of
the
chapter.
One
white
paper
items
and
put
out
some
suggestions
for
time.
So
if
we
can
get
those
on
and
I'm
willing
to
join
an
early
morning
to
make
it
easier
for
people
in
asia-pacific
to
join.
A
Yes,
so
if
we
scroll
to
that
page
I
believe
it's
page,
five
is
where
we
have
different
alternatives
and
I
wanted
to
throw
out
some
principles
to
try
and
selected
here
and
I.
Think
we
could
probably
do
it
fairly
fast,
which
is
I'm
very
interested
to
link
to
this
Frederick,
who
made
the
suggestion
link
to
at
sea
as
a
informative
reference.
A
In
order
to
understand
the
meaning
of
this
document
and
I'd
like
to
try
and
minimize
the
normative
references
we
make
period
at
all,
I
think
you
already
have
one
exception
to
that:
we're
making
normative
reference
to
the
cloud
native
definition,
but
because
that
documents
three
sentences
are
also
controlled
by
CN
CF.
It's
a
take
a
simpler
process,
and
so
I
will
come
in
and
I
think
make
my
own
alt
second
suggestion
here,
but
I
guess
I
would
love
to
see.
Is
there?
Anyone
and
I
was
curious
to
hear
on
your
perspective.
D
Think
I
think
the
fundamental
question
is:
what
do
you
associate?
We
do
that
to
see
if
you
associate
containers-
and
there
is
one
answer,
if
you
associate
cloud
native
then
naturally,
containers
or
you
know-
maybe
even
pods
are
not
enough.
Foods
are
certainly
better
because
there
is
the
assumption
of
using
kubernetes
full
orchestration
containers.
You
know
you
can
you
spit
out
kubernetes
and
therefore
could
be
heavily
contested,
whether
that
could
be
considered
cognitive.
A
Sure
I
will
say
that
I
helped
coin
the
CNF
term
and
we
were
always
clear
that
it
was
cloud
native
network
function,
not
containerized
network
function
to
try
and
make
things
a
little
bit
more
specific.
But
that
then,
would
we
answer
my
question
about
trying
to
limit
exactly
what
a
CNF
is.
I.
B
Would
say
not
limiting
it
to
containers
or
pods
since
I
expect
at
the
platforms,
including
kubernetes,
to
use
whatever
underlying
blocks,
make
sense,
I
think
the
functionality
may
look
similar
to
a
pot
or
container,
but
there
may
be
something:
that's
not
a
container
and
I.
Don't
think,
that's
the
the
definition
of
a
container
and
what
it
does
is
what
I
think
you
care
about
and
then
more
specifically,
all
the
different
parts
in
that
would
be
the
principles
around
being
cloud
native.
B
Say
that
a
container
is
an
implementation
of
one
part
of
that
and
just
like
pods
they're,
an
implementation
and
the
technology,
that's
implementing
those.
If
we
point
to
those
and
we
need
to
grow
beyond
that,
then
we're
not
going
to
cover
it
or
if
someone
came
in
and
change
those
and
it's
from
someone's
perspective
of
caring
about
the
principles.
Maybe
a
pot
is
no
longer
cloud
native
unlikely,
but
that
would
be
why
I
would
say:
let's
focus
on
the
definitions
of
what
they
mean
versus
the
implementation
mm
I.
D
Tend
to
approve
the
kind
of
cloud
nativeness
from
the
benefit
and
and
and
in
the
terrible
context.
Certainly
the
benefit
is
you
know
the
disaggregation,
but
also
the
unified
lifecycle
management
by
kubernetes,
api
and
so
I
would
not
link
it
to
contain
as
necessary,
because
being
I'd
want
to
introduce
new
runtimes
handling,
VMs
or
cata
containers
or
whatnot,
which
are
strictly
speaking,
not
containers,
but
just
lineups
called
Danis
is
something
else.
E
C
Think
it's
worth
pointing
out
that
they
they're
kind
of
five,
the
five
alternatives
that
we
we've
put
into
the
chapter.
One
document
I,
don't
think
any
of
them.
Mention
containers
I.
Think
that's
important
to
note.
There's
a
lot
of
talk
of
micro
services
and
immutable
infrastructure,
but
I,
don't
think
there's
any
mention
of
containers
in
those
definitions.
F
So
I
think
it
may
be
worth
actually
pointing
out
the
distinction
with
a
concrete
example.
So
what
I'm
saying
is
like
if
you
go
to,
for
example,
there
are
nine
components.
For
example,
see
you
especially
the
D
you
there.
The
moment
is
just
around
containerization,
but
not
really
cloud
native
I.
Think
I
can
in
fact
add
that
I
can
volunteer
to
add
that
that
really
is
a
pretty
concrete
example
with
this
emerging.
G
G
So,
for
example,
can
I
scale
it
horizontally
or
only
can
I
get
it
to
auto,
heal
and
recover,
and
is
the
configuration
declarative
so
I
can
configure
it
in
an
easier
and
more
holistic
way,
and
so
I
think
part
of
it
is
trying
to
try
to
drive
the
definition
in
that
path
and
I.
Think
part
of
the
poem
that
we're
going
to
run
into
is
like?
G
Yes,
you
can
build
from
like
something
that
follows
the
cloud
native
definition,
but
and
then
stick
it
into
something
that
into
an
Orchestrator
that
does
not
support
cloud
native
principles
or
car
native
orchestration
angle
psi
and
even
though
you've
built
it
in
this
particular
way.
Many
of
the
benefits-
I
just
don't
get
benefits
out
of
it,
but
you
won't
get
that
it's
it's
when
you
couple
it
with
the
orchestrator
that
you
get
that
you
that
you
maximize
the
benefits.
Oh,
but
here's,
the
guy
that
I
tend
to
use
myself.
B
D
What
that's
ongoing
I
think
one
of
the
big
difference
between
the
different
outline
that
we
see
some
of
them
are
talking
about
cloud
native
network
functions
by
other
words,
are
talking
about
not
cognitive
network
applications
and
I.
Think
it's
worth
pointing
out
that,
while
you
know
typical,
telco
functions
are
cloud
native
network
functions,
network
functions
themselves
are
usually
defined
by
standards
like
3gpp,
like
application,
can
be
anything
like
an
OSS,
ruby
sss-bok.
D
So
naturally,
application
is
a
much
wider
category.
The
network
function
and
a
much
less
already
defied
category
the
network
function.
So
for
that
reason,
maybe
it
would
be
better
to
talk
about
applications
and
not
network
functions.
If,
then,
you
are
adamant
not
to
link
into
any
other
normative
definitions,
then
network
functions
are
very
clearly
defined
by
Etsy
and
a
fee,
and
then
the
network
functions
themselves
are
defined
by
3gpp.
So
maybe
it's
a
better
option
to
talk
about
applications.
D
H
Watson
as
far
as
the
definitions,
one
of
the
things
that
keeps
coming
up
is
the
grouping
of
microservices
or,
if
you
want
to
say,
containers
or
pods
or
VMs
or
whatever,
and
then
the
a
single
micro
service
pot
or
whatever,
and
so
within
cloud
native,
a
group
of
micro
services
there's
an
application.
So
within
the
Fe
docks
it
looks
like
there's.
A
group
of
a
group
of
functionality
can
be
a
network
function.
C
The
clave
is
and
I
think
the
the
what
I
tried
to
add
in
41.1,
and
one
of
the
others
I
think
was-
was
to
use
the
link
it
to
the
definition
of
a
virtualized
Network
function
component,
which
is
the
bit
in
Etsy,
which
decomposes
that
higher-level
function
into
those
multiple
bits
of
functionality.
Potentially
right.
I
B
B
C
B
Not
one
is
a:
it
doesn't
define
what
well-defined
external
interfaces
are:
well-defined,
functional
behaviorist
if
those
have
definitions
somewhere
else,
they
leave
it
vague
enough
that
that
could
be
anything.
What
is
what
is
a
well-defined
external
interface
and-
and
this
could
I
think
there
was
someone
mentioned
benefits
as
a
one
way
to
look
at
things.
The
problem
with
having
benefits
as
your
as
your
part
of
your
definitions,
it
doesn't
it
leaves
it
open
to
interpretation.
B
So
then
you
could
say
if
you
want
segregation
where
you
could
do
segregation
and
many
different
one
I
just
so
that's
that
that
would
be
going
finger.
In
any
case,
this
is
just
an
expansion,
I
think
of
the
from
the
other
white
paper
to
make
sure
and
include
those
parts.
It
doesn't
include
some
of
the
things
that
folks
have
mentioned.
Like
the
cloud
native
network
components,
it
does
mention
part
of
the
virtual
network
function,
but
then
points
over
and
I
think
all
1.1
is
trying
to
add
in
part
of
the
cloud
native.
B
C
So
so
Doug
one
the
1.1.
Sorry,
though
there
was
a
comment
on
alt
one
that
the
CNC
of
cloud
native
definition
wasn't
wasn't
kind
of
detailed
enough
about
what
we'd
want
to
see
from
a
cloud
native
Network
function
and
so
I
added
in
that
that
bit
about
immutable
infrastructure
from
the
cloud
native
principles
document
that
was
being
written
because
I
felt
it
called
out
what
we
were
looking
for
from
a
you
know
in
terms
of
guidance
for
the
software
vendors,
if
you
like,
but
the
rest
of
it
was
the
same
for
us.
B
So
this
one
I
was
trying
to
build
on
this
based
on
I,
think
the
alt
4
and
5
I
added
this
woman.
So
it's
taking
some
of
those
ideas
are
the
direction
of
alt
1.1
and
then
linking
it
a
little
bit
more
towards
the
cloud
native
side.
So
this
is
mainly
to
do
a
mapping.
So
what
are
we
looking
at
for
folks
that
are
doing
cloud
native
already
that
are
interested
in
the
net
cloud
native
network
functions?
What
would
that
mean?
B
And
then,
if
you're
going
to
either
way
trying
to
say
how
do
we
take
something
that
we
understand
from
the
v-world
and
move
towards
cloud
native?
So
this
was
talked
about
a
little
bit
earlier.
It
seems
like
a
cloud
native
Network
function
if,
if
we
take
actually
let
me
step
over,
if
we
take
a
virtual
network
function,
it
seems
like
a
virtual
network
function,
is
a
cloud
native
or
could
be
an
application,
and
so
a
cloud
native
network
function
could
be
a
cloud
native
application.
B
So
it's
it's
a
specifically
an
application
that
focuses
on
the
network
domain
and
that's
that
has
a
good
definition
and,
and
then
this
is
saying
it's
similar
to
a
virtual
network
function
and
it's
specifically
think
similar,
because
I
think
there's
going
to
be
pieces,
maybe
like
the
virtualized
and
the
virtualized
hardware.
Abstraction
are
probably
not
going
to
be
part
of
a
cloud
native
network
function.
B
That's
going
to
be
there's
going
to
be
something
pushed
out,
so
it
won't
actually
be
in
the
the
the
network
function
itself
that
would
be
taken
out
in
a
virtual
network
function.
It
needs
to
know
how
to
work
with
it,
but
that's
potentially
not
going
to
be
part
of
it
and
it
may
be
part
of
it.
But
that's
what
I'm
saying
it's
similar
versus
the
same
and
and
then
grease
the
parts
that
you
have
in
here
about
the
immutable
structure
declared
of
AP
is
what
I
added
in
was
composed
of
microservices
o2
year.
B
1.1
I
think
that's
important.
It
wouldn't
be
well
and
proposing
that
a
cloud
native
application
is
composed
of
Micra
services.
That's
that's
already
a
defined
definition
of
what
those
applications
are.
So
if
a
virtual
network
function
is
an
application-
and
it
seems
like
a
cloud
native
Network
function
would
be
an
application
and
you
would
follow
those
standards
and
then,
if
we
have
that,
if
it's
composed
of
Micra
services
and
other
parts
that
allow
it
to
be
an
application,
we'll
makarov
services
are
very
similar
to
the
virtualized
Network
function,
components
that
are
defined
in
Etsy.
B
So
now
you
have
a
mapping
on
the
application
level,
the
network
function
and
the
components
that
it's
built
from
and
I
think
that
would
allow
people
that
are
doing
application
level,
but
the
development
and
deployment
to
know
on
both
sides.
If
you're
familiar
with
the
networking
world
or
the
cloud
native
platforms,
what
you
want
to
do
and
then
I
think
the
rest
of
it
is
as
1.1.
So
that
goes
down
to
this
saying
what
Etsy
defines
a
virtual
network
function
is
and
then
going
on
from
there.
C
Think
going
back
to
one
of
your
earlier
comments
as
well
about
what
is
a
well-defined
external
interface
and
well-defined
functional
behavior.
We
could
add
the
they
are
defined
by
industry
standard
specifications.
You
know
Thomas
mentioned
3gpp,
for
example.
You
know
that
that
I
think
that's
how
I
would
read
it
in
that
they
are
defined
by
a
an
industry
specification
I.
D
C
F
G
Is
do
we
want
to
do
we
want
to
add
in
the
the
concept
of
of
having
to
tie
mechanism
to
talk
to
us?
You
know
QA
to
or
set
of
specifications,
because
this
is
something
that
will
probably
happen.
Organically
organically
anyways
grew
through
the
market
and
one
of
the
things
that
I
want
to
be
a
bit
careful
with.
Is
that
we
don't
we
don't
deny
groups,
you
have
more
esoteric
needs
or
I
want
to
or
want
to
experiment,
so
they
can
try
to
push
the
boundary
further.
B
B
From
the
standpoint
of
saying,
you're
from
a
virtual
virtual
network
and
a
function,
we're
saying
that
those
standards
like
one
of
them
is
you're
going
to
use
for
drill
hardware
abstractions,
so
to
be
able
to
your
some
point,
you're
going
to
implement
some
type
of
connectivity
to
the
network
and
hardware
but
you're
using
some
type
of
abstraction
layer,
and
it
seems
like
when
you
get
down
to
the
external
interfaces
and
functional
behavior.
There's
there's
this
edge
between
what
the
standard
is
and
then
how
you're
going
to
implement
it.
B
If,
if
you're,
if
you
have
a
standard
that
requires
you
to,
let's
say
that,
maybe
if
either
the
functional
behavior
or
the
interface
from
the
standard
that
you're
wanting
to
integrate
with,
would
not
allow
you
to
do
it
in
a
cloud
native
way.
I
think
that,
should
we
shouldn't
make
the
definition
of
a
CNF
limit
it
to
a
standard.
B
That's
not
cloud
native
and
said:
I
think
we
should
say
this
network
function,
that's
implementing
that
functionality,
that's
required
in
the
industry,
because
the
authority
out
there
is
not
cloud
native
and
I
think
that
would
be
ok,
so
we
could
say
we
have
95
percent
of
our
network
functions
are
now
positive.
This
set,
which
are
critical
to
the
business
or
not
cloud
native,
and
here
are
the
reasons
why
and
then
you
work
on
the
standards
to
allow
them
to
be
implemented
if
possible.
B
But
what
we're
talking
about
is
a
set
of
principles
and
definite
will
definitions
but
principles,
and
they
that
you
can
follow
that
will
give
some
benefits.
If
the
benefits
do
not
meet
your
needs,
then
you
select
something
else
or
we're
saying
is.
If
you
follow
the
principles
and
they
give
the
benefits,
then
someone
should
be
able
to
say
I've,
followed
all
the
criteria
and
meet
those
the
what's
required
to
get
the
benefits
based
on
definitions.
C
B
G
B
Response
I
predict
and
then
you
can
add
M.
What
I
was
saying
was
if
there's
a
standard
out
there.
So
this
goes
with.
We
need
to
be
able
to
integrate
with
brown
field
and
there
could
be
things.
I've
done,
a
lot
of
work
with
stuff,
that's
legacy.
You
can
have
stuff,
that's
been
running
for
20
plus
years
and
you.
B
C
B
Something
that's
running,
and
you
can't
implement
that
in
a
cloud
native
way.
That's
okay!
It
just
happens
to
be
one
of
one
of
the
one
particular
application
that
you're
going
to
implement.
That's
not
going
to
be
able
to
follow
all
the
standards.
That's
okay,
whatever
it
is.
What
I'm
saying
is
the
cloud
native
network
function?
Definition
should
focus
on
being
cloud
net.
D
B
Can
be
cloud
native
in
my
mind,
I
mean
that's:
ok,
typically
wet
stuff,
like
network
service,
mesh
and
other.
You
know
many
other
projects
and
are
trying
to
solve
how
to
do
these
layer.
2
things
in
a
cloud
native
way,
I
think
that
you
can
do
all
of
if
we
say
OSI
layers
in
a
cloud
native
way,
and
if
you
go
into
very
specific
examples,
I'm
sure
that
we
could
go
through
and
find
something
I
would
say.
This
is
not
possible
to
do
in
a
cloud
native
way
and
you
don't
have.
C
B
Think
about
networking,
there's
enterprise
applications
and
many
other
applications
that
you
could
say
the
way
you've
designed
this
does
not
allow
you
to
build
a
cloud
native
version.
You'd
have
to
redesign
it
completely,
which
is
ok.
Not
all
principles
are
going
to
be
beneficial
to
solve
all
problems.
H
This
is
Watson,
here's
one
thing
also
to
keep
in
mind
with
the
definition
of
cloud
native
micro
services
and
so
on
and
so
forth.
Even
in
this
paper,
if
we
were
to
say
you
know,
put
what
definition
we
want
here.
If
you
have
a
monolith
and
then
you
say
that
it's
cloud,
Native
communities
just
going
to
say
no,
it's
not
regardless
of
what
we
put
here.
So
there
are
certain
certain
patterns
who
might
consider
an
anti-pattern,
and
you
know
it's
just
we're
not
going
to
be
fooling
anyone.
So
it's
something
to
be
aware
of.
H
D
Fundamentally,
these
these
standards
that
we're
discussing
very
very
seldom
defines
something
that
dictates
a
certain
way
of
implementing
a
network
function,
so
whether
it's
implemented
as
a
network
function
or
as
a
million
of
modules,
which
are
micro
services.
These
questions
are
typically,
you
know,
orthogonal
to
what
these
standards
define,
which
is.
Basically
what
is
the
protocol
we
are
using
for
communicating
and
what
is
the
you
know
the?
D
What
are
the
state
transition
diagrams
and
so
on
that
we
need
to
adhere
to
so
I
I
see
in
many
cases
that
when
it
comes
to
telco
standards,
they
sort
of
ignore
whether
the
implementation,
fulfills
the
crowd
cloud,
native
criteria
or
cloud
native
definition,
or
not.
They
just
look
at
how
these
functions
communicate
through
their
API,
so
through
their
interfaces.
So
I
I
don't
see
anything
wrong
here
with
the
approach.
I
just
wanted
to
understand
what,
when
you
said,
you
know
non
cloud
native
standards.
How?
How
do
you
mean
that.
G
So
so
part
of
it
probably
what
I
the
reason
I
brought
that
particular
thing
up
in
the
first
place
was
first
worst
case
scenario
and
I.
Don't
think
anyone's
doing
this
here
anymore.
It
is
we
don't
we
don't
say
it
must
be.
B
host
user
must
be
mammoth,
or
you
know,
here's
here's
the
blessed
the
Bloodless
I
in
these
standards
when
I'm
glad
to
hear,
like
the
other
various
founders,
don't
push
into
the
implementation
to
who
to
that
degree
as
well.
So
for
me,
that's
a
very
good
time.
G
The
one
thing
that
I
was
thinking
of
is
we
need
to
make
sure
that
there's
some
form
of
flexibility
for
for
operators
to
be
able
to
choose
what
what
they
want
within
their
their
infrastructures
and
also
the
flexibility
for
vendors
to
pick
and
choose
things
that
that
works
for
them
and
I
want
to
be
a
little
bit
careful
because
we
we,
we
say
that
industry
best
best
standards
like
that.
You
know
which
standards
are
we
talking
about?
G
Which
ones
are
going
to
be
the
the
ones
that
are
blessed
or
not
like
for
me
that
that
could
be
a
best
practice
that
we
drive
for
saying
we
highly
recommend
you
use
industry,
well-known
standards
and
and
so
on,
but
but
I
also
to
be
careful
with
not
creating
a
definition
that
becomes
dependent
on
an
external
on
an
external
standard,
and
my
preference
would
be
that
we
that
we
have
part
of
the
cloud
native
happy.
You
stayed
what
you're
right.
G
You
stayed
how
you
communicate
with
the
outside
world,
like
you
can
say:
I
speak
ma'am
if
I
speak
via
user
I
speak
a
Charo,
V,
directly,
DB,
K
or
so
on,
and
you
specify
with
payload
that
you
have
like
my
halo,
is
gonna,
be
IP
or
Ethernet
or
MPLS,
or
something
else,
and
that
way
that
you
can
give
you
you're
not
created
a
declarative
set
up
that
allows
your
Orchestrator
to
pair
things
together.
You
give
it
enough
conduct
that
they
can
start
pairing
things
or
tell.
B
Don't
think
that
defining
having
a
declarative
manner
for
saying
here's,
what
we
want
thee,
either
a
network
function
or
platform
is
fredrik,
saying
I,
don't
think
that
stops
us
from
using
existing
standards.
What
the
suggestion
is,
is
we
don't
have
those
external
standards
as
part
of
the
definition
of
a
cloud
native
network
function?
B
Instead,
we
say
here's
how
a
cloud
native
network
function
should
behave
and
here's
how
we
expect
it
to
be
developed
and
the
platform
support
that's
expected,
and
you
can
talk
about
all
the
different
layers
which
are
in
other
areas,
not
in
this
intro
and
then,
as
far
as
implementation,
you're
saying
when
you're
following
these
principles,
we
want
to
be
able
to
support
existing
standards.
Well,
that's,
that's
would
be
developing
an
application
to
meet
a
specific
standard,
so
I
don't
think,
there's
anything
that
we're
suggesting
to
define
being
cloud
native.
B
That
would
say
you're
not
able
to
meet
a
majority
of
the
standards.
I.
Just
put
it
as
a
a
note
that
there
could
be
specific
example,
application
or
alse
a
virtual
network
function
or
a
nsv
platform
component
that
you
wouldn't
be
able
to
implement
in
a
way
that
someone
would
recognize
it
in
a
cloud
native
way,
but
as
far
as
following,
if
we
had
a
cloud
native
definition
of
a
CNF,
that's
fully
cloud
native
and
not
saying
it's
using
it's
it's
using
an
external
standard
and
it
must
have
those
interfaces.
B
Then
you're
still
open
to
implementing
this
doesn't
block
us
in,
and
that
seems
like
when
you
would
say,
what's
an
example
of
a
cloud
native
5g
session
border
controller.
Well,
that's
probably
something
that
we
could
have
an
example
section.
How
would
you
create
that
as
a
cloud
native
and
you'd
probably
break
that
down
and
say
here's
how
it
could
look,
so
it's
not
stopping
either
integration
or
implementation
of
those
standards.
It's
as
Frederick
said
we're
not
locking
ourselves
into
expanding.
Someone
could
build
a
brand-new
greenfield
platform
that
doesn't
maybe
uses
completely
different
protocols.
B
B
So
I
think
the
plan
is
with
this
definition
we're
coming
up
on
the
hour
and
what
we're
going
to
do
here.
We
were
going
to
schedule.
Some
follow-up
calls
ideally
have
have
it
available
for
some
of
the
folks
that
are
in
asia-pacific
that
weren't
able
to
join
give
them
a
time
to
review.
This
call
is
recorded,
so
hopefully
that
can
be
sent
out
and
folks
can
review.
B
And
then
get
some
I
guess
more
feedback
from
hopefully
more
operators
that
are
that
are
out
from
what
I'm
hearing
it.
It
sounds
like.
The
part
that
is
agreed
is
or
may
be.
Moving
towards
agreement
is
a
cloud
native
Network
function
seems
to
be.
We
could
say
that
it
is
an
application,
a
cloud
native
application,
I
think
there's
agreement
on
that
and
it's
based
on
components
or
pieces,
and
maybe
we
can
say
that's
micro-services,
but
there's
I
think
we're
saying
it.
B
It's
a
the
application
level
versus
a
CNF
is
a
micro
service,
at
least
I'm
hearing
that
there's
more
movement
towards
that
I
think
that
would
be
alt
for
if
you
look
at
the
definitions
to
simplify
it
versus
all
three.
So
it's
a
network
function
is
like
a
cloud
native
application
which
is
similar
to
a
virtual
network
function
and
that's
made
of
a
micro
services
which
are
similar
to
virtualized,
Network,
function,
components
and
not
to
say
we're
going
to
use
all
four.
B
B
Yeah
I'll
glue
that
and
then
we
seem
to
be
in
agreement
that
there
needs
to
be
something
about
what
are
some
of
the
principles
with
some
of
them
they're
pointing
out
a
mutable
infrastructure
or
declarative
API
is
micro
services
and
that
repeatable
the
employment
process.
That's
one
of
them
that
keeps
coming
up
in
reference
to
the
cloud
native
principles,
specifically
saying
if
it's
CN
CF
definitions
and
we're
talking
about
cloud
native,
those
may
be
moved
into
a
later
chapter.
B
B
G
B
Music
group
third
Monday
call
I'm,
if
that's
unless
that's
too
soon,
but
thinking
that
we
don't
have
a
lot
of
time
for
we're
going
to
get
feedback
with.
If,
if
we're
trying
to
get
this
done
before,
coupon
and
publish
there's
just
not
a
lot
of
time,
but
we
could
spread
it
out.
Maybe
you
know
this
depends
on
what
folks
want.
G
So
one
left
one
last
thing
as
well
unrelated
to
the
to
the
white
paper,
so
I
just
want
to
make
a
quick
announcement,
so
there's
an
edge
computing
world
event
coming
going
on
in
Mountain,
View
in
early
mid-december
and
I'm
part
of
the
program
committee
to
help
load
it
up
with
with
people
on
the
networking
track
and
there's
still
a
couple.
Lots,
open
and
I
want
to
make
sure
we
get
some
cloud
native
it
talks
and
apt
in
your
path.
G
I
G
B
B
So
I'm
not
hearing
anything
other
suggestions
for
a
follow-up
and
I
will
say
that
main
reason
I
was
doing
tomorrow
was
5:00
a.m.
Eastern
was
I,
know
that
there's
some
conferences
going
in
Shanghai
and
I
think
that
it
ends
on
Wednesday
and
I
could
see
folks
traveling
to
try
and
I,
hopefully
get
some
of
those
folks
to
join
so
they'd
see
this
in
their
evening,
but
not
midnight.
So
that
would
be
good.