Open Stack

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) <dedutta at 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 at 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.toman at RACKSPACE.COM]
> > Sent: Monday, May 23, 2011 2:10 PM
> > To: Debo Dutta (dedutta)
> > Cc: Alex Neefus; Ying Liu (yinliu2); <openstack at 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.com at lists.launchpad.net
> [mailto:openstack-bounces+dedutta=cisco.com at lists.launchpad.net] On
> Behalf Of Alex Neefus
> > Sent: Monday, May 23, 2011 1:05 PM
> > To: Ying Liu (yinliu2); openstack at 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.com at lists.launchpad.net
> [mailto:openstack-bounces+alex=mellanox.com at lists.launchpad.net] On
> Behalf Of Ying Liu (yinliu2)
> > Sent: Saturday, May 21, 2011 1:10 PM
> > To: openstack at 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 at 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 abuse at rackspace.com, and delete the original message.
> > Your cooperation is appreciated.
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110524/5a3265ac/attachment.html>