[resending to the ovs-dev as I sent my original reply to Russell only] Comments inline
Salvatore On 24 June 2015 at 16:15, Russell Bryant <rbry...@redhat.com> wrote: > 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? > While the API allows you to map a provider network to a specific VxLAN VNI or GRE tunnel key, I have never seen this in practice. Also, I have no idea of what concrete use case might require this scenario. But it won't be the first time someone would come up with some science-fi use case that is a key requirement for their deployment! Nevertheless, I don't think that an implementation of provider networks must support all transport types. Flat and Vlan only is fine for me. API requests for different transport types should be rejected. I believe that the provider networks code already has hooks to allow the plugin to declare which transport types are allowed. > > > 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. > That's how neutron is supposed to work. > > > > 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. > Absolutely > > > > 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? > > > That is correct. Indeed neutron operates under the *wrong* assumption that it controls IP addressing on provider networks, which is not true and this might lead to issues such as duplicated IPs, unless appropriate slicing of IP CIDRs is performed. > (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. > I think the best answer to this point is that having a provider network backed by something which is not a physical network or a vlan is a purely theoretical use case. The API allows you to do so, but there's no practical use for that. Unless someone chimes in this thread and proves me wrong. > > -- > Russell Bryant > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
