►
From YouTube: Ambient Mesh WG meeting 2023 09 06
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).
A
Okay,
all
right
good
morning,
everyone
welcome
to
the
September
6th
Wednesday
is
still
ambient
weekly
contributors
meeting
and
first
on
the
agenda,
we
have
keys
asking
about
where
we
are
with
hurricane.
B
I
think
where
we
talked
about
whether
or
not
we
want
to
Hairpin
do
we
want
to
customize
redirection
in
an
event,
and
the
has
been
summarized
in
this
issue
on
GitHub
the
takeaways
is
that
from
that
meeting,
is
that
you're
not
going
to
customize
reduction
in
capture
for
beta,
maybe
even
ever,
because
the
trade-offs
aren't
something
that
we're
okay
with
and
that
we
need
Global
airport
over
ntls
in
the
ambience
when
it
comes
to
Pure
authentication
policies
to
govern
the
capture?
B
So
with
that
in
mind,
I
wanted
to
Circle
back
around
to
see
where
we
are
happening
in
general.
You
know
do
not
remember
that
whole
discussion
was
kind
of
triggered
by
Stevens
dot
around
digital
hairpinning
and
how
you
want
to
handle
the
situation
when
uncaptor
traffic
is
is
destined
towards
a
to
a
capture
pod.
B
The
scene
from
my
recollection
feels
like
the
prevalent
approach
that
there's
the
most
consensus
on
was
to
do
plain,
not
neutral
TLS
for
those
uncaptured
and
captured
Source
workloads,
but
I
wanted
to
ask
can
ask
everybody
to
see
if
you
want
to
reassess
that
Stephen
had
multiple
options
in
his
doc
so
might
be
trying
to
go
back
to
the
to
the
drawing
board
and
kind
of
find
some
consensus
there
in
order
to
move
forward
with
implementation,
I
already
saw
one
one
down
votes,
which
I
believe
is
John,
so
it's
a
group
have
some
stuff
to
discuss.
C
Yeah
I,
don't
I,
didn't
agree
with
using
plain
text.
Part
I
didn't
realize.
Other
people
thought
that
either
necessarily
so
of
course,
I'm.
Not
the
only
one
person.
That's
oh
sorry,
wait
when
you
say
playing
TLS,
never
mind.
Sorry,
I
thought
single
leg,
Yeah
single
leg
dealers,
my
bad
I
changed
my
mind
thumbs
up.
D
That's
yeah,
that's
the
only
option
we
have
I
guess
is
the
single
leg,
implementation,
air,
pin
I,
think
costin
had
still
I.
Think
Austin
wanted
to
assess
the
security
impacts
of
that
and
I
think
he's
right
too,
because
that
would
still
requires
to
add
basically
a
one-off
custom
flow
degraded
off
in
just
for
this
case,
but
I
think
we
have
to
so.
We
we
have
to
just
kind
of
take.
Take
that
up.
I,
think
that
hit
I
think
so
yeah.
B
Yeah,
so
just
for
completeness
sake,
there
are
a
couple
of
other
options
in
the
dock
that
are
actually
various
pros
and
cons.
Whether
it
was
specials
internal
identity
deny
always
plain
text
to
pass
through.
I
think
plain
takes
past
you
with
the
the
other
big
one
that
had
some
I
had
some
support
for
it.
B
B
B
Right
there
yeah
so
essentially,
what's
the
the
flow
is
that
the
source
pod
sends
a
a
connection
of
some
sorts
or
request
to
the
perhaps
or
destination
pod,
and
that
cat
destination
pod
also
has
a
waypoint
the
Z
tunnel
in
order
to
enforce
policy
and
and
such
is
going
to
to
Hairpin
that
request
to
the
to
the
Waypoint
waypoints,
going
to
apply
policy
Etc
and
then
send
traffic
lab
back
to
the
back
down
to
the
lead
tunnels
and
the
the
question
that
the
underlying
question
here
about
Hand
hair
pitting
is
what
I've
been
to
t-shirt
the
z-tunnel
use
to
forge
that
to
the
Waypoint.
B
Typically
in
the
HBO
use
case,
it's
a
delegated
identity
flow,
where
the
Z
tunnel
uses
the
identity
of
the
workload,
the
capture
Source,
to
send
to
the
Waypoint,
and
usually
it's
not
a
hairpin
situation.
It's
the
source
view
tunnel
sitting
to
the
destination
Waypoint
on
the
in
the
hair,
putting
scenario
there
is
no
Source
identity,
and
so
the
underlying
question
is:
do
we
have
a
you
know?
B
We
have
other
different
options
for
how
to
handle
they're,
not
being
an
identity
that
we
can
verify
from
the
SEO
side
and
we
said
a
special
unauthenticated
identity.
Do
we
just
deny
all
plain
texts
to
istio
again,
it
could
be
encrypted
by
some
other
names,
but
all
you
know
in
the
issue
context:
do
we
just
deny
all
playing
sex
traffic?
Do
we
allow
plaintext
separate
to
the
waypoints
up
into
this
case?
Be
up
until
now?
At
this
point,
we
have
not
allowed
anything
plain
text
to
go
to
the
Waypoint.
B
We
just
everything
had
to
be
H
phone,
and
so
those
are
the
kind
of
the
approaches
to
this
underlying
problem
of
how
do
we
handle
un
captured
traffic?
We
cannot
access
an
identity.
Does
that
make
sense.
B
Cool,
oh
one,
other
thing
to
add:
with
the
proposed
qls
approach
for
more
security
punches
users,
they
will
always
have
the
opportunity
to
add
a
pre-authentication
and
set
strips
mtls
policy
if
they
want
to
deny
all
plain
text
traffic
and
that
and
even
with
hair
petting
I
think
we
discuss
that
as
a
short
path
that
can
apply
at
the
zoo
tunnel
to
where
plate
text
traffic
under
a
strict
peer
authentication
policy
won't
even
go
to
the
Waypoint
it'll
be
just
the
the
tracker
could
be
dropped
at
the
Z
tunnel.
Yeah.
B
Okay,
so
yeah,
so
if
we
have
agreements
here,
what
I
will
do
is
I'll
create
a
issue
kind
of
summarizing
the
implementation
and
working
on
implementing
it.
Thanks
folks,.
A
B
F
B
So
I
should
have
added
the
link
here.
It's
in
the
spin
review
section,
but
I'll
copy
it
down
for
completeness,
but
I
wanted
to
remind
folks,
especially
Toc
members,
that
we
there's
a
second
doc
that
needs
reviewing
so
the
the
target
rep
PR
for
the
API
changes
at
Target,
rep
to
istio
policy
when
you're
talking
to
Waypoint
or
other
or
Gateway
API,
Gateway,
that's
merged,
but
for
authorization
policy.
B
The
full
kind
of
vision
of
what
we
want
for
for
ambient
and
even
authorization
policy.
Yeah
won't
ambient
specifically
there's
another
step.
That's
unit
for
off
D
policy,
which
is
to
add
a
layer
field
to
indicate
what
layer
the
policy
is
is
targeting.
B
The
doc
is
more
information
along
with
some
examples,
and
so
just
a
reminder
to
folks
to
take
a
look
at
that,
especially
TSU
member
who's.
Looking
for
a
couple
more
approvals,
I
think
John's
approved,
but
we'll
need
a
couple
more
before.
We
feel
comfortable
moving
forward
with
eight
cat
changes
and
any
sort
of
implementation.
So
just
a
reminder.
B
I
I
think
that,
as
far
as
the
drop
ambient
to
Beta
doc
timeline
goes,
the
I
think
this
is
pretty
important
changes
just
because
the
the
API
changes
are
going
to
you
know
impact
a
lot
of
the
other
function
increases
functionality
that
we
might
need
to
do
for
Ambience,
so
I
love
to
try
to
get
this
get
the
underlying
API
PR
out
soon,
maybe
merge
by
end
of
September
would
be
I
feel
like
a
reasonable
goal,
based
on
kind
of
based
on
existing
timelines
from
that
need
for
things
that
need
to
see
approval.
B
A
So
one
will
you
sign
off
by
next
week.
Is
that
I
guess
ASAP
can
mean
a
lot
of
things.
G
Kids,
to
confirm
the
plan
is
that
the
API
will
be
merged
and
the
implementation
will
I
mean
when
we
are
not
hide
it
or
whatever.
It
will
be
ambient
only
and
for
waypoints
and
weapons
or
L7
and
Z
tunnel
for
L4,
with
everything
else
not
supported.
B
Yes,
I
think
that
makes
the
most
sense.
The
only
the
only
place
where
we're
splitting
up
layers
when
it
comes
to
any
practical
topology
is
ambient.
At
this
point,
so
yeah
any
anything
targeting
the
side
part
would
not
be
I,
don't
think
would
be
valid.
G
Or
gateways
so
so
both
of
them
will
be
out
I.
Think
it's
fine,
that's
that's
the
and
are
you
pursuing
any
similar
authorities?
I
mean,
or
we
have
many
discussions
in
the
Gateway
group
about
adding
some
form
of
authorization
policies.
Yes,
you
are
you
or
someone
else
pursuing
that
or
for
Gateway.
B
I'm
supposed
to
be
I
I
took
a
action
out
of
a
couple
weeks
back
in
the
Gateway
API
meeting
to
use
an
investigation
and
have
been
there
with
other
things,
but
it
is
in
the
scope
of
gamma
for
sure.
If
you
try
to
do
this
and
I
to
be
honest,
I
think
it
would
be
really
interesting
to
have
this
layered
targeted
approach
in
istio
for
and
and
see
how
that
works
and
potentially
integrate
that
in
whatever
we
do.
Upstreaming
gamble,
because
I
think
separation
would
be
really
interesting.
B
Interesting:
okay,
as
far
as
the
the
proper,
the
API
proper
and
the
Ingress
use
case,
I
don't
know
if
anybody's
looking
into
operation
policy
for
that
yeah
I,
don't
know.
There's
anybody
pursuing
that
at
the
moment,
yeah,
because.
G
I'm
sure
every
gate
implementation
has
its
own
authorizations.
There
is
no
questions
that
everyone
complement
the
gate,
we'll
have
someone,
please
not
see.
Okay,
good.
Do
you
just
just
wanted
to
see
where
we
stand
with
the
different
direction?
G
A
If
there's
nothing
else
on
that,
one
next
up
is
Kevin.
Where
are
we
with
SE.
H
Scope:
oh:
what's
the
service
entry
I
meant
to
service
entry,
so
at
link
there's
a
design
doc
that
we
spoke
about
a
couple
weeks
back
kind
of
arguing
that
the
current
behavior
for
scope
of
service
entries
is
wrong
and
there's
a
couple.
It's
been
discussed
before
I
I
learned
so
there's
some
contacts
from
2019.
This
was
discussed
then,
and
there's
other
GitHub
issues.
I
dug
up.
H
My
position
hasn't
really
changed,
which
is
that,
after
looking
at
the
additional
contexts
provided
that
that
we
should
change
the
default
scoping
of
service
entries
and
ambient
and
I
wanted
to
get
more
eyes
on
this.
My
the
last
action
item
was
to
look
over
the
context
from
2019
and
go
through
the
old
GitHub
issues
and
Link.
You
know
link
to
link
to
the
other
stakeholders
and
yeah
I
think
we
should
still
namespace
scope.
Them
is
the
short
answer
and
I'd
love
to
to
take
this
work
on.
If
we
can
get
agreement.
C
Yeah
I've
I've
read
this
a
few
times,
and
one
thing
I
struggled
with
is
understanding
we're
doing
this
like
what
problem
are
we
solving
that
people
have?
Who,
who
are
we
solving
it
for?
What's
the
requirements
like
I'm
missing
a
lot
of
context,
I
think.
H
Oh
okay,
I
thought
I
heard
a
voice,
no,
so
for
for
me,
the
requirements
are
that
namespace
boundaries
are
respected
and
that
we're
multi-tenant
safe
in
service
entries
today
are
not,
and
so
that,
for
me,
is
the
requirement
who
we're
solving
for
I
linked
a
couple
GitHub
issues
of
other
people
who
have
run
into
bugs
related
to
this
Behavior
today.
This
is
how
service
entries
work
today
in
classic
istio
and
I've
linked
a
couple.
H
H
I
would
like
to
fix
it
for
both,
but
I
understand
the
feasibility
of
doing
it,
for
classic
is
very
difficult
and
frankly,
the
timelines
aren't
the
same.
I
mean
that
ship
has
already
sailed,
so
I
think
the
time
frame
like
in
my
mind,
doing
this
for
ambient
needs
to
happen
before
ambient.
So
that's
the
urgency
to
think
about
now.
G
That's
that's
excellent.
One
thing
I
mean
we
had
some
discussions
in
terminal,
30
percent.
Quite
quite
a
bit
you
you
know
semicently,
it's
used
for
you
know
we
have
the
duplicated
part,
which
is
a
duplication
of
workload,
entry
for
which
maybe
wait.
Wait,
wait,
wait,
wait
could
at
some
point
you
know
not
have
two
ways
to
do
it
in
ambient.
G
Then
there
is
a
use
for
egress
gateways
which
I
think
people
knows
that
ambient
has
a
solution
for
the
class
gateway
to
this
right
now
and
then
there
is,
you
know
the
the
setting
HTTP
layer.
You
know
properties
for
for
Route
One
for
egress,
which
again
I
don't
think
it's
supported
is
it
did.
We
add
support
for
it
in
in
ambient
I
saw
that
Zeta
is
only
doing
L4,
so
I'm
trying
to
see
how
it
fits.
H
G
But
what
what
do
we
support?
I
mean
you
mean
the
the
user
service
Centric
to
add
IPM
and
DMX
mesh
expansion,
or
which
should
be
using
actually
workload
entry
or
you
need
to
just
create
some
DNS
in
because
we
support
maybe
some
fields
and
some
very,
very
narrow
use
cases.
But
we
definitely
don't
support
the
entire
thing
and
redirecting
to
the
address
Gateway
or
you
know,
applying
everything
on
anything.
H
C
Yeah
I
was
I,
don't
know
if
I'm
necessarily
agreeing
but
like
if
our
goal
is
to
make
it
so
that
Easter
is
multi-tenant
and
has
strong
name
space
boundaries.
This
is
nowhere
near
enough,
like
I
can
easily
just
go,
make
a
virtual
service
for
google.com
and
any
namespace
and
they'll
be
used
by
everyone
right.
C
So
I
feel
like
we're
not
really
meeting
the
goal.
If
that's
the
goal,
which
is
not
clear
because
there's
no
goals
really
stated
and
like
the
issues
aren't
actually
I
mean
I
looked
through
the
linked
issues.
Most
of
them
don't
seem
to
actually
be
fixed
by
this
either.
So
it's
it's
very
hard
to
understand
what
we're
actually
trying
to
do.
I
mean
it's
clear:
what
we're
trying
to
do?
It's
not
clear!
Why
we're
trying
to
do
it
and
if
it
meets
the
requirements
of
what
we're
trying
to
do.
H
Okay,
if
the
pushback
is
that
we
need
more
succinct
goals,
I'm
happy
to
update
the
doc
with
with
more
goals.
My
goal
is
namespace
boundaries
right.
So
if
virtual
service
is
also
it's
Global,
I
have
a
similar
concern
for
that,
and
so
I
would
like
to
include
that
in
this
dock.
It's
the
same
motivation.
C
Yeah,
it's
not
clear
what
a
namespace
boundary
means
either
like
someone
creating
a
you
know,
I
mean
if
you
import
anything
from
the
other
namespace,
then
they
have
the
ability
to
mess.
With
your
your
workload
to
some
extent,
I
could
create
10
000
Services
as
one
example
and
dos
the
Sidecar.
So
it's
like.
Is
there
a
real
like?
Is
there
a
specific
isolation
goal
that
we're
trying
to
achieve?
Because
if
we
just
say
multi-tenancy,
it's
kind
of
it's
become
meaningless
because
everyone
kind
of
has
different
ideas
of
what
tenant
isolations
actually
mean.
I
So
one
way
to
look
at
it
could
be
that
in
general,
service
or
anything
that
is
analogous
to
a
service
has
been
namespace
scoped,
both
in
kubernetes
apis,
as
well
as
I.
Think
routes
in
Gateway
apis
are
also
scoped
by
namespace,
so
service
entry
and
virtual
surface
are,
you
know
essentially
analogous
to
external
services
and
routes,
and
it
would
make
sense
to
have
them
be
namespace
scope
to
to
prevent
clashing,
especially
when
you're
within
an
Enterprise
where
multiple
tenants
might
choose.
I
You
know
mail.xyz.com
as
an
external
URL,
and
they
might
step
on
each
other.
So
it
does
appear
to
me
and
again
I'm
relatively
new
to
the
community,
so
maybe
I'm
missing
something,
but
it
would
appear
that
these
are
all
analogous
to
variations
of
services
and
should
be
namespace
scope.
Just
like
regular
kubernetes
services
or
namespace
scope
and
routes
are
namespace
scope.
I
But
the
part
that
is
common
is
that
it
is
always
a
variation
of
namespace
based
isolation.
So
I
think
we
can
reasonably
assume
that
if
everybody
does
a
multi-tenant
solution,
you
know
they
will
include
an
element
of
Separation
by
namespace.
Two
tenants
will
never
share
the
same
name
series,
for
example,
so
sure.
C
I
totally
get
that
namespace
isolation
is
important.
I,
just
don't
think
that
this
actually
gets
us
meaningfully
more
in
that
direction
like
we
already
have
boundaries
that
can
be
enforced.
For
example,
we
have
imports
and
exports
so
why,
when
we
can
already
put
imports
and
exports
both
at
Global
and
per
pod
or
per
service
levels,
I
mean
that
for
both
of
us,
both
imports
and
exports,
so
we
have
like
four
different
levels
of
controls.
I
Now,
what
if
a
malicious
user
Imports
from
another
and
and
Glovers
that
that
that
destination.
C
C
I
Here's
the
thing,
though,
you're
right
that
maybe
firstly
not
too
many
people
use
multi-tenant.
You
know
service
measure
I
can
leave
with
ambient.
Obviously
so
it
won't
be
that
much
demand,
so
so
at
least
but
the
longer
you
go
without
changing
it,
the
longer
the
harder
it
gets
to
change
eventually
and
if
we
think
architecturally
it's
the
right
thing
to
do,
then
sooner
is
better
than
later.
I
F
I
G
That's
maybe
that's
the
answer.
I
mean,
for
example,
if
you're
short
service
you
mentioned
virtual
service
is
a
similar
problem.
Well,
for
virtual
service,
we
have
a
solution
which
is
HTTP
route
which,
which
it's
clearly
defined
as
a
very
clear
semantics
about
NASA's
boundary.
It's
not
really
about
monkey
10
I'm
thinking
in
general,
probably
should
stop
mixing
multi
tenant,
it's
just
normal
behavior
in
kubernetes
that
everyone
should
follow
and
for
service
centers.
I
But
wouldn't
it
be
further
confusing
where
HTTP
route
is
namespace
scoped
and
virtual
services,
not
namespace
code?
Are
they
essentially
not
the
same
thing.
B
I
G
Okay,
my
point
was
that
we
fixed
virtual
service
by
creating
HTTP
route.
I
mean
you
cannot
it's
very
tricky
for
users
to
have
one
crd
called
something
that
behaves
in
five
different
ways,
and-
and
does
you
know,
depending
on
context,
if
you're
using
it
ambient
it's
one
way
to
use
it
in
sidecast
a
different
way?
Nobody
can
keep
track
of
this,
so
maybe
take
was
a
part
of
service
entries
that
you
absolutely
need
I
mean.
Is
it
aggressive,
I,
don't
know
which
case
you
you
really
have
in
mind
and
create
a
new
crd?
G
Is
not
that
hard
to
create
a
new
CRT
and
have
proper
semantics
and
narrow,
and
maybe
you
know
in
the
context
of
gateways,
so
other
people
can
adopt
this
notice,
your
specific
and
so
on.
I
I
think
it's
just
for
architectural
consistency,
perhaps
I
mean
you're
right
I
mean
you
can
just
create
a
new
crd,
which
is
which
has
a
different
scope
than
what
you
think
the
current
one
has
at
least
my
my
perspective
is
that
you
know
service
entry
is
essentially
an
external
service
and
same
kinds
of
logic
should
apply
as
for
any
service.
I
Similarly
with
virtual
Service,
so
that's
the
view
but
you're
right.
There
is
a
big
issue
that
hey
the
sidecar
mode,
has
already
been
shipping
with
this
scope,
and
that
is
definitely
a
concern,
but
the
longer
we
don't
do
this,
then,
the
more
likely
it
just
never
happens.
I
E
I
just
want
to
make
sure
I
understand
the
problem
that
we're
discussing
here
so
that
I'm
on
the
same
page,
if,
if
today,
you
want
to
add
a
service
entry
or
frankly,
a
virtual
Service,
and
you
want
to
make
sure
that
it
does
not
disrupt
existing
traffic
in
your
mesh.
E
What
you
need
to
do
is
to
look
at
every
other
namespace
to
see
if
there
are
other
service
entries
or
virtual
Services
defined
with
that
same
host,
and
then
look
at
the
actual
Telemetry
data
from
all
of
the
traffic
to
see.
If
someone
is
accessing
that
host
without
a
service
entry,
and
then
you
can
know
okay,
this
host
name
is
or
isn't
safe
to
use.
Is
that
a
correct
summary.
E
C
I,
don't
know
that
you
can
really
get
the
Telemetry
without
the
service
entry.
So
it's
a
bit
of
a
chicken
and
egg
problem,
but
yeah
I
mean
in
general.
That's
how
you
could
do
it.
C
C
It's
not
necessarily
just
that,
like
I,
think
the
whole
service
entry
API
is
kind
of
broken
to
some
extent
like
we
can't
even
Implement
half
the
API
in
ambient
and
then
now
we're
saying
it
behaves
differently
like
it's
kind
of
getting
wonky,
so
I,
don't
necessarily
know
I.
Don't
think
the
solution
would
be
just
include
virtual
service
I'm,
not
necessarily
sure
what
the
solution
would
be.
B
Ideologically
I'm
on
this
I'm
on
the
side
of
name
things,
the
namespace
should
operate
in
namespace
scope.
I,
do
hear
the
feedback,
Zone
I,
think
it's
compelling
what
it
sounds
like
we
need.
Let
me
practice
this
phrase
that
differently
it
sounds
like
what
we
need
is
a
new
resource
service.
It
sounds
like
service
entry
is
broken.
B
There
is
a
subset
of
function.
There's
a
bit
of
functionality
in
the
API
that
not
usable
ambient
which
we're
wanting
to
you
know
have
stable
support
for
at
some
point
in
the
future,
have
interrupted
within
between
Ambience
and
sidecar
SEO
at
some
point
in
the
future,
and
it's
very
difficult
to
have
any
kind
of
I,
don't
even
say
parody,
a
typical
type
of
any
kind
of
interop
when
you've
got
two
different
behaviors
in
a
way
that
is
pretty
intrusive
to
users.
B
Making
networking
calls
so
what
it
sounds
like
I
I
can't
remember
who
said
it
in
the
past,
but
I
I,
wonder
if
similar
to
the
kubernetes
service
resource
it
serves
entry
into
doing
too
many
jobs
or
if
it
rather,
if
it
is
doing
too
many
jobs
and
the
the
products
that
benefit
from
having
different
resources.
You
know
smaller
resources
or
just
different
resources
to
accomplish
those
things
that
are
keeping
ambient
in
mind
and
that's
how
we
move
forward
here.
It's
a
little
crazy,
so
Delta
have
worked
for
sure.
I
Thank
you,
I
would
go
back
to
the
point
that
you
know:
firstly,
the
analogy
with
kubernetes
services,
and
secondly,
was
there
a
strong
reason
for
this
to
have
Global
scope
to
begin
with.
Has
we
don't
know
the
history
of
past
discussions
on
this,
but
was
there
ever
a
strong
reason
for
this
to
specifically
have
Global
cluster
scope.
I
Resources,
probably
should
prefer
smaller
scope
than
larger
and
and
the
analogy
with
Services
suggests
that
it
should
be
namespace
scope.
But,
of
course,
we're
dealing
with
the
fact
that
sidecar
already
has
this
shipping
for
with
global
scope,
and
that
makes
the
transition
harder.
C
D
I
E
Think
about
the
impact
there
is
character
or
categorically
different.
The
right
like
when
you
create
a
namespaced
service
that
URL
has
a
namespace
as
part
of
its
identity.
So
there's
very
little
chance
of
someone
accidentally
already
having
been
using
that
and
now
it
changes,
whereas
if
you're
capturing
google.com
there's
actually
a
pretty
decent
chance
that
other
namespaces
are
already
using
that
and
get
effectively
a
surprise
when
a
service
entry
changes
the
definition
without
having
access
to
their
namespace.
B
I
mean
at
the
end
of
it
feels
like
it
feels
like.
Probably
space
is
that
we
are
attempting
to
create
namespace
is
so
overblown,
but
like
tenancy
or
sure
namespace
properties
within
a
global
with
a
global
registry
which
is
DNS
right.
That's
the
common
threat
between
service,
the
service
resource,
the
service
entry
resource
is
that
you
are,
you
know
effectively
capturing,
you
know
via
I,
won't
say
capturing,
but
the
routing
is
happening
and
resistance
happening
via
DNS.
B
The
way
that
service
gets
around
a
wrap
gets
around.
This
is,
you
know,
it
makes
things
that
makes
the
global
thing
have
the
name
space
embedded
in
it
to
reduce
collisions
but
to
John's
point
in
the
chat.
If
you
have
a
common
name
space
and
you
create
a
Google
service
in
the
commenting
space,
you
will
run
into
some
unexpected
issues,
because
I
think
the
DNS
is
still
going
to
be
Global
and
it's
difficult
to
you
know
have
that
intent
of
how
that's
supposed
to
work
in
any
meaningful
ways.
B
You
know
conflict
with
external
things,
so
it
does
feel
like
the
current
behavior,
because
I
can't
remember,
because
service
entry
is
inherently
Global
because
you're
specifying
the
full
host
like
we're,
not
appending
the
service
entry
name
space
like
we,
don't
have
any
kind
of
key
to
represent
the
namespace
or
to
push
to
the
network
layer.
The
namespace
of
the
API
object
the
way
the
service
does.
B
It
feels
like
there
is
a
potential
for
improvement
in
the
API,
either
improvements
or
replacement
in
the
API
to
to
account
for
this.
It's
a
better
match.
Some
of
the
the
implementation
details
and
service
that
make
it
workable.
G
G
H
The
google.com
example
I
tested
with
classic
inside
car
I,
don't
and
I
noticed
that
behavior
and
notice.
We
were
copying
it
to
Ambience
and
that
felt
wrong.
So
I
don't
have
an
ambient
use
case,
but
sanjeev's
initial
point
I
think
this
is
the
time
to
you
know.
Our
choices
are
remove
it
before
beta
and
Kick
the
Can,
or
we
should
fix
it
now,
but
I
don't
want
to
ship
service
entry
with
something
that
is
perhaps
a
foot
gun.
G
F
H
We
had
the
whole
XTS
ambient
Evolution
right,
and
so
you
get
workloads
that
can
be
a
hostname
which
will
be
resolved
on
demand
DNS
or
you
could
just
go
to
that
DNS
and
zetunnel.
If
it
if
it
looks
up
and
has
that
host,
it
might
go
to
the
wrong
place.
So
just
in
theory,
it
feels
like
that
we
could
have
that
problem
again,
which
makes
sense
because
we
have
it
in
classic.
H
I
haven't
tested
it
in
ambient
I,
don't
know
if
that
is
truly
a
problem
and
ambient,
but
I
think
the
whole
point
is
API
architectural.
It's
not.
How
does
ambient
work
today?
I
think
that
answer
that
question
should
be
for
like
going
forward
before
we
ship
beta,
make
sure
we're
happy
about
the
state
of
things.
That's
the
question.
I
want
to
make
sure
that's
answered.
H
H
G
C
G
H
C
With
that,
it
doesn't
have
the
same
problem
with
the
ambient
waypoints,
because
the
waypoints
kind
of
change
the
model.
So
it's
all
it
does
some
sidecars,
but
we're
moving
information
I
want
to
help
sidecar,
so
I
guess
it
probably
doesn't
really
help
in
this
case.
E
B
H
Yeah
so
frankly,
I
haven't
spent
enough
time
thinking
about
virtual
service,
so
I
don't
feel.
I
can
speak
to
that.
But
I
do
agree
with
the
sentiment
that
the
idea
is
we're.
Looking
at
multi-tenancy
and
namespacing.
We
should
do
this
across
the
entire
SEO
API
for
ambient
before
it
goes
in
so
I
agree
that
the
design
doc
should
take
into
account
anything
virtual
service
related
and
whatnot,
if
like
it
should
be
holistic.
H
H
G
The
reason
we
have
DNS
structure
in
history
of
the
original
reason
was
for
security,
because
application
needs
to
resolve
a
service
name
of
fully
qualified
domain
name
and
if
the
underlying
network
is
not
secure.
So
if
the
result
DNS
resolver
is
not
a
cure,
then
our
security
is
broken
because
some,
you
know
some
of
men
in
the
middle,
the
DNS
and
then
we
capture
the
differencing.
We
verify
wrong
certificate
and
so
forth.
There
is
a
document
describing
it
that
is
and
remains
a
valid
use
case.
G
I
mean
if
you
have
a
network
where
the
DNS
resolver
is
not
secured,
we
need
some
form
of
DNA
scapular
or
you
need
to
put
some
secure.
Dns
in
place
doesn't
matter
which
one
and
that's
the
only
thing
I
mean.
Now
later.
We
have
used
it
to
invest
recently,
other
things,
but
that's
that's.
The
fundamental
reason
is
still
there,
because
our
security
model
is
based
on
intercepting
IPS
that
are
result
of
Gears
resolution.
H
So,
if
virtual
Services,
if
our
answer
is
that
virtual
services
are
I,
have
to
think
about
that
more,
but
it
seems
like
off
the
cuff
virtual
Services
have
HP
route,
which
is
the
better
safer
version.
It
feels
like.
We
wanted
a
safer
version
of
service
entry,
perhaps
eventually,
but
it
seems
inconsistent
to
me
to
ship
virtual
services
and
not
ship
service
entry
in
my
mind
and
that's
why
I
got
to
talk
with
solo
and
other
folks
for
why
virtual
Services
were
needed.
But
it
feels
like
we
should
remove
them
both
and
be
consistent.
C
It's
different
because
virtual
service
is
a
waypoint
only
thing
and
service
entry
is
eternal
and
service
entry
doesn't
really
make
sense
for
waypoints
because
we
only
have
Ingress
waypoints.
So
how
are
you
never
going
to
hit
at
google.com
on
the
Ingress
Waypoint
right?
It
only
really
make
sense
if
we
do
that.
What
I
assume
the
next
agenda
item
is,
which
is
about
egress
waypoints,
so.
H
A
All
right
so,
while
Ben
is
taking
notes,
Here,
who
has
this
last
item,
TCP
routing
for
Z
tunnel.
F
J
Yep
so
I
wanted
to
raise
this
item,
since
it
was
part
of
the
ambient
API
design
doc
for
egress,
specifically
how
TCP
routes
could
be
used
in
the
Z
tunnel
for
routing
egress
traffic
and
I
was
wondering
if
that's
still,
the
most
valid
solution
for
I.
Guess
controlling
that
egress
traffic
and
yeah.
Our
TCP
routes
for
Z
tunnel.
Is
that
something
that
scope
for
beta
or
Beyond.
B
On
the
one
hand,
sure
that
would
be
maybe
the
spot
that
we
might
think
about,
because
Eternal
tends
to
handle
L4
things,
but
also
view
tunnel
as
part
of
its
design
is
supposed
to
be
small
and
kind
of
cover
mesh
transport
and,
from
my
understanding
at
least
like
it
covers
mesh
transport
and
that's
it.
B
Adding
TCP
route
definitely
feels
like
an
expansion
on
that
and
I
think
that
I
I
personally
could
be
convinced
if
we
had
more
user
feedback,
indicating
that
there's
a
great
desire
for
TCP
route
and
there's
a
valid
reason.
Why
adding
the
waypoints
to
do
routing
is
to
is
a
blocker
for
people,
but
in
the
absence
of
that
I'm,
probably
leaving
on
the
side
of
keeping
Z
tunnel
small
for
a
beta
and
letting
users
change
our
minds
on
it.
So.
J
All
right,
I
know
just
kind
of
one
of
my
concerns
for
I
guess
TCP
route.
If
this
is
something
that
we
go,
if
we
want
to
pursue
for
configuring,
Z
tunnel
is
I
the
fields
that
are
suggested
in
the
design.
Dock
currently
don't
exist
in
the
TCP
route,
spec
and
so
I
kind
of
wanted
to
raise
this
item,
because
if
this
is
something
that
we
are
pursuing,
I
feel
like,
we
should
be
kind
of
exploring
that
design
discussion
sooner
rather
than
later.
J
Otherwise,
like
post
beta
is
going
to
come
around
and
we're
going
to
be
delayed
on
apis
that
don't
exist
right
now.
G
Yeah
I
think
I
I.
We
discussed
this
in
a
very,
very
long
trade
before
on
on
Slack
and
I
kind
of
changed
a
bit
my
mind,
but
the
fundamental
problem
is
that
to
support
egress
I
mean
with
HealthWorks,
is
z
tunnel
in
support
L4.
We
definitely
need
you
know.
If
we
want
to
have
an
egress
Gateway,
we
need
some
way
to
direct
traffic
to
the
egress
Gateway.
There
is
no
questions
that
you
know.
Otherwise,
bytes
will
not
go
there.
G
Now.
Tct
route
is
one
way
to
do
it,
cni
not
missing
and
letting
the
CMI
layer
doing.
It
is
another
way,
but
one
of
the
two
needs
to
happen,
and
so
far
we've
been
very
adamant
that
everything
must
be
captured
by
Z
tunnel
and
we
don't
want
to
let's
see
an
eye
layer,
take
care
of
it.
So
that
implies
that
we
we
have
to
support
the
City
route.
I
cannot
see
how
else
we
can.
G
Okay,
so
so
the
promise
we
want
to
use
HTTP
route
instead
of
virtual
service,
because
we
we
just
discussed
that
you
know
virtual
Services
same
problem,
so
HTTP
route
is
a
place
where
we
separate
detail
for
nl7,
so
ftcp
routine,
HTTP
route.
So
if
we
want
to
move
to
http
route
because
it
has
namespace
isolations
and
probably
want
to
move
to
TCP
route
as
well,
because
it
also
has
any
special
isolation-
and
it
has
a
proper
12
semantics
over
here-.
C
Yeah
I
think
this
generally
points
to
a
bigger
problem
is
that
with
Z
tunnel
we
are
operating
in
the
same
space
as
the
cnis
and
because
we
are
a
general
open
source
project
that
wants
to
run
everywhere.
The
natural
tendency
is
to
go
re-implement
every
surface
that
we
may
need
so
we've
already
reinvented
service
we've
already
reinvented.
C
You
know
all
these
other
things
so
sure
why
not
invent
redo
some
other
thing
that
really
is
belonging
at
the
cni
layer
and
so
I
think,
there's
kind
of
a
more
general
direction
that
we
may
need
to
start
looking
to
have.
Okay.
We
have
this
case
where
we
can
do
everything
ourselves
for
cases
where
we're
in
really
dumb
environments
that
aren't
flexible
enough,
but
we
may
also
need
to
be
able
to
run
Z10
all
in
a
more
integrated
manner
that
can
make
use
of
the
infrastructure
instead
of
replacing
it.
C
You
know
when
we
run
on
kind
sure
why
not
replace
Q
proxy
to
do
Services.
It's
not
very
smart,
but
other
cnis
are
a
lot
smarter
and
you
know,
being
the
10th
project
to
implement
a
cube.
Proxy-Like
thing
is
kind
of
not
the
best
use
of
time.
J
And
I
guess
in
terms
of
driving
this
discussion,
since
it
sounds
like
definitely
needs
More
Design
stage
at
this
point.
Is
that
doc
that
I
linked
to
the
best
place
to
continue
that
or
do
we
need
a
separate
dock
specifically
for
this
scenario.
C
It's
probably
good
to
discuss
in
another
dot
because
that's
like
the
giant
ambient
API
stock
right
that
was
just
mostly
intended
for
light
future
Direction.
So
having
a
more
scope,
funds
probably
are
clear.
C
G
C
G
G
A
Hey
folks,
I
need
to
run
to
another
meeting
and
if
you
guys
want
to
continue
to
discuss
someone
else,
please
take
over
the
presentation.
J
C
C
F
I
F
J
It
sounds
like
we
need
a
new
design
doc
for
this
and
there's
some
skepticism
on
the
priority
on
this,
but
so
I
guess
first
step
will
be
to
get
a
new
design
doc
together.
To
kind
of
summarize
what
we've
discussed
here
and
what's
currently
in
that
API
ambient
API
doc.
C
C
F
J
I
Hey
I
just
had
a
quick
question
for
the
community.
Is
there
anybody
looking
at
I'm
thinking
of
looking
at
making
ambient
work
with
OBS
base
cnis?
Is
there
somebody
else
working
on
something
similar
and
would
like
to
collaborate
offline
on
me
having
ambient
work
with
obvious
Style
cnis.