Getting to Unified Network Services<br />Erik Carlin<br />erik.carlin@rackspace.com<br />
The Time for Cloud Networking is NOW<br />The world wants:<br />1. Security<br />Hypervisor becoming more accepted as a mu...
History<br />NetworkService<br />Rackspace/Nicira<br />NetworkContainers<br />Cisco<br />NetworkService<br />Citrix/Racksp...
Process & Thoughts<br />Started conversation with people who drafted the blueprints<br />Goal was convergence so we’re not...
14 hours<br />Etherpad Discussion:<br />http://tinyurl.com/osnetwork<br />Wiki Summary:<br />http://wiki.openstack.org/Net...
Participants (I know I missed some – sorry!)<br />
Conclusions<br />There is no more “NaaS”<br />Networking capabilities are diverse enough that we don’t want a single monol...
Diablo Goals<br /> “Quantum” Service<br />Def: The smallest amount of a physical quantity that can exist independently<br ...
Diablo Goals<br />IPAM Service<br />(still need a project name)<br />Provide IP address management capabilities across ser...
Diablo Goals<br /> “Donabe” Service<br />Def: Japanese clay pot<br />Ability to create “containers” of cross service cloud...
Diablo Goals<br />Nova Refactoring to Support These Services <br />Introduce using a parallel approach to minimize disrupt...
Questions?<br />
Upcoming SlideShare
Loading in …5
×

Getting to Unified Network Services

2,198 views
2,142 views

Published on

Kickoff presentation at OpenStack Diablo design summit explaining process of rationalizing different blueprints and introducing proposed plan for networking in OpenStack.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,198
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
205
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Hypervisor – PCI 2.0 compliance on EC2APIsApps and ecosystem tools still workQueryable endpoint catalog, versions, and extensionsNo lock-inPeople use HA Proxy instead of ELBBut, same SW means you can feel comfortable leveraging and migrating those resourcesVM image formatGlance image conversionNetwork federationFederated zones in nova is coolAlso need federated network
  • Successfully aligned on overall approach and target diablo deliverables
  • Define the logical networking modelDefine the standard edge interface points between quantum and “interface services”Define a pluggable way in which quantum and interfaces services interact to “plug in”
  • Start with network containers
  • Getting to Unified Network Services

    1. 1. Getting to Unified Network Services<br />Erik Carlin<br />erik.carlin@rackspace.com<br />
    2. 2. The Time for Cloud Networking is NOW<br />The world wants:<br />1. Security<br />Hypervisor becoming more accepted as a multi-tenant security boundary<br />Now want network isolation<br />Workload Migration and Cloud Bursting<br />Canonical APIs (+ extensions)<br />No lock-in <br />VM image format<br />Network federation<br />
    3. 3. History<br />NetworkService<br />Rackspace/Nicira<br />NetworkContainers<br />Cisco<br />NetworkService<br />Citrix/Rackspace/Nicira<br />NaaS Core Design<br />Intel<br />NetworkServicePOC<br />NTT/Midokura<br />Unified<br />Plan<br />
    4. 4. Process & Thoughts<br />Started conversation with people who drafted the blueprints<br />Goal was convergence so we’re not presenting competing blueprints<br />Rationalized conclusions are still proposals<br />Today represents a point in time snapshot, we’re not done<br />This is the beginning, we want and need more involvement<br />
    5. 5. 14 hours<br />Etherpad Discussion:<br />http://tinyurl.com/osnetwork<br />Wiki Summary:<br />http://wiki.openstack.org/NetworkServiceDiablo<br />
    6. 6. Participants (I know I missed some – sorry!)<br />
    7. 7. Conclusions<br />There is no more “NaaS”<br />Networking capabilities are diverse enough that we don’t want a single monolithic network service<br />Decompose into independent OpenStack network projects/services that are individually deployable but can work as a suite<br />e.g. Core L2/L3, IPAM, FW, LB, etc. <br />Assess service granularity over time to ensure not too fine grained<br />Containers are extremely valuable but broader than network and should become it’s own higher level service<br />Start with simple building blocks and add to them over time<br />Experimental in diablo<br />
    8. 8. Diablo Goals<br /> “Quantum” Service<br />Def: The smallest amount of a physical quantity that can exist independently<br />Most basic network building block service<br />Expose an L2 network and enable other services (compute, LB, FW, etc.) to attach to it<br />L2 bridging / federation a latter step that may be in Quantum or a separate VPN service<br />
    9. 9. Diablo Goals<br />IPAM Service<br />(still need a project name)<br />Provide IP address management capabilities across services including nova, LB, FW, etc.<br />Could evolve into a broader repository of network information<br />
    10. 10. Diablo Goals<br /> “Donabe” Service<br />Def: Japanese clay pot<br />Ability to create “containers” of cross service cloud resources and have them assembled (and potentially managed)<br />Containers can be hierarchical<br />High level orchestration service<br />Think DCaaS or AWS Cloud Formation<br />
    11. 11. Diablo Goals<br />Nova Refactoring to Support These Services <br />Introduce using a parallel approach to minimize disruption to nova<br />Several potential ways of doing this and need feedback from nova devs<br />
    12. 12. Questions?<br />

    ×