-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2015 06:34 PM, Gabriel Bezerra wrote: > Em 10.03.2015 14:24, Carl Baldwin escreveu: >> Neutron currently does not enforce the uniqueness, or >> non-overlap, of subnet cidrs within the address scope for a >> single tenant. For example, if a tenant chooses to use >> 10.0.0.0/24 on more than one subnet, he or she is free to do so. >> Problems will arise when trying to connect a router between these >> subnets but that is left up to the tenant to work out. >> >> In the current IPAM rework, we had decided to allow this overlap >> in the reference implementation for backward compatibility. >> However, we've hit a snag. It would be convenient to use the >> subnet cidr as the handle with which to refer to a previously >> allocated subnet when talking to IPAM. If overlap is allowed, >> this is not possible and we need to come up with another >> identifier such as Neutron's subnet_id or another unique IPAM >> specific ID. It could be a burden on an external IPAM system -- >> which does not allow overlap -- to work with a completely >> separate identifier for a subnet. >> >> I do not know of anyone using this capability (or mis-feature) >> of Neutron. I would hope that tenants are aware of the issues >> with trying to route between subnets with overlapping address >> spaces and would avoid it. Is this potential overlap something >> that we should really be worried about? Could we just add the >> assumption that subnets do not overlap within a tenant's scope? >> >> An important thing to note is that this topic is different than >> allowing overlap of cidrs between tenants. Neutron will continue >> to allow overlap of addresses between tenants and support the >> isolation of these address spaces. The IPAM rework will support >> this. >> >> Carl Baldwin > > > I'd vote for allowing against such restriction, but throwing an > error in case of creating a router between the subnets. > > I can imagine a tenant running multiple instances of an > application, each one with its own network that uses the same > address range, to minimize configuration differences between them. >
I agree with Gabriel on the matter. There is nothing inherently wrong about a tenant running multiple isolated network setups that use overlapping addresses (as there is nothing wrong about multiple tenants doing the same). There seems to be a value in disallowing overlapping subnets attached to the same router though. All in all, there seems to be no need to limit neutron API just because most external IPAM implementation do not seem to care about supporting the use case. It's also an issue that the change proposed is backwards incompatible. /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVAMCPAAoJEC5aWaUY1u57d/cH/A+nAuLrNaCPumjlOPJP90c3 4oSh0ioxEQw2uBRx1mWvcQle0M1U4Psy5CqIjeHgDhRlCNKB2gAYvm7/lCwZoCw7 pxLUerfZPFguNKYCUly1MYyo0gorycFgemoHKEFwHboDJfPdGYxdhW8HuemCClOG ZSeRzjO2rGaHU8XT+QWgI14UBiAu+XlQHy3UwUKEaffXOnja7noCU99/6d7+6TgF 5/RdFhpfn6pcRvLboiquo57w6N3q7moORgrGSMuP8cnMMTxo9/TLie+vMXmLPobB YmeG1ar1q0ouGKb6ZG7KokUyl6CdpgowZ6bqetPELjBLIO+uhcsJ6g9NvRl4T9o= =WQ3Q -----END PGP SIGNATURE----- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev