<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" 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.b
{mso-style-name:b;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle20
{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'>As I said in my previous reply, I’m all for having cohesive API model across Openstack components, at the same time we should be clear to take the requirements into consideration and map it to our Netstack use cases properly and if possible/required enhance it. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>BTW: The comment posted in the Etherpad was made by me prior to the design summit and still echoes the same point as I said in the previous line. This was also before we agreed as a team in the summit for plug-in based model though it was in various proposals. We didn’t spend any time discussing details - how multiple plug-ins advertise/register and various other details to start with. Also I’m not sure couple of us agreeing or disagreeing in the etherpad can be taken as complete team decision as I’m also new to this process.<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'>I also see other emails from Rick C, Dan Prince and Jorge W and there is already some work happened and Jorge is working towards a formal approval process.<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'>I think we should quickly start with this as basis and review, enhance it if we see a value in concept like “port profiles” proposed in Ying’s doc for Quantum extensions. I agree we need to discuss, decide on this as soon as possible and move on to start developing Quantum side extensions.<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'>Ram<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 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> Saturday, May 21, 2011 1:06 PM<br><b>To:</b> Ram Durairaj (radurair)<br><b>Cc:</b> Ying Liu (yinliu2); openstack@lists.launchpad.net; Jorge Williams<br><b>Subject:</b> Re: [Openstack] [NetStack] Quantum Service API extension proposal<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Sat, May 21, 2011 at 11:51 AM, Ram Durairaj (radurair) <<a href="mailto:radurair@cisco.com">radurair@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'> </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 far as I remember, In Design summit, we’ve agreed to expose “extra” attributes for Virtual networks and any other vendor specific features using “API-Extensions” and possibly thru existing Openstack extension mechanisms. Don’t recall that we’ve concluded on Jorge’s proposal.</span><o:p></o:p></p></div></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'> </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'>Also I think it’s better to follow a consistent model across the Openstack , provided the current Jorge’s proposal is generic enough and flexible enough for what we are trying to do in our NetStack side. I think we should take a look at Jorge’s and Ying model and as a team we decide.</span><o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hi Ram, <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Apologies if I have misinterpreted the consensus here, but I seem to remember widespread verbal agreement during the summit on basing the API and its extensions off of the standard OpenStack mechanisms. Also, the main Quantum Diablo Etherpad: <a href="http://etherpad.openstack.org/6LJFVsQAL7">http://etherpad.openstack.org/6LJFVsQAL7</a> (specific text pasted below) seems to show you and Salvatore agreeing to Erik's comment that we should use the standard OpenStack API and it includes a link to Jorge's doc on OpenStack Extensions. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Jorge's proposal for extensions includes things like extension querying/discovery, a mechanism for preventing conflicts between extension fields from different vendors, etc. that I think are pretty fundamental to the what we'll need to make Quantum successful. As a result, I am personally still strongly in favor of using the standard OpenStack extension mechanism as the base of our API mechanism for Quantum. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think Jorge's work is still in progress (Jorge?) so there should be an opportunity to provide input on that front as well. If there are types of extensions that you are thinking about that won't work in the standard OpenStack model or if you simply think there is a better way to do it, that is something we should try to flush out ASAP. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Dan<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><div><p class=MsoNormal>======= Start From Etherpad ======== <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div id=magicdomid123><p class=MsoNormal style='line-height:12.75pt'><span class=b><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>4. For EACH network service (could be one or more depending on question #3), should there be a single, canonical REST API or should there be multiple APIs? By canonical, we mean the base API is the same regardless of the driver/plugin that is implementing it.</span></b></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> <span class=b><b> How should API extensibility be handled? </b></span><o:p></o:p></span></p></div><div id=magicdomid124><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div id=magicdomid125><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>POSSIBLE ANSWERS:<o:p></o:p></span></p></div><div id=magicdomid126><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div id=magicdomid127><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>EC - [8] We should strive for a single approach across all Open Stack services. To that end, we should follow the nova model and have a single "core" REST API that is applicable across all drivers/service engines. Where particular operations, headers, attributes, etc. are niche or vendor specific, API extensions should be implemented that allow for those capabilities to be programatically exposed but not required to be supported by all drivers/service engines. If you are not familiar with the concept of OpenStack API extensions, there is a presentation here - <a href="http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=get&target=Extensions.pdf">http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=get&target=Extensions.pdf</a>. Jorge is also doing a talk about this on Tue, 2PM at the Diablo summit.<o:p></o:p></span></p></div><div id=magicdomid128><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div id=magicdomid129><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>RamD[8] Completely agree. APIs should be OpenStack API model<o:p></o:p></span></p></div><div id=magicdomid130><p class=MsoNormal style='line-height:12.75pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span class=apple-style-span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>SO[8]: Agree with Erik and Ram.</span></span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> ======= End From Etherpad ======== <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><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'> </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 informed our Netstack team during our Design Summit, absolutely. we can take up the API extensions and Sure, Ying can lead and help develop the workstream and the related code contributions as part of overall Quantum. I’ll let Ying add more here .</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'><br>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'><br>Ram</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'> </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'> </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'> openstack-bounces+radurair=<a href="http://cisco.com" target="_blank">cisco.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a> [mailto:<a href="mailto:openstack-bounces%2Bradurair" target="_blank">openstack-bounces+radurair</a>=<a href="http://cisco.com" target="_blank">cisco.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>] <b>On Behalf Of </b>Dan Wendlandt<br><b>Sent:</b> Saturday, May 21, 2011 11:05 AM<br><b>To:</b> Ying Liu (yinliu2)</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] Quantum Service API extension proposal<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Ying,<o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks for sending this out. I think many of the capabilities you are looking to introduce (ability to configure ACLs, QoS, packet statistics) are definitely things we will want Quantum to expose as API extensions (and possibly in the future, as part of the base API if they are sufficiently general). <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>During the summit we had agreed that extensions to Quantum would follow the "standard" openstack extension mechanisms proposed by Jorge Williams, see: <a href="http://www.slideshare.net/RackerWilliams/openstack-extensions" target="_blank">http://www.slideshare.net/RackerWilliams/openstack-extensions</a><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I've been trying to find someone to take a lead on building the API extension framework within quantum to provide plugins with the ability to register such extensions in a way compatible with Jorge's proposal, so perhaps you would like to take the lead on designing and coding that? The blueprint is at: <a href="https://blueprints.launchpad.net/network-service/+spec/quantum-api-extensions" target="_blank">https://blueprints.launchpad.net/network-service/+spec/quantum-api-extensions</a> . Out plan from the summit was that all functionality except the base "network connectivity" would initially be exposed as extensions, with the ability for these extensions to be proposed as additions to the base API in the future. Thanks, <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Sat, May 21, 2011 at 10:09 AM, Ying Liu (yinliu2) <<a href="mailto:yinliu2@cisco.com" target="_blank">yinliu2@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'>Hi all,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We just posted a proposal for OpenStack Quantum Service API extension on community wiki page at <a href="http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.pdf" target="_blank">http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.pdf</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>or <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.docx" target="_blank">http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.docx</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Please review and let us know your comments/suggestions. An etherpad page is created for API extension discussion <a href="http://etherpad.openstack.org/uWXwqQNU4s" target="_blank">http://etherpad.openstack.org/uWXwqQNU4s</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Best,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ying<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></body></html>