Hi Ian. I can't see your proposal. Can you please make it public viewable? Some comments inlined below.
On Wed, Dec 18, 2013 at 01:20:50PM +0100, Ian Wells <ijw.ubu...@cack.org.uk> 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.yamah...@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. I'm not against trunking. I'm trying to understand what requirements need "trunk network" in the figure 1 in addition to "L2 gateway" directly connected to VM via "trunk port". thanks, > 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@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