►
From YouTube: Ambient Mesh WG meeting 2023 09 27
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
Okay
good
morning,
everyone
I
am
welcome
to
the
Wednesday
September
27th.
It's
still
ambient
worker
meeting.
So
first
up
on
the
agenda
is
aiton
and
you'll
see.
B
I
am
yes,
so
I
think
that
I
kind
of
got
we
kind
of
got
the
answer
from
Kate
in
the
issue
itself.
But
maybe
it's
worth
raising
this
scenario,
and
so,
if
you
go
into
the
issue
alone,
the.
A
B
B
B
B
So
it's
kind
of
security
problem
if
I
may
say,
but
it
turns
out
that
there
is
an
impressed
document
which
is
already
approved
by
a
case,
and
we
delay
targeted
authorization
policy,
and
in
that
case,
when
the
user
is
specifying
a
layer
equals
transport
and
we
have
the
effective
behavior.
Is
that
the?
B
If
there
is
no
Waypoint,
then
of
course
the
that
Daniel
is
going
to
enforce
this
policy?
But
if
there
is
a
Waypoint,
then
nothing
is
going
to
be
changed.
The
envoy
is
going
to
enforce
the
same
policy.
C
It
does
answer
the
question:
I
guess.
The
only
thing
is
this
is
not
too
straightforward
to
the
user
right.
So
basically,
you
are
asking
user
to
use
stuff
even
for
Z
tunnel,
just
a
layer,
four
I
would
just
do
thinking
loud
because
for
me
it
took
me
a
while
to
get
it
I
I,
just
think
for
user.
It
will
take
them
some
time
and
it
would
say
surprise.
D
D
If
you
want
to
start
and
that
learning
curve
already
exists
like
if
you
want
to
start,
you
know
doing
JW's,
taking
JWT
claims
or
doing
request
path,
matching
and
authorization
policy
with
just
Z
tunnel.
You
are
already
going
to
not
be
able
to
do
that,
and
so
it
I
I
think
it
makes
a
lot
of
sense
to
you
know
as
part
of
that
same
learning
curve.
D
C
Hey
you
before
you
do
anything
you
have
to
change
your
RC
policy,
pretty
much,
whether
you're
using
layer,
4
or
whether
you're
using
layer
7,
because
the
way
I'm
seeing
right
now
because
before
I
am
when
I
look
at
your
proposal:
keys,
I'm,
thinking,
okay,
when
I'm
used,
if
I'm
not
changing
my
RC
policy,
basically
I'm
setting
layout
to
Onset
right,
which
is
the
default
behavior,
which
is
fine
and
it
works
for
I,
believe
it
works
for
Z
tunnel
in
the
case
study
Channel,
I
use,
which
is
super
cool,
but
now
I'm
thinking,
that's
actually
not
good,
because
you
don't
know
when
who
other
people
would
deploy
a
waypoint
for
my
service
producer
and
consumer
perspective,
you
don't
control
I,
guess.
D
I
mean
yes,
the
user
will
have
to
change
their
authorization
policy,
but
in
my
my
understanding
would
be
that
a
lot
of
users
would
be
having
to
change
their
operation
policies
migrating
over
to
Andy
and
in
in
general
right.
The
the
kinds
of
policies
that
are
often
written
would
you
know,
at
least
from
my
experience
tend
to
be.
D
You
know
that
they're
I've
seen
very
few
policies
that
are
just
L4.
If
you,
if
you
want
to
require
a
cert,
then
you'll
use
pre-op
communication.
Instead,
you
may
do
like
have
some
IP
blocks,
but
most
customers,
most
users
I've
seen
are
wanting
to
you
know,
do
path
matching,
or
only
certain
HTTP
operations.
D
Things
like
that,
so
there's
already
going
to
be
some
churn
inherence
in
adopting
Ambience
We've,
also
for
beta
we've
scoped,
the
the
goal
down
to
just
Greenfield
and
souls
so
kind
of
with
those
two
axioms
in
tow.
It
I
guess
to
me,
doesn't
feel
like
a
lot
to
to
have
a
user
start
to
start
to
think
about
their
their
policies.
As
far
as
what
layer
they're
going
to
be
enforced
at
because
now
there's
not
a
sidecar
doing
all
the
enforcement,
you
have
two
different
places.
D
E
I
think
I
was
up.
I
feel
like
this
issue.
The
next
issue,
the
past
issue,
the
one
before
that.
Basically
everything
we've
talked
about
for
the
past
few
months-
is
really
pointing
to
the
architecture
being
wrong
and
now
we're
seeing
the
consequences
of
it.
Now
that
we're
getting
a
lot
more
experience
with
it,
every
issue
keeps
coming
back
to
the
fact
that
we
do
this
hairpinning
and
the
waypoints
kind
of
magically
capture
everything
on
the
workload
like
I
I,
can't
think
of
a
single
issue.
E
F
Well,
I
completely
agree
with
John,
of
course,
but
I
mean
at
least
for
Pat
winning,
but
I
want
to
apply
regular.
You
know,
announcements
that
we
also
have
the
option
to
if
the
user
has
to
change
the
the
API
and
then
they
need
to
make
changes.
Maybe
we
should
reconsider,
supporting
you
know
Network
policy
with
some
extensions
where
it
pass
identity
and
at
least
a
user
will
migrate
to
something
that
you
know
makes
sense
and
it
will
be
supported
in
more
broadly,
that's
my
usual.
You
know
announcement.
E
Yeah
I
think
we
fundamentally
get
in
this
tricky
territory
when
we
declare
that
a
waypoint
is
a
waypoint
for
workloads
rather
than
a
service.
Oriented
thing
like
Gateway
is
like
an
Ingress.
Gateway
is
a
service
thing
generally
right,
you
expose
google.com,
you
don't
expose
I,
don't
know
some
board
job
ide123.
E
We
get
into
a
lot
of
awkward
territory
there
right.
That
means
that
all
traffic
that
goes
to
the
Pod
we
need
to
Loop
through
the
Waypoint,
which
adds
all
this
hair,
pinning
issues
that
we've
talked
about,
and
you
know
this
is
another
aspect
of
that
as
well.
E
E
The
workload-based
policy
is
attached
to
the
Waypoint,
and
so
now
we
have
these
Waypoint
based
policies,
but
they're,
really
not
workload-based
they're
they're
Waypoint
based
it
feels
it
seems
like
to
me
at
this
point:
we've
gone
so
far,
chords
getting
to
the
point
where
we
could
just
have
Services
attached
to
waypoints,
like
there's
some
extreme
edge
cases
where
you
want
to
apply
L7
policies
to
traffic
directly
to
a
workload,
but
it
seems
quite
rare
that
you're
not
actually
going
through
a
service
like
in
the
original
Eastview
model.
E
We
moved
to
a
workload-based
policies
instead
of
service
based
ones,
because
you
have
multiple
services
or
zero
services
or
you
could
have
some
services,
but
not
call
it
so
attaching
authorization
policy
to
Services
is
kind
of
wonky,
but
because
now,
with
the
waypoints
of
service
could
be
an
actual
physical
piece
of
infrastructure,
not
just
a
VIP.
We
can
actually
enforce,
like
the
traffic,
went
through
the
service
and
apply
the
service
policies
right.
It's
a
physically
a
different
thing
to
go
through
the
service
or
not
go
through
the
service.
E
So
we
could
say,
for
example,
I
want
a
waypoint
for
service
X
I
want
an
authorization
policy
on
service,
X
and
then
I,
furthermore,
want
to
add
a
number
policy.
It
says
all
traffic
to
these
pods
must
go
through
service
X,
because
I
don't
want
people
to
bypass
it.
The
last
step,
of
course,
could
be
optional
or
more
nuanced.
Maybe
you
want
to
say
traffic
can
come
from
servicex
or
it
can
come
from
Prometheus
who's,
going
to
scrape
me
directly
and
not
go
through
the
Waypoint
right.
E
So
it
would
be
a
large
change
for
sure,
but
I
think
a
lot
of
the
problems
we're
getting
ourselves
into
is
to
try-
and
you
know,
work
from
these
two
apis
backwards
into
the
new
architecture.
Instead
of
working
from
how
existing
you
know,
things
work
and
then
try
and
give
the
functionality
we
want
to
users
and
I
will
say:
I
played
a
large
part
in
that
that
was
my
philosophy
in
every
aspect
of
design
was
do
whatever
crazy
stuff.
E
I
Sure
I
have
two
sort
of
questions.
Slash
comments.
The
first
one
is
more
of
a
question,
but
if
I
current
expected
behavior,
if
I
have
an
author
policy,
so
we've
documented
that
quote-unquote
L4
auth
policies
are
implemented
by
z-tunnel,
but
it
is
sort
of
implied
what
an
L4
auth
policy
is.
I
So
is
it
fair
to
say
that
a
policy
that
essentially
does
not
have
a
method
or
operation
whatever
the
methods
and
the
operations
field
is
effectively
in
if
if
the
from
field
is
is
an
L4
classification
and
the
two
field
does
not
have
any
methods
or
operations?
That
is
what
constitutes
an
L4
policy
is.
Is
that
an
accurate
statement,
because
we
sort
of
never
state
that
explicitly.
I
So
yeah
so
so
yeah,
so
so,
basically
I
think
I
I
believe
what
it
translates
to
is
most
of
the
cases
for
L4
policy
are
when
you
either
don't
have
an
operation
specified
dog
because
most
of
the
operations
are
HTTP
methods
or
there
is
a
ports
field
in
the
two
under
two.
So
it's
all
kind
of
a
little
bit
wishy-washy
I
mean
not
wishy-washy,
but
wait.
I
So
are
we
saying
now
that
if
I
have
a
policy,
an
existing
policy
which
meets
those
rules-
and
hence
is
an
L4
policy
that
normally
would
be
applied
by
z-tunnel?
If.
I
If,
according
to
each
proposal,
the
layering,
the
layering,
that's
added,
essentially
overrides
any
implicit
Logic,
the
layering
is
an
explicit
Direction
whether
to
process
this
at
Z
tunnel
or
at
Waypoint.
I
I
We've
talked
on
and
off
about
parts
of
the
Z
tunnel,
overlapping
with
cni
logic,
and
obviously
policy
is
one
of
those.
So
do
we
have.
I
Is
this
the
right
time
to
sort
of
have
a
converged
position
on
the
overlap
of
L4
functionality
of
ambient
with
The
cnis
L4
functionality.
I
H
H
F
H
There's
quite
a
lot
of
there's
quite
a
lot
of
overlap.
Is
it
a
problem
right
for
the
the
end
user
that
there
are
two
potential,
the
same
API
different
sentence,
right,
active.
H
H
I
I
Kubernetes
L4
policy
does
what
it
does
and
we
will
have
another
L4
policy
at
the
service
mesh
layer,
and
then
we
can
sort
of
you
know,
address
these
kinds
of
issues
like
the
the
Z
tunnel
versus
Waypoint
thing,
or
that
we
in
we
have
a
statement
of
direction
to
try
and
have
one
layer
of
L4
Percy
working
with
the
kubernetes
community,
yeah
Italy
a
little
bit
of
a
political
issue,
sort
of
but
the.
I
It
is
because
there's
been
some
discussion
in
the
istio
group,
a
word
which
is
talked
about
converging,
some
or
all
of
the
Z
tunnel
with
the
cni
layer.
C
Yeah,
by
the
way,
the
discussion
you
guys
are
having
actually
remind
me
how
you
know:
Cillian
Network
policy
right,
which
is
a
derived
version
from
kubernetes
Network
policy
and
how
nice
it
actually
supports
smooth
transition
from
ask
user
for
grow
from
layer,
three
layer,
4
to
layer,
seven
I,
don't
believe
as
the
use
of
psyllium
I
would
have
to
you
know
kind
of
go
using
this
layer
thing
to
kind
of
untangle
my
model
between
layer,
three
layer
for
two
layer,
seven
I
actually
really
like
that
model
to
allow.
I
Foreign,
yes
and
it's
a
single
sort
of
converged
policy
model
that
automatically
does
L3
or
L4
or
L7.
C
H
Also
I
spend
some
time
coming
back
to
the
implementation
complexity
discussion
that
John
was
having
like
so
we're
having
to
do
in-depth
conversations
at
once
like
what
should
our
policy?
What
should
our
kind
of
stake
in
the
ground?
What's
the
best
possible
long-term
outcome
and
how
we're
going
to
work
towards
it?
H
H
Is
it
too
hard
to
implement
workload
policy
in
the
Waypoint
right,
like
what
are
we
doing
for
existing
user
transitions
moving
away
from
the
sidecar
models?
Those
are
kind
of
almost
those
are
things
that
have
to
align
in
the
law,
but
they're.
They
have
very
different
kind.
H
Making
structures
around
and
you
know,
John
wrote
up
some
points.
Obviously
some
implementation
complexity
issues.
There
are
some
issues
with
ulcers
being
entirely
service
center
right.
When
we
talk
about
stable
sets
right,
which
we
have
to
work
through
all
right.
H
While
people
sets
are
rare,
they
are
still
important
enough
that
I
show
up
and
there
is
no
the
for
a
stable
set
right.
There's
no
well-designed
capture
point
for
a
proxy
right.
You
end
up
either
being
a
forwarding
Roxy
right
or
you
were
going
to
into
the
workload
right
and
so
do
we
say
you
can
have
l7s.
There's
all
these
kinds
of
implementations,
I
guess.
My
question
right
now
is
which
which
of
these
two
topics?
F
What
is
the
easiest
and
simplest
experience
that
users
will
understand
and
and
because
we
cannot
force
people
to
stop
using
network
policy
without
and
the
ideal
scenario
will
be
apis
that
are
agreed
by
multiple
vendors
and
people,
not
all
vendors
who
support
them,
but
some
of
them
will
just
like
with
Gateway
with
the
extension
mechanism
that
is
used
in
gateways
where,
again,
some
extensions
are
optional
and
as
long
as
we
we
can
agree,
it's
not
issue
a
specific
APN
or
it's
your
only
API
I
see
we.
G
We
should
be
focusing
on
the
end
user
experience
to
that
end.
I
have
a
question,
and
this
might
show
some
of
my
ignorance
with
with
how
ambient
works
today,
but
the
the
stateful
set
problem
in
in
gamma
HTTP
routes
are
attached
to
services,
not
to
gateways.
So
how
does
gamma
serve
stateful
sets
today.
E
E
Not
attached
to
now
in
Israel,
we
do
have
a
way
to
do
it,
but
it's
kind
of
a
it's
not
a
perfect
way,
because
we
we
mat
on
traffic,
to
the
pods,
but
we
have
absolutely
no
way
to
know
if
they
called
service
and
it
resolved
about
or
they
just
called
the
Pod
directly.
So
it's
a
little
bit
wonky,
because
those
are
literally
the
same
thing
on
the
network
right
because
there's
no
VIP.
E
That's
how
we
implement
it,
I,
don't
know
if
we
look
for
gamma
properly
to
not
implement
it
like
this.
The
success,
but
this
bet
kind
of
leaves
it
out.
They
basically
say
there
needs
to
be
a
front
end
so
that
in
most
cases
that's
the
cluster
IP
button
Theory
could
be.
You
know
something
else.
H
H
H
H
It
just
so
happens
that
that
works
for
any
type
of
workload.
Addressing
the
problem
is,
as
John
mentioned,
knowing
what
pod
they're
trying
to
talk
to
right,
isn't
necessarily
or
ideally,
all
the
information
that
we
want.
H
Now
it
isn't
information
to
know
what
authorization
policy
to
implement
when
the
organization
policy
is
worth
attached
because
to
set
up
all
C
policies
and
then
materialize
that
inside
the
Waypoint
and
that's
what
happens
right,
there
has
to
be
something
that
takes
destination
IP
and
Maps
it
into
an
odd
Z
policy
based
on
some
matching
criteria
and
then
implement
the
check
right.
That's
that's.
H
The
thing
that
mimics
the
behavior
of
a
cycle
right
is
the
ability
to
map
back
in
wavelength
for
all
the
current
loads
in
the
name
space
and
that
you
know,
probably
for
an
istory
standpoint.
Control
plane
standpoint
is
not
an
overly
complex
task,
do
far
more
complicated
things
not
in
this
2D,
but
it
is
complexity,
and
it
does
I
can
see
why,
for
some
vendors,
it
presents
implementation
challenges
when
they
want
to
use
some
other
piece
of
infrastructure.
John.
A
H
Some
use
cases
I'm
aware
of
so
the
question
is
right:
this
is
just
a
pure
implementation
complexity.
Question
right.
The
reason
why
we
use
workload
selectors
in
all
Z
policy
is
to
avoid
the
unintended
consequence
of
or
lack
of
currency
and
authorization
policy
enforcement
for
access
right.
You
need
to
be
able
to
reason
about
the
attachment
of
policies
to
workloads
and
not
just
services,
to
ensure
that
they're
always
enforced,
because
Services
can
be
changed
without
workloads
being
changed.
H
Right
that
that
happens,
right
I
mean
DNS
poisoning
attacks
happen.
There
are
various
forms
of
this
type
of
attack
right.
E
H
We
have
in
a
waypoint
in
in
a
world
of
DMZ
I
would
agree,
but
in
a
world
of
heterogeneous
corporate
networks,
I
do
disagree
right
and
we've
seen
that
right
and
it's
kind
of
being
talked
about
in
the
security
community
of
it
too
right
like
on
the
audit
side.
H
F
F
Explicitly
means
that
you
have
a
network
policy
or
well
for
policies
that
say
only
things
that
can
talk
with
me
is
a
price
enforcement
point,
be
it
a
waypoint,
be
it
Ingress,
Gateway
being
whatever
it
is.
As
long
as
you
have
a
chain
of
custody-
and
you
know
exactly,
is
that
the
policies
going
to
the
point?
You
are
good
and
it's
equivalent
with
what
we
are
doing
with
ambient
way.
Ambient
does
have
an
Ingress
Gateway
in
front
of
the
workloads.
K
H
H
Like
we
certainly
didn't
have
a
sexual
guarantee
before
with
sidecar
right,
we
had
none.
Now
we
have
something
that
looks
a
bit
like
a
cni
and
allows
us
to
get
some
form
of
structural
guarantee.
So
I
agree.
There's
some
flexibility
here,
but
I
just
want
to
be
careful
about
getting
about
the
secured
posture
right,
Services
come
and
go.
H
E
I
think
one
one
thing
on
Ingress:
there
are,
you
know
delegating
the
authorization
of
Ingress.
It
does
have
a
pretty
fatal
flaw
that
in
theory,
someone
in
a
different
name
space
could
create
some
route
that
doesn't
have
the
policy
and
then
route
it
to
your
service
right
and
it's
the
same
shared
identity.
E
H
H
Would
rather
not
right,
would
try
to
provide
structural
guarantees
and
Define
apis
that
make
it
harder
to
do
it
right.
Workload
attachment
really
does
help.
People
stand
their
security
cluster.
H
C
Hey
I
just
want
to
remind
everybody.
We
have
20
minutes
left
well,
should
we
spend
over
20
minutes,
discuss
the
most
important
thing,
I'm
thinking,
Louis
and
costing
you
guys
mentioned.
You
know
what
is
the
desire
user,
behavior
and
resources?
That's
probably
the
most
important
thing
without
thinking
about
how
we
need
to
implement
it.
C
H
H
The
question
John
asked,
which
is
look,
can
we
or
can
we
not
do
workload,
oriented
policies
and
waypoints?
If
we
just
can't
do
it
right,
which
is
a
technical
question,
then
that's
going
to
have
some
Downstream
impact
on
the
API.
If
you
commented
from
the
other
direction
say
look
this:
we
want
the
API
to
be
as
we
could
come
up
that
way.
So
that's
a
question
about
what
should
authorization
policy
and
do
and
how
should
we
interpret
it.
E
E
That's
not
an
Easter
configured
Envoy
with
our
custom
filters
and
whatnot
that
we've
we've
created
to
be
a
waypoint
right
like
there
is
a
waypoint
as
a
service
is
really
a
Gateway
right
like
it's
not
a
huge
stretch
to
say
you
could
put
any
off-the-shelf
Gateway
implementation
and
have
it
be
a
waypoint
if
it's
a
service
in
the
current
design
of
Waypoint,
it.
H
H
Idea
of
I
got
one
one
crap
one
crab
for
John.
H
J
G
So
if
three
people
section
is
service,
injection
is
kind
of
the
way
that
I
think
of
Waypoint.
If
there
are
services
that
we
don't
provide,
you
ought
to
be
able
to
do
transparent
service
ingestion
of
other
services
into
the
flow
with
their
own
apis,
their
own
configuration,
but
the
injection
being
managed.
H
H
H
We
need
to
be
able
to
use
something
else
right
and
those
things
will
come
around
limitations
right
right.
They
may
offer
less
features
fewer
features
that
should
not
be
a
limitation
on
istio
as
to
what
istio
offers
right.
There
should
be
a
well-defined
contract
with
those
things
that
say:
Hey
I
want
to
be
bump
in
the
wild
for
the
Waypoint
users,
great
here's,
the
contractual
integration
Point,
here's
how
that
integration,
Works
Implement
features
at
your
will,
but
those
features
don't
necessarily
impinge
the
implementation
choices
istio
makes
for
its
Waypoint.
H
A
G
H
H
Right
and
they're
allowed
to
do
less
right,
let's
be
clear,
like
there's,
no
compatibility
guarantee
other
than
the
structural
guarantee.
We
will
send
you
the
track,
but
these
this
construct
right,
just
like
we
do
for
integrating
with
CA
as
custom
mentioned.
D
I
think
I
think
for
me
it's
a
little
bit
less
than
it's
a
little
bit
different
than
compatibility
guarantee
and
more
of
you
know
going
back
to
the
to
the
the
workload
question
right.
Like
you
mentioned
like
this
seems
like
that's
part
of
the
core
problem
statement
is
workload
versus
service
based
policy.
D
Can
we
even
say
that
waypoints
Implement
workload
policy
today?
Well,
I
guess
we
can
because,
like
a
per
name
space,
but
the
policies
themselves
aren't
bound
to
to
workloads
freely
anymore,
like
like
everything
about
Waypoint,
it
looks
kind
of
a
Gateway,
it
talks
kind
of
the
Gateway,
but
it's
not
a
Gateway
because
we're
still
holding
under
the
Roku
construct-
and
even
you
know,
there's
only
so
much
any
project.
We're
gonna
be
able
to
do
when
it
comes
to
compatibility.
D
So
I
don't
know,
even
though
that
you
know
I
I
personally,
with
the
cut
with
the
users
that
I
see
I
I
see,
you
know
need
for
compatibility
for
me,
it's
more
of
that
inherent
architectural
posture
of
why
why
not
just
lean
in
and
make
way
on
a
Gateway
I
think.
That's
probably
the
most
compelling
release
of.
H
All
this
for
me
and
anybody's
nobody's
saying
that
Waypoint
isn't
a
Gateway
right.
Waypoint
is
a
forward
proxy
right,
so
like
the
Z
tunnel,
which
is
the
climbed,
tells
it
I
want
to
talk
to
this
pod,
and
you
could
write
a
policy
to
get
that
right.
The
only
difference
in
like
if
I
write
an
OT
policy
as
on
the
forward
proxy,
so
clients
are
trying
to
talk
this
pod
right.
The
thing
I'll
see
in
the
traffic
is
an
IP
I
can
write
a
policy
against
CIP
and
that
would
give
me
a
workload,
oriented
policy.
H
H
F
So
front
ends
are
front
ends,
backends
are
backends,
yes,
front
ends,
have
IPS
and
beeps
and
whatever
they
have
in
that
distinguished
right
policies
for
the
tips,
foreign
policies
for
the
actual
IPS
backend
IPS,
there
are
very
different
things
and
we
are
mixing
them
together.
That's
a
problem
here
that
we
are
confusing
VIPs
with
tribies.
H
Well
right,
so
the
only
thing
we're
saying
is
look
like.
There
are
clearly
situations
where
we
need
waypoints
to
act
as
a
forward
proxy
like
just
like.
We
need
Gateway
tech
to
support
proxy,
like
you
can
absolutely
use
the
Gateway
API
outside
of
istio
to
set
up
a
forward
proxy
and
there's
no
way
that
that's
not
going
to
be
a
common
use
case
right.
The
only
convenience
we
provide
today
is
a
mapping
between
a
label
selector
and
an
IP
to
identify
an
authorization
policy
to
apply
to
a
specific
piece
of
traffic.
H
H
That's
a
whole
other
discussion
right
and
maybe
that's
part
of
the
long-term
API
description,
but
this
one
like
the
only
thing
we're
talking
about
is
workload
label
set
mapping
to
IPS
in
Envoy.
That's
the
feature
Waypoint
has
to
implement
sure
sorry,
that's
the
feature.
Istio
has
to
implement
the
support
workload
to
policy
selection
or
any
piece
of
traffic.
F
Or
not,
Implement
and
defer
to
you
know
other
Solutions
and
focus
you
know
kind
of
keep
things
separate
to
them.
You
have
one
key
one:
one
solution
for
services
and
beams
one
solution,
for
there
is
no
reason
to
combine
them.
We
are
Force
combining
them
because
you
know
both
are
policies
which
are
very
different.
H
Like
I
was
talking
like
John
and
I
chatted
a
bit
about
this
and
I
suggested,
like
Z
total
could
say
when
it
talks
to
the
Waypoint.
This
is
who
I'm
trying
to
talk
to,
including
all
of
the
labels,
because
it
knows
the
metadata
right.
It
actually
has
the
baggage
right.
We
were
using
that
it
could
pass
it
right
and
you
could
just
implement
the
label
selector
in
one
way
and
it
would
work
right.
H
H
H
I
just
want
to
point
out
like
there
are
solutions
to
the
implementation
complexity,
problem
that
are
orthogonal
to
the
I
need
to
have
a
different
Waypoint
implementation
and
I.
Don't
want
to
couple
those
two
things,
because
if
we're
going
to
design
for
allowing
other
waypoints,
those
other
waypoints
is
going
to
have
their
own
apisio
can't
be
responsible
for
them
right.
So
we
can't
overly
couple.
H
H
I
would
strongly
argue
that
we
do
because
of
Buster
local
and
the
reason
why
other
Waypoint
implementations
like
let's
say
you
want
to
go
and
implement
IPS
or
Deepak
inspection
stuff
like
be
it
being
a
bump
in
The
Wire.
You
are
absolutely
going
to
want
that
for
stateful
set
you're
going
to
want
coverage
so
not
thinking
about
any
company
or
Niche,
but
your
company's
in
that
business.
G
Yeah
one
other
data
point
there
in
trying
to
find
users
to
provide
feedback
for
ambient
I
did
touch
base
with
Salesforce
and
I
heard
that
they
suspect
ambient
will
not
be
something
that
they
can
adopt
broadly
internally,
because
they
are
so
Reliant
in
sidecar
mode
on
the
client-side
proxying,
which
I
think
is
what
you're
talking
about
the
forward
proxying
Louis.
G
H
H
G
H
Yes,
and
with
no
restriction
on
what
Holocene
is
being
implemented
by
that
Waypoint
choice
or
not
right,
we
can't
these
two
is
much
more
prescribed.
So
it's
going
to
be
like
you're,
going
to
have
a
Gateway
class,
which
is
like
aviatrics
Waypoint
and
all
that
will
tell
istio
is
hey
Z
tunnels
send
it
to
the
aviatrix
Waypoint
instead
of
an
istio
Waypoint
right,
there's
some
contract
for
how
that
works
and.
G
J
E
Yeah
I
mean
we
don't
even
necessarily
need
the
Z10
layer
to
know
that
it's
a
Gateway
right.
We
can
assign
new
services
and
new
DNA
names
and
new
VIPs
and
really
just
make
them
standard,
eBay
objects,
and
we
can
ease
the
Migration
by
using
something
like
external
name,
to
provide
an
alias.
We
want
the
same,
you
know
clustered
our
local
names,
but
there
doesn't
necessarily
even
need
to
be
any
magic.
H
One
thing
I
would
suggest
that
we
do
in
istio
is
strong
recommend
if
you're
going
to
bring
your
own
Waypoint
implementation
that
you
do
meet
certain
security
integration
requirements
with
Seattle
right.
We
don't
really
want
to
recommend,
like
the
Wild
West
in
terms
of
security
Now
how
how
to
go
about
that.
H
Like
that
another
conversation
but
which
you
know
those
ideas
have
come
up
before
yeah
so
like
I
I,
have
an
idea
in
my
head
about
how
we
might
like,
from
an
API
standpoint,
automate
such
an
integration,
you're
right
like
from
a
networking
like
hey,
VIPs
and
endpoints,
construct
yeah,
we
can
do
stuff,
but
I
think
we
also
want
something
that
users
can
kind
of
introspect,
but
we
don't
have
to
go
into
the
Weeds
on
that.
But
I
would
think
it's
a
very
good
idea
to
say.
E
H
F
Yeah,
but
on
a
more
pragmatic,
so
practical
sorry
to
interrupt
on
a
practical
term,
I
mean
we
want
to.
You
know,
try
to
move
from
the
end
forward
and
to
we
don't
have
to
ship
everything
at
once.
So
I
understand
enforcing
workload
policies
in
waypoints.
We
don't
yet
know
the
perfect
solution,
perfect
API.
We
are
not
in
other
consensus,
but
for
service
enforcement.
I.
Don't
think
there
is
any
doubt
or
any
particular
objection
or
I
mean
we
are
in
pretty
solid
ground
on
enforcing
service
policies.
F
Would
it
be
possible
to
move
forward
with
you
know:
Z
tunnel
plus
service
policies
in
waypoints
gate
or
whatever
and
defer
to
a
future
version?
The
workloads
I
mean
we
don't
have
to
ship
everything
that
one
sort
of
or
solve
all
the
problems
at
once
we
can
keep
using
cycles
for
a
while,
and
that
would
give
us
you
know
more
focus
on
you
know
more
wood
figured
arrows
if
you
want
to
use
that
code.
H
So
I'm,
always
okay
with
the
idea
of
deferring
like
we
don't
have
to
implement
everything
right,
but
we
should
reserve
the
right
to
implement
that
right.
I,
don't
want
to
take
I,
don't
want
to
like
structurally
remove
the
ability
to
do
it
right
so
that,
like
that's
saying
like
Gateway
like
Waypoint,
has
to
be
able
to
act
as
a
forward
proxy.
It's
optional,
whether
when
acting
as
a
Ford
proxy
equipment,
workload,
alt
Z
policy
right-
is
that
a
fair
summary
question.
H
So
Z
tunnel
still
needs
to
know,
hey
I'm,
trying
to
talk
to
a
Pog
I'm
going
to
send
traffic
through
the
Waypoint.
It
just
might
not
Implement
any
LZ
policy
on
it
right,
or
at
least
it
has
to
be
able
to
do
that.
F
You
know
which
Services
we
are,
you
know
better
GA.
Anyone
can
use
that
for
service
use
cases
and
the
others
are
still
in
progress.
We
are
still
iterating,
please
don't
use
it
in
production
because
we
may
change
implementation,
details
or
whatever,
but
it's
not
black
and
white,
and
and
we
need
to
solve
all
the
the
workload
convertible
problems
in
order
to
ship
service.
H
F
A
H
If
you
say
that
up
front
we're
not
going
to
meet
no
no
like
niche's
requirement
right
and
anybody
else's
right
and
also
by
the
way,
if
I'm,
acting
as
a
forward
proxy
I,
can
Implement
Gateway
style
authorization
policies
as
a
forward
proxy
right.
I
could
like
we
could
describe
what
that
would
look
like
right.
So
there's
the.
H
F
F
H
Don't
have
healthy
right,
those
are
those
are
all
like
separate
decisions
but
like
when
zetunnel
is
in
place.
I
think
we
have
to
have
that
as
a
Lego
Bridge.
Otherwise,
the
system
is
too
hard
reason
about
like
the
hairpinning
problem
right,
which
is
a
different
use
case
like
stuff
coming
from
Nazi
tunnel
trying
to
get
into
something
and
our
answers.
There
are
hairpin
it
block
it
tell
every
user,
they
must
go
through
a
gateway
right
which
we
could
go
and
look
at
again.
H
And
this
deal
could
say:
look
we
don't
do
hairpinning,
it's
too
complicated,
go
through
a
gateway
and
a
vendor
to
go
and
yeah.
We
do
a
hairpinning.
We
do
all
this
crazy
stuff
right
how
about
it,
but
it
still
says
no
we're
going
to
keep
it
pretty
straightforward
and
simple,
but
that's
a
valid
thing
to
do
again.
Right,
doesn't
change
any
of
the
structural
traffic
guarantees.
I
Hey
it
seems
like
we
talked
about
two
or
three
different
threads
in
the
call.
Would
it
be
possible
to
quickly
summarize
sort
of
which
are
the
three
or
three
odd
heads
of
discussion
in
this
area,
because
it
seems
like
we
were
sort
of
going
across
multiple
threads
of
topics
under
oath.
H
Yes,
I
think
there's
a
a
kind
of
well
the
Lego
bricks
of
ambient
right.
Is
there
a
structural
guarantee
that
Waypoint
as
a
definition,
means
all
traffic
into
service
account
or
namespace
I.E?
The
Waypoint
scope
must
go
through
the
Waypoint,
regardless
of
what
Waypoint
actually
implements
in
terms
of
policy
right.
So
it's
it's
the
contract
between
the
L7
layer
and
The
L4
there,
because
if
we're
going
to
redefine
that
right,
that
has
some
pretty
sweeping
implications.
H
Those
choices
are,
and
similarly
for
the
hairpinning
use
case
right
for
traffic
coming
from
outside
the
mesh
right,
which
means
traffic.
That's
not
h-bone,
based
on
identity
that
we
know
and
share
watch
what
should
we
do
right
and
that's
a
similar
type
of
choice
for
number
two
right:
how
much
complexity
do
we
want
in
istio
and
then
obviously
number
one
impacts
any
vendor
who
wants
to
provide
their
own
Waypoint
implementation.
H
And
vendors
are
going
to
have
different
feelings
about
what
traffic
they
do
or
don't
want
to
see
or
like,
but
istio
knows
nothing
about
what
policies
a
vendor
can
implement.
So
it
has
no
opinion
about
what
policy
is
implemented
in
that
Waypoint
in
a
vendor
amended
when
Waypoint
don't
care
the
lender's
problem.
I
H
This
well
yeah,
well,
I,
guess,
there's
all
this
stuff
about
like
API
Evolution
right
so
should
istio
adopt
Network
policy
as
an
L4
only
API
and
recommend
its
use
and
sub
question
there.
How
do
we
prevent
conflict
with
existing
cni
right.
I
Right,
even
even
going
with
that
assumption.
For
now,
it's
not
clear
to
me
that
the
current
L4
options
within
istio
are
adequate,
because
a
one
of
the
value
of
ambient
is
now
we've
made
it
applicable
to
all
protocols
right,
including
like
UDP,
and
things
like
that
and
from
a
quick
look.
It
seemed
to
me
like.
We
might
need
some
more
rules
and
filters,
given
the
fact
that
we
are
transporting
a
broader
set
of
protocols
now
than
previously
with
sidecar
mesh,
which
was
essentially
DCP.
I
So
we
might
need
to
think
about
that
a
little
bit
more,
so
even
assuming
that
s2l4
is
separate
from
cnil4
permanently
I
think
we
should
think
a
bit
more
about
it.
Oh.
H
H
H
E
F
Is
that
yes,
but
so
it's
it's
not
okay
and
I,
don't
I
think
it's
not
once
it
is
a
use
case,
but
it
doesn't
have
to
be
coupled
or
shipped
at
the
same
time
or
implemented
with
the
same
solution.
I
mean
we
can
use
a
different
solution
for
one
of
the
others
and
sidecars
are,
is
a
valid
solution
for
for
well.
H
F
But
we
can
be
very
clear:
this
is
an
integration
point
for
services
and
a
different
integration
point
will
be
provided
for
workload
to
work
with.
It
doesn't
have
to
be
exactly
the
same
integration
point
for
CH.
We
provide
multiple
integration.
What
they
provide
you,
also
it's
it's
it's
it's!
We
it's
fine
to
have
multiple
solutions
for
each
problem
to
fix
the
right
solution.
H
H
Well,
if
you,
if
you're,
going
to
offer
a
security
product
which
I'm
not
going
to
speak
for
much,
but
it
probably
do
that's
a
problem
with
this
ambiguity
like
I,
don't
think
it's
a
good
idea
for
all
immunity
questions
so
like
I'm,
going
to
push
back
a
little
bit
on
this
to
at
least
get
the
point
like
if
we
say
like
this
is
for
vendors,
and
this
is
a
like
that
we
are
very
clear
right
if
it
varies
by
like
like
I,
don't
want
to
say
we'll
use
sidecars
like
I'm,
okay,
saying
like
they
only
get
this
with
ambience.
H
J
H
E
H
H
B
F
H
E
Yeah
I'd
be
worried,
though,
for
saying,
like
you
know,
I
don't
want
this
Edge
case
to
make
the
experience
worse
for
all
the
other
cases,
when
there's
already
a
solution
for
that
edge
case
too,
like
the
fact
that
someone
may
want
to
apply
L7
policies
to
L7
stateful
sets
and
they
don't
like
Cycles,
isn't
compelling
enough.
For
me
it
is
sway
the
design
of
the
entire
system
like
they
have
a
solution.
It's
one
that's
used
in
production
by
thousands
of
companies.
Today,
it's
a
decent
solution.
H
I,
don't
think
I
don't
want
to
end
up
trying
to
solve
every
problem.
Everybody
is
going
to
agree
with
you
on
like
that.
That
solution
is
fine
right
when
the
operational
burden
of
sidecars
is
problematic
right.
The
maintenance
upgrade
cve
patching
right,
which
is
one
of
the
big
motivators
in
ambient,
still
holds.
H
Well,
like
we
could,
we
could
say:
look
there
is
no
workload
aware
authorization
policy
implemented
in
the
Waypoint.
The
Waypoint
can
act
as
a
forwarding
proxy
right
just
to
pass
through
forwarding
proxy.
So
you
can
get
L7
Telemetry,
which
is
one
of
the
big
values
of
Waypoint
right
generically
right
and
we
could
say
it's
just
relax
the
constraint
on
the
alt
Z
policy
right.
E
F
G
H
We
know
that
the
rollout
of
open
Telemetry
in
real
Enterprises
consistently
is
not
what
you
would
need
it
to
be
like
one
of
our
primary
value
ads
is
like.
Yes,
you
can
get
yourself
to
60
or
40
on
Telemetry,
by
updating
your
apps
you're.
Never
getting
yourself
to
100
and
100
is
where
you
get
the
actual
operational
value,
and
you
can
do
audit.
F
H
Because
they
are
in
the
same
situation
right,
but
but
like
we've,
been
spending
the
last
seven
years
trying
to
persuade
people
to
do
that.
Right,
like
like
I,
think
that's
just
like
a
hard.
No
right
like
we
sell
the
value
proposition
of
consistent
golden
signals.
Yes
regard,
regardless
of
what
you
did
and.
F
E
F
I
strongly
disagree.
You
get
a
minimum
amount
of
telemetries
that
you
can
only
sniff
to
plain
text
HTTP
with
the
native
integration
you
get
full
Telemetry,
including
your
own
application,
telement
to
get
rich
collections;
everything
that
you
care
about
in
your
application,
including
https
traffic.
If
your
application
is
doing
native
https
and
standardized
across
all
the
components
in
the
entire,
you
know
as
a
matter
what
Gateway
used.
E
So
I
think,
if
our,
if
our
real
goal
is
to
say
that
you
get
you
know
L7
Telemetry
everywhere,
though
only
putting
it
through
the
Waypoint
is
actually
a
huge
blocker,
because
there's
a
huge
cost
to
the
waveline
right.
It's
it
breaks
compatibility
with
applications.
It
has
a
huge
latency
and
cost
it's
operationally
expensive.
It
may
not
be
as
complex
as
a
sidecar,
but
you
have
to
pay
for
the
compute.
You
send
all
traffic
through
your
parts
of
it.
If.
E
H
C
H
And
there
are
other
things
like
I
just
mentioned:
Telemetry
like
you
could
do
job
token,
validation
on
Ford,
like
opaque,
like
forwarded
traffic
right
and
still
not
Implement
workload,
specific
LT
policy
right.
There
are
lots
of
other
things
that
we
have,
that
can
work
just
fine
on
like
transparent
or
forward
proxy
mode.
G
Aperture
product
we
just
saw
shown
at
istiocon
was
it
yesterday
or
the
day
before
as
I
understand,
it
would
require
the
forward
proxy
functionality.
G
H
H
H
E
A
H
E
I
couldn't
catch
the
talk
but
I'm
looking
through
the
slides
now
I,
don't
actually
think
what
I'm
proposing
it
breaks
that
model,
because
presumably
they're
receiving
traffic
to
workloads
through
service
right.
It's
only
in
the
case
of
stateful
sets
that
we
want
to
have
a
seven
policy
application
and
we
could
find
other
ways
to
do
that.
I'll.
G
Admit
that
I'm
a
little
bit
confused
by
the
statement
that
it's
only
through
stateful
sets
forward
proxy
gathers
client-side
layer,
7
Telemetry,
like
the
existing
model,
where
we
have
a
proxy
on
each
side
forward
and
a
reverse
proxy
effectively
I'm
a
bit
confused
how
it
would
only
apply
to
traffic
headed
towards
stateful
sets.
That
sounds
like
a
reverse
proxy
to
me.
H
G
F
That
means
happening
is
gone,
so
there
is
no
hairpin
in
the
use
case
or
scenario
where
happening
will
be
needed
all
clients
at
the
tunnel.
No
problem,
no
hair,
pinning
a
client
doesn't
have
Z
tunnel,
not
in
scope,
not
a
problem,
no
need
for
helping
either.
D
So
if
the
summary,
essentially
that
if
staple
set
is
required,
then
we
need
workload,
oriented
waypoints.
If
we
can
either
a
live
staple,
sets
from
support
or
come
up
with
something
specific
sets,
then
we
can
align
with
certain
service
oriented
policy
which,
from
where
I'm
spitting,
seems
to
be
the
current
direction
of
Gateway
API.
D
We
just
talked
about
this
in
Alaska
API
meeting.
There
is
no
immediate
future
for
any
sort
of
workload.
Policy.
Kubernetes
doesn't
really
have
that
concept.
Everything
on
the
network
is
like
go
through
service.
It
is
the
certain
representation
of
about.
D
Sure
sure
right,
yeah,
there's
nothing.
You
can
be
there
for
our
arbitrary
policy.
Sure
yeah
I,
don't
know
the
the
more
John
pulls
on
that
thread
like
how
how
many,
if
we
can
have
alignment
with
Gateway
API
stuff,
with
kubernetes
et
cetera
at
L7
stateful
sets
that
does
feel
does
still
sort
of
needs
to
me.
I
don't
know
I
I,
guess.
Foreign
policy
against
SQL
sets
is
important.
Proxy
feels
sort
of
where,
because
you're
not
going
through
service,
no
like.
H
Like
forward
proxies
are
widely
used
in
the
industry,
even
in
kubernetes
widely,
even
at
Ingress
gateways,
people
use
Ford
proxies
right.
The
only
thing
that
they
might
use
to
select
the
destination
may
be
opaque
to
the
clients,
but
the
client
has
still
got
a
token,
which
is
an
encrypted
form
of
the
IP
address
to
the
destination
right.
That's
what
often
what
is
done
in
session
cookies
right.
So
these
are
not
Niche
things
right,
like
that.
We
are
not
going
to
get
hit
with.
H
H
There
is
no
there's
no
standard
for
that
custom.
All
right
it
is.
It
is
widely
used
industry
practice.
There
is
no
standard
for
it
because
we
want
to
be
clear.
Ford
proxying
is
also
widely
used
and
network
version
I,
don't
know
what
an
end
and
then
Enterprise
stuff
like
Kafka
right
forward.
Proxying
is
used
all
the
time
the
cosmo,
the
Microsoft
Azure
database
right.
H
A
E
E
H
You
have
a
different
operational
model
right,
that's
really
painful,
like
we
can
have
different
API
models,
a
different
operational
models,
that's
bad
like
we
should
try
and
avoid
that,
like
the
plague,
because
we
know
operational
complexity
is
like
a
force
multiplier
on
like
how
operators
perceive
the
system
like
we
could
say
like
staple
sets,
L4
only
okay,
like
that's
an
API,
but
it
doesn't
change
the
operational
model
of
the
system
as
far
as
the
user
perceives
it.
It's
a
capability.
It's
not
I
I
have
to
deploy
something
different.
H
I
I
think
we
already
will
pass
the
time.
So
maybe
probably
you
want
to
drag
the
discussion
any
further,
but
I
feel
like
we
were.
Were
we
equating
forward
proxy
with
the
need
to
have
workload-based
policies
like
it
seems
like?
I
H
I
I
Right
and
then,
secondly,
you
know
this
whole
discussion
about
State,
full
sets
and
so
on,
and
that's
in
the
context
of
kubernetes
workloads,
but
with
with
VM
based
workloads
or
maybe
some
future
I,
don't
know
awesome
based
workloads
or
whatever.
I
I
H
H
H
Information
about
a
staple
set
than
we
might
have
about
just
bear
IP,
but
I
suspect
some
of
the
other
stuff
will
fall
out,
but
yeah
we
should
track
it.
I
And
one
last
thing
about
the
cni
discussion,
so
I
think
the
history
with
the
CNR
Network
policy
was
they
did
talk
about
how
initially
there
was
discussion
about
having
Services
based
kubernetes
Network
policy,
but
in
their
case
they
ended
up
choosing
workload-based
Network
policy,
primarily
because
the
whole
policy
thing
was
implemented
differently
by
different
plugins.
So
the
lowest
common
denominator
that
could
satisfy
every
implementation
of
network
policy
was
to
Target
workloads
and
they
did
have
back
and
forth
between
service
based
Network
policy
and
workload-based
network
policy,
but
to
satisfy
every
plugin.
H
I
Yes,
yeah
with
workload-based
policy,
you
can
be
functionally
address
all
your
scenarios,
even
if
sometimes
you
might
be
inefficient,
because
you're
targeting
policies
per
backend
as
opposed
to
targeting
It
Against
The
Logical
service,
but
functionally
you
can
cover
it,
and
so
they
ended
up
doing.
After
back
and
forth
between
service-based
policy
and
workload-based
policy,
they
ended
up
converging
on
working.
This
policy.
I
K
J
K
Also,
what
use
cases
are
we
totally
limiting
I
think
potentially
staple
sets
are
a
bit
of
a
are
a
bit
of
a
limiting
example,
they're
sort
of
the
first
to
come
to
mind,
but
they're
also,
you
know
not
necessarily
indicative
of
the
whole
pool,
so
I'm
wondering
yeah
what
we'd
be
limiting
ourselves
to
and
what
the
behavior
would
be.
If
we,
you
know,
if
we
didn't
have
those
yeah,
it's
either
Target
an
IP,
it
would
just
go
straight
to
the
to
the
destination
or
what
would
even
happen.
H
Traffic
must
flow
right,
so
the
only
decision
is.
Does
the
client-side
detail
will
make
the
decision
to
go
to
the
Waypoint
or
not
and
then
kind
of
Waypoint
for
the
Tropic
or
not,
and
then
probably
a
compliant
Waypoint
implementation
would
check
if
the
IP
was
forwarding.
The
traffic
2
was
part
of
the
same
trust
domain
as
itself.
K
K
No
I
I
understand
so
I'm
just
add
like
polling.
You
know
what
what
would
we
do
then?
Oh
right
like
what
would
the
behavior
be?
Would
we
just
say
you
know
when
we
reject
I
mean
I
the
thing
I'm
thinking
about
and
I
think
about
pretty
consistently
with
things
like
this
is
like
what
we're
trying
to
do
is
provide
value
on
top
of
existing
Services
right.
H
C
K
H
So
I
think
we
need
it
all
on
this
point
right,
we
need
to
call
out
examples.
We
need
to
look
at
the
pros
and
cons
argument
on
the
complexity,
right
and,
and
some
of
the
points
here
like
we
can
decouple
policy
from
this
choice.
Right
so
does
decoupling
policy
from
this
choice
right.
What
impacts
does
that
have
on
complexity?
Is
is
complexity,
the
primary
concern
all
right,
John.
A
H
H
And
then
do
we
need
to
go
and,
like
I
haven't
been
back
into
the
The
Hairpin
documents
in
a
while
sorry,
but
it
seems
like
we
may
want
to
go.
Take
another
look
at
that
document
once
we've
taken
the
pass
at
this
document.
Is
that
also
Fair.
H
H
Shouldn't
assume
that,
from
the
beginning
event,
vendors
think
about
your
requirements.
H
What
are
you
trying
to
do
right?
Because,
if
you're
asking
for
a
contract,
I'm
a
vendor
too
so
I'm
going
to
think
about
this
as
well?
What
do
you
want
to
be
able
to
do
because
speak
now
or
forever
hold
your
peace
when
it
comes
to
contract.
H
I
H
H
Over
time,
I'll
I'll
work
with
John
and
try
and
get
as
much
captured
as
possible.
Thanks.