Open Stack

I think we have two different cases here - one where a 'trunk' network
passes all VLANs, which is potentially supportable by anything that's not
based on VLANs for separation, and one where a trunk can't feasibly do that
but where we could make it pass a restricted set of VLANs by mapping.

In the former case, obviously we need no special awareness of the nature of
the network to implement an L2 gateway.

In the latter case, we're looking at a specialisation of networks, one
where you would first create them with a set of VLANs you wanted to pass
(and - presumably - the driver would say 'ah, I must allocate multiple
VLANs to this network rather than just one'.  You've jumped in with two
optimisations on top of that:

- we can precalculate the VLANs the network needs to pass in some cases,
because it's the sum of VLANs that L2 gateways on that network know about
- we can use L2 gateways to make the mapping from 'tenant' VLANs to
'overlay' VLANs

They're good ideas but they add some limitations to what you can do with
trunk networks that aren't actually necessary in a number of solutions.

I wonder if we should try the general case first with e.g. a
Linuxbridge/GRE based infrastructure, and then add the optimisations
afterwards.  If I were going to do that optimisation I'd start with the
capability mechanism and add the ability to let the tenant specify the
specific VLAN tags which must be passed (as you normally would on a
physical switch). I'd then have two port types - a user-facing one that
ensures the entry and exit mapping is made on the port, and an
administrative one which exposes that mapping internally and lets the
client code (e.g. the L2 gateway) do the mapping itself.  But I think it
would be complicated, and maybe even has more complexity than is
immediately apparent (e.g. we're effectively allocating a cluster-wide
network to get backbone segmentation IDs for each VLAN we pass, which is
new and different) hence my thought that we should start with the easy case
first just to have something working, and see how the tenant API feels.  We
could do this with a basic bit of gateway code running on a system using
Linuxbridge + GRE, I think - the key seems to be avoiding VLANs in the
overlay and then the problem is drastically simplified.
-- 
Ian.


On 21 December 2013 23:00, Erik Moe <emoe264 at gmail.com> wrote:

> Hi Ian,
>
> I think your VLAN trunking capability proposal can be a good thing, so the
> user can request a Neutron network that can trunk VLANs without caring
> about detailed information regarding which VLANs to pass. This could be
> used for use cases there user wants to pass VLANs between endpoints on a L2
> network etc.
>
> For the use case there a VM wants to connect to several "normal" Neutron
> networks using VLANs, I would prefer a solution that did not require a
> Neutron trunk network. Possibly by connecting a L2-gateway directly to the
> Neutron 'vNic' port, or some other solution. IMHO it would be good to map
> VLAN to Neutron network as soon as possible.
>
> Thanks,
> Erik
>
>
>
> On Thu, Dec 19, 2013 at 2:15 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
>
>> On 19 December 2013 06:35, Isaku Yamahata <isaku.yamahata at gmail.com>wrote:
>>
>>>
>>> Hi Ian.
>>>
>>> I can't see your proposal. Can you please make it public viewable?
>>>
>>
>> Crap, sorry - fixed.
>>
>>
>>> > Even before I read the document I could list three use cases.  Eric's
>>> > covered some of them himself.
>>>
>>> I'm not against trunking.
>>> I'm trying to understand what requirements need "trunk network" in
>>> the figure 1 in addition to "L2 gateway" directly connected to VM via
>>> "trunk port".
>>>
>>
>> No problem, just putting the information there for you.
>>
>> --
>> Ian.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131223/87a6c607/attachment.html>