On 06/23/2015 06:56 PM, Ben Pfaff wrote: > On Tue, Jun 23, 2015 at 11:58:25PM +0200, Salvatore Orlando wrote: >> I'm afraid I have to start bike shedding on this thread too. >> Apparently that's what I do best. > > These are important clarifications, not bikeshedding. > > More below (with lots of trimming and reflowing for clarity): > >> On 06/23/2015 05:10 PM, Ben Pfaff wrote: >>> A "tenant network" is what OVN calls a logical network. OVN can >>> construct it as an L2-over-L3 overlay with STT or Geneve or >>> whatever. Tenant networks can be connected to physical networks via >>> OVN gateways. >>> >>> A "provider network" is just a physical L2 network (possibly >>> VLAN-tagged). In such a network, on the sending side, OVN would >>> rely on normal L2 switching for packets to reach their destinations, >>> and on the receiving side, OVN would not have a reliable way to >>> determine the source of a packet (it would have to infer it from the >>> source MAC). Is that accurate? >> >> While this is correct, it is also restrictive - as that would imply that a >> "provider network" is just a physical L2 segment on the data centre. >> Therefore logical ports on a provider networks would be pretty much pass >> through to the physical network. While it is correct that they might be >> mapped to OVS ports on a bridge doings plain L2 forwarding onto a physical >> network, this does not mean that L2 forwarding is the only thing that one >> can do on provider networks. >> >> A provider network is, from the neutron perspective, exactly like any other >> logical network, including tenant networks. What changes are bindings (or >> mappings, I don't know what's the correct OVN terminology). These bindings >> define three aspects: >> 1 - the transport type (VLAN, GRE, STT, VxLAN, etc) >> 2 - the physical network, if any >> 3 - the segmentation id on the physical network, if any, >> >> For tenant networks, bindings are implicit and depend on what the control >> plan defaults to. As Ben was suggesting this could STT or Geneve. >> For provider networks, these bindings are explicit, as the admin defines >> them. For instance I want this network to be mapped to VLAN 666 on physical >> network MEH. >> >> In practical terms with provider networks the control plane must honour the >> specification made in the neutron request concerning transport bindings for >> the logical networks. If it can't honour these mapping - for instance if it >> does not support the select transport type - it must return an error. >> Nevertheless the control plane still treats provider networks like any >> other network. You can have services like DHCP on them (even if often is >> not a great idea), apply security groups to its ports, uplink them to >> logical routers, and so on.
This is great clarification. Thanks, Salvatore. I've been looking at this very focused on some specific use cases (using the provider networks extensions to specify 'flat' or 'vlan' transport type on a specific physical network) as that is what I have seen come up regularly. Do people actually use this to specify other transport types? Do you know of any good references on uses? For example, I'm not sure what is expected if you only set the transport type to VxLAN or whatever. Is it just "use VxLAN, but exactly how is left up to the backend" ? Or is it more well defined than that? > OK, let me take another stab at a recap, then. > > For a tenant network, it is outside the scope of Neutron to dictate or > configure how packets are transported among VMs. Instead, that is > delegated to the plugin itself or to whatever the plugin configures > (e.g. in this case, to OVN). > > For a provider network, the administrator (via Neutron) configures use > of a specific transport in a specific way. A Neutron plugin must > operate over that configured transport in that way, or if cannot then it > must refuse to operate at all. > > OK, if that all that is correct, does the following logical extension > also hold? A provider network implementation is expected to > transparently interoperate with preexisting software that shares a given > transport. For example, if I set up a provider network with Neutron on > a particular Ethernet network, and I have a bunch of physical machines > attached to the same Ethernet network, then I would expect my Neutron > VMs attached to the physical network to be able to communicate back and > forth with those physical machines. > > If that is the case, then I guess one description of the two different > types of network is this: a Neutron plugin may *define* a tenant > network, but a Neutron plugin only *participates* in a provider network. > Is that fair? > > (I apologize if all this should be obvious to Neutron veterans. I'm new > to this!) Based on this thread, and some conversations I've seen between other Neutron devs, this is definitely *not* obvious. The recap you have here sounds right to me, though. However, as discussed above, what's expected from the Neutron backend for a transport type other than 'vlan' or 'flat' with a physical network specified isn't clear to me. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
