►
From YouTube: Istio networking WG meeting - 2018-11-08
Description
- Traffic Governance UX Survey short announcement
- Network scoping theme
- Network scoping and policy attachment
- Clarify the scope of Istio Networking APIs : namespace or cluster-wide
A
Alright,
hello,
everybody
welcome
to
this
your
networking
community
meeting.
We
will
dedicate
this
meeting
to
Network
scoping
team
in
general,
so
we
have
a
proposal
to
review
and
there
are
a
few
issues
that
are
in
this
area.
Okay,
but
before
we
start,
I
would
like
to
make
a
short
announcement.
In
case
people
missed
the
emails
I
sent
about
the
traffic
governance
survey,
so
there
is
a
form
of
in
which
were
kindly
ask
you
to
review
a
short
example
of
configuration
for
traffic
government
governance.
A
So
there
are
two
proposals
and
we
would
like
to
know
your
opinion.
So
if
you
could,
please
spend
five
minutes
or
more
to
read
it
and
understanding
and
indicate
your
preference.
It
would
be
great,
so
I
will
probably
review
the
results
in
the
next
networking
meeting
that's
in
about
two
weeks,
but
it
would
be
great
if
you
could,
if
you
could
answer
by
the
end
of
next
week.
Okay,
thank
you,
alright
and
also
I,
think
Rafael,
I'm,
not
sure.
A
If
you
already
joined
you
added
a
last-minute
item
about
a
demo,
Easter
multi
cluster
on
open
shifts
and
I'm,
not
entirely
sure,
we
will
have
time
to
cover
it
and
I
also
think
this
is
better
suited
for
the
network.
The
environment
meeting
so
I
wonder
if
it's
okay
to
to
do
your
demo.
Next
wicked
environment,
environment,
meeting
I.
C
A
A
E
B
While
we
are
covering
here
some
of
the
motivations
behind
this,
we
poke
the
eye
capture
from
the
top,
but
it's
probably
worth
discussing
generally
and
also
some
aspects
of
the
general
direction
that
this
dog
is
taking
the
fourth.
So
we
have.
We
have
a
big
problem
today,
right
with
big
meshes
that
because
we
don't
understand,
scoping
or
contextual
usage
right,
we
have
to
deliver
the
configuration
for
every
service
that
is
within
the
mesh
every
envoy
in
the
mesh
right.
B
So
we
end
up
with
this
big
end:
squared
configuration,
delivery
problem
and
we've,
you
know,
Hubble
the
long
getting
sto
to
work
in
that
mode
with
you
know
up
to
about
3,000
services,
but
it's
painful
and
it's
all
slow.
It's
a
real
problem
with
no
startup
time.
It's
a
real
problem
with
system
reliability
and
we
need
to
be
there
and
we
have
feedback
from
a
number
of
a
doctor
saying
that
they're
more
than
happy
to
declare
what
the
dependencies
of
a
given
workload
are
right.
B
That
usually
means
either
a
pod
or
a
deployment
or
a
namespace,
they're
willing
to
say
level
of
granularity
walk
services
in
the
network
of
the
bacons.
You,
and
so
we
have
a
feature
in
here
called
egress,
which
is
basically
a
way
for
a
namespace
owner
to
say
here:
are
these
set
of
services
that
I'm
going
to
take
a
dependency
on,
and
this
in
filter
logic
allows
you
to
be
either
fairly
loose
about?
How
you
make
that
specification
or
very
precise?
B
So
we
could
support
grant
on
denied
right
now
we
can
debate
the
general
structure.
The
API
and
I
had
some
additional
feedback
in
the
doc,
maybe
from
spike
about
whether
these
two
things
belong
on
the
same
resource
or
not.
The
only
reason
I
put
them
in
the
same
resource
is
it's
somewhat
structurally
mirrors,
what's
available
today
in
kubernetes
network
policy
right
it
has
an
ingress
and
egress
definition
for
a
workload
binding.
B
Now
the
egress
rules
today
right
because
of
some
of
our
existing
implementation
issues
can't
really
be
considered
and
the
egress
firewall
from
a
strong
persecuted
perspective,
not
because
of
any
conceptual
limitation,
but
because
of
implementation
limitations.
We
have
today
we're
not
willing
to
make
that
as
a
strong
assertion,
but
over
time
it
could
become
that
and
probably
make
sense
for
it
to
become
that
right.
F
Which
will
provide
census
scene
is
okay
and
then
can
I
post
that
to
making
that
more
or
viable.
Today,
I
mean
we
discuss
in
the
past
how
we
can
enforce
ignorance
by
using
that
policy
network
elysium
uses
a
grass
gateway.
So
technically
it
is
difficult,
but
it
is
already
kind
of
possible
to
enforce.
Yes.
B
I
was
quite
careful
not
to
duplicate
the
functionality
from
communities
that
were
policy
arrest
rules
right.
So
this
is
a
intended
to
be
a
kind
of
layer,
7
declaration,
it's
a
higher
level
representation,
so
you
could
have
both
at
the
same
time
and
both
to
be
in
effect
right.
You
could
have
this
to
you
in
calico,
running
s2
and
psyllium
running
or
st
on
some
other
c,
and
I
based
implementation
of
Cabrini's
negra
policy,
and
you
know
they'll,
probably
be
some
discussion
in
the
long
run
about
when
you
need
one.
B
The
other
piece
of
the
other
thing
that
we
do
in
here,
and
so
I
show
some
examples,
syntax
and
I
don't
claim
that
the
ingress
syntax
here
is
finalized.
So
we
could
just
debate
the
structure.
The
other
thing
that
we
do
is
we
declare
a
kind
of
scoping
constraint
on
the
declarations
that
we
have
in
our
own
API
is
that
effect,
basically,
whether
services
are
visible
only
within
a
namespace
within
which
they're
declared
or
whether
they're
available
to
be
referenced
by
another
namespace.
B
B
This
has
the
general
effect
of
making
namespaces
more
independent
right.
In
theory,
I
can
declare
the
same
service
in
two
distinct
namespaces,
the
both
private.
They
would
never
know
about
each
other
right,
so
they
can
more
independently
operate
while
independently
claiming
the
same
part
of
the
network.
Namespace
I
can
declare
the
same
host.
F
B
Now
only
the
things
that
are
contractual
between
namespaces,
essentially
when
namespace
a
exposes
a
service
to
another
namespace,
you
know,
are
a
more
global
set
of
constraints.
To
do
a
more
global
set
of
constraints
need
to
be
applied.
This
is
likely
to
prove
useful
for
modeling
egress
right.
You
know,
and
I
gave
an
example
in
the
bottom
of
the
document,
and
so
this
is
scoping.
B
Obviously,
this
making
namespaces
more
independence
right
has
some
bearing
on
whether
namespaces
our
tendency
units
or
not
right
now
might
be
relevant
to
some
people.
Right
I
think
the
folks
had
some
right,
the
utility
around
namespaces
being
independent
units
of
administration.
This
would
facilitate
that
there's
still
a
the
ability
for
a
top-level
admin
control.
There's
a
note
here
about
how
we
kind
of
cluster,
why
or
mesh
why
the
administrator
would
impose
two
foals
with
constraints
in
this
system
which
we
can
get
into
the
details
of
so
hopefully
that
does
a
reasonable
job
of
summarizing.
B
What's
going
on
one
of
the
motivations
and
one
of
the
key
long-term
impacts
of
this
type
of
change,
so
at
this
point,
I
should
probably
just
open
up
to
questions,
and
rather
than
going
through
the
types
of
questions
and
the
doc.
Maybe
we
just
kind
of
repeat
them
here,
as
people
want
to
bring
them
up.
How.
B
H
B
Have
kind
of
two
idioms
right
for
multi
cluster
ISTE,
oh
right,
one
is
that
the
mash
is
global
right
I,
all
the
namespaces
are
the
same
namespace,
no
matter
where
they
Rock
right.
So
if
you
have
namespace
and
cluster
a
namespace
in
custardy,
they
are
the
same
thing
from
at
least
from
Ana
security
and
administrative
point
of
view,
and.
B
F
I
D
A
H
H
F
B
G
F
B
Because
this
is
configuration
right,
it
belongs
to
administrative
domain
yeah,
so
I
have
to
be
very
careful
about
that
now
could
could
be
have
other
items,
yes,
I,
don't
know,
I'd
like
to
see
a
stronger
justification
for
adding
any.
You
know
the
the
one
that
was
discussed
was
you
know,
because
public
basically
means
export
this
service
outside
my
namespace,
so
someone
else
can
consume
it.
You
could,
in
theory,
put
a
constraint
on
that
export
to
say
who
Eurex
a
lot
of
things
for
to
or
who
you
want
to
export
to.
F
B
D
C
King
cobra
doesn't
like
a
shared
base.
Class
and
imports
from
I
mean,
like
everything
that
he
put
in
there
will
get
inherited
to
everybody
else,
and
then,
on
top
of
that,
you
add
things
that
are
specific
to
the
namespace.
So,
for
example,
everything
depends
on
history
of
I,
mean
the
history
of
tell
em
I'm
trained
in
history
of
policy
service
to
talk
to,
and
also
they
probably
also
depend
on,
Prometheus
and
so
on.
F
B
Goal
of
any
any
default
configuration
namespace
right,
one
that
the
admin
says.
This
is
the
global
set
of
defaults
right.
It
has
to
merge
per
standard,
merge
semantics
with
the
resources
that
are
scoped
at
the
namespace
level
and
in
the
case
of
something
like
egress
right,
it
would
be
a
union
and
you
couldn't
remove
them
in
the
case
of
ingress.
If
you
know
what
it
weighs.
B
Yes,
you
can
urge
much
like
and
in
the
case
of
ingress,
it's
because
it's
an
order
of
execution,
its
concatenation
right,
which
means
the
global
one
takes
precedence.
Now
it
seems
reasonable
as
a
general
pattern.
You
have
to
kind
of
go
through
in
a
domain
by
domain
phases
to
see
if
that
pattern
holds
across
all
of
the
API
resources
that
we
have
right.
E
F
G
F
B
F
D
J
B
A
K
B
F
F
F
A
A
B
B
L
B
L
So
this
would
be
like,
if
I'm
administrator
for
a
group
of
developers
who
may
be
in
charge
of
for
many
services-
let's
say
50
services
I
may
have
50
team
to
develop
these
services,
so
I
can
apply
a
global
policy
that
I
would
be
able
to
say
these
are
the
things
I
want
to
set
aside
for
my
team
and
needs
other
flexibilities.
I
can
allow
them,
and
then
these
are
the
things
I.
Definitely
don't
expect
them
to
access.
L
K
B
F
B
So
there's
there's
a
variety
of
situations
right,
so
one
I
want
to
make
sure
that
this
is
very
clearly
separated
from
admission
control.
You
can
always
use
it:
Mission
Control,
to
constrain
a
namespace
owner
from
performing
a
bunch
of
actions,
and
we
have
a
separate
proposal
right
about
using
policy
documents
that
constrains
the
ability
of
a
namespace
owner
to
declare
certain
Network
names
right.
So
you
can
use
that
to
constrain
now.
There's
there's
some
debate
about
how
much
utility
that
provides
and.
F
B
Only
the
issue
we
have
today
that
this
doesn't
solve
is
while
it
constrains
the
ability
of
a
namespace
owner
to
write
an
artifact
that
impacts
another
namespace
corner.
It
doesn't
constrain
the
ability,
the
namespace
owner
to
a
webinar,
in
fact
that
have
impacts
themselves
right.
That's
the
distinction
between
the
two
things
right.
So,
if
I,
what.
B
C
B
So
that's
what's
the
crux
like
think
that
the
canonical
use
case
we
have
here
is
ingress
right,
so
you
have
some
some
admin
who
owns
the
physical
ingress
gateways
they
own
the
proxy
and
they
own
the
hostname.
That's
a
apple.com
right
and
then
they
they
want
to
say
I,
want
of
our
namespaces
to
be
able
to
define
pieces
of
Apple
comm
product.
L
B
The
other
way
is
to
say,
look
I,
the
owner
of
the
Gateway
I'm
only
going
to
import
apple.com
definitions
from
five
of
the
five
thousand
namespaces
in
the
mesh
right,
because
I
will
take
those
service
entries
that
are
declared
public
from
those
five
namespaces
out,
perform
virtual
service,
merge
on
them
and
those
are
the
ones
I'll
load.
Okay,
so
I
can
prevent
another
namespace
from
declaring
something
in
a
calm
and
impacting
the
gateway
all
right.
So
it's
it's
managing
the
authority
by
namespace
reference,
as
opposed
to
by
partitioning
the
network.
Namespace.
B
C
And
because
then,
like
it
mean,
if
this
model
constraints,
you
do
say
you
hit
a
namespace
owner,
can
define
something
X
or
Y,
but
and
I
don't
see
a
way
by
which
this
model
is
telling
you
this
namespace
one
I
can
declare
X
or
Y
as
and
exported
service,
which
active
can
be
imported
by
somebody
else.
Now,
as
we
need
something
to
constrain
the
imports.
That's
where
our?
If
we
can
that
the
traffic
ownership
thing
comes
in
right,
you.
B
B
No
I'm
talking
about
the
public
one
right.
There
are
three
namespaces
and
that
one
owns
apple.com,
slash
sales,
one
owned,
slash,
store
or
one
own
slash.
I,
don't
know
support
right
if
I
trust
those
namespaces
to
never
deviate
from
the
piece
that
they
own,
then
I'm.
Fine
right,
I'll
only
import
those,
so
I
can't
have
an
a
rogue
namespace
inject
stuff
into
the
gateway
that
I
own
are.
M
F
B
L
B
Global,
so
that's
already
problematic
right,
so
this
is
strictly
better
than
that,
because
at
least
I
can
control
who
I'm
willing
to
trust
right
all
right,
I'm,
cuz
namespaces
are
trust,
domains
right.
They
have
owners
and
admins
right.
They
have
identities,
so
I
am
delegating
to
them
when
I'm
not
delegate
I'm,
not
being
very
precise
about
the
subdivision
of
the
network
namespace
and
delegating
to
them
that.
F
F
C
C
L
B
A
F
F
Yes,
yes,
once
more
once
more
comment
here,
so
if
apple.com
really
is
owned
by
this
right
tonight,
you
have
an
IP
address
and
a
certificate
which
ever
may
space
around
the
gateway
with
that
IP
address
and
certificate
is
a
only
real
owner
of
apple.com
and
with
these
methods
they
can
delegate
where
exactly
stuff
goes,
but
ultimately
is
a
certificate
right
here.
This
mapping
that
defines
the
LS
level
at
least
yes,.
D
D
B
B
Mostly,
you
get
fired
for
getting
your
ingress
wrong
right
because
you
haven't
locked
down
the
services
that
you're
responsible
for
Gateway
is
an
interesting
sight
one
here
in
the
long
run,
though
right
I
mean
as
long
as
we
have
network
control,
and
those
are
the
only
things
that
are
like
basically
endpoints
that
are
reachable
by
the
network.
It
does
act
like
if
our
wall,
in
the
sense
that
it
prevents
you
from
talking
to
anything
else,
the
terminology
might
feel
a
little
different,
but
it
effectively
will
act
like
that
for
a
time.
C
And
so
the
point
being
that
like,
if
we
act,
let
expand
the
scope
of
the
system.
There
is
something
like
there.
You
can
use
HTTP
proxy
or
the
connect
proxy
and
so
on.
Where
you
explicitly
talk
to
the
proxy
in
order
to
talk
to
the
external
world,
then
it
actually
becomes
more
of
a
proxy
miscibility
thing
and
not
more
of
a
firewall
thing,
because
they
are
that
in
that
case,
I
can
choose
to
talk
to
somebody
directly.
C
B
C
D
Because,
what's
going
on,
is
that
you're
not
just
importing
or
you're,
not
not
just
saying
yeah
I'm,
allowing
workloads
to
make
a
connection
to
this
host
you're?
Also
saying
I'm,
gonna
import,
all
virtual
services
and
all
routing
rules
that
are
hung
on
to
that
hostname.
So,
what's
going
on
here
is
not
it's
like
basically
telling
users,
this
is
a
firewall
I
think
is
gonna,
lead
them
down
the
wrong
path
of
understanding,
because
what
we're
saying
is
it's
more
yeah,
it's
more
like,
like
an
import
statement
at
the
top
of
your
program.
G
D
I
think
we
should
split
up
the
ingress
anyway.
I
think
it's
a
bad
idea
to
have.
This
are
back
next
to
the
egress,
because
they're
making
very
different
promises
from
a
security
perspective,
and
they
don't
they
don't
like.
They
have
really
different
rules
about
how
you
would
merge
them,
and
it
also
means
that
you
can't
sort
of
split
off
access
control
as
a
different
module
than
than
this
kind
of
service
visibility.
Stuff.
So
like
calico,.
B
There
is
no
difference,
logically
layer,
7
between
IP,
accessibility
and
path,
based
routing
right.
All
that
you're
doing
is
declaring
control
over
a
more
fine-grained
definition
of
the
network.
There's
no
logical
distinction
there
now
I.
My
spikes
argument
about
look
the
the
egress
stuff
has
slightly
different
or
software
semantics
in
certain
scenarios,
and
so
the
administration
requirements
over
them
may
be
different
than
number.
The
ingress
stuff
right.
I
buy
that
as
an
argument
for
separation.
D
B
B
I'm,
like
I'm
fine,
going
either
way.
The
only
other
thing
I
would
point
out
is
the
unit
of
edit
is
probably
the
same.
The
owner,
the
person
who
would
create
this
resource
is
probably
the
same
person
or,
if
you
split
into
two
that
was
great
both
it's
not
necessarily
that
bad,
but
we
have
had
feedback
about
how
often
we
make
people
create
two
resources
when
they
could
create
one.
G
A
Logically
necessary,
for
instance,
right
now,
the
destination
rule
has
too
many
logical
concepts
in
it,
and
it's
problematic
I,
just
like
I,
know
discussion
this
morning
with
Shri
Ram.
So
we
should
really
like
not
worry
about
how
many
resources
they
are,
but
whether
it
makes
sense
or
not,
we
to
have
them
separate.
A
B
C
It
would
actually
be
things
like
in
even
if
I
use
a
simple
he
talks
thing
I
would
be
frequently
updating
the
egress
aspects,
as
my
service
close
and
concerns
more,
but
the
ingress
would
actually
remain
the
same.
But
if
I
were
to
enforce
some
form
on
access
control,
saying
only
this
person
can
edit,
then
it
actually
becomes
a
bottleneck,
because
you
know
I
would
have
to
audit
each
and
every
change
that
the
entire
resource.
Just
to
see
that
oh,
this
is
only
for
the
egress
I
know.
I.
B
Buy
the
argument
like
they
may
actually
have
slightly
different
administrative
life
cycles,
and
that
would
mean
that
they
should
be
split
and
that
you
might
make
this
the
parallel
argument
that
kubernetes
traffic
policy
has
should
itself
be
split
because
its
egress
rules
are
like
UT,
evolved
in
a
different
rate
than
its
ingress
rules
or
be
subjected
to
different
security
reviews,
or
things
like
that.
So
I
don't
have
a
problem
with
that.
That's
that's
just
not
the
true
and
it's
it's
very
easy.
D
L
B
F
D
Actually,
not
not
about
specifying
a
a
rule.
It's
about
whether
or
not
a
policy
exists
that
selects
that
workload.
Yes
right,
so
you
could
have
a
policy.
It
was
empty,
had
zero
rules
in
it,
but
if
the,
if
the
selector
for
the
policy
selects
your
workload,
then
that
workload
is
now
moves
from
being
default
allowed
or
default.
A
B
B
Much
in
the
weeds
on
the
ingress
stuff,
because
if
we're
going
to
split
this,
we're
going
to
come
back
and
have
a
separate
review
anyway,
with
Lehman
there's.
Obviously
one
of
the
big
questions
with
ingress
and
ordered
rules
is
how
we
would
do
merging
with
global
level
have
been
defaults
right
in
prioritization
and
I.
Think
there's
gonna
be
some
refinement
of
that
discussion
and.
D
D
B
Respect
within
roaming
rule,
we
have
to
have
the
ability
for
some
routes
to
not
be
gateway
bound
and
some
to
be
gateway
bound.
We
don't
split
that
by
resource
we
split
that
by
hostname,
so
we
don't
have
the
ability
to
do
that
precisely
the
way.
You
would
want
right
now,
within
the
existing
virtual
service,
API.
K
C
Or
more
virtual
service
I
mean,
let
me
put
it
another
way.
The
Gateway
does
not
necessarily
have
to
be
serviced
in
the
registry.
It
could
effectively
run
as
a
separate
set
of
pool
of
leg
on
why
somewhere
and
it's
just
consuming
configurations
in
that
case,
being
able
to
define
this
per
namespace
level
thing
would
actually
be
slightly
problematic,
but
we
could
work
around
that
as
such,
but.
D
F
F
C
F
C
F
C
L
L
B
F
D
A
B
Know
it
is
never
possible,
that's
why
we
use
the
terms
ingress
and
egress.
If
we
choose
not
to
align
a
bit
which
we're
going
to
split
the
resource
apart,
there's
not
much
point
aligning
with
it.
Then
we
can
choose
different
names,
but
if
they're
lines-
and
then
we
pick
the
names
important
export
dependency
scope
was
a
variety
of
options.
The.
F
F
F
A
D
D
A
D
B
F
B
B
I
think
you
know
obviously
there's
a
fair
amount
of
detail
both
in
terms
of
the
API
structure
and
maybe
some
of
those
semantics
around
some
of
the
use
cases
as
a
broad
stroke
is
this
something
people
feel
like
is
headed
in
the
right
direction
or
not,
and
if
you're
I'm
staying
because
I
don't
understand
it,
yeah
and
I
need
see
more
detail
more
examples.
That's
a
totally.
C
May
have
to
clean
this
up,
and
then
we
basically
send
a
final
version
of
document
that
would
copy
get
the
right
feedback
that
you
want,
like
you
know,
being
we've
split
the
ingress
and
egress
part,
and
then
like
do
the
proper
naming
a
shared
and
namespace
stuff
with
dampers.
Then
it
probably
makes
a
lot
of
sense
for
people,
because
right
now
we
have
corrected
a
whole
bunch
of
concepts
like
you
know
in
satu
like
while
talking
about
this.
F
Make
it
a
bit
more
easier
to
digest
and
to
understand
I
I
mean
I've,
been
working
on
this
for
the
egress
part
on
on
an
implementation
or
a
proof
of
concept
and
and
I'm
hoping
to
get
it
into
one
to
two
and
or
whatever
at
least
200,
to
have
visibility
in
public
stuff.
So
it
may
be
easier
to
play
with
some
sings.
A
keeper
metal
is
part
of
this
too.
So
maybe.
B
B
C
Properly
so
I
want
much
other
like
being
down
over
on
the
API
first
and
like
understand
the
impacts
and
semantics
and
then
do
a
proper
termination,
because
I
do
not
want
to
get
anything.
That's
like
you
know,
like
a
prototype
version,
that's
like
into
a
release
and
then
worry
about
backward-compatible
rather.
F
F
G
F
L
M
A
M
A
A
A
G
B
B
A
B
B
A
A
B
Destination
rule
Z
is
a
namespace
cooked
thing
and
it
is
attached
to
the
service
entries
which
it
declares
for
mm-hm
and,
if
I,
so,
this
is
where
merging
gets
a
little
bit
complicated.
If
I
have,
if
I'm
poor,
two
namespaces,
they
declare
the
same
service
entry
and
are
decorated
by
to
destination
rules
that
diverge
and
behavior
right,
then
we
have
to
have
some
resolution.
Okay,
not.
A
L
A
F
B
B
A
B
A
Okay,
so
I
think
we're
really
running.
We
ran
over
time
already,
so
each
other
yeah
we'll
probably
need
to
stop
now,
but
I
do
encourage
everybody
to
like
provide
comments
offline
in
the
document,
All,
Souls
and
Demon's
I.
Guess
that
works
if
I
need.
We
will
have
one
more
meeting
next
week
if
I
see
like
a
lot.