Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Kevin Benton]

I think we will probably end up having to support the direct pass through
anyway. The reason that landed in the spec is because someone claimed they
had switches that couldn't do translation very well. We will just need
volunteers to make the changes required on the Neutron side.

On Wed, Dec 7, 2016 at 10:19 AM, Vasyl Saienko 
wrote:

>
>
> On Wed, Dec 7, 2016 at 7:34 PM, Kevin Benton  wrote:
>
>> >It work only when whole switch is aimed by single customer, it will not
>> work when several customers sharing the same switch.
>>
>> Do you know what vendors have this limitation? I know the broadcom
>> chipsets didn't prevent this (we allowed VLAN rewrites scoped to ports at
>> Big Switch). If it's common to Cisco/Juniper then I guess we are stuck
>> reflecting bad hardware in the API. :(
>>
>
> @Kevin
> It looks that I was wrong, on the example I provided I expected to
> configure VLAN mapping on Gig0/1 uplink. It will not work in this case, but
> if configure VLAN mapping at ports where baremetal are plugged (i.e: Fa0/1
> - 0/5) it should work :)
> I definitely need more practice with VLAN mapping...
>
>
>
>>
>> On Wed, Dec 7, 2016 at 9:22 AM, Vasyl Saienko 
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton  wrote:
>>>


 On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko 
 wrote:

> @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.
>
> 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.
>
> Current trunks implementation in Neutron will work just fine with
> baremetal case with one small addition:
>
> 1. segmentation_type and segmentation_id should not be API mandatory
> fields at least for the case when provider segmentation is VLAN.
>
> 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.
>
>
> @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.
>
> I don’t see other option than to control uniqueness of segmentation_id
> on Neutron side for baremetal case.
>

 Well unless there is a limitation in the switch hardware, VLAN mapping
 is scoped to each individual port so users can pick the same local
 segmentation_id. The point of the feature on switches is for when you have
 customers that specify their own VLANs and you need to map them to service
 provider VLANs (i.e. what is happening here).

>>>
>>> It work only when whole switch is aimed by single customer, it will not
>>> work when several customers sharing the same switch.
>>>
>>>


>
> Reference:
>
> [0] https://review.openstack.org/#/c/277853/
> [1] https://review.openstack.org/#/c/277853/10/specs/approved/VL
> AN-aware-baremetal-instances.rst@35
>
> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton  wrote:
>
>> 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.
>>
>> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/
>>
>> On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:
>>
>>>
>>>
>>> On 7 December 2016 at 04:02, Vasyl Saienko 
>>> wrote:
>>>
 Armando, Kevin,

 Thanks for your comments.

 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.

>>> 

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Vasyl Saienko]

On Wed, Dec 7, 2016 at 7:34 PM, Kevin Benton  wrote:

> >It work only when whole switch is aimed by single customer, it will not
> work when several customers sharing the same switch.
>
> Do you know what vendors have this limitation? I know the broadcom
> chipsets didn't prevent this (we allowed VLAN rewrites scoped to ports at
> Big Switch). If it's common to Cisco/Juniper then I guess we are stuck
> reflecting bad hardware in the API. :(
>

@Kevin
It looks that I was wrong, on the example I provided I expected to
configure VLAN mapping on Gig0/1 uplink. It will not work in this case, but
if configure VLAN mapping at ports where baremetal are plugged (i.e: Fa0/1
- 0/5) it should work :)
I definitely need more practice with VLAN mapping...



>
> On Wed, Dec 7, 2016 at 9:22 AM, Vasyl Saienko 
> wrote:
>
>>
>>
>> On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton  wrote:
>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko 
>>> wrote:
>>>
 @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.

 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.

 Current trunks implementation in Neutron will work just fine with
 baremetal case with one small addition:

 1. segmentation_type and segmentation_id should not be API mandatory
 fields at least for the case when provider segmentation is VLAN.

 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.


 @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.

 I don’t see other option than to control uniqueness of segmentation_id
 on Neutron side for baremetal case.

>>>
>>> Well unless there is a limitation in the switch hardware, VLAN mapping
>>> is scoped to each individual port so users can pick the same local
>>> segmentation_id. The point of the feature on switches is for when you have
>>> customers that specify their own VLANs and you need to map them to service
>>> provider VLANs (i.e. what is happening here).
>>>
>>
>> It work only when whole switch is aimed by single customer, it will not
>> work when several customers sharing the same switch.
>>
>>
>>>
>>>

 Reference:

 [0] https://review.openstack.org/#/c/277853/
 [1] https://review.openstack.org/#/c/277853/10/specs/approved/VL
 AN-aware-baremetal-instances.rst@35

 On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton  wrote:

> 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.
>
> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/
>
> On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:
>
>>
>>
>> On 7 December 2016 at 04:02, Vasyl Saienko 
>> wrote:
>>
>>> Armando, Kevin,
>>>
>>> Thanks for your comments.
>>>
>>> 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.
>>>
>> 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 
>>> 

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Kevin Benton]

>It work only when whole switch is aimed by single customer, it will not
work when several customers sharing the same switch.

Do you know what vendors have this limitation? I know the broadcom chipsets
didn't prevent this (we allowed VLAN rewrites scoped to ports at Big
Switch). If it's common to Cisco/Juniper then I guess we are stuck
reflecting bad hardware in the API. :(

On Wed, Dec 7, 2016 at 9:22 AM, Vasyl Saienko  wrote:

>
>
> On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton  wrote:
>
>>
>>
>> On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko 
>> wrote:
>>
>>> @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.
>>>
>>> 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.
>>>
>>> Current trunks implementation in Neutron will work just fine with
>>> baremetal case with one small addition:
>>>
>>> 1. segmentation_type and segmentation_id should not be API mandatory
>>> fields at least for the case when provider segmentation is VLAN.
>>>
>>> 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.
>>>
>>>
>>> @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.
>>>
>>> I don’t see other option than to control uniqueness of segmentation_id
>>> on Neutron side for baremetal case.
>>>
>>
>> Well unless there is a limitation in the switch hardware, VLAN mapping is
>> scoped to each individual port so users can pick the same local
>> segmentation_id. The point of the feature on switches is for when you have
>> customers that specify their own VLANs and you need to map them to service
>> provider VLANs (i.e. what is happening here).
>>
>
> It work only when whole switch is aimed by single customer, it will not
> work when several customers sharing the same switch.
>
>
>>
>>
>>>
>>> Reference:
>>>
>>> [0] https://review.openstack.org/#/c/277853/
>>> [1] https://review.openstack.org/#/c/277853/10/specs/approved/VL
>>> AN-aware-baremetal-instances.rst@35
>>>
>>> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton  wrote:
>>>
 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.

 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/

 On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:

>
>
> On 7 December 2016 at 04:02, Vasyl Saienko 
> wrote:
>
>> Armando, Kevin,
>>
>> Thanks for your comments.
>>
>> 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.
>>
> 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.
>>
>> By trying to apply current neutron trunking model leads to the
>> following errors:
>>
>> *Scenario 2: single user scenario, create VMs with trunk and
>> non-trunk ports.*
>>
>>- User create two networks:
>>net-1: (provider:segmentation_id: 100)
>>net-2: (provider:segmentation_id: 101)
>>
>>- User create 1 trunk port
>>port0 - parent port in net-1
>>port1 - subport in net-2 and define user segmentation_id: 300
>>

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Vasyl Saienko]

On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton  wrote:

>
>
> On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko 
> wrote:
>
>> @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.
>>
>> 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.
>>
>> Current trunks implementation in Neutron will work just fine with
>> baremetal case with one small addition:
>>
>> 1. segmentation_type and segmentation_id should not be API mandatory
>> fields at least for the case when provider segmentation is VLAN.
>>
>> 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.
>>
>>
>> @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.
>>
>> I don’t see other option than to control uniqueness of segmentation_id on
>> Neutron side for baremetal case.
>>
>
> Well unless there is a limitation in the switch hardware, VLAN mapping is
> scoped to each individual port so users can pick the same local
> segmentation_id. The point of the feature on switches is for when you have
> customers that specify their own VLANs and you need to map them to service
> provider VLANs (i.e. what is happening here).
>

It work only when whole switch is aimed by single customer, it will not
work when several customers sharing the same switch.


>
>
>>
>> Reference:
>>
>> [0] https://review.openstack.org/#/c/277853/
>> [1] https://review.openstack.org/#/c/277853/10/specs/approved/VL
>> AN-aware-baremetal-instances.rst@35
>>
>> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton  wrote:
>>
>>> 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.
>>>
>>> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/
>>>
>>> On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:
>>>


 On 7 December 2016 at 04:02, Vasyl Saienko 
 wrote:

> Armando, Kevin,
>
> Thanks for your comments.
>
> 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.
>
 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.
>
> By trying to apply current neutron trunking model leads to the
> following errors:
>
> *Scenario 2: single user scenario, create VMs with trunk and non-trunk
> ports.*
>
>- User create two networks:
>net-1: (provider:segmentation_id: 100)
>net-2: (provider:segmentation_id: 101)
>
>- User create 1 trunk port
>port0 - parent port in net-1
>port1 - subport in net-2 and define user segmentation_id: 300
>
>- User boot VMs:
>BM1: with trunk (connected to ToR Fa0/1)
>BM4: in net-2 (connected to ToR Fa0/4)
>
>- VLAN on the switch are configured as follow:
>Fa0/1 - trunk, native 100, allowed vlan 300
>Fa0/4 - access vlan 101
>
> *Problem:* BM1 has no access BM4 on net-2
>
>
> *Scenario 3: multiple user scenario, create VMs with trunk.*
>
>- User1 create two networks:
>net-1: (provider:segmentation_id: 100)
>net-2: (provider:segmentation_id: 101)
>
>- User2 create two 

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Kevin Benton]

On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko  wrote:

> @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.
>
> 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.
>
> Current trunks implementation in Neutron will work just fine with
> baremetal case with one small addition:
>
> 1. segmentation_type and segmentation_id should not be API mandatory
> fields at least for the case when provider segmentation is VLAN.
>
> 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.
>
>
> @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.
>
> I don’t see other option than to control uniqueness of segmentation_id on
> Neutron side for baremetal case.
>

Well unless there is a limitation in the switch hardware, VLAN mapping is
scoped to each individual port so users can pick the same local
segmentation_id. The point of the feature on switches is for when you have
customers that specify their own VLANs and you need to map them to service
provider VLANs (i.e. what is happening here).


>
> Reference:
>
> [0] https://review.openstack.org/#/c/277853/
> [1] https://review.openstack.org/#/c/277853/10/specs/approved/
> VLAN-aware-baremetal-instances.rst@35
>
> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton  wrote:
>
>> 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.
>>
>> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/
>>
>> On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:
>>
>>>
>>>
>>> On 7 December 2016 at 04:02, Vasyl Saienko 
>>> wrote:
>>>
 Armando, Kevin,

 Thanks for your comments.

 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.

>>> 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.

 By trying to apply current neutron trunking model leads to the
 following errors:

 *Scenario 2: single user scenario, create VMs with trunk and non-trunk
 ports.*

- User create two networks:
net-1: (provider:segmentation_id: 100)
net-2: (provider:segmentation_id: 101)

- User create 1 trunk port
port0 - parent port in net-1
port1 - subport in net-2 and define user segmentation_id: 300

- User boot VMs:
BM1: with trunk (connected to ToR Fa0/1)
BM4: in net-2 (connected to ToR Fa0/4)

- VLAN on the switch are configured as follow:
Fa0/1 - trunk, native 100, allowed vlan 300
Fa0/4 - access vlan 101

 *Problem:* BM1 has no access BM4 on net-2


 *Scenario 3: multiple user scenario, create VMs with trunk.*

- User1 create two networks:
net-1: (provider:segmentation_id: 100)
net-2: (provider:segmentation_id: 101)

- User2 create two networks:
net-3: (provider:segmentation_id: 200)
net-4: (provider:segmentation_id: 201)

- User1 create 1 trunk port
port0 - parent port in net-1
port1 - subport in net-2 and define user segmentation_id: 300

- User2 create 1 trunk port
port0 - parent port in net-3

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Vasyl Saienko]

@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.

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.

Current trunks implementation in Neutron will work just fine with baremetal
case with one small addition:

1. segmentation_type and segmentation_id should not be API mandatory fields
at least for the case when provider segmentation is VLAN.

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.


@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.

I don’t see other option than to control uniqueness of segmentation_id on
Neutron side for baremetal case.

Reference:

[0] https://review.openstack.org/#/c/277853/
[1]
https://review.openstack.org/#/c/277853/10/specs/approved/VLAN-aware-baremetal-instances.rst@35

On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton  wrote:

> 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.
>
> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/
>
> On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:
>
>>
>>
>> On 7 December 2016 at 04:02, Vasyl Saienko  wrote:
>>
>>> Armando, Kevin,
>>>
>>> Thanks for your comments.
>>>
>>> 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.
>>>
>> 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.
>>>
>>> By trying to apply current neutron trunking model leads to the following
>>> errors:
>>>
>>> *Scenario 2: single user scenario, create VMs with trunk and non-trunk
>>> ports.*
>>>
>>>- User create two networks:
>>>net-1: (provider:segmentation_id: 100)
>>>net-2: (provider:segmentation_id: 101)
>>>
>>>- User create 1 trunk port
>>>port0 - parent port in net-1
>>>port1 - subport in net-2 and define user segmentation_id: 300
>>>
>>>- User boot VMs:
>>>BM1: with trunk (connected to ToR Fa0/1)
>>>BM4: in net-2 (connected to ToR Fa0/4)
>>>
>>>- VLAN on the switch are configured as follow:
>>>Fa0/1 - trunk, native 100, allowed vlan 300
>>>Fa0/4 - access vlan 101
>>>
>>> *Problem:* BM1 has no access BM4 on net-2
>>>
>>>
>>> *Scenario 3: multiple user scenario, create VMs with trunk.*
>>>
>>>- User1 create two networks:
>>>net-1: (provider:segmentation_id: 100)
>>>net-2: (provider:segmentation_id: 101)
>>>
>>>- User2 create two networks:
>>>net-3: (provider:segmentation_id: 200)
>>>net-4: (provider:segmentation_id: 201)
>>>
>>>- User1 create 1 trunk port
>>>port0 - parent port in net-1
>>>port1 - subport in net-2 and define user segmentation_id: 300
>>>
>>>- User2 create 1 trunk port
>>>port0 - parent port in net-3
>>>port1 - subport in net-4 and define user segmentation_id: 300
>>>
>>>- User1 boot VM:
>>>BM1: with trunk (connected to ToR Fa0/1)
>>>
>>>- User2 boot VM:
>>>BM4: with trunk (connected to ToR Fa0/4)
>>>
>>>- VLAN on the switch are configured as follow:
>>>Fa0/1 - trunk, native 100, allowed vlan 300
>>>Fa0/4 - trunk, native 200, allowed vlan 300
>>>
>>> *Problem:* 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 

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Kevin Benton]

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.

