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
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@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
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
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
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 ______________________________________________ pretty think 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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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@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@ogf.org [mailto:nsi-wg-bounces@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Henrik Thostrup Jensen -
John MacAuley -
Radek Krzywania