Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
I feel that we are getting quite far away from supporting my use case. Use case: VM wants to connect to different 'normal' Neutron networks from one VNIC. VLANs are proposed in blueprint since it's a common way to separate 'networks'. It is just a way to connect to different Neutron networks, it does not put requirements on method used for tenant separation in Neutron. Ability to specify VID from user is there since, for this use case, the service would be used by normal tenants, and preferable not exposing Neutron internals (that might not use VLANS at all for tenant separation). Also several VMs could specify the same VID for connecting to different Neutron networks, this to avoid dependencies between tenants. We would like to have this functionality close to the VNIC, not requiring a extra 'hop' in the network both for latency, throughput performance and fault management. The strange optimizations are there because of this. Also, for this use case, the APIs from a user perspective could be cleaner. Maybe we should break out this use case from the L2-gateway? /Erik On Mon, Dec 23, 2013 at 10:09 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: I think we have two different cases here - one where a 'trunk' network passes all VLANs, which is potentially supportable by anything that's not based on VLANs for separation, and one where a trunk can't feasibly do that but where we could make it pass a restricted set of VLANs by mapping. In the former case, obviously we need no special awareness of the nature of the network to implement an L2 gateway. In the latter case, we're looking at a specialisation of networks, one where you would first create them with a set of VLANs you wanted to pass (and - presumably - the driver would say 'ah, I must allocate multiple VLANs to this network rather than just one'. You've jumped in with two optimisations on top of that: - we can precalculate the VLANs the network needs to pass in some cases, because it's the sum of VLANs that L2 gateways on that network know about - we can use L2 gateways to make the mapping from 'tenant' VLANs to 'overlay' VLANs They're good ideas but they add some limitations to what you can do with trunk networks that aren't actually necessary in a number of solutions. I wonder if we should try the general case first with e.g. a Linuxbridge/GRE based infrastructure, and then add the optimisations afterwards. If I were going to do that optimisation I'd start with the capability mechanism and add the ability to let the tenant specify the specific VLAN tags which must be passed (as you normally would on a physical switch). I'd then have two port types - a user-facing one that ensures the entry and exit mapping is made on the port, and an administrative one which exposes that mapping internally and lets the client code (e.g. the L2 gateway) do the mapping itself. But I think it would be complicated, and maybe even has more complexity than is immediately apparent (e.g. we're effectively allocating a cluster-wide network to get backbone segmentation IDs for each VLAN we pass, which is new and different) hence my thought that we should start with the easy case first just to have something working, and see how the tenant API feels. We could do this with a basic bit of gateway code running on a system using Linuxbridge + GRE, I think - the key seems to be avoiding VLANs in the overlay and then the problem is drastically simplified. -- Ian. On 21 December 2013 23:00, Erik Moe emoe...@gmail.com wrote: Hi Ian, I think your VLAN trunking capability proposal can be a good thing, so the user can request a Neutron network that can trunk VLANs without caring about detailed information regarding which VLANs to pass. This could be used for use cases there user wants to pass VLANs between endpoints on a L2 network etc. For the use case there a VM wants to connect to several normal Neutron networks using VLANs, I would prefer a solution that did not require a Neutron trunk network. Possibly by connecting a L2-gateway directly to the Neutron 'vNic' port, or some other solution. IMHO it would be good to map VLAN to Neutron network as soon as possible. Thanks, Erik On Thu, Dec 19, 2013 at 2:15 PM, Ian Wells ijw.ubu...@cack.org.ukwrote: On 19 December 2013 06:35, Isaku Yamahata isaku.yamah...@gmail.comwrote: Hi Ian. I can't see your proposal. Can you please make it public viewable? Crap, sorry - fixed. 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. No problem, just putting the information there for you. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
Hi Ian, I think your VLAN trunking capability proposal can be a good thing, so the user can request a Neutron network that can trunk VLANs without caring about detailed information regarding which VLANs to pass. This could be used for use cases there user wants to pass VLANs between endpoints on a L2 network etc. For the use case there a VM wants to connect to several normal Neutron networks using VLANs, I would prefer a solution that did not require a Neutron trunk network. Possibly by connecting a L2-gateway directly to the Neutron 'vNic' port, or some other solution. IMHO it would be good to map VLAN to Neutron network as soon as possible. Thanks, Erik On Thu, Dec 19, 2013 at 2:15 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 19 December 2013 06:35, Isaku Yamahata isaku.yamah...@gmail.comwrote: Hi Ian. I can't see your proposal. Can you please make it public viewable? Crap, sorry - fixed. 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. No problem, just putting the information there for you. -- Ian. ___ 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
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
On 19 December 2013 06:35, Isaku Yamahata isaku.yamah...@gmail.com wrote: Hi Ian. I can't see your proposal. Can you please make it public viewable? Crap, sorry - fixed. 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. No problem, just putting the information there for you. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
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
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
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
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
On Dec 16, 2013, at 11:17 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote: Added openstack-dev On Mon, Dec 16, 2013 at 11:34:05PM +0100, Erik Moe emoe...@gmail.com wrote: Hi, I have added a new document to the launchpad. Document should now be more in line with what we discussed at the Icehouse summit. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms Doc: https://docs.google.com/document/d/1lDJ31-XqkjjWC-IBq-_wV1KVhi7DzPkKYlCxTIPs_9U/edit?usp=sharing You are very welcome to give feedback if this is the solution you had in mind. The document is view-only. So I commented below. - 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? IMHO, the trunk network is one which carries VLAN tagged traffic. However, I'm wondering if this is explicitly needed or not as well. Thanks, Kyle - 4 IP address management nitpick Can you please clarify what the L2 gateway ports in section 2 modeling proposal, figure 1? - Table 3 Will this be same to l2-gateway one? https://blueprints.launchpad.net/neutron/+spec/l2-gateway - Figure 5 What's the purpose of br-int local VID? VID can be directly converted from br-eth1 VID to VM VID untagged. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
Hi, thanks for your comments. see answers below. Thanks, Erik On Tue, Dec 17, 2013 at 6:17 AM, Isaku Yamahata isaku.yamah...@gmail.comwrote: Added openstack-dev The document is view-only. So I commented below. - 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? In some use cases the trunk network will trunk all VLANS from a VM, so they can for example be 'tunneled' to another VM or externally. In the use case where a VM wants to connect to multiple Neutron networks, the trunk network is a logical connection between the VM trunk port and the L2-gateways. From my point of view it looks a little strange for this use case, but I think this is what we said during our meeting in Hong Kong (Unless I misunderstood something...). I added use case where two VMs are connected through a trunk network. This can not be optimized away. The network would have to be able to trunk all VLANs between the VMs. - 4 IP address management nitpick Can you please clarify what the L2 gateway ports in section 2 modeling proposal, figure 1? I have now tried to clarify this more. - Table 3 Will this be same to l2-gateway one? https://blueprints.launchpad.net/neutron/+spec/l2-gateway I will try to align to this and maybe other proposals as much as possible. Just wanted to have some feedback before I do too many assumptions. - Figure 5 What's the purpose of br-int local VID? VID can be directly converted from br-eth1 VID to VM VID untagged. Unless something has changed, all vNICs handled by OVS-agent are connected to br-int. br-int has a local VID for separating traffic. br-int is connected to one or more other bridges representing one or more physical networks. The br-int VID is mapped to a per bridge VID, so two separate Neutron networks could have the same VID on two different physical networks. -- 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
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
On 12/17/13, 6:36 AM, Erik Moe wrote: Hi, thanks for your comments. see answers below. Thanks, Erik On Tue, Dec 17, 2013 at 6:17 AM, Isaku Yamahata isaku.yamah...@gmail.com mailto:isaku.yamah...@gmail.com wrote: Added openstack-dev The document is view-only. So I commented below. - 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? In some use cases the trunk network will trunk all VLANS from a VM, so they can for example be 'tunneled' to another VM or externally. In the use case where a VM wants to connect to multiple Neutron networks, the trunk network is a logical connection between the VM trunk port and the L2-gateways. From my point of view it looks a little strange for this use case, but I think this is what we said during our meeting in Hong Kong (Unless I misunderstood something...). I added use case where two VMs are connected through a trunk network. This can not be optimized away. The network would have to be able to trunk all VLANs between the VMs. I see the case where admin user wants to have more than one L2 gateways to talk to the same VM trunk port. Also, these L2 gateways may connected to the untagged networks that belongs different tenants. The trunk network should belong to a single tenant though. Yi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
Added openstack-dev On Mon, Dec 16, 2013 at 11:34:05PM +0100, Erik Moe emoe...@gmail.com wrote: Hi, I have added a new document to the launchpad. Document should now be more in line with what we discussed at the Icehouse summit. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms Doc: https://docs.google.com/document/d/1lDJ31-XqkjjWC-IBq-_wV1KVhi7DzPkKYlCxTIPs_9U/edit?usp=sharing You are very welcome to give feedback if this is the solution you had in mind. The document is view-only. So I commented below. - 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? - 4 IP address management nitpick Can you please clarify what the L2 gateway ports in section 2 modeling proposal, figure 1? - Table 3 Will this be same to l2-gateway one? https://blueprints.launchpad.net/neutron/+spec/l2-gateway - Figure 5 What's the purpose of br-int local VID? VID can be directly converted from br-eth1 VID to VM VID untagged. -- 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
