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