►
From YouTube: Istio networking WG meeting - 2018-12-06
Description
-Modeling the sidecar via Gateway
A
C
D
E
Yeah,
it's
two
things.
One
really
I
just
want
to
acknowledge
a
couple
things
up
front.
One
I
wasn't
actually
planning
on
presenting
this
document
today,
because
I
hadn't
had
any
time
to
put
into
it
over
the
last
day
and
a
half,
because
I've
had
some
other
meetings.
I
had
to
go
to,
and
so
this
this
this
document
is
not
written
in
kind
of
a
user-facing
document
like
way.
There's
a
lot
of
it's
very
dense.
E
It
was
designed
to
cover
just
the
hard
details
and
facilitate
a
kind
of
design
review
among
people
who
were
intimately
familiar
with
the
details,
and
then
the
second
thing
is
why
this
proposal,
instead
of
the
previous
one
around
Network,
scoping
and
hopefully
I,
can
address
that
pretty
quickly.
And
then
we
can
drill
into
discussion
about
the
document
itself
and
the
design
choices
and
why
some
things
are
done.
The
way
they're
done.
So
if
that
works
for
everybody
and
I.
E
So
one
of
the
things
that
this
this
document
is
very
feature
dense.
It
covers
some
use
cases
that
really
don't
have
anything
specifically
to
do
with
cyber's
per
se,
but
have
to
do
with
limitations
of
Gateway
itself
for
the
kind
of
more
typical
use
cases,
people
are
used
to
thinking
about
gateway
in
their
context.
E
So
those
caveats
made
why
this
proposal,
instead
of
Network
scoping
well
there
are.
There,
are
two
things
so
one
the
whatever
we
do
did
in
network
scoping.
We
were
always
going
to
be
in
this
situation
where
we
have
to
declare
attachments
to
a
workload,
and
we
had
to
declare
basically
a
list
of
services
that
can't
be
available
to
that
workload
to
which
this
thing
was
attached
and
those
two
facilities
are
facilities.
E
That
already
exists
today
in
gateway,
logically
right
gateway,
already
declares
of
binding
to
a
set
of
services
and
gateway,
declares
a
way
to
attach
itself
to
workloads.
Currently
the
way
it's
you
know
primarily
intended
to
attach
itself
to
just
standalone
envoy
instances
running
as
middle
proxies,
but
it
already
has
a
feature
to
do
just
generically
describe
how
it
would
you
bind.
D
And
one
point
here
is
that
the
current
specification
is
a
bit
confusing
and
broken
in
the
sense
that
the
Select
Orion
is
a
gateway.
Typically,
you
know
it's
kind
of
not
selecting
a
specific
main
space
and
it
is
very
kind
of
big.
You
select,
ingress
gateway
by
just
a
few
running.
Is
your
system
and
make
it
run
in
a
different
system,
so
it's
not
very
well
defined
today.
It
needs
to
be
fixed.
So
that's
if.
E
E
They
want
to
be
able
to
control
both
the
inbound
and
outbound
ports
for
a
workload
as
a
sidecar
right.
They
want
able
to
control
the
port
numbers.
They
want
to
control
the
protocols
that
are
attached
to
those
supports
and
they
want
to
be
able
to
attach
behaviors
to
those
ports
right.
So
poor
listener
extensions
right,
that's
covered.
You
know
the
Envoy
extension
stuff
that
we
do
today.
You
want
to
be
able
to
manage
those
attachments.
E
You
also
basically
declare
the
list
of
services
you
were
going
to
attach
and
you
would
have
to
model
traffic
running
in
both
directions.
It
would
look
an
awful
lot
like
Gateway,
so
it
didn't
seem
worthwhile,
in
my
view,
to
have
two
resources
that
had
fundamentally
the
same
structure.
Yes,
there
are
some
variants
and
use
cases,
but
we've
been
a
little
trigger-happy
today
in
creating
resources.
E
What
that
traffic
is
bound
to
in
terms
of
the
destinations
or
ingress,
in
particular
local
ports,
right
the
things
that
the
workload
would
actually
implement.
So
this
this
proposal
refines
the
game,
a
syntax
around
external
services
for
egress
to
give
the
definer
more
control
or
how
the
services
are
basically
converted
into
the
routing
table.
That
envoy
is
programmed
with
by
pilot,
and
that
means
it
has
to
cover
both
the
service,
entry
and
virtual
service
and
also
for
ingress
to
have
simple
inline
declarations
of
port
forwarding
right.
E
Not
everything
that
we
do
with
traffic
capture
is
going
to
be
classical.
You
know
socket
except
calls
in
the
kernel
right.
We
do
fancy
things
with
IP
tables.
Today
we
may
do
with
CNI.
We
might
do
fancy
things
with
Vee
or
IP
VLAN
or
other
traffic
capturing
mechanisms
right
that
we
don't
want
to
necessarily
have
to
be
able
to
declare
all
of
those.
We
want
a
kind
of
placeholder
for
the
environment
to
be
able
to
say,
look,
I'm,
gonna
capture,
inbound
or
outbound
traffic.
You,
the
owner
of
the
work.
E
E
Okay,
so
this
proposal
basically
covers
those
things
and
a
couple
of
other
things,
and
maybe
I'll
talk
about
the
generic
gateway
use
cases
after
we
cover
the
fundamental
parts
for
sidecar.
So
now
we've
we
add
a
type
field
to
Gateway,
which
indicates
basically
that
the
basic
structure
of
what
type
of
proxy
is,
and
we
have
three
fundamental
proxy
types.
In
the
system.
We
have
an
edge
gateway
which
receives
traffic
from
outside
the
mesh
and
forwards
it
to
something
inside
the
mesh.
E
E
E
D
E
You
know
we
there
might
be
an
argument
to
say
like
we
should
have
middle
and
we
should
have
a
egress
right
just
because
there
are
some
slight
variations
and
the
the
kind
of
default
configuration
we
might
do
for
a
gateway.
If
it's
only
responsibility
was
to
send
traffic
coming
from
inside
the
mesh
to
something
outside
of
the
mesh.
We
already
model
out
on
our
API
and.
D
D
D
E
C
E
C
D
F
F
E
G
D
E
F
F
I
D
J
E
User
documentation
at
all
right-
this
is
this-
is
for
this
private
audience
and
right.
It's
designed
to
go
through
this
stuff
in
density.
I
tried
very
carefully
specifically
Frank
with
bind
to
map
to
exist
that
can
exist
in
conceptual
understanding,
externally
of
what
people
understand
bind
to
mean
in
proxies.
E
Alright,
if
you
go
read
the
documentation
for
engine
X
or
H,
a
proxy
or
caddy,
or
any
these
other
servers
bind
typically
means
the
thing
I'm
going
to
attach
this
listener
to
right.
They
don't
already
consistent
use
the
same
terminology
right,
there's
variance
in
the
terminology,
but
that's
what
it
means.
Yeah.
F
I
think
I
there's
nothing
wrong
with
this
once
you
get
to
that
lower
level
of
understanding,
but
there's
just
no
mapping
to
a
highlight
like
I
I'm,
always
struggling
with
so
taking
something
that
is
complicated,
figuring
it
all
out
and
then
and
then
kind
of
figure
out.
You
know
how
would
I
explain
this
to
a
user,
I
didn't
say:
I
want
to
configure
my
system
to.
You
know,
control
the
size
of
the
you
know
the
config
getting
generated
and
I
in
my
slide
cars.
You
know
I.
What
do
you
tell
them?
F
Where
do
they
start
like,
and
then
you
get
into
this
whole?
Okay,
you
got
this
type
and
I.
Think
it's
a
three
by
three
matrix,
there's
nine
different
combinations.
There
I
think
some
are.
You
said
explicitly
right
at
the
end,
the
document
but
they're
invalid,
but
a
couple
of
them
anyway,
but
then
the
other
ones.
Okay.
What
do
these
mean
yeah?
F
What,
if
I
do
a
middle
with
a
you
know
if
I
say
the
things
tight
middle
and
it
binds
I
can't
remember
what
they
were
but
say
side
hi
anyway,
that
you
can
see
comedy
should
combine
with
selector
and
then
used
to
give
a
selector
and
say
what,
if
you
point
to
the
owners,
control
or
proxy,
and
you
say
you
know
the
type
of
sidecar
and
you
know
and
buying.
Is
this
what
all
this
means?
I
guess.
C
F
This
totally
straightforward
with
the
defaults,
like
you
said,
you
know,
if
you
don't
say
anything
and
say:
oh
yeah,
this
is
an
ingress,
it's
a
gateway
and
that's
my
standard
thing
and
the
bind
is
default.
The
right
thing
and
the
selector
even
means
something
pretty
sensible.
But
then,
when
you
start
thinking
about
especially
the
middle,
why
more
confused
when
you
get
into
the
middle
and
egress.
H
D
Depends
on
which
gate
is
it?
Now
we
have
different
types
of
gateways.
A
gateway,
type,
ingress
or
edge
would
be
configured
by
the
administrator
of
the
domain,
and
that
decides
how
the
domain
is
split
up
and
work,
which
namespaces
is
allowed.
The
Gateway
correspond
to
a
site
gonna
be
managed
by
the
person
whose
minions
application,
because
it's
my.
D
Six
videos
already
with
authentication
access,
sorry
for
the
security
see
of
these,
which
have
separate
series
a
mixer
see
of
this.
One
of
them
select
some
towards
and
all
of
them
have
slightly
different
way
to
match
staff
and
different
way
to
represent
stuff
I,
don't
think
it's
helping
people
to
have
20
CR
these,
instead
of
ones
here.
G
C
K
I
mean
my
point
being
that,
yes,
we
can't
we
D
be
extra
three
C
alleys
with
the
exact
same
semantics,
but
the
fact
that
is
a
different
name
basically
automatically
creates
a
separate
flow
which
leaves
less
room
for
confusion
and
interpretation,
because
it's
like,
if
El
Cid
call
sidecar,
then
you
know
that
you
cannot
screw
or
on
with
that
CRD
and
try
to
apply
it
to
a
gate
thing
you
can
documentation
wise.
It
becomes
much
more
easier
to
write.
K
That
may
say
this
is
a
CRE
applies
to
only
sidecars,
which
means,
if
you
try
to
point
to
some
gateway,
it
just
will
not
work.
They
would
know
immediately
that
you
don't
have
to
write
a
verbose
documentation
to
explain
the
fact
that
if
you
try
to
do
X,
if,
yes,
if
you,
if
a
then
this
happens,
if
B
them
something
happens,
if
C
then
something
happens,
that's
equal
to
saying
having
1/2
bar
API
and
then
sticking
like
500.
If
conditions
within
that.
K
D
The
benefit
of
bringing
in
reality
what
we
are
computing
there
computing
F
way
or
whatever
other
books.
You
are
going
to
have
it's
a
fact
that
it
can
be
used
to
purchase
stuff
for
a
side
cover.
Can
you
move
that
different
configuration
is
not
that
relevant
to
this?
To
do
to
deserve
a
completely
different
API
I
mean
you
can
have
a
sidecar
that
can
be
program
as
simple
as
you
can
accept
rocket
from
outside
on
a
sidecar.
There
is
no
restriction
in
a
sidecar
that
it
needs
to
accept
rally
to
ingress
right.
E
L
D
E
D
C
Extreme,
if
you
take
any
field,
and
then
you
say
instead
of
having
an
enum,
let's
have
five
different
see.
Are
these
that's,
like
that's
the
case
right,
so
I
proposed
with
the
furthest
discussion
for
offline,
because
we're
like
going
around
all
around
this
particular
topic
and
I
think
there
is
more
to
come.
I
want.
D
Be
hijacked
yes,
that's
a
program,
that's
one
thing,
and
second,
there
are
some
usability
problems
that
we
are
having
with
the
fact
that
the
selectors
that
you
put
in
the
Gateway
actually
applies
to
Ferrando
namespace,
which
also
is
related
to
the
hijacking
and
miss
configurations.
And
finally,
we
have.
The
problem
is
that
the
Gateway
can
be
put
in
any
namespace
and
it's
not
clear
how
they
interact
with
each
other.
So
those
three
things
will
probably
need
to
be
broken
by
the
API
change,
because
we
need
to
fix
the
security.
D
D
E
So,
just
to
be
clear,
so
people
understand
what
the
problem
is.
If
I
have
the
gateway,
the
Envoy
is
implementing
a
gateway
running
in
a
namespace
that
has
access
to
a
TLS
certificate
stored
in
a
secret
in
that
namespace
and
then
I
define
a
gateway
in
another
namespace.
That
Ben
is
loaded
by
the
envoys
in
the
other
namespace,
but
that
gave
a
configuration
refers
to
a
TLS
served
by
a
relative
path.
That's
the
a
lessor
gets
loaded,
which
means
that
my
definition
is
now
able
to
use
a
TLS
certificate
that
I
don't
control.
J
D
E
To
not
break
people
in
a
backward
incompatible
way,
we'll
have
to
put
an
option
for
flight
in
a
flag
to
say
that
we
will
continue
to
merge
gateways
across
namespaces
if
that
flag
is
enabled
from
the
default
on
upgrade
will
be
enabled,
but
we
would
strongly
recommend
people
to
switch
away
from
doing
that.
I
guess.
N
K
D
K
C
E
That
block
resins
gateways
have
multiple
server
blocks
right,
which
today
so
far,
I
mostly
just
been
I'm.
Gonna,
listen
on
this
port
or
I'm
gonna,
listen
on
this
port
and
then
they
have
hosts
that
they
serve
on
those
blocks
on
those
listeners.
So
this
just
gives
you
the
refinement
of
control
to
say
well,
I
want
to
be
able
to
have
this
listener,
be
binding,
maybe
on
a
specific
IP
right,
particularly
in
the
case
where
you
have
to
network
interfaces
right.
E
E
What's
shown
here,
though,
is
I
specifically
provide
kind
of
a
standard
set
of
binds
for
ingress
and
egress,
and
these
are
basically
placeholder
binds
to
say
the
environment
will
figure
out
what
the
actual
physical
bind
is,
and
we
need
that
because,
if
we're
going
to
have
some
people
use
iptables
at
runtime
and
some
people
use
D,
eath
or
something
else
right.
If
you
statically
declared
what
the
line
type
was,
then
every
time
the
environments
needed
to
use
a
different
binds,
the
API
wouldn't
work
right.
So
we
need
some
indirection
and
the
interaction
here.
D
E
E
C
K
D
D
D
K
K
But
that's
why
I
do
that
multiple
I
mean
if
you're
doing
a
shorthand
for
an
inline
service
in
a
week,
then
I
can
come
and
ask
you
a
logically
I
can
I
have
a
shorthand
for
a
virtual
service
say:
can
I
have
a
shorthand
for
a
destination
to
an
effective?
It
becomes
a
they
got.
You
know,
because
this
is
who's.
E
D
Me
give
you
a
quick
explanation:
one
workload
that
is
using
UDS.
How
would
I
create
a
service
entry,
because
the
service
entry
defines
that
Hayes's
host
name
is,
has
an
endpoint,
a
UDS
socket,
but
that
applies
for
the
entire
class,
but
so
basically
it's
different
in
ETS
and
it's
probably
everyone
well.
D
K
That's
why,
if
that
service
entry
in
that
particular
namespace
is
private
and
it's
not
gonna
be
visible
to
all
the
other
namespaces
okay
and
then
within
that
particular
namespace
alone.
If
that's
of
its
it's
only
a
matter
of
like
configured
service
entry
for
everybody
else,
I
didn't
you
can
actually
either
specify
a
dummy,
IP
or
something
about
saw
done
basically
and
that
it's
for
sure
my.
D
E
E
L
E
E
D
K
D
D
D
Is
also
service.
Entry
currently
is
for
egress
for
defining
interest,
and
it's
also
used
to
define
a
list
of
IP
of
real
IP
m
ports.
Overloading
it
will
give
the
semantics
which
is
III.
It
means
is
a
local
port
on
how
the
sidecar
is
connecting
to
to
the
workload
on
your
gonna,
say.
Machine
is
even
more
confusing
for
users,
because
we
already
have
two
semantics
that
are.
E
The
point
here
is,
we
can
add
this
later.
We
can
use
service
entry
and
we
can
see
what
the
usability
that
feels
like
right,
whether
that
is
good
for
users
or
not
or
whether
having
the
they
should
be
cutting
out
that
look
up
right,
because,
particularly
for
ingress
right,
you
know
you're
routing
traffic,
just
to
something
that
is
a
localhost.
D
K
No
I'm
not
going
to
sing
with
the
actual
thing
that
people
use
and
what
I'm
recycling
with
the
fact
that
adding
an
endpoint
here
is
actually
going
to
open
the
door
to
a
lot
of
other
troubles
in
future,
because
somebody
would
come
and
add,
like
hey.
I
would
like
to
have
a
DNS,
addressable
hostname
here
and
then
that'll
start
expanding
into
like
hey.
But
this
is
Adina's
admissible.
I
need
to
look
up
in
the
service.
K
E
E
E
E
K
C
D
D
K
E
K
D
E
E
D
With
me
and
I,
don't
see,
there
is
anything
wrong
with
with
with
with
having
I
mean
I
in
nginx.
You
have
one
something
farm
it
includes
effectively.
Is
your
config
it
you
can
think
of
it
as
one
big
config,
where
we
put
everything
together
and
some
stuff
can
be
in
different
blocks
like
like
the
inclusion
in
energy
days,
but
eventually
it's
one
consistent,
big
block,
so
I
don't
see
a
problem,
for
example,
putting
a
service
entry
record
in
in
the
latest
one.
D
C
E
So
having
covered
binds
the
next
and
probably
the
most
important
part
of
this
specification,
is
the
host
section
right,
just
as
it
does
today
in
is
in
Oh
while
host
does
is
it's
a
list
of
DNS
names
that
are
resolved
against
service
entries
or
virtual
services?
Now,
today,
in
sto,
they're
only
resolved
against
virtual
service
for
site
cards
that
the
dynamically
generated
psych
our
behavior,
is
resolved
against
both
virtual
service
and
service
entry.
E
So
what
we're
doing
here
is
we're
saying
that
we're
allowing
for
resolution
against
both
service
entry
and
virtual
service
right,
which
is
a
slight
change
for
Gateway,
but
not
a
breaking
one
and
we're
describing
the
priority
of
the
binding
of
the
attachment,
and
basically,
what
we
say
is
if
you
have
an
equivalent
hostname,
that
is
bound
that
is
declared
by
both
a
virtual
wrists
and
the
service
entry.
The
virtual
service
one
will
take
priority
if
the
match
between
the
hostname
and
the
virtual
service
is
a
wild
card
match
right,
it's
a
non
perfect
match.
E
E
So,
for
instance,
I
can
now
put
a
declaration
in
that
would
guarantee
that
some
paths
match
on
star
would
occur
before
any
host
specific
matching
or
other
things
like
that
or
I
could
put
it
afterwards
if
I
want,
whose
specific
matching
to
take
precedence
by
ordering
the
declaration
of
the
hosts
right.
So
one
of
the
problems
we've
always
had
with
SDO
is
the
ordering
of
routing
has
been,
in
some
cases
to
synthetic
for
people
to
control.
E
E
Oh,
the
other
thing
you'll
notice
is:
there
is
syntax
now
in
the
API
to
scope
the
reference
to
a
namespace
and
there's
some
debate
about
what
this
syntax
should
active.
But
this
base
syntax
is
saying:
I
want
the
definition
of
example
to
calm
from
namespace
one
and
not
from
all
namespaces
or
yeah
an
arbitrary
random
one
chosen
for
under
by.
We
have
to
do
with
these.
L
E
Using
slash
is
the
separator
here
right
so
basically
the
example
above
an
action
in
the
spit
on
to
the
bottom.
We
describe
the
syntax,
so
the
syntax
for
entry
is
now
this
right,
there's
an
optional
namespace
name
that
has
a
separator
from
the
host
name.
If
the
name
space
is
alighted,
it's
the
equivalent
of
saying
all
namespaces
right,
which
is
the
current
behavior
and.
F
E
So
the
yes
I
didn't
mean
to
follow
up
on
that
comment.
Prank
on
your
right.
Ok,
so
there's
just
looking
right!
So
there's
there's
a
debate
about
whether
the
default
namespace
reference
should
be
the
same
namespace
as
the
definition
or
star.
Yes,
that's
a
worthwhile
debate
to
have
the
current
behavior
is
obviously
star.
So
that's
probably
what
we
have
to
ship
may.
F
D
F
E
This
but
they're,
probably
in
conflict
on
a
given
domain,
is
low.
What
you're
more
like
there
are
people
who
will
have
conflicts,
and
so
they'll
have
to
pay
the
tax
so
using
the
explicit
namespace
name
but
they're.
The
the
current
reference
versus
reference.
All
is
probably
not
that
important
a
distinction
to
make,
and
so
it's
probably
fine
to
the
default
to
be
star
that
make
sense.
I.
D
And
and
I
want
to
make
here,
is
this
particular
syntax
and
way
to
specify
dependency
supplies,
both
side,
cars
and
the
edge
routers
physically,
meaning
that
this
is
a
uniform
way
to
specify
this
war
clothes.
His
main
space
or
the
ingress
is,
is
spoking
with
specific
destination,
specific
names,
missin
destinations.
E
Right
that
that
is
a
very
important
part
of
this
these
days,
which
is
the
same
as
it
was
in
the
network
scooping
proposal.
Yes
right,
I
is
the
owner
of
a
a
big
edge
gateway.
Don't
want
any
namespace
to
be
able
to
define
example.com
right,
I
want
to
be
able
to
control
which
namespaces
are
allowed
to
define
example.com.
F
I
D
K
E
K
C
N
C
C
M
K
Why
is
my
application?
I
can
define
and
you
mix
the
main
socket
here.
A
natural
end
point
apply
from
the
Eva's
path.
Where
you
specify
hey
here,
is
a
instead
of
equal
service
and
I'm.
Actually
gonna
expose
I
can
either
buy
into
an
IP
or
I
can
bind
to
unique
so
main
socket
depending
on
how
the
application
wants
and
then
the
same
set
of
syntax
that
he
actually
have.
So.
This
will
no
longer
have
me
in
the
Gateway,
but
like
same
namespace,
tour,
star
and
service
door,
namespace
and
blah
blah
and
all
other
stuff.
The.
D
K
E
K
Like
you
know
the
clear
expression,
and
so
this
basically
means
the
Gateway
expect
that
you
actually
currently
have
well
boil
down
to
like
you
will
no
longer
have
Minds,
you
will
no
longer
have
those
endpoints
and
what
you
have
is
like.
Yes,
the
selector
will
actually
apply
only
to
the
local
namespace
and
not
anywhere
else
so.
K
K
But
that's
what
I'm
saying
you
normal
have
to
have
a
bind,
because
then
you
specify
an
ingress
server
and
you
can,
if
you
omit
the
bind
it'll
automatically
bind
to
all
the
ports
in
the
English
part,
and
if
you
omit
the
I
need
to
specify
an
IP,
then
only
bind
to
that
IP
plus
subset
of
floral.
Like
you
know,
ports
and
the
same
thing
can
be
applied
on
the
egress
path
as
well.
K
K
D
K
Yes,
we
have
the
irregular
middle
of
introduces
a
middle
or
edge
thing,
because
we
were
actually
doing
the
buying
business
and
once
that
this
whole
part
is
gone.
The
Gateway
no
longer
have
to
has
to
differentiate
itself
to
a
SAN
eggs
or
irregular,
because
it's
like
it
is
a
gateway,
and
today
we
are
using
it
the
exact
same
way
and
people
can
just
drop
in
a
gateway
and
like
do
whatever
the
stuff
that
they
want
to
do.
E
K
E
K
E
D
E
D
D
K
E
Leaving
that
the
mind
versus
being
a
type
filled
in
gateway
versus
an
implicit
declared
field
in
Sri,
MCRD,
they're,
logically
exactly
the
same
thing.
You'd
give
it.
But
do
we
accept
the
fact
that
we
still
have
to
deal
with
the
workload
binding
right,
the
selector
side,
then
yeah
and
the
ordering
of
hosts
and
the
scoping
of
the
reference
services
to
namespaces
equivalently
in
both
Gateway
and
site
or
kneeler
before
yeah.
F
F
E
F
A
difference
the
Sri
Rams,
making
I
thought
I
thought.
Maybe
this
is
it
we're
just
wrong
or
I'm
wrong
anyway,
in
thinking
that
a
lot
of
this
stuff
does
not
apply
to
ingress
and
egress
gateways
in
the
old
terminology?
This
is
all
very
you
know
very
specific.
You
know
sidecar
kinds
of
advanced
configuration
of
no,
no
at
all,
so
yeah.
E
Ingress
clearly
applies
to
edge
gateway,
right
yeah,
but
it
finds
the
ingress
definitely
applies
to
educate
ways
for
traffic
receiving
coming
in
from
outside
of
the
mesh
where
they
don't
know
in
advance
how
the
environment
is
provisioning,
the
IP
or
the
traffic
mechanism
to
receive
that
traffic.
So
that
needs
to
be
synthetic
for
edging
grass
you're
saying
IP
is
needed
there.
No.
K
In
mind
that
when
you
have
specified
a
gateway,
you
can
also
say
the
host
as
a
start
just
playing
start
today
and
this
syntax
it
or
if
what
it
implies.
This
is
what
the
discussion
we
were
having
already
in
place,
everything
is
a
service
registry
would
end
up
being
exposed
if
you
actually
like
automatically
provide
the
gateway
of
the
ability
that,
like
you,
can
specify
a
hostname
or
service
registry,
and
it
will
just
get
exposed
in
the
Gateway.
The
downside.
K
E
K
E
C
C
E
It
does
sound,
just
sweet,
we
understand
what
we've
agreed
upon
right
rather,
but
whether
we
have
one
type
or
three
and
how
that
type
is
expressed
either
strd
or
a
type
field.
The
need
for
control
of
reports,
the
need
to
scope,
two
namespaces
and
are
generally
agreed
upon,
and
the
need
to
have
a
synthetic,
binding
mechanism
right.
That's
environmentally
sensitive.
E
E
F
I
agree,
I.
Think.
The
question
in
my
mind,
though,
is
what's
the
80/20
use
case
like
I.
Think
one
of
the
use
cases
is
the
fundamentally
most
important
one
here
and
if
that's
the
hard
one
or
if
that's
kind
of
brought
down
because
of
the
ten
ten
or
twenty
percent
use
case
to
the
point
that
that
becomes
really
hard.
This
is
what
I'm
so.
E
D
M
K
M
K
K
E
D
D
E
N
F
M
Can
we
focus
on
user
scenario,
because
this
looks
like
an
awfully
awfully
complicated
and
we
already
heard
a
feedback
from
user.
The
Gateway
API,
the
existing
API
is
super
complicated.
Already
so
I
like
for
Frank,
said
early
on
focus
on
the
80%.
Can
we
come
up
with
simple
solutions
for
the
short
term
first
and
collect
feedback
under
you
Bob
from
there
absolutely.
E
D
N
K
K
J
E
C
E
D
E
So
the
other
thing
that
should
be-
and
we
didn't
really
get
to
it-
is
to
declare
a
virtuals
to
have
a
virtual
service,
be
used
by
they
say
be.
The
shared
ingress
gateway,
which
is
the
gateway
itself,
is
owned
by
an
admin.
You
don't
have
to
create
a
gateway
resource
in
your
namespace.
To
do
that
anymore
and.
E
You
don't
have
either
of
those
things,
so
it's
actually
like
what
we
would
see
is
a
net
reduction
in
config.
Actually,
but
a
clear
separation
of
roles
and
responsibilities,
right
I
would
just
create
the
virtual
service
for
the
portion
of
example.com
that
I
owned
and
the
gates
be.
The
gateway
owner
would
typically
just
refer
to
it.
Using
the
host
specification,
say
Louie's
name
space
with
example.com,
and
they
would
get
that
behavior.
M
E
A
D
C
E
A
E
Why
I
said
edge
doesn't
by
default,
because
that
would
be
a
behavioral
change
right
from
as
an
operate
it
would
be.
You
would
start
binding
the
service
entries
where
you
weren't
previously,
but
slight
car.
If
you
read
the
description
right,
it
very
clear,
I
made
it
pretty
clear
here
all
right,
that's
what
I'm
talking
about.
C
D
You
don't
have
to
do
that,
so
ugly
role
doesn't
need
to
know
the
name
of
the
ingress
know
nobody
to
put
bind
section
in
catarse,
because
you
just
put
the
trust
service.
The
owner
of
the
gateway
will
specify
here.
I
want.
You
say
this
example
at
home
from
name
space
yeah,
because
they
don't
care
about
it
right.
E
D
F
D
The
u.s.
gateway
they
use
of
an
egress
gateway
is
not
something
that
the
user
will
contribute.
I
mean
it's
again,
not
a
user
control,
it's
not
mean
configure
each
direction,
so
the
admin
can
specify
all
the
traffic
going
out
must
go
to
an
egress
gateway,
put
traffic
policy
put
whatever
to
restrict
it,
and
it
will
be
a
mesh
configuration
or
not
mean
configuration.
You
don't
want
to
give
user
control
over
this
handsome
bother
it
right.
E
So
that
the
if
we
were
aggressing
through
the
sidecar
Frank,
then
service
a
you
know,
imagine
there's
a
host
name
here
that
had
a
service
entry
where
it
was
type
mesh,
external
or
and
then
we
go
straight
out
to
the
side
car.
If
we
were
configuring,
a
middle
proxy
as
an
egress
gateway,
it
would
love
that
service
entry
and
then
there
would
be
a
service
entry
in
another
namespace
that
was
and
this
we
could
pull
from
the
other
thing
where
we
had
public
and
private
service.
C
A
C
D
E
Yes,
they're
even
more
complicated
use
cases
than
these
right,
which
we
have
run
into
specifically.
We've
specifically
heard
about
this
one,
all
right,
not
using
IP
tables
for
capture
right,
but
I,
still
want
to
right.
I'm
going
to
get
the
proxy
port
or
not
even
using
proxy
protocol
I'm
just
going
to
use,
is
fixed
port
for
a
egress
and
act
as
a
reverse
proxy.
Writing.
The
application
has
to
be
fully
aware
that
it's
doing
it
right
we've
run
into
both
of
those.
E
M
M
K
If
you
look
at
I
added
this
demo
that
specification
in
the
bottom
of
this
file,
I
mean,
if
you
look
at
that,
it's
I
mean
it's
like
you
don't
have
to
the
only
the
problem
here
is
already
felts.
There's
a
whole
bunch
of
it.
Felts
and
switch
key
is
configuration
that
just
makes
no
head
hurt.
That
has,
if
you
go
to
sidecar
when
it's
there
is
not
much
there's.
D
E
D
C
E
C
D
E
Because
we
need
to
make
progress
because
we
can't
afford
to
keep
going
otherwise
that
we
won't
ever
ship
this
one,
one
that
one
is
Sri
Ram
and
I
can
hash
this
out
right
and
we'll
have
a
frank
like
well:
Frank
I'll,
try
and
fix
namitha
two
issues
so
we'll
basically,
Sri,
Ram
and
I
are
going
to
do
Dueling
Banjos
and
see
if
we
can
East
he
and
I
can
come
to
consensus.
Then
that
might
be
a
good
signal
about
everybody
else.