Subject: RE: [NSIS] state management question

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Mar 2003 16:35:31 +0100

Georgios,

That is one aspect of the question.

another way to put it:
Should there be a single state management procedure which all signalling applications (and indeed all NSIS entities) have to use?
OR
Should we decouple the lower and upper layers and allow a clever implementor to integrate them for efficiency for particular signalling applications?

(i prefer the second.)

another way to put it:
Should the NTLP internal design be determined by the state management service it offers externally to signalling applications ?

(sounds like a bad idea to me, though i admit i am more influenced by philosophical considerations in holding that view.)

cheers,

robert h.

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 31 March 2003 16:16
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] state management question
> 
> 
> Hi Robert
> 
> I do not understand your question.
> Are you saying that we need to have two
> refresh management procedures?
> One for NTLP states and one for NSLP states!
> 
> Best Regards,
> Georgios
> 
> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: maandag 31 maart 2003 17:13
> To: Georgios Karagiannis (ELN); [email-masked]
> Subject: RE: [NSIS] state management question
> 
> 
> hi georgios,
> 
> you are right to point out this difference.
> (in the email at the start of the thread: "(Note that this is 
> entirely not about state that the NTLP uses internally, e.g. 
> to route messages correctly.)")
> 
> so, my question is about the assertion:
> "One can use the NTLP state management procedure to maintain 
> the NSLP reservation) states"
> 
> (can one really? is it a good idea? is it more than an 
> implementation issue?)
> 
> especially, if it is more than an implementation issue, 
> ***what is the actual impact on the protocol?*** (in broad 
> terms, or giving an example)
> 
> cheers,
> 
> r.
> 
> > -----Original Message-----
> > From: Georgios Karagiannis (ELN)
> > [mailto:[email-masked]]
> > Sent: 31 March 2003 16:04
> > To: Hancock, Robert; [email-masked]
> > Subject: RE: [NSIS] state management question
> > 
> > 
> > Hi Robert
> > 
> > The NTLP states are in my opinion different than the 
> > NSLP states.
> > The NTLP states are more associated with forwarding behavior and 
> > the NSLP application states are reservation states.
> > One can use the NTLP state management procedure to maintain the 
> > NSLP (reservation) states, but this cannot be done the other 
> > way around!
> > This is for example valid when not all NSIS nodes support 
> > NSLP functionality
> > (but they support NTLP functionality).
> > 
> > Best Regards,
> > Georgios
> > 
> > -----Original Message-----
> > From: Hancock, Robert [mailto:[email-masked]]
> > Sent: maandag 31 maart 2003 16:42
> > To: Georgios Karagiannis (ELN); [email-masked]
> > Subject: RE: [NSIS] state management question
> > 
> > 
> > georgios,
> > 
> > two questions:
> > *) regardless of whether the general idea of soft stateness 
> > is good and how well it works in RSVP, why support it 
> > explicitly in the NTLP - why isn't this a signalling 
> > application issue? if something is needed in the NTLP, why 
> > isn't it an implementation issue?
> > *) assuming the answer is still 'it is meaningfully part of 
> > the NTLP', what kind of detectable impact on the actual 
> > protocol would you expect it to have?
> > 
> > what i'm trying to make progress from is the generalised view 
> > 'let's put soft state in the NTLP' and turn that into a 
> > concrete statement whose impact on the framework can be 
> > evaluated. at the moment, it seems to be a matter of opinion 
> > whether the question has no meaning or very deep meaning (at 
> > least to me).
> > 
> > robert h.
> > 
> > > -----Original Message-----
> > > From: Georgios Karagiannis (ELN)
> > > [mailto:[email-masked]]
> > > Sent: 31 March 2003 14:49
> > > To: [email-masked]
> > > Subject: RE: [NSIS] state management question
> > > 
> > > 
> > > 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
> > > 
> > 
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Tom Taylor <[email-masked]>
Date: Mon, 31 Mar 2003 11:26:31 -0500

I've seen enough of this dialogue now to decide that this is not a totally stupid 
question.  Could we possibly get a bit more concrete and indicate what sort of state 
variables we are talking about at the NTLP level?  Is it next-NTLP-hop for a given 
NTLP session, and what else?