RE: [NSIS] state management and the nsis framework

"Freytsis, Ilya" <ifreytsis@Cetacean.com> Tue, 13 May 2003 15:44 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 LAA17399 for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 11:44:44 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DFAm802243 for nsis-archive@odin.ietf.org; Tue, 13 May 2003 11:10:48 -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 h4DFA7B02174; Tue, 13 May 2003 11:10:07 -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 h4DF9DB02102 for <nsis@optimus.ietf.org>; Tue, 13 May 2003 11:09:13 -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 LAA17267 for <nsis@ietf.org>; Tue, 13 May 2003 11:42:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FbxC-0005B7-00 for nsis@ietf.org; Tue, 13 May 2003 11:44:34 -0400
Received: from [63.127.199.195] (helo=arb-exchange1.cetaceannetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19FbxC-0005B4-00 for nsis@ietf.org; Tue, 13 May 2003 11:44:34 -0400
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <KMZM1KYW>; Tue, 13 May 2003 11:47:35 -0400
Message-ID: <6D8664171C38D511B5AD0002B325CE660157224B@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@Cetacean.com>
To: 'Georgios Karagiannis' <karagian@cs.utwente.nl>, louise.burness@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 11:47:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="windows-1251"
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, Georgios.

I agree with Robert that the there is no difference in terms of the overall
functionality seen by the NSLP user. At the same time the functionality
split between layers that you suggest is enforcing much closer integration
between them. I do not agree with your expectation in respect to the network
load benefits (the efficient implementation will do just as good; at the end
the amount of the state information to be maintained is the same) and fail
to see any other advantages of this approach. Only complications.

Regards,
Ilya Freytsis 

 -----Original Message-----
From: 	Georgios Karagiannis [mailto:karagian@cs.utwente.nl] 
Sent:	Tuesday, May 13, 2003 10:51 AM
To:	louise.burness@bt.com
Cc:	nsis@ietf.org
Subject:	Re: [NSIS] state management and the nsis framework

Hi Louise

One of the issues with the two layer split is that two types of states have
to be maintained:
NTLP states and NSLP states.
The NTLP states are associated with transport features, while the NSLP
states
are associated with signaling application features.

One way of providing soft state management is by specifying completely
independent soft state management procedures for the NTLP and NSLP layers.
This means that NTLP will have to use its own NTLP refresh messages and each
NSLP protocol
that is using the NTLP layer will also have to use its own refresh messages.
This will create an unnecessary load on the network.

The other way of providing soft state management is to only use the refresh
messages
belonging to one of the protocol levels (NTLP or NSLP). In this way the load
on the
network can be severely reduced.

Best regards,
Georgios



----- Original Message -----
From: <louise.burness@bt.com>
To: <karagian@cs.utwente.nl>; <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
Sent: Tuesday, May 13, 2003 4:02 PM
Subject: RE: [NSIS] state management and the nsis framework


> 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
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis