[ovs-dev] [PATCH] OPENFLOW-1.1+: note on table-miss
Simon Horman
horms at verge.net.au
Fri Nov 1 08:06:44 UTC 2013
On Fri, Nov 01, 2013 at 04:25:25PM +0900, YAMAMOTO Takashi wrote:
> > On Fri, Nov 01, 2013 at 03:23:10PM +0900, YAMAMOTO Takashi wrote:
> >> > 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.
> >>
> >> it sounds difficult to handle for controller-side programmers.
> >>
> >> >
> >> > 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.
> >>
> >> this leaves the question what should be the default.
> >
> > I meant to do both A and B.
> > But yes, it does side-step the issue to some extent.
> >
> >>
> >> C:
> >> decide what to do (packet-in or drop) per ofconn basis,
> >> depending on OF versions.
> >> (ofconn_receives_async_msg can take care of this.)
> >
> > That is fine, so long as there is one connection.
> > And in the case where there is no controller then I think
> > the OpenFlow 1.0 behaviour degrades to drop anyway.
> >
> > But I think we need to consider the case of multiple controllers.
> > In particular two, both ROLE_EQUAL, that use OpenFlow versions
> > with different defaults in this regards. I believe this is supported
> > as of OpenFlow 1.2.
>
> i meant, in that case, send packet-in only to connections using
> prior OF versions.
Oh, I see. Yes, I think that could work.
More information about the dev
mailing list