Subject: RE: [NSIS] state management and the nsis framework

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 13 May 2003 11:57:57 +0100

oops, typo spotted (see below)

> -----Original Message-----
> From: Hancock, Robert 
> Sent: 13 May 2003 11:50
> To: 'Georgios Karagiannis'
> Cc: [email-masked]
> Subject: RE: [NSIS] state management and the nsis framework
> 
> 
> georgios,
> 
> in terms of what is being discussed below, could you clarify 
> if you see
> any difference in overall NSIS functionality between our two 
> descriptions
> (and what this difference is).
> 
> if there is no overall difference, could you explain why you 
> prefer your
> split of responsibility between NSLP/NTLP. what you propose 
> seems to me
> to assume a closer customisation of NTLP functionality to 
> support one specific
> signalling application that I feel we should be aiming for.
                         ^^^^
should be:              "than"

> 
> cheers,
> 
> r.
> 
> 
> > ------------------------------------------------------------
> > [GK]
> > > Okay, but will then the following functionality will also 
> > be possible:
> > > The NSLP refresh procedure can be a pure NTLP refresh procedure,
> > > meaning that a refresh NTLP message is periodically sent
> > > through all the NTLP stateful nodes located between NI 
> (sender) and
> > > NR (receiver).  If a NTLP state in a NTLP stateful is not 
> refreshed
> > > on time then the NTLP functionality at this node informs 
> > the NSLP state
> > that
> > > the refresh procedure is unsuccessful.
> > 
> > >> [reh] I think you are describing a case for a particular 
> > NSLP, where an
> > NSLP-aware node
> > >> just wants to know that it's NSLP peer is alive and 
> > kicking. In that
> > case, I would rather think of this
> > >> as the NSLP generating a rather small, content-free 
> > keepalive which it
> > sends via the NTLP to
> > >> its peer. An implementation would be free to piggyback 
> > this information
> > on whatever is going on
> > >> inside the NTLP, so the end result is identical (in
> > performance/functionality terms) to what you
> > >> describe. However, I prefer my way of thinking about it 
> > for at least 2
> > reasons:
> > >> a. looser coupling between NSLP/NTLP specification
> > >> b. cleaner support from multiple NSLPs
> > 
> > [GK] No, I am describing a situation where the NTLP state 
> > management is
> > performed by the
> > NTLP protocol. If needed the NSLP protocol can use this NTLP 
> > procedure to
> > realise the
> > NSLP soft state management.
> _______________________________________________
> 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: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 13 May 2003 15:22:12 +0200

Hi Robert

[reh]
> > signalling application that I feel we should be aiming for.

[GK]
The main difference is the following:
* In my proposed text, the NTLP is used to provide NTLP soft state
management,
   meaning that NTLP refresh messages are used. The NSLP is using this
procedure
   for NSLP soft state management. If a NTLP state is not refreshed, then
the NSLP instance
   is informed about it. Moreover, for inter-domain signaling no NSLP
refresh
   messages are needed. Please note that a NSLP might choose to not use the
NTLP soft
   state management.

* If  I understood you correctly, in your proposed text you are in favour of
using
   the NSLP protocol to provide the NSLP and NTLP soft state manegement.
Meaning that
   each NSLP will have to use its own refresh messages for providing NSLP
and NTLP soft state
   management.

In my opinion my proposed text is presenting a NTLP/NSLP soft state
management concept that is not specific
for one signaling application, but that is general and can be used for all
types of signaling applications.
Please note that this soft state management concept is similar to the soft
state manegement concept presented
in the Bob Braden's draft, see:
http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-01.txt

However, please note that these two proposals could be combined. The NSLP
that does not use the NTLP
soft state management concpet could provide its own by using NSLP refresh
messages.

Best regards,
Georgios