When/where is the meeting on Monday? -- Kevin Benton
> On Nov 2, 2014, at 11:12 PM, Erik Moe <erik....@ericsson.com> wrote: > > > > From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] > Sent: den 31 oktober 2014 23:35 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints > > > On 31 October 2014 06:29, Erik Moe <erik....@ericsson.com> wrote: > > > I thought Monday network meeting agreed on that “VLAN aware VMs”, Trunk > network + L2GW were different use cases. > > Still I get the feeling that the proposals are put up against each other. > > I think we agreed they were different, or at least the light was beginning to > dawn on the differences, but Maru's point was that if we really want to > decide what specs we have we need to show use cases not just for each spec > independently, but also include use cases where e.g. two specs are required > and the third doesn't help, so as to show that *all* of them are needed. In > fact, I suggest that first we do that - here - and then we meet up one > lunchtime and attack the specs in etherpad before submitting them. In theory > we could have them reviewed and approved by the end of the week. (This > theory may not be very realistic, but it's good to set lofty goals, my > manager tells me.) > > Ok, let’s try. I hope you theory turns out to be realistic. J > > Here are some examples why bridging between Neutron internal networks using > trunk network and L2GW IMO should be avoided. I am still fine with bridging > to external networks. > > Assuming VM with trunk port wants to use floating IP on specific VLAN. Router > has to be created on a Neutron network behind L2GW since Neutron router > cannot handle VLANs. (Maybe not too common use case, but just to show what > kind of issues you can get into) > neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID > The code to check if valid port has to be able to traverse the L2GW. Handing > of IP addresses of VM will most likely be affected since VM port is connected > to several broadcast domains. Alternatively new API can be created. > > Now, this is a very good argument for 'trunk ports', yes. It's not actually > an argument against bridging between networks. I think the bridging case > addresses use cases (generally NFV use cases) where you're not interested in > Openstack managing addresses - often because you're forwarding traffic rather > than being an endpoint, and/or you plan on disabling all firewalling for > speed reasons, but perhaps because you wish to statically configure an > address rather than use DHCP. The point is that, in the absence of a need > for address-aware functions, you don't really care much about ports, and in > fact configuring ports with many addresses may simply be overhead. Also, as > you say, this doesn't address the external bridging use case where what > you're bridging to is not necessarily in Openstack's domain of control. > > I know that many NFVs currently prefer to manage everything themselves. At > the same time, IMO, I think they should be encouraged to become Neutronified. > > In “VLAN aware VMs” trunk port mac address has to be globally unique since it > can be connected to any network, other ports still only has to be unique per > network. But for L2GW all mac addresses has to be globally unique since they > might be bridged together at a later stage. > > I'm not sure that that's particularly a problem - any VM with a port will > have one globally unique MAC address. I wonder if I'm missing the point > here, though. > > Ok, this was probably too specific, sorry. Neutron can reuse MAC addresses > among Neutron networks. But I guess this is configurable. > > Also some implementations might not be able to take VID into account when > doing mac address learning, forcing at least unique macs on a trunk network. > > If an implementation struggles with VLANs then the logical thing to do would > be not to implement them in that driver. Which is fine: I would expect (for > instance) LB-driver networking to work for this and leave OVS-driver > networking to never work for this, because there's little point in fixing it. > > Same as above, this is related to reuse of MAC addresses. > Benefits with “VLAN aware VMs” are integration with existing Neutron services. > Benefits with Trunk networks are less consumption of Neutron networks, less > management per VLAN. > > Actually, the benefit of trunk networks is: > > - if I use an infrastructure where all networks are trunks, I can find out > that a network is a trunk > - if I use an infrastructure where no networks are trunks, I can find out > that a network is not a trunk > - if I use an infrastructure where trunk networks are more expensive, my > operator can price accordingly > > And, again, this is all entirely independent of either VLAN-aware ports or > L2GW blocks. > > Both are true. I was referring of “true” trunk networks, you were referring > to your additions, right? > > Benefits with L2GW is ease to do network stitching. > There are other benefits with the different proposals, the point is that it > might be beneficial to have all solutions. > > I totally agree with this. > > So, use cases that come to mind: > > 1. I want to pass VLAN-encapped traffic from VM A to VM B. I do not know at > network setup time what VLANs I will use. > case A: I'm simulating a network with routers in. The router config is not > under my control, so I don't know addresses or the number of VLANs in use. > (Yes, this use case exists, search for 'Cisco VIRL'.) > case B: NFV scenarios where the VNF orchestrator decides how few or many > VLANs are used, where the endpoints may or may not be addressed, and where > the addresses are selected by the VNF manager. (For instance, every time I > add a customer to a VNF service I create another VLAN on an internal link. > The orchestrator is intelligent and selects the VLAN; telling Openstack the > details is needless overhead.) > - this use case set suggests VLAN trunks, but says nothing about anything > else. > > 2. Service VMs, where I'm attaching one VM to many networks so that I can use > that VM to implement many instances of the same service. Either the VM won't > hotplug VIFs, or it won't hotplug enough VIFs (max # VIFs << max # VLANs). > - this use case set suggests bringing multiple networks into a single port, > which is the trunk port use case > - addressing would likely be Openstack's responsibility, again suggesting > trunk ports > - this use case could equally be solved using an L2GW and a trunk network, > but that would require more API calls and doesn't add much value > > 3. An external service appliance, where I'm attaching one external port to > many networks so that I can use that appliance to implement many instances of > the same service. > - given the external service is probably on a provider network, this > suggests that I want to composite multiple tenant networks to a trunked > (external) network, indicating an L2GW or an external port specific extension > - I would probably like the addresses to be under the control of Openstack > (so that I can take a tenant network address and prevent it from being > re-used, implying that the tenant-side ports can have addresses > > 4. I want to connect multiple VMs to a trunk network, and some VMs to > individual VLANs in the same network > (seems useful with my network engineer hat on, but I'm struggling to think of > a concrete example) > - works best with L2GW; also works with two trunk ports > > 5. An anti-use-case: I want to send Neutron's networking into a death spiral > by making a forwarding loop > - the L2GW allows you to do this (connect trunk port to access port); we > may want to avoid this 'feature' > > Yes, the loop one also came to my mind. J > > Here’s a future use-case: I am an NFV using ports with and without VLANs. Now > I want QoS. > > That's still coming out as 'we probably only require one of trunk ports and > L2GWs, but both is nicer'. Also, I know that we'd like not to make a mistake > here, but we've been talking about this for at least 18 months, so I would > prefer that we try for at least one and ideally both of these solutions and > risk deprecating them later rather than sitting on the fence for another six > months. > > Agree. > Platforms that have issues forking of VLANs at VM port level could get around > with trunk network + L2GW but having more hacks if integration with other > parts of Neutron is needed. > > My inclination is that the L2GW should not try and take advantage of the > encap in a VLAN-based underlay. It makes it more efficient but ties it too > closely with the actual physical implementation of the network. > > Not sure I follow, I’ll re read this tomorrow…. > Platforms that have issues implementing trunk networks could get around using > “VLAN aware VMs” but being forced to separately manage every VLAN as a > Neutron network. On platforms that have both, user can select method > depending on what is needed. > > Thanks, > Erik > > -- > Ian. > > /Erik > > _______________________________________________ > 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
