[openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs

Isaku Yamahata isaku.yamahata at gmail.com
Thu Dec 19 05:35:22 UTC 2013


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

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Isaku Yamahata <isaku.yamahata at gmail.com>



More information about the OpenStack-dev mailing list