►
From YouTube: Ambient Mesh WG Meeting 2023 03 15
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
So
I
added
this
kind
of
aspirationally,
hoping
that
I
would
finish.
Writing
the
doc
before
the
meeting
which
shouldn't
happen.
So
we
more
have
my
notes
about
the
documented
right,
but
since
we
had
nothing
else
on
the
agenda,
I
figured
I'd,
keep
it
here
and
get
some
early
feedback.
B
B
That
was
not
the
most
thoroughly
designed
API
I
was
mostly
stick
what
we
needed
and
then
we'll
evolve
it
because
we
haven't
launched
yet
right,
so
that
was
never
really
intended
to
be
the
final
API,
just
the
API
we
had
at
the
time.
So
since
then,
we've
discovered
quite
a
few
gaps
in
it.
I
tried
to
identify
what
those
are
here.
B
My
main
goal
of
this
meeting
really
is
to
make
sure
that
these
actually
address
all
the
cases
that
we've
we've
run
into
so
I
would
love
feedback
on
other
things
that
are
kind
of
missing
in
the
API
that
we
need
to
consider,
and
then
the
intent
after
once
this
is
ready,
is
to
have
kind
of
the
next
revision
of
the
API
I
doubt
it
will
be
the
final
revision,
so
we're
probably
not
locked
in
yet,
but
you
know,
hopefully
I'll
at
least
try
this
over
for
a
few
months
before
we
need
to
make
some
some
big
revisions
again.
B
If
at
all,
so
the
general
idea,
let
me
go
over
the
gaps,
so
one
Gap
today
is
we.
We
don't
have
a
service
representation.
We
actually
have
each
workload.
Just
has
a
list
of
service
IP
addresses
that
they're
a
part
of,
and
then
we
kind
of
aggregate
those
together
to
form
like
this
service
definition
that.
B
Hard
to
implement
things
on
service,
so,
for
example,
there's
like
session
Affinity
as
part
of
service.
We
don't
really
have
a
way
to
attach
that
unless
we
inline
it
into
every
workload
which
is
kind
of
weird.
B
Also,
let
me
I
guess
put
this
down
here:
I'm
along
the
same
lines
in
our
metrics
there's
a
few
keys
or
labels
that
are
related
to
service.
They
have
like
the
service
name
and
namespace
today.
Those
are
the
only
fields
that
we
don't
support
in
the
metrics
reporting,
because
we
don't
know
about
you
know.
If
we
don't,
we
don't
know
about
any
of
the
service
info.
We
just
have
the
IP
address,
which
it's
asking
for
the
name,
not
the
IP
address.
B
Some
other
issues
with
service
is
that
service
can
actually
have
endpoints
in
it
that
aren't
pods,
but
because
we
look
at
pods
and
then
kind
of
reverse
and
engineer
the
service
we
just
ignore
those
entirely.
So
if
you
add
some
endpoints
to
a
service,
those
will
never
be
selected
by
z-tunnel
kind
of.
Similarly,
the
Readiness
logic
is
not
exactly
accurate,
like
we
try
to
recreate
the
Readiness
logic
of
service,
but
it's
not
I,
don't
know
all
the
gaps.
I
know
at
least
one
that
there's
this
published
and
already
addresses
in
service.
B
B
Well,
we
have
a
list
of
Waypoint
IP
addresses,
that's
like
the
actual
pod
IP
of
the
waypoints,
so
I
do
have
some
concerns
that
scaling
up
and
down
waypoints,
where
you
set
up
maintenance
need
to
push
out
a
lot
of
information
of
all
the
workloads
that
are
selected
by
those
and
then
there's
more
like
next
hops
than
just
a
waypoint.
For
example,
on
cross-network
traffic
we
may
need
to
Traverse
an
East-West
gateway
to
reach
it,
not
just
a
waypoint.
B
We
don't
currently
represent
that
at
all.
So
right
now,
just
focusing
on
the
gaps.
I
have
some
proposals
below
obviously
but
I
wanted
to
get
feedback
on
this
see
if
there's
things
missing,
these
aren't
real
problems.
Whatever.
D
Yeah,
hey
John,
a
couple
of
thoughts
that
come
to
mind
as
I've
spent
time
over
the
last
few
weeks,
diving
into
the
workloads
apis.
D
B
Yeah
so
I
think
that
is
a
valid
concern.
One
thing
on
the
terminology
not
to
nitpick,
but
just
so
we're
on
the
same
page,
so
in
istio
different
clusters
may
be
on
the
same
network
like
the
the
boundary
is
really
the
network.
Not
the
cluster
network
is
kind
of
the
IP
space
boundary
and
then
you
still
at
least
in
our
data
terminology,
yeah
yeah.
D
B
Problem
so
I
totally
agree.
I
I
definitely
agree.
That's
a
gap.
I
have
some
ideas
on
how
we
can
solve
that
I.
Don't
think
it's
too
far
off
which
we
can
get
into
if
we
want,
but
definitely
valid
thanks
for
pointing
that
out.
D
Another
area
of
the
of
the
API
too
again
I'm
still
new
to
this
coming
up
to
speed,
but
you
know
the
gateway
address,
try
to
understand.
Looking
at
the
code,
it
looks
like
the
gateway
address
gets
set,
but
it's
not.
When
you
look
at
the
configuration
of
a
z
kennel,
you
don't
see
it
set
and
there's
her
Queen
kind
of
dis
and
disambiguate
or
better
understand
what
that
gateway
address.
Is
you
know,
obviously
the
Waypoint
addresses
to
me.
B
Yeah,
so
that
gateway
address
actually
isn't
in
the
workload
API
that
served
over
XDS.
That's
the
in-memory
representation,
which
is
mostly
just
a
weird
Legacy
hangover
from
POC.
We
did
like
two
years
ago
when
that
was
how
we
first
implemented
it.
So
I
I
agree
like
the
general
idea
was
that
it
was
supposed
to
be
the
kind
of
next
hop
or
like
how
you
reach
it,
which
could
be
a
waypoint,
but
it
could
also
be
an
East-West
Gateway,
for
example,
or
maybe
in
the
future.
B
If
we
represent
something
like
google.com,
it
could
be
an
egress
Gateway,
that's
a
bit
hand
wavy
on
that.
For
sure
we
haven't
thought
about
egress
that
much,
but
that's
younger
the
idea,
but
that's
kind
of
to
some
extent
separate
from
the
XDS
API.
Although
I
think,
given
that,
like
this
one
that
we
need
to
represent
the
East-West
Gateway,
that
may
be
the
API
we
end
up
with
anyways
and
then
remove
Waypoint
addresses
and
make
it
more
generic.
D
D
It
it
is,
it
was
like
what
Waypoint
addresses
and
gateway
address.
It
seems
to
me
like
if
a
waypoint
address
is
defined.
That's
essentially
the
the
the
next
hop
for
the
destination
of
that
workload.
Ip
right,
so
maybe
it
just
makes
sense
to
have
gateway,
address,
addresses
being
plural
and
then,
if
it's,
if
it's
a
waypoint
or
an
East-West,
Gateway
or
whatever
it
might
be,
that
becomes
the
destination
or
next
top
for
the
destination.
Workflow.Com.
B
Yep
definitely
I
think
I.
Don't
think
that
there's
a
case
where
you
need
to
know
the
Waypoint
and
the
East
West
Gateway
I,
believe
we
can
consolidate
to
one
field,
have
to
think
about
it
more,
but
that
seems
plausible
any
other.
Any
other
gaps.
E
No,
not
a
gap
but
just
kind
of
curious.
What
your
thoughts
were
with
respect
to
handling
endpoints
for
service.
Like
did
you
want
to
kind
of
separate
it
and
chunk
it
kind
of
like
they
did
with
endpoint
slice
or
you
thinking
about
just
having
it
one
monolithic
structure.
B
Yeah
so
I,
let
me
I
guess
go
into
the
proposal
and
it
should
answer
that
question
pretty
quickly.
This
is
not
flushed
out.
I
I
will
update
it
with
like
a
proper
Proto
with
a
diff
of
what
we
have,
but
the
general
idea
is,
we
would
add
a
new
type.
That's
a
service,
and
this
service
would
basically
today
contain
just
like
the
name,
namespace
and
host
name
of
the
service.
So
we
can
fulfill
the
metrics
requirement
in
the
future.
B
It
would
also
have
things
like
you
know
whether
this
is
cross
mesh
or
cluster
local
or
a
session
Affinity
or
not
or
whatever
settings.
We
need
to
do
to
fill
this
full
service
API
requirement,
since
we
don't
actually
have
multiples
in
Z10,
though
it
probably
deferred,
and
we
can
continue
adding
Fields
as
we
need
to
you
know,
get
through
all
the
aspects.
B
You
can
put
this
in
a
different
order.
I
think
that
it
makes
sense
to
have
a.
Let
me
actually
I
do
have
a
photo
here.
Let
me
just
copy
it
in
real,
quick.
B
A
top
level
message
I
call
address
here,
but
we
can
obviously
bike
shed
the
name
that
kind
of
Aggregates,
both
workloads
and
services.
The
reason
I
think
this
is
useful
is
for.
Oh
sorry,
can
you
scroll
down
to
this
code
block
thanks,
yeah.
The
reason
I
think
this
is
useful?
Is
it
allows
us
to
have
a
way
to
for
Z10
to
say
I
got
this
IP
address
now?
What
is
it
and
send
a
request
for
to
the
control,
plane
and
kind
of
do
on-demand
routing?
B
So
if
we
had
the
separate
XDS
resources
for
service
and
workload
that
are
subscribed
to
directly
we'd
have
to
kind
of
do
a
weird,
like
request
for
this
IP
as
a
workload
and
as
a
service
and
then
kind
of
like
race
them,
I,
guess
and
see
which
one
wins
which
could
be
done,
but
it's
kind
of
awkward,
so
having
just
a
single
type.
That
kind
of
is
a
one
of
each
of
them.
B
I
think
may
be
useful,
but
we
could
also
allow
like
we
could
have
used
to
de-exposed
address
as
kind
of
an
aggregated
type
and
then
workload
and
service.
If
something
only
cares
about
workloads,
for
example,
I,
don't
know
well
like
we'd,
have
to
think
through
the
use
cases,
but
just
the
idea
there
and
then
so
on
service.
B
If
you
scroll
down
a
bit,
ignore
the
route
for
now
that
one's
less
on
service,
we
have,
you
know
just
like
I
mentioned
name
namespace
hostname
address
ports,
nothing
to
controversial
there
I
think
we'll
extend
it.
Obviously,
with
some
Fields
later,
as
I
mentioned.
B
Does
this
make
sense
so
far?
I
don't
want
to
talk
for
30
minutes
if
no
one's
following.
B
Okay,
cool,
if
you
can
scroll
back
up
sorry.
E
For
terminology,
so
you
know,
workload
historically
just
means
just
a
binary
right
running
somewhere,
I
I,
wonder
if,
if
from
the
perspective
of
the
client,
if
endpoint
makes
more
sense,
I'm
not
I'm,
not
sure
the
the
distinction
between
endpoint
and
workload.
B
We
I
mean
it
might
like
naming's
hard.
Obviously,
the
one
thing
that
may
be
confusing
is
in
kubernetes
and
endpoint
is
the
joining
of
a
service
and
a
workload
like
that
forms
an
endpoint,
but
you
could
have
a
workload
without
a
service
at
all.
Right
like
we
could
call
it
endpoint.
It
may
make
sense
in
other
contexts
if
you're
purely
coming
from
kubernetes
Context.
It
may
be
confusing
in
that
regard,
like
that's
what
we
call
a
service
instance
in
the
internal
pilot
model,.
B
I,
don't
like
I
I.
Definitely,
don't
think
that
these
are
necessarily
the
ideal
names
just
that
may
be
a
concern,
but
then
points
I'm.
A
B
Happy
to
have
better
knee
ending
suggestions
on
here,
I
I'm,
not
a
Namer,
so
to
answer
kind
of
Nate's
initial
question,
though
so
I
think
for
workloads.
We
would
keep
it
largely
the
same
as
we
do
today.
Oh
I
guess
one
Gap
I
forgot
workloads
are
only
based
on
pods.
B
We
don't
actually
do
any
like
workload,
entry
service
entry,
anything
like
that,
so
we
kind
of
have
no
VM
support,
which
was
just
largely
an
implementation
limitation.
That
was
never
you
know
intentional
plan
or
anything
so
for
workloads,
though
you
know,
we
would
look
at
all
of
these
sources
for
workloads.
We
have
that's
pods,
workflow
entries
and
actually
endpoints
themselves
and
we'd
kind
of
do
a
join
across
those
by
IP
address.
B
So
if
we
have
a
pod
or
workload
entry
by
that
IP
address,
we'd,
obviously
take
that
information
and
populate
all
the
fields
of
workload.
So
that's
you
know
the
name,
namespace
trust
domain,
all
the
good
stuff,
that's
what
we
already
do,
except
for
work
that
it
would
be
new.
B
Of
course,
the
kind
of
newer
thing
would
be
that
we
also
look
at
endpoints,
which
could
be
from
endpoints
endpoint,
slices
or
kind
of
our
synthesized
endpoints
by
joining
service
and
workload,
entry
or
service
entry
and
pods,
which
don't
exist
in
endpoints
in
the
API
server,
but
they're
kind
of
logically
equivalent,
and
you
still
and
then
also
join
those
with
IP
address.
So
if
the
IPA
is
already
a
pod
or
workload
which
is
kind
of
the
normal
case,
then
we
would
use
that
to
add
the
dips
field
to
the
workloads.
B
So
this
handles
the
case
where
service
Readiness
is
not
properly
respected.
So,
instead
of
trying
to
recreate
that
kind
of
service
like
in
pod
logic
in
the
workload
XDS,
we
would
we
wouldn't
do
that
at
all.
We'd,
actually
look
at
the
endpoints
and
say:
okay,
here's
an
endpoint
for
this
service
It's
associated
with
this
pod,
and
then
we
can
do
the
join
there.
B
That
way,
we
don't
have
to
be
in
the
business
of
dealing
with
like
the
Readiness
Logic
for
okay
is
this
pod
and
the
service
actually
Associated
together,
which
is
more
complicated
than
just
the
label,
selects
the
pod,
so
that
will
give
roughly
the
same
behavior
in
most
cases,
but
if
there's
edge
cases
that
you
know
like
that,
we
would
published
not
ready
again
addresses
or
whatnot.
We
would
still
get
the
nips
properly.
B
The
other
thing
that's
kind
of
interesting
is
that
we
may
have
endpoints
where
we
don't
have
pods
I.
Don't
feel
amazing
about
this,
but
my
current
proposal
is
that
we
would
still
create
a
workload
and
it
would
just
be
missing
a
lot
of
information.
So
in
the
endpoint
we
get
some
info
like
we
definitely
have
namespace
an
IP
address.
B
That
might
be
be
it
I
mean
I
have
to
go
through
the
whole
thing,
but
we
want
to
have
service
count.
We
want
to
have
names,
workload,
names,
workload
version,
so
it'd
be
a
very
Bare
Bones
workload.
It
would
always
be
TCP,
of
course,
because
we
don't
know
if
it
Sports
H1
or
not.
So
we
have
these
very.
Like
minimal
representations
of
these
workloads
that
have
been
synthetically
added
to
endpoints
by
the
user,
so
I
forget
what
your
original
question
was
Nate,
but
I
I
thought
this
would
answer
it.
B
So
let
me
know
if
it
if
it
didn't
or
if
this
makes
sense,
I.
E
Forgot
what
it
was
too,
but
this
is
great
okay.
B
B
So,
in
a
in
a
endpoint
today,
or
usually
it's
endpoint
slices
because,
like
you,
can
manually,
configure
the
endpoints
right
and
put
IP
addresses
there
that
aren't
pods.
So
if
someone
has
a
service,
we
should
still
be
sending
traffic
to
those
endpoints,
otherwise,
like
we'll
be
giving
different
routing
Behavior.
But
we
don't
know
much
about
those
endpoints
like
we
effectively
just
know
the
namespace
and
the
IP
address
and
what
whatever
else
is
in
endpoints,
which
is
not
very
much
info
right.
B
Yeah,
so
if
a
user
is
sent
directly
to
those
IP
addresses
like
there
would
be
no
different
routing
information
because
we
don't
have,
we
would
never
upgrade
to
H
phone,
because
we
don't
have
enough
info
to
know
if
it's
H1
or
not,
and
we
have
basically
no
additional
metadata
for
Telemetry.
The
difference
would
be
if
they
access
the
service.
We
would
actually
still
we
would
start
sending
traffic
to
those
when
previously
they're
just
ignored
entirely.
C
B
Okay,
I
think
the
last
thing
well
one
we
talked
about
a
bit
about
this
before,
but
it
probably
makes
sense
to
replace
Waypoint
addresses
with
something
like
more
generic,
like
Gateway
or
next
top
or
whatever.
We
want
to
call
it
that's
kind
of
more
generic
than
you
know.
Just
Waypoint
I,
don't
know
we
can
bike,
show
the
meaning,
but
something
along
those
lines.
That's
more
generic
and
I
think
it
also
makes
sense
to
replace
the
list
of
ips
with
a
bit
that
way.
B
We
don't
have
to
change
it
every
time
you
know
Waypoint
scales
up
or
down,
we
just
have
a
stable
dip
and
you
know,
as
it
goes
up
and
down
it's
no
problem
now
the
Z
tunnel,
wouldn't
literally
send
it
to
that
dip.
It
would
be
smart
enough
to
look
at
the
dip
and
you
know,
say:
okay,
here's
this
VIP
I
also
know
this.
Vip
is
actually
the
Waypoint
service
that
Waypoint
service.
B
Has
these
workloads
Associated
so
I'm
going
to
load
balance
across
those
workloads
which
I
think
when
I
describe
that
it
sounded
complicated,
but
it's
pretty
simple
in
the
actual
implementation,
and
so
it's
basically
just
like
a
key
into
the
service
which
has
a
list
of
workloads
rather
than
sending
the
whole
list
there.
B
B
F
B
Yes,
that
is
through
today,
there
is
a
APR
that
adds
the
service
already.
Okay,.
F
F
The
Key
by
IP
address
has
becoming
a
problem
for
some
of
the
scenarios,
particularly
as
you're
looking
into
Beyond
one
single
cluster
on
different
network
right,
you
could
have.
Maybe
some
of
the
workloads
are
represented
as
the
same
IP
address.
So
that
definitely
is
an
important
scenario
for
us
and
then
I
have
a
general
question
about
this
XDS
Evolution,
you
are.
Are
you
proposing
the
change
for
zetano,
or
are
you
also
proposing
some
of
these
workload
XDS
impacting
Waypoint
as
well.
B
Yeah
so
today
the
z-tunnel
obviously
exclusively
uses
this
API
for
configuration.
There's
been
some
work.
Let
me
send
a
link
on
the
talk
of
using
the
workload
API
for
getting
metadata
for
Telemetry
instead
of
doing
metadata,
Exchange,
which
this
would
be
all
of
this,
would
not
make
that
worse.
I
think
that's
still
a
bit
under
discussion
in
general,
I
think,
but
I
think
that
usage
would
be
compatible
in
the
distant
future.
Potentially,
we
could
use
this
API
for
routing
in
the
Waypoint
as
well.
B
B
F
B
F
B
Yeah,
so
I
I
have
some
ideas
for
how
we
solve
that
I'll,
try
and
explain
it
here,
but
I
don't
think
I'm
going
to
represent
it
well,
because
I
haven't
really
thought
through
how
to
explain
it.
B
B
So
the
only
thing
we
could
key
on
for
that
is
the
IP
address.
However,
we
know
that
when
a
z
tunnel
gets
a
request
from
an
outbound
request,
it's
going
to
the
same
network
right
we're
not
expecting
to
see.
You
know
if
a
pod
says
curl
one,
two,
three:
four:
that
by
definition
is
one
two,
three
four
in
my
own
network.
B
So
what
I
was
thinking
was
that
in
exos
you
can
actually
have
aliases
for
a
type,
so
full
key
would
be
Network,
slash,
IP,
and
then
we
would
allow
Z
tunnel
to
also
query
just
by
the
IP,
which
implicitly
means
the
same
network.
Actually
now
that
I'm
typing
this
out,
there's
actually
no
need
for
that.
The
Z
panel
can
always
just
request
its
own
network
name.
So
maybe
this
is
all
too
complicated
and
we
just
make
the
key.
F
F
F
B
B
That's
what
you're
saying
like
let's
say
we
have
a
I'd
say
we
have
the
East
West
Gateway.
The
IP
address
is
two
three
four
five
right
and
it's
in
network
a
and
the
workload
has
this
IP
address,
I.
Think
what
you're
saying
is
that
you
want
to
represent
all
these
workloads
in
this
remote
Network
as
having
the
IP
address
of
the
Gateway,
because.
B
F
But
it
was
the
with
the
isolated
control
plane
right,
you
don't
you
don't
know
the
actual
IP
on
the
remote
clusters
pause
right
with
the
isolated.
So
you
only
know
the
the
Gateway
East
West
Gateway
IP
yeah.
B
F
Probably
you
need
that
to
do
like
yeah
validation.
Yes,.
F
B
Yeah
so
I
think
this
is
a
case
that
we
should
consider
so
I'll
get
the
cops
in
next.
In
case
you
have
a
better
suggestion,
but
I
think
representing
it.
As
the
IP
address
is
the
Gateway.
It's
probably
not
how
we
want
to
represent
it
and
instead
it's
more.
The
IP
address
is
unknown
and
this
is
the
Gateway.
But
then
we
have
this
issue
where
we
don't
actually
have
a
key
yeah
now,
so
we
probably
need
a
new
key
format
for
like
unknown
IP
or
something
I'll.
B
H
G
Yeah
I
mean
I
was
thinking
that,
like
pod
itself
or
the
workload
entry,
the
service
entry,
every
resource
that
gets
written.cd
has
a
uid
so
that
assures
globally
unique.
It
might
be
Overkill.
My
my
primary
thought
was
to
your
first
point,
John
about
the.
G
If
we
had
a
missing
IP,
how
do
we
handle
the
keying
and
my
thought
would
be
to
kind
of
delineate
all
workloads
that
we
know
about
basically
like
workloads
we
can
send
to
from
ones
that
we
can
receive
from
right
because,
like
IPS
are
even
in
the
question
mark
IP,
that's
never
going
to
be
our
source
IP
right.
So
it's
only
a
valid
destination
yeah,
so
you
can
still
look
up
from
IP.
G
B
Do
something
like
like
this
is
the
workload
a
known
IP
address
when
the
IP
address
is
unknown.
The
key
is
not
the
IP,
it's
actually
uid
Plus
network
uid
could
come
from
workhood
or
something
the
actual
key
doesn't
really
matter
that,
because
on
this
case
we
would
never
be
looking
these
up
like
we're.
Never
getting
a
requests
with
this
unknown
IP.
Obviously,
because
we
don't
know
what
the
IP
is,
so
we
never
have
to
do
on-demand,
lookups
right.
This
would
always
be
something
that's
pushed
by
the
control
plane.
B
So
what
the
key
is
doesn't
actually
matter.
It
seems
to
be
static
so
that
we
can
correlate
them
between
requests
right,
so
I
think
uid
would
would
work
fine
there
or
any
really
any
anything.
That's
just
stable
and
unique.
It's
sufficient
and
I
do
like
the
point
on
source
workloads
and
destination.
Workloads.
B
I,
don't
know
if
those
is,
if
that's
like
something,
we
would
treat
differently
in
the
actual
API
itself
or
just
like.
Let
no
nips
are
kind
of
destination.
Only
I
have
to
think
that
through
a
bit.
H
Did
you,
okay,
yeah
I,
think
I'm
back,
so
my
what
I
was
meant
to
say
is
that
a
plot?
The
name
is
probably
the
right
approach
here.
It
also
works
with
with
multiple
networks
and
and
mostly
satisfies
most
of
the
requirements
keep
in
mind.
We
also
may
have
the
use
case
of
transitions,
so
we
need
some
way
to
to
represent
the
basically
support.
H
We
cannot
just
put
multiple
ports
behind
a
single
IP.
We
need
some
way
to
identify.
Guid
is
pretty
ugly
and
and
not
intuitive,
and
you
know
why
would
you
use
a
new
uuid
when,
when
you
have
a
host
name-
and
you
can
also
represent
the
namespace
cluster
and
have
full
you
know,
fqdn-
that
that
makes
sense
and
can
be
used
in
other
places?
H
I
think
it's
it's
a
very
important
use
case
and,
and
it
will
be
wonderful
if,
if
you
know
the
discovery
system
and
everything
would
have
dual
mode
where
you
can
use
either
host
claims,
which
are
would
be
the
fully
qualified
domain
name
with
what
I
DNA
space
and
some
some
cluster
specific
extension
or
their
IPs
without
first
using
any
multi-network
situation,
because
because
IPS
will
no
longer
be
unique
yeah.
That
was
my
my
point.
Sorry
for
the
audio.
B
Does
anyone
see
a
need
for
their
gateways,
which
now
means
waypoints
or
East-West
gateways
to
be
DNS
names,
or
do
we
only
care
about
sporting
IP
addresses,
because
one
box
need
a
different
schema?
If
we
we
want
DNS
names
well,.
H
B
B
I
mean
really:
that's,
not
amazing,
I'm,
not
no
offense
to
you
at
all,
Stephen
like
that's
the
best
we
could
do.
But
given
this
is
z
tunnel,
we
can
easily
make
it
if
we
wanted
to
support
that.
We
could
make
detail
and
do
the
DNS
right,
it's
easier
to
add
that
extensibility
and
then
an
Envoy.
H
B
H
H
Yes,
but
that
way
I
mean
yeah,
they
have
different
degrees
of
integration
and
different
ways
to
integrate
I
mean
all
of
them
will
be
useful.
I
think
we
can
make
it
work
with
either
if
we
have
all
of
them.
It's
wonderful,
of
course,
but
we
need
to
put
host
names
more
into
into
the
product
that
my
the
general
point,
because
Sni
is
very
important
in
any
multi-tenancy.
You
know
we
cannot
assume
anyone
can
get
an
IP
address.
Ipv4
address
really
anytime.
They
want
for
free.
B
One
thing
that's
tricky:
if
you're
doing
like,
let's
say
you
have
Cloud
run,
you
have
a
hostname
for
it,
not
an
IP
address
and
it's
part
of
a
service.
You
call
the
service
and
then
we
send
to
the
quadrant
that
works
fine.
But
if
a
user
directly
sends
to
the
workload
like
a
cloud
run
service,
we
won't
be
able
to
match
it
right,
because
we
only
see
the
IP
address.
H
Yeah,
that's,
it
can
be
addressed,
I
mean
it
does
not
take
Cloud
around
as
an
example.
But
but
there
are
many
cases
where
you
know:
sni-based
routing
can
be
used
or
the
Gateway
can
terminate.
And
do
you
know,
presentation.
H
Because
we
may
need
to
put
Support
also
in
the
in
order
to
to
have
a
more
secure
best
sensation
model
with
ipip
can
be
reallocated,
and
it's
very
complicated
to
have
a
cookies
that
include
the
IP
that
make
soon
be
replaced.
But
both
names
are
a
bit
more
persistent.
B
Okay,
I
I
think
that
in
the
short
term,
we
probably
for
a
workload
not
being
IP
based.
We
may
need
to
think
through
that
a
bit
more
like
I,
see
the
use
case.
I'm,
just
not
sure
how
we'd
represent
it.
B
I
think
allowing
DNS
names
in
the
gateway
address
is
pretty
easy
to
do
now,
though,
so
I
to
be
perfectly
behind
implementing
that
we
I
don't
know
how
hard
it
will
be
to
do
DNS
and
Z
tunnel,
hopefully
not
so
hard,
but
we
can
always
delay
the
implementation
anyways
and
update
the
API
to
be
future
proof.
If
we,
if
we
need.
B
G
Yeah
I
was
wondering,
maybe
just
remind
me,
real
quick
at
it.
Why
did
we
want
to
represent
VIP
as
like,
unknown
and
use
a
Gateway
like?
Is
there?
Was
there
a
use
case
where
we
might
want
to
hit
a
waypoint
before
going
remote
right
like
there
was
an
idea
earlier
to
reuse
the
gate?
The
Waypoint,
like
turn,
that
Waypoint
addresses
into
like
a
gateways
and
I
guess
I
was
wondering
if
it
makes
sense
to
leave
that
as
waypoints
right.
If
it's
in
another
Network,
we
know
that
the
IP
probably
is
nonsense.
G
Oops
I
didn't
mean
to
raise
my
hand
again,
oh
if
it
was
back
to
like
if
it
was
the
East
West
Gateway
like
if,
if
you
had
a
lot
of
ips
just
in
different
networks
or
they
were
duplicated
yeah,
but
you
knowing
that
it's
in
another
Network.
Do
you
know
that
that
IP
is
not
actually
reachable
in
your
network.
B
That's
yeah.
If
this
was
let
me,
let
me
copy
this,
so
I,
don't
mingle
this
one.
If
we
had
this
config
I
actually
had
that
about.
This
is
actually
useful.
Both
IPS
are
useful
because
we
can
request,
even
though
this
IP
is
on
a
different
network.
We
could
request
this
through
the
East-West
Gateway
at
this
IP
address
and
say:
I
want
this
specific
IP
address
on
the
other
network.
This
could
be
useful
for,
like
stateful
sets,
for
example,
right
where
I
want
to
access
a
specific
instance
of
a
workload
on
another
Network.
B
B
So
obviously
you
can't
do
that,
but
for
the
general
purpose,
even
the
standard,
istio
multi-network,
we
actually
do
know
the
IPS
there,
so
they
can
be
used.
Okay,
so
that
makes
sense
Kevin.
Whoever.
B
Yeah
yeah
so
I
think
if
you
have
the
IPS
like
it's
useful
to
be
there,
and
it's
also
useful
to
know
I
think
that
we
don't
know
the
ipe,
because
then
in
the
age
phone
request,
we
need
to
request
something
right,
and
we
talked
about
in
that
multi-network
one
for
the
case.
When
we
don't
have
its,
we
would
instead
put
like
the
hostname.
B
So
like,
if
we
don't
we
that
would
allow
it
to
say
like
okay,
if
we
don't
know
the
IP
put
the
hostname
instead,
otherwise
we
wouldn't
really
know
like.
If
we
had
the
I
guess,
we
could
say
like
Gateway
IP
equals
IP
then
do
that
or
something
it's
just
a
little
funky,
so
I
yeah
I
would
need
to
definitely
need
to
like
scope
this
out
more
concretely,
but
I
think
this
is
kind
of
closing
in
most
of
the
gaps.
B
I
hope
like
I
said
this
is
like
very
much
rough
draft,
so
I
plan
to
put
this
together
a
lot
more
thoroughly
and
we'll
obviously
have
folks
review
it
again.
Take
some
time
to
try
to
digest
this
and
whatnot.
F
Yeah,
that
sounds
good,
so
what
custom
was
suggesting
earlier,
I
think
it
was
part
name.
So
how
would
I
work
for
the
parts
that
are
running
on
the
remote
cluster,
where
you
don't
necessarily
know
the
name
of
the
part.
B
H
Yeah
sounds
good,
which
is
how
browsers
typically
work
I
mean
if
you
you
can.
If
you
connect
to
google.com,
you
use
google.com,
that's
kind
of
the
host
name,
it's
a
service
or
a
cluster
given
kubernetes.
But
if
you
want
to
talk
specifically
to
a
pod
because
you
have
a
question
session
or
you
have
stay
positive
or
whatever,
then
you
need
to
know
either
the
hostname
or
the
IP
address.
You
cannot
talk
with
someone.
If
you
don't
know
the
address.
A
H
To
confirm:
are
we
planning
to
implement
this
with
the
current
East-West
sni-based
gateway
to
mangling?
What
are
we
planning
to
implement
it
as
Z
tunnel,
like
our
employee,
using
H1,
no.
B
This
is
the
double
H1
discussion.
I
B
B
Put
all
this
will
be
implemented,
but
the
multi-network
aspects
of
like
doing
the
Double
H
Bond,
sending
to
the
east
west
Gateway
I
at
least
I.
Don't
personally
plan
to
implement
that
right.
We
kind
of
said:
here's
the
here's,
how
we're
going
to
do
it
we'll
do
the
Double
H
bone
and
you
know
XYZ,
but
you
know
we'll
defer
that
until
it's
a
priority
but.
B
F
Can
you
have
Waypoint
support
and
the
East
West
Gateway
does
not
I
guess
it
was
a
Gateway
with
also
have
super
Edge,
but
with
double
edge
bone
so.
B
B
Yeah,
so
I
I
think
yeah,
we'll
need
more
than
just
address.
We'll
definitely
probably
make
it
a
message
that
we
can
extend
with
more
fields
in
the
future
as
we
need
and
have
IP
probably
pour
it
today.
We
assume
it's
15
0008,
but
we'll
probably
want
to
allow
other
courts.
I.
Think
it's
useful
for
East
West
Gateway,
actually
like
the
default,
would
probably
not
even
be
fifteen
thousand
eight
resource
Gateway,
since
we
already
have
the
port
exposed
the
15
4431
or
whatever.
D
Yeah
I
just
want
to
go
back
to
a
point
that
you
were
making
earlier
about
using
a
service
to
front
end
the
Waypoint
no
longer
using
the
Waypoint
pod
IPS.
So
in
that
case
we
could
represent
multiple
Waypoint
pods
using
a
service,
and
then
each
of
those
Waypoint
pods
would
have
a
workload
entry
and
then
there
would
be
a
a
service
entry.
D
D
H
That's
how
we
use
I
think
the
normal
way
to
represent
services
to
a
service
entry
workload
entries
for
individual
I
mean
they
do
the
same
thing,
but
conceptually
they
are,
you
know
you
can
entrepreneur.
The
service
normally
use
I
would
use
seven
percent.
D
No
I'm
just
trying
to
think
so
Z
tunnel
needs
afford
to
to
a
waypoint,
and
now
it's
forwarding
to
a
service
IP
of
If.
Instead
of
a
pod,
ID
yeah.
B
So
that's
within
the
API
model,
so
instead
of
it's
basically
just
do
we
have
the
control
plane,
take
the
service
and
convert
it
to
a
list
of
hot
IPS,
or
do
we
just
push
the
service
and
then
let
z10on
do
it,
so
it
will
still
actually
go.
Take
the
dip.
Look
at
all
the
workloads
in
it,
which
already
has
this
information
for
other
service
routing
purposes
and
send
directly
to
pod
IPS,
using
whatever
load
balancing
it
wants.
So
it's
more
just
the
API,
the
actual
runtime
Behavior.
It
will
still
send
directly
to
pod
IPS.
B
Yeah
I
would
expect
I
mean
in
theory
it
could
send
to
the
VIP,
but
I
don't
see
why
I
I
think
we
can
do
things
better
by
sending
directly
to
the
pods,
like
we
already
do
that
for
everything
else,
anyways.
So
all
the
logic's
already
in
detail
and
whatnot
for
that.
H
B
B
Like
the
general
z-tunnel
routing
is
like
make
the
smartest
decision
I
can.
If
the
next
hop
is
smarter,
defer
the
decision
yeah
on
the
last
hop,
then
I
have
to
make
the
decision
right.
So
you
know,
if
there's
a
waypoint
in
front,
then
we
don't
want
to
resolve
to
a
specific
bit
well.
I
know:
I,
think
that
I
don't
think
I'm
explaining
this
well.
F
B
B
Is
yeah
actually
I
mean
it
does
that
today
it's
just
the
representation
is
not
as
efficient,
but
I
think
we
already
support
multiple
waypoints
in
Z
tunnel
today.
So.
B
We
today
we
have
like
this
logic
where
we
look
at
a
Gateway
like
a
Gateway,
is
a
representation
of
the
Waypoint.
But
then
we
rely
on
some
internal
details
that
okay,
a
Gateway
means
that
we're
going
to
have
pods
with
this
label,
and
then
we
look
at
those
pods
and
then
we
find
out
I.
You
know
all
the
pods
to
send,
which
is
like
not
really
it's
kind
of
relying
on
implementation,
details
of
istio.
B
So
now
that
we
have
actually
a
service,
it's
just
like
how
gateways
work
with
Ingress,
so
you
create
a
Gateway.
It
gets
assigned
to
some
IP
address,
that's
written
into
the
status,
and
now,
if
you
want
to
reach
that
you
just
go
to
a
bad
IP
address,
so
I,
don't
know
what
exactly
Integrations
that
will
help
in
the
future,
but
it
would
allow
for
example,
if
someone
wanted
to
write
a
I.
B
Don't
know
custom
Z
tunnel,
for
example,
and
didn't
want
to
rely
on
implementation,
details
that
would
work
or
if,
for
example,
I
wanted
to
run
my
waypoints,
not
as
pods
in
the
cluster
but
as
pods
somewhere
else.
All
I
need
to
do
is
write
some
IP
address
into
the
status
and
that
would
be
respected
so
kind
of
making
it
less
istio.
A
H
H
I
think
that
I
didn't
hear
any
objection
in
the
bug.
I
think
that
John
didn't
like
mesh
internal
happy
to
put
something
else.
But
so
the
idea
is
that
by
default,
cluster
local
stay
local
in
citan
mode,
and
if
you
use
anything
else
more
or
less
it
will
be
global.
So
clusters
are
local
or
something
that
has
representation
is
self-decentry.
So
you
opt
in
by
creating.
H
I
I
think
we
have
concerns
with
that
cluster
local
should
be
local,
I
I.
Think
the
discussion
is,
how
do
we
report
into
dissolved
Behavior
with
mesh
white?
And
there
is,
you
know,
obviously
MCS,
which
is
not
ready
yet
because
it's
Alpha
I'm
still
kind
of
not
adopted
very
broadly
and
then
there
are
all
kind
of
other
options,
but
I
think
for
short-term
using
service
entry
is
decent
enough.
E
H
E
Yeah,
that's
that's
reasonable,
but
yeah
I'd
say
if
you
want
to
get
working
on
it,
go
for
it.
Okay,.
F
Okay,
cool
can
I
quickly
ask
Stephen
about
if
there's
any
update
on
the
VM
talk
that
we
discussed
last
time.
B
Yeah
one
comment
on
that:
that's
gonna
highly
overlap
with
the
implementation
of
my
doc
that
I
discussed,
because
it's
about
you
know
reading
all
this
information
and
kind
of
aggregating
it.
So
we
should
just
make
sure
we're
in
sync
there
yeah.
B
Comment
also
along
those
lines,
just
the
kind
of
FYI
on
we
talked
about
using
Z
tunnel
in
other
areas
like
on
a
VM
or
outside
serverless
environment.
Someone
contributed
to
changes
for
those
it's
actually
fairly.
Small,
basically
Z
tunnel
has
a
mode.
B
You
can
say
it's
running
in
node
mode
or
sidecar
mode,
and
just
tweaks
a
few
minor
behavior
things
like
requesting
its
certificate
for
its
own
identity
instead
of
the
delegated
identity
and
a
few
other
things
so
yeah,
just
an
FYI
in
case
people
weren't
following
along
in
the
repo
I,
think,
that's
maybe
useful.
B
Yeah,
it's
it's
I
I.
Definitely
just
like
10.
Second
summary
is
that
it's
we
just
need
to
read
from
workload:
entry
service,
entry,
service,
pod,
endpoints
and
aggregate
them
all
together,
okay,
which
is
easier
said
than
done,
but
you
know
it's
like.
Basically,
my
proposal
is
saying
we
need
to
consider
all
the
sources
and
that's
also
what
we
need
for
VMS.
So.
H
Cool
one
one
request
for
you
know:
tscn
people
who,
who
you
know
are
good
with
names.
It
would
be
wonderful
if
we
didn't
use
zitara,
sidecar
or
because
it
will
be
very
confusing
for
people.
You
can
say
you
know
ambient
or
VMS
ambient
or
serverless,
but
I
would
avoid
the
term
side
card
because
it's
you
know
we
have
the
old
sidecars.
We
are
telling
people
sidecars
are
not
necessarily
good.
It's
I,
don't
know.
C
H
Least,
for
me,
it's
always
I
have
a
bit
of
confusion.
A
E
Yeah
I
I
sorry
I
had
conversantly
thought
to
you
like
I,
wonder
if,
if
we
should
focus
more
on
like
the
identity
aspect
of
it
like
either
it's
a
dedicated
or
shared,
or
something
like
that,
rather
than
getting
to
the
the
old
terminology.
B
E
F
Okay,
thanks
full
point:
the
document
of
this
icon.
We
should
read
and
comment
if
you
don't
like
the
naming
anything
I
think
the
last
thing
is
I,
don't
know
if
you
will
mention
your
supportability
or
just
move
to
next
week.
I
I'll
just
kind
of
toss
it
out
there
for
folks
to
be
thinking
about
so
I've
started.
Writing
a
doc
on.
I
You
know
a
safe
mode,
nistio
and
casting
brought
up
a
great
point
that
you
know
ambient
has
a
you
know
it's
currently
you
or
when
it's
going
to
be
Alpha,
but
there
will
likely
be
things
within
ambient
that
will
have
different
supportability
supportability
levels
compared
to
the
main,
like
the
main
set
of
features.
I
As
far
as
note
level
Z
tunnel,
and
things
like
that,
so
want
to
get
folks
thinking
about
kind
of
subdividing
Ambience
as
a
mode
and
calling
out
specific
things
that
might
be
experimental
or
off,
support
comes
to
mind
or
even
which
kind
of
situation
so
be.
Thinking
about
that
we
can
discuss
more
next
week.
H
Yeah
and
and
for
context
what
my
my
what
I'm
trying
to
achieve
is
you
know.
Obviously,
we
want
to
have
istio
with
only
better
and
stable
features,
but
there
are
exceptions
to
to
the
rules
always,
and
one
of
the
exceptions
would
be
that
istio
by
default.
Will
support
was
a
stable
and
better
apis
and
features,
but
will
also
support
ambient
because,
again,
that's
a
direction.
We
want
ambient
in
the
sense
of
interoperability,
be
internal
and
not
having
all
functions
to
turn
it
off.