Re: [ovs-dev] [PATCH] [Patch V2] OVN: Logical-Physical Separation and L2 SW Gateways
On Mon, Mar 28, 2016 at 1:07 PM, Russell Bryant wrote: > > > On Mon, Mar 21, 2016 at 11:47 AM, Darrell Ball 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 >> > > 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
Re: [ovs-dev] [PATCH 1/2] [Patch V3] OVN: Physical Endpoints
>
> please see responses inline
>
> -- Forwarded message --
> From: Russell Bryant
> Date: Tue, Mar 29, 2016 at 11:18 AM
> Subject: Re: [ovs-dev] [PATCH 1/2] [Patch V3] OVN: Physical Endpoints
> To: Darrell Ball
> Cc: ovs dev
>
>
>
>
> On Tue, Mar 29, 2016 at 12:56 AM, Darrell Ball wrote:
>
>> The following patch series implements physical-logical separation
>> to be used presently by gateways.
>>
>> The physical endpoint changes allow the physical network to be
>> managed more easily by a dedicated provider network management 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.
>>
>> Physical endpoints are defined here as endpoints at the border of a
>> physical network.
>> This presently applies to gateways.
>> If no physical endpt, the encap is assumed empty.
>> 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 must
>> be supplied for gateway physical endpoints configuration.
>> Support is provided to bind multiple physical endpoints to a logical port
>> for
>> future considerations.
>>
>> Physical Endpoint Patch:
>>
>> 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.
>>
>> 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.
>>
>> Signed-off-by: Darrell Ball
>> ---
>> ovn/ovn-sb.ovsschema | 23 +++-
>> ovn/ovn-sb.xml | 75 +++
>> ovn/utilities/ovn-sbctl.8.in | 47 +++
>> ovn/utilities/ovn-sbctl.c| 290
>> ++-
>> 4 files changed, 429 insertions(+), 6 deletions(-)
>>
>> diff --git a/ovn/ovn-sb.ovsschema b/ovn/ovn-sb.ovsschema
>> index 32f8748..14ecb99 100644
>> --- a/ovn/ovn-sb.ovsschema
>> +++ b/ovn/ovn-sb.ovsschema
>> @@ -1,7 +1,7 @@
>> {
>> "name": "OVN_Southbound",
>> -"version": "1.2.0",
>> -"cksum": "1259182303 5368",
>> +"version": "1.3.0",
>> +"cksum": "4176169852 6394",
>>
>
> The patch will have to be rebased as this has changed in the meantime.
>
>
>> "tables": {
>> "Chassis": {
>> "columns": {
>> @@ -71,6 +71,21 @@
>> "min": 0, "max": "unlimited"}}},
>> "indexes": [["tunnel_key"]],
>> "isRoot": true},
>> +"Physical_Endpoint": {
>> +"columns": {
>> +"name": {"type": "string"},
>> +"chassis": {"type": {"key": {"type": "uuid",
>> + "refTable": "Chassis",
>> + "refType": "weak"},
>> + "min": 1, "max": 1}},
>> +"chassis_port": {"type": {"key": "string", "min": 1,
>> "max": 1}},
>> +"type": {"type": {"key": {
>> + "type": "string",
>> + "enum": ["set", ["vlan"]]}}},
>> +"ingress_encap": {"type": "string"},
>> +"egress_encap": {"type": "string"}},
>> +"indexes": [["name"]],
>> +"isRoot": true},
>> "Port_Binding": {
>> "columns": {
>> "logical_port": {"type": "string"},
>> @@ -96,6 +111,10 @@
>> "refTable": "Chassis",
>> "refType": "weak"},
>> "min": 0, "max": 1}},
>> +"phys_endpts": {"type": {"key": {"type": "uuid",
>> + "refTable":
>> "Physical_Endpoint",
>> + "refType": "weak"},
>> + "min": 0, "max": "unlimited"}},
>> "mac": {"type": {"key": "string",
>> "min": 0,
>> "max": "unlimited"}}},
>>
>
> The code and documentation both seem to imply that there should be at most
> 1 Physical_Endpoint per Port_Binding. Should "unlimited" by "1" here? If
> multiple endpoints gains a meaning in the future, it can be changed.
>
> >> The port binding code and documentation clearly support binding
> multiple physical endpoints to a logical
> >> port.
> >> look here: *cmd_lport_bind_phys_endpts*(*struct* ctl_context *ctx)
>
>
> More broadly, I'm also wondering if having Physical_Endpoints on each
> Port_Binding makes sense. We already have Chassis. To me, binding the
> gateway port to a chassis is the relationship that
[ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint separation proposal
The following is a proposal regarding how to allow logical and physical endpoint contexts for OVN to stay separated, from a CMS POV. A logical endpoint has the form: ls1-port1. A physical endpoint has the general form: chassis/physical port or location on chassis/encapsulation. Some advantages for cleanly separating logical and physical layers are: 1) Logical and physical domains can be managed separately; for example, by different companies or business units, with minimal interaction overhead. 2)The physical layer details can change without needing to change the logical layer; for example, a physical endpoint vlan can change without needing to change the logical layer, which in OVN resides in the NB DB. The physical endpoint encapsulations can even change in future, without needing to update the NB DB supported options and/or churning the NB DB. 3) The logical configuration remains simple in that it just needs to concern itself with tasks such linking users to services, without too much concern about where the services or users are presently located. A physical topology CMS or sub-component of a CMS can be used to configure physical endpoints in the SB DB directly, bypassing the NB DB and northd processing. A new Physical_Endpoint table describes endpoints used to reach a physical network only, including localnet and gateway cases. This physical topology CMS would write to this new table. Physical_Endpoint TABLE Summary: Core Features: name string (must be unique within table) chassis chassis record chassis_port string type string ingress_encapstring egress_encap string Details: Core Features: name: string (must be unique within table) A physical_endpoint name which can be used to describe its connection role. chassis: chassis record. chassis_port: string Physical port with the context the associated chassis. type: string, can be single vlan, which is presently supported. In future, a tunnel type such as MPLS/IP tunnels or multiple vlans might be used. Nomenclature is TBD. ingress_encap: string Encapsulation expected for packets received on this physical endpoint. Incorrect encapsulation will result in packet drop. egress_encap: string Encapsulation used for packets transmitted on this physical endpoint. If type is vlan, ingress_encap == egress_encap as per existing OVN expected behavior. A new ovn-sbctl command can be used in lieu of CMS support. ovn-sbctl phys-endpt-add phys_endpt_name chassis_name chassis_port type ingress_encap egress_encap The existing Port Binding table is modified for localnet and gateway cases. options : phys_endpt was added for gateways. options : phys_endpt replaces tag for localnet. Note that there is some redundancy in information, as phys_endpt includes chassis and there is a separate column for chassis in the Port Binding table. Port_Binding TABLE . . . Summary: Core Features: datapathDatapath_Binding logical_portstring (must be unique within table) chassis optional weak reference to Chassis tunnel_key integer, in range 1 to 32,767 mac set of strings typestring Patch Options: options : peer optional string Localnet Options: options : network_name optional string options : phys_endptoptional physical endpoint record VTEP Options: options : vtep-physical-switch optional string options : vtep-logical-switch optional string options : phys_endptoptional physical endpoint record Nested Containers: parent_port optional string tag optional integer, in range 1 to 4,095 . . . Details: Localnet Options: These options apply to logical ports with type of localnet. options : phys_endpt: optional physical endpoint record Used to derive physical port, ingress encapsulations and egress encapsulations. . . VTEP Options: These options apply to logical ports with type of vtep. options : phys_endpt: optional physical endpoint record Used to derive physical port, ingress encapsulations and egress encapsulations. . . . The existing ovn-sbctl lport-bind command synta
