Subject: [NSIS] clarifications on shore-ntlp

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 30 Jun 2003 12:33:46 +0200

Melinda,

I've read your draft and would like to provide a brief feedback:

I like the introduction of TLVs in an early stage. The "epoch" and protection of internal state mechanisms sound useful too.

Could you explicitely identify which state-information is maintained by NTLP? I wasn't able to understand that from your document.

§5.5.1 mentions that "Messages containing the MESSAGE_ID_LIST TLV are normally sent end-to-end in a forward direction with a destination IP address equal to the address of the original reservation, or trigger, request." I thought MESSAGE_IDs were only valid between adjacent NTLP nodes. Could you clarify?
§5.3, last section, specifies that Nodes receiving a message ... containing a MESSAGE_ID TLV with the ACK_Desired flag set should respond with a MESSAGE_ID_ACK TLV. If response to "ACK_Desired" is optional, how does the sender react if his request is never ACKed because the receiver doesn't support this option?
Further, your draft doesn't seem to define whether or how an originator of a summary refresh reacts if it doesn't receive ACK/NACK messages (e.g. due to losses).

§ 5.3 mentions that a "The ACK_Desired flag will typically be set only in trigger messages". The text doesn't define "trigger messages".

§ 5.5.1 says, "The destination IP address may be set to the NTLP next hop when the next hop is known to be NTLP-capable." That's the case for upstream communication only, isn't it?

I don't intend to start a detailed discussion. I'm rather asking for a couple of clarifications by the author. 

Regards, Rüdiger

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

---

From: Melinda Shore <[email-masked]>
Date: Mon, 30 Jun 2003 14:26:22 -0400

1) Right now the only state being maintained by the NTLP is
for its own function, which would include timers, per-hop
path state, ACK/NACK state, etc.

2) 2961 says that MESSAGE_IDs may only used between adjacent
nodes.  That there's a conflict in my document is an error
on my part, but it isn't obvious to me which is the right
answer.  In 2961 MESSAGE_ID is used to support reliable
messaging, which is hop-by-hop.  We've talked a bit on the
mailing list about identifiers with global scope and while
there's some agreement that it's needed there really hasn't
been sufficient discussion of namespace collision avoidance
and there hasn't been discussion of how to avoid a
proliferation of identifiers, the latter of which is a
potential problem.

3) As I mention in the TO DO list the NACK and error
processing need to be filled out.  "Error" would include
packet loss, and you're correct to point that out.

4) a trigger message is the first one to request a
particular reservation/data flow.  This is another topic
that requires discussion by the working group since it
touches on the problem of where to place the layer
separation and how clean it should be (or how much awareness
the layers should have of each other).  

5) yes, that's correct, and the text needs to be clearer.

Thanks,

Melinda