►
From YouTube: CNCF CNF Working Group Meeting - 2020-11-30
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
I
think
we
can
probably
get
started
here.
So
thanks
everybody
for
joining
today.
A
Thanks
for
the
comment
in
the
chat,
this
is
the
telco
version,
so
this
is
the
I
guess,
like
second
kickoff
meeting,
if
we
can
say
that
of
the
cnf
working
group
notes
on
top
and
the
agenda
for
today.
First,
I
want
to
say
thanks
to
anybody,
that's
contributing
to
the
discussion
right
now
in
the
the
slack
channel.
A
I
think
it's
been
like
quite
a
lively
discussion
and
I'd
like
to
kind
of
address
some
of
those
points
today
in
the
agenda
and
so
quickly
going
over
that
we'll
just
do
like
a
quick
overview
of
what
we're
doing
talking
about
like
how
we
think
the
the
group
can
work
and
then
kind
of
addressing
some
of
those
discussion
points
that
have
been
brought
up
in
the
slack
channels,
especially
around
like
what
is
our
audience
and
how
do
we
incorporate
them
into
what
we're
doing
so?
A
We're
really
focused
on,
like
the
the
outcomes
of
this
group
before
we
get
started,
is
there
anybody
else
that
would
like
to
add
something
to
the
agenda.
A
Okay
hearing
none,
I
think
we
can
get
started
so
and
also,
please
feel
free
before
any
other
meetings
to
add
things
to
the
agenda
whenever
you
want,
and
so
the
first
thing
I'm
going
to
point
out
for
those
who
weren't
able
to
attend
the
like
official
kickoff
meeting
at
cubecon,
there's
kind
of
like
two
different
things
you
can
do
here.
One
is
you
can
rewatch
it
on
the
cncf
youtube
and
the
second
thing
is,
we
also
put
together
a
short
overview
deck
of
the
working
group.
A
Now
this
will
be
a
living
document.
It'll
be
updated,
but
the
link
will
stay
the
same.
So
if
you
want
to
pass
this
off
to
other
internal
colleagues
and
chat
about
it
or
provide
comments
like
on
the
deck,
please
feel
free
to
do
that
and
use
that
as
the
way
to
pitch
it
to
other
people
that
may
be
interested
in
the
group
now.
I
know
a
lot
of
people
on
the
on
the
call
today,
weren't
or
sorry
were
at
the
kickoff
meeting
kubecon.
A
So
I
won't
go
through
the
overview
deck,
because
it's
a
lot
of
what
we
went
over
then.
So
the
current
focus
is
on
is
on
the
the
best
practices
and
requirements
for
telecom
targeted
like
cloud
native
workloads,
and
I
guess
the
the
first
thing
that
ties
a
little
bit
into
what
we
were
talking
about
before
is
like
what
should
this
group
kind
of
focus
on
in
terms
of
the
the
benefits
of
like
cnfs?
A
Thank
you
victor
for
creating
like
this
first
pull
request
in
terms
of
the
the
charter,
and
so
I
guess
I
wanna,
like
maybe
jump
into
the
discussion
here,
is
what
do
people
think
is?
Does
anybody
have
any
other
ideas
of
like
what
should
be
included
in
the
charter?
Did
anybody
not
have
a
chance
to
create
the
polar
cross
that
they
wanted.
A
B
B
B
On
so
I
guess
the
the
idea
would
be
like
blueprint
or
or
sort
of
reference
architecture
of
cloud
native
network
functions.
C
Think
it's
this
taylor.
I
think
it's
at
least
going
to
come
up
in
discussions.
I
so
I
would
say
it's
not
that
we
should
avoid
discussing
infrastructure
and
and
the
architecture
and
everything
else
it's
going
to
come
up,
so
it
would
be
is.
Is
it
in
scope
at
some
point
to
actually
try
to
test
and
talk
about
the
best
practices?
A
Yeah,
I
guess
if
I,
if
I
could
jump
in
here
too,
for
a
second.
I
know
one
thing
that
cntt
and
I
guess
the
new
new
kid
under
lf
networking
is
talking
about
like
building
the
like
an
actual
like
reference
architecture
based
on
kubernetes.
So
maybe
could
you
tell
how
you
see
the
group
of
the
work
that
you're
suggesting
in
this
group
as
different
from
that
effort,
because
we
don't
want
to
like
duplicate
efforts
here.
A
D
Hey
bill,
this
is
andrew
from
red
hat,
just
just
a
quick
one,
I
guess
on
sort
of
conformance
and
reference
architectures,
I
think
you
know
one
one
of
the
complexities
of
of
dealing
with
telco
is
that
they
have
many
many
constraints
around.
You
know
how
they
produce
architectures
and
actually,
as
we
think,
about
the
types
of
applications
that
will
go
from
you
know
more
traditional
heavyweight
into
sort
of
cncf
kind
of
environment.
Some
of
those
restraints
are
going
to
come
with
them.
D
Some
of
these
applications
do
not
naturally
fit
into
this
environment.
Now
that
doesn't
mean
they
can't
be
adapted
to
do
so.
I
think
there
are
limitations
for
some
of
them,
but
you
know
I
I
I
guess
just
trying
to
use
my
words
carefully
is
sort
of
strict
reference.
Architectures,
I
think,
are
difficult
to
do
when
it
comes
down
to
telco.
D
You
know
the
idea
that
you
know
without
a
specification,
so
I've
used
this
example
before,
but
you
know
you
take
meth,
for
example,
right
it's
clear
specifications
around
protocols,
around
interfaces,
fives,
etc
without
specifications.
Reference
architectures
are
rather
hard,
and
you
know
one
of
the
wonderful
things
about
kubernetes
is
it's
a
framework
rather
than
you
know,
a
true
set
of
specifications,
and
I
think
it's
difficult
at
that
point
to
to
get
conformance
against
very
strict
reference
architectures.
I
think
you
know
things
like
being
able
to
provide.
You
know.
Guidance,
I
think,
is
very
good.
D
You
know
in
sense
of
a
group
that
has
you
know
good
skills,
good
knowledge
and
a
good
goal
around.
What's
a
good
way
of
doing
things
from
kubernetes
point
of
view,
but
I
think
that
has
to
be
taken
in
context
with
the
application
approach,
because,
ultimately,
it's
the
applications
here
that
we're
really
trying
to
support
rather
than
just
a
kubernetes
platform.
So
there's
just
a
couple
of
my
thoughts.
A
Yeah
absolutely-
and
maybe
I
could
address
like
the
last
part,
specifically
because
I
think
this
has
been
a
point
of
confusion
for
like
quite
a
few
people
in
terms
of
conformance
versus
best
practices,
and
this
also
came
up
in
the
conversation
in
the
slack
with
the
comments
from
ian
that
right
cloud
native,
isn't
exactly
like
a
thing.
A
This
working
group
is
to
help
people
understand
where
they
are
on
that
spectrum
and
what
would
be
the
benefits
of
becoming
like
more
cloud
native,
and
so
I
think
we
might
want
to
move
a
little
bit
away
from
saying
we're
talking
about
conformance
specifically,
because
I
know
it's
quite
a
loaded
term
in
the
telco
industry
and
maybe
move
more
towards
talking
about
like
best
practices.
D
A
Yeah
great,
so
maybe
as
like
an
action
point,
I
like
before
the
next
meeting,
I
could
kind
of
go
through
what
we
have
so
far
and
kind
of
like
update
some
of
the
documentation
to
make
sure
that
we're
talking
about
like
best
practices,
rather
than
conformance
unless
anybody
else
wants
to
raise
their
hand
and
say
like
this
is
something
that
they
want
to
work
on.
C
So
it's
unlike
some
tests
that
are
just
going
to
be
pass,
fail
this
one
you're
you're,
really
looking
at
that
spectrum
that
bill's
talking
about
so
any
type
of
phrasing
or
wording
that
you
see
that
looks
like
you're
locked
in
versus
it's
just
helping
you
to
know
how
well
you're
doing-
and
I
think
this
would
tie
into
something
gergae
had
talked
about
in
slack
2
and
maybe
daniel
as
well.
C
If
you're
looking
at
requirements
for
yourself
as
a
service
provider
and
saying
we
need
to
have
some
type
of
integration
or
performance
or
something
else
and
there's
a
gap
or
some
capability,
that's
not
there
on
a
kubernetes
based
deployment,
then
by
all
means
you're
saying
this
part
of
the
solution
is
not
going
to
be
as
cloud
native.
That's
fine!
C
C
So
this
this
won't
be
what
we're
coming
up
with
these
best
practices.
You
could
think
of
them,
as
maybe
more
a
la
carte
you're
going
to
go
through,
and
someone
make
a
say,
we're
doing
great
on
security,
for
how
you're
going
to
handle
security
on
a
kubernetes
based
platform.
But
we
need
to
do
something
else
here
if
we
want
to
take
advantage
of
the
benefits
and
then
something
else
you
may
say,
we
need
to
not
do
this
at
all
because
of
our
needs.
A
Yeah,
so
I
think
that
may
be
kind
of
like
a
good
like
transition
into
how
we're
thinking
about
like
structuring
the
work
right
now,
so
that
people
can
understand
that
it's
kind
of
more
a
la
carte
and
so
the
process
for
defining.
I
guess
it's
not
requirement
best
practices
and
so
taylor
of
I
taylor
and
I've
created
like
a
template
similar
to
the
kubernetes
enhancement
proposal.
A
The
cut
process
used
in
kubernetes,
which
is
similar
to
the
process
used
in
rust
and
python
2.,
and
I
guess,
as
we
as
we
found
out
the
the
hardest
thing
in
computer
science
is
always
naming.
So
I
think
taylor,
maybe
the
first
thing
that
we
need
to
do
based
off
this
discussion
is
actually
maybe
rename
the
templates,
because
it's
not
specifically
conformance
that
we're
talking
about
but
best
practices.
A
Now,
if
anybody
has
a
better
name
here,
taylor
and
I
tried
to
come
up
with
a
a
name
but
didn't
have
an
idea,
and
so
we
want
to
create
kind
of
like
a
template
to
help
structure
the
work
and
the
discussion
here
that
we're
doing,
and
so
I
think,
taylor,
one
of
the
things
that
we
need
to
do
is
remove
conformance
from
this
and
maybe
move
it
to
like
best
practice.
A
So,
if
anybody's
familiar
with
the
work
in
kubernetes,
a
lot
of
it
now
is
structured
through
kubernetes
enhancements
and
it's
kind
of
a
template
to
structure
like
what
we're
going
to
be
talking
about,
and
this
is
kind
of
how
we
see.
A
People
like
working
in
this
work
group
to
propose
like
cloud
native
best
practices
that
they
think
should
be
followed
and
so
similar
to
that
there's
kind
of
a
release:
sign-off
checklist,
summary
motivation,
goals,
non-goals
the
actual
proposal
with
user
stories,
notes,
reference
constraints,
references
alternatives,
the
testing
plan,
the
scoring
and
the
implementation
history,
and
so
I'll
dive
kind
of
into
like
each
of
these
more
specifically.
But
if
anybody
has
any
questions
or
feedback
or
comments
about
this
process,
this
is
kind
of
like
our
first,
like
idea
of
how
we
should
do
it.
A
E
A
couple
questions
real
quick
before
we
dive
in
I'm
kind
of
confused
now,
because
it
seems
like
the
scope
of
this
has
shifted
over
the
weekend.
So,
like
a
couple
things,
if
we're
not
doing
requirements,
then
what
makes
our
best
practices
any
more
than
just
our
opinions
written
down
on
paper
like
how?
What
is
the
determining
factor
to
say
that
this
is
a
good
practice
that
you
should
be
doing
b2
if
we're
just
now
doing
a
collection
of
best
practices?
E
E
But
you
know
we
have
like
5000
reference
architectures
floating
around,
and
people
forget
that
the
first
word
is
reference,
so
I
can
go
and
reference
something
and
do
an
architecture
off
of
it.
But
it's
probably
not
going
to
be
the
same.
So
how
do
I
apply
best
practices
to
cntt's
re2?
F
I
I'll
second,
that
I
I
have.
I
sort
of
my
hackles
went
up
a
little
bit
when
I
heard
the
term
best
practices,
because
that
is
a
very,
very
squishy
thing,
and
I
think
that
perhaps
what's
getting
a
little
bit
lost
here
is
that.
F
We're,
starting
from
the
point
of
view
of
we
can
do
things
rather
than
thinking,
perhaps
more
in
terms
of
the
thing
that
we
want
to
ultimately
do
and
what
we
need
in
order
to
get
there
so,
and
I
think
that
there
are
lots
of
different
answers
to
that.
Second
question:
different
people
have
different
answers
and
it
might
be
worthwhile
collecting
those
with
some
specificity
as
to
what
people
are
actually
trying
to
achieve.
C
About
so
we've
gone
back
and
forth
on
having
hard
requirements,
and
that
could
go
whether
you
have
some
type
of
scoring
system
that
doesn't
that
does
pass
fail
or
you
could
still
have
a
gradient,
but
these
are
hard
requirements
and
we're
expecting
everyone
to
follow
them.
I
think
in
the
end,
and
whatever
you
put
if,
if
someone
says
it's
not
valuable,
they're
not
going
to
do
it.
So
if
you
look
more
at,
I
guess
what
cncf
does
in
general,
with
options,
it
gives
you
a
lot
of
options.
C
The
landscape
is
to
help
you
go
in
and
find
different
things
for
categories
that
you
may
need.
So
it's
it's.
I
wouldn't
say
that
the
point
with
this
is
to
throw
out
every
best
practice
about
any
applications
running.
So
if,
if
we
re-look
at
this,
the
idea
was,
if
you're
going
to
run
networking
or
a
telecom
specific
applications.
C
How
would
you
take
those
and
then
run
them
on
a
kubernetes
based
platform
and
get
and
make
it
as
efficient
as
possible,
leveraging
capabilities
and
kubernetes
and
everything
else
so
that
you
really
need
to
look
at
specific
applications?
What
are
real
real
world
applications?
Okay
and
then
talk
about
their
features
and
how
you
may
best
run
those.
G
Can
we
just
let's
not
have
a
you
in
that
sentence,
which
is
the
you
that
cares
that
a
cnf
is
you
know,
running
properly,
assuming
that
it's
a
bunch
of
microservices
with
a
mutable
infrastructure?
Who
cares
most
about
that,
because
I
don't
see
how
that
matters
terribly
much
to
a
service
provider,
who's
buying,
an
application
from
somebody
else
that
it's
made
from
a
bunch
of
microservices
if
it's
made
from
a
bunch
of
microservices
or
not
if
it
delivers
the
service
and
it's
maintainable
and
it's
operable
and
so
on
and
so
forth,
then
we're
good.
G
But
there
are
a
lot
of
questions
about
actually
can
it
deliver
that
service
today
and
what
is
that
service?
And
is
there
any
framework
about
what
it
looks
like?
Those
are
best
practices,
I
think,
would
be
very
valuable,
but
I
I'm
concerned
that
if
we
skip
past
that
level
of
requirements,
the
level
of
requirements
that
actually
matter
that
it's
doing
a
job,
that
we
all
recognize
and
we
jump
to
it-
doesn't
matter
whether
or
not
it
does
anything
useful
it
just
matters
that
it
runs
as
a
bunch
of
micro
services.
G
Then
we
we've
we've
like
a
lot
of
projects.
At
the
moment,
we've
basically
just
pretended
that
we
all
understand
what
the
requirements
are
and
skip
straight
to
design
again.
D
Okay,
I
guess
the
difficulty
with
that
would
be.
Is
you
know
how?
How
do
we
determine
that
it's
useful
and
so,
rather
than
using,
we
you
all
use
we.
So
how
does
how
does
anybody
determine
it's
useful?
Well,
it's
completely
subjective
based
on
the
environment
that
it's
going
to
go
in.
I
think
there's.
E
Though,
like
uptime,
if
we
do
something
that
reduces
up
time,
it
should
be
mixed.
You
know
I
mean
there
are
some
core
things
that
I
don't
think
a
single
one
of
us
would
dispute
is
a
core
requirement,
and
I
see
some
really
fancy
technology
that
comes
out
from
here
and
there
and
it'll
like
fundamentally
violate
one
of
these
core
requirements
for
just
networking
in
general,
like
junior,
you
know,
network
plus
type
stuff
and
those
questions
never
get
asked
of.
You
know.
E
G
I
could
give
you
well
I'd,
say
better
examples,
different
examples,
right
one
is
that
we
are
looking
for
a
cnf
that
can
do
at
least
in
many
cases
fast
networking.
In
other
cases,
if
you
like
clean
networking,
we're
the
networking
that
kubernetes
familiar
with
so
a
requirement
for
cnf
is
that
it
uses
a
set
of
interfaces
that
it
would
expect
to
find
in
the
platform
to
deliver
those
that
functionality
and
without
documenting
what
that
kind
of
functionality
is
we
aren't
going
to
get
those
interfaces?
That's
one
example
we
expect.
G
I,
I
think
everybody
would
agree
with
me
that
cnfs
are
mostly
provided
by
vendors
and
that
run
on
a
platform
that
isn't
provided
by
the
vendor.
So
some
sort
of
understanding
between
vendor
and
platform
would
be
necessary
for
that
to
work.
We
expect
that
a
cnf
is
deployable
now
the
application
deployment
stuff
that
I've
seen
in
the
community
largely
assumes
that
kubernetes
is
actually
a
part
of
the
application,
but
that's
not
the
model
we're
trying
to
follow
here.
G
So
what
a
deployable
application
is
what
an
application
is,
and
certainly
what
a
cnf
is
not
well
defined
in
this
particular
environment,
and
I
I
said
this
on
the
channel
and
I'll
say
it
again
that
there's
more
than
one
audience
here,
we
tend
to
focus
on
the
telco
itself
as
the
only
people
that
matter
here,
but
they're,
just
one
of
about
four
audiences
that
you
can
reasonably
consider
while
deciding
what
a
cnf
is
and
what
it's
good
for,
because
yeah
we
need
to
make
it
so
that
they
can
operate
it
and
that
effectively
builds
a
be
a
mobile
or
a
cable
or
whatever
network
for
them.
G
But
on
the
other
hand,
we
also
need
to
make
sure
that
an
application
team
independent
of
that
telco,
because
this
is
not
quite
the
devops
environment-
we're
thinking
of,
can
be
supportable
that
the
platform
can't
be
broken.
These
things
right,
different
audiences
need
different
things
and
they
all
need
to
be
satisfied
for
a
successful
system.
D
I
would
agree
with
what
you're
saying
I
think,
as
always
the
devil's
in
the
details.
Isn't
it
I
mean
what
certainly,
what
we've
found
from
doing
doing
integration
and
our
on
not
name
any
vendors.
Is
you
know
the
less
complex?
The
application
you
know,
sort
of
as
you
head
from
web
service
down
to
complex
network
function,
is
the
more
complex
they
get.
D
The
more
integration
work
is
required
and
it's
required
at
all
the
various
levels,
all
the
way
down
to
to
the
hardware
right
down
to
we've
found
everything
from
you
know,
microcode
to
biosis
to
all
sorts
of
things
that
need
tweaking
and
that
I
think
that's
that's.
The
challenge
really
is
where,
where
do
we
draw
the
line
in
terms
of
saying?
D
D
I
mean
one
of
the
things
I
was
considering
was:
if
it's
as
this
is
an
inclusive
group,
is
it
is
in
a
vendor
and
platform's
best
interest
to
to
contribute
how
one
would
normally
configure
something
now
you
know
whether
whether
any
particular
vendor
that
sits
on
top
of
this
is
happy
with
that
secret
sauce
being
known
is,
is
the
discussion
left
to
have
another
time,
but
you
know,
I
think
that
that's
one
way
to
do.
D
It
is
make
this
a
group
where
references
are
provided
as
well
as
we
have
a
framework
in
which
we
can
receive
them.
But
my
last
point
then
I'll
shut
up
is
you
know?
One
of
the
difficulties
is
cni.
You
know
we.
I
don't
believe
we
should
prescribe
a
cni.
I
mean
there
are
going
to
be
many
and
they're
probably
going
to
be
more
and
they
serve
different
purposes
so
that
that
does
complicate
things
as
well.
G
That
that
last
point,
I
think
perhaps
the
problem
you
might
argue
with
the
cni-
is
that
we
we've
never
and
I'll,
take
the
cntt
as
an
example
and
therefore
probably
make
a
lot
of
enemies
in
the
process.
But
you
know
the
cnt
is
busy
defining
a
lot
of
ways
in
which
you
would
put
a
reference
architecture
together,
but
I
don't
think
it's
ever
defined
what
that
architecture
actually
needs
to
accomplish.
G
You
know
the
requirements
came
in
basically
by
seeing
what
openstack
did
and
listing
them
as
requirements
rather
than
base
saying
what
does
the
cnf
need
to
do?
Why
don't
we
ask
some
cnf
designers
what
it
needs
to
do
and
listing
the
requirements.
G
B
D
B
One
aspect
I
I
was
in
the
beginning,
throwing
this
best
practices
or
or
reference
architecture
in
the
in
the
room,
but
I
really
have
a
same
sentiment
regarding
the
the
reference
architectures
and
this
kind
of
standardization
work
on
on
paper
because
never
going
to
to
cover
all
the
use
cases.
B
What
I
meant
actually
is
I'm
fully
subscribing
to
that
idea
of
a
certain
level
of
of
conformance
testing
of
the
hard,
let's
say
facts
that
could
be
created
against
some
definition,
because
it's
something
to
that
will
drive
potentially
the
the
change
in
the
in
the
environment.
So
what
we
are
facing-
and
I
can
also
bring
a
concrete
examples-
and
maybe
we
can
start
with
the
pain
points
identification
addressing
the
the
concrete
use
cases.
So
we
are
as
a
company.
B
B
We
faced
the
issue
that,
when
an
application
vendor
comes
to
us
like,
for
example,
5g
packet
core,
whatever
vendor
you
take,
they
have
a
specific
certifications
with
some
commercial
platforms,
let's
say
on
based
on
the
partnerships,
but
nobody
has
covering
everything,
and
then
we
are
in
the
in
the
position.
Okay,
how
do
we
prove
that
our
kubernetes
is
really
capable
of
running
that
application?
It
should
be
vice
versa.
B
That
application
should
actually
have
a
conformance
that's
to
confirm
that
it
can
run
in
a
generically
enough
kubernetes,
and
this
is
what
I
meant
about.
Can
we
set
a
set
of,
or
can
we
think
of,
set
of.
B
Assumptions,
blue
even
derive
them
from
the
best
practices
to
actually
make
this
cloud
native
network
function
definition,
so
what
cloud
native
function
can
do
and
what
it
cannot
do
if
it
claims
to
be
a
cloud
native
one
example,
and
I
think
it's
not
for
this
session,
but
for
for
a
further
work.
One
example
is
this
networking
approach
it's
a
one-to-one
copied
from
the
virtualized
world.
The
network
function
skips
normally
like
this
big
network
function,
skips
normally
entire
kubernetes
networking
for
whatever
and
goes
out
through
this
multinic
setup.
B
Is
this
a
practice
that
we
want
to
follow,
or
we
want
to
advocate
more
for,
like
let's
use
the
kubernetes
networking
for
that
and,
let's
make
it
say,
usable
adapted
and
so
on.
So
many
other
things
also
kernel
parameters,
bios,
you
know
stuff
that
that
could
be
taken
into
account
as
a
part
of
current
practice
and
then
qualify
it
as
a
patent
on
rta
pattern.
Something
like
that.
So.
G
I
I
agree,
but
I
would
just
say
that
each
one
of
those
things
serves
a
purpose
and
the
purpose
that
it's
serving
again
largely
there
are
say
two
purposes
here.
Actually
what
one
is
does
it
allow
the
cnf
to
run?
Can
we
bring
this
down
to
a
checklist
of
items
that
that
the
cnf
consumes
it?
This
way,
the
platform
provides
it
this
way,
because
there's
a
contract
between
cnf
and
platform
of
this
is
the
level
of
behavior.
G
I'm
looking
for
from
the
platform
for
this
cnf
to
provide
the
sla
that
it's
offering
the
other
one
is
where
you
come
into
this,
which
is
as
a
network
architect.
You
want
to
be
able
to
link
your
cnf
to
the
wider
network
and
that
being
the
case,
then
there's
a
separate
and
independent
set
of
problems.
That
says,
does
the
networking
that
we
have
allow
you
to
properly
wire
this
into
the
external
network
because,
again
you
know
kubernetes
and,
and
I'm
not
going
to
judge
multis
and
things
here,
but
the
cni
definition
as
kubernetes
has.
G
H
B
Why
I
mean
with
a
complex
environment,
a
networking
environment?
That's
definitely
one
part
of
the
of
the
blame
is
on
the
operators
who
grown
that
and
then
who
are
running
that
in
in
the
production.
But
it's
something
also
to
be
revised
in
the
cloud
native
way.
Is
that
actually
the
best
best
pattern
to
follow,
or
is
it
maybe
like?
B
Is
there
a
better
pattern
to
follow
like
recommendation
that
comes
out
of
group
or
whatever
premium,
and
there
are
some
current
practices
which
are
maybe
not
so
a
good
pattern
to
follow?
This
is
what
I'm
interested
in.
If
we
can
induce
some
some
change
into
how
we
produce
the
things
beyond
just
kubernetes
itself,
I
I.
D
Think
I
think
that
I
can
understand
where
you're
coming
from.
I
think,
but
I
mean
my
background-
is
in
networking.
Okay,
so
just
to
be
transparent,
is
you
know
the
difficulty
with
the
networking
pieces?
D
If
we
try
to
to,
I
think
if
we
try
to
make
a
conformance
for
more
simplistic
networking,
for
example
in
kubernetes
and
obviously
there's
good
reasons
for
wanting
to
do
that,
because
it's
easier
you
know
and
and
probably
is
less
less
problematic
for
everything
from
coding
to
troubleshooting
the
the
real
problem
is
that,
as
coop,
I
think
is
that
as
kubernetes
is
becoming
infrastructure.
In
that
sense,
if
you
look
at
how
it's
going
to
get
deployed
for
ran,
for
example,
it's
essentially
a
networking
infrastructure
and
it's
a
platform
infrastructure.
D
It's
an
orchestrator,
it's
it's
me
it's
many
things.
The
difficulty
is
that
networking
goes
back
20
30
years
and
a
lot
of
this
stuff
is
set
up
in
that
way
for
for
really
good
reasons,
so
you'd
actually
have
to
go
back
to
to
the
whole
networking
piece
that
has
nothing
to
do
with
kubernetes
and
start
trying
to
change
that.
Now,
I'm
not
suggesting
everything
should
stay.
The
same
forever,
but
that's
that
that
is
a
very
big
place
to
start
and
a
lot
of
these
applications
have
multiple
interfaces.
D
For,
for
many
many
reasons
I
mean
yeah
tunneling
and
everything
could
be
made
a
lot
more
straightforward
and
there
are
things
we
could
do
in
that
area,
actually
for
service
providers
and
others
to
make
things
more,
telco
friendly
with
actually
less
protocols.
Frankly,
on
the
networking
side,
but
that
doesn't
fit
all
telcos
either.
Not
all
of
them
will
want
to
run
the
particular
protocols
I'm
thinking
of
and
not
all
of
them
do,
and
I
never
will
and
have
a
religious
objection
to
pretty
much.
D
H
I
want
to
zoom
in
a
little
bit
here
and
underscore
this
point,
we're
kind
of
dancing
around
it
and
I
think
it's
a
big
one.
We
all
know
that
vanilla
kubernetes
is
insufficient
right.
The
difference
between
the
vanilla
kubernetes
and
the
the
actual
kubernetes
distributions
that
could
be
used
for
cns
is
big.
H
It's
it's
exactly
that
gap
that
has
to
do
with
networking
and
not
only
that
there
are
other
things
having
to
do
with
orchestration
and
multi-cluster.
I
know
some
of
you
are
part
of
the
multi-cluster
sig
there's
a
lot
of
work
going
on
there
and
there
are
a
lot
of
different
solutions
to
that
as
well.
H
We
so
here's
the
thing
you
know
if
there's
going
to
be
a
best
practice
that
says
well,
some
of
us
are
encouraging.
For
example,
the
use
of
multis
that
was
that
was
discussed
here
is
this
is
a
practical
good
solution
for
a
cnf.
H
G
It
does
it
does
that
job
if
I'm
a
cnf
builder
as
opposed
to
a
network
architect,
does
it
do
that
job
and
actually,
when
it
comes
to
connecting
to
the
network,
I
would
personally
debate
that
it
does
that
job
as
well
as
it
could.
H
But
yeah,
I
absolutely,
I
think
the
things
going
on
in
the
network
service
mesh
group
are
also
a
very
good
critique.
The
point
is,
you
know
if,
if
we
as
a
cnf
work
group
are
talking
about
best
practices,
is
using
multisip
best
practice
or
not.
You
know
here
we're
moving
beyond
vanilla,
kubernetes
and
maybe
maybe
we
have
to
to
an
extent,
because
this
is
where
I
think
a
somebody
who's
building
a
cnf
will
need
some
help.
You
know
what.
G
H
Can
they
do
and
what
can
they
target
and
if
they
target
multiple
technologies?
You
know
that's
where
we
get
into
the
conformance
thing
right.
Is
this
work
group
going
to
say
that
the
best
practice,
for
example,
is
to
use
multis
and
what
would
be
that
the
implications
of
that,
and
this
connects
a
little
bit?
I
know
in
an
earlier
telco
user
group
meeting,
I've
talked
about
creating
another
work
group
having
to
do
with
multispar2
to
kind
of
fix
some
of
the
orchestration
issues
having
to
do
with
motus.
E
E
Like
yeah,
but
like
I
don't
like
in
the
cnt
reference
architecture,
one
of
the
debates
we
had
early
on
was
you
know
they
put
a
requirement
down.
That
says
I
need
a
cni
multiplexer.
Well.
Is
that
a
requirement,
or
is
that
an
implementation,
slash
solution
to
meet
an
actual?
You
know
functional
or
non-functional
requirement
of
multiple
interfaces
or
packet
treatment,
or
whatever
rightly
like?
I
said,
even
if
all
we
do
is
prescribe
best
practices.
D
H
Now
right,
I'm
I'm
trying
to
keep
it
high
level.
It
was
just
an
example,
but
but
this.
I
I
What
is
the
best
practice
like,
for
instance,
a
simplification
of
the
configuration
could
be
one
one
characteristics
of
the
best
practice
in
in
order
for
it,
for
a
cnf
to
connect
to
multiple
networks.
Using
multis
can
be
a
very
complex
configuration
okay.
So
now
that
the
the
key
is
as
cnf
needs
to
connect
to
multiple
networks
so
take
5g
deployment,
5g
ram
deployment
when
you're
running
it
a
du
functionality
or
a
upf
functionality,
it
needs
to
connect
to
g
node
b.
It
needs
to
connect
to
amf
function,
it
needs
to
connect
to
smf
functions.
I
These
are
all
cnfs
or
or
or
kubernetes
applications
running
at
different
parts
of
the
cloud
right.
So
the
requirement
is
these
guys
need
to
be
able
to
communicate.
They
need
to
be
able
to
discover
each
other.
They
need
to
be
able
to
connect
with
each
other
now
trying
to
bring
in
and
saying.
Oh,
maltese
is
the
best
practice.
Why
is
it
a
best
practice?
It's
not
it's!
I
Why
not
just
stop
it
there
and
say
the
platform
must
provide
an
ability
for
a
cnf
to
be
able
to
cut,
connects
to
multiple
networks
and
stop
there
and
and
and
in
terms
of
in
terms
of
the
best
practices,
you
simply
state
that
it
should
be
very
simple
to
configure
and
it
should
be
automatically
so
that
you
can
automate
it
so
otherwise,
plumbing
all
these
pieces
is
a
pain
in
the
neck,
even
if
you
use
multis
or
use
any
other
multiplexers,
don't
even
why
even
go
to
the
multiplexers.
Why
multiplexers
right
so.
D
I
agree
this
is
kind
of
what
I
was
alluding
to
before
is
that
you
know,
as
it's
a
sort
of
a
plug-in
architecture
on
one
level,
is
the
people
who
provide
these
technologies?
So,
let's
you
know
we
talk
about
multi.
So
let's
say
multis
is
you
know
a
a
sort
of
a
almost
a
reference
implementation,
but
a
best
practice.
D
Implementation
from
the
point
of
view
of
multis
to
cope
with
is
is
the
type
of
configuration
we
we
recommend
in
the
following
use
cases
I
mean
that
that's
that's
kind
of
what
I
was
alluding
to
before
is
taking.
I
agree
with
you,
it's
like
taking
it
from
the
application
point
of
view.
Where
do
you
stop?
It's
like
well
kind
of
stop
with
the
applications
integration
at
some
point,
and
if
people
have
methods
of
doing
multiple
interfaces
or
you
know
whatever
else
you
want
to
do
with
it,
then
then
people
can
contribute.
D
A
I
mean
if
I
could
just
pause
the
conversation
for
a
minute
here.
I
know
we've
heard
a
lot
from
the
vendors
and
I
want
to
thank
all
of
you
for
your
perspective.
I
just
want
to
actually
turn
it
over.
I
know
we
have
quite
a
few
service
providers
on
the
call
too,
so
I'd
like
to
hear
from
them
too.
So
I
know
we
have
deutsche
telekom,
swisscom
bell,
canada
charter.
Sorry,
if
I'm
missing
anybody,
but
does
anybody
from
one
of
the
service
providers?
I
know
we've
had
quite
a
few
different
conversations.
J
Yeah
I
can.
This
is
ruben
from
swisscom
speaking,
so
I'm
fairly
new
to
that
group
so
so
bear
with
me
please.
J
I
was
just
listening
the
thing
on
on
requirements
or
my
view
is
that
conformance
without
having
a
shared
understanding
of
what
are
the
assumptions
is
really
difficult,
at
least
for
me
right-
and
this
is
this-
would
be
one
thing
right
without
necessarily
going
into
the
details
if
the
design
space
is
in
finite
because
anybody
can
do
whatever
he
wants,
that's
going
to
be
very,
very
difficult,
so
I
hope
I
could
express
myself
properly
here,
but
for
me
this
would
be
one
input
right.
I
mean
right
now
with
conformance.
J
And
then
the
other
thing
that
I
can
say
I
mean
I
think
there
was
this
debate
about
requirement
or
or
how
precise
we
want
to
be.
I
think,
at
the
current
time,
when
I
see
the
status
of
the
technology
and
how
fast
it
might
be
moving,
I'm
not
sure
whether
we
can
I'm
just
not
sure
how
much
we
can
look
into
the
crystal
ball
and
really
make
very,
very
strong
requirement
right.
J
J
If
I
at
least
so
my
two
cents,
if
I
come
back
on
the
on
the
whole
networking
part-
or
I
would
say
the
more-
I
mean
we
have
this
discussion
around
vanilla,
kubernetes,
not
being
enough
right,
I
mean
here
at
least
we
could
try
to
make
it
a
bit
more.
I
think
we
should
try
to
make
it
a
bit
more,
a
bit
more
precise
right,
because
again,
this
is
certain.
It's
true.
Everybody
understands
that,
but
there's
so
many
ways
to
solve
it
right
now.
J
That
might
be
clear
for
all
of
you
and-
and
it's
maybe
just
me
not
knowing
the
the
overall
landscape
enough
that
could
be,
but
that
could
be
a
place
to
start
right.
A
Yeah
does
anybody
else
want
to
speak
to
that
point.
C
More
generally,
I
would
say
an
effort
to
map
terminology
and
language
to
what
you're
going
to
find
in
kubernetes
and
right
now,
I'm
going
to
keep
leaning
into
kubernetes
instead
of
general
cloud
native.
It's
fine
to
do
this
and
we
want
the
principles
and
when
we
talk
about
something
we
can
actually
measure
we'll
have
to
get
more
precise
and
talk
about
each
implementation,
so
starting
with
kubernetes.
C
C
So
you
could
talk
about
the
a
network,
function
and
say:
well,
then,
what
would
that
be
as
a
something
running
on
kubernetes
and
and
start
looking
at
how
that
ties
in
so
then
you
can
actually
get
down
to
a
specific
application
say
this
telco
application,
which
would
be
a
kubernetes
workflow,
could
be
deployed
in
these
many
different
ways.
So
what
are
the
best
practices
on
those
things,
and
then
it
has
various
features
that
it
already
potentially
already
exists
because
it's
already
been
implemented.
C
So
how
would
you
harness
those
or
use
those
they
may
tie
into
using
cni's
or
maybe
or
some
other
networking,
or
maybe
it's
totally
different
features
like
storage?
How
are
you
storing
your
data
is?
Are
you
handling
data
on
kubernetes
in
a
way
that
it
can
help
you
do
recovery
and
and
everything
else
or
is
kubernetes
going
to
get
in
your
way,
because
you
were
you've
implemented
handling
state
in
a
way
that
you're
going
to
fight
kubernetes?
C
C
And
probably
starting
with
the
ones
that
a
real
application
and
breaking
down
the
features
and
actually
seeing
sing
rather
than
say,
let's,
let's
pick
one
particular
thing
that
has
a
gap
on
kubernetes
and
figure
that
out.
Let's
start
looking
at
best
practices
of
a
real
application
and
and
see
what
comes
out.
A
I'm
also
adding,
I
know,
there's
quite
a
bit
going
on
in
the
chat
too
in
terms
of
conversations.
So
thanks
for
everybody,
that's
adding
there
like
one
of
the
points
is
that
nfv
didn't
work
out
somewhere
between
working
working
out
very
well.
Some
people
call
it
failing
like
our
goal
is
to
help.
How
can
we
make
this
transition
better
and
that's
what
this
working
group
is
trying
to
figure
out,
and
so
what
are
the
outcomes?
We're
we're
trying
to
have?
A
Are
there
any
other
operators
that
would
like
to
kind
of
provide
their
input
or
opinion
on
where
we
should
go?
Yeah
go.
K
Ahead
dan
from
bell,
so
I've
been
vocal
around
the
fact
that
I
don't
think
like
a
reference
architecture
that
everybody's
going
to
be
applying
to
will
work.
I
think
there's
too
many
fluidity
in
that
ecosystem
to
think
that
you're
going
to
be
able
to
align
on
a
single
platform
and
everybody
agrees
on
it.
I
do
agree
with
ian's
comment
around
the
contracts.
I
think
that's
the
I
think
that's
the
one.
K
Aside
from
that,
yet
I
think
from
an
operator
perspective,
cloud
native
is
not
that
we
just
want
to
have
a
packaged
cnf
for
a
package
container
workload.
Is
we
want
to
be
able
to
leverage
the
capabilities
of
the
that
the
cloud
can
offer
us
to
do
those
services
so
rather
than
have,
for
example,
complex
control
and
sync
mechanisms
between
functions?
Can
we
leverage
gremlin
capabilities?
K
K
Those
are
the
benefits
we
want
to
get
out
of
this,
and
I've
been
vocal
about
the
fact
that
I
would
like
that
working
group
to
help
us
find
new
use
cases
or
new
ways
of
building
functions
in
a
network
that
doesn't
become
like
a
big
clutch,
big
fat
container
with
six
interfaces,
because
we
don't
know
how
to
integrate
them
together
and
make
them
like
a
more
integrated
into
a
simpler
way.
That's
from
our
perspective,
that's
the
way
to
go
whether
I
end
up
with.
K
I
end
up
with
my
own
if
we're
able
to
have
this
abstracted
con
so
that
we
can
have
that
in
the
the
class
the
single
way
of
doing
it
and
still
now
we
have
that
same
challenge
and
if
you
try
to
get
to
perfection
too
fast
in
those
kind
of
framework,
we,
if
we
aim
for
perfection
in
that
kind
of
in
the
same
ecosystem
for
cns
well,
we'll
end
up
again,
eight
years
later,
not
having
a
real,
like
industry,
approved
way
of
doing
those
functions,
and
something
else
would
have
happened
like
unique
or
knowledge
or
some
new
ways
of
doing
things
with
asics
and
the
end
will
have
the
same
results.
C
C
Then
one
of
the
things
in
the
those
proposals
is
to
say
why,
so
you
could
talk
about
the
capability
to
it,
allows
you
to
stitch
these
different
pieces
together
and
lowers.
Maybe
the
efforts
for
the
developers,
as
well
as
the
operation
side,
whether
that's
a
collaboration
between
vendors
that
are
helping
to
support,
are
the
service
providers,
ops
teams
that
they
know
that
the
applications
are
following
some
best
practice
that
they've
already
are
familiar
with,
say,
kubernetes
feature
that
helps
to
provide
some
something
for
each
of
those
applications
that
fit
together.
C
And
then,
if,
if
you
look
at
some
of
the
comments
and
the
chat
about
like
onap
and
osm
and
stuff,
you
could
say
a
an
application.
That's
helping
to
provide
maybe
enhance
enhancements
or
leveraging
the
the
capabilities
of
kubernetes
for
some
type
of
business
view
on
the
orchestration
is
likely
to
tie
right
into
the
monitoring
and
status
and
other
capabilities
of
kubernetes.
But
let
kubernetes
do
a
lot
of
the
the
legwork
behind
so
you're
you're,
not
trying
to
force
things
to
certain
way,
but
just
nudge
and
guide
things
in
a
certain
direction.
K
K
We
were
doing
in
vnf,
the
same
capabilities,
the
same
requirements,
the
same
infrastructure
requirements
we
have
and
you
need
to
ship
them
together,
sruv
pneuma
pinning
all
those
things
need
to
come
up
because
that's
the
way
we
use
from
existing
code,
the
vnf,
the
vienna
vendors,
come
from
existing
codes
to
what
is
going
to
be
happening
right
now
in
cnfs.
What
I'm
looking
at
at
some
point
is
well,
is
it
required?
So
I
understand
that
some
protocols
are
missing
in
kubernetes,
so
it's
not
was
not
built
for
some
some
of
them,
that's,
okay!
Multi-Interface!
K
Do
we
need
multi-interface
right
now
we
do
because
the
code
we
get
comes
with
it.
But
at
some
point,
if
I'm
I'm
going
to
build
a
cg
net
function
in
two
years,
do
I
still
need
multi-interface
one
for
management
and
something
and
do
I
still
need
that?
Or
can
we
look
beyond
that
because
you
don't
think
about
this,
but
adding
that
multi-interface
means
you
need
to
find
the
different
ways
of
doing
network
segmentation
in
your
cluster,
which
is
oh
by
the
way,
still
not
there
so
you're.
K
That's
the
the
trick
that
to
get
all
those
things
working,
because
you
try
to
integrate
them
as
they
were
in
vnfs
at
the
end,
we're
still
eight
years
and
there's
still
gonna
be
other
other
things
not
working,
and
that's
why
I'm
afraid
of
at
the
time
it's
gonna
take
to
align
on
this
over
time
rather
than
look
at
okay.
This
is
the
ones
we
get
for
the
next
18
months,
but
if
somebody's
building
a
new
cnf
in
2022,
why
can't
you
look
at
a
different
way
of
building
it?
K
D
D
D
E
Bill
we're
almost
at
the
top
of
the
hour.
I
just
want
to
throw
in
one
more
proposed
outcome
from
a
provider,
and
this
is
going
to
be
way
less
sexy
than
a
lot
of
the
stuff
that
we're
talking
about,
but
we've
been
pushing
kate's
out
into
our
production
network
for
like
the
last
couple
years,
and
I
think
the
vast
majority
of
us
on
the
provider
side
are
probably
people
like
me
who
work
on
like
our
development
and
office
at
the
cto
side,
but
like
engaging
with
operations
doing
things
at
telco
scale.
E
E
How
do
I
manage
you
know
multi-tenancy
right
like
if
I
don't
give
every
single
one
and
then
this
comes
to
ian's
point
about
you
know
a
single
egress
right
you,
the
problem
with
these
reference.
Architectures
right
is
it's
looking
at
a
single
piece
of
a
stack
and
then
all
of
a
sudden.
I
go
one
layer
out
my
network
and
I
have
this
aggregate
firewall
and
I
open
up
one
port
on
this
firewall
for
a
subnet
that
all
of
these
you
know
things
in
a
shared
cluster
are
now
piggybacking
off
each
other.
E
There's
just
all
these
weird
operational
challenges,
you
know
for
running,
not
like
even
the
most
basic
network
like
control,
plane,
function,
stuff
and
just
regular
web
scale.
Stuff,
like
we
don't
tend
to
run
like
two
to
three
enterprise
applications.
We
run
literally
thousands
of
applications
for
lots
of
different
people,
video
applications
and
I'm
really
hoping
one
of
the
outcomes
of
this
isn't
just
the
sexy
stuff
of.
How
do
I
get
like
a
packet
core
to
work
efficiently
in
case
but
like?
How
do
I
run
like
5000
clusters,
with
like
5
000,
different
firewall
rules?
A
Cool
thank
you
for
that.
I
appreciate
everyone's
discussion.
I
think
it's
been
just
as
lively
as
the
kickoff
meeting.
I
think
it's
great
that
there's
so
many
different
opinions.
I
know
not
everybody
can
make.
This
meeting
should
also
be
great
to
move
some
of
this
discussion
to
github.
A
So
if
you
have
an
idea
or
if
there's
some
place,
you'd
want
this
group
to
go
I'd
encourage
you
strongly
to
create
a
pr
against
the
repo
and
then
we
can
also
have
the
discussion
there
and
I
think
both
the
at
the
meetings
and
online
through
github.
We
can
help
kind
of
move
this
forwards.
So
with
that,
I
really
appreciate
the
discussion
for
today
and
I
I
hope
you
will
continue
to
contribute
to
this
group
thanks
for
joining
today.