<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
span.EmailStyle17
{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:Wingdings;
color:#1F497D'>J</span><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'>My T idea is *<b>slightly</b>* different from the port mirroring
idea. We might want to have the semantics in the wire (not the port). So when
you unplug the wire and replug it elsewhere, you don’t have to worry
about mirroring the new port. Similarly you want a bump in the wire use case –
of course you can model it as a vm-x----bumpVM-----vm-y but would it make sense
to just define the wire and have bumpVM part of the wire. <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 guess it’s a port vs wire semantics question. <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'>Hence I started the T discussions. <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'>Regards<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>debo<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 24, 2011 8:57 AM<br>
<b>To:</b> Debo Dutta (dedutta)<br>
<b>Cc:</b> Kyle Mestery (kmestery); openstack@lists.launchpad.net<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>Hi Debo,<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>That makes sense as a use case. One way to model that
would be as a "port mirror" ( <a
href="http://en.wikipedia.org/wiki/Port_mirroring">http://en.wikipedia.org/wiki/Port_mirroring</a>
). Port mirroring is sometimes referred to as SPAN thanks to a large
networking vendor ;) <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>In your example, if VM A is connected on port XYZ, a quantum
plugin might expose a capability to "mirror" the traffic from that
port to either another port on the network (local port mirroring) or to a
remote IP address using encapsulation (remote port mirroring). This would
seem to fit cleanly into our existing model. <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 style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Tue, May 24, 2011 at 8:17 AM, Debo Dutta (dedutta) <<a
href="mailto:dedutta@cisco.com">dedutta@cisco.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>Hi<br>
<br>
I think I was unclear. What I meant were having network wire constructs<br>
like a T where there are actually 3 end points and one of the end points<br>
of the T could be in sniff mode or in a bump-in-the-wire mode. I am not<br>
sure how the current API would support these semantics.<br>
<br>
Use case: imagine vm A talks to B and one wants to monitor the content<br>
by sniffing and the monitoring agent is in vm C. This is not a uncommon<br>
use case.<br>
<br>
Regards<br>
<span style='color:#888888'>Debo</span><o:p></o:p></p>
<div>
<p class=MsoNormal><br>
-----Original Message-----<br>
From: Kyle Mestery (kmestery)<br>
Sent: Monday, May 23, 2011 4:54 PM<br>
To: Debo Dutta (dedutta)<o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal>Cc: Troy Toman; <a
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Subject: Re: [Openstack] [NetStack] Quantum Service API extension<br>
proposal<br>
<br>
Debo:<br>
<br>
A tap is nothing different than a VM vnics from a switch perspective, it<br>
still contains a portion owned by Nova (the tap itself) and it connects<br>
to a port, which is owned by Quantum. So in essence, the tap still has<br>
both a "vif" and a "port" in this terminology.<br>
<br>
Thanks,<br>
Kyle<br>
<br>
On May 23, 2011, at 4:10 PM, Debo Dutta (dedutta) wrote:<br>
<br>
> Hi Troy<br>
><br>
> What about a tap? Its also like a port ....Should that be in quantum?<br>
><br>
> Regards<br>
> Debo<br>
><br>
> From: Troy Toman [mailto:<a href="mailto:troy.toman@RACKSPACE.COM">troy.toman@RACKSPACE.COM</a>]<br>
> Sent: Monday, May 23, 2011 2:10 PM<br>
> To: Debo Dutta (dedutta)<br>
> Cc: Alex Neefus; Ying Liu (yinliu2); <<a
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
> Subject: Re: [Openstack] [NetStack] Quantum Service API extension<br>
proposal<br>
><br>
> I think the idea was slightly different. We were equating a vif to<br>
NIC in a physical server. A port was equated to a switch port on a<br>
physical switch. Doesn't necessarily mean they have to be different.<br>
But, there was a reason we used different terminology.<br>
><br>
> In particular, we felt the vif was something that would continue to be<br>
in the server's domain and managed within Nova. A port was a construct<br>
that is owned and managed by the network service (Quantum).<br>
><br>
> Troy<br>
><br>
> On May 23, 2011, at 3:56 PM, Debo Dutta (dedutta) wrote:<br>
><br>
><br>
> Quick question: it seems we are calling one end of the virtual wire a<br>
port and the other a vif. Is there a reason to do that? Can we just call<br>
say that that a wire connects 2 ports?<br>
><br>
> Also another interesting network scenario is when there is a wire<br>
connecting 2 ports and you have a tap (for all sorts of scenarios). I<br>
think the semantics of the tap might be quite basic.<br>
><br>
> Regards<br>
> debo<br>
><br>
> From: openstack-bounces+dedutta=<a href="http://cisco.com" target="_blank">cisco.com</a>@<a
href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a><br>
[mailto:<a href="mailto:openstack-bounces%2Bdedutta">openstack-bounces+dedutta</a>=<a
href="http://cisco.com" target="_blank">cisco.com</a>@<a
href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>] On<br>
Behalf Of Alex Neefus<br>
> Sent: Monday, May 23, 2011 1:05 PM<br>
> To: Ying Liu (yinliu2); <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Subject: Re: [Openstack] [NetStack] Quantum Service API extension<br>
proposal<br>
><br>
> Hi All -<br>
><br>
> I wanted to lend support to this proposal, however I don't think we<br>
should be so quick to say this whole thing is an extension.<br>
><br>
> We benefit a lot from having a standard capabilities mechanism as part<br>
of our core Quantum API. I like Ying's key value method as well. I think<br>
it's logical, clean and scalable. I propose that basic read access of<br>
"cap" off of our major objects: network, port, interface be included
in<br>
our first release.<br>
><br>
> So in summary I would like to encourage us to add:<br>
> GET /networks/{net_id}/conf<br>
> GET /networks/{net_id}/ports/{port_id}/conf/<br>
> GET {entity}/VIF/conf/<br>
><br>
> Each of these would return a list of keys.<br>
><br>
> Additionally Quantum base should support<br>
> GET /networks/{net_id}/conf/{key}<br>
> GET /networks/{net_id}/ports/{port_id}/conf/{key}<br>
> GET {entity}/VIF/conf/{key}<br>
><br>
> Where {key} is the name of either a standard capability or an<br>
extention capability. We can define an error code now to designate a<br>
capability not supported by the plugin. (i.e. 472 - CapNotSupported)<br>
><br>
> Finally we don't need to standardize on every capability that might be<br>
supported if we provide this simple mechanism. Specific capabilities<br>
Key,Value sets can be added later but or included as vendor specific<br>
extensions.<br>
><br>
> I'm happy to add this to the wiki if there is consensus. Rick/Dan -<br>
Maybe this should be a topic for Tuesdays meeting.<br>
><br>
> Alex<br>
><br>
> ---<br>
> Alex Neefus<br>
> Senior System Engineer | Mellanox Technologies<br>
> (o) <a href="tel:617.337.3116">617.337.3116</a> | (m) <a
href="tel:201.208.5771">201.208.5771</a> | (f) <a href="tel:617.337.3019">617.337.3019</a><br>
><br>
><br>
><br>
><br>
><br>
> From: openstack-bounces+alex=<a href="http://mellanox.com" target="_blank">mellanox.com</a>@<a
href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a><br>
[mailto:<a href="mailto:openstack-bounces%2Balex">openstack-bounces+alex</a>=<a
href="http://mellanox.com" target="_blank">mellanox.com</a>@<a
href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>] On<br>
Behalf Of Ying Liu (yinliu2)<br>
> Sent: Saturday, May 21, 2011 1:10 PM<br>
> To: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Subject: [Openstack] [NetStack] Quantum Service API extension proposal<br>
><br>
> Hi all,<br>
><br>
> We just posted a proposal for OpenStack Quantum Service API extension<br>
on community wiki page<br>
athttp://<a
href="http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=vi%0d%0aew&target=quantum_api_extension.pdf"
target="_blank">wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=vi<br>
ew&target=quantum_api_extension.pdf</a><br>
> or<br>
><br>
<a
href="http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view%0d%0a&target=quantum_api_extension.docx"
target="_blank">http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view<br>
&target=quantum_api_extension.docx</a><br>
><br>
> Please review and let us know your comments/suggestions. An etherpad<br>
page is created for API extension<br>
discussionhttp://<a href="http://etherpad.openstack.org/uWXwqQNU4s"
target="_blank">etherpad.openstack.org/uWXwqQNU4s</a><br>
><br>
> Best,<br>
> Ying<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">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><br>
><br>
><br>
> Confidentiality Notice: This e-mail message (including any attached or<br>
> embedded documents) is intended for the exclusive and confidential use<br>
of the<br>
> individual or entity to which this message is addressed, and unless<br>
otherwise<br>
> expressly indicated, is confidential and privileged information of<br>
Rackspace.<br>
> Any dissemination, distribution or copying of the enclosed material is<br>
prohibited.<br>
> If you receive this transmission in error, please notify us<br>
immediately by e-mail<br>
> at <a href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>, and
delete the original message.<br>
> Your cooperation is appreciated.<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">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><br>
<br>
<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">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>
</div>
</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>