On Wed, Sep 14, 2016 at 10:33 AM, Vikas Choudhary < [email protected]> wrote:
> > > On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <[email protected]> > 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 <[email protected]> >> Reply-To: OpenStack List <[email protected]> >> Date: 2016年9月14日 星期三 上午11:50 >> >> To: OpenStack List <[email protected]> >> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal >> >> >> >> On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <[email protected]> >> 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 <[email protected]> >>> Reply-To: OpenStack List <[email protected]> >>> Date: 2016年9月13日 星期二 下午9:09 >>> To: OpenStack List <[email protected]> >>> >>> 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 <[email protected]> 写道： >>> >>> 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:[email protected] <[email protected]>] >>> *Sent:* Tuesday, September 13, 2016 12:56 PM >>> *To:* OpenStack Development Mailing List (not for usage questions) < >>> [email protected]> >>> *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 <[email protected]> 写道： >>> >>> >>> >>> *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: [email protected] >>> ?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: [email protected] >>> ?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected] >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
