►
From YouTube: Istio Networking WG meeting - 2018-11-15
Description
- Network scoping follow up
A
Naturally,
scoping
proposal
from
last
week,
and
hopefully
everybody
had
enough
time
to
read
it
and
is
funded,
and
there
are
plenty
of
questions
to
cover
the
full
rest
of
the
hour
we
have
so
do
it.
Would
you
like
maybe
to
talk
more
about
the
updates?
I
can't
there's
a
main
takeaway.
So
would
you
like
to
get
questions
a.
B
B
B
B
So,
while
there's
still
some
bike
shedding
about
naming
going
on,
hopefully
we'll
come
to
some
reasonable
resolution
with
that
in
the
short
term.
Maybe
it's
not
the
best
use
the
meetings
time
to
bike
shed
on
the
names,
but
I
did
update
in
the
document.
I
renamed
the
resource
to
network
scope
just
to
make
it
a
little
clearer,
although
I
don't
think
that's
gonna
be
the
final
name.
B
Then
there
were
a
bunch
of
questions
about
how
global
defaults
would
work
and
there's
kind
of.
Is
this
somewhat
existential
question
about?
Do
we
follow
a
paradigm
of
you
know
electing
a
special
namespace
for
the
global
defaults,
or
do
we
create
equivalent
schemas
in
C
Rd
s,
4
cluster
scope
series
and
how
those
be
the
global
defaults?
B
B
C
Created
proposal
and
discuss
that
it's
giving
profiles
basic
is
having,
in
the
same
cluster,
helping
different
parallel
installations
of
each
ta
with
different
versions.
I
mean
with
kinetic
pressure,
production
version
and
maybe
small
variants,
and
each
of
them
creating
kind
of
sort
of
having
authority
force
busy.
So
you
will
not
have
a
cluster
de
force,
but
you'll
have
a
default
pair
profile.
So
you
can
have
developer
for
if
I
don't
have
different
settings
and
within
the
same
production
process,
and
you
can
use
namespaces
the
mother,
whose.
D
C
Position
the
weight
with
work
is
that
you
points
I
contingent
remain
static.
Electric
charge
is
kind
of
one
controlling
how
you
are
operating
your
stuffings
and
business
a
profile
you
get
the
set
of
telemetry
server
spiral,
servers
and
probably
defaults,
different
aspects,
those
that'll
kind
of
completely
telling
blow
by
the
resources.
Yes,.
B
It
would
first,
this
is
kind
of
very
fixed
Global's
that
cluster
resources
would
represent,
seem
problematic
in
the
long
run,
and
so,
while
it's
something
we've
done
elsewhere
in
other
parts
that
config
I
was
talking
with
Martin
and
some
folks
in
the
configure
working
group.
You
know,
maybe
we
should
document.
This
is
policy
to
say
look.
We
should
not
vary
this
scheme
as
honest
as
a
good
reason
to
we
should
treat
namespaces
as
if
they
were
a
pseudo
hierarchy,
at
least
a
two-level
one.
B
To
begin
with
and
right
that
should
make
the
API
is
more
conceptually
similar.
The
other
thing
and
Martin
brought
this
up
on
one
of
the
comments
and
it's
pretty
reasonable.
Is
that
most
the
defaults
if
the
resources
are
designed
to
be
merged
and
the
job
of
applying
a
default
is
just
doing
a
sensible
right,
and
so
there's
a
there's,
a
question
here
about
what
should
mCP
do
all
right?
So
let's
say
we
have
a
a
cluster.
A
a
namespace
which
represents
the
defaults.
B
B
B
Let's
make
the
more
like
the
clarify
degree
situation,
I
think
which
could
have
also
done
the
merging
two,
so
I
I
think
I
agree
with
Martin
that
it's
okay
for
galley
to
do
the
merge
and
for
this
feature
to
basically
be
a
galley,
only
feature
right,
but
if
we
want
to
have
a
admin,
namespace
and
you
say
to
Galilee
what
the
admin
namespace
is
and
when
in
people
make
changes,
there
were
two
other
resources
it
takes.
Care
of.
The
merge
semantics
for
the
particular
resource
type
certainly
keeps
implementation.
A
little
simpler
does.
E
E
C
E
C
B
There
is
a
question
here
right
in
theory.
This
specification
would
allow
galle
to
do
the
merging
right.
If
the
only
reason
for
Gally's
do
it
is
because
you
are
going
to
be
delivering
to
a
pilot,
/
namespace
right,
but
the
problem,
the
pilot-
has
a
global
right.
It's
a
trip
to
be.
We
treat
the
pilot
is
a
global
controller
right
and
I.
Think
we're
gonna
stick
with
that,
and
that
would
be
a
big
architectural
change.
C
B
B
Exact
is
how
complicated
are
the
word
semantics
and
what
scale
that
they
need
to
be
done,
so
the
the
electing
a
namespace
as
the
default
admin
namespace.
Those
seem
like
a
concern
galley
to
take
on
because
the
scale
is
smaller
and
the
domain
required.
Knowledge
is
less.
It's
not
a
lot
of
code.
Yeah.
E
C
I
will
explain,
I
think
so
we
can
say
hey
by
default.
Each
namespace
is
completely
isolated
from
all
the
others.
There
is
no
default
of
you.
You
have
a
consistent
and
clear
articulation
in
a
space.
Generally
just
happens
to
be
able
to
generate
these
configurations
that,
especially
for
a
namespace
to
some
other
mechanism
for
merging
defaults
are
distractive
whatever
override
in
the
end,
you
can
say
a
dump
or
the
configuration
for
my
space
and
you
give
the
set
of
gamal.
That
is
a
complete
set
and
deterministic
set
of
everything
that
oppresses
on
Xmas
right.
C
Made
one
by
this
was
from
other
sources:
I
need
make
it
use
heavy
or
something
that
it
doesn't
necessarily
put
any
constraint
on
how
the
config
for
any
space
is
configured
just
said
in
Zn
pilot
we'll
get
for
each
namespace
a
set
of
configs,
and
that
config
will
be
the
source
of
truth.
And
you
can,
you
know,
dump
it
in
or
not
use
galley
with
something
else,
but
still
have
some
merging
and
takes
this
output
and
sss
configuration
right.
So.
B
E
A
C
C
Plan
and
I
see
there
is
a
confusion
here.
Once
we
enable
Network
scope,
everything
all
policies,
policy,
security,
art
became
missing.
Who
follows
us?
The
furnace
is
so.
This
is
not
only
about
importing
future
services,
its
complete
isolation
of
namespaces,
when,
when
we
name
D
theta,
because
that's
what
we're
trying
to
solve
at
that's.
C
B
B
C
C
B
It
came
up
in
the
context
of
this
talk
because
I
had
to
write
something
about
admin
defaults,
because
it
is
a
present
concern.
Yeah
and
I
did
have
the
chart
with
my
time,
which
is
why
this
came
up.
So
it's
an
important
issue.
If
we
all
agree
in
principle
that
we
don't
want
to
create
custom,
CR
DS,
we
want
to
have
an
admin
namespace
and
we
want
Gally
to
act
like
a
lightweights.
Basically
like
a
lightweight
CD
tool
for
a
very
small
subset
of
capabilities.
B
Are
we
the
arbiter,
need
to
find
emerging
semantics
of
each
type
precisely
to
find
them
right?
So
it's
either
order
concatenation
its
Union
merge.
Those
are
really
only
two
viable
ones
right
to
have
sensible
emerging
semantics,
then,
is
this
tech
merge
able,
is
a
question
and
hopefully
being
careful
enough
to
make
sure
that
it
is
and
then
what
other
types
would
I
need
to
apply
to
and
very
clearly
or
back
right,
because
that
that's
one
thing
that
people
are
very
much
one
control
over.
C
C
B
B
G
B
G
Well,
that
would,
but
that
is
same
as
putting
all
the
stuff
in
one
namespace
and
then
importing
that
namespace
and
all
the
configurations
right
yeah
this
use
case.
But
no,
but
in
my
mind,
global
default
is
there's
a
global
network
scope
object
which
defines
like
import
a
B
and
C
and
D-
and
here
are
the
like.
You
know
XY
and
Z,
and
that
basically
gets
inherited
by
everybody
and
they
add
their
stuff
on
top
of
it.
That.
C
G
Then
that
is
my
point.
That
is
where
things
just
start
breaking,
because
I
mean
sure
we
can
do
that
as
long
as
we
say
by
default,
everything
is
open
for
all
people.
If
there
is,
we
want
to
do
something
like
you
know,
like
you
know,
not
open
for
all,
but
everybody
basically
gets
to
do
like
you
know
only
local
namespace
access
only
global
default,
then
it
effectively
means
everybody
has
been.
Who
would
take
the
Matias
example
right?
G
B
The
upgrade
transition
plan
is
by
default.
If
you
don't
have
this
resource
in
your
namespace
right
subject
to
a
flag,
you
import
everything
right,
which
is
the
behavior
today.
If
you
add
this
resource,
then
you
are
saying
that
I
want
to
down
scope.
My
visible
network
and
I
don't
have
any
implicit
imports
right.
Everything
is
explicitly.
A
C
I
G
C
Settings
here
and
whatever
upsetting
is
when
you
upgrade
from,
if
you
want
zero
to
whatever
this
will
be,
you
keeps
an
X
I,
see
nothing
breaks,
it
keeps
the
existing
behavior.
You
start
migrate
in
a
space
by
namespace
and
at
some
point,
when
you
hold
the
namespace,
is
having
migrated
in
help.
You
network
scope.
You
said
you
change
the
default,
be
you
radio
or
Great
Eastern,
and
specify
here
one
cluster
wise
to
have
reservation
right
and
at
that
point
any
new
namespace
would
have
to
put.
C
Know
existing
I
mean
you,
you
you,
you
will
start
upgrading
to
East
your
own
one,
which
has
this
come
already.
Let's
say
you
go
by
on
each
namespace
and
you
put
a
network
scope
and
you
want
a
great
and
a
great
so
gradually
odd
networks,
oh
and
when
you
finish
it
only
spaces
and
verifies
that
each
namespace
has
a
net
or
scope.
You
can
turn
the
default
and
for
new
namespaces.
You.
B
B
J
B
G
My
point
is
this:
like
we
thought
of
this
exact
same
model
may
be
designed
the
first
set
of
the
API
things,
but
then
nobody
immediately
broke
was
when
we
had
to
do
things
like
this
K
native
stuff,
where
they
were
dynamically,
creating
objects,
namespaces
and
adding
services,
and
so
on.
So
it
actually
adds
additional
overhead
to
them.
B
G
No,
no
I'm
not
talking
about
how
to
define
it.
What
I
am
saying
is
I
mean
management
wise
if
I
have
a
system
like
something
like
kn8,
which
is
creating
a
namespace
dumping,
a
bunch
of
things
and
then
deleting
the
namespace
all
done
programmatically
in
response
to
some
user
event
and
so
on.
Then,
in
that
case,
what
we're
doing
here
by
saying
that
we
will
not
have
a
clue
like
global
network
scope
that
everybody
else
would
inherit
from,
but
and
that
and
that
we'd
only
have
to
like
high-level
flag
buttons.
Like
you
know,
I
mean.
G
Hold
on
I
think
I'm,
not
Burnett.
What
I'm
saying
is
that
if
you
imagine
a
system
that
is
creating
a
dynamic,
namespace
and
then
dumping
a
bunch
of
workloads
in
there,
they
do
their
stuff
and
then
the
namespace
get
deleted.
And
so,
let's
say
these
workloads
all
have
like
in
across
all
sort
of
dynamic
liquid
namespaces.
They
all
have
a
common
set
of
dependencies.
They
all
depend
on
some
fixes
that
have
namespace
that
are
pre
created
that
are
already
existing
and
that
are
there
right
and
so
now,
by
default.
G
What
we're
doing
with
this
model
that
we
have
today,
they
can't
simply
set
a
global
namespace
only
by
default
setting.
They
can't
even
they
don't
want
to
set
a
global
star
by
default,
setting
because
that's
too
much
overhead
what
they
want
is
like:
hey
I,
have
this
network
or
project
that
everybody
is
basically
gonna
inherit
and
I
just
define
it
one
time
when
I
first
deploy
my
controller
on
the
system
and
then
the
controller
can
create
a
namespace
and
boom
by
default
demo
decorated
in
a
space
program,
and
we
didn't
here
it's
this
network
scope.
G
B
B
B
G
Did
the
same
thing
with
let's
encrypt
right
to
be
thought
like
hey?
How
much
work
is
it
for
you
to
simply
reduced
your
Gateway
resource,
and
why
you?
What
do
you
have
to
bother
with
these
two
increases
was,
and
then
we
ended
up,
be
bent
head
over
heels
to
fix
that,
let's
encrypt,
unlike
you,
know,
support
them
by
merging
gateways
and
doing
all.
B
B
I
G
B
C
B
G
G
M
M
Yes,
me
need
anything
yeah
all
right,
so
I've
been
looking
at
the
document
and
I
rather
look
a
little
late.
It
feels
like
he's
trying
to
achieve
a
lot
of
things.
It's
just
from
configuration
point.
You
know
if
you're
an
operator
it
still
feels
you
have
to
look
at
a
lot
of
resources
to
understand.
What's
going
on,
just
you
be
more
specific.
B
M
Sorry
Louis
I
miss
that.
Can
you
say
that
again?
Can
you
believe
in
more
specific?
Yes,
so
basically,
what
I'm
looking
at
is
import
semantics.
We're
a
looking
at
Network
scope,
I
have
to
figure
out,
I
have
to
first
figure
out
the
other
namespaces.
What
host
they
are
exposed,
then
I
need
to
import
them
then,
and
what
the
virtual
services
are
doing.
I
would
have
to
still
go
to
what
you
think
yourselves
and
see
what's
kind
of
wrong
thing.
They
are
doing
right.
There
are
at
least
three
to
four
resources.
B
I
would
actually
one
virtual
services
already
merged
today,
so
if
you
own
a
gateway
that
is
binding,
multiple
virtual
services
and
you
you're
responsible
for
understanding
what
they
do
or
you
choose
not
to
import
them
right,
and
you
have
a
monolithic
virtual
service,
which
you
completely
own
and
define
as
a
unit.
You
get
that
choice.
B
Alright
and
that's
an
important
property.
This
this
design
or
just
distinctly
right
distinctly
different
from
before
right.
I
can
choose
not
to
import
anything
right
and
create
a
virtual
service
for
a
hostname.
That's
defined
elsewhere
and
I
have
arbitrary
control
over
it.
If
I
choose
to
import
and
virtual
services
from
n
different
namespaces,
then
they
need
to
merge.
B
M
B
Just
that
that
was
my
and
then
just
coming
back
specifically
on
virtual
services,
if
it
for
people
who
know
what
I
say
is
the
order
of
merge
is,
if
you
define
the
virtual
service
in
that
namespace.
The
merge
order
is
that
that
virtual
service
declaration
is
prepended
to
ones
that
are
outside
the
namespace.
B
This
is
extremely
useful
for
things
like
let's
encrypt
right,
where
I,
as
the
Gateway
owner
can
basically
attach
common
behavior
to
everything,
that's
bound
to
my
gateway
with
path
based
selection
and
have
a
deterministic
merge
where
the
other
namespaces
cannot
override
that
behavior
right,
which
is
precisely
the
thing
we
wanted
for
lensing
crypt
that
we
weren't
able
to
do
before.
I.
J
H
J
G
E
Argue
that
part
of
our
goal
should
be
that
you
don't
have
to
write
like
if
we
think
about
a
consumer
I,
there's
some
service-
that's
probably
another
namespace
that
I
want
to
consume.
I
really
shouldn't
have
to
think
about
their
virtual
service
or
a
lot
of
that
configuration
right
like
that
and
that's
the
normal
case
right.
Somebody's
publishing
a
service
they
describe
how
to
contact
this
I
import,
that
host
name
or
I
import.
That
namespace.
E
This
provider
will
control
the
the
virtual
service
that
does
the
canary
to
my
service,
and
consumers
of
my
service
should
never
see
that
right,
like
they
shouldn't
have
to
care
about
that.
So
that's
I,
guess
that's
my
problem
with
like
yes,
you're
importing
and
stuff,
and
you
don't,
and
if
you
want
to
understand
what
it's
doing,
you
have
to
go,
look
at
it,
there's
no
way
to
get
around
that,
but
most
of
the
time
you
shouldn't
have
to
care
what
that
stuff
is
because
you're
consuming
some
some
hostname
some
surface
yeah.
J
H
J
True
I
agree
yeah,
it's
just
you
haven't
definitely
more
control
with
this
new
model.
It's
just
the
level
configuration
the
complex
that
you
certainly
increase.
So
it's
it's
going
to
be
a
little
bit
harder
for
user
to
actually
know
if
that
configuration
is
actually
what
they
wanted
to
come
fake.
Well,.
B
J
B
N
C
B
M
B
So
we're
only
ask
people
to
do
this,
one
if
you
are
concerned
about
your
scale
and
if
you're,
that
paranoid
about
workloads
running
in
your
name,
spaces
that
you
think
we'll
the
egress,
the
things
that
you
don't
want
them
to
be
able
to
egress
to
which
is
a
concern
for
some
companies
right.
It's
a
it's
an
egress
part
wall
declare
that
there
are
seven.
D
B
O
B
Today,
right
all
the
destination
rule
stuff
is
attached
by
the
service
producer,
and
we
especially
are
retaining
that
semantics.
Now.
The
one
thing
that
is
this
pattern
of
namespace
ownership
would
allow
for
is.
We
could
in
theory,
though,
I'm
not
currently
recommending
it,
because
we
haven't
validated
that
it
makes
sense
to
allow
the
consumer
to
override
destination
rules
for
the
services.
E
E
B
D
D
E
It
to
be
clear,
this
is
part
of
the
reason
that
I
brought
up
some
of
the
merging
stuff
earlier,
because
this
all
gets
very
complicated,
right
and
I
think
it
needs
to
be
very
clear
where
we
do
the
merging
and
what's
and-
and
we
have
a
very
clear
story
about
how
it
works
and
I
think
we
do
today
with
this
scheme.
But
we
just
need
to
be
careful,
as
we
add
more
rather.
N
B
The
resource
plan
you
Larry
you've
tried
to
do
that
right.
Obviously,
things
like
virtual
services
right,
which
contain
many
rules
right,
they're,
basically
ordered
lists
of
rules,
I
get
implemented,
which
is
the
same.
The
same
thing
is
logically
true
for
our
back
policy
merging
still
has
to
occur
between
those
groups
of
rules.
Alright,
so,
and
we
didn't
provide
control
over
that.
B
So,
yes,
we
are
thinking
about
which
roles
are
going
to
own,
which
resources,
but
we're
also
somewhat
constrained
by
you
know
what
well
the
current
idioms
are
for
resource
edit
and
resource
access
control
in
kubernetes
and
elsewhere.
Right.
We
still
expect
there
to
be
a
unit
of
edit,
which
is
aligned
with
a
role
right
and
I,
expect
that
there
is
a
network
namespace
admin
who
is
going
to
create,
update
and
delete
this
resource.
Who
is
responsible
for
basically
the
definition
of
the
network
within
that
namespace,
but.
E
Are
a
lot
most
yeah
timeouts
or
the
clear
example
right
so
like
Shannon
to
your
point,
I
think
your
point
is
correct.
Right
now
are
the
the
actual
contents
of
our
resources
split
configuration
that
different
people
care
about
and
to
Louise
point
right.
We
talked
about
moving
some
of
that
stuff
out
and
into
other
documents
like
yes,
we
know
that
that's
a
problem
in
our
config
today,
but
it's
not
it's
worth
talking
about
this
discussion
right
and
something
in
it
and
can.
C
N
B
So
I
think
there's
a
or
the
attachment
points
of
fault
injection
and
what
the
valid
faults
you
might
want
to
use
and
that
might
actually
be
more
of
a
producer
concern
because
they
understand
the
canonical
error
modes
of
their
service
and
then
are
they
on
or
not
right.
That
might
be
a
way
of
dividing
up
those
rules,
but
we
haven't
gone
through
in
detail
on
that
particular
use
case.
And
that's
is
the
me
your
major
remaining
tension
between
the
producer
and
consumer,
but.
B
E
H
B
B
B
C
B
B
D
C
B
While
it's
not
a
pressing
concern
today
for
some
customers,
we
could,
in
theory,
use
this
declaration
to
limit
the
DNS
discoverability
of
the
network,
all
right.
Well,
what
do
you?
What
do
you
mean?
So
if
I
run
code
in
a
namespace
that
is
subject,
this
scope
and
I
try
resolve
a
host
name
that
is
not
imported
I,
don't
get
anything.
G
E
G
C
B
N
Yeah,
maybe
a
way
of
framing
this
is
when
we
first
started
looking
at
Sto
a
year
and
a
half
ago.
The
first
thing
we
noticed
was
that
there
was
no
default
denial
policy.
There
was
no
sharding
of
the
config
in
the
in
the
sidecars
and
that
there
was
no
way
to
remove
the
host
name
from
discoverability
as
a
result,
I
think
of
those
three
the
III
mentioned
them
in
order
of
importance
defending.
M
N
J
The
wall
of
the
scenario
we
are
thinking
using
about
this
is
you,
so
you
guys,
probably
remember
we
wrote
a
proposal
about
in
the
multi
cluster
environment.
You
don't
expose
everything
to
the
other
cluster,
so
one
of
the
scenario
we
were
thinking
is
I'm,
glad
I'm.
Sorry,
yes,
the
mesh
Federation
so
well
of
just
an
area.
We're
thinking
is
on
that
remote
cluster.
You
could
use
this
scoping
and
DNS
scoping
to
actually
control.
Maybe
you
have
ten
services.
You
only
want
one
or
two
services
to
be
exposed
to
the
other
clusters
through
mesh
Federation.
E
It's
more
than
locality,
based
routing
right
so,
like
I,
think
to
your
point,
I
think
what
you're
getting
at
Louie
is.
We
want
applications
to
have
basically
the
same
view
of
the
world
as
the
sidecar,
that's
in
front
of
them,
because
that's
really
what
this
DNS
visibility
bit
is
and
I
totally
agree
with
that.
I
think
that
that's
that's
exactly
the
right
path,
so.
B
B
Obviously,
this
proposal
right
gives
because
we
essentially
isolate
namespaces
and
namespaces
connect
independently
or
they
can
collaborate.
Do
we
need
the
other
thing
all
right,
because
the
use
cases
for
the
traffic
ownership
stuff
were
really
around
giving
gateway
owners,
particularly
for
ingress
the
ability
to
delegate
trust
around
hostname
or
other
networking
aspects
to
other
namespace
owners
so
that
their
config
would
impact
the
behavior
of
an
ingress.
Well
that
we
we
have
that
behavior
in
this
API
right
I
have
the
ability
to
delegate
trust
or
to
not
by.
H
M
M
O
G
E
G
E
G
E
N
G
E
E
M
C
C
G
Is
actually
saying
this
odd
valid
is
that
you
see
when
I
said
we
can
input
specific
virtual
services
and
destination
responding
space?
You
said
that
is
like
I
might
as
well
go
to
produce
a
model
where
ice,
where
I
decide
what
to
X
or
tornados,
we'll
just
in
cream
put
the
whole
thing,
but
Shannon
is
pointing
out
that
the
fact
that
I
have
to
know
namespace
foo
has
a
host
called
bar
is
itself
a
bad
user
experience,
because
I
want.
B
C
B
N
Sure
so
it's
I
use
them
all.
I
recognize
that
there's
ownership
of
of
a
host
name
or
URL,
and
whether
that's
first
come
first
serve
or
you
want
to
build
something
more
complicated
like
a
namespace
own.
That
is
sort
of
irrelevant.
But
the
problem
is:
is
that
from
the
consumers
perspective,
I
shouldn't
care
who
owns
it
all
I
care
about?
Is
that
my
application
wants
to
make
a
request
out
to
a
URL?
No,
no.
N
B
I'm
being
very
careful
here,
right
virtual
host
delegation
right
I,
just
don't
know
the
thing
we
care
about,
because
the
service
stuff
is
well
covered
already,
where
you
don't
have
to
know
right.
The
network
name
is
the
black
box,
and
that's
all
you
can
see
you
for
virtual
host,
where
I'm
dividing
up
portions
of
a
network
namespace
at
a
more
granular
level
right
and
delegating
ownership
of
that
to
another
organizational
unit,
because.
N
B
B
N
B
K
E
Being
proposed
here
say
we
want
to
encode
this
notion
of
namespace
I
same
in
part
to
address
part
of
your
concern
right.
You
can
import
strictly
a
host
with
no
namespace
or
anything
like
that,
and
you
don't
have
to
care
who's
provisioning,
that
configuration
Louise,
saying
we
can
go
one
step
further
and
we
can
import
host
and
a
namespace.
We
can
say
I
want
this
host
and
I
want
it
to
be
from
from
this
administrative
domain.
E
That's
also
a
valid
use
case
and
we
want
to
be
able
to
satisfy
both
where
a
user
doesn't
have
to
care
who's.
Producing
the
config
I
just
want
a
host
name
and
that
works
under
the
host
API.
We
would
like
to
be
able
to
go
further
and
say:
I
want
this
hostname
administered
by
this
entity,
and
we
can
also
say
that
with
the
API
okay,
can
you
so?
Let
me
understand.
N
B
B
G
B
G
N
B
Well
aware
of
is
for
ingress
right,
where
I,
as
the
business
owner,
one
all
traffic,
to
go
out
through
some
egress
middle
proxy,
so
there
will
be
a
namespace
owner
who's
going
to
define
the
name,
let's
say
facebook.com
and
they're
going
to
define.
That
name
is
pointing
to
that
middle
proxy.
There's
gonna
be
another
namespace
owner
is
going
to
define
the
name
facebook.com
and
it's
gonna
point
it
to
the
external
entry
right
if
split
horizon
right
and
I'm
doing
it
deliberately,
because
I
want
aggress
gateway
access,
control
management.
B
N
B
C
B
K
M
B
B
Exactly
that's
what
I
was
saying
so
I
think
just
pinning
this
to
egress
is
not
the
right
model.
No
no
I'm
just
saying
ingress
is
one
example.
It's
a
very
clear
one
of
a
split
horizon
DNS
right.
There
are
plenty
of
other
examples
within
enterprise
of
people
doing
split
horizon
right,
which
is
what
this
is
representing.
J
B
B
B
B
C
E
P
P
A
B
One
thing
I'm
very
Kirk
I
was
very
clear
from
this
dog
to
talk
about
what
clothing
could
not
be
delivered
intimately
I
think
we
can
reasonably
deliver
this
feature
without
global
default
yeah.
As
long
as
we
have
the
be
flag
which
says
it's
either
no
important
everything
or
in
more
nothing
by
default,
nobody.
B
B
So
we
don't
need
to
get
hung
up
on
that.
The
there
doesn't
seem
to
be
a
much
discord
about
virtual
service
import
and
export
and
service
import.
Sergers
public
private
as
a
natural
is
also
a
natural
scoping
or
thing
which
is
even
more
coarse-grained,
but
very,
very
producer
oriented
and
some
obvious.
No
one
seems
to
have
any
negative
feedback
about
that,
so
that
I
think
that's
baked
in
so
near
as
I
think
you
wanted
to
spend
a
little
more
time
with
it
to
see
how
you
felt
about
it.
B
We
didn't
entirely
come
to
a
conclusion
on
traffic
ownership
and
whether
we
did
or
did
not
need
something
more
fine-grained,
but
at
this
Elise
this
allows
us
to
make
progress
and
get
some
user
feedback
everywhere
about
whether
this
is
or
is
not
fine
grained
enough,
and
it
provides
a
lot
of
control.
It's
one
thing
at
this
clearly
does.
Is
it
gives
you
a
lot
of
control?
C
G
C
C
E
What
if
I
define
a
virtual
service
that
overrides
some
other
hostname
and
somebody
imports
my
entire
my
entire
namespace,
so
they
get
kind
of
some
unintended
virtual
service
that
I
defined
for
myself,
but
because
they
import
the
entire
namespace,
it
comes
along
and
it
get
merged
with
the
real
virtual
service.
For
that
post
thing.
Well,
that's
what
you
chose
to
do
right.