RE: [NSIS] state management and the nsis framework

louise.burness@bt.com Tue, 13 May 2003 14:10 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13506 for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 10:10:03 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DDa7q24927 for nsis-archive@odin.ietf.org; Tue, 13 May 2003 09:36:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDZvB24797; Tue, 13 May 2003 09:35:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DDR3B24170 for <nsis@optimus.ietf.org>; Tue, 13 May 2003 09:27:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12434 for <nsis@ietf.org>; Tue, 13 May 2003 10:00:29 -0400 (EDT)
From: louise.burness@bt.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FaMM-0004BX-00 for nsis@ietf.org; Tue, 13 May 2003 10:02:26 -0400
Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19FaMM-0004BT-00 for nsis@ietf.org; Tue, 13 May 2003 10:02:26 -0400
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id <KC2KP1HC>; Tue, 13 May 2003 15:03:06 +0100
Message-ID: <ADEC16A81CFF17489F5A2A9E1D2226DE8DCDCA@i2km41-ukdy.nat.bt.com>
To: karagian@cs.utwente.nl, robert.hancock@roke.co.uk
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 15:02:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
content-class: urn:content-classes:message
Content-Type: text/plain; charset="iso-8859-1"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>

Hi

What is the actual benefit of mixing the two protocols like this? Generally,
its best to keep the interface and meaning between the two elements as
simple as possible? Efficincy gains must be minimal? Is it guarenteed that
beacuse the NTLP/ transport is still alive  the NSLP still is?

Louise

-----Original Message-----
From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 13 May 2003 14:22
To: Hancock, Robert
Cc: nsis@ietf.org
Subject: Re: [NSIS] state management and the nsis framework


Hi Robert

[reh]
> > 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"
>

[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


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis