<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Proposal C, VLAN-aware-VMs, is about trying to integrate VLAN traffic from VMs with Neutron in a more tightly fashion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It terminates the VLAN at the port connected to the VM. It does not bring in the VLAN concept further into Neutron. This is done by mapping each VLAN from the
VM to a neutron network. After all, VLANs and Neutron networks are very much alike.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The modelling reuses the current port structure, there is one port on each network. The port still contains information relevant to that network.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">By doing these things it’s possible to utilize the rest of the features in Neutron, only features that have implementation close to VM has to be overlooked
when implementing this. Other features that have attributes on a VM port but is realized remotely works fine, for example DHCP (including extra_dhcp_opts) and mechanism drivers that uses portbindings to do network plumbing on a switch.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">After the Icehouse summit where we discussed the L2-gateway solution I started to implement an L2-gateway. The idea was to have an VM with a trunk port connected
to a trunk network carrying tagged traffic. The network would then be connected to a L2-gateway for breaking out a single VLAN and connect it with a normal Neutron network. Following are some of the issues I encountered.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Currently a neutron port/network contains attributes related to one broadcast domain. A trunk network requires that many attributes are per broadcast domain.
This would require a bigger refractory of Neutron port/network and affect all services using the ports/networks.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Due to this I dropped the track of tight integration with trunk network.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Then I tried to just use the trunk network as a plain pipe to the L2-gateway and connect to normal Neutron networks. One issue is that the L2-gateway will bridge
the networks, but the services in the network you bridge to is unaware of your existence. This IMO is ok then bridging Neutron network to some remote network, but if you have an Neutron VM and want to utilize various resources in another Neutron network (since
the one you sit on does not have any resources), things gets, let’s say non streamlined.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Another issue with trunk network is that it puts new requirements on the infrastructure. It needs to be able to handle VLAN tagged frames. For a VLAN based
network it would be QinQ.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">My requirements were to have low/no extra cost for VMs using VLAN trunks compared to normal ports, no new bottlenecks/single point of failure. Due to this and
previous issues I implemented the L2 gateway in a distributed fashion and since trunk network could not be realized in reality I only had them in the model and optimized them away. But the L2-gateway + trunk network has a flexible API, what if someone connects
two VMs to one trunk network, well, hard to optimize away.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Anyway, due to these and other issues, I limited my scope and switched to the current trunk port/subport model.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The code that is for review is functional, you can boot a VM with a trunk port + subports (each subport maps to a VLAN). The VM can send/receive VLAN traffic.
You can add/remove subports on a running VM. You can specify IP address per subport and use DHCP to retrieve them etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Bob Melander (bmelande) [mailto:bmelande@cisco.com]
<br>
<b>Sent:</b> den 24 oktober 2014 20:13<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">What scares me a bit about the “let’s find a common solution for both external devices and VMs” approach is the challenge to reach an agreement. I remember a
rather long discussion in the dev lounge in HongKong about trunking support that ended up going in all kinds of directions.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">I work on implementing services in VMs so my opinion is definitely colored by that. Personally, proposal C is the most appealing to me for the following reasons:
It is “good enough”, a trunk port notion is semantically easy to take in (at least to me), by doing it all within the port resource Nova implications are minimal, it seemingly can handle multiple network types (VLAN, GRE, VXLAN, … they are all mapped to different
trunk port local VLAN tags), DHCP should work to the trunk ports and its sub ports (unless I overlook something), the spec already elaborates a lot on details, there is also already code available that can be inspected.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Bob<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">From:
</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>torsdag 23 oktober 2014 23:58<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">There are two categories of problems:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">1. some networks don't pass VLAN tagged traffic, and it's impossible to detect this from the API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">2. it's not possible to pass traffic from multiple networks to one port on one machine as (e.g.) VLAN tagged traffic<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">(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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">(2) is addressed by several blueprints, and these have overlapping ideas that all solve the problem. I would summarise the possibilities
as follows:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">A. Racha's L2 gateway blueprint,
<a href="https://blueprints.launchpad.net/neutron/+spec/gateway-api-extension">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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">B. Isaku's L2 gateway blueprint,
<a href="https://review.openstack.org/#/c/100278/">https://review.openstack.org/#/c/100278/</a>, which is more limited in that it refers only to external connections.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">C. Erik's VLAN port blueprint,
<a href="https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms">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).<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">E. Kyle's very old blueprint,
<a href="https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api">
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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">I would recommend we try and find a solution that works with both external hardware and internal networks. (B) is only a partial solution.<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">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.<br>
-- <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Ian.<o:p></o:p></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">On 23 October 2014 02:13, Alan Kavanagh <<a href="mailto:alan.kavanagh@ericsson.com" target="_blank">alan.kavanagh@ericsson.com</a>> wrote:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">+1 many thanks to Kyle for putting this as a priority, its most welcome.<br>
</span><span class="hoenzb"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#888888">/Alan</span></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
-----Original Message-----<br>
From: Erik Moe [mailto:<a href="mailto:erik.moe@ericsson.com">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">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">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">iawells@cisco.com</a>; <a href="mailto:Calum.Loudon@metaswitch.com">
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">mestery@mestery.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">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">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">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><o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>