[openstack-dev] [Kuryr] IPVLAN data path proposal

Vikas Choudhary choudharyvikas16 at gmail.com
Wed Sep 14 05:10:47 UTC 2016


On Wed, Sep 14, 2016 at 10:33 AM, Vikas Choudhary <
choudharyvikas16 at gmail.com> wrote:

>
>
> On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <limao at cisco.com>
> wrote:
>
>> > Though, not the best person to comment on macvlan vs ipvlan, one
>> limitation of macvlan is that on physical interfaces, maximum possible
>> number of random mac generations may not cope-up with large number of
>> containers on same vm.
>>
>> Thanks, yes, it is a limitation, Vikas.
>> This happened if you use vlan as tenant network. If tenant network use
>> overlay mode, maybe it will be a little bit better for the mac problem.
>> The reason why I mention macvlan can be one of choice is because ipvlan
>> need a very new kernel , it maybe a little bit hard to use in prod
>> env(AFAIK).
>>
>
> You have a valid point regarding ipvlan support in newer kernel versions
> but IIUC overlay mode might not help if nic has a limit on max number of
> macs that it supports in hardware.
>
   for example:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-08030b-securityguide/GUID-ED71C989-6295-4175-8CFE-7EABDEE83E1F.html
<http://www.brocade.com/content/html/en/configuration-guide/fastiron-08030b-securityguide/GUID-ED71C989-6295-4175-8CFE-7EABDEE83E1F.html>

>
>

