I created an etherpad and added use cases (so far just the ones in your email).



From: Erik Moe [mailto:erik....@ericsson.com]
Sent: den 2 november 2014 23:12
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

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<mailto: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. ☺
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, 
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 
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 

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. ☺
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 

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.




OpenStack-dev mailing list

Reply via email to