2. Goals
• Networking
as
a
first
class
service
that
can
;e
together
network
“endpoints”
from
different
services.
• Provide
flexibility
in
networking
implementa;ons
with
plug-‐ins
that
implement
a
generic
network
interface:
– Network
segmenta;on/provisioning
– IP
address
management
– Business
logic
to
determine
what
customers
are
allowed
to
configure
with
networking.
3. Scope
• Network
service
only
manages
connec;vity
+
addressing,
which
are
shared
across
services.
• Compute,
Firewalls,
Load
Balancers,
VPN,
etc…
should
be
separate
services,
and
would
consume
the
networking
service.
4. Why?
• Why
1st-‐class
service?
– Cloud
is
about
orchestra;ng
all
kinds
of
services,
not
all
will
be
provided
by
compute
VMs.
Network
must
be
able
to
;e
together
all
such
services.
– Single
integra;on
point
for
networking
logic,
instead
of
having
to
do
it
in
each
service.
• Why
plug-‐in
design?
– Want
to
incorporate
“best-‐of-‐breed”
networking
solu;ons
that
solve
cloud
networking
challenges.
Best
solu;on
may
depend
on
provider.
– How
and
to
what
degree
customers
can
manipulate
networking
will
depend
on
provider.
Need
customer-‐aware
“business
logic”
to
manage
things
network
crea;on,
network
associa;ons,
IP
addresses.
5. Use
Case
Examples
• Private
tenant
network
with
VPN
network
connec;on.
• Firewall
service
with
interface
on
public
interface
and
interface
on
a
private
tenant
network.
• Mul;-‐;er
web
applica;on,
web
VMs
have
two
interfaces,
one
on
public,
one
on
private
backend
network
with
DB
servers.
6. High-‐level
Interac;ons
Customer
APIs
Network
Service
Generic
Network
API
Compute
Service
Network
Plugin(s)
LB
Service
Talks
to
Compute
Nodes
Talks
to
Network
Devices
(vSwitches,
physical
switches,
etc.)
Talks
to
LB
Nodes
7. What’s
Next?
• This
is
a
long-‐term
project.
Want
to
get
started
during
Bexar.
• Plan
to
create
group
of
interested
par;es
for
detailed
designed
discussions,
coordina;ng
coding.
• First
goal
will
be
to
implement
exis;ng
OpenStack
nova
networking
func;onality
as
“default
plugins”.