<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 13, 2016 at 5:26 PM, Liping Mao (limao) <span dir="ltr"><<a href="mailto:limao@cisco.com" target="_blank">limao@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div>Hi Ivan，</div>
<div><br>
</div>
<div>It sounds cool！</div>
<div><br>
</div>
<div>for security group and allowed address pair，</div>
<div>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. </div></div></blockquote><div><span style="background-color:rgb(255,255,0)">Vikas:</span></div><div><span style="background-color:rgb(255,255,0)"><br></span></div><div>Can you please elaborate "maybe just disable port-security can be one of the choice. then do not need allowed address pairs in this case" ?</div><div><br></div><div>Are you suggesting a solution where by disabling port security, each container can have its own security group? Would you mind please explaining a bit more for me ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>
</div>
<div><br>
</div>
<div>Regards，</div>
<div>Lipimg Mao</div><div><div>
<div><br>
在 2016年9月12日，19:31，Coughlan, Ivan <<a href="mailto:ivan.coughlan@intel.com" target="_blank">ivan.coughlan@intel.com</a>> 写道：<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>Overview<u></u><u></u></b></p>
<p class="MsoNormal">Kuryr proposes to address the issues of double encapsulation and exposure of containers as neutron entities when containers are running within VMs.<u></u><u></u></p>
<p class="MsoNormal">As an alternative to the vlan-aware-vms and use of ovs within the VM, we propose to:<u></u><u></u></p>
<p><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span>Use allowed-address-pairs configuration for the VM neutron port<u></u><u></u></p>
<p><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span>Use IPVLAN for wiring the Containers within VM<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In this way:<u></u><u></u></p>
<p><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span>Achieve efficient data path to container within VM<u></u><u></u></p>
<p><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span>Better leverage OpenStack EPA(Enhanced Platform Awareness) features to accelerate the data path (more details below)<u></u><u></u></p>
<p><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span>Mitigate the risk of vlan-aware-vms not making neutron in time<u></u><u></u></p>
<p><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span>Provide a solution that works on existing and previous openstack releases<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This work should be done in a way permitting the user to optionally select this feature.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<h2><b><span lang="EN-US" style="font-size:11pt;line-height:105%;font-family:calibri,sans-serif;color:windowtext">Required Changes<u></u><u></u></span></b></h2>
<p class="MsoNormal">The four main changes we have identified in the current kuryr codebase are as follows:<u></u><u></u></p>
<p style="margin-right:0cm;margin-bottom:8pt;margin-left:18pt;line-height:105%">
<span style="font-family:symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span></span>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.<u></u><u></u></p>
<p style="margin-right:0cm;margin-bottom:8pt;margin-left:18pt;line-height:105%">
<span style="font-family:symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span></span>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.<u></u><u></u></p>
<p style="margin-right:0cm;margin-bottom:8pt;margin-left:18pt;line-height:105%">
<span style="font-family:symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span></span>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.<u></u><u></u></p>
<p style="margin-right:0cm;margin-bottom:8pt;margin-left:18pt;line-height:105%">
<span style="font-family:symbol"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times new roman"">
</span></span></span>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
<span style="font-family:"courier new"">allowed-address-pairs</span> flag in the <span style="font-family:"courier new"">
port-update</span> function. We intend to make use of Kuryr’s existing IPAM functionality to request these IPs from Neutron.<u></u><u></u></p>
<p class="MsoNormal"><b><u></u> <u></u></b></p>
<p class="MsoNormal"><b>Asks<u></u><u></u></b></p>
<p class="MsoNormal">We wish to discuss the pros and cons.<u></u><u></u></p>
<p class="MsoNormal">For example, containers exposure as proper neutron entities and the utility of neutron’s allowed-address-pairs is not yet well understood.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We also wish to understand if this approach is acceptable for kuryr?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>EPA<u></u><u></u></b></p>
<p class="MsoNormal"><span style="color:rgb(37,37,37);background-image:initial;background-color:white;background-size:initial;background-origin:initial;background-clip:initial;background-position:initial;background-repeat:initial">The Enhanced Platform Awareness initiative is a continuous program to enable fine-tuning of the platform for virtualized network functions.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(37,37,37);background-image:initial;background-color:white;background-size:initial;background-origin:initial;background-clip:initial;background-position:initial;background-repeat:initial">This is done by exposing the processor and platform capabilities through the management and orchestration layers.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(37,37,37);background-image:initial;background-color:white;background-size:initial;background-origin:initial;background-clip:initial;background-position:initial;background-repeat:initial">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.</span><u></u><u></u></p>
<p class="MsoNormal"><a href="http://itpeernetwork.intel.com/openstack-kilo-release-is-shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/" target="_blank">http://itpeernetwork.intel.com<wbr>/openstack-kilo-release-is-sha<wbr>ping-up-to-be-a-milestone-for-<wbr>enhanced-platform-awareness/</a><u></u><u></u></p>
<p class="MsoNormal"><a href="https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf" target="_blank">https://networkbuilders.intel.<wbr>com/docs/OpenStack_EPA.pdf</a><u></u><u></u></p>
<p class="MsoNormal"><a href="https://www.brighttalk.com/webcast/12229/181563/epa-features-in-openstack-kilo" target="_blank">https://www.brighttalk.com/web<wbr>cast/12229/181563/epa-features<wbr>-in-openstack-kilo</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Regards,<u></u><u></u></p>
<p class="MsoNormal">Ivan….<u></u><u></u></p>
</div>
<p>------------------------------<wbr>------------------------------<wbr>--<br>
Intel Research and Development Ireland Limited<br>
Registered in Ireland<br>
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare<br>
Registered Number: 308263</p>
<p>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.</p>
<p></p>
</div>
</blockquote>
</div></div><blockquote type="cite">
<div><span>______________________________<wbr>______________________________<wbr>______________</span><span><br>
<span>OpenStack Development Mailing List (not for usage questions)</span><br>
<span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org</a>?subject:unsubscrib<wbr>e</span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a></span><br>
</span></div>
</blockquote>
</div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><br></div></div>