[Nsi-wg] Error code and serviceException

[Radek Krzywania]

Hi
For me it's reasonable, however shouldn't it be a binary notation? E.g. lets
take a byte as a base
PAYLOAD_ERROR               00010000 (16)
   MISSING_PARAMETER         00010001 (17)
   NOT_IMPLEMENTED           00010010 (18)
CONNECTION_ERROR            00100000 (32)
   INVALID_TRANSITION        00100001 (33)
   CONNECTION_EXISTS         00100010 (34)
   CONNECTION_NONEXISTENT    00100011 (35)
   CONNECTION_GONE           00100100 (36)
Etc.

This gives 15 error types (first 4 bits) + 15 specific errors per type
(second 4 bits). It may be easier to use it in the code, e.g. if you don't
care for specific errors (AND, OR, XOR operations possible) it will be
easier to extract and interpret interesting information IMHO. If 15x15
errors is insufficient, we can use 16 bits as a base for that (that would be
255x255), or something in between (e.g. 8bits base 31x7)

Best regards
Radek
   

______________________________________________
Radosław Krzywania

Network Department of
Poznan Supercomputing and Networking Center

http://www.man.poznan.pl
______________________________________________

> -----Original Message-----
> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf
> Of Henrik Thostrup Jensen
> Sent: Tuesday, December 11, 2012 1:46 PM
> To: NSI Working Group
> Subject: [Nsi-wg] Error code and serviceException
> 
> Hi everyone
> 
> I was doing some error handling stuff in OpenNSA and realized that we
> probably didn't close that one properly after Oxford. These are also
pretty
> important to get into an appendix in the standard, so we can do proper
error
> handling in the imeplementations.
> 
> Here are the error code that I presented in Oxford:
> 
> PAYLOAD_ERROR               00100
>    MISSING_PARAMETER         00101
>    NOT_IMPLEMENTED           00102
> CONNECTION_ERROR            00200
>    INVALID_TRANSITION        00201
>    CONNECTION_EXISTS         00202
>    CONNECTION_NONEXISTENT    00203
>    CONNECTION_GONE           00204
> SECURITY_ERROR              00300
>    UNAUTHORIZED              00301
> TOPOLOGY_ERROR              00400
>    UNKNOWN_STP               00401
>    STP_RESOLUTION_ERROR      00402
>    NO_PATH_FOUND             00403
> INTERNAL_ERROR              00500
>    INTERNAL_NRM_ERROR        00501
> RESOURCE_UNAVAILABLE        00600
>    STP_UNAVALABLE            00601
>    BANDWIDTH_UNAVAILABLE     00602
> 
> I _think_ we agreed to them without to much fuzz. The idea is that we can
> add new errors without changing the protocol and that a new resource
> unavailable code (say 00603, can be generalized into 00600 if the
> implementation does not know 00603).
> 
> I think we also need a failure to indicate that a connection could not be
> created due to a downstream NSA being unavailable or similar. I cannot
think
> of a good name though, but it belongs under 00200 / CONNECTION_ERROR.
> Maybe CONNECTION_CREATE_ERROR / 00205.
> 
> Note that it is the error codes (the numbers) that should be specified in
the
> errorId field in the nsi:serviceException. The names should not be
> transmitted.
> 
> Previously some have used 'SVC' as a prefix to the error codes (to
indicate
> service failure), but I am not sure if we agreed on anything for
> NSI2 (I don't see the need
> 
> @John: Maybe you could put the error codes in the WSDL documentation.
> 
> Finally, right now, variables is mandatory in nsi:serviceException,
however
> not all errors need to be related to a variable (downstream NSA
unavailable),
> so I suggest we make variables optional.
> 
> 
>      Best regards, Henrik
> 
>   Henrik Thostrup Jensen <htj at nordu.net>
>   Software Developer, NORDUnet
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg