On Mon, Mar 28, 2016 at 1:07 PM, Russell Bryant <russ...@ovn.org> wrote:
> > > On Mon, Mar 21, 2016 at 11:47 AM, Darrell Ball <dlu...@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 <db...@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. > Thanks; I agree its better to drop localnet w.r.t. physical endpts support > > 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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
