[ovs-dev] [PATCH] [Patch V2] OVN: Logical-Physical Separation and L2 SW Gateways

Russell Bryant russell at ovn.org
Mon Mar 28 20:07:20 UTC 2016


On Mon, Mar 21, 2016 at 11:47 AM, Darrell Ball <dlu998 at gmail.com> wrote:

> The following patch series implements physical-logical separation
> to be used presently by gateways and localnet.
> The patch series also includes L2 SW Gateway support which depends on the
> physical-logical separation changes.
>
> The physical logical separation changes allow the physical network to be
> managed more easily by a dedicated CMS or CMS function and also allow
> the northbound schema to remain purely logical.
> Another benefit to allow more easily for additional encapsulations to be
> used when interacting with physical provider networks.
>
> The gateway changes in this patch series are for SW gateways only, as
> HW gateways will be updated later.
>
> Physical endpoints are defined here as endpoints at the border of a
> physical network.
> This presently applies to localnet and gateways.
>
> For localnet physical endpoints, chassis name and chassis port can be
> supplied as
> dummy arguments or omitted. This is useful if the same localnet logical
> port is
> distributed across multiple chassis. If chassis and port are omitted, the
> same
> encapsulation on all HVs of a given localnet is implied and a single
> logical port
> should be used. Then the physical endpoint is bound to the localnet
> logical port.
> If multiple encapsulations are needed, multiple physical endpoints would
> be defined
> and bound to separate localnet logical ports.
> If no physical endpt is bound to a localnet, the encap is assumed empty.
> Note that physical location information for localnet ports can also serve
> just
> for administrative purposes as well.
>
> For gateways, a single physical endpoint must be bound to each logical
> port.
> The chassis name must match the chassis system-id. All 6 arguments should
> be supplied for gateway physical endpoints configuration.
>
> The specific changes are:
> ovn-sb.ovsschema: Add physical endpoint table and phys_endpts to logical
> ports
> ovn-sb.xml: Update documentation regarding physical endpoints and their
> binding to logical ports. Also describe possible future encapsulation type
> usages.
> Document the new "gw" logical port type
>
> ovn-sbctl.c: Add configuration for physcial endpoints and binding to
> logical ports.
>
> ovn-sbctl.8.in: Update the ovn-sbctl man page for physical endpoints and
> binding
> to logical ports.
>
> The second part of the patch series supporting SW gateways also uses
> physical
> endpoints.
> The SW gateway runs in the context of ovn-controller as other HVs.
> The gateway node uses a single bridge (call it br-int) that is actively
> controlled by
> OVN. This bridge also houses the tunnels connecting other HVs.
> Additional physical bridges are created for each physical port supported
> by the gateway. These bridges enforce normal action only by default.
> A pair of patch ports are created to connect each LS to br-int.
>
> A new logical port type is added for SW gateways called "gw". This is
> needed
> to differentiate logic from HW gateway support. Changes to HW gateway
> support are coming in a subsequent series.
>
> patch.c: Physical bridge and patch port creation
>
> physical.c: Add SW gateway flow generation support, including physical
> endpoint
> support and update localnet flow generation to use physical endpoints.
> Support gateway br-int patch ports as "physical" ports
>
> binding.c support the use of physical endpoint for gateway (gw) logical
> ports
>
> ovn-nb.xml: document the new "gw" logical port type
>                     remove tag field for localnet under container support
>
> ovn-controller.c; patch.h: Add a chassis name parameter needed for gateways
> Particular logical port types are not presently specified/enforced in the
> NB and SB
> schemas themselves. This may be to allow flexibility and ease of adding
> new types.
>
> Test case updates:
>
> ovn.at: A new test is added to exercise the SW gateway for L2 switching
> and also
>             using physical endpoints.
>             The localnet test case is updated to use physical endpoints.
>
> v1->v2: Fix physical bridge creation logic and update based on RFC patch
> series review
>
> Signed-off-by: Darrell Ball <dball at vmware.com>
>

After talking through this to make sure I understood it and then thinking
about it some more, I have a suggestion.

The highest priority right now is getting toward a gateway solution.  i
think the localnet discussion is a distraction.  How about we just cut that
out completely and leave localnet ports as they are with no changes for
now.  We can change them later, but it may be better to not let that block
other work.

Regarding the use case I've brought up a couple of times, I've proposed
what I think is a simpler solution to my problem for now here:
http://openvswitch.org/pipermail/dev/2016-March/068650.html

-- 
Russell Bryant



More information about the dev mailing list