"dev" <dev-boun...@openvswitch.org> wrote on 08/18/2016 01:14:24 PM:
> From: Ben Pfaff <b...@ovn.org>
> To: dev@openvswitch.org
> Cc: Ben Pfaff <b...@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-boun...@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 <b...@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 <rmo...@us.ibm.com>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
