<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 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0in;
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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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'>Hi Dan,<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. By using the type “ethernet” the decision about which bridge to use is made by the script which is referenced by the “script” element in the interface, right?<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'> <interface type='ethernet'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <target dev='vnet7'/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <script path='/etc/qemu-ifup-mynet'/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </interface<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'>In that case, how would Nova know which script to point to? Is it always the same script?<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'>In the context of 802.1Qbh (VN-Tag), I have worked with it before, so here is an example interface configuration:<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'> <interface type='direct'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <mac address='02:16:3e:65:a9:e7'/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <source dev='eth4' mode='private'/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <virtualport type='802.1Qbh'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <parameters profileid='enterprise-xyz'/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </virtualport><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <model type='virtio'/><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </interface><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'>To construct the above configuration, the source dev, i.e. “eth4” and the profileid, i.e. “enterprise-xyz” has to be known. The profile “enterprise-xyz” itself has the VLAN Id (among other pieces of network information) encapsulated. Again, the question is, how will Nova know the “source dev” and “profiled”?<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'>~Sumit.<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 style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><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"'> Dan Wendlandt [mailto:dan@nicira.com] <br><b>Sent:</b> Tuesday, May 31, 2011 9:53 AM<br><b>To:</b> Sumit Naiksatam (snaiksat)<br><b>Cc:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack][NetStack] "Attach resource to port" semantics<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Sumit, responses inline. Thanks,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Dan<o:p></o:p></p><div><p class=MsoNormal>On Tue, May 31, 2011 at 9:12 AM, Sumit Naiksatam (snaiksat) <<a href="mailto:snaiksat@cisco.com">snaiksat@cisco.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>Hi Dan,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>Thanks for your prompt response on this.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>As I understand from your explanation, the knowledge of the edge binding resides with Nova, and in the case of my example that edge binding is br100. Is that correct? If so, how does Nova acquire this knowledge? I ask because, my expectation was that br100 (i.e. the Linux bridge) is created and managed by Quantum (and/or the plugin underneath).</span><o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The way I see it, the "edge binding" is determined by Nova, then communicated to Quantum. It is the one bit of information that must be shared across both systems. Nova acquires this information as part of the VM creation process. For example, in the case of libvirt with type ethernet on a linux system, nova would be the one creating the linux device that represents the VM NIC. It must then pass this edge binding of (device-name, linux-system, interface-id) to Quantum, which must be running a plugin that knows how to manage a vswitch on that linux host that can get/receive packets from the linux device. <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>Also, if we move away from using the interface type bridge (in the context of libvirt) to ethernet as you suggest, would that be the only type that would be supported? If so, that will not work with VN-Tag/VEPA since that requires a type direct. If we are indeed not limiting to just the ethernet type, then how does Nova know which type to use (assuming that the knowledge of the underlying network connectivity resides with Quantum)?</span><o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Our goal is to add more flexibility to the "vif plugging" portion of the libvirt code to support multiple use cases, including both "ethernet" and "direct". In fact, VN-Tag/VEPA was one of the use cases we explored when deciding on the model. Based on my understanding of how libvirt handles 802.1Qbg, the libvirt XML includes a <virtualport> object that corresponds to such a VM NIC and this virtual port includes parameters that identify the VM, including a an "instanceid" parameter that globally represents the virtual port. I would expect that the "edge-binding" in this case would be (instanceid, interface-id). As a note, I have not actually used libvirt like this on an actual VN-Tag/VEPA system. If you are able to explore this use case in more detail it would be great feedback for the Quantum design. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>Its good to hear that the work on Quantum and Nova refactoring is going well. While that is in progress, it might be helpful to get some skeletal flowcharts (or even textual descriptions) describing the flows (with the interaction between Nova and Quantum fleshed out).</span><o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I agree that would be valuable. We'll work on this.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>Thanks,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;color:#1F497D'>~Sumit. </span><o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:10.0pt'> Dan Wendlandt [mailto:<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>] <br><b>Sent:</b> Monday, May 30, 2011 11:15 PM<br><b>To:</b> Sumit Naiksatam (snaiksat)</span><o:p></o:p></p><div><p class=MsoNormal><br><b>Cc:</b> <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><o:p></o:p></p></div><div><p class=MsoNormal><b>Subject:</b> Re: [Openstack] [NetStack] "Attach resource to port" semantics<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Sumit,<o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This is a great question to be asking, as it gets to the heart of how Quantum will work with Nova (or any any other OpenStack service that plugs into the network). As you suggest, our goal here is to try and come up with a clean separation between the responsibilities of Nova and theresponsibilitiesof Quantum.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The way I think about it, the act of "attaching a VM NIC to the network" actually happens at two distinct layers: logical (managed by Quantum) and, for lack of a better name, non-logical (managed by Nova). <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Non-Logical: This occurs when the Nova spins up a VM and plugs the VM NIC into the vswitch. For example, with Nova using libvirt, this amounts to creating a linux device representing the VM NIC (e.g., tap0) and associating it with a vswitch (e.g., br0). With Quantum, this act alone should not actually cause the VM to be able to send and receive packets, unless the logical connectivity of the VM NIC has already been setup (see below). Instead, it is just establishing a channel by which vswitch controlled by Quantum can pass packets to and from the VM NIC once the proper logical connectivity has been specified. With Quantum, Nova must have an "interface-id" for each VM NIC. When Nova spins up a VM and creates a new port on a vswitch, it communicates to Quantum the interface-id associated with that port on the vswitch. We refer to as the "edge binding" (see slides #7 and #14 in<a href="http://www.slideshare.net/danwent/quantum-diablo-summary" target="_blank">http://www.slideshare.net/danwent/quantum-diablo-summary</a>). <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Logical: This type of "plugging" is done by the tenant via the Quantum API. The Quantum API exposes the concept of networks and ports on those networks to model this logical connectivity. Interface-ids can be "attached" to a port, indicating the network connectivity that should be seen by the VM NIC with the associated interface-id (e.g., two VMs attached to ports on the same logical network can connect directly at L2, others cannot). A simple implementation of a logical network could be to put implement each logical network as a different VLAN within a single physical L2 domain, with a Quantum plugin managing the vswitch to put each port on the appropriate VLAN (see slide #15). <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The motivation for this design is that Nova does not need to be involved when the logical connectivity of a VM changes. Nova just needs to worry about making sure the vswitch (or physical switch if using VNTag/VEPA) managed by the Quantum plugin has a channel to pass bits to and from each VM NIC, and knows the identify of each of those channels (the edge binding). It is up to the Quantum plugin managing the vswitch to make sure the right logical connectivity (or lack thereof) is implemented. <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Along with folks from the Nova team, we've been discussing the details of how this model applies to different Nova "virt" layerimplementations, including libvirt, XenServer, VMware, etc. As you suggest, the libvirt model where Nova specifies only a bridge to connect to is less flexible, so we're looking at using an <interface> elements of type "ethernet" instead of type "bridge" as an alternative (Ryu did some work on this in a branch). <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Implementation work on an experimental version of Quantum has been progressing well, so in another week or two I would expect that we can have a full stack of code that people can play with using a slightly tweaked version of Nova. Having thisavailablewill hopefully make the above description of a logical + non-logical plugging step more concrete and will serve as a good vehicle for feedback from the community. Happy to chat more about this tomorrow at the Networking meeting on IRC.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>dan<o:p></o:p></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, May 30, 2011 at 9:01 PM, Sumit Naiksatam (snaiksat) <<a href="mailto:snaiksat@cisco.com" target="_blank">snaiksat@cisco.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Hi,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I would like to request clarity on the semantics of the "attach resource to port" operation proposed in Quantum in the context of spawning a VM. Let's discuss this with respect to a specific example. As of today, nova-compute generates the domain configuration (libvirt.xml), including the network interface configuration as below -</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><interface type='bridge'></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><source bridge='br100'/></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><mac address='02:16:3e:78:4d:84'/></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><!-- <model type='virtio'/> CANT RUN virtio network right now --></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><filterref filter="nova-instance-instance-00000001"></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><parameter name="IP" value="10.1.0.2" /></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><parameter name="DHCPSERVER" value="10.1.0.1" /></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><parameter name="PROJNET" value="10.1.0.0" /></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><parameter name="PROJMASK" value="255.255.255.128" /></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'></filterref></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'></interface></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>By virtue of specifying "br100" as the bridge to connect to, nova-compute is configuring the attachment from the virtual NIC (on the VM) to the network, and the "attachment" operation is (implicitly) realized when the VM is spawned (and running).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>With the introduction of the "attach resource to port" operation, we are introducing an explicit step in the process of the VM spawning. It implies that prior to invoking the "attach resource to port" operation, nova-compute would not know which bridge to connect to (i.e. it would not know the identity of "br100"). So does nova-compute first spawn the VM without the network interface configuration? If that is the case, it brings us to the next question, which is, what does the "attach resource to port" operation actually do? There are at least two possibilities here -</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>(1) The operation merely results in the identification (and, if required, the configuration) of "br100" as the bridge to connect the VM's network interface to. If that is the case, we need a way to propagate this information (i.e. "br100") back to the entity which invoked the "attach resource to port" operation. Subsequently, that same entity will have to perform another action to craft the VM's network interface configuration (with the acquired knowledge of "br100") and also add this network interface to the configuration of the VM (by making appropriate libvirt calls). Adding this network interface configuration could be done, both, prior to starting the VM, or even while the VM is running.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>OR </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>(2) The operation not only identifies/configuration of "br100", but also crafts the VM's network interface configuration, and adds that interface to the VM (by making appropriate libvirt calls). Note that this second option amounts to Quantum controlling a resource on the VM (which ideally should be outside the scope of Quantum).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>OR, is it something else?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Kindly let me know what you thoughts are on this. As projected above, these semantics have implications on how nova-compute will deal with spawning VMs (and it might be different from what it is today), and hence it might be important to address this issue sooner.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Thanks,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>~Sumit.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>PS: As I write this, it occurs to me that it's not very clear as to what the "create port" operation would do in the above case as well, since no actual port is created on the bridge. Any thoughts?</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><br><br clear=all><br>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <br>Nicira Networks, Inc. <br><a href="http://www.nicira.com" target="_blank">www.nicira.com</a> | <a href="http://www.openvswitch.org" target="_blank">www.openvswitch.org</a><br>Sr. Product Manager <br>cell: <a href="tel:650-906-2650" target="_blank">650-906-2650</a><br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p></div></div></div></div></div></blockquote></div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br clear=all><br>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <br>Nicira Networks, Inc. <br><a href="http://www.nicira.com">www.nicira.com</a> | <a href="http://www.openvswitch.org">www.openvswitch.org</a><br>Sr. Product Manager <br>cell: 650-906-2650<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p></div></div></body></html>