> On Oct 22, 2015, at 9:28 AM, Ben Pfaff <b...@nicira.com> wrote: > > + The first axis is the <dfn>connection point</dfn>. Physical networks can > + be <em>connected at hypervisors</em>. To access a physical network in > this > + fashion, a VM must run on a hypervisor that is directly connected to that > + network, that is, its hypervisor must be on the physical network's > subnet. > + Alternatively, physical networks can be <em>centrally connected</em>, > with > + packets passing through a tunnel to a central point. This model does not > + require hypervisors to have a direct connection to the physical network, > + but it does require setting up and maintaining a central gateway.
I worry a bit that our use of "physical networks" is a bit muddy. In particular, the physical networks described here versus a VTEP bridging physical workloads. > + The second axis is the <dfn>degree of NAT</dfn> (network address > + translation). The lowest level of NAT is <em>no NAT</em>, in which VMs > are > + directly assigned physical network IP addresses. The next level is > <em>IP > + address translation</em>, which translates IP addresses. This allows This is probably a losing terminology battle, but I think this is really called NAT... > + physical and logical IP addresses to be separately allocated. Finally, > + <em>(full) NAT</em> translates IP addresses and transport port numbers. > + Only full NAT allows multiple VMs to share a public IP address. ...and this is called PAT. I think it may be useful to use both sets of terms. Or not. Maybe I'm just old. > + OVN doesn't add any value to this kind of physical network > + connectivity, because plugging the VM's interface directly into a > + physical network bridge works just as well. OVN provides this option > + for use by CMSes (e.g. OpenStack Neutron) that require all of the > + network connectivity on a hypervisor to go through a single > networking > + provider (i.e. OVN). As Russel mentioned, this seems a little overly negative. > + OVN will implement direct support for this case. For now, one can > + implement it with an <code>localnet</code> port that patches to an s/an/a/ --Justin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
