►
From YouTube: Gateway API GAMMA Meeting for 20230509
Description
Gateway API GAMMA Meeting for 20230509
A
A
So
it's
definitely
helpful
for
us
to
get
a
good
idea
and
we'll
be
able
to
attend
each
of
these
meetings
to
ensure
that
maintain
this
kind
of
schedule
makes
sense,
and
also
just
to
pitch
the
the
regular
Gateway
API
meeting,
which
has
typically
been
pretty
late
in
the
evening
for
EU
folks,
is
next
week
going
to
be
at
a
similar
time.
Slot
to
this
meeting.
A
I
think
it
is
going
to
be
30
minutes
earlier
than
this
next
week,
so
avoiding
conflicts
with
gamma
awarding
conflicts
with
Sig,
multi-cluster
and
it'll
be
trialing.
A
new
Pine
slot
for
the
main
gateway,
API
I'm
meeting
to
hopefully
make
it
more
accessible
for
EU,
are
times
on
folks
to
be
able
to
join
all
right
and,
as
always,
we
have
an
open
Agenda.
So
please
feel
free
to
add
any
topics
that
you'd
like
to
discuss
in
the
meeting
notes
and
with
that
I
can
get
started.
A
B
I'll
get
unmuted,
eventually,
okay,
yeah,
hopefully
we're
good
all
right.
So,
first
up
yeah
what
you
already
mentioned,
the
next
cable
API
meeting.
It
is
actually
30
minutes
later
than
our
start
time
now.
So
25
minutes
from
now
a
week
from
now
as
when
that
meeting
will
start,
then
next
up
the
rc2
of
v0.7.0
is
almost
ready.
We
realized
a
little
too
late
that
well
a
little
later
than
I
would
have
liked
that
we
missed
a
pretty
big
detail
around
redirect
clarification,
the
PRI,
Linked
In.
B
The
agenda
covers
that,
just
if
you
have
any
opinions,
please
get
them
in
the
next
few
hours.
We
already
have
a
couple
approvals
on
that,
so
it
is
going
to
merge
soon
and
once
that
merges
we're
going
to
turn
around
and
get
our
C2
out.
Pretty
quick
and
rc2
I
expect
will
be
our
last
RC
before
the
final
release.
A
E
A
D
Yeah
so
I
sent
I
I
forget
if
they
were
approved
or
not,
but
I
sent
some
PRS
to
move
the
gifts
from
provisional
to
implementable,
which
I
think
really
just
represents
kind
of
the
current
state.
We've
been
in
that
state
really
for
for
a
while.
We
have
I
think
three
implementations
now
so
we're
kind
of
at
the
point.
Now,
where
we
have
multiple
implementations,
we
have
conformance
tests.
I
think
we
should
start
progressing
to
officially
experimental
shortly,
after
maybe
in
the
0.8
time
frame.
B
Yeah
I,
don't
think
anything
is
merged
on
that
front,
but
I
think
it's
still.
You
know,
at
least
from
my
perspective.
I
was
waiting
until
we
had
at
least
one
gamma
meeting,
so
we
could
clearly
announce
it
and
give
anyone
a
chance
to
have
any
comments,
but
I
think
we
already
have
a
few
people
that
have
approved
it.
It's
just
got
a
hold
on
it
that
will
probably
be
removed
today
as
well.
B
Right,
you
never
know
the
the
reason
that
it's
going
to
implementable
and
experimental
is
at
least
historically
experimental
has
been
included
in
a
release
experimental
well.
It
refers
to
experimental
release,
channel
trying
to
get
0.7.0
out
before
adding
scope
to
it,
but
I
think
it
largely
meets
the
criteria
of
experimental
too
so
I
think
we
should
be
able
to
turn
around
and
make
another.
You
know
release
pretty
quickly.
That
just
says
by
the
way,
gamma's
experimental
I
think
it's
more
of
a
formality.
E
B
D
B
Yeah
I
think
the
the
entire
Gateway
API
implementations
page
needs
some
significant
updates,
because
we
have
we
have
some
implementations
on
there
that
are
still.
You
know.
Work
in
progress
haven't
released.
Anything
we
have,
some
that
have,
you
know,
are
fully
conformant,
and
then
we
have
some
that
are
also
doing
mesh
or,
and
some
that
are
only
doing
mesh
and
we
don't
really
have
a
good
way
to
represent
any
of
those
States.
So
yeah
I'm
sure
others
have
opinions
on
this
too.
But
we
need
some
cleanup
around
that.
A
How
do
we
route
to
Services
across
mesh
boundaries?
So
the
goal
of
this
is
to
make
routing
to
services
in
the
mesh
work
in
a
predictable
and
sensible
manner.
I
think
the
the
difficulty
here
is
that
some
of
what
is
practical
to
implement,
maybe
at
odds
with
a
convenient
experience,
but
there's
definitely
tension
here
between
different
meshes
different
implementation,
details
different
assumptions,
so
that
there's
not
going
to
be
a
lot
of
must
in
this
it's
kind
of
the
unfortunate
reality
of
it.
A
It's
almost
the
constraints
that
we're
dealing
with
here
are
some
implementations
are
commonly
deployed
by
say,
like
a
single
Cloud
vendor,
and
you,
where
you
can
have
an
assumption
of
all
of
my
best
communication
within
multiple
clusters,
is
happening
within
a
single
VPC,
so
you
have
a
flat
Network
for
other
vendors,
we're
trying
to
bridge
multiple
Cloud
providers
in
a
single
mesh.
So
you
don't
necessarily
have
those
assumptions,
although
you
might,
if
you're
deploying
a
cni
underneath.
A
I
think
that's
unfortunate,
but
I
don't
know
how
much
we
can
do
to
prescribe
how
this
is
treated
other
than
basically
allowing
affordances
and
accommodations
to
be
able
to
have
different
routing
Behavior
depending
on
mesh
implementation.
Details
I
think
that
the
goal
of
this
is
to
get
as
much
as
we
can
towards
a
towards
patterns
that
are
commonly
supportable
and
implementable,
as
should,
and
then
some
allowances
for
how
much
is
may
choose
to
implement
it.
If
certain
behaviors
are
present
so.
F
Yeah
just
a
quick
comment:
maybe
it
would
be
good
to
clarify
with
the
terms
with
East-West
Gateway
and
all
the
other
things
that
are
discussing,
because
there's
a
huge
amount
of
confusion
and
things
in
reality
are
much
simpler
than
they
look.
I
mean
if
you
ignore
the
you
know
as
I
see
of
terms
that
we
invented
and
confusion,
and
you
know
kind
of
if
you,
my
my,
for
example,
for
East
West
Gateway
I
mean,
is
Gateway
API
restricted
to
only
public
internet
addresses
and
not
allowed
to
represent
these
two
as
gateways.
C
F
C
A
C
F
Yeah
my
apartment
was
initial
in
JK
and
Ronaldo,
probably
other
places
with
the
Gateway
API.
You
can
put
an
annotation
or
or
some
other
and
make
it
an
internal
Gateway.
So
there
is
no
difference
between
East
West
and
north
south.
Both
of
them
can
be
programmed
with
the
Gateway
API
and
both
of
them
don't
need
to
be
different
or
treated
specially
I
agree
with
you.
The
problem
is:
how
do
you
make
sure
that
you
know
HTTP
router
service
is
visible
to
the
east
west
gateways
that
you
intend
to
be.
A
When
traffic
gets
to
it,
it
can
determine
if
it
is
authorized
or
not.
So
it
can
reject
unauthorized
traffic
there,
but
it
cannot
without
like
introducing
it.
If
it's
you
technically
could
but
I,
don't
think
anybody
wants
to
have
a
sidecar
proxy
redirect
traffic
to
a
different
destination
in
most
common
cases.
So
that
would
be
one
way.
A
Gateway
or
something
like
that
and
that's
sort
of
like
what
ambient's
doing
where
it
could
be
a
place
to
enforce
policy
which
will
enforce
traffic
routing
policy,
and
it
does
for
basically
dumb
requests
so
inbound
requests
that
don't
know
what
endpoint
they're
intending
to
reach,
but
for
requests
that
no
a
specific
endpoint
they're
trying
to
reach
like
such
as
those
coming
from
a
Gateway
or
coming
from
a
client
sidecar.
Those
are
passed
through
directly.
A
That
is
an
element
of
flexibility
that
I
just
like
for
consistency.
You
don't
want
to
necessarily
expect
or
require
that
Waypoint.
Oh,
that,
like
we've,
went
like
proxy
at
a
boundary
like
that,
because
that
would
be
a
substantial
architectural
change
for
many
meshes
if
it
were
to
require
an
internal
implementation
detail
for
enforcing
producer
rules
in
a
place
like
that,
yeah
costume.
F
About
flat
networks,
or
are
we
talking
about,
you
know
separate
dpcs,
where
you
you
are,
you
don't
have
a
flat
Network,
because
the
fundamental
problem
we
had
with
this
is
that
you
don't
know
how
to
address
it.
I
mean
how
is
IP
can
be
duplicated,
same
IP
address
into
networks.
How
could
the
sidecar
or
the
client
refer
to
the
to
the
destination
in
a
way
that
will
go
to
to
you
know:
egress
Gateway,
Ingress,
Gateway
and
all
the
middle
boxes,
nuts
and.
A
It
felt
pertinent
to
also
address
other
issues,
all
of
like
scope
and
crossing
boundaries
such
as
within
the
match,
when
you
may
have
client
routing
rules
and
producing
producer
valuables
to
find
or
when
you're
crossing
boundaries,
either
within
a
cluster
set,
where
you
have
some
Assumption
of
service,
functionability
and
sameness
between
different
clusters,
or
this
is
like
across
a
cluster
set
boundary
where
you
do
not
have
that
assumption
between
different
clusters.
So
the
across
cluster
set,
where
you
basically
don't
have
that
assumption
is
pretty
straightforward.
A
It
basically
has
to
go
through
some
sort
of
East-West
Gateway
because
it
should
not
reasonably
have
any
knowledge
of
the
actual,
direct
and
point
that
it's
trying
to
reach
and
it
needs
to
have
a
boundary
by
I
watch
rally.
Rules
can
be
applied
to
income
traffic,
so
that
is
like
a
East-West
Gateway
between
between
clusters.
C
F
Some
some
warnings
here
we
kind
of
try
to
do
this
with
istio,
with
multinetal
support
and
because
we
missed
many
of
the
points
we
kind
of
put
ourselves
in
a
corner
where
we
have
trouble
getting
out
of
so
it
is
very
important
to
consider
those
Corner
cases
when
designing
it.
Otherwise,
you
end
up
with
sna
routings
that
we
did
or
something
similar
which
which
we
know
that
it's
not
going
to
work.
A
E
A
That
is
not
necessarily
ideal
for
some
user
stories,
particularly
for
the
ability
of
mesh,
our
like
service
owners
in
a
mesh
to
be
able
to
do
something
like
dream
traffic,
that's
inbound
to
their
service
and
redirect
it
to
avoid
service
Interruption.
When
they're
doing
something
like
a
blue
green
deployment
or
breaking
up
a
monoliths,
something
like
that,
it's
typically
like
preferable
for
a
service
producer
owner
to
have
more
control
over
that.
A
But
enforcing
so
like
that's
a
pattern
that
we
can
guide
usage
towards
in
terms
of
like
suggestions,
but
enforcing
that
basically
requires
having
that
traffic
Transit
through
a
Gateway
of
some
sort.
Be
that
add
a
name
space
boundary
or
at
an
East-West
cluster
boundary
or
redirected
through
a
a
second
hop
and
and
absent
that
which
is
basically
a
it's
an
indirection.
That
makes
it
more
expensive
to
use
the
mesh.
G
C
A
A
F
Yes,
don't
forget:
don't
forget
that
the
workload
needs
to
authenticate
that
it's
talking
with
the
Ingress
Gateway.
If
you
want
to
bypass
security
also,
you
are
saying
that
you
know
Gateway
request,
don't
go
through
authorizations
and
you
must
authentically
the
Gateway
is
very
strongly.
Otherwise
anyone
can
pretend
to
be
a
Gateway
and
bypass
it.
So
it's
it's
very
tricky.
A
And
I
think
there
are
some
existing
allowances
in
respect
for
that,
where
it
it
says
like
or
other
sufficient
authorization
policy
or
something
like
that.
But
I
was
not
really.
The
scope.
I
was
trying
to
focus
on
it's
more
of
just
like
where
the
rounding
Behavior
was
designed
and
like
how
an
endpoint
is
selected
and
basically
like
the
way
to
enforce
that
it
in
a
mess
you
commonly
are
trusting
the
client
sidecar
to
do
that
with
basically
like
the
safety
check
of
the
actual
optimization
that
is
enforced.
C
A
A
So
you're,
basically
you're
splitting
the
trust
Model
A
little
bit
like
you
can
enforce
the
act
like
what
you
can
actually
enforce
is
at
the
destination,
and
then
you
can
expect
reasonable
behavior
from
the
client,
with
kind
of
like
the
safety
check
of
you're
able
to
enforce
it
to
something
undesirable
happens
at
the
destination.
Sidecar.
F
Are
you
are
you
familiar
with
the
proposal
for
presentations
that
is
discussed
in
Gateway,
because
that's
also
very
related
with
selecting
the
endpoint,
basically
using
cookies
to
oh,
so,
basically,
it's
preserving.
The
idea
is,
how
do
you
talk
with
a
specific
IP
for
people
set
or
or
presentation
use
case,
which
is
very
exactly
what
you
know
kind
of
client
determining
the
actual
endpoints
that
he's
talking
with
and
we
are
discussing
the
putting
the
cookies
so
Ingress
Gateway,
East,
West,
Gateway
and
all
the
other
intermediaries
consistently
allow
clients
to
select
destination.
That.
G
C
There
are
certain
cases
like
this,
where
certain
cases
like
that,
when
they
get
a
little
bit
interesting,
especially
viewed
through
the
lens
of
you,
know
the
various
the
way
the
various
different
meshes
do
that
because
yeah
it's
they're,
pretty
easy
ways
that
sidecar
based
meshes
can
do
that
that
end
up
being
not
very
easy
ways
for
some
of
the
other
meshes
to
do
it.
So
that's
one
of
the
interesting
things
we
run
into
here,
but
Mike
I
think
a
lot
of
this
boils
down
to
yeah.
We
should
come
back
here.
A
Fair
yeah,
yeah
and
I
I
think.
The
thing
that
gives
me
like
the
most
optimism
about
this
is
that,
even
if
we
end
up
in
a
place
where
you're
not
able
to
enforce
producer
routing
configuration
you're
still
able
to
distribute
the
ability
to
author
it
to
the
owners
of
the
service.
So,
basically
because
of
Gateway
guys
like
like
role
oriented
design,
you
can
have
a
service
owner,
be
able
to
both
author,
the,
like
East-West
routing
rules
for
the
service
and
a
north
south
HTTP
route
attached
to
a
north-south
gate
right.
A
E
F
I'm
curious:
how
open
would
people
be
to
to
agree
on
a
common
protocol?
I
mean
similar
with
what
we
are
trying
with
the
HTTP
to
connect
or
mask
or
some
standard.
So
so
we
can
represent
East-West
Gateway
as
a
protocol,
and
then
different
implementation
can
can
interoperate
with
each
other's
East
West
gateways
and.
C
C
Mostly
because
every
time
I
start
thinking
about
East-West
gateways,
I
get
bound
up
with
egress
rules
and
controls
and
I
don't
want
to
think
about
that
right
now,
because
there's
enough
without
thinking
about
it,
I
think
if
I
start
thinking
too
much
about
that
I'll.
That
will
not
be
in
service
of
my
stated
goal
earlier
of
actually
completing
this
document
and
getting
into
people's
hands.
F
C
I,
don't
think
that
gamma
as
a
whole
has
put
enough
consideration
into
egress
gateways
for
us
to
meaningfully
consider
that,
within
the
scope
of
this
document,
I
completely
agree
that
we
should
try
to
not
paint
ourselves
into
Corners
around
it
and
that
gamma
as
a
whole
needs
to
put
more
thought
into
that.
But
I,
don't
think.
We've
had
enough
conversation
about
that
right
now
to
have
it
be
a
meaningful
part
of
the
scope
for
this
Gap.
A
C
C
A
So
I
guess
today,
I
was
just
trying
to
give
an
overview
of
where
I've
gotten
to
so
far
and
raise
like
attention
and
awareness
on
that,
and
what
I
would
like
to
do
is
finally
get
this.
Gap
opened
up
and
and
shared
out
for
broader
review,
and
it
possibly
makes
sense
to
split
it
up
into
a
multi-cluster
use
cases
and
a
cluster
internal
one.
A
If
that
may
be
a
more
pragmatic
way
to
start
getting
these
checks,
but
yeah,
basically
differentiating
between
routing
behavior
and
actual
authorization
like
traffic
policy,
all
C,
Behavior
I
think
it's
important
and
making
sure
that
I
think
we
are
going
to
even
if
we
have
like
client
defined
routing
Behavior,
where
the
client
is
either
the
Gateway
or
client
defined.
Routing
rules.
A
All
right-
well,
apologies
for
rambling,
so
long.
Hopefully
there
will
be
something
to
actually
review
in
the
very
near
future.
It
has
taken
a
lot
of
iteration
to
to
to
get
to
a
point,
but
I
think
it's
just
been
the
kind
of
attention
between
a
finding
a
reasonable
way
to
achieve
the
ux.
We
want
within
the
constraints
of
making
sure
this
is
something
that
will
be
implementable
across
all
the
matches
that
are
participating
in
this
and
yeah.
A
E
E
C
The
whole
policy
enforcement
thing
is
is
interesting
right
and
getting
to
a
place
where
you
could
use
open
policy
to
go
and
create
gateway
gateway.
Api
policy
and
I'd
like
to
point
out
I,
am
using
policy
in
the
sense
of
the
English
word
here.
Not
the
term
of
art
related
to
attaching
things
definitely
seems
like
something
that
would
be
interesting
to
do.
Not
gonna
lie
the
idea
of
taking
open
policy
stuff
and
translating
it
into
Envoy
filters
kind
of
scares
me,
but
that's
for
very
different
reasons
that
have
nothing
to
do
with
gamma.
C
G
The
open
service
messages
does
something
like
this
as
well
out
on
my
filter
and
I.
Didn't
think.
Seo
is
external
required
on
with
Filter,
but
I
might
be,
might
be
wrong
on
that
I
think
this
is
just
send
it
because
envoy's
got
native
support
for
sending
a
request
to
an
external
op
server.
So
it's
we're
on
by
specifically
it's
not
too
difficult
for
something
like
gamma.
It
gets
a
little
more
complicated
because
not
every
data
plane
has
have
built-in
external
off
server
construct,
and
so
it
gets.
C
B
B
E
B
Instead
of
trying
to
build
that
into
the
API
these,
the
suggestion
was
maybe
we
could
use
this
as
proof
of
concept
for
using
policy
like
Opa
specifically.
So
this
is
what
we
did.
It
just
got
stuck
and
Frozen
in
time,
but
that's
fine,
but
it's
just
an
example
of
I
think
there
are
some
valid
use
cases
where
we
don't
want
to
rely
on
API,
but
we
could
have
some
standard
Opa
policies
for
that.
A
Yeah
that
that
definitely
feels
encouraging
to
me
similar
to
some
of
the
other
policy
stuff
that
we've
talked
about
with,
like
timeouts
and
retries,
where
we
have
extended
conformance
things
that
are
maybe
defined
within
the
scope
of
say,
like
Opa.
In
this
case,
maybe
like
those
aren't
necessarily
going
to
live
in
Gateway
gun
cells.
But
maybe,
if
Opa
defines
something
that
follows
a
like
policy
attachment
that
that
it's
like
an
implication
of
policy
attachment,
crds
or
the
direct
policy
attachment,
or
something
like
that.
F
There
is
some
discussion
on
the
chat-
maybe
you
know
I
know
not
all
meshes
support
external
authorization
or
something
like
that,
but
maybe
we
should
have
some
some
common
API
for
all
meshes
that
do
have
the
concept
of
delegated
I
am
so.
Agents
like
oppa
can
be
written
in
a
vendor
neutral
way
for
the
subset
of
vendors
that
may
support
this.
E
A
Right
with
that,
I'm
gonna
wrap
it
up
for
the
day.
Thank
you,
everyone
for
listening
to
me
ramble
and
hopefully,
we'll
get
something
more
concrete
available
for
review
soon,
but
it
does
feel
like
we're
actually
making
progress
on
getting
to
a
thing.
That
is
a
distillation
of
what
is
implementable
and
pragmatic
in
terms
of
the
ux
that
we
can
offer.
A
So
thank
you
for
your
patience
and
hopefully
it
feels
like
we're
continue
to
make
progress
and
hopefully
near
being
able
to
get
gamma
promoted
to
either
intellectual
and
or
experimental
near
future.
So
I'll
definitely
appreciate
all
the
working
folks.
You
have
contributed
to
getting
Mrs
R
and
to
getting
us
not
over
the
finish
line,
but
to
getting
us
to
the
next
stop.
So
thank
you
so
much
yeah
next
Milestone
like
this
one,
take
care
and
have
a
great
day.
Y'all.