►
From YouTube: Ambient Mesh WG Meeting 2023 04 05
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
B
Please,
because
I'm
on
another
meeting,
I
can't.
A
So
I
don't
have
slides
I
just
have
a
the
dock
on
GitHub.
For
some
reason,
I
no
longer
can
create
docs
in
the
Community
Drive
I,
don't
know
what
happened,
but
it's
very
difficult
to
publish
if
you
work
at
Google
these
days.
A
So
the
I
wanted
to
discuss
this
issue.
Yeah
I,
don't
want
to
use
my
personal
email.
Sorry
see
I
wanted
to
discuss
this
topic
that
was
brought
up
a
few
weeks
ago,
which
is
essentially
I
want
to.
The
proposal
is
for
ambient
to
use
workload
Discovery
service
to
get
the
metadata
about
the
peers,
and
that
would
be
replacement
for
the
baggage
header
that
was
originally
in
the
Prototype,
and
let
me
so
give
you
some
background.
We,
when
we
populate
metrics
in
istio
for
the
HTTP
request
total.
A
A
So
one
of
the
issues
with
that
approach
is
the
fact
that
we
have
to
send
it
on
every
on
every
Quest
so
that,
for
the
short
connect
request,
the
size
of
the
payload
can
be
significant.
If
you
have
very
short
HTTP
request,
the
overhead
is
a
few
kilobytes
and-
and
we
we
notice
that
people
might
you
know,
observe,
is
increasing
payload
sizes
and
they
don't
really
like
it
because
also
increases
their
Network,
Ingress
and
Ingress
costs,
even
when
they
don't
use
Telemetry
so
that
it's
not
that
we
they.
A
A
A
Otherwise,
you
your
features,
our
features,
degrade
and
that's
problematic,
because
now
for
any
proxy
or
any
SDK
that
wants
to
be
part
of
the
mesh,
not
only
they
have
to
implement
the
the
HTTP
connect
and
mtls,
they
also
have
to
have
to
implement
the
baggage
header,
which
is
a
big
ask
and
because
the
the
as
far
as
I
know,
this
is
not
yet
a
standard.
So
none
of
the
sdks
come
of
it
by
default,
so
that
means
they
have
to
implement
it
in
code
and
that's
a
big
problem
for
many
of
them.
A
At
least.
We
know
that
from
the
grpc
experience,
because
JPC
today,
when
they,
if
you
have
a
JPC
based
mesh,
if
you
want
to
join
the
istio-based
sidecar
mesh,
you
without
telematic
degrades,
partly
because
grpc
doesn't
send
this
header,
and
the
fourth
problem
is
the
fact
that
it's
completely
untrusted,
because
the
the
when
the
source
sends
its
baggage
other,
it
can
say
whatever
it
wants
in
the
baggage,
and
we
will
collect
Elementary
enemy
Telemetry
and
we
never
verify.
A
That
means
it's.
It
can
be
surprising
if
you
are
have
untrusted
sources
on
the
edge
you
can.
Basically,
you
know
they
can
affect
your
Telemetry
in
subtle
ways,
for
example
by
exploding
cardinality
or
by
you
know,
sending
things
that
you
you
know
you
can
be
basically
misguided
and
that's
that's
a
flaw.
A
D
D
Wtc
definition,
but
for.
A
But
we
still
yeah
those
are
Legacy
methods,
let's
go
so
what
I'm?
What
the
proposal
is
about
is
really
so,
instead
of
having
all
those
gear
based
methods
where
the
client
sends
you
stuff
or
the
the
it's,
the
method
is
sprinkled
in
the
standards.
Yes,
we
actually
have
a
dedicated
XDS
for
metadata,
and
so
what
that
means
is
that,
if
you
want
to
retrieve
sure
go
ahead,
connect
up.
B
Yeah,
so
so
quiet,
so
this
XDS
based
Master,
you
are
proposing
a
new
SDS
service
to
get
the
pr
metadata
information.
So
this
is
not
something
existing
right.
This
is,
will
be
a
new
XPS,
so.
A
B
Yeah,
because
you
mentioned
the
grpc
and
a
few
broader
scope,
so
I
think
you
know
for
interoperability.
If
it's
a
part
of
the
Amway
standard,
then
I
guess
it
will.
It
will
improve
the
interoperability
in
service
match.
B
B
A
B
A
B
So
the
metadata
will
be
part
of
the
workload
the
data
workload
Discovery
service,
a
part
of
the
I
mean
eating,
is
part
of
the
response
from
the
workload
Discovery
service
or
it's
a
separate.
A
A
B
And
as
a
lookup
is
through
the
the
key
for
workload,.
A
Right
so
the
lookup
can
happen
in
Envoy
using
metadata
Discovery
service,
because
we
already
have
that
in
MBM,
so
we
can
easily
use
it,
but
it
can
also
happen
in
hotel.
It
can
happen
in
the
you
know.
Other
Hotel
implementations
I
mean
we
have
open
source
Hotel
collector.
That
already
has
it
something
like
this
it
just
doesn't.
It
just
doesn't
work
for
the
both
View
and
destination,
but
it
only
works
for
the
local
resource.
A
A
So
the
the
issue
is
that
it's
a
resource
activated
while
for
istio
we
want
to
both
have
source
and
destination,
not
just
research,
but
sorry
the
the
there's,
not
there's
not
a
single
way
to
do
it
right,
so
the
The
Proposal
is
really
to
make
it
more
extensible
and
the
the
way
to
do
it
to
support
is
to
request
total,
as
it
is
now,
is
to
do
this
processing
in
Envoy
using
wvgs,
but
it
can
also
be
done
in
hotel
using
a
hotel,
collector
processor,
so
that
Android
doesn't
have
to
do
anything.
Okay,.
A
A
A
Then
we
need
to
have
some
kind
of
header
identifying
the
destination
we
just
we
don't
have
this
mode
right.
I
mean
yes,
I
understand
the
workflow
that,
for
example,
you
could
have
thing
where
you
make
requests
to
Zito
and
have
a
header
saying
you
know,
destination
man,
you
know
desired
namespace
and
then
the
key
becomes
partner,
import,
namespace.
A
C
A
D
D
So
I
think
we
discussed
this
in
the
past,
I
mean
it's
it's
some
ways.
The
client
will
need
to
know
the
remote
period
prid
and,
for
example,
you
can
derive
this
information
one
way
or
another.
It
doesn't
matter
how
it
is
faster
into
original,
presenting
Source
address,
AJ
proxy
headers
next
modeling
44
I
mean
we
have
plenty
of
metadata
servers
that
we
discussed
in
the
past,
but
it's
a
core
requirement
for
a
client
to
know
what
this
IP
address
of
the
server
is
talking.
A
C
I,
don't
think
you
necessarily
know
the
Final
Destination
like
when
I
connect
to
google.com
I
just
know
the
event
for
google.com
I.
Don't
know
the
Borg
IP
address
right,
but
I
want
so
like
my
concern
is
if
we
I
agree
that
in
a
normal
deployment
you
do
know
all
the
IP
addresses
actually
that
part's,
fine
but
I
know
there
are
some
folks
that
have
split
brain
control
plans
where
they
only
know
about
their
own
cluster
or
Network,
and
they
kind
of
delegate
the
choice
of
the
actual
pod
IP
later.
C
A
C
Same
level
of
trust,
you
have
the
end-to-end
TLs
from
to
the
actual
back
end,
like
you
trust
the
gateway
to
get
you
to
the
back
end.
But
then
you
verify
the
TLs
certificate
of
the
actual
back
end
right.
A
C
I
mean
I,
guess
like
it
could
give
you
like
the
one
thing
that
we
know
is
the
certificate
right.
That's
the
only
trusted
information
actually,
and
so
you
could
say
hey.
They
said
that
their
IP
address
one
two,
three
four
and
I
looked
at
that
IP
address
and
their
identity
doesn't
match
their
certificate.
So
it's
wrong,
and
then
we
at
least
know
that
they
didn't
lie
about
their
identity.
Part
right.
C
A
So
that
that
all
makes
sense-
and
actually
that's
the
whole
point
of
this
proposal-
is
that
we
have
to
make
it
explicit
what
the
back
end
is
right.
We
need
to
know
at
the
protocol
level
who
you're
talking
to
because
right
now,
it's
implicit
because
we
just
send
baggage
somebody
somewhere
fills
up
the
baggage,
but
you
we
have
to
support
them.
You
know
just
a
regular
key
for
the
destination
workload
regardless
of
telemetry.
D
D
You
use
the
set
of
data
points
you
you
may
use
information
on
certificates,
you
use
baggage,
you
may
use
DNS
reverse
lookups
like
it
has
been
done
for
20
years
when
you
know
analyzing
success
logs
and
you
have
this
extra
tool,
which
is
MDS,
which
is
you
know
already
something
that
we
support
for
around
the
end,
where
you
can
also
get
details
about
the
peer
buys
Peter,
IP
report
name
so
and
and
and
it's
it's
basically
going
to
be
a
you
know,
kind
of
pick,
the
best
information
most
trustworthy
information
from
the
set
that
you
have.
C
C
Don't
know
if
the
server
needs
the
baggage,
though
right
so
I,
don't
know
if
we'd
be
able
to
avoid
that
overhead
right.
D
A
Well,
it
is
not
a
great
issue.
You
shouldn't
be
sending
baggage
to
arbitrary
destinations.
That's
actually
a
big
issue
in
history
is
that
people
complain
that
we're
leaking
cluster
details
outside
of
the
world
I.
Don't
think
it's
a
good
feature
like
if
you,
if
you
don't
know
what
destination
is
you
shouldn't
send
stuff
about
the
cluster?
Well,.
C
If
you're
doing
H1,
then
you
inherently
know
like
I,
could
you
could
still
argue
very
much
that
you
should
be
able
to
connect
to
someone
without
telling
them
more
information
than
just
your
identity?
But
at
least,
if
we're
just
saying
we
only
do
it
on
the
H1
baggage,
like
we
only
send
hmon
to
known
destinations.
So
we
want
to
send
it
to
google.com
at
least
well.
A
C
A
C
B
A
C
A
A
Can
you
can
view
baggage
as
identifying
information?
It's
just
it's
a
civil
kilobyte,
it's
worth
of
obscure
data.
That
comes
with
a
request,
and
that's
that's
the
issue.
Really.
It's
just
it's
fine
to
identify.
I
have
a
limited
information
that
identifies
you,
but
having
all
of
it
sent
always
is
a
problem.
B
A
B
B
A
B
C
C
D
A
There's
a
subtle
issue
of
Delegation,
because
when
Z
Talent
connects
right
now
it
it
presents
certificate,
but
it's
it
has
to
tell
about
the
you
know
exported
four.
So
it's
a
bit
of
a
weird
thing,
because
we
we
trust
export
reform
more
than
the
certificate,
but
I
think
it
can
be
resolved
in
the
future.
A
C
One
thing
I
want
to
understand
so
like
an
Envoy
and
whatnot,
we'll
use
the
workload
XPS
and,
but
you
mentioned
Hotel
collector,
could
augment
this
data,
but
they're
like
processing
thing
after
the
correct
name
is
attribute
processor.
What
does
it
use
like?
Would
it
still
use
the
IP
address,
because
we,
at
least
today,
like
we
don't
like
nowhere
in
the
Telemetry,
is
an
IP
address
right.
A
C
C
Because
if
we
were
to
use
like
I
mean
one
of
the
goals,
was
it's
easier
for
things
to
interrupt?
If
we
don't
adopt
Hotel
fully
and
do
you
know
kind
of
the
custom
Motel
processor,
then
I
think
this
actually
makes
it
harder,
because
I
would
imagine
it's
easier
to
stick
a
header
with
some
information
about
yourself
than
to
connect
to
XDS
right.
A
Well,
I
think
it's
well,
but
you
always
have
to
send
identify
information.
It's
just
right
now
we
raise
it
because
it
it
hurts
cardinality
and
Telemetry.
But
if,
if
we
didn't
care
about
cardinality,
we
just
put
the
Pod
name
as
a
label.
C
Of
I,
mostly
meant
like,
if
you
were
using
just
like
plain
Primitives,
for
example,
not
hotel,
and
you
want
to
join
the
mesh
like
we
said.
One
of
the
goals
was
to
make
it
easier
for
things
to
interoperate
with
the
mesh.
A
C
C
D
So
we're
going
to
put
some
comment
on
the
thread,
but
in
the
XDS
is
what
is
using
and
how
we
configure
and
communicate
information.
But
the
root
of
the
information
is
still
what
the
Pod
Watcher
and
whatever
you
get
from
from
kubernetes
and
any
any
non-esq
non.
Xds
application
can
connect
to
kubernetes
or
use
whatever
protocols,
because
the
source
of
Truth
is
not
XDS.
It's
kubernetes.
C
C
But
you
can
get
some
of
it
yeah,
but
you're
not
going
to
have
necessarily
all
the
information
about
all
IPS
connecting
to
you,
I
mean
even
in
istio.
That's
not
really,
true,
necessarily
that
any
one
control
plane
knows
about
all
these
IP
addresses
right.
I
think
there
was
something
about
like
federating
between
the
control
planes,
but
it
would
be
something
that
needs
to
be
scoped
out
more
I.
Think.
A
A
I
think
that
would
allow
more
options
and
both
implementations
and
protocols,
but-
and
we
can
do
it
if
we
use
this
option
and
then
the
second
point
is
that
we
also
need
to
be
very
explicit
about
how
we
identify
workload.
Just
like
John
mentioned,
we
need
we
needed
to
Define
what
the
service
sends
to
identify
the
destination.
If
it's,
if
it's
behind
the
gateway
and
a
similar
on
the
client,
we
need
to
send
the
x44
onesie
tunnel.
A
So
if
you
do
those
two
things
we
can
so
if
we
use
metadata
Discovery
service
in
ambient
only-
and
we
also
send
the
identify
information
as
headers-
not
just
not
the
whole
package,
I
think
we
can.
We
can
use
this
for
the
initial
ambient
version.
B
C
D
A
You'll
mentioned
that
zetanus
pulls
the
source,
IP
actually
I
think
is
also
not
necessarily
a
good
thing,
because
for
the
we
can't
reuse
the
tunnel
so
either
way.
I
think
we
just
need
to
be
clear
for
that.
What
we
are
going
to
do
in
in
the
first
version,
but
the
key
is
basically
we
need
to
on
the
source.
We
need
to
send
the
actual
Source
IP
and
on
destination.
We
need
to
send
the
actual
destination
AP,
and
we
have
those
two
bits
of
information.
D
Yeah,
by
the
way,
this
whole,
how
do
we
propagate?
Let's
not
forget
that
beside
istio
Telemetry
applications
themselves,
May,
integrate
with
open,
Telemetry
or
other
things
and
present
applications
themselves
may
need
this
kind
of
information
on
Source,
IP,
client,
IP,
so
I
think
we
need
to
to
you
know:
merge
trans
metadata,
information,
PR
or
some
other
mechanisms
too.
Allow
applications
together.
D
A
Yeah
sure
it's
this,
but
you
can,
you
can
use
just
HTTP
xgs
version
yeah.
C
D
You
can
call
this
study
if
some
CNA
providers-
apparently
it's
not
possible.
C
C
D
C
A
A
Right
that
I
think
that,
then
it's
a
separate
problem,
yeah
yeah
I,
think
what
question
is
saying
is
actually
a
different
problem,
because
in
for
weapons
we
use
H
bonds.
So
we
always
know
identity.
A
C
D
A
D
Yeah
I
generally
hates
options,
but
I
think
baggage
I
mean
if
we
can
also
discover
something,
but
I
don't
think
we
are.
We
should
start
remove
baggage
yet
since
tracing
other
things
probably
still
need
baggage,
but
definitely
we
should
implement
this
as
well,
because
it's
it's
I
mean
the
trust
aspect
is
I.
Think
very
important
to
me
at
least.
C
Yeah
one
note
on
the
first
launch
discussion:
the
branch
racer
1.18
is
in
six
phase,
so
there's
probably
not
many
changes
that
we
can
make,
but
we've
also
committed
that
we're
not
stuck
on
compatibility
for
the
initial
launch.
So
we
can
very
well
make
a
very
big
breaking
change
in
seven
days
if
we
want
to
without.
A
D
What
some
some
background
data
point
I've
been
also
talking
with
Brooks
with
a
grpcio
team,
which
also,
you
know
supports,
as
you
know,
XDS
and
and
mesh,
and
they
are
also
looking
at
how
to
to
pass
metadata
and
the
images
baggage.
I,
don't
know
if
that
I
mean
probably
we
need
to
discuss
with
with
them
if
the
same
method
Discovery
services
acceptable
to
them
or
if
they
want
to
adopt
it.
A
A
B
C
A
A
C
A
A
A
C
C
No,
it
does
not.
We
have
the
users,
the
user
opens
a
connection
for
each
connection.
They
open,
we
open
a
HTTP,
do
stream,
it's
one-to-one
mapping
and
it's
driven
by
the
the
user.
It
may
be
a
bit
different
in
the
Waypoint
case,
actually,
because
the
waypoint's
doing
its
own
HTTP
connection,
pooling
and
load
balancing,
so
I
think
that's
a
bit
different,
but
for
Z
tunnel,
it's
strictly
driven
by
the
client,
which
is
the
application
that
we
don't
touch
right.
C
A
All
right,
if
not,
then
let's
call
it
good
for
today.