Open Stack

RE: vlan trunking support for network tunnels
Copying to dev mailing list.
	- Greg

-----Original Message-----
From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com] 
Sent: Thursday, October 03, 2013 6:33 AM
To: Bob Melander (bmelande)
Cc: Regnier, Greg J
Subject: Re: Service VM discussion - mgmt ifs

On Oct 3, 2013, at 1:56 AM, Bob Melander (bmelande) <bmelande at cisco.com> wrote:
> 
> The N1kv plugin only uses VXLAN but for that tunneling method the VLAN trunking is supported. The way it works is that each VXLAN is mapped to a *link local* VLAN. That technique is pretty much amenable to any tunneling method.
> 
> There is a blueprint for trunking support in Neutron written by Kyle (https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api). I think that it would be very useful for the service VM framework if at least the ML2 and OVS plugins would implement the above blueprint. 
> 
I think this blueprint would be worth shooting for in Icehouse. I can flesh it out a bit more so there is more to see on it and we can target it for Icehouse if you guys think this makes sense. I think not only would it help the service VM approach being taken here, but for running "OpenStack on OpenStack" deployments, having a trunk port to the VM makes a lot of sense and enables more networking options for that type of testing.

Thanks,
Kyle

> We actually have an implementation also for the OVS plugin that supports its tunneling methods. But we have not yet attempted to upstream it.
> 
> Thanks,
> Bob
> 
> Ps. Thanks for inserting the email comments into the document. If we can extend it further in the coming weeks to get a full(er) picture then during summit we can identify/discuss suitable pieces to implement in phases during Iceberg timeframe. 
> 
> 
> 3 okt 2013 kl. 01:13 skrev "Regnier, Greg J" <greg.j.regnier at intel.com>:
> 
>> Hi Bob,
>>  
>> Does the VLAN trunking solution work with tenant networks that use (VxLAN, NVGRE) tunnels?
>>  
>> Thanks,
>>                 Greg
>>  
>> From: Bob Melander (bmelande) [mailto:bmelande at cisco.com]
>> Sent: Wednesday, September 25, 2013 2:57 PM
>> To: Regnier, Greg J; Sumit Naiksatam; Rudrajit Tapadar (rtapadar); 
>> David Chang (dwchang); Joseph Swaminathan; Elzur, Uri; Marc Benoit; 
>> Sridar Kandaswamy (skandasw); Dan Florea (dflorea); Kanzhe Jiang; 
>> Kuang-Ching Wang; Gary Duan; Yi Sun; Rajesh Mohan; Maciocco, 
>> Christian; Kyle Mestery (kmestery)
>> Subject: Re: Service VM discussion - mgmt ifs ... The service VM 
>> framework scheduler should preferably also allow selection of VIFs to 
>> host a logical resource's logical interfaces. To clarify the last statement, one "use case"
>> could be to spin up a VM with more VIFs than are needed initially 
>> (e.g., if the VM does not support vif hot-plugging). Another "use 
>> case" is if the plugin supports VLAN trunking and attachement of the 
>> logical resource's logical interface to a network corresponds to trunking of a network on a VIF.
>>  
>> There are at least three (or four) ways to dynamically plug a logical 
>> service resource inside a VM to networks:
>> - Create a VM VIF on demand for the logical interface of the service 
>> resource
>> ("hot-plugging")
>> - Pre-populate the VM with a set of VIFs that can be allocated to 
>> logical interfaces of the service resources
>> - Create a set of VM VIFs (on demand or during VM creation) that 
>> carry VLAN trunks for which logical (VLAN) interfaces are created and allocated to service resources.
>>