►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220228
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220228
A
All
right
we're
recording
it
is
february.
28Th
we've
got
lots
to
get
through
today.
I
I
don't
see
nick
on
the
call
yet,
so
let
me
just
actually
jeff
you're
on
the
call.
Do
you
have
anything
I
think
I
may
have
added
this
incorrectly
in
on
our
last
meeting
a
couple
weeks
ago?
Is
there
anything
to
discuss
here?
Should
I
move
on
to
the
next
one.
B
You
didn't
add
it
incorrectly,
I
said
I'd,
have
it
ready
and
I
just
haven't
quite
finished
it?
I
should
have
it
done
tomorrow
and
so
I'll
post
it
on
the
channel
and
add
it
to
the
agenda
for
next
week.
Okay,
so
sounds
sorry.
A
A
No
worries,
I
completely
understand
all
right.
Well,
let
me
move
on
then
to
the
next
item
on
the
list,
which
is
v1
alpha,
well,
a
discussion
that
I've
been
having
individually
with
a
few
different
people,
and
I
wanted
to
surface
it
up.
I
think
we
we
may
have
mentioned
this
on
different
calls
too,
essentially
and
maybe
on
different
pr's,
but
it
hasn't
been
in
a
central
place
anywhere,
but
essentially
do
we
need
a
v1
alpha
3.
A
A
One
of
them
is
the
idea
of
renaming
reference
policy.
I
have
gotten
some
feedback,
both
in
internally
and
externally,
that
the
name
of
reference
policy
is
confusing.
I've
had
people
confused
that
reference
policy
is
just
one
of
our
other.
You
know
policy
attachment
type
things.
So,
if
you
think
of
the
concept
like
timeout
policy
or
retry
policy,
and
then
alongside
that,
you
see
reference
policy
and
you
say
well,
surely
this
is
the
same
thing
and
it's
actually
pretty
different.
A
I
I
get
how
that's
confusing
it's
unfortunate,
that
that
the
naming
ended
up
the
way
it
is,
and
I
I
think,
I'm
the
one
who's
just
that
name.
There
has
been
a
proposal
that
we
could
rename
that
resource
from
reference
policy
to
I
throughout
reference
binding,
but
I'm
sure
there
are
other
good
names
out
there,
but
the
idea
being,
can
we
remove
this
connotation
with
our
other
policy
resources
and
and
have
a
different
name
here?
A
The
pro,
I
think,
is
a
is
a
very
big
one
here.
It's
that
this
is
a
confusing
name.
I
will
likely
be
confusing
to
users
to
have
a
resource
named
reference
policy
that
is
unrelated
to
our
other
policy
efforts
and
resources.
A
I
completely
get
and
understand
that
I,
the
cons
that
I
have
come
up
with
are
unfortunately,
also
compelling
one.
I've
had
a
chat
in
sick
api
machinery
on
slack
about
what
can
we
even
do
you
know
I
there
there's
not
a
whole
lot
of
prior
art
for
renaming
an
api
in
kubernetes,
because
it's
just
not
really
possible
from
what
I
can
tell
the
the
way
to
rename
things
is
to
create
a
new
thing
and
get
rid
of
the
old
thing
which
yay.
A
Instead,
you
know
that
that
means
we're
not
create
we're
not
going
to
persist
data.
There's
no
way
to
really.
You
know,
take
the
old
api
and
have
some
kind
of
conversion
web
hook
that
magically
migrates
everything
over
for
us.
We
could
have
a
script
or
something
sure,
but
it
it.
It
feels
very
messy
because
we
end
up
in
this
place
where
we
have
to.
A
Fortunately,
it's
worth
pointing
out
whenever
you
think
of
you
need
to
support
both
things
immediately,
you
think
of
conflicts.
Fortunately,
conflicts
are
not
an
issue
here,
it's
a
purely
additive
api,
so
you
can't
actually
conflict.
You
just
add
new
things
that
are
allowed,
but
it
is
still
extra
effort
for
every
implementation
out
there.
A
A
It
may
not
be
the
end
of
the
world,
but
I
I
just
I
just
want
to
throw
this
out
there
and
see
any
any
other
pros
or
cons.
People
can
think
of
any
other
comments
on
this
one.
Before
I
get
to
the
next
one.
C
I
just
had
a
thought,
then.
I
thought
I
suggested
as
well
that
the
reference
policies
were
confusing
because
of
the
policy
thing
too,
but
it
feels
like
the
other.
I
mean.
The
other
option
we
have
here
is
to
change
the
policy
thing,
which
I
don't
really
think
many
people
have
implemented
too
much
yet
to
change
the
type
like
the
suggested
name
of
those
things.
C
That
would
probably
be
easier
and
wouldn't
then
involve
renaming
reference
policy.
I've
literally
just
thought
of
that,
but
yeah,
I
think
that
might
be
more
viable
and
that
would
then
not
be
a
breaking
api
change
because
that's
all
custom
api
anyway,
right,
like
that,
might
be
a
way
to
dodge
this
problem.
C
I
think
the
your
point
about
reference
policy
being
similar
to
network
policy
is,
is
pretty
good.
I
mean,
I
think,
there's
probably
also
some,
I
think
rob
you
made
the
point
that
it's
a
little
bit
more
like
an
outback
thing
than
it
is
like.
Never
policy
like
yeah,
it's
more
like
an
outback
thing,
so
using
binding
or
some
other
hardback
related
verb
kind
of
makes
sense
to
them.
C
So
that's
on
the
other
side,
so
yeah,
I
think
I'm
kind
of
in
a
similar
spot
to
you
rob
is
that
this
one
feels
like
it's
bit
six
and
one
half
a
dozen,
the
other
and
like
it
doesn't
feel
like
there's
really
any
good
choices
here.
A
C
A
A
I
it
may
not
require
a
new
like
it
may
not
require
v1
alpha
3
if
we're
just
adding
and
deprecating
something
like,
but
it
there's
there's
just
there's
not
a
whole
lot
of
precedence
for
it.
So
yet
another
place
where,
if
we
went
ahead,
we
would
be
blazing
new
new
ground,
I
think
about
being
on
the
bleeding.
A
A
Oh,
it's
a
new
thing
that
you
can
use
if
you
want
to
so
this
is
very
specific
to
the
proposal
that
already
exists
in
the
form
of
a
gap,
but
if,
if
it
were
required,
so
this
has
been
proposed
at
various
points,
it
finally
made
it
into
a
gap,
but
I
know
there
has
been
discussion
around
this
for
a
while
it.
It
really
mirrors
what
already
exists
on
gateway
in
terms
of
listener
names,
and
the
idea
here
is
that
we
can
attach
policy
to
individual
route
rules
potentially
in
the
future.
A
These
are
all
things
that
it
could
enable,
not
necessarily
that
it
would
enable
on
day
one
it
could
be
used
in
logging
and
events
for
implementation,
so
they
could
refer
to
hey
this
specific
route.
Rule
is
what
we're
using
to
route
this
request,
or
whatever
the
other
thing
is
most
relevant.
A
I
think,
and
that's
attaching
routes
as
part
of
route
delegation
and
jeff
will
probably
have
a
clear
picture
next
week,
but
I
think
I
think
we
we
all
have
a
rough
idea
of
what
this
would
look
like
the
idea
being
that
use
a
parent
ref
and
you
attach,
to
a
specific
section,
a
specific
rule
within
a
route,
so
the
the
rule
for
slash
foo
you
you've
attached
to
that
and
that
that's
what
you're
you're
routing
to
so
that
that's
all
well
and
good.
A
Those
are,
I
think,
reasonably
well
understood,
use
cases
for
this,
but
the
key
thing
is:
should
it
be
required
or
not
it's
it's
not
so
much
should
we
add
this
field,
it's
should
we
add
it
and
make
it
required
so
that
I
think
the
biggest
reasons
to
add
this
field
and
make
it
required
are
that
it's
consistent
with
gateway
that
we
have
a
name
field
on
gateway
listeners.
It's
required.
A
A
And,
of
course,
implementations
if
it
is
required,
will
always
be
able
to
rely
on
this
field
being
present,
so
they
could
consistently
use
it
for
blogging.
Debugging
events
whatever
is
relevant
here.
I
those
those
seem
helpful,
but
I
do
think
the
cons
may
outweigh
the
pros
here.
I
think
none
of
the
potential
use
cases
described
above
actually
need
this
field
to
be
required,
they're
all
possible,
at
least
from
my
perspective.
A
A
We
can,
you
know,
require
name
to
be
specified
for
every
route
rule
that
you
know,
but
the
the
the
real
concern
that
I
have
here
is
requiring
name
to
be
specified
for
every
route
rule
adds
this
unnecessary
verbosity.
So
you
can
imagine
that
we
have
a
very
large
number
of
route
rules
compared
to
gateway
listeners
like
you
can
imagine,
you
have
a
single
gateway
with
80
and
443.
Listening
as
a
rough
example
right
and
then
you
have
lots
of
different
route
rules
attached
to
that
we've
added
significantly
more
cost.
A
If
every
route
rule
also
has
to
include
a
name,
I
I
think
it's
it's
a
little
bit
different
math
than
you
know,
the
gateway
listener
name
and
a
required
name
field
there,
and
I
think
that
the
use
cases
we're
describing
here,
although
they're
useful,
are
not
something
that
everyone
is
going
to
use
attaching
policy
to
an
individual
route,
rule
sure
attaching
routes
as
part
of
route
delegation.
I
think
these
are
very
cool
features,
but
they
feel
very
advanced
and-
and
I
I
had
not
added
this
one
yet,
but
I've
brought
it
up
before
that.
A
The
whole
idea
of
route
rules
is
entirely
optional
right.
A
a
route
rule
is
really
just
a
shortcut.
You
can
accomplish
the
same
thing
by
just
having
multiple,
smaller
routes.
If
you
really
need
to
so
again,
this
feels
not
as
relevant
as
or
required
as
what
we've
done
with
gateway
listener,
name
where
having
a
single
gateway
is
really
meaningful
there
in
many
cases.
A
So
those
these
are
my
thoughts.
Okay,
I
should
add
one
last
thing
and
that
that
is
that
this
is
the
one
change
that
I
can
think
of
where
there's
just
absolutely
no
path.
For
conversion
well,
almost
no
path,
we
could
do
this
fun
thing
where
we
have
a
conversion
web
hook
that
actually
populates
like
generated
values
for
route
rule
names,
but
that
feels
messy
and
maybe
confusing.
If
we
have
again,
I
expect
our
v1
output.
A
2
user
base
is
not
massive,
so
so
we
shouldn't
put
tons
of
weight
on
this,
but
it
is
still
a
consideration
that
it
is
a
relatively
painful
change.
It's
one
of
those
things
where
users
can't
just
change
the
api
version
and
apply.
They
need
to
change
the
api
version
and
do
some
manual
effort
to
make
a
change
here.
A
B
Mike's
one
of
my
engineers
so
and
he's
been
helping
me
with
the
with
the
route
spec
stuff
or
route
delegation.
Sorry,
so
I
could.
I
could
almost
show
you
guys
what
what
we're
going
to
propose
here,
but
basically
we
were
thinking
of
adding
in
a
a
you
know
for
for
matches
in
the
in
the
http
route.
B
We'd
add
in
like
a
section
name
so
that
you
could
in
a
child
route,
you
could
reference.
B
Maybe
this
be
easier
if
I
shared
my
screen
that
work
wrong.
B
B
All
right,
hopefully,
you
can
see
this
now.
Okay,
I
see
no,
it's
good.
So
what
we're
looking
at
is
and
I'm
struggling
with
the
auto
formatting
in
google
docs
so
which
I'm
sure
several
of
you
are
quite
familiar
with,
but
the
basic
idea
would
be,
for
you
know
each
set
of
match
criteria.
We
could
add
a
section
name
to,
but
only
if
we
wanted
to
do
delegation.
B
So
you
know
I
have
a
criteria
here.
Gonna
match
something
or
it
might,
and
there
might
be
more
than
just
pass
right.
It
could
be
yeah
like
header,
so
here's
struggle,
here's
my
formatting
issues,
but
then
you
say
a
allowed
routes
and
then
you
could
have
another
section
for
another
path,
but
you
can
necessarily
have
to
have
a
section
name
if
you
just
wanted
to
do
a
match
criteria
and
a
backend
reference.
B
So
from
our
perspective,
I
don't
I
don't
see
a
need
to
require
naming
matching
criteria
or
sets
of
matching
criteria.
I
think
it's
optional
would
be
just
fine.
A
Yeah,
that's
this
is
close
to
how
I'd
I'd,
imagined
it
working
and-
and
I
agree
section
name
feels
like,
or
you
know,
rule
name
whatever
whatever
it
is.
It
feels
like
something
that
is
a
requirement:
a
prerequisite
to
exist.
F
A
G
C
I
think
that
if
we
make
it
optional,
we
do
need
to
be
really
clear
about
you
about
if
you're,
referring
to
some
subsection
of
a
route
object
like
a
http
route,
object
like
what
are
the
ways
that
you
can
refer
to
the
subjections
and
what
is
required,
and
how
does
the
behavior
work
like
if
you
want
to
refer
to
the
the
the
rules
in
the
the
rule
list
via
you
know,
via
an
index
like
and
you
have,
some
rules
have
names.
How
does
the
combination
of
the
two
things
work?
C
You
know,
and
so
that's
that
those
are
the
things
that
I
thought
of
that
I'm
like.
Oh,
that's
really
complicated,
but
we've
got
other
places
in
the
api
where
there
are
equally
complicated
things
and
we've
sold
it
just
by
having
a
very
clear
tightly
defined,
set
of
rules
that
define
how
those
things
work
you
know
like
if
you
don't
specify
a
name,
the
name
given
to
it,
like
the
name
that
you
can
refer
to
it
by
is
the
index
number
in
the
list.
C
That's
probably
you
know
if,
if
there
is
a
conflicting
name
of
an
index
number
the
index
number
we
use
instead
or
something
some
some
set
of
rules
like
that
that
are
reasonably
straightforward,
that
remove
sort
of
any
possibility
of
there
being
no
way
to
uniquely
identify
to
identify
a
rule
or
section
or
whatever.
We
call
it.
That,
I
think,
is
the
downside
of
making
it
optional,
which
is
not
that
big,
a
downside.
In
my
view
and
yeah.
C
H
G
C
Then
you
get
all
the
listeners
yeah
and
for
your
a
route
attaching
to
a
parent
route
or
something
like
that.
Then,
if
you
don't
specify
a
section,
you
get
all
the
sections.
You
know,
and
you
know
where.
Maybe
you
don't
want
that
right
like,
but
that
means
well,
if
you
don't
want
that,
then
you
specify
the
section.
That's
you
know,
but
that
is
long.
It
doesn't.
I
don't
think
the
rules
matter
exactly
where
they
are
as
long
as
there
is
a
very
clearly
defined
set
of
rules
for
what
happens.
A
A
If
you
don't
have,
you
can
only
attach
routes
if
it
if
to
it,
to
a
very
specific
section
like
for
route
delegation,
you'd
require
section
name
to
be
specified,
but
I
don't
know-
and
I
I
think
you
know
that
those
that's
probably
yeah-
that
yeah
we
can-
we
can
get
into
that-
I'm
very
interested
in
what
jeff
and
michael
propose
soon
but
yeah.
I
I
can
see
arguments
either
way
on
that
one
and
yeah
okay.
So
let
me
let
me
keep
on
going
here.
A
I
it
seems
like
if
I'm
understanding
what
others
are
saying
here.
There
is
some
interest
in
at
least
exploring
either
a
rename
of
this
or
rename
of
just
doing
due
diligence
on
what's
possible.
Here.
A
That's
my
my
take
on
this
not
necessarily
moving
forward,
but
getting
some
more
details
on
what
what
is
even
possible
and
exploring
names.
For
you
know,
policy
attachment
is,
can
we
use
config,
I
mean,
can
we
I
don't
know
some
other
term
there
and
the
other
the
other
side
of
it
is.
I
seems
like
again.
This
is
just
my
understanding
of
what's
been
said
so
far.
It
seems
like
they're.
A
Most
of
us
are
fine
with
leaving
this
as
an
optional
field.
Does
that
seem
okay,
cool?
So
if,
if
we're
good
with
this
being
optional,
I
think
I
think
we're
in
that.
That
was
my
biggest
concern
about
the
need
for
v1
alpha
3.
I
tried
to
scope
out
what
a
v1
alpha
3
would
look
like,
and
it
scared
me
a
bit.
You
know
it
just
delays
everything
and
adds
significant
work,
so
it
seems
like
at
least
this.
A
This
biggest
concern
of
mine
is
likely
not
an
issue,
so
I
I
had
mentioned
in
the
get
proposing
this
that
we
were
going
to
discuss
this
idea
and
this
you
know
what
we
wanted
to
do
in
today's
meeting
and
so
I'll
take
an
action
to
run
through
and
update
that.
A
I
think
that
the
proposal
right
now,
I
believe,
is
for
an
optional
field,
but
I
just
want
to
make
sure
that
we're
we're
all
on
the
same
page
and
I
can
report
back
cool
all
right
nick.
I
think
I
should
hand
it
back
to
you.
You
had
a
couple
of
the
first
things.
Well,
previous.
First
things
on
the
agenda.
Maybe
do
you
want
to
discuss
yeah.
C
Yeah
sure
so
yeah
next
one
is
an
fyi
yeah
has
been
picked
as
the
spring
linux
foundation
mentorship
project,
I'm
going
to
be
mentoring,
her
walking
through
a
cncf
docs
assessment
of
our
website
to
make
a
bunch
of
recommendations
about
the
docs
themselves
and
also
the
architecture
and
stuff
like
that.
So
yeah
just
wanted
to
make
sure
everyone's
aware
that
that's
happening,
and
so,
if
you
see
me
around,
please
welcome
her
yeah
she's
she's
super
excited
about
working
on
the
project.
A
Pause
for
anyone
else,
that's
awesome,
yeah.
Thanks
for
getting
that
set
up,
I'm
excited
to
have
her
helping
out.
C
Yeah
cool
cool,
I
think
I
think
our
I've
been
having
spent
a
little
time,
obviously
preparing
for
this
going
through
the
docks,
I
think
in
general
our
doc's
pretty
good,
like
we
have
good
information
in
there,
but
I
think
the
architecture
needs
work.
You
know
is
the
sort
of
the
headline
that
I
think
is
the
case,
but
I
want
to
let
her
make
her
own
decisions,
so
cool,
okay.
So
the
next
thing
is
quick
clarification.
C
I
saw
the
thing
about
service
load
services,
a
new
load,
monitor
class
spec
field
that
lets
you
pick,
which
cl,
which,
like
service
and
type
load,
balancer
provider.
You
want
to
use-
and
I
was
just
like:
do
we
care
about
this?
Do
we
need
to
write
down
how
that
will
work?
It
doesn't.
H
I
guess
my
question
would
be
what
what
interaction
are
you
considering.
C
You
know
and
bet
I
just
wanted
to
have
asked
the
question
that
to
make
sure
that
none
of
us-
you-
I
don't
I
and
one
of
the
other
things
that
came
up
when
I
was
thinking
about
this-
is,
I
don't
think,
we've
ever
actually
specified
anywhere
what
types
of
services
are
appropriate
to
be
a
backend
in
the
gateway.
C
I
think
we
specifically
have
left
a
lot
of
that
undefined,
but
like
it
does
mean
that
if
you're
gonna
for
some
reason
have
your
gateway
to
service
refer
to
services,
type
load,
balancer
things
could
get
pretty
funky
and
not
in
the
good
funky
way
so
yeah.
So
I
just
wanted
to
sort
of
say:
hey
like
this
is.
H
C
Overloaded
yeah
it's
a
strong
thumbs
up
from
me
on
that
front,
it
was
more
just
I
was
like
I
wanted
to
have
asked
the
question
once
in
here,
so
that
we
can
all
know
that
low
balancer
class
is
a
thing
and
be
like.
Do
we
need
to
care
about
this?
I
think
that
probably
not
is
the
answer,
but
I
wanted
to
have
raised
it
here.
That's
all.
C
Yeah,
it's,
I
think
we
kind
of
implicitly
assume
that
it's
a
that's
that
it's
like
a
cluster
ip
service.
To
be
honest,
that
we
really
assume
that
the
the
service
is
a
cluster
open,
that's
not
using
any
of
the
other
service
magic
and
we
we
expect
that
it's
used
as
a
bucket
of
pods,
really
a
bucket
of
endpoints.
H
It
might
actually
be
even
more
akin
to
a
headless
service
yeah,
because
people
just
route
directly
to
the
back
end.
We
might
just
want
to
clarify
that.
That's
like
a
good
clarification
for
the
docs.
C
C
To
answer
by
talking
about
this
lingman,
so
thank
you
yeah,
and
so
I
think
rob
is
just
yeah.
We
we
need
to
document
how
service
you
know
how
services
should
be
routed
to
and
that
you
know.
Probably
we
want
to
make
it
explicit
that
if
you're
using
a
service
type
load
balancer
using
it
as
a
back
end
in
a
gateway
is
just
it
doesn't
it.
It's
kind
of
the
behavior
is
always
going
to
be
undefined
because
you're
mixing
two
constructs,
but
we
need
to
document
that
I
think.
H
A
You
know,
because
service
type
load
balancer
is
just
a
super
set
of
cluster
id
right.
So
as
long
as
the
service
itself
includes
endpoints-
and
this
this
again
requires
us
to
document
this.
But
my
interpretation
is
that
when
you're
forwarding
to
a
service
you're,
so
you're
forwarding
to
the
endpoints
that
are
selected
by
that
service
and
and
anything
beyond,
that
is
tangential.
C
I
think
true,
but
I
think
I
feel
like
the
there's
so
much
overlap
with
what
the
idea
of
what
a
service
type
load
balancer
does
with
what
I
get
with
what
the
gateway
api
does,
it's
probably
better
to
be
clear:
don't
this
is
not
a
peanut
butter
and
chocolate
situation.
This
is
like
a
oil
and
water
situation.
Don't
mix
them?
It's
not
a
good
idea.
E
C
E
C
So
yeah
for
the
case
you're
talking
about
it,
sounds
like
you're
talking
about
like
a
a
layer,
7
gateway,
just
l4
I
mean
just.
I
want.
C
E
C
C
So
in
that
case,
like
the
the
layer,
4
load,
balancer
that
sits
outside
the
cluster,
like
that's,
actually
a
gateway
because
it
like
knows
about
the
outside,
doesn't
know
about
cluster
networking
or
care,
and
the
inside
does.
Who
knows
how
to
get
to
some
service
inside
for
something
like
contour
saying
I
mean
I'm
a
maintainer
on
contour
right,
so
here's
an
example,
a
lot.
It's
an
english
controller,
and
so
it
uses
envoy
that
runs
in
cluster
as
its
data
plane,
and
it
requires
some
other
thing
to
bit
to
set
up
the
layer.
C
4
data
path
to
get
the
traffic
to
envoy
and
so
contour
has
a
gateway
that
describes
the
the
the
place
sort
of
the
place
to
attach
the
the
envoy
copy
that
the
http
routes,
and
so
like.
That's
what
contours
gateway
means.
But
you
say
you
rob
and
the
gke
team
have
the
gke
gateway
controller
that
describes
the
creation
of
a
cloud
load.
C
And
so
you
know
the
thing
that
you're
talking
about
if
you
want
to
have
an
upstream
load
balancer
that
is
not
described
by
the
gateway
inside
the
cluster
it'll
work,
but
like
it's
a
little
like
I
would.
I
would
guess
that
you
will
get
some
impedance
mismatch
about
the
way
that
we
talk
about
gateways
like
in
general,
we've
sort
of
at
the
moment
we
can
tended
to
bucket
gateways
into
like
does
la
does
layer
four
and
only
does
layer.
Seven,
because
only
does
layer.
C
Seven
is
very
corresponding
to
like
an
ingress
controller
in
sort
of
a
traditional
ingress
controller
and
does
layer,
four
is
pretty
corresponding
to
service
of
type
load,
balancer
cloud
provider.
E
E
C
Yeah,
okay,
yeah
yeah,
and
so
I
mean
yeah.
I
agree
that
that's
that's,
and
that
is
another
reason
why
we
left
that
vague,
so
that
we
didn't
so
that
the
fact
that
we're
roughly
thinking
about
it
in
these
two
big
buckets
doesn't
preclude
other
people
using
it
in
some
other
way.
But
in
my
mind
that
that's
the
central
conceit
of
the
gateway
is
that
it's
like
translating.
C
E
A
Yeah
that
should
be
possible.
I
I'd
be
interested
in
the
specific
use
case,
but
that
should
be
possible.
I
mean,
obviously
our
cloud
load
balancers
are
widely
used
to
route
to
in-cluster
proxies,
for
example
right.
So
if
you
were
deploying
contour
or
istio
as
you're
kind
of
in
cluster
proxy-
that
that's
something
that
that
is
already
pretty
broadly
supported,
and
I
think
what
you're
talking
about
is
is
different,
but
I
think
the
same
pattern
largely
applies.
C
Yeah,
I
think
it
sounds
like
a
really
interesting
use
case
to
be
honest,
that
yeah,
if
you
wouldn't
mind,
spending
a
little
like
spending
some
time
like
writing
up
the
sort
of
thing
that
you're
thinking
about
then
I
would
certainly
like
to
make
sure
that
we
can
that
we
have
considered
those
use
cases
and
we're
not
like
blocking
people
from
doing
something
like
that.
I
I
feel
like
chaining
gateways,
like
kind
of
makes
sense
like
contour
is
like
for
me.
C
Contour
is
definitely
going
to
end
up
having
you
the
in
a
world
where
there
is
where
we
don't
use
service
of
type
load,
balancer
anymore,
because
gateway
api
seems
better,
which
is
probably
a
long
way
in
the
future,
but
yeah
anyway,
like
in
that
sort
of
world
where
we
don't
use
service
type
load,
balancer
anymore,
because
gateway
is
better.
C
You
know
contour
is
going
to
have
a
gateway
to
describe
a
place
to
attach
http
routes
to,
but
contour
is
going
to
need
a
gateway
to
describe
how
to
get
the
layer
4
path
into
the
cluster,
and
so,
in
that
case,
like
you're
kind
of
going
to
have
like,
in
effect,
like
kind
of
a
chaining
kind
of
thing
happening.
Where
this,
the
the
exposing
envoy
gateway,
then
sort
of
leads
to
the
the
ingress
controller
gateway.
C
C
So
the
you,
the
the
provide
the
layer,
4
path
load
balancer,
is
going
to
have
different
scaling
requirements
to
the
contour
and
envelope,
and
so
like
it's
kind
of
up
to
your
the
implementation
that
takes
the
gateway,
config
and
figures
out
how
to
make
it
work
to
figure
out
how
to
how
to
scale
those
things.
We
have
not
addressed
programmatic,
like
configuring
inside
the
gateway
anything
about
how
it
would
scale
at
the
moment.
C
A
Yeah,
please
follow
up
by
if
you,
if
you
have
any
other
questions,
want
to
describe
what
you're
thinking
of
we're
we're
very
interesting
use
cases
here,
we've
been
as
nick
mentioned,
we're
we've
been
largely
focused
on
two
buckets
of
implementations.
Right
now,
but
being
aware
of
other
types
of
implementations
or
potential
implementations
or
use
cases
will
help
us
build
a
better
api.
So
absolutely.
C
Okay,
we'll
do
great.
I
think
one
thing
that
that
was
related
to
that.
I
see
luan
asking
some
questions
in
the
chat
that
she
and
I
had
a
chat
about
the
other
day.
C
I
don't,
I
think,
we've
implied
that,
but
I
don't
think
we've
made
that
super
explicit,
that
that's
how
if
you
have
five
ip
addresses
and
two
listeners,
then
you're
going
to
end
up
with
like
10
listener,
ip
combinations
right
and-
and
so
I
think
that
it's
really
important-
that
we
make
that
very
clear
that
that's
the
expected
contract
and
if
you
want
to
have
like,
I
think,
cleveland-
and
I
were
talking
about
what
happens
when
you
want
to
have.
If
you
want
to
have
this
ip
expose.
C
A
C
Yeah,
that
would
definitely
be
a
quote,
but
I
think
the
assumption
that
we
have
made
at
this
point
is
what
I
said,
and
so,
if
we
want
to
do
something
different,
then
we
need
to.
You
know,
write
down
what
I've.
What
I've
said
is
assumed
in
the
api
at
the
moment,
and
if
we
weren't
going
to
change
that,
then
we
need
to
change
it
like
real
soon,
because
once
we
like
go
to
beta.
C
Cool,
I
think
it
might
to
just
to
answer
the
exact
question
in
my
mind.
I
don't,
I
can't
think
of
any
use
case
that
involves
like
subdividing
the
addresses
and
stuff
that
wouldn't
be
better
handled
with
more
smaller
gateway
objects
that
get
merged
together
to
configure
a
single
data
plan
which
again
is
100.
Okay,
you
don't
it's
not
like
a
hard
thing
that
that
one
gateway
equals
one
data
plane,
you're
allowed
to
take
a
set
of
gateways
under
a
gateway
class
and
collapse
them
together
in
some
way.
That
makes
sense
to
your
implementation.
A
Cool
all
right,
let
me
run
off
to
pr
issue.
Triage
I've
been
out
of
office
for
a
bit,
so
I'm
a
bit
rusty
on
what's
happening
here.
If
anyone
has
issues
or
prs
that
you
know
need
attention,
please
highlight
them.
I
definitely
don't
want
to
miss
anything
here.
I
think
what
we've
seen
is
a
few
of
these
issues
at
the
top
that
have
been
updated
recently
are
just
removing
the
stale
life
cycle.
A
I
think
nick
you've
been
handling
the
mentorship
project
so
good
there.
I
think
we
just
had
someone
volunteer
for
the
this
validation
task,
yeah.
Okay,
so
I'm
not
sure.
A
A
Next
is
conditions
for
policy
attachment.
I
think
this
is
also
a
life
cycle,
one
yeah,
so
I
don't
think
there's
anything
massive
that
has
been
a
new
issue
that
has
surfaced
recently.
I
think,
as
far
as
issues
go
we're
in
a
reasonably
good
place
as
far
as
pull
requests.
I
don't
know
of
any.
Oh,
yes,
nick
I'm
sorry
I
I
have.
I
owe
you
a
review
on
this
one.
A
So
this
this
one
is
very
much
on
me
and
anyone
else
who
who
wants
to
review
it.
It
does
very
much
look
like
it
works.
C
F
C
And
tell
me
what
you
think,
but
yeah
I'm
pretty
confident.
I've
got
it
right.
We
won't
really
know
for
sure.
Until
we
cut
our
next
simba
release,
yeah
yeah
he
releases,
but
but
the,
but
we
will
at
least
we
should
at
least
see
the
main.
The
main
images
as
they
get
released
be
updated
makes
sense.
This
is
gonna.
This
is
gonna,
be
helpful.
C
This
this
is
required
for
me
to
you
know
do
this
so
that
then
the
whole
idea
is
to
make
it
so
that
we
have
like
a
basically
a
cucutal
apply
yaml
of
ready
yaml
that
will
create
a
namespace
install
the
admission
web
hook,
install
the
crds
all
that
sort
of
stuff.
C
This
is
all
about
making
sure
that
the
admission
win
pool
is
built
and
tagged
in
the
right
way
to
make
that
easier,
and
then
once
we've
done
that,
once
we've
got
that
there
then
that's
like
in
my
mind,
this
is
all
stuff
that
we
need
to
do
before
we
can
go
beta.
We
need
to
have
consistent,
install
method
we
need
to
have
you
know,
basically
a
ideally
a
one
liner
that
says
apply
this
thing.
You
know
in
the
standard
you
know,
devops
yolo
way
of
you
know
call
pipe
to
bash.
C
C
That
will
do
this
and
a
single
yammer
you
can
render
and
do
the
thing
that
you
can
include
on
including
your
tutorial
that
says
to
get
the
gateway
api
working
apply
at
this
version
and
you
can
apply
the
0.4.1
release,
bundle
that
will
give
you
for
the
experimental
or
stable
release
bundles,
and
that
will
give
you
the
correct
versions
of
the
cids
workbook
that
enforces
them.
You
know
all
that
sort
of
stuff
so
that
then,
in
your
conformance,
ci
and
all
that
sort
of
stuff
you've
got
a
standard
thing.
A
Yeah
yeah.
That
makes
a
lot
of
sense.
Thank
you
for
taking
this
on.
I
wonder
if
this
is
something
that
justifies
another
patch
released,
04
2,
whatever
it
is,
maybe
we
could
do
we
could
experiment
with
like
a
o42
rc.
A
You
know
rc1
rc2
until
we
know
that
we
have
an
image
pushing
the
way
we
expect
it
to
and
then
just
cut
a
patch
release
that
includes
a
web
hook.
F
A
Great
awesome,
no,
I
think
that's
good,
so
I
owe
you
a
review
on
this
one,
but
well
it's
good
from
what
I've
seen
I
I
don't
think
this
person
is
on
the
call
right.
B
A
F
Yeah,
so
sorry
for
the
long
turnaround
time
on
the
response
to
the
reviews,
but
I
just
got
that
in
before
the
meeting.
I
did
make
a
change
to
it
and
that's
that's
also
why
there
was
some
latency
on
this.
I
ran
into
some
issues
in
terms
of
implementability
for
the
merge
rules,
so
those
have
changed
once
again.
F
F
It
was
pointed
out
that
the
http
and
https
protocol
types
do
not
imply
support
for
http
2.,
so
I've
explicitly
added
in
h2
and
h2c
protocol
types
feel
free
to
bike,
shed
the
names
there,
I'm
not
married
to
them,
and
then
I've
also
just
gone
through
and
done,
like
small
fixes
so
happy
to
respond
to
any
more
review
comments.
You
all
have
hopefully
much
more
quickly.
This
time.
H
F
And
so
there
were
two
fronts
to
this
one
was
we
tried
to
figure
out
how
common
it
is
for
people
to
share
grpc
and
http
on
the
same
hostname
and
port,
but
on
different
uris,
and
we
found
out
that
it's
actually
not
super
common?
We
couldn't
get
very
many
concrete
users
of
this
out
in
the
wild.
The
other
thing
is:
if
people
want
to
do
that,
they
always
have
the
ability
to
drop
down
to
an
http
route.
They
just
miss
out
on
user
experience.
F
There
aren't
currently
any
things
that
you
can
do
with
grpc
route
that
you
can't
do
with
http
route.
There
are
some
that
we've
considered
and
those
are
in
the
future
directions
section,
but
I
don't
think
they
should
be
deal
breakers
for
people
who
have
that
you
know
sort
of
corner
case.
A
I
haven't
looked
at
the
updated
version
of
this,
but
to
clarify
is
the
guidance?
If
so,
you
know
we
can't
prevent
configuration,
you
know
with
http
route
and
grpc
route,
claiming
the
same
host
name
right.
So
if
that
happens,
is
the
expectation
that
we
would
always
support,
grpc
and
not
http.
If
both
exist
like
is
there
some
kind.
F
I
mean
so
maybe
I'm
like
not
clear
on
how
validation
works,
but
I
saw
that
there
was
like
a
status
of
was
it
like
accepted
and
routes
can
be
rejected
by
setting
status,
false
there's
like
a
condition
or
something
like
that,
and
so
it
would
be
the
first
route
like
if,
if
the
first
one
attached
to
a
host
name
is
a
grpc
route,
then
you
try
to
configure
an
http
with
the
same
host
name.
You
would
reject
it
with
not
accepted
and
then
vice
versa.
Right.
C
A
Yeah
that
that
seems
reasonable.
I
hate
to
add
more
potential
fuzziness
here,
but
let's
just
let's
just
say,
is:
is
there
any
room
or
any
rationale
to
say
this
is
what
we
recommend,
but
it
you
know
we're
not
going
to
entirely
prevent
or
require
that
implementations
don't
support
the
both
at
the
same
time
like
do
we
do
we
want
to
leave
that
that
open
as
you
can
choose
to
support
both
you
just
or
should
we
just
close
that
door
completely
up
front.
F
So
the
main
reason
why
I
tried
to
make
it
like
a
concrete
determination
was
because,
if
at
some
point
in
the
future,
we
did
find
that
the
popularity
of
this
use
case
grew
and
the
story
for
implementability.
F
For
you
know
different
implementations
changed
then
it
would
be
a
backwards,
compatible
change
to
add
in
these
specific
merge
semantics
and
if
we
just
leave
it
open
and
say
it's
implementation
defined.
We
do
not
have
that
ability,
because
you
know
different
implementations
can
be
doing
completely
different
things.
A
And
you
mentioned
so.
The
other
thing
I
know
you
mentioned
was
the
the
the
new
protocols
you
added
these
are
these
are
intended
to
be
protocols
on
the
gateway
itself.
F
Right
and
maybe
maybe
I
need
to
do
some-
some
more
work
here
for
integration
between
those
two
protocols
and
http
http
route,
because
I
imagine
you
would
be
able
to
use
those
two
together
as
well
right.
F
F
A
C
I
think
probably
one
thing
that
might
be
worth
you
having
to
think
about
richard
is:
would
it
be
possible
for
people
to
use
the
grpc
route
to
do
stuff
around,
like
the
automatic
rest
to
grpc
conversion.
F
Right,
I
I
do
think
that's
a
great
use
case.
I
just
don't
think
that
we
should
take
on
that
complexity
in
this
particular
gap.
C
100
agree:
100
agree,
it's
more
like
think
in
in
under
your
future
directions,
or
something
like
that,
like
section
just
have
a
think
about
it
and
like
are
we?
Are
we
stopping
ourselves
from
being
able
to
do
that?
At
some
point,
I
don't
think
we
are
the
top
of
my
head,
but
it
seems
worth
just
taking
you
know,
taking
a
few
minutes
to
think
through.
Like
are
we
blocking
that
use
case
by
anything
we're
doing
here.
A
I
don't
know
now
that
that's
an
interesting
version
of
that,
what
we've?
What
we've
talked
about,
the
closest
thing
to
chaining
routes,
that
we've
talked
about
right
now
is
route
delegation.
The
idea
of
delegating
you
know
say:
slash
foo
to
a
different
name,
space
and
letting
route
admins
in
that
name,
space
configure
how
routing
works
under
that
path.
A
H
Yeah,
I
think
that
one
is
like
you
can.
Eventually,
most
network
systems
becomes
this
directed
acyclic
grab.
We
might
even
be
sick,
like
the
of
components.
The
thing
is:
we're
really
focused
on
enabling
kind
of
a
base
level
of
use
cases,
while
keeping
the
api
easy
to
understand.
So
I
think
like
could
you
chain
the
routes?
Probably
could
implementations
actually
handle
that
level
of
complexity
is
one
question
and
then
do
users
have
like
a
a
good
use
case
that
requires
adding
on
that
complexity,
then
that
one
is
would
be
interesting
to
see.
C
I
think
the
thing
that
I
wanted
to
say
here
is,
I
feel,
like
the
best
way
to
think
about.
The
different
types
of
routes
is
syntactic.
Sugar
http
route
is
syntactic
sugar
on
top
of
a
tcp
route
like
that,
the
the
hdd
period
takes
the
concepts
of
the
ccp
route
and
wraps
them
with
further
extra
bits
that
are
http
protocol
specific
in
the.
C
Route
is
syntactic
sugar
for
http,
you
know,
and
h
and
tls
route
is
like
a
is
syntactic
sugar
around
a
tcp
yeah,
and
so
I
think
what
you're
talking
about
john
is
like
taking
a
tcp
around
and
using
it
to
describe
the
tcp
specific
parts
of
a
connection
and
then
having
another
route
that
sort
of
changed
off
that
one
that
says.
Okay.
F
C
E
C
Yeah,
no,
I
I
I.
I
just
said
that
yeah
quality
service
bits
on
the
tcp
connection
are
actually
a
really
good.
A
really
good
example
of
something
that
might
be
tcp.
C
Yeah
yeah
yeah
yeah,
absolutely
yeah.
No,
that's
actually
a
really
good
point
in
my
mind,
you
might
the
the
off
the
top
of
my
head
answer
I
would
give
to
that.
Is
that
that
sort
of
stuff,
in
my
mind,
like
it's,
some
combination
of
the
listener
and
the
whatever
you're
doing
but
yeah?
That
is,
that
is
a
really
good
point,
but
the
yeah,
I
think
again
what
bowie
said
is
we're
kind
of
trying
to
hit
these
like
really
straightforward
use
cases
with
like
a
single
way
to
do
it.
C
Like
you
know,
the
hdp
route
is
about
like
basically
ingress,
but
better
right
like
and
you
know,
the
tcp
route
is
kind
of
like
service
type
load
balance
a
bit
better.
You
know,
and
that's
that's
really
where
we're
thinking
like
the
whole
point
of
these
things
is
to
sort
of
take
things
that
people
are
doing
already
and
make
them
easy
and,
like
I
think,
if
you
look
at
the
thing
you
go,
make
them
design
them
to
be
role-based
so
that
you
can
so
that
the
conflict
can
be
sort
of
shared
between
teams.
C
You
know
in
a
sensible
way
and
to
make
it
so
that
all
of
this
config
is
explicit
somewhere.
You
know
so
you're
not
ending
up
with
really
important
config
living
in
annotations,
which
is
a
bad
time
for
everybody.
C
This
stuff
should
be
described
explicitly
somewhere
and
that's
why
we've
got
lots
of
extension
points
for
custom,
cids
and
stuff,
like
that.
We
have
the
you
know
the
policy
extension
mechanism,
yeah.
C
Take
stuff
that
that
your
route
needs
to
know
about
and
sort
of
wrap
it.
You
can
have
some
extra
conflict
that
sort
of
wraps
that
thing
that
is
not
described
inside
that
inside
that
http
r.
So
we
have
a
couple
of
ways
to
do
that
already
that
I
think
mean
that
we
can
meet
the
sort
of
use
case
of
providing
a
really
straightforward
way
to
configure
easy
stuff
and
keep
the
complicated
stuff
to
be
more
complicated.
C
A
You
yeah
yeah,
really
really
good
questions
yeah.
Thank
you,
everyone
for
the
great
discussion
today.
I
think
we
are
at
time
or
past
time.
Actually,
let
me
I
think
everything
else
is
mostly
good
I'll
make
sure
that
default
to
run
through
the
rest
of
these
myself.