1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/

On Wed, Dec 7, 2016 at 7:49 AM, Armando M.  wrote:

>
>
> On 7 December 2016 at 04:02, Vasyl Saienko  wrote:
>
>> Armando, Kevin,
>>
>> Thanks for your comments.
>>
>> 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.
>>
> 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.
>>
>> By trying to apply current neutron trunking model leads to the following
>> errors:
>>
>> *Scenario 2: single user scenario, create VMs with trunk and non-trunk
>> ports.*
>>
>>- User create two networks:
>>net-1: (provider:segmentation_id: 100)
>>net-2: (provider:segmentation_id: 101)
>>
>>- User create 1 trunk port
>>port0 - parent port in net-1
>>port1 - subport in net-2 and define user segmentation_id: 300
>>
>>- User boot VMs:
>>BM1: with trunk (connected to ToR Fa0/1)
>>BM4: in net-2 (connected to ToR Fa0/4)
>>
>>- VLAN on the switch are configured as follow:
>>Fa0/1 - trunk, native 100, allowed vlan 300
>>Fa0/4 - access vlan 101
>>
>> *Problem:* BM1 has no access BM4 on net-2
>>
>>
>> *Scenario 3: multiple user scenario, create VMs with trunk.*
>>
>>- User1 create two networks:
>>net-1: (provider:segmentation_id: 100)
>>net-2: (provider:segmentation_id: 101)
>>
>>- User2 create two networks:
>>net-3: (provider:segmentation_id: 200)
>>net-4: (provider:segmentation_id: 201)
>>
>>- User1 create 1 trunk port
>>port0 - parent port in net-1
>>port1 - subport in net-2 and define user segmentation_id: 300
>>
>>- User2 create 1 trunk port
>>port0 - parent port in net-3
>>port1 - subport in net-4 and define user segmentation_id: 300
>>
>>- User1 boot VM:
>>BM1: with trunk (connected to ToR Fa0/1)
>>
>>- User2 boot VM:
>>BM4: with trunk (connected to ToR Fa0/4)
>>
>>- VLAN on the switch are configured as follow:
>>Fa0/1 - trunk, native 100, allowed vlan 300
>>Fa0/4 - trunk, native 200, allowed vlan 300
>>
>> *Problem:* 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
>>
>>
>> Making segmentation_id on trunk subport optional and inheriting it from
>> port network segmentation_id solves such problems.
>> According to original spec both segmentation_type and segmentation_id are
>> optional [0].
>>
>> Does Neutron/Nova place information about user's VLAN onto instance via
>> network metadata?
>>
>> Reference:
>> [0] https://review.openstack.org/#/c/308521/1/specs/newton/v
>> lan-aware-vms.rst@118
>>
>
> Ah, I was actually going to add the following:
>
> 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.
>
> 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'.
>
> [1] https://review.openstack.org/#/c/277853/
> [2] https://github.com/openstack/neutron/blob/master/
> neutron/services/trunk/rules.py#L215
>
> Cheers,
> Armando
>
>
>>
>> Thanks in advance,
>> Vasyl Saienko
>>
>> On Tue, Dec 6, 2016 at 7:08 PM, Armando M.  wrote:
>>
>>>
>>>
>>> On 6 December 2016 at 08:49, Vasyl Saienko 
>>> wrote:
>>>
 Hello Neutron Community,


 I've found that nice feature vlan-aware-vms was implemented in Newton
 [0].
 However the usage of 

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Armando M.]

On 7 December 2016 at 04:02, Vasyl Saienko  wrote:

> Armando, Kevin,
>
> Thanks for your comments.
>
> 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.
>
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.
>
> By trying to apply current neutron trunking model leads to the following
> errors:
>
> *Scenario 2: single user scenario, create VMs with trunk and non-trunk
> ports.*
>
>- User create two networks:
>net-1: (provider:segmentation_id: 100)
>net-2: (provider:segmentation_id: 101)
>
>- User create 1 trunk port
>port0 - parent port in net-1
>port1 - subport in net-2 and define user segmentation_id: 300
>
>- User boot VMs:
>BM1: with trunk (connected to ToR Fa0/1)
>BM4: in net-2 (connected to ToR Fa0/4)
>
>- VLAN on the switch are configured as follow:
>Fa0/1 - trunk, native 100, allowed vlan 300
>Fa0/4 - access vlan 101
>
> *Problem:* BM1 has no access BM4 on net-2
>
>
> *Scenario 3: multiple user scenario, create VMs with trunk.*
>
>- User1 create two networks:
>net-1: (provider:segmentation_id: 100)
>net-2: (provider:segmentation_id: 101)
>
>- User2 create two networks:
>net-3: (provider:segmentation_id: 200)
>net-4: (provider:segmentation_id: 201)
>
>- User1 create 1 trunk port
>port0 - parent port in net-1
>port1 - subport in net-2 and define user segmentation_id: 300
>
>- User2 create 1 trunk port
>port0 - parent port in net-3
>port1 - subport in net-4 and define user segmentation_id: 300
>
>- User1 boot VM:
>BM1: with trunk (connected to ToR Fa0/1)
>
>- User2 boot VM:
>BM4: with trunk (connected to ToR Fa0/4)
>
>- VLAN on the switch are configured as follow:
>Fa0/1 - trunk, native 100, allowed vlan 300
>Fa0/4 - trunk, native 200, allowed vlan 300
>
> *Problem:* 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
>
>
> Making segmentation_id on trunk subport optional and inheriting it from
> port network segmentation_id solves such problems.
> According to original spec both segmentation_type and segmentation_id are
> optional [0].
>
> Does Neutron/Nova place information about user's VLAN onto instance via
> network metadata?
>
> Reference:
> [0] https://review.openstack.org/#/c/308521/1/specs/newton/
> vlan-aware-vms.rst@118
>

Ah, I was actually going to add the following:

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.

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'.

[1] https://review.openstack.org/#/c/277853/
[2]
https://github.com/openstack/neutron/blob/master/neutron/services/trunk/rules.py#L215

Cheers,
Armando


>
> Thanks in advance,
> Vasyl Saienko
>
> On Tue, Dec 6, 2016 at 7:08 PM, Armando M.  wrote:
>
>>
>>
>> On 6 December 2016 at 08:49, Vasyl Saienko  wrote:
>>
>>> Hello Neutron Community,
>>>
>>>
>>> I've found that nice feature vlan-aware-vms was implemented in Newton
>>> [0].
>>> However the usage of this feature for regular users is impossible,
>>> unless I'm missing something.
>>>
>>> As I understood correctly it should work in the following way:
>>>
>>>1. It is possible to group neutron ports to trunks.
>>>2. When trunk is created parent port should be defined:
>>>Only one port can be parent.
>>>segmentation of parent port is set as native or untagged vlan on the
>>>trunk.
>>>3. Other ports may be added as subports to existing trunk.
>>>When subport is added to trunk *segmentation_type* and *segmentation_id
>>>*should be specified.
>>>

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Vasyl Saienko]

