Re: [NSIS] state management and the nsis framework

["Georgios Karagiannis" <[e-mail]>]

Hi Ilya
I agree that there is no difference in terms of the overall
functionality seen by the NSLP user. However, it will be a difference
on the specifications of the NTLP and NSLP protocols.
By load on the network I am refering to the number of refresh messages
that have to be sent and processed by a NSLP/NTLP aware node
in order to support one signaling application.
Thus I am not refering to the numebr of states that will have to be created
within a node.

Best regards,
Georgios


----- Original Message -----
From: "Freytsis, Ilya" <[e-mail]>
To: "'Georgios Karagiannis'" <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, May 13, 2003 5:47 PM
Subject: RE: [NSIS] state management and the nsis framework


> 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:[e-mail]]
> Sent: Tuesday, May 13, 2003 10:51 AM
> To: [e-mail]
> Cc: [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> 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:[e-mail]]
> > Sent: 13 May 2003 14:22
> > To: Hancock, Robert
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
>

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis