Open Stack

Hi Andreas,
We can definitely set some time to discuss this. 
I am usually available from 5 to 14:00 UTC.  
Let's follow up on IRC (irenab).

BR,
Irena

-----Original Message-----
From: Andreas Scheuring [mailto:scheuran at linux.vnet.ibm.com] 
Sent: Monday, August 25, 2014 11:00 AM
To: Irena Berezovsky
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

Hi Irena,
thanks for your reply. Yes sure, collaboration would be great. 
Do you already have a blueprint out there? Maybe wen can synchup this week to discuss more details? Cause I would like to understand what exactly you're looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 utc). My irc name is scheuran. Maybe we can get in contact this week!

You also where talking about sriov. I saw some blueprint mentioning sriov & macvtap. Do you have any insights into this one, too? What we also would like to do is to introduce macvtap as network virtualization option. Macvtap also registers mac addresses to network adapters...


Thanks,
Andreas


On Sun, 2014-08-24 at 08:51 +0000, Irena Berezovsky wrote:
> Hi Andreas,
> Thank you for this initiative.
> We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. 
> Please let me know if you would like to collaborate on this effort.
> 
> BR,
> Irena
> 
> -----Original Message-----
> From: Andreas Scheuring [mailto:scheuran at linux.vnet.ibm.com]
> Sent: Friday, August 22, 2014 11:16 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support 
> for non promic mode adapters
> 
> Thanks for your feedback. 
> 
> No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. 
> But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. 
> 
> The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community.
> But of course advice and feedback of experienced neutron developers is essential!
> 
> So I will proceed like this
> - Create a blueprint
> - Commit first pieces of code to get early feedback (e.g. ask via the 
> mailing list or irc)
> - Upload a spec (as soon as the repo is available for K)
> 
> Does that make sense for you?
> 
> Thanks,
> Andreas
> 
> 
> 
> On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
> > I think this sounds reasonable. Do you have code for this already, 
> > or are you looking for a developer to help implement it?
> > 
> > 
> > On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring 
> > <scheuran at linux.vnet.ibm.com> wrote:
> >         Hi,
> >         last week I started discussing an extension to the existing
> >         neutron
> >         openvswitch agent to support network adapters that are not in
> >         promiscuous mode. Now I would like to enhance the round to get
> >         feedback
> >         from a broader audience via the mailing list.
> >         
> >         
> >         The Problem
> >         When driving vlan or flat networking, openvswitch requires an
> >         network
> >         adapter in promiscuous mode.
> >         
> >         
> >         Why not having promiscuous mode in your adapter?
> >         - Admins like to have full control over their environment and
> >         which
> >         network packets enter the system.
> >         - The network adapter just does not have support for it.
> >         
> >         
> >         What to do?
> >         Linux net-dev driver offer an interface to manually register
> >         additional
> >         mac addresses (also called secondary unicast addresses).
> >         Exploiting this
> >         one can register additional mac addresses to the network
> >         adapter. This
> >         also works via a well known ip user space tool.
> >         
> >         `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`
> >         
> >         
> >         What to do in openstack?
> >         As neutron is aware of all the mac addresses that are in use
> >         it's the
> >         perfect candidate for doing the mac registrations. The idea is
> >         to modify
> >         the neutron openvswitch agent that it does the registration on
> >         "port
> >         add" and "port remove" via the bridge command.
> >         There would be a new optional configuration parameter,
> >         something like
> >         'non-promisc-mode' that is by default set to false. Only when
> >         set to
> >         true, macs get manually registered. Otherwise the agent
> >         behaves like it
> >         does today. So I guess only very little changes to the agent
> >         code are
> >         required. From my current point of view we do not need any
> >         changes to
> >         the ml2 plug-in.
> >         
> >         
> >         Blueprint or a bug?
> >         I guess it's a blueprint.
> >         
> >         What's the timeframe?
> >         K would be great.
> >         
> >         
> >         
> >         I would be thankful for any feedback on this! Feel free to
> >         contact me
> >         anytime. Thanks in advance!
> >         
> >         Regards,
> >         Andreas
> >         
> >         (irc: scheuran)
> >         
> >         
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >         
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > 
> > --
> > Kevin Benton
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>