►
From YouTube: CNCF SIG Network 2020-09-17
Description
CNCF SIG Network 2020-09-17
A
B
B
B
C
B
D
B
B
B
C
A
A
C
A
B
Good
deal
very
nice
very
nice
to
have
you
yash
and
tomas
thanks
for
coming
thanks
for
coming.
We
just
by
way
of
introducing
for
you
part
of
today's
agenda,
and
that
is
to
follow
up
on
some
work
stream
items
that
are
within
the
service
mesh
working
group.
The
service
mesh
working
group,
the
slides
and
charter
for
it
are,
can
be
seen
here
and
the
cncfc
networks
charter
is
broader
than
a
service
mesh
focus.
B
There
are
about
four
initiatives
within
that
group
right
now.
We
just
as
a
brief
recap
for
everyone.
There's
a
bit
about
one
initiative
about
service,
mesh
interface,
conformance
or
smi,
conformance
for
those
that
were
like
paying
really
really
really
close
attention.
I
think
yesterday,
maybe
the
day
before
yeah,
I
think
it
was
yesterday
or
tuesday
there's
a
little
bit
of
a
leak.
It
feels
like
a
leak
of
a
new,
yet
another
service
mesh,
that's
being
announced,
and-
and
this
is
one
that's
been
in
the
works
for
a
while.
B
I
hesitate
to
name
it
because
it
feels
like
it
was
an
accidental
announcement
and
but
this
particular
service
mesh.
It
uses
smi
entirely
as
its
rest
api,
or
rather
it
uses
yeah.
Its
implementation
is
done
through
smi
and
that's
the
only
interface
that
it
has,
and
so
I
highlight
it
just
as
another
another
example
of
some
of
the
steam
building
behind
smi.
B
Another
one
is
with
part
of
the
envoy
project,
the
the
nighthawk
load
generator
and
trying
to
help.
Try
to
you
know
trying
to
make
do
some
analysis
around
the
just.
What
happens
when
you
have
load
generators
distributed
and
coalescing
they're,
you
know
doing
statistical
analysis
coalescing
those
results
examining
things
in
a
distributed
world,
then.
The
fourth
aspect
to
our
to
this
working
group
is
a
bit
about
service
mesh
patterns
and
so
depending
upon
who
else
shows
up
today
we
might
actually
get
to
those
patterns
so.
B
B
Using
the
topic,
and
maybe
on
record,
to
answer
a
recent
question
that
michelle
had
had
not
that
not
that
we
need
to
be
on
record,
but
so
one
of
these
initiatives
is
smi
conformance
the
more
service
meshes
that
are
out
there.
The
more
that
people
projects
might
like
to
confirm
sort
of
officially
that
they're
that
they
are,
in
conformance
with
the
apis,
that
smi
sets
forth
to
perform
this
type
of
conformance.
B
This
particular
piece
of
work
has
been
well
something
that
was
established
as
a
goal
about
a
year
ago,
last
october,
and
a
couple
of
bright
students
have
worked
on
this
for
a
few
months
and
then
they
sort
of
handed
it
off
to
a
couple
of
other
bright
students
and
and
we're
essentially
at
a
place
in
which
this
this
initiative
is
the
the
tooling
is
essentially
there
that
there's
mesherie
as
a
tool
supports
eight
different
service
meshes
today.
Some
of
the
later
ones
that
it
supports,
are
open
service.
B
Mesh
kuma
are
kind
of
prominent
examples
of
two
service
meshes
that
claim
support
for
smi,
and
there
are
two
examples
of
service
meshes
that
you
can
use
meshri
to
validate
smi
with
today,
there's
kind
of
a
lot
to
not
not
a
lot,
but
there's
a
few
concerns
specific
to
how
you
would
do
conformance
testing
or
in
this
way.
One
is
that
you
know
similar
to
there
being.
B
I
forget
like
at
one
point:
there
was
80
something
kubernetes
distributions,
maybe
there's
more
or
less
now
I
don't
know,
but
to
be
able
to
claim
that
you
are
that
the
software
that
you're
shipping
is
in
fact
kubernetes.
It
needs
to
adhere
to
and
behave
again.
You
know
in
accordance
with
the
signature
of
kubernetes
apis
and
so,
and
so
you
know
in
the
same
fashion,
should
a
service
mesh
claim
conformance
with
smi.
It
should
behave
and
respond
in
accordance
with
that
specification,
and
so
that's
what
this
this
initiative
is
about.
B
So
if,
as
each
individual
service
mesh
project
and
as
just
service
mesh
users
are
able
to
perform
validation,
it's
it's
important
consideration
that
one
to
acknowledge
that
not
all
service
meshes
intend
to
fully
deliver
on
smi's
specifications
some
of
its
specifications
they
just
don't
ever
intend
to
to
have
that
capability.
So
it's
important
to
acknowledge
that
there's
a
difference
between
capability
and
compliance.
B
So
if
the
mesh
has
that
capability,
is
it
in
compliance
or
if
it
says
hey,
it's
never
going
to
have
it
then
that
that
probably
doesn't
you
know
it?
Doesn't
it's
not
failing
a
test,
because
the
test
is
inappropriate,
but
that's
kind
of
a
point
of
discussion.
I
think
something
that
probably
not
enough
eyes
have
been
on.
Let
me
call
upon
the
collective
minds
that
are
on
this
call
right
now
and
and
get
it
get
in
a
couple
of
opinions.
B
Does
it
also
make
sense
to
you
that
that
same
report
would
itemize
particular
apis
or
a
whole,
an
entire
api
that
a
mesh
will
never
be?
You
know
like?
Is
it
that
a
mesh
will
never
have
that
capability
like?
Is
it
possible
to
be
this?
Is
I
don't?
This
is
just
a
mind
exercise
for
everyone
on
here.
In
your
mind,
is
it
possible
to
be
compliant
with
the
specification
and
yet
not
implement
a
certain
percentage
of
it?
A
Yeah,
so,
traditionally
speaking,
if
someone
says
I
comply
with
mumble
mumble,
I
would
expect
whatever
mumble
mumble
is
specified
to
actually
work,
and
so,
if
you
have
sort
of
a
partial,
if
you
want
to
get
a
general
compliance
in
a
partial
way,
you
sort
of
need
some
way
to
talk
about
the
subsetting
in
a
sane
sense
right.
So
you
can
say:
okay,
we
support
smi
and
we
support.
You
know
profile
one
profile,
three
and
profile,
seven,
so
that
you
actually
can
understand
clearly
what's
being
done
and
that
it's
being
done.
B
B
B
Do
you?
Is
it
still
like
just
a
sort
of
edit
in
accordance
with
what
you
were
saying
generally
like
it?
It
would
be
in
most
projects.
It
would
be
simplified
to
just
language
like
well,
assuming
that
they're
passing
that
service
mesh
is
passing
every
other
test
and
that
the
in
the
gateway
tests
made
up
30
of
the
spec.
A
Don't
think
the
percentage
tells
you
anything,
because
I
I
could
be
70
percent
compliant
in
in
the
way
you
just
described,
where
I
just
simply
aren't
I'm
not
implementing
a
gateway,
and
so
I'm
not
doing
that.
But
I
have
stellar
compliance
on
everything
I
do
implement
or
I
could
be
70
compliant
because
I'm
a
complete
show
and
there's
literally
no
way
to
distinguish
there.
It
may
be
useful
to
think
about
how
long-running
standards
have
dealt
with
some
of
this.
A
Now,
there's
not
a
lot
of
mechanical
difference
between
somebody
introduced
to
something
new
to
the
smi
spec
versus
you.
Don't
support
gateways
in
both
cases.
You
need
some
reasonable
way
of
saying
very
succinctly
what
you
do
and
don't
support
so,
basically
saying
being
able
to
say
I
support
and
part
of
this
has
to
feedback
the
smi
community
right
about
how
they
classify
their
stuff
because
they're
the
ones
that
should
come
from
but
being
able
to
say.
I
have
a
hundred
percent
compliance
with
smi
core
and
I
have.
A
I
have
no
compliance
at
all
with
smi
gateway,
for
example.
Okay:
well,
clearly
you
don't
support
smi
gateway.
It
doesn't
mean
that
you're
screwing
it
up
you're,
just
not
even
trying-
and
that's
really
quite
different,
because
you
know
somebody
who
has
a
really
poor
compliance
score
on
something
they're
trying
to
do.
That
could
be
a
poor
indicator
in
general
of
software
quality,
whereas
you've
got
seller
really
really
stellar
compliance
scores
on
all
the
things
you
claim
to
be
compliance
compliant
on.
That's
quite
different.
B
It
pleases
me
to
hear
you
say
that
yeah,
because,
as
we
were
talking
over
it
initially,
I
was
a
had
brought
this.
This
up
was
to
really
sort
of
acknowledge
that
hey,
wouldn't
really
feel
fair
to
some
or
like
it's
not
it's
not
necessarily
about
fairness,
but
it
wouldn't.
It
would
feel
like
a
misrepresentation
that
they
would
that
a
given
mesh
might
have
a
stellar
implementation,
but
always
be
represented
as
a
70
pass
rate,
because
they.
B
So
there
are
four
smi
spec,
I'm
saying
some
things
that
some
of
you
know,
but
there's
four
smi
specs
these
simple
verbal
statements
or
high-level
descriptions
of
some
of
the
tests
that
will
be
asserted
and
verified.
Some
of
that
is,
like
you
know
you
do
a
traffic
split.
You
deploy
a
sample
app,
you
send!
You
generate
some
load,
you
you
validate,
that
of
the
100
requests
sent
that
50
were
that.
You
know
you
you're
doing
this.
B
A
A
B
That's
helpful
yeah.
I
wish
I'm
an
smi
maintainer,
but
I'm
one
of
eight,
the
other
two
people
that
I
mentioned
were
would
have
been
three
of
eight
or
like
it
would
have
been.
This
is
that
this
is
a
fantastic
input
and
I'm
remiss
there
I'm
sad
that
there
aren't
a
couple
of
others
here
to
help
concrete.
B
B
B
B
B
Helping
people
understand
them,
so
hopefully
everyone
is
able
to
open
the
link
in
case
you're,
not
able
to
see
it
very
well,
but
if
you
would
have
a
gander
and
and
have
a
comment
these
are.
These
patterns
are
broken
down
for
the
mo
broken
down
into
different
areas,
they're
not
identified
really
by
what
is
foundational
and
what
is
advanced.
B
Through
configuration,
and
so
that
that's
kind
of
what
this
this
group,
this
collection
is
about
this
next
one
is
just
you
know:
how
do
you
get
up
and
going
and
doing
it
either
locally
or
remotely
different
service
mesh
architectures,
a
popular
pattern
of
there
being
sidecar
proxies
being
used?
There
were
service
meshes
of
past,
and
current
service
meshes
that
also
use
a
node
agent
like
a
daemon
set
model.
B
C
B
A
No
it's
a
little
bit
underway.
There
was.
There
was
a
there
were
several
months
and
then
the
the
talk
came
back
to
it
and
they
had
some
really
really
smart
questions,
some
of
which
you
just
kind
of
go.
I
feel
stupid
for
not
having
answered
that.
So,
for
example,
they
asked
what
versions
of
kubernetes
do
you
support
with
your
releases
and
we've
done
sort
of
very
broad
testing
across
different
kinds
of
environments,
various
public
clouds,
et
cetera.
A
So
I
I
went
back
through
on
that
question
and
actually
rear
nrci,
going
all
the
way
back
to
1.12
and
just
for
good
measure
going
all
the
way
forward
to
119,
and
we,
you
know
basically
in
the
course
of
that
found
all
that
was
always
well
across
that
range
and
got
that
up
on
the
release,
notes
pages
and
then
commented
to
do
that.
I've
still
got
a
few
more
questions.
They've
asked
for,
unfortunately,
to
really
do
a
good
job
of
answering
some
of
their
questions.
A
I'll
need
to
draw
some
pretty
pictures
because
they're
asking
about
things
like
you
know
what
new
features
came
in
here
and
I
can
do
sort
of
a
dry
bullet
list,
but
it's
not
going
to
help
the
the
talk.
I
don't
think
because
they're
not
day-to-day
in
the
mock
and
a
couple
of
pretty
pictures
actually
on
the
release
page.
You
should
make
that
really
clear.
So
that's
that's
kind
of
where
that
is
right
now,
so
I've
still
got
a
few
more
things
to
do.
B
A
So
I
mean
my
experience
with
that
sort
of
thing
is
that
a
lot
of
it
comes
down
to
the
tone
of
the
tone
with
which
the
invitation's
extended
I've
seen
people
get
very
excited
about
hey.
You
know
we
have
a
venue
here.
We
wanted
to
offer
the
opportunity
for
you
to
come
in
on
the
cadence,
that's
comfortable
and
tell
us
about
your
progress
and
sort
of
spread.
The
word
a
little
bit.
That
invitation
goes
super
well.
A
And
then
yeah
and
the
other,
the
other
piece
of
it
quite
frankly
is
cubecon
is
a
giant
bowl
of
content
all
at
once
and
that's
intensely
overwhelming,
but
the
oh
this
week
in
a
week
where
not
a
lot
else
has
happened
that
I've
noticed
going
by
that
I'm
going
to
invest
my
time
in
there
was
this
talk,
that's
been
given
or
had
been
given
last
week
on
this
topic
over
here.
That
looks
interesting.
That's
often
much
less
overwhelming
for
audiences
than
we
have
500
talks,
which
one
would
you
like
yeah.
A
B
Nice
yeah
good
yeah.
Actually
I
had
gotten
a
question
from
jim,
whose
last
name,
I
think
is
saint
lager
of
currently
of
intel.
He
was
he's
been
on.
These
calls.
A
few
different
times
has
asked
some
good
questions.
He'd
recently
asked
about
the
relationship
between
the
cncf
sig
network
and
it
wasn't
the
kubernetes
sig
network.
It
was
the
kubernetes.
A
A
And
one
thing
I
don't
know
how
much
work
it
is,
that
might
be
helpful,
is
just
having
an
index
of
these
are
all
the
things
going
on
on
a
regular
basis
that
cncf's
networking
thinks
might
be
of
interest
to
people
who
are
interested
in
networking
in
the
cloud
native
space
right.
So
here's
the
relevant,
you
know,
meetings
that
are
happening
in
the
kubernetes
networking
singing
committee
space
and
here's
these
community
meetings
that
are
happening
for
these
communities
and
that
kind
of
thing
like
it's
sort
of
like.
A
C
C
B
C
B
If
we
could
so
we're
going
to
be
giving
time
back,
but
before
we
do,
since
I
gotta
say
like
I,
my
I've,
my
hands
been
sort
of
shaking,
I
haven't
had
like
actual
human
contact
in
a
while.
I
didn't
get
my
cubecon
in,
and
so
I
gotta
be
friendly
and
social
a
bit
and
so
yosh
since
you're
on
the
call
and
thomas.
Do
you
guys
mind
introducing
I'd
love
to
get
to
know
you
some
and
just
what?
What
you're
into
what
your
focus
is?.
D
Yeah
sure
I
can
go
first,
so
I
work
in
vmware
and
I'm
working
on
the
kubernetes
on
these
peer
product
and
so
I've
actually.
So
this
is
just
a
way
for
me
to
keep
in
touch
with
what
you
guys
are
doing,
and
so
I've
just
been
attending
some
of
the
meetings.
So
this
is
just
me
or
looping
and
then
figuring
out
some
of
the
things
that
you
guys
are
working
on.
B
D
Right
for
me,
I
think
so
to
give
you
more
of
a
background,
I'm
working
on
the
cubelet
equivalent
team
we
have
in
so
we
we
run
equivalent
of
a
cubelet
or
a
virtual
cubelet
fork
on
esxi.
So
I'm
I'm
working
on
that
team.
So
a
lot
of
the
networking
is
a
bit
higher
layer
for
me,
but
I'm
just
interested
in
like
learning
about
it.
At
this
point.
B
Josh
something
else
to
maybe
click
on
and
spend
30
seconds
looking
at
is
this
there's
been
a
collection
of
folks
who've
been
working
on
helping
define
cloud
native
networking
and
some
of
its
concepts
and
principles,
and
it's
been
a
it's
a
resource
kind
of
it's
been
a
point
of
discussion
in
this
sig
in
the
past.
So
there's
a
link
there.
If
it's
and
then.