►
From YouTube: Gateway API GAMMA Meeting for 20230328
Description
Gateway API GAMMA Meeting for 20230328
A
Free
all
right,
good
morning
afternoon
or
evening
as
it
may
be,
depending
on
your
time
zone
and
welcome
everybody
to
the
March
28th
meeting
of
the
Gateway
API
camera
project.
As
a
reminder,
kubernetes
code
of
conduct
rules
are
in
effect,
so
please
respectfully,
you
can
find
the
mini
notes.
In
the
event,
invite
I'll
also
drop
a
link
in
the
chat
again.
If
anyone
who
needs
it,
it's
an
open
Agenda.
A
So
please
feel
free
to
add
any
topics
that
you're
interested
in
discussing
and
feel
free
to
add
your
name
to
the
attendees
list.
So
we
can
okay
understand
if
we
was
able
to
come
to
these
events.
As
another
reminder,
they
vary
by
time,
the
the
very
bi-weekly
at
the
time.
So
this
is
the
like
8am
Pacific
time.
This
is
going
to
be
friendly
to
an
accessible
for
EU
folks.
A
3
P.M
PST
to
be
more
converting
to
West
Coast
and
extending
over
to
Oceano
all
right
with
that.
We
can
get
into
our
recap
of
that
briefly
and
I'll
start
on
screen.
A
So
yeah,
let's
brief
recap:
from
last
week,
we
celebrated
getting
the
conformance
testing
plan,
get
merge
provisional.
Thank
you
Mike
again
for
all
your
work
on
getting
that
together,
really
appreciate
that.
A
A
We
also
Rob
covered
the
Gateway,
API
and
MCS.
So
that's
the
multi-cluster
services
API
and
that's
a
proposal.
That's
or
it's
a
gap,
that's
linked
here.
We
definitely
encourage
folks
to
look
at
that.
The
intent
is
to
kind
of
standardize
how
multi-cluster
Communications
can
happen,
including
within
gamma.
So
that's
something
that
would
definitely
appreciate
getting
more
eyes.
B
A
Because
getting
implementation
support
for
this
functionality
is
definitely
going
to
be
a
big
part
of
making
it
successful.
So
I
would
definitely
encourage
folks
to
check
out
Rob
skep
on
MCS
and
Gateway
API.
If
you
have
not
yet
and
I
guess.
The
final
thing
that
we
started
last
week
was
a
bit
of
a
discussion
around
segment
segmentation
within
a
backlit
graph.
A
I
think
that's
a
very
early
discussion,
but
if
you
have
thoughts
or
preferences
on
that
feel
free
to
check
out
the
issue
and
it's
recording
from
last
week,
if
you're
interested
in
that
functionality,
all
right,
I
see
Rob
joined
if
you
wanna
I
can
hand
it
over
to
you.
I
was
gonna
cover
briefly,
but
if
you
want
to
talk
about
the
Gateway
API,
ga
prioritization
would
love
for
you
to
kind
of
cover
that
briefly
here,
and
particularly
like
access
for
kids
to
gamma.
C
Yeah
definitely
I
would
I
would
be
happy
to
do
that.
I
thanks
thanks
for
adding
to
the
agenda.
That
was
definitely
something
like
I'd
meant
to
do
at
a
high
level.
What
we're
trying
to
do
here
is
in
the
the
main
gateway
API
project.
Do
everything
we
can
to
prioritize
a
1.0
release
in
the
next
few
months
and
for
us
1.0
means
GA
for
Gateway
class,
Gateway
and
HTTP
route,
real
focus
on
centralized
conformance
reporting
and
other
things
that
are
really
just
about
productionization.
C
We
have
so
many
great
implementations
of
the
API.
It
really
is
more
of
a
formality
to
Market
as
GA
now
I
think
these
specific
apis
are
already
quite
stable.
So
what
what
we're
saying
in
this
Doc
is
that
we
really
want.
C
You
know
every
new
feature
that
we
work
on
involves
cost
and
we
want
to
be
as
focused
as
we
possibly
can
over
the
next
few
months
on
anything
that
we
need
to
do
for
GA
and
things
that
don't
qualify
under
that
will
you
know
just
not
have
the
same
level
of
priority
with
that
said.
This
is
really
not
meant
to
impact
gamma
per
se.
C
It
is
gamma
is
still
very
much
a
priority
and
something
we
we
consider
a
parallel
effort,
so
not
trying
to
delay
gamma
in
any
way,
but
maybe
in
this
in
the
same
thought,
process.
I
think
what
gamma
is
trying
to
do
is
similar
in
the
sense
of
trying
to
do
everything
possible
to
you
know
not
expand
the
scope,
but
it
just
get
the
scope
that
exists
out
so
again
that
that's
very
similar
to
what
we're
trying
to
do
with
the
project
as
a
whole.
C
Happy
to
answer
any
questions
on
this,
but
you
know
high
level.
We
really
want
to
get
GA
release
out
soon
and
any
anything
we
can
do
to
help
with
that
is
very
appreciated.
A
Oh
thanks
for
covering
that
yeah
I
am
excited
about
that
and
I'm
sure
that
all
of
our
users
of
various
Gateway
API
applications
will
be
very
excited
to
have
that
happen
too.
A
All
right,
I,
don't
see
Sean
in
here,
yet
I
don't
know
if
Keith
he
wanted
to
briefly
cover
all
the
gamma
performance
work
that
John
had
started
because
I
think
that
you
would
work
on
it
a
bit
too
in
the
past.
D
Yeah
I
can
cover
it.
Give
a
give
it
a
brief
summary
here
so
yeah,
so
this
PR
is
also
very
exciting
kind
of
following
up
from
Mike
beaumont's
work
defining
the
testing
plan.
This
PR
actually
starts
implementing
the
conformance
tests
for
gamma.
D
D
The
overall
surface
area
of
the
changes
isn't
that
great,
but
it's
not
great,
but
isn't
that
large,
it's
pretty
much
what
you
just
expect,
but
hang
on
a
second,
my
headset
is
dying.
Yeah.
The
the
service
area
is
not
too
large,
but
the
big
thing
that
I
know
John
wanted
to
surface
here
is
the
fact
that
this
PR
kind
of
brings
in
the
istio
app
image
for
use,
as
both
the
client
and
the
server.
D
D
Where
does
the
code
for
these
images
live
all
these
various
things,
so
yeah
there's
also
the
the
ongoing
conversation
of
okay.
Well,
if
we're
gonna
have
performance
of
grpc
Route,
that's
probably
going
to
introduce
you
another
image
for
conformance
testing.
D
The
general
consensus
that
I
that
I
gather
from
yesterday
is
that
there's
a
desire
to
kind
of
collapse
that
into
one
dependency
moving
forward,
but
it
was
unclear
if
that's
a
blocker
for
this
PR
or
if
folks
are
comfortable
following
up
here.
So
that
is
the
gist
of
it.
Does
anybody
have
any
questions
or
comments
about
to
add.
C
Yeah
I
can
just
Echo
what
I
had
said
previously
as
well.
Is
that
you
know
I
think
somebody.
Somebody
raised
a
very
good
comment
in
in
the
last
in
the
meeting
yesterday,
which
is
that
I,
ideally
tests
and
their
dependencies
are
bundled
together
as
part
of
our
release
right.
So
we
would
love
to
control
as
much
as
possible
as
far
as
what
it
means
to
be
conformant,
and
ideally
that
would
include
the
images
we're
using
to
run
the
tests.
C
I'm,
not
entirely
sure
you
know
I,
think
I
think
we
all
kind
of
have
the
same
end
goal
of
hey.
Can
we
have
one
image
that
covers
all
these
capabilities
in
one
place?
I
don't
want
to
blah
I
personally,
don't
want
to
block
on
that.
You
know
that
that
is
a
good
end
goal,
but
at
the
you
know,
the
the
most
important
thing
today
is
that
we
have
meaningful
conformance
tests.
We
can
work
on.
You
know
a
a
single
image
at
some
later
point.
C
C
Yeah
costing
you
you've
got
a
good
point.
I,
don't
know
that
we
necessarily
need
just
a
single
image
I.
If
we
can,
if
there's
enough
overlap,
I
would
like
to
simplify
you
know
if,
wherever
possible,
you
know
right
now
what
we're
doing
in
our
conformance
test
framework
is.
We
have
a
a
base
set
of
infrastructure
that
we
deploy
for
everything
and
we
try
and
reuse
it
for
different
test
cases.
So
we're
not.
You
know
we
don't
have
a
x,
very
expensive
test.
C
C
E
C
Oh
yeah,
sorry,
the
the
high
level
is
I.
I,
think
an
end
goal
where
we
can
have
as
few
images
as
possible
is
is
kind
of
you
know.
C
And
and
I
and
I
was
not
trying
to
block
this
PR
on
that.
What
I
do
think
is
important
is
that
we
have
some
way
of
controlling
you
know
like
I
I'd
hate,
for
an
external
dependency
to
somehow
affect
our
conformance
tests
unexpectedly,
just
because
it
changed
and
we
didn't
we
weren't
aware,
and
you
know,
and
and
from
the
external
dependency
part,
you
know,
you'd
hate
to
unintentionally
break
something
that
you
weren't
testing
your
you
know
whatever
right
yeah.
C
So
even
if
it's
effectively
the
same
code
base,
if
there's
some
way
to
you
know,
have
a
copy.
That's
Gateway,
API
specific.
That
feels
like
a
reasonable
starting
point.
E
Yeah,
okay,
yeah,
that
no
that's
good
I
I
wanted
someone
to
basically
tell
me
what
to
do,
because
my
default
answer
will
be
just
use
the
Easter
one
because
I'm
from
Eastview.
So
it's
you
know
my
bias
but
yeah.
That
makes
sense
in
the
short
term.
E
A
Have
any
more
to
add,
but
yeah
basically
like
it's
we're.
Definitely
appreciative.
I
think
this
is
a
great
idea
to
like
jump
start,
a
conformance
testing
Suite
so
and
like
no
objections
to
the
content
of
using
this
test
Runner
but
yeah,
it's
just
like
longer
term
governance
of
it
really.
C
I,
so
that
that
was
my
other
point
I,
you
know
if,
assuming
that
this
is
a
superset,
I
I
haven't
looked
into
this
image
much
but
I'm
assuming
it
includes
an
echo
server
that
provides
meaningful
output,
yeah.
E
C
Yeah,
and
so
so
that
that
seems
like
a
thing
that
that
would
be
broadly
useful
I.
You
know,
because
we
have
so
much
shared
infrastructure
and
we're
trying
to
not
spin
up.
You
know
a
new
deployment,
a
new
set
of
pods
for
every
test
case
if
we
can
standardize
on
an
image
that
maybe
is
a
bit
heavier
weight,
but
includes
all
the
things
we
might
want
to
potentially
test.
A
Okay,
cool
thanks
for.
A
I'm
excited
for
us
to
be
able
to
start
making
progress
on
having
real
performance
tests.
This
is
exciting
up
next
Keith.
Do
you
want
to
share
a
bit
about
this
paragraph
clarification
for
gamma
I,.
D
So
this
skip
comes
out
of
an
issue
from
I
think
it
was
our
last
gamma
meeting
where,
basically,
you
know,
we,
we
spent
a
little
bit
of
time
talking
about
the
elephant
in
the
room
around
service
and
the
fact
that
most
people
here
agree
that
service
is
not
the
best
long-term
thing
to
bind
to,
but
kubernetes
release
Cadence,
as
well
as
just
the
historical,
the
ga
and
accept
the
service
resource,
is
going
to
make
it
difficult
to
to
wait
for
anything
from
kubernetes.
D
So,
oh
the
actually,
the
greater
context
of
that
conversation
was
bringing
up
gamma
for
Gateway
API
070
review
similar
to
last
time,
and-
and
we
did
this
for
060
reviewers
were
edited
about
using
service.
So
I
wrote
this
get
to
attempt
to
clarify
how
we
you
know
kind
of
the
reasoning
for
service
being
used
as
a
parent
ref,
as
well
as
what
other
kinds
of
resources
are
usable
for
parent.
For
a
paragraph,
this
gets
into
implementation
specific.
D
D
I
I
had
a
series
of
thoughts
that
I've
since
edited
down
a
bit
since
I
think
it
was
Saturday
it
popped
into
my
head,
but
wanted
to
get
folks's
opinions
on
this,
the
gist
the
high
level
ideas
here
are
that
the
parent
ref
is
the
front
end
of
the
lowercase
s
general
service,
and
that,
if
you
want
to
you,
know
the
resource
that
you
use
for
parent
ref
is
the
matching
mechanism
for
traffic
from
the
producer
route
perspective.
Does
this
route
apply
to
my
my
again?
D
Lowercase
s,
service
I
also
mentioned
service
import
a
bit
in
here
to
be
more
General,
linked
to
Rob's
PR
for
for
Multicultural
service
and
in
Gateway
API,
and
it's
listed
under
extended
conformance
the
the
kind
of
goal
that
I
had
for
this
was
to
try
to
kind
of,
let
reviewers
know
almost
implicitly
like
if
we
were
going
to
have
a
resource
and
Upstream
kubernetes
to
be
able
to
bond
with
parent
ref.
D
This
is
what
it
would
have
to
look
like
and
fulfill
spend
some
time
talking
with
Mike
talking
to
John
and
thinking
about
it
myself
and
as
excited
as
I
was
for
the
IEP
address
resource.
D
The
fact
that
it
it's
has
a
parent
ref
field
that
binds
to
Service
makes
it
a
bit
unwieldy
from
an
implementation
perspective,
as
well
as
a
ux
perspective.
When
you
know
many
people
in
kubernetes
who,
who
you
know
like
to
bring
back
the
spreadsheets
of
IP
addresses
and
what
they
could
respond
to
like
something
like
a
DNS
resource
would
be
I
think
more
in
the
right
direction,
but
that's
a
bit
of
a
digression
but
yeah
I.
The
the
this
Doc
is
linked
in
the
in
the
agenda.
D
Notes:
I'll
link
it
to
the
issue
that
I
created
last
week,
but
I'll
take
a
big
pause
here
and
let
folks
ask
questions
or
clarifications
or
tell
me,
I'm
crazy.
That's
also
welcome.
A
Cool
I
haven't
had
a
chance
to
I'll
read
through
the
updated
part
about
the
some
of
the
implications,
specific
paragraphs,
such
as
the
like
potential
for
introducing
egress
functionality
like
that
I
haven't
gotten
for
that,
but
I
I
think
in
general.
A
I
think
this
is
really
important
to
kind
of
clarify
like
the
front
end
role
and
what
we
need
something
to
implement
and
that
kind
of
like
helps
set
the
stage
for
being
able
to
use
this
stock
as
a
way
to
participate
in
any
kind
of
seeing
discussions
about
breaking
up
the
service
resource,
potentially
I
think
that
that's
really
kind
of
important
for
framing
what
do
we
need
from
it
and
how
the
various
like
some
parts,
even
if
we
don't
want
to
buy
into
IP,
addresses
the
paragraph
I
think
it
might
be
worth
bringing
back
the
mention
of
that
just
in
terms
of
like
what
it
fulfills.
A
F
Yeah,
just
just
an
idea:
I
mean
when
it
just
came
actually
just
Define
some
requirements
that
any
resource
that
we
bind
to
must
have
a
spec
and
then
IP
address
so
basically
more
like
an
interface
and
requirements
so
that
any
implementation
can
bind
to
a
resource.
F
As
long
as
that
resource
has
an
IP
in
the
spec,
but
I
don't
know
where
the
where's
the
service,
we
can
have
several
options,
so
we
can
cover
both
service
service
import
if
they
have
different
fields
because
in
reality
most
meshes
rely
on
some
form
of
Ip
regulation
perception.
So
what
we
need
to
we
need
to
that's
what
we
are
doing.
We
are
taking
an
IP
address,
so
IP
address
is
cluster
iprb
and
we
are
doing
something
with
that
traffic
if
it
matches.
A
F
A
Think
we
have
a
mention
of
that
in
maybe
13
24,
the
the
like
extrude
binding,
one
I,
think
maybe
mentions
like
the
role
of
the
front
end,
and
we
could
probably
pull
a
line
from
that
and
be
here
as
well.
I
think
that
would
be
useful,
John
I.
F
E
F
The
foreign
resource,
if
it
is
your
whatever
service
entry
full
bar,
whatever
any
implementation,
will
be
able
to
look
up
that
resource
load.
It
find
the
IP
in
some
place
and
then
we'll
know
that
it
needs
to
apply
I,
don't
know,
then
we
don't
bind
to
service.
We
bind
to
anything
that
matches
the
interface
of
having
a
cluster
IP
or
deep
or
something
in
a
specific
place.
E
I
think
there's
I
I
had
two
kind
of
concerns:
okay,
the
one
to
say
that
a
parent
has
an
IP
address.
That
is
an
implementation.
Specific
is,
is
fine,
but
to
say
that
we're
going
to
accept
arbitrary
types
like
istio
will
accept
the
console
type
without
knowing
about
it,
for
example,
because
it
kind
of
duct
types
it
to
have
an
IP
address
somewhere.
E
I.
Think
it's
problematic
controller
like
kubernetes
is
not
well
set
up
to
read
arbitrary
resources
that
we
don't
know
about
ahead
of
time.
But
it's
partly
fine
to
say,
like
Easter,
able
to
find
a
type
that
will
have
an
IP
address.
Eastview
will
support
that
as
a
parent
ref,
but
I
don't
think
we
should
expect
other
implementations
to
support
those.
E
E
The
other
thing
is
I.
Think
IP
address
is
at
least
a
good
start.
It
may
not
be
the
only
front
end
attribute
like
you
could
imagine
in
like
proxy
this
year.
Bc,
for
example,
you
don't
actually
match
on
any
IP
address
right.
You
match
another
listening,
so
I'd
be
fine,
being
more
restrictive
to
begin
with,
but
I
would
open
up
the
possibility
that
it
doesn't
need
an
IP
address.
It
just
needs
some
notion
of
front
end,
which
is
probably
an
IP
address,
or
a
DNS
name.
C
C
Usually
that
could
be
apparent,
but
would
I
don't
know
what
that
looks
like
in
mesh,
but
that
seemed
that's.
That's
a
question
that
does
seem
to
come
up
fairly.
Often
of
you
know
what
what
is
the
future
of
Gateway
in
gamma,
you
know
the
Gateway
resource,
specifically
I.
E
Think
it
really
blurs
the
line,
then
between
mesh
and
Ingress
right,
so
I
think
if
you
made
a
cluster
IP
Gateway
type,
there's
absolutely
no
reason
why
we
can't
buy
into
that.
E
Is
it
kind
of
confusing
that
sometimes
it's
this
very
kind
of
implicit
thing
and
sometimes
I?
Guess
it's
not
even
really
that
implicit,
it's
just
like?
Where
is
it
actually
actuated
like?
Do
you
have
a
dedicated
load,
balancer
instance
per
Gateway,
or
is
it
kind
of
this
messy
implicit
thing
which
the
spec
totally
leaves
open?
It's
just
today,
traditionally
I
think
people
think
of
one
Gateway.
It
means
one
load
balancer
and
it's
this
very
concrete
thing
so
I
think
from
at
least
my
opinion.
Gamma
is
perfectly
suited
for
that.
E
It
may
need
some
education
on
making
users
not
be
like
what
the
hell
is
going
on,
but
it's
perfectly
suited
for
the
model.
In
my
opinion,.
C
Yeah
and
I
I
think
that
reference
to
a
cluster
IP
Gateway
is
especially
relevant
since
I
know
you
and
I
think
Dave
are
working
on
those.
You
know
address
scope,
related
gaps
right
now,
which
would
introduce
the
concept
of
essentially
a
cluster
IP
Gateway.
Maybe
not
exactly
what
you
mean
by
cluster
IP
Gateway,
but
it
would
be
a
Gateway
that
served
a
cluster
IP
address
which
starts
to
get
especially
blurry
in
how.
E
E
Mean
it
is
close
yeah,
but
I
think
that's
still
more
for
like
at
least
in
current
implementation
for
visioning
a
traditional
Ingress
Gateway.
Whereas
if
we
did
like
the
whole
fold
on
cluster
IP
Gateway
replacement
for
service,
then
it's
like
yeah
provision,
their
DNS
name,
it's
part
of
the
mesh
there's
no
physical
infrastructure
for
it,
but
it's
definitely
one
step
on
the
path
there.
A
Yeah
I
I
think
even
just
like,
with
what
kind
of
the
scope
of
what
what
you're
currently
talking
about
with
the
Plus
for
IP
gateways
or
like
in
cluster
gateways.
Console
has
similar
needs,
whether
it's
for
like
Transit
gateways
between
clusters
or
like
bridging
to
off
cluster
resources.
Things
like
that,
like
egress
gateways,
could
be
another
way
to
implement
this.
C
Yeah
I
think
that
makes
a
lot
of
sense,
I,
I,
think
to
me
one
of
the
things
that
would
be
really
helpful
in
this
Gap
would
be
to
clarify
you
know
if
Gateway
doesn't
make
sense,
which
it
seems
like
there's
still
some
gaps
here.
Why
doesn't
it
make
sense
and
what
gaps
need
to
be
filled
for
Gateway
to
be
a
meaningful
parent
rep?
You
know
like
because
if,
if
I
were
just
you
know,
as
I
was
just
kind
of
looking
at
this,
it
seems
like
you
know,
you
know
from
a
naive
perspective.
C
F
I
have
two
points
here.
First
of
all,
I
want
to
to
make
sure
I
responded
to
John.
Maybe
we
need
to
update
our
dog.
Maybe
we
need
to
to
to
make
it
more
clear
that
an
implementation
is
free
to
instantiate
the
Gateway.
However,
it's
it
fits
I
mean
it
may
be.
One
Gateway
is
one
deployment
resource
whatever,
but
it
may
be
one
multi-tenant
shared
gateways.
That
is
you
know
whatever
it
can
be.
One
side
cut.
Sidecar
is
actually
a
Gateway.
We
run
them
way
in
istio.
F
Other
people
use
similar
heavy
gateways
next
to
the
port,
but
it's
a
valid
implementation
of
a
Gateway.
It's
nothing
specific
as
long
as
implemented
the
apis
are
when
the
tests
are
passing
and
I
would
also
mention
that,
for
example,
in
JK
is
an
internal
load
balancer,
it's
not
really
a
gateway.
F
It's
a
more
like
a
mesh
concept
Waypoint
in
history.
It's
also
kind
of
is
used
for
mesh,
not
for
traditional
Ingress
from
the
internet
to
to
boards.
So
we
kind
of
already
kind
of
in
implementation,
already
blood
the
lines
and-
and
we
are
using
Gateway
objects
to
configure
the
mesh
or
configure
internal
traffic
or
things
that
are
not
Ingress
from
the
internet.
E
E
We
program
every
side
card
to
actuate
that
and
it's
like
fully
distributed,
and
that's
perfectly
fine
I
think
that
if
we
start
using
Gateway
or
mesh
in
that
way,
we'll
just
need
to
do
a
little
bit
of
education
for
users,
because
I
think
some
people
may
be
confused
by
that.
But
I
think
that
it
is
conceptually
correct
and
it's
more
of
an
education
and
documentation
issue.
F
And
users
will
be
confused
anyway,
when
they
see
gateways
used
in
history
or
in
JK
or
in
other
places
where
there
are
actually
internal
objects
that
are
only
used
internally
for
local
traffic
and
and
we
call
them
Gateway
as
well,
so
I
think
I
think
we
we,
especially
if
we
are
flexible
in
things
that
it's
the
requirement
has
to
have
a
an
IP
address
and
Gateway
feeds
a
bill.
I
think
it
will
resolve
most
of
the
problems.
D
Yeah
I'd
be
I'm,
pretty
interested
to
hear
event
like
eventually
from
implementations
like
La
quincerty
or
those
where
the,
where
the
Gateway
might
not
be
managed
as
part
of
the
mesh,
and
you
actually
have
to
do
with
two
control
planes.
Like
you
take
the
issue
case,
then
things
get
a
bit
simpler
because
you've
got
a
single.
D
You
know.
You've
got
a
single,
a
control
plane,
typically
doing
both
jobs,
and
you
can
in
in
some
tricky
situations.
You
can
cheat
a
bit
because
you've
got
the
full
context.
This
kind
of
falls
into
the
next
agenda.
D
Item
topic
with
mac
and
Flynn
were
working
on
as
far
as
the
Gateway
and
mesh
interactions,
I
I'm
personally
I'm,
all
for
using
Gateway,
as
both
the
parent
ref
and
the
backend
ref
I
think
it
makes
a
lot
of
sense
conceptually
in
my
mind,
I
do
think
that
when
you're
in
a
situation
where
you're
manifest
we're
extra
manifests,
look
like
identical
from
the
Gateway
use
case
in
the
mesh
use
case,
but
they
might
behave
differently
implicitly,
then
you've
got
to
just
make
sure
you're
really
careful
so
yeah,
well
that
conceptually
I
don't
have
any
any
blockers.
D
I
do
think.
There's
some
education
to
be
done.
A
All
right,
so
it
feels
like
the
action
item
here
is
kind
of
like
what
I
try
to
capture
the
notes
of
like
adding
a
section
to
the
stock
about
gateways
as
a
parent
rush.
And
what
do
we
expect
them
to
be
used
for?
What
do
we
not
expect
them
to
be
used
for
yet
or
and
if
not,
why
not
and
just
kind
of
like
get
that
part
in
writing,
because
it
feels
like
a
discussion.
We've
had
come
up
several
times.
A
Yeah
I
think
this
one
of
the
things
just
like
configuration,
verbosity
I,
think
is
one
of
the
immediate
drawbacks
of
like
people
having
existing
Services
service
resources
and
adding
a
new
Gateway
resource
to
configure
all
of
them
on
top
of
HTTP
is
just
it's
one
extra
thing:
it's
not
necessarily
a
deal
breaker,
but
it
is
like
a
thing
worth.
A
Capturing
yeah,
I
think
there's
a
big
conversation
here
about
like
what's
the
future
of
the
service
resource,
and
how
can
we
potentially
split
up
that
front
end,
and
maybe
a
Gateway
is
an
answer
to
that.
So
yeah,
looking
forward
to
kind
of
seeing
how
this
comes
together.
B
You
know,
issues
is
just
kind
of
going
through
some
example
use
cases
and
then
doing
like
yaml
Snippets
that
compare
and
see.
Okay,
you
know
how
how
big
of
a
difference
is
this?
What
would
this
look
like
to
the
user
to
to
kind
of
you
know
flush
that
out
of
it.
A
A
Cool
yeah
now,
thanks
for
all
the
thoughts
and
contributions
on
that
topic
feels
like
there's
a
lot
there
potentially
so
definitely
like.
Let's
get
some
of
that
content
into
the
doc
or
leave
comments
or
leave,
notes
or
start
discussions.
A
A
A
What
kind
of
expanded
the
scope
a
little
bit
to
basically
make
sure
that
we
have
consistent
and
predictable
Behavior
across
different
boundaries,
so
kind
of
the
boundaries
that
I'm
considering
and
the
scope
of
this
is
Gateway
to
mesh
all
across
namespaces,
so
potentially
from
a
consumer
advances
with
consumer
routing
rules
to
a
news,
it's
producer
routing
rules
and
across
clusters,
as
well
so
like
within
a
cluster
set
and
the
the
file.
A
One
here
is
something
that's
not
part
of
any
spec
yet,
but
console
does
have
some
of
those
limitations
for
basically
across
the
like
cluster
set
boundary
so
like
addressing
their
services
that
are
imported,
that,
where
that
Assumption
of
sameness
does
not
apply
so
kind
of
at
a
high
level.
A
We
would
like
to
get
we're
this
once
we
get
the
stocking
shape
to
be
shared
out.
Kind
of
the
goal
is
going
to
be
getting
consensus
on.
This
is
a
ux
that
we
would
like
to
be
configurable,
Flynn
and
I
share.
The
opinion
of
it
would
be
preferable
for
things
to
be
mesh
aware,
rather
than
routing
directly
to
endpoints.
A
A
We
want
to
explicitly
enable
single
vendor
mutations
where,
like
a
single
implementation,
owns
both
of
the
Scopes
to
be
able
to
collapse,
merge
introduce
efficiencies
in
terms
of
like
how
they
make
their
routing
decisions,
whether
that's
like
pre-computing,
applying
rules
and
then
run
into
a
Civic
endpoint,
or
something
like
that.
So
we're
working
on
the
stock,
we're
not
intended
to
propose
a
concrete
API.
Yet
just
trying
to
get
contestants
on
like
this
is
the
thing
that
we
would
like
to
be.
Configurable
and
I.
A
That's
definitely
gonna
be
a
point
of
trying
to
figure
out
where
other
messes
are
at
and
kind
of
like
if
there
is
a
common
standard
or
if
this
is
something
that
perhaps
like
leans
itself
towards
introducing
the
the
off
debuted
mesh
resource
as
as
a
potential
place
for
a
required
one
of
kind
of
configuration
to
avoid
bundling
this
onto
HTTP
root
or
backend
ref,
or
anything
like
that.
So
that's
a
short
scenario
where
we're
at
now
and
yeah.
Look
for
this
coming
soon.
Pm
Austin.
F
Yeah
I
I
I
I
mean,
is
that
something
I've
been
you
know
advocating
from
the
beginning
of
the
project
and
I
think
I,
don't
know
why
what's
the
relation
with
with
the
major
resource
or
or
or
apis,
because
this
is
completely
a
protocol,
and
you
know
wire
protocols,
definition
and
agreements.
Not
anything
else.
Istio,
for
example,
is
using
is
moving
to
H1
protocol
with
HTTP
to
connect
with
some
metadata.
In
the
past
we
use
a
crazy
protocol.
Other
vendors
have
similar
protocols
that
are
specific
to
them.
F
There
is
no
way
that
istio
or
other
implementations
that
do
mpls
or
use
protocols
will
be
able
to
interoperate
with
each
other
unless
we
agree
on
a
common
protocol.
In
my
opinion,
and
no
API
is
going
to
solve
this
because
at
wire
level
you
cannot
communicate
so
maybe
with
with
plain
text,
we
don't
have
the
problem
of
mtls
and
root
certificates
and
all
the
others,
but
we
still
have
the
problem
of
of
how
do
we
encapsulate
metadata
next
to
the
TCP
streams?
F
How
do
we
do
all
the
other
stuff
that
are
protocol
related
and
if
others,
vendors
are
open
to
adopt
the
rfcs
along
around
musk
and
and
HTTP
to
connect,
then
we
can
have
at
least
a
Baseline,
and
we
can
have
one
implementations
at
least
interoperate
with
the
base
protocol,
and
then
we
can
discuss
negotiating
or
if
both
implementation
speaks
the
same
things
and
then
use
a
different
protocol.
But
I
I
really
don't
see
any
chance
for
interrupt
into
implementation
without
a
common
Protein.
That's
that's
my.
F
Protocol
so
on
RFC,
you
know
you
know
again
what
we
do
in
Eastern
and
ambient
with
HTTP
to
connect,
which
is
based
on
the
iitf
mask
rfcs
is
a
starter.
I
mean
we
are
probably
flexible
in
history
as
well.
If,
if
someone
finds
a
better
protocol,
probably
you
can
implement
it,
but
we
need
across
vendors
to
Define
one
protocol
that
we
all
support.
That's
otherwise
will
not
be
able
to
talk
with
each
other.
A
A
We've
done
early
Explorations
here
years
ago,
with
some
little
like
Hamlet,
spec,
stuff
too,
but
yeah
so
I
I'm
not
intended
to
cover
the
actual
like
protocol,
specifics
more
of
like
how
L7
routing
rules
are
applied
and
where
those
are
applied,
and
things
like
configuration
sync
across
clusters
versus
applying
those
like
through
a
Gateway
of
some
sort
when
you're
doing
multi-cluster
things
for
for
namespaces,
like
routing
having
like
only
consumer
rules,
apply
versus
the
like
merged
state
of
consumer
and
then
producer
roles
and
save
for
Gateway,
like
basically
being
mesh
aware
and
like
respecting
a
gamma
service
configuration
and
like
any
splits
to
make
you
compare
to
that
level
versus
routing
just
to
like
the
back
end
endpoints
of
a
service,
so
that
that's
kind
of
the
scope
and
yes,
I,
think
that
that's
the
like
protocol
thing
is
a
step
past
that
that
we
will
hopefully
get
to
at
some
point,
but
not
a
not
in
scope
for
this
right
now.
F
Well,
I,
don't
see
how
I
mean
if,
if
we
don't
have
the
protocol,
I
don't
know
how
we
can
test
anything
else.
I
mean
it's.
How
is
the
conformance
test
or
anything
that
that
is
practical
for
users?
Will
work,
but
okay
I
mean
any
order.
We
do
at
the
end
of
the
day.
If
we
don't
have,
the
protocol
should
not
be
able
to
have
two
mesh
implementation
is
the
same.
Cluster
sets
only.
A
Somewhere
yeah
I
I
think
to
clarify
the
scope
that
I'm
focused
on
right
now
is
within
a
single
implementation
and
when
we
get
to
multiple
implementations
or
traffic
between
implementations,
that's
definitely
going
to
be
yeah
like
one
of
the
first
building
blocks,
it's
kind
of
how
to
negotiate
and
do
that.
F
A
B
A
B
A
Yes
and
like
mesh
routing
between
name
spaces,
mesh
routing
between
clusters
in
the
cluster
set
basically
trying
to
have
a
consistent
behavior.
That
is,
that,
like
matches
users,
expectations
for
all
of
these
different,
like
boundary,
Crossing
type,
routing.
B
No,
it
makes
sense.
That's
definitely
important
to
solidify
that.
A
If
there's
nothing
else,
we
want
to
come
during
this
time.
I'll
wrap
up
15
minutes
early.
Thank
you
very
much
everyone
for
taking
time
to
join
and
Report.
The
conversation
today
take
care
have
a
good
rest
of
your
day.
Thank
you.
Thanks
foreign.