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

Reply via email to