>
>
>>
>> Regards,
>> Liping Mao
>>
>> From: Vikas Choudhary <choudharyvikas16 at gmail.com>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: 2016年9月14日 星期三 上午11:50
>>
>> To: OpenStack List <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>
>>
>>
>> On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <limao at cisco.com>
>> wrote:
>>
>>> Hi Ivan and Gary,
>>>
>>> maybe we can use macvlan as ipvlan need very new kernel.
>>> allow-address-pairs can aslo allow different mac in vm.
>>> Do we consider macvlan here? Thanks.
>>>
>>
>> Though, not the best person to comment on macvlan vs ipvlan, one
>> limitation of macvlan is that on physical interfaces, maximum possible
>> number of random mac generations may not cope-up with large number of
>> containers on same vm.
>>
>>
>>>
>>> Regards,
>>> Liping Mao
>>>
>>> From: Liping Mao <limao at cisco.com>
>>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Date: 2016年9月13日 星期二 下午9:09
>>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>>
>>> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>>
>>> Hi Gary,
>>>
>>> I mean maybe that can be one choice in my mind.
>>>
>>> Security Group is for each neutron port,in this case,all the docker on
>>> one vm will share one neutron port(if I understand correct),then they will
>>> share the security group on that port,it is not per container per security
>>> group,not sure how to use security group in this case?
>>>
>>> Regards,
>>> Liping Mao
>>>
>>> 在 2016年9月13日,20:31,Loughnane, Gary <gary.loughnane at intel.com> 写道:
>>>
>>> Hi Liping,
>>>
>>>
>>>
>>> Thank you for the feedback!
>>>
>>>
>>>
>>> Do you mean to have disabled security groups as an optional
>>> configuration for Kuryr?
>>>
>>> Do you have any opinion on the consequences/acceptability of disabling
>>> SG?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Gary
>>>
>>>
>>>
>>> *From:* Liping Mao (limao) [mailto:limao at cisco.com <limao at cisco.com>]
>>> *Sent:* Tuesday, September 13, 2016 12:56 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev at lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>>
>>>
>>>
>>> Hi Ivan,
>>>
>>>
>>>
>>> It sounds cool!
>>>
>>>
>>>
>>> for security group and allowed address pair,
>>>
>>> Maybe we can disable port-security,because all the docker in one vm
>>> will share one security group on the vm port. I'm not sure how to use sg
>>> for each docker,maybe just disable port-security can be one of the
>>> choice. then do not need allowed address pairs in this case.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Lipimg Mao
>>>
>>>
>>> 在 2016年9月12日,19:31,Coughlan, Ivan <ivan.coughlan at intel.com> 写道:
>>>
>>>
>>>
>>> *Overview*
>>>
>>> Kuryr proposes to address the issues of double encapsulation and
>>> exposure of containers as neutron entities when containers are running
>>> within VMs.
>>>
>>> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
>>> propose to:
>>>
>>> -          Use allowed-address-pairs configuration for the VM neutron
>>> port
>>>
>>> -          Use IPVLAN for wiring the Containers within VM
>>>
>>>
>>>
>>> In this way:
>>>
>>> -          Achieve efficient data path to container within VM
>>>
>>> -          Better leverage OpenStack EPA(Enhanced Platform Awareness)
>>> features to accelerate the data path (more details below)
>>>
>>> -          Mitigate the risk of vlan-aware-vms not making neutron in
>>> time
>>>
>>> -          Provide a solution that works on existing and previous
>>> openstack releases
>>>
>>>
>>>
>>> This work should be done in a way permitting the user to optionally
>>> select this feature.
>>>
>>>
>>>
>>>
>>> *Required Changes*
>>>
>>> The four main changes we have identified in the current kuryr codebase
>>> are as follows:
>>>
>>> ·         Introduce an option of enabling “IPVLAN in VM” use case. This
>>> can be achieved by using a config file option or possibly passing a command
>>> line argument. The IPVLAN master interface must also be identified.
>>>
>>> ·         If using “IPVLAN in VM” use case, Kuryr should no longer
>>> create a new port in Neutron or the associated VEth pairs. Instead, Kuryr
>>> will create a new IPVLAN slave interface on top of the VM’s master
>>> interface and pass this slave interface to the Container netns.
>>>
>>> ·         If using “IPVLAN in VM” use case, the VM’s port ID needs to
>>> be identified so we can associate the additional IPVLAN addresses with the
>>> port. This can be achieved by querying Neutron’s show-port function and
>>> passing the VMs IP address.
>>>
>>> ·         If using “IPVLAN in VM” use case, Kuryr should associate the
>>> additional IPVLAN addresses with the VMs port. This can be achieved using
>>> Neutron’s allowed-address-pairs flag in the port-update function. We
>>> intend to make use of Kuryr’s existing IPAM functionality to request these
>>> IPs from Neutron.
>>>
>>>
>>>
>>> *Asks*
>>>
>>> We wish to discuss the pros and cons.
>>>
>>> For example, containers exposure as proper neutron entities and the
>>> utility of neutron’s allowed-address-pairs is not yet well understood.
>>>
>>>
>>>
>>> We also wish to understand if this approach is acceptable for kuryr?
>>>
>>>
>>>
>>>
>>>
>>> *EPA*
>>>
>>> The Enhanced Platform Awareness initiative is a continuous program to
>>> enable fine-tuning of the platform for virtualized network functions.
>>>
>>> This is done by exposing the processor and platform capabilities through
>>> the management and orchestration layers.
>>>
>>> When a virtual network function is instantiated by an Enhanced Platform
>>> Awareness enabled orchestrator, the application requirements can be more
>>> efficiently matched with the platform capabilities.
>>>
>>> http://itpeernetwork.intel.com/openstack-kilo-release-is-sha
>>> ping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>>>
>>> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>>>
>>> https://www.brighttalk.com/webcast/12229/181563/epa-features
>>> -in-openstack-kilo
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ivan….
>>>
>>> --------------------------------------------------------------
>>> Intel Research and Development Ireland Limited
>>> Registered in Ireland
>>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>>> Registered Number: 308263
>>>
>>> This e-mail and any attachments may contain confidential material for
>>> the sole use of the intended recipient(s). Any review or distribution by
>>> others is strictly prohibited. If you are not the intended recipient,
>>> please contact the sender and delete all copies.
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> --------------------------------------------------------------
>>> Intel Research and Development Ireland Limited
>>> Registered in Ireland
>>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>>> Registered Number: 308263
>>>
>>> This e-mail and any attachments may contain confidential material for
>>> the sole use of the intended recipient(s). Any review or distribution by
>>> others is strictly prohibited. If you are not the intended recipient,
>>> please contact the sender and delete all copies.
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160914/90d5ed1f/attachment.html>


More information about the OpenStack-dev mailing list