Armando, Kevin,

Thanks for your comments.

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.
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.

By trying to apply current neutron trunking model leads to the following
errors:

*Scenario 2: single user scenario, create VMs with trunk and non-trunk
ports.*

   - User create two networks:
   net-1: (provider:segmentation_id: 100)
   net-2: (provider:segmentation_id: 101)

   - User create 1 trunk port
   port0 - parent port in net-1
   port1 - subport in net-2 and define user segmentation_id: 300

   - User boot VMs:
   BM1: with trunk (connected to ToR Fa0/1)
   BM4: in net-2 (connected to ToR Fa0/4)

   - VLAN on the switch are configured as follow:
   Fa0/1 - trunk, native 100, allowed vlan 300
   Fa0/4 - access vlan 101

*Problem:* BM1 has no access BM4 on net-2


*Scenario 3: multiple user scenario, create VMs with trunk.*

   - User1 create two networks:
   net-1: (provider:segmentation_id: 100)
   net-2: (provider:segmentation_id: 101)

   - User2 create two networks:
   net-3: (provider:segmentation_id: 200)
   net-4: (provider:segmentation_id: 201)

   - User1 create 1 trunk port
   port0 - parent port in net-1
   port1 - subport in net-2 and define user segmentation_id: 300

   - User2 create 1 trunk port
   port0 - parent port in net-3
   port1 - subport in net-4 and define user segmentation_id: 300

   - User1 boot VM:
   BM1: with trunk (connected to ToR Fa0/1)

   - User2 boot VM:
   BM4: with trunk (connected to ToR Fa0/4)

   - VLAN on the switch are configured as follow:
   Fa0/1 - trunk, native 100, allowed vlan 300
   Fa0/4 - trunk, native 200, allowed vlan 300

*Problem:* 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


Making segmentation_id on trunk subport optional and inheriting it from
port network segmentation_id solves such problems.
According to original spec both segmentation_type and segmentation_id are
optional [0].

Does Neutron/Nova place information about user's VLAN onto instance via
network metadata?

Reference:
[0]
https://review.openstack.org/#/c/308521/1/specs/newton/vlan-aware-vms.rst@118

Thanks in advance,
Vasyl Saienko

On Tue, Dec 6, 2016 at 7:08 PM, Armando M.  wrote:

>
>
> On 6 December 2016 at 08:49, Vasyl Saienko  wrote:
>
>> Hello Neutron Community,
>>
>>
>> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
>> However the usage of this feature for regular users is impossible, unless
>> I'm missing something.
>>
>> As I understood correctly it should work in the following way:
>>
>>1. It is possible to group neutron ports to trunks.
>>2. When trunk is created parent port should be defined:
>>Only one port can be parent.
>>segmentation of parent port is set as native or untagged vlan on the
>>trunk.
>>3. Other ports may be added as subports to existing trunk.
>>When subport is added to trunk *segmentation_type* and *segmentation_id
>>*should be specified.
>>segmentation_id of subport is set as allowed vlan on the trunk
>>
>> Non-admin user do not know anything about *segmentation_type* and
>> *segmentation_id.*
>>
>
> 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.
>
> HTH
> Armando
>
> [1] https://review.openstack.org/#/c/361776
>
>
>> 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?
>>
>> References:
>> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
>> [1] https://review.openstack.org/#/c/361776/15/doc/networking-gu
>> ide/source/config-trunking.rst
>> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>>
>> Thanks in advance,
>> Vasyl Saienko
>>
>> 
>> 

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Armando M.]

On 6 December 2016 at 08:49, Vasyl Saienko  wrote:

> Hello Neutron Community,
>
>
> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
> However the usage of this feature for regular users is impossible, unless
> I'm missing something.
>
> As I understood correctly it should work in the following way:
>
>1. It is possible to group neutron ports to trunks.
>2. When trunk is created parent port should be defined:
>Only one port can be parent.
>segmentation of parent port is set as native or untagged vlan on the
>trunk.
>3. Other ports may be added as subports to existing trunk.
>When subport is added to trunk *segmentation_type* and *segmentation_id
>*should be specified.
>segmentation_id of subport is set as allowed vlan on the trunk
>
> Non-admin user do not know anything about *segmentation_type* and
> *segmentation_id.*
>

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.

HTH
Armando

[1] https://review.openstack.org/#/c/361776


> 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?
>
> References:
> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [1] https://review.openstack.org/#/c/361776/15/doc/networking-gu
> ide/source/config-trunking.rst
> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>
> Thanks in advance,
> Vasyl Saienko
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Kevin Benton]

The segmentation type of the trunk (how the VM attached to the parent port
sees the traffic) has nothing to do with the provider segmentation details
(how the traffic will be encapsulated when it leaves the compute node).

You're right that a normal user won't know the latter details, but they
don't need to. The user specifies how they want traffic from arbitrary
networks encapsulated into their VM. So they can say they want netA on vlan
100, netB on vlan 200, and that's what the VM will see - even if netA is a
GRE network and netB is a vlan network on vlan 3000.

On Dec 6, 2016 08:51, "Vasyl Saienko"  wrote:

> Hello Neutron Community,
>
>
> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
> However the usage of this feature for regular users is impossible, unless
> I'm missing something.
>
> As I understood correctly it should work in the following way:
>
>1. It is possible to group neutron ports to trunks.
>2. When trunk is created parent port should be defined:
>Only one port can be parent.
>segmentation of parent port is set as native or untagged vlan on the
>trunk.
>3. Other ports may be added as subports to existing trunk.
>When subport is added to trunk *segmentation_type* and *segmentation_id
>*should be specified.
>segmentation_id of subport is set as allowed vlan on the trunk
>
> Non-admin user do not know anything about *segmentation_type* and
> *segmentation_id.* 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?
>
> References:
> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [1] https://review.openstack.org/#/c/361776/15/doc/networking-
> guide/source/config-trunking.rst
> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>
> Thanks in advance,
> Vasyl Saienko
>
> __
> 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
>
>
__
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

[openstack-dev] [neutron] Vlan aware VMs or trunking

[Vasyl Saienko]

Hello Neutron Community,


I've found that nice feature vlan-aware-vms was implemented in Newton [0].
However the usage of this feature for regular users is impossible, unless
I'm missing something.

As I understood correctly it should work in the following way:

   1. It is possible to group neutron ports to trunks.
   2. When trunk is created parent port should be defined:
   Only one port can be parent.
   segmentation of parent port is set as native or untagged vlan on the
   trunk.
   3. Other ports may be added as subports to existing trunk.
   When subport is added to trunk *segmentation_type* and
*segmentation_id *should
   be specified.
   segmentation_id of subport is set as allowed vlan on the trunk

Non-admin user do not know anything about *segmentation_type* and
*segmentation_id.* 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?

