<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Hi Ian,</div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)">Here some details about integrating the L2-gateway (supporting multiple plugins/MDs and not limited to OVS agent implementation) as a trunking gateway:</div><div class="gmail_default" style="font-family:georgia,serif;font-size:large;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><span style="font-family:georgia,serif;font-size:large">It's a block, i.e. building block, that has multiple access ports as tenant Neutron network ports (having that block type/uuid as device_owner/device_id) but in different Neutron networks and up to one gateway port as a provider external network port. </span></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default"><font face="georgia, serif" size="4"><font color="#000000">Adding the two following constraints ensure that</font></font><font color="#000000" face="georgia, serif" size="4"> Neutron networks and blocks are stubby and there's no way to loop the networks thus very simply and very easily providing one of the several means of alleviating the raised concern</font><span style="color:rgb(0,0,0);font-family:georgia,serif;font-size:large">: </span></div><div class="gmail_default" style="color:rgb(0,0,0)"><span style="font-family:georgia,serif;font-size:large">1) Each Neutron network cannot have more than one port that could be bound/added to any block as an access port.</span></div><div class="gmail_default" style="color:rgb(0,0,0)"><span style="font-family:georgia,serif;font-size:large">2) Each block cannot own more than one </span><span style="font-family:georgia,serif;font-size:large">gateway port that can be set/unset to that block. </span></div><div class="gmail_default" style="color:rgb(0,0,0)"><span style="font-family:georgia,serif;font-size:large"><br></span></div><div class="gmail_default" style="color:rgb(0,0,0)"><span style="font-family:georgia,serif;font-size:large">If the type of that block is "learning bridge" then the gateway port is a Neutron port on a specific provider external network (with the segmentation details provided as with existent Neutron API) and that block will forward between access-ports and gateway-port in broadcast isolation (as with private VLANs) or broadcast merge (community VLANs). For that, a very easy implementation was provided for review a very long time ago.</span><br></div><div class="gmail_default"><font face="georgia, serif" size="4"><font color="#000000"><br></font></font></div><div class="gmail_default"><font face="georgia, serif" size="4"><font color="#000000">If the type of that block is "trunking bridge" then the gateway-port is a trunk-port as in "VLAN-aware VMs BP" </font></font><font face="georgia, serif" size="4"><font color="#000000">or as </font></font><font color="#000000" face="georgia, serif" size="4">a dynamic collection of Neutron ports as in a suggested extension of the "networks collection Idea" with each port in a different provider external network (with a 1 to 1 transparent patching hook service between 1 access-port@tenant_net_x and 1 external-port@provider_net_y that could be the place holder for a cross-network summarized/factorized security group for tenant networks or whatever ...)... Then we further abstract a trunk as a mix of VLANs, GREs, VxLANs, etc. (i.e. Neutron networks) next to each others on the same networks trunk not limited to usual VLAN trunks. What happens (match -> block/forward/...) to this trunk in the provider external networks as well as in the transparent patching hooks within that block is up to the provider I guess. Just a tiny abstract idea out of the top of my head that I can detail in the specs if there's a tiny interest/match with what is required?</font></div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default"><font color="#000000" face="georgia, serif" size="4">Thanks,</font></div><div class="gmail_default"><font color="#000000" face="georgia, serif" size="4"><br></font></div><div class="gmail_default"><font color="#000000" face="georgia, serif" size="4">Best Regards,</font></div><div class="gmail_default"><font color="#000000" face="georgia, serif" size="4">Racha</font></div><div class="gmail_default"><font face="georgia, serif" size="4"><font color="#000000"><br></font></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 23, 2014 at 2:58 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>There are two categories of problems:<br><br></div><div>1. some networks don't pass VLAN tagged traffic, and it's impossible to detect this from the API<br></div><div>2. it's not possible to pass traffic from multiple networks to one port on one machine as (e.g.) VLAN tagged traffic<br><br></div><div>(1) is addressed by the VLAN trunking network blueprint, XXX. Nothing else addresses this, particularly in the case that one VM is emitting tagged packets that another one should receive and Openstack knows nothing about what's going on.<br><br>We should get this in, and ideally in quickly and in a simple form
where it simply tells you if a network is capable of passing tagged
traffic. In general, this is possible to calculate but a bit tricky in
ML2 - anything using the OVS mechanism driver won't pass VLAN traffic,
anything using VLANs should probably also claim it doesn't pass VLAN
traffic (though actually it depends a little on the switch), and
combinations of L3 tunnels plus Linuxbridge seem to pass VLAN traffic
just fine. Beyond that, it's got a backward compatibility mode, so it's
possible to ensure that any plugin that doesn't implement VLAN
reporting is still behaving correctly per the specification.<br></div><div><br></div><div>(2) is addressed by several blueprints, and these have overlapping ideas that all solve the problem. I would summarise the possibilities as follows:<br><br></div>A. Racha's L2 gateway blueprint, <a href="https://blueprints.launchpad.net/neutron/+spec/gateway-api-extension" target="_blank">https://blueprints.launchpad.net/neutron/+spec/gateway-api-extension</a>, which (at its simplest, though it's had features added on and is somewhat OVS-specific in its detail) acts as a concentrator to multiplex multiple networks onto one as a trunk. This is a very simple approach and doesn't attempt to resolve any of the hairier questions like making DHCP work as you might want it to on the ports attached to the trunk network.<br></div>B. Isaku's L2 gateway blueprint, <a href="https://review.openstack.org/#/c/100278/" target="_blank">https://review.openstack.org/#/c/100278/</a>, which is more limited in that it refers only to external connections.<br></div>C. Erik's VLAN port blueprint, <a href="https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms" target="_blank">https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms</a>, which tries to solve the addressing problem mentioned above by having ports within ports (much as, on the VM side, interfaces passing trunk traffic tend to have subinterfaces that deal with the traffic streams).<br></div>D. Not a blueprint, but an idea I've come across: create a network that is a collection of other networks, each 'subnetwork' being a VLAN in the network trunk.<br></div><div>E. Kyle's very old blueprint, <a href="https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api" target="_blank">https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api</a> - where we attach a port, not a network, to multiple networks. Probably doesn't work with appliances.<br></div><div><br></div><div>I would recommend we try and find a solution that works with both external hardware and internal networks. (B) is only a partial solution.<br></div><br></div><div>Considering the others, note that (C) and (D) add significant complexity to the data model, independently of the benefits they bring. (A) adds one new functional block to networking (similar to today's routers, or even today's Nova instances).<br><br></div><div>Finally, I suggest we consider the most prominent use case for multiplexing networks. This seems to be condensing traffic from many networks to either a service VM or a service appliance. It's useful, but not essential, to have Neutron control the addresses on the trunk port subinterfaces.<br><br></div></div>So, that said, I personally favour (A) is the simplest way to solve our current needs, and I recommend paring (A) right down to its basics: a block that has access ports that we tag with a VLAN ID, and one trunk port that has all of the access networks multiplexed onto it. This is a slightly dangerous block, in that you can actually set up forwarding blocks with it, and that's a concern; but it's a simple service block like a router, it's very, very simple to implement, and it solves our immediate problems so that we can make forward progress. It also doesn't affect the other solutions significantly, so someone could implement (C) or (D) or (E) in the future.<span class="HOEnZb"><font color="#888888"><br>-- <br></font></span></div><span class="HOEnZb"><font color="#888888">Ian.<br><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 23 October 2014 02:13, Alan Kavanagh <span dir="ltr"><<a href="mailto:alan.kavanagh@ericsson.com" target="_blank">alan.kavanagh@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 many thanks to Kyle for putting this as a priority, its most welcome.<br>
<span><font color="#888888">/Alan<br>
</font></span><div><div><br>
-----Original Message-----<br>
From: Erik Moe [mailto:<a href="mailto:erik.moe@ericsson.com" target="_blank">erik.moe@ericsson.com</a>]<br>
Sent: October-22-14 5:01 PM<br>
To: Steve Gordon; OpenStack Development Mailing List (not for usage questions)<br>
Cc: <a href="mailto:iawells@cisco.com" target="_blank">iawells@cisco.com</a><br>
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints<br>
<br>
<br>
Hi,<br>
<br>
Great that we can have more focus on this. I'll attend the meeting on Monday and also attend the summit, looking forward to these discussions.<br>
<br>
Thanks,<br>
Erik<br>
<br>
<br>
-----Original Message-----<br>
From: Steve Gordon [mailto:<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>]<br>
Sent: den 22 oktober 2014 16:29<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Cc: Erik Moe; <a href="mailto:iawells@cisco.com" target="_blank">iawells@cisco.com</a>; <a href="mailto:Calum.Loudon@metaswitch.com" target="_blank">Calum.Loudon@metaswitch.com</a><br>
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints<br>
<br>
----- Original Message -----<br>
> From: "Kyle Mestery" <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
><br>
> There are currently at least two BPs registered for VLAN trunk support<br>
> to VMs in neutron-specs [1] [2]. This is clearly something that I'd<br>
> like to see us land in Kilo, as it enables a bunch of things for the<br>
> NFV use cases. I'm going to propose that we talk about this at an<br>
> upcoming Neutron meeting [3]. Given the rotating schedule of this<br>
> meeting, and the fact the Summit is fast approaching, I'm going to<br>
> propose we allocate a bit of time in next Monday's meeting to discuss<br>
> this. It's likely we can continue this discussion F2F in Paris as<br>
> well, but getting a head start would be good.<br>
><br>
> Thanks,<br>
> Kyle<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/94612/" target="_blank">https://review.openstack.org/#/c/94612/</a><br>
> [2] <a href="https://review.openstack.org/#/c/97714" target="_blank">https://review.openstack.org/#/c/97714</a><br>
> [3] <a href="https://wiki.openstack.org/wiki/Network/Meetings" target="_blank">https://wiki.openstack.org/wiki/Network/Meetings</a><br>
<br>
Hi Kyle,<br>
<br>
Thanks for raising this, it would be great to have a converged plan for addressing this use case [1] for Kilo. I plan to attend the Neutron meeting and I've CC'd Erik, Ian, and Calum to make sure they are aware as well.<br>
<br>
Thanks,<br>
<br>
Steve<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-October/047548.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-October/047548.html</a><br>
_______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>
</div></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>