►
From YouTube: Ambient Mesh WG Meeting 2023 03 22
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Right,
yeah
I
wanted
to
talk
a
bit
about
compatibility
and
by
that
I'm
talking
mostly
about
between
when
we
ship
1.18
with
Alpha
between
1920,
whatever
we
decide
is
beta
and
what
kind
of
compatibility
guarantees
we're
going
to
offer.
I
recommend
none
and
to
further
that
I
recommend
that
we
start
off
intentionally
making
a
breaking
change
so
that
we're
not
overly
cautious
about
compatibility
and
making
ambient
worse
off.
You
know
by
favoring
backwards
compatibility
or
doing
the
right
thing.
B
C
So
the
idea
is
that
we've
already
had
a
lot
of
breaking
changes
in
ambient
to
begin
with.
Right
it
doesn't
respect
all
the
same
apis
as
the
studio
does
inside
car
mode.
Then
there
would
be
a
second
set
of
braking
changes
when
we
go
to
Beta.
B
I
think
what
your
first
thing
was
about
sidecar
to
ambient,
which
is
true,
I'm,
talking
more
about
ambient
Alpha
to
ambient
beta
like
no
one
should
expect
to
upgrade
an
ambient
cluster
without
downtime.
No
one
should
expect
for
the
old
version
of
the
new
version
interoperate
or
anything
along
those
lines.
C
B
D
That's
how
it
should
be
I
mean
what
what
is
I
mean:
I'm,
not
sure
if
we
should
intentionally
make
a
breaking
change
but
I'm
guaranteed.
That
will
make
a
breaking
change
unintentionally.
So
the
dogs
need
to
be
absolutely
clear
that
it's
an
alpha
e118.
We
get
a
visit
in
119..
Yes,.
B
So
I
I
agree,
that's
how
it
should
be
as
Alpha.
Historically,
that's
not
how
we
treated
alphas
and
I
want
to
make
sure
that
six
months
down
the
line
when
we
want
to
make
a
breaking
change.
That
is
incompatible
with
the
alpha,
but
is
far
better
in
what
we
want
to
do
that.
Someone
in
this
group
is
not
going
to
say,
hey,
but
I
want
to
upgrade
from
alpha
to
Beta
with
no
downtime
I
want
to
find
that
out
now,
instead
of
six
months
from
now
is
really
the
goal.
D
Going
to
say
something
so
John
we
had
a
discussion
in
previous
meeting
about
the
safety
Steel
and
that
apis
that
are
already
better
and
that
we
commit
to
them
to
be
better
even
in
ambient
needs
to
remain
better.
So
if
gamma
is
better
and
someone
is
using
gamma,
it
is
expected
they
will
not
have
to
make
changes
when
we
upgrade
to
whatever
version
of
you
know
ambient
or
whatever
else
and
any
you
understand
what
I
mean
I
mean.
D
If
a
user
is
using
gamma,
you
don't
guarantee,
you
know,
seamless
migration,
we
don't
want
to
do
anything,
but
but
if
you
use
gamma
API,
you
should
not
have
to
make
changes,
but
it
is
any
better
API.
D
D
D
Back
I
completely
agree:
no,
no,
no
I'm,
not
I'm,
not
saying
we
should
not
remove
it.
We
should,
if
we
launch,
you
know
if
we
say
that
ambient
supports
authorization
without
workload
selector,
we
document
it
and
we
commit
to
it.
So
once
we're
seeing
that's
that's
how
it's
supposed
to
be,
we
don't
go
back
to
it
and
add
it
backwards.
B
Oh,
that's!
That's
exactly
what
I
so
my
topic
achieved
its
goal
is
that
I
wanted
to
weed
out
opinions
like
this
early
I.
Don't
want
us
to
commit
to
anything
on
ambient
today,
because
we
don't
know
we
have
no
feedback
from
users
on
how
it
works
we
haven't
done.
We
haven't
even
implemented
the
new
workload
selector
replacement
right,
so
we
have
no
even
internal
feedback
from
our
own
team
making
commitments
to
things.
That
is
basically
our
one
time
to
make
changes
on
the
future
of
istio
without
any
real
feedback.
I
think
is
a
mistake.
B
D
B
D
E
B
Api
sorry
Francis
standard
wrap.
Okay,
if
you're
using
an
alpha
platform,
then
the
fact
that
the
apis
are
stable
has
no
meaning
you
have
the
lowest
common
denominator.
It
becomes
Alpha
right
if
you
use
the
stable
API
on
the
stable
data
plane,
sidecars
the
net
stable,
but
a
stable
API
on
the
alpha
data
plane.
Ambient
makes
the
API
also
Alpha
and
subject
to
changing
Behavior
I.
Think
that's
how
I
view
it
like.
We
can't
somehow
say
that
something
stable
on
an
alpha
platform.
A
D
Rule
no!
No,
if
we,
if
we
claim
it
supported
by
Ambience,
so
we're
saying
ambient
may
make
a
claims
that
HTTP
route
is
supported
and
then
we
are
committed,
but
we
may
not
make
this
payment.
We
can
not.
We
can
choose
to
say
that
authorization
apis
are
not
supported
in
ambient
prices.
It's
an
alpha
experiment,
but
the
yeah
I
completely
agree
on.
If
we
are
very
clear
about
I
mean
maybe
in
contact
with
the
safety
steel,
we
have
something
similar
to
ambient
where
the
list
may
be
empty,
then
I
think
it's
reasonable.
B
Okay,
so
just
to
be
extra
clear,
you
are
okay
with
saying
that
there
is
no
compatibility
guarantees
between
1.18
ambient
Alpha
and
1.19
ambient
Alpha,
slash
beta
wherever
we
get
by
that
point,
even
with
the
stable
apis.
Like
awesome
policy.
E
C
So
Phil
has
a
question
in
the
sidebar
well
ambient
it
here
the
semantic
versioning
moving
forward
once
released,
or
will
there
be
more
version
changes
Phil,
I
think
that
istio
has
never
revved
past
the
the
one
major
version.
All
of
our
releases
have
been
minor
version
releases,
which
I
think
technically
are
not
supposed
to
include
breaking
changes
that
we
have
had
some.
E
B
Mean
kubernetes
model,
which
is
kind
of
that
diversion
is
unrelated
to
compatibility
and
the
compatibility
is
really
the
alpha
beta
stable
feature
stages,
which
the
alpha
I
mean
ambient
will
progress
through
those
stages
and
we
have
definitions
of
what
those
means.
What
those
mean,
so
you
know
in
1.8,
can
we
plan
to
announce
ambient
as
Alpha,
which
is
basically
ad
in
every
category
right?
We
can
make
breaking
changes.
It
may
have
security.
B
Bugs
performance
issues
would
all
be
about
which
all
are
true
for
ambient
today,
but
once
we
get
to
Beta
I
think
there's
I.
D
Sorry
HTTP
route,
it's
beta
and
it's
got
a
typical
guarantee
to
be
stable
and
minor
changes.
When
you
move
to
V1
anything
that
is
Alpha,
it's
alpha,
everything
that
is
initial
virtual
service
or
authorization.
We
may
have
a
different
API
that
that
replaces
it.
Then
it
may
not
be
supported
in
ambient
but
will
not
change
it.
B
Okay,
unless
anyone
else
has
anything
we'll
move
on
to
the
next
one.
B
All
right,
this
is
an
extension
of
this
giant
dock
on
all
the
ambient
apis,
but
specifically
about
egress.
So
in
the
past
we
have
kind
of
focused
on
Ingress
or
producer
waypoints,
where
you
know
the
produced
service
runs
their
Waypoint.
All
traffic
going
to
the
service
goes
through
their
Waypoint
and
we
agreed
to
kind
of
defer
egress
for
now
and
they
kind
of
it,
the
not
the
default.
B
So
what
this
new
part
of
the
dock
is
kind
of
exploring
how
we
can
reintroduce
egress
into
ambient
and
what
that?
What
that
might
look
like
I
would
say
that
everything
here
is
is
pretty
pretty
up
in
the
air.
I'd
say
and
I
also
think
that,
just
because
we're
talking
about
it
now
doesn't
necessarily
mean
it's
even
something
that
we
include
in
the
short
term.
It
could
be
something
that
we
even
go
to
stable
without
and
add
it
later
right.
B
It
doesn't
have
to
to
be
done,
and
we
don't
have
to
do
all
that
either
we
could
it's
kind
of
progressively
more
and
more
features.
Added
to
this
in
the
stock,
I
actually
had
a
few
more
ideas
that
I
didn't
put
on,
because
I
didn't
want
to
add
more
confusion,
but
you
know
just
trying
to
say
like
we
don't
need
to
do
all
this.
We
could
do
summer
of
it
or
none
of
it.
B
So,
let's
see
yeah.
So
just
a
reminder
like
the
Baseline
Behavior
today
is
that
you,
even
if
everyone
in
the
cluster
has
waypoints
all
traffic,
will
will
not
go
through
them.
On
the
egress
side,
it's
only
inbound
waypoints.
B
So
in
ambient
things
are
a
bit
different
than
beside
cars
and
sidecars.
We
can
just
match,
you
know
on
hostname,
google.com
or
something
if
we
want
to
match
traffic
to
google.com,
but
in
ambient
we
we
have
kind
of
two
layers,
so
we
have
Z
tunnel
which
is
only
doing
L4.
B
So
we
can't
possibly
tell
Z
tunnel
to
Route
traffic
to
google.com,
because
that
requires
like
host
header,
matching
arrest
and
I
matching,
which
Z
tunnel
is
not
going
to
do.
We
can
have
the
Waypoint
do
that
because
it's
doing
the
L7
processing,
but
we
need
to
know
what
traffic
to
actually
get
to
the
Waypoint
in
order
for
it
to
do
that.
B
B
So,
in
my
opinion,
we
should
focus
on
making
it
very
explicit
egress,
similar
to
how
Ingress
is
that
we,
you
only
actually
have
routes
for
the
things
you're
actually
going
to
send
graphic
through,
and
it's
not
just
like
sure,
give
me
information
about
the
entire
world,
which
we
know
doesn't
scale
so
well.
Actually,
if
there's
any
questions
now
before
I
present
more
concrete
ideas,
please.
B
Okay,
so
the
first
step,
I,
think
and
largely
I
expect
this
to
be
more
of
a
low
level.
Config
there's
a
higher
level
config
in
the
next
section,
so
don't
get
too
hung
up
on.
This
is
to
Define
kind
of
an
L4
routing
API.
B
So
if
we,
if
you
anyone,
was
reading
through
closely
on
the
XDS
dock,
there
was
a
section
where
I
proposed
adding
a
route.
This
is
kind
of
that's
kind
of
the
implementation
details
of
how
this
API
would
be
implemented,
which
I
think
is
next
on
the
agenda.
So
from
a
user
perspective
we
would
allow
them
basically
create
a
TCP
route.
That's
part
of
the
Gateway
API
today,
which
can
match
on
basically
a
cider
or
a
report
and
send
it
to
a
gateway.
Gateway
could
be
an
egress
Gateway
or
a
waypoint.
B
Both
of
them
are
represented
by
gateways.
So
it's
the
same
same
kind
of
logic
there
and
all
of
a
sudden.
It
tells
the
Z
tunnel
that
this
traffic
needs
to
go
through
the
Gateway.
It
doesn't
actually
configure
any
routes
on
that
Gateway.
So
now,
if
you
only
have
this
config
like
the
traffic,
would
get
to
the
egress
Gateway
or
the
Waypoint,
but
then
it
would
just
be
dropped.
B
B
Yeah,
this
is
more
saying
once
the
traffic
gets
to
the
tunnel
after
the
direction.
What
is
the
next
hop,
and
so
we
would
have
kind
of
I
mean
I'll
go
more
into
it
later,
but
a
precedence
of
like
okay.
Is
it
a
known
service?
It
goes
to
the
service
routing.
Is
it
an
own
pod?
It
goes
to
the
Pod
routing.
If
it
matches
a
route,
then
it
does
the
routing
Behavior
and
you
know,
kind
of
allows
like
override
beyond
the
service
mechanism.
D
D
Separation
solution,
but
but
it's
it's
also
important.
B
Agreed,
would
you
mind
scrolling
down
to
the
next
section.
B
Francis,
could
you
scroll
to
the
next
section,
also
you're,
muted,
by
the
way?
Thank
you
yeah,
just
if
you
could
just
focus
only
on
the
service
egress
routes.
That
would
be
there.
We
go
cool,
so
the
the
way
I
expect
users
to
use
it
more
commonly
would
be
not
doing
PCP
routes
which
is
kind
of
the
lower
level
and
but
is
using
the
higher
level
routes
like
HTTP
route.
B
So
if
we
wanted
to
do
a
consumer
override,
for
example,
where
you
know
their
Echo
service
to
find
some
rules
but
I,
as
in
my
own
namespace,
when
I
override
it
and
I
don't
know,
set
some
time
out
or
whatever
today,
we
don't
have
a
way
to
do
that,
but
in
the
gamma
API
there's
a
a
way
they
specify
on
how
to
do
this,
which
is
basically,
if
you
are
attaching
to
a
service,
that's
in
another
namespace,
then
it's
considered
a
consumer
override
right,
and
so
we
can
now
Diego
hydroson
yeah.
D
I
I
think
we
we
we,
we
may
again
confuse
the
the
egress,
because
in
initial
classic
we
have
two
different
sides
of
the
API.
We
have
the
first
part,
which
is:
how
do
you
get
the
traffic
to
the
egress
Gateway
and
then
you
have.
The
second
part
is:
how
do
you
configure
any
Great
Escape,
maybe
a
squid
which
I
think
someone
implemented,
maybe
some
other
components
that
is
completely
outside
of
our
control.
D
B
Yeah
I.
E
B
Agree
with
you,
maybe
I
think
my
dog's
a
little
bit
different,
but
I
I
I
agree
with
what
you
said
at
the
same
time,
so,
okay,
yeah
so
I
mean
I'll
I'll
present.
What
I
have
here
but
I
think
it's
worth
revisiting
based
on
what
you
said.
I
completely
agree
so,
like
the
first
part,
I
presented
the
TCP
route
that
is
aligned
with
what
you
said
right
that
is
get
the
traffic.
It.
D
Is
it
is
mostly
online
I
would
not
put
10.000
as
an
example.
It
was
the
public
IP
ranges
and
because
IP
brain
is
very
difficult
to
to
express,
because
there
are
so
many
and
IPv6
is
also
kind
of
messy.
Probably
we
should
have
a
default
Behavior
where
all
the
public
IP
addresses
go
to
the
Escape
if
I
defaults,
that's
my
as
usability
I
think
I
had
a
document
in
the
past
about
the
same.
The
same
same
thing,
foreign.
B
Default
but
maybe
we
can
have
like
aliases
or
something
so
you
can
say,
match
public.
E
G
Yeah,
that
was
the
part
that
I
mean
I
I,
agree
that
we
need
some
way
to
capture
the
traffic,
but
in
sidecar
mode
right.
The
user
doesn't
have
to
be
aware
and
I'm
not
saying
that
the
users
aren't
aware
of
these
IP
ranges,
but
the
user
didn't
have
to
care,
whereas.
G
Understand
the
technical
limitations
of
why
we're
imposing
using
the
TCP
route
with
IP
ranges
or
Port
ranges
right,
but
from
a
user
perspective
it
requires
a
different
knowledge
of
the
underlying
system
right,
they
need
to
know
the
potentially
the
IP
ranges
of
their
services
that
they
can
say.
Well,
not
this
IP
range
or
something
right
and
I
I'm,
not
arguing
that
this
is
the
wrong
way.
I
just
want
to
point
out
that
this
is
feels
almost
I
I
unders,
like
capturing
by
host
I,
understand
why
that
is
like.
G
D
I
I
mean
maybe
I
was
not
talking
about
my
my
proposal
earlier.
I
mean
I.
Think
Jones
TCP
route
did
something
for
advanced
users
that
have
you
know
non-standard
compliant
networks,
but
for
virtual
old
users,
egress
should
work
automatically
out
of
box
with
no
configuration
whatsoever.
You
don't
you
should
not
have
to
put
a
TCP
route
in
the
system
or
understand
routes
or
cidrs
or
anything
like
that
to
to
use
egress.
D
Definition
of
internal
is
a
tricky
one.
The
definition
of
external
is
very
simple,
because
it's
clear
that
note,
10,
dot,
x,
0
and
192.168
cannot.
We
can
be
routed
on
egress,
so
it
cannot
be
egress,
but
for
Ingress
we
may
have
you
know
some
Auto
detection,
looking
at
kubernetes
cluster
info
to
find
out
the
port,
CID
Arrangement
and
for
all
pasta.
Since
the
mesh,
we
can
look
at
the
service,
CID
arranges
or
you
can
just
State
blindly,
all
private
IPS
are
internal.
We.
G
Right,
I
think
guess
what
I'm?
What
I'm
trying
to
say
here
is
I
think
this
gets
this
moves
into
a
potentially
complicated
space
of
you
know:
how
do
we
make
it
easy
versus?
How
do
we
make
it
configurable
and
I
think
that
there
is
a
balance
here,
but
I
think
that
yeah
what
you
said
about
potentially
cap
like
sending
all
unknown
IP
you.
G
Traffic
to
these
egress
gateways
that
that
potentially
Rings
true
for
me
but
I,
think
it's
that
that
it
that
interaction
that
I
just
want
to
make
sure
we
were
capturing
oops.
I
Okay,
great,
oh
I,
guess
I
have
a
couple
of
questions.
I'll
just
say
it
about.
F
I
I
E
B
Maybe
maybe
I
don't
know
if
T
I
don't
know
if
the
TCP
route
one
can
use
Virtual
service
to
be
honest,
because
we
don't
have
a
way
in
Virtual
service
to
say
forward
to
a
Gateway,
but
you
only
can
forward
to
a
hostname,
so
we
could
kind
of
hack
it
together.
If
we
really
needed
to
I,
don't
know,
maybe
maybe
it's
my
answer.
I
should.
B
We
could
probably
make
it
work
if
we
so
desired.
Yeah,
okay,.
I
Oh
just
thinking
loud
yeah,
the
second
question
I,
have
is
back
to
what
you
guys
were
just
discussing
about
how
to
detect
external
traffic.
Sorry
about
the
background
noise
I
was
thinking
like
in
istio
user
kind
of
have
to
register
external
traffic
with
service
entries
right.
So
if
they
already
tell
us
what
are
the
external
traffics,
is
there
any
way
we
can
potentially
leverage
that
information
was
asking
them
again
in
the
TCP
routes?
I
gave
you
an
example.
You
kind
of
specify
these
see
the
block
I
have
to
go
to
the
US.
B
Yeah
one
of
the
things
I
wanted
to
avoid
was
this
implicit
behavior
on
the
Waypoint,
where
it
has
routing
information
for
the
entire
world
right.
That's
why
we
had
to
introduce
things
like
sidecar
news,
scope,
things
and
that's
something
that
we
have
solved
so
far
in
ambient
right.
The
only
the
Waypoint
only
has
the
minimal
amount
of
information
needed.
That's
not
N,
squared,
it's
pretty
small.
If
we
say
that
now,
every
single
Waypoint
in
the
match
has
access
to
every
single
service
entry.
B
Implicitly,
we
may
be
back
in
territory
where
we
suddenly
need
export
two
we
need
sidecar,
scoping
or
equivalent.
It
may
take
us
back
a
step.
On
the
other
hand,
if
it's
only
things
that
we've
declared
as
external
services,
but
you
know
as
like
mesh
external
service
entries
and
not
every
service
in
the
mesh,
it
may
be
more
tenable.
So
I'll
again
answer
your
question
with.
Maybe
it
might
make
sense.
E
E
I
D
D
D
D
B
Yeah,
maybe
I
should
have
started
with
the
the
end
instead
of
worked
my
way
up
from
the
low
level
to
the
high
level.
The
end
goal
is
basically
to
allow
a
mode
where
you
can
say
send
all
unknown
traffic
to
the
egress
Gateway
and
the
egress
Gateway
needs
zero
config.
It's
just
doing
fully
Dynamic
forwarding,
based
on
the
requested
host.
You
don't
even
need
service
entries
at
all,
so
that's
kind
of
the
North
Star,
where
I'm
trying
to
get
to
and
when
I
say
egress
Gateway.
B
That
could
be
a
shared
egress,
Gateway
or
a
waypoint.
If,
depending
on
how
you
want
to
model,
it
I
think
those
are
effectively
equivalent
as
just
whether
you
want
to
use
a
dedicated
one
for
your
own
namespace
or
service
account,
or
you
have
a
shared
one.
That's
in
the
entire
cluster
looks.
D
D
I
would
not
overall
the
word
to
word
a
waypoint
for
this
I
mean
Waypoint,
let's
keep
Waypoint
for
the
internal
traffic
for
between
ports,
and
you
know
per
namespace
Eagles
Gateway
and
Global
egress
gateways
property
more
reasonable,
and
that
also
takes
care
of
operates.
B
Okay,
let
me
continue.
This
is
a
good
discussion.
I,
like
I
said
this
was
meant
to
be
kind
of
a
really
draft,
so
a
lot
of
good
feedback
and
definitely
I'm
not
trying
to
just
push
through
what
I
have
written
here.
I
think
I
disagree
with
most
things
that
have
been
said,
but
I
will
go
through
what
I.
E
B
So,
oh
yeah,
sorry
going
back
to
what
Lynn
said
on
service
entry.
One
issue
with
that
is
that
the
vast
majority
of
service
entries
don't
have
IP
addresses
or
rips
assigned
right.
You
don't
say:
here's
my
google.com
service
entry,
it's
at
one,
two,
three
four
right,
you
just
say:
google.com,
it's
pretty
rare
to
have
a
static,
IP
defined
in
a
service
entry,
and
so
it's
most
service
entries
probably
would
not
actually
be
useful
for
for
this
purpose.
B
D
E
H
B
Currently,
you
can
have
you
can
assign
a
VIP
or
you
can
have.
Obviously
you
have
a
host
name
as
well
and
then,
depending
on,
if
it's
HTTP,
TCP
or
Sni
or
TLS,
we
do
IP
the
Sni
or
the
hostname,
so
it
depends
on
the
protocol
and
what
Fields
they
provide
yeah,
but
generally.
The
idea
here
is
that
Z
tunnel
is
not
going
to
do
much
of
any
routing
here.
B
So
in
most
cases
you
probably
want
to
say
send
all
traffic
that
I
don't
know
about
through
the
egress
and
then
the
egress
will
do
all
the
processing
from
there
or
you
say:
I,
don't
care
about
this
fancy
egress
stuff,
just
direct
go
from
Z
tunnel
and
I.
You
know
for
more
performance
skip
a
hop
which
we
could
even
have
as
a
cluster
level
config
right.
B
The
other
case,
though,
is
not
external
traffic,
but
it's
more
for
overrides
for
internal
traffic,
which
is
a
little
bit
different,
because
in
that
case
we
do
know
the
IP
addresses.
So
we
can't
have
more
focused
routes
that
say
when
I
am
connecting
to
Echo
app,
then
I
want
to
go
through
my
egress
Waypoint
and
apply
some
different
policies,
so
I
think
Austin
may
not
like
this
potentially
because
you
said
you
wanted
things
split,
but
here
it's
not
split.
So
what
this
would
do
is
actually
configure
two
parts.
It
would
configure
z101
Waypoint.
B
Thank
you
so
on
Z
tunnel,
this
would
basically
say
like
the
equivalent
of
it.
We
wouldn't
actually
literally
have
this
route,
but
this
is
like
how
we
would
program.
Z
tunnel
is
say:
Okay
match
the
echo
IP
on
this
specific
port
and
send
it
to
the
Waypoint
proxy
and
then
on
the
Waypoint
proxy.
B
If
you
scroll
down
again
today,
we
match
on
like
our
default
matches
would
be
on
each
producer
service
and
then
all
the
pods
that
are
behind
the
Waypoint.
We
basically
just
append
a
match
on
these
consumer
services
for
things
that
we
have
defined.
So
there
would
be
a
new
match
on
the
echo
IP
import
and
then
we
could
do
whatever
routing
L7
logic
that
they
had
configured
in
their
override.
B
So
the
main
difference
here
is
that
it's
not
implicit,
each
user
for
each
namespace
is
explicitly
configuring
their
override.
So
the
Waypoint
is
not
being
bloated
with
a
bunch
of
configuration
it's
only
as
they
explicitly
add
these
overrides,
which
are
pretty
rare
that
we're
adding
more
and
more
routes.
So
we
shouldn't
have
this
N
squared
problem,
where
every
Waypoint
does
about
every
service
in
the
mesh.
B
That's
that's
the
main
thing.
I
think
I
had
some
more
info
that
I
wrote
up
on
another
doc
about
the
more
like.
Once
we
get
to
the
egress
Gateway
using
the
kind
of
First
Step.
How
do
we
do
the
routing
from
there
like
today?
You
can
configure
an
eager,
Escape
way
to
do
all
these
routes,
but
it's
pretty
painful,
as
everyone
probably
knows
so
kind
of
like
the
north
star.
B
That
I
talked
about,
like
okay,
send
all
I,
know
traffic
to
the
egress
and
then
the
egress
kind
of
magically
figures
out
how
to
send
the
traffic
from
there.
I
had
some
ideas
for
that.
I
didn't
have
time
to
write
them
down
here,
but
it's
something
that
we
should
explore
and
happy
to
get
more.
Opinions
on
this
yeah
I
have
more
opinions
on
this
part,
especially
because
I'm
curious.
If
you
think
this
violates
your
splitting
of
the.
D
Well,
I
I,
I,
I,
I
I
still
believe
it
will
be
better
to
have
separate
documents.
Separate
use
cases
separate
tests
for
for
each
of
those
individual
use
cases
I
mean,
but
in
the
end,
yes,
it
will
be
a
TCP
route
for
advanced
users
and
the
mechanism.
I
completely
agree
with
you
and
I.
Just
again,
don't
like
the
confusion
about
too
many
use
cases
in
a
single
Dock
and
in
a
single
API,
but
maybe
for
1.0
for
work
for
1.04
next
dash
for
Alpha
version
of
ambient.
D
Maybe
we
should
focus
on
only
one,
which
is
probably
the
most
important
which
is
to
to
have
the
automatic
Behavior
they
do
it.
You
know
minimal
configuration
electricity
route,
Upstream
is
is
more
stable,
I,
don't
think
we
have
CID
arranging
gamma.
Yet
in
TCP
route,
I,
don't
remember.
I.
D
But
I
would
prefer
to
have
the
Upstream
PCB
route
to
handle
this,
not
ours
and
then
absolutely
I
mean
that's
a
spec.
We
follow
it,
but
that's
a
big
implementation
defaults
should
definitely
be
the
workout
of
books
and
should
be
the
first
priority.
B
Yeah
so
I
like
just
to
be
clear,
like
I,
don't
think
we
should
do
any
of
this
in
the
short
term.
I
I
wanted
to
present
it
now,
because
I
think
it
helps
to
have
kind
of
a
at
least
a
big
vision
of
where
we
should
go,
and
because
a
lot
of
people
have
have
talked
about
this,
but
absolutely
I
think
Ingress.
We
should
focus
heavily
on
stabilizing
that.
D
B
Got
it
yeah,
okay,
I,
see.
B
Go
ahead!
Lynn.
I
Yeah
so
I
think
this
is
probably
clear
to
you
and
Carson
and
people
who
are
very
familiar
with
the
giveaway
API.
It
might
be
worthwhile
for
you
to
highlight.
What's
in
this
proposal,
unique
to
istio,
that's
not
part
of
the
Gateway
NPI.
Is
it
just
to
see
the
block
I
couldn't
tell.
B
Yeah,
so
for
the
consumer
override
part
that
is
following
the
gamma
spec,
just
as
as
defined
the
only
thing,
that's
a
little
odd
about
it,
I
mean,
like
most
people
fall
and
expect
do
it
by
sidecar
configuration
right.
So
we
are
the
only
the
only
ambient
Waypoint
implementation,
so
it's
kind
of
a
novel
implementation
of
the
API,
but
it
is
following
the
spec
as
it's
defined.
B
The
first
part
with
just
like
this
TCP
route.
Kind
of
you
know
binding
to
the
namespace
forwarding
to
a
gateway,
I
think
that's
fairly
novel
I,
don't
think,
there's
really
a
forward
to
Gateway,
that's
been
defined
by
the
spec
I
mean
it
makes
a
lot
of
sense
to
me
and
I
think
it's
something
that
we
could
probably
put
in
the
spec
as
something
that's
a
kind
of
well
well-known,
back-end
reps.
B
But
it's
not
something
that
I've
seen
used
before
I
mean
it's.
It's
allowed
like
back
in
Rifkin,
refer
to
anything,
but
it's
not
a
standardized
back
and
ref,
but
we.
D
D
D
B
Just
don't
want
the
implementation
details
of
the
Waypoint
like
service
and
deployment
to
rise
into
the
API.
If
we
can
avoid
it
because
they
may
not
actually
be
there
right,
you
may
have
a
waypoint,
that's
actuated
by
some
Cloud
load,
bouncer
or
it
lives
in
a
different
cluster,
runs
on
a
VM.
Whatever.
J
Yeah
I
mean
whether
you
refer
to
a
Gateway
or
the
service
for
the
Gateway,
but
they're
both
supported
it
just
comes
down
to
what
support
level
right.
So
we
refer
to
the
service
of
the
gateway,
then
that
is
considered
core
support,
but
John
I
do
agree.
I
like
the
idea
of
actually
using
Gateway
as
a
backend
roof,
as
opposed
to
the
service
for
the
Gateway.
J
As
you
mentioned,
the
Gateway
doesn't
have
a
service
but
I
think
just
abstracting
away
the
the
St
the
service
layer
from
the
Gateway
and
being
able
to
have
that
mental
model.
That
says:
hey
you're,
just
routing
to
this
particular
Gateway
and
not
necessarily
worrying
about
whether
there's
a
service
there
or
not.
B
D
B
B
B
Right
yeah,
so
I'd
be
fine
with
adding
a
way
to
say
that
you
can
say:
send
all
traffic
to
X.
Gateway
I
I
have
absolutely
no
problem
with
that,
and
it
could
be
a
higher
level
API
than
TCP
route.
It
could
be
cluster-wide
setting
mesh
config
I,
don't
know.
Oh
I'm,
gonna
boom
Mike
said
the
API.
I
have
no
issues
with
that.
I,
don't
think
it's
like
out
of
the
box
default
like
you
just
installed
ambient,
instead
of
your
traffic's
going
through
this.
D
D
And
then
it's
automatically
doing,
you
know
forwarding
everything
to.
B
I
mean
I
I,
like
the
idea
that
my
issue
is
that
there's
no
istio
implementation
that
can
support
that
today.
Do
you
have
to
deploy
a
third-party
thing
like
squid,
and
so,
if
you're
deploying
squid,
then
it's
not
going
to
be
the
istio
Gateway
class,
like
I
I,
feel
like
we're
close
to
there,
but
there's
some
gaps,
or
at
least
in
my
understanding.
B
D
So
we
need
to
make,
we
need
to
make
it
to
increase
gateway
to
a
compatibility
quantity
so
once
we
make
it,
and
that
also
covers
multi-network
covers
you
know,
robots
and
other
things,
and
then
we
are
in.
B
B
We
just
need
to
get
the
traffic
there.
On
the
other
hand,
if
we
want
to
use
first
party,
then
we
need
to
get
the
traffic
there
and
we
also
need
to
make
it
accept
all
the
traffic
and
pass
through
right.
B
Which
I
think
we
should
do,
but
it's
it's
a
bit
more
work
than
just
getting
the
traffic
there
from
the
Z
tunnel
and
I
agree
with
what
quad
said
in
chat
that
a
regular
Waypoint
can
be
turned
into
egress.
I
I
completely
agree
that
we
should
and
that's
kind
of
what
I
was
pitching
in
the
stock
is
that
you
can
forward
to
a
centralized
egress
Gateway
like
we
do
today.
B
There's
use
cases
for
that,
but
we
also
should
be
able
to
forward
through
our
namespace
Waypoint
as
the
egress
Point,
and
you
know
those
trade-offs
there
and
which
one
you
would
use
for
different
use
cases.
I
Yeah
I
was
going
to
say,
you
know,
I
agree,
zero,
config
is
nice,
but
I
do
think
they
are
most
likely.
A
lot
of
user
wants
the
flexibility
to
be
able
to
config
whether
it
goes
to
maybe
this
no
Waypoint,
oh,
even
no
egos,
Gateway
or
maybe
there's
a
waypoint
on
the
way
out,
or
maybe
there's
the
egress
Gateway
on
the
way
out
to
them.
So
with
all
these
conditions,
I
just
don't
know
how
can
we
get
the
zero
config
correctly,
so
I
I
would
say
I.
I
D
I
I
don't
think
we
are
disagreeing
and
we
should
have
definitely
Advanced
the
configuration
and
we
should
probably
also
have
easy
user
configuration
but
which
one
we
prioritize,
Electronics
first
I
would
say
most
common
use.
Cases
should
probably
come
first,
not
the
advanced
use
cases,
but
because
we
get
more
time
to
to
play
with
the
apis.
But
the
common
use
case.
It's
relatively
clear,
not.
I
Not
really,
if
you
think
about
in
the
context
of
multiple
clusters,
you
know,
and
then
the
traffic
goes
to
maybe
our
Amazon
Lambda
service.
You
know.
D
D
I
No,
no
just
isolated
control,
plane,
that's
multi-clustered
and
you
do
cross
costs
of
traffic,
which
is
pretty
common
too.
All
I'm.
Just
saying
is
you
know
these
scenarios
you
might
want
to
config
your
back
end,
referently
right,
so
anything
down
automatically
could
be
wrong
in
that
sense.
Well,
I.
D
I
agree
with
you
I'm
just
arguing
that
if
that's
the
common
case
that
most
users
have
and
because
most
multi-clusters
are
a
bit
more
advanced
and
you
know
single
cluster
with
an
application
just
going
to
a
through
squid
or
some
Enterprise
proxy
to
the
internet.
I
D
C
Yeah
thanks
so
I
I,
don't
have
particular
comments
on
this
issue,
but
I
noticed
that
there
are
increasingly
issues
that
spur
on
a
lot
of
really
healthy
discussion
in
our
group,
which
is
fantastic,
I'm
wondering
how
we
make
decisions
on
those
issues.
Ordinarily,
that
would
fall
to
a
work
group
lead.
But
this
is
not
an
official
work
group
of
the
istio
project,
so
we
don't
have
any
leads,
but
at
some
point
you
know
with
ambient
being
ready
to
launch
to
Alpha
in
the
very
near
future.
F
G
So
I
think
like
there's,
obviously
going
to
be
a
healthy
amount
of
discussion
about
it
and
like
as
the
design
continues
to
iterate
like
we
will
come
to
like
I
think
we
should
have
a
formal
process,
but
I
do
think
this
being
brought
up
for
the
first
time,
usually
will
bring
up
quite
a
bit
of
of
things
that
you
know,
because
the
original
designer
is
not
going
to
have
everyone's
input
immediately
and
so,
but
that
that's
natural
I
guess
is
what
I'm
saying
for
this
particular
design.
But.
D
What
decision
to
make
I
mean
the
only
thing
is,
if
someone
volunteers,
to
implement
some
parts
of
this
document,
it
will
evolve
for
experimental,
some
bnts
and
the
main
decision
would
be
to
move
to
better
particular
chronic
presentation.
We
are
not.
You
know,
we
never
said
no
to
to
trying
something
out
against
you.
E
G
B
Usually,
when
things
go
Alpha,
they
also
go
beta
on
this
doc.
I
am
not
disappointed
at
all.
With
the
amount
of
discussion.
It
was
very
much
intended
to
be
an
early
pulse
on
where
what
people
needed,
what
people
thought?
What
where
we
wanted
to
go
on
other
docs
I
mean
that's,
maybe
a
different
story
right
that
there
is
a
a
general
lack
of
the
working
group
leads
as
a
resolution
mechanism,
but
even
in
the
normal
working
groups.
We
don't
typically
rely
on
that
anyways
generally.
B
If
we
can't
come
to
agreement
on
something
which
is
exceedingly
rare,
it
ends
up
moving
directly
to
the
TOC,
which
we
could
do
here,
but
I
really
can't
remember
in
the
past
year
a
time
when
we
actually
escalated
a
disagreement.
C
F
G
Ahead
speaking
of
moving
forward
at
a
reasonable
Pace,
you
think
we
could
move
forward
to
the
next
item
at
this
reasonable
Pace
I.
B
I,
do
yes,
I
agree.
I
just
want
to
say
one
quick
thing
that
I
remembered
before
I
forget.
One
issue
we
may
have
with
this
consumer
override
business
is
that
now
the
Waypoint
has
a
different
identity
from
the
workload.
So
by
adding
a
consumer
policy,
your
identity
that
is
used
will
change.
So
we
will
need
to
account
for
that.
I
B
Yes,
so
if
you
could
open
that,
so
this
is
the
same
doc.
We
went
over
last
week,
but
it's
been
refined
a
bit
based
on
the
discussion.
I,
don't
think,
there's
much
groundbreaking
changes,
it's
just,
maybe
more
concrete
if
you
weren't,
following
the
crazy
mess
of
ideas
flowing
through
last
week.
B
B
Here
we
go
yeah
this
message,
so
I
put
this
in
here.
It's
maybe
a
little
premature,
like
I.
Don't
actually
think
this
should
be
the
last
part
of
the
stock
we
Implement,
probably
because
it's
tied
to
the
the
previous
discussion,
which
is
still
up
in
there
but
I
just
wanted
to
add
it
here
for
completeness.
B
B
So
I
just
wanted
to
quickly
introduce
that.
We
definitely
can
debate
the
exact
details
and
it
doesn't
make
sense
to
add
those
to
Z10.
Until
we
have
you
know
the
actual
user-facing
apis
defined,
but
I
just
want
to
introduce
that
real,
quick
Lynn
you
and
you
want
to
discuss
this-
was
there
specific
parts
that
you
wanted
to
go
over
on
on
this.
I
No
so
I
think
this
looks
great
I,
I'm,
sorry
I'm
on
my
mobile
phone
I.
Think
last
time
you
discussed
that
you're
going
to
add
the
weight
in
the
workflow
resources.
I
wasn't
sure
if
it's
added
so
with
that
in
place,
I
think
it's
a
reasonable
I
more
want
to
know.
If
anybody
has
strong
objection
to
this,
because
I
think
Kevin
might
already
been
writing
some
of
these
and
John.
You
probably
already
also
started
some
of
these,
so
I
just
want
to
say
you
know.
D
D
Objection
I
mean
definitely
we
need
to
to
represent
the
routes,
because
we
need
to
implement
TCP
route
in
gamma
and
Gateway
and
the
previous
documents
that
you
described
so
that
needs
to
be
present
in
somehow,
and
there
is
a
discussion
what
about
if
it
should
be
done
to
LDS,
which
already
kind
of
covers
this
to
some
extent,
if
you
ever,
if
you
have
a
kind
of
convoluted
set
of
employee
filters
and
other
things,
you
could
express
kind
of
the
same
thing
with
cluster
and
the
current
API,
and
probably
that's
what,
because.
F
D
H
Perfect,
so
my
only
concern
is
that
do
we
have
these
standard
photos
for
doing
what
this
photo
does
so
we're
just
duplicating
them,
and
that
doesn't
seem
right,
because
we
already
have
infrastructure
to
handle
the
same
product
in
grpc
and
Android,
and
now
going
to
have
a
completely
different
set
of
products
that
digital
users
do
the
same
thing.
But.
H
H
F
H
I
Comments
that
you
feel
it's
it's
unnecessarily
complex,
please
try
entering
the
documents.
H
D
What
that
will
imply
that
Z
tunnel
or
any
implementation
of
a
equivalent
of
ambient
will
have
to
be
employed
effectively
or
support
the
employee
configuration
model
and
you
know
have
listeners,
have
the
same
kind
of
filters
and
if
we
have
the
problem
with
proxy
the
grpc
by
the
way,
someone
has
a
field
to
to
something
proxygrpcc
plus
influential
crash,
because
they
they
have
stick
validation
for
something.
So
it's
not
entirely
true
that
you
have,
you
know,
listener,
filter
and
so
forth
and
automatically
grpc
and
Envoy
work.
H
H
B
Participating
yeah
I
think
this
is
a
not
something
we're
going
to
solve
in
this
meeting.
It's
something.
That's
we've
discussed
quite
a
bit
I'm
happy
to
discuss
more,
but,
in
you
know
very
happy
to
delay
the
route
until
we
fully
resolve
it,
but
I
don't
think
it
should
block
adding
what
is
effectively
tooth
yields
to
the
existing
API.
We
have
like
we,
we
it's
kind
of
in
some
ways,
a
philosophical
discussion
of
like.
B
B
We
can
revisit
that,
but
I,
don't
think
tweaks
to
the
API
should
be
blocked
on
revisiting
that
discussion.
Now.
This
is
the
exact
type
of
thing
that,
like
Mitch's
comment
on
how
we
resolve
this,
you
know
I,
think
it'd
be
very
reasonable
to
have
this
go
to
Toc,
to
weigh
in
on
what
our
direction
is,
because
this
is
a
high
level
API
decision
on
whether
we
are
aligning
on
existing
apis
or
defining
our
own
right.
That's
a
very
doc
type
decision
to
make.
E
B
D
B
The
main
thing
so
well,
there's
a
new
service
API
dedicated
to
representing
a
service
so
that
we
can
put
things
like
affinity
and
other
service
level
objects
like
host
names.
We
don't
have
hostname
today
and
then
in
the
actual
workload
itself.
The
only
thing
really
is
that
we
make
Waypoint
a
bit
more
flexible
than
just
an
IP
address,
so
that
it
can
be
a
host
name
and
have
a
port,
and
we
make
a
network
Gateway
Fields.
B
I
mean
I
personally
have
a
pretty
strong
opinion
on
that.
We
do
it
this
way,
but
I'm,
very
biased,
I
wrote
the
doc.
Obviously
there's
other
people
who
would
agree
with
you,
I'm
sure,
probably
quad
and
I
know
some
other
people
have
expressed
similar
opinions.
B
So
if
we
I
mean,
if
there's
this
tension,
then
we
can,
like
you
know,
have
a
resolution
and
discuss
this
in
the
QC.
If
we're
aligning
on
Envoy
or
making
our
new.
G
We
spent
like
a
couple
like
a
lot
of
time
talking
about
this
a
couple
months
ago,
and
this
is
like
this
takes
basically
this
Dock
and
throws
us
back
to
December
so
like
if
we
want
I
agree
with
John
that
if
we
want
to
align,
if
we,
if
we,
if
we
want
to
make
the
decision
now
like
if
we
want
to
decide
now
that
we
want
to
align
the
entire
API
with
XDS,
like
that's
a
much
higher
level
discussion,
and
we
should
take
it
out
of
this
meeting
right
now
because,
like
there
are
folks
in
this
meeting
that
are
blocked
on
this
design.
B
I
will
say
as
well
that
I
think
I
mean
please
correct
me
if
Iran,
but
I,
think
Louis,
Lin
and
I
are
pretty
strongly
in
favor
of
using
these
apis
rather
than
the
envoy
apis.
B
D
But
John
I
mean
we
had
the
discussion
about
the
the
workload
Discovery
service,
which
is
difficult
to
put
for
something
that
is
not
covered
by
existing
apis.
It's
pretty
different
because
it
covers
other
use
cases
yeah,
wait
that
doesn't
mean
that
if
it's
a
it's
a
global
decision
that
affects
all
apis
and
not
completely
opposed
with
the
except
for
router
or
not
completely
opposed
for
not
using
cdscbs,
and
my
interest
would
be
actually
to
have.
D
You
know
hpod
Federate
and
you
know
in
CD
and
CDs
and
generate
this
API
at
least
so
we
support
CDs
EDS
but
with
because
that's
a
problem.
There
are
all
kind
of
implementations
that
already
I
mean
it's
a
console.
Remember
console
implementation,
which
we
translated
to
console
to
XDS
regions
or
other
ways
to
to
generate
endpoints
and
clusters
to
to
XDS.
I
I
I
D
I'm
not
against
it
I
mean
I'm
I'm
perfectly
fine
with
having
this
as
a
private
DPM
only
thing
that
I'm
I'm
strongly
for
is
to
have
ability
to
bridge
existing
EDS
CDs
implementation
into
into
ambient,
so
federations,
with
the
things
that
we
we
had
before.
That's
that's.
My
only
concern
I'm
not
saying
that
Z
tunnel
a
whole
lot.
Implementation
must
support
CDs
and
EDS
just
that
systems
that
is
using
cdscds
and
some
parts
must
be
supported.
Somehow.
B
H
D
B
B
Did
this
one
is
that
the
performance
is
in
our
measurements
over
10x
better
to
do
it
this
way
than
to
shove
it
into
you
know:
Square,
Peg
and
round
hole
of
the
XDS
apis
that
exists
today
and
the
other
is
complexity
right,
like
we
don't
handle
95
of
the
fields
in
cluster,
but
they
now
may
be
said,
and
we
need
to
figure
out
what
we
do
there.
It
has
this
deep
structure,
lots
of
allocations,
all
those
all
these
issues.
H
B
Yeah,
but
it's
also
like
like
why?
What
is
the
benefit?
It's
not
like?
We
can
just
go
plug
into
consoles
XDS
server
and
read
their
things,
because
we're
going
to
need
all
this
information,
that's
shoved
into
metadata.
Basically,
it's
an
East
geo-specific
config
that
we're
shoving
into
like
basically
a
map
of
string
string
because
it's
an
existing
API,
but
there's
no
value
in
that.
E
B
Don't
have
a
connection
of
a
connection
pool.
That's
the
whole
point
of
the
ambient
XDS
is
that
it's
higher
level
apis
that
are
declarative.
Nowhere
in
here
are
we
saying
that
they're
how
these
things
should
be
behaved
like
Envoy
is
effectively
imperative
right,
you're,
saying:
oh,
this
is
a
cluster.
It's
a
connection
pool.
We
don't
say
that
in
positional
API
we
say
here's
a
service
go.
H
B
E
B
B
B
Inlining
is
about
looking
at
how
the
API
scales
efficiently
in
real
world
use
cases,
rather
than
tying
it
to
implementation
details.
So,
yes,
like
Envoy,
does
clusters
that
then
point
to
endpoints,
but
that
has
implications
on
performance
right
now,
anytime.
We
want
to
end
update
an
endpoint.
We
have
to
resend
the
list
of
endpoints
if
we
have
a
workload,
that's
in
multiple
Services,
which
is
very
common
with
meaningful
works,
because.
H
B
H
D
And
the
Google
can't
do
that
as
well,
but
I
I
want
to
make
two
two
points
here:
one
about
routes
actually
sorry
for
going
back
to
make
it
less
controversial.
My
suggestion
was
to
use
the
TCP
route
defined
by
the
by
the
app
stream
API,
which
has
almost
all
the
elements
that
we
need,
which
one
is
that
so
one
defined
by
by
TCP
route
in
K2,
API,
okay,
so
that
will
make
it
very
less
completely
uncontroversial,
because
that's
pushed
up
an
API
defined
Upstream
by
kubernetes.
We
don't
invent
anything
new.
D
It
just
sends
the
same
Proto
that
is
used
by
by
kubernetes
and
probably
for
service
and
point
slice.
For
example,
if
we
have
a
representation
of
the
proto-use
pen
point
slice,
it
should
not
be
controversial,
but
just
in
the
XDS
as
a
distribution
mechanisms
for
photos
defined
by
kubernetes,
which
again
nobody
should
can
object
that
that
endpoint
slice
is,
is
a
standard
API
for
representing
endpoints.
D
D
We
learned
a
lot
of
lessons,
it's
very
reasonable,
to
have
some
simpler
apis
that
may
be
proclaude,
grpc
and
and
if
an
employee
May
adopt
at
some
point
like
you
you
what
Implement
is
a
workload
or
envoic,
maybe
at
some
points
they
should
also
adopt
10
point
slice
and
TCP
routers
as
a
high
level
concept
that
are
simpler,
I,
don't
think
we
necessarily
are
diverging
from
them.
We
were
just
trying
some
new
ways
to
do
things
more
efficiently
that
and
we
should
adopt
as
well.
H
D
Yeah,
no,
no
definitely
we
want
whatever
is
defined
here
should
also
to
approximately
grpc
will
have
to
and
probably
by
employee
as
well.
No.
H
B
Agree
I
agree:
yeah
I
have
no
problem
taking
what
we
feel
is
the
best
API
and
bringing
it
Beyond
z-tunnel,
but
I
do
have
a
problem
with
taking
a
subpar
API
for
our
use
case
and
bring
it
into
Z
tunnel
just
for
the
purpose
of
conforming
with
an
existing
API.
When
these
are
not
even
user-facing
apis
right
like
we
should
make
sure
that
we
are
most
efficient
and
simple
bug-free
Etc.
That
is
more
important
than
conforming
to
existing
apis
for
an
internal
API.
In
my
opinion.
B
H
D
Think
we're
on
an
agreement
here.
What
I
mean
journey
is
saying
that
we
want
to
improve
some
apis.
We
all
agree
that
all
those
apis
we
want
to
promote
them
and
and
to
be
adopted
by
you
know
to
the
grpc
and
other
folks.
So
there
is
no
disagreement
really
here,
I
mean
we
all
Johnny
is
not
saying
that
we
are
not
going
to
propose
this
to
to
and
boy
and
proximus.
D
D
Thank
you.
So
can
we
move
forward
with
the
small
changes
and
and
being
parallel,
pushes
it
to
push
it
to
also
to
to
the
others.
D
No,
no,
no
I'm,
I'm,
I'm
I'm,
saying
that
we
we
need
to
you
know
be
careful
with
with
how
we
we
integrated
existing
exists
servers.
If
we
have
a
way
to
to
integrate
you
to
translate
I'm
happy.
B
Yeah,
our
the
layer
of
how
do
we
get
the
East
2D
internal
representation,
which
has
many
sources
files,
kubernetes
XDS,
that's
orthogonal
from
then
how
eastgro
takes
that
internal
representation
and
send
it
to
Zito
in
my
opinion,
so
we
could
have
absolutely
any
config
Source
you
want,
but
that
we
end
up
implementing
and
that's
perfectly
fine.
But
then
there's
one
API
between
Zito
and
Easter
d.
B
All
right
we're
well
over
time
either
everyone
froze
our
eye
froze,
but
I
was
like.
This
is
probably
a
good
place
to
wrap
up.
E
D
I,
don't
think
that
objections
and
then
what
and-
and
you
know
we
need
to
take
it
off
with
to
up
to
up
to
this
car,
to
start
discussion
with
with
the
other
one
to
complete
the
I.
Don't
think
there
is
disagreement
about
trying
to
Upstream
them
yeah.