References:
[0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[1]
https://review.openstack.org/#/c/361776/15/doc/networking-guide/source/config-trunking.rst
[2] https://etherpad.openstack.org/p/trunk-api-dump-newton

Thanks in advance,
Vasyl Saienko
__
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

Re: [openstack-dev] [neutron] VLAN aware VMs: Current status?

[Ildikó Váncsa]

Hi Kyle,

First of all, sorry for the late response.

We are working on the design and implementation, the first patches are planned 
to be up by the end of this week.

We could surely use more hands as it is quite a large amount of work that this 
blueprint requires. If there are any Neutron experts who would and could help 
out we would appreciate it. We prepared a wiki page [1], which contains 
information about the plans and design, it also includes a link to tasks/work 
items. If anyone is willing to join to the implementation please ping me via 
mail or IRC (ildikov) so we can sync up regarding to the work items.

Thanks and Best Regards,
Ildikó

[1] https://wiki.openstack.org/wiki/Neutron/TrunkPort 

 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: July 30, 2015 16:26
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [neutron] VLAN aware VMs: Current status?
 
 I'm sending this email to solicit a response from the owners of the VLAN 
 aware VMs spec [1] [2]. The spec was merged on June 24,
 and I haven't seen any code posted. Given I expect this to take some 
 iterations in review, is the plan to push code for this sometime
 soon?
 
 
 Thanks!
 
 Kyle
 
 
 [1] https://review.openstack.org/#/c/94612/
 [2] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

__
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

[openstack-dev] [neutron] VLAN aware VMs: Current status?

[Kyle Mestery]

I'm sending this email to solicit a response from the owners of the VLAN
aware VMs spec [1] [2]. The spec was merged on June 24, and I haven't seen
any code posted. Given I expect this to take some iterations in review, is
the plan to push code for this sometime soon?

Thanks!
Kyle

[1] https://review.openstack.org/#/c/94612/
[2] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
__
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

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

[Ildikó Váncsa]

Hi Kyle,

 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: June 15, 2015 04:26
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
 
 On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa ildiko.van...@ericsson.com
 wrote:
 
 
   Hi,
 
 
 
   Since we reopened the review for this blueprint we’ve got a
 large number of comments. It can be clearly seen that the original proposal
 has to be changed, although it still requires some discussion to define a
 reasonable design that provides the desired feature and is aligned with the
 architecture and guidelines of Neutron. In order to speed up the process to
 fit into the Liberty timeframe, we would like to have a discussion about this.
 The goal is to discuss the alternatives we have, decide which to go on with
 and sort out the possible issues. After this discussion the blueprint will be
 updated with the desired solution.
 
 
 
   I would like to propose a time slot for _next Tuesday (06. 16.),
 17:00UTC – 18:00UTC_. I would like to have the discussion on the
 #openstack-neutron channel, that gives a chance to guys who might be
 interested, but missed this mail to attend. I tried to check the slot, but 
 please
 let me know if it collides with any Neutron related meeting.
 
 
 
 
 This looks to be fine. I would suggest that it may make more sense to have it
 in an #openstack-meeting channel, though we can certainly do a free-form
 chat in #openstack-neutron as well. I think the desired end-goal here should
 be to figure out any remaining nits that are being discussed on the spec so
 we can move forward in Liberty.
 

I wasn’t sure that it is a good idea to bring an unscheduled meeting to the 
meeting channels. Is it acceptable to hold an ad-hoc meeting there or does it 
have to be registered somewhere even if it's one occasion? As much as I saw the 
#openstack-meeting-4 channel is available although the list of meetings and the 
.ical file is not in sync, it's not taken in either. Should we try it there?

I agree with the desired outcome, so that we can start the implementation as 
soon as possible. I will try to send out an agenda before the meeting with the 
points that we should discuss.

Thanks and Best Regards,
Ildikó

 
 Thanks,
 
 Kyle
 
 
 
 
 
 
   Thanks and Best Regards,
 
   Ildikó
 
 
   ___
 ___
   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
 
 
 

__
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

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

[Kyle Mestery]

On Mon, Jun 15, 2015 at 7:40 AM, Ildikó Váncsa ildiko.van...@ericsson.com
wrote:

 Hi Kyle,

  -Original Message-
  From: Kyle Mestery [mailto:mest...@mestery.com]
  Sent: June 15, 2015 04:26
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
 
  On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa 
 ildiko.van...@ericsson.com
  wrote:
 
 
Hi,
 
 
 
Since we reopened the review for this blueprint we’ve got a
  large number of comments. It can be clearly seen that the original
 proposal
  has to be changed, although it still requires some discussion to define a
  reasonable design that provides the desired feature and is aligned with
 the
  architecture and guidelines of Neutron. In order to speed up the process
 to
  fit into the Liberty timeframe, we would like to have a discussion about
 this.
  The goal is to discuss the alternatives we have, decide which to go on
 with
  and sort out the possible issues. After this discussion the blueprint
 will be
  updated with the desired solution.
 
 
 
I would like to propose a time slot for _next Tuesday (06. 16.),
  17:00UTC – 18:00UTC_. I would like to have the discussion on the
  #openstack-neutron channel, that gives a chance to guys who might be
  interested, but missed this mail to attend. I tried to check the slot,
 but please
  let me know if it collides with any Neutron related meeting.
 
 
 
 
  This looks to be fine. I would suggest that it may make more sense to
 have it
  in an #openstack-meeting channel, though we can certainly do a free-form
  chat in #openstack-neutron as well. I think the desired end-goal here
 should
  be to figure out any remaining nits that are being discussed on the spec
 so
  we can move forward in Liberty.
 

 I wasn’t sure that it is a good idea to bring an unscheduled meeting to
 the meeting channels. Is it acceptable to hold an ad-hoc meeting there or
 does it have to be registered somewhere even if it's one occasion? As much
 as I saw the #openstack-meeting-4 channel is available although the list of
 meetings and the .ical file is not in sync, it's not taken in either.
 Should we try it there?


I think as long as there isn't a scheduled meeting in place, we can use the
channel for a one-off meeting. It has the added benefit of being logged in
the same way as other meetings, and we can focus the discussion.

I agree with the desired outcome, so that we can start the implementation
 as soon as possible. I will try to send out an agenda before the meeting
 with the points that we should discuss.


Perfect! I've added a note to the Neutron meeting for tomorrow [1] to
highlight this. If you get the agenda written, please add a pointer in the
Neutron meeting agenda in the same place.

[1]
https://wiki.openstack.org/wiki/Network/Meetings#Announcements_.2F_Reminders


 Thanks and Best Regards,
 Ildikó

 
  Thanks,
 
  Kyle
 
 
 
 
 
 
Thanks and Best Regards,
 
Ildikó
 
 
___
  ___
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
 
 
 

 __
 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

__
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

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

[Ildikó Váncsa]

Hi Kyle,

Thanks for your support. Let's go for the meeting channel option then, so the 
final details for the tomorrow's meeting are:

Time: Tuesday (06. 16.), 17:00UTC - 18:00UTC
Location: #openstack-meeting-4

I will add a pointer to the agenda, when we have it!

Best Regards,
Ildikó

 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: June 15, 2015 15:52
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
 
 On Mon, Jun 15, 2015 at 7:40 AM, Ildikó Váncsa ildiko.van...@ericsson.com 
 wrote:
 
 
   Hi Kyle,
 
 
-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: June 15, 2015 04:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
   
On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa 
 ildiko.van...@ericsson.com
wrote:
   
   
  Hi,
   
   
   
  Since we reopened the review for this blueprint we’ve got a
large number of comments. It can be clearly seen that the original 
 proposal
has to be changed, although it still requires some discussion to 
 define a
reasonable design that provides the desired feature and is aligned 
 with the
architecture and guidelines of Neutron. In order to speed up the 
 process to
fit into the Liberty timeframe, we would like to have a discussion 
 about this.
The goal is to discuss the alternatives we have, decide which to go 
 on with
and sort out the possible issues. After this discussion the blueprint 
 will be
updated with the desired solution.
   
   
   
  I would like to propose a time slot for _next Tuesday (06. 16.),
17:00UTC – 18:00UTC_. I would like to have the discussion on the
#openstack-neutron channel, that gives a chance to guys who might be
interested, but missed this mail to attend. I tried to check the 
 slot, but please
let me know if it collides with any Neutron related meeting.
   
   
   
   
This looks to be fine. I would suggest that it may make more sense to 
 have it
in an #openstack-meeting channel, though we can certainly do a 
 free-form
chat in #openstack-neutron as well. I think the desired end-goal here 
 should
be to figure out any remaining nits that are being discussed on the 
 spec so
we can move forward in Liberty.
   
 
 
   I wasn’t sure that it is a good idea to bring an unscheduled meeting to 
 the meeting channels. Is it acceptable to hold an
 ad-hoc meeting there or does it have to be registered somewhere even if it's 
 one occasion? As much as I saw the #openstack-
 meeting-4 channel is available although the list of meetings and the .ical 
 file is not in sync, it's not taken in either. Should we try it
 there?
 
 
 
 
 I think as long as there isn't a scheduled meeting in place, we can use the 
 channel for a one-off meeting. It has the added benefit of
 being logged in the same way as other meetings, and we can focus the 
 discussion.
 
 
 
   I agree with the desired outcome, so that we can start the 
 implementation as soon as possible. I will try to send out an
 agenda before the meeting with the points that we should discuss.
 
 
 
 
 Perfect! I've added a note to the Neutron meeting for tomorrow [1] to 
 highlight this. If you get the agenda written, please add a
 pointer in the Neutron meeting agenda in the same place.
 
 [1] 
 https://wiki.openstack.org/wiki/Network/Meetings#Announcements_.2F_Reminders
 
 
 
   Thanks and Best Regards,
   Ildikó
 
   
Thanks,
   
Kyle
   
   
   
   
   
   
  Thanks and Best Regards,
   
  Ildikó
   
   
  ___
___
  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
   
   
   
 
   
 __
   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
 
 

__
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

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

[Kyle Mestery]

On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa ildiko.van...@ericsson.com
wrote:

  Hi,



 Since we reopened the review for this blueprint we’ve got a large number
 of comments. It can be clearly seen that the original proposal has to be
 changed, although it still requires some discussion to define a reasonable
 design that provides the desired feature and is aligned with the
 architecture and guidelines of Neutron. In order to speed up the process to
 fit into the Liberty timeframe, we would like to have a discussion about
 this. The goal is to discuss the alternatives we have, decide which to go
 on with and sort out the possible issues. After this discussion the
 blueprint will be updated with the desired solution.



 I would like to propose a time slot for _*next Tuesday (06. 16.),
 17:00UTC – 18:00UTC*_. I would like to have the discussion on the
 #openstack-neutron channel, that gives a chance to guys who might be
 interested, but missed this mail to attend. I tried to check the slot, but
 please let me know if it collides with any Neutron related meeting.




This looks to be fine. I would suggest that it may make more sense to have
it in an #openstack-meeting channel, though we can certainly do a free-form
chat in #openstack-neutron as well. I think the desired end-goal here
should be to figure out any remaining nits that are being discussed on the
spec so we can move forward in Liberty.

Thanks,
Kyle


  Thanks and Best Regards,

 Ildikó

 __
 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


__
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

[openstack-dev] [Neutron] VLAN-aware VMs meeting

[Ildikó Váncsa]

Hi,

Since we reopened the review for this blueprint we've got a large number of 
comments. It can be clearly seen that the original proposal has to be changed, 
although it still requires some discussion to define a reasonable design that 
provides the desired feature and is aligned with the architecture and 
guidelines of Neutron. In order to speed up the process to fit into the Liberty 
timeframe, we would like to have a discussion about this. The goal is to 
discuss the alternatives we have, decide which to go on with and sort out the 
possible issues. After this discussion the blueprint will be updated with the 
desired solution.

I would like to propose a time slot for _next Tuesday (06. 16.), 17:00UTC - 
18:00UTC_. I would like to have the discussion on the #openstack-neutron 
channel, that gives a chance to guys who might be interested, but missed this 
mail to attend. I tried to check the slot, but please let me know if it 
collides with any Neutron related meeting.

Thanks and Best Regards,
Ildikó
__
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

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Yi Sun]

