>
> please see responses inline
>
> ---------- Forwarded message ----------
> From: Russell Bryant <russ...@ovn.org>
> Date: Tue, Mar 29, 2016 at 11:18 AM
> Subject: Re: [ovs-dev] [PATCH 1/2] [Patch V3] OVN: Physical Endpoints
> To: Darrell Ball <dlu...@gmail.com>
> Cc: ovs dev <dev@openvswitch.org>
>
>
>
>
> On Tue, Mar 29, 2016 at 12:56 AM, Darrell Ball <dlu...@gmail.com> 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 <db...@vmware.com>
>> ---
>> 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 makes sense here. How
> that is realized on the chassis is a separate thing. It seems like a list
> of physical endpoints could be on the Chassis, instead.
>
>
> >> The pre-existing code used by hypervisors binds logical ports to
> "physical endpts". This is done thru. the
> >> iface-id in external_ids. This is needed to map b/w logical and
> physical "endpoints".
>
>
> We also have a somewhat conflicting approach in configuring each chassis.
> We have ovn-bridge-mappings, but these patches take a different approach
> that doesn't appear to actually work in all cases.
>
> >> This approach works in all cases
> >> If there is a case that it does not support, I can comment on the
> design of that feature - let me know
>
> A Physical_Endpoint has a "chassis_port". The code will look for
> br-<chassis_port> and create it if it doesn't exist. If ovn-controller
> creates it, it won't do anything useful as no interface has been added to
> the bridge.
>
> >> It creates a trunk port which is all that is needed; this port is
> intended to be unmanaged by OVN
>
> I'd rather just make use of ovn-bridge-mappings. Roughly, I think that
> means replacing "chassis_port" with "network_name" and using that name to
> figure out which bridge to use on the chassis based on its local
> ovn-bridge-mappings configuration.
>
> >> I disagree; the bridge mappings is being generated by a human parsing
> the network topology and port
> >> mapping per chassis on every chassis; this is both error prone and
> manual work intensive.
> >> I think a later patch proposes then copying bridge-mapping to the
> chassis table so it can be used
> >> by the CMS
> >> This marshalling cannot be managed easily and is limited in
> applicability in real networks
>
> >> The physical endpoint approach has a few aspects including making the
> physical network config more
> >> plug and play, allowing the physical and logical networks to be managed
> separately and supporting
>
> >> different >> encapsulations seen in most real provider networks
>
>
>
> To be even more difficult, I still find myself wondering if this
> Physical_Endpoint stuff is needed at all. It doesn't seem to actually add
> any new capabilities, but it does add new complexity. I feel like we could
> add this initial L2 gateway support without having it at all. I couldn't
> help myself and have started writing it to try to see what that would look
> like. I'm trying to do it as quick as I can so that I can get on board
> with this or have a more clear alternative proposal.
>
> --
> Russell Bryant
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
