Subject: RE: [NSIS] state management question

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

Hi Roland

RFC2961 describes an optimization procedure!

Best Regards,
georgios

-----Original Message-----
From: Roland Bless [mailto:[email-masked]]
Sent: maandag 31 maart 2003 16:24
To: Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: Re: [NSIS] state management question

Hi Georgios,

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

> 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.

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
 
> -----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

-- 
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: Roland Bless <[email-masked]>
Date: Mon, 31 Mar 2003 17:04:45 +0200

Hi Georgios

> RFC2961 describes an optimization procedure!

IMO it describes a number of operational problems
and solutions for them due to feedback of implementers
and operators. RFC 2961 won't be there if it was pure 
optimization. However, there may be some environments 
in which these extensions are not necessarily required.
But I got the impression from several discussions that
most people think that RFC 2205 alone is not sufficient for
most cases.

Regards,
 Roland