Open Stack

>It seems to me that the existence of the multiprovider extension is
an important point for this discussion.  Multiprovider, as I understand
it, allows describing a network composed of multiple L2 segments
with implicit east-west routing between them.

Not quite. Multiprovider is to describe different L2 segments that are all
connected together via some kind of translator (e.g. l2 gateway) that
ensures they are all part of the same broadcast domain. It doesn't fit with
what we are looking to achieve because all of the segments are supposed to
be part of the same broadcast domain so there is only one DHCP instance for
all segments, subnets are shared between all of them, a router only
attaches to one, etc.

>But I was suggesting that there might be some scenarios where routing
happened without a corresponding router object, and in fact it appears
that this is already the case: between the segments of a multiprovider
network.

There isn't routing between different subnets for multiprovider networks. A
multiprovider network is just an l2 broadcast domain realized on multiple
encapsulation mediums.

>I think Ian's posts have now clarified this.  The current order of
events is:
>- Neutron creates an unbound port, associated with a network, and
allocates an IP address for it.
>- Nova chooses a host for the new VM.
>- The port is bound and plugged on that host.

This is only the case if someone passes a port UUID into Nova to use. If
Nova creates the port itself, it will wait until it's scheduled to a
compute node so the port creation request should already have the host_id
field set.

Supporting the case a pre-created port and migration will be the issue. We
would essentially need to allow ports to be re-assigned to different
networks to handle these scenarios.

Cheers,
Kevin Benton
On 21/07/15 15:45, Salvatore Orlando wrote:
> On 21 July 2015 at 14:21, Neil Jerram <Neil.Jerram at metaswitch.com
> <mailto:Neil.Jerram at metaswitch.com>> wrote:
>
>
>     You've probably seen Robert Kukura's comment on the related bug at
>     https://bugs.launchpad.net/neutron/+bug/1458890/comments/30, and there
>     is a useful detailed description of how the multiprovider extension
>     works at
>     https://bugs.launchpad.net/openstack-api-site/+bug/1242019/comments/3.
>     I believe it is correct to say that using multiprovider would be an
>     effective substitute for using multiple backing networks with
>     different
>     {network_type, physical_network, segmentation_id}, and that logically
>     multiprovider is aiming to describe the same thing as this email
>     thread
>     is, i.e. non-overlay mapping onto a physical network composed of
>     multiple segments.
>
>
>     However, I believe multiprovider does not (per se) address the IP
>     addressing requirement(s) of the multi-segment scenario.
>
>
> Indeed it does not. The multiprovider extension simply indicates that
> a network can be built using different L2 segments.
> It is then up to the operator to ensure that these segments are
> correct, and it's up to whatever is running in the backend to ensure
> that instances on the various segments can communicate each other.

It seems to me that the existence of the multiprovider extension is an
important point for this discussion.  Multiprovider, as I understand it,
allows describing a network composed of multiple L2 segments with
implicit east-west routing between them.  Which is a large part
(although not all) of the requirement that the current discussion is
trying to meet.  Given that multiprovider already exists - and assuming
that it is generally accepted and approved of - surely we should not add
a competing model for the same thing, but should instead look at adding
any additional features to multiprovider that are needed to meet the
complete set of requirements?

>
> I believe the ask here is for Neutron to provide this capability (the
> neutron reference control plane currently doesn't).

What exactly do you mean here?  I don't think the operators are asking
for a software implementation of the implicit east-west routing, for
example, because they already have physical kit that does that.
(Although perhaps that kit might need some kind of instruction.)  For
the DHCP function (as I think you've written elsewhere) all that's
needed is to run a DHCP agent in each segment.

I don't know if the operators were aware of multiprovider - AFAIK, it
wasn't mentioned as a possible ingredient for this work, before Robert
Kukura's comment cited above - but if they were, I think they might just
be asking for the IP addressing points on top of that; both
segment-based and mobile.


> It is not yet entirely clear to me whether there's a real need of
> changing the logical model, but IP addressing implications might be a
> reason, as pointed out by Neil.
>
>
>
>     >
>     > This proposal offers a clear separation between the statically bound
>     > and the mobile address blocks by associating the former with the
>     > backing networks and the latter with the front network.  The mobile
>     > addresses are modeled just like floating IPs are today but are
>     > implemented by some plugin code (possibly without NAT).
>
>     Couldn't the mobile addresses be _exactly_ like floating IPs already
>     are?  Why is anything different from floating IPs needed here?
>
>     >
>     > This proposal also provides some advantages for integrating dynamic
>     > routing.  Since each backing network will, by necessity, have a
>     > corresponding router in the infrastructure, the relationship between
>     > dynamic routing speaker, router, and network is clear in the model:
>     > network <-> speaker <-> router.
>
>
> Ok. But how that changes because of backing networks? I believe the
> same relationship holds true for every network, or am I wrong?

Even if not for every network, it's presumably also an interesting
question for multiprovider networks.  (And so there may already be an
answer!)

>
>
>
>     I'm not sure exactly what you mean here by 'dynamic routing', but I
>     think this touches on a key point: can IP routing happen anywhere in a
>     Neutron network, without being explicitly represented by a router
>     object
>     in the model?
>
>     I think the answer to that should be yes.
>
>
> But this would also mean that we should consider doing without the
> very concept of router in Neutron.
> If we look at the scenarios we're describing here, I'd agree with you,
> but unfortunately Neutron is required to serve a wide variety of
> scenarios.

I didn't mean that there should _never_ be explicit router objects in
Neutron.  Clearly those already exist, for good reasons, and should
continue to serve their scenarios.

But I was suggesting that there might be some scenarios where routing
happened without a corresponding router object, and in fact it appears
that this is already the case: between the segments of a multiprovider
network.  (Note that the API/data model documentation should still make
it clear in such cases that the routing behavior is expected.)

>
>
>     Right.  A key requirement, for this to be possible, is that Nova's
>     host
>     selection happens before the IPAM system is asked to allocate an IP
>     address.  I have an action to investigate that, but if anyone
>     happens to
>     know already, please do say.
>
>
> I am 99.99% sure this is not possible at the moment unless something
> is done to make nova scheduler network aware.
> Also, this will add a point of coupling between the instance boot and
> network provisioning processes, which are independent at the moment.

I think Ian's posts have now clarified this.  The current order of
events is:

- Neutron creates an unbound port, associated with a network, and
allocates an IP address for it.
- Nova chooses a host for the new VM.
- The port is bound and plugged on that host.

Therefore we at least need an enhancement to defer the IP address
allocation until later than it is at the moment.

In addition, it seems everyone agrees that the Nova scheduler should
eventually be network aware; but perhaps quite a lot can be achieved in
a first phase without that.

>
>
>     >
>     > 1. This alternate model offers no way to distinguish the two
>     types of
>     > address blocks.
>
>     Agreed.  But I wonder if normal floating IPs can be used for the
>     mobile
>     IP addresses (as also suggested above).
>
>
> I get the concept, but it's not really a floating IP in neutron terms,
> as that implies SNAT/DNAT.
> Also, from what I gather it's not about single mobile addresses, but
> we're talking about entire subnets that can be moved around.

Ah, I see now.  If an IP address from a mobile block is used, that's the
fixed IP that the VM sees.  Agree that that's different from a floating
IP, then.

>
>
>
>     > 2. We don't have the benefit of modeling the segments with
>     Neutron networks.
>
>     Agreed, but it appears that multiprovider has already taken a
>     different
>     view here, and already provides the ability for a network to map to
>     multiple {network_type, physical_network, segmentation_id} tuples.
>
>
> Modelling segments as logical networks is not necessarily a benefit in
> my opinion;
> it's more a convenience. For instance the reference control plane
> might implement provider networks in a way such that:
> 1) a "ghost router" is created in the l3 agent to ensure E-W traffic
> across all segments (the router is "ghost" because it's not exposed as
> neutron logical router
> 2) a distinct dnsmasq instance is started on every segment of the
> network to ensure DHCP functionality
> 3) metadata services can be provided through the ghost router rather
> than using isolated metadata

Agree with this detail, but ...

>
> I think this alternative is worth exploring anyway.

... not sure what you're suggesting to explore.  Do you mean explore
meeting the requirement with a multiprovider network, instead of with
the front and backing networks proposal?

Regards,
    Neil


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150722/ce1d1995/attachment.html>