<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br><br>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.<br>

<br>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.<br><br></div>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.<br><br>On 17 December 2013 06:17, Isaku Yamahata <span dir="ltr"><<a href="mailto:isaku.yamahata@gmail.com" target="_blank">isaku.yamahata@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- 2 Modeling proposal<br>
  What's the purpose of trunk network?<br>
  Can you please add a use case that trunk network can't be optimized away?<br></blockquote><div><br></div><div>Even before I read the document I could list three use cases.  Eric's covered some of them himself.<br>

<br></div><div></div><div>The reasons you might want to have a trunked network passing VLAN traffic:<br></div><div>1: You're replicating a physical design for simulation purposes [2] <br><br>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.<br>

</div><div><br></div><div>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.<br>

</div><div><br></div>-- <br><div>Ian.<br><br>[1] <a href="https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs">https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs</a><br>

</div><div>[2] <a href="http://blogs.cisco.com/wp-content/uploads/network1-550x334.png">http://blogs.cisco.com/wp-content/uploads/network1-550x334.png</a> - a 
network simulator (search for 'Cisco VIRL'). Shameless plug, sorry, but 
it's an Openstack based application and I'm rather proud of it.<br></div></div></div></div>