►
From YouTube: CNCF SIG Network 2020-12-17
Description
CNCF SIG Network 2020-12-17
A
A
A
Oh
yeah,
so
right
now,
looking
into
on
y
and
its
usage
models
and
its
performance
aspects,
so
that's
where
I
reached
out
in
slack,
join
smp
and
smi
so
and
it's
all
through
the
documentation,
that's
been
there,
which
I
should
say
has
been
pretty
well
documented
on
a
lot
of
these
things
are
compared
to
their
other
communities.
I've
been
part
of
in
the
past,
so.
A
B
B
You
know
your
your
daytime
focus
like
to
help
you
sort
of
achieve
part
of
your
goals
more
quickly.
It
could
help
and
then,
at
the
same
time
help
some
of
the
projects.
Actually
we're
going
to
talk
about
a
couple
of
them
now
so
and
part
of
that.
It's
funny
funny
that
you
mentioned
it
because
part
of
it
is
about
organization.
B
A
Yeah
absolutely
yeah,
it's
interesting
to
see
if
he
is
one
of
the
topic,
because
that's
that's
been
my
background.
The
last
few
years
now
and
that's
that's
the
space
we're
looking
at
leveraging
one
way,
for
example
among
other
things,
but
yeah.
So
it's
yeah
looking
to
see
what
that
discussion
entails.
B
A
B
C
B
No
very
good,
you
know
what
it
may
be
you
I
we
will
see
when
we're
done.
Maybe
it
was
recording
the
whole
time
and
I
just
couldn't
tell
but
so
fair
enough.
Well,
we've
got
a
set
of
a
small
collection
of
dedicated
individuals
on
today's
call,
and
we've
got
two
other
individuals
who
are
slacking
with
me
and
and
I'm
trying
to
get
him
to
join
the
call,
because
it
would
be
easier
to
do
it
verbally.
B
B
There
is
ian
wells
from
cisco
was
wanting
to
talk
about
nfv
and,
and
so
I've
invited
him
to
the
call.
I
I'm
not
sure
if
he's
going
to
join
or
not
there's
a
couple
of
things,
somehow
a
little
bit
housekeeping
housekeeping
around
the
work
streams
inside
the
service
mesh
working
group
to
talk
about
and
since
frederick
is
here,
there's
a
little
bit
to
talk
about
with
respect
to
smi
in
general,
cool
and
actually
ken
since
you're.
B
Boy,
all
the
topics
are
service
smash
topics
except
for
nfv,
okay,
fair
enough.
So
thank
you
all.
If
anyone
has
any
other
topics,
please
feel
free
to
list
them
because
we'll
we
will
get
through
them.
So
today
is
this
december
17th.
This
is
the
cncf
sig
network
call
jumping
into
the
topics
of
the
the
service
mesh
working
group.
So
as
a
refresher
for
for
most
of
us
that
working
group
had
been
formed,
I
don't
know
some
many
months
ago.
B
Is
that
some
of
the
folks
who
are
critical
to
those
meetings
aren't
able
to
make
this
time
and
so
amy?
One
of
the
things
that
that
I
wanted
to-
and
you
know
I've
struggled
with
either
suggesting
that
that
this
sig
network
meet
at
a
different
time
or
tossing
out
a
separate
meeting
time
for
surface
mesh
working
group.
B
C
B
C
B
B
B
Okay,
so
one
one
of
the
reasons
why
why
this
time
is
an
inconvenience
is
based
on
time
zones
of
the
people
who
are
working
on
a
couple
of
things
within
here.
So
there's
under
this
focus
is
about
performance
and
service
mesh
service
mesh
performance.
It's
about
a
few
things
trying
to
standardize
the
way
in
which
service
meshes
and
their
workloads
their
their
performance
is
analyzed.
B
It's
not
entirely
about
hard
statistics
with
respect
to
performance,
it's
also
with
respect
to
measuring
the
value
that's
being
derived
from
a
mesh
and
how
it's
being
run,
which
is
to
say
how
much
you're
asking
a
service
mesh
to
do
and
how
much
weight.
Do
you
give?
How
much
do
you
value
those
things
as
part
of
the
conversation?
Part
of
that
same
conversation
is
about
distributed
performance
analysis.
B
That
effort
is
taking
on
a
name
well
or
is
taking
on
a
project
name
called
get
nighthawk
if
you're
not
familiar
with
nighthawk,
it's
the
load
generator
for
of
the
envoy
project,
and
so
there's
a
few
load
generators
out
there.
Actually
many
load
generators
out
there.
The
envoys
nighthawk
load,
generator
is,
is
becoming
more
and
more
popular
and
that
working
group
is
trying
to
help
it
be
so
it's
creating
a
get
nighthawk
a
number
of
distributions
of
nighthawk
and
kind
of
a
get
nighthawk
dot.
B
This
meeting,
because
I
feel
like
it,
it
would
do
a
disservice
to,
or
you
know,
going
really
deep
on
one
thing,
and
only
talking
about
that
thing
would
do
a
disservice
to
someone
who
wants
to
talk
about
core
dns
or
you
know,
ambassador
or
other
things.
Amy,
that's
been
my
personal
challenge,
probably
about
guilt
over
like
anyway,.
C
No
reason
to
feel
like
upset
about
this.
We
are
we're
currently
working
on
being
able
to
figure
out
better
processes
for
hey.
How
could
we
actually
get
projects
that
want
to
be
incubating
in
so
I
mean
if
you
would
like,
I
would
put
this
on
the
sig
updates
for
january.
Around
help
support
the
sigs
in
this
process.
Is
that
fair.
B
B
B
B
B
So
the
discussion
is
and
the
agreement
was,
you
know
the
land,
those
that
are
involved
and
focused
and
have
skin
in
the
game.
Some
of
that
has
changed
over
time
and
right
now
it
looks
like
there's.
A
number
of
people
of
the
maintainers
that
are
involved
are
ready
to
move
some
things
forward.
So
so,
for
my
part,
I'm
one
of
those-
and
so
I
think.
B
B
This
on
these
work,
streams
and
organization
of
them
and
and
getting
them
like
part
of
this,
is
I'm
sort
of
pointing
the
finger
back
at
myself
and
kind
of
having
ken
on
the
side
of
the
line
as
well,
where
I'm
so
we're
saying:
hey,
there's
a
bit
more
organization
for
us
to
do
to
make
to
to
bring
some
of
these
together
to
like
have
consistent
meeting
times
to
to
make
sure
that
we
can.
We
can
meet
and
go
through
these
and
begin
publishing.
Some
of
these
things
there's
a
bunch
of
well-documented
work.
B
That's
been
done
around
each
of
these
work
streams,
but
but
it's
not,
but
but
for
my
part,
I'm
I'm
I'm
falling
short,
and
so
are
some
of
the
other
people
participating
falling
short
on
getting
the
word
out
there.
These
activities
are
going
on
because
I
I
happen
to
bump
into
a
lot
of
people
who
are
very
interested
in
them.
B
One
of
those
is,
as
a
related
note,
is
like
the
service
mesh
survey.
There
had
been
so
amy
you,
you
might
be
in
a
position
to
help
characterize
this.
A
bit
more
is
amy
still
with
us,
no
okay,
so
some
of
you
have
seen
it's
been
either
been
once
or
twice
there
have
been.
The
cncf
has
done
it
there's
a
number
of
surveys.
B
I'm
not
sure
what
the
the
latest
ones
have
been
called,
but
they're,
basically
usage
surveys
and
one
of
them
had
been
about
how
different
service
meshes
are
being
used
and
being
adopted,
and
I
was
looking
the
last
you
know
a
year
and
something
ago
when
I
looked
at
one.
It
was
embarrassingly
wrong
and
I
made
comments
about
that.
B
Privately,
probably,
and
then
there
was
some
recent
chatter
about
another
one
that
was
published
and
it
was
less
embarrassingly
wrong,
but
still
quite
wrong
or
quite
pissed
poorly
done
and
as
I
went
to
go,
make
a
public
comment
about,
or
I
wasn't
anyway,
as
I
went
to
go
comment
on
that.
I
thought.
Oh.
B
People
might
think
that
the
the
service
mesh
working
group
or
the
sig
network
might
be
responsible
for
that
kind
of
a
survey.
Maybe
we
should
get
it
right
and
in
the
service
mesh
in
the
smi
bi-weekly
meetings,
there
was
an
ask
for
to
survey
smi
users
or
potential
smi
users
for
use
cases
like
ones
that
frederick
had
recently
mentioned,
and
so
I
took
up
an
action
item
to
help
facilitate
such
a
survey,
I'm
taking
it
through
the
sig
network
here.
B
So,
for
my
part,
I
think
I
think
it's
high
time
that
we
do
a
real,
an
actual
survey
that
there's
a
there's.
No
doubt,
and
maybe
december
is
the
month.
There's
no
doubt
and-
and
ken
you
may
know-
there's
no
doubt
a
got.
What
was
the
cncf
radar,
the
use,
end
user
radar
and
user
technology
radar?
That
will
eventually
that
will
be
done,
one
done
on
service
mesh
and
the
clock
is
ticking
and
for
my
part,
I
think
those
can
be
kind
of
helpful
things.
D
B
Nice,
okay,
yeah
good
yeah,
can
I
I
think
a
barrier
had
been
recently
broken
down
at
I've,
been
invited
to
go
to
hang
out
on
the
end
user
call,
which
is
great
because
for
my
part,
I
want
to
help
bring
those
use
cases
back
to
definitely
the
service
and
so
yeah.
So
I
was
just
so
I'm
going
on
public
record
to
say
that
I
caught
myself
before
I
made
a
silly
comment
like
hey.
This
survey
isn't
well
done.
B
F
G
F
It's
been
a
very
long
while
actually
yeah
yeah,
apparently
this
this
is
the
x,
cisco,
convocation.
That's
really
quite
disturbing
so
nfv
as
a
general
statement
is
trying
to
make
things
that
usually
end
up
not
exclusively
but
usually
end
up
in
service
provider
networks,
things
that
are
trying
to
do.
You
know
treat
network
traffic
as
sort
of
raw
packets
or
do
weird
things
with
weird
protocols,
because
you
know
service
provider
standards
are
generally
weird
low
level
more
low
level
networking
than
you
would
normally
find
in
kubernetes.
F
It
is
delivering
exactly
the
functionality
that
they're
looking
for
and
again
the
fact
that
when
we
want
extensions,
we
can
just
build
on
top
of
it
with
the
service
mesh
says
to
me
that
it's
doing
the
right
job.
So
the
question
I'm
left
with
is:
firstly:
can
we
enumerate
our
requirements
on
the
nfv
side
of
things,
the
things
we
want
to
do
without
regard
to
the
solutions
like
cni
out
there
to
actually
say?
If
we
can
do
this,
then
we
can
get
our
job
done.
F
And
my
feeling
here
is
that
the
more
we
try
and
bend
the
cni
to
the
will
of
a
very
small
minority
of
use
cases,
the
more
we're
doing
the
wrong
thing.
So,
but
that's
a
personal
feeling
how
the
the
the
general
question
is,
if
I
want
to
run
a
network
function
that
plays
with
packets
the
other
network
function,
I
want
to
concern
myself
with,
is,
if
I
own
a
network
function
that
consists
of
multiple
reaching
domains
verbs
on
the
network.
F
I
was
up
there
at
start.
The
network
service
mesh
ed,
took
it
and
run
with
it,
but
it
was
me
and
him
and
kyle
who
had
the
original
idea.
So,
yes,
the
original
idea
of
nsm
was
something
a
little
bit
more
raw
than
it's
turned
out
to
be,
and
I
think
it
might
have
a
potential
part
of
this
solution,
although,
as
I've
seen
it
develop,
I
think
it's
developing
more
in
the
direction
of
cloud
to
cloud
connectivity
which
isn't
our
problem
in
nfv.
F
Quite
as
things
stand,
in
fact,
my
feeling
is
my
suspicion
is
that
in
much
the
same
way
as
you've
got
a
cni
and
then
you've
got
service
mesh
running
on
top
nsm
fills
the
role
of
that
service
mesh
in
raw
networking,
but
there
isn't
an
underlying
layer
there
and
there's
a
more
basic
question
of
how
it
should
be
dealing
with
the
network
at
the
lower
level.
That
was
is
the
one
that
we're
missing
right
now.
F
Want
what
I
think
is
a
far
enough
different
kind
of
networking
that
it's
probably
not
sensible
to
add
it
to
the
cni,
if
we're
being
honest
in
much
the
same
way
that
I
don't
try
and
make
block
object,
storage
answer
to
the
same
apis.
I
don't
think
these
two
sorts
of
networking
should
answer
to
the
same
apis.
E
A
little
bit
towards
that
as
well,
there
have
been
years
worth
of
efforts
to
try
to
extend
out
cni's
scope
from
a
variety
of
different
parties,
and
cmi
remains
mostly
unchanged
in
this
respect.
So
I
even
I
I
agree
that
I,
with
with
the
I,
don't
think
it's
the
right
approach
anyway,
but
even
if
we
thought
it
was
the
right
approach,
the
chances
of
getting
your
community
to
accept
the
meeting
in
that
area
is
makes
the
point
most
likely
moved
anyway.
F
E
There's
people
little
drop
things
like.
Oh,
let's
do
something
with
this
rov,
let's
do
something
with
with
mpls:
let's
do
something
with
with
only
ethernet
or
so
on.
These
are
technically
all
out
of
out
of
spec
and
they're
running
into
the
same
problems
that
neutron
ran
into
earlier
on,
which
is
that
neutron
did
not
meet
their
needs,
and
so
they
ended
up
co-opting
things
like
oh
yeah,.
F
What
I'd
like
to
do
is
I'd
like
to
make
sure
we've
got
some
degree
of
quantification
of
the
problem
statement
rather
than
the
solution,
because
this
is
one
of
those
problems
that
you
tend
to
find.
People
are
basically
saying:
I
see
these
open
source
projects
they've
been
out
there
for
so
long.
They
must
solve
my
problem.
I
I
don't
think
people
necessarily
appreciate
how
different
their
problem
is.
So
I
think
it's
more
there's
an
element
of
just
defining
what
would
be
a
working
solution?
G
A
F
I
I'm
here
in
part
because
I've
been
involved
with
the
cnf
working
group,
but
I
just
want
to
be
clear
about
an
audience
problem
that
we
have
here.
We
talk
as
if
service
providers
are
our
audience
for
this
level
of
feature,
and
that's
simply
not
true.
The
people
who
consume
apis
that
do
networking
are
the
people
that
write
applications
that
do
networking
service
providers
then
try
and
run
those
applications,
but
service
providers.
Don't
generally
I
mean
there
are
exceptions
to
every
rule,
but
service
providers
are
generally
not
the
authors
of
those
applications.
F
F
A
F
We
we
are
right;
this
is
a
judgment.
Firstly,
we
define
the
problem
before
we
start
saying
how
it's
solved,
but
my
my
best
guess
here
is
that
whatever
that
solution
looks
like
it's
so
far
removed
from
what
cni
does
today,
that
it
would
make
more
sense
not
to
mingle
it
with
the
cni,
but
that
is
a
best
guess.
It's
not
necessarily
true
right
now,
until
you
know
what
the
problem
is,
we
can't
say
what
the
answer
is.
E
E
Is
that
they're
commonly
configured
through
a
custom
resource
and
they
bubble
up
the
southbound
cni
api
to
the
northbound,
which
means
that
if
kubernetes
ever
decides,
they
want
to
change
the
cni
spec
that
those
low-level
details
have
been
have
been
exposed,
and
it
also
means
that
the
many
of
these
the
subnets
and
similar
and
or
parameters
like
what
like
vlan
vxlan
parameters
and
so
on
often
you
get
welded
into
those
as
well,
rather
than
negotiated.
So.
E
F
Let
me
let's
it's
interesting:
what
you've
just
written
down
lee,
because
I'll
come
to
that
in
a
moment,
but
but
starting
from
what
frederick's
just
said
right.
If
we
look
at
something
like
maltus
right,
it
said
that
a
cni
networking,
the
cni
networking
api
is
largely
adequate
to
the
task.
It
describes
the
sort
of
networking
that
we
want
and
then
it
said,
but
the
only
problem
here
that
we
used
to
be
able
to
do
with
virtual
machines,
and
we
can't
do
with
containers
which
we
can't
get
multiple
interfaces
into
a
single
container.
F
Now
there
are
flaws
with
both
of
those
statements
statement,
one
to
one
number,
one
that
cni
gives
us
the
kind
of
networking
we
want,
which
is
that
there's
a
single
network
domain.
It
is
layer,
3
addressed
it's
all
about
reachability
that
there's
one
egress
from
the
cloud
that
I
use
for
for
the
networking
that's
coming
across
the
cni.
F
Literally.
None
of
that
is
true
in
terms
of
nfv.
I
want
multiple
points
of
egress
from
the
cloud
and
the
only
reason
I
have
multiple
interfaces
in
a
container
is
because
that's
the
only
way.
I
can
point
at
different
points
of
cloud
egress.
At
the
same
time,
then
we
get
things
like
whenever
we
get
into
this.
It
always
seems
to
turn
up
with
ip
address
management.
F
I
don't
always
have
an
ip
address
and
it
doesn't
always
reside
on
one
interface.
I
might
be
doing
things
like
ecmp
load
balancing,
so
my
interface,
my
address
my
grades,
I
might
be
doing
mpls
where
I
don't
have
an
address
at
all.
So
all
of
these
assumptions
it's
easy
to
find
a
use
case
that
invalidates
them
and
then,
finally,
that
namespace
thing
I
am
trying
to
get
multiple
interfaces
into
my
namespace.
Actually,
no,
no
I'm
not
literally
don't
want
two
interfaces
in
the
namespace.
That's
exactly
the
thing
I
don't
want.
F
E
E
Yeah,
but
by
the
way,
tying
this
to
to
the
layers
as
well,
so
most
of
these
are
at
the
l2
and
l3
layers,
and
we
have
people
who
are
service
mesh
experts
here.
So
one
of
the
one
of
the
things
one
of
the
challenges
as
well,
that
we
that
we
need
to
look
at
is
is
how
to
build
these
things
so
that
they
complement
each
other.
E
So
in
other
words,
most
service
meshes
focus
on
the
l4
l7
managing
pcp
sockets,
managing
the
application
related
things
like
http
or
grpc
or
somewhere,
and
at
this
particular
level
you're.
Looking
at
how
do
you
actually
establish
that
initial
connectivity,
like
you,
have
multiple
clusters?
How
do
you
establish
connectivity
between
those
clusters
or
maybe
clusters
with
connectivity
to
external
systems?
It
could
be
a
vpn
to
a
client
or
a
partner
in
the
case
of
a
telecom.
E
It
could
also
be
how
do
I
establish
connectivity
across
multiple
sites
now
that
we're
starting
to
see
edge
data
centers
start
to
start
to
come
up,
and
how
do
we
ensure
that
we
don't
get
things
like
ipe
conflicts
or
localize,
the
things
that
were
originally
global
and
scope?
Try
to
localize
them,
and
these
are
problems,
domains
that
are
outside
of
the
standard
service
mesh,
but
they
have.
E
They
have
massive
impact
on
on
the
service
mesh
space,
depending
on
the
type
of
service
that
that
is
provided
and
the
ideal
state
is
that
it's
fully
abstract
again
that
you
don't
have
to
worry
about
those
low-level
details.
As
long
as
like
you
know
how
to
connect
to
something
that
it
just
works,
but
we're
not
at
that
at
that
state.
Just
yet,
and
so
just
just
some
just
some
thoughts
as
well,
because
I
want
to
make
sure
it's
relevant
to
to
the
people
who
are
who
are
on
the
call.
As.
E
B
Yeah,
you
totally
do
as
a
matter
of
fact.
You
know,
there's
any
number
to
your
point:
frederick,
there's
any
number
of
like
sort
of
core
service
mesh
use
cases
that
that
when
you
have
a
service
mesh
as
it's
defined
today
or
as
it's
commonly
spoken
to
today,
when
you
have
a
service
mesh
discussion,
don't
they
don't
go
low
enough
to
rely?
E
E
E
As
the
identifier
anymore,
because
that's
now
dynamic,
we
now
have
overlap.
We
have
it,
it
makes
the
it
makes
the
infrastructure
when
you
bind
identity
to
it.
It
makes
you
weld
at
the
security
and
the
infrastructure
together
in
a
way
that
makes
it
brittle,
and
so
one
of
we
have
within
most
service
meshes
the
spf
identities
or
we
have
cryptographic
identities.
We're
able
to
use
so
binding
against
the
identity
against
those
trust
domains
is
a
much
stronger
proposition
because
I
could
say
this
stress
domain
and
that
trust
domain.
E
E
One
of
the
problems
to
run
into
is
that
the
service
meshes
don't
tend
to
implement
the
federation
portion
of
speed.
They
implement
the
workload
api,
but
not
the
not
the
federation
portion
of
api,
which
then
complicates
the
federation
of
these
of
these
identities,
so
by
providing
some
form
of
federation,
whether
it's
allowing
your
system
to
to
run
with
spire
and
building
against
spire
or
building
the
federation
api
out
yourself,
which
is
not
a
complex
api.
E
It
doesn't
fully
solve
the
problem,
but
it
gets
us
a
major
step
towards
that
level
of
independence
and
then
that
helps
separate
you
from
those
l203
concerns,
and
that
means
we
could
even
drive
you
to
a
different
protocol
which
could
be
non-ip
based.
You
don't
care,
because
you've
asked
for
something
as
long
as
you
can
get
that
socket
to
what
you
need.
You've
maintained
that
that
independence,
so
does
that
make
sense.
B
Oh
a
ton
yeah.
I
I
think
that
the
day
had
today
had
long
past,
since
it
was
appropriate
to
use
an
ip
address,
to
identify,
much
or
at
least
at
least
in
my
area
focus,
and
when
you
said
spire
a
moment
ago
was,
were
you
using
that
interchangeably
with
an
asvid
like?
Let
me
let
me
say
it
like
this,
that
I'm
I'm
being.
E
All
being
I'll,
be
very
specific,
so
spire
is
a
is
a
reference
implementation
of
spiffy
there's
two
apis.
You
have
the
workload
api
that
pushes
down
s
vids
down
and
then
there's
a
federation
api,
which
is
how
do
you
actually
join
things
together?
How
do
you
join
together,
multiple
trust
domains
and
so
spire
is
a
reference.
E
Implementation
doesn't
have
to
be
spire,
I'm
bringing
that
in
as
an
example,
because
it
fully
implements
both
sides,
but
it
could
be,
it
could
be
istio
or
it
could
be
kuma
or
be
something
else.
As
long
as
those
federation
apis
are
adhered
to
in
the
spiffy
spec.
The
spiffy
is
this
is
the
spec,
then
that
that
gives
that
that
would
help
tremendously
towards
getting
us
towards
the
multi
towards
the
multi-cluster
approach.
G
Yeah,
this
is
actually
something
that
we're
really
interested
in
the
console
side
here
about
wondering
like
what
is
the
status
of
other
service
mesh's
interest
in
either
like
the
federation
spec
of
spiffy
or
the
hamlet
spec,
that
was
proposed
by
vmware
and
seems
to
have
kind
of
like
lost
steam
over
the
past
like
year
to
six
months.
It's
definitely
something
that
we're
looking
at
for
internal
use.
B
B
That
federate,
you
know,
federation
of
these
identities,
of
these
catalogs
of
these
services
is
that
they're,
either
smi
or
maybe
an
nfvi
or
or
a
hamlet.
You
know,
needs
to
become
a
real
boy
and,
and
one
place
to
sort
of
make
it
a
real
boy.
If
you
will
is,
is
here
in
this
forum
or
in
this
in
the
cncf
sort
of
in
this
forum,
the
those
project
maintainers
had
asked
a
couple
of
times
about
interest
and
and
we're
interested
I
mean
we're.
B
B
It
was
pre
pre-release
of
tanzania
service
mesh
and
they
weren't
feeling
the
love
in
istio
environments
working
group,
so
to
speak,
and
we're
feeling
placated
or
we're
being
placated
in
the
smi
community
meetings
and
between
that
and,
I
think,
yeah.
I
think
that
you've
got
a
accurate
sentiment,
as
you
characterize
sort
of
where
the
project's
at.
E
So
there
are
commitments
from
right-handed
groups.
I've
also
had
conversations
with
with
red
hat
and
they
are.
They
are
interested
in
the
they
don't
have
a
good
federation
story
and
they
are
interested
in
this
as
a
potential
approach
which
has
some
issue
implications.
But
there's
I
think
the
istio
one
is
going
to
come
down
to
whether
the
governance
has
been
sufficiently
decentralized
because
wally
was
being
controlled
by
by
google
it.
E
The
the
will
just
was
wasn't
there
for
for
some
of
these,
like
they,
they
knew
they
supported
the
the
svid
downstream,
but
not
the
not
the
federation
portions,
and
so
I,
if,
if
the
governance
is
decentralized,
there
may
be
more
more
interest
in
this
type
of
things,
because
it
helps
with
with
a
broader
set
of
use
cases
than
than
the
initial
scope
that
istio
was
originally
designed
for,
which
was
only
kubernetes
clustering
because
it
welded
the
big
problem
actually
comes
from.
Where
do
you?
Where
do
you
route
your
identities?
E
To
is?
Do
you
route
them
to
to
an
individual
cluster?
Because,
right
now
the
cluster
is
the?
Is
the
identity
provider
or
can
you
can
you
weave
it
into
a
wider
story
which,
as
a
company
or
as
a
business
unit,
you're
able
to
control
your
identities,
regardless
as
to
whether
they're
kubernetes,
some
or
something
else,
and
to
provide
that
that
integration
across
the
across
the
board
and
again
going
back
to
tying
it
back
to
the
end
of
the
portion?
E
This
allows
us
to
treat
nfv
as
a
layer,
and
we
don't
have
to
worry
about
from
your
service
mesh
side.
You
don't
have
to
worry
about.
You
worry
about
about
those
low-level
details
as
much,
because
you're
not
bound
to
a
specific
ip
address,
you're,
not
binding
to
a
certain
vxlan
protocol
or
similar
those.
Those
are
all
abstracted
away.
At
that
point,.
B
F
Let's
try
that
or
without
mute.
So
that's
that's
a
good
question.
I
don't
have
a
straight
answer
for
you
right
now.
I
just
wanted
to.
Basically
I
guess
terrify
you
about
the
kind
of
networking
we're
doing
so
that
you
know
really
to
say
that
it
doesn't
matter
what
you
do
with
service
meshes.
It
isn't
going
to
solve
this
problem
because
it's
a
weird
and
different
problem.
It
demands
efficiency,
among
other
things
and
and
it's
annoyingly
low
level
and
not
really
relevant
to
again
most
people's
experience
of
what
they're
doing
with
networking.
F
F
F
It's
not
obvious
that
it
necessarily
wants
to
belong
to
the
network
sig,
because
it's
not
about
networking
in
kubernetes,
it's
about
building
a
network
function
and
only
and
what
kubernetes
needs
to
provide
to
do.
That
is
only
one
part
of
the
problem
and
it's
also
a
little
bit
it's
everywhere
at
the
moment.
It's
how
do
I
make
my?
How
do
I
make
my
network
functions
cloud
native?
What
is
cloud
native?
What
is
an
application?
So
it
goes
on.
So
it's
a
little
bit
cross-platform
really.
F
B
I
agree
on
all
points
and
I'm
to
be
candid:
I'm
confused
as
to
like
cnf
conformance
working
group
like
it
is
all
about.
I
I
wait
like
for
my
part.
I
don't
need
any
additional
work,
so
you're
happy
not
to
or
not
I'm
happy
to
have
the
working
group
here
or
or
not,
but
it
is
like
so
much
more
about
networking
and
even
deeper
sort
of
lower
layer,
service
provider,
centric
networking
than
the
sig
see
app
or
the
other
and
granted
it's
a
cross
function.
F
Yeah,
well,
that's
it!
There
are
other
parts
here
things
like,
for
instance,
sig
app
delivery
could
potentially
be
interesting,
but
on
a
fairly
cursory
read
of
what
they're
doing
then,
what
they're
doing
is
talking
about
applications
that
are
delivered,
including
the
kubernetes
right
kubernetes,
is
a
part
of
the
application
and
again
that
turns
out
to
be
a
use
case,
distinction
between
what
service
providers
would
like
to
do
and
how
most
people
use
kubernetes.
Most
people
are
interested
in
running
one
app
on
their
kubernetes.
F
F
I
think
it's
important
that
we
get
people
who
are
thinking
to
do
that
to
recognize
the
distinction
between
what
they
want
to
do
and
what
everything
that
has
been
done
before,
because
the
immediate
conclusion
they
come
to
is
really.
It
must
work,
and
all
I
have
to
do
is
go
and
pick
and
choose
the
components
off
the
shelf
and
figure
out
which
ones
make
it
work
and
that's
sometimes
a
flawed
assumption.
F
B
It's
a
big
ol,
and
this
is
why
this
is
why,
earlier
when
we're
opening
the
call-
and
I
was
talking
about
the
surface
mesh
working
group
and
some
of
the
things
that
it's
doing,
the
where
I
was
trying
to
express
a
feeling
of
potential
guilt-
was
to
like
go
deep
and
focus
on
one
of
the
advancing
one
of
those
initiatives
using
this
hour.
Because
networking
as
a
thing
is
fast
broad-wide
and
so.
F
But
you
might
view
this.
As
for
networking
as
a
whole,
how
do
we
make
the
important
things
easy
and
the
hard
things
possible?
And
arguably
the
cna
might
makes
a
lot
of
important
things.
Very
easy
and
service
meshes
make
even
more
important
and
comparatively
complex
things
easy,
but
the
cni
as
it
stands
denies
the
possibility
to
make
the
hard
things
possible,
but
so
there's
a
little
bit
of
something
that
needs
to
be
broadened
out
in
that
direction.
And
since
again,
nearly
100
of
kubernetes
users
have
no
interest
in
doing
hard
things.
B
Let
me
ask
you
this
right,
there's
a
number
of
related
problem
statements
that
that
I
would
probably
add
to
this
list
that
are
from
a
layer,
seven
centric
perspective.
Where
we're
saying
where
I
would.
I
would
say
that
the
application
and
its
needs
are
under
characterized
in
in
layer,
seven
land
to
be
able
to
bring
forth
to
facilitate,
for
those
needs,
a
bit
more
programmatically
or
a
bit
more
automatically
and
things
like
not
exactly
cnab.
But
things
like
open
application
model
or
om.
B
Well,
is
that
there's
a
lack
of
a
the
lack
of
application,
lack
of
a
complete
definition
of
what
a
workload
is,
what
it
like,
what
it
is,
what
it
needs.
What
it
depends
on
doesn't
need
multiple
paths
out
like
and
if
there
are,
why
would
it
prefer
one
versus
the
next
sort
of
we
consider
like
things
about
affinity
or
anti-affinity
in
yeah.
F
You
you've
got
it's
sort
of
interesting.
I
I
think
what's
happened
here
is
that
we
don't
really
talk
at
the
level
of
a
workload
we
we
talk.
You
know
again,
if
I'm
netflix
right
and
sure
this
is
not
how
they
run
on
many
levels,
but
if
I'm
basically
running
a
and
as
a
service
offering
with
netflix,
be
it
salesforce
be
anyone
else
right.
It
isn't
a
matter
of
running
multiple
applications,
I'm
running
literally
one
application.
F
I've
broken
it
into
components
that
I'm
trying
divide
up
and
give
to
people
to
manage
them
separately,
but
I
only
have
one
application.
I
don't
really
have
to
think
at
the
application
level,
because
it
is
my
literal
job
description
when
you
start
asking
yourself
well
how
what
happens
if
I'm
running
many
of
these
things
simultaneously,
not
microservices
but
actual
self-contained
applications.
F
I
want
to
run
it
in
one
cloud.
Then
you
actually
don't
have
a
description
of
what
an
application
is
and
what
it
touches
and
what
else
it
might
want
to
communicate
with,
because
a
lot
of
these
things,
like
the
policy
of
how
microservices
communicate
and
the
security
you
put
in
place
there
and
the
metrics
of
how
microservices
communicate
that
are
relevant
to
the
person
running
the
application
and
maintaining.
It
are
also
interesting
to
the
guy
who's
using
multiple
applications,
because
now
they
want
to
know
how
these
applications
are
interacting
with
each
other.
F
E
Yeah,
there's
there's
a
part
of
what
needs
to
be
considered
in
the
space
as
well
is
how
do
you
provide
enough
information
for
these
infrastructure
components
to
be
properly
scheduled
by
by
the
orchestrator
and
so
right?
Now
it's
it's
it's
a
black
box,
but
even
the
parameters
on
on
what
the
system
supports
is
is
still
a
black
box
and
not
well
not
well
extracted,
so,
in
other
words
dude.
If
I
want
to
run
a
bump
in
the
wire
firewall,
this
thing
doesn't
have
an
ip
address.
E
It
doesn't
care
about,
load,
balancers
or
anything
like
that,
but
when
I,
when
I
install
it
into
kubernetes,
I
need
to
know
okay.
Well
what
what
protocol
is
this
thing
going
to
use?
Is
it
an
ethernet
based
one?
Is
it
ip?
Is
it
something
else?
So
what
is
its
payload?
And
the
second
thing
is:
how
do
I
actually
communicate
with
it?
Like
do
I
speak
with
it
over
a
kernel
interface?
Is
there
a
shared
memory
thing
I'm
going
to
drop
in?
E
Is
there
a
device
I'm
going
to
drop
in
that
it
knows
how
to
communicate
over,
and
so
it
needs
to
be
able
to
describe
its
capabilities
to
the
northbound,
so
they
can
get
scheduled
in
now,
whether
it's
kubernetes
or
something
else.
I
in
the
ideal
world
shouldn't
matter,
but
you
know
there's
right
now:
there's
not
a
good
description
or
definition
of
what
these
things
look
like
in
a
way
that
we
can
meaningfully
consume
them.
Despite
the
fact,
we
have
all
these
different
efforts
to
define
okay.
E
F
F
You
can
do
whatever
you
like
almost
with
the
networking,
but
most
people
will
shoot
themselves
in
the
foot
if
they
try
and
join
in
at
that
level
and
at
the
highest
level,
you've
got
something
which
is
narrow
and
prescriptive,
but
generally
doing
exactly
what
you
want
to
do
with
no
additional
value.
No
additional
craft
like
again
service
meshes
trying
to
deliver
particularly
specific
functionality
that
health
applications.
F
It's
possible,
that
if
we
stuck
that
lower
level
in
there,
we
would
certainly
find
more
flexibility
at
the
higher
levels
as
well.
I'm
not
saying
it's
necessarily
exactly
related,
but
the
one
that
always
comes
to
me
is
the
fact
that
envoy
is
effectively
running
privilege,
because
it's
doing
dirty
tricks
with
the
with
the
networking
that
aren't
strictly
permitted
by
the
cni
and
arguably
a
related
question
of
well.
What
networking
is
the
cni
itself
consuming?
F
You
know
if
there's
a
cni
plug-in?
How
does
it
attach
to
the
outside
world?
Is
there
a
possib
potential
for
for
more
things
there,
so
it's
possible
that
what
we're
doing
here
would
bring
value.
It's
not
the
first
place
I'm
trying
to
go,
but
I'm
certainly
not
saying
this
is
all
on
a
on
a
another
avenue
all
by
itself
and
it
doesn't
tie
back
in.
E
By
the
way,
the
oam
looking
at
the
networking
portion,
I
I
think,
is
binding
on
the
wrong
thing,
because
you're
binding
on
a
subnet
and
for
your
application
and
you
pass
in
a
subnet
id
for
for
how
to
connect
it
in,
and
this
had
this
is.
This
should
have
nothing
to
do
with
the
application
itself.
The
application
should
not
ask.
I
need
to
be
on
this
specific
subnet
in
order
to
in
order
to
communicate
that's
something
else.
E
F
This
this,
this
is
one
of
those
things
where
we
always
like
to
talk
about
immutable
infrastructure,
and
if
networking
is
infrastructure,
then
indeed
it's
immutable,
but
if
you're
a
part
of
the
networking,
then
it's
not
infrastructure.
It's
just
you
know
more
functionality
existing
elsewhere
and
in
no
sense
is
it
immutable.
F
So
when
we
talk
about
network
functions
since
they're,
going
down
to
the
lowest
level,
then
they
start
choosing
their
addressing.
They
start
choosing
their
mac
addresses.
Sometimes
they
certainly
start
choosing
protocols
that
are
not
ip
and
that's
where
you
know
a
lot
of
these
standards
like
oh
well,
you're,
an
application
of
course
you'll
want
to
subnet
and
figure
out
what
to
do
with
it
that
isn't
actually
how
this
works
once
you've
got
to
that
level.
E
F
E
B
E
Yeah,
if
you
look
at
it
from
something
like
like
build
pack
like
saying
what
do
you
want
to
connect
to
well,
there's
a
database
that
I'm
going
to
call
that
I'm
going
to
give
a
name,
but
that
name
is
not
a
it's,
not
a
it's
a
top-level
request.
It's
not
it's,
not
the
actual
binding.
It's
like.
I
need
to
connect
to
my
postgres
service,
whether
it
actually
renders
to
an
internal
postgres
or
some
external
one,
a
hosted
in
cloud
version.
E
You
don't
care
you're,
saying
that
the
protocol
is
postgres
and
you
need
to
communicate
to
something
that
speaks
that
and
so
having
a
having
a
system
where
you
can
describe.
I
need
to
have
a
relationship
with
a
service
within
the
spec
I
think
would
be,
would
be
excellent
and
how
the
system
renders
that
into
it.
It's
the
same
advice
that
I
gave
to
originally.
They
call
it
the
multi-interface
working
group.
They
changed
it
to
to.
E
I
forget
the
name
of
it
now,
but
never
never
plumbing.
I
think
it's
what
they
call
it
a
working
group
within
within
kubernetes,
but
the
the
initial
version
of
it
was
that
they
wanted
to
provide
multiple
interfaces.
It's
like
who
actually
cares
about
multiple
interfaces
as
a
user.
I
don't
care
about
it
about
multiple
interfaces.
I
care
about.
I
need
a
fast.
I
need
fast
access
to
my
to
my
storage
and
I
want
to
describe
that.
I
have
that.
I
need
this
faster
axis
somehow
and
how
it
gets
rendered
into
the
system.
E
I
don't
care
if
it's
all
over
the
same
interface,
whether
it's
a
different
one,
if,
if
they,
if
they
found
a
way
to
make
carrier,
pigeons
work
in
a
ethical
way,
then
I'm
all
in,
and
so
it's
it's
not
it's.
It's
not
a
like
you.
Don't
you
want
to
be
careful
not
to
buy
into
things
that
are
too
low
in
this
scenario,
and
I
think
that's
it's
a
common
it.
E
It's
a
common
practice
to
do
so,
but
there's
there's
consequences
down
the
line,
as
you
start
to,
as
you
start,
to
try
to
scale
these
things
up
and
so,
and
so
I
think,
describing
what
they
need
to
connect
to,
and
the
type
of
things
that
they
need
would
be
okay,
but
not
necessarily
describing
down
to
like.
I
need
the
specific
subnet
id
or
any
these
particular
because
those
now
you're
making
now
you're
making
assumptions
about
the
implementation
that
may
not
be
accurate.