Guys,
I just checked the schedule of unconference sessions. There are no free
slots anymore.

Yi

On Tuesday, October 29, 2013, Isaku Yamahata wrote:

 Hi Erik and Li.
 Unconference at the next summit?

 On Mon, Oct 28, 2013 at 02:34:28PM -0700,
 beyounn beyo...@gmail.com javascript:; wrote:

  Hi Erik,
 
  While we were discussing about the service VM framework, the trunk port
  support was also mentioned.  I think people do see the needs for it.
 
  I have seen someone have mentioned another BP
 
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin
  your BP already. Maybe it is same as what you are doing.
 
  And the trunk port use case can also impact how the zone being
 constructed
  in the fwaas context (when a firewall VM uses a trunk port to connect
  multiple networks). The basic question is how we should present a trunk
 port
  and the vlan on a trunk port to Neutron.
 
 
 
  Yi
 
 
 
  From: Erik Moe [mailto:emoe...@gmail.com javascript:;]
  Sent: Monday, October 28, 2013 1:56 PM
  To: openstack-dev@lists.openstack.org javascript:;
  Subject: [openstack-dev] [Neutron] VLAN aware VMs
 
 
 
  Hi!
 
  We are looking into how to make it possible for tenant VMs to use VLAN
  tagged traffic to connect to different Neutron networks.
 
 
 
  The VID on frames sent/received will determine which Neutron network the
  frames are connected to.
 
 
  https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
  I would like to find others that also see the need for this kind of
  functionality and would like to discuss this.
 
  Regards,
  Erik
 

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org javascript:;
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 --
 Isaku Yamahata isaku.yamah...@gmail.com javascript:;

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org javascript:;
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Android-x86
http://www.android-x86.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Kyle Mestery (kmestery)]

How about if we do a developers lounge chat at 2PM Thursday?

On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com
 wrote:

 Guys,
 I just checked the schedule of unconference sessions. There are no free slots 
 anymore.
 
 Yi
 
 On Tuesday, October 29, 2013, Isaku Yamahata wrote:
 Hi Erik and Li.
 Unconference at the next summit?
 
 On Mon, Oct 28, 2013 at 02:34:28PM -0700,
 beyounn beyo...@gmail.com wrote:
 
  Hi Erik,
 
  While we were discussing about the service VM framework, the trunk port
  support was also mentioned.  I think people do see the needs for it.
 
  I have seen someone have mentioned another BP
  https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in
  your BP already. Maybe it is same as what you are doing.
 
  And the trunk port use case can also impact how the zone being constructed
  in the fwaas context (when a firewall VM uses a trunk port to connect
  multiple networks). The basic question is how we should present a trunk port
  and the vlan on a trunk port to Neutron.
 
 
 
  Yi
 
 
 
  From: Erik Moe [mailto:emoe...@gmail.com]
  Sent: Monday, October 28, 2013 1:56 PM
  To: openstack-dev@lists.openstack.org
  Subject: [openstack-dev] [Neutron] VLAN aware VMs
 
 
 
  Hi!
 
  We are looking into how to make it possible for tenant VMs to use VLAN
  tagged traffic to connect to different Neutron networks.
 
 
 
  The VID on frames sent/received will determine which Neutron network the
  frames are connected to.
 
 
  https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
  I would like to find others that also see the need for this kind of
  functionality and would like to discuss this.
 
  Regards,
  Erik
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 --
 Isaku Yamahata isaku.yamah...@gmail.com
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 -- 
 Android-x86
 http://www.android-x86.org
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Erik Moe]

