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

Simon Horman horms at verge.net.au
Fri Aug 31 01:40:26 UTC 2012


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?



More information about the dev mailing list