[ovs-dev] [PATCH] OPENFLOW-1.1+: note on table-miss

Simon Horman horms at verge.net.au
Fri Nov 1 05:52:53 UTC 2013


On Tue, Oct 15, 2013 at 05:12:22PM +0900, YAMAMOTO Takashi wrote:
> Signed-off-by: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
> ---
>  OPENFLOW-1.1+ | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/OPENFLOW-1.1+ b/OPENFLOW-1.1+
> index 07b2660..4f30520 100644
> --- a/OPENFLOW-1.1+
> +++ b/OPENFLOW-1.1+
> @@ -121,6 +121,13 @@ didn't compare the specs carefully yet.)
>        [optional for OF1.3+]
>  
>      * More flexible table miss support.
> +      This requires the following.
> +      - Change the default table-miss action (in the absense of table-miss
> +        entry) from packet_in to drop for OF1.3+.  Decide what to do if
> +        a switch is configured to support multiple OF versions.

I'm wondering what is a good approach to take here.

It is possible to configure Open vSwitch (ovs-vswtichd) to only accept Open
Flow 1.3+ connections.  In which case it should be possible to select the
default behaviour described above.  However it is also possible for Open
vSwitch (ovs-vswtichd) to be configured to accept a connections for Open
Flow versions prior to 1.3, and 1.3+.

This is complicated by the fact that OpenFlow 1.3 conveniently deprecates
all the TABLE_MOD bits that allow configuration of this behaviour. Though I
assume deprecated doesn't mean not allowed.

With the constraints describe above and making the bold assumption that I'm
not missing any further constraints I propose the following:

A:
  1. If Open vSwtich is configured to only accept connections
     for Open Flow 1.3+ then default to drop.

  2. Otherwise use the current default, packet_in.

  Is this a good idea? It may be to subtle to be useful in practice.

B:
  Implement TABLE_MOD to allow it to be used to control the behaviour
  of each table's miss behaviour.

  We could even go so far as to encourage people to use it,
  even if they are using Open Flow 1.3+, to ensure that the
  behaviour is what they expect.



More information about the dev mailing list