►
From YouTube: CNCF Telecom User Group Meeting - 2021-02-01
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,
it's
for
after
now,
so
I
think
we
can
probably
get
started
if
you're
new
here,
you
can
add
your
name
to
the
meeting
minutes.
That'd
be
great
and
the
agenda
day
is
actually,
I
think,
pretty
full.
A
Okay,
just
a
couple
highlight
of
events
upcoming.
So
if
you're
not
aware
the
cloud
native
network
function,
working
group
meets
every
week
at
1600
utc.
So
in
hour
after
this,
you
can
jump
right
into
the
next
meeting.
A
There
is
an
etsy
plug
test
right
now
going
on
in
february,
if
you're
interested
in
that
more
details
in
the
link
and
also
there's
cubecon
in
may,
and
alongside
of
that,
there
is
the
kubernetes
on
the
edge
event
collected
event
and,
if
you're
interested
in
submitting
to
the
cfp,
for
that,
it's
currently
open
it
actually
just
got
announced
last
week
so
get
in
while
you
still
can
and
if
you're
interested
in
learning
more
about
running
kubernetes
on
the
edge,
definitely
sign
up
and
join
the
event
tickets
will
be
launching
later
this
week.
A
So
with
that,
I
think
most.
This
meeting
is
going
to
be
talking
about
his
networking,
orchestration
task
force
and
there's
a
link
to
the
slides
here
and
if
we
have
time,
there's
also
some
folks
from
erickson
who
want
to
talk
about,
I'm
not
sure
how
exactly
to
say
it
eno.
I
think
it
is.
But
with
that
tell
I
can
hand
it
over
to
you.
B
Thanks
so
much
bill,
so
hello,
everyone
happy
monday.
I
really
want
to
use
the
time
as
effectively
as
possible.
So
my
idea
is
this.
B
I
know
many
people
I
see
people
joining
even
now
know
what
this
is
about
already,
because
this
was
presented
in
a
previous
tug,
and
there
is
a
slack
channel
where
some
of
us
has
been
have
been
discussing
discussing
this,
but
I
will
do
a
very,
very
quick
recap
of
the
slides
just
to
make
sure
that
everybody
here
knows
what
the
general
topic
of
this
is,
and
I
think
the
core
item
of
the
agenda
that
I
I
I
want
to
get
through
today
is
organization
really
deciding
over
how
we
are
going
to
continue
to
develop
this
topic,
and
I
think
there
are
a
few
different
options.
B
So
I
think
the
core
of
the
discussion
should
be
pros
and
cons
and
some
ideas
and
how
how
to
how
to
continue
meeting.
I
guess
that
would
be
it
and
if
we
do
have
time
I
would
love
to
see
the
intro
for
for
eno
or
eno
and
yeah
we'll
see
if
we
can
leave
as
much
time
as
possible
for
that.
Okay.
B
B
Thank
you,
my
favorite
comments,
yeah.
I
I
want
to
emphasize
in
all
my
slides
here.
The
tone
here
is
not
it's.
It's
me
kicking
the
ball
forward
with
some
ideas.
If
any
of
this
seems
controversial
to
anybody,
or
you
disagree
with
something,
it
does
not
mean
that
this
is
not
the
right
topic
for
you
right
if,
if
any
of
these
lines
ring
a
bell
to
you
and
think
well,
this
is
a
problem.
This
is
something
we
can
work
on
together.
B
That's
what
I'm
trying
to
do
here
to
provoke
us.
Of
course.
I'm
writing.
Excuse
me
only
from
my
own
perspective
of
problems
that
I've
seen.
But
yes,
this
is
not
the
end
all
or
or
be
all
of
it.
B
So
with
that,
you
know
the
starting
point,
I
think,
for
a
lot
of
us
is
that
we
we
don't
have
enough
solutions
in
kubernetes
for
for
networking,
or
I
should
say
we,
we
have
solutions
that
are
technical,
but
there
are
a
lot
of
challenges
and
and
making
them
work
and
bringing
them
all
together
and
again.
One
of
the
items
in
my
agenda,
too,
is
a
gap
analysis
of
looking
at
what
we
have
right
now
and
together
trying
to
figure
out
well
what's
missing,
how
should
these
things
work
together?
B
Better,
and
I
do
not
think
we
will
finish
it
today,
but
I
thought
it's
something
we
could
start
discussing.
B
So
I'm
not
reading
through
the
signs
everybody
here
can
read,
I
assume
and
just
trying
to
talk
over
them
and
give
you
an
idea
of
what
the
tone
is.
I
will
mention
them
ian
wells
and
I
have
had.
I
thought
I
thought
a
very
interesting
discussion
on
top
of
the
slide.
So
if
you
join
the
sides
on
on
google
docs,
you
can
read
the
discussion
there.
B
What
was
interesting
for
me
is,
I
think
one
of
the
challenges
is
really
understanding.
What
a
network
even
is,
and
what
does
it
mean
to
attach
to
a
network
if
that
is
even
the
right
verb
right?
We
do
know
that
we
want
our
pods
or
maybe
services,
or
maybe
even
other
things,
other
resources
in
kubernetes
to
connect
attach
in
some
way
to
these
networks.
But
we
also
know
that
networks
are
never
one
size
fit
all
right,
and
here
I'm
mentioning
special
networks,
but
even
non-special
networks.
B
D
B
Have
very
specific
resources,
such
as
networks
with
associated
providers
and
we
have
subnets
and
we
have
ports
and
virtual
ips
and
other
related
resources
to
that.
But
those
resources
already
define
what
networking
is
and.
E
I
think
to
throw
in
and
yeah
my
comments
are
all
littered
down
the
side
you'll
see
here
and.
B
B
Why
networking
and
not,
and
not
network,
as
the
word
here
and
it
kind
of
ties
to
the
the
problem
I
was
just
talking
about,
we
don't
even
know
what
a
network
is
exactly
so
networking
seems
to
be
the
more
general
idea
here.
Orchestration
2
ian
brought
up
the
point.
That
he's
not
sure
this
is
really
about
orchestration.
B
I
think
again,
orchestration
can
mean
a
lot
of
different
things
to
different
people
and
if
you
don't
accept
my
definition,
that's
also
okay.
My
my
point
is
that,
even
though
we
have
the
low-level
solutions
to
a
lot
of
these
things-
and
I'm
not
even
mentioning
things
like
psyllium
and
submariner
and
all
kinds
of
high
performance
secure
low-level
networking
solutions
for
kubernetes,
a
lot
of
these
things
exist,
but
I
think
all
of
us
found
out
you
know
if
you've
ever
done
some
sort
of
poc
to
see
hey.
B
B
Our
challenge,
I
think,
really
is
tying
them
together
in
a
way
that
you
can
design
workloads
that
in
a
scalable
manner,
so
designing
many
workloads.
So
that's
what
I'm
calling
orchestration
here.
You
can
also
call
it
management.
B
I
think
there
are
a
lot
of
different
words
for
it,
so
I
use
orchestration
as
a
shorthand,
and
I
mean
to
offend
nobody
who
who
might
think
that
orchestration
deals
more
specifically
with
other
things.
B
Yeah
I'll
do
that.
Okay,
I
think-
maybe
I'll
just
very
quickly
just
finish
this
and
then
I'll
go
back
to
the
chat
and
just
end
this
rambling
over
the
slides.
So
one
idea
I
kind
of
talked
about
was
to
bring
back
the
the
this
ties
to
what
I
mean
by
orchestration.
B
B
Was
not
it's
not
amazing,
it
doesn't
solve
all
the
problems,
but
it
does
and
also
creates
problems,
but
it
does
have
some
idea
of
networking
as
a
service
right.
You,
you
request
the
provider
and
the
provider
provides
something.
Now
we
don't
want
exactly
the
same
thing
in
kubernetes
in
terms
of
being
able
to
provide
the
same
thing,
but
we
do
know
that
somebody
needs
to
some
component
in
the
system
needs
to
manage
this
for
us
and
manage
all
the
different
clients
that
require
that
provisioning
right,
and
I
gave
the
example
in
a
previous
tag.
B
I
created
this
poc
called
nap
that
intends
to
create
providers
for
multis
under
the
idea
that
sure
multis
you
can
write
a
cni
config
and
do
anything
with
it
really.
But
who's
going
to
be
able
to
manage
all
these
configs
who's
going
to
be
say
that
two
different
configs,
the
two
different
designers
created,
would
be
able
to
work
on
the
same
space.
So
you
need
some
way
to
coordinate
these
things.
B
Yeah,
I
think
yeah
hopefully
ian
I
I
I
I
address
that
well
enough,
okay,
so
well,
first
of
all,
before
I
really
get
into
organization
any
kind
of
high-level
comments
or
even
low-level
comments
on
on
what
I
presented
so
far,
that
you
think
can
help
us
move
forward.
B
Yeah,
of
course,
I
agree,
I
will
just
underline
that.
I
think
portability
too
can
be
sometimes
a
controversial
word
for
some
people,
we're
obviously
talking
about
being
able
to
run
on
on
different
kubernetes
solutions,
maybe
different
platforms,
but
we
also
want
to
make
sure
that,
within
our
own
organization,
we
can
actually
deploy
on
multiple
sites
and
possibly
with
multiple
technologies.
As
long
as
those
technologies
are
trying
to
achieve
the
same
thing,.
E
So
yeah,
my
my
laptop
audio,
has
decided
to
destroy
itself
and
I
don't
know
why
I
mean:
let's
not
confuse
implementation
from
interface,
because
in
an
ideal
world
we
would
have
one
interface.
I
don't
care
how
that
interface
is
implemented.
I
care
that
that
interface
is
up
to
the
job,
which
is
why
the
cni
exists
right.
We
don't
care
which
theo
were
using,
we
shouldn't,
but
we
care
that
the
cni
does
the
job
that
the
interface
describes,
which
is
why
kubernetes
applications
today
work
on
any
kubernetes
with
any
cni
plugged
in.
E
B
I,
yes,
you
know,
there's
a
delicate
balance.
I
think
there
between
the
implementation
and
the
abstraction
or
the
mottoing
above
it,
because
we
obviously
want
to
share
and
group
similarities
as
much
as
we
can
right
at
the
same
time
avoiding
the
problem
of
the
lowest
common
denominator
right.
We
don't
want
to
have
something
that
just
here's,
an
l2
network
with
some
maybe
annotations,
and
then
there
are
we.
B
We
can
probably
think
of
10
different
ways
to
implement
l2
networking
inside
on
top
or
at
the
side
of
of
kubernetes,
but
we
still
want
maybe
a
way
to
share.
We
don't
want
to
keep
reinventing
the
wheel
for
every
single
solution
and
make
every
single
solution
a
snowflake.
E
Yeah
yeah,
so
I
mean-
and
this
will
come
up
when
we
talk
about
eno
as
well
but
effectively.
Firstly,
it
needs
to
be
driven
top
down.
What
is
the
problem
that
we
have,
as
opposed
to
here,
is
a
great
solution.
Let
me
hammer
the
problem
into
the
form,
that's
into
a
form
that
this
solution
solves,
which
is
easily
done.
E
It's
it's
an
easy
thing
to
to
do,
and
it
would
be
a
mistake
to
assume
that,
just
because
I've
written
something,
it's
necessarily
the
right
idea,
the
other
one
is
perhaps
it's
worth
remembering
that
the
simpler
we
can
make
the
platform
the
more
we
can
enable
applications
on
that
platform
to
do
the
job,
the
more
flexible.
That
is
because
to
take
the
l2
network
example.
E
If
I
could
run
an
application
that
gives
me
layer,
2
networks,
then
I
solve
the
problem
of
layer,
2
networking,
but
I
haven't
exclusively
solved
the
problem
of
layer
2
networking,
so
it
might
be
that
a
simpler
platform
interface
is
actually
more
useful
to
us.
If
it
enables
more
things,
we
can
always
write
code
and
ship
it,
as
you
know,
as
default
services,
for
instance,
that's
entirely
possible,
but
if
we
don't
build
it
into
the
platform,
then
it
doesn't
mean
to
say
that's
the
only
thing
you
could
possibly
use.
You
can
be
inventive
after
that.
B
Right,
you
know,
I
I
think
one
of
the
questions
is
here
is
even
if
we
want
to
build
a
platform
right,
the
old
joke
of
you
know
we
have
10
standards,
so
let's
create
another
standard
to
standardize
those
standards
and.
E
That
much
is
true,
but
if
we
look
at
the
solutions
that
we
have
to
a
greater
or
lesser
extent,
you
can
always
come
up
with
a
problem
that
they
don't
solve.
For
so
we
do
need
to
build
something:
we're
not
building
it,
because
we're
bored
and
co-writing
code
is
fun.
We're
building
it
because
we're
actually
short
of
functionality.
B
Right,
I
suspect
that
might
be
the
case
you
know,
but
but
I.
B
Suspect
that
might
be
the
case,
I
think
doing
a
proper
gap
analysis
and
trying
to
understand
perhaps
there's
one
project.
Even
the
you
know,
project
that
we're
going
to
be
talking
about
today
that
could
be
extended,
improved,
worked
upon
or
generalized
in
some
way
that
could
do
what
we
hope
to
achieve.
We
don't.
B
I
guess
that's
my
point
and
maybe
with
that
I
I
do
want
to
move
to
the
real
pressing
topic.
As
I
said,
how
do
we
move
on
from
here
in
terms
of
organization,
because
this
this
started
kind
of
haphazard?
I
gave
a
presentation,
it
generated
some
interest
and
I
think
a
lot
of
us
realized
that
we're
all
facing
the
same
problems
and
we
could
probably
join
forces
in
and
finding
a
solution.
D
D
I
I'd
like
to
understand:
are
you
really
focusing
on
the
networking
orchestration
or
are
we
talking
about?
First
of
all,
what
we
need
to
orchestrate
so
the
fundamental
telco
networking
that's
required
for
a
healthy
cloud
native
network
function
and
then
once
we
have
that
well
defined,
we
can
start
talking
about.
How
should
that
get
orchestrated.
B
So,
okay,
well,
two
ways
I
would
respond
and
other
people
can
respond
in
different
ways.
Definitely
not
thinking
about
building
an
orchestrator,
it's
more
about
thinking
about
the
requirements
for
orchestration
generally
right.
So
I'm
not
thinking
about
building
a
management
layer,
but
I
am
thinking
about
what
kind
of
custom
resources
do
we
need
in
kubernetes
to
to
implement
that.
B
So
so
you
know
going
back
to
the
point
ian
made:
are
we
going
to
be
building
a
platform,
or
maybe
the
decision
will
be
that
we
just
need
to
create
very
clear
custom
resources
and
maybe
allow
different
kind
of
implementations
operators
to
to
actually
turn
them
into
to
a
solution,
but
have
everybody
use
the
same
set
of
custom
resources?
So
we
get
portability
that
way
right
and
you
mentioned
network
functions
right.
I
I
think
we're
even
thinking
more
abstractly
than
that
right,
I'm
not.
B
At
least
I
didn't
even
mention
the
word
network
function,
that
kind
of
encapsulation
or
network
services
or
what's
in
between,
or
you
know
what
we're
thinking
of
this
from
a
telco
perspective,
of
course
here
in
the
tug,
but
it's
not
even
just
telco
solutions
right.
There
are
other
things
that
require
advanced
and
special
networking
and
yeah.
G
So
another
quick
question
because
you're
talking
about
organization,
what
is
the
plan
to
engage
like
sig,
networking
and
kate's
architecture?
Because
the
thing
that
scares
me
is
you
said
we're
all
going
to
try
to
like
standardize
on
something.
That's
called
a
custom
resource
definition
and
custom
and
standard
tend
to
clash
pretty
mightily.
So
I'm
just
kind
of
curious
like
if
these
are
just
crds
and
operators
floating
around.
F
B
So
the
question
really
is:
how
do
we
organize-
and
I
just
threw
that
out
as
an
idea
again,
I
don't
think
that
might
be.
You
know
we
might
decide
that
the
correct
direction
is
to
go
to
sig
networking
and
to
and
to
give
a
strong
proposal
that
they
can't
say
no
to
right.
The
the
whole
group,
but
here's
the
first
question.
Should
this
be?
B
Should
we
organize
as
a
kubernetes,
sig,
telco
networking
or
I
don't
know
exactly
what
to
call
it
or
networking
orchestration
or
something
like
that
or,
but
would
that
be
the
best
way
to
move
forward
with
this
and
another
way
to
move
forward
would
be
maybe
a
work
group
within
a
cncf,
so
modeled
kind
of
like
the
cnf
work
group.
That
was
just
started
that
I
think
has
been
exciting
and
hopefully
we'll
be
productive.
B
I'm
a
bit
lost
myself,
so
I
about
how
to
move
forward.
So
I'd
love
to
hear
ideas
from
from
people
here.
B
G
The
difference
between
the
cnf
working
group,
which
says
it's
going
to
tackle
the
level,
never
I
mean
I
don't
want
to
pull
the
whole.
Like
my
group's
doing
the
same
thing,
your
group's
doing
type
thing
because,
unlike
I
felt
there
was
a
very
clear
distinction
between
what
anuket
was
trying
to
solve
and
what
the
tug
slash
cnf
working
group
was
trying
to
solve,
like
one
is
building
reference
architectures
trying
to
like
standardize
platform
side.
The
other
one
is
like
just
looking
at
like
how
to
do
networking
and
design
practices
in
case.
F
This
is
taylor.
I've
I've
been
thinking
about
this
too.
I
guess,
since
the
pr
first
presentation
tell
and
it
there's
definitely
overlap
between
all
of
them.
F
I'd
say
the
the
first
part
would
be
the
problem
trying
to
find
doing
the
gap
analysis
and
what
is
the
problem
to
solve,
and
that
could
very
much
be
in
scope
for
what
the
cnf
working
group
is
wanting
right
now
the
focus
happens
to
be
on
a
smaller
area,
but
the
overall
scope
of
the
group
is
would
include
how
do
you
make
cns
portable,
which
they
are
networking
applications?
That's
what
we're
really
saying.
F
How
do
you
make
networking
applications
that
are
going
to
work
on
as
many
you
know,
platforms
that
are
kubernetes
based
as
possible,
so
networking,
as
you
say,
versus
the
network
pal,
that's
a
central
part
of
what's
needed.
It
just
happens
to
not
be
the
current
focus
and
then
from
the
telecom
user
group
searching
and
looking
for
problems.
If
you
go
back
to
even
the
the
original
white
paper
that
you
were
working
on
gergei
the
follow-up
white
paper
that
got
completed
doing
that
type
of
gap.
Analysis
is
all
in
scope.
F
For
those,
so
I'm
not
saying
where,
at
least
on
the
analysis
and
of
the
problems
and
networking
that
you're
proposing
or
their
tell,
I
don't
see
that
as
out
of
scope
and
I'm
I'm
not
sure
that
we
need
another
group
to
say:
let's
go
find
the
problems
and
then
the
second
part
is
a
separation
of
any
type
of
solution
from
the
problem
I
think,
is
necessary.
So
if
we're
looking
at
projects
that
look
like
they're
a
potential
good
solution,
those
should
be
segmented
off
from
the
group.
F
That's
trying
to
look
and
be
unbiased,
specifically
within
cncs,
so
whether
you're
talking
about
a
working
group
or
a
sig,
the
goals
are
to
find
problems
that
end
users
may
have
and
then
try
to
look
at
the
different
solutions
and
and
within
cncf
it's
giving
people
multiple
options,
not
not
picking
one.
So
any
type
of
opinionated
solution
needs
to
be
separated.
E
We
we've
discussed
this
before
in
the
terms
of
the
audiences
that
we
have
and-
and
we
have
to
remember-
there's
not
just
one,
and
some
of
them
are
very
underrepresented
as
well,
setting
aside
the
doers
and
what
they
want
to
do
for
a
second,
then,
the
people
that
bring
problems
to
us
are
cnf
developers,
and
I
think
they
are
very
underrepresented.
What
are
they
actually
trying
to
do?
What
are
the
things
they're
finding
difficult?
E
We
know
we've
got
network
architects
within
service
providers
or
anyone
else
trying
to
solve
a
network
problem,
perhaps
also
not
terribly
well
represented,
are
the
people
who
are
actually
going
to
operate.
This
solution
need
to
figure
out
whether
or
not
it's
controllable
or
whether
it
when
it
goes
wrong.
It
will
go
wrong
in
weird
and
inscrutable
ways
they
can't
to
solve
their
problem.
There
is
in
the
cnf
working
group.
There
is
a
document
that
tries
to
expand
upon
that,
but
it
needs
to
be.
You
know
if
we
knew
what
our
audiences
were.
E
We
could
use
these
different
groups
to
actually
bring
the
right
people
together
at
the
right
time.
I
don't
need
necessarily
a
network
architect
in
the
room
to
discuss.
You
know
nitty
gritty,
cnf
programming
problems.
I
need
to
talk
to
cnf
developers
and
find
out
what
programming
problems
they
have
as
an
example
they're,
the
ones
who
have
to
talk
to
me
in
that
so
having
different
ways
of
organizing
it.
So
we
get
the
right
audience
together
to
discuss
their
mutual
problems
simultaneously.
B
That
makes
a
lot
of
sense
to
me.
I
like
to
tailor
your
separation
between
no,
I
think
it
was
ian
who
said
doers
versus
what
was
the
opposition
to
doers.
E
Problem
bringers,
I
think,
in
the
sense
that
you
know,
doers
should
be
doing
things
that
solve
problems,
but
you
need
to
define
your
problems
like
we
keep
saying
so
so
you
know
it's
fine.
We've
got
people
who
actually
want
to
change.
Kubernetes,
write
code,
write
examples
and
so
on.
E
I'm
absolutely
discouraging
those,
but
the
problem
we
have
is
that
that
you
know
we
should
have
a
cohesive
view
of
what
the
problem
is
from
as
many
perspectives
as
we
can
get
to
make
sure
we're
actually
attacking
it
correctly,
and
I
think
actually
it's
not,
that
we
haven't
got
a
lot
of
people
in
the
room
and
today
is
a
fine
example.
It's
that
our
balance
is
a
bit
skewed.
G
I
don't
want
us
to
spiral
off
topic,
though
bill,
because
I
think
this
is
an
important
one.
I
mean
like
I'm
not
saying
that
there
shouldn't
be
two
different
groups
or
there
should.
I
do
feel
like
there's
some
duplication,
but
like
it's
really
really
hard
to
like
do
real
work,
if,
especially,
if
you're
trying
to
be
in
the
doer
category
and
also
a
10
15
different
groups,
exactly
I
worry
too
like
just
going
to
be.
G
You
know
blunt
because
I've
seen
it
in
the
past,
if
we're
not
tying
in
to
the
greater
cncf
ecosystem,
we're
going
to
be
treated
as
a
one-off
and
have
a
hard
time
getting
like
things
that
may
be
good
for
kubernetes,
overall,
etc
pushed
into
the
you
know
larger
conversation,
and
then,
conversely,
I
do
think
I
was
really
hoping
that
the
cnf
working
group
or
the
tug
was
going
to
spin
into
something
a
little
bit
more
concrete
because,
like
if
I
go
to
I
attend
safety,
networking
calls
I
mean
they
might
as
well
call
it
sig
sidecar.
G
G
I've
got
leprosy
and
they're
like
stay
away
from
this
guy
he's
asking
terrible,
uncomfortable
questions
that
we
don't
want
to
address
here
so
yeah,
I'm
really
kind
of
curious
kind
of
like
what
the
long-term
revolution
and
I
kind
of
thought
that
that's
what
the
cnf
working
group
was
spawning
into
and
if
that's
not
the
case,
that's
fine,
but
I'd
like
some
clarity,
it'd
be
nice
for
us
to
know
like
where
we
could
focus
our
efforts
to
have
the
biggest
impact
on
this
space
because
it
does
need
to
be
addressed.
In
my
opinion,.
B
So
so
let
me
brainstorm
something
because
I
was
listening
very
carefully
to
taylor,
who
I
think
has
a
lot
of
experience
with
this
organization.
My
thought
is,
you
know
I
named
this
a
task
force,
which
was
just
a
name.
I
chose
that's
not
like
anything
else,
and
maybe
it's
a
good
idea
to
keep
it
that
way
so
kind
of
like
a
cross
group
task
force
because
jeff,
as
you
said,
many
of
us
attend
many
of
these
meetings.
There
are
only
so
many
hours
a
week
and
different
ones
of
us
attend
different
meetings.
B
According
you
know,
to
our
priorities
we
have
to
pick
and
choose,
we
can't
go
to
all
of
them.
You
know
just
look
at
the
cncf
calendar
there's
something
every
hour
of
the
day
right
and
all
of
them
might
be
interesting
and
might
be
relevant.
So
maybe
the
idea
is
to
maybe
an
idea
could
be
to
have
this
task
force
really
be
unaffiliated
directly.
B
It
could
be
underneath
the
cnf
work
group,
but
it
should
work
independently
right
because
as
people
as
some
of
you
have
said-
and
you
know
I
I
like
the
same
thing-
I
think
the
cnf
work
group
is
very
exciting.
B
But
it's
big
there's
a
lot
of
people
there
bringing
in
different
topics
and
jeff,
as
you
said,
that
bringing
up
some
lower
level
ideas
about
networking.
Could
you
know
it's
hard
to
get
everybody
to
focus
on
the
same
thing,
especially
if
we
intend
to
be
doers.
If
we
intend
to
be
doers,
I
I
can
see
us
easily
taking
up
every
single
cnf
meeting
just
on
this
topic
right
so,
and
we
can't
do
that
there
should
be
more
room
there
under
that
umbrella
for
the
agenda.
B
B
Yeah
so
there's
you
know,
there's
the
slack
channel
that
I
hope
everybody
saw
the
link
and
can
join
if
they're
interested
and
by
the
way
we
can
continue
to
discuss
this
there.
If
we
don't
settle
on
anything
today,
it's
just
easier
to
do
in
person.
I
think.
B
Yeah,
the
github
style
repository
seems
pretty
cool
the
way
the
cnf
work
group
works.
We
could
we
can
really
copy
that
model
exactly.
How
do
people
feel
about
that?
Do
you
feel,
like
that's,
productive,
using
github
discussions
and
things
like
that.
F
So
I'm
I
want
to
go
back
to
the
one
primary
thing
I
was
saying
tell
the
splitting
of
finding
the
problem.
You
know
you're
trying
to
split
those
two
roles
versus
the
doers,
creating
solutions.
F
You
know
this
task
force
that
you
you
you
say
you
want
to
organize
around.
It
could
be
under
the
tug.
It
could
be
the
cnf
working
group
right
now
on
the
problem
itself.
It
seems
very
relevant
for
say
the
new
use
cases,
so
ian
was
pushing
forward
the
last
several
weeks.
It
came
actually
from
the
end
of
last
year
talking
about
use
cases
before
we
talk
about
best
practices
like
what
what
are
these
for?
What's
the
context.
F
Well,
there
will
be
within
any
use
case,
you're
going
to
have
some
problems
that
you're
trying
to
solve,
and
so
with
what
you're
putting
forward
there
are
there's
going
to
be
use
cases
behind
these
networking
gaps
and
kubernetes
that
you're
talking
about
workloads
are
going
to
have
a
problem
with
handling
the
networking.
So
what
are
those?
What
are
those
use
cases
and
then
starting
state
problems
that
would
fit
on
the
working
group
in
my
mind
very
well,
but
it
doesn't
have
to
be
so.
You
could
definitely
have
a
task
force
that
meets
around
it.
F
You
could
say-
and
you
could
do
this
right
now.
As
my
point
in
the
cnf
working
group,
you
can
have
someone
that
says
what
we
care
about
is
state.
How
are
we
handling
cloud
estate
and
data
in
a
cloud-native
way?
We
really
want
to
focus
on
that
problem
space,
because
we
want
solutions
that
are
going
to
help
us
as
a
cnf
vendor
build
applications
that
actually
continue
to
function
but
fall
into
cloud
native.
You
know
best
practices.
F
Well,
you
could
have
a
focused
task
force,
they're
still
working
within
the
cnf
working
group,
because
you're
saying
we
want
all
these
networking
applications
to
benefit,
but
it's
a
focus
group
and
you
can
keep
meeting.
We
want
space
in
the
repository
to
keep
adding
new
documents
that
are
about
each
one
of
those
topics.
So
networking
tell
seems
like
a
a
focused
topic
for
networking
applications
that
needs
to
happen,
so
my
suggestion
would
at
least
be
to
think
about
it
being
something
that
would
be
relevant
there.
B
Yeah
I
that
that
sounds
like
a
great
start,
it's
probably
worth
bringing
up,
maybe
again
in
the
cnf
work
group,
to
make
sure
that
every,
although
I
I
think,
there's
a
lot
of
overlap
between
people
in
this
meeting
today
and
that
group,
but
to
make
sure
that
that
group
agrees.
I
I
would
say
that
thinking
about
it.
B
It
sounds
like
a
good
starting
point,
but
I
I
hope
it
won't
be
the
the
ending
point
because,
as
I
said,
it's
not
all
about
cnfs
the
cnf
working
group
and
specifying
requirements
for
cns
and
portability.
Cnfs
encapsulate,
maybe
the
networking
problem
in
a
very
specific
way,
both
technically
and
both
from
a
business
perspective.
Just
the
the
kind
of
roles
that
are
in
the
room,
equipment
providers,
vendors
platform
providers,
orchestration
providers
and
and
other
solution
integrations
and
providers.
B
Cnfs
are
as
a
focal
point
for
the
problem
in
the
use.
Cases
are
a
very
specific
use
case,
I'm
hoping
at
least
to
locate
it
in
a
way
that
would.
E
E
I
don't
think
anyone's
disagreeing
with
that,
not
least
because
if
we
can
come
up
with
a
way
of
solving
problems,
more
generally
they're,
probably
problems.
We
encounter
ourselves
in
some
point
in
the
future,
with
a
cnf
hat
on.
That's
that's
fine,
but
what
taylor's
preaching
and
venue,
because
I've
been
preaching
it
to
him
is
big-
is
problem
before
solution.
E
If
you
think
that
a
given
solution
can
solve
more
than
just
this
problem,
you
can
put
that
argument
down.
You
can
say
you
know
this
is
more
general
purpose.
This
doesn't
attack
just
the
one
problem
or,
alternatively,
you
can
say
here
is
another
problem
that
doesn't
have
something
to
do
with
cns
that
it's
worth
our
time
to
solve.
E
That's
totally
fine,
but
if
you
approach
this
bottom
up
from
the
you
know,
we'll
solve
the
problem
of
solve
the
problem,
undefined
thereof
of
networking
orchestration
and
that
will
solve
all
the
network
problems
in
the
world
without
actually
asking
yourself
what
the
problems
are.
You'll
miss
the
target,
so
we've
got
to
be.
I
F
That
ian
one
moment
so
I'd
say
that
there's
two
things
there
there's:
how
do
we
work
with
what
we
have
and
then
what
were
the
problems
that
were
trying
to
be
solved?
So,
yes,
there
are
some
solutions,
but
there's
also
some
new
solutions
like
network
service
mesh
I'll
just
put
out,
is
a
new
solution.
That's
not
it's
not
being
used
standard
I'd
say
is
like
a
lot
of
the
cni's.
F
If
we
say,
let's
just
keep
building
with
what
we
already
have,
then
it's
not
questioning
whether
or
not
we
went
down
the
right
path
and
if
we
step
away
from
anything
new
that
we're
doing
in
these
groups-
and
you
go
look
at
the
kubernetes
groups
that
have
been
talking
about
networking
for
a
while.
They
already
know
that
there's
problems
with
the
current
paths
they've
been
looking
at
it
for
a
long
time.
D
F
E
I
I
just
want
to
put
words
in
youn's
mouth
and
see
whether
I'm
choosing
the
right
ones.
So,
when
you're
saying
how
do
we
use
it,
are
we
really
saying
they're?
Okay,
so
I've
got
a
bunch
of
cnfs
and
hypothetically
or
in
reality,
I'm
just
using
a
networking
solution
that
I
found
on
the
shelf
now?
How
do
I
actually
use
those
cnfs?
Is
that
the
orchestration
that
you're
talking
about.
I
I
C
Any
any
single
attempt
at
address-
I
would
disagree
with
that
like
cnt,
is
to
cherry-pick
current
solutions,
not
about
building
new
solutions,
and
what
we
miss
currently
is
what
I
think
that
is
two
kind
of
interfaces
from
current.
This
one
is
to
to
build
and
configure
networks
or
networking
solutions,
and
that's,
I
think,
what
john
mentioned
and
other
is
enough-
that
interface
to
consume
these
networks,
because
I
think
we
currently
do
not
have
that.
Even
if
we
have
the
cni,
the
different
cni's
have
different
annotations
and
they
can
be
totally
incompatible
with
each
other.
I
B
G
Yeah,
I
I
want
to
like
really
quick
pile
on
with
tal
here,
because
this
is
what
always
happens,
and
so
there's
two
things
a.
I
think
taylor's
right
that
if
we
completely
splinter
off,
I
don't
think
we're
a
long
term.
Even
if
you
build
really
cool,
let's
say
the
doers
go
and
build
something.
I
don't
think
it's
going
to
like
get
the
adoption
that
they
want
like
there
needs
to
be.
Some
type
of
you
know
consideration
on.
Like
I
mean,
let
me
use
an
example.
G
Gary
gaye
has
proposed
alternate
apis
in
the
past
for
kubernetes,
based
on,
like
some
of
his
initial
gap,
analysis
right.
Let's
say
a
small
group
of
people
go
out
and
they
actually
build
this
and
it
works,
and
it's
good.
If
we're
not.
You
know
in
some
type
of
like
cohesive,
like
agreement
within
our
little
domain.
Here
I
don't
see
how
that
is
going
to
without
major
major
major
efforts
get
any
type
of
traction
within
the
rest
of
the
kubernetes
ecosystem,
who
a
lot
of
times
don't
actually
care.
G
What
we're
doing,
if
we're
just
being
honest
right,
like
I
mean,
there's
a
reason
why
sig
networking
really
is
sick,
sidecar,
six
servicemen,
because
that's
what
they
care
about
networking,
but
they
have
their
sig,
and
then
they
have
these
like
different.
You
know
groups,
it's
kind
of
like
what
taylor
was
saying
right,
like
you
know,
even
if
we
need
to
change
like
the
overarching
name
of
the
cnf
working
group,
there
needs
to
be
some
type
of
collective,
because
it's
always
the
same
30
of
us
on
all
these
different
calls
so
like.
B
So
I
you
know,
I
think,
we're
kind
of
we
kind
of
overdid
the
differences
here
between
doers
and
and
problem
providers.
As
you
mentioned
jeff,
it's
really
often
this
the
same
people
and
we're
not
really
dividing
the
work.
All
these
meetings
are
kind
of
on
different
topics.
I
think
we're
all
in
coordination.
It's
not
like
these
things
are
done
in
silos.
I
don't
think
the
cncf
is
cobbles
together
silos,
so
so
we
are
coordinating
and
part
of
discussions
like
this
are
those
coordination.
B
Of
course
we
we
want
to
be
efficient
and
don't
want
to
waste
time
only
on
constantly
coordinating
efforts.
So,
in
the
effort
of
moving
in
the
in
the
interest
of
moving
forward
taylor,
I
propose
that
we
basically
accept
your
proposal
here
that
that,
if
this
is
hopefully
this
is
what
you
were
matches
with
what
you
were
proposing.
But
the
idea
is
that
let's
continue
working
for
now.
B
Working
group,
we
can
maybe
use
the
github
area
there
and
create
a
new
topic.
We
can
think
about
exactly
how
to
organize
it.
We'll
start
with.
Maybe
I'm
proposing
the
other
things
on
my
agenda
for
today,
that
we
won't
get
to
things
like
a
gap.
Analysis-
and
you
know
we-
we
can
continue
discussion
discussion-
how
what
we're
actually
going
to
do
right
in
terms
of
creating
a
platform
or
or
something
new
and
yeah.
We
don't
have
to
treat
it
as
the
end-all
be-all.
B
This
this
thing
can
continue
to
evolve
and,
as
we
learn,
maybe
more
efficient
way
to
to
work
here,
but
I
think
it's
a
good
starting
point,
and
you
know,
as
I
continued
that
point,
the
difference
between
the
doers
and
the
architects
right.
B
These
things
always
work
together.
It
always
evolves.
You
create
a
poc.
You
learn
something
new.
You
can
never
find
your
complete
solution
on
paper,
at
least
not
from
my
perspective,
there's
the
slideware
and
there's
the
software,
and
hopefully
they'll
continue
talking
to
each
other
and
and
evolving.
F
That
sounds
good,
let's
follow
up
after
and
and
try
to
look
at
some
of
the
existing
discussions
and
items,
and
maybe
some
of
the
things
that
aren't
quite
into
the
repository
yet,
but
what
we're
planning
and
then
we
can
see
where
some
of
this
would
fit
and
some
may
fit
under
existing
things,
and
I
I'm
just
from
looking
at
slides
and
stuff.
I
think
we're
going
to
need
new
discussions.
F
We
are
planning
on
having
something
equivalent
to
whatever
we
want
to
call
the
sig
network,
not
the
one
that
we've
been
referring
to,
but
we've
had
conversations
with
the
lee
and
matt
from
the
current
sig
network
and
cncf
we've
been
talking
with
sig
app
delivery
because
there's
it
goes
across
those
we've
been
talking
to
the
other
cigs.
We
do
think
there's
likely
to
be
something.
F
Yes,
we're
working
on
that
that's
longer
term
to
make
sure
that
we're
aligned
with
the
rest
of
what
cncf
does
but
we're
moving
towards
those.
So
we're
not
going
to
be
just
focused
on
a
network
functional,
but
we
can.
We
can
talk
some
about
what
do
we
do
next?
I
did
move
the
eno,
the
eno
items
out
from
underneath
your
bullet
point
in
the
agenda,
because
I
do
want
to
say
from
the
standpoint
of
presenting
solutions.
F
We
don't
want
to
stop
that.
We
actually
want
to
hear
so
coming
to
the
telecom
user
group,
maybe
making
a
space
in
even
in
the
cnf
working
group,
for
presentation
on
ideas
on
projects
we
want
to
make
space
for
that.
If
the
telecom
user
group
is
maybe
the
more
open
space
right
now,
that
goes
beyond
what
the
cnf
working
group,
we
could
start
meeting
more
often
than
once
a
month,
but
we
have
about
eight
minutes.
I
don't
know
how
much
time
is
needed
for
the
eno.
F
If
that's
something
that
we
want
to
present
now
or
or
defer
cal,
are
you
going
to
present
on
that
or
is
someone
else.
J
Hi,
this
is
alok
yeah,
hey,
we
kind
of
wanted
at
least
around
30
minutes,
but
yeah
with
the
interest
of
time.
If,
if
it
it
can
be
a
short
introduction,
I
can
like
highlight
the
major
portions
and
just
to
trigger
this
up
and
we
can
take
in
detail
in
some
future
dedicated
sessions
or
in
some
future
talk
meetings
as
well.
B
J
A
H
Also,
I
would
like
to
ask
to
to
ask
something
small,
so
this
meeting
is
is
happening
once
per
month
right
so
because
I'm
seeing
that
we
have
many
topics
that
we
need
to
discuss
and
many
things
that
we
need
to
solve.
Actually
is
there
any
plan
to
make
this
more
often
or
we
we
should
still
keep
it
like
just
once
per
month.
What
is
your
thoughts
on
that.
B
It's
once
every
two
months
because
of
the
time
zone
issue
well,.
F
So
we
have
right
now
the
it's
once
a
month,
but
the
time
shifts.
So
the
next
call
would
be
several
hours
earlier,
trying
to
make
it
easier
for
asia
pacific
to
join
anyone
in
asia,
pacific
time
zones.
But
if,
if
there
is
an
interest
to
start
having
more
of
and
the
telcom
user
group
really
is
a
space
to
say
we
have
ideas
of
any
type,
something
that
we
want
to
bring
a
problem
that
we
don't
know
where
it
should
go.
F
We
have
a
just
a
project
or
whatever
it's
open
for
anything
related
to
I'd,
say
networking,
not
just
telecom
specific,
but
any
networking
stuff
that
could
be
applied
in
in
the
telecom
world
would
would
be
appropriate.
And
if
we
want
to
start
meeting
more
than
once
a
month,
maybe
even
saying
at
least
once
a
month
for
the
both
versus
every
other
month,
like
you're
saying,
then
we
could
do
that,
and
I
I
guess
just
putting
that
forward
right
now.
B
Nobody
is
talking
more
meetings
right,
taylor,
the
the
issue
is
that
sometimes
we
have
these
meetings
and
there's
not
that
much
on
the
agenda.
There
have
been
shorter
meetings,
it
it.
It
seems
to
fluctuate
and
depend
right.
E
So
the
problem
is:
we've
got
like
three
slack
channels,
two
groups,
two
meetings
and
no
focus
as
to
which
one's
doing
which
bit.
So
if
we
have
a
telecom
user
group
meeting
once
a
month-
and
we
have
a
working
group
meeting
once
a
week
or
whatever
for
a
given
agenda
topic-
which
one
does
it
go
in.
F
So
that,
right
now
the
way
I'd
see
it
anne
is
the
based
on
and
what
tal
is
I'm
saying
that
this
networking
problem,
definitions
and
and
gap
analysis
would
be
a
good
topic
in
the
cnf
working
group
so
that
we
could
say
here's
what's
been
happening
there
I
mean
it
can
always,
of
course
meet
outside
pal.
So
if
like
working
sessions
and
stuff
like
that,
but
that
cnf
working
group
meeting,
we
could
talk
specifically
hey
here's,
what
we've
done
some
more
information
on
the
gap.
F
Analysis
but
stuff
like
eno,
is
a
good
place.
I
think
for
the
tug
and
there's
other
things
I
know
tal
that
were
in
the
slides
that
could
be
dick
dig
more
into
them
as
far
as
what's
available
right
now,
not
just
eno
but
other
stuff.
On
the
that
the
task
force
slides
have
those
could
also
be
good
in
the
tug.
F
B
So
so
quick,
we
have
three
more
minutes
left.
I
I
do
want
to
say
well,
I
personally
won't
be
able
to
join
the
the
cnf
work
group
today.
So
if
there's
interest
in
continuing
discussion,
it's
there
I'll,
I
might
be
able
to
join
a
bit
late.
So
maybe
other
people
here
can
keep
the
ball
rolling
and
and
I'll
get
updated.
Somehow.
F
And
we
can
always
do
it,
async
slack,
and
there
is
mailing
list
for
both
of
these.
F
F
So
I'll
circle
back
around
about
the
I
guess
the
next
meeting,
if
if,
unless
we
get
some
votes
right
now
on
the
call,
you
can
do
a
plus
one
in
the
chat.
But
do
we
want
to
do
a
tug
next
start
having
another
one
meeting
rather
than
every
two
months
at
this
time,.
B
F
And
we
can
always
cancel
too
that
the
idea
would
be
asking
for
agenda
items
and
so
right
now,
potentially
we
have
eno
and
I'm
not
going
to
ask
to
give
an
overview
in
one
minute.
So
we
could
definitely
have
that
as
the
next
one
and
if
there's
availability,
then
we
do
it.
If
no
one
adds
any
agenda
items,
then
we
we
send
out
a
notice
that
we're
not
going
to
have
that
meeting.
F
Way,
all
right,
I'll
I'll
put
a
post
out,
we
may
do
like
a
vote.
Put
it
put
like
an
online
vote,
see
if
there's
feedback
on
having
it
at
this
time,
monthly.
Shifting
to
that
or
where
we
want
to
go.