<div dir="ltr"><div><div>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.<br>
<br></div>In the former case, obviously we need no special awareness of the nature of the network to implement an L2 gateway.<br><br>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:<br>
<br></div><div>- 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<br></div><div>- we can use L2 gateways to make the mapping from 'tenant' VLANs to 'overlay' VLANs<br>
</div><div><br></div><div>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.<br></div><div><br>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.<br>
-- <br></div><div>Ian.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 December 2013 23:00, Erik Moe <span dir="ltr"><<a href="mailto:emoe264@gmail.com" target="_blank">emoe264@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ian,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Erik</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Dec 19, 2013 at 2:15 PM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On 19 December 2013 06:35, Isaku Yamahata <span dir="ltr"><<a href="mailto:isaku.yamahata@gmail.com" target="_blank">isaku.yamahata@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Ian.<br>
<br>
I can't see your proposal. Can you please make it public viewable?<br>
</blockquote><div><br></div></div><div>Crap, sorry - fixed.<br></div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> Even before I read the document I could list three use cases. Eric's<br>
> covered some of them himself.<br>
<br>
</div></div>I'm not against trunking.<br>
I'm trying to understand what requirements need "trunk network" in<br>
the figure 1 in addition to "L2 gateway" directly connected to VM via<br>
"trunk port".<br></blockquote></div></div><br></div><div class="gmail_extra">No problem, just putting the information there for you.<span><font color="#888888"><br><br>-- <br></font></span></div>
<span><font color="#888888"><div class="gmail_extra">Ian.<br></div></font></span></div>
<br></div></div><div class="im">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>