Open Stack

Thanks for sharing your thoughts on the mailing list.
I will read them carefully and provide my comments soon.

In the meanwhile, I advice you file a blueprint, possibly with more
design/implementation details.
The blueprint you reference aimed at solving a much easier problem.
In the spec (or the whiteboard) it was mentioned that a full solution to
the issue of network domain sharing was out of its scope.

Salvatore


On 5 July 2013 16:11, Zang MingJie <zealot0630 at gmail.com> wrote:

> Hi:
>   Currently we are working on a problem of neutron network isolation
> and inter-communication. Currently neutron has private network and
> shared network, but they are not flexible. The private network cannot
> access other network, and the shared network is fully open. To solve
> this problem, we got another design.
>
>   First, introduce a new concept "Zone", basically each Zone is a
> isolated ip address space, like VPN-Site in cisco vrf or route
> distinguisher in mpls-vpn or bgp-vpnv4. Each network must belong to a
> Zone. And we must ensure ip address is unique inside every Zone, which
> means no duplicated ip in the same Zone. By this assumption, given
> (Zone,ip-address) tuple we can locate a unique port.
>
>   Then, we implement our l3 agent, make sure all networks in the same
> Zone can communicate each other, and network in different Zones can't
> communicate. Each tenant can create limit number of Zones (quota) and
> share it to others for intercommunication.
>
>   By separate Zone from tenant, we get more flexible control of
> network scope. To maintain backward compatibility, when migrate,
> create a Zone for all shared network and create Zones for each tenant.
>
>   Data Model:
>     * add a new resource: Zone (CRUD)
>     * add a new parameter Zone to network
>     * deprecate 'shared' param of network
>     * a network w/o Zone and is shared belongs global Zone
>     * a network w/o Zone and is not shared belongs the Zone which has
> the same id of tenant-id
>
>   API change:
>     * add API to grant/revoke Zone access to others (should we support
> revoke ?). a tenant only permitted to create network in the Zone he
> can access.
>
>   Implementation overview:
>     * l3-agent should be changed to suite the requirement, don't
> launch l3-agent per node*tenant, but per node*Zone. This should be
> very easy.
>     * Ensure ip uniqueness inside Zone when creating subnets
>
>   Related BPs:
>     *
> https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130706/a5842413/attachment.html>