Hi Debo,<div><br></div><div>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 ;) </div>
<div><br></div><div>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. </div>
<div><br></div><div>Dan</div><div><br><br><div class="gmail_quote">On Tue, May 24, 2011 at 8:17 AM, Debo Dutta (dedutta) <span dir="ltr"><<a href="mailto:dedutta@cisco.com">dedutta@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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>
<font color="#888888">Debo<br>
</font><div class="im"><br>
-----Original Message-----<br>
From: Kyle Mestery (kmestery)<br>
Sent: Monday, May 23, 2011 4:54 PM<br>
To: Debo Dutta (dedutta)<br>
</div><div><div></div><div class="h5">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" value="+16173373116">617.337.3116</a> | (m) <a href="tel:201.208.5771" value="+12012085771">201.208.5771</a> | (f) <a href="tel:617.337.3019" value="+16173373019">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
ew&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
&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><br>
</div></div></blockquote></div><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>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br><br>
</div>