[ovs-dev] NX error codes for Open Flow 1.1+

[Simon Horman]

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.