Open Stack

On 21/07/15 01:47, Assaf Muller wrote:
>
> ----- Original Message -----
>> I'm looking for feedback from anyone interest but, in particular, I'd
>> like feedback from the following people for varying perspectives:
>> Mark McClain (proposed alternate), John Belamaric (IPAM), Ryan Tidwell
>> (BGP), Neil Jerram (L3 networks), Aaron Rosen (help understand
>> multi-provider networks) and you if you're reading this list of names
>> and thinking "he forgot me!"
>>
>> We have been struggling to develop a way to model a network which is
>> composed of disjoint L2 networks connected by routers.  The intent of
>> this email is to describe the two proposals and request input on the
>> two in attempt to choose a direction forward.  But, first:
>> requirements.
>>
>> Requirements:
>>
>> The network should appear to end users as a single network choice.
>> They should not be burdened with choosing between segments.  It might
>> interest them that L2 communications may not work between instances on
>> this network but that is all.  This has been requested by numerous
>> operators [1][4].  It can be useful for external networks and provider
>> networks.
> I think that [1] and [4] are conflating the problem statement with the
> proposed solutions, and lacking some lower level details regarding the
> problem statement, which makes it a lot harder to engage in a discussion.
>
> I'm looking at [4]:
> What I don't see explicitly mentioned is: Does the same CIDR extend across racks,
> or would each rack get its own CIDR(s)?

I think it's the latter, i.e. what you call option (1) below.

>  I understand this can differ according to
> the architectural choices you make in your data center, and that changes the
> choices we'd need to make to Neutron in order to satisfy that requirement.
>
> To clarify, option (1) means that a subnet is contained to a rack. Option (2)
> means that a subnet may span across racks. I don't think we need to change the network/subnet
> model at all to satisfy case (1). Each rack would have its own network/subnet
> (Or perhaps multiple, if more than a single VLAN or other characteristic is desired).
> Each network would be tagged with an AZ (This ties in nicely to the already proposed Neutron AZ spec),
> and the Nova scheduler would become aware of Neutron network AZs. In this model
> you don't want to connect to a network, you want Nova to schedule the VM and then have Nova choose
> the network on that rack. If you want more than a single network in a rack, then there's
> some difference between those networks that could be expressed in tags (Think: Network flavors),
> such as the security zone. You'd then specify a tag that should be satisfied by the
> network that the VM ends up connecting to, so that the tag may be added to the list
> of Nova scheduler filters. Again, this goes back to keeping the Neutron network and subnet
> just as they are but doing some work with AZs, tagging and the Nova scheduler.
> We've known that the Nova scheduler must become Network aware for the past few years,
> perhaps it's time to finally tackle that.

Interesting.  Perhaps we can do something along those lines that will
fly without lots of change in Nova/Neutron interactions:

- allow a Neutron network to have tags associated with it

- when launching a set of VMs, allow specifying a network tag, instead
of a specific network name/ID, with the meaning that each VM can attach
to any network that has that tag.

Longer term the Nova scheduler could become tag-aware, as you suggest,
but until then I think what will happen is that

- Nova will choose a host independently of the network tag

- if it isn't possible for Neutron to bind a port on that host to a
network with the requested tag, it will bounce back to Nova, and Nova
will try the next available host (?)

So, inefficient, but kind of already working.

Effectively, with this model, the tag is replacing Carl's front
network.  Which nicely side-steps any confusion above which network ID a
port is expected to have.

Regards,
    Neil