On Thu, Aug 30, 2012 at 09:33:23PM -0700, Ben Pfaff wrote: > 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.
FWIW, I spoke to the Ryu people and they have a preference for receiving in-spec errors unless an NX extension is in use. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
