[Nsi-wg] Error code and serviceException

[John MacAuley]

Radek - The error codes are currently strings, so no restrictions.

Henrick - Add your error codes to the following living document I created after our last discussion:

https://code.google.com/p/ogf-nsi-project/wiki/NSIErrorCodes

John.

On 2012-12-11, at 8:22 AM, Radek Krzywania <radek.krzywania at man.poznan.pl> wrote:

> 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
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg