►
From YouTube: Technical Oversight Committee 2021/08/16
Description
Istio's Technical Oversight Committee for August 16th, 2021.
Topics:
- Networking Roadmap for 1.12
- Gateway Topology graduation to Beta - Discussion
A
A
B
B
D
For
the
most
part,
items
on
here
are
just
moving
existing
features
forward
and
feature
quality,
so
delta
to
alpha.
The
only
api
that
we
want
to
promote
is
workload
group.
We
decided
that
virtual
service.
We
should
really
prefer
the
kubernetes
apis
for
that
for
destination
rule.
We
want
to
try
to
align
better
with
the
gateway
like
the
kubernetes
gateway
api
and
then
service
entry
and
workload.
Entry,
don't
really
have
anything
holding
them
back,
but
stable
is
a
big
step.
So
we
want
to
put
more
discussion
into
that
proxy
list.
D
Jrpc
was
just
added
support
and
pilot
for
111,
so
I
want
to
try
to
get
that
to
alpha
quality
in
this
release.
Jacob
and
niraj
want
to
get
ipv6
to
experimental
support,
dns
proxy.
We
really
just
want
to
promote
that
to
beta.
For
the
most
part,
it's
good
be
just
enhancing
tests,
especially
around
like
multi-cluster,
multi-network
and
staple
set
edge
cases.
D
D
D
Zhong,
who
is
going
to
implement
his
proposed
api
for
topology,
aware,
load,
balancing
and
finally,
we
have
a
pr
already
out
to
add
some
http
support
on
gateways
and
then,
for
you
know,
lower
priority
items
that
we
may
or
may
not
have
time
to
implement.
I
want
to
try
to
support
hostname
based
load
balancer
resources
to
help
aws
users,
especially
with
using
multi-network.
D
We
can
implement
the
apis,
but
a
lot
of
the
actual
benefits
from
them
would
rely
on
some
of
what
we
have
to
do
for
delta
xds
already.
So
I'm
not
really
sure
if
we'll
actually
add
the
apis
or
not.
Now
we
probably
will,
since
it
should
be
somewhat
low
effort,
but
they
probably
won't
actually
provide
real
benefit
yet
and
that's
pretty
much
it.
F
F
It
went
yeah
like
the
amount
of
testing
required
in
order
to
get
this
done
and
kind
of
it's
more
for
not
many
people
probably
are
are
kind
of
using
this
right
now
and
some
of
the
code
changes
required
for
this
are,
I
would
say,
there's
gonna,
be
issues
right,
like
even
with
the
amount
of
testing
that
I'm
trying
to
do
right
now.
You
know
we
keep
kind
of
finding
subtle
bugs.
So
I
think
that's.
Why
we're
we're
kind
of
opting
for
this
experimental
mode
right
now,.
C
So
I
think
the
big
difference
between
south
and
experimental
is
that
experimentally
looking
for
more
feedback
on
the
direction
you
should
go
on.
The
reason
I
asked
is
because
ipv6
is
alpha
right
now
and
it
this
would
mean
that
we'd
have
one
ipv6
feature
that
was
often
one
that
was
experimental.
I
don't
know
if
that
would
create
confusion
or
anything,
but
that
was
like
that.
One.
G
A
G
B
G
G
G
G
G
G
H
E
A
G
G
F
F
So
you
know
the
question
I
have.
Is
you
know
what
is
the
path
for
for
this
from
going
from
alpha
to
beta?
You
know,
could
it
be
more?
Is
there
anything
blocking
this
other
than
say
you
know
better
documentation,
or
you
know
additional
unit
tests,
I'm
kind
of
given,
given
those
limitations
that
we
have
right
now.
J
Custom
go
ahead
from
from
environments,
we
go
for
112
we're
scheduled
to
have
proxy
config
as
a
crd,
so
from
the
point
of
view
of
if
after
the
api
review,
because
for
the
first
thing
is
in
investment
and
proxy
config,
we
have
very
low
bar
to
add
apis.
I
think,
for
anything
that
we
promote
to
data,
we
need
drc
to
approve
the
api.
J
You
know
as
it
is,
because
it's
a
responsibility
that
will
you
know
we
need
to
support
it
for
a
very,
very
long
time
and
we
cannot
just
take
you
know
things
we
added
experimental
and
automatically
promote
it
without
the
property
review,
but
if
the
decision
is
to
keep
it
in
proxy
config
and
I'm
okay
with
that
in
112,
we
have
a
vehicle
and
it
will
be
a
crd.
So
we
can,
we
can
do
whatever
is
necessary
to
maintain
it
and
to
test
it
now.
J
My
concern,
I
put
a
note
on
the
side,
is
forward.
Client.
Sir
details
interacts
with
another
discussion
in
security
and
networking
about
how
to
set
headers
about
security
related
properties
and
again
we
should
have
a
consistent,
ideally
reconsistent
behavior.
We
cannot,
you
know,
do
things
differently
and
we
should
treat
it
as
an
api
that
we
want
to
support
a
long
time.
But
in
the
end,
if
the
decision
is
to
keep
it
as
it
is
and
not
doing
anything,
then
we
have
the
fake
screen
112.
J
Not
necessarily,
but
at
least
we'll
be
having
crds
that
you
know
we'll
have
some
validation
and
we
we
will
have
some.
We
already
have
a
review
about
which
deals
to
kill
and
which
fields
to
to
promote.
Maybe
alpha
two
may
be
better,
that's
a
different
decision,
but
at
least
this
is
moving
forward
and
and
it
will
have
a
proper
city
and
some
garbage
removed.
G
Yeah
so
lin,
in
my
mind,
at
least,
if
we
are
making
the
proxy
config
crd
and
since
mesh
config
or
proxy
configure
column
have
been
an
alpha
for
a
long
time.
It
would
probably
make
sense
to
make
a
beta
directory
since
we
are
going
to
take
the
fields
which
we
know
we
want
and
move
it
there
right
like.
These
are
the
fields
that
belong
there,
so
at
least
that
part
should
be
beta
and
then,
as
we
already
have
like
within
a
beta
api,
we
do
have
some
alpha
fields
so
going
forward
when
we.
J
J
G
I'm
not
talking
about
these
fields.
I
was
talking
about
general
proxy
and
faith
yeah,
all
right
so
now
for
this
one,
I
think
that
debate
can
be
had
which
also
lou
is
mentioning
right.
Where
does
this
belong,
but
they
belong
in
a
gateway
class
api?
Do
they
belong
in
proxy
config
or
do
they
belong
somewhere
else?.
G
H
Yeah
for
me,
I
think
the
gateway
question
definitely
blocks
going
this,
but
I'm
not
sure
how
I
feel
about
getting
into
beta.
I
kind
of
feel
like
this
has
been
around
for
a
while
and
is
something
we
think
users
should
be
able
to
keep
using
and
it's
going
to
proxy
convict
going
to
beta,
as
it
sees
okay.
K
K
J
J
Whatever
is
a
result
for
jot,
it
should
be
consistent
and
xfcc
in
particular,
is
very
hard
to
parse,
and
it's
not
really
a
very
good
api
that
we
want
to
support
long
time,
because
again
it's
it's
it's
it's.
It
has
a
syntax
that
it's
you
know
very
variable,
and,
and
so
so
so
if
we
start
extracting
claims
from
certificate
and
trusting
the
certificates,
probably
we
don't
want
this
api
in
particular,.
J
Well,
we
we
don't
actually
use
it
in
in
anywhere.
It's
just
pass
through
and
the
syntax
is,
you
know
we
can
have
a
different
field,
including
not
including
I
mean
full
certificate,
not
for
certificate
and
whatever
it's
a
pretty
complicated
config.
It's
not
just
pass
it
to
so
I
I
I
security,
review
and
and
and
security
and
networking
should
reviews
what
how
we
want
to
deal
with
with
claims
from
mtls
or
from
from
jobs
and
should
have
a
consistent
story.
M
J
No,
this
is,
this
is
a
very
specific
header
and
it's
particularly
bad.
If
you
want
to
do
security
decisions
based
on
it,
I
mean
given
the
syntax
and
and
how
difficult
it
is
to
pass
correctly.
It
has
quotes
and
and
and
certificates,
and
then
you
have
either
full
certificate,
or
so
I
I
actually
try
to
use
it
for,
for
you
know,
different
things,
and
and
and
it's
it's
a
it's
a
huge
pain,
even
if
it
wasn't
a
huge
pain.
J
N
J
That
that's
exactly
what
I'm,
what
I
want
to
support,
but
they
are
not
supported
if
you
are
in
an
open
in
a
gateway
to
popular
case.
So
if
the
mtls
is
not
terminated
in
in
the
gateway
directly,
but
you
go
to
network
topology,
the
information
that
you
talk
about.
They
are
passed
in
this
header
and
nobody
is
parsing,
this
header
and
we
we
ignore
them.
Basically,
that's
what
I'm
talking
about.
So
we
don't
support
our
own
api.
If
you
are
in
a
network
topology
in
a
gateway,
topologies.
N
J
That's
that's
a
header
delegation.
We
have
mtls
terminated
in
the
front
end
and
then
the
information
is
passed
somehow
to
to
easier
and
easter.
Would
you
know
somehow
use
it
in
its
own
api
and
trick
it
as
it's
a
pretty
complicated
program
and-
and
I
want
to
make
sure
we
have
a
you-
know,
an
understanding
of
how
we
are
going
to
solve
it
before
we
promote
an
api
to
that.
That's
my
point.
G
G
I
don't
know
if
you
want
to
make
what
kind
of
choices
you
want
to
make
right.
This
is
basically
to
mostly
for
application
consumption.
If
you
want
your
proxy
can
also
make
decisions
based
on
it,
but
this
field
right
now
just
tells
you
whether
you
are
forwarding
whether
you
are
sanitizing
or
whether
you
are
appending
right.
G
J
G
K
K
I
do
think
it
would
be
nice
if
we
can
have
a
little
bit
more
guide
on
how
this
could
be
used,
because
the
documentation
right
now
essentially
only
teaches
you
how
you
could
potentially
enable
it
and
what
are
the
options
you
could
do
to
enable
this,
but
it's
like
in
like
a
guidance
of
as
a
user.
What
am
I
going
to
do
with
this
information?
I
think
niraj.
You
are
more
indicated
as
the
application
developer
for
the
service
owner
now.
This
is
the
additional
information
they
can
potentially
leverage
and
pass
through
their
application.
K
G
Yeah,
so
I
think
that's
a
fair
point:
we
can
beef
up
the
documentation,
so
that's
the
feedback.
I
guess
jacob
for
you
right.
We
can
make
sure
I
think.
Currently
this
points
to
onward
documentation
but,
like
I
think,
when
cost
was
saying
sometimes
the
onward
documentation
is
more
confusing.
So
we
that
this
that's
definitely
doable.
J
J
That's
what
that's
how
the
termination
would
use.
I
mean
that's
what
you
do.
The
first
front-end
terminates
mtls
and
then
is
passing
this
header,
but
we
just
pass
it
through
without
applying
it
in
our
pack.
So
we
have
an
arbuck
saying
that
mtls
client
principle
must
be
x.
We
don't
see
it
because
it's
a
header
that
we
we
ignore.
Basically.
J
K
G
Yeah,
I
mean
those
I
mean,
like
I
said
those
are
valid
to
add
as
later
on,
we
can
say:
okay,
this
is
how
you
do
these
things
in
authorization
I
think
currently
what's
allowed
is
you
can
do
per
hop
validation,
as
I
can
see
so
at
the
gateway
you
can
configure
authorization
policies
which
will
say
only
allow
traffic
for
these
principles
and
then
at
the
service
level.
You
can
say
I
only
want
to
be
contacted
by
ingress
gateway
principle
right,
that's
how
you
will
have
authorization.
G
J
N
I
think
that
would
be
a
new
feature
request
right,
because
xfcc
here
it
was
originally
implemented
for,
like
only
using
the
user
application
like.
Actually,
we
have
like
several
github
issues
filed
by
customers,
asking
that
they
prefer
to
use
that
heater
in
the
application.
That's
why
we
added
this
in
the
first
place,
but
for
use,
starting
also,
that
would
be
a
new
visual
crisp.
H
G
H
H
G
H
J
K
G
H
G
F
H
G
Okay,
I
think
I
think
the
summary
is
basically
we're
talking
about
the
gateway
topology
field,
which
is
part
of
proxy
config.
The
xff
x
forwarded
four
header,
which
is
configured
via
num,
topology
or
number
of
hops.
That
seems
useful
and
clear.
Many
people
are
using
it
the
xfcc
side
of
house
where,
at
the
gateways
you
decide
you
want
to
sanitize
you
want
to
set.
You
want
to
append
that's
little
unclear
in
terms
of
how
users
can
use
it
and
what's
a
benefit.
G
So
that
was
one
request
to
make
sure
we
add
more
examples
and
clarify
the
documentation
before
we
can
mark
them
as
data,
and
the
beta
promotion
is
contingent
on
the
fact
that
proxy
config
is
not
contingent,
but
proxy
config
itself.
Crd
will
be
beta
in
112
and
if
it's
not,
then
probably
will
promote
this
independently.
L
L
G
L
I
see
yeah,
I
do
agree
that
oc
policy
based
on
their
x,
f,
xf
cc,
will
be
very,
very
important
in
the
future.
If
we
want
to
promote
it,
because
we
can't
rely
on
the
back
end
to
consume
it,
and
also
we
don't
have
flexibility
to
configure
their
services
avoid
proxy
to
like
to
decide
what
to
do
right,
yeah,
but
I
I
think
it's
okay
to
promote
to
beta
and
since
the
default
is
forwarding,
we
can
still
rely
on
their
user's
backend
to
consume.
It.
J
L
L
L
So
itself
is
about
security
information
and
it's
not
we're
understood
standard.
I
think
that's
the
risk
here
yeah,
but
I
think
beta
is
okay
might
be,
but
not
ga.
If
we
want
to
go
ga,
we
want
to
defend
their
all
c
and
allow
users
to
define
on
z,
based
on
that,
so
that
we
can
close
their
loop
just
on
their
envoy,
avoid
proxy
not
depend
on
the
back
end.
F
G
A
A
I
I
need
one
pair
strategy
document
for
his
to2022
so
that
I
can
kick
up
the
roadmap.
I
know
toc
is
supposed
to
do
that,
but
I
need
one
person
who
I
can
connect
with
or
I'm
happy
to
connect
with
all
of
you.
But
since
everyone
is
busy,
the
financial
can
take
the
charge
and
make
the
job
easier.
For
me
I'll.
H
A
B
B
John
recently
noted
that
on
the
supported
versions,
page
that
we
have
actually
tested
110
with
122.,
but
yeah
we're
going
to
be
in
this
situation,
where
we
have
an
interesting
support
window
gap
and
it
might
just
be
a
good
idea
to
say
that
110
is
supported
on
122
instead
of
being
tested,
but
not
officially
supported,
because
it
represents
an
inching
support.
Cliff.
G
B
So
I
mean
you're
correct.
The
issue
I
think
we're
seeing
is
that
certainly
at
google
right
we're
seeing
122
start
to
roll
out
into
gke's
rapid
channel,
and
so
we
we,
we
had
a
support
gap
right
where
we
had
to
tell
users
that
they
had
to
take
110,
which,
at
the
time
or
like
before
several
days
ago,
was
the
only
supported
release
that
would
work
on
that
kubernetes
version.
B
C
M
C
B
Hard
time
so,
the
right
we've
already
said
that
it's
tested,
but
not
supported.
We
could
say
that
it's
supported
right,
it's
not
strictly
in
in
policy,
but
it's
an
interesting
challenge
for
users
today,
right
who
are
going
to
move
to
122.
right.
Well,
they
can't
right
the
challenge
for
us
at
google.
Was
it
with
gk's
channels
right?
B
B
B
B
B
C
I
H
H
G
Yeah,
I
think
there
are
two
things
right:
either
we
revise
and
create
a
smart
policy
that
can
handle
this,
which
I
think
is
a
little
trickier,
because
if
you
look
at
110
we
already
have
four
officially
supported
releases
and
then
three
additional
releases
which
are
tested.
That
means
somebody
has
at
least
done
the
work
for
seven
kubernetes
releases
right.
So
I
think
the
other
thing
that
what
lewis
was
trying
to
start
was
maybe
saying
in
the
beginning.
Is
it
an
exception
case?
G
G
G
G
B
H
And
there
there
still
could
be
a
problem
there.
I
think
that
nurse
was
pointing
out
like
so.
Let's
say
one
time
came
out:
a
user
is
on
110
one
uh-huh.
If
they
go
and
upgrade
kubernetes
without
upgrading
istio,
maybe
it
breaks
because
they
didn't
read
the
fine
print
that
only
110.3
is
supported
on
yep.
B
Right
I
mean-
maybe
maybe
we
have
to
like
look
at
how
we
represent
the
data
yeah.
Maybe
we
caveat
the
patch
release
or
something
like
that,
so
you
get
you
know
122
in
parenthesis,
1.10.4
right
and
then
it's
fairly
clear
right.
But
given
that
we're
on
a
three-month
cycle
and
they're
on
a
four-month
cycle,
we
will
have
one
release
where
there's
two
months
of
drift
right.
E
K
B
G
B
People
must
be,
I
suspect,
you
know,
you
know,
m
out
the
end
service.
Mesh
solutions
in
the
market
are
scrambling
right
now
to
figure
out
why
their
customers
are
broken
when
they
get
upgraded,
if
they,
if
they
copied
what
we
did
or
didn't
copy,
what
we
did
so,
I'm
sure
there's
some
wailing
and
gnashing
of
teeth
going
on
elsewhere.