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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
