<div dir="ltr"><span id="gmail-docs-internal-guid-9a586633-da2d-9863-06ba-6c78ef704f7a"><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;vertical-align:baseline;white-space:pre-wrap">
@Armando:
IMO the spec [0] is not about enablement of Trunks and baremetal. This spec is rather about trying to make user request with any network configuration (number of requested NICs) to be able successfully deployed on ANY ironic node (even when number of hardware interfaces is less than number of requested attached networks to instance) by implicitly creating neutron trunks on the fly. </span></p><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;vertical-align:baseline;white-space:pre-wrap">I have  a concerns about it and left a comment [1]. The guaranteed number of NICs on hardware server should be  available to user via nova flavor information. User should decide if he needs a trunk or not only by his own, as his image may even not support trunking. I suggest that creating trunks implicitly (w/o user knowledge) shouldn't happen.</span></p><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Current trunks implementation in Neutron will work just fine with baremetal case with one small addition:</span></p><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">1. segmentation_type and segmentation_id should not be API mandatory fields at least for the case when provider segmentation is VLAN.</span></p><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">2. User still should know what segmentation_id was picked to configure it on Instance side. (Not sure if it is done automatically via network metadata at the moment.). So it should be inherited from network provider:segmentation_id and visible to the user.</span></p><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">@Kevin:
Having VLAN mapping support on the switch will not solve problem described in scenario 3 when multiple users pick the same segmentation_id for different networks and their instances were spawned to baremetal nodes on the same switch.</span></p><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">I don’t see other option than to control uniqueness of segmentation_id on Neutron side for baremetal case.</span></p><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Reference:</span></p><div dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><br></div><p dir="ltr" style="line-height:1.6;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">[0] </span><a href="https://review.openstack.org/#/c/277853/" style="text-decoration:none"><span style="font-size:12.6667px;font-family:arial;background-color:transparent;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://review.openstack.org/#/c/277853/</span></a></p><span style="font-size:14.6667px;font-family:arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap">[1] </span><a href="https://review.openstack.org/#/c/277853/10/specs/approved/VLAN-aware-baremetal-instances.rst@35" style="text-decoration:none"><span style="font-size:14.6667px;font-family:arial;background-color:transparent;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://review.openstack.org/#/c/277853/10/specs/approved/VLAN-aware-baremetal-instances.rst@35</span></a></span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton <span dir="ltr"><<a href="mailto:kevin@benton.pub" target="_blank">kevin@benton.pub</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just to be clear, in this case the switches don't support VLAN translation (e.g. [1])? Because that also solves the problem you are running into. This is the preferable path for bare metal because it avoids exposing provider details to users and doesn't tie you to VLANs on the backend.<div><br></div><div>1. <a href="http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/" target="_blank">http://ipcisco.com/vlan-<wbr>mapping-vlan-translation-%E2%<wbr>80%93-part-2/</a></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 7:49 AM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-5705913576746559854h5">On 7 December 2016 at 04:02, Vasyl Saienko <span dir="ltr"><<a href="mailto:vsaienko@mirantis.com" target="_blank">vsaienko@mirantis.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="ltr">Armando, Kevin,<div><br></div><div>Thanks for your comments.</div><div><br></div><div>To be more clear we are trying to use neutron trunks implementation with baremetal servers (Ironic). Baremetal servers are plugged to Tor (Top of the Rack) switch. User images are spawned directly onto hardware. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Ironic uses Neutron ML2 drivers to plug baremetal servers to Neutron networks (it looks like changing vlan on the port to segmentation_id from Neutron network, scenario 1 in the attachment). Ironic works with VLAN segmentation only for now, but some vendors ML2 like arista allows to use VXLAN (in this case VXLAN to VLAN mapping is created on the switch.). Different users may have baremetal servers connected to the same ToR switch.</div><div><br></div><div>By trying to apply current neutron trunking model leads to the following errors:</div><div><br></div><div><b>Scenario 2: single user scenario, create VMs with trunk and non-trunk ports.</b></div><div><ul><li>User create two networks:<br>net-1: (provider:segmentation_id: 100)<br>net-2: (provider:segmentation_id: 101)<br><br></li><li>User create 1 trunk port<br>port0 - parent port in net-1<br>port1 - subport in net-2 and define user segmentation_id: 300<br><br></li><li>User boot VMs:<br>BM1: with trunk (connected to ToR Fa0/1)<br>BM4: in net-2 (connected to ToR Fa0/4)<br><br></li><li>VLAN on the switch are configured as follow:<br>Fa0/1 - trunk, native 100, allowed vlan 300<br>Fa0/4 - access vlan 101</li></ul><div><b>Problem:</b> BM1 has no access BM4 on net-2</div></div><div><br></div><div><br></div><div><div><b>Scenario 3: multiple user scenario, create VMs with trunk.</b></div><div><ul><li>User1 create two networks:<br>net-1: (provider:segmentation_id: 100)<br>net-2: (provider:segmentation_id: 101)<br><br></li><li>User2 create two networks:<br>net-3: (provider:segmentation_id: 200)<br>net-4: (provider:segmentation_id: 201)<br><br></li><li>User1 create 1 trunk port<br>port0 - parent port in net-1<br>port1 - subport in net-2 and define user segmentation_id: 300<br><br></li><li>User2 create 1 trunk port<br>port0 - parent port in net-3<br>port1 - subport in net-4 and define user segmentation_id: 300<br><br></li><li>User1 boot VM:<br>BM1: with trunk (connected to ToR Fa0/1)<br><br></li><li>User2 boot VM:<br>BM4: with trunk (connected to ToR Fa0/4)<br><br></li><li>VLAN on the switch are configured as follow:<br>Fa0/1 - trunk, native 100, allowed vlan 300<br>Fa0/4 - trunk, native 200, allowed vlan 300</li></ul><div><b>Problem:</b> User1 BM1 has access to User2 BM4 on net-2, Conflict in VLAN mapping provider vlan 101 should be mapped to user vlan 300, and provider vlan 201 should be also mapped to vlan 300</div></div></div><div><br></div><div><br></div><div>Making segmentation_id on trunk subport optional and inheriting it from port network segmentation_id solves such problems.</div><div>According to original spec both segmentation_type and segmentation_id are optional [0].</div><div><br></div><div>Does Neutron/Nova place information about user's VLAN onto instance via network metadata?</div><div><br></div><div>Reference:</div><div>[0] <a href="https://review.openstack.org/#/c/308521/1/specs/newton/vlan-aware-vms.rst@118" target="_blank">https://review.openstack.o<wbr>rg/#/c/308521/1/specs/newton/v<wbr>lan-aware-vms.rst@118</a></div></div></blockquote><div><br></div></div></div><div>Ah, I was actually going to add the following:</div><div><br></div><div>Whether segmentation type and segmentation ID are mandatory or not depends on the driver in charge of the trunk. This is because for use cases like Ironic, as you wonder, these details may be inferred by the underlying network, as you point out.</div><div><br></div><div>However, we have not tackled the Ironic use case just yet, for the main reason that ironic spec [1] is still WIP. So as far as newton is concerned, Ironic is not on the list of supported use cases for vlan-aware-vms, yet [2]. The reason why we have not tackled it yet is that there's the 'nuisance' in that a specific driver is known to the trunk plugin only at the time a parent port is bound and we hadn't come up with a clean and elegant way to developer a validator that took into account of it. I'll file a bug report to make sure this won't fall through the cracks. It'll be tagged with 'trunk'.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/277853/" target="_blank">https://review.openstack.o<wbr>rg/#/c/277853/</a></div><div>[2] <a href="https://github.com/openstack/neutron/blob/master/neutron/services/trunk/rules.py#L215" target="_blank">https://github.com/opensta<wbr>ck/neutron/blob/master/neutron<wbr>/services/trunk/rules.py#L215</a></div><div><br></div><div>Cheers,</div><div>Armando</div><div><div class="m_-5705913576746559854h5"><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="ltr"><span class="m_-5705913576746559854m_-8252273091685435205gmail-"><div><br></div><div>Thanks in advance,</div><div>Vasyl Saienko</div></span></div><div class="m_-5705913576746559854m_-8252273091685435205gmail-HOEnZb"><div class="m_-5705913576746559854m_-8252273091685435205gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 6, 2016 at 7:08 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.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="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 6 December 2016 at 08:49, Vasyl Saienko <span dir="ltr"><<a href="mailto:vsaienko@mirantis.com" target="_blank">vsaienko@mirantis.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="ltr">Hello Neutron Community,<div><br></div><div><br></div><div>I've found that nice feature vlan-aware-vms was implemented in Newton [0].</div><div>However the usage of this feature for regular users is impossible, unless I'm missing something.</div><div><br></div><div>As I understood correctly it should work in the following way:</div><div><ol><li>It is possible to group neutron ports to trunks.<br></li><li>When trunk is created parent port should be defined:<br>Only one port can be parent. <br>segmentation of parent port is set as native or untagged vlan on the trunk.</li><li>Other ports may be added as subports to existing trunk.<br>When subport is added to trunk <b><i>segmentation_type</i></b> and <i style="font-weight:bold">segmentation_id </i>should be specified.<br>segmentation_id of subport is set as allowed vlan on the trunk</li></ol><div>Non-admin user do not know anything about <b><i>segmentation_type</i></b> and <b><i>segmentation_id.</i></b> </div></div></div></blockquote><div><br></div></span><div>Segmentation type and ID are used to multiplex/demultiplex traffic in/out of the guest associated to a particular trunk. Aside the fact that the only supported type is VLAN at the moment (if ever), the IDs are user provided to uniquely identify the traffic coming in/out of the trunked networks so that it can reach the appropriate vlan interface within the guest. The documentation [1] is still in flight, but it clarifies this point.</div><div><br></div><div>HTH</div><div>Armando </div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/361776" target="_blank">https://review.openstack.org/#<wbr>/c/361776</a> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir="ltr"><div><div>So it is strange that those fields are mandatory when subport is added to trunk. Furthermore they may conflict with port's network segmentation_id and type. Why we can't inherit segmentation_type and segmentation_id from network settings of subport?<br></div></div><div><br></div><div>References:<br></div><div>[0] <a href="https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms" target="_blank">https://blueprints.launchp<wbr>ad.net/neutron/+spec/vlan-awar<wbr>e-vms</a></div><div>[1] <a href="https://review.openstack.org/#/c/361776/15/doc/networking-guide/source/config-trunking.rst" target="_blank">https://review.openstack.org/#<wbr>/c/361776/15/doc/networking-gu<wbr>ide/source/config-trunking.rst</a></div><div>[2] <a href="https://etherpad.openstack.org/p/trunk-api-dump-newton" target="_blank">https://etherpad.openstack<wbr>.org/p/trunk-api-dump-newton</a></div><div><br></div><div>Thanks in advance,</div><div>Vasyl Saienko</div></div>
<br></span><span>______________________________<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></span></blockquote></div><br></div></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></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></div></div><br></div></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></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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>