Thanks Liping!

Yes we are using the kuryr ipam driver in the PoC code, otherwise we have to 
manage the IP addresses manually.
We chose IPVlan mostly due to the hardware limitation of the mac addresses on 
the NIC (i.e. No. of virtual devices created on a master exceeds the mac 
capacity and puts the NIC in promiscuous mode and performance is a concern)

Thanks,
Louise

From: Liping Mao (limao) [mailto:li...@cisco.com]
Sent: Monday, September 19, 2016 11:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

Thanks for your reply, your poc is cool, Louise!
You already can use --ipam-driver=kuryr to use kuryr-ipam to do this in your 
poc code?
BTW, any reason you choose ipvlan, but not macvlan.

Regards,
Liping Mao

From: <Daly>, Louise M <louise.m.d...@intel.com<mailto:louise.m.d...@intel.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: 2016年9月19日 星期一 下午5:26
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

Hi Liping,

I am also on the team working on the ipvlan proposal and I will try and answer 
your question the best I can.

I think from your blog post you understand the proposal correctly. The steps 
you mentioned are very similar to the code PoC with ipvlan.

These are the steps we followed when we manually set up a IPVlan PoC, this does 
not include IPAM. We managed the IP addresses manually.

1.  Create two VMs on a private network

2.  Create a docker ipvlan network (eg. docker network  create -d ipvlan 
--subnet=192.168.0.0/24 --gateway=192.168.0.1 -o ipvlan_mode=l2 -o parent=ens3 
ipvl_net)

3.  Run some containers on the network (eg. docker run --net=ipvl_net 
--ip=192.168.0.15 -it --rm alpine /bin/sh)

4.  Associate the IP addresses with the VM port
Containers can now ping each other and VMs on the same network.

In the code PoC we use the kuryr-ipam for IP address management, so the extra 
step of creating the ports in your version we have incorporated into the code 
PoC.

Thanks,
Louise
From: Liping Mao (limao) [mailto:li...@cisco.com]
Sent: Sunday, September 18, 2016 3:00 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

Hi Ivan,

I tried your proposal with manually steps in Mitaka, I use netns(instead of 
docker container) and macvlan(instead of ipvlan) in my test:
https://lipingmao.github.io/2016/09/18/kuryr_macvlan_ipvlan_datapath_poc.html

Did I understand correct? Any comments will be very appricated.
Thanks.

Regards,
Liping Mao

From:  Liping Mao <li...@cisco.com<mailto:li...@cisco.com>>
Reply-To:  OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date:  2016年9月13日星期二下午7:56
To:  OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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.cough...@intel.com<mailto:ivan.cough...@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 ChangesThe 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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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.
--------------------------------------------------------------
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to