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