►
From YouTube: Ambient Mesh WG meeting 2023 08 30
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
A
Know,
okay,
anyhow
without
further
Ado
welcome
to
the
Wednesday
August
30th
ambient
weekly
TR
this's
meeting
and
so
first
up
we
have
peace.
Talking
about
Waypoint
policy.
C
A
Me
you
can
just
go
to
you,
see
that
one
100%
on
the
on
the
toolbar
yeah,
just
upper
leftand
corner,
says
100%.
You
can
just
click
on
that
and
make
it
like
125
or
150.
B
C
Yeah
much
appreciated
yeah
so
wanted
to
Circle
back
around
to
the
original
Waypoint
policy,
Target
rep
discussion
after
last
week.
We
got
some
feedback
from
a
couple
of
folks
who
felt
well
just
had
some
questions
about
the
upgrade
and
migration
story,
as
well
as
I.
C
Think
zong,
who
someone
who
a
maintainer,
who
who
not
able
to
make
this
meeting
because
of
the
time
zone,
had
some
questions
or
or
concerns
about
the
target
rep
in
general
and
so
I
wanted
to
just
you
know,
reopen
the
the
original
proposal
and
make
sure
that
we've
got
I
Le
some
little
consensus
that
we
still
want
to
do
this,
because
a
lot
of
the
discussion
and
the
conversation
that's
been
happening-
is
on
just
the
API
PR,
adding
the
tar
rep
to
the
API
and
so
I'm
I'm
wanting
to
see
a
couple
of
things
one
do
we
do?
C
We
still
feel
comfortable
with
the
tradeoff
and
the
you
know,
ramifications
of
adding
Target
rep
and
two.
If
we
have
alignment
on
that,
we
move
forward
with
the
API
PR
and
then
have
the
follow-up
discussions
in
the
actual
implementation
of
aach
resource,
because
we
have
quite
a
few
comments
on
the
API
itself.
D
C
E
Here,
I'm
I
think
the
API
a
it's
okay
I
me.
We
should
have
Target
ref
in
the
API.
Even
if
we
don't
clearly
know
what
thetic
I
mean,
I,
don't
think
it's
it's.
A
C
Support
I
think
I,
I
think
I
agree
with
that.
I
think
there's
going
to
be
some
variation
from
API
to
API
on
the
specifics.
Optimation
policy,
for
example,
has
you
know
some
some
issues
with
with
scoping
when
it
comes
to
the
the
the
layer
targeting
which
is
a
separate
proposal?
So
yeah
I
completely
agree
with
that
feedback.
Anybody.
C
Else
so,
if
not,
then
I
guess
my
question
to
the
I
think
three
Toc
members
in
attendance
today
it
could
be
Lynn,
John
and
Mitch.
Is
you
know?
Is
there
anything
outstanding
on
the
API
PR
itself
that
you'd
like
to
see
before
giving
it
one
more
review
and
approval
so
that
we
can
move
forward
with
the.
B
Implementation
I'll
have
to
take
not
to
make
sure
things
haven't
changed
since
I
last
looked,
but
the
idea
was
was
good
to
me.
So
I
will
I'll
take
another
look
at
that
today,
but
I
think
it
should
be
fine.
Are
we
like
hiding
this
or
somehow
mention
this-
is
only
for
ambient
or
something,
and
to
make
this
not
directly
to
stable
API
to
some
in
some
way.
B
Perfect
yeah,
that's.
E
B
Yeah
I
wanted
to
do
on
gateways
as
well,
but
I
don't
want
to
shove.
This
kind
of
large
thing
straight
to
ga.
B
C
And
And,
to
clarify
that
there's
some
a
lot
of
discussion
on
the
p
on
the
pr
for
right
now
we
are
scoping
it
to
to
ambient
only
because
there
are
some.
There
are
some
questions
about
client
side
application,
especially
on
a
per
resource
basis
and
how
clients
had
overrides
and
such
might
work
in
the
Contex
of
Gateway
API
in
parody,
and
so
because
the
blocker
was
like
the
reason
we
we
are
doing
this
is
for
ambient.
C
B
Yeah
I
mean
I'm
fine
with
if
we
would
need
to
it
to
make
it
easier,
but
the
concerns
don't
make
sense.
To
me,
I
mean
it's
syntax
sugar
for
a
workload
selector,
so
it
doesn't.
It
can't
be
wrong
in
some
ways
like
yeah
those
details
about
what
happens.
If
you
work
with
sector
as
well
and
like
there's
details,
we
need
to
work
out
but
to
say,
like
client
overrides
that
that
to
me
maybe
I'm
just
missing
it,
but
it
doesn't
seem
to
make
sense,
especially
since
on
gateways
by
definition,
there's
no
client
override.
B
So,
like
I
said
like
it's,
my
just
scope
it
to
ambient,
but
we
should
do
a
fast
fall
to
expand.
It.
E
E
Yeah
I
want
to
say
kind
of
the
opposite.
It
will
be
super
strange
to
have
the
target
ref,
which
is
introduced
by
the
kubernetes
Gateway
API
apply
to
anything
but
the
gateway
to
say,
okay
gateways
that
defin
API
Target
ref,
it
doesn't
apply
to
them,
but
it
applies
to
something
else
that
doesn't
have
anything
to
do
with
gateways.
B
E
E
E
E
F
Turn:
okay,
if
you
guys
are
done
with
that
particular
point,
I
I
just
want
to
walk
through
the
migration
scenario.
The
only
thing
I'm,
not
too
comfortable,
I
think
I
share
with
kids.
Last
time
is
the
migration
scenario,
just
making
sure
you
know
we
have
a
pass
for
people
using
SAA
today
to
be
able
to
migrate
to
ambient
using
this
particular
policy
with
Target
ref.
So
in
my
mind,
I'm
thinking
through,
let's
say
I-
have
sleep
cause
htb
being
right.
F
The
most
simple
is
your
scenario
and
let's
say:
I
have
HTTP
beam.
Maybe
I
have
multiple
replicas
right
and
I'm
using
Cy
car
today
now
I'm
explore
ambient
I
would
expect
I
would
probably
stand
H
be
being
in
ambient
as
well
right,
so
I
probably
would
have
PSY
and
ambient
coexist
and
transition
and
maybe
gradually
shift
traffic
to
ambient.
If
the
Test
passing
so
say,
I'm
using
a
simple
policy
I
know
your
PR
covers
multiple.
F
It's
using
authorization
policy,
as
example
right
so
I
set
up
authorization
policy
on
my
httv,
be
that
has
certain
rules
and
my
authorization
policy
was
for
cica
today,
right
because
I
come
from
the
word
of
cycl,
so
I,
probably
using
a
workload,
selector
I'm,
selecting
app
HTTP
being
now
that
I
also
have
HTP
being
some
of
the
replica
or
maybe
another
deployment
of
a
being
Canary
deployment
in
ambient.
So
now,
I'm
also
needing
to
create
another
authorization
policy,
I
assume
and
in
that
new
authorization
policy.
F
I
expect
I
would
using
the
same
like
rules
and
condition.
The
only
difference
would
be
instead
of
using
work.
Club
selector
I
would
using
the
the
the
target
ref
to
bind
to
the
Waypoint,
for
my
H
being
assuming
I
also
have
a
waypoint
right,
because
that
has
to
be
there
is
this
the
flow
of
migration
we
are
expecting.
F
C
F
I
understand
that
yeah
but
I'm,
just
because
we're
talking
about
API
design
right
so
I
just
want
to
make
sure
we
don't
foresee
issues
with
that
approach
that
we
would
require
us
to
change
in
the
API
again.
C
Well,
so
so
I
don't
think,
there's
an
issue,
because
if
you're
moving
from
Waypoint
I
mean
from
side
car
to
to
ambient
you're
going
to
like
the
your
current
stuff,
is
matching
selecting
the
workload
you're
going
to
have
to
change
the
that
policy
to
select
the
Waypoint
anyway.
Is
that
not
correct
yeah.
B
Surface
level,
syntax
difference,
you
either
put
a
label
selector
that
references,
a
Gateway
object
or
you
put
a
Target
ref.
But
it's
the
same
thing
it's
just
like
you
could
directly
translate
to
and
from
them
they're
100%
identical
it's
just
whether
you
type
name
or
a
label
that
represents
the
name.
F
B
F
B
F
Work
yeah,
that's
so
yeah!
That's
what
I
want
to
walk
through.
So
that's
scenario:
number
one
I
think:
if
we
educate
User,
it's
probably
okay,
it's
a
little
bit
painful,
but
at
least
there
is
a
pass
for
that.
I
think
scenario:
number
two
would
be:
how
would
we
alert
user
when
the
configuration
mismatching
would
we
be
able
to
detect
hey
you're
using
Target
you
using
workflow
selector?
But
now
you
have
a
waypoint.
Maybe
you
should
switch
to
use
Target
ref.
F
Pre-Thinking
because
I
think
it
could
be
a
little
bit
error
prone
from
a
user
perspective
where
they
might
have
the
fet
ref,
which
they
should
have
work
close
selector,
or
maybe
they
have
a
workload
selector,
but
it
should
be.
The
target
ref
depends
on
which
deployment
model
they.
F
Yes,
if
analyzer
can
detect
such
a
thing,
I
think
it
would
be
really
good
to
analyze.
The
only
really
tricky
thing
is
the
analyzer
needs
to
not
only
look
at
the
yamama.
It
needs
to
consider
the
data
plan
topology
that
the
yam
is
applying
to.
So
it
has
to
be
a
little
bit
more
intelligent
than
analyze.
It
today,
I
think.
C
Yeah
so
so
it
sounds
like
most.
Most
of
the
questions
are
around
or
most
of
the
concerns
around
the
the
change
in
in
in
policy
application
from
pods
to
waypoints
is
that
does
that
sound,
accurate.
F
C
Y
okay,
so
if,
if
that's
the
the
feedback,
I
think
it
sounds
like
we
can
move
forward
with
this
PR,
there
are
other
PRS
that
are
being
staged
on
the
implementation.
So
we
can
move
pretty
quickly
after
that,
as
far
as
the
Gateway
piece
trying
to
go
back
and
find
the
feedback
that
caused
us
to
kind
of
back
up
from
Gateway
API
Ingress
gateways,
but
I
can't
find
it
at
the
moment.
F
Look
is
that
the
pr
to
change
the
the
way
we
bind
to
the
Gateway
to
use
Target
ref
as
well.
C
H
I
found
the
comment
here.
We
go
yes,
so
for
gway,
API
gway,
specifically
this
target
rep
should
also
be
applicable.
Do
we
ALS?
Do
you
want
to
support
this
for
policy
targeting
a
resource
in
a
different
name,
space
versus
putting
the
policy
in
the
name
space?
Yes?
And
so
the
question
was
around
where's.
The
policy
live
in
reference
to
the
the
Gateway,
which
is
the
name
space
today
for
Gateway
API
gateways,
your
your
policies
can
it's
it's
still
a
workload
targeted.
C
Your
your
policies
are
still
workload
targeted
right,
You,
don't
select
the
we
don't
have
that
workload
to
Gateway
policy,
attachment
change,
that
we
do
in
ambient
for
regular,
G
API,
and
so
that
was
why
we
kind
of
removed
gateways
like
Ingress
gateways
from
the
scope
of
of
it,
because
that's
a
separate
change,
that's
that
is
going
to
break
users
who
aren't
moving
to
ambient
I.
Remember.
C
B
Enough,
oh,
oh
I'm,
totally
fine
with
it
applying
to
to
normal
to
not
just
way
points
like
I
said
I'm
fine
with.
If
we
have
to
do
it
to
way
points
just
to
avoid
confusion,
but
there's
no
reason
in
my
mind
to
to
limit
it.
C
B
No,
it
is
it,
is,
you
still
apply
them
to
the
the
Gateway
workload
like?
How
do
you
apply
an
authorization
policy
to
an
Ingress
Gateway
with
the
Gateway
API?
It's
exactly
the
same
as
ambient.
Today
you
do
a
label
selector
and
we've
said
the
only
supported
label
to
select
on
is
the
Gateway
name
label,
which
is
identical
to
referencing
it
by.
E
What
what
did
that
voice
a
confusion
if
we
Define
a
new
class
of
Gateway,
let's
say
ISO
Gateway
modern
ambient,
whatever
you
want
to
call
it,
which
would
have
the
semantics
that
only
target
ref
applies
and
it's
super
compliant
to
the
Gateway.
And
you
know
maybe
we
have
different.
We
make
different
choices
about
about
the
API
surface.
So
basically
we
leave
the
old
gateways
alone
and
there
is
no
confusion.
C
Ground
I'm,
not
necessarily
I,
don't
think
we
necessarily
need
a
whole
new
class.
It
would
be
nice
to
essentially
have
users
be
able
to
opt
into
to
well.
I,
don't
even
know
how
you
opt
in
well,
you
said
the
Gateway
CL
and
create
the
Gateway.
We
have
users
to
be
able
to
opt
into
the
gateway,
API
behavior
on
a
very
explicit
way,
but
I'm.
C
That's
not
wrong.
What
I'm
worried
about
is
eventually
having
to
remove
that
Gateway
class,
and
we
want
that
to
become
the
default,
but
yeah
I,
don't
know
have
to
think
about
that.
A
little
bit
more
Len
see
your
hand
up.
F
Yeah
so
I
guess
I'm
trying
to
understand
what
the
advantage
is
to
support
Target
ref
in
this
scenario,
because
from
pass
to
Waypoint
right,
we
didn't
have
a
choice
right,
because
the
label
on
the
parts
httv
being
is
different
than
the
Waypoint.
So
we
essentially
get
bring
a
lot
of
complexity
to
the
user
to
say,
Hey.
You
actually
have
to
replicate
your
authorization
policy
As
you
move
from
SAA
to
ambient.
F
You
have
to
kind
of
make
a
duplicate,
and
you
have
to
manually
change
the
target
ref
instead
of
using
workflow
selector,
but
for
for
Gateway,
wouldn't
that
be
the
same
label.
I
mean
what
would
be
the
advantage
to
support
this
target
ref
other
than
having
user
doing
more
work.
B
It's
I,
so
one
I
would
argue
it's
not
more
work.
In
one
case
you
have
to
match
on
a
magic
label
and
in
the
other
case
you
match
on
a
very
explicit
well-
defined
API
and
in
one
case
you're
saying
magic
label
equals
my
Gateway
and
the
others
say:
name
is
my
Gateway,
so
it's
the
same
amount
of
work,
but
it's
much
more
structured
and
the
structure
is
defined
by
the
kubernetes
Gateway
API,
where
every
vendor
API
policy
attachment,
follows
the
same
structure
and
they
have
tooling
around
understanding
these
attachments
and
Etc
and
documentation.
B
So
we
have
consistent
ecosystem.
The
other
thing
it
does
that's
really
important
is
that
today
you
create
the
Gateway
API
and
under
the
hood
we
we
spin
up
pods
right,
but
that's
kind
of
an
implementation
detail
from
a
user
perspective.
They
only
interact
with
the
Gateway
and,
if
they're,
moving
from
a
different
gate.
Gway
implementation
like
AWS
implementation,
there's
not
going
to
be
a
pod
into
the
cluster
right.
B
So,
by
having
attachments
go
to
the
actual
Gateway,
we
avoid
leaking
the
internal
details
and
we
have
them
actually
attached
to
their
their
the
thing
that
they
they
create
right.
It's
like
in
in
kubernetes.
You
don't
attach
something
to
like
a
lowlevel
internal
resource
like
an
endpoint
or
something
right.
You
attach
it
to
the
higher
level
resources
and
sure
they
create
internal
junk
behind
the
scenes.
B
But
that's
internal
detail
that
you
don't
need
to
worry
about,
and
in
fact
you
may
not
even
have
a
pod
in
some
implementations
of
easto,
whether
that's
a
vendor
modification
or
some
future
changes.
We
made,
for
example,
I
had
a
prototype
in
the
past
where
you
created
a
Gateway
in
EO
and
it
spun
up
a
pod,
but
the
Pod
was
actually
in
a
completely
different
cluster
and
it
was
totally
like
kind
of
managed
and
that.
A
B
Have
easily
been
running
on
some
serverless
compute
or
not
even
kubernetes,
at
all,
running
on
some
VM
or
whatnot
right,
so
it's
it
helps
us
preserve
the
separation
between
the
actual
user
intent
in
the
implementation,
and
it's
just
as
easy,
if
not
easier,.
F
Okay,
so
I
think
I
understand
the
purpose
of
it.
I
would
argue,
you
know
probably
continue
to
preserve
the
workload.
Selector
semantics
is
also
valuable
for
users
who
are
using
them
today,
and
particularly,
who
are
you
know
using
them
migrate
from
SAR
to
this
new
wood
allows
them
and
they
can
migrate
off
worklow
selector
if
they
choose
to
and
move
to,
Target
rep.
It
works
better,
but
it
gives
them
the
transition
period
without
creating
like
duplicate
resources.
B
I'm
not
sure
what
you're
talking
about
with
side
Parts.
This
is
about
G
wavs,
it's
unrelated
to
side
cars
and
by
the
way
the
attachment
currently
is
described
as
experimental,
so
I
mean
I'm,
just
fine
I'm,
not
saying
we
should
delete
it
right
away
or
anything.
But
it's
not
like
this
is
some
something
that's
been
around
for
10
years
and
everyone
has
their
label
selector
policies.
This
is
a
new
thing,
the
Gateway
API,
and
it
it's
explicitly
called
out
that
attaching
resources
is
experimental
and
the
reason
we
kept.
That
experimental
is
exactly
to
do
this.
F
D
F
C
Okay,
great,
if,
if
that's
the
case,
then
we
I'll
I'll
tra,
with
Jackie
about
adding
Gateway
back
into
scope
with
those
clarifications.
I
think
it
makes
a
lot
of
sense
since
we
already
have
prior
art
I
do
think
we
should
kind
of
summize
in
the
chat.
I
I
think
we
should
also
try
to
highlight
the
the
shift
for
Gateway
attachment,
maybe
a
bit
more
prominently
or
not
prominent,
maybe
more
something
more
relevant
to
to
users
on
the
docs
page,
and
you
can
you
can
tackle
that.
F
F
B
G
C
It's
not
just
me
it's,
you
know
lots
of
lots
of
folks
on
the
community
working
on
it.
So
appreciate,
appreciate
everybody's
effort.
Okay,
John
you've
got
the
next
topic.
B
Yeah,
oh
cool
you're,
opening
it
for
me,
yep
I,
don't
know
why
I
muted,
myself,
yeah
I
just
want
to
go
over
this
blog
post,
so
I
get
some
more
out.
Revenue
no
I'm
just
kidding,
not
necessarily
because
we
should
should
do
this
or
not,
but
I
think
it's
like
I
wrote
it
for
myself
to
understand
e.
Do
a
bit
more
and
it
helped
me
a
lot.
So
maybe
it
will
help
others
and
it
will
certainly
probably
help
understand
C's
perspective,
more
I,
at
least
for
me.
B
It
did
and
I
agree
with
it
quite
a
bit
more
than
I
I
did
in
in
the
past.
So
basically
what
this
is
exploring
is
today
we
have
this
Waypoint
Gateway
class
and
it
does
all
this
magic.
When
you
apply
it
right,
you
just
apply
the
Gateway
and
all
of
a
sudden
Everything's
changed
all
the
traffic
goes
through
the
Waypoint.
We
accept
traffic
to
Services.
We
accept
traffic
to
pods,
you
can
use
service
bound
routes
and
we,
you
know,
apply
the
routes
there.
B
It's
all
this
kind
of
magic
that
happens
with
a
very
small
action
of
just
creating
that
you
know
five
line.
Gateway
object,
so
what
I
was
exploring
is
what,
if
we
wanted
to
do
something
like
waypoints,
but
without
using
the
Waypoint.
B
Potentially
without
EO
like
what,
if
we
wanted
a
way
points
with
a
I,
don't
know
enginex,
Gateway
or
Google
load,
balancer,
Gateway
or
whatever,
and
that's
basically
what
this
is
I
happen
to
use
E2,
because
I
I
don't
like
other
products
because
I'm
not
used
to
them,
and
it
annoys
me,
but
it's
just
using
the
standard
easto
Gateway,
so
it's
not
using
any
Secret
Sauce.
So
if
you
scroll
down
a
bit
basically,
what
I've
done
is
just
deployed
standard
used
to
it
with
normal
Gateway.
B
Some
test
applications
nothing
interesting
here.
These
are
just
completely
standard
applications
and
then
some
test,
client
and
then
we
can
see.
We
can
obviously
connect
from
the
client
directly
to
server
no
secret
sauce
at
all,
no
no
L7
proxy
or
anything
right.
That's
just
kind
of
the
Baseline.
Now,
if
we
want
to
add
some
L7
things,
we
can
just
deploy
a
Gateway,
and
this
is
100%
a
standard
Gateway.
Just
like
you
would
write
for
Ingress
traffic.
The
only
difference
is
we
marked
it
as
a
cluster
IP.
B
Instead
of
load,
balancer
technically
could
be
load
balancer,
but
you
probably
don't
want
to
expose
it
externally
and
that's
it
and
I
can
call
it
just
like
I
did
before
it's
a
little
bit
awkward
because
I
don't
have
DNS
setup,
but
I
will
that's
later
in
the
doc,
and
now
my
request
goes
through
the
Gateway,
so
I
have
kind
of
an
internal
load
balancer
to
the
echo
service,
but
I
can
still
go
to
the
normal
service
if
I
wanted
to
so
like
all.
These
call.
B
Passs
are
kind
of
valid
here
on
this
somewhat
confusing
grid
of
of
things.
This
part
is
kind
of
just
notes
almost
on
how
to
set
up
external
DNS,
but
the
the
real
gist
of
it
is
that
if
you
do
this
setup,
then
the
config
before
automatically
sets
up
DNS
as
well.
So
now
I
can
just
call
echo.
mesh.
how
john.net
or
whatever
domain
you
use
instead
of
the
cluster.
local
address
and
yeah.
So
the
next
big
thing
that's
different
from
a
waypoint
is
with
waypoints.
We
enforce
the
traffic
actually
goes
through
there
right.
B
So
we
can
do
something
similar
if
we
just
use
Network
policy,
this
blocks
all
traffic
other
than
that
from
the
Gateway
and
then
now
the
graph
looks
like
this.
It
looks
a
lot
more
like
the
Waypoint
topology.
One
thing
that's
very
different
is
that
in
waypoints
today
we
do
well.
We
there's
a
lot
of
contention
around
this,
but
we
potentially
do
the
hair
pinning
if
a
client
doesn't
go
through
the
Gateway
right.
B
B
Is
you
create
a
route
and
you
bind
that
to
the
service
itself,
we're
modifying
the
actual
service
instead
of
just
attaching
a
route
to
the
Gateway,
and
then
we
did
deploy
a
Gateway
and
I
just
use
the
eole
command,
but
it's
basically
a
very
similar
thing.
So
we
end
up
again
with
I,
practically
identical
diagram
of
before.
B
That's
about
it,
U
there's
a
few
differences
here,
so
it's
a
bit
awkward
to
use
a
non
HB
protocol
for
this
case,
like
with
TCP
on
a
Gateway
matching.
You
really
only
have
like
Port
matching
because
we
don't
have
additional
destination
IP
like
the
destination
IP
for
a
standard.
Gateway
is
always
the
gateways
own
IP
address,
so
you
can't
really
get
value
out
of
that,
whereas
with
the
Waypoint
setup,
we
have
two
IPS
really
like.
B
Obviously,
the
Gateway
gets
a
request,
but
inside
of
it
it's
tunneled,
so
we
have
the
intended
original
service
destination
and
then
obviously
one
big
difference
is
whether
we
modify
the
service
or
we
make
kind
of
a
new
service
that
has
the
L7
behavior,
there's
also
automatic
transport
encryption
with
the
Waypoint.
But
we
will
add
that
to
the
diy1
in
the
next
section,
and
currently
it's
I
mean
could
foresee
a
way
that
we
could
add
it,
but
there's
not
a
clear
path
to
having
kind
of
client
aware
policies
in
the
Gateway.
B
D
B
Part
of
the
context
was
that
I
think
I
mean
correct
me
if
I'm
wrong,
but
I
think
this
is
what
thinks
that
we
should
do
and
and
I
didn't
fully
understand
it,
and
it
led
to
some
confusion,
at
least
for
me
in
discussions.
So
at
the
very
least,
this
will
help
understand.
It
helped
me
understand
what
C
was
talking
about
by
actually
trying
it
instead
of
just
saying:
no,
that's
not
what
a
wayo
is.
A
B
Now,
I
do
actually
think
that
there's
valuable
things
here,
I'm
not
saying
that
we
necessarily
should
go
all
in
on
this
approach.
I
haven't
decided
for
myself
personally
what
I
think
we
should
do
yet
I'm
still
kind
of
exploring,
but
I
am
starting
to
kind
of
rethink
some
things
so
that
yeah.
E
Yeah
and
and
and
what
actually
that's
an
internal
document,
I'm
working
on
a
public
version
as
well.
My
point
is
that
whatever
is
in
this
document
is
already
possible,
with
any
class
of
Gateway
and
with
any
any
vendor.
So
it's
not
something
that
we
decide
to
do
or
not
to
do
it's
something
that
is
designed
by
the
Gateway.
You
know
API
and
it
works
and
provides
the
same
capabilities
except
that
for
plain
text
or
non
EO
clients.
E
If
you
have
a
nono
client,
there
is
a
major
difference,
I
mean
in
our
case
we
go
to
to
pod,
and
then
we
her
in
back
and
forth
to
to
the
way
points
so
two
round
trips
and
we
don't
get
jot
and
whatever
with
this
solution,
you
make
a
small
change
in
the
config.
You
use
a
friendly
name,
I
mean
example.com
or
whatever,
which
is
nice
for
some
customers,
and
some
people
prefer
to
use
cluster
local.
E
Some
people
consider
it's
friendly
to
use
their
their
their
domain
name,
but
you
go
straight
to
the
the
Gateway,
so
you
save
one
round
trip
and
you
can
use
jot
and
all
the
power
of
the
Gateway
explicitly
or
pick
your
implementation
of
Gateway.
If
you
want
I
mean
it's,
not
your
you're,
not
stuck
with
only
apis,
you
can
pick
up,
I,
don't
know
whatever
you
want.
D
E
It
doesn't
have
anything
to
do
with
way
point.
It's
just
saying
that
hey
you
can
use
Waypoint,
it's
wonderful,
it
works
perfectly.
It
has
a
lot
of
benefits
if
you,
if
that's
what
you
want
or
if
you
choose
to
you,
can
use
a
different
Gateway.
No
problem
which
may
have
other
features
may
have
other
Behavior
May
support
different
set
of
feature
different
authentic.
Whatever
you
want,
okay,
and
that
Gateway
is
perfectly
polid
and
it's
perfectly
fine
to
use
it.
I
mean
there
is
nothing
wrong
with
using
a
Gateway.
That's
what
it's
designed
for.
E
Yeah,
not
only
that
you
can,
you
can
specify
everyone
is
denied,
nobody
can
go
otherwise
and
them
through
the
Gateway.
But
you
can
say
this
particular
workl
that
I
trust,
because
in
same
Nam
space
same
same
user
and
it's
collocated,
it
can
go
directly
because
again
it's
you
can
have
two
microservices
from
the
same
owner.
You
just
Define
them
to
Port.
You
collocate
them
because-
and
you
trust
everything.
B
B
One
more
section,
and
then
I
I'll
have
some
more
to
answer
to
your
question
Justin,
but
just
to
make
sure
I
don't
jump
ahead.
The
other
thing
one
of
the
big
gaps
we
had
no
encryption
turns
out.
We
have
a
pretty
good
encryption
thing,
that's
Z
tunnel,
and
we
can
use
that
here
right.
So
if
we
just
make
the
client
and
server
in
the
mesh
like,
we
don't
actually
deploy
waypoints,
we
just
have
Z
tunnel
here
and
then
I
I
work
around.
B
What
I
think
is
a
bug
that
I
will
look
into
in
the
future.
With
this
disable
H
phone
now
we
can
do
basically
the
exact
same
thing,
but
it's
encrypted,
and
we
can
it's
hard
to
tell
it's
encrypted
because
we
made
Z
no
transparent.
B
But
we
do
have
this
nice
k
thing
and
it
shows
this
you
may
notice
it
actually
doesn't
show
any
traffic
to
Echo
V2
and
that's
a
bug
in
our
gemetry
which
I
found
during
writing
this,
but
we
can
discuss
that
maybe
separate,
and
we
can,
even
if
you
scroll
down
a
bit,
if
we
don't
like
Network
policy
now
we
could
use
authorization
policy
which
is
basically
the
same
but
slightly
different,
and
we
can
use
identities
instead
of
labels.
B
If
we
want
so
yeah,
that's
that's
it
going
back
to
Justin's
question,
like
some
of
the
context
is
in,
we
made
a
ton
decisions
in
ambient
and
almost
everywhere
along
the
way
we
decided
to
reinvent
things
right.
We
have
huge
competition
with
the
cni
because
we
basically
reinvent
everything
the
cni
does,
except
for
ipam
right.
You
know.
B
We
we
handle
Telemetry,
we
handle
I,
forget
other
things.
There's.
A
B
We
we
do
everything
right
like
the
cni
is
basically
usess,
and
a
lot
of
that
I
think
is
because
we
built
it
on
top
of
CN
that
don't
provide
a
lot
of
functionality,
but
a
lot
of
cnis
do
provide
a
lot
of
functionality
right
it
like
we
have
this
awkward
overlap
where
we
try
and
run
the
entire
world-
and
you
know
we
say
this-
is
what
a
service
is,
we're
going
to
change
that
meaning
we
do
all
those
things,
and
that
leads
to
a
lot
of
complexity.
B
I,
think
it
leads
to
I,
don't
know,
that's
that's
the
that's
kind
of
the
the
kernel
of
what
I've
been
thinking
about
for
the
past
few
days
or
weeks
or
or
whatever
I
don't
have
a
conclusion,
yet
necessarily,
but
I've
been
kind
of
thinking
like
what.
If
we
went
the
opposite
approach
and
tried
to
reuse
the
underlying
platform
as
much
as
we
as
we
could-
and
we
just
add
kind
of
little
tweaks
here
and
there
to
provide
things
we
need.
B
You
know
like
what,
if
we
we
didn't,
do
cic
management,
we
let
Ser
manager,
do
that
or
if
we
didn't
do
service
load,
balancing
and
whatnot
and
let
the
cni
do
that
and
okay,
maybe
the
C,
don't
have
the
encryption
we
need,
but
we
can
add
that
in
a
much
lighter
weight
way
kind
of
after
all,
the
cni
stuff,
instead
of
hijacking
the
earliest
possible
Point
and
like
waypoints,
like
we
reinvented
a
new
Waypoint
like
what,
if
we
just
use.
B
Could
be
an
east2
Gateway
because
we
have
that,
but
it
could
be
engine
X
or
whatever.
So
that's
what
I've
been
kind
of
looking
into
thinking
through.
D
Yeah
so
so
it
seems
then
like
and
and
I
I
know.
We've
had
some
side
conversations
about
this
as
well.
That
then,
actually,
this
is
sort
of
saying
that
ambient
is
a
pattern.
There
is
a
reference
implementation
that
we've
talked
about
with
Z
tunnel
and
with
Waypoint
proxies,
but
there
are
probably
other
ways
that
you
could
implement
this
without
using
those
components
still
get
a
lot
of
the
same
apis.
But
then
you
could
have
alternate
implementations.
Is
that
a
fair
summary
of
what.
B
We
we
first
did
the
most
maximalist
approach
of
Reinventing
everything
and
right,
so
part
of
that
was
for
good
reasons.
Part
of
that
was
because
that's
easy
to
do
an
open
source,
because
it's
hard
to
make
assumptions
about
their
platform,
because
we
want
to
run
everywhere
on
every
system
and
they're
all
different
and
part
of
it
was
because
we
evolved
ambient
very
slowly,
like
the
initial
versions
of
ambient
literally
took
the
side
car
as
is,
and
just
stuck
it
in
a
pod
like
it
was
a
side
pod
right.
It
was
a
side
car.
B
B
Thing
and
just
kind
of
reinvented
everything
now
the
other
approach
I
was
going
is
like
what,
if
we
did,
the
totally
minimalist
approach
like
we
do
the
least
amount
possible,
and
it
turns
out
there's
very,
very
little
tat.
You
do
it's
mostly
just
adding
mqls
almost
as
like
a
last
encryption
thing
now.
What
we
do
for
real
is
probably
somewhere
in
between
those
or
maybe
we
have
some
options
or
something,
but
that's
kind
of
where
I'm
at
yet
I.
A
H
Hey
two
sort
of
thoughts
on
this
one
is:
is
there
an
inclination
or
a
sort
of
aspirational,
thought
that
the
L7
proxy
will
be
plug-in
replaceable
at
some
point,
and
Waypoint
is
just
one
sample
implementation,
but
this
entire
architecture
works
in
the
future
with
your
own
flavor
of
Waypoint,
instead
of
what
we
give
like
is.
Is
it
supposed
to
be
plugin
replaceable
at
some
point.
B
A
B
Standard
gway
here
so
the
answer
is
maybe.
H
Well,
100%
standard
any
implementation
of
the
Gateway
API
in
particular.
Otherwise
you
would
have
to
have
a
new
API
for.
E
B
E
So
if
I
can
jump
in
John,
there
is
one
point
here
that
is
I.
Don't
I
want
to
make
sure
it's
not
lost.
It
is
100%
possible
today,
with
almost
any
implementation
of
Gateway.
As
long
as
user
is
willing
to
make
the
config
change
to
use
friendly
names
instead
of
clor
local.
The
only
thing
that
is
not
possible
is
to
preserve
the
clust
of
local
semantics.
So
if
the
user
is
changing
to
example,
you
know
Echo
do
example.com,
then
today
you
can
do
that.
Every
I.
G
E
H
D
E
They
will
be
supported
because
a
gate
to
implementation
may
or
may
not
have
a
particular
I
mean
if
you
use,
for
example,
Google
Gateway.
Instead
of
the
of
EO
Gateway,
you
will
have
the
am
policies
that
Google
provide
if
you
use
Amazon
you'll
have
whatever
authorization
policy,
Amazon
provider,
so
so
for.
D
Yeah
I
guess
that's
more
making
the
statement
that,
like
I
I,
think
it's
a
little
over
simplifying
to
say
that
any
Gateway
anyone
that
supports
the
Gateway
API
can
do
what
we're
doing,
which
I
think
is
not
entirely
true
it.
It
has
to
support
other
things
as
well,
not
like
just
being
Gateway
compliant,
is
not
sufficient
to
have.
B
Yeah,
like
you,
don't
get
exactly
what
Easter
gets,
but
you
get
the
the
things
that
that
Gateway
provides,
which
is
yes,
there's
the
core
which
everyone
has
Gateway
API
core,
that's
routing.
Everyone
has
that
and
there'll
be
more
core
and
then
whatever
extensions
they
have
so.
G
B
We
have
our
extensions
and
other
their
extensions,
yeah
I
think
Mitch
was
first.
G
Yeah,
so
looking
at
the
diagram
that
you
have
here,
I'm
trying
to
understand
the
relationship
to
hair
pinning
is
the
Z
tunnel
handling
encryption
as
it
leaves
shell
client
and
then
decryption
as
it
gets
to
Gateway
ISO
or
does
Gateway
ISO
have
to
participate
in
that
mtls
encryption.
B
Yeah,
in
this
case,
I
have
so
in
the
E
Waypoint
model.
The
Waypoint
itself
terminates
the
H
bone
right.
We
had
theorized
the
idea
of
what
we
called
sandwich
where
the
Waypoint
was
just
a
normal
po.
It
didn't
handle
encryption
at
all
and
it
would
run
on
the
Node
with
Z
tunnel
and
Z
tunnel
would
do
it.
The
reason
we
never
shipped.
That
is
because
we
couldn't
come
up
with
a
good
way
to
pass
identity
from
Z
tunnel
to
the
Gateway.
If.
B
But
we
never
that
was
going
to
the
blocker
like
it
was.
We
didn't
finalize
it.
So
in
this
case
what
I
have
is
exactly
that
sandwich
model
Z
tunnel
is
terminating
on
the
Gateway
easto
node,
and
that's
why
I
said.
There's
a
limitation
in
this
that
the
Gateway
EO
can't
really
do
client
orare
policies,
I
mean
they
could
get
the
IP
address,
maybe,
but
they
would
not
get
the
identity
from
the
TS
handshake.
B
At
least
at
this
time
we
could
obviously
add
some
enhancement
to
the
Z
tunnel,
but
even
then
it
would
probably
be
kind
of
a
East
chish
specific
way
which
we'd
have
to
get
added
to
other
things.
And
one
thing
to
note
two:
is
this
encryption
only
works
for
in
cluster
gateways,
so
we
mentioned
before
like
hey,
you
can
stick
AWS
load
balancer
here
and
it
works
fine,
that's
true,
but
you're
not
going
to
go.
Stick
Z
tunnel
on
AWS
load
balancer.
G
B
Yeah
I'm
not
proposing
anything
I'm
really
just
trying
to
get
some
share,
some
understanding
of
like
what
Waypoint
is
and
isn't,
and
what
you
could
do
without
Waypoint
and
to
me,
this
kind
of
had
a
lot
of
light.
Bul
moments,
as
I
was
kind
of
going
through
this.
Okay
and
I'm,
like
it
may
result
in
proposal
eventually
has
not
yet
that's
great
thanks.
E
Anything
The,
Proposal
really
I
mean
there
are
some
proposal,
joh
implicit
here,
which
is
one
to
actually
fix
what
we
said
about
propagating
his
identity.
Make
sure
that
we
can,
we
can,
you
know,
do
the
identity,
delegations
and
and
and
and
some
other
things
that
previously
we
agreed,
but
we
we
never
prioritized
because
this
works.
But
there
are
some,
like
you
know,
Corner
cases
and
and
and
and
and.
C
Rauges
yeah,
so
this
is
very
interesting
to
me.
I
I'm,
intrigued
by
the
idea
of
seio
the
project
looking
to
use
to
utilize
the
underlying
platform
as
much
as
possible.
I
think
that's
the
direction
that
things
are
going
between
Gateway
API
I
would
like
to
see
some
more,
not
from
you
John
or
anybody
who,
but
in
general,
I
think
to
get
there.
C
Ideally,
we
see
some
more
collaboration
on
the
cni
side
as
far
as
these
capabilities,
but
that's
neither
really
here
nor
there
when
I
I
think
that
when
you
try
to
create
when
you're
experimenting
and
you're
iterating
quickly
and
you're
looking
to
push
something
out
there
as
reference
imp
reference
implementation,
you
can
kind
of
find
yourself
in
a
situation
where
you've
created
a
product
and
people
use
it
and
I
think
that
ambient
could
very
easily
become
that
I.
Don't
think
that
that
well,
I
think
ambient
will
become
that
actually
and
I.
C
Don't
think.
That's
necessarily
a
bad
thing,
but
I
do
think
that,
as
we
start
thinking
about
the
kind
of
iso
positioning
as
a
as
a
project
and
giving
people
the
opportunity
to
use
Gateway
API
and
like
the
network
policy
piece,
you
know.
Where
does
the
platform
itself
stop?
And
where
does
you
know
isio
as
a
reference
implementation
continue?
I
just
think
it's
interesting!
Nothing!
C
Really
there,
but
I
I
I
do
I
will
say
in
the
short
term,
I
I
like
the
idea
of
keeping
Theo,
as
is
kind
of
ecosystem
wise,
because
I
think
there's
a
lot
of
innovation
and
speed
that
we
can
have
as
a
commun
as
opposed
to
trying
to
like,
as
opposed
to
trying
to
Wrangle
multiple
other.
G
G
That
being
said,
this
does
sort
of
Reminisce
of
the
like
microservices
to
monolith
transition
that
we
made
in
six
in
that
when
you
have
an
ecosystem
play
and
you're
heavily
reliant
on
other
things
that
are
present
in
the
ecosystem,
you
essentially
begin
putting
the
burden
of
dependency
management
and
API
version
Management
on
the
user.
When
that's
one
or
two
pieces,
that's
pretty
manageable.
G
If
it
turns
into
8
to
10
that
are
all
mandatory
for
your
mesh
to
even
begin
to
function
it
it
starts
to
look
like
a
pretty
unpleasant
user
experience.
So
I,
I,
guess
I'd,
say
I'm
cautiously
optimistic
about
that
direction.
But
we
do
need
to
be.
There
is
a
right
size.
Just
pushing
everything
out
into
ecosystem
is
is
not
the
right.
E
Was
that
we
were
managing
all
the
pces
and
that's
why
and
it
had
the
same
security
characteristics
same.
That's
why
we
could
create
a
monol
in,
but
in
this
case
it's
a
platform
that
we're
integrating
with,
which
is
completely
different
and
has
completely
different
characteristics.
So
you
know
it's
not
black
and
white,
with
service
microservices
versus
monoliths.
It's
a
very
you
know
specific
decision
about
a
lot
of.
H
Sense,
On,
a
related
note,
I,
think
similar
points
also
apply
to
the
znal
proxy
implementation,
because
right
now,
the
way
it's
position
is
that
this
is
an
very
opinionated
solution.
This
is
a
zal
proxy.
It
only
does
mtls
and
that's
the
only
model,
but
if
we
want
to
encourage
alternate
implement
ations
of
those
Eternal
proxy
which
maybe
take
over
more
of
the
service
load,
balancing
or
add
fancier
service
load,
balancing
or
better
integration
with
cni.
Are
we
explicitly
encouraging
that
discouraging
that
like
or
are
we
saying?
H
No,
if
you
want
a
compliant
ambient
Ambient
implementation,
your
L4
plock
should
be
Z
tunnel
and
Z
tunnel
only
like
I
feel
like
it's
not.
This
is
a
Newcomer's
view,
so
correct
me,
if
I'm
off
here,
but
it
feels
like
completely
opinionated
that
this
is
z
tunnel
is
the
one
and
only
thing
that
you
can
do
for
your
L4
proxy.
Do
we
want
to
message
or
whether
there
are
it's
a
you
know,
replaceable
model
at
some
point.
B
Yeah
I
I
completely
agree.
That's
focus
on
Waypoint,
but
I
totally
agree.
The
same
concern
exists
about
zel
and
that's
something
I've
been
think
you
have
a
ton,
and
this
actually
I
think
the
link
is
probably
very
vague,
but
it's
they
are
super
related,
like
one
of
the
reasons
that
we
claim
that
we
have
to
do
service
in
Z
tunnel,
which
is
what
leads
to
99%
of
the
complexity
in
Z.
Tunnel
right
is
that
we
need
to
know
what
service
they
wanted
so
that
we
can
connect
to
the
Waypoint
in
this
model.
B
So
this
is
one
way
to
enable
the
cni
to
do
a
lot
of
the
things
that
Z10
does
or
the
cni
to
continue
doing
a
lot
of
things
it
does
today,
instead
of
doing
in
Z10,
potentially
not
the
only
way,
but
it
is
definitely
one
way
so
I'm.
Definitely
considering
that
as
well.
I
am
I'm
pretty
concerned
about
us
Reinventing
all
of
service
in
Z
tunnel,
like
it's
a
it's
a
lot
of
complexity
and
work,
especially
when
one
of
our
goals
is
like
to
be
100%,
transparent
and
compatible.
H
Right
agree:
just
on
that
point:
do
we
have
an
explicit
statement
here
that
the
goal
of
Z
tunnel
is
to
leverage
cni
wherever
possible,
or
the
goal
would
be
eventually
to
bring
in
cni
like
functionality
into
the
Z
tunnel
to
minimize
the
variation
of
different
cnis
like
do
we
have
a
position
on?
Yes,
the
intent
of
Z
tunnel
would
be
to
maximize
reuse
of
cni
capability.
B
H
B
It's
it's.
It's
definitely
an
interesting
goal.
I
I,
don't
want
to
say
that
I
think
that
we
should
do
it
yet,
but
I'm
definitely
very,
very
interested
in
the.
E
H
E
C
Go
all
right
we're
bit
over
time.
Thank
you,
everybody
for
the
very
good
conversation
looking
forward
to
seeing
where
this
continues
to
go.
As
always,
if
you
got
something
else,
you
want
to
talk
about,
please
feel
free
to
add
up
to
the
ambient
agenda.
U
with
that
we
will
we'll
close
out
today.
Thanks.