►
From YouTube: SIG Network Gateway API meeting for 20230206
Description
SIG Network Gateway API meeting for 20230206
A
All
right
welcome
to
the
Gateway
API
meeting
for
February
6
2023..
We've
got
lots
and
lots
to
get
through,
but
before
I
go
any
further.
I
just
want
to
welcome
everyone.
This
is
a
kubernetes
community
meeting.
We
abide
by
the
same
code
of
conduct
as
the
rest
of
the
community.
Largely
just
means
be
nice
to
each
other,
yeah
very
straightforward.
This
agenda,
I
hope
everyone
can
has
a
link
to
it.
A
If
you
don't
I'll
drop
it
in
chat,
anyone
should
feel
welcome
to
add
things
to
the
agenda
at
any
point
or
drop,
something
in
chat,
whatever's,
easiest
and
we'll
try
and
get
to
it.
But
with
that
I
think
the
first
thing
we
we
have
on
the
agenda
is
this
egress
discussion
and
Philip
I.
Think
I
see
you
on
the
call.
Maybe
you
can
provide
a
little
bit
of
background
about
this
sure.
B
Sure
yeah
so
sort
of
how
we
got
here:
I
I,
so
I'm
a
product
manager
at
F5
and
I
focus
on
service
provider,
Communication
service
provider
stuff,
and
we
really
have
we've
built
a
product.
That's
really
about
how
to
make
kubernetes
work
better
for
service
providers.
B
You
know
primarily
for
like
launching
5G,
so
you
know
service
providers
for
the
first
time
like
mobile
telephone
companies,
let's
call
them
for
the
first
time,
they're
really
trying
to
move
into
using
Cloud
native
practices
and,
of
course,
kubernetes
is
sort
of
the
main
tool
for
that
and
so
I'm
coming
at
it
very
much
from
a
you
know,
sort
of
where
are
the
gaps
in
kubernetes
networking
that
make
it
difficult
for
these
telcos
to
launch
5G
or
other?
B
You
know
kinds
of
what
we
call
Network
functions
at
F5.
We
also
have
you
know
other
folks,
like
the
nginx
guys,
you
know
who
have
sort
of
a
broader
remit
and
are
working
more.
You
know
with
the
Enterprises
and
stuff
I
I
wrote
this
egress
thing
primarily
from
a
service
provider
kind
of
Telco
point
of
view,
because
this
is
one
of
one
of
the
biggest
gaps
that
we've
uncovered
and
I
can
go
into
the
gaps
more
generally
and
I
think
I
kind
of
put
some
of
it
into
the
document.
B
But
you
know
telcos
in
general,
they're
very
sensitive
to
things
that
are
below
layer.
Seven
like
IP
addresses,
and
you
know
different
protocols.
B
B
The
major
problems
that
they
face
around
that
are
related
to
egress
and
if
you
were
or
the
numbering
starts,
and
essentially
you
know,
one
of
the
problems
is
that
the
you
know
the
applications
that
these
service
providers
are
launching
are
networking
applications,
and
there
is,
you
know
some
Legacy
aspect
to
it
and
some
just
sort
of
you
know
just
by
the
nature
of
being
a
networking
application
matters.
So,
for
example,
you
know
IP
addressing
is
really
important.
B
You
know
it
can
take
six
weeks
of
IP
engineering
to
determine
what
IP
addresses
to
use
for
a
new
network
element,
that's
being
introduced,
and
so
you
know
having
the
correct
IP
address
as
the
source
for
ad
traffic
as
it
egresses
is
super
important.
So
one
of
the
key
use
cases
that
we
Implement
is
what
we
call
egress
snaps,
where
egressing
traffic
gets
snatted
to
well-known
IP
addresses
for
that
Network
function
and.
B
On
a
like
a
namespace
by
name
space
basis,
and
that
seems
to
be
working
for
for
for
the
telcos
it
also.
One
of
the
other
issues
is
that
their
Network
functions
aren't
sort
of
just
a
bunch
of
apis.
B
That
really
kind
of
meant
to
be
like
a
singular
Network
function
that
both
calls
out
and
receives,
and
so
having
the
traffic
go
through.
The
same
logical
elements
like
a
Gateway
is
helpful.
B
I
mean
part
of
it's
for
things
like
you
know,
coordinating
IP
addresses,
like
I,
said
before
part
of
it's
also
for
like
just
coordinating
policies
that
you're
going
to
apply,
and
you
want
to
be
consistent
for
ingressing
and
egressing
traffic
and
not
have
to
totally
set
network
paths
and
then
there's
some
sort
of
more
kind
of
edgy
cases
around
ipv4,
V6,
translation
and
then
just
the
fact
that
you
know
the
telcos
have
very
complex
networks
outside
of
and
network
domains
outside
of
the
cluster.
B
So
a
cluster,
you
know
you
may
have
traffic,
that's
egressing
toward
you
know
several
different
domains
that
aren't
routable
to
each
other
and
that
have
to
pass
through
different
firewalls.
B
So
we
actually
apply
like
Source
mat,
addressing
based
on
the
destination
that
you're
you're,
headed
to
in
the
network
domain,
I,
think
and-
and
so
I
talked
in
here-
a
little
bit
also
about
our
implementation,
not
so
much
because
I'm
recommending
that
that's
the
way
everybody
has
to
do
it,
but
to
kind
of
just
to
help
illustrate
some
of
the
pain
points
of
that
we
ran
into
while
trying
to
Implement
egress
controls
like
how
to
coordinate
with
the
cni.
B
Because,
generally
the
cni
is,
you
know,
sort
of
determining
what's
happening
with
egressing
traffic,
and
we
went
through
a
couple
of
different
iterations
on
that,
where
we
either
did
custom
development
with
the
cni
so
like
with
red
hat
with
their
ovn
kubernetes
that
they
include
with
openshift.
They
did
some
sort
of
custom
logic
with
us
that
they're
going
to
now
be
gaing
as
a
as
a
feature
called
multiple
external
gateways.
B
We
were
looking
at
whether
we
wanted
to
modify
like
Calico,
and
you
know
how
how
we
wanted
to
do
this
if
we
wanted
to
do
it
on
a
cni
per
cni
basis,
and
we've
been
working
on
a
couple
of
strategies
that
we
call
cni
Independence
to
try
and
sort
of
shortcut
the
cni
to
funnel
heat
press
traffic
toward
the
right,
Gateway
and
I
I
kind
of
explained.
Some
of
that
in
the
in
the
form
or
further
down
in
the
dock.
A
Yeah
this
is
this
is
really
great.
Thank
you,
for
you
know,
writing
this
up
and
getting
the
conversation
started.
It
is
helpful
to
see
how
you're
using
this
you
know
how
how
you're
implementing
Ingress
today
I
think.
One
of
my
questions
here
is:
how
do
you
I
guess?
B
I
would
think
that
you
would
Implement
an
egress
route,
egress
routes
and
I.
Think
probably
you
wouldn't
necessarily
make
it
a
mandatory
part
of
the
you
know:
they're
the
whatever
three
levels
right,
there's
the
the
mandatory
the
optional
and
the
custom
I
think
you'd
make
it.
You
know
optional
stuff,
because
probably
you
know
a
lot
of
gateways.
B
Don't
you
know
are
not
that
interested
in
egress
and
there
is
some
additional
trouble
in
it,
but
I
would
leave
I
would
leave
the
particulars
to
how
you
get
the
traffic
maybe
up
to
the
implementation,
because,
like
we're
looking
at
doing
it
with
service
mesh,
we
also
have
this
sort
of
mini
cni
that
can
sort
of
shortcut
traffic.
That's
going
to
egress
and
you
know
funnel
all
the
non-egressing
traffic
toward
the
primary
cni,
Calico
or
whatever,
but
but
send
the
egressing
traffic
toward
our
Gateway
I.
B
A
A
It
sounds
like
the
problems
that
you're
trying
to
solve.
Are
you
know
fairly
low
level?
It
seems
like
you're
you're
primarily
focused
on
IP
routing
is.
Is
that
correct
that
you
know
not
so
much.
B
Yes,
so
so
I
think
it's
a
little
bit
analogous
to
like
so
part
of
it
is
just
getting
the
traffic
to
the
same
Gateway
right
and
then
you
know
just
like
with
CCP
route
like
with
TCP
route,
you
don't
have
to
specify
the
IP
addresses
directly
like
you
know,
you
can
have
some
more
custom
work
there
once
once
the
traffic
is
going
to
the
same
Gateway,
but
like
again
for
policies,
one
one
of
the
things
we're
very
interested
in
doing
is
expanding,
how
you
do
policies
and
having
like
we're,
implementing
firewall
and
application
firewall
and
other
kinds
of
policies
on
top
of
our
routes,
and
so
you
know
for
egress
I'd
like
to
be
able
to
do.
B
You
know
a
lot
of
our
customers.
Let
me
put
it
this
way.
A
lot
of
our
customers
want
to
collapse,
their
firewall
infrastructure
down
closer
to
their
applications,
and
so
right
now,
if
you
have
a
cluster
that
has
you
know
various
Network
functions
running
in
it
all
of
the
firewalls
that
are
around.
B
It
have
to
be
configured
for
each
of
those
applications
and
again
for
each
different
network
domain,
blah
blah
blah
and
it's
very
hard
to
do
that
stuff,
using
like
kubernetes
Network
policies,
guys
from
Verizon
I,
just
got
off
a
call
from
the
guy
from
Verizon
who
said,
use
some
salty
language
about
trying
to
do
it
with
kubernetes
network
policies
right.
B
But
if
you
can
funnel
it
all
through
the
Gateway,
you
can
apply
consistent
policies
on
either
L4
type
firewalls
like
ACLS
and
the
applications,
but
also
application.
Firewalls,
where
you
are,
you
know,
checking
maybe
the
API
both
directions
but
yeah,
absolutely
more
than
just
the
snap
thing
is
the
single
highest
priority,
but
then
having
it
in
a
consistent
place
to
apply
consistent
policy
is
probably
the
second
highest.
E
And
actually,
there
is
scope
for
at
least
from
my
perspective,
there
is
scope
for
this
to
venture
into
the
HTTP
land
as
well.
E
Knowing
you
know
at
which
point
like
in
the
classic
icap
over
days
of
old
right,
there's
a
pre-cache
filter,
post-cash,
filter,
pre-cash,
request,
post-cash,
request,
precache
response,
post
cash
response
hooks
for
applying
security
policies
like
this
is
in
the
late
90s
early
2000s
I
think
there
is
scope
Force
many
of
those
things
to
be
applicable
via
egress
policies
as
well
and
having
a
distinct
degrees.
Increased
route
allows
us
to
make
that
distinction.
E
A
F
No
go
ahead,
we
should
would
you
also
want
to
build
to
route
on
5G
protocols
like
gtpc,
gdpu
escp?
Is
that
yeah.
B
What
we
currently
do,
we
have
L7
Ingress
crds
for
those,
so
we
have
Sip
and
GTP
and
pfcp
we're
actually
finishing
pscp,
but
you
know
in
gap
all
of
us,
those
Elco
protocols
and
at
the
moment,
with
egress,
we
just
were
just
doing
The
L4
treatment.
So
we
don't
do
much
with
that,
except
for
the
protocols
that
specifically
need
to
have
ingression
dress
together
like
diameter
again
for
those
of
you
who
aren't
into
Telco.
This
is
you
know.
B
B
E
Right
having
it
applied
in
a
symmetric
manner
can
lead
to
potential
holes
being
exposed
like
if
you,
if
you
think
that
the
rule
is
applicable
to
Ingress
and
it
now,
depending
on
the
form
of
the
rule,
it
catches
an
egress
and
expose,
does
something
you
don't
intend
to
do.
Those
kind
of
issues
can
be
resolved
by
having
them
separate.
B
All
up
after
you,
it's
just
the
you
know,
the
role
of
the
Ingress
is
to
take
some
kind
of
traffic
from
the
outside
and
direct
it.
To
you
know
a
service
right
and
egress
doesn't
necessarily
have
a
service
and
egress
doesn't,
isn't
you
know
you're
not
specifying
like
in
a
in
an
egress
route.
You
wouldn't
be
specifying
where
it
goes
to
you
just
be
saying
where
it
goes
via
right,
you'd
be
saying
it
goes
via
the
Gateway,
not
that
it
goes
to
a
service
like
an
Ingress.
A
We
have
a
fair
number
of
people
on
the
call
I
wanted
to
see
if
there
are
other
implementations
represented
here
that
have
been
considering
L7
egress
routing,
because
you
know
be
helpful
as
we're
developing
this
to
to
not
just
think
of
of
you
know
a
couple
layers,
but
you
know
if
we're
also
inevitably
going
to
go
to
L7
to
you
know,
think
holistically
Sean.
It
looks
like
you've
been
thinking
about
that
with
istio.
H
D
Yep,
that's
all
too
yeah.
Is
there
any
chance
that
we
could
see?
There's
there
are
a
lot
of
different
use
cases
in
that
document,
which
is
pretty
cool.
It
would
be
really
interesting
to
see
some
more
specifics
on
I
don't
know.
D
I
think
that,
at
least
for
me
it
would
be
very
helpful
to
see
some
more
of
the
details
on
some
of
these
things.
Thank
you.
B
Okay,
stupid
yeah,
we
can
do
that.
I
mean
I.
Think
we're
already
like
we're
kind
of
hoping
that
our
transition
to
to
the
Gateway
API
from
our
crds
will
help
us
kind
of
clean
some
things
up
like
like
our.
We
have
one
big
massive
egress
crd
and
it's
got
a
lot
of
stuff
in
it.
It's
got
it.
D
B
Yeah,
that's
true,
that's
true,
yeah!
No,
absolutely,
and
we
can
show
you
you
know
yeah.
We
can
show
you
the
setup
that
we
use
for
egress
and
how
it
integrates
with
our
different.
You
know,
Ingress
stuffs
and
how
we
configure
our
vlans,
and
you
know
we
we
label
each
of
our
Network
domains.
We
call
them
VMS,
even
though
you
know
they
can
be
vlans
or
verbs
or
whatever.
F
Almost
like
a
generic
mailbox
solution,
I
mean
this
is
where
you're
using
kubernetes
as
a
service
provider,
I
use,
providing
5G
Services,
there's
not
an
end
point.
It's
more
is
going
through
and
then
going
someplace
else.
B
B
That
is
an
excellent
question,
because
the
way
5G
is
laid
out
is
there
are
two
parts
to
a
five,
so
they're,
they're
sort
of
three
parts
to
5G,
there's
fudgy,
radio
at
least
and
a
lot
of
people
are
implementing
5G
radio
and
they
don't
need
any
of
this
stuff
right,
they're,
just
adding
a
new
radio
at
the
far
end
and
if
you're
using
a
phone
and
it
pops
up
and
says
5G
you're,
probably
just
getting
5G
radio,
then
there's
the
5G
core,
which
is
broken
apart
into
two
parts:
there's
the
user
plane,
which
is
the
pass-through
stuff
you're
talking
about
where
you
know,
when
you
go
to
browse
on
your
phone,
it
passes
through
there
on
the
way
to
the
internet
and
then
there's
the
control
plane
where
all
the
signaling
happens,
to
establish
your
mobile
Mobility
session
to
establish
your
qos
for
phone
calls
to
track
the
bytes
you're
using
all
of
that
kind
of
control,
stuff
control,
how
you're
text
messages
get
sent
through
right
now,
we're
focused
mostly
on
that
control,
plane
stuff,
and
so
it's
not
a
pass-through.
B
F
B
Yeah
I
wouldn't
call
it
service,
chaining,
service,
chaining
kind
of
implies
that
you're,
taking
the
same
information
and
kind
of
passing
it
through
and
doing
different
things
to
it,
at
least
in
in
5G
and
a
lot
of
Telco.
But
it's
more
like
you
know,
I
want
to
look
up
information
about
the
subscriber.
Oh
then
I
want
to
tell
this
element
that
he's
connecting.
Then
that
element
wants
to
tell
somebody
else.
You
know
find
out
from
that
person
anywhere.
B
You
know
what
calories
on
and
then
it
sends
it
back,
and
then
that
allows
the
other
guy
to
send
something
back
to
you.
But
it's
all
like
call
establishment
that
kind
of
stuff.
F
A
I
I
do
want
to
agree
with
what
Shane
dropped
in
chat
there,
that
we
are
probably
close
to
a
time
check.
So
what
would
be
most
helpful
now
is
just
figuring
out
what
what
we
should
do
next,
one
of
the
things
that
seems
pretty
clear
to
me
is
that
this
is
a
very
good
start,
but
that
there
are
other
use
cases,
especially
when
we're
talking
about
different
players
that
have
not
been
covered.
A
B
I
think
I'd
put
a
little
line
at
the
bottom
after
I
was
done,
typing
I
I.
Think,
like
I,
put
a
bunch
of
telcos
that
if
somebody
has
something
more
to
say
about
Telco
added
up
there
and
if
we've
got
other
use
cases
that,
like
I,
wasn't
covering
at
all
something
totally
different
or
brand
new,
you
know
put
it
below
the
line.
B
I
don't
know.
Does.
A
That
sound
okay,
yeah,
that
I
think
that's
reasonable,
I
think
John
and
Mike
both
mentioned
that
they
were
interested
in.
You
know:
L7
egress
configuration
so
maybe
if
we
can
start
collecting
some
of
the
use
cases
for
that,
at
least
to
start
in
this
talk
and
then
we
can
go
from
there
and
then
you
know
I
think
the
other
thing
that
I
saw
mentioned
in
chat
a
lot
is,
if
there's
some
way
to
diagram
this
or
give
some
more
examples,
I
think
that
would
go
a
really
long
ways.
B
A
Okay,
great
I
think
we've
got
the
pretty
clear
follow-ups,
then
any
any
action
items
I
I
missed
here.
B
I'll
keep
on
going
just
at
a
high
level,
though
I'm
gonna
add
some
diagrams.
Other
people
can
add
things
here
about
use
cases
that
they
see
and
then
we'll
use
that
process
to
start
distilling
who's
interested
in
actually
working
on
this
right,
and
then
we
start
defining
what
it
would
look
like.
Okay,.
A
Great
well
yeah,
thank
you
for
starting
this
discussion.
I
know
I
know
it's
been
on.
You
know,
on
my
mind,
for
a
while
just
have
not
had
the
time
to
to
push
it
forward,
so
glad
to
glad
to
see
this
moving
and
yeah.
Definitely
we
can
follow
up
next
week.
Hopefully
we'll
get
a
a
bit
more
progress
in
between
and
see
where
we
go
from
there
all
right.
Thank
you
again.
A
A
Maybe
we'll
come
back
yeah.
We
can
come
back
up
all
right
Shane
if
you're
around.
Let's
go.
Let's
talk
about
061
release.
C
Yeah
sounds
good,
sorry
in
advance,
because
I'm
sick,
again
so
I,
probably
sound
horrible,
so
Gateway
API
v061,
is
going
to
release
this
week
most
likely
tomorrow,
and
it's
going
to
include
predominantly
updates
for
conformance
tests,
so
just
be
on
the
lookout
for
that.
From
here
on,
you
should
probably
start
seeing
faster
releases
more
releases
because
we're
going
to
try
to
do
those
at
a
more
regular
Cadence.
C
Yeah,
if
there's
no
comments
or
anything
about
thank
you
Flynn
and
then
blixt,
which
is
a
project
that
is
being
a
it,
is
a
implementation
of
Gateway
API,
which
will
be
used
for
reference
and
testing
in
Gateway.
Api
is
about
ready
to
get
its
first
release.
C
We
are
at
the
point
where
we
have
a
basic
level
of
support
for
UDP
route
that
should
at
least
make
it
possible
to
just
start
using
it
at
a
basic
level
and
that
usage
in
Gateway
API
CI
feedback
into
the
changes
that
we
need
to
make
going
forward
until
we're
at
a
point
where
it
covers
a
decent
amount
of
conformance.
A
Great
thanks
yeah,
exciting
to
see
a
old
hot
One
release
coming
soon,
and
it
will
be
great
to
have
it
in
CI.
One
thing
on
the
061
release:
I
just
want
to
make
sure
I.
Remember
this
correctly.
I
think
what
we're
doing
is
anything
that
is
labeled
in
the
061
Milestone.
So
there's
a
PR
that
has
the
061
Milestone
on
it.
A
C
This
is
yes,
this
is
the
one
that
was
meant
to
be
neutral
because
it's
based
on
Gateway
API.
It's
an
only
a
Gateway
API
implementation
on
the
control
plane
and
it's
Linux
kernel
for
the
data
plane
using
eppf.
So
that
is
what
we're
going
to
start
plugging
into
the
CI
to
get
started.
It's
not
going
to
get
us
everything
we
want.
As
a
matter
of
fact,
it's
not
going
to
get
us
a
whole
lot
day.
One
but
it'll
get
us
started
on
some.
C
Some
of
the
basics,
particularly
things
around
like
Gateway,
and
then
some
of
the
statuses
and
stuff
like
that
for
Route
attachment
can
be
done
with
layer,
4
routes.
We
are
talking
about
adding
TLS
route
support
for
it
in
time.
That's
going
to
be
interesting
and
then
the
at
some
point
we
would
consider,
maybe
starting
to
add
something
layer
7
to
it.
That
was
just
there
so
that
we
could
do
some
testing,
but
wouldn't
actually
be
like
a
good
implementation.
H
C
No,
no,
the
goal
is
that
the
conformance
tests
will
actually
run
on
PRS
so
that
you
can't
you're
not
as
easily
breaking
things
like.
If
you
make
a
change
that
touches
well
anything
that
that
would
suddenly
be
out
of
conformance
right
now.
Today
we
don't
catch
that
so
with
licks,
we
would
in
Theory
start
catching
those
more
often
right.
H
C
H
C
A
Yeah
I
don't
think
that
we've
decided
on
the
correct
order
of
operations
there,
but
that
is
a
good
point.
I
think
one
of
the
things
that
blixt
offers
that
is
is
very
important
is
right.
Now
we
have
a
a
gap
in
terms
of
L4.
Implementations
of
the
API
and
bleaks
allows
us
to
kind
of
push
forward
with
conformance
tests
and-
and
you
know,
implementation
quickly
with
that.
But
I
I
agree
that
we
have
to
be
careful,
adding
any
prerequisites
to
new
features.
H
A
H
And
you
know,
honestly
in
case
I'm
trying
to
avoid
is
like
okay,
I'd
be
old
and
then
I
have
to
go,
modify
this
random
project
that
I
don't
really
care
about
no
offense
dad
my
field
so
that
it
passes
test,
whereas,
like
you
know
it
becomes
a
bottleneck.
No.
C
F
C
To
be
a
problem,
we'll
have
to
talk
about
that
and
see
what
the
solution
is.
I,
don't
know
if
we
need
to
hold
up
the
meeting
for
it,
but
we
can
definitely
go
offline
and
say
what
is
a
good
compromise
there?
Is
it
really
untenable
for
there
to
have
to
be
some
situations
where
you
need
to
update
that
implementation?
I
can
understand
that.
A
So
one
of
one
of
the
things
just
you
know
this
is
in
my
own
personal,
workflow
and
and
I
think
we've
we've
talked
about
this
earlier
is
I.
Think
many
of
us
were
reviewing
conformance
tests
will
take
the
pr
and
manually
run.
It
run
it
against
a
few
implementations
to
see
how
it
does
it
seems
like
it
would
be
really
nice
to
have
some
on-demand
need
jobs
available
to
do
that
for
us,
that
is,
that
is
entirely
possible.
I
think
that
may
be
a
good
way
to
integrate
bleaks
tier.
A
But
again,
let's
you
know
that
this
is.
We
can
follow
up,
but
I
I
think.
C
G
A
G
I
So
when
it
comes
to
policy
attachments,
we
were
discussing
this
in
gamma
last
week,
and
we
were
talking
about
you,
know,
connection
settings
and
things
that
you
know
a
message:
implementation,
not
research
policy
attachment
so
to
represent,
and
it
it.
It
came
up
in
that
in
that
discussion
that
there's
seems
to
be
a
little
bit
of
hesitation
to
use
policy
attachments
for
a
for
a
couple
of
reasons.
One
of
them,
on
my
end
personally
is
is
crd
proliferation.
I
You
know
to
create
a
a
new
policy
of
any
sort
you
commit
to
a
new
resource
that
is
an
iPod
or
API
that
you
have
to
you
have
to
maintain,
and
you
know,
for
especially
you
know,
a
lot
of
messages
take
a
lot
of
take
Flack
for
having
you
know
too
many
crds.
Now
you
know
to
be
able
to
express
policy.
You
have
to
add
one
for
each
kind
of
policy
that
you're
wanting
to
represent
at
least
based.
I
I
It's
really
useful
for
a
lot
of
a
lot
of
use
cases,
but
in
in
Metro
we're
not
using
at
least
at
this
point
Gateway
and
Gateway
class
and
listener,
there's
fewer
rungs,
fewer
levels
of
the
hierarchy
and
so
that
framework
can
kind
of
feel
can
feel
a
bit
heavy.
I
So
that
and
I
know,
there's
a
lot
of
been
a
lot
of
thought
about
meta
resources
and
Nick
is
working
on
that
on
that
Gap
I've
seen
a
couple
of
PRS
and
for
that,
but
to
kind
of
help
put
you
in
the
in
the
mindset
that
we
were
that
we
were
in
last
week.
One
of
the
you
know
you
talk
about
connection
settings
on
HTTP
2
like
when
window
size,
I
believe
and
some
other
things.
The
another
example
that
came
up
on
the
opposite
end
of
that.
I
That's
a
little
bit
easier
to
imagine
a
user
wanting
to
tweak
is
timeouts.
You
know,
timeouts
are
so
hard
to.
You
know
to
get
consistent
across
different
data
plan.
Implementations
totally
totally
get
that,
but
you
know
as
a
particular
mesh.
You
know
implementation
like
with
osm
the
idea
of
having
to
go
and
if
I
want
to
represent
timeouts
to
my
for
My
Oh.
I
If
I
want
my
users,
favorite
timeouts
I
have
to
create
an
new
crd
and
I
have
to
version
that
and
I
have
to
start
thinking
about
defaults
and
overrides
just
to
get
the
very
first
iteration
of
that
of
that
feature,
and
so
I
guess
I
wanna.
We
we
just
decided
it
would
be
a
good
idea
to
bring
this
up
to
the
MonDay
meeting
for
a
general
audience.
Policy
attachment
is
one
of
those
things
that
hasn't
been
used
a
ton.
I
It's
not
a
really
great,
like
usage
of
it
in
the
wild,
and
that's
one
of
the
areas
I've
been
hoping
that
that
that
gamma
could
do
some
exploration
in,
and
this
is
kind
of
our
early
early
feedback
talking
through
the
possibility
of
doing
something
real
with
it.
So
I
wanted
to
know
if
anybody
else
has
had
similar
thoughts
or
concerns
and
just
kind
of
get
some
some
other
feedback
on
our
feedback.
A
Yeah
this
is
this
is
really
good.
I
agree
with
much
of
what
you're
saying
here:
I
I,
completely
understand
the
the
fear
of
just
having
too
many
crds
and
crds
are
paying
to
manage
both
from
implementation
and
the
user
side,
so
so
I
get
it
and,
and
then
I
I
also
get
that
you
know.
Policy
attachment
model
today
is
wildly
flexible,
which
is
you
know
it.
A
It
meets
many
of
the
most
advanced
use
cases,
but
also
introduces
lots
of
complexity
to
get
there
I,
so
so
I
get
both
of
those
I.
Think
Nick's,
meta
resource
idea
of
you
know
basically
at
least
the
way
I
understand
it
of
just
a
a
resource
that
decorates
or
extends
a
single
kind
of
resource,
or
you
know
like
one
resource
at
a
time
without
any
kind
of
hierarchy,
is
very
interesting
that
that
probably
works
well
for
a
lot
of
use
cases.
A
So
so
that's
definitely
a
good.
You
know.
Directional
thing
I
also
want
to
highlight
some
discussion.
That's
happened
at
least
in
Envoy
land
I
know
not
every
mesh
implementation,
not
every
Ingress.
Implementation
is
Envoy
based,
but
a
lot
are,
and
so,
if
you
happen
to
have,
you
know
like
timeout,
is
a
great
example
that
everyone,
but
the
reason
these
things
aren't.
You
know
something
we
can
put
in
Gateway.
Api
is
because
we
have
lots
of
underlying
implementations.
D
A
D
A
Yeah
yeah,
no
I,
I
I
thought
timeout
would
be
so
easy
to
express
and
then
I
I
dug
into
it
and
looked
you
know.
I
was
comparing
nginx
Envoy
and
aha
proxy
at
the
time
and
there's
almost
no
overlap
in
terms
of
the
configurable
timeouts.
If
you,
if
you
actually
read
the
very
specific
details
of
what
each
timeout
means,
but
I
yeah.
D
G
Bowie
yeah,
so
I
think
the
one
question
would
be.
We
did
go
through
this
exercise.
So
what
would
I'm?
Assuming
that
you
know
it
is
possible
that
you
come
to
a
different
conclusion.
But
what
what?
What
is
different,
this
time,
that
that's
something
that
comes
to
mind
in
terms
of
evaluating,
for
example,
something
like
timeouts
and
abstracting
them.
I
I
think
our
feedback
isn't
so
much
that
timeout
should
be
a
part
of
HTTP
route.
It's
that-
and
I
mentioned
this
in
the
meeting
last
week
from
the
beginning
meeting
rather
I
feel
myself
reaching
for
something
lighter
than
policy
attachments,
but
not
as
I
guess
final
or
are
General
as
HTTP
route
or
or
any
x
route
in
the
family.
I
Like
rob,
you
mentioned,
like
Nick's
meta
resource,
is
very
intriguing
to
me
that
perhaps
there
is
maybe
we're
starting
to
talk
about
something.
That's
a
concrete
example
of
a
meta
resource.
I
That's
not
policy
attachments
that
solves
a
little
bit
smaller
use
case
because,
again
from
from
mesh
world,
there's
a
lot
that
we
want
to
express
that
we
know
probably
is
not
going
to
be
in
the
core.
Ap
core
is
overloaded,
but
the
the
main
HTTP
route
like
API,
but
we
want
to
be
able
to
get
stuff
out
there
for
users
to
configure
these
use
cases
and
we're
trying
to
find
a
spot
to
put
that.
Does
that
help.
D
D
The
mesh
implementations
really
should
be
things
where
a
lot
of
what
you
want
should
be
a
surface
area
where
the
user
does
not
have
to
configure
it
where
the
defaults
make
sense,
but
you
occasionally
want
to
tweak
something,
and
so
they
end
up
feeling
pretty
different,
and
a
lot
of
us
ended
up
kind
of
feeling
like
yeah
Simplicity
is
really
good
and
we
would
like
to
find
something
that
does
not
need
the
complexity
of
policy
attachment
and
again
you
know
there
are
several
I
see
several
faces
here
that
were
there
in
the
gamma
meeting,
so
you
think
I
ever
stated.
J
Yeah
I
just
wanted
to
kind
of
mention
they
hear
a
lot
of
like
these
implementations.
Don't
do
X
or
they're,
so
wildly
different.
I.
Think
a
good
perspective
is
to
think
of
end
users.
J
What
is
beneficial
to
them
and
potentially
like
maybe
they
are
different,
unique,
but
you're
also
setting
a
standard
as
part
of
the
working
group,
and
if
you
can
say
80
of
the
use
cases
are
just
by
the
standard,
then
you
could
probably
create,
for
example,
timeout
Fields
retry
Fields,
like
as
generic
policy
put
it
in,
like
I,
guess
extended
conformance
until
these
other
implementations
to
catch
up
right
and
then
yeah.
What's
great
for
me
as
an
end
user
is
then
we
have
portability
like
I.
J
Don't
I
can
have
one
app
deployed
here
and
use
this
implementation
when
I
transition
to
some
other
distribution
or
implementation,
like
these
definitions
or
my
timeouts
and
retries
will
just
continue
working
because
I
know
like
this
group
has
set
the
standard
and
implementations
will
like
change
the
functionality
to
fit
that
standard.
You
know
what
I
mean.
A
Yep
that
makes
sense,
I
I
do
want
to
time
box
this,
but
I'll,
let
Mike
go
next
and
then
maybe
we
can
keep
on
moving.
K
Yeah
I'll
be
quick
I'll
just
put
one
on
like
the
policy
attachment
feels
overly
complex,
like
even
putting
aside
the
issue
of
like
crd
proliferation.
It's
it's
a
deep,
very
nested,
crd
it
or
pattern
for
a
crd
itself,
which
feels
like
a
lot
for
a
user
to
comprehend
in
order
to
make
a
relatively
simple
change
for
like
business
logic
of
one
application,
so
yeah
just
plus
one
on
like
it's
it's
powerful.
K
It
is
very
useful
in
certain
use
cases,
but
a
lot
of
our
common
cases
are
actually
much
simpler
and
might
benefit
for
a
simpler
ux.
K
Makes
sense
yeah
that's
before
even
getting
into
like?
Could
we
possibly
consolidate
some
of
these
like,
even
if
we
have
to
do
our
own,
like
just
having
a
smaller,
would
be
better.
A
Yeah
that
that
makes
sense,
maybe
we
need
some
I'm
trying
to
think
of
the
best
way
to
follow
up
here,
because
this
is
a
much
bigger
topic
than
we
have
time
for
in
today's
meeting.
Maybe
maybe
we
need
a
follow-up
meeting
focus
more
on
this.
A
In
the
meantime,
it
might
help
to
to
start.
You
know
the
thing
that
that
this
seems
like
to
me
as
a
discussion
on
GitHub,
with
with
some
of
the
limitations
of
the
API
or
the
model,
I
guess
and-
and
maybe
we
can
go
from
there,
but
this
is
this
is
a
big
topic
and
yeah
I.
Don't
have
any
clear
action
items
open
to
to
other
ideas
here
before
we
move
on.
A
That's
really
yeah.
That's
a
good
distinction.
I
think
that
at
a
minimum
now
yeah
policy
attachment
is
complex
is
an
issue
or
a
discussion.
The
second
one
we
have
started
some
discussion
around
timeouts
has
a
rough
example.
Timeouts
keeps
every
time
policy
attachment
comes
up,
timeouts
come
up,
so
you
know,
that's
probably
worth
the
discussion
on
its
own
and
you
know.
Maybe
if
somebody
is
willing
to
start
those
two
discussions.
Can
we
have
any
volunteers
for
that
before
we
move
on.
I
I
can
create
the
issue
for
policy
attachment
or
the
discussion
on
policy
attachment.
A
Anybody
can
there's
there's
nothing
to
answer
yeah.
D
So
yeah
all
right
I
can
create
the
the
one
about
timeouts,
I
guess
I'll
create
one
about
timeouts
specifically
and
then
maybe
go
from
there
into
okay.
You
know
other
things
we
could
consider
generalizing.
A
Great
thanks
I
appreciate
raising
this
topic
and
yeah.
Hopefully
more
discussion,
async
offline
I've
lost
track,
but
we
went
up
to
keep
I
think
we're
back
down
to
the
reference
Grant
cap.
Hopefully,
I
didn't
miss
anything
along
the
way.
I
just
wanted
to
highlight
this.
It
is.
We
are
proposing
moving
reference,
Grant
Upstream,
so
sigoff
would
take
ownership
I.
A
You
know
it
is
merged
as
provisional,
but
there
were
a
number
of
unresolved
issues
that
the
linked
PR
attempts
to
resolve
and
I
wanted
to
highlight
those
because
they,
you
know
I'd,
say
the
the
group
of
Gateway
API
implementation.
Implementers
are
probably
most
familiar
with
reference
Grant
and
we're
getting
some
suggestions
to
make.
You
know
changes.
Some
some
are
fairly
significant
to
reference.
Grant
one
is
giving
up
on
status
and
reference
Grant
I.
Don't
think
anyone
will
be
too
upset
about
that.
A
We
never
had
status.
We
just
left
room
for
it,
then
we're
moving
kind,
renaming
it
to
Resource
and
using
the
resource
terminology
which
usually
just
means
lowercase
and
plural,
as
opposed
to
kind.
A
That
is
a
more
precise
way
to
reference
resources
which
is
preferred
when
it
you
know
it.
The
the
resource
can
reference
any
number
of
indeterminate
kinds
of
resources.
A
Then
there
has
been
a
suggestion,
we'll
see
where
it
goes
to
add
verbs,
the
idea
being
that
a
verb
would
allow
you
to
describe
the
purpose
you're,
allowing
a
reference
to
exist
for
so
right
now
we
have
a
concept
of
in
Gateway
API.
You
can
allow
access
to
TLS
certs
or
to
forward
traffic
right,
and
so,
if
you
had
a
verb
to
describe
I'm,
allowing
access
to
this
secret
to
polity,
lesser
out
or
I'm,
allowing
access
to
this
service
to
forward
traffic,
but
nothing
else,
you
know
I
I,
don't
know.
A
The
idea
of
verbs
actually
enables
some
other
pretty
interesting
use
cases,
because
if
you
very
clearly
specified
the
purpose
for
the
reference
you
can
loosen
up
some
other
restrictions
and
then
finally,
the
the
most
significant
change
of
them
all
I
would
say
would
be
opening
up
room
to
namespace
label
selectors.
So
the
idea
that
you
could
allow
references
from
any
namespace
or
a
set
of
namespaces
with
specific
labels,
big
changes.
If
you
have
opinions
on
these,
it
is
still
you
know
it.
A
A
Basically,
yes,
I
tried
try
to
make
a
an
argument
for
keeping
it
and
at
high
at
high
level.
There
were.
The
concern
was
if
we
had
it,
who
would
populate
it
and
how
would
it
scale?
Basically,
if
there's
an
indeterminate
number
of
implementations
that
are
populating
this?
How
do
we
know
that
you
know
a
reference?
A
Grant
can
hold
that
you
know
what
what
is
the
limit
and
then
what
value
does
it
provide
over,
say
a
separate
resource
that
so
one
of
the
Alternatives
proposed
was
a
reference
granted
resource,
but
basically
a
resource
that
tracks
this
reference
Grant
has
been
used
to
Grant
these
forms
of
access
by
this
implementation.
Okay,.
A
Unclear
we're
gonna
have
to
have
reference
Grant
as
part
of
the
reference
Grant
included
in
Gateway
API
for
some
time,
because
at
best
this
reference
Grant
resource
will
make
it
into
127..
That
would
have
to
happen
this
week.
I'm
not
sure
that
the
pr
I've
linked
will
actually
get
in
this
week.
If
it
doesn't,
it's
not
till
128,
so
we'll
have
to
have
the
crd
in
Gateway
API
for
a
fairly
long
period
of
time.
Okay,
thanks
yeah
Mike.
K
Yeah
just
minor
point
of
feedback
in
terms
of
trying
to
keep
the
ux
of
reference
right,
simple
reference
grants
have
consistently
been
one
of
the
biggest
stumbling
blocks
for
our
users,
adopting
console,
API,
Gateway
and
Gateway
API.
It's
a
thing
that
almost
always
gets
forgotten
and
then
they're
looking
at
status,
and
why
doesn't
this
work
and
oh
I
need
to
learn
this
thing
and
maybe
having
it
become
more
common
in
other
parts
of
the
cube
ecosystem
will
help
with
that.
But
definitely,
like
is
color
my
initial
reaction
towards.
K
A
Yeah
yeah
that
that
is
very
helpful
and
you
know
I
I
think
many
of
these
things
are
are
not
necessarily
overcome.
You
know
that
the
first
two
are
not
over
complicating,
but
I
would
agree
that
verbs
and
and
namespace
label
selectors
both
have
the
potential
to
over
complicate
so
feedback
I.
G
A
Yeah,
that's
so
the
reason
we
left
so
in
Gateway
API
reference
Grant.
We
have
spec
and
no
status
with
the
idea
that
it
would
at
least
leave
room
for
status.
We
got
some
pushback
when
we
tried
that,
but
we
you
know
well,
you
know
we
might
want
it
yeah,
yeah
and
now
the
thing
is
well:
okay,
you've
you've
had
it
for
a
year
plus,
and
you
still
haven't
done
anything
with
it.
So
yeah.
A
Will
it
ever
yeah
so-
and
this
is
this-
is
also
Sega,
where
resources
traditionally
don't
have
status
so
I.
A
You
know,
I
I,
think
it's
fine
to
remove
it
or
remove
any
possibility
of
it
with
that
yeah
there's
a
there's
a
lot
more
discussion
available
on
there
and
actually
probably
the
the
pr
before
that.
It's
there's
lots
of
bits
that
link
back
to
the
previous
PR
that
have
more
discussion
on
it
right
now.
But
if
you,
if
you
have
comments,
definitely
add
them,
there
I'll
be
helpful.
A
But,
yes,
we
are
way
way
past
time
check
here,
so
I
do
want
to
just
very
quickly
run
through
I
guess,
one
more
thing,
and
that
is
this
one
here.
Thank
you
Shane
for
adding
this.
This
is
a
comment
that
got
lost
on
an
old
PR,
but
at
some
point
we
need
to
probably
transition
this
to
an
issue.
A
I
can
do
I
can
do
that
after
this
meeting
actually,
but
we
need
to
Define
what
it
means
to
have
multiple
references
to
TLS,
certs
and
kubernetes
secrets
and
then
okay,
sorry,
one
one
last
thing:
I
am
really
looking
for.
I
I
commented
on
the
path
redirect
and
rewrite
Gap
issue,
I'm,
looking
for
one
more
implementation
that
has
implemented
this
right
now
now
we
know
that
Envoy,
Gateway
and
istio
have
implemented
this.
A
If
we
can
find
just
one
more
implementation
that
has
implemented
this
feature,
I
think
will
be
good
to
move
it
forward,
but
we
do
need
probably
one
more
implementation.
So
I
mentioned
a
few
people
here,
but
if
you're
on
the
call,
if
you're
familiar
with
an
implementation,
that's
supporting
this
today,
please
comment
on
this
on
this
issue.
A
We
we
are
past
time.
So
thank
you,
everyone
for
great
discussion.
Today.
We
missed
some
things,
we'll
push
them
on
to
next
week,
but
thanks
everyone
and
have
a
good
rest
of
your
week.