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.yamah...@gmail.com
<mailto: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.
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
