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

Russell Bryant russell at ovn.org
Mon Mar 21 16:41:40 UTC 2016


On Mon, Mar 21, 2016 at 8: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.
>

I feel like we're overloading the term CMS here.  We're now using it to
describe both the entity responsible for managing the logical network
configuration, as well as the configuration of the physical network.  It
would be nice to clarify this somehow.


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

How about making it strictly as omitted?  Dummy values would look like
broken configuration to me.


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

Can you expand on what you mean by "administrative purposes" here?

On a related topic, I have a need for a localnet port that exists on a
subset of hypervisors.  In this case, I still only want to model it with a
single logical localnet port.

That would work today as long as no VIF ports are created on a chassis that
does not have that network available locally.  We need to improve this on
the OpenStack integration side to make sure that we never try to bind a
port to a chassis where that network is not available.  I was originally
thinking that this work might help solve that problem, but now I'm not sure
that's true.  Using the physical endpoints table would require a logical
port and a physical endpoint for every hypervisor attached to that network,
which could be hundreds.

I think this can all still work, but for this use case, we just need to
store the bridge mappings in the southbound database, as well.  I was
thinking of storing it as an external_id on the Chassis record.

How does that sound?

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

Typo on "physical"


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

The version history should be outside of the commit message.  If you put it
below the "---", it will be in the email but not the commit message.

>
> Signed-off-by: Darrell Ball <dball at vmware.com>
> ---
>  ovn/controller/binding.c        |  15 +-
>  ovn/controller/ovn-controller.c |   2 +-
>  ovn/controller/patch.c          | 135 +++++++++++++++++-
>  ovn/controller/patch.h          |   2 +-
>  ovn/controller/physical.c       |  47 ++++++-
>  ovn/ovn-nb.xml                  |  11 +-
>  ovn/ovn-sb.ovsschema            |  23 +++-
>  ovn/ovn-sb.xml                  |  92 ++++++++++++-
>  ovn/utilities/ovn-sbctl.8.in    |  48 +++++++
>  ovn/utilities/ovn-sbctl.c       | 295
> +++++++++++++++++++++++++++++++++++++++-
>  tests/ovn.at                    | 135 ++++++++++++++++++
>  11 files changed, 774 insertions(+), 31 deletions(-)
>

I'm holding off on reviewing the code in detail because I want to first
make sure I understand how this particular OpenStack use case fits (or
probably does not fit) into this.

-- 
Russell Bryant



More information about the dev mailing list