Open Stack

Ian,
Could you unlock your doc at 
https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs?
It require a permission to read.
Thanks
Yi

On 12/18/13, 4:20 AM, Ian Wells wrote:
> A Neutron network is analagous to a wire between ports.  We can do 
> almost everything with this wire - we can pass  both IP and non-IP 
> traffic, I can even pass MPLS traffic over it (yes, I tried).  For no 
> rational reason, at least if you live north of the API, I sometimes 
> can't pass VLAN traffic over it.  You would think this would be in the 
> specification for what a network is, but as it happens I don't think 
> we have a specification for what a network is in those terms.
>
> I have a counterproposal that I wrote up yesterday [1]. This is the 
> absurdly simple approach, taking the position that implementing trunks 
> *should* be easy.  That's actually not such a bad position to take, 
> because the problem lies with certain plugins (OVS-based setups, 
> basically) - it's not a problem with Neutron.
>
> It's very uncompromising, though - it just allows you to request a 
> VLAN-clean network.  It would work with OVS code because it allows 
> plugins to decline a request, but it doesn't solve the VLAN problem 
> for you, it just ensures that you don't run somewhere where your 
> application doesn't work, and gives plugins with problems an 
> opportunity for special case code.  You could expand it so that you're 
> requesting either a VLAN-safe network or a network that passes 
> *specified* VLANs - which is the starting position of Eric's document, 
> a plugin-specific solution to a plugin-specific problem.
>
> I accept that, for as long as we use VLAN based infrastructure, we 
> have to accommodate the fact that VLANs are a special case, but this 
> is very much an artifact of the plugin implementation - Linux bridge 
> based network infrastructure simply doesn't have this problem, for 
> instance.
>
> On 17 December 2013 06:17, Isaku Yamahata <isaku.yamahata at gmail.com 
> <mailto:isaku.yamahata at gmail.com>> wrote:
>
>     - 2 Modeling proposal
>       What's the purpose of trunk network?
>       Can you please add a use case that trunk network can't be
>     optimized away?
>
>
> Even before I read the document I could list three use cases.  Eric's 
> covered some of them himself.
>
> The reasons you might want to have a trunked network passing VLAN traffic:
> 1: You're replicating a physical design for simulation purposes [2]
>
> 2: There are any number of reasons to use VLANs in a physical design, 
> but generally it's a port reduction thing.  In Openstack, clearly I 
> can do this a different way - instead of using 30 VLANs over one 
> network with two ports, I can use 30 networks with two ports each.  
> Ports are cheaper when you're virtual, but they're not free - KVM has 
> a limitation of, from memory, 254 ports per VM. So I might well still 
> want to use VLANs.  I could arbitrarily switch to another encap 
> technology, but this is the tail wagging the dog - I have to change my 
> design because Neutron's contract is inconsistent.
>
> 3: I want to condense many tenant networks into a single VM or 
> physical box because I'm using a single VM to offer logically 
> separated services to multiple tenants. This has all the points of (2) 
> basically, that VLANs are not the only encap I could use, but they're 
> the conventional one and widely supported.  Provider networks do 
> actually offer the functionality you need for this already - if you're 
> talking physical - but they would, I think, be awkward to use in 
> practice, and they would eat NIC ports on your hosts.
>
> -- 
> Ian.
>
> [1] 
> https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs
> [2] http://blogs.cisco.com/wp-content/uploads/network1-550x334.png - a 
> network simulator (search for 'Cisco VIRL'). Shameless plug, sorry, 
> but it's an Openstack based application and I'm rather proud of it.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/f0232a0b/attachment.html>