►
Description
Kubernetes Networking Panel: Collaborate on the Spec, Compete on Execution - Moderated by Robert Starmer, Kumulus & Susan Wu, Midokura
"Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Every pod has its own IP address and there’s no need to explicitly create links between pods. Mapping container ports to host ports is unnecessary.
This is an elegant design where pods can be treated much like VMs or physical hosts from the perspectives of port allocation, naming, service discovery, load balancing, application configuration and migration.
A group of people passionate about this topic from several leading and respected technology companies got together recently to form a Special Interest Group (SIG) to design the specification. The same companies that collaborated on the spec also compete on the implementation as long as they follow the following fundamental requirements (barring any intentional network segmentation policies):
• All containers can communicate with all other containers without NAT;
• All nodes can communicate with all containers (and vice-versa) without NAT;
• The IP that a container sees itself as is the same IP that others see it as.
Open source is a truly fascinating new world where people working for complementary and/or competing technologies can work together and accomplish a common goal.
This is the case of the Kubernetes Networking Special Interest Group (Kubernetes-networking-sig). The group banded together to help solve the following four networking problems:
1. Highly-coupled container-to-container communications;
2. Pod-to-Pod communications;
3. Pod-to-Service communications;
4. External-to-internal communications.
Hear from a panel ranging from open source networking projects, such as MidoNet, Contiv Calico, and Flannel, who implemented their networking for Kubernetes and get their unique perspectives on how their respective solutions augment native Kubernetes networking. With the opportunity to collaborate during the SIG and compete on the execution - this is a panel you don’t want to miss!"
About Susan Wu
Susan is the Director of Technical Marketing at Midokura. She has previously led product positions for Oracle/Sun, Citrix, AMD and Docker. She is a frequent speaker for industry conferences, such as Linuxcon, ContainerCon and Cloud Open. Honored by the Cloud Network of Women (CloudNOW) organization as one of the Top Women in Cloud for 2013, Susan is passionate about advancing women’s contribution to the cloud industry and serves on the Board of Directors for CloudNOW.
About Brandon Philips
Brandon Philips is helping to build modern Linux server infrastructure at CoreOS as CTO. Prior to CoreOS, he worked at Rackspace hacking on cloud monitoring and was a Linux kernel developer at SUSE. As a graduate of Oregon State's Open Source Lab he is passionate about open source technologies.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
We
have
a
nice
panel
here
today,
sort
of
going
across.
We
have
brandy.
Actually
do
you
guys
want
to
introduce
yourselves,
it's
probably
better
than
me,
trying
to
introduce
you
yeah,
oh
yeah,
well,
they're.
There
is
that
I
didn't
practice
that
all
morning,
so
let's
go
ahead
and
introduce
you
guys
as
well
sure.
B
C
D
E
A
Great,
so
look
one
of
the
one
of
the
biggest
things
you
know.
The
title
of
this
talk
was
sort
of
the
history
of
pulling
together
a
spec
and
then
still
being
able
to
differentiate
enough
well
something
along
those
lines
to
be
able
to
compete
in
the
space,
basically
making
Network
a
competitive
technology
as
well
as
a
core
technology.
One
of
the
things
that
I
saw,
having
been
through
a
number
of
open
source
projects
that
that
pulled
lots
of
underlying
resources
together
was
that
the
the
networking
specification
was
often
a
problem.
A
It
created
a
lot
of
sort
of
disconnect
between
different
vendors
and
one
of
the
things
that's
come
out.
I
think
out
of
out
of
the
the
KU
brunetti
space
specifically
is
a
networking
SPECT.
That
is
not
like
that.
It's
not
broken
at
its
base,
as
some
have
said,
and
instead
is
a
good
baseline.
At
the
same
time,
we
want
to
look
at
how
we
differentiate
that
and
I'd
love
your
opinion
on
how
how
you
got
to
the
point
of
a
stable
specification
to
begin
with,
and
then
we
can
dive
into
more
interesting
topics.
A
D
Since
I
have
a
mic,
I'll
go
and
start
so
I.
So
early
on
one
of
the
things
that
we
did
in
the
networking
sig
is.
We
were
very
careful
on
how
much
we
scope
so
I
think,
like
you,
have
to
start
off
with
small.
These
are
very
complex
topics
and
there's
a
lot
of
edge
cases
that
can
they
can
get
you
so
we
we
decided
to
start
off
with
well,
let's
talk
about
only
about
ingress
traffic
to
start
off
with,
and
let's
get
that
right
and
and
slowly
added
on
on
top
of
that.
D
So
so
I
think
part
of
it
is
just
like
really
good
scoping
and
getting
everyone
on
board
to
the
same
to
the
same
concept.
And
then
we
discussed
several
different
approaches
to
to
deal
with
it
and
I.
Think
that
that,
like
that
easy
I
can't
say
it's
easy,
but
rather
that
that
smaller
scope
I
think
led
a
long
way
towards
getting
the
getting
the
bottle
right.
C
So
you
know
I
think.
The
other
thing
is
that
we
really
focused
on
having
this
be
actually
user
requirement,
driven
rather
than
vendor,
driven,
which
is
some
of
the
things
that
have
bedeviled
other
projects
like
OpenStack
in
this
space.
You
know
we,
you
know,
what
do
people
want
to
do?
People
want
their
to
have
their
containers
be
able
to
talk
to
another
people
want
to
be
able
to
get
traffic
into
their
container
infrastructure.
The
spec
should
allow
you
know
the
end
user
or
the
operations
team
to
identify
what
behavior
they
want.
C
C
B
And
I
want
to
tell
you
back
just
a
little
bit.
I
think
one
of
the
reasons
that
Cooper
Nettie's
has
been
able
to
pretty
reasonably
insanely
move
forward
and
networking
is
early
on
the
the
core
team
at
KU
benetti's
said
it's
going
to
be
l3
networking
where
every
single
pod
is
going
to
get
an
IP.
All
the
services
are
going
to
get
a
unique
IP.
It's
going
to
work
with
plain
DNS,
bramley
use,
normal
forwarding
or
routing
I.
Think
that
fundamentally
changed
the
conversation.
B
Finally,
to
this
model,
where,
with
with
Cuban
at
ease
and
with
the
concept
of
pause
in
the
underlying
networking,
where
you
have
to
have
something
a
little
bit
more
advanced
as
baseline,
not
as
like
some
Sdn
initiative
inside
of
the
company
but
baseline
infrastructure,
and
so
I
think
that
was
that
was
a
pretty
bold
cus
p
move
that
the
the
team
made
early
on
in
Coober
Nettie's.
It's
enabled
a
lot
of
what
we
see
in
the
networking
space
today
on
it.
A
Balaji,
did
you
have
any
no
okay
great?
So
so
that's
that's
the
history,
so
we
got
into
a
stable
baseline
now.
The
next
question
is
there:
there
are.
Some
of
you
are
from
vendors
that
have
networking
technology.
Some
of
you
looked
at
networking
technologies,
a
core
way
of
differentiating
your
products.
A
Can
you
describe
maybe
some
of
the
ways
that,
even
though
the
spec
itself,
like
you
said,
is
very
abstract
in
its
in
its
modeling,
still
gives
you
the
flexibility
without
breaking
people's
ability
to
potentially
my
great
applications
between
different
environments,
because
it's
sort
of
a
consistency
from
that
view?
Is
there
something
specific
that
really
enables
the
the
ability
to
still
compete?
You
know
provide
interesting
differentiation
across
the
underlying
platforms.
Yeah.
B
Okay
got
it
so
is
this:
is
this
better?
Here's
so
before
we
get
further
along
in
the
conversation,
can
I
just
get
a
show
of
hands
who's
who's
used
network
policies
inside
of
Cooper
Nettie's?
Okay,
so
we
have
about
half
the
audience
that
sees
network
policies
so
just
want
to
set
some
baseline
here.
So
inside
of
human
Eddie's,
there's
the
concept
of
labels
labels
get
applied
to
essentially
every
object
in
the
system,
so
you
have
the
idea.
You
know
I.
F
C
This
this
becomes
interesting
thing.
I,
don't
think
you
necessarily
want
to
bake
lots
of
hooks
directly
into
the
base
API.
You
know
again.
This
leads
to
OpenStack
problems.
This
leads
to
a
whole
bunch
of
discontinuities
in
the
infrastructure,
and
you
now
get
vendors
arguing
over
this
hook
versus
that
hook.
C
You
know
what
you
need
to
have
in
that
spec
is
a
way
for
someone
to
express
the
intent
of
what
they
want
out
of
their
network
out
of
the
way
they
want
their
pods
to
communicate
once
you
have
that
intent,
I
might
render
it
very
differently
from
someone
else.
I
Tiger
might
render
some
very
differently
from
someone
else
and
the
way
I
render
it
might
be
unique
to
some
to
the
way
other
people
render
it
but
sauce.
Everyone
adheres
to
you
know.
C
At
the
end
of
the
day,
giving
having
the
same
end
result
a
can
talk
to
be
but
see
can't
talk
to
d
or
whatever
it
is.
It
allows
you
to
migrate.
The
minute
I
start
baking
proprietary
hooks
into
the
api's.
It's
you
know
it's
at
that
point.
We
might
as
well
call
it
done
and
walk
away
because
we'll
never
get
to
convergence
after
that.
C
C
You
know
this
container
to
be
sent
off
to
my
DPI
appliance
somewhere
else
in
the
infrastructure.
So
now,
all
of
a
sudden,
we
have
to
have
the
concept
of
tunnels
and
everything
else
within
the
underlying
network
layer.
In
order
for
that
hook
to
work.
That's
too
specific
a
case.
You
know,
if
you
want
to
render
that
you
could
say,
containers
labeled,
a
you
know,
should
be
able
to
talk
to
only
two
containers:
labeled
X.
C
If
those
containers
haven't
be
DPI
boxes
and
great,
you
know
that
now
I've
allowed
somebody
to
use
my
wonderful
DPI
containers,
but
I
haven't
burdened
the
API
with
something
specific
just
to
me,
and
then
someone
else
is
going
to
want
to
have
a
hook.
That
does
almost
exactly
the
same
thing
in
a
different
way.
Again:
witness
Neutron,
I'm
sorry,
I'm
picking
on
Neutron,
but
it's
such
an
easy
topic.
D
D
You
should
get
rid
of
all
of
your
your
SD
and
stuff
and
use
this
other
thing
instead,
because
we
only
support
that
would
would
not
come
across
very
well
so
by
providing
that
that
API
makes
it
easy
for
customers
to
leverage
their
current
st
ends,
but
I
give
them
most
or
all
of
the
benefits
that
goober
Nettie's
would
would
provide
for
them.
So
I
think
that
that's
key
to
key
to
the
success
is
those
very
clean.
Ap
is
I.
E
One
thing
I
guess
I
want
to
say
first
of
all-
is
that
the
batteries
included
with
replaceable
models
is
really
really
nice
in
the
overall
content,
canadian
ecosystem,
maybe
in
other
ecosystem
as
well.
But
this
is
sort
of
really
refreshing.
You
know
compared
to
like
where
I
came
from,
I
was
trying
to
create
a
virtual
switch
for
VMware,
hyper-v
and
kvm,
and
you
know
all
these
vendor
lock-in
that
you
have
to
fight
for.
E
So
this
respect
allows
you
to
actually
in
a
weight
on
top
of
that
when
we
looked
at
conte
back
in
you
know,
last
year
we
created,
you,
know:
IP
pure
IP
connectivity,
all
the
networking,
because
in
some
cases
people
want
to
always
so
it
allows
you
the
flexibility
to
vendors,
to
create
differentiation
and
add
value
to
it.
So,
in
a
way,
I
think
vendors
can
differentiate
and
I
think
the
spec
is
the
right
level.
A
A
So,
actually,
one
of
the
things
that
you
guys
mentioned-
you
talked
about
labels
and
how
important
labels
are
to
the
overall
environment
I,
actually
wonder
when
you're
talking
about
rendering
things
and
the
fact
that
the
underlying
infrastructure
gets
rendered
sort
of
as
the
underlying
infrastructure
needs
to
be.
One
of
the
topics
that
I
think
comes
out
of
that
question
is,
is
you
know,
using
labels
to
provide
segregation,
provide
a
layer
of
security?
Is
that
adequate?
Is
there?
Is
there
something
more
that's
needed
there,
or
can
you
define
enough
of
the
policy
model
through
labels?
A
C
We'll
take
a
stab
at
it,
I
think
the
answer
is
yes,
and
probably
it's
one
of
the
only
ways
you're
going
to
be
able
to
do
that.
So
if
we
think
back
to
the
way
we
used
to
build
virtualized,
network
environments
and
you'd,
say
okay,
I'm
going
to
take
this
application,
go
put
it
in
VLAN
1!
I'm
going
to
take
this
application,
put
it
in
VLAN
too,
so
everything
in
VLAN
1
can
talk
to
everything
in
VLAN
1.
Everything
we
went
to
can
talk
to
everything
in
VLAN.
C
To
that's
already
a
problem
go
ask
the
guys
at
sony
about
having
ubiquitous
connectivity
within
a
a
realm.
It
ends
badly,
usually,
but
to
now
I
need
as
we
circulating
this
cloud
native
environment.
I
need
to
have
things
in
eight
and
one
talk
two
things
into,
but
they're,
not
all
the
things
in
one
you
talked
to
all
things
into,
and
so
that
requires
firewalls.
So
you
also
get
this
very
complex
environment.
C
That's
also
fairly
static
and
hard
to
configure
if
I
get
to
if
instead
I
start
sticking
labels
on
things
these
labels
say
this
is
X
and
annex
should
be
able
to
talk
to
why
it
doesn't
really
matter
where
the
X's
and
Y's
are
in
the
infrastructure.
It
doesn't
matter
if
I
have
one
of
them
or
a
million
of
them
or
there's
five
of
them,
one
second
and
40
of
them
the
next.
Second,
the
policies
still
rendered
on
it.
C
If
I
tried
to
do
this
via
vlans
or
VX
lands
or
I
tried
to
do
this
by
configuring
firewalls.
To
do
this,
yours
not
going
to
be
able
to
do
that.
You
know
the
the
policy
is
tied
to
the
endpoint.
What
that
endpoint
is
expressing
its
ldap
server,
it's
a
web
front
end,
and
then
you
attach
your
policy
to
that.
That's
the
way
you
can
actually
get
repeatable
policy
enforcement
doing
it
any
other
way.
I
think
is
going
to
be
interesting.
D
So
I
I
can't
think
of
any
reason
why
we
would
need
a
different
model
from
from
labels.
I
think
that
that
should
be
should
be
sufficient.
But
that
being
said,
something
that
we
have
to
be
careful
is
we're
talking
about
the
hooks
earlier.
We
have
to
make
sure
that
we
don't
end
up
with
the
same
problem
where
your
label,
if
you
have
a
label,
you
can
stick
arbitrary
data
and
then
that
becomes
your
vendor
side
channel
hook,
that
that
allows
you
to
do
things
beyond
what
the
API
gives
you.
B
Sure
so,
I
think
the
root
of
that
question
is
really
around
two
things:
ensuring
that
the
system
and
whatever
security
system
you
put
in
place
for
your
networking,
always
fails
close.
So
that
means
that,
like
be
by
default
things
and
your
network
are
things
in
your
cluster.
Without
labels
or
things
that
don't
comply
with
policy
are
not
able
to
route
and
then
also
KU
benetti's
over
the
last
two
releases
have
has
gotten
pretty
rich
role-based
access
control.
A
Well
that
actually
negated.
My
next
question
so
sorry
well,
I
was
I
was
going
to
ask.
You
know
how
does
rolls
base
access
and
labels
and
the
sort
of
the
almost
the
beginnings
of
multi
tendency
that
gets
derived
from
that
start
to
come
together.
I've
talked
to
a
couple
of
companies
that
are
trying
to
understand
how
to
better
deal
with
multi-tenancy
within
the
current
goober
Nettie's
environment.
I
know,
there's
a
lot
of
work
going
on
in
that
space.
A
B
Essentially,
every
single
resource,
whether
that
be
a
network
policy
resource
or
a
pod
or
a
namespace,
is
able
to
have
policy
applied
to
it
and
I
think
what
will
fall
out
of
it,
similar
to
what
we've
seen
with
labels
inside
of
Cuba
Nettie's
is
we
now
need
to
learn
the
patterns
that
make
sense
for
those
for
that
really
powerful
framework
that
we
got
it's
similar
to
to
unix,
extended
attributes
and
acls
like
we
created
a
really
powerful
system?
Now?
What
are
the
patterns
that
are
going
to
actually
be
useful?
B
I
I
would
guess
that
a
lot
of
it
comes
down
to
namespaces
map
to
small
groups.
Like
you
know,
single
pizza,
size
groups,
and
that
is
that
will
be
the
foundation
that
a
lot
of
the
businesses
start
from.
Is
this
name's
Jace
I
trust
this
namespace
house,
its
network
policy?
These
are
the
people
that
are
in
that
namespace
and
if
something
goes
wrong,
I
know
who,
to
page.
D
So
talking
about
security
and
change,
the
focus
slightly.
So
if
you
look
at
something
like
some
of
security
and
labels
perspective,
and
then
you
look
at
something
like
selinux
selinux
is
labels
and
an
action
based
upon
what
those
labels
are.
So
this
is
a
well-understood
bottle.
There
is
complexity
that
arises
as
as
was
mentioned,
but
but
in
the
whole
it
should
provide
a
really
good
base
to
to
build
out
effective
security.
So
I.
E
Think
the
you
another,
I
guess
that
your
question
was
like
it
always
access
for
the
overall.
Can
I
create
a
class
of
connected
application
in
versus
a
network
specific
policy?
I
think
the
indo-pacific
pauses
should
be
handling
the
network
specific
part
of
it.
The
role
based
access
control
should
be
accessing,
like
should
I
know,
deploy
the
application.
So
I
think
these
are
two
different
things.
You
can
look
at
right.
C
We
already
have
some
folks,
you
know
in
this
space
even
advance
of
our
back,
and
so
you
know
I've
seen
people
that
have
done
things
like
in
their
see
I
CD
chain
you
know
validate.
If
the
person
doing
the
check-in
is
allowed
to
assert
that
label
in
the
pod
spec
and
if
they're,
not
the
CI,
fails
or
the
the
you
know
this.
You
know
so
there's
many
ways
of
solving
this.
Obviously
it's
best
if
it's
solved
within
Cooper
Nettie's,
but
there
are
people
open,
re,
tackling
this.
C
The
interesting
thing
about
using
labels
you
can
use
namespaces
and
namespaces
are
one
way
of
segregating
things,
but
you
might
end
up
how
do
you
represent
potentially
multiple
hierarchies
of
things
right?
So
the
you
know
its
name.
Spaces
are
a
useful
tool,
but
you?
How
do
you
do
like
subgroups
within
groups
within
tenants?
So
the
met?
You
start
thinking
about
multi
tag
heat
the
term
multi-tenancy?
Actually,
because
you.
C
Is
not
you
know?
How
do
you
split
tenants
up?
You
know,
so
it's
more
of
a
is
this
thing
in
a
group
and
what
are
the
app?
What
are
the
characteristics
of
this
group?
There
might
be
subgroups
and
it
might
be
a
Venn
diagram,
that's
complete
or
incomplete,
and
those
are
the
labels
you
attach
and
then
who
is
allowed
to
attach
those
labels
is
once
you
can
control
that
via
are
back
or
via
other
mechanisms.
C
You
have
a
really
rich
security
mechanism
that
doesn't
import
a
philosophy
of
how
you
should
organize
your
organization
or
your
service.
It
can
become
much
more
I.
Don't
make
you
organize
your
organization,
the
way
I
thought
about
it.
You
can
organize
the
organization
that
makes
it
way.
It
makes
sense
for
you.
A
Yeah,
that's
very
good,
so
switching
gears
just
a
little
bit
one
of
the
other
sort
of
topics
in
the
network.
Space,
of
course,
is
that
underlying
resource,
the
the
actual
networking
technology
or
non
technology
in
some
cases
that
that
some
might
deploy
under
a
Cooper
Nettie's
environment.
What
do
you
guys
think
about
the
need
for
or
the
desire
to
have
a
software-defined
Network
sitting
underneath
Cooper
Nettie's,
and
is
that
even
really
necessary.
F
B
E
B
Think
one
of
the
beauties
of
the
Cooper
Nettie's
ecosystem
and
all
the
networking
technologies
and
vendors
that
have
been
involved
so
far.
Is
that
really
we
have
a
full
spectrum,
and
this
is
a
huge
advantage
for
Cuba
Nettie's.
It
means
that
we
can
go
in.
So
one
of
the
first
things
we
did
was
core
OS
when
Cooper
Nettie's
was
really
young.
B
We
said
this,
this
networking
policy,
this
l3
everything
network
policy,
is
going
to
be
a
challenge
for
a
lot
of
people,
so
we
built
this
thing
called
flannel
and
we
still
see
a
ton
of
usage
of
this
where
we
actually
are
tunneling
like
via
VX
land
between
machines
with
single
IPS,
to
create
this
pod
network.
This
is
super
important,
like
very
few
individuals
want
to
talk
to
netops
just
to
get
by
q.
Brunette
is
running
inside
their
data
center.
B
It
just
slows
down
the
project
and
it
slows
that
so
it's
important
to
have
these
the
spectrum.
I,
don't
think
it's
necessary.
Most
people
don't
go
into
production
by
like
having
a
coup.
Brunetti
specific,
like
VX
land
thing,
some
do,
but
it's
it's
the
having
that
flexibility
means
that
Cooper
Nettie's
is
able
to
land
inside
of
an
environment,
proved
out
the
model
a
little
bit
and
then
build
confidence
that
everything
we
can
sort
out.
B
Networking
we
know
how
to
route
packets,
like
it's
a
great
challenge,
to
put
here
the
networking
team
inside
of
an
enterprise
so
I
this
l3
network.
Do
you
think
you
can
route
it
like
it's
a
good
ship,
it's
a
good
challenge
and
so
I
think
it's
important
just
for
an
adoption
and
called
that
confidence
building
that
every
organization
goes
through
and
these
sorts
of
changes.
C
So
you
know
Brandon
sorry
hit
it.
You
know
kuber
Nettie's.
These
are
IP
addresses.
These
are
IP
endpoints,
so
pretty
much
anything
that
can
get
IP
from
A
to
B,
be
it
and
over
labia
de
native
routed
infrastructure
is
going
to
work.
You
know
and
that
the
nice
thing
about
that
is.
We
know
how
to
do
that
at
scale.
We've
been
doing
it
for
a
real
a
long
time.
It's
called
the
public
internet.
So
we
know
that
there's
a
really
large
proof
case
that
IP
networks
generally
work.
C
So
if
I
want
to
put
them
over
a
overlay
Network,
you
know
some
kind
of
end
cap
network
that
works.
If
I
want
to
run
it
natively
that
works
too
and
in
fact
I
may
use
different
techniques,
depending
on
where
I
deploy
I
might
use
an
overlay
in
SE,
Asia
and
I
might
run
native
network
in
in
my
private
cloud.
C
Cabernets
doesn't
care
so
I,
don't
think
an
SDN
is
and
hate
the
term
sdn
as
well.
I,
don't
think
you
know.
Cooper
neighs
is
a
software-defined
Network
in
itself.
You're
controlling
the
network's
behaviors
by
API
calls
it's
not
an
overlay
Network.
You
can
run
it
over
an
overlay
network
or
not
I.
Think
the
interesting
challenge
for
someone
is
if
they
decide
they're
going
to
deploy
Cooper
Nettie's
with
an
overlay,
Network
and
they're
running
on
top
of
VMs
they're
on
top
of
another
overlay
Network.
C
So
now
you
have
the
problem
with
1,400
bytes
of
payload
and
I
of
header
and
Hunter
bytes
of
payload,
all
right,
so
I
now
get
to
troubleshoot
the
Cooper
Nettie's
overlay
on
top
of
the
vm
overlay
on
top
of
the
underlying
network,
and
you
know
good
luck,
trying
to
figure
out
why
your
network
isn't
coming
up,
but
you
know
you
can
do
that
if
you
want,
but
it's
it's
not
required
this.
This
is
just
IP
traffic.
However,
you
want
to
get
the
IP
packets
from
A
to
B
is
fine.
D
So
they've
mentioned
also
stuff,
I
was
going
to
say,
but
the
one
thing
about
Cooper
Nettie's
networking
model
is
that
it's
the
core,
the
basic
requirements
to
get
Cooper
Nettie's
up
and
running,
is
very
small,
so
it
things
like
a
pod
should
be
able
to
communicate
with
another
with
another
pod.
The
the
host
should
be
able
to
communicate
with
pods
and
like.
If
you
meet
these
small
set
of
requirements,
then
you
should
be
able
to
get
a
working
Cooper
Nettie's
cluster.
E
Co,
one
use
case
that
I
think
we
have
seen
actually
one
of
the
customers
for
Conti
was
sapa.
Diba
was
a
public
reference.
Customer
was
sort
of
a
mixed-mode
use
cases
right,
yeah,
VMS
still
in
a
part
of
the
application,
and
you
want
to
have
a
application,
not
just
defined
container
only
application
but
like
a
overall
vm
plus
bare
metal
plus
containers
for
them.
The
containers
can
we
come
up
and
go
quickly
that
you
know
communities
can
bring
it
up
or
somebody
can
bring
up
those
quickly,
but
not
the
other
ones.
E
The
VMS
and
the
paid
models
are
sort
of
there,
but
if
you
want
to
connect
them
all
of
them
together
and
operator
wants
to
have
a
holistic
view
of
VN
plus,
you
know
all
of
them
part
of
a
single
application,
and
you
want
to
have
policy.
That's
in
to
end,
let's
say:
I
just
containerized
a
front
end,
for
example,
for
whatever
reason
right
and
then
leave
there
are
some
stuff.
The
way
it
is
I
want
to
have
a
holistic
application
view.
I.
Think
that
helpful.
E
So
one
of
the
demos
we
have
I
mean
I've,
not
we
have
anymore,
but
one
other
thing
was
that
can
t
has
in
the
food
is
a
with
integration
with
or
a
CI
Cisco
ACI,
which
is
a
vm
HC
d
BM
actually
is
VM
and
then
web
tier
and
apps
here
in
container
format,
and
then
the
integration
allows
you
to
have
into
and
view
for
contracts
or
policies.
So
that's
a
use
case,
I've
seen
Arriba,
otherwise,
one
of
the
customers.
I
think
they
spoke
in
a
couple
of
forums.
There's
few
customers
like
that.
E
So
that
would
be
the
use
case
where
you
want
the
automation
of
the
underlay
to
be
as
fast
as
a
Cuban
eighties.
Now
you
don't
want
to
have
to
manually,
do
it
after
the
fact
or
things
like
that,
so
you
want
to
have
automation.
So
that's
why
I
would
say
sdn
at
to
a
point.
We
all
worked
in
the
SDN
companies
before
so
I
know
what
Sdn
means,
but
if
it
means
the
automation
of
physical
switches
sure
so.
A
Is
that
may
be
a
better
way
of
thinking
of
it?
Is
that
you
know
you
have
this
abstraction
now
from
the
network
layer,
and
you
want
to
map
that
to
or
from
from
the
Cooper
Nettie's
network
interface
model
right,
that's
an
abstraction
model,
and
then
underneath
that
you
can
have
an
SDN,
so
you
can
have
whatever
you
know,
advanced
technology,
controller-based
networking
model
you
need.
If
you
need
that
in
your
environment,
is
that
may
be
a
better
way
of
thinking
about
it?
Yeah.
E
I
think
you
know
simply
the
existing
technology
of
doing
it
manually
doesn't
work
anymore
right.
When
you
talk
about
containers,
is
you
know,
people
don't
want
to
create
a
ticket
to
create
an
intro
configuration
for
you,
and
so
so
so
so,
if
you
do
have
the
other
infrastructure-
and
there
is
a
lot
of
interactions
with
the
existing
structure,
I
definitely
see
a
value
there.
So
what
it's
worth.
C
E
Think
I
think
it's
not
needed
I'm
just
saying
is:
it
will
be
helpful
to
automate
it
right.
You
need
to
be
able
to
automate
some
well
yeah.
You
could
sure
automate
I'm.
This
thing
is
there's
ways
to
automate.
Of
course,
all
I'm
saying
is:
if
sdn
solution
solves
that
problem
sure,
but
what
I'm
saying
is
it's
it's
as
a
use
case.
That's
all
so.
A
A
If
that's
your
interface
into
your
application,
then
that
can
drive
any
automation
it
needs
to
drive
which
might
be
you
know,
kicking
off
a
bash
script,
even
if
it
comes
down
to
that
level
of
control,
all
right,
so
yeah,
okay,
so
I
I
think
we
have
a
couple
minutes
left
still
do
people
have
questions
or
should
I
ask
one
more
leading
question,
hopefully
leading
question:
there
are
some
questions
in
the
audience
yeah.
Let's.
F
So
I
work
for
comcast
there's
a
couple:
calm
casters
in
this
room,
one
of
our
biggest
challenges
in
the
network
architecture
right
now
is
migrating
to
ipv6.
We
have
huge
initiatives
all
across
the
board
with
ipv6
would
love
to
know
more
about
ipv6
and
cooper
Nettie's,
and
and
go
into
more
detail
with
that.
D
C
Mean
I
think
the
if
you
look
at
it,
we've
said
that
Cooper
Nettie's
is
an
IP
per
pod.
There's
really
nothing
in
that.
That
says:
that's
gotta
be
ipv4
or
ipv6
and
I
can't
speak
for
any
of
the
other
solutions
out
there.
But
calico
is
v6
native
has
been
from
day
one.
That's
fine,
it's
just
another!
It
you
know
it's
ipv4
versus
ipv6.
The
code
paths
are
basically
the
same.
C
I
think
the
orchestration
folks
have
been
a
little
bit
laggard
Lee
in
doing
that,
mainly
because
a
lot
of
people
deploy
these
things
on
public
cloud
and
our
public
cloud
vendors
have
not
seen
the
light
to
deploy
v6.
You
can't
really
get
v6
on
on
AWS
or
GCE
or
anything
at
this
point.
So
until
those
platforms
support
v6,
it's
going
to
be
hard.
C
G
D
C
H
C
Let
me
ask
you
what
the
difference
between
the
magic
bits
signifying
an
l2
label
are
how
they're
any
different
from
the
magic
bits
that
happen
to
be
an
IP
address
is,
at
the
end
of
the
day,
that
filter,
for
example,
is
being
deployed
on
that
host.
If
somebody's
got
root,
access
on
that
host
to
undo
the
l3
filters,
they
most
certainly
have
the
ability,
then,
to
reconfigure
OBS,
to
put
you
in
a
different
l,
two
segments.
C
So
I
think
you
get
to
do
it.
Brandon
just
said
these
things
have
to
fail
closed.
These
have
to
be
places
where
you
grant
permission.
I
want
to
open
for
43
from
these
things,
not
I
want
to
block
everything
else,
so
it
you
have
to
sort
of
think
it
fail,
closed
versus,
fail,
open
model.
Anyone
else
I
mean.
E
I
think
that
there
should
be
choices
right
in.
I
think
not
it's,
not
every
customer
or
every
scenario
is
going
to
be
the
same.
I
think
the
best
ways
to
implement
different
options,
and
you
choose
based
on
that.
So
we
have
seen
in
the,
for
example,
can
t
we
implemented
a
sort
of
l2
native
l3
and
always
right.
So
these
are
all
the
way
you
connecting
writing
some
people.
Are
you
know
whatever
we
I
don't
want
to?
You
know,
like
argue
with
anybody
like
you
know,
this
is
not
the
right
way.
E
D
D
That
being
said,
one
area
that
I
that
I
think
that
we
could
probably
spend
all
the
time
focusing
on
is
how
do
we
segment
the
control
plane
from
the
from
the
data
plane
and
that,
I
think,
would
give
us
a
real
win,
because
even
if
they
took
over
that
particular
pod,
then
that
that
it
doesn't
make
it
impossible.
But
it's
yet
another
step
that
has
to
be
taken
before
you
can
compromise
your
your
control
plane.
C
C
A
A
C
C
A
D
Think
the
big
the
biggest
thing
that
it's
going
on
right
now,
I
think,
is
the
work
in
multi-tenancy
that
we
spoken
about,
and
I
think
that
multi-tenancy
is
going
to
open
up
a
lot
of
use
cases
both
not
just
from
like
host
but
also
within
enterprise
environments,
in
order
to
to
help
drive
in
order
to
drive
adoption
of
various
application.
So
I'm
really
excited
about
those
efforts.
I
think.
E
I
was
looking
at
the
signal
networks.
Sake
group
there's
really
like
to
open
issues.
Basically
you
know,
maybe
you
know
the
next
big
idea
is
not
there
yet,
and
so
we
need
to
add
more.
If
you
need
some
features,
go
ahead
and
submit
an
issue
or
something
and
work
through
the
system
and
other
thing,
I
guess
would
be
network
s
la's
monitoring
piece.
Maybe
you
can
define
policy
that
to
monitor
certain
application
or
certain
part.
You
know,
I'm
not
sure,
I'm
not
saying
it's
it's
the
next
big
thing.