Subject: RE: [NSIS] state management question

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 31 Mar 2003 15:48:48 +0200

Hi all

Since the RSVPv1 (RFC2205) refresh procedure and the management of refresh 
timers work quite well I think that it should be reasonable to try and 
reuse them in NTLP.

Best Regards,
Georgios

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: donderdag 27 maart 2003 9:51
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] state management question

Robert,

my answers on your final questions in line. I've 
added some text on the message sequence number 
mechanism, which I think is another issue 
raising concerns.

Regards, Rüdiger

| To make it concrete in this case:
| - should the NTLP contain fields which are refresh times? 
|   always? sometimes?

Don't think so. Local time information should be used to 
maintain state only. Also a refresh reduction mechanism 
shouldn't require timestamps to be transmitted. If possible.

| - should the NTLP have a bit in its header which 
|  distinguishes between state refreshing and other messages?

As the refresh message initiates completely new state in the 
case of a route change in new routers, the refreshes 
shouldn't be "marked". Your idea is to distinguish between a 
refresh of state and a modification of this state?  
Valid Point. It may be more useful to have 
"state set up & modification" messages instead of 
"state set up & refresh" messages. The NLTP 
receiving a "state set up" with an already existing session 
ID knows that this is a refresh and acts accordingly. 

| - should the NTLP make up its own mind whether to acknowledge 
|   state creation or deletion messages?

The fast answer is: no, that's an issue of NSLP. It gets 
tricky should NTLP maintain state also for services without 
local NSLP support (the NTLP relay case). I think we should 
clarify what these NTLP relay nodes are supposed to do with 
messages they have no NSLP support for. Or whether we 
allow such a NTLP relay function at all. My personal 
feeling is:
- NTLP relay may be useful.
- NTLP service state maintenance only if NSLP is present.
In this case, each NTLP node must interpret the NSLP field 
of a "state set up" message first and then check the 
session ID.

A concern I have is whether to maintain sequence numbers in 
NTLP or NSLP only or whether to maintain them on both 
layers. If refreshes are handled by NTLP only, NTLP must 
be aware of the sequence numbers. It must maintain the 
service specific sequence numbering mechanism too. In the 
case of an NTLP relay, there's no service specific state, 
hence there's no sequence number maintenance (for relayed 
messages). It might be advantageous to let the sequence 
number mechanism count messages between adjacent NTLP 
peers only.

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 31 Mar 2003 16:24:24 +0200

Hi Georgios,

On Mon, 31 Mar 2003 15:48:48 +0200

> timers work quite well I think that it should be reasonable to try and 

Sorry, I disagree here if you do not include RFC 2961 as well.
If I remember correctly, there was a consensus to use at least
both 2205+2961 as a starting point.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked] WWW: http://www.tm.uka.de/~bless
Institute of Telematics, University of Karlsruhe, Germany  
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Mon, 31 Mar 2003 09:35:43 -0500

> both 2205+2961 as a starting point.

That is correct, although that decision should probably be
confirmed on the mailing list.  I don't recall anybody
voicing objection to it at the meeting.

Melinda