On Fri, Aug 31, 2012 at 10:40:26AM +0900, Simon Horman wrote: > 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.
Sounds good. Thank you. > > > 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? No. The OpenFlow specs say little about what errors should be used in what situations. (In the places where it does specify errors, we try to follow what it says and I'd consider it a bug if we get it wrong.) But since it says so little, I've assumed for a while that controllers don't generally try to intelligently do different things based on the particular error that they get back. However, the only controller that I've contributed significant code to is NOX, and that was long ago, before OpenFlow standardization, so I can't and won't claim any expertise in that area. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