Ok, 2PM Thursday is fine with me.



On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery)
kmest...@cisco.comwrote:

 How about if we do a developers lounge chat at 2PM Thursday?

 On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com
  wrote:

  Guys,
  I just checked the schedule of unconference sessions. There are no free
 slots anymore.
 
  Yi
 
  On Tuesday, October 29, 2013, Isaku Yamahata wrote:
  Hi Erik and Li.
  Unconference at the next summit?
 
  On Mon, Oct 28, 2013 at 02:34:28PM -0700,
  beyounn beyo...@gmail.com wrote:
 
   Hi Erik,
  
   While we were discussing about the service VM framework, the trunk port
   support was also mentioned.  I think people do see the needs for it.
  
   I have seen someone have mentioned another BP
  
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin
   your BP already. Maybe it is same as what you are doing.
  
   And the trunk port use case can also impact how the zone being
 constructed
   in the fwaas context (when a firewall VM uses a trunk port to connect
   multiple networks). The basic question is how we should present a
 trunk port
   and the vlan on a trunk port to Neutron.
  
  
  
   Yi
  
  
  
   From: Erik Moe [mailto:emoe...@gmail.com]
   Sent: Monday, October 28, 2013 1:56 PM
   To: openstack-dev@lists.openstack.org
   Subject: [openstack-dev] [Neutron] VLAN aware VMs
  
  
  
   Hi!
  
   We are looking into how to make it possible for tenant VMs to use VLAN
   tagged traffic to connect to different Neutron networks.
  
  
  
   The VID on frames sent/received will determine which Neutron network
 the
   frames are connected to.
  
  
   https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
  
   I would like to find others that also see the need for this kind of
   functionality and would like to discuss this.
  
   Regards,
   Erik
  
 
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  --
  Isaku Yamahata isaku.yamah...@gmail.com
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  --
  Android-x86
  http://www.android-x86.org
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Yi Sun]

Yap, 2pm is good
Yi

On Tuesday, November 5, 2013, Erik Moe wrote:

 Ok, 2PM Thursday is fine with me.



 On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery) 
 kmest...@cisco.com wrote:

 How about if we do a developers lounge chat at 2PM Thursday?

 On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com
  wrote:

  Guys,
  I just checked the schedule of unconference sessions. There are no free
 slots anymore.
 
  Yi
 
  On Tuesday, October 29, 2013, Isaku Yamahata wrote:
  Hi Erik and Li.
  Unconference at the next summit?
 
  On Mon, Oct 28, 2013 at 02:34:28PM -0700,
  beyounn beyo...@gmail.com wrote:
 
   Hi Erik,
  
   While we were discussing about the service VM framework, the trunk port
   support was also mentioned.  I think people do see the needs for it.
  
   I have seen someone have mentioned another BP
  
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin
   your BP already. Maybe it is same as what you are doing.
  
   And the trunk port use case can also impact how the zone being
 constructed
   in the fwaas context (when a firewall VM uses a trunk port to connect
   multiple networks). The basic question is how we should present a
 trunk port
   and the vlan on a trunk port to Neutron.
  
  
  
   Yi
  
  
  
   From: Erik Moe [mailto:emoe...@gmail.com]
   Sent: Monday, October 28, 2013 1:56 PM
   To: openstack-dev@lists.openstack.org
   Subject: [openstack-dev] [Neutron] VLAN aware VMs
  
  
  
   Hi!
  
   We are looking into how to make it possible for tenant VMs to use VLAN
   tagged traffic to connect to different Neutron networks.
  
  
  
   The VID on frames sent/received will determine which Neutron network
 the
   frames are connected to.
  
  
   https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
  
   I would like to find others that also see the need for this kind of
   functionality and would like to discuss this.
  
   Regards,
   Erik
  
 
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  --
  Isaku Yamahata isaku.yamah...@gmail.com
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  --
  Android-x86
  http://www.android-x86.org
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenSta



-- 
Android-x86
http://www.android-x86.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Isaku Yamahata]

I'm fine with 14:00 on Thursday.

On Tue, Nov 05, 2013 at 07:59:55AM +0100,
Erik Moe emoe...@gmail.com wrote:

 Ok, 2PM Thursday is fine with me.
 
 
 
 On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery)
 kmest...@cisco.comwrote:
 
  How about if we do a developers lounge chat at 2PM Thursday?
 
  On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com
   wrote:
 
   Guys,
   I just checked the schedule of unconference sessions. There are no free
  slots anymore.
  
   Yi
  
   On Tuesday, October 29, 2013, Isaku Yamahata wrote:
   Hi Erik and Li.
   Unconference at the next summit?
  
   On Mon, Oct 28, 2013 at 02:34:28PM -0700,
   beyounn beyo...@gmail.com wrote:
  
Hi Erik,
   
While we were discussing about the service VM framework, the trunk port
support was also mentioned.  I think people do see the needs for it.
   
I have seen someone have mentioned another BP
   
  https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin
your BP already. Maybe it is same as what you are doing.
   
And the trunk port use case can also impact how the zone being
  constructed
in the fwaas context (when a firewall VM uses a trunk port to connect
multiple networks). The basic question is how we should present a
  trunk port
and the vlan on a trunk port to Neutron.
   
   
   
Yi
   
   
   
From: Erik Moe [mailto:emoe...@gmail.com]
Sent: Monday, October 28, 2013 1:56 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN aware VMs
   
   
   
Hi!
   
We are looking into how to make it possible for tenant VMs to use VLAN
tagged traffic to connect to different Neutron networks.
   
   
   
The VID on frames sent/received will determine which Neutron network
  the
frames are connected to.
   
   
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
   
I would like to find others that also see the need for this kind of
functionality and would like to discuss this.
   
Regards,
Erik
   
  
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
   --
   Isaku Yamahata isaku.yamah...@gmail.com
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
   --
   Android-x86
   http://www.android-x86.org
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-- 
Isaku Yamahata isaku.yamah...@gmail.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] VLAN aware VMs

[Erik Moe]

Hi!

We are looking into how to make it possible for tenant VMs to use VLAN
tagged traffic to connect to different Neutron networks.

The VID on frames sent/received will determine which Neutron network the
frames are connected to.

https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

I would like to find others that also see the need for this kind of
functionality and would like to discuss this.

Regards,
Erik
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[beyounn]

Hi Erik,

While we were discussing about the service VM framework, the trunk port
support was also mentioned.  I think people do see the needs for it. 

I have seen someone have mentioned another BP
https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in
your BP already. Maybe it is same as what you are doing.

And the trunk port use case can also impact how the zone being constructed
in the fwaas context (when a firewall VM uses a trunk port to connect
multiple networks). The basic question is how we should present a trunk port
and the vlan on a trunk port to Neutron.

 

Yi

 

