<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 20/07/15 23:27, Ian Wells wrote:<br>
</div>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>There are two routed network models:<br>
<br>
</div>
<div>- I give my VM an address that bears no relation to its location and ensure the routed fabric routes packets there - this is very much the routing protocol method for doing things where I have injected a route into the network and it needs to propagate.
It's also pretty useless because there are too many host routes in any reasonable sized cloud.<br>
<br>
</div>
<div>- I give my VM an address that is based on its location, which only becomes apparent at binding time. This means that the semantics of a port changes - a port has no address of any meaning until binding, because its location is related to what it does
- and it leaves open questions about what to do when you migrate.<br>
<br>
</div>
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.</div>
</blockquote>
<br>
Right.<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr"> But then you say:<br>
<div>
<div><br>
<div class="gmail_extra">
<div class="gmail_quote">On 20 July 2015 at 10:33, Carl Baldwin <span dir="ltr"><<a moz-do-not-send="true" href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<div><br>
</div>
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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Thanks, good point. And does IP allocation currently happen when a port is _created_?<br>
<br>
(By the way, (1) any faults in the IPAM-related proposal are really mine, not Carl's; he's just trying to present my half-baked idea as fairly as he can; (2) therefore I really appreciate your feedback on it!)<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"><br>
</div>
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.</div>
</div>
</div>
</div>
</blockquote>
<br>
I suppose any Neutron API enhancement will have some cost, and proposal 1 has the one specific aspect that Mark McClain pointed out, that ports end up with a backing network ID, not the front network ID, and that that may surprise a lot of existing plugin code.
I don't really see your "has to be deployed by all operators", "every future change has to align with it" and "if optional it's a burden ..." points, though.<br>
<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra"> I accept proposal 1 is easy, but it's not universally applicable. It doesn't work with Neil Jerram's plans,</div>
</div>
</div>
</div>
</blockquote>
<br>
I'm not sure that this current discussion has to address _all_ possible use cases. To be clear about what you mean, though: do you mean that representing [routed] in terms of proposal 1 would require a backing network for each VM? (If so, I agree that that
wouldn't be good!)<br>
<br>
[routed] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/198439/">
https://review.openstack.org/#/c/198439/</a><br>
<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">it doesn't work with multiple interfaces per host,</div>
</div>
</div>
</div>
</blockquote>
<br>
Why not?<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">and it doesn't work with the IPv6 routed-network model I worked on.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Can you give a pointer?<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra"><br>
Given that, I wonder whether proposal 2 could be rephrased.<br>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Should that say "some network types allow unbound ports not to have addresses"?<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"></div>
<div class="gmail_quote">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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Not sure on your exact point here, but what about new subnet pools?<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"></div>
<div class="gmail_quote">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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Well that would be IPAM-module-internal anyway; I'd say that - at least during phase 1 - it could do whatever it likes to work out sensible IP allocation. Longer term, sure, one could create a formal datamodel for this.<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"></div>
<div class="gmail_quote">4: when the port is bound, the IPAM is referred to, and it's told the binding information of the port.<br>
</div>
<div class="gmail_quote">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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I believe it's already supported for a port's fixed IPs to change - so hopefully nothing particularly new here.<br>
<br>
<blockquote cite="mid:CAPoubz78zJ2x1Uqz6vVUqZX_JvdMDva1fsbXeMnMn=uyhE5kSA@mail.gmail.com" type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"></div>
<div class="gmail_quote">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.<br>
<br>
</div>
<div class="gmail_quote">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.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Thanks! That's very much what I was thinking too, so really appreciate your support and adding useful flesh to the bone.<br>
<br>
Regards,<br>
Neil<br>
<br>
</body>
</html>