►
From YouTube: Ambient Mesh WG Meeting 2023 05 03
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
Of
the
agenda,
as
we
have
our
Alpha
for
ambient
coming
out
now,
it
looks
like
May
31st
is
their
new
estimated
launch
date.
We
have
a
few
things
to
resolve
in
terms
of
upgrades
and
migrations.
A
Obviously
we're
hoping
that
users
do
not
migrate
their
production
workloads
to
our
Alpha
release
just
yet,
but
we
do
expect
to
graduate
this
relatively
quickly
if
we're
capable
and
if
we
get
positive
user
feedback
and
I
did
hear
from
some
users
at
kubecon
that,
regardless
of
the
alpha
designation,
they
intend
to
put
this
in
production
as
soon
as
possible.
The
justification
that
they
gave
was
basically
they're
spending
so
much
on
sidecar
CPU
allocation
right
now
that,
even
if
it's
risky
they've
got
to
find
an
alternative
to
bring
their
bill
down.
A
So
the
the
two
topics
that
I
have
listed
are
about
the
order
of
upgrade
and
the
Order
of
migration
think
the
upgrade
one
may
be
a
little
bit
easier.
As
you
all
know,
we've
spent
a
lot
of
time
talking
about
how
waypoints
will
upgrade
in
the
tag
and
revision
apis.
A
What
we
have
spent
less
time
talking
about
is
what
causes
the
Z
tunnel
to
upgrade,
and
does
that
happen?
Should
that
happen
before
the
Waypoint
after
the
Waypoint
or
either
or
do
we
have
a
strong
opinion
there.
B
Which
I
guess
there's
an
interesting
question
about
which
which
of
the
two
pieces
is
more
adoptable
to
change
in
protocol
or
Behavior
right?
We
more
directly
control
the
zetonal
code
and
can
put
things
in
there
to
adapt
to
different
versions
of
envoy,
but
on
the
other
hand,
knowing
what
it's
still
a
complicated
State
management
process.
If
there's
a
compatibility
problem.
C
D
Yeah
I
I,
agree:
I,
think
we
have
more
flexibility
with
Z
tunnel,
so
an
Envoy
for
reference.
I
think
you
probably
know
this,
but
rather
you
have
to
upgrade
the
control
plane
first
and
you
have
to
you
can't
bend
downgrade
the
control
plane
either
you
have
to
downgrade
the
data
plan,
so
we
only
support
an
older
version
of
the
proxy
because
it's
not
in
our
control,
so
we
can't
predict
the
future
as
Eternal
is
in
our
control.
So
we
can
just
make
sure
that
we
don't
break
forward
compatibility.
D
If
we
choose
to
do
that,
so
we
have
a
bit
more
flexibility.
We
may
not
want
to
exercise
that,
for
you
know
maintainability,
but
we
I
think
we
have.
We
could
reasonably
say
that
I
I
generally
agree.
Z10
will
probably
make
sense
to
upgrade
first,
but
I
think
we
probably
also
need
to
plan
out
not
just
what
is
the
recommended
path.
But
what
are
the
supported
paths
for
people
doing
things
like
skip
upgrades
downgrades
rollbacks
that
type
of
thing
a
tape?
Well,
I
mean
we
have
a
lot
of
dependencies
right.
D
We
have
the
control
planes,
Eternal
cni,
waypoints,
sidecars
Ingress.
The
last
three
are
probably
all
the
same,
given
that
they're
all
Envoy
but
they're,
still
different,
like
a
table
of
The
Matrix
of
support,
would
probably
go
a
long
way
in
in
understanding
this,
but
in
general
I
think
we
could
probably
strive
for
at
least
plus
or
minus
one
version
on
Z
tunnel
and
Easter
D.
It's
probably
reasonable.
E
E
So
probably
the
best
approach
is
to
define
the
protocol
that
we
support,
meaning
have
a
clear
documentation
with
testing
for
how
this
is
your
age,
one.
You
know
hdb
to
connect
blah
blah
whatever
headers
yeah
it
should
be.
You
know
we
should
strive
to
maintain
protocol
compatibility
for
as
long
as
possible
and
Define
new
protocols
when
we
want
to
do
to
Revit.
E
I
mean
just
say
that
we
support,
but
I
I
want
to
make
sure
we
don't
repeat
the
mistake
where
we
have
to
upgrade
all
istio
or
components
at
once,
and
they
need
to
have
matching
version
from
the
same,
build
with
the
same
options
and
everything
else.
D
D
Exactly
so,
I
mean
it's
not
forever,
but
15
versions
is
quite
a
long
time
right.
That's,
but
the
control
plane
and
cni
like
that
relationship,
I
think
can
be.
It
can
be
locked
down
a
bit
because
you
can
run
multiple
control
plans
too
right,
yeah.
E
But
you
can
keep
those
old
I
mean
you
can
keep
tunnel
or
whatever
for
cnis,
that
support
h-borne
with
whatever
control
planes
they
have
that
completely
independent
I
mean
the
evolution
of
the
tunnel
and
whatever
control
pain.
It's
using
and
the
rest
are
completely
separate.
You
don't
have
to
use
the
same
control
brain
for
both.
D
A
D
A
D
D
Oh,
that
I
think
so
yeah
sorry
I
was
talking
about
the
control
thing,
but
the
data
plane
we'll
need
to
support
mini
versions
across
I,
don't
know
if
we
like
in
Envoy,
we
never
committed
to
anything
right.
D
E
But
just
a
reminder:
proxy
less
is
independent
of
the
tunnel.
There
is
two
or
three
proxies
variation,
so
we
absolutely
must
have
protocol
stability
and
to
not
sink
in
terms
of
the
tunnel
upgrade.
But
in
terms
of
you
know,
there
is
a
mesh
protocol
and
all
components
should
follow
the
protocol.
D
I
think
on
to
supporting
them
it's
helpful
for
to
allow
either
options,
so
you
can
do
wait
or
rollbacks
and
whatnot.
Obviously,
we
should
have
a
opinionated
way
to
do
it.
In
that
opinion,
I
think
is
upgrades.
Eternals
first
makes
the
most
sense
to
me.
D
Well,
in
general,
I
think
we'll
recommend
them
be
separate,
like
we've
kind
of
moving
away
from
that
one
big
used
to
operator
that
installs
five
things
to
installing
each
one
separately,
right
so
I
think
we'll
recommend
you
install
them
as
two
separate
steps.
D
Yeah
I
mean
you
can't
really
use
Z
tunnel
and
Easter
D.
In
the
same
chart
effectively
I
mean
there
are
literally
different
home
trips,
so
if
you're
using
Helm,
you
can't
possibly
combine
them,
but
if
you're
using
Easter
cuddle,
you
don't
want
to
combine
them
because
Z
tunnels
is
not
revisioned
but
Easter.
Dia
is
right,
so
you
kind
of
need
them
separate.
So
you
can
install
two
ease
duties
and
one
Z
tunnel
that
makes
sense
and.
A
D
E
I
mean
cni
and
Z
tunnel
can
be
combined
and
probably
should
discuss
if
we
want
to
combine
them
or
not
or
what
the
install
process,
because
both
of
them
requires
super
high
permissions
I
mean
host
level,
non-level
dimensions,
okay,.
A
A
No,
that's
what
I'm
saying
they
can't
if
they're
using
waypoints
that
are
on
the
default
revision
and
the
default
revision
also
operates,
which
control
plane
controls
the
Z
tunnel,
then
those
two
pieces
will
move
together
simultaneously.
E
The
way
I
got
working,
what
I
discussed
last
time
about
having
a
Gateway
as
East
God
is
your
system,
oh
nice?
E
F
So
do
we
have
similar
problem
today
with
the
Gateway?
Well,
we
recommend
the
user
to
install
it's
your
D
separately
from
the
Ingress
Gateway
right.
So
during
upgrade
you
can
fully
control
the
sequence
between
the
two.
D
Depends
on
if
you're
doing
the
manual
install
or
the
automated
install
for
a
manual
install
you
manually,
control
it.
Of
course,
if
you're
doing
the
auto
install,
then
it's
the
same
thing
that
Mitch
talked
about
with
the
Waypoint.
Once
you
change
the
default
revision,
then
it
will
start
upgrading.
Any
gateways
pointed
to
the
default
revision
right.
D
Know
yeah,
that's
only
if
you're,
you
know,
if
you're
using
the
default,
the
default
provision
so
yep.
D
That
part,
it's
well
it's
different
today,
so
today
it
only
it
upgrades
when
you
restart
the
containers,
now
we're
going
to
restart
them
for
you
for
the
gateways
yeah.
So
that
part,
we
don't
have
any
signal
on,
because
that
even
for
gateways,
that's
also
going
out
with
1.18.
D
on
the
restarting
I
haven't
really
seen.
People
complain
about
that,
but
I
mean
you
don't
have
to
do
it.
Of
course,
right
you
can
use
a
non-default
version
if
you
want
more
control,
so
yeah.
A
F
A
E
B
B
Right,
so
Z
tunnel
will
always
support
both
right
when
you
upgrade
it.
Envoy
will
likely
only
support
h-bone
for
a
period
of
time.
Right.
That
feature
is
not
on
the
immediate
roadmap
and
Envoy
foreign.
B
E
D
E
Isn't
this
part
of
the
handshake
I
mean
if
it
doesn't
support
human
fallback
wage,
but
not
detector
foreign.
B
B
Yeah
are
there?
Are
there
other
types
of
changes?
We
might
expect
right,
there's
some
discussion
about
less
baggage
and
more
metadata
lookup
out
of
band,
but
that
shouldn't
break
anything
as
long
as
the
metadata
lookup
supersedes
baggage
in
theory
right
if
you're
always
sending
baggage
as
long
as
the
server
receiving
the
baggage
can
get
it
the
information
it
wants
from
the
baggage
or
from
metadata.
Look
at
it's
not
a
problem.
It's
only
a
problem
if
the
client
stops
sending
it
and
the
server
is
not
able
to
look
up
and
meditate.
B
C
E
That
you
brought
this
issue,
do
we
have
any
position
on
on
switching
from
package
to
metadata
lookup.
B
E
But
if
we
have
it
working
with
metadata,
then
maybe
you
know
it's
wasteful
docent
baggage,
I.
Don't
know
we
probably
need
to
do
some
testing
to
see
what
is
the
cost
of
baggage
proxilious
grpc
people
were
very
very
opposed
to
to
this,
but
they're
also
post
metadata,
so
that
doesn't
change
too
much,
but
maybe
we
should
not
have
two
ways
to
do
it.
Do
things
long
term
I
mean
we
should
pick
one
now.
A
So
I
I'm,
going
to
interrupt
this
just
a
bit
in
terms
of
I,
know,
there's
a
lot
of
compatibility
issues
that
we
have
to
talk
about
over
the
coming
year
in
terms
of
upgrades.
Traditionally,
the
default
revision
is
something
we
tell
users
to
move
last.
That's
considered
the
stable
revision
right.
If
you
didn't
select
anything
else
when
opting
into
sdo,
you
get
the
default
revision,
so
the
structure
that
we've
advised
users
have
taken
the
past
is
maybe
you
have
an
alpha
tag
and
a
beta
tag,
and
you
upgrade
each
of
those
tags.
A
First,
you
watch
how
they're
going
they're
the
early
adopters,
the
things
that
can
break
and
then,
after
a
while,
once
the
beta
tag
has
shown
to
not
have
any
problems
with
the
upgrade
you
go
and
move
the
default
revision
as
a
last
step.
A
G
B
A
B
F
E
To
be
clear,
I
mean
it's,
we
still
have
multi-cluster,
so
normal
processes.
You
update
the
canary
cluster,
where
you're
testing
your
workloads,
you
verify
it
works,
it's
not
a
problem,
so
it's
not
like
it
was
before
with
them.
Whoever
it
was
very
tightly
coupled
and
so
I
mean
z
tunnel.
It's
supposed
to
have
a
stable
protocol.
It
should
be
safe
to
to
in
place
upgrade
like
like
cni.
We
are
not
doing
Canada
Imports.
A
John
you
mentioned
that
we're
not
tied
to
the
Z
tunnel,
communicating
with
the
default
revision
of
istiod.
Is
that
something
like
that
is
currently
configuration
based.
You
could
say:
label
your
z-tunnel
and
it
connects
to
a
different
sdod,
or
is
that
just
currently
hard-coded
but
we'd
be
open
to
changing
that.
D
No
I
think
it's
reading
the
same
proxy
config
that
we
read
for
onoys,
which
has
a
discovery
address,
so
you
can
I
assume
we.
We
probably
only
study
studio.co
system
today,
okay
I
think
you
could
probably
set
it
in
the
health
chart.
If
you
know
what
you're
doing
yeah
okay
so.
A
I
I
think
the
outcome
here
that
I'm
hearing
is
for
my
initial
pass
of
our
CI
CD
reference
architecture.
I'll,
follow
the
steps
that
I've
listed
in
the
notes.
Here
install
the
new
control
plane
migrate,
your
tags,
one
by
one
to
the
new
revision
migrate.
The
default
revision
to
the
new
control
plane
then
install
the
new
Z
tunnel
and
turn
down
the
old
control
plane
that
that
can
act
as
a
first
pass,
we'll
get
some
feedback
from
users
and
and
see.
If
there's
anything,
that's
not
really
lining
up
well
for
them.
E
I
heard
that
pretty
weird
I
think
the
only
safe
way
to
upgrade
cni
and
the
tunnel
is
to
court
on
it
at
this
point.
If
anyone
believes
that
it's
you
can
do
it
safely
without
coordinates
and
loads
and
doing
the
same
thing
you
do
when
you
upgrades
at
kernel
and
the
rest
of
the
node,
so
I
would
treat
cni.
E
A
A
There's
also
I've
heard
a
few
other
ideas
like
the
ability
to
Canary
a
z-tunnel.
All
of
those
are
interesting.
The
this
reference
architecture
is
very
much
scoped
to
the
alpha
release
designed
to
get
feedback
from
users
to
give
them
sort
of
a
template
to
follow
as
they
try
out,
but
I'm
very
much
open
to
exploring
ways.
You
know
we've
invested
most
of
our
time.
Most
of
our
discussions
have
been
on
the
Waypoint
because
we
believe
that's
the
riskier
upgrade
of
the
two
over
the
coming
three
months.
A
We
should
invest
more
time
on
the
Z
tunnel
side
to
understand
what
the
impact
is
to
traffic
to
evaluate
coordinating
options.
Canary
options
before
we
go
to
Beta
I
would
like
to
have
a
better
idea
of
the
impact
of
upgrading,
a
z
tunnel
on
users
and
any
mitigation
steps
that
they
can
take.
E
E
B
A
B
B
E
A
E
More
about,
if
we
have
control
or
not
I
mean
that's
my
concern
we,
but
the
ideal
situation
if
Ctrl
is
successful,
is
that
will
not
have
any
control,
because
the
platform
vendor
will
include
somehow
zitar
function
right
into
the
data
plates?
So
first
last
it's
out
of
your
control.
It's
whoever
you
know
vendor
is
upgrading
the
cni
and
data
planes.
They
will
include
whatever
version
of
guitars
they
tested
with
which
maybe
not
even
something
else.
B
A
I
think
I
am
in
favor
of
separating
the
life
cycle
of
the
other
istio
components
from
the
life
cycle
of
the
Z
tunnel.
I
I
would
say.
However,
we
need
a
detailed
proposal
on
that
and
probably
full
Toc
review
like
that,
should
not
be
something
we
go
or
proceed
with
without
a
lot
of
careful
consideration.
B
Yeah
I
think
for
the
moment
we
probably
have
to
keep
them
coupled
because
we
we
would
have
to
introduce
a
whole
new
revision
scheme
right,
like
the
Z
tunnel
revision
and
the
Waypoint
revisions
right
and
also
this
has
to
coexist
with
regular
old,
sidecars
right,
which
would
normally
have
a
third
revision.
So
for
the
moment,
it's
probably
best
to
just
have
one
and
hope
it
doesn't
fall
over.
B
F
So
what
is
our
order
again
because
I
guess
I
I,
think
it
upgrades
Eternal
before
control
plane
is
honestly
very
confusing
because
so
I'm
trying
to
understand
what
advantage
does
it
provide?
The
main
reason
is,
for
the
longest
time
we've
been
educated
to
you,
so
you
have
to
update
your
control
plane.
First,
then,
your
data
plan,
so
we
always
kind
of
would
tell
user
that.
So,
if
you
think
about
zetano
as
part
of
your
data
plan,
you
wouldn't
think
it
would
update
update
after
the
control
plane.
A
I
think
what
we're
saying
is
from
a
technological
perspective.
The
Z
tunnel
can
upgrade
at
any
point
in
the
process.
It
can
be
step
one.
It
can
be
the
last
step
it
can
fall
somewhere
in
the
middle.
We
have
broad
compatibility,
obviously
for
the
sake
of
the
CI
CD
reference
implementation
and
it
has
to
fall
somewhere
right.
B
Yeah
so
I
guess
there's
a
fair
question
here,
which
is
we
obviously
want
it
to
be
independent
in
the
long
run,
but
in
the
medium
to
short
term,
what
is
going
to
yield
the
most
stable
experience
per
user?
It's,
like
that's
the
least
disruptive,
so
we
get
feedback
so
there's
a
control
plane
first
or
data
plane.
First
right
if
you've
been
telling
users
to
do
control
plane
first
forever
and
control.
Pane
first
allows
us
to
patch
for
any
XDS
configuration
API
issues
that
we
have
may
have
committed
in
the
previous
release.
A
A
B
E
Yeah
I
don't
know,
but
we
need
to
design
for
what
is
the
end.
State
we
want
to
be
in
I
mean
Alpha,
doesn't
really
matter,
I
have
an
extreme
solution
for
you.
How
about
I
mean
I,
don't
know
if
it's
extreme
how
about
when
you
install
the
tunnel.
E
It
also
installed
a
small
ecod
with
everything
turned
off
and
just
Waypoint
and
which
is
specifically,
you
know
tuned
for
Z
tunnels
and
nothing
else,
all
the
other
feature
off
and
then
it's
absolutely
completely
independent,
because
Z
tunnel
will
have
its
own
stod
will
do
its
own
stuff
and
we
can
completely
decouple
the
recycle
and
upgrade
and
everything
else
since,
if
you
turn
off
all
the
features
and
all
the
other
things
and
you
dedicate-
and
it's
really
only
4G
tunnels,
you
know
we
could
use
almost
zero
CPUs
and
not
be
affected
by
whatever
waypoints
are
doing
yeah.
B
I
think
that
has
to
be
part
of
that
bigger
design
right
for
the
independent
upgrade
right.
It's
probably
a
bit
much
to
chew
that
all
for
Alpha.
At
this
point,
I
I
get
what
you're
saying
like
I
mean.
Logically,
they
have
two
independent
control
planes.
So
why
not
just
make
that
the
case
yeah
I
just
think
we
need
a
bit
more
time
to
work
through
that.
E
E
A
Okay,
that's
helpful
input.
I.
Think
that
gives
me
what
I
need
to
build
the
reference
architecture
and
I
will
share
that
with
you
all
once
it
is
in
a
good
state.
A
The
second
question,
I
had
unfortunately
I
think,
is
the
more
complex
of
the
two
I'll
try
to
wrap
the
conversation
up
fairly
quickly,
because
I
know
we
have
other
people
with
agenda
items
when
migrating
to
ambient
from
sidecar
mode.
A
F
Yeah
and
my
understanding
is
the
istioci
that
sets
of
the
traffic
redirection
should
check
if
it's
psycha
exists,
ish
or
if
the
psychi
injection
label
exists,
it
should
not
set
up
the
redirection,
so
we
wouldn't
need
to
be
captured
by
zetano.
F
F
A
F
D
A
D
Games
so
in
gamma,
there's
no
gateways
actually.
D
A
D
Not
an
issue
yeah.
F
The
key
point
I
want
to
make
to
wrap
this
up
image
is
the
assumption
is
as
if
you
were
a
user.
You
shouldn't
need
to
change
your
HTTP
route
or
virtual
service
or
destination
rule
that
should
continue
to
work.
The
only
thing
you
need
to
worry
about
is
from
that
cycle
to
deploy
the
Waypoint.
I
Oh
yeah,
so
I
actually
put
a
design
document
there.
So
let
me
try
to
share.
I
Yeah,
so
basically,
this
is
some
follow-up
actions
we
want
to
take.
After
our
the
ebpf
redirection
work
has
been
merged.
So
for
now
the
ebb
redirection
can
work
well
with
kindness
and
Calico.
So
there
are
some.
You
know
worker
some
steps
you
need
to
take,
especially
for
the
RTF
side.
You
either
to
disable
this
thing.
The
Calico
will
work
so
now
we
want
to
make
sure
the
psyllium
part
can
work
well
with
the
EPF
part.
So
this
is
basically
some
summarize
summarize
here.
I
I
If
this
is
correct
right
right,
yep,
okay,
so
let
me
continue
so
this
three
big
issues
and
we
have
a
solution
for
for
each
of
them,
so
the
first
one
we
can
rely
on
some.
You
know
BPF
priority
field
order
here,
so
the
CDM
also
has
this
option.
So
it
means
when
you
install
psyllium,
you
can
put
their
TC
evpm
program
after
our
redirection
TC
program.
The
other
part
is,
we
need
to
rely
on
the
celium
client
API
to
get
related
interface
information.
So
these
are
two
pre
requirements.
I
One
is
you
need
to.
We
need
to
import
import,
the
psyllium
client
API
in
our
htl
source
code,
the
other
one
is
to
Grant
access
to
this
one
and
the
added
the
third
part
is
into
disable
the
sort,
IP
verification
for
the
Italian
part.
So
this
also
is
a
psyllium
option
here,
but
this
option
will
only
be
available
the
ball
in
the
upcoming
psyllium
release,
so
it
means
this
solution
will
if
we
will
go
in
this
way.
The
whole
solution
will
only
work
after
psyllium
1.14,
because
this
option
is
only
available.
I
You
know
in
this
release,
so
I
already
got
some
comments
from
Belgium
and
and
eaten.
So
thanks
a
lot
for
the
comments.
So
one
big
thing
we
are
in
question
now
is
actually
this
part
so
how
we
package
all
these
things
together.
Do
we
want
to
you
know,
employ
import
all
the
psyllium
client
API
in
the
Easter
search
code
directly
or
any
suggestions
here
and
for
this
go.
C
I
C
I
Yeah
so
before
that
I
will
prefer
to
see
the
the
technical
Direction,
especially
for
the
for
the
for
the
first
part.
For
this
part,
do
we
want
to
put
it
directly
into
istio,
Ci
or
I
mean,
let's
mentioned
a
separate
model
in
it?
Still
then,
because
if
we
put
all
the
dependency
in
the
in
the
Easter
sea
I,
we
also
need
to
detect
the
underlying
CI.
If
it
is
psyllium,
then
we
enable
you
know
specific
code
to
do
the
related
thing.
I
If
it
is
not,
we
will
follow
the
original
code
path,
so
it
is
acceptable
or
not.
You
prefer,
you
know,
a
separate
module.
This
is
the
the
big
question
we
want
to
ask.
G
Well,
I
think
that
as
you've
always
saying
the
question,
the
answer
that
question
relies
on
the
implementation
right,
like
I,
think
I
think
we
need
to
better
understand
the
actual
abpf
implementation
here
before
we
decide
on
same
module,
different
modules,
cni
I.
Think
that,
like
you
know,
we
have
some
psyllium
and
evpf
expertise
on
our
side
and
would
just
like
to
see
what
the
like
the
the
exact
design
in
terms
of
like
just
to
answer.
I
B
Very
specifically,
Iris
I
think
you
know
this
solution
requires
the
integration
of
the
psyllium
client
right
yeah.
If
there
was
a
solution
that
didn't
require
the
integration
of
the
psyllium
clients,
it
would
probably
change
the
answer
to
your
first
question
or
might
change
the
answer
to
your
first
question.
I
F
E
I
think
in
history,
if
you
look
at
the
code,
you'll
find
that
we
have
code
specific
to
gcp.
We
have
code
specific
to
other
platforms.
I,
don't
think
it's
it's.
It
was
ever
a
policy
that
if
a
code
is
licensed
Apache,
you
cannot
use
it.
You
know
within
reasonable.
You
know
dependencies
and
other
things.
So
I,
don't
think
anyone
would
say
it's
impossible
or
is
not
allowed
to
use.
H
Maybe
you
just
write
your
own
cni
extension
for
istio
right
so
I
think
if
the
changes
are
severe
or
serious
or
large,
as
they
would
I
think
end
up
being
here,
not
just
integrating
the
ceiling
client,
but
also
like
fundamentally
probably
having
a
different
flow
for
how
redirection
is
configured.
It
makes
sense
to
do
that
separately
from
the
actual
cni
piece
itself
that
we've
already
got
I.
Don't
really
want
to
cram
more
branching
logic
into
our
cni
component,
because
it
is
already
something
of
a
mess
but
yeah.
E
I
read
some
medicine
probably
need
some
cleanup.
There
is
conditional
compilation
we
can
build.
You
know
we
still
CNN
serious.
Whatever
we
have
options
to
you
know.
If
we
want
to
keep
the
battery
size
smaller,
you
want
to
keep
dependency
smaller,
but
in
the
end,
so
this
interception
should
probably
be
eventually
part
of
the
cni
itself
and
we
should
try
to
get
it
Upstream
in
kubernetes
as
a
requirement
having
apis
that
they
direct
stuff
to
a
particular
port
and
Port,
so
that
all
mesh
implementation
can.
E
F
B
D
Yeah
I
think
we
may
be
going
down
the
wrong
path
of
it
like
in
the
current
implementations,
we're
kind
of
building
on
top
of
democracy
and
eyes
that
don't
do
much,
and
so
just
hijacking
everything
from
them
and
bypassing
them
is
perfectly
fine,
because
we
replace
all
their
functionality
yeah,
but
I'm.
D
Not
sure
that
same
pattern
is
what
is
expected
for
people
that
run
things
like
psyllium
I
think
that
both
the
psyllium
team
is
open
to,
and
it
would
lead
to
a
better
outcome
if
we
actually
integrate
more
closely
with
psyllium,
rather
than
just
trying
to
inject
our
programs
before
theirs
and
win
the
race,
because
there's
a
lot
of
functionality
that
psyllium
does
that
we
don't
do
or
intend
to
do
right
like
they
have
tons
of
network
policy.
D
G
Might
accomplish
right,
I
think
I.
Think
the
problem
here
is
that,
because
we
haven't
seen
it,
we
don't
know
if
it
even
accomplishes
that
I
agree
John
100
with
your
takeaway,
but
according
to
Iris
that
that
that
is
okay,
so
I
think
we
need
to
figure
out
if
the
like
I
think
the
important
part
of
this
proposal
is:
does
it
fulfill
those
requirements,
not
necessarily
the
the
client
Library.
D
G
What
I
would
think
as
well,
but
I
would
like
to
have
I
mean
I'm
I'm
open
to
the
to
the
design
if
it
does
work,
because
Iris
mentioned
that
there's
a
working
POC,
so
I
I
think
it's
important.
That's
why
I'm
saying
I
think
it's
important
for
us
to
see
what's
happening
here
and
then
make
a
decision
about.
I
So,
basically
for
women,
we
summarize
the
three
bigger
issues
when
we
integrate
with
the
cilium,
because
it's
also
ebpf
based
a
solution,
so
the
the
big
one
I
mean
the
first
ones,
the
EPPI
program
or
the
problem.
So
for
this,
when
we
we
will
want
to
utilize
the
psyllium
option
here,
but
this
is
the
big
thing:
I
think
the
gym
or
eaten
they
have
concern
with,
because
they
are
not
sure
whether
this
can
really
work
or
Not
So.
I
Based
on
that
they
want
to
see
a
demo
or
something
like
this
I
think
for
our
part,
we
can,
you
know,
add
more
details
for
this
part,
and
maybe
some
you
know
demo
or
prototype
to
prove
that
this
solution
can
work.
I
think
this
is
the
major
concern
from
from
Eaton
or
Belgium
am
I
correct.
I
B
Is
yeah
so
I
think
like
whether
or
not
the
cni
includes
the
the
psyllium
client
library
is
probably
a
secondary
concern
right.
So
it
sounds
like
there
are
three
options:
three
things
to
evaluate
right:
one:
does
the
proposal
like
the
technical
proposal
work,
regardless
of
how
it's
incorporated
into
cni
two?
I
So,
for
the
second
one
second
thing
to
to
know
you
know:
negotiation
or
collaboration
with
the
psyllium
community.
What's
the
better
approach
here.
I
B
I
A
F
Yep
yeah,
so
eight
and
you
are-
our
team-
is
also
looking
at
this
area.
Just
so
you
know
so
we're
also
interested
in
doing.
G
G
We
should
take
this
because
this
is
kind
of
very
specific.
So
maybe
we
should
you
know
if
we're
interested
in
the
devil
in
these
details
here,
maybe
we
should
schedule
something
specifically
to
chat
about
this,
because
this
might
this
might
take
quite
a
while,
but
yeah
I
think
I.
Think
it's
an
interesting
conversation.
E
D
C
E
Because
we
also
have
you
know,
side
cuts
we
also
have,
but
zitana
is
not
the
only
ones
that
intercept
some
stuff.
I
mean
I
know
there
is
an
API
already
in
Syrian
to
redirect
the
port
to
a
blood.
So
it's
not
really
it's
just
an
extension
of
the
API
is
already
exposed.
I
I
actually
did
MCRD,
like
called
notary
there,
something
like
this
but
yeah,
but
it
seems
it's
not
very
user
friendly,
especially
if
we
want
to
do
things,
because
if
you
want
to
utilize
this,
you
need
to
config
a
one
part
by
one
part.
What
I
mean
one
by
one
is
you
know
October
serum,
no.
E
C
B
E
B
C
B
I
E
I
Yeah,
but,
based
on
today's
discussion,
seems
we
want
to
approach
another
way.
Like
you
know,
collaborate
with
psyllium
directly,
since
John
has
some
collaboration
in
the
Google
side,
so
join
where
you
initiated
the
discussion,
and
if
this
is
the
case,
we
can
pause
our
current
work
to
see.
You
know
how
that
direction
goes.
Is
this
reasonable
John.
D
Yeah
sorry
you're
just
like
one
week
ahead
of
where
we
were
so
we're
planned
to
talk
with
them.
Foreign.
F
Do
you
think
it
is
a
beneficial
for
us
to
evaluate
your
approach
to
so
I
think
multiple
people
have
asked
if
it's
okay
like
if
it's
open,
source,
ready
or
just
for
people
as
a
poc
in
a
branch
I
think
we
would
love
to
see
it
to
see
if
this
approach
could
potentially
be
better
yeah.
F
B
B
B
When
you
have
a
mesh
versus
just
the
cni,
but
Z
tunnel
on
its
own
shouldn't,
interfere
with
that
all
right,
because
Z
tonal
is
just
pure
L4,
L3
L4,
so
I
think
the
expectation
would
be
that
Network
policy
would
continue
to
work
if
there
was
no
Waypoint
in
place.
I
I
B
E
I
G
B
I
We
may
need
you
know.
Action
to
you
know
summarize.
Current
Network
policy
support
in
ambient
I
think
there
are
a
big
hole
here.