On Wed, Aug 29, 2012 at 10:59:09AM -0700, Ben Pfaff wrote: > On Mon, Aug 27, 2012 at 05:08:34PM +0900, Simon Horman wrote: > > I am wondering if you could offer some guidance with regards to > > using NX error codes. > > > > I have not checked all use-cases, but it seems to me that for OpenFlow1.0 > > such messages are only used when an NX extension is in use and thus the > > controller is aware of the extension and error code. This seems > > straightforward. > > If that's what happened, it was accidental. I guess that there are some > situations where OpenFlow simply doesn't define an appropriate error > code, so we invented an extension error code to cover that case. (When > there is an appropriate error code, we should use it.) > > > What I am concerned about is OpenFlow1.1+, in particular the following two > > cases. The basis of my concern is that using NX codes seems to imply that > > they are understood by the controller, but the codes seem to be used in > > conjunction with standard OpenFlow1.1+ behaviour, not NX extensions. > > > > 1. An NX code is used but an equivalent OpenFlow1.1+ code exists. > > For example OFPERR_NXBRC_BAD_TABLE_ID and OFPERR_OFPBRC_BAD_TABLE_ID. > > > > Three behaviours spring to mind > > > > i. Always use OFPERR_NXBRC_BAD_TABLE_ID > > ii. Always OFPERR_OFPBRC_BAD_TABLE_ID by adding the appropriate NX() > > annotation to its definition. This appears to be the way that > > OFPERR_OFPBMC_DUP_FIELD is handled. > > iii. Use OFPERR_NXBRC_BAD_TABLE_ID for OpenFlow 1.0 and > > OFPERR_OFPBRC_BAD_TABLE_ID for Open Flow 1.1+. > > In general, when or if there's an OpenFlow 1.1+ code that is > approximately appropriate, I'd prefer to use it. Ideally, the > ofp-errors code would be flexible enough so that we can just return a > single OFPERR_* code, without knowing or caring what protocol is in use, > and then ofperr_encode_reply() or related code would choose the > appropriate protocol encoding. This is (ii), I think.
Yes, I think that is (ii) and having thought about things more since I wrote my previous email I agree that this seems preferable. In the case I give above I think that it should be easy enough to a achieve and I'll see about making a patch. I'll also hunt though the code for other cases. > > 2. An NX code is used but no equally specific OpenFlow1.1+ code exists. > > For example OFPERR_NXBIC_DUP_TYPE. > > > > Here I also see a few options > > > > i. Always use OFPERR_NXBIC_DUP_TYPE. > > ii. Always use a less specific type, e.g. OFPERR_OFPIT_BAD_INSTRUCTION. > > > > Using OFPERR_NXBIC_DUP_TYPE only for Open Flow 1.0 doesn't seem > > to be meaningful as OFPERR_NXBIC_DUP_TYPE is annotated as NX1.1+ > > and the error code is only used in an OpenFlow 1.1+ code path. > > Hmm. I like the idea of specific errors, so I'd lean toward i. But I'm > open to discussion. I also like the idea of specific errors, however, I'm not sure how comfortable I am about the implication that the controller needs to know NX messages when not using any (other) NX extensions. Is there a well defined behaviour for controllers when they encounter an unknown error message? _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