From: Erik Moe [mailto:emoe...@gmail.com] 
Sent: Monday, October 28, 2013 1:56 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN aware VMs

 

Hi!

We are looking into how to make it possible for tenant VMs to use VLAN
tagged traffic to connect to different Neutron networks.

 

The VID on frames sent/received will determine which Neutron network the
frames are connected to.


https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

I would like to find others that also see the need for this kind of
functionality and would like to discuss this.

Regards,
Erik

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Kyle Mestery (kmestery)]

I think the trunk port BP referenced below (and registered by myself) would 
likely solve this use case. There is no design summit session to discuss this, 
but I hope to have an unconference slot in Hong Kong to discuss this with folks 
who are interested.

Thanks,
Kyle

On Oct 28, 2013, at 4:34 PM, beyounn beyo...@gmail.com wrote:

 Hi Erik,
 While we were discussing about the service VM framework, the trunk port 
 support was also mentioned.  I think people do see the needs for it.
 I have seen someone have mentioned another BP 
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in 
 your BP already. Maybe it is same as what you are doing.
 And the trunk port use case can also impact how the zone being constructed in 
 the fwaas context (when a firewall VM uses a trunk port to connect multiple 
 networks). The basic question is how we should present a trunk port and the 
 vlan on a trunk port to Neutron.
  
 Yi
  
 From: Erik Moe [mailto:emoe...@gmail.com] 
 Sent: Monday, October 28, 2013 1:56 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron] VLAN aware VMs
  
 Hi!
 
 We are looking into how to make it possible for tenant VMs to use VLAN tagged 
 traffic to connect to different Neutron networks.
  
 The VID on frames sent/received will determine which Neutron network the 
 frames are connected to.
 
 https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
 I would like to find others that also see the need for this kind of 
 functionality and would like to discuss this.
 
 Regards,
 Erik
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Isaku Yamahata]

Hi Erik and Li.
Unconference at the next summit?

On Mon, Oct 28, 2013 at 02:34:28PM -0700,
beyounn beyo...@gmail.com wrote:

 Hi Erik,
 
 While we were discussing about the service VM framework, the trunk port
 support was also mentioned.  I think people do see the needs for it. 
 
 I have seen someone have mentioned another BP
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in
 your BP already. Maybe it is same as what you are doing.
 
 And the trunk port use case can also impact how the zone being constructed
 in the fwaas context (when a firewall VM uses a trunk port to connect
 multiple networks). The basic question is how we should present a trunk port
 and the vlan on a trunk port to Neutron.
 
  
 
 Yi
 
  
 
 From: Erik Moe [mailto:emoe...@gmail.com] 
 Sent: Monday, October 28, 2013 1:56 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron] VLAN aware VMs
 
  
 
 Hi!
 
 We are looking into how to make it possible for tenant VMs to use VLAN
 tagged traffic to connect to different Neutron networks.
 
  
 
 The VID on frames sent/received will determine which Neutron network the
 frames are connected to.
 
 
 https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
 I would like to find others that also see the need for this kind of
 functionality and would like to discuss this.
 
 Regards,
 Erik
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Isaku Yamahata isaku.yamah...@gmail.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Erik Moe]

Hi Yamahata,

yes, unconference sounds good.

I agree that quantum-network-bundle-api is in the same area. I missed this
blueprint.

/Erik


On Mon, Oct 28, 2013 at 11:10 PM, Isaku Yamahata
isaku.yamah...@gmail.comwrote:

 Hi Erik and Li.
 Unconference at the next summit?

 On Mon, Oct 28, 2013 at 02:34:28PM -0700,
 beyounn beyo...@gmail.com wrote:

  Hi Erik,
 
  While we were discussing about the service VM framework, the trunk port
  support was also mentioned.  I think people do see the needs for it.
 
  I have seen someone have mentioned another BP
 
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin
  your BP already. Maybe it is same as what you are doing.
 
  And the trunk port use case can also impact how the zone being
 constructed
  in the fwaas context (when a firewall VM uses a trunk port to connect
  multiple networks). The basic question is how we should present a trunk
 port
  and the vlan on a trunk port to Neutron.
 
 
 
  Yi
 
 
 
  From: Erik Moe [mailto:emoe...@gmail.com]
  Sent: Monday, October 28, 2013 1:56 PM
  To: openstack-dev@lists.openstack.org
  Subject: [openstack-dev] [Neutron] VLAN aware VMs
 
 
 
  Hi!
 
  We are looking into how to make it possible for tenant VMs to use VLAN
  tagged traffic to connect to different Neutron networks.
 
 
 
  The VID on frames sent/received will determine which Neutron network the
  frames are connected to.
 
 
  https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
  I would like to find others that also see the need for this kind of
  functionality and would like to discuss this.
 
  Regards,
  Erik
 

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 --
 Isaku Yamahata isaku.yamah...@gmail.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VLAN aware VMs

[Yi Sun]

Yes, if we can do that it will be perfect. How should we arrange this? I
will arrive at the morning of 5th.
Yi

On Monday, October 28, 2013, Erik Moe wrote:


 Hi Yamahata,

 yes, unconference sounds good.

 I agree that quantum-network-bundle-api is in the same area. I missed this
 blueprint.

 /Erik


 On Mon, Oct 28, 2013 at 11:10 PM, Isaku Yamahata 
 isaku.yamah...@gmail.comjavascript:_e({}, 'cvml', 
 'isaku.yamah...@gmail.com');
  wrote:

 Hi Erik and Li.
 Unconference at the next summit?

 On Mon, Oct 28, 2013 at 02:34:28PM -0700,
 beyounn beyo...@gmail.com javascript:_e({}, 'cvml',
 'beyo...@gmail.com'); wrote:

  Hi Erik,
 
  While we were discussing about the service VM framework, the trunk port
  support was also mentioned.  I think people do see the needs for it.
 
  I have seen someone have mentioned another BP
 
 https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin
  your BP already. Maybe it is same as what you are doing.
 
  And the trunk port use case can also impact how the zone being
 constructed
  in the fwaas context (when a firewall VM uses a trunk port to connect
  multiple networks). The basic question is how we should present a trunk
 port
  and the vlan on a trunk port to Neutron.
 
 
 
  Yi
 
 
 
  From: Erik Moe [mailto:emoe...@gmail.com javascript:_e({}, 'cvml',
 'emoe...@gmail.com');]
  Sent: Monday, October 28, 2013 1:56 PM
  To: openstack-dev@lists.openstack.org javascript:_e({}, 'cvml',
 'openstack-dev@lists.openstack.org');
  Subject: [openstack-dev] [Neutron] VLAN aware VMs
 
 
 
  Hi!
 
  We are looking into how to make it possible for tenant VMs to use VLAN
  tagged traffic to connect to different Neutron networks.
 
 
 
  The VID on frames sent/received will determine which Neutron network the
  frames are connected to.
 
 
  https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
  I would like to find others that also see the need for this kind of
  functionality and would like to discuss this.
 
  Regards,
  Erik
 

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org javascript:_e({}, 'cvml',
 'OpenStack-dev@lists.openstack.org');
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 --
 Isaku Yamahata isaku.yamah...@gmail.com javascript:_e({}, 'cvml',
 'isaku.yamah...@gmail.com');

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org javascript:_e({}, 'cvml',
 'OpenStack-dev@lists.openstack.org');
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Android-x86
http://www.android-x86.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev