[ovs-dev] [PATCH 1/2] ovn/TODO: Update for items that have been completed.

[Ryan Moats]

"dev" <dev-bounces at openvswitch.org> wrote on 08/18/2016 01:14:24 PM:

> From: Ben Pfaff <blp at ovn.org>
> To: dev at openvswitch.org
> Cc: Ben Pfaff <blp at ovn.org>
> Date: 08/18/2016 01:14 PM
> Subject: [ovs-dev] [PATCH 1/2] ovn/TODO: Update for items that have
> been completed.
> Sent by: "dev" <dev-bounces at openvswitch.org>
>
> I think that all of these items are either done now or just simply don't
> need this level of detail.
>
> Signed-off-by: Ben Pfaff <blp at ovn.org>
> ---
>  ovn/TODO | 114 ++++
> +----------------------------------------------------------
>  1 file changed, 8 insertions(+), 106 deletions(-)
>
> diff --git a/ovn/TODO b/ovn/TODO
> index dab8648..b3c4831 100644
> --- a/ovn/TODO
> +++ b/ovn/TODO
> @@ -1,70 +1,11 @@
>  -*- outline -*-
>
> -* L3 support
> -
> -** New OVN logical actions
> -
> -*** icmp4 { action... }
> -
> -Generates an ICMPv4 packet based on the current IPv4 packet and
> -processes it according to each nested action (and then pops back to
> -processing the original IPv4 packet).  The intended use case is for
> -generating "time exceeded" and "destination unreachable" errors.
> -
> -ovn-sb.xml includes a tentative specification for this action.
> -
> -Tentatively, the icmp4 action sets a default icmp_type and icmp_code
> -and lets the nested actions override it.  This means that we'd have to
> -make icmp_type and icmp_code writable.  Because changing icmp_type and
> -icmp_code can change the interpretation of the rest of the data in the
> -ICMP packet, we would want to think this through carefully.  If it
> -seems like a bad idea then we could instead make the type and code a
> -parameter to the action: icmp4(type, code) { action... }
> -
> -It is worth considering what should be considered the ingress port for
> -the ICMPv4 packet.  It's quite likely that the ICMPv4 packet is going
> -to go back out the ingress port.  Maybe the icmp4 action, therefore,
> -should clear the inport, so that output to the original inport won't
> -be discarded.
> -
> -*** tcp_reset
> -
> -Transforms the current TCP packet into a RST reply.
> -
> -ovn-sb.xml includes a tentative specification for this action.
> -
> -*** Other actions for IPv6.
> -
> -IPv6 will probably need an action or actions for ND that is similar to
> -the "arp" action, and an action for generating
> -
> -** IPv6
> -
> -*** Drop invalid source IPv6 addresses
> -
> -*** Don't forward non-routable addresses
> -
> -*** ICMPv6 action
> -
> -Similar to the ICMPv4 action, ICMPv6 messages should be generated.
> -
> -*** Neighbor Discovery
> -
> -**** ND Router Advertisements
> -
> -The router ports should periodically send out ND Router Advertisements
> -and respond to Router Solicitations.
> -
> -**** Learn MAC bindings on ND Solicitations
> -
> -**** Properly set RSO flags
> -
> -** Dynamic IP to MAC bindings
> +* Dynamic IP to MAC binding enhancements.
>
>  OVN has basic support for establishing IP to MAC bindings dynamically,
>  using ARP.
>
> -*** Ratelimiting.
> +** Ratelimiting.
>
>  From casual observation, Linux appears to generate at most one ARP per
>  second per destination.
> @@ -72,14 +13,14 @@ second per destination.
>  This might be supported by adding a new OVN logical action for
>  rate-limiting.
>
> -*** Tracking queries
> +** Tracking queries
>
>  It's probably best to only record in the database responses to queries
>  actually issued by an L3 logical router, so somehow they have to be
>  tracked, probably by putting a tentative binding without a MAC address
>  into the database.
>
> -*** Renewal and expiration.
> +** Renewal and expiration.
>
>  Something needs to make sure that bindings remain valid and expire
>  those that become stale.
> @@ -87,24 +28,16 @@ those that become stale.
>  One way to do this might be to add some support for time to the
>  database server itself.
>
> -*** Table size limiting.
> +** Table size limiting.
>
>  The table of MAC bindings must not be allowed to grow unreasonably
>  large.
>
>  ** MTU handling (fragmentation on output)
>
> -* ovn-controller
> -
> -** ovn-controller parameters and configuration.
> -
> -*** SSL configuration.
> -
> -    Can probably get this from Open_vSwitch database.
> -
> -** Security
> +* Security
>
> -*** Limiting the impact of a compromised chassis.
> +** Limiting the impact of a compromised chassis.
>
>      Every instance of ovn-controller has the same full access to the
central
>      OVN_Southbound database.  This means that a compromised chassis can
> @@ -144,38 +77,7 @@ large.
>    needs work for scale and possibly for availability as deployments
>    grow.  Here are some thoughts.
>
> -  Andy Zhou is looking at these issues.
> -
> -*** Reducing amount of data sent to clients.
> -
> -    Currently, whenever a row monitored by a client changes,
> -    ovsdb-server sends the client every monitored column in the row,
> -    even if only one column changes.  It might be valuable to reduce
> -    this only to the columns that changes.
> -
> -    Also, whenever a column changes, ovsdb-server sends the entire
> -    contents of the column.  It might be valuable, for columns that
> -    are sets or maps, to send only added or removed values or
> -    key-values pairs.
> -
> -    Currently, clients monitor the entire contents of a table.  It
> -    might make sense to allow clients to monitor only rows that
> -    satisfy specific criteria, e.g. to allow an ovn-controller to
> -    receive only Logical_Flow rows for logical networks on its
hypervisor.
> -
> -*** Reducing redundant data and code within ovsdb-server.
> -
> -    Currently, ovsdb-server separately composes database update
> -    information to send to each of its clients.  This is fine for a
> -    small number of clients, but it wastes time and memory when
> -    hundreds of clients all want the same updates (as will be in the
> -    case in OVN).
> -
> -    (This is somewhat opposed to the idea of letting a client monitor
> -    only some rows in a table, since that would increase the diversity
> -    among clients.)
> -
> -*** Multithreading.
> +** Multithreading.
>
>      If it turns out that other changes don't let ovsdb-server scale
>      adequately, we can multithread ovsdb-server.  Initially one might
> --

LGTM

Acked-by: Ryan Moats <rmoats at us.ibm.com>