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

Vikas Choudhary choudharyvikas16 at gmail.com
Wed Sep 14 03:50:13 UTC 2016


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-
> shaping-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.openstack.org?subject:unsubscribe
> 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/d8ca2275/attachment.html>


More information about the OpenStack-dev mailing list