<html><body>
<p><tt><font size="2">Gabriel Bezerra <gabrielb@lsd.ufcg.edu.br> wrote on 03/10/2015 12:34:30 PM:<br>
<br>
> <br>
> Em 10.03.2015 14:24, Carl Baldwin escreveu:<br>
> > Neutron currently does not enforce the uniqueness, or non-overlap, of<br>
> > subnet cidrs within the address scope for a single tenant. For<br>
> > example, if a tenant chooses to use 10.0.0.0/24 on more than one<br>
> > subnet, he or she is free to do so. Problems will arise when trying<br>
> > to connect a router between these subnets but that is left up to the<br>
> > tenant to work out.<br>
> > <br>
> > In the current IPAM rework, we had decided to allow this overlap in<br>
> > the reference implementation for backward compatibility. However,<br>
> > we've hit a snag. It would be convenient to use the subnet cidr as<br>
> > the handle with which to refer to a previously allocated subnet when<br>
> > talking to IPAM. If overlap is allowed, this is not possible and we<br>
> > need to come up with another identifier such as Neutron's subnet_id or<br>
> > another unique IPAM specific ID. It could be a burden on an external<br>
> > IPAM system -- which does not allow overlap -- to work with a<br>
> > completely separate identifier for a subnet.<br>
> > <br>
> > I do not know of anyone using this capability (or mis-feature) of<br>
> > Neutron. I would hope that tenants are aware of the issues with<br>
> > trying to route between subnets with overlapping address spaces and<br>
> > would avoid it. Is this potential overlap something that we should<br>
> > really be worried about? Could we just add the assumption that<br>
> > subnets do not overlap within a tenant's scope?<br>
> > <br>
> > An important thing to note is that this topic is different than<br>
> > allowing overlap of cidrs between tenants. Neutron will continue to<br>
> > allow overlap of addresses between tenants and support the isolation<br>
> > of these address spaces. The IPAM rework will support this.<br>
> > <br>
> > Carl Baldwin<br>
> <br>
> <br>
> I'd vote for allowing against such restriction, but throwing an error in <br>
> case of creating a router between the subnets.<br>
> <br>
> I can imagine a tenant running multiple instances of an application, <br>
> each one with its own network that uses the same address range, to <br>
> minimize configuration differences between them.<br>
> <br>
</font></tt><br>
<tt><font size="2">While I'd personally like to see this be restricted (Carl's position), I know</font></tt><br>
<tt><font size="2">of at least one existence proof where management applications are doing precisely what Gabriel is suggesting - reusing the same address range to minimize the configuration differences.</font></tt><br>
<br>
<tt><font size="2">Ryan Moats</font></tt></body></html>