<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>This has been settled and we're not moving forward with it for Kilo. I agree tenants are an administrative concept, not a networking one so using them for uniqueness doesn't really make sense.</div>
<div><br>
</div>
<div>In Liberty we are proposing a new grouping mechanism, as you call it, specifically for the purpose of defining uniqueness - address scopes. This would be owned by a tenant but could be shared across tenants. It's still in the early stages of definition
though, and more discussion is needed but should probably wait until after Kilo is out!</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, March 12, 2015 at 6:38 AM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>My concern is that we are introducing new objects in Neutron that are scoped to a tenant and we don't have anything else like that right now. For example, I can create 100 3-tier topologies (router + 3 subnets/networks) with duplicated names, CIDRs, etc
between all of them and it doesn't matter if I do it on 100 different tenants or all under the same tenant.<br>
</div>
<div><br>
</div>
<div>Put a different way, tenants don't mean anything in the Neutron data model. They are just a tag to use to enforce quotas, policies, and filters on incoming API requests. Uniqueness shouldn't come from 'x' + tenant_id.</div>
<div><br>
</div>
<div>It seems like what is being introduced here is going to fundamentally change that by forcing the creation of separate tenants to have overlapping IPs. I think the barrier should be very high to introduce anything that does that.</div>
<div><br>
</div>
<div>Can you elaborate why tenants are used for uniqueness for IPAM instead of having a separate grouping mechanism?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 11, 2015 at 3:24 PM, Ihar Hrachyshka <span dir="ltr">
<<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div>
<div class="h5"><br>
On 03/10/2015 06:34 PM, Gabriel Bezerra wrote:<br>
> Em 10.03.2015 14:24, Carl Baldwin escreveu:<br>
>> Neutron currently does not enforce the uniqueness, or<br>
>> non-overlap, of subnet cidrs within the address scope for a<br>
>> single tenant. For example, if a tenant chooses to use<br>
>> <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> on more than one subnet, he or she is free to do so.<br>
>> Problems will arise when trying to connect a router between these<br>
>> subnets but that is left up to the tenant to work out.<br>
>><br>
>> In the current IPAM rework, we had decided to allow this overlap<br>
>> in the reference implementation for backward compatibility.<br>
>> However, we've hit a snag. It would be convenient to use the<br>
>> subnet cidr as the handle with which to refer to a previously<br>
>> allocated subnet when talking to IPAM. If overlap is allowed,<br>
>> this is not possible and we need to come up with another<br>
>> identifier such as Neutron's subnet_id or another unique IPAM<br>
>> specific ID. It could be a burden on an external IPAM system --<br>
>> which does not allow overlap -- to work with a completely<br>
>> separate identifier for a subnet.<br>
>><br>
>> I do not know of anyone using this capability (or mis-feature)<br>
>> of Neutron. I would hope that tenants are aware of the issues<br>
>> with trying to route between subnets with overlapping address<br>
>> spaces and would avoid it. Is this potential overlap something<br>
>> that we should really be worried about? Could we just add the<br>
>> assumption that 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<br>
>> to allow overlap of addresses between tenants and support the<br>
>> isolation of these address spaces. The IPAM rework will support<br>
>> this.<br>
>><br>
>> Carl Baldwin<br>
><br>
><br>
> I'd vote for allowing against such restriction, but throwing an<br>
> error in case of creating a router between the subnets.<br>
><br>
> I can imagine a tenant running multiple instances of an<br>
> application, each one with its own network that uses the same<br>
> address range, to minimize configuration differences between them.<br>
><br>
<br>
</div>
</div>
I agree with Gabriel on the matter. There is nothing inherently wrong<br>
about a tenant running multiple isolated network setups that use<br>
overlapping addresses (as there is nothing wrong about multiple<br>
tenants doing the same).<br>
<br>
There seems to be a value in disallowing overlapping subnets attached<br>
to the same router though.<br>
<br>
All in all, there seems to be no need to limit neutron API just<br>
because most external IPAM implementation do not seem to care about<br>
supporting the use case.<br>
<br>
It's also an issue that the change proposed is backwards incompatible.<br>
<br>
/Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJVAMCPAAoJEC5aWaUY1u57d/cH/A+nAuLrNaCPumjlOPJP90c3<br>
4oSh0ioxEQw2uBRx1mWvcQle0M1U4Psy5CqIjeHgDhRlCNKB2gAYvm7/lCwZoCw7<br>
pxLUerfZPFguNKYCUly1MYyo0gorycFgemoHKEFwHboDJfPdGYxdhW8HuemCClOG<br>
ZSeRzjO2rGaHU8XT+QWgI14UBiAu+XlQHy3UwUKEaffXOnja7noCU99/6d7+6TgF<br>
5/RdFhpfn6pcRvLboiquo57w6N3q7moORgrGSMuP8cnMMTxo9/TLie+vMXmLPobB<br>
YmeG1ar1q0ouGKb6ZG7KokUyl6CdpgowZ6bqetPELjBLIO+uhcsJ6g9NvRl4T9o=<br>
=WQ3Q<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb">
<div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div>Kevin Benton</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>