Subject: [NSIS] QoS NSLP: Reason for tearing

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 20 Mar 2007 19:02:06 +0200 (EET)

We have discussed a bit the NSLP tear operation, and would propose to add 
an INFO_SPEC also to the RESERVE message. This INFO_SPEC would be used to 
indicate the reason for a tearing RESERVE. Possible reasons include 
internal QNE error, Path Truncated, pre-emption, etc. Since the RESERVE is 
sent towards the QNE, a NOTIFY MAY be sent towards the QNI.

Any comments on this?

Jukka

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 22 Mar 2007 17:29:27 +0000

> sent towards the QNE, a NOTIFY MAY be sent towards the QNI.

In principle this sounds OK. However, I'm not sure whether using the
INFO_SPEC for this is the right way to do it.

The reason codes for tearing aren't the same as the error codes in the
INFO_SPEC. The optional error-specific information also probably does
not make sense in this context. So, should we define something else to
carrying this information? Or, should we 'profile' the INFO_SPEC for
this use? (In the second case, we'd have to consider what to do if an
inappropriate code is used, e.g. "mandatory object missing"). One factor
in the decision might be what you do with this information when you
receive it - if it is purely informational then the choice might be less
critical.

Andrew

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 22 Mar 2007 19:36:32 +0200 (EET)

Hi,

The purpose is of course for diagnostics. Whatever the error code is, it 
doesn't affect the implementation a bit. Yet, it allows a humanoid (or AI) 
to get the information that e.g. a QNE had an internal system error. This 
would allow to take measures.

Furthermore, the error specific information can be used to provide the 
source of the error node, the QNE that killed a reservation. This is not 
possible currently.

Jukka