Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect?

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 13 Mar 2006 08:35:52 +0100

Hello Roland,

|Consequently I would prefer removal of the ACK flag and possibly
|provide a simple HELLO mechanism (with adjustable timeouts)
|between peers to detect communication failures. I really don't know
|what fast reaction an application could undertake due a
|transmission/processing failure of a RESERVE message that was
|detected by the currently proposed ACK mechanism. -> see below

Such a Hello mechanism may indeed be the better idea. The current 
NSLP version seems to be rather stable. Would you propose to 
include the Hello mechanism in the current draft or would it be 
acceptable to to start working on it in a later version (e.g. 
separate document - may be a feature desireable for other 
nslps too - or qos nslp version 2)?

Regards,

Rüdiger

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 13 Mar 2006 13:22:02 +0100

Hi Ruediger,

> nslps too - or qos nslp version 2)?

I think that adding a simple Hello mechanism would be not
so complex, since overall it would be easier than implementing the
currently proposed ACK mechanism with retransmissions
per message. On the other hand we have a problem, because
information is missing about the identity of the next QoS NSLP peer
since the latter is managed by GIST and the NLI is currently
not passed over the API (which makes it also hard to realize summary
refreshes BTW). So one could think
about an API extension that allows to pass NLIs from GIST to NSLPs so
that the NSLP instance is at least able to monitor a mapping from
sessions or flows to peers/neighbors.

Note that GIST has already a HELLO mechanism per MA though it's primary
purpose was not to detect failures, but to keep the MA open, right? Thus
the rate of HELLO messages would be relatively low. Moreover, it will
not detect the liveliness of the QoS NSLP instance, only of the GIST
instance. The second issue that we need to decide about is
the reaction of QoS NSLP when a failure is detected.
Possibly it can send an Invalidate Routing State to it's own GIST
instance. This may not help, however, in case the routing and GIST
is still working correctly. Sending a NOTIFY (but for which peers
exactly?) would also be an option, but I doubt that this would help
much.

Regards,
 Roland