[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