►
From YouTube: Istio Networking WG meeting - 2019-08-01
Description
- “Release blocker” new priority
- List of maintainers, rights and responsibilities
- nftables, working PoC for Istio CNI
- Discuss outline for new Istio Topologies.
A
Hi
and
welcome
everybody,
and
especially
the
people
joining
the
networking
working
here.
We
have
loaded
up
gender
today.
So
there
are
a
couple
of
announcements
in
the
beginning,
got
a
one
night
and
then
I'm
gonna
actually
move
the
demo
about
the
cni,
because
it
will
take
a
bit
less
and
it's
a
bit
more
deterministic.
I'll
move
it
as
the
third
item.
I
hope
need
you're.
Okay
with
this
and
then
there'll
be
a
lot
of
good
discussion
related
to
multi.
A
All
the
things
Nate
and
I
see
Stephen
also
has
something
so,
let's
get
started
so
the
first
one
it's
about
the
release
blocker.
So
there
were
some
discussions
in
the
TOC
about
how
we
determine
which
issues
are
which
fix.
We
need
to
wait
before
launching
a
release.
The
conclusion
was
that
there
will
be
a
new
priority
called
release:
blocker,
that's
a
sort
of
a
P
minus
one,
and
only
the
release.
Managers
can
add
this
priority
to
an
issue
or
to
a
bug.
A
So
P
zeros
are
no
longer
released
block
because
they
were
before
because
there
are
way
too
many
peasy
rows
and
they
never
make
it
in
time.
We're
trying
to
release
with
the
more
predictable
cadence
and
if
you
have
an
issue
of
fix
and
you
think
that
the
release
should
be
blocked
because
of
that
you
need
to
contact
the
release,
managers
and
let
them
know
and
basically
discuss
and
negotiate
with
them.
I
guess
that's
pretty
much.
It
can.
B
A
A
Good
all
right
next
item:
unless
there
are
more
questions,
so
the
next
one
is
an
interesting
one.
So
what
there's
been
this
recent
effort
around
creating
a
list
of
maintained
errs
for
the
various
work
groups
and
areas
of
East,
and
this
like
the
main
Turner's
list,
you
can
actually
see
it
here.
I'm
sharing
this
list
is
an
initial
list
that
we
tried
to
put
together.
Based
on
you
know,
contributions.
There
might
be
names
that
are
missing
from
this
list,
in
which
case
please
ping
me.
A
The
reality
is
that
the
list
will
change
based
on
actual
metrics,
so
we
started
gathering
metrics
from
like
CN
CF
about
maybe
two
weeks
ago
so
and
the
maintainer
status
will
be
really
a
meritocratic
status
based
on
actual
contributions.
So,
including
you
know,
fixes
issues,
comments,
I,
guess
participation,
so
this
list
is
subject
to
change
right.
A
So
the
responsibilities
like
maintenance
may
be
assigned
bars
on
which
they
we
need
to
fix
right
and
also
participate
in
triage
generally,
like
loopy
and
active
maintainers
for
all
the
rules,
but
the
rights
are
like
really
powerful,
because
it's
right
to
approve
code
changes
in
the
respective
areas,
so,
for
instance,
for
networking
it's
like
much
of
pilot,
but
not
only
right.
I
also
try
to
create
a
separate
list
for
networking
CNI,
which
has
like
the
who
have
actively
developed
this.
A
So
we
made
like
discuss
father
if
the
two
should
be
just
one
list
depend
on
the
you
know,
the
preference
there
are
or
like
all
these
discussions
happen
in
the
still
working
group
leads
meeting.
Maybe
I
will
I
will
have
I
will
add
the
link
to
the
minutes
for
that
meetings
and
people
can
see
you
know
like
what's
being
discussed,
and
and
do
you
think
that,
obviously
it's
open
to
everybody,
so
everybody
can
join.
The
next
meeting
will
be
on
Friday
at
11
right
after
the
TOC.
A
A
A
C
A
C
C
C
So
I'm
to
demonstrate
that
I
have
to
attach
to
one
of
the
containers,
which
is
the
kind
of
a
main
application
container
I,
even
though
it's
called
an
FFT
and
it
it's
it's
a
job.
It's
kind
of
application
all
right
and
to
demonstrate
the
resulting
enough
tables.
I
had
to
install
an
F
n
ft,
CLI
2,
but
for
normal
applications.
It's
not
required
so
the
N
and
if
T
tables,
basically
they'll,
be
programmed
in
the
kernel
and
then
whatever
the
stack
will
take
care
of
all
the
filtering
required
here.
C
C
Alright
so
and
here's
the
resulting
table,
nft
tables
has
a
more
rich
feature
set
and
it
also
supports
different
sets.
So
you
can
define
a
set
of
based
on
ports,
you
can
define
a
set
of
based
on
their
IP
addresses
and
then
these
sets
can
be
referred
from
the
rules
and
that's
exactly
what
I
use
here.
So
I
did
the
court
the
driver,
enough
tables
driver
running
with
the
CNI
it
defines
the
pending
for
the
exclusion.
Inclusion
are
different
sets
and
then
it
in
the
in
the
rule.
C
It
refers
to
those
sets,
and
so
the
the
grand
finale,
the
most
important
part
is
basically
this
rule,
which
tells
the
old
TCP
traffic
needs
to
be
transfered
to
1500
won
as
a
transparent
proxy.
So
I
have
a
kernel
version,
5,
0,
0
here
and
I
tested
the
functionality
it
works.
Well,
the
redirect
like,
as
we
used
to
have
with
IP
tables,
works
perfectly
fine
with
the
enough
tables
and
the
kernel.
C
415
I
haven't
tested,
lower
versions,
I
guess
I
mean
probably
it's
less
relevant
I
don't
know,
but
so
this
is
what
I'd
like
to
show
I
mean
if
you
guys
have
any
questions
based
on
the
output
presented
on
the
screen.
Let
me
know
how
do
you
are
you
exclude
outbound
traffic
from
that
redirect
outbound
traffic
here.
C
Now
there
is
a
PR
out,
unfortunately,
so
far
we
couldn't
find
a
place
where
we
could
test
it.
I
mean,
unfortunately,
neither
Travis
which
I'm
using
for
myself
or
Circle
CI,
gives
ability
to
law,
@nf
an
empty
table
and
have
tables
module,
because
it's
required
in
most
of
the
cases
like
on
the
more
more
recent
Ubuntu,
1804
or
nineteen
ninety
and
ten
or
nineteen,
not
1904,
it's
it's
it's
preloaded.
So
it's
not
a
problem,
but
though
those
guys
they're
using
the
older
version
of
VM,
so
I
cannot
really
test
that
NCI.
C
Based
on
that
I
had
the
discussion
with
team
Swanson
and
where
the
we
saw.
The
alien
since
I
have
a
proof
that
it's
working,
we
probably
merge
it,
because
so
people
could
basically
start
playing
with
it,
but
they're
gonna
be
a
big
disclaimer,
not
tested,
and
they
see
I,
at
least
at
this
point,
and
once
we
have
a
proper
platform
to
test
that.
Well,
then,
we'll
we'll
deal
with
that.
C
Well,
only
visual
I
mean
I
could
definitely
do
some
tests.
I
mean
I
just
need
an
idea.
What
exactly
you
want
me
to
test,
but
what
I
noticed
that
the
start
time
for
the
container
is
way
faster,
because
you
see
in
case
of
the
IP
tables,
it's
an
external
executable
for
every
single
rule
you
have
here.
We
talk
directly
to
the
kernel
over
the
net
Linux
socket,
so
there
is
no
any
delay,
nothing,
no
spooning
child
processes
or
all
that
things
do.
D
C
C
F
G
D
E
D
E
I'm
not
entirely
sure
if
it
wouldn't
be
better
to
because
we
are
trying
to
separate
just
the
responsibilities,
a
bit
installer
operator
and
so
forth,
and
it
might
be
better
for
all
the
CNI
relay
I
mean
all
that
I
Peter.
Well,
I
know
that
repository
is
not
properly
named,
but
maybe
it
would
be
better
to
do,
is
IP
table
and
creating
the
docker
image
for
the
initializer
and
CNI
in
the
same
place.
So
they're
concentrating
the
same
then.
B
D
C
A
A
B
So,
just
a
little
bit
of
background
I
came
onto
multi
cluster,
a
couple
months
back
and
in
various
discussions
and
various
Docs
cuz
there
are
about
a
thousand
different
multi
cluster
Doc's
from
various
different
people
across
the
community.
I
was
trying
to
just
kind
of
get
my
head
around
number
one.
B
What
all
the
different
aspects
to
multi
cluster
are,
and
there
seem
to
be
a
lot
of
collisions
of
terminology
and
I,
think
I.
Think
those
two
problems
were
all
painfully
aware
of
so
I
kind
of
set
out
on
this.
This
journey,
if
you
will
of
kind
of
like
number
one
kind
of
coming
in
at
turns
terms
with
what
the
terminology
is
and
I
referred,
a
lot
to
the
doc
from
rulli
and
Shriram
previous
networking
working
meetings.
B
B
So
that's
that's
the
general
idea,
so
what
I
like
to
do
is
get
consensus
on
what
that
outline
should
be
today
and
then
we
can
start
tackling
individual
sections
and
and
bear
in
mind
that
there's
already
content
separately
from
this,
that
we've
already
started
working
on
to
fill
out
some
of
these.
These
bits-
I
talked
with
Steven
dake
and
various
others,
and
it's
it's
kind
of
ongoing.
So
there's
these!
These
are
not
empty
sections
yet,
but
I
just
wanted
to
kind
of
keep
it
at
a
high
level
for
now.
B
So
anyway,
if
we
just
start
going
through
it
here,
we
start
out
with
networking
all
of
these,
basically
because
that's
kind
of
like
the
simplest
way
to
splice
it.
So
you
have
a
single
network
or
multiple
networks.
H
A
H
I
H
J
E
Seem
like
this
space
is
not
accurate,
because
even
in
the
single
address
space
we
have
nuts
or
firewalls
or
other
things
that
prevent
direct
port
connectivity.
So
the
characteristic
is
that
you
have
port
connectivity.
You
can
have
two
ports
next
to
each
other
in
the
same
address
space,
but
with
a
firewall
between
or
not
police
is
not
allowing
direct
connectivity,
and
then
you
are
still
not
and.
A
H
Single
or
quill
will
confuse
another
set
of
people,
so
you
I'm,
not
gonna,
get
overly
hung
up
on
it,
but
single
net.
This
is
not
just
you
not
subscribing
a
single
network.
That's
not
that
we're
describing
here.
Okay,
what
do
you
have
tempted?
Because
network
you
know,
there's
layer,
2
networks
is
layer,
three
networks,
you
know
so.
A
A
E
H
K
E
A
So
John,
would
you
mind
going
in
this
document
where
the
single
network
is
explained,
I,
I,
suppose
there
is
a
section
below
right
and
provide
the
comment
about
water.
You
know
right
terminology
here
and
also
names.
I
noticed
you
linked
in
the
meeting
notes,
a
document
that
has
just
a
few
words
in
it
outline,
but
there
is
nothing
more
and
I
know
there
is
more
to
it
so
reasoning.
The
correct
document.
A
E
More
comment,
speaking
of
documentation,
I
would
like
to
make
sure
that
the
place
which
is
documented
the
most
is
API,
because
that's
what
people
are
looking
at.
That
means
a
network
is
part
of
the
configuration
mesh
configuration.
It's
also
I,
think
part
of
the
labels
and
stuff
that
is
part
of
the
networking,
APs
and
judge
under
documented.
Currently,
yes,.
J
B
B
B
After
cluster
topologies,
we
start
breaking
down
control,
plane,
topologies
as
its
own
dimension,
just
for
various
purposes,
H,
a
all
the
things.
Basically,
there's,
there's
still
lots
of
I
guess
on
our
n
to
figure
out
exactly
how
we
want
to
break
this
down
so
I,
just
kind
of
left
it
as
a
top-level
bullet
for
now.
Identity.
Trust,
obviously,
is
a
big
thing,
so
I
figured
that
warranted
its
own
section
as
well.
B
I
B
B
So
the
last
bit
after
we've
talked
about
everything
else.
We
just
kind
of
go
through
the
tenancy
models
with
an
sto,
so
that
basically
comes
down
to
Tennessee,
namespaces
and
meshes,
and
that's
where
we
also
talk
about
mesh
peering,
AKA,
best
federation
and
then
the
last
bit
is
a
best
practices
section.
So
for
each
one
of
these
things
now
that
we've
explained
the
concepts
we
want
to
kind
of
go
back
and
talk
about
okay,
how
can
how
can
or
how
should
you
use
these
things?
J
Just
want
to
say
that
the
best
practices
will
probably
live
in
a
different
section
of
the
docs
than
the
rest
of
the
architectural
content.
It.
It's
think
that
we
might
have
to
discuss
in
the
documentation
working
group,
because
I
see
that
that's
living
in
that
in
many
cause,
or
there
are
many
possible
places
where
the
best
practices
could
live.
J
K
E
Won't
comment
here:
even
in
a
single
cluster,
you
may
still
have
network
policies
that
create
effectively
multiple
networks.
You
may
still
run
multiple
control
planes
and
that's
what
we
want
for
Canada
and
other
purposes,
and
you
still
can
have
multiple
identity
and
trusts
that
you
need
to
deal
with
so
I.
Don't
think
that
cluster
one
cluster
of
five
cluster
is
really
the
difference
here,
but.
K
E
Think
we
have
a
bit
of
documentation
is
a
bit
implied.
Is
the
fact
that
we
can
support
a
two
gateway?
I
mean
all
the
egress
vs.,
ingress
and
stuff
can
be
used,
I
mean
yeah,
it's
not
properly
documented
I
agree,
but
it's
very.
I
Much
should
we
bring
the
the
cluster
question
up
to
be
the
first
thing
and
kind
of
men
in
there
that,
like
most
of
the
rest
of
the
discussion
and
the
rest
of
this
section,
is,
is
more
relevant
when
there
are
multiple
questions
because
I
think
yes
well
in
theory,
a
lot
of
this
is
relevant
for
single
Buster.
It's
really
not
I
was.
K
E
Another
way
to
simplify
is
to
not
have
so
many
two.
If
we
say
that
Easter
hey
can
be
installed
in
multi
one
or
more
clusters,
and
you
know
there
is
no
one
cluster
versus
many
clusters,
it's
easier
that
can
be
deployed
wherever
and
you
don't
have
to
worry
about.
Hey
you,
I
have
one
cluster
I,
have
five
clusters
well,.
B
E
Point
is
not
it's:
it's
network
policies
are
starting
to
be
used
by
people
more
frequently,
and
network
policy
creates
exactly
the
same,
multiple
networks.
So
that's
not
that
theoretical
and
multiple
control
planes
is
our
one
of
our
goals.
What
for
the
Installer
an
operator
so
I
think
we
should
not
say
that
hey
if
it's
a
single
cluster
implies
single
Network
single
control,
plane
single
everything,
but
all
the
other
dimensions
are
identical
for
all
cases
and.
A
E
E
B
I
I
J
I
These
are
the
different
dimensions
you
need
to
think
about,
and
it
I
think
it
definitely
makes
sense
to
at
least
describe
a
couple
common
topologies,
not
per
dimension,
but
overall
right
so
like
we
can
talk
about
a
single
cluster
as
the
simplest
one.
But
then
you
know
comment
that
we're
being
set
ups
coming
with
that
not
the
best
practices,
though,
and
so
best
practices
might
tell
you
what
what
you
should
do
exempt.
The
examples
might
include
ones
that
are
common
with
existing
stuff,
but
maybe
you
want
to
move
away
from
and
we're.
J
Working
on
the
comprehensive
rail
to
try
to
give
our
users
that
comprehensive
guidance
and
that
overarching
story
that
you're
talking
about,
let's
go
and
do
a
single
cluster
and
give
you
guidance
on
how
to
do
that
in
a
specific
way.
But
we
can
take
the
conversation
offline
and
how
to
do
that
and
to
the
work
ducks
working
group,
because
there's
current
working
progress
towards
that
goal.
Okay,
there.
A
Are
some
common
topologies
and
we
already
inoculated
many
of
them
right?
We
just
have
take
back
that
documentation
and
map
it
to
these
dimensions.
Right,
maybe
one
cluster.
We
have
the
multi
cluster
single
network,
you
have.
We
have
the
multi
cluster
multi
network
as
well.
We
don't
have
yet
mesh
Federation
and,
like
trust,
Federation,
because
I
guess
this
is
not
yet
completely
left
out
right.
A
So
we
don't
have
like
anything
around
tenancy
is
more
document
if
and
I
think
it
was
the
expecting
like
more
from
this
presentation,
like
I
thought,
there'd
be
more
around
the
tenancy
models
in
the
Federation,
because
these
are
I.
Think
that's
where
the
there
is
lack
of
consensus
in
general,
like
what
is
Federation
versus
what
is
not.
E
B
L
E
M
A
I
K
I
Is
partly
why
things
may
confusing?
So
if,
if
we
focus
on
this
on
just
the
case
of
you
own
all
the
stuff
and
you're
using
SEO
on
all
of
it,
and
you
are
running
multiple
meshes
right,
then
there
doesn't
need
to
be
a
standard.
There
doesn't
need
to
be
a
bunch
of
people
involved,
it's
just
off
since
us
deciding
here's
how
this
works,
and
maybe
we
need
to
term
other
than
Federation
for
that,
because
I
think
people
think
that
means
a
bunch
of
other
stuff.
So.
A
Far
as
van
I
mean
I,
thought,
Federation
is
where
you
have
different
trust
domains,
not
necessarily
implying
multiple
meshes
owned
by
the
same
entity
right
so
it
looks
like
we
have
this
in-between.
What
would
that
be
called
may
be
different
than
mesh
Federation,
because
it's
not
so
much
of
a
Federation,
it's
mesh
connection,
maybe
so
mesh
merging.
E
I
I
E
A
E
I
I
A
E
L
E
I
I
E
I
One
of
the
things
we've
talked
about
is:
maybe
we
can
automate
like
in
a
multi
mesh.
Maybe
you
can
automate
at
some
other
Federation,
so
you
have
some
higher
level
Kannada
multi
mesh
operator
in
Alamut.
This
is
managing
all
this.
That
sense
of
Federation
and
sets
of
the
you
know,
keeps
the
trust,
bundles,
updated,
there's
a
discovery.
E
E
I
A
E
A
G
G
B
Id
will
probably
be
there
all
the
things
that
this
doc
would
have
to
talk
about,
would
be
there,
and
and
and
also
these
are
conceptual
Doc's,
so
I'm
not
sure
gosh
I
do
you
would
even
appear
in
these
Doc's
necessarily,
it
seems
more
conceptual
for
how,
at
a
you
know,
big
picture
diagrams.
It's
all
things
talk
yeah.
J
Include
an
implementation
detail
like
mesh
ID
on
the
conceptual
dot
on
the
architecture
version
of
the
dot.
We
would
definitely
include
it
so
keep
that
in
mind
we're
trying
very
hard
to
keep
features
and
implementation
details
in
different
documents
and
the
docs
we're
trying
to
do
a
very
job
of
doing
that.
Just.
E
E
B
Okay,
so
I,
that
was
a
great
discussion
on
Tennessee.
To
be
honest,
at
this
point,
I
almost
probably
didn't
even
need
to
list
out
the
simple
it's
a
tendency.
I
really
just
want
kind
of
want
to
get
more
or
less
the
top-level
bullets
if
these
are
the
right
dimensions.
So
networking
cluster
control
planes,
identity
in
trust
and
tendency
being
pretty
much
the
sum
total.
So
these
five
categories
being
the
dimensions
of
HDO
topology,
so.
A
I'm
not
sure
this
Federation
is
called
it
the
same
as
tenancy
right
because
you
might
have
a
single
cluster
and
if
your
tenancy
model
is
to
segment
it
by
namespace
right,
you
still
have
like
some
sort
of
multi
tenant
there
without
needing
to
do
Federation
or
multiple
meshes.
So
to
me,
the
multi
meshes
is
a
separate
thing
from
tenancy
and
I'm.
Not
even
sure
the
namespace
is
the
right
model
for
tenancy
is.
I
Part
of
the
reason
that
the
the
multi
mesh
got
pulled
under
tenancy
is
that
there
is
a
tendency
model
that
we've
seen
people
use,
which
is
cluster
as
unit
of
tenancy,
and
when
you
do
that,
because
things
mean
different
things
in
the
same
namespace,
you
actually
need
to
use
multi
mesh
to
connect
to
those
right.
There
was
you,
those
each
area
doesn't
match
at
least
that's
kind
of
a
proposal,
so
I
think
we're
missing
kind
of
that.
Linkage
between
cluster
is
the
tenant,
and
hence
you
need
Multi
mesh.
So.
E
I
I
E
This
token,
you,
in
a
single
class,
we
have
two
different
namespaces
that
are
completely
different
organizations,
because
again
you
are
whatever
provider
and
and
and
and
you
can
still
use
the
Federation
mechanism
protocols
to
communicate
me
to
do
namespaces.
If
you
choose
to
I,
mean
it's
a
explicit
export
and
an
explicit
consequence.
I
A
A
I
I
A
A
I
E
I
I
J
I
E
K
So
can
we
have
a
top
level
of
decision,
whether
you
have
single
mesh
or
multi
mesh
and
then
within
single
mesh?
You
have
choice
of
single
cluster
with
multi
cluster
and
then
within
single
cluster.
You
have
choice,
of
whatever
choice
is
available,
as
our
documentation
comes
online,
to
explain
how
to
do
things
and
same
with
multi
classes,
because
I
feel
like
this
document
dumps
a
lot
of
a
concept,
but
it
doesn't
help
me
as
if
I'm
a
user
to
trying
to
decide
what
type
of
topology
I
want.
K
B
Win:
that's!
That's
not
really
the
that's,
not
really
the
purpose
of
document.
This
document
is
before
you
get
to
that
document.
This
document
outlines
the
cut
the
conceptual
model.
What
these
things
mean,
what
is
what
are
the
network
topologies,
what
our
attention
models
and
then
there's
going
to
be
another
document.
That's
going
to
say
how
do
you
tie
all
this
together?
How
do
you,
how
do
you?
How
do
you
build
your
topology
to
meet
your
requirements?
That's.
J
Probably
best
practice
just
to
give
you
some
additional
context,
what
what
nate
is
saying
so
one
challenge
I
have
to
create
the
type
of
content,
you're,
saying
or
you're
describing
is
that
I
don't
have
a
clear
model
to
then
go
and
create
say
a
decision
tree
for
people
using
this
terminology
for
them
to
may
be
able
to
make
those
informed
decisions.
So
this
is
like
Nikki,
saying
the
priest
step
to
the
document
that
you
are
describing.
J
K
B
J
A
A
Think
Steve
look
like
Steve
laughs,
sorry
about
that.
So
hopefully
we
will
cover
in
the
next
movie,
neither
like
environments
or
networking
what
Steve
had
it
was.
Let
me
see
here:
oh
no,
he
actually
deleted
it.
It
was
about
the
first
dimension
of
multi
cluster,
single
and
multiple
networks.
Okay,
so
I
think
we're
all
good
and
we're
finishing
in
time.
Thank
you
very
much
for
joining
the
meeting,
bringing
meaningful
comments
and
see
you
again
in
two
weeks.
Bye.