<div dir="ltr">On 21 July 2015 at 07:52, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class=""><p dir="ltr">> Now, you seem to generally be thinking in terms of the latter model, particularly since the provider network model you're talking about fits there.  But then you say:</p>
</span><p dir="ltr">Actually, both.  For example, GoDaddy assigns each vm an ip from the location based address blocks and optionally one from the routed location agnostic ones.  I would also like to assign router ports out of the location based blocks which could host floating ips from the other blocks.</p></div></blockquote><div>Well, routed IPs that are not location-specific are no different to normal ones, are they?  Why do they need special work that changes the API?<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="">
<p dir="ltr">> On 20 July 2015 at 10:33, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>> wrote:<br>
>><br>
>> When creating a<br>
>> port, the binding information would be sent to the IPAM system and the<br>
>> system would choose an appropriate address block for the allocation.</p>
</span><p dir="ltr">Implicit in both is a need to provide at least a hint at host binding.  Or, delay address assignment until binding.  I didn't mention it because my email was already long.<br>
This is something and discussed but applies equally to both proposals.</p></div></blockquote><div>No, it doesn't - if the IP address is routed and not relevant to the location of the host then yes, you would want to *inject a route* at binding, but you wouldn't want to delay address assignment till binding because it's location-agnostic.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="">
<p dir="ltr">> No, it wouldn't, because creating and binding a port are separate operations.  I can't give the port a location-specific address on creation - not until it's bound, in fact, which happens much later.<br>
><br>
> On proposal 1: consider the cost of adding a datamodel to Neutron.  It has to be respected by all developers, it frequently has to be deployed by all operators, and every future change has to align with it.  Plus either it has to be generic or optional, and if optional it's a burden to some proportion of Neutron developers and users.  I accept proposal 1 is easy, but it's not universally applicable.  It doesn't work with Neil Jerram's plans, it doesn't work with multiple interfaces per host, and it doesn't work with the IPv6 routed-network model I worked on.</p>
</span><p dir="ltr">Please be more specific.  I'm not following your argument here.  My proposal doesn't really add much new data model.</p></div></blockquote><div>My point is that there's a whole bunch of work there to solve the question of 'how do I allocate addresses to a port when addresses are location specific' that assumes that there's one model for location specific addresses that is a bunch of segments with each host on one segment.  I can break this model easily.  Per the previous IPv6 proposal, I might choose my address with more care than just by its location, to contain extra information I care about.  I might have multiple segments connected to one host where either segment will do and the scheduler should choose the most useful one.<br><br></div><div>If this whole model is built using reusable-ish concepts like networks, and adds a field to ports, then basically it ends up in, or significantly affecting, the model of core Neutron.  Every Neutron developer to come will have to read it, understand it, and not break it.  Depending on how it's implemented, every operator that comes along will have to deploy it and may be affected by bugs in it (though that depends on precisely how much ends up as an extension).  <br><br>If we find a more general purpose interface - and per above, mostly the interface is 'sometimes I want to pick my address only at binding' plus 'IPAM and address assignment is more complex than the subnet model we have today' then potentially these datamodels can be specific to IPAM - and not general purpose 'we have these objects around already' things we're reusing - and with a clean interface the models may not even be present as code into a deployed system, which is the best proof they are not introducing bugs.<br></div><div><br></div><div>Every bit of cruft we write, we have to carry.  It makes more sense to make the core extensible for this case, in my mind, than it does to introduce it into the core.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<p dir="ltr">We've discussed this with Neil at length.  I haven't been able to reconcile our respective approaches in to one model that works for both of us and still provides value.  </p></div></blockquote><div>QED.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Could you provide some links so that I can brush up on your ipv6 routed network model?  I'd like to consider it but I don't know much about it.</div></blockquote><div><br></div><div>The best writeup I have is <a href="http://datatracker.ietf.org/doc/draft-baker-openstack-ipv6-model/?include_text=1">http://datatracker.ietf.org/doc/draft-baker-openstack-ipv6-model/?include_text=1</a> (don't judge it by the place it was filed). But the concept was that (a) VMs received v6 addresses, (b) they were location specific, (c) each had their own L2 segment (per Neil's idea, and really the ultimate use of this model), and (d) there was information in the address additional to just its location and the entropy of choosing a random address.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="">
<p dir="ltr"><br>
> 1: some network types don't allow unbound ports to have addresses, they just get placeholder addresses for each subnet until they're bound<br>
> 2: 'subnets' on these networks are more special than subnets on other networks.  (More accurately, they dont use subnets.  It's a shame subnets are core Neutron, because they're pretty horrible and yet hard to replace.)<br>
> 3: there's an independent (in an extension?  In another API endpoint?) datamodel that the network points to and that IPAM refers to to find a port an address.  Bonus, people who aren't using funky network types can disable this extension.<br>
> 4: when the port is bound, the IPAM is referred to, and it's told the binding information of the port.<br>
> 5: when binding the port, once IPAM has returned its address, the network controller probably does stuff with that address when it completes the binding (like initialising routing).<br>
> 6: live migration either has to renumber a port or forward old traffic to the new address via route injection.  This is an open question now, so I'm mentioning it rather than solving it.</p>
</span><p dir="ltr">I left out the migration issue from my email also because it also affects both proposals equally.</p></div></blockquote><div>Understood, and wise at this point, I think.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="">
<p dir="ltr">> In fact, adding that hook to IPAM at binding plus setting aside a 'not set' IP address might be all you need to do to make it possible.  The IPAM needs data to work out what an address is, but that doesn't have to take the form of existing Neutron constructs.</p>
</span><p dir="ltr">What about the L2 network for each segment?</p></div></blockquote><div>What about it?  There may be an L2 network per port and no more.  True in both my case and Neil's, in fact, where your network system proposed is just storing address ranges and they're not really L2 segments at all.  (Also, your terminology usage is now getting confusing. ;)  <br><br>My point is not that your model is *wrong* - it's that it's *not generally applicable* and therefore shouldn't be encoded in core Neutron as if it's the only way this could possibly work.  Better that we have a system where that model is *not* core, and as an added bonus doesn't attempt to make use of core objects like networks for things that they don't entirely suit.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p dir="ltr">I suggested creating provider networks for these.  Do you have a different suggestion?  </p></div></blockquote><div>My suggestion is per above - that using Neutron 'networks' to be 'a network to which I can attach a VM' and 'a location specific addressing construct' is overloading it considerably, and doesn't suit the general purpose case. And that pluggable IPAM, kinda, allows you to make IPAM specific addressing models (which are generally admin-only anyway) - or, better, letting the IPAM system discover for itself how addressing works - is a nicer option.  It's actually not difficult to create completely objects to represent this, what is difficult is getting that agreed as a change to a core datamodel, so I think taking this and riffing on it works better than saying 'this is how it shall be' with a somewhat limited solution.  People can still use the solutions in the meantime, particularly since they're admin-facing interfaces.<br></div><br></div><div class="gmail_quote">You know, there comes a moment where I really want to get in front of a whiteboard...<br></div></div></div>