Open Stack

On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando
<salv.orlando at gmail.com> wrote:
> It is however important to ensure services like DHCP keep working as usual.
> Treating segments as logical networks in their own right is the simples
> solution to achieve this imho.

Agreed.

> While the logical model and workflow you describe here makes sense, I have
> the impression that:
> 1) The front network is not a neutron logical network. Because it does not
> really behave like a network, with the only exception that you can pass its
> id to the nova API. To reinforce this consider that basically the front
> network has no ports.

One thing that I have been trying to figure out how to do is to take
the external network model that we currently have and scale it without
really changing the way the user interacts with it to get a floating
IP and associate it with their instances port.  I've seen external
networks that span several AZs to reach thousands of hosts.  To the
end user, it is convenient to see it as one pool of addresses for
their floating IPs which can be associated with any port anywhere.

But, there are problems with doing this as a single L2 broadcast
domain.  I'd like to map this external network to the same kind of
routed segments infrastructure that the operators are asking for.  I
was hoping to do so without changing what the end user sees through
the API.

In my use case, the front network is a place to hang the floating IP subnet.

GoDaddy has done something like this but they did it a bit differently
without NAT.  However, they also use the "external" or "front" network
as a place to hang the floating IP subnet.

My model may not be the best way to do this.  I'm happy to go back to
the drawing board.  However, I'd like for people to understand that I
want an address block that is not confined to a segment.  I'd like to
use it for floating IPs to be associated with any port on any of the
segments.  Today, we associate subnets with networks.  That was part
of the motivation for modeling this as a network.

> 2) from a topological perspective the front network "kind of" behaves like
> an external network; but it isn't. The front network is not really a common
> gateway for all backing networks, more like a label which is attached to the
> router which interconnects all the backing networks.

I don't understand well enough to comment.

> 3) more on topology. How can we know that all these segments will always be
> connected by a single logical router? Using static router (or If one day BGP
> will be a thing), it is already possible to implement multi-segments
> networks with L3 connectivity using multiple logical routers, isn't it?

If there are multiple logical routers connected together couldn't you
consider the overall routing effect of those routers as a single
router if the details aren't important?

> 4) Point #5 is making assumptions on network aware scheduling. I am not sure
> we already have the ability to inform the nova scheduler to deploy an
> instance on a host where a give network is available.

This is something we need to continue to discuss.

> 5) I think that I would treat the "front" network as a "network group" or
> "cluster". I noticed the term "subnet cluster" is used in the etherpad. I
> find this term appropriate because it seems to me that in this scenario the
> final user does not care at all about the network intended as a L2 segment.
> 6) It seems one of the purposes of using backing networks is to identify an
> address block for the ports being created. But then how would that play with
> mobile address blocks? From an instance workflow perspective, should
> instances be associated with one or more address blocks at boot time?
> 7) What happens is a user attaches a router to a backing network and connect
> that router to an external network? Does that becomes a gateway for all
> backing networks or just for that network? And would the workflow be for
> uplinking a front network to an external network?

The user's router is just a gateway for the user's private network.

I imagine that a front network could itself be an external network.

>> > 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?

I don't think they are.  Given our current model, floating ips come
from subnets associated with an external network.  That's why I
modeled the front network as such, so that the floating IP model would
look very much like it does today.

>> >
>> > 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?

I think what I'm trying to say is that if segments are not modeled as
full blown Neutron networks, what would we attach the BGP speaker to
for a segment?

Carl