hi irena,

in the proposal of andreas you want to enforce the non-promisc mode
per l2-agent? so every port managed by this agent will have to be in a
non-promisc state?
at a first read of the mail, I understood that you want to manage that
per port with an extension.
By using an extension, an agent could host promisc and non-promisc
net-adapters, and other MD could potentially leverage this info (at
least LB MD).

On Wed, Aug 27, 2014 at 3:45 PM, Irena Berezovsky <ire...@mellanox.com> wrote:
> Hi Mathieu,
> We had a short discussion with Andreas about the use case stated below and 
> also considered the SR-IOV related use case.
> It seems that all required changes can be encapsulated in the L2 OVS agent, 
> since it requires to add fdb mac registration on adapted interface.
> What was your idea related to extension manager in ML2?
>
> Thanks,
> Irena
>
> -----Original Message-----
> From: Mathieu Rohon [mailto:]
> Sent: Wednesday, August 27, 2014 3:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non 
> promic mode adapters
>
> you probably should consider using the future extension manager in ML2 :
>
> https://review.openstack.org/#/c/89211/
>
> On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky <ire...@mellanox.com> 
> wrote:
>> 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:scheu...@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:scheu...@linux.vnet.ibm.com]
>>> Sent: Friday, August 22, 2014 11:16 AM
>>> To: openstack-dev@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
>>> > <scheu...@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@lists.openstack.org
>>> >
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Kevin Benton
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to