►
Description
Presentation of SMI Metrics and Linkerd demo. Discussion of Service Mesh Interface Metric and Traffic Specs. Discussion of scope of Service Mesh Performance.
A
A
A
A
B
Yeah,
it's
all
open,
so
I'm
working
on
the
linkedin
project,
it's
a
full-time,
so
the
current
project
that
I've
been
working
on
is
actually
semi.
It's
actually
smart
extension
for
linkerd.
We
have.
We
haven't
spoken
about
it
in
the
call
et
cetera,
but
I've
been
working
from
the
last
one
and
a
week
full
time
on
that
project,
where
just
like,
viz
and
other.
B
Now
in
linkedin,
we
have
these
extension
models
right
where
we
we
added
that
recently
in
a
in
a
in
a
recent
release
where
we
have
this
and
other
stuff,
has
extensions
vision,
etc.
So
so
yeah.
So
we
are
now
trying
to
create
a
semi
extension
that
installs
an
adapter
that
converts
stuff
etc,
so
that
so
that
linker
doesn't
need
to
have
all
the
smi
details
in
the
repository.
C
B
B
A
Good
well,
most
of
all
of
us
at
least
have
name
recognition
with
one
with
the
next
of
us
auto.
One
of
the
probably
key
ingredients
here
is
going
to
be
about
10
minutes
late,
so
hopefully
another
six
minutes.
So
I'll
kick
us
off,
though,
and
kind
of
introduce
the.
Why
it
is
that
we're
going
to
spend-
maybe
maybe
an
hour,
maybe
less
together.
C
A
A
Therein
lie
their
question:
what
is
the
alignment
and
and
overlap
and
underlap
and
as
the
cncf,
how
do
we?
How
are
we
communicating
the
service
mesh
story
in
some
respects?
There
were
some
suggestions
on
on
the
position
of
authority
that
the
cncf
has
and
how
we
might
determine
have
tooling
and
to
to
determine
what
is
a
service
mesh
and
whether
or
not
someone
is
implementing
the
surface
mesh
and
that
kind
of
a
thing
there
was
a
lot
of.
A
There
were
a
few
different
toc
members
who,
I
consider
were
being
great
stewards
of
of
the
cncf
of
the
projects
that
are
represented,
and
they
were
also
you
know,
like.
I
do
much
of
the
time
I'm
having
to
try
to
make
quick
decisions
or
formulate
thoughts
based
on
ignorance,
so
they're
ignorant
of
a
lot
of
the
details
of
well
really
all
three
of
those
projects
that
I
just
mentioned,
and
so
their
question
is:
how
do
those
align
or
can
they
align?
Should
they
meld
into
one?
Should
they
meld
into
two?
A
Should
they
stay
as
three
and
so
we're
here
trying
to
do
some
of
that
diligence?
And
so
I
today's
the
direction
of
today's
discussion
was
really
to
take
maintain
surface
mesh
performance,
maintainers,
so
sunku,
nick
jackson
and
otto
van
der
schaff
and
myself,
through
sort
of
a
presentation
from
from
smi
from
with
specifically
on
metrics,
to
help
this
this
up
this
other
collection,
this
other
project
really
understand
smi,
metrics
much
better
and
that's
kind
of
the
goal.
That's
that's
sort
of
the
I
mean
overarching.
A
The
goal
is
to
for
us
collectively
to
say
to
to
you,
know,
verbalize
or
articulate
in
written
form.
Here's
how
we
think
that
the
projects
are
complementary,
where
they
don't
do
things,
maybe
how
they
all
come
into
one
or
stay
separate
whatever
those
whatever.
That
answer
is,
but
is
to
just
earnestly
explore
that,
and
we
start
by
cross
presentations,
helping
explain
what
the
projects
are
about
back
and
forth
to
each
other
and
so
tarun's.
The
first
stop
so
rooney.
B
B
So
as
as
the
problem
here
is
that
each
mesh,
each
mesh
gives
out
the
metrics
in
a
different
way
in
a
different
format,
etc,
and
it
would
be
really
nice
to
have
to
have
a
single
way
single
api
that
you
could
use
to
get
metrics
out
of
any
different
mesh
right
so
that
you
can
build
top
tools
on
top
of
it
that
consume
these
metrics
and
do
a
specific
task,
etc.
So
an
obvious
example
here
is
flagger,
which
does
canary
deployments
on
any
mesh
it.
B
B
They
have
implementation
specific
to
specific
to
the
mystery,
but
I'm
not
sure
here,
but
but
the
the
conclusion
here
is
that
tools
like
flagger
etc
can
be
built
that
consume
these
metrics
in
a
in
a
in
a
uniform
manner
without
having
to
know
how
a
specific
mesh
responds
to
metric
queries,
the
format
etc.
So
so
how
so
so?
This
is
solved
by
having
perhaps
by
having
an
sms
metrics
adapter.
This
is
not
like
an
adapter,
because
it
is
not
con.
B
It
is
kind
of
converting
stuff,
but,
unlike
it
is
not
unlike
other
adapters,
because
there
are
no
resources
here.
First,
for
example,
you
would
not.
You
would
not
apply
a
traffic
matrix
resource
to
a
kubernetes
api.
You
would
you
do
a
traffic
split.
So
so
there
is
this
adapter
api
that
sm
that
repo
is
in
the
sma
metrics
repository
in
the
in
the
service
mesh
interface
organization.
B
Once
you
install
once
you
install
that
adapter
during
the
installation
you
specify
which
mesh
is,
is
there
in
your
cluster
and
and
if
you
have
any
changes
there
so,
for
example,
with
linkardi,
you
can
specify
the
prometheus
url.
If
you
have
a
custom
namespace
and
things
like
that.
So
so,
with
some
configuration
like
that,
once
you
install
the
adapter,
you
can
have
a
uniform
way
of
getting
metrics.
B
A
If
this
is
an
act,
characterization
or
not,
but
part
of
the
difference
that
you
are
articulating
between
smi
metrics
as
an
adapter
and
how
it
differs
a
little
bit
from
some
of
the
other
specs
is
that
is
that
your
these
external
applications,
like
flagger?
As
the
example
are
you
are
consuming?
These
signals
are
consuming
these
metrics,
whereas
with
the
other
specifications
they
might
be
much
more
applying.
B
Stuff
too
yeah
yeah.
That
makes
sense
so,
with
I
mean
likely
said,
with
sms
metrics.
It's
mostly
on
the
consumer
side.
All
of
the
adapter
doesn't
apply
anything
it
just
reads
stuff
from
your
cluster
and
renders
that
and
renders
those
metrics
in
a
uniform
manner,
irrespective
of
the
mesh
right
is
irrespective
of
the
machines
inside
the
cluster.
B
So
so
I'm
running
a
kubernetes
cluster,
I'm
not
sure
about
the
version,
but
but
the
linkedin
version
is
the
is
the
latest
version,
because
because
we
did
some
changes
in
the
latest
version
of
the
linkedin
that
are
not
that
are
not
the
defaults
in
the
sma
matrix
repo.
As
of
right
now
I
had
to
update
some
of
the
values.ml
to
to
to
take
account
of
the
latest
changes,
so
once
the
that
is
there,
you
can
so
I
went
ahead
and
installed
the
semi
adapter
by
using
a
helm
command.
B
I
rendered
the
chat
and
then
applied
that
so
because
I
did
that
you
can
see
here,
you
can
see
a
deployment
in
the
in
the
in
the
in
the
default
name.
This
calls
it
called
sma,
metrics
and,
and,
as
you
can
see
linked
in
installation
is
all
is
also
there.
If
you
do
linked
check,
this
should
be
all
green,
etc.
The
elegant
liquid
is
a
service
project
in
the
cnc
ecosystem,
so
once
you're
so
now
we
have
linked
installation
and
our
and
also
the
adapter
installed.
B
Give
me
a
second
so
so,
once
you
do
that
you
it
also
it
also
installs
an
api
service.
So
like
a
cubicle
api
service
is
a
is
like
a
general
way
of
car.
It's
like
an
it's
like
a
building,
an
extension
absorber
extension
on
kubernetes,
so
that
so
that
you
can
consider
this
services
also
an
extension
in
kubernetes,
with
all
the
with
all
the
tls
guarantees,
etc.
Right
with
all
security
guarantees,
etcetera.
It's
like
an
it's
like
it's
like
kubernetes
api,
but
but
it's
an
external
one.
B
The
the
queries
are
returned
by
a
deployment
not
on
the
kubernetes
api
server.
So
because
we
did
that
we
have
the
sma
metrics
service
here
installed.
It's
it's
an
api
service
and
now
because
now
that
you
have
installed
it,
we
can
do
it
we
can
now
now
I
can
do
a
query
actually
on
a
on
a
metric,
so
so
I'll
go
ahead
and
do
it
under
cubic
tile
raw
query
on
the
api
service.
B
So
here
what
I'm
doing
is
that
I'm
doing
a
query
on
the
smi
ap
api
service
that
the
adapter
installed
and
I'm
querying
for
the
prometheus
deployment
in
the
in
the
linkedin
is
namespace.
So
so
this
query
essentially
returns
the
metrics
for
the
prometheus,
install
instance
in
the
link
device
namespace.
So
because
I
did
that
you
can
see
you
can
see
automatically
that
it
is
it
returns.
B
So
this
is
the
format
that
we
use
currently
with
with
sma
metrics,
where
we
reply
where
the
api
replaces,
with
with
the
following
metrics
for
each
deployment
that
you
specify,
and
this
could
be
deployment,
pod,
name,
space,
etc.
So
it's
pretty
flexible
that
way
that
you
could
be
like
give
me
all
the
latencies
for
the
name
space
lingard
device.
So
it
adds
up
all
the
deployments
and
their
metrics
you
could
you
could
even
go
ahead
and
ask
granularly
for
a
pod.
Even
so
so
the
api
is
granular.
B
So,
as
you
can
see
here,
we
have
p99
latencies,
p90,
p50,
etc,
but
this
is
only
for
prometheus,
but
you
would
want
to
see
you
would
want
to
see
how
matrix
for
each
edge
right.
So
so
this
means
that
these
are
the
prometheus
matrix
for
all
its
edges
for
for
every
connection
that
prometheus
gets
essentially
so
so
now
we'll
go
ahead
and
and
and
we'll
ask
for
the
metrics
at
each
edge.
B
So,
for
example,
because
prometheus
does
interactions
with
all
with
all
the
different
kinds
of
things
right
like
like
I
mean
it,
scrapes
metrics
from
everywhere.
Essentially
so,
if
you
do
adjust
for
prometheus,
this
list
is
huge
because
it's
specifying
the
latencies
for
each
edge.
Essentially
one
other
thing
to
note
is
that
lincoln
division
also
gets
so
in
the
edge.
We
always
we
always
specify
the
direction
on
which
on
which
the
metrics
are
being
showcased.
B
So,
for
example,
if
we
do
a
promise
is
not
a
great
example,
because
it's
it's
on
the
outbound
side,
right
like
pramit
is
asking
is
scraping,
is
creating
metrics
for
from
others,
but
you
could
go
ahead
and
install
an
application
service.
I
can
try
doing
that
so
so
there
is
this
emoji
order
service
that
we
use
for
demos.
B
Obviously
we
just
created
that
and
it
will
take
some
more
time
before
things
are
made,
go
so
things
run
so
essentially,
while
the
while
installation
happens
so
essentially,
as
you
saw
irrespective
of
the
underlying
mesh
right,
it
could
be
steel,
it
could
be
linked,
etc.
Once
you
do
a
query,
you
get
the
metrics
in
the
same
format
for
any
application
for
any
anything.
Essentially.
So
currently
we
support
linkedin
linkedin
supported
in
the
repo.
B
B
So
so
so
so,
as
you
can
saw
in
the
example,
so
now
I
am
asking
the
metrics
for
for
the
web,
as
you
can
see
for
web,
there
is
a
there
is
a
there
is
an
edge
from
vote
bot.
So
so
what
board
is
an
automated
client
that
keeps
sending
requests
for
web?
As
you
can
see,
we
can
see
the
traffic
matrix
on
each
edge
and
on
a
specific
direction.
So
so
this
is
all
just
the
metrics
for
from
vote
bot
to
web
service.
B
B
A
I'm
throwing
up
some
of
the
specifics
in
that
implementation
are
so
to
summarize,
like
the
the
current
extent
of
sims,
my
metrics
as
a
spec
and
as
you've
demonstrated
through
this
implementation,
like
the
implementations
may
differ,
but
the
spec
itself
is
oriented
toward
well
curating
top
level
metrics
that
an
operator
would
be.
That
would
be
like
the
what's
the
right,
the
the
most
bang
for
their
buck,
the
highest
fidelity
metrics.
If
you
will
the
ones
that
are
the
most
insightful.
So
the
top
line,
and-
and
you
know,
and
and.
A
A
Like
I
mean
just
just
in
internalizing
sort
of
articulating
the
value
of
smi
metrics
is
fairly
short,
well
ubiquitous,
a
ubiquitous
interface
by
which
you
can
get.
You
have
short
time
to
value
of
like
of
these
top
line,
metrics
across
your
the
apps
that
are
running
on
whatever
mesh
you're
running
and
so
and
yeah.
So
there's
a
lot
of
value
there.
The
kubernetes
native
integration
as
well,
then.
A
D
Good
point
lisa
and
thank
you
tharon
for
the
demo.
It's
really
helpful
from
my
perspective.
One
of
the
biggest
confusion
point
given
my
background
and
my
natural
work
right
now
is
enabling
service
mesh
for
5g
and
edge
deployments.
The
word
edge
is
kind
of
you
know
conflicting
in
that
sense,
but
not
just
that
the
way
I
see
this,
the
traffic
matrix
as
we
call
it
at
the
p90
p99
a
lot
of
these
latency
metrics
right.
D
So
these
for
from
our
perspective
that
so
far
the
discussions
I
had
are
more
of
not
observability
per
se,
but
more
of
a
kpis
that
we,
you
know
from
a
performance
standpoint
like
what
are
these
kpis,
that
we
looking
to
see
effectiveness
or
the
mesh
utilization,
or
right
so
or
there
and
overall
performance
of
a
service
mesh
all
right.
So
so
one
is
transactions
per
second,
another
is
latency,
two
main
things
that
we
see
so
categorizing
this
as
a
metrics.
D
I
right
so
I'm
just
getting
to
see
the
smi
spec
on
traffic
metrics,
but
and
it's
kind
of
confusing
in
that
sense,
because
these
are
more
towards
kpis
than
observability
side
of
things
right.
So
when
you
start
looking
into
prometheus
and
and
what's
the
whether
infrastructure,
resource
utilization
or
part
utilization
or
part
metrics,
so
I
see
a
little
bit
of
conflict
there.
But
you
know
ideally-
and
I
said
one
side
to
look
at
this
from
a
performance
aspect-
is
okay
between
two
edges.
D
What
are
my
metrics,
that
I
look
for
p50
or
any
other
latency
numbers
from
a
overall
performance
standpoint
right,
so
these
are
between
source
and
destination
in
in
within
a
cluster
within
a
between
two
parts.
Orbits
between
services
is
one
aspect,
but
I
think
the
performance
characterization
aspect
would
be
much
more
encompassing
with
respect
to
what
what
would
my
infrastructure
be
right?
What's
underneath
my
kubernetes
cluster
right?
So
how
would
it
impact
performance
versus
you
know,
between
different
clusters
or
within
a
cluster
part
of
service
service
department?
D
A
lot
of
these
topologies
that
we
could
consider
and
say
how
is
my
service
mesh
impacting
overall
performance
of
my
kubernetes
cluster
and
from
a
spec
perspective?
You
know
touches
upon
the
key
part
of
where
you're
getting
the
metrics
between
source
and
destination,
but
we
might
have
to
kind
of
characterize
it
or
slay
it
across
these
other
dimensions
where
it
impacts
the
performance
right.
How
do
you
configure
a
lot
of
these
underlying
aspects
of
a
kubernetes,
cluster
and
and
service
mesh
configuration
where
it
impacts
the
performance?
B
D
Right
right,
no,
I
agree
an
end
of
the
day
in
a
production
environment
or
any
deployment.
That's
what
it
matters
where
you
have
your
day,
zero
day,
one
configuration
all
done
and
it's
all
about
how
my
applications
and
are
performing,
but
you
know,
for
I
think
the
discussion
is
about
looking
into
how
smi
and
smb
can
work
together
right
right.
So
in
that
sense
you
know
this
is
one
aspect
of
overall
performance
analysis
or
performance
characterization.
D
A
Yeah
yeah,
I
know
I
know
that
the
format
of
this
discussion
is
only
brings
us
halfway
to
well.
I
don't
think
it's
like
one
third
of
the
way
to
like
the
data
that
we
need
like
there
is,
and
I
don't
I
honestly
don't
know
that
we're
in
a
good
position
to
do
it
right
now,
but
but
there's
a
sort
of
a
cross
presentation
back
to,
and
actually
I
don't
think
we
invite
we
didn't
like
this.
A
So
by
the
way,
thanks
for
the
thanks
for
coming
on
thanks
for
the
demo,
it's
good
stuff
to
assume
his
point,
like
smi
metrics,
hits
the
sweet
spot
for
what
people
like
what
they
need
to
immediately
know
to
know
whether
or
not
it's
a
green
light
or
a
red
light
or
like
and
or
where
they're
starting
to
have
a
yellow
light.
So
to
speak,
and
sometimes
that's
the
app.
A
A
Yeah
the
two
can
either
and
I
like
I,
I
hesitate
to
like
go
into
like
begin
to
suggest
things
because,
because
really
there's
a
presentation
that
needs
to
go
back
about
smp
and
what
it's
trying
to
accomplish
touched
on.
Some
I'll
try
to
say
a
couple
of
others,
which
is
that
there
are
well
I'll
I'll
bring
this.
The
service
master
performance
road
map
up,
because
at
a
just
at
a
high
level,
it
characterizes
part
of
the
scope
of
the
project
itself
and
what
you
know
where
the
focus
is
intended
to
be.
A
At
its
core
or
s,
p
itself
is
a
spec
and
and
isn't
the
implementation
as
a
project,
though
it
does
have
a
number
of
softer
goals
or
or
information
disseminating
goals
around
well
common
workload.
Profiles
like
being
able
to
help
inform
people
about
whether
or
not
they're
really
running
their
infrastructure
in
a
performant
way
or
not
like
in
a
comparative
way.
A
It's
to
some
of
that
is
around
publication
and
and
sort
of
the
running
of
benchmarks
and
the
publications
of
those
that
analyses,
and
so
some
of
that
not
all
of
that,
hopefully
that's
represented
within
the
spec,
but
not
all
of
it
is
of
the
spec.
So
not
all
of
the
goals
are
of
the
spec
as
you
go
to
characterize
the
performance
of
any
service
mesh
or
really
like
in
some
respects,
some
respects.
It's
just
the
mesh.
A
That's
interesting
to
measure
then
period
for
many
others,
it's
the
workload
and
the
mesh
and
for
others,
it's
the
workload,
the
mesh,
the
orchestrator,
the
the
infrastructure
down
below
and
and
then
all
of
the
myriad
permutations
of
those
configurations
and
that's
kind
of
the
crux
at
what
the
spec
is
is
aimed
at
it.
It
wasn't
it's
not
really
aimed
at
describing
your
workload.
There
are
other
specs
that
do
that.
A
It
wasn't
really
aimed
at
describing
so
much
the
function
like
it
does
try
to
capture
and
describe
the
functionality
and
configuration
of
your
service
mesh
and-
and
that's
actually
a
good
like
where
that
overlaps,
where
that
config
overlaps,
that's
an
ideal
spot
to
say
to
potentially
characterize
that
in
an
smi
format.
So
if
there
is,
if
there,
I
think
we
talked
about
this
on
an
smi
call
some
time
ago
is
like
if
there's
a
there's
a
traffic
spec
and
that
characterizes
a
particular
protocol
or
a
port
that
requests.
A
You
know
the
traffic
is
transiting
okay.
Well,
that's
an
opportunity
to
use
the
same.
Descriptor
use
the
same
spec
to
characterize
that
the
I
think
what,
as
as
we
look
at
these
two
and
we
try
to
embrace
the
the
overlap
and
potentially
extend
that
that
yeah
we'll
find
that
smp
wants
to
be
quite
detailed
and
not
concise
in
nature,
whereas
I
think
we'll
find
smi
by
well
by
virtue
of
a
couple
of
facts.
A
I
think
one
that
it's
that
that
you
know
it's
trying
to
it's,
not
intentionally
trying
it's
it's
by
its
nature,
being
lowest
common
denominator.
It's
something
or
it's
hitting
the
top
level
use
cases
and
it's
reinforcing
those
by
hitting
those
somewhat
quickly
and
refining
them
over
time
and
as
we're,
seeing
with
like
smi
metrics
as
a
spec,
and
as
we
would
if
we
were
to
open
up
smi
traffic
spec
that
we
would
see
that
those
only
go
so
deep
or
or
they
don't
capture.
A
All
the
the
things
that
that
you,
that
you
would
want
to
if
you're,
going
to
articulate
what
a
5g,
what
one
5g
network
looks
like
and
its
workloads
and
characterizing
its
performance
versus
something
else
and
part
of
the
question
that
we'll
go
to
ask
ourselves
collectively,
is
because
I'm
really
I'm.
For
my
part,
I'm
really
truly
trying
not
to
lead
the
answers
or
lead.
A
The
questions
here
is
how
much
of
interest
is
that
between
the
two
projects,
to
I
think
you
know
to
to
to
reuse
and
to
bring
that
potentially
bring
them
under
one
umbrella
like
is
that?
Is
that
really
helpful,
and
does
I
think
in
general,
like
having
more
people
and
more
eyeballs
and
things
you
know
on
things
is
generally
helpful.
It's
like
there's
more
people
pushing
you
know
rolling
the
boat.
The
same
way
like
pushing
the
yeah
is
that
good?
A
That
was
leading
the
question
by
the
way.
What
I
just
said,
I
guess
I
was
trying
to
be
encouraging
of
like
earnestly
exploring
part
of
that.
Is
you
know
how
much?
How
painful
is
it
to
to
to
to
spend?
You
know
like
right
now
we
meet
you
in
an
smi
community.
You
know
we
meet
once
every
two
weeks
for
30
minutes
and
not
good.
I'm
not.
A
I
think
it
would
take
him
30
minutes
to
present
a
performance
analysis
of
a
given
environment
and
a
of
a
given
workload
and
and
and
that's
fine
okay.
We
meet
more
frequently
or
change
the
charter
or
have
separate
meetings
that
are
more
performance-oriented
versus
functionality-oriented,
which
is
what
smi
is
so
those
yeah
those
are.
D
No
thanks
lee.
It's
a
really
good
point.
I
mean
last
few
months
I've
been
looking
into
various
performance
aspects
of
the
service
mesh
across
the
community.
I've
been
searching,
there's
no
one
specific
way
or
standardized
way
of
representing
aesthetic
apis
representing
things
that
are
results
ready.
I
look
into
istio.
D
They
have
a
certain
way
of
showing
some
of
these
results
looking
down,
why
they
have
certain
way
of
sharing
some
of
these
tests
versus
how
the
their
results
should
be
understood,
right
so
and-
and
what
I
see
here,
either
through
smi
or
smp,
is
to
not
just
a
deployment
or
not
just
a
test
methodology
or
a
common
way
to
understand
some
of
these
results,
and
that
is
heavily
missing.
I
mean,
for
example,
some
of
the
tests
we
have
done.
D
We
have
shared
in
the
service
mesh
con,
that's
happening
tomorrow
between
auto
and
I
we
were
looking
at
inconsistencies
in
traffic
generators,
load,
generators
right
versus
you
know
how
these
metrics
should
be
understood.
Each
each
different
community
has
their
own
way
of
sharing
some
of
these
metrics,
so
standardizing
some
of
this
effort
in
terms
of
a
specification
in
terms
of
examples
right.
D
So
there's
this
gap
as
to
how
it's
some
of
these
things
are
run
versus
this
deployed
versus
understood
right
or
what
software
stack
we
use
and
how
to
configure
some
of
these
things.
There's
that
huge
gap
that
I
I
do
see
and-
and
there
is
an
opportunity
to
kind
of
make
it
uniform
and
standardize
some
of
this
and
with
respect
to
roadmap
what
you're
sharing.
D
I
think
it
would
be
really
good
to
understand
smi's
interest
on
some
of
these,
because
creating
a
spec
with
traffic
metrics,
what
it
is
right
now
versus
encompassing
overall
performance
aspects
across
the
whole
stack
from
hardware
all
the
way
to
your
application.
There
are
many
layers
in
between
right,
so
looking
at
all
of
those
and
figuring
out
how
performance
model
should
be
specified
right,
so
those
that
is
a
conversation
to
have,
and
we've
been
looking
at
different
topologies
different
infrastructure
types
in
different
tests.
D
A
B
Good
and
if
I
can
try
doing
that,
I
mean
I
haven't
worked
a
lot
on
the
traffic
specs
side
of
things
have
been
only
on
the
triometric
side
of
things,
but
I
think
it
I.
I
think
it
allows
you
to
group
a
route
right
essentially
specify
a
route
on
which
you
would
want
to
do
a
specific,
ta,
specific
filtering
or
anything
like
that.
But
but
I'm
really
not
sure
on
the
specific
stuff
here.
A
Now
one
of
the
nice
things
about
the
http
group
or
this
layer
7
protocol
is,
is
that
it
can
get
a
lot
more
detailed
and
yeah.
This
is
this
is
one
of
like
from
an
s
p
perspective,
or
at
least
from
my
perspective,
that
this
is
one
of
those
you
know
nice
areas
of
reuse
or
like
like
when
this
roadmap
was
written.
With
this
statement
here,
enhanced
service
mesh
configuration
model,
the
model
that
smp
has
for
how
a
service
mesh
is
configured.
A
You
know
with
the
integration,
I
think
we
said
with
maybe
too
many
times,
but
with
an
integration
to
smi
or
in
consideration
of
smi.
It's
like
this
is
potentially
a
really
good
example
of,
like
you,
a
lack
of
desire
to
reinvent
the
wheel
part,
but
what
needs
to
be
assessed
assessed
in
some
detail
is
like
what
what
can't
be
expressed
here
or
if
there
is
anything
that
can't
be
expressed
here,
that
one
of
the
service
meshes
might,
but
even
even
then
like.
A
If
the
answer
was
right
now,
you
can't
express
certain
things
in
the
http
route
group
that
traffic
mesh
is
capable
of.
It's
like
well,
okay,
well,
that
doesn't
mean
that
s
p
shouldn't
or
that
we
that
it
wouldn't
be
desired,
that
it
doesn't
use
the
spec.
Rather,
that
just
means
work
can
be
done
to
enhance
the
traffic
spec
and
so.
D
A
What
what
probably
in
a
healthy
way
or
hopefully,
a
nice
way,
what
adds
to
the
consideration
is
that
of
meshery
as
well,
which
is
we
don't
need
to?
I
mean
like
yes,
that
is
another
topic.
It
is
another
point
of
consideration.
There
are
other
maintainers
there
to
have
that
to
reflect
that
basically
like
or
maybe
we
could
hit
it
in
one
fell
swoop
somewhat
quickly,
but
yeah.
It
adds
to
the
thinking.
D
Okay,
so
one
question
for
you
know
towards
the
semi
folks:
who've
been
with
smi
for
a
while.
So
what,
in
terms
of
performance
versus
the
the
reason
behind
creating
traffic
specs,
for
example,
so
I
know
from
what
I
see
there
is
specification
of
what
what
things
should
be
or
could
be
versus
people
contributing
a
set
of
adapters
or
sort
of
crds,
or
you
know,
sdks
towards
the
smi
community.
So
it's
trying
to
understand
the
scope
of
smi
communities.
D
C
I
can
jump
in
the
definitely
want
to
have
implementations.
In
fact,
it's
a,
I
think,
an
implementation
first
approach,
the
spec
comes
later
for
us,
so
it's
like
we've
seeded
the
apis
as
the
current
crds
as
functionality.
That
already
exists
and
is
it's
common
between
implementations
and
then
anything
new
is
really
driven
by
someone
going
and
prototyping
this
thing.
C
So
that's
definitely
the
philosophy
behind
it
in
terms
of
scope,
I'm
not
really
sure
if
we
have
like
a
an
outline
of
what
the
scope
is
necessarily
in
writing,
but
to
me
I
think
it's
really
to
provide
a
common
interface
so
that
so
that
there
could
be
a
unified
ecosystem
around
service
meshes,
so
like
lots
of
tools
being
able
to
use
the
functionality
that
service
mesh
provides
without
actually
having
to
be
implementation.
Specific
anything
in
that
direction,
I
think,
is,
is
the
right
direction.
D
That's
great.
The
reason
I
ask
is
you
know
from
a
performance
standpoint,
because
this
can
be
another
sub
topic
within
an
smi
so
to
focus
on
performance
and
how
it
could
evolve.
So
in
that
sense
there
is
a
scope
for
us
to
kind
of
discuss
and
take
it
further,
because
some
projects
they
just
want
to
expect
to
be
there
and
implementations
can
be.
You
know
your
own
thing
kind
of
thing,
so
it's
good
that
you
know
from
a
scope
perspective,
it's
pretty
pretty
open
for
anything
related
to
service
mesh.
C
B
If
we
can,
we
can
start
it
as
a
separate
doc
right,
separate
thing
and
then
maybe
see
if
there
are.
If
there
are
any,
is
there
any
mutual
thing
with
with
traffic
metrics,
then
we
can
start
seeing
all
of
the
common
parts
and
then
using
stuff
right.
Maybe
maybe
that
could
be
a
better
way
rather
than
starting
starting
from
starting
from
traffic
matrix.
A
E
A
So
the
next,
which
might
be
anyway
well
I'll,
send
you
the
recording,
will
soonku
will
help
characterize
it
a
little
bit.
But
but
the
next
step
here
is
to
grab
a
one-off
time
with
as
many
of
the
smi
folks
as
we
can
get
to
present
s
p
and
all
of
what
it
is
trying
to
consider.
You
know
the
the
world
hunger
that
it's
trying
to
solve
and
and
then
begin
to
hash
through
some
suggestions
on.
A
D
So
in
terms
of
sharing
the
smb
part,
at
least
so
you
know
this
current
smp
details.
Talk
about
you
know
what
can
be
good
or
what's
good
with
the
in
terms
of
performance,
but
I
guess
in
terms
of
implementation,
measuring
comes
in
right,
so
measuring
would
be
the
the
tool
that
we
discussed
here
about
how
you
can
actually
deploy
and
test
and
understand
performance.
So,
if
you're
sharing
about
smb,
you
kind
of
need
a
way
to
say
that
hey
here's,
how
you
deploy
and
and
understand
these
performance
metrics.
A
A
How
do
we,
you
know,
provide
clarity
to
to
to
the
world
and
to
those
that
are
participating
and
looking
at
what
the
projects
are
doing
and
so
so
both
so
to
your
point.
Both
projects
need
to
have
diligence
done
in
this
way
like
to
explore
yeah
I
keep.
I
don't
know
why
I
keep
on
being
so
sensitive.
I
guess
because
I'm
sitting
like
right
in
the
middle
of
a
lot
of
this,
but
it's
yeah
to
explore
whether
or
not
I
think
there's
a
suggestion.
Should
they
all
three
come
together?
A
Should
two
of
them
come
together
should
should
they
all
stay
separate?
How
do
they
reinforce
each
other
and
it's
very
much
so
been
the
the?
For
my
part,
I'll
say
it's
very
much
so
been
the
desire,
and
it's
demonstrated
publicly
time
and
time
again
that
they're
intended
to
be
intertwined,
you
know
minimally
quite
intertwined
and
reinforcing
of
the
other
performance
is
such
a
such
a
tough
thing,
a
big,
long,
deep,
wide
thing
to
produce
and
it's
sensitive
and
it's
it's
tough
to
get
right
and
yeah.
A
That
was
like
one
of
the
first
goals
of
the
mastery
project
was
to
enable
users
like
you.
Let
them
answer
their
own
questions
and
in
a
repeatable
way
and
and
so
you're
right,
like
as
we
go
to
describe
like
it'll
one
it'll
help
as
we
go
to
describe
what
the
spec
itself
is
s
p
it'll
reinforce
an
understanding
of
what
that
spec
is.
A
D
A
Yeah
sounds
good,
fair
enough.
Well,
all
right,
we'll
we'll
do
it
we'll
we'll
ping
every
we'll
send
out
a
doodle
or
something
we'll
find
another
meeting
time.
I
really
appreciate
the
fact
that
michelle
you
helped
get
some
other
folks
on
is
really
nice.
Please
do
everyone
like
that.
I
guess
next
time
we
meet
you'll
be
able
to
digest
what
s
p
is
and
hopefully
a
bit
of
what
mastery
is
as
well,
maybe
to
sunk's
point.
A
You
know,
in
terms
of,
however,
many
meetings
people
want
to
have
and
we
can
also
use
other
forums
or
reuse
forums,
so
the
sig
network
forum
is
going
it's
going
to
get
fairly
packed
shortly,
but
there's
a
it's
a
first
in
first
out
so
there's
time
there
as
a
forum,
the
toc
has
welcomed
this
discussion
on
a
cncf
toc
call
which,
which
is
fantastic.
I
think
that
it'll
be
it'll.
Everyone
will
have
a
hard
time
arguing
publicly.
A
I
could
say
it's
it's
kind
of
a
sensitive
thing,
as
as
people
go
to
digest
and
understand,
not
everyone
will
not
make
a
suggestion
like
I've.
I,
like
I've,
just
made
it
through
this
whole
meeting,
hopefully,
and
not
suggested
that
something
happen.
That
won't
happen
on
a
call
like
that
people
will
suggest.
Okay,
these
two
things
need
to
get
renamed,
and
then
you
do
this
and
you
put
these
together
and
it's
like
well
first
that
would
ideally
come
from
each
of
the
project
maintainers
as
to
what
they
think
is
so.