[openstack-dev] [Openstack-dev] [Neutron] Shared network improvement (RFC)
Zang MingJie
zealot0630 at gmail.com
Fri Jul 5 14:11:21 UTC 2013
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
More information about the OpenStack-dev
mailing list