Subject: [NSIS] drop the term session? (was: RE: Comments on framework draft)

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 20 Oct 2002 00:18:13 +0100

hi all,

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: 19 October 2002 21:06
> To: [email-masked]; [email-masked]; Hancock, Robert
> Subject: RE: [NSIS] Comments on framework draft
> 
> 
> 
>   *> 
>   *> > 
>   *> > 2) Are "sessions" established between NSIS Entities?  Note
>   *> >    that they don't eliminate state, but just move it to
>   *> >    another layer - what advantages does this have over the
>   *> >    more stateless RSVP protocol machinery?
>   *> [reh] all 'session' is is a name for whatever protocol 
> layer state is established between NSIS peers. this could be 
> very small (nothing), just next/previous hop id (like RSVP), 
> or quite complex (including security information).
>   *> 
>   *> the relative amounts of state in NSIS protocol vs. 
> signalling applications is a very good question, as is 
> working out how it can be minimised. i don't personally 
> expect it can be eliminated in a real protocol, but nothing is fixed.
>   *> 
>   *> (people are free to suggest a less loaded term than 'session'.)
>   *> 
> 
> I suggest that the solution is to simply eliminate the term.  It does
> not seem necessary, and perhaps not useful.  Note that in routing
> protocols, neighboring routers announce their presence to each other
> and may even exchange security information, but these neighbor
> announcements are not said to create sessions.  My 2-level signaling
> draft simply says:
> 
> 
>       A CSTP module must maintain state that lists the node's 
> neighbors.
>       This state includes the IP address of the neighbor and the local
>       interface used to reach it.  This per-neighbor state 
> also includes
>       two Boolean flags giving important properties of the neighbor,
>       e.g., ISPS-capable and Direct-Neighbor.  A node builds the
>       neighbor list as a result of receiving CSTP messages.  The
>       neighbor list should be implemented as soft state that 
> is deleted
>       if it is not refreshed.
> 
> Introducing a term like "session" for this neighbor state does not
> seem to me to add any clarity.
> 
> Bob Braden
> 

how about: where we use 'peer session' as a noun, replace it with 'peer relationship' (probably a better term anyway, as well as less loaded); replace 'peer session addressing' with 'peer-peer addressing'. the abstract fact of there being some relationship is in any case more important than any specific state information.

[why not just say "hop by hop"? that's the term i used to use, but i was then assailed by people who claimed i was talking about IP hops. sometimes you can't win.]

cheers,

robert h.

========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.