[openstack-dev] [Neutron][L3] Representing a networks connected by routers
Neil.Jerram at metaswitch.com
Tue Jul 21 14:12:36 UTC 2015
[Sorry, mistaken send as mixed format, so quoting may not have come out
right. Hope this time is better...]
On 20/07/15 23:27, Ian Wells wrote:
> There are two routed network models:
> - 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.
> - 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.
> 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:
> On 20 July 2015 at 10:33, Carl Baldwin <carl at ecbaldwin.net
> <mailto:carl at ecbaldwin.net>> wrote:
> When creating a
> port, the binding information would be sent to the IPAM system and the
> system would choose an appropriate address block for the allocation.
> 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.
Thanks, good point. And does IP allocation currently happen when a port
(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!)
> 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 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.
> I accept proposal 1 is easy, but it's not universally applicable.
> It doesn't work with Neil Jerram's plans,
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!)
> it doesn't work with multiple interfaces per host,
> and it doesn't work with the IPv6 routed-network model I worked on.
Can you give a pointer?
> Given that, I wonder whether proposal 2 could be rephrased.
> 1: some network types don't allow unbound ports to have addresses,
> they just get placeholder addresses for each subnet until they're bound
Should that say "some network types allow unbound ports not to have
> 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.)
Not sure on your exact point here, but what about new subnet pools?
> 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.
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
> 4: when the port is bound, the IPAM is referred to, and it's told the
> binding information of the port.
> 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).
I believe it's already supported for a port's fixed IPs to change - so
hopefully nothing particularly new here.
> 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.
> 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.
Thanks! That's very much what I was thinking too, so really appreciate
your support and adding useful flesh to the bone.
More information about the OpenStack-dev