►
From YouTube: Ambient Mesh WG Meeting 2023 02 01
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
B
Yeah,
okay,
yeah,
yeah,
sorry,
I,
there's
just
a
lot
of
open
topics:
sorry
somewhere,
there's
a
table
with
colors,
okay
yeah.
So
in
previous
weeks
we
talked
about
different
options
for
doing
the
Z
tunnel,
authorization
policy
or
network
policy,
or
what
we
should
do
I
want
to
see
if
we
could
drive
towards
consensus
on
that
I.
B
My
opinion
and
I
think
this
sounded
like
kind
of
weak
consensus
last
week
was,
we
would
add
a
I
forget
what
you
call
it
a
proxy
class
or
we
could
probably
come
up
with
a
better
name,
but
some
some
class
on
the
authorization
policy
to
Define
what
it's
for,
and
there
was
some
hand
wavy
discussion
of
like
oh
well,
we'll
do
certain
Behavior
based
on
the
type
of
the
policy
in
the
class
and
that's
what
this
table
shows
it.
B
The
table
is
favoring
being
extremely
precise
and
not
a
concise
explanation.
That's
why
it's
25
lines
I
think
our
docs
could
be
much
much
more
concise
than
this
and
still
get
the
message
across.
B
So
if
you're
seeing
this
giant
table,
one
thing
gets
too
complicated.
You
might
be
right,
but
hopefully
that's
not.
You
know
over
indexing
on
on
that,
so
I
guess
what
I
wanted
to
talk.
C
B
D
B
D
Have
a
question:
I
have
a
question
on
this.
Oh
sorry,
okay,
so
I
have
a
question
is
proxy
class.
Why
do
we
really
need
it?
So,
for
example,
let's
say
if
we
go
with
like
one
single
policy:
spec
one
single
API,
and
if
there
is
a
Parent
Trap,
then
we'll
directly
apply
it
to
Waypoint.
If
there
is
no
Parent
Trap
we'll
apply
to
his
eternal
sidecars
and
videos
and.
B
The
issue
that
we're
trying
to
solve
is
identifying
which
requests
are
meant
for
a
z
tunnel
and
which
are
not
because
the
issue
is
that
Z
tunnel
can
only
ever
do
L4
policy
right
and
so
basically,
if
we
don't
have
a
way
to
say
this
policy
is
only
for
the
Z
tunnel.
Then
any
policy
that
we
have,
that
has
an
L7
attribute
and
a
namespace
is
going
to
break
in
Z
Tunnel
right.
D
B
But
that's
that's!
The
issue
is
that
if
so,
if
you
say,
I
have
to
apply
like
a
namespace
policy
with
with
L7
and
attribute
right
now,
I
may
have
wanted
that
to
say:
oh
I
just
want
to
apply
other
sidecars
because
I
know
all
my
sidecars,
maybe
I
even
put
a
port
and
say
like
this
only
applies
to
480
and
I
know
all
my
applications
run
HTTP
there
right.
B
B
It's
basically
like
the
issue
that
you
try
to
solve
with
sidecars,
but
much
worse,
but
even
worse
is
like
we
want
to
so
there's
kind
of
two
ways
when
you
have
ignoring
sidecars,
when
you
have
the
Waypoint
and
Z
tunnel
request
path,
there's
kind
of
two
options
for
authorization,
policy
enforcement-
we
can
say:
okay,
you
had
a
waypoint.
The
Waypoint
must
have
done
the
policy
enforcement.
B
If
the
request
came
from
Waypoint,
we
just
pass
it
through
NZ
tunnel
and
don't
do
any
policy
right
that
that
model
would
work
fine
without
this
I
think
I.
Think
a
safer
model
is
to
have
separate
layers
with
separate
policies.
So
we
have
defense
in
depth
similar
to
inside
course
how
you
can
have
Network
policy
at
the
l3l4
layer
and
then
authorization
policy
at
the
L7
layer
right.
B
So
if
we
do
that,
then
we
need
to
Clearly
say
these
policies
are
for
the
waypoints
and
I
can
put
on
my
L7
attributes
there
and
whatnot,
and
these
policies
are
for
the
Z
tunnel
and
we
can
actually
reject
if
they
even
try
to
put
L7
attributes.
So
we
don't
run
into
the
issue
of
them
accidentally
doing
it
and
then
denying
it
runtime.
D
Okay,
so
my
only
concern
with
this
is
right.
Now,
with
this
approach,
you're
gonna
have
like
two
different
policy:
spec
one
position,
one
for
the
Waypoint
right
yeah.
We
we
can
have
like
one
single
policy
spec.
If
someone
is
specifically
specifying
the
parent
graph,
then
we
should
like
promote
a
message
like.
If
you
want
to
apply
the
policy,
all
seven
policies,
L7
attributes,
then
you
should
have
parent
rep
and
we
choose
to
not
apply
policies
on
Z
tunnel.
If
it's
like
the
L7
attributes,.
B
Like
is
there
ways
we
could
make
it
work
we
could
probably
implement
it,
but
to
me,
like
being
very
explicit,
is
much
more
clear,
like
the
alternative,
really
that
we
initially
thought
was
using
network
policy
as
this.
So
it's
very
clear
like
this
is
your
L4
API.
This
is
your
L7
API
right
and
they
layer.
B
So
that's
effectively
what
this
is
doing.
It's
just
we're
using
authorization
policy,
for
you
know,
syntax
reasons.
E
D
F
Sorry
I
have
two
mute
buttons:
I,
don't
I,
don't
think
this
is
that
out
of
pattern,
you've
got
an
L4
layer.
You've
got
an
L7
layer,
they
kind
of
handle
different
things.
There's
nothing
implicit,
I,
think
The
L4
policy
API
is
not
that
dissimilar
to
what
some
other
of
the
more
advanced
cnis
are
doing.
F
I
definitely
I
definitely
do
not
want
a
world
where
we're
kind
of
like
implicitly
guessing
how
to
apply
the
policy
depending
on
the
network
architecture.
That
seems
scary.
So.
D
G
Concern
is
I,
don't
have
a
proposal,
but
I
have
a
concern
of
the
fact
that
we
have
to
reference
infrastructure
components
in
the
API,
because
that
will
complicate
any
migration
between
infrastructures,
for
example,
if
you
have
a
policy
set
that
refers
to
weapons
per
service
account,
and
you
want
to
migrate
to
policies
that
refer
to
weapons
per
namespace.
G
E
I
I
kind
of
agree
with
with
quote
on
this
one,
but
did
we
didn't
we
decide
that
waypoints
are
represented
by
Gateway
resources.
A
E
So
I
think
we
can
address
what's
consent
by
having
the
reference
to
the
Gateway,
which
is
what
government
Gateway
is
well,
not
those
workload.
Selector
join.
G
Well,
assuming
that
the
stability
of
Instagram
API,
like
are
we
going
to
have
this
notion
of
namespace
and
service
account
with
gay
points
gateways
forever?
Or
is
it
just
a
temporary
situation
right.
E
G
G
Right
and
I
think
we
need
to
make
it
very
explicit
somewhere,
it's
hard
to
say
when
you
say
wait,
does
it
mean
the
weapon,
intent
or
the
way
input
physical,
Waypoint
right,
because
I
think
the
intent
is
fine.
Reference
between
intent
is
fine,
but
reference
to
the
physically
deployment
is
not
okay,
I
think.
B
Yeah
yeah,
I
I
totally
agree
with
that
and
I
think
it's
I'll
clarified,
but
it's
the
intent
so,
like
you
could
imagine,
hypothetically
a
user
creates
five
Gateway
objects
in
five
different
namespaces,
but
that's
implemented
by
one
Mega
proxy.
That's
lives
in
other
cluster
or
something
right.
I
think
that
that
would
be
perfectly
fine
now
and
in
the
istio
model
as
implemented
today.
There
there
are
one
to
one
but
there's:
no,
that's
not
a
requirement
right.
E
And
with
that
there
is
no
requirements,
that's
a
waypoint
or
Gateway
is
actually
an
Easter
component,
any
other.
You
know
kubernetes
gamma
gateways
that
supports
this
policies
that
happens
to
implement.
This
policy
will
also
work
equally
well.
So
if
you
put
console
or
whatever
as
a
Gateway
and
they
implement,
this
API
is
not
to
be
perfectly
Fair.
G
Yeah
so
I
think
what
missing
is
probably
the
we
need
to
Define
very
well
with
the
intent
of
a
Gateway
is
I.
Think
right
now
it's
the
sort
of
the
Gateway
spec
is
what
the
intent
is,
but
I
think
that
that's
the
critical
bit
here
because
referring
to
that,
seems
fine,
because
then
anyone
else
can
implement
the
Waypoint
as
the
way
as
you
wish,
including
non-envoy.
But
if
we
somehow
have
to
refer
to
Waypoint
by
its.
B
B
Yeah,
no,
that's
that's
absolutely
the
case
and
I
totally
agree
like
the
intent
is
that
a
Gateway
represents
the
Waypoint
and
you
we
could
have
an
option
to
disable
us
creating
the
actual
Envoy
deployment
and
someone
else
can
get
something
that
deploys
nginx
or
something
right,
and
so
those
those
two
are
not
tightly
coupled.
We
only
have
one
implementation
where
they're
tightly
coupled
but
I
totally
agree.
That's
that's
shouldn't
be
the
case
and
I
will
make
sure
that's
clarified
in
the
doc.
G
Yeah,
well,
that's
fine,
because
that
concerns
mostly
about
like
I,
mean
we
start
from
a
situation
where
I
have
like
a
you
know:
virtual
Waypoint
per
service
account
because
that's
sort
of
what
our
model
is
in
issue,
and
so,
when
you
make
it
easy
to
migrate
the
situation
where
you're
going
to
share
and
and
if
you
have
to
create
these
Waypoint
resources
using
Gateway
apis.
That
means
your
policies
also
have
to
change,
and
it
just
makes
migration
complicated.
H
G
E
Space
I
I
think
the
intent
is
that
waypoints
can
be
implemented
as
per
per
service
account
per
Gateway
or
less
infrastructure.
So
I
don't
think
we
want
to
make
any
policy
decisions.
That
assumes
that
will
only
have
one
Waypoint
per
service
account.
H
E
I
I
assume,
when
vendors
or
whoever
implements
other
things
will
have
different
classes
of
data.
Gateway
class
provides
different
and
users
will
opt
the
Internet.
It's
not
a
migration
issue.
They
can
still
choose
to
have
that
namespace,
but
whatever
they
want
it's
not,
but
there
will
be
other
options
being
provided.
I
suspect.
E
B
Yeah
I
think
we
would
say
that
if
they
want
more
granular
policies,
they
should
have
more
granular
waypoints
and
do
per
service
count
way
points,
and
if
they
need
even
more
granular
than
service
account,
then
this
is
really
the.
What
we
were
debating
quite
a
bit
a
couple
weeks
ago
is
that
we
can't
actually
represent
that
today,
so
they'd
have
to
do
more.
Invasive
changes
like
splitting
up
their
workloads
to
use
different
service
counts,
but
we,
our
hypothesis,
was
that
that
would
be
a
very
small
number
of
users.
In
that
case,.
G
C
E
The
policy
is
not
it's
scary.
For
to
service,
I
mean
it's
not
the
granularity
is
that
it's
you
have
a
policy
money
for
an
a
space
in
the
police.
You
can
refer,
you
know
if
it
goes
to
36.
You
apply
some
policy
if
it
goes
to,
and
you
have
the
content
of
the
policy
itself,
it's
it's
making
it.
You
know
granular.
G
E
Account
the
service
yeah
for
this
case
you
keep
using
sidecars,
so
I,
don't
think
deprecating,
sidecars
or
the
old
policies
or
I'm
not
trying
to
force
migrate.
Anyone
if
you
have
one
better
performance,
simpler
life,
easier
maintenance
and
so
forth.
You
use
Gateway,
API,
use,
gamma,
API
and
use
this
restricted,
more
restrictive
set
of
features
or
you
can
use
Cycles.
So
it's
not.
E
G
E
I
I,
don't
think
we
necessarily
want
I
I
personally,
don't
want
this.
I
want
people
who
need
Advanced
features
or
super
complicated
things
to
keep
using
sidecars
and
people
who
want
easy
to
maintain
simpler,
faster
things
to
the
zombie
and
I.
Don't
think
we
we
want
to
mix
it
because
they
don't
have
to
implement
all
those
crazy
features
in
ambient
and
make
ambient
slow.
E
F
G
Kind
of
the
general
principle
right,
if
and
if
we
make
it
explicit
right,
that
means
we'll
stuck
with
it
forever.
So
the
problem
is
the
benefit
of
implicit.
Is
that
you
have
flexibility
to
choose
later,
but
if
you
make
it
explicit
whether
you
know
this
the
layout
term
references,
then
it's
it's.
It
has
to
be
that
way
forever.
Right,.
F
E
Obviously
we
have
options,
but
because
it's
you
know
that's
what
we're
doing
right
now.
I
mean
we
are
adopting
the
kubernetes
Gateway
model,
where
we
refer
our
past
policies
or
whatever
to
the
gator
HTTP
route,
and
we
still
support
the
old
one.
So
if
we
find
that
later,
we
like
Ethan
was
saying,
we
need
to
introduce
more
granular
activities
can
obviously
add
it.
F
B
A
Okay,
cool
I,
guess
from
my
perspective,
I
do
agree.
Proxy
class
seems
right.
I
was
a
little
bit
intimidated
by
the
table.
You
put
together,
Joe,
particularly
the
semantics
difference
between
Gateway
and
Waypoint.
I
think
could
be
potentially
confusing
to
user,
especially
a
lot
of
times.
People
are
going
to
think
Waypoint
as
a
Gateway,
so
the
semantics
here,
such
as
the
semantic
Force
selector
and
the
parent
giraffe
right,
the
inconsistency
would
be
interesting.
But
by
the
way,
are
you
suggesting
for
the
parent
arrive?
A
A
E
Journal,
if
I
can
make
a
suggestion,
can
you
add
an
I
in
front
of
the
Gateway,
so
I
Gateway
or
istio
Gateway
and
then
add
copy
that
to
K
Gateway,
which
is
kubernetes,
because
these
are
two
gateways
and
I.
Don't
think
when
I
read
it,
I
thought
you
were
I
thought
you
were
talking
about
istio
Gateway,
but.
E
B
Well,
I
remember
both
kind
of
but
I
guess
yeah.
A
E
B
E
E
B
B
That
could
be
a
ambiguous
escape
hatch.
E
B
B
E
We
may
still
want
to
put
Gateway
class
Waypoint
Gateway
class
Ingress
Gateway
class
eClass.
Just
for
the
sake
of
support,
you
know
be
intended.
A
B
So
the
intent
is
that
if
you
leave
it
unspecified,
we
give
Legacy
behavior
for
backwards
compatibility,
and
so
they
don't
have
to
specify
things.
But
for
some
things
we
do
want
them
to
be
explicit.
So
like
Z
tunnel,
for
example,
we
only
will
apply
things
to
detail
if
they
tell
us
it's
for
Z
tunnel,
because
it
has
different
semantics
with
L7
right.
C
E
B
H
B
G
B
E
I
think
it's.
There
is
another
aspect
of
this
discussion.
John.
If
we
apply
do
you
want
to
apply
policy
twice
and
and
how
does
it
intermingle
and
if
you
have,
you
may
have
some
decisions
where
you
allow
or
deny
based
on
a
mix
of
L7
and
L4,
and
splitting
it
into
is
extremely
tricky
and
semantically
and
for
users.
I
would
rather
have
the
Waypoint
apply
L4
nl7
policies
together,
because
then
you
can
make
sense
of
them.
Oh.
B
I
absolutely
agree:
we
should
not
force
the
user
to
split
them
like
the
Waypoint
has
to
do
both
and
if
they
want
to
apply
wow.
My
initial
thing
was
if
they
want
to
apply
a
set
of
policies
which
can
be
mixed
and
then
an
additional
set
of
policies
of
Z
tunnel.
That's
fine,
yeah
I.
Think
the
alternative
is,
maybe
you
say,
okay
at
Z
tunnel,
if
it's
already
on
the
Waypoint,
don't
apply
policies
but
I,
don't
think
that's
good
from
a
kind
of
layering
model
right.
B
G
G
Be
applied
so
far
right,
but
but
if
a
service
like,
if
it's
applied
at
Waypoint,
you
don't
know
the
service
account
B
at
Waypoint.
E
G
E
D
E
That
I
agree,
but
we
want
to
maintain
paperwork.
I,
don't
know
that's
unfortunate,
but
but
necessary.
If
you
want
to
give
backward
compatibility.
H
E
Yeah
yeah
that
may
be
another
option,
but
I
I
I
would
stay
away
from
making
any
things.
That
requirement
is
saying
that
API
requires
declare
on
water
because
we
still
won't
be
able
to
save
cost
by
using
the
I.
I
would
rather
go
with
documentation
explaining
clearly
which
attributes
are
used.
What,
where
and
and
figure
out
wait
till
kubernetes
get
the
gamma
defines
their
own
motorization
and
then
maybe
move
to
that,
because
that
would
probably
be
more
clear.
C
D
So
I
have
a
question
so
introduction
to
this
proxy
class
would
resolve
the
hot
Z
TCP
issue
like
because
right
now
we
have
the
Separation
Will,
Wait
and
Waypoint,
and
later
and
Waypoint
can
serve
to
like
the
broad
TC
reports
as
well.
If
there
is
any
right,
we
can
resolve
this
right.
We
shouldn't
support
the
TCP
thing
anymore,
right.
B
No
I
think
it
is
still
an
issue
because
in
the
Waypoint
you
could
have
a
TCP
or
snift
port
and
I
have
L7
policy.
So
we
just
don't
need
the.
D
C
D
B
B
So,
for
example,
you
could
have
a
Watson
policy
right,
we're
never
going
to
put
wasm
in
the
Z
tunnel,
but
that
doesn't
mean
that
you
don't
want
to
have
a
horror
things
doing
wasm
right
or
like
client-side
routing
overrides
for
T
speed
like
we're
not
in
complex
routing
logic,
into
Z
tunnel,
even
for
TCP.
But
that
is
something
that
can
be
expressed
in
the
API
in
Waypoint.
So
there's
still
the
use
cases
to
send
through
the
Waypoint
for
TCP
traffic,
not.
C
B
G
D
B
Traffic
goes
to
the
Waypoint.
We
can
certainly
have
a
user
configure
things
more
explicitly
and
say
that
this
set
of
traffic
like
they,
the
the
granularity,
is
this
namespace
or
this
service
count
like
all
or
nothing
goes
through
the
Waypoint
right.
We
could
add
policy
to
say
this
set
of
traffic.
You
know
goes
to
the
Waypoint
and
the
set
can
skip
I,
think
that's
fine
and
that
could
be
based
on
board
or
protocol
and
allow
things
like
that.
But
they're.
E
And
the
different
Industries
is
was
an
external
Z
will
probably
never
be
in
seasonal
and
they're
important
part
of
the
authorization
gateways.
Again
they
still.
The
Gateway
API
is
defined
TCP
route
and
and
TLS
route
and
other
things.
So
so
the
gateways
need
to
support
L4
routes
for
this
purpose,
but
I
completely
agree
with
that
that
the
PCB
hack
and
the
confusion
that
we
had
can
be
resolved
in
in
with
with
Waypoint.
So
there
is
no
need
to
continue
to
support
this
guest
mode.
E
Where
report
maybe
TCP,
maybe
I'll,
maybe
HTML
7,
maybe
L4,
and
we
just
based
on
sniffing
especially
since
Gateway,
has
clearly
separated
ports,
and
you
know
you
either
have
a
particity
routes
or
you
attach
HTTP
routes.
If
you
attach
an
HTTP
route,
it's
clear
intent
that
this
is
going
to
be
an
HTTP
Port.
So
I
don't
think.
Maybe
we
can
add
later
sniffing
mode.
If
we,
if
the
Gateway
API
defines
sniffing
and
other
vendors,
but
I,
don't
think
we
should.
E
D
G
G
B
B
Like
a
race
I
mean
like
I,
I,
totally
agree,
most
people
don't
don't
use
it,
and
port
number
and
protocol
are
also
not
necessarily
the
same
right.
You
can
run
into
issues
there,
so
I
I
agree.
We
should
protocol,
but
I.
Don't
know
that
it's
strictly
coupled
to
this
discussion
of
how
Ambient
Energy
tunnel
behave.
G
E
It's
a
good
point
in
this
way
when
you
said
parent,
ref,
John,
didn't
you
mean
exactly
the
same
semantics
and,
and
you
know
you
can
return
to
a
section
in
the
Gateway
which
implies
sport.
E
C
B
B
E
B
G
Well,
yeah
I
mean
that
that
part
too,
but
I
mean
it's
just
hard
to
explain
that
you
you,
our
system,
analyzes
this
content
of
the
spec,
seeing
if
it's
port
and
only
applies
on
that
part
because
it's
just
seems
complex
first
of
all,
Port
is
a
back-end
Port,
not
Service
Port.
So
now
we
have
12
of
Z.
I
have
two
dual
advancing,
which
is
again
a
problem
right.
B
That
that
is
what
I
realized
then,
who
said
that
that
I
was
concerned
with,
but
it.
If,
if
we
ignore
that
problem,
it
seems
like
you
would
just
add
Port
as
an
attribute
in
our
back
right.
But
that
is
an
issue
that
now
it's
changing
from
back
end
port
to
Service
Port,
because
it's
happening
before
the
VIP
resolution.
Now.
G
E
No
no,
but
it's
it's
purpose,
so
the
policies
will
not
be
completely.
You
know
applied
to
the
entire
Waypoint
or
the
entire
gateways
they
will
apply
to.
They
must
have
a
port.
E
No,
no,
no,
no,
no,
the
Waypoint
cannot
know
back
and
Port
service
I.
Don't
think
anyone
expected
that
you
can
write
a
policy
in
a
in
a
waypoint
or
a
Gateway
referring
to
the
back
end
port,
because
in
a
more
cluster
you
can
have
multiple
services
with
different.
You
know:
service,
port
and
different.
G
G
Right,
but
we
have
a
problem,
because
if
you,
if
you,
if
your
Waypoint
is
per
IP
I'm
a
mix
of
TCP
and
TCP
ports,
we
need
to
make
sure
that
we
don't
apply.
It
should
be
policy
to
the
TCP
port
and
the
only
way
I,
don't
say,
I
have
a
way
to
do
that.
Right
now,
over
there
per
Waypoint
selectorate
foreign.
B
Yeah
yeah
so
I
mean
by
in
so
if
we
add
a
new
field,
that's
like
today
how
you
do
it
is.
You
say,
on
Port,
80,
I'm,
applying
L7
policies
and
it's
up
to
the
user
to
make
sure
that
poor
data
is
actually
HTTP
and
that
they
didn't
apply
that
to
the
whole
namespace
and
some
other
service
runs
TCP
on
poor
data
right.
It's
it's
not
amazing!
B
That's
why
REM
suggestions,
we
add
protocol
TCP
or
HTTP
and
say
this
policy
only
applies
to
http,
and
then
they
don't
manually
figure
it
out
right
so
I
mean
from
us
in
the
Waypoint
for
a
service.
We
know
if
it's
HTTP
or
not
for
a
pod,
I
guess
you'd.
Well,
it's
a
bit!
It's
a
bit
harder
there,
because
we
don't
have
as
much
info
in
the
xdss
today
right
like,
but
for
each
yeah
that
becomes
problematic
there.
E
B
B
E
Quickly,
better,
it's
literally
better
if
the
restrictions,
if
in
Waypoint
we
put
restriction
to
validation
and
through
requirements
that
you
must
have
a
port
and
you
must
be
either
TCP
or
HTTP,
and
you
need
to
be
explicit,
I
think
it's
a
win
for
everyone,
because
it's
it's
the
confusion
we
had
inside
in
install
the
API,
where
we
cannot
change
it
because
of
backward
compatibility,
classification
and
and
Legacy,
but
with
Waypoint.
We
have
the
opportunity
to.
You
know,
remove
the
confusion
that
we
found
in
in
Cycles.
I
I
G
E
B
E
Saying
that
waypoints
are
used
for
L7
and
and
for
L4,
we
are
just
using
Z
tunnel
with
with
a
reduced
API
surface
I
mean
without
M7
and
and
then
in
V2.
We
can.
You
know,
based
on
what
gamma
git
we
are
doing,
we
can
introduce
because
that's
exactly
what
what
Gateway
did
I
mean
they
launched
with
HTTP
only
with
HTTP
route
and
TCP
stuff
is
still
in
Alpha
and
not
supported
by
most
gate
implementations.
E
If
JK
Gateway
doesn't
support
TCP
routes,
why
would
the
Skyfall,
if
V1
ambient,
only
ships
with
Let's.
E
F
B
But
the
only
thing
that
has
a
protocol
associated
with
it
is
a
service.
Yes,
so
on
the
server
Waypoint
for
sorry,
the
server
Z
tunnel,
we
get
a
request
always
to
a
pod
IP
and
we
need
to
say
this
had
to
have
gone
through
the
Waypoint
or
or
it's
fine
to
not
go
through
Waypoint,
but
a
pod
IP
doesn't
have
a
protocol
associated
with
it.
So
there's
no
way
for
a
z
tunnel.
To
ever
say
this
request
should
have
gone
to
a
waypoint
which.
E
It
it
does,
I
mean
it's
not
the
the
request
to
a
port
IPS
or
equals
to
both
IPM
port,
and
we
have
the
container
Port,
which
has
a
name,
and
we
have
the
service
port,
which
has
a
name.
So
even
if
you
go
to
8080,
88
is
a
Target
Port
for
service,
so
we
we
can
either
explicitly
or
or
or
you
know,
Define
what
are
the
HTTP
ports
that
we
are
concerned
about
and
have
the
target
ports
I.
B
E
Sure
I'm
sure
you
can
resolve
this
is
ambiguity
and
be
explicit
about
about
what
ports
are
selected
as
https
and
much
easier
than
than
combining
TCP
so
and
it's
not
bad
to
have
explicit
HTTP.
So
if
you
have
HTTP
I
think
it's
it's,
you
know
application
for
the
Target
Port
plenty
of
quiz
to
be
explicit
and-
and
you
know.
E
G
G
E
G
Yeah,
so
the
fact
that
this
GP
is
explicit,
but
we
still
have
to
support
you,
know
TCP
ports
and
GP
services,
so
it
could
be
like
an
exception
there.
But
it's
it's
different
than
saying
you
know.
Everything's
just
can
be
either
because
once
you
have
an
intent
that
shows
this
http,
you
have
to
honor
that
intent
and
that's
easier
to
do.
B
I'm
very
conflicted,
like
I,
agree
that
less
guessing
is
better,
but
at
the
same
time
like
one
of
the
goals
of
ambient
is
easy
onboarding,
and
we
know
that
before
we
had
sniffing
the
issue,
every
single
person
that
adopted
these
two
had
was
that
they
had
to
go
rename
every
ports
in
their
entire
mesh
to
get
functionality
right,
so
we'd
be
kind
of
taking
many
steps
backwards.
If
we,
if
we
add
that
requirement
back
trying.
E
E
E
A
E
E
So
when
you
create
either
an
HTTP
router,
any
anything
that
declares
the
intents
that
you
want
a
particular
service
or
port
to
be
L7.
You're
done,
you
don't
have
to
do
any
guessing.
If
you
don't
do
anything,
then
it's
TCP.
That
means
you
don't
care.
I
mean
if
a
particular
portal-
or
you
know
it's-
it's
not
doesn't
have
anything
else.
7
referred
to
it
then
bye
pass.
B
J
B
K
Yes,
so
I
think
you
know
my
question
is
about:
will
we
take
a
similar
approach
of
the
Gateway
API
to
be
explicit,
like
HTTP
route,
TCP
route,
basically
in
the
policy
name
or
the
policy
itself?
The
explicit
about
you
know
whether
it's
for
L7
or
for
you
know,
io4
or
you
know,
I
just
wish
to
know
the
current
direction
will
in
That
explicit
direction
or
something
you
know
deduced
from
I
guess
deduced
and
rather
than
you
know,
being
explicit.
K
E
That's
that's
again:
the
cost
is
not
only
security.
It's
it's!
You
know
you
have
to
go
to
Waypoint
for
Waypoint
to
guess.
If
you're
doing
HTTP
or
TCP
versus
TCP
goes
straight
through
and
if
you
actually
want
L7
Telemetry
you
opt-in
for
a
seventh
element,
you
pay
the
price
for
so
hope,
and
you
get
a
simple
telement.
You
don't
want
it.
You
get
L4,
Telemetry
and,
and
it's
cheaper.
So
any
things
that
will
involve
an
extra
hope
should
have
an
intent
behind
it.
It
should
never
put
an
extra
hope
without
user.
K
Something
like
a
TCP
policy,
full
or
PCP
policy
bars
that
only
apply
to
Z
tunnel
and
HTTP
policy,
food
or
HTTP
policy
bar
only
applied
to
Waypoint
via
this
or
like
a
with
this
approach,
conforming
to
the
Gateway
API
standard
or
or
what's
a
I
guess,
what's
the
wrong
of
that
being
explicit?
Is
that
basically
user
needed
to
be
conscious
about
whether
they
are
defining
L4
L7
or
we
want
to
somehow
reduce
the
user's
burden
of
specifies
layer
or
I
I'm
a
little
bit?
B
B
Necessarily
have
an
answer
that
but
I
was
going
to
say
like
there.
The
intent
is
still
explicit
in
the
current
design.
It's
it's
just
a
more
coarse,
grained,
explicit
signal
right.
So
you
know
we
could
have
at
the
Pod
Level
Pro,
like
you
know,
there's
different
levels
of
where
we
can
explicitly
opt
in
I
I.
Think
it's
worth
visiting,
but
well
I!
Guess
we
don't
have
much
time
to
discuss
other
topics,
but
I
think
we
should
yeah
John.
E
E
An
incremental
approach
and-
and
you
know,
do
exactly
the
same
thing-
that
Gateway
did
move
with
HTTP
first
and
super
explicitly
intentions
and
odds
more
flexibility
later,
because
that
will
allow
us
to
ship
ambient
faster
with
with
more
strength,
because
we'll
focus
on
on
the
L7
and
and
the
things
where
Waypoint
is
absolutely
necessary
and
doesn't
stop
us
from
doing
it
later.
More
guest
based
approach.
B
B
E
If
you
are
very
explicit,
I
mean
you
have
to
require
hey
to
use
Waypoint
and
get
all
these
wonderful
features.
You
need
to
continue
to
put
a
name
for
the
fourth.
If
the
containers
backward
is
a
service,
it's
not
the
regression.
We
already
require
it
in
this.
You
know
you
get
a
lot
of
value
by
putting
that
explicit
intent.
A
So
shall
we
revisit
this
John
after
you've,
given
some
thoughts
on
implementation,
yeah
yeah,
because
we're
out
of
time
too
I
I,
don't
think
we'll
have
times
for
any
other
topics,
but
there
are
actually
there
are
a
couple
of
topics.
So
please
take
time
to
take
a
look
of
the
dog
offline.
Maybe
we
can
discuss
next
time.
J
Okay,
so
this
just
came
up
in
a
recent
commit
from
John.
Previously
we
were
pending
a
like
Dash,
proxy
Waypoint,
proxy
name
for
all
of
our
Waypoint
proxies
and
I
I.
Guess
that
recently
changed
to
be
more
in
line
with
the
Ingress
scope,
but
I
noticed
that
it
kind
of
results
in
some
conflicts.
Specifically,
if
you
deploy
a
Gateway
resource
for,
for
example,
just
using
HTTP
bin,
and
you
name
that
Gateway
resource
HTTP,
then
it
actually
ends
up
trying
to
create
a
deployment.
J
J
The
suffix
on
the
end
personally,
I
I
feel
like
a
lot
of
users,
just
tend
to
name
their
things,
the
same
so
like
if
you
have
a
back-end
service,
HTTP
bin,
and
you
have
a
virtual
service
and
destination
rule
for
that
you
end
up,
naming
those
HTTP
then
too,
so
it
just
kind
of
seems
like
they've
Fallen,
to
the
same
line
of
logic
when
they
try
and
create
a
waypoint
proxy
for
HTTP
bin.
J
But
if
anybody
else
wants
to
win,
there's
some
discussion
there
in
the
issue
already,
but
just
trying
to
get
a
sense
of
what
the
community
would
expect.
The
proper
action
to
be.
A
E
But
but
the
spec
allows,
if
you
have
bought
a
waypoint
and
a
gate
with
the
same
name
or
multiple
Gateway
and
the
waypoints
are
the
same
name.
We
are
allowed
to
concatenate
them
and
to
to
have
a
single
deployment
that
combines
both
or
the
previous
discussion,
where
it's
a
representation.
The
physical
representation
of
of
the
Waypoint
Gateway,
multiple
waveforms,
multiple
name
spaces
can
be
combined,
however,
necessary
am
I
making
sensors
so.
E
C
E
Gateway
class
I
mean,
if
you
have
different
with
Gateway
classes,
then
maybe
you
can
concatenate
the
Gateway
class
with
the
with
the
Gateway
name,
because
if
you
have
the
internal
load,
balancer
and
and
externals,
then
then
you
definitely
cannot
combine
them,
but
within
the
single
class
you
can
combine.
So
so,
if
one
is
mesh,
the
other
glass
is
is
internet
or
whatever
you
use
for
internet
to
use
anything
I,
don't
remember.
E
E
Yeah,
probably
something
without
this
deal
would
be
more
interesting
for
other
Defenders
too.
E
B
Yeah
I,
obviously
what
you
mean
I
mean
in
the
original
examples:
I
have
the
class
internet
I
mean
technically,
the
user
can
name
the
class
whatever
they
want.
That's
just
the
defaults
we
come
out
of
the
box
with
I
feel
like
we
can't
say
that
we're
mesh
by
default
because
or
I
mean
we
certainly
couldn't
say
that
we're
internet
by
default
because
you
could
easily
have
you
know
10
different
anchors
controllers
right,
but
the
user
could
decide.
Okay,
I
will
maybe
use
these
to
go.
Easter
is
called
internet
and.
E
E
Also,
you
can
have
some
classes.
Probably
that
could
be
remember
this.
We
have
a
bug
or
discussion
about
how
to
support
revisions
with
with
Gateway
classes
yeah,
it's
kind
of
the
same
same
issue
about
creating
some
sort
of
Internet
class
which
can
point
to
istio
it's
an
alias,
a
town
or
whatever
you
want
to
call
it
foreign.
B
B
J
B
A
A
I
guess
that's
it
for
today,
thanks
so
much
and
then
we'll
align
the
topics
for
next
week.
The
remainder
of
the
topics.