From mailnull@www1.ietf.org  Tue May  6 03:42:17 2003
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 DAA10805
	for <nsis-archive@odin.ietf.org>; Tue, 6 May 2003 03:42:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h467odh24309
	for nsis-archive@odin.ietf.org; Tue, 6 May 2003 03:50:39 -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 h467oW824267;
	Tue, 6 May 2003 03:50:32 -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 h467ii823932
	for <nsis@optimus.ietf.org>; Tue, 6 May 2003 03:44:44 -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 DAA10609
	for <nsis@ietf.org>; Tue, 6 May 2003 03:35:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Cx1C-0003zq-00
	for nsis@ietf.org; Tue, 06 May 2003 03:37:42 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Cx16-0003z1-00
	for nsis@ietf.org; Tue, 06 May 2003 03:37:36 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h467b5Yp004094;
	Tue, 6 May 2003 09:37:05 +0200 (MET DST)
Message-ID: <001e01c313a2$4bdab540$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: <john.loughney@nokia.com>
Cc: <nsis@ietf.org>
Date: Tue, 6 May 2003 09:37:07 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001B_01C313B3.0F46FC90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Subject: [NSIS] regarding NTLP protocol design considerations work
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>

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C313B3.0F46FC90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi John

Could you please inform about the status of the
NTLP protocol design considerations work?

I am actually very much interested in contributing=20
to this work!

Best Regards,
Georgios

------=_NextPart_000_001B_01C313B3.0F46FC90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3502.5390" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi John</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Could you please inform about the =
status of=20
the</FONT></DIV>
<DIV>NTLP protocol design considerations work?</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am actually very much interested in contributing </DIV>
<DIV>to this work!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best Regards,</DIV>
<DIV>Georgios</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_001B_01C313B3.0F46FC90--

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



From mailnull@www1.ietf.org  Wed May  7 03:57:13 2003
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 DAA19861
	for <nsis-archive@odin.ietf.org>; Wed, 7 May 2003 03:57:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h47866822383
	for nsis-archive@odin.ietf.org; Wed, 7 May 2003 04:06:06 -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 h47861822376;
	Wed, 7 May 2003 04:06:01 -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 h4784T822293
	for <nsis@optimus.ietf.org>; Wed, 7 May 2003 04:04:29 -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 DAA19818
	for <nsis@ietf.org>; Wed, 7 May 2003 03:55:06 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19DJnb-0006Hl-00
	for nsis@ietf.org; Wed, 07 May 2003 03:57:11 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19DJnb-0006Hh-00
	for nsis@ietf.org; Wed, 07 May 2003 03:57:11 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h477w1703928
	for <nsis@ietf.org>; Wed, 7 May 2003 10:58:02 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T620eae068fac158f25bc9@esvir05nok.ntc.nokia.com>;
 Wed, 7 May 2003 10:58:00 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 7 May 2003 10:58:00 +0300
Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 7 May 2003 10:58:00 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 7 May 2003 10:57:59 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 7 May 2003 10:57:58 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB320636231945@esebe023.ntc.nokia.com>
Thread-Topic: regarding NTLP protocol design considerations work
Thread-Index: AcMTo62cpzHJh/iTTTasEgnllm6ZKgAypkZg
To: <karagian@cs.utwente.nl>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 07 May 2003 07:58:00.0038 (UTC) FILETIME=[60DA4060:01C3146E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4784U822294
Subject: [NSIS] RE: regarding NTLP protocol design considerations work
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>
Content-Transfer-Encoding: 8bit

Hi Georgios,

Henning & Melinda are working on the draft, I hope they have something for the WG to review 
in advance of the next IETF.

thanks,
John

-----Original Message-----
From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 06 May, 2003 10:37
To: Loughney John (NRC/Helsinki)
Cc: nsis@ietf.org
Subject: regarding NTLP protocol design considerations work


Hi John

Could you please inform about the status of the
NTLP protocol design considerations work?

I am actually very much interested in contributing 
to this work!

Best Regards,
Georgios
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Thu May  8 08:16:15 2003
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 IAA20726
	for <nsis-archive@odin.ietf.org>; Thu, 8 May 2003 08:16:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h48CPgo06443
	for nsis-archive@odin.ietf.org; Thu, 8 May 2003 08:25:42 -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 h48CPX806436;
	Thu, 8 May 2003 08:25:33 -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 h48COe806386
	for <nsis@optimus.ietf.org>; Thu, 8 May 2003 08:24:40 -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 IAA20689
	for <nsis@ietf.org>; Thu, 8 May 2003 08:14:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19DkKL-0002WA-00
	for nsis@ietf.org; Thu, 08 May 2003 08:16:45 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19DkKL-0002W1-00
	for nsis@ietf.org; Thu, 08 May 2003 08:16:45 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1Y93P>; Thu, 8 May 2003 13:17:04 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA98E@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Date: Thu, 8 May 2003 13:17:01 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] state management and the nsis framework
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>

dear colleagues,

after some discussion about layer split issues and 'state management', i have attempted to put together some text of a proposal. I think this addresses most of the concerns expressed either on the mailing list or directly (to me). 

please let me know if it seems to be wrong/meaningless/unclear/disagreeable for any other reason. for now, I would like to use it as a working assumption.

cheers,

robert h.

===================================================================
[probably to go somewhere in section 3.2]
State Management (and the Layer Split)

Internet signalling requires the existence and management of state within the network for several reasons, ranging from state specific to signalling applications (e.g. buffer space allocations on interfaces or firewall pinhole status) to state needed to support signalling message transport (e.g. who is the peer to forward upstream signalling messages to). This section describes how state management functionality is split across the NSIS layers.

0. How the NTLP internal state is managed is a matter for its design and indeed implementation.

1. Conceptually, the NTLP provides a uniform message delivery service to signalling applications. It is unaware of the difference in state semantics between different types of signalling application message (e.g. whether a message changes or just refreshes signalling application state, or even has nothing to with signalling application state at all).

2. An NTLP instance in a node processes and if necessary forwards all signalling application messages "immediately". (It might offer different service classes, but these would be distinguished e.g. by reliability or priority, not signalling application state aspects.) Observable consequences of this are that the NTLP does not contain explicit timer or message sequence information related to the signalling application; and that signalling application messages pass immediately through an NSLP-unaware node (they can't be jittered there, or re-sent onto alternative paths if re-routing takes place later).

3. Within any node, it's an implementation decision whether to generate/jitter/filter refreshes either separately within each signalling application that needs this functionality, or as part of generic/shared code (a "soft-state management toolbox") more closely associated with the NTLP. The choice doesn't affect the NTLP specification at all. Implementations might piggy-back NTLP soft-state refreshe information (if the NTLP works this way) on signalling application messages, or even combine soft-state management between layers.

4. It may be helpful for signalling applications to receive state-management related 'triggers' from the NTLP, that a peer has failed or become available ("down/up notifications"). These triggers would be about adjacent NTLP peers, rather than signalling application peers. We can consider this as another case of route change detection/notification (which the NTLP is also supposed to do anyway).

4a. It is an open issue (i.e. we need to think more about) how sophisticated to make the definition of what triggers the NSLP would like; for example, should 'down' mean 'any loss of contact' or 'loss of contact for more than X seconds' and so on. Probably, we should err on the side of simplicity, and also require that the meaning of the trigger should not depend on how the NTLP generates it (which could be some lower layer connection reset, or loss of some number of NTLP-internal refreshes, or some other external source).

5. The existence of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the signalling application level. In this sense, up/down notifications are advisories which allow faster reaction to events in the network, but shouldn't be built into NSLP semantics. (This is essentially the same distinction - with the same rationale - as SNMP makes between traps and normal messages.)

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



From mailnull@www1.ietf.org  Fri May  9 04:13:47 2003
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 EAA08868
	for <nsis-archive@odin.ietf.org>; Fri, 9 May 2003 04:13:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h498Ncl13917
	for nsis-archive@odin.ietf.org; Fri, 9 May 2003 04:23:38 -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 h498NU813902;
	Fri, 9 May 2003 04:23:30 -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 h498Ka813685
	for <nsis@optimus.ietf.org>; Fri, 9 May 2003 04:20:36 -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 EAA08714
	for <nsis@ietf.org>; Fri, 9 May 2003 04:10:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19E2zJ-0002V9-00
	for nsis@ietf.org; Fri, 09 May 2003 04:12:17 -0400
Received: from infres.enst.fr ([137.194.192.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19E2zI-0002V2-00
	for nsis@ietf.org; Fri, 09 May 2003 04:12:16 -0400
Received: from luu (dhcp7-211.enst.fr [137.194.7.211])
	by infres.enst.fr (Postfix) with SMTP
	id A5EC11950; Fri,  9 May 2003 10:13:09 +0200 (MEST)
Message-ID: <004901c31602$7f69ed60$d307c289@enst.fr>
From: "Thanh Tra LUU" <luu@enst.fr>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>, <nsis@ietf.org>
References: <76C92FBBFB58D411AE760090271ED4181EA98E@rsys002a.roke.co.uk>
Subject: Re: [NSIS] state management and the nsis framework
Date: Fri, 9 May 2003 10:10:45 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit


Hello Robert,

Please watch my oppion in the text.


> Internet signalling requires the existence and management of state within
the network for several reasons, ranging from state specific to signalling
applications (e.g. buffer space allocations on interfaces or firewall
pinhole status) to state needed to support signalling message transport
(e.g. who is the peer to forward upstream signalling messages to). This
section describes how state management functionality is split across the
NSIS layers.
>
> 0. How the NTLP internal state is managed is a matter for its design and
indeed implementation.
>

ok, I hope that the internal states can support almost all potential
signaling applications.


> 1. Conceptually, the NTLP provides a uniform message delivery service to
signalling applications. It is unaware of the difference in state semantics
between different types of signalling application message (e.g. whether a
message changes or just refreshes signalling application state, or even has
nothing to with signalling application state at all).
>

ok. NSLP will use the message and control all of the state of signaling
application. It means that if
NSLP want to send a message refresh, it must asks NTLP to do it. But I think
that NTLP can support something automatic and repeated (as the soft-state
management toolbox)  (3) , eg : NSLP ask NTLP : during T1(ms) please send
the refresh message every K(ms), if there is an error, send a notification.


> 2. An NTLP instance in a node processes and if necessary forwards all
signalling application messages "immediately". (It might offer different
service classes, but these would be distinguished e.g. by reliability or
priority, not signalling application state aspects.) Observable consequences
of this are that the NTLP does not contain explicit timer or message
sequence information related to the signalling application; and that
signalling application messages pass immediately through an NSLP-unaware
node (they can't be jittered there, or re-sent onto alternative paths if
re-routing takes place later).
>

ok. it's great, especially for path-decoupled signaling and the
signaling is more flexible in a heterogenous environment . I think about a
field which can tell NTLP continue processing or forwarding the message when
NTLP examine the header of  the message.





> 3. Within any node, it's an implementation decision whether to
generate/jitter/filter refreshes either separately within each signalling
application that needs this functionality, or as part of generic/shared code
(a "soft-state management toolbox") more closely associated with the NTLP.
The choice doesn't affect the NTLP specification at all. Implementations
might piggy-back NTLP soft-state refreshe information (if the NTLP works
this way) on signalling application messages, or even combine soft-state
management between layers.
>

I'm very interested in soft-state management toolbox of NTLP et how NSLP
uses it to manage the states of signaling application. This party is clear.


> 4. It may be helpful for signalling applications to receive
state-management related 'triggers' from the NTLP, that a peer has failed or
become available ("down/up notifications"). These triggers would be about
adjacent NTLP peers, rather than signalling application peers. We can
consider this as another case of route change detection/notification (which
the NTLP is also supposed to do anyway).
>

ok, Can we call them common triggers for all NSLPs ?  eg : if NTLP see that
the routing table is changed, it will notify its NSLP and adjacent NTLP.


> 4a. It is an open issue (i.e. we need to think more about) how
sophisticated to make the definition of what triggers the NSLP would like;
for example, should 'down' mean 'any loss of contact' or 'loss of contact
for more than X seconds' and so on. Probably, we should err on the side of
simplicity, and also require that the meaning of the trigger should not
depend on how the NTLP generates it (which could be some lower layer
connection reset, or loss of some number of NTLP-internal refreshes, or some
other external source).
>

ok, I think it depends on each particular signaling application. For exemple
: 'down' should mean
    + any loss of contact
    + loss of contact for more than X seconds or after resending X times a
message.
    + receive a notification of error from NTLP or from some other
application, other entities...

> 5. The existence of these triggers doesn't replace NSLP refreshes as the
mechanism for maintaining liveness at the signalling application level. In
this sense, up/down notifications are advisories which allow faster reaction
to events in the network, but shouldn't be built into NSLP semantics. (This
is essentially the same distinction - with the same rationale - as SNMP
makes between traps and normal messages.)
>

I think something are not clear. You mean the error triggers and the normal
operation  of soft-state management. I don't understand the reason why you
talk about the replacement of error triggers and normal operation.

Nary Tra

PhD student
ENST, Paris
Tel: (0033) (0) 1 45 81 71 06.


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



From mailnull@www1.ietf.org  Fri May  9 12:58:04 2003
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 MAA23079
	for <nsis-archive@odin.ietf.org>; Fri, 9 May 2003 12:58:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h49H85U26077
	for nsis-archive@odin.ietf.org; Fri, 9 May 2003 13:08:05 -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 h49H7e825984;
	Fri, 9 May 2003 13:07:40 -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 h49H6m825139
	for <nsis@optimus.ietf.org>; Fri, 9 May 2003 13:06:48 -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 MAA22953
	for <nsis@ietf.org>; Fri, 9 May 2003 12:56:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19EBCM-0005q5-00
	for nsis@ietf.org; Fri, 09 May 2003 12:58:18 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19EBCL-0005po-00
	for nsis@ietf.org; Fri, 09 May 2003 12:58:17 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZA0N>; Fri, 9 May 2003 17:58:33 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA998@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Fri, 9 May 2003 17:58:32 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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,

[snip]

> ok. NSLP will use the message and control all of the state of 
> signaling
> application. It means that if
> NSLP want to send a message refresh, it must asks NTLP to do 
> it. But I think
> that NTLP can support something automatic and repeated (as 
> the soft-state
> management toolbox)  (3) , eg : NSLP ask NTLP : during T1(ms) 
> please send
> the refresh message every K(ms), if there is an error, send a 
> notification.

my view is that this is an implementation issue, and hence not relevant to the specification of the NTLP. (i am trying to keep the framework focussed on protocol rather than service definitions.) if the software implementing specifically the NSLP generates these things internally, nothing is changed in protocol operation.
 
> > 4. It may be helpful for signalling applications to receive
> state-management related 'triggers' from the NTLP, that a 
> peer has failed or
> become available ("down/up notifications"). These triggers 
> would be about
> adjacent NTLP peers, rather than signalling application peers. We can
> consider this as another case of route change 
> detection/notification (which
> the NTLP is also supposed to do anyway).
> >
> 
> ok, Can we call them common triggers for all NSLPs ?  eg : if 
> NTLP see that
> the routing table is changed, it will notify its NSLP and 
> adjacent NTLP.

there is still some openness here about who gets to see the triggers (are they sent to adjacent nodes or not). but this is the basic idea.

> > 4a. It is an open issue (i.e. we need to think more about) how
> sophisticated to make the definition of what triggers the 
> NSLP would like;
> for example, should 'down' mean 'any loss of contact' or 
> 'loss of contact
> for more than X seconds' and so on. Probably, we should err 
> on the side of
> simplicity, and also require that the meaning of the trigger 
> should not
> depend on how the NTLP generates it (which could be some lower layer
> connection reset, or loss of some number of NTLP-internal 
> refreshes, or some
> other external source).
> >
> 
> ok, I think it depends on each particular signaling 
> application. For exemple
> : 'down' should mean
>     + any loss of contact
>     + loss of contact for more than X seconds or after 
> resending X times a
> message.
>     + receive a notification of error from NTLP or from some other
> application, other entities...

i would prefer to think of these as independent of signalling application. (this is at least partly also an implementation issue anyway.)

> 
> > 5. The existence of these triggers doesn't replace NSLP 
> refreshes as the
> mechanism for maintaining liveness at the signalling 
> application level. In
> this sense, up/down notifications are advisories which allow 
> faster reaction
> to events in the network, but shouldn't be built into NSLP 
> semantics. (This
> is essentially the same distinction - with the same rationale 
> - as SNMP
> makes between traps and normal messages.)
> >
> 
> I think something are not clear. You mean the error triggers 
> and the normal
> operation  of soft-state management. I don't understand the 
> reason why you
> talk about the replacement of error triggers and normal operation.

OK: the point I am trying to make is that an NSLP should not be written saying (for example) "Install state with a xxx-Create message and then you know it is always present unless you receive a notification from the lower (NTLP) layer." Another way of saying this: we don't ask the NTLP to provide the environment in which it is trivial to provide a hard-state NSLP (i.e. by guaranteeing to detect and report remote error conditions). I'm well open to better text explaining this if anyone has some.

> 
> Nary Tra
> 
> PhD student
> ENST, Paris
> Tel: (0033) (0) 1 45 81 71 06.
> 

hope this helps,

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



From mailnull@www1.ietf.org  Fri May  9 14:31:27 2003
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 OAA26351
	for <nsis-archive@odin.ietf.org>; Fri, 9 May 2003 14:31:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h49IfVk01500
	for nsis-archive@odin.ietf.org; Fri, 9 May 2003 14:41:31 -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 h49IfP801488;
	Fri, 9 May 2003 14:41:25 -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 h49Iee801392
	for <nsis@optimus.ietf.org>; Fri, 9 May 2003 14:40:40 -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 OAA26258
	for <nsis@ietf.org>; Fri, 9 May 2003 14:30:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ECfA-0006VI-00
	for nsis@ietf.org; Fri, 09 May 2003 14:32:08 -0400
Received: from infres.enst.fr ([137.194.192.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ECf9-0006VC-00
	for nsis@ietf.org; Fri, 09 May 2003 14:32:07 -0400
Received: from luu (dhcp7-211.enst.fr [137.194.7.211])
	by infres.enst.fr (Postfix) with SMTP id F02FA18AA
	for <nsis@ietf.org>; Fri,  9 May 2003 20:33:03 +0200 (MEST)
Message-ID: <000e01c31659$834455e0$d307c289@enst.fr>
From: "Thanh Tra LUU" <luu@enst.fr>
To: <nsis@ietf.org>
Date: Fri, 9 May 2003 20:33:40 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C3166A.469ACB40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Subject: [NSIS] Proxies in NSIS
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>

C'est un message de format MIME en plusieurs parties.

------=_NextPart_000_000B_01C3166A.469ACB40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

I have something not very clear about the proxy in the framework 2 of =
NSIS. I don't know how the sender can communnicate with proxy ( =
protocol, interface, authorization...?) when sender is not a NSIS-aware =
. It is possible that the proxies is not on the first router connecting =
the sender to network ?=20

Thanks,


Nary Tra,
ENST, Paris.
Tel: (0033) (0) 1 45 81 71 06

------=_NextPart_000_000B_01C3166A.469ACB40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello everyone,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have something not very clear about =
the proxy in=20
the framework 2 of NSIS. I don't know how the sender can =
communnicate&nbsp;with=20
proxy ( protocol, interface, authorization...?) when sender is not a =
NSIS-aware=20
. It is possible that the proxies is not on the first router connecting =
the=20
sender to network ? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Nary Tra,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>ENST, Paris.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Tel: (0033) (0) 1 45 81 71=20
06</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C3166A.469ACB40--

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



From mailnull@www1.ietf.org  Sun May 11 22:17:52 2003
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 WAA17470
	for <nsis-archive@odin.ietf.org>; Sun, 11 May 2003 22:17:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4C1hAp02632
	for nsis-archive@odin.ietf.org; Sun, 11 May 2003 21:43:10 -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 h4C1gvB02623;
	Sun, 11 May 2003 21:42: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 h4C1fDB02564
	for <nsis@optimus.ietf.org>; Sun, 11 May 2003 21:41: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 WAA17425
	for <nsis@ietf.org>; Sun, 11 May 2003 22:15:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19F2sU-00043n-00
	for nsis@ietf.org; Sun, 11 May 2003 22:17:22 -0400
Received: from [63.127.199.195] (helo=arb-exchange1.cetaceannetworks.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19F2sT-00043k-00
	for nsis@ietf.org; Sun, 11 May 2003 22:17:21 -0400
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <KMZM1230>; Sun, 11 May 2003 22:20:15 -0400
Message-ID: <6D8664171C38D511B5AD0002B325CE660157223B@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@Cetacean.com>
To: "'Thanh Tra LUU'" <luu@enst.fr>, nsis@ietf.org
Subject: RE: [NSIS] Proxies in NSIS
Date: Sun, 11 May 2003 22:20:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3182D.06418CE0"
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3182D.06418CE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi, Nary.
 
There are two concepts of NSIS proxies discussed in the framework:
1.	So called "on path" proxies that are somewhat similar to the concept
of RSVP proxy (see
http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt
<http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt> )
2.	Proxies for signaling applications that require/use some off-path
processing facilities
 
It is important to note that in either case the communication between the
NSIS unaware hosts (1) or off-path application facility (2) and NSIS proxy
is outside of the NSIS itself. Probably it is reasonable to expect that the
first NE along data path where the flow enters the NSIS domain will act as
an NSIS proxy. This NE is not necessarily the first router connecting the
sender to the network though.
 
Best regards,
Ilya Freytsis
 
-----Original Message-----
From: Thanh Tra LUU [mailto:luu@enst.fr]
Sent: Friday, May 09, 2003 2:34 PM
To: nsis@ietf.org
Subject: [NSIS] Proxies in NSIS
 
Hello everyone,
 
I have something not very clear about the proxy in the framework 2 of NSIS.
I don't know how the sender can communnicate with proxy ( protocol,
interface, authorization...?) when sender is not a NSIS-aware . It is
possible that the proxies is not on the first router connecting the sender
to network ? 
 
Thanks,
 
 
Nary Tra,
ENST, Paris.
Tel: (0033) (0) 1 45 81 71 06

------_=_NextPart_001_01C3182D.06418CE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C3180A.AEE2BAE0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:243145407;
	mso-list-type:hybrid;
	mso-list-template-ids:1006415252 1581021738 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
@list l1
	{mso-list-id:1255744693;
	mso-list-type:hybrid;
	mso-list-template-ids:-1317470730 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>H=
i, Nary.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
here are two
concepts of NSIS proxies discussed in the =
framework:<o:p></o:p></span></font></span></p>

<ol style=3D'mso-margin-top-alt:0in' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l1 level1 =
lfo2;tab-stops:list .5in'><span
     class=3DEmailStyle15><font size=3D2 color=3Dnavy =
face=3DArial><span
     =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>S=
o
     called &#8220;on path&#8221; proxies that are somewhat similar to =
the concept of RSVP
     proxy (see <a
     =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt=
">http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-03.txt</a>)<=
o:p></o:p></span></font></span></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l1 level1 =
lfo2;tab-stops:list .5in'><span
     class=3DEmailStyle15><font size=3D2 color=3Dnavy =
face=3DArial><span
     =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>P=
roxies
     for signaling applications that require/use some off-path =
processing
     facilities<o:p></o:p></span></font></span></li>
</ol>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
t is
important to note that in either case the communication between the =
NSIS
unaware hosts (1) or off-path application facility (2) and NSIS proxy =
is
outside of the NSIS itself. Probably it is reasonable to expect that =
the first
NE along data path where the flow enters the NSIS domain will act as an =
NSIS
proxy. This NE is not necessarily the first router connecting the =
sender to the
network though.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>B=
est
regards,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
lya
Freytsis<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Thanh Tra LUU
[mailto:luu@enst.fr]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, May 09, =
2003 2:34 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> nsis@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [NSIS] Proxies =
in NSIS</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Hello
everyone,</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>I have
something not very clear about the proxy in the framework 2 of NSIS. I =
don't
know how the sender can communnicate&nbsp;with proxy ( protocol, =
interface,
authorization...?) when sender is not a NSIS-aware . It is possible =
that the
proxies is not on the first router connecting the sender to network ? =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Thanks,</span><=
/font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Nary
Tra,</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>ENST,
Paris.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Tel:
(0033) (0) 1 45 81 71 06</span></font><font color=3Dblack><span =
style=3D'color:
black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C3182D.06418CE0--
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Mon May 12 03:46:01 2003
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 DAA04439
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 03:46:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4C7BQK01890
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 03:11:26 -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 h4C7BLB01878;
	Mon, 12 May 2003 03:11:21 -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 h4C7ADB01835
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 03:10: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 DAA04415
	for <nsis@ietf.org>; Mon, 12 May 2003 03:44:18 -0400 (EDT)
From: maarten.buchli@alcatel.be
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19F80m-0005qH-00
	for nsis@ietf.org; Mon, 12 May 2003 03:46:16 -0400
Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be)
	by ietf-mx with esmtp (Exim 4.12)
	id 19F80l-0005pU-00
	for nsis@ietf.org; Mon, 12 May 2003 03:46:15 -0400
Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16])
	by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h4C7khLt009259
	for <nsis@ietf.org>; Mon, 12 May 2003 09:46:43 +0200 (MEST)
Subject: RE: [NSIS] state management and the nsis framework
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: nsis@ietf.org
Date: Mon, 12 May 2003 09:46:41 +0200
Message-ID: <OF639EFC1D.703751D8-ONC1256D24.00292FCD@net.alcatel.be>
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 05/12/2003 09:46:42
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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 Robert,

See inline.

Regards.
Maarten





"Hancock, Robert" <robert.hancock@roke.co.uk>@ietf.org on 09/05/2003
18:58:32

Sent by:    nsis-admin@ietf.org


To:    nsis@ietf.org
cc:
Subject:    RE: [NSIS] state management and the nsis framework


hi,

[snip]


>
> > 5. The existence of these triggers doesn't replace NSLP
> refreshes as the
> mechanism for maintaining liveness at the signalling
> application level. In
> this sense, up/down notifications are advisories which allow
> faster reaction
> to events in the network, but shouldn't be built into NSLP
> semantics. (This
> is essentially the same distinction - with the same rationale
> - as SNMP
> makes between traps and normal messages.)
> >
>
> I think something are not clear. You mean the error triggers
> and the normal
> operation  of soft-state management. I don't understand the
> reason why you
> talk about the replacement of error triggers and normal operation.

OK: the point I am trying to make is that an NSLP should not be written
saying (for example) "Install state with a xxx-Create message and then you
know it is always present unless you receive a notification from the lower
(NTLP) layer." Another way of saying this: we don't ask the NTLP to provide
the environment in which it is trivial to provide a hard-state NSLP (i.e.
by guaranteeing to detect and report remote error conditions). I'm well
open to better text explaining this if anyone has some.

[MB] How does this relate to the softstate toolbox that you've mentioned?
That toolbox may be more closely associated with the NTLP such that the
soft state management does not have to be implemented in each application.
In that case the softstate of both layers can be combined and the NTLP will
trigger the NSLP in case the of a timeout of the refresh timer. Hence, in
that case the NSLP can rely on triggers (one of the triggers being 'soft
state timeout') from the NTLP only.

So, this would allow for a hard state NSLP specification but will require
the NTLP to manage soft state. Since the soft state management is a generic
functionality it seems to make sense to include it in the NTLP.

What do you think?



_______________________________________________
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



From mailnull@www1.ietf.org  Mon May 12 04:37:03 2003
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 EAA05346
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 04:37:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4C82Tp05245
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 04:02:29 -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 h4C82HB05231;
	Mon, 12 May 2003 04:02:17 -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 h4C81SB04913
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 04:01:28 -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 EAA05333
	for <nsis@ietf.org>; Mon, 12 May 2003 04:35:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19F8oL-00063G-00
	for nsis@ietf.org; Mon, 12 May 2003 04:37:29 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19F8oL-000638-00
	for nsis@ietf.org; Mon, 12 May 2003 04:37:29 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZDFP>; Mon, 12 May 2003 09:38:00 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA999@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Mon, 12 May 2003 09:37:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 maarten,

> > > 5. The existence of these triggers doesn't replace NSLP
> > refreshes as the
> > mechanism for maintaining liveness at the signalling
> > application level. In
> > this sense, up/down notifications are advisories which allow
> > faster reaction
> > to events in the network, but shouldn't be built into NSLP
> > semantics. (This
> > is essentially the same distinction - with the same rationale
> > - as SNMP
> > makes between traps and normal messages.)
> > >
> >
> > I think something are not clear. You mean the error triggers
> > and the normal
> > operation  of soft-state management. I don't understand the
> > reason why you
> > talk about the replacement of error triggers and normal operation.
> 
> OK: the point I am trying to make is that an NSLP should not 
> be written
> saying (for example) "Install state with a xxx-Create message 
> and then you
> know it is always present unless you receive a notification 
> from the lower
> (NTLP) layer." Another way of saying this: we don't ask the 
> NTLP to provide
> the environment in which it is trivial to provide a 
> hard-state NSLP (i.e.
> by guaranteeing to detect and report remote error 
> conditions). I'm well
> open to better text explaining this if anyone has some.
> 
> [MB] How does this relate to the softstate toolbox that 
> you've mentioned?
> That toolbox may be more closely associated with the NTLP 
> such that the
> soft state management does not have to be implemented in each 
> application.
> In that case the softstate of both layers can be combined and 
> the NTLP will
> trigger the NSLP in case the of a timeout of the refresh 
> timer. Hence, in
> that case the NSLP can rely on triggers (one of the triggers 
> being 'soft
> state timeout') from the NTLP only.
> 
> So, this would allow for a hard state NSLP specification but 
> will require
> the NTLP to manage soft state. Since the soft state 
> management is a generic
> functionality it seems to make sense to include it in the NTLP.
> 
> What do you think?

I don't disagree with any of this as an engineering approach. However, there is a separate question about what needs to be fixed in a standard:

1. If we believe that the 'soft state management service' should be a universal thing, then we need to define exactly what it is. This seems to be a hard thing to do for two reasons:
a. we can't anticipate the varied needs of all the possible future signalling applications, and we might end up with something needlessly complex;
b. the state management visible to signalling applications will be the joint result of several NTLP hops, so its behaviour is even harder to define.

2. In any case, apart from saying 'state management within a node could be common to all applications or specific to each', there doesn't seem to be any need to standardise anything concrete about it - the necessary implementation freedom isn't ruled out by making the NTLP 'thin', because there doesn't seem any need to have common implementation approaches between two signalling application-aware peers.
[Basically, all the comments I have seen about this are about how functionality should be arranged inside a node, not about what functionality is needed in the 'NTLP-on-the-wire' to support it.]

Cheers,

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



From mailnull@www1.ietf.org  Mon May 12 05:55:55 2003
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 FAA06654
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 05:55:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4C9LNR11241
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 05:21:23 -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 h4C9LHB11227;
	Mon, 12 May 2003 05:21:17 -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 h4C9K5B11186
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 05:20:05 -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 FAA06645
	for <nsis@ietf.org>; Mon, 12 May 2003 05:54:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FA2P-0006SD-00
	for nsis@ietf.org; Mon, 12 May 2003 05:56:05 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FA2O-0006SA-00
	for nsis@ietf.org; Mon, 12 May 2003 05:56:04 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4C9v35s011839;
	Mon, 12 May 2003 11:57:03 +0200 (MET DST)
Message-ID: <009701c3186c$d7d745d0$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
References: <76C92FBBFB58D411AE760090271ED4181EA98E@rsys002a.roke.co.uk>
Subject: Re: [NSIS] state management and the nsis framework
Date: Mon, 12 May 2003 11:57:04 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Robert

Please receive my comments in line!

>> 1. Conceptually, the NTLP provides a uniform message delivery service to
signalling
>> applications. It is unaware of the difference in state semantics between
different types
>> of signalling application message (e.g. whether a message changes or just
refreshes signalling
>> application state, or even has nothing to with signalling application
state at all).

I agree with the statement that the NTLP provides a uniform message delivery
service to signalling
applications. However, the NTLP protocol should be used to initiate, refresh
and teardown a NTLP state.
Therefore different types of NTLP messages are neaded, i.e., to initiate a
NTLP state,
to refresh a NTLP state and to tear down a NTLP state.

>> 2. An NTLP instance in a node processes and if necessary forwards all
signalling application
>> messages "immediately". (It might offer different service classes, but
these would be distinguished
>> e.g. by reliability or priority, not signalling application state
aspects.) Observable consequences of
>> this are that the NTLP does not contain explicit timer or message
sequence information related to
>> the signalling application; and that signalling application messages pass
immediately through an
>> NSLP-unaware node (they can't be jittered there, or re-sent onto
alternative paths if re-routing takes place later).

Here I also agree with you on the fact that the NTLP does not contain
explicit timer or message
sequence information related to the signalling application. However, if the
NTLP needs this information to manage the
NTLP states then this information should be allowed.


>> 3. Within any node, it's an implementation decision whether to
generate/jitter/filter refreshes either
>> separately within each signalling application that needs this
functionality, or as part of generic/shared
>> code (a "soft-state management toolbox") more closely associated with the
NTLP. The choice doesn't
>> affect the NTLP specification at all. Implementations might piggy-back
NTLP soft-state refreshe
>> information (if the NTLP works this way) on signalling application
messages, or even combine
>> soft-state management between layers.

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. "


>> 4. It may be helpful for signalling applications to receive
state-management related 'triggers'
>> from the NTLP, that a peer has failed or become available ("down/up
notifications"). These triggers
>> would be about adjacent NTLP peers, rather than signalling application
peers. We can consider this
>> as another case of route change detection/notification (which the NTLP is
also supposed to do anyway).

What do you mean by saying that:
"These triggers
would be about adjacent NTLP peers, rather than signalling application
peers."

I think that the NTLP instance should also be able to trigger a NSLP
instance also for other reasons.

>> 5. The existence of these triggers doesn't replace NSLP refreshes as the
mechanism for maintaining
>> liveness at the signalling application level. In this sense, up/down
notifications are advisories which allow
>> faster reaction to events in the network, but shouldn't be built into
NSLP semantics. (This is essentially the
>> same distinction - with the same rationale - as SNMP makes between traps
and normal messages.)

Do you mean that the functionality described in my remark on your remark
(bullet) 3, above,
will not be possible?

Best Regards,
Georgios



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



From mailnull@www1.ietf.org  Mon May 12 07:51:01 2003
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 HAA09329
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 07:51:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4CBGXD19240
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 07:16:33 -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 h4CBGJB19226;
	Mon, 12 May 2003 07:16:19 -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 h4CBF7B19185
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 07:15:07 -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 HAA09286
	for <nsis@ietf.org>; Mon, 12 May 2003 07:49:05 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FBpg-00073v-00
	for nsis@ietf.org; Mon, 12 May 2003 07:51:04 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FBpf-00073l-00
	for nsis@ietf.org; Mon, 12 May 2003 07:51:03 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4CBq5728948
	for <nsis@ietf.org>; Mon, 12 May 2003 14:52:05 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6229441e49ac158f25121@esvir05nok.ntc.nokia.com>;
 Mon, 12 May 2003 14:52:05 +0300
Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 12 May 2003 14:52:04 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 12 May 2003 14:51:38 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] state management and the nsis framework
Date: Mon, 12 May 2003 14:51:38 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB3206360C1F24@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMYYvtoxlmoLpJES86EWwwLE6fuYAAGQWMA
To: <robert.hancock@roke.co.uk>, <nsis@ietf.org>
X-OriginalArrivalTime: 12 May 2003 11:51:38.0954 (UTC) FILETIME=[D8D7D2A0:01C3187C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CBFFB19190
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>
Content-Transfer-Encoding: 8bit

Hi Robert & Maarten,

> 2. In any case, apart from saying 'state management within a 
> node could be common to all applications or specific to 
> each', there doesn't seem to be any need to standardise 
> anything concrete about it - the necessary implementation 
> freedom isn't ruled out by making the NTLP 'thin', because 
> there doesn't seem any need to have common implementation 
> approaches between two signalling application-aware peers.
> [Basically, all the comments I have seen about this are about 
> how functionality should be arranged inside a node, not about 
> what functionality is needed in the 'NTLP-on-the-wire' to support it.]

Thinking more about this, how state is stored in a node seems
to be implementation specific.  I am not sure that we can 
standardize this, nor am I sure we want to.

What might be a larger question is, do we specify a basic state machine
in the NTLP document?  If we do, how does it relate to any state machines
or state needed by the protocols running on top of NTLP? 

Is it sufficient for NTLP to specify the grammer but not the management
of the state machine?

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



From mailnull@www1.ietf.org  Mon May 12 08:34:53 2003
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 IAA10238
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 08:34:53 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4CC0P222013
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 08:00:25 -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 h4CC0FB22006;
	Mon, 12 May 2003 08:00:15 -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 h4CBxsB21952
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 07:59:54 -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 IAA10199
	for <nsis@ietf.org>; Mon, 12 May 2003 08:33:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FCX0-0007KJ-00
	for nsis@ietf.org; Mon, 12 May 2003 08:35:50 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FCWz-0007KG-00
	for nsis@ietf.org; Mon, 12 May 2003 08:35:49 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZD5H>; Mon, 12 May 2003 13:36:20 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA99C@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Georgios Karagiannis'" <karagian@cs.utwente.nl>
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Mon, 12 May 2003 13:36:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 georgios,

and see my comments too...

[snip]
[GK:]
> I agree with the statement that the NTLP provides a uniform 
> message delivery
> service to signalling
> applications. However, the NTLP protocol should be used to 
> initiate, refresh
> and teardown a NTLP state.
> Therefore different types of NTLP messages are neaded, i.e., 
> to initiate a
> NTLP state,
> to refresh a NTLP state and to tear down a NTLP state.
> 
> Here I also agree with you on the fact that the NTLP does not contain
> explicit timer or message
> sequence information related to the signalling application. 
> However, if the
> NTLP needs this information to manage the
> NTLP states then this information should be allowed.

[reh] Neither of these are ruled out (both covered by the original 'Point 0', i.e. that what goes on inside the NTLP is up to it and its designers. From a framework perspective, I'm not very interested in this aspect (not that it isn't interesting in general, of course).
 
> >> 3. Within any node, it's an implementation decision whether to
> generate/jitter/filter refreshes either
> >> separately within each signalling application that needs this
> functionality, or as part of generic/shared
> >> code (a "soft-state management toolbox") more closely 
> associated with the
> NTLP. The choice doesn't
> >> affect the NTLP specification at all. Implementations 
> might piggy-back
> NTLP soft-state refreshe
> >> information (if the NTLP works this way) on signalling application
> messages, or even combine
> >> soft-state management between layers.
> 
> 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

> >> 4. It may be helpful for signalling applications to receive
> state-management related 'triggers'
> >> from the NTLP, that a peer has failed or become available ("down/up
> notifications"). These triggers
> >> would be about adjacent NTLP peers, rather than signalling 
> application
> peers. We can consider this
> >> as another case of route change detection/notification 
> (which the NTLP is
> also supposed to do anyway).
> 
> What do you mean by saying that:
> "These triggers
> would be about adjacent NTLP peers, rather than signalling application
> peers."
> 
> I think that the NTLP instance should also be able to trigger a NSLP
> instance also for other reasons.

[reh] this is about the framework section 3.2.1 picture (fig.5). in the picture here:

   NSLP                          NSLP

   NTLP------NTLP------NTLP------NTLP

  node 1    node 2    node 3    node 4

suppose node 3 detects a route change or that node 4 is 'dead'. who does it tell about that? does it tell only its NTLP peer (node 2) or attempt to ensure that the NSLP knows as well, i.e. node 1? and if the latter, where does it stop?

> 
> >> 5. The existence of these triggers doesn't replace NSLP 
> refreshes as the
> mechanism for maintaining
> >> liveness at the signalling application level. In this 
> sense, up/down
> notifications are advisories which allow
> >> faster reaction to events in the network, but shouldn't be 
> built into
> NSLP semantics. (This is essentially the
> >> same distinction - with the same rationale - as SNMP makes 
> between traps
> and normal messages.)
> 
> Do you mean that the functionality described in my remark on 
> your remark
> (bullet) 3, above,
> will not be possible?

[reh] functionality possible so far as i can tell.

> 
> Best Regards,
> Georgios
> 
> 
cheers,

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



From mailnull@www1.ietf.org  Mon May 12 08:45:45 2003
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 IAA10665
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 08:45:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4CCBI623455
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 08:11:18 -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 h4CCBCB23439;
	Mon, 12 May 2003 08:11:12 -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 h4CCA6B23388
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 08:10:06 -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 IAA10618
	for <nsis@ietf.org>; Mon, 12 May 2003 08:44:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FCgs-0007RU-00
	for nsis@ietf.org; Mon, 12 May 2003 08:46:02 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FCgr-0007RK-00
	for nsis@ietf.org; Mon, 12 May 2003 08:46:01 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZD6F>; Mon, 12 May 2003 13:46:33 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA99D@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Mon, 12 May 2003 13:46:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

john,

> 
> Hi Robert & Maarten,
> 
> > 2. In any case, apart from saying 'state management within a 
> > node could be common to all applications or specific to 
> > each', there doesn't seem to be any need to standardise 
> > anything concrete about it - the necessary implementation 
> > freedom isn't ruled out by making the NTLP 'thin', because 
> > there doesn't seem any need to have common implementation 
> > approaches between two signalling application-aware peers.
> > [Basically, all the comments I have seen about this are about 
> > how functionality should be arranged inside a node, not about 
> > what functionality is needed in the 'NTLP-on-the-wire' to 
> support it.]
> 
> Thinking more about this, how state is stored in a node seems
> to be implementation specific.  I am not sure that we can 
> standardize this, nor am I sure we want to.

I'm sure we could try to standardise it, but I think the end 
result would be meaningless. I'm pretty certain it would be a 
very bad idea to try.

> 
> What might be a larger question is, do we specify a basic 
> state machine
> in the NTLP document?  If we do, how does it relate to any 
> state machines
> or state needed by the protocols running on top of NTLP? 

I would say that is a matter of protocol specification taste, and
the answers may be different for different protocols (NTLP and NSLPs).

My taste is that state machines or equivalent are good ways at least
to describe protocols, and possibly also to define them, especially 
for non-trivial protocols (and I would claim the existence of 2209
in parallel with 2205 in support).

I think non-trivial interactions between state machine descriptions
of different protocols should be avoided at all costs, however. It should
be possible to read and understand an NSLP spec knowing nothing about
NSIS beyond the framework. 

> 
> Is it sufficient for NTLP to specify the grammer but not the 
> management
> of the state machine?

please clarify.

> 
> JOhn
> 

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



From mailnull@www1.ietf.org  Mon May 12 10:08:47 2003
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 KAA13313
	for <nsis-archive@odin.ietf.org>; Mon, 12 May 2003 10:08:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4CDYJa29256
	for nsis-archive@odin.ietf.org; Mon, 12 May 2003 09:34:19 -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 h4CDYDB29223;
	Mon, 12 May 2003 09:34:13 -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 h4CDXIB29155
	for <nsis@optimus.ietf.org>; Mon, 12 May 2003 09:33:18 -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 KAA13139
	for <nsis@ietf.org>; Mon, 12 May 2003 10:07:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FDzN-0000C8-00
	for nsis@ietf.org; Mon, 12 May 2003 10:09:13 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FDzM-0000C4-00
	for nsis@ietf.org; Mon, 12 May 2003 10:09:12 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4CEAB5s023198;
	Mon, 12 May 2003 16:10:12 +0200 (MET DST)
Message-ID: <012701c31890$351dab80$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
References: <76C92FBBFB58D411AE760090271ED4181EA99C@rsys002a.roke.co.uk>
Subject: Re: [NSIS] state management and the nsis framework
Date: Mon, 12 May 2003 16:10:13 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Robert

Please see the second version of my comments in line:

[GK:]
> I agree with the statement that the NTLP provides a uniform
> message delivery
> service to signalling
> applications. However, the NTLP protocol should be used to
> initiate, refresh
> and teardown a NTLP state.
> Therefore different types of NTLP messages are neaded, i.e.,
> to initiate a
> NTLP state,
> to refresh a NTLP state and to tear down a NTLP state.
>
> Here I also agree with you on the fact that the NTLP does not contain
> explicit timer or message
> sequence information related to the signalling application.
> However, if the
> NTLP needs this information to manage the
> NTLP states then this information should be allowed.

>> [reh]
>> Neither of these are ruled out (both covered by the original 'Point 0',
i.e. that what goes
>> on inside the NTLP is up to it and its designers. From a framework
perspective, I'm not very
>> interested in this aspect (not that it isn't interesting in general, of
course).

[GK] Okay, is it then possible to mention in the framework draft that these
iussues are not ruled out?


------------------------------------------------------------
[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.

------------------------------------
[Original--reh]
>5. The existence of these triggers doesn't replace NSLP
>  refreshes as the
>  mechanism for maintaining
>  liveness at the signalling application level. In this
> sense, up/down
>  notifications are advisories which allow
> faster reaction to events in the network, but shouldn't be
>  built into
>  NSLP semantics. (This is essentially the
> same distinction - with the same rationale - as SNMP makes
> between traps
> and normal messages.)
> >

[GK]
> Do you mean that the functionality described in my remark on
>  your remark (bullet) 3, above,
> will not be possible?
>
 [reh]
> >functionality possible so far as i can tell.

[GK
Could you then please emphasize it into the text!

Best Regards,
Georgios


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



From mailnull@www1.ietf.org  Tue May 13 05:22:00 2003
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 FAA01724
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 05:22:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4D8lvG01403
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 04:47:57 -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 h4D8lkB01396;
	Tue, 13 May 2003 04:47:46 -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 h4D8kSB01333
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 04:46:28 -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 FAA01672
	for <nsis@ietf.org>; Tue, 13 May 2003 05:20:02 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FVyv-00017g-00
	for nsis@ietf.org; Tue, 13 May 2003 05:21:57 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FVyu-00017d-00
	for nsis@ietf.org; Tue, 13 May 2003 05:21:57 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4D9N0D27003
	for <nsis@ietf.org>; Tue, 13 May 2003 12:23:00 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T622de1fed8ac158f24078@esvir04nok.ntc.nokia.com>;
 Tue, 13 May 2003 12:23:00 +0300
Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 13 May 2003 12:23:00 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 13 May 2003 12:22:59 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 12:22:59 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB3206362319CD@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMYhJl7ENLzZYzWT0eohZGwkepNUwArHcfg
To: <robert.hancock@roke.co.uk>, <nsis@ietf.org>
X-OriginalArrivalTime: 13 May 2003 09:22:59.0926 (UTC) FILETIME=[3F19E760:01C31931]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4D8kTB01334
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>
Content-Transfer-Encoding: 8bit


> > Is it sufficient for NTLP to specify the grammer but not the  management
> > of the state machine?
> 
> please clarify.

Messages between the boxes vs. what the boxes do.  My question is, then, is
NTLP more about the messages & parameters between entities as opposed to the
internal states of the boxes?

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



From mailnull@www1.ietf.org  Tue May 13 06:44:33 2003
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 GAA03142
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 06:44:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DAAVN07119
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 06:10:31 -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 h4DAAOB07104;
	Tue, 13 May 2003 06:10:24 -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 h4DA9oB07056
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 06:09:50 -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 GAA03126
	for <nsis@ietf.org>; Tue, 13 May 2003 06:43:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FXHZ-0001YF-00
	for nsis@ietf.org; Tue, 13 May 2003 06:45:17 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FXHZ-0001Y6-00
	for nsis@ietf.org; Tue, 13 May 2003 06:45:17 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZF7H>; Tue, 13 May 2003 11:45:51 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9A7@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 11:45:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

john,

> > > Is it sufficient for NTLP to specify the grammer but not 
> the  management
> > > of the state machine?
> > 
> > please clarify.
> 
> Messages between the boxes vs. what the boxes do.  My 
> question is, then, is
> NTLP more about the messages & parameters between entities as 
> opposed to the
> internal states of the boxes?
> 
> John
> 

so far as what is normatively standardised, i would say absolutely the first and not the second.

so far as what is useful to include in the standard to make the first easy to understand and interpret (but only for that purpose), the second is usually pretty useful.

i think it would be a bad idea to include internal state description which is 'added value' on top of what is the minimal description needed to understand the protocol operation.

what do the NTLP designers think?

r.

ps. the situation for the NSLPs is somewhat different. but we'll get to that ...
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Tue May 13 06:48:09 2003
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 GAA03207
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 06:48:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DAE7N07302
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 06:14: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 h4DAE3B07291;
	Tue, 13 May 2003 06:14:03 -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 h4DADnB07256
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 06:13:49 -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 GAA03180
	for <nsis@ietf.org>; Tue, 13 May 2003 06:47:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FXLQ-0001Za-00
	for nsis@ietf.org; Tue, 13 May 2003 06:49:16 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FXLQ-0001ZF-00
	for nsis@ietf.org; Tue, 13 May 2003 06:49:16 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZF7S>; Tue, 13 May 2003 11:49:51 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9A8@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Georgios Karagiannis'" <karagian@cs.utwente.nl>
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 11:49:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

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.

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



From mailnull@www1.ietf.org  Tue May 13 06:56:12 2003
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 GAA03421
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 06:56:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DAMA807681
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 06:22:10 -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 h4DAM5B07665;
	Tue, 13 May 2003 06:22:05 -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 h4DALuB07621
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 06:21:56 -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 GAA03372
	for <nsis@ietf.org>; Tue, 13 May 2003 06:55:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FXTH-0001cT-00
	for nsis@ietf.org; Tue, 13 May 2003 06:57:23 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FXTG-0001cO-00
	for nsis@ietf.org; Tue, 13 May 2003 06:57:23 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZF8P>; Tue, 13 May 2003 11:57:57 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9A9@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Georgios Karagiannis'" <karagian@cs.utwente.nl>
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 11:57:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

oops, typo spotted (see below)

> -----Original Message-----
> From: Hancock, Robert 
> Sent: 13 May 2003 11:50
> To: 'Georgios Karagiannis'
> Cc: nsis@ietf.org
> 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
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Tue May 13 08:12:47 2003
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 IAA06018
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 08:12:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DBclb13891
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 07:38:47 -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 h4DBcaB13817;
	Tue, 13 May 2003 07:38:36 -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 h4DBXcB12571
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 07:33:38 -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 IAA05698
	for <nsis@ietf.org>; Tue, 13 May 2003 08:07:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FYae-00027L-00
	for nsis@ietf.org; Tue, 13 May 2003 08:09:04 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FYad-000264-00
	for nsis@ietf.org; Tue, 13 May 2003 08:09:03 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4DC9axd011082;
	Tue, 13 May 2003 05:09:36 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHD95421;
	Tue, 13 May 2003 05:09:35 -0700 (PDT)
Message-Id: <200305131209.AHD95421@mira-sjc5-c.cisco.com>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
cc: nsis@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [NSIS] state management and the nsis framework 
In-Reply-To: Message from robert.hancock@roke.co.uk
   of "Tue, 13 May 2003 11:45:50 BST." <76C92FBBFB58D411AE760090271ED4181EA9A7@rsys002a.roke.co.uk> 
Date: Tue, 13 May 2003 08:09:34 -0400
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>

> so far as what is normatively standardised, i would say
> absolutely the first and not the second.  so far as what
> is useful to include in the standard to make the first
> easy to understand and interpret (but only for that
> purpose), the second is usually pretty useful.

State machines in protocol definitions tend to be
descriptive rather than normative, as you say.  They
also tend to describe protocol state rather than "box
state."  I think much of this is clear in practice.

One thing that's struck me about some of the recent state
discussions is that in some of the comments it's not clear
what the real implications are for the protocol, and it
would be helpful to me if people could be more explicit
about what they think it means for the protocol when they
make comments about state retention, etc.

I'm in the process of finishing up a first NTLP protocol
draft, which I'll iterate with Henning.  After we come to
agreement it needs to be checked out by a couple of
reviewers, after which it will be posted to internet-
drafts.

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



From mailnull@www1.ietf.org  Tue May 13 08:17:14 2003
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 IAA06224
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 08:17:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DBhFZ14394
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 07:43:15 -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 h4DBh8B14362;
	Tue, 13 May 2003 07:43:08 -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 h4DBgEB14324
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 07:42:14 -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 IAA06180
	for <nsis@ietf.org>; Tue, 13 May 2003 08:15:43 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FYix-0002Ep-00
	for nsis@ietf.org; Tue, 13 May 2003 08:17:39 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FYiw-0002Em-00
	for nsis@ietf.org; Tue, 13 May 2003 08:17:39 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4DCIh701011
	for <nsis@ietf.org>; Tue, 13 May 2003 15:18:43 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T622e82de10ac158f25152@esvir05nok.ntc.nokia.com>;
 Tue, 13 May 2003 15:18:43 +0300
Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 13 May 2003 15:18:43 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 13 May 2003 15:18:42 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] state management and the nsis framework 
Date: Tue, 13 May 2003 15:18:42 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB3206362319E5@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework 
Thread-Index: AcMZSVZTjQRdt0AVRQOJ54uCVi80zgAAEsmg
To: <mshore@cisco.com>, <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 13 May 2003 12:18:43.0210 (UTC) FILETIME=[CB635EA0:01C31949]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4DBgEB14325
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>
Content-Transfer-Encoding: 8bit

Hi all,

> One thing that's struck me about some of the recent state
> discussions is that in some of the comments it's not clear
> what the real implications are for the protocol, and it
> would be helpful to me if people could be more explicit
> about what they think it means for the protocol when they
> make comments about state retention, etc.

Yup, that would be a good idea.  Also, several folks have
already asked me about some NSLPs & I suggested they submit
individual drafts on them, which could be used as possible
examples during the NTLP design.

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



From mailnull@www1.ietf.org  Tue May 13 08:43:15 2003
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 IAA07991
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 08:43:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DC9Gs17230
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 08:09:16 -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 h4DC9AB17215;
	Tue, 13 May 2003 08:09:10 -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 h4DC8OB17189
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 08:08:24 -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 IAA07962
	for <nsis@ietf.org>; Tue, 13 May 2003 08:41:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FZ8H-0002n7-00
	for nsis@ietf.org; Tue, 13 May 2003 08:43:49 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FZ8G-0002mz-00
	for nsis@ietf.org; Tue, 13 May 2003 08:43:48 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4DCih5s003943;
	Tue, 13 May 2003 14:44:43 +0200 (MET DST)
Message-ID: <001f01c3194d$6e9bdb30$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Melinda Shore" <mshore@cisco.com>
Cc: <nsis@ietf.org>
References: <200305131209.AHD95421@mira-sjc5-c.cisco.com>
Subject: Re: [NSIS] state management and the nsis framework 
Date: Tue, 13 May 2003 14:44:45 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Melinda

We tried to describe the real implications for the protocol in two drafts:
http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp-
00.txt
http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-01.txt

Best Regards,
Georgios

----- Original Message -----
From: "Melinda Shore" <mshore@cisco.com>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
Sent: Tuesday, May 13, 2003 2:09 PM
Subject: Re: [NSIS] state management and the nsis framework


> > so far as what is normatively standardised, i would say
> > absolutely the first and not the second.  so far as what
> > is useful to include in the standard to make the first
> > easy to understand and interpret (but only for that
> > purpose), the second is usually pretty useful.
>
> State machines in protocol definitions tend to be
> descriptive rather than normative, as you say.  They
> also tend to describe protocol state rather than "box
> state."  I think much of this is clear in practice.
>
> One thing that's struck me about some of the recent state
> discussions is that in some of the comments it's not clear
> what the real implications are for the protocol, and it
> would be helpful to me if people could be more explicit
> about what they think it means for the protocol when they
> make comments about state retention, etc.
>
> I'm in the process of finishing up a first NTLP protocol
> draft, which I'll iterate with Henning.  After we come to
> agreement it needs to be checked out by a couple of
> reviewers, after which it will be posted to internet-
> drafts.
>
> Melinda
> _______________________________________________
> 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



From mailnull@www1.ietf.org  Tue May 13 09:29:26 2003
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 JAA11369
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 09:29:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DCtSv21612
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 08:55:28 -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 h4DCtIB21594;
	Tue, 13 May 2003 08:55:18 -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 h4DCjiB20934
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 08:45:44 -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 JAA10939
	for <nsis@ietf.org>; Tue, 13 May 2003 09:19:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FZiO-0003nF-00
	for nsis@ietf.org; Tue, 13 May 2003 09:21:08 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FZiN-0003n9-00
	for nsis@ietf.org; Tue, 13 May 2003 09:21:07 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4DDMA5s005603;
	Tue, 13 May 2003 15:22:10 +0200 (MET DST)
Message-ID: <003301c31952$aa212f20$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
References: <76C92FBBFB58D411AE760090271ED4181EA9A9@rsys002a.roke.co.uk>
Subject: Re: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 15:22:12 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

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



From mailnull@www1.ietf.org  Tue May 13 10:10:03 2003
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



From mailnull@www1.ietf.org  Tue May 13 10:49:18 2003
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 KAA15209
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 10:49:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DEFM929138
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 10:15:22 -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 h4DEFFB29131;
	Tue, 13 May 2003 10:15:15 -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 h4DEEbB29057
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 10:14:37 -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 KAA15192
	for <nsis@ietf.org>; Tue, 13 May 2003 10:48:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fb6N-0004bW-00
	for nsis@ietf.org; Tue, 13 May 2003 10:49:59 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fb6M-0004bN-00
	for nsis@ietf.org; Tue, 13 May 2003 10:49:58 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4DEp05s009963;
	Tue, 13 May 2003 16:51:00 +0200 (MET DST)
Message-ID: <001b01c3195f$12f94760$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: <louise.burness@bt.com>
Cc: <nsis@ietf.org>
References: <ADEC16A81CFF17489F5A2A9E1D2226DE8DCDCA@i2km41-ukdy.nat.bt.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 16:51:02 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

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



From mailnull@www1.ietf.org  Tue May 13 11:32:14 2003
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 LAA16914
	for <nsis-archive@odin.ietf.org>; Tue, 13 May 2003 11:32:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4DEwIt00360
	for nsis-archive@odin.ietf.org; Tue, 13 May 2003 10:58:18 -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 h4DEwCB00345;
	Tue, 13 May 2003 10:58:12 -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 h4DEvTB32765
	for <nsis@optimus.ietf.org>; Tue, 13 May 2003 10:57:29 -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 LAA16807
	for <nsis@ietf.org>; Tue, 13 May 2003 11:30:55 -0400 (EDT)
From: louise.burness@bt.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fblq-000534-00
	for nsis@ietf.org; Tue, 13 May 2003 11:32:50 -0400
Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fblp-000523-00
	for nsis@ietf.org; Tue, 13 May 2003 11:32:50 -0400
Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <K6J2K20H>; Tue, 13 May 2003 16:33:38 +0100
Message-ID: <ADEC16A81CFF17489F5A2A9E1D2226DE8DCDCB@i2km41-ukdy.nat.bt.com>
To: karagian@cs.utwente.nl
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Tue, 13 May 2003 16:33:08 +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

Yip, I see that point. But, might there not be other cases where this
near-functionality duplication or ability to infer information occurs?
Urgh...for example, at a guess something similar might happen when mobility
occurs and the NLTP and NSLP states might need to be moved. Efficiency gains
at this point might be much more significant. If so, then your argument will
then (correctly, but not helpfully) lead you to say that one protocol is
going to be more efficient than two

Louise

-----Original Message-----
From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 13 May 2003 15:51
To: Farr,AL,Louise,XVR2 BURNESAL R
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



From mailnull@www1.ietf.org  Tue May 13 11:44:44 2003
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



From mailnull@www1.ietf.org  Wed May 14 02:39:22 2003
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 CAA07177
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 02:39:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4E65jx04542
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 02:05:45 -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 h4E65dB03913;
	Wed, 14 May 2003 02:05:39 -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 h4E650B03787
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 02:05:00 -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 CAA07144
	for <nsis@ietf.org>; Wed, 14 May 2003 02:38:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fpvl-00034i-00
	for nsis@ietf.org; Wed, 14 May 2003 02:40:01 -0400
Received: from [137.194.192.1] (helo=infres.enst.fr)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fpvl-00034a-00
	for nsis@ietf.org; Wed, 14 May 2003 02:40:01 -0400
Received: from luu (dhcp7-211.enst.fr [137.194.7.211])
	by infres.enst.fr (Postfix) with SMTP id E31AD1895
	for <nsis@ietf.org>; Wed, 14 May 2003 08:41:06 +0200 (MEST)
Message-ID: <000c01c319e3$f65a75e0$d307c289@enst.fr>
From: "Thanh Tra LUU" <luu@enst.fr>
To: <nsis@ietf.org>
References: <ADEC16A81CFF17489F5A2A9E1D2226DE8DCDCA@i2km41-ukdy.nat.bt.com> <001b01c3195f$12f94760$4c0d5982@dynamic.cs.utwente.nl>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 08:42:17 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Georgios,

>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.

In the framework, I see that there is not refresh message of NSLP. It means
the NSLP will use the refresh message of NTLP for its purpose and the
information in the NTLP refresh message depends on NSLP. Morever, I don't
understatnd clearly why the load on the network can be severely reduced if
we only use refresh message belonging to one of the protocol levels.

Best regards.

Nary Tra
ENST, Paris
Tel : (0033) (0)1 45 81 71 06


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



From mailnull@www1.ietf.org  Wed May 14 03:48:09 2003
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 DAA08565
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 03:48:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4E7EYx20033
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 03:14:34 -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 h4E7EHB20025;
	Wed, 14 May 2003 03:14:17 -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 h4E7DuB19995
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 03:13:56 -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 DAA08537
	for <nsis@ietf.org>; Wed, 14 May 2003 03:47:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fr0T-0003TX-00
	for nsis@ietf.org; Wed, 14 May 2003 03:48:57 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fr0S-0003TT-00
	for nsis@ietf.org; Wed, 14 May 2003 03:48:56 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4E7nx5s006156;
	Wed, 14 May 2003 09:49:59 +0200 (MET DST)
Message-ID: <001201c319ed$6c2b0c90$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Freytsis, Ilya" <ifreytsis@Cetacean.com>
Cc: <nsis@ietf.org>
References: <6D8664171C38D511B5AD0002B325CE660157224B@mail.cetaceannetworks.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 09:50:00 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

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" <ifreytsis@Cetacean.com>
To: "'Georgios Karagiannis'" <karagian@cs.utwente.nl>;
<louise.burness@bt.com>
Cc: <nsis@ietf.org>
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: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
>

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



From mailnull@www1.ietf.org  Wed May 14 03:57:48 2003
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 DAA08753
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 03:57:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4E7ODX20603
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 03:24:13 -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 h4E7O7B20583;
	Wed, 14 May 2003 03:24: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 h4E7N5B20516
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 03:23:05 -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 DAA08718
	for <nsis@ietf.org>; Wed, 14 May 2003 03:56:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fr9K-0003XI-00
	for nsis@ietf.org; Wed, 14 May 2003 03:58:06 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fr9J-0003XF-00
	for nsis@ietf.org; Wed, 14 May 2003 03:58:05 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4E7xA5s006572;
	Wed, 14 May 2003 09:59:10 +0200 (MET DST)
Message-ID: <001c01c319ee$b4780060$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: <louise.burness@bt.com>
Cc: <nsis@ietf.org>
References: <ADEC16A81CFF17489F5A2A9E1D2226DE8DCDCB@i2km41-ukdy.nat.bt.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 09:59:11 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Louise

There might be situations that for a specific NSLP
this duplication could be required. Therefore, in one of my last e-mails I
mentioned that the
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.

What I would also like to emphasize is that when a user is roaming and a
handover take place
then both  NTLP and NSLP states have to be transferred to the new path.

Best Regards,
Georgios

----- Original Message -----
From: <louise.burness@bt.com>
To: <karagian@cs.utwente.nl>
Cc: <nsis@ietf.org>
Sent: Tuesday, May 13, 2003 5:33 PM
Subject: RE: [NSIS] state management and the nsis framework


> Hi
>
> Yip, I see that point. But, might there not be other cases where this
> near-functionality duplication or ability to infer information occurs?
> Urgh...for example, at a guess something similar might happen when
mobility
> occurs and the NLTP and NSLP states might need to be moved. Efficiency
gains
> at this point might be much more significant. If so, then your argument
will
> then (correctly, but not helpfully) lead you to say that one protocol is
> going to be more efficient than two
>
> Louise
>
> -----Original Message-----
> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
> Sent: 13 May 2003 15:51
> To: Farr,AL,Louise,XVR2 BURNESAL R
> 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



From mailnull@www1.ietf.org  Wed May 14 04:17:51 2003
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 EAA09192
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 04:17:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4E7iGq22684
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 03:44:16 -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 h4E7iBB22652;
	Wed, 14 May 2003 03:44:11 -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 h4E7g6B22549
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 03:42:06 -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 EAA09132
	for <nsis@ietf.org>; Wed, 14 May 2003 04:15:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FrRi-0003fC-00
	for nsis@ietf.org; Wed, 14 May 2003 04:17:06 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FrRh-0003f9-00
	for nsis@ietf.org; Wed, 14 May 2003 04:17:05 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4E8IA5s007445;
	Wed, 14 May 2003 10:18:10 +0200 (MET DST)
Message-ID: <006601c319f1$5bcb51d0$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Thanh Tra LUU" <luu@enst.fr>, <nsis@ietf.org>
References: <ADEC16A81CFF17489F5A2A9E1D2226DE8DCDCA@i2km41-ukdy.nat.bt.com> <001b01c3195f$12f94760$4c0d5982@dynamic.cs.utwente.nl> <000c01c319e3$f65a75e0$d307c289@enst.fr>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 10:18:11 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Nary Tra

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.

When we only use refresh message belonging to one of the protocol levels
then
for one signaling application the number of refresh messages needed
can be two times smaller than the number of refresh messages that have to be
processed
when we use NTLP refresh messages to refresh the NTLP states
and independent NSLP refresh messages to refresh the NSLP states.


Best Regards,
Georgios





----- Original Message -----
From: "Thanh Tra LUU" <luu@enst.fr>
To: <nsis@ietf.org>
Sent: Wednesday, May 14, 2003 8:42 AM
Subject: Re: [NSIS] state management and the nsis framework


> Hi Georgios,
>
> >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.
>
> In the framework, I see that there is not refresh message of NSLP. It
means
> the NSLP will use the refresh message of NTLP for its purpose and the
> information in the NTLP refresh message depends on NSLP. Morever, I don't
> understatnd clearly why the load on the network can be severely reduced if
> we only use refresh message belonging to one of the protocol levels.
>
> Best regards.
>
> Nary Tra
> ENST, Paris
> Tel : (0033) (0)1 45 81 71 06
>
>
> _______________________________________________
> 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



From mailnull@www1.ietf.org  Wed May 14 06:19:02 2003
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 GAA11181
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 06:19:02 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4E9jTZ31208
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 05:45:29 -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 h4E9jHB31174;
	Wed, 14 May 2003 05:45:17 -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 h4E9i7B31105
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 05:44:07 -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 GAA11139
	for <nsis@ietf.org>; Wed, 14 May 2003 06:17:10 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FtLk-0004CZ-00
	for nsis@ietf.org; Wed, 14 May 2003 06:19:04 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FtLj-0004CW-00
	for nsis@ietf.org; Wed, 14 May 2003 06:19:03 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4EAK8D10146
	for <nsis@ietf.org>; Wed, 14 May 2003 13:20:08 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T62333c80c0ac158f23077@esvir03nok.nokia.com>;
 Wed, 14 May 2003 13:19:58 +0300
Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 14 May 2003 13:19:51 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 14 May 2003 13:19:44 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 13:19:44 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB320636231A01@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMZ890xJwZjNR/4SZGQtujOsHXDiAADjqgQ
To: <karagian@cs.utwente.nl>, <luu@enst.fr>, <nsis@ietf.org>
X-OriginalArrivalTime: 14 May 2003 10:19:44.0762 (UTC) FILETIME=[56F465A0:01C31A02]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4E9i7B31106
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>
Content-Transfer-Encoding: 8bit

Hi Georgios,

> When we only use refresh message belonging to one of the protocol levels then
> for one signaling application the number of refresh messages needed
> can be two times smaller than the number of refresh messages that have to be
> processed when we use NTLP refresh messages to refresh the NTLP states
> and independent NSLP refresh messages to refresh the NSLP states.

At present, I don't know if we have made a determination which layer
must refresh what layer. One could imagine a light-weight NTLP which
does not require refreshign, but all is handled via NSLP refreshes
or visa-versa.

It seems that you are requesting the possibility at refreshing at
both layers, correct?

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



From mailnull@www1.ietf.org  Wed May 14 06:37:08 2003
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 GAA11641
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 06:37:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4EA3ZO32138
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 06:03:35 -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 h4EA39B32122;
	Wed, 14 May 2003 06:03:09 -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 h4EA2JB32073
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 06:02:19 -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 GAA11608
	for <nsis@ietf.org>; Wed, 14 May 2003 06:35:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FtdM-0004Ic-00
	for nsis@ietf.org; Wed, 14 May 2003 06:37:16 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FtdL-0004IZ-00
	for nsis@ietf.org; Wed, 14 May 2003 06:37:16 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4EAcL5s013709;
	Wed, 14 May 2003 12:38:21 +0200 (MET DST)
Message-ID: <019c01c31a04$f128cc40$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: <john.loughney@nokia.com>, <nsis@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB320636231A01@esebe023.ntc.nokia.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 12:38:22 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi John

What I am actually saying is that  both layers should be able to provide
soft state
management. The soft state management at both layers could use refresh
messages
belonging to one of the protocol levels, e.g., NTLP. If a NTLP state is not
refreshed
in time the NSLP instance is informed about it.
Otherwise the NSLP instance assumes that the NTLP state is alive.
This is similar to the concept proposed by Bob Braden,
see:
http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-01.txt

In this way the the number of refresh messages
that have to be processed, per signaling application,
by the NTLP/NSLP aware node is minimized.

Best regards,
Georgios




----- Original Message -----
From: <john.loughney@nokia.com>
To: <karagian@cs.utwente.nl>; <luu@enst.fr>; <nsis@ietf.org>
Sent: Wednesday, May 14, 2003 12:19 PM
Subject: RE: [NSIS] state management and the nsis framework


> Hi Georgios,
>
> > When we only use refresh message belonging to one of the protocol levels
then
> > for one signaling application the number of refresh messages needed
> > can be two times smaller than the number of refresh messages that have
to be
> > processed when we use NTLP refresh messages to refresh the NTLP states
> > and independent NSLP refresh messages to refresh the NSLP states.
>
> At present, I don't know if we have made a determination which layer
> must refresh what layer. One could imagine a light-weight NTLP which
> does not require refreshign, but all is handled via NSLP refreshes
> or visa-versa.
>
> It seems that you are requesting the possibility at refreshing at
> both layers, correct?
>
> John
>

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



From mailnull@www1.ietf.org  Wed May 14 07:43:53 2003
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 HAA13295
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 07:43:53 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4EBAME04939
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 07:10:22 -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 h4EBADB04931;
	Wed, 14 May 2003 07:10:13 -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 h4EB9DB04884
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 07: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 HAA13273
	for <nsis@ietf.org>; Wed, 14 May 2003 07:42:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fug4-0004gd-00
	for nsis@ietf.org; Wed, 14 May 2003 07:44:08 -0400
Received: from mail2.telekom.de ([195.243.210.197])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fug3-0004fv-00
	for nsis@ietf.org; Wed, 14 May 2003 07:44:08 -0400
Received: from [127.0.0.1] by mail2.dmz.telekom.de with ESMTP; Wed, 14 May 2003 13:43:55 +0200
Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 14 May 2003 13:43:13 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <KZD1PXJJ>; Wed, 14 May 2003 13:43:15 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB45F@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 13:43:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4EB9DB04885
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>
Content-Transfer-Encoding: 8bit

Hi Georgios

| If a NTLP state is not refreshed in time the NSLP instance 
| is informed about it. Otherwise the NSLP instance 
| assumes that the NTLP state is alive.

   +---C---+
  /         \
 A-----------B

Assume A, B, C to support NTLP, whereas the NSLP of interest is only 
supported by A and B. Once the link A-B is broken, the NTLP A-B
isn't refreshed while the NSLP A-B could easily maintain state 
via A-C-B communication.

How does your system react in this case? It is of no importance to 
the NSLP B that NTLP B lost connectivity to NTLP A.

Regards, Rüdiger

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



From mailnull@www1.ietf.org  Wed May 14 11:13:09 2003
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 LAA21074
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 11:13:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4EEdh021344
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 10:39:43 -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 h4EEdPB21319;
	Wed, 14 May 2003 10:39:25 -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 h4EEchB21296
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 10:38:43 -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 LAA21043
	for <nsis@ietf.org>; Wed, 14 May 2003 11:11:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fxwk-0006a1-00
	for nsis@ietf.org; Wed, 14 May 2003 11:13:34 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Fxwk-0006Zu-00
	for nsis@ietf.org; Wed, 14 May 2003 11:13:34 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSB1ZJBJ>; Wed, 14 May 2003 16:14:10 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41806AC10C5@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 16:14:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

dear colleagues,

What direction[s] are we heading in this discussion?

First, a general point. What I believe we are trying to achieve in this
NSIS work is to develop tools which are generally useful for path-associated
signalling in the Internet; one of the mechanisms to do this is to put 
functionality which we generally believe to be generic to all such situations
into a common lower layer. In the absence of *any* discussion so far of the 
general characteristics of signalling applications - beyond the fact that they 
need to transfer data between instances of themselves - the only safe 
functionality to put in the lower layer is that of data transfer. (There 
have been plenty of requests for such a discussion, but no one seem to want to 
open that Pandora's box at the moment.)

Putting functionality into the NTLP, which happens to match nicely
with what is needed by one rather specific signalling application, without 
analysing (in detail) how it affects NTLP usefulness more generally, strikes
me as being a stunningly bad idea.

To specifics:
We have a proposal that the framework should define how the NSLP should be
able to 'use' refresh functionality within the NTLP layer, essentially in the
interests of efficiency and reduced network load.

Taken most literally, this would imply defining a soft-state refresh machine
which the NTLP operated for its own purposes but whose state was exposed to
signalling applications. This would be possible but it strikes me as a 
dangerously high degree of interlayer coupling. Even if it was useful for
a single-application world, we would have to decide what it meant when 
multiple applications were operating between the same pair of NTLP neighbours,
or some NTLP nodes didn't understand all of the applications. I have no idea how
to do this.

It seems much easier to me to have conceptually independent refresh mechanisms,
in particular neither layer needs to know that the other is even using soft-state
as a liveness mechanism. A complaint is that independent refresh mechanisms 
would double the message rate and network load. This is just plain wrong. A 
single message can refresh state at more than one level, and any decent
NTLP implementation should be able to schedule its own operation so that 
this gain is achieved (there is plenty of experience from other protocols in 
how to do this sort of thing). In fact, our biggest gain comes from being able
to handle multiple signalling applications and sessions in a single NTLP message
(2961 bundling-style), and this is made easy specifically by minimising the
inter-layer state coupling.

Of course, it also depends on what the NSLP is using this NTLP state-management
capability for. *If* the only way it is used is to find out "something failed"
then this is quite a different case. We are already (I think) assuming that the
NTLP does some sort of 'peer liveness' monitoring (detecting route changes,
restarts and so on), and it can report failures in this to signalling 
applications. But that is nothing about sharing a refresh mechanism, and
(nicely) makes no restrictions on how the NTLP should actually be designed.

Cheers,

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



From mailnull@www1.ietf.org  Wed May 14 12:44:32 2003
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 MAA26997
	for <nsis-archive@odin.ietf.org>; Wed, 14 May 2003 12:44:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4EGB7u29611
	for nsis-archive@odin.ietf.org; Wed, 14 May 2003 12:11: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 h4EGArB29591;
	Wed, 14 May 2003 12:10:53 -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 h4EG9RB29514
	for <nsis@optimus.ietf.org>; Wed, 14 May 2003 12:09:27 -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 MAA26705
	for <nsis@ietf.org>; Wed, 14 May 2003 12:42:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FzMW-0007Pc-00
	for nsis@ietf.org; Wed, 14 May 2003 12:44:16 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19FzMV-0007PZ-00
	for nsis@ietf.org; Wed, 14 May 2003 12:44:15 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4EGjK5s028158;
	Wed, 14 May 2003 18:45:21 +0200 (MET DST)
Message-ID: <01c601c31a38$362d3910$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>, <nsis@ietf.org>
References: <76C92FBBFB58D411AE760090271ED41806AC10C5@rsys002a.roke.co.uk>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 14 May 2003 18:45:22 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Robert

>> It seems much easier to me to have conceptually independent refresh
mechanisms,
>> in particular neither layer needs to know that the other is even using
soft-state
>> as a liveness mechanism. A complaint is that independent refresh
mechanisms
>> would double the message rate and network load. This is just plain wrong.
>> A single message can refresh state at more than one level, and any decent
>> NTLP implementation should be able to schedule its own operation so that
>> this gain is achieved (there is plenty of experience from other protocols
in
>> how to do this sort of thing).

Please note that the above described proposal is actually in favour of
interlayer
coupling and it is actually similar to what I was proposing :-)
I was proposing that the NTLP refresh messages are used to refresh the NTLP
and NSLP states!
In order to do this the NTLP instance has to generate a trigger in certain
situations.
A NSLP instance can then use this trigger for its soft state management.

If we consider that the types and ways of NTLP triggers are part of APIs,
then we
probably do not have to specify, in the NSIS framework,
how and when the NTLP triggers are generated.

Best regards,
Georgios


----- Original Message -----
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: <nsis@ietf.org>
Sent: Wednesday, May 14, 2003 5:14 PM
Subject: RE: [NSIS] state management and the nsis framework


> dear colleagues,
>
> What direction[s] are we heading in this discussion?
>
> First, a general point. What I believe we are trying to achieve in this
> NSIS work is to develop tools which are generally useful for
path-associated
> signalling in the Internet; one of the mechanisms to do this is to put
> functionality which we generally believe to be generic to all such
situations
> into a common lower layer. In the absence of *any* discussion so far of
the
> general characteristics of signalling applications - beyond the fact that
they
> need to transfer data between instances of themselves - the only safe
> functionality to put in the lower layer is that of data transfer. (There
> have been plenty of requests for such a discussion, but no one seem to
want to
> open that Pandora's box at the moment.)
>
> Putting functionality into the NTLP, which happens to match nicely
> with what is needed by one rather specific signalling application, without
> analysing (in detail) how it affects NTLP usefulness more generally,
strikes
> me as being a stunningly bad idea.
>
> To specifics:
> We have a proposal that the framework should define how the NSLP should be
> able to 'use' refresh functionality within the NTLP layer, essentially in
the
> interests of efficiency and reduced network load.
>
> Taken most literally, this would imply defining a soft-state refresh
machine
> which the NTLP operated for its own purposes but whose state was exposed
to
> signalling applications. This would be possible but it strikes me as a
> dangerously high degree of interlayer coupling. Even if it was useful for
> a single-application world, we would have to decide what it meant when
> multiple applications were operating between the same pair of NTLP
neighbours,
> or some NTLP nodes didn't understand all of the applications. I have no
idea how
> to do this.
>
> It seems much easier to me to have conceptually independent refresh
mechanisms,
> in particular neither layer needs to know that the other is even using
soft-state
> as a liveness mechanism. A complaint is that independent refresh
mechanisms
> would double the message rate and network load. This is just plain wrong.
A
> single message can refresh state at more than one level, and any decent
> NTLP implementation should be able to schedule its own operation so that
> this gain is achieved (there is plenty of experience from other protocols
in
> how to do this sort of thing). In fact, our biggest gain comes from being
able
> to handle multiple signalling applications and sessions in a single NTLP
message
> (2961 bundling-style), and this is made easy specifically by minimising
the
> inter-layer state coupling.
>
> Of course, it also depends on what the NSLP is using this NTLP
state-management
> capability for. *If* the only way it is used is to find out "something
failed"
> then this is quite a different case. We are already (I think) assuming
that the
> NTLP does some sort of 'peer liveness' monitoring (detecting route
changes,
> restarts and so on), and it can report failures in this to signalling
> applications. But that is nothing about sharing a refresh mechanism, and
> (nicely) makes no restrictions on how the NTLP should actually be
designed.
>
> Cheers,
>
> r.
> _______________________________________________
> 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



From mailnull@www1.ietf.org  Thu May 15 02:17:45 2003
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 CAA27832
	for <nsis-archive@odin.ietf.org>; Thu, 15 May 2003 02:17:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4F5iau21170
	for nsis-archive@odin.ietf.org; Thu, 15 May 2003 01:44:36 -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 h4F5iVB21161;
	Thu, 15 May 2003 01:44:31 -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 h4F5hvB21141
	for <nsis@optimus.ietf.org>; Thu, 15 May 2003 01:43:57 -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 CAA27729
	for <nsis@ietf.org>; Thu, 15 May 2003 02:16:35 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GC4T-0004Da-00
	for nsis@ietf.org; Thu, 15 May 2003 02:18:29 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GC4S-0004DX-00
	for nsis@ietf.org; Thu, 15 May 2003 02:18:28 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4F6JUD00290
	for <nsis@ietf.org>; Thu, 15 May 2003 09:19:36 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T623786b524ac158f23077@esvir03nok.nokia.com> for <nsis@ietf.org>;
 Thu, 15 May 2003 09:19:30 +0300
Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 15 May 2003 09:19:29 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 15 May 2003 09:19:27 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 15 May 2003 09:19:21 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB3206360C1F30@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMaLCXqyF5iniXWS3+OdMXKC+oNYwAfBXyQ
To: <nsis@ietf.org>
X-OriginalArrivalTime: 15 May 2003 06:19:27.0855 (UTC) FILETIME=[F038B7F0:01C31AA9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4F5hvB21142
Subject: [NSIS] Topics for IETF 57
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>
Content-Transfer-Encoding: 8bit

Hi all,

I'm preparing the NSIS IETF 57 meeting.  My initial feeling is that we should have a
focused meeting, working on  NTLP and the framework.

My tentative list of topics would be:

NTLP Discussion lead by the editors 
Framework open issues
Short summary of other WG documents, including:
 Security Threats & RSVP Security properties
 Analysis doc

I think we can easily fit all of the above into a 2½ hour slot.  However,
if someone has additional topics for discussion, please contact me
with the discussion topic and time needed.

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



From mailnull@www1.ietf.org  Thu May 15 04:12:24 2003
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 EAA00582
	for <nsis-archive@odin.ietf.org>; Thu, 15 May 2003 04:12:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4F7dIX08257
	for nsis-archive@odin.ietf.org; Thu, 15 May 2003 03:39:18 -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 h4F7dDB08250;
	Thu, 15 May 2003 03:39:13 -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 h4F7c7B08210
	for <nsis@optimus.ietf.org>; Thu, 15 May 2003 03:38:07 -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 EAA00507
	for <nsis@ietf.org>; Thu, 15 May 2003 04:10:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GDqv-000542-00
	for nsis@ietf.org; Thu, 15 May 2003 04:12:37 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GDqu-00053y-00
	for nsis@ietf.org; Thu, 15 May 2003 04:12:36 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4F8Dh5s022598;
	Thu, 15 May 2003 10:13:43 +0200 (MET DST)
Message-ID: <001b01c31ab9$e75ed690$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB460@G8PQD.blf01.telekom.de>
Subject: Re: [NSIS] state management and the nsis framework
Date: Thu, 15 May 2003 10:13:44 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id h4F8Dh5s022598
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4F7c7B08211
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>
Content-Transfer-Encoding: 8bit

Hi Ruediger

Okay, thus you are assuming that a re-routing takes place!

But if (A) and (B) are not end nodes, and the following network
configuration is used:
Before re-routing:
(D = end node) <->(E)<->(F)<->(A)<->(B)<->(G)<->(H)<->(Z= end node)

After rerouting (due to failure of link (A)<->(B)) the following network
configuration can be chosen
by the applied dynamic routing protocol:

(D = end node) <->(E)<->(F)<->(A)<->(C)<->(I)<->(H)<->(Z= end node)


Consider that  the nodes (D), (E), (F), (A), (B), (G), (H), (Z) and (I) can
support both NTLP and
NSLP protocols. Node (C) as you already proposed supports only the NTLP
protocol and not
the NSLP protocol.
Due to failure of the link (A)<->(B) a re-routing takes place.
When the path coupled signaling is used, the new re-routed forwarding path
will be (mainly)
chosen by the applied dynamic routing protocol.
It may happen that the new re-routed path is not at all passing through node
(B).
This means that the old NSLP state stored  in node (B) before re-routing
will remain
there for "ever" (if of course no other soft state management solution is
applied).

Therefore, I think that in many situations, if a re-routing takes place it
will
affect both the NTLP and NSLP state management procedures.
Thus not only the NTLP state management.

Best Regards,
Georgios



----- Original Message -----
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: <karagian@cs.utwente.nl>
Sent: Thursday, May 15, 2003 8:29 AM
Subject: RE: [NSIS] state management and the nsis framework


> Hi Georgios,
>
> I'm assuming it to be standard Internet architecture.
> There's a best route between A and B. A broken link
> results in a new best route bewteen A and B.
>
> Regards, Rüdiger
>
> | I do not completely understand the depicted scenario.
> | Are you trying to say that there are two paths between A and
> | B that are used
> | simultaneously:
> | One is the direct path A-B and the other is the path A-C-B.
> | Considering that this is not a load sharing solution,
> | is this scenario realistic?
> |
> | Best Regards,
> | Georgios
> |
> |
> | ----- Original Message -----
> | From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
> | To: <karagian@cs.utwente.nl>
> | Cc: <nsis@ietf.org>
> | Sent: Wednesday, May 14, 2003 1:43 PM
> | Subject: RE: [NSIS] state management and the nsis framework
> |
> |
> | > Hi Georgios
> | >
> | > | If a NTLP state is not refreshed in time the NSLP instance
> | > | is informed about it. Otherwise the NSLP instance
> | > | assumes that the NTLP state is alive.
> | >
> | >    +---C---+
> | >   /         \
> | >  A-----------B
> | >
> | > Assume A, B, C to support NTLP, whereas the NSLP of interest is only
> | > supported by A and B. Once the link A-B is broken, the NTLP A-B
> | > isn't refreshed while the NSLP A-B could easily maintain state
> | > via A-C-B communication.
> | >
> | > How does your system react in this case? It is of no importance to
> | > the NSLP B that NTLP B lost connectivity to NTLP A.
> | >
> | > Regards, Rüdiger
> | >
> | >
> |
>

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



From mailnull@www1.ietf.org  Thu May 15 06:59:40 2003
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 GAA03070
	for <nsis-archive@odin.ietf.org>; Thu, 15 May 2003 06:59:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4FAQcQ19125
	for nsis-archive@odin.ietf.org; Thu, 15 May 2003 06:26:38 -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 h4FAQPB19109;
	Thu, 15 May 2003 06:26:25 -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 h4FAPGB19088
	for <nsis@optimus.ietf.org>; Thu, 15 May 2003 06:25:16 -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 GAA03043
	for <nsis@ietf.org>; Thu, 15 May 2003 06:57:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GGSc-0005iu-00
	for nsis@ietf.org; Thu, 15 May 2003 06:59:42 -0400
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GGSb-0005iq-00
	for nsis@ietf.org; Thu, 15 May 2003 06:59:41 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 15 May 2003 11:49:17 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <KZD1RB87>; Thu, 15 May 2003 11:49:16 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB463@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Thu, 15 May 2003 11:49:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4FAPGB19089
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>
Content-Transfer-Encoding: 8bit

Hello Georgios,

assume A-B to be replaced by A-C-B. You've changed 
my example in your reply and I'd prefer if you'd 
answer my original question.

Regards, Rüdiger


| -----Original Message-----
| From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
| Sent: Thursday, May 15, 2003 10:14 AM
| To: Geib, Rüdiger
| Cc: nsis@ietf.org
| Subject: Re: [NSIS] state management and the nsis framework
| 
| 
| Hi Ruediger
| 
| Okay, thus you are assuming that a re-routing takes place!
| 
| But if (A) and (B) are not end nodes, and the following network
| configuration is used:
| Before re-routing:
| (D = end node) <->(E)<->(F)<->(A)<->(B)<->(G)<->(H)<->(Z= end node)
| 
| After rerouting (due to failure of link (A)<->(B)) the 
| following network
| configuration can be chosen
| by the applied dynamic routing protocol:
| 
| (D = end node) <->(E)<->(F)<->(A)<->(C)<->(I)<->(H)<->(Z= end node)
| 
| 
| Consider that  the nodes (D), (E), (F), (A), (B), (G), (H), 
| (Z) and (I) can
| support both NTLP and
| NSLP protocols. Node (C) as you already proposed supports 
| only the NTLP
| protocol and not
| the NSLP protocol.
| Due to failure of the link (A)<->(B) a re-routing takes place.
| When the path coupled signaling is used, the new re-routed 
| forwarding path
| will be (mainly)
| chosen by the applied dynamic routing protocol.
| It may happen that the new re-routed path is not at all 
| passing through node
| (B).
| This means that the old NSLP state stored  in node (B) before 
| re-routing
| will remain
| there for "ever" (if of course no other soft state management 
| solution is
| applied).
| 
| Therefore, I think that in many situations, if a re-routing 
| takes place it
| will
| affect both the NTLP and NSLP state management procedures.
| Thus not only the NTLP state management.
| 
| Best Regards,
| Georgios
| 
| 
| 
| ----- Original Message -----
| From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
| To: <karagian@cs.utwente.nl>
| Sent: Thursday, May 15, 2003 8:29 AM
| Subject: RE: [NSIS] state management and the nsis framework
| 
| 
| > Hi Georgios,
| >
| > I'm assuming it to be standard Internet architecture.
| > There's a best route between A and B. A broken link
| > results in a new best route bewteen A and B.
| >
| > Regards, Rüdiger
| >
| > | I do not completely understand the depicted scenario.
| > | Are you trying to say that there are two paths between A and
| > | B that are used
| > | simultaneously:
| > | One is the direct path A-B and the other is the path A-C-B.
| > | Considering that this is not a load sharing solution,
| > | is this scenario realistic?
| > |
| > | Best Regards,
| > | Georgios
| > |
| > |
| > | ----- Original Message -----
| > | From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
| > | To: <karagian@cs.utwente.nl>
| > | Cc: <nsis@ietf.org>
| > | Sent: Wednesday, May 14, 2003 1:43 PM
| > | Subject: RE: [NSIS] state management and the nsis framework
| > |
| > |
| > | > Hi Georgios
| > | >
| > | > | If a NTLP state is not refreshed in time the NSLP instance
| > | > | is informed about it. Otherwise the NSLP instance
| > | > | assumes that the NTLP state is alive.
| > | >
| > | >    +---C---+
| > | >   /         \
| > | >  A-----------B
| > | >
| > | > Assume A, B, C to support NTLP, whereas the NSLP of 
| interest is only
| > | > supported by A and B. Once the link A-B is broken, the NTLP A-B
| > | > isn't refreshed while the NSLP A-B could easily maintain state
| > | > via A-C-B communication.
| > | >
| > | > How does your system react in this case? It is of no 
| importance to
| > | > the NSLP B that NTLP B lost connectivity to NTLP A.
| > | >
| > | > Regards, Rüdiger
| > | >
| > | >
| > |
| >
| 
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Thu May 15 07:57:23 2003
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 HAA05242
	for <nsis-archive@odin.ietf.org>; Thu, 15 May 2003 07:57:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4FBOLv23291
	for nsis-archive@odin.ietf.org; Thu, 15 May 2003 07:24:21 -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 h4FBOEB23280;
	Thu, 15 May 2003 07:24:14 -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 h4FBNsB23209
	for <nsis@optimus.ietf.org>; Thu, 15 May 2003 07:23:54 -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 HAA05195
	for <nsis@ietf.org>; Thu, 15 May 2003 07:56:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GHNK-0006JF-00
	for nsis@ietf.org; Thu, 15 May 2003 07:58:18 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GHNJ-0006JC-00
	for nsis@ietf.org; Thu, 15 May 2003 07:58:18 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4FBvC5s000975;
	Thu, 15 May 2003 13:58:06 +0200 (MET DST)
Message-ID: <009301c31ad9$402be5f0$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB463@G8PQD.blf01.telekom.de>
Subject: Re: [NSIS] state management and the nsis framework
Date: Thu, 15 May 2003 13:57:14 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id h4FBvC5s000975
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4FBNsB23210
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>
Content-Transfer-Encoding: 8bit

Hi Ruediger

I tried to emphasize that the network configuration example
that you used, in many situations cannot be considered as a
network configuration applied in NSIS.

Now to answer to your question.
If I would assume that the network configuration in your example is a
realistic one and that it can be considered as a generic network
configuration
used in NSIS then yes, it is of no
importance to the NSLP B that NTLP B lost connectivity to NTLP A.
But in my opinion this would be the same way of thinking if one would
assume that failures never occur in the Internet
and that soft state management procedures are not needed
at all.

Best Regards,
Georgios

----- Original Message -----
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: <karagian@cs.utwente.nl>
Cc: <nsis@ietf.org>
Sent: Thursday, May 15, 2003 11:49 AM
Subject: RE: [NSIS] state management and the nsis framework


> Hello Georgios,
>
> assume A-B to be replaced by A-C-B. You've changed
> my example in your reply and I'd prefer if you'd
> answer my original question.
>
> Regards, Rüdiger
>
>
> | -----Original Message-----
> | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
> | Sent: Thursday, May 15, 2003 10:14 AM
> | To: Geib, Rüdiger
> | Cc: nsis@ietf.org
> | Subject: Re: [NSIS] state management and the nsis framework
> |
> |
> | Hi Ruediger
> |
> | Okay, thus you are assuming that a re-routing takes place!
> |
> | But if (A) and (B) are not end nodes, and the following network
> | configuration is used:
> | Before re-routing:
> | (D = end node) <->(E)<->(F)<->(A)<->(B)<->(G)<->(H)<->(Z= end node)
> |
> | After rerouting (due to failure of link (A)<->(B)) the
> | following network
> | configuration can be chosen
> | by the applied dynamic routing protocol:
> |
> | (D = end node) <->(E)<->(F)<->(A)<->(C)<->(I)<->(H)<->(Z= end node)
> |
> |
> | Consider that  the nodes (D), (E), (F), (A), (B), (G), (H),
> | (Z) and (I) can
> | support both NTLP and
> | NSLP protocols. Node (C) as you already proposed supports
> | only the NTLP
> | protocol and not
> | the NSLP protocol.
> | Due to failure of the link (A)<->(B) a re-routing takes place.
> | When the path coupled signaling is used, the new re-routed
> | forwarding path
> | will be (mainly)
> | chosen by the applied dynamic routing protocol.
> | It may happen that the new re-routed path is not at all
> | passing through node
> | (B).
> | This means that the old NSLP state stored  in node (B) before
> | re-routing
> | will remain
> | there for "ever" (if of course no other soft state management
> | solution is
> | applied).
> |
> | Therefore, I think that in many situations, if a re-routing
> | takes place it
> | will
> | affect both the NTLP and NSLP state management procedures.
> | Thus not only the NTLP state management.
> |
> | Best Regards,
> | Georgios
> |
> |
> |
> | ----- Original Message -----
> | From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
> | To: <karagian@cs.utwente.nl>
> | Sent: Thursday, May 15, 2003 8:29 AM
> | Subject: RE: [NSIS] state management and the nsis framework
> |
> |
> | > Hi Georgios,
> | >
> | > I'm assuming it to be standard Internet architecture.
> | > There's a best route between A and B. A broken link
> | > results in a new best route bewteen A and B.
> | >
> | > Regards, Rüdiger
> | >
> | > | I do not completely understand the depicted scenario.
> | > | Are you trying to say that there are two paths between A and
> | > | B that are used
> | > | simultaneously:
> | > | One is the direct path A-B and the other is the path A-C-B.
> | > | Considering that this is not a load sharing solution,
> | > | is this scenario realistic?
> | > |
> | > | Best Regards,
> | > | Georgios
> | > |
> | > |
> | > | ----- Original Message -----
> | > | From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
> | > | To: <karagian@cs.utwente.nl>
> | > | Cc: <nsis@ietf.org>
> | > | Sent: Wednesday, May 14, 2003 1:43 PM
> | > | Subject: RE: [NSIS] state management and the nsis framework
> | > |
> | > |
> | > | > Hi Georgios
> | > | >
> | > | > | If a NTLP state is not refreshed in time the NSLP instance
> | > | > | is informed about it. Otherwise the NSLP instance
> | > | > | assumes that the NTLP state is alive.
> | > | >
> | > | >    +---C---+
> | > | >   /         \
> | > | >  A-----------B
> | > | >
> | > | > Assume A, B, C to support NTLP, whereas the NSLP of
> | interest is only
> | > | > supported by A and B. Once the link A-B is broken, the NTLP A-B
> | > | > isn't refreshed while the NSLP A-B could easily maintain state
> | > | > via A-C-B communication.
> | > | >
> | > | > How does your system react in this case? It is of no
> | importance to
> | > | > the NSLP B that NTLP B lost connectivity to NTLP A.
> | > | >
> | > | > Regards, Rüdiger
> | > | >
> | > | >
> | > |
> | >
> |
>

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



From mailnull@www1.ietf.org  Thu May 15 08:27:26 2003
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 IAA06699
	for <nsis-archive@odin.ietf.org>; Thu, 15 May 2003 08:27:26 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4FBsPG25700
	for nsis-archive@odin.ietf.org; Thu, 15 May 2003 07:54:25 -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 h4FBsJB25692;
	Thu, 15 May 2003 07:54:19 -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 h4FBrBB25638
	for <nsis@optimus.ietf.org>; Thu, 15 May 2003 07:53:11 -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 IAA06628
	for <nsis@ietf.org>; Thu, 15 May 2003 08:25:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GHpf-0006om-00
	for nsis@ietf.org; Thu, 15 May 2003 08:27:35 -0400
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GHpe-0006oS-00
	for nsis@ietf.org; Thu, 15 May 2003 08:27:34 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 15 May 2003 14:27:52 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <KZD1RML5>; Thu, 15 May 2003 14:27:51 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
Cc: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Thu, 15 May 2003 14:27:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4FBrBB25639
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>
Content-Transfer-Encoding: 8bit

Hi Georgios,

To repeat:

G| If a NTLP state is not refreshed in time the NSLP instance 
G| is informed about it. Otherwise the NSLP instance 
G| assumes that the NTLP state is alive.

R|   +---C---+
R|  /         \
R| A-----------B

R| Assume A, B, C to support NTLP, whereas the NSLP of interest is only 
R| supported by A and B. Once the link A-B is broken, the NTLP A-B
R| isn't refreshed while the NSLP A-B could easily maintain state 
R| via A-C-B communication.

G|...yes, it is of no
G| importance to the NSLP B that NTLP B lost connectivity to NTLP A.

I'd like to come back to my question: Could you kindly tell me how your
system reacts in this case? 

G| I tried to emphasize that the network configuration example
G| that you used, in many situations cannot be considered as a
G| network configuration applied in NSIS.

Could you provide a refernce to an NSIS WG document with the network 
configurations to be applied by NSIS in most situations?

Regards, Rüdiger
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Thu May 15 09:21:17 2003
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 JAA08263
	for <nsis-archive@odin.ietf.org>; Thu, 15 May 2003 09:21:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4FCmH130431
	for nsis-archive@odin.ietf.org; Thu, 15 May 2003 08:48:17 -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 h4FCmBB30419;
	Thu, 15 May 2003 08:48:11 -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 h4FCl7B30358
	for <nsis@optimus.ietf.org>; Thu, 15 May 2003 08:47:07 -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 JAA08208
	for <nsis@ietf.org>; Thu, 15 May 2003 09:19:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GIfq-0007E7-00
	for nsis@ietf.org; Thu, 15 May 2003 09:21:30 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19GIfq-0007E4-00
	for nsis@ietf.org; Thu, 15 May 2003 09:21:30 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4FDMU5s004303;
	Thu, 15 May 2003 15:22:37 +0200 (MET DST)
Message-ID: <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de>
Subject: Re: [NSIS] state management and the nsis framework
Date: Thu, 15 May 2003 15:22:32 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Ruediger

[RG]
> I'd like to come back to my question: Could you kindly tell me how your
> system reacts in this case?

[GK]
If I would assume that the network configuration in your example is a
realistic one and that it can be considered as a generic network
configuration used in NSIS then:

Assuming that the link (A)<->(B) fails, and
If the re-routing time is higher than the refresh timer used by the
NTLP protocol at node (B) then the NTLP and  NSLP states
could be tear down. If the re-routing time is less than the refresh timer
used by the
NTLP  protocol at node (B) then the NTLP and NSLP states
could be maintained.
However, if due to the failure at link (A)<->(B) the NTLP and NSLP state at
node (B)  are tear down,
then the NTLP and NSLP states at node (B) will be re-initiated after
re-routing.
---------------------------------------------

[RG]
> Could you provide a reference to an NSIS WG document with the network
> configurations to be applied by NSIS in most situations?

[GK]
The network configuration to be applied by NSIS in most situations is
a generic Internet architecture, where path coupled signaling is used
to route NSIS signaling messages. Meaning that in most situations the path
that is
followed by NSIS signaling messages
is defined by a typical dynamic routing protocol.
Such a situation is depicted in the example that I provided.
----------------------------------

If I understood you correctly,  you try to say that a route change will
mainly affect the NTLP soft
state management and not the NSLP soft state management.
What I am trying to say is that in many situations a route change will
affect both NTLP and NSLP
soft state management procedures.

Best Regards,
Georgios





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



From mailnull@www1.ietf.org  Fri May 16 11:19:01 2003
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 LAA28845
	for <nsis-archive@odin.ietf.org>; Fri, 16 May 2003 11:19:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4GEkXT17262
	for nsis-archive@odin.ietf.org; Fri, 16 May 2003 10:46:33 -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 h4GEkRB17247;
	Fri, 16 May 2003 10:46:27 -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 h4GEj7B17203
	for <nsis@optimus.ietf.org>; Fri, 16 May 2003 10:45:07 -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 LAA28751
	for <nsis@ietf.org>; Fri, 16 May 2003 11:17:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ggz3-0000Ka-00
	for nsis@ietf.org; Fri, 16 May 2003 11:18:57 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ggz2-0000KQ-00
	for nsis@ietf.org; Fri, 16 May 2003 11:18:56 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GFIDV20382;
	Fri, 16 May 2003 11:18:13 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KRLFVBRM; Fri, 16 May 2003 11:18:13 -0400
Received: from nortelnetworks.com (acart1eq.ca.nortel.com [47.129.129.132]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JQNA0J3N; Fri, 16 May 2003 11:18:13 -0400
Message-ID: <3EC5012E.7060200@nortelnetworks.com>
Date: Fri, 16 May 2003 11:18:06 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Georgios Karagiannis <karagian@cs.utwente.nl>
CC: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, nsis@ietf.org
Subject: Re: [NSIS] state management and the nsis framework
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl>
In-Reply-To: <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Georgios' example raises this question: is NTLP used to maintain the path between 
successive NSLP nodes, or is it used to maintain an end-to-end path which may 
traverse a variable set of NSLP nodes as a result of rerouting activity.  If the 
latter is the case, the implication for NSLP is that there has to be a way to bring 
a new NSLP node into the picture (i.e. provide it with all the necessary state) 
quickly and also to clear state from NSLP nodes dropped from the path.

Just to restate my point: does NTLP control which NSLP nodes are in the end-to-end 
path, or does NSLP (i.e. the specific signalling application) do so?

Georgios Karagiannis wrote:
> Hi Ruediger
> 
> [RG]
> 
>>I'd like to come back to my question: Could you kindly tell me how your
>>system reacts in this case?
> 
> 
> [GK]
> If I would assume that the network configuration in your example is a
> realistic one and that it can be considered as a generic network
> configuration used in NSIS then:
> 
> Assuming that the link (A)<->(B) fails, and
> If the re-routing time is higher than the refresh timer used by the
> NTLP protocol at node (B) then the NTLP and  NSLP states
> could be tear down. If the re-routing time is less than the refresh timer
> used by the
> NTLP  protocol at node (B) then the NTLP and NSLP states
> could be maintained.
> However, if due to the failure at link (A)<->(B) the NTLP and NSLP state at
> node (B)  are tear down,
> then the NTLP and NSLP states at node (B) will be re-initiated after
> re-routing.
> ---------------------------------------------
> 
> [RG]
> 
>>Could you provide a reference to an NSIS WG document with the network
>>configurations to be applied by NSIS in most situations?
> 
> 
> [GK]
> The network configuration to be applied by NSIS in most situations is
> a generic Internet architecture, where path coupled signaling is used
> to route NSIS signaling messages. Meaning that in most situations the path
> that is
> followed by NSIS signaling messages
> is defined by a typical dynamic routing protocol.
> Such a situation is depicted in the example that I provided.
> ----------------------------------
> 
> If I understood you correctly,  you try to say that a route change will
> mainly affect the NTLP soft
> state management and not the NSLP soft state management.
> What I am trying to say is that in many situations a route change will
> affect both NTLP and NSLP
> soft state management procedures.
> 
> 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



From mailnull@www1.ietf.org  Mon May 19 06:35:47 2003
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 GAA14416
	for <nsis-archive@odin.ietf.org>; Mon, 19 May 2003 06:35:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4JA4eF03153
	for nsis-archive@odin.ietf.org; Mon, 19 May 2003 06:04:40 -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 h4JA4YB03121;
	Mon, 19 May 2003 06:04:34 -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 h4JA14B03003
	for <nsis@optimus.ietf.org>; Mon, 19 May 2003 06:01:04 -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 GAA14331
	for <nsis@ietf.org>; Mon, 19 May 2003 06:31:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19HhxQ-0001cj-00
	for nsis@ietf.org; Mon, 19 May 2003 06:33:28 -0400
Received: from infres.enst.fr ([137.194.192.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19HhxQ-0001cZ-00
	for nsis@ietf.org; Mon, 19 May 2003 06:33:28 -0400
Received: from luu (dhcp7-211.enst.fr [137.194.7.211])
	by infres.enst.fr (Postfix) with SMTP id 8145A19AB
	for <nsis@ietf.org>; Mon, 19 May 2003 12:34:05 +0200 (MEST)
Message-ID: <00a001c31df2$636720e0$d307c289@enst.fr>
From: "Thanh Tra LUU" <luu@enst.fr>
To: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Mon, 19 May 2003 12:35:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Tom Taylor,

It's clear that NTLP only has the scope on its peer-relation (the NSIS
adjacent entity and there is no other NEs between).  NTLP is the means for
NSLP to establish the E2E signaling on peer-relation.

According to me, Georgios' example is an one of the general case : there is
a change of topology (change of routing table, interruption, mobile...).

regards

Nary Tra
ENST, Paris
Tel (0033) (0)1 45 81 71 06.

----- Original Message -----
From: "Tom Taylor" <taylor@nortelnetworks.com>
To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
Cc: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>; <nsis@ietf.org>
Sent: Friday, May 16, 2003 5:18 PM
Subject: Re: [NSIS] state management and the nsis framework


> Georgios' example raises this question: is NTLP used to maintain the path
between
> successive NSLP nodes, or is it used to maintain an end-to-end path which
may
> traverse a variable set of NSLP nodes as a result of rerouting activity.
If the
> latter is the case, the implication for NSLP is that there has to be a way
to bring
> a new NSLP node into the picture (i.e. provide it with all the necessary
state)
> quickly and also to clear state from NSLP nodes dropped from the path.
>
> Just to restate my point: does NTLP control which NSLP nodes are in the
end-to-end
> path, or does NSLP (i.e. the specific signalling application) do so?



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



From mailnull@www1.ietf.org  Tue May 20 14:16:16 2003
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 OAA23793
	for <nsis-archive@odin.ietf.org>; Tue, 20 May 2003 14:16:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4KHgfq22156
	for nsis-archive@odin.ietf.org; Tue, 20 May 2003 13:42:41 -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 h4KHgYB22145;
	Tue, 20 May 2003 13:42:34 -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 h4KHfoB22099
	for <nsis@optimus.ietf.org>; Tue, 20 May 2003 13:41:50 -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 OAA23733
	for <nsis@ietf.org>; Tue, 20 May 2003 14:14:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IBcE-0007PR-00
	for nsis@ietf.org; Tue, 20 May 2003 14:13:34 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IBcD-0007P7-00
	for nsis@ietf.org; Tue, 20 May 2003 14:13:33 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KIEJJ27603;
	Tue, 20 May 2003 14:14:19 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KRLFWKGH; Tue, 20 May 2003 14:14:19 -0400
Received: from nortelnetworks.com (taylor-2.ca.nortel.com [47.129.171.7]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JQNA0K3L; Tue, 20 May 2003 14:14:19 -0400
Message-ID: <3ECA7073.2080806@nortelnetworks.com>
Date: Tue, 20 May 2003 14:14:11 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Thanh Tra LUU <luu@enst.fr>
CC: nsis@ietf.org
Subject: Re: [NSIS] state management and the nsis framework
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr>
In-Reply-To: <00a001c31df2$636720e0$d307c289@enst.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

I think the consequences of what you're saying are that if there is a change of 
topology at the transport level:

1) at each node where the NSLP application is present, NTLP must notify the NSLP 
application that a change has occurred.  I assume indications of change are 
propagated between NTLP nodes along the path, so NTLP nodes remote from the point of 
change are aware of the change;

2) it is up to the NSLP application to reestablish topology at its own level;

3) contrary to what George has been proposing, it is therefore not possible to 
expect NTLP to refresh NSLP soft state.

Thanh Tra LUU wrote:
> Hi Tom Taylor,
> 
> It's clear that NTLP only has the scope on its peer-relation (the NSIS
> adjacent entity and there is no other NEs between).  NTLP is the means for
> NSLP to establish the E2E signaling on peer-relation.
> 
> According to me, Georgios' example is an one of the general case : there is
> a change of topology (change of routing table, interruption, mobile...).
> 
> regards
> 
> Nary Tra
> ENST, Paris
> Tel (0033) (0)1 45 81 71 06.
> 
> ----- Original Message -----
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
> Cc: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>; <nsis@ietf.org>
> Sent: Friday, May 16, 2003 5:18 PM
> Subject: Re: [NSIS] state management and the nsis framework
> 
>
> 
>>Georgios' example raises this question: is NTLP used to maintain the path
> 
> between
> 
>>successive NSLP nodes, or is it used to maintain an end-to-end path which
> 
> may
> 
>>traverse a variable set of NSLP nodes as a result of rerouting activity.
> 
> If the
> 
>>latter is the case, the implication for NSLP is that there has to be a way
> 
> to bring
> 
>>a new NSLP node into the picture (i.e. provide it with all the necessary
> 
> state)
> 
>>quickly and also to clear state from NSLP nodes dropped from the path.
>>
>>Just to restate my point: does NTLP control which NSLP nodes are in the
> 
> end-to-end
> 
>>path, or does NSLP (i.e. the specific signalling application) do so?
> 
> 
> 
> 
> _______________________________________________
> 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



From mailnull@www1.ietf.org  Wed May 21 03:50:19 2003
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 DAA11293
	for <nsis-archive@odin.ietf.org>; Wed, 21 May 2003 03:50:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4L7H0C24391
	for nsis-archive@odin.ietf.org; Wed, 21 May 2003 03:17:00 -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 h4L7GtB24386;
	Wed, 21 May 2003 03:16:55 -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 h4L7FbB24335
	for <nsis@optimus.ietf.org>; Wed, 21 May 2003 03:15:38 -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 DAA11290
	for <nsis@ietf.org>; Wed, 21 May 2003 03:48:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IOJV-00049h-00
	for nsis@ietf.org; Wed, 21 May 2003 03:47:05 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IOJU-00049e-00
	for nsis@ietf.org; Wed, 21 May 2003 03:47:04 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4L7mM5s020066;
	Wed, 21 May 2003 09:48:22 +0200 (MET DST)
Message-ID: <000a01c31f6d$5b942e40$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Tom Taylor" <taylor@nortelnetworks.com>
Cc: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr> <3ECA7073.2080806@nortelnetworks.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 21 May 2003 09:48:23 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Tom

Please note that the data path is using for routing,
typical dynamic routing protocols, e.g., OSPF.
In a path coupled signaling protocol, (i.e.,
on-path signaling protocol) the signaling protocol has to actually use
the same (on a coupled manner) path as the path used by the
data path.
This means that the NSLP protocol cannot change the network topology that
is used by the data path.

Best Regards,
Georgios

----- Original Message -----
From: "Tom Taylor" <taylor@nortelnetworks.com>
To: "Thanh Tra LUU" <luu@enst.fr>
Cc: <nsis@ietf.org>
Sent: Tuesday, May 20, 2003 8:14 PM
Subject: Re: [NSIS] state management and the nsis framework


> I think the consequences of what you're saying are that if there is a
change of
> topology at the transport level:
>
> 1) at each node where the NSLP application is present, NTLP must notify
the NSLP
> application that a change has occurred.  I assume indications of change
are
> propagated between NTLP nodes along the path, so NTLP nodes remote from
the point of
> change are aware of the change;
>
> 2) it is up to the NSLP application to reestablish topology at its own
level;
>
> 3) contrary to what George has been proposing, it is therefore not
possible to
> expect NTLP to refresh NSLP soft state.
>
> Thanh Tra LUU wrote:
> > Hi Tom Taylor,
> >
> > It's clear that NTLP only has the scope on its peer-relation (the NSIS
> > adjacent entity and there is no other NEs between).  NTLP is the means
for
> > NSLP to establish the E2E signaling on peer-relation.
> >
> > According to me, Georgios' example is an one of the general case : there
is
> > a change of topology (change of routing table, interruption, mobile...).
> >
> > regards
> >
> > Nary Tra
> > ENST, Paris
> > Tel (0033) (0)1 45 81 71 06.
> >
> > ----- Original Message -----
> > From: "Tom Taylor" <taylor@nortelnetworks.com>
> > To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
> > Cc: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>; <nsis@ietf.org>
> > Sent: Friday, May 16, 2003 5:18 PM
> > Subject: Re: [NSIS] state management and the nsis framework
> >
> >
> >
> >>Georgios' example raises this question: is NTLP used to maintain the
path
> >
> > between
> >
> >>successive NSLP nodes, or is it used to maintain an end-to-end path
which
> >
> > may
> >
> >>traverse a variable set of NSLP nodes as a result of rerouting activity.
> >
> > If the
> >
> >>latter is the case, the implication for NSLP is that there has to be a
way
> >
> > to bring
> >
> >>a new NSLP node into the picture (i.e. provide it with all the necessary
> >
> > state)
> >
> >>quickly and also to clear state from NSLP nodes dropped from the path.
> >>
> >>Just to restate my point: does NTLP control which NSLP nodes are in the
> >
> > end-to-end
> >
> >>path, or does NSLP (i.e. the specific signalling application) do so?
> >
> >
> >
> >
> > _______________________________________________
> > 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



From mailnull@www1.ietf.org  Wed May 21 07:44:03 2003
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 HAA15242
	for <nsis-archive@odin.ietf.org>; Wed, 21 May 2003 07:44:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4LBAnc07958
	for nsis-archive@odin.ietf.org; Wed, 21 May 2003 07:10:49 -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 h4LBAdB07949;
	Wed, 21 May 2003 07:10:39 -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 h4LB8wB07901
	for <nsis@optimus.ietf.org>; Wed, 21 May 2003 07:08:58 -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 HAA15211
	for <nsis@ietf.org>; Wed, 21 May 2003 07:41:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IRxF-00055E-00
	for nsis@ietf.org; Wed, 21 May 2003 07:40:21 -0400
Received: from infres.enst.fr ([137.194.192.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IRxE-00055B-00
	for nsis@ietf.org; Wed, 21 May 2003 07:40:21 -0400
Received: from luu (dhcp7-211.enst.fr [137.194.7.211])
	by infres.enst.fr (Postfix) with SMTP id DA6EE1895
	for <nsis@ietf.org>; Wed, 21 May 2003 13:41:39 +0200 (MEST)
Message-ID: <004a01c31f8d$c7a169c0$d307c289@enst.fr>
From: "Thanh Tra LUU" <luu@enst.fr>
To: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr> <3ECA7073.2080806@nortelnetworks.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 21 May 2003 13:40:28 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Tom Taylor,

> 1) at each node where the NSLP application is present, NTLP must notify
the NSLP
> application that a change has occurred.  I assume indications of change
are
> propagated between NTLP nodes along the path, so NTLP nodes remote from
the point of
> change are aware of the change;

Yes, NTLP notifies NSLP that a change has occurred. Please note that, there
can be a lot of  different NSLPs on a NTLP, so I think it can notify only
some NSLPs.

------------                                      ----------
|   NSLP   |                                     |   NSLP   |
-----------         ------------             ----------
|  NTLP   |  == |   NTLP   | ===== |    NTLP  |
-----------        -----------              ------------
            <------                <--------

   A                      B                            C.

Even though B is not a NSLP-aware, the indications of change are still
propaged to A.

> 2) it is up to the NSLP application to reestablish topology at its own
level

I don't know what the word reestablish topology means, do you mean
reestablish a new signalling route ? If you mean reestablish a new
signalling route, I think that's better if it's up to NSLP.

> 3) contrary to what George has been proposing, it is therefore not
possible to
> expect NTLP to refresh NSLP soft state.

Yes, I think so.


regards

 Nary Tra
ENST, Paris
Tel (0033) (0)1 45 81 71 06.


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



From mailnull@www1.ietf.org  Wed May 21 08:31:37 2003
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 IAA16791
	for <nsis-archive@odin.ietf.org>; Wed, 21 May 2003 08:31:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4LBwOa11270
	for nsis-archive@odin.ietf.org; Wed, 21 May 2003 07:58:24 -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 h4LBwGB11257;
	Wed, 21 May 2003 07:58:16 -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 h4LBvWB11183
	for <nsis@optimus.ietf.org>; Wed, 21 May 2003 07:57:32 -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 IAA16735
	for <nsis@ietf.org>; Wed, 21 May 2003 08:30:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ISiE-0005Ok-00
	for nsis@ietf.org; Wed, 21 May 2003 08:28:54 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ISiD-0005OZ-00
	for nsis@ietf.org; Wed, 21 May 2003 08:28:53 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LCTZF21824;
	Wed, 21 May 2003 08:29:35 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KRLFWZ2P; Wed, 21 May 2003 08:29:35 -0400
Received: from nortelnetworks.com (acart1ck.ca.nortel.com [47.129.129.62]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JQNA0KVT; Wed, 21 May 2003 08:29:35 -0400
Message-ID: <3ECB712D.7060909@nortelnetworks.com>
Date: Wed, 21 May 2003 08:29:33 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Georgios Karagiannis <karagian@cs.utwente.nl>
CC: nsis@ietf.org
Subject: Re: [NSIS] state management and the nsis framework
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr> <3ECA7073.2080806@nortelnetworks.com> <000a01c31f6d$5b942e40$4c0d5982@dynamic.cs.utwente.nl>
In-Reply-To: <000a01c31f6d$5b942e40$4c0d5982@dynamic.cs.utwente.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

As I see it, there are two topologies: the sequence of NTLP nodes can be 
distinguished from the sequence of NSLP nodes for a particular application. 
Obviously these are linked, but to the extent that you can have intervening NTLP 
nodes that do not also support the particular NSLP application, the NTLP topology 
can change while leaving the NSLP-level topology intact.  For this to happen, NTLP 
would have to have maintenance of the NSLP topology as an explicit goal.  That is, 
in the event of a break, NTLP searches for an alternate route to the next NSLP node, 
for which it has an address.

If and only if NTLP cannot heal the break at its level, it notifies the NSLP 
application, which must then initiate its own recovery action.  That is where quick 
updating of new NSLP nodes and automatic dropping of stale state in NSLP nodes lost 
from the path become requirements.

Do I have the right picture?

Georgios Karagiannis wrote:
> Hi Tom
> 
> Please note that the data path is using for routing,
> typical dynamic routing protocols, e.g., OSPF.
> In a path coupled signaling protocol, (i.e.,
> on-path signaling protocol) the signaling protocol has to actually use
> the same (on a coupled manner) path as the path used by the
> data path.
> This means that the NSLP protocol cannot change the network topology that
> is used by the data path.
> 
> Best Regards,
> Georgios
> 
> ----- Original Message -----
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Thanh Tra LUU" <luu@enst.fr>
> Cc: <nsis@ietf.org>
> Sent: Tuesday, May 20, 2003 8:14 PM
> Subject: Re: [NSIS] state management and the nsis framework
> 
> 
> 
>>I think the consequences of what you're saying are that if there is a
> 
> change of
> 
>>topology at the transport level:
>>
>>1) at each node where the NSLP application is present, NTLP must notify
> 
> the NSLP
> 
>>application that a change has occurred.  I assume indications of change
> 
> are
> 
>>propagated between NTLP nodes along the path, so NTLP nodes remote from
> 
> the point of
> 
>>change are aware of the change;
>>
>>2) it is up to the NSLP application to reestablish topology at its own
> 
> level;
> 
>>3) contrary to what George has been proposing, it is therefore not
> 
> possible to
> 
>>expect NTLP to refresh NSLP soft state.
>>
>>Thanh Tra LUU wrote:
>>
>>>Hi Tom Taylor,
>>>
>>>It's clear that NTLP only has the scope on its peer-relation (the NSIS
>>>adjacent entity and there is no other NEs between).  NTLP is the means
> 
> for
> 
>>>NSLP to establish the E2E signaling on peer-relation.
>>>
>>>According to me, Georgios' example is an one of the general case : there
> 
> is
> 
>>>a change of topology (change of routing table, interruption, mobile...).
>>>
>>>regards
>>>
>>>Nary Tra
>>>ENST, Paris
>>>Tel (0033) (0)1 45 81 71 06.
>>>
>>>----- Original Message -----
>>>From: "Tom Taylor" <taylor@nortelnetworks.com>
>>>To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
>>>Cc: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>; <nsis@ietf.org>
>>>Sent: Friday, May 16, 2003 5:18 PM
>>>Subject: Re: [NSIS] state management and the nsis framework
>>>
>>>
>>>
>>>
>>>>Georgios' example raises this question: is NTLP used to maintain the
> 
> path
> 
>>>between
>>>
>>>
>>>>successive NSLP nodes, or is it used to maintain an end-to-end path
> 
> which
> 
>>>may
>>>
>>>
>>>>traverse a variable set of NSLP nodes as a result of rerouting activity.
>>>
>>>If the
>>>
>>>
>>>>latter is the case, the implication for NSLP is that there has to be a
> 
> way
> 
>>>to bring
>>>
>>>
>>>>a new NSLP node into the picture (i.e. provide it with all the necessary
>>>
>>>state)
>>>
>>>
>>>>quickly and also to clear state from NSLP nodes dropped from the path.
>>>>
>>>>Just to restate my point: does NTLP control which NSLP nodes are in the
>>>
>>>end-to-end
>>>
>>>
>>>>path, or does NSLP (i.e. the specific signalling application) do so?
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>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



From mailnull@www1.ietf.org  Wed May 21 09:43:34 2003
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 JAA20964
	for <nsis-archive@odin.ietf.org>; Wed, 21 May 2003 09:43:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4LDAMC18739
	for nsis-archive@odin.ietf.org; Wed, 21 May 2003 09:10:22 -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 h4LDAHB18733;
	Wed, 21 May 2003 09:10:17 -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 h4LD9xB18687
	for <nsis@optimus.ietf.org>; Wed, 21 May 2003 09:09:59 -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 JAA20940
	for <nsis@ietf.org>; Wed, 21 May 2003 09:42:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ITqJ-0006mq-00
	for nsis@ietf.org; Wed, 21 May 2003 09:41:19 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ITqI-0006mn-00
	for nsis@ietf.org; Wed, 21 May 2003 09:41:18 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4LDga5s004762;
	Wed, 21 May 2003 15:42:36 +0200 (MET DST)
Message-ID: <000e01c31f9e$d8502250$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Tom Taylor" <taylor@nortelnetworks.com>
Cc: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr> <3ECA7073.2080806@nortelnetworks.com> <000a01c31f6d$5b942e40$4c0d5982@dynamic.cs.utwente.nl> <3ECB712D.7060909@nortelnetworks.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 21 May 2003 15:42:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Tom

I think that your description is right!
However, I do not know what kind of healing process you have
in mind. The soft state procedures can be considered as a healing process.
In my opinion, when, per signaling application, a NTLP state and a NSLP
state are used
within one NSIS entity then the NTLP and NSLP healing process(es), on each
NSIS entity,
are very much inter-related.
Thus quick updating of new NSLP nodes and automatic dropping of stale state
in NSLP nodes lost
from the path are signifficant issues.

Best Regards,
Georgios




----- Original Message -----
From: "Tom Taylor" <taylor@nortelnetworks.com>
To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
Cc: <nsis@ietf.org>
Sent: Wednesday, May 21, 2003 2:29 PM
Subject: Re: [NSIS] state management and the nsis framework


> As I see it, there are two topologies: the sequence of NTLP nodes can be
> distinguished from the sequence of NSLP nodes for a particular
application.
> Obviously these are linked, but to the extent that you can have
intervening NTLP
> nodes that do not also support the particular NSLP application, the NTLP
topology
> can change while leaving the NSLP-level topology intact.  For this to
happen, NTLP
> would have to have maintenance of the NSLP topology as an explicit goal.
That is,
> in the event of a break, NTLP searches for an alternate route to the next
NSLP node,
> for which it has an address.
>
> If and only if NTLP cannot heal the break at its level, it notifies the
NSLP
> application, which must then initiate its own recovery action.  That is
where quick
> updating of new NSLP nodes and automatic dropping of stale state in NSLP
nodes lost
> from the path become requirements.
>
> Do I have the right picture?
>
> Georgios Karagiannis wrote:
> > Hi Tom
> >
> > Please note that the data path is using for routing,
> > typical dynamic routing protocols, e.g., OSPF.
> > In a path coupled signaling protocol, (i.e.,
> > on-path signaling protocol) the signaling protocol has to actually use
> > the same (on a coupled manner) path as the path used by the
> > data path.
> > This means that the NSLP protocol cannot change the network topology
that
> > is used by the data path.
> >
> > Best Regards,
> > Georgios
> >
> > ----- Original Message -----
> > From: "Tom Taylor" <taylor@nortelnetworks.com>
> > To: "Thanh Tra LUU" <luu@enst.fr>
> > Cc: <nsis@ietf.org>
> > Sent: Tuesday, May 20, 2003 8:14 PM
> > Subject: Re: [NSIS] state management and the nsis framework
> >
> >
> >
> >>I think the consequences of what you're saying are that if there is a
> >
> > change of
> >
> >>topology at the transport level:
> >>
> >>1) at each node where the NSLP application is present, NTLP must notify
> >
> > the NSLP
> >
> >>application that a change has occurred.  I assume indications of change
> >
> > are
> >
> >>propagated between NTLP nodes along the path, so NTLP nodes remote from
> >
> > the point of
> >
> >>change are aware of the change;
> >>
> >>2) it is up to the NSLP application to reestablish topology at its own
> >
> > level;
> >
> >>3) contrary to what George has been proposing, it is therefore not
> >
> > possible to
> >
> >>expect NTLP to refresh NSLP soft state.
> >>
> >>Thanh Tra LUU wrote:
> >>
> >>>Hi Tom Taylor,
> >>>
> >>>It's clear that NTLP only has the scope on its peer-relation (the NSIS
> >>>adjacent entity and there is no other NEs between).  NTLP is the means
> >
> > for
> >
> >>>NSLP to establish the E2E signaling on peer-relation.
> >>>
> >>>According to me, Georgios' example is an one of the general case :
there
> >
> > is
> >
> >>>a change of topology (change of routing table, interruption,
mobile...).
> >>>
> >>>regards
> >>>
> >>>Nary Tra
> >>>ENST, Paris
> >>>Tel (0033) (0)1 45 81 71 06.
> >>>
> >>>----- Original Message -----
> >>>From: "Tom Taylor" <taylor@nortelnetworks.com>
> >>>To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
> >>>Cc: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>; <nsis@ietf.org>
> >>>Sent: Friday, May 16, 2003 5:18 PM
> >>>Subject: Re: [NSIS] state management and the nsis framework
> >>>
> >>>
> >>>
> >>>
> >>>>Georgios' example raises this question: is NTLP used to maintain the
> >
> > path
> >
> >>>between
> >>>
> >>>
> >>>>successive NSLP nodes, or is it used to maintain an end-to-end path
> >
> > which
> >
> >>>may
> >>>
> >>>
> >>>>traverse a variable set of NSLP nodes as a result of rerouting
activity.
> >>>
> >>>If the
> >>>
> >>>
> >>>>latter is the case, the implication for NSLP is that there has to be a
> >
> > way
> >
> >>>to bring
> >>>
> >>>
> >>>>a new NSLP node into the picture (i.e. provide it with all the
necessary
> >>>
> >>>state)
> >>>
> >>>
> >>>>quickly and also to clear state from NSLP nodes dropped from the path.
> >>>>
> >>>>Just to restate my point: does NTLP control which NSLP nodes are in
the
> >>>
> >>>end-to-end
> >>>
> >>>
> >>>>path, or does NSLP (i.e. the specific signalling application) do so?
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>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
>

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



From mailnull@www1.ietf.org  Wed May 21 11:19:49 2003
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 LAA25042
	for <nsis-archive@odin.ietf.org>; Wed, 21 May 2003 11:19:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4LEkei27221
	for nsis-archive@odin.ietf.org; Wed, 21 May 2003 10:46:40 -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 h4LEkQB27215;
	Wed, 21 May 2003 10:46:26 -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 h4LEjkB27153
	for <nsis@optimus.ietf.org>; Wed, 21 May 2003 10:45:46 -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 LAA25011
	for <nsis@ietf.org>; Wed, 21 May 2003 11:18:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IVKx-0007aE-00
	for nsis@ietf.org; Wed, 21 May 2003 11:17:04 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IVKx-0007Zc-00
	for nsis@ietf.org; Wed, 21 May 2003 11:17:03 -0400
Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LFHkF26292;
	Wed, 21 May 2003 11:17:46 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KRLFNF8N; Wed, 21 May 2003 11:17:46 -0400
Received: from nortelnetworks.com (acart1ck.ca.nortel.com [47.129.129.62]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JQNA0KYZ; Wed, 21 May 2003 11:17:46 -0400
Message-ID: <3ECB9890.1050203@nortelnetworks.com>
Date: Wed, 21 May 2003 11:17:36 -0400
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Georgios Karagiannis <karagian@cs.utwente.nl>
CC: nsis@ietf.org
Subject: Re: [NSIS] state management and the nsis framework
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr> <3ECA7073.2080806@nortelnetworks.com> <000a01c31f6d$5b942e40$4c0d5982@dynamic.cs.utwente.nl> <3ECB712D.7060909@nortelnetworks.com> <000e01c31f9e$d8502250$4c0d5982@dynamic.cs.utwente.nl>
In-Reply-To: <000e01c31f9e$d8502250$4c0d5982@dynamic.cs.utwente.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

I'm realizing as I think about it that various healing procedures are possible. 
Depending on the procedure, NTLP can act autonomously or NSLP would have to 
coordinate recovery.  I expect I'd better learn more about how these things are done 
in practice before I go further in my speculations.

So I'll drop this discussion, noting that we have agreed on two requirements at the 
NSLP level.

Georgios Karagiannis wrote:
> Hi Tom
> 
> I think that your description is right!
> However, I do not know what kind of healing process you have
> in mind. The soft state procedures can be considered as a healing process.
> In my opinion, when, per signaling application, a NTLP state and a NSLP
> state are used
> within one NSIS entity then the NTLP and NSLP healing process(es), on each
> NSIS entity,
> are very much inter-related.
> Thus quick updating of new NSLP nodes and automatic dropping of stale state
> in NSLP nodes lost
> from the path are signifficant issues.
> 
> Best Regards,
> Georgios
> 
> 
> 
> 
> ----- Original Message -----
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
> Cc: <nsis@ietf.org>
> Sent: Wednesday, May 21, 2003 2:29 PM
> Subject: Re: [NSIS] state management and the nsis framework
> 
>>As I see it, there are two topologies: the sequence of NTLP nodes can be
>>distinguished from the sequence of NSLP nodes for a particular 
>>application.  Obviously these are linked, but to the extent that you can have
>>intervening NTLP nodes that do not also support the particular NSLP application,
 >>the NTLP topology can change while leaving the NSLP-level topology intact.  For
 >>this to happen, NTLP would have to have maintenance of the NSLP topology as an
 >>explicit goal. That is, in the event of a break, NTLP searches for an alternate
 >>route to the next NSLP node, for which it has an address.
>>
>>If and only if NTLP cannot heal the break at its level, it notifies the
>>NSLP application, which must then initiate its own recovery action.  That is
>>where quick updating of new NSLP nodes and automatic dropping of stale state
 >>in NSLP nodes lost from the path become requirements.
>>
>>Do I have the right picture?
>>
...

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



From mailnull@www1.ietf.org  Wed May 21 14:51:56 2003
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 OAA01551
	for <nsis-archive@odin.ietf.org>; Wed, 21 May 2003 14:51:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4LIIoh06003
	for nsis-archive@odin.ietf.org; Wed, 21 May 2003 14:18:50 -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 h4LIIhB05972;
	Wed, 21 May 2003 14:18:43 -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 h4LIHvB05887
	for <nsis@optimus.ietf.org>; Wed, 21 May 2003 14:17:57 -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 OAA01353
	for <nsis@ietf.org>; Wed, 21 May 2003 14:50:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IYeF-0001It-00
	for nsis@ietf.org; Wed, 21 May 2003 14:49:11 -0400
Received: from infres.enst.fr ([137.194.192.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IYeE-0001Iq-00
	for nsis@ietf.org; Wed, 21 May 2003 14:49:10 -0400
Received: from luu (dhcp7-211.enst.fr [137.194.7.211])
	by infres.enst.fr (Postfix) with SMTP id C9713191B
	for <nsis@ietf.org>; Wed, 21 May 2003 20:50:31 +0200 (MEST)
Message-ID: <00b201c31fc9$36a6e260$d307c289@enst.fr>
From: "Thanh Tra LUU" <luu@enst.fr>
To: <nsis@ietf.org>
References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB464@G8PQD.blf01.telekom.de> <00a201c31ae5$0e6a8240$4c0d5982@dynamic.cs.utwente.nl> <3EC5012E.7060200@nortelnetworks.com> <00a001c31df2$636720e0$d307c289@enst.fr> <3ECA7073.2080806@nortelnetworks.com> <000a01c31f6d$5b942e40$4c0d5982@dynamic.cs.utwente.nl> <3ECB712D.7060909@nortelnetworks.com> <000e01c31f9e$d8502250$4c0d5982@dynamic.cs.utwente.nl> <3ECB9890.1050203@nortelnetworks.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Wed, 21 May 2003 20:45:55 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi Tom,

I agree with you about there are NSLP's topology and NTLP's topology. But
NLTP's topology changes then NSLP's topology can also change when NSLP can
"lay on" NTLP at some nodes. I don't think it's important to talk about
this, but just a justification.

> I'm realizing as I think about it that various healing procedures are
possible.
> Depending on the procedure, NTLP can act autonomously or NSLP would have
to
> coordinate recovery.  I expect I'd better learn more about how these
things are done
> in practice before I go further in my speculations.
>
> So I'll drop this discussion, noting that we have agreed on two
requirements at the
> NSLP level.


Best regards

Nary Tra
ENST, Paris
(0033) (0)1 45 81 71 06


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



From mailnull@www1.ietf.org  Thu May 22 04:57:24 2003
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 EAA05021
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 04:57:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4M8OaH13520
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 04:24:36 -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 h4M8OUB13511;
	Thu, 22 May 2003 04:24:30 -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 h4M8NlB13477
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 04:23:47 -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 EAA05008
	for <nsis@ietf.org>; Thu, 22 May 2003 04:56:05 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IlqV-0006kU-00
	for nsis@ietf.org; Thu, 22 May 2003 04:54:43 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IlqU-0006kR-00
	for nsis@ietf.org; Thu, 22 May 2003 04:54:42 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M8u2D06963
	for <nsis@ietf.org>; Thu, 22 May 2003 11:56:03 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625c228ba1ac158f24150@esvir04nok.ntc.nokia.com> for <nsis@ietf.org>;
 Thu, 22 May 2003 11:56:02 +0300
Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 11:56:02 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 11:55:59 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 22 May 2003 11:55:59 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBD1@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMfy4jiJWgwDsAjQwS06379urCrEwAdAbAw
To: <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2003 08:56:00.0133 (UTC) FILETIME=[F758DB50:01C3203F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M8NlB13478
Subject: [NSIS] WG update
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>
Content-Transfer-Encoding: 8bit

Hi all,

A short WG update.

The updated charter should be reviewed by the IESG at the next
conference call.  With any luck, it will be approved with
minimal changes.

The ADs have almost completed their AD review on the Requirements
document.  They initial comments are that the document looks good.

I will update you more when I hear more.

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



From mailnull@www1.ietf.org  Thu May 22 05:08:00 2003
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 FAA05204
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 05:08:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4M8ZCF13975
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 04:35:12 -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 h4M8Z6B13910;
	Thu, 22 May 2003 04:35:06 -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 h4M8STB13648
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 04:28:29 -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 FAA05096
	for <nsis@ietf.org>; Thu, 22 May 2003 05:00:47 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ilv3-0006lY-00
	for nsis@ietf.org; Thu, 22 May 2003 04:59:25 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ilv2-0006lV-00
	for nsis@ietf.org; Thu, 22 May 2003 04:59:24 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M90k712969
	for <nsis@ietf.org>; Thu, 22 May 2003 12:00:46 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625c26dcfbac158f25119@esvir05nok.ntc.nokia.com>;
 Thu, 22 May 2003 12:00:45 +0300
Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 12:00:46 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 12:00:09 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] state management and the nsis framework
Date: Thu, 22 May 2003 12:00:08 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBD2@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMfnvuH1fdXQtWkRYKc2weBaSKaOQAoS5gg
To: <karagian@cs.utwente.nl>, <taylor@nortelnetworks.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2003 09:00:09.0226 (UTC) FILETIME=[8BD16EA0:01C32040]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M8SUB13649
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>
Content-Transfer-Encoding: 8bit

Hi Georgios,

> I think that your description is right!
> However, I do not know what kind of healing process you have
> in mind. The soft state procedures can be considered as a healing process.
> In my opinion, when, per signaling application, a NTLP state and a NSLP
> state are used within one NSIS entity then the NTLP and NSLP healing 
> process(es), on each NSIS entity, are very much inter-related.
> Thus quick updating of new NSLP nodes and automatic dropping 
> of stale state in NSLP nodes lost from the path are signifficant issues.

Soft-state is definately a healing process, but in addition, I have always
imagined that a NSLP layer could undertake action if needed as well.  For
example, if an NSLP notices that there is some problem, it need not
wait for softstate timeout, before it undertakes corrective procedures.

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



From mailnull@www1.ietf.org  Thu May 22 05:12:03 2003
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 FAA05295
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 05:12:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4M8dFr15015
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 04:39:15 -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 h4M8d8B15000;
	Thu, 22 May 2003 04:39:08 -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 h4M8cSB14955
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 04:38:28 -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 FAA05267
	for <nsis@ietf.org>; Thu, 22 May 2003 05:10:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Im4h-0006oh-00
	for nsis@ietf.org; Thu, 22 May 2003 05:09:23 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Im4g-0006ob-00
	for nsis@ietf.org; Thu, 22 May 2003 05:09:22 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h4M9Ag5s009460
	for <nsis@ietf.org>; Thu, 22 May 2003 11:10:42 +0200 (MET DST)
Message-ID: <003501c32042$064ebe20$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: <nsis@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB32063658EBD2@esebe023.ntc.nokia.com>
Subject: Re: [NSIS] state management and the nsis framework
Date: Thu, 22 May 2003 11:10:44 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hi John

I agree!

Best Regards,
Georgios

----- Original Message -----
From: <john.loughney@nokia.com>
To: <karagian@cs.utwente.nl>; <taylor@nortelnetworks.com>
Cc: <nsis@ietf.org>
Sent: Thursday, May 22, 2003 11:00 AM
Subject: RE: [NSIS] state management and the nsis framework


> Hi Georgios,
>
> > I think that your description is right!
> > However, I do not know what kind of healing process you have
> > in mind. The soft state procedures can be considered as a healing
process.
> > In my opinion, when, per signaling application, a NTLP state and a NSLP
> > state are used within one NSIS entity then the NTLP and NSLP healing
> > process(es), on each NSIS entity, are very much inter-related.
> > Thus quick updating of new NSLP nodes and automatic dropping
> > of stale state in NSLP nodes lost from the path are signifficant issues.
>
> Soft-state is definately a healing process, but in addition, I have always
> imagined that a NSLP layer could undertake action if needed as well.  For
> example, if an NSLP notices that there is some problem, it need not
> wait for softstate timeout, before it undertakes corrective procedures.
>
> br,
> John
>

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



From mailnull@www1.ietf.org  Thu May 22 05:16:57 2003
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 FAA05419
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 05:16:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4M8i9x15368
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 04:44:09 -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 h4M8i4B15326;
	Thu, 22 May 2003 04:44:04 -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 h4M8h6B15248
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 04:43:06 -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 FAA05350
	for <nsis@ietf.org>; Thu, 22 May 2003 05:15:23 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Im9B-0006qi-00
	for nsis@ietf.org; Thu, 22 May 2003 05:14:01 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Im9B-0006qf-00
	for nsis@ietf.org; Thu, 22 May 2003 05:14:01 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M9FND02360
	for <nsis@ietf.org>; Thu, 22 May 2003 12:15:23 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625c343a8fac158f23168@esvir03nok.nokia.com> for <nsis@ietf.org>;
 Thu, 22 May 2003 12:15:21 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 12:15:21 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 12:15:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 22 May 2003 12:15:21 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBD6@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMfnvuH1fdXQtWkRYKc2weBaSKaOQAoS5ggAAB5YaA=
To: <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2003 09:15:21.0554 (UTC) FILETIME=[AB9BA320:01C32042]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M8h6B15249
Subject: [NSIS] IETF 57 Proposed Agenda
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>
Content-Transfer-Encoding: 8bit

Hi all,

I'm trying to get organized for the next IETF already.  I have requested
2 slots.  Our goals for the meeting should be:

1) Close off remaining issues with the Framework doc
2) Close off remaining issues with the Analysis doc
3) Close off remaining issue with Security Threats for NSIS & RSVP Security Properties
4) Focused discussion on the NTLP proposal (to be issued before the meeting)
5) Way forward with the NSLPs

So, I propose the following agenda.  With regards to the NLSP protocols, I know
that there will be several individual proposals.  I would like at the meeting
to gain consensus on how to go forward with those work items. Please comment
on the proposed agenda - positive & negative comments are welcome.

John


Day 1 (2.5 hour session)

Agenda bashing - 5 minutes
WG update & charter review - 25 minutes

NTLP review - 45 minutes

Framework update / review - 30 minutes
http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-02.txt

Analysis document review - 15 minutes
http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt

Security Threats for NSIS & RSVP Security Properties - 30 minutes
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt

Day 2
Agenda bashing - 5 minutes
NSLP QoS Signaling proposal - 20 minutes
NSLP MIDCOM Signaling proposal - 20 minutes
Wrap-up / other business - 15 minutes
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Thu May 22 05:20:59 2003
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 FAA05616
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 05:20:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4M8mB315722
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 04:48:11 -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 h4M8m7B15709;
	Thu, 22 May 2003 04:48: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 h4M8loB15680
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 04:47:50 -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 FAA05594
	for <nsis@ietf.org>; Thu, 22 May 2003 05:20:07 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ImDl-0006vo-00
	for nsis@ietf.org; Thu, 22 May 2003 05:18:45 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ImDk-0006vk-00
	for nsis@ietf.org; Thu, 22 May 2003 05:18:45 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M9K7708721
	for <nsis@ietf.org>; Thu, 22 May 2003 12:20:07 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625c389200ac158f25119@esvir05nok.ntc.nokia.com>;
 Thu, 22 May 2003 12:20:06 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 12:20:07 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 12:19:53 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 22 May 2003 12:19:49 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBD7@esebe023.ntc.nokia.com>
Thread-Topic: Security Threats for NSIS & RSVP Security Properties documents
Thread-Index: AcMgQ0tiq9Nf0yDRQ3aqvNh4FVNQMQ==
To: <nsis@ietf.org>
Cc: <Hannes.Tschofenig@mchp.siemens.de>
X-OriginalArrivalTime: 22 May 2003 09:19:53.0585 (UTC) FILETIME=[4DC04610:01C32043]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M8loB15682
Subject: [NSIS] Security Threats for NSIS & RSVP Security Properties documents
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>
Content-Transfer-Encoding: 8bit

Hi all,

I would like to gage WG opinion on the following documents:

Security Threats for NSIS 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt

RSVP Security Properties 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt

My question is, are they ready or soon to be ready for WG last call?
If anyone has open issues with them, please comment on them.  If you
have not read them, please do so.  These documents will have impact
upon the protocol work we will be doing.

Also, perhaps the editor of the documents could comment on this - 
Hannes, do you feel that either document is ready for WG last
call?

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



From mailnull@www1.ietf.org  Thu May 22 06:10:17 2003
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 GAA07043
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 06:10:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4M9bV320354
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 05:37:31 -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 h4M9bPB20174;
	Thu, 22 May 2003 05:37:25 -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 h4M9aeB19584
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 05:36:40 -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 GAA07015
	for <nsis@ietf.org>; Thu, 22 May 2003 06:08:56 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Imz1-0007Pt-00
	for nsis@ietf.org; Thu, 22 May 2003 06:07:35 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Imz0-0007Pq-00
	for nsis@ietf.org; Thu, 22 May 2003 06:07:34 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4MA8uD12225
	for <nsis@ietf.org>; Thu, 22 May 2003 13:08:57 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625c654927ac158f23168@esvir03nok.nokia.com> for <nsis@ietf.org>;
 Thu, 22 May 2003 13:08:56 +0300
Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 13:08:56 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 13:06:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 22 May 2003 13:05:41 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBE5@esebe023.ntc.nokia.com>
Thread-Topic: Security Threats for NSIS & RSVP Security Properties documents
Thread-Index: AcMgQ0tiq9Nf0yDRQ3aqvNh4FVNQMQABdf+Q
To: <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2003 10:06:12.0778 (UTC) FILETIME=[C64778A0:01C32049]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M9aeB19585
Subject: [NSIS] Draft cut-offs & new procedure for IETF 57
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>
Content-Transfer-Encoding: 8bit

Hi all,

The draft cut-off dates fore IETF 57 are as follows:

June 23, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET
June 30, Monday - Internet Draft final submission cut-off at 09:00 ET

In addition, the Internet-Drafts Administrator has instituted a new policy
that all new WG drafts (i.e. -00.txt versions) need to be approved by
the chair ahead of time. 

All those people planning on submitting new documents, even individual
drafts, please let me know what you are planning on doing - it will
help me in planning the meeting and getting things organized.

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



From mailnull@www1.ietf.org  Thu May 22 06:34:05 2003
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 GAA07430
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 06:34:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4MA1Jo21667
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 06:01:19 -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 h4MA1DB21657;
	Thu, 22 May 2003 06:01:13 -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 h4MA0GB21578
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 06:00:16 -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 GAA07412
	for <nsis@ietf.org>; Thu, 22 May 2003 06:32:32 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19InLq-0007XE-00
	for nsis@ietf.org; Thu, 22 May 2003 06:31:10 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19InLp-0007XB-00
	for nsis@ietf.org; Thu, 22 May 2003 06:31:10 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4MAWVD10166
	for <nsis@ietf.org>; Thu, 22 May 2003 13:32:32 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625c7ad0dbac158f23168@esvir03nok.nokia.com> for <nsis@ietf.org>;
 Thu, 22 May 2003 13:32:27 +0300
Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 13:31:21 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 13:31:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 22 May 2003 13:31:20 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBE8@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] state management and the nsis framework
Thread-Index: AcMfnvuH1fdXQtWkRYKc2weBaSKaOQAoS5ggAAB5YaAAAsPY0A==
To: <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2003 10:31:21.0023 (UTC) FILETIME=[494364F0:01C3204D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4MA0GB21579
Subject: [NSIS] Updated charter proposal
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>
Content-Transfer-Encoding: 8bit

Hi all,

Just to refresh everyone's memory, the proposed charter update is as follows. Note that some dates on the goals & milestones need to be updated.

John

Next Steps in Signaling (nsis) Charter

Chair(s):
J. Loughney <john.loughney@nokia.com>

Transport Area Director(s):
S. Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>

Transport Area Advisor:
A. Mankin <mankin@isi.edu>

Mailing Lists:
General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

Description of Working Group:

The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocols with QoS signaling as the first use case.  This working group will concentrate on a two-layer signaling paradigm.  The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model.  

The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work. 

NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a tool box or building block approach, the two-layer model will be used to separate the transport of the signaling from the application signaling.  This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources.  The initial NSIS application will be an optimized RSVP 	QoS signaling protocol.  The second application will be a middle box traversal protocol.  It may be that a rechartering of the working group occurs before the completion of this milestone.

Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS-PR, and RSVP-PR auth-session, will be addressed.

It is a non-goal of the working group to develop new resource allocation protocols. Resource reservation and traffic engineering are out of scope of this working group.  Additionally, third party signaling is out of scope of this working group.  Mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context also welcomes participation and expression of requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T. 

Goals and Milestones:

MAR 03	Submit "Requirements for Signaling Protocols" to IESG for 
		publication as Informational RFC
APR 03	Submit "RSVP Security Properties" to IESG as Informational RFC
MAY 03	Submit "NSIS Threats" to IESG as Informational RFC
JUL 03	Submit "Analysis of Existing Signaling Protocols" to IESG as
		Informational RFC
SEP 03	Submit "Next Steps in Signaling: Framework" to IESG for publication 
		as Informational RFC
FEB 04	Submit "NSIS Transport Protocol" to IESG for publication for 
		Proposed Standard
MAR 04	Submit "NSIS QoS Application Protocol" to IESG for publication 
		for Proposed Standard
SEP 04  	Submit "NSIS Middle Box Signaling Application Protocol" to 
		IESG for publication for Proposed Standard
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Thu May 22 09:21:36 2003
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 JAA12818
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 09:21:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4MCmrA05305
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 08:48:53 -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 h4MCmiB05221;
	Thu, 22 May 2003 08:48:44 -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 h4MCi8B04803
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 08:44:08 -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 JAA12428
	for <nsis@ietf.org>; Thu, 22 May 2003 09:16:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IpuM-0001Jp-00
	for nsis@ietf.org; Thu, 22 May 2003 09:14:58 -0400
Received: from david.siemens.de ([192.35.17.14])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IpuL-0001Jm-00
	for nsis@ietf.org; Thu, 22 May 2003 09:14:58 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by david.siemens.de (8.11.7/8.11.7) with ESMTP id h4MDGJ120859;
	Thu, 22 May 2003 15:16:19 +0200 (MEST)
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h4MDGIK26852;
	Thu, 22 May 2003 15:16:18 +0200 (MEST)
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19)
	id <HY9X3YB3>; Thu, 22 May 2003 15:16:17 +0200
Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675FF0@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Date: Thu, 22 May 2003 15:16:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties document
 s
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 john, 
hi all, 

the security threats for nsis document is in a good shape. i recently got
some minor comments which i will incorporate with the next version. i would
like to encourage more nsis members to read the document and to send me
their comments to improve the quality.

the rsvp security properties draft needs more work (certainly a cleanup,
shortening). i think it is not ready for last call at the moment. btw, it is
available at: 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-01.t
xt
again, comments to this draft are also highly appreciated. 

ciao
hannes



> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Thursday, May 22, 2003 11:20 AM
> To: nsis@ietf.org
> Cc: Tschofenig Hannes
> Subject: Security Threats for NSIS & RSVP Security Properties 
> documents
> 
> 
> Hi all,
> 
> I would like to gage WG opinion on the following documents:
> 
> Security Threats for NSIS 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt
> 
> RSVP Security Properties 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt
> 
> My question is, are they ready or soon to be ready for WG last call?
> If anyone has open issues with them, please comment on them.  If you
> have not read them, please do so.  These documents will have impact
> upon the protocol work we will be doing.
> 
> Also, perhaps the editor of the documents could comment on this - 
> Hannes, do you feel that either document is ready for WG last
> call?
> 
> thanks,
> John
> 
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Thu May 22 09:28:54 2003
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 JAA13140
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 09:28:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4MCuBJ05927
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 08:56:11 -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 h4MCu6B05895;
	Thu, 22 May 2003 08:56:06 -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 h4MCt4B05827
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 08:55:04 -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 JAA13065
	for <nsis@ietf.org>; Thu, 22 May 2003 09:27:17 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Iq4w-0001X4-00
	for nsis@ietf.org; Thu, 22 May 2003 09:25:54 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Iq4v-0001Wr-00
	for nsis@ietf.org; Thu, 22 May 2003 09:25:54 -0400
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4MDR3717853
	for <nsis@ietf.org>; Thu, 22 May 2003 16:27:04 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T625d13173eac158f21946@esvir01nok.ntc.nokia.com>;
 Thu, 22 May 2003 16:18:47 +0300
Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 16:18:47 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 22 May 2003 16:18:46 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 22 May 2003 16:18:46 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBF7@esebe023.ntc.nokia.com>
Thread-Topic: Security Threats for NSIS & RSVP Security Properties documents
Thread-Index: AcMgZFhYdpLzjoxwQ9SmD3nVdEaHcQAAAlRQ
To: <hannes.tschofenig@siemens.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2003 13:18:46.0794 (UTC) FILETIME=[AD0266A0:01C32064]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4MCt4B05828
Subject: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties documents
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>
Content-Transfer-Encoding: 8bit

Hi Hannes,

> the security threats for nsis document is in a good shape. i recently got
> some minor comments which i will incorporate with the next version. i would
> like to encourage more nsis members to read the document and to send me
> their comments to improve the quality.

So, I suggest a sort of pre-WG last call on the Security Threats document.
I humbly ask people to read the document and make comments.  If Hannes
could then target a mid-June update, then I think we could start a WG
last call before Vienna.

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



From mailnull@www1.ietf.org  Thu May 22 10:51:05 2003
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 KAA16934
	for <nsis-archive@odin.ietf.org>; Thu, 22 May 2003 10:51:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4MEINR13703
	for nsis-archive@odin.ietf.org; Thu, 22 May 2003 10:18:23 -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 h4MEIFB13680;
	Thu, 22 May 2003 10:18:15 -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 h4MEHZB13628
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 10:17:35 -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 KAA16884
	for <nsis@ietf.org>; Thu, 22 May 2003 10:49:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IrMl-0002PD-00
	for nsis@ietf.org; Thu, 22 May 2003 10:48:23 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 19IrMl-0002Ot-00
	for nsis@ietf.org; Thu, 22 May 2003 10:48:23 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4MEnEhb025730;
	Thu, 22 May 2003 07:49:15 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHN74860;
	Thu, 22 May 2003 07:49:13 -0700 (PDT)
Message-Id: <200305221449.AHN74860@mira-sjc5-c.cisco.com>
To: john.loughney@nokia.com
cc: hannes.tschofenig@siemens.com, nsis@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties documents 
In-Reply-To: Message from john.loughney@nokia.com
   of "Thu, 22 May 2003 16:18:46 +0300." <DADF50F5EC506B41A0F375ABEB32063658EBF7@esebe023.ntc.nokia.com> 
Date: Thu, 22 May 2003 10:49:13 -0400
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>

I continue to think this is an excellent document, but the
layer split issues are sometimes not completely obvious and
at some point in the not-too-distant future we're going to
need to have a thorough discussion of where different
protections need to be made available, and to what extent
security concerns should drive certain layer split
decisions.  Also, different types of applications will have
different threat models and different needs (for example,
the concerns in a discovery protocol will be different from
the concerns in a reservation protocol).  Clearly those can
only be properly discussed in the context of the application
protocols themselves, but at any rate I think there may be a
need to beef out the layer split and transport layer
discussions.

But generally I think the document is ready for last call
(although there may be some formatting issues in the
references, formfeeds, etc).

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



From mailnull@www1.ietf.org  Fri May 23 13:22:15 2003
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 NAA15033
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:22:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHLoQ05810
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:21:50 -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 h4NHLXB05575;
	Fri, 23 May 2003 13:21:33 -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 h4N3EdB32488
	for <nsis@optimus.ietf.org>; Thu, 22 May 2003 23:14:39 -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 XAA10533
	for <nsis@ietf.org>; Thu, 22 May 2003 23:46:34 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J3UV-0000Yj-00
	for nsis@ietf.org; Thu, 22 May 2003 23:45:11 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J3UQ-0000YS-00
	for nsis@ietf.org; Thu, 22 May 2003 23:45:10 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4N3kTD15129
	for <nsis@ietf.org>; Fri, 23 May 2003 06:46:29 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T62602d8128ac158f24150@esvir04nok.ntc.nokia.com>;
 Fri, 23 May 2003 06:46:29 +0300
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 23 May 2003 06:46:29 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 23 May 2003 06:46:29 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties documents 
Date: Fri, 23 May 2003 06:46:28 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EBFA@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties documents 
Thread-Index: AcMgcWVtNFrKncvNTZmoAaG2R6fmHwAbFe2A
To: <mshore@cisco.com>
Cc: <hannes.tschofenig@siemens.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 23 May 2003 03:46:29.0024 (UTC) FILETIME=[E4844200:01C320DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4N3EdB32489
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>
Content-Transfer-Encoding: 8bit

Hi Melinda,

> I continue to think this is an excellent document, but the
> layer split issues are sometimes not completely obvious and
> at some point in the not-too-distant future we're going to
> need to have a thorough discussion of where different
> protections need to be made available, and to what extent
> security concerns should drive certain layer split
> decisions.  Also, different types of applications will have
> different threat models and different needs (for example,
> the concerns in a discovery protocol will be different from
> the concerns in a reservation protocol).  Clearly those can
> only be properly discussed in the context of the application
> protocols themselves, but at any rate I think there may be a
> need to beef out the layer split and transport layer
> discussions.

Good point - Hannes, do you think that you coul daddress this
in the update?  Melinda, if you have any specifics you think should be
added, please let Hannes know.

> But generally I think the document is ready for last call
> (although there may be some formatting issues in the
> references, formfeeds, etc).

Good.

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



From mailnull@www1.ietf.org  Fri May 23 13:42:34 2003
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 NAA16265
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:42:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHg8811081
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:42:08 -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 h4NHfpB10679;
	Fri, 23 May 2003 13:41:51 -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 h4N7xfB27125
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 03:59:41 -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 EAA28461
	for <nsis@ietf.org>; Fri, 23 May 2003 04:31:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J7wF-0002xM-00
	for nsis@ietf.org; Fri, 23 May 2003 04:30:07 -0400
Received: from thoth.sbs.de ([192.35.17.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J7wE-0002xJ-00
	for nsis@ietf.org; Fri, 23 May 2003 04:30:06 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h4N8VUu29279;
	Fri, 23 May 2003 10:31:30 +0200 (MEST)
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h4N8VTI08403;
	Fri, 23 May 2003 10:31:30 +0200 (MEST)
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19)
	id <HY9XPBGX>; Fri, 23 May 2003 10:31:29 +0200
Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675FF6@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, mshore@cisco.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Security Threats for NSIS & RSVP Security Properti
	es documents 
Date: Fri, 23 May 2003 10:31:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 john, 
hi melinda. 

thank you for raising this issue. 

it is true that the rsvp security properties document does not reflect the
two layer split discussions. 

i would certainly like to incorporate a discussion about the two layer split
into the document. however, some issues make it complicated for me: 

- the two layer split has an impact on certain security issues. the rsvp
security properties document address the security of rsvp (obviously). since
many of these issues are more concentrated on non peer-to-peer security
(which is not provided in rsvp) it is difficult to discuss them  in this
context (since they are simply not there). an example: the session
identifier

- there is no doubt that different nslps add different security requirements
and particularly authorization seems to the hard part. we looked into the
nat/firewall and the qos signaling and discovered some differences (which is
not surpising). however, other people have other applications in mind, which
i am not aware of. hence it might be difficult to address their needs
whithout knowing what they want. an example: melinda, you mention a
discovery protocol.

- i haven't seen a document about the ntlp functionality yet. the need for
some security mechanisms simply arises from the presence of certain
payloads, messages and protocol functionality. this document should be
created by melinda and henning. without a reference point i can only create
fuzzy text.

btw, the "nsis aaa" draft actually adds a number of information to the rsvp
security draft although it was not really noticed by anyone. the reason for
this is the misleading name of the draft. allison gave me the advice to
change it to nsis qos authorization. 

as a summary i can try hard to incorporate some issues, but i need more
input (and feedback) from other people. 

ciao
hannes


> 
> Hi Melinda,
> 
> > I continue to think this is an excellent document, but the
> > layer split issues are sometimes not completely obvious and
> > at some point in the not-too-distant future we're going to
> > need to have a thorough discussion of where different
> > protections need to be made available, and to what extent
> > security concerns should drive certain layer split
> > decisions.  Also, different types of applications will have
> > different threat models and different needs (for example,
> > the concerns in a discovery protocol will be different from
> > the concerns in a reservation protocol).  Clearly those can
> > only be properly discussed in the context of the application
> > protocols themselves, but at any rate I think there may be a
> > need to beef out the layer split and transport layer
> > discussions.
> 
> Good point - Hannes, do you think that you coul daddress this
> in the update?  Melinda, if you have any specifics you think should be
> added, please let Hannes know.
> 
> > But generally I think the document is ready for last call
> > (although there may be some formatting issues in the
> > references, formfeeds, etc).
> 
> Good.
> 
> thanks,
> John
> 
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Fri May 23 13:42:33 2003
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 NAA16263
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:42:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHg7A11068
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:42: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 h4NHfxB10964;
	Fri, 23 May 2003 13:41:59 -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 h4N9UMB32545
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 05:30:22 -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 GAA00365
	for <nsis@ietf.org>; Fri, 23 May 2003 06:02:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Ly-0003dE-00
	for nsis@ietf.org; Fri, 23 May 2003 06:00:46 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Lx-0003cc-00
	for nsis@ietf.org; Fri, 23 May 2003 06:00:45 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <LPHBCTKC>; Fri, 23 May 2003 11:01:38 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41806AC11F8@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Subject: RE: [NSIS] state management and the nsis framework
Date: Fri, 23 May 2003 11:01:38 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

dear all,

I sense this conversation is drawing towards a conclusion.

1. In terms of what happens when rerouting happens, i think our current working
assumption is that
*) NTLP 'healing' means: it ensures that signalling messages follow the new
correct path, and should tell the NSLP that something has changed;
*) NSLP 'healing' means: do anything special that the signalling application
wants to account for the fact that the path has changed. 
I'd rather not express this requirement in terms of refresh timers
but in this more abstract way.

2. There could be a significant open issue: what if the interested NSLP instance 
isn't at the same node where the NTLP node recognises the re-routing event.
Should 're-routing has happened' messages get sent around as some people
are assuming? Note that, unless the NTLP retains knowledge of every NSLP that
is interested in each flow, there is no way for it to decide when to stop
propagating such messages (which could lead to some interesting signalling
storms). OTOH, since I regard these as sematically optimisations, from a 
framework perspective this can probably be regarded as an
NTLP design question, at least to a large extent.

3. I'd strongly object to describing things in terms of 'NTLP refresh refreshing
NSLP state' (or indeed vice versa), since it assumes a mechansism in each layer
and then ties them together, not an ideal architectural approach. In any case,
that is not fundamentally what is wanted: what is wanted is that the NSIS 
protocol suite implementation at a node may schedule and combine messages even
at different layers to reduce load on the network, but any protocol state machines
are logically independent at each layer.

I'll try to post a revised proposal for the framework state management section
in a few days, assuming this message doesn't provoke another storm...

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



From mailnull@www1.ietf.org  Fri May 23 13:42:36 2003
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 NAA16293
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:42:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHgAx11117
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:42:10 -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 h4NHg1B11007;
	Fri, 23 May 2003 13:42:01 -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 h4N9UOB32554
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 05:30:24 -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 GAA00370
	for <nsis@ietf.org>; Fri, 23 May 2003 06:02:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9M0-0003dN-00
	for nsis@ietf.org; Fri, 23 May 2003 06:00:48 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Lz-0003cd-00
	for nsis@ietf.org; Fri, 23 May 2003 06:00:47 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <LPHBCTK1>; Fri, 23 May 2003 11:01:41 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41806AC11F9@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Date: Fri, 23 May 2003 11:01:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] framework: proposal on bundling
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>

Dear all,

We have a set of outanding issues on 'transport-like functions' and where they
should go in the NTLP/NSLP layer model. I'd like to make a sequence of proposals
about how these should be resolved, starting with the easy ones...

'Bundling' is 'getting more than one signalling application message into a 
single network layer message'. (It was introduced as an RSVP option in 2961,
essentially for performance reasons.)

My proposal is that the NTLP should support bundling. (A more precise statement:
an NTLP instance is free to decide whether or not to bundle messages together;
however, it should always be prepared to receive them - on the grounds that 
implementing de-bundling is simpler than implementing a negotiation procedure.
implementing bundling is somewhat less trivial.) 

Based on past verbal/m.l. discussions i think this is not too controversial, 
here is the reasoning:
*) whether or not messages are in a bundle has no semantic significance, and
no significance beyond the NTLP-hop over which they are bundled.
*) if only NSLPs could bundle, this would significantly restrict the scope
for doing this (only messages for the same signalling application could be
bundled).
*) bundling affects addressing - a bundled message has to be explicitly 
addressed (not implicitly+router alert addressed), only the NTLP has the 
intelligence to work out how/whether this is possible.
*) we don't prevent an NSLP providing an NTLP with a group of messages to send
at once (and recommending that the NTLP deliver them as a group) but this
is mainly an implementation/API issue. The NTLP may have to unbundle them
anyway.

any objections?

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



From mailnull@www1.ietf.org  Fri May 23 13:42:35 2003
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 NAA16279
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:42:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHg9j11098
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:42:09 -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 h4NHg0B10987;
	Fri, 23 May 2003 13:42:00 -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 h4N9UMB32549
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 05:30:22 -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 GAA00366
	for <nsis@ietf.org>; Fri, 23 May 2003 06:02:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Ly-0003dG-00
	for nsis@ietf.org; Fri, 23 May 2003 06:00:46 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Lx-0003cb-00
	for nsis@ietf.org; Fri, 23 May 2003 06:00:45 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <LPHBCTKD>; Fri, 23 May 2003 11:01:38 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41806AC11F7@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: Melinda Shore <mshore@cisco.com>, john.loughney@nokia.com
Cc: hannes.tschofenig@siemens.com, nsis@ietf.org
Subject: RE: [NSIS] RE: Security Threats for NSIS & RSVP Security Properti
	es documents 
Date: Fri, 23 May 2003 11:01:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

dear all,

I think we should see this document as logically similar to the
requirements document, i.e. covering the NSIS problem as a whole at
some high level, rather than trying to include all protocol design
goals as well. Otherwise it will never be finished.

There remains the question of where to discuss and document layer split
and other issues. One logical place would be the framework, which (I think)
is going to define the layer split from other perspectives. However, it
already has some assertions on this (crudely, NTLP security is about 
protecting information in transit, NSLP security is about protecting
operational aspects of the signalling application). I'm not sure it's possible
to say something which will be useful in the long term without something
more concrete to do security analysis on (e.g. we should write a good
applicability statement for a concrete NTLP, and make sure it is designed
from the start with security issues in mind rather than having them only
thought about in later stages).

My suspicion is that most security issues are intra- rather than inter-layer.
The main inter-layer point would be that because of the existence of
NSLP-unaware intermediate nodes terminating the NTLP, NTLP security is basically
pointless, at least from a purist's perspective. However, there seems to have
been fairly clear w.g. consensus up to now that we don't want to engineer the
NTLP to prevent this (FW section 3.2.1) circumstance arising, so we will just 
have to live with that.

r.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: 22 May 2003 15:49
> To: john.loughney@nokia.com
> Cc: hannes.tschofenig@siemens.com; nsis@ietf.org
> Subject: Re: [NSIS] RE: Security Threats for NSIS & RSVP Security
> Properties documents 
> 
> 
> I continue to think this is an excellent document, but the
> layer split issues are sometimes not completely obvious and
> at some point in the not-too-distant future we're going to
> need to have a thorough discussion of where different
> protections need to be made available, and to what extent
> security concerns should drive certain layer split
> decisions.  Also, different types of applications will have
> different threat models and different needs (for example,
> the concerns in a discovery protocol will be different from
> the concerns in a reservation protocol).  Clearly those can
> only be properly discussed in the context of the application
> protocols themselves, but at any rate I think there may be a
> need to beef out the layer split and transport layer
> discussions.
> 
> But generally I think the document is ready for last call
> (although there may be some formatting issues in the
> references, formfeeds, etc).
> 
> Melinda
> _______________________________________________
> 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



From mailnull@www1.ietf.org  Fri May 23 13:42:52 2003
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 NAA16331
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:42:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHgQT11203
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:42:26 -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 h4NHgHB11159;
	Fri, 23 May 2003 13:42:17 -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 h4N9gUB01339
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 05:42:30 -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 GAA00630
	for <nsis@ietf.org>; Fri, 23 May 2003 06:14:17 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Xh-0003jd-00
	for nsis@ietf.org; Fri, 23 May 2003 06:12:53 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 19J9Xg-0003jX-00
	for nsis@ietf.org; Fri, 23 May 2003 06:12:52 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4NAEGD04953
	for <nsis@ietf.org>; Fri, 23 May 2003 13:14:16 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T62619074d5ac158f24150@esvir04nok.ntc.nokia.com>;
 Fri, 23 May 2003 13:14:12 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 23 May 2003 13:14:11 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Fri, 23 May 2003 13:14:10 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties documents 
Date: Fri, 23 May 2003 13:14:09 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB32063658EC0B@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] RE: Security Threats for NSIS & RSVP Security Properties documents 
Thread-Index: AcMhElAOWcihCC5MTsytVcacqjtUowAAVofQ
To: <robert.hancock@roke.co.uk>, <mshore@cisco.com>
Cc: <hannes.tschofenig@siemens.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 23 May 2003 10:14:10.0417 (UTC) FILETIME=[0D632610:01C32114]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4N9gUB01340
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>
Content-Transfer-Encoding: 8bit

Hi Robert,

> I think we should see this document as logically similar to the
> requirements document, i.e. covering the NSIS problem as a whole at
> some high level, rather than trying to include all protocol design
> goals as well. Otherwise it will never be finished.

I agree, but I think that all Melinda was saying was some (hopefully
brief) comments to the affect that different parts of the
functionality, which may be related to the layer split, may
have some impact upon the security threats.  This seems
reasonable to me.

John

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



From mailnull@www1.ietf.org  Fri May 23 13:48:40 2003
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 NAA16719
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:48:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHmE012086
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:48:14 -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 h4NHm1B11797;
	Fri, 23 May 2003 13:48:01 -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 h4NAZbB03740
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 06:35:37 -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 HAA01755
	for <nsis@ietf.org>; Fri, 23 May 2003 07:07:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JAN6-000459-00
	for nsis@ietf.org; Fri, 23 May 2003 07:06:00 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JAN5-000456-00
	for nsis@ietf.org; Fri, 23 May 2003 07:05:59 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h4NB7IY04480;
	Fri, 23 May 2003 13:07:18 +0200 (MEST)
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h4NB7Hd19024;
	Fri, 23 May 2003 13:07:17 +0200 (MEST)
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19)
	id <HY9XP1L8>; Fri, 23 May 2003 13:07:17 +0200
Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675FFE@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: "'Hancock, Robert'" <robert.hancock@roke.co.uk>,
        Melinda Shore
	 <mshore@cisco.com>, john.loughney@nokia.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Security Threats for NSIS & RSVP Security Properti
	 es documents 
Date: Fri, 23 May 2003 13:07:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 robert, 

thank you for your comment. i agree with you that it might be very difficult
to incorporate the two layer split into the rsvp security properties
document. 

~ snip ~
> My suspicion is that most security issues are intra- rather 
> than inter-layer.
> The main inter-layer point would be that because of the existence of
> NSLP-unaware intermediate nodes terminating the NTLP, NTLP 
> security is basically
> pointless, at least from a purist's perspective. However, 
> there seems to have
> been fairly clear w.g. consensus up to now that we don't want 
> to engineer the
> NTLP to prevent this (FW section 3.2.1) circumstance arising, 
> so we will just 
> have to live with that.

i was always in favor to prevent this as discussed in the mailing list.
there should at least a way to provide the capability to skip certain nodes
(even rsvp has this functionality). 

for a security point of view it matters in the following case:

Node     A               B                C 
NSLP     X               Y                X & Y

assumption: all three entities belong to a different administrative domain. 

if a signaling message with nslp payload X (e.g. firewall signaling) is sent
to node B where the security of the NTLP is terminated then you have a
problem. 

if node B and node C belong to the same adm. domain then it does not really
matter (except for identity management). this functionality is actually also
provided by rsvp with the identity rep. as a end host you do not really know
which entity authenticates you (first rsvp node, pdp, etc.). 

ciao
hannes


> 
> r.
> 
> > -----Original Message-----
> > From: Melinda Shore [mailto:mshore@cisco.com]
> > Sent: 22 May 2003 15:49
> > To: john.loughney@nokia.com
> > Cc: hannes.tschofenig@siemens.com; nsis@ietf.org
> > Subject: Re: [NSIS] RE: Security Threats for NSIS & RSVP Security
> > Properties documents 
> > 
> > 
> > I continue to think this is an excellent document, but the
> > layer split issues are sometimes not completely obvious and
> > at some point in the not-too-distant future we're going to
> > need to have a thorough discussion of where different
> > protections need to be made available, and to what extent
> > security concerns should drive certain layer split
> > decisions.  Also, different types of applications will have
> > different threat models and different needs (for example,
> > the concerns in a discovery protocol will be different from
> > the concerns in a reservation protocol).  Clearly those can
> > only be properly discussed in the context of the application
> > protocols themselves, but at any rate I think there may be a
> > need to beef out the layer split and transport layer
> > discussions.
> > 
> > But generally I think the document is ready for last call
> > (although there may be some formatting issues in the
> > references, formfeeds, etc).
> > 
> > Melinda
> > _______________________________________________
> > 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



From mailnull@www1.ietf.org  Fri May 23 13:53:05 2003
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 NAA16992
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 13:53:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NHqd812739
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 13:52:39 -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 h4NHqXB12576;
	Fri, 23 May 2003 13:52:33 -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 h4NC4wB08986
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 08:04:58 -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 IAA03582
	for <nsis@ietf.org>; Fri, 23 May 2003 08:36:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JBlX-0004fu-00
	for nsis@ietf.org; Fri, 23 May 2003 08:35:19 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JBlW-0004fq-00
	for nsis@ietf.org; Fri, 23 May 2003 08:35:18 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4NCaC9N015070;
	Fri, 23 May 2003 05:36:12 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHO83556;
	Fri, 23 May 2003 05:36:11 -0700 (PDT)
Message-Id: <200305231236.AHO83556@mira-sjc5-c.cisco.com>
To: Tschofenig Hannes <hannes.tschofenig@siemens.com>
cc: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [NSIS] RE: Security Threats for NSIS & RSVP Security Properti es documents 
In-Reply-To: Message from hannes.tschofenig@siemens.com
   of "Fri, 23 May 2003 10:31:27 +0200." <2A8DB02E3018D411901B009027FD3A3F03675FF6@mchp905a.mch.sbs.de> 
Date: Fri, 23 May 2003 08:36:11 -0400
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>

> it is true that the rsvp security properties document does not reflect the
> two layer split discussions. 

I'm sorry if I was unclear - I was referring to the NSIS
threats document, not the RSVP security properties document.

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



From mailnull@www1.ietf.org  Fri May 23 14:01:01 2003
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 OAA17653
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 14:01:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NI0ZT15240
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 14:00:35 -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 h4NI0SB15196;
	Fri, 23 May 2003 14:00:28 -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 h4NHxxB14746
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 13:59:59 -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 NAA17454
	for <nsis@ietf.org>; Fri, 23 May 2003 13:59:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JGoH-0000Wq-00
	for nsis@ietf.org; Fri, 23 May 2003 13:58:29 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JGoG-0000UU-00
	for nsis@ietf.org; Fri, 23 May 2003 13:58:28 -0400
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4NHvHFa022607;
	Fri, 23 May 2003 10:59:15 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEL17517;
	Fri, 23 May 2003 10:56:57 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13692; Fri, 23 May 2003 10:56:57 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16078.24809.216265.190878@thomasm-u1.cisco.com>
Date: Fri, 23 May 2003 10:56:57 -0700 (PDT)
To: john.loughney@nokia.com
Cc: <nsis@ietf.org>, <Hannes.Tschofenig@mchp.siemens.de>
In-Reply-To: <DADF50F5EC506B41A0F375ABEB32063658EBD7@esebe023.ntc.nokia.com>
References: <DADF50F5EC506B41A0F375ABEB32063658EBD7@esebe023.ntc.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Subject: [NSIS] Mike's security threats comments
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>
Content-Transfer-Encoding: 7bit


Hannes, here are a few random and not well
integrated on my part's comments:

in section 2 on end 2 end communication, you state
that:

          Providing end-to-end signaling message protection for NSIS
          would cause difficulties for authentication and key
          establishment procedures. It would furthermore limit the
          flexibility of a signaling protocol in general.

I don't understand why this is especially
different than end to middle, etc. In fact, I
don't even understand why it's different from end
to first hop. If I were attached to a remote
network (say in an airport lounge) and the end
host was my desktop machine, it seems to me that
that's a case where the trust relationship is
inverted; that is, I'd have a relation with my
desktop machine, but not the first NSIS hop.

My general comment here, I guess, is that I'm not
sure what the overall utility is with these
distinctions, and/or what they're trying to
accomplish. I'm not saying that there isn't a
taxonomy here (I think there is), it's just that
I'm not sure the distinctions you are trying to
draw with the examples.

Maybe it would be better to devise this taxonomy
two dimensionally, with "adjacent" and "crosses
trust boundary" as the two axis? This is sort of
how I think of SIP, for example.


Section 2.1, MITM Attacks:

This first paragraph is interesting, but it seems
rather odd to be placed in a discussion of MITM
attacks. Its more of a discussion about state
establishment considerations -- though important,
is it relevant to a discussion of threats?

In general in this section, it sort of mixes
threats and solutions. That is, establishing an SA
is what one generally does to counter some set of
threats. Though proper SA establishment may in
turn have its own threats, I'm not sure they're
relevant to this document which I sort of view as
a "what security threats does the design need to
have answers for."

My suggestion is to phrase this only in terms of
the threats, not ways of countering them in 1, 2
and 3.

Section 2.2, eavesdropping

I think it's worth parsing apart the difference
between adjacent and non-adjacent eavesdropping. 
That is, what happens when signaling
intermediaries can snoop. The analogous SIP
situation is proxies and SRTP keys. This is
distinct from non-participants eavesdropping 
via sniffers, etc.

Section 2.2, Combining...

This section really seems to be about DoS. What I
don't really see here -- and maybe it just needs
to be separate bullets -- is a discussion of CPU
and state-storage attacks. Eg, leveraged attacks
by making a non-complex message force a node to do
expensive modular arithmetic, as well as the whole
subject of state retention/spoofing. The latter is
a particular concern, I'd think, because of the
possibility to source-spoof combined with PATH
state. I might be wrong, but I don't think that
RSVP handles this well.

2.14, Cost control

I think I understand where you're going here, but
to me this is a little broader than cost control.
What this really says to me is that any implicit
trust of the access provider's network as is the
current case with dialin networks is suspect in
the brave new world of wireless, etc. The *threat*
to my mind is that I might accidentally connect to
a bogus or sleazy provider. (the solution being
strong auth/authz of the provider).

Part of that threat might be addressed by knowing
cost structures of the remote provider, but I'm
not entirely sure that that's a threat per se so
much as a (debatable) requirement of the protocol.
One can envision a rate structure XML site which
the mobile downloads/contacts which is outside of
the domain of NSIS, after all.


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



From mailnull@www1.ietf.org  Fri May 23 14:01:36 2003
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 OAA17719
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 14:01:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NI1BZ15455
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 14:01:11 -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 h4NI12B15395;
	Fri, 23 May 2003 14:01:02 -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 h4NI0PB15177
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 14:00:25 -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 OAA17602
	for <nsis@ietf.org>; Fri, 23 May 2003 14:00:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JGoh-0000Yr-00
	for nsis@ietf.org; Fri, 23 May 2003 13:58:55 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JGoh-0000WO-00
	for nsis@ietf.org; Fri, 23 May 2003 13:58:55 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4NHxT9R012930;
	Fri, 23 May 2003 10:59:44 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHP11528;
	Fri, 23 May 2003 10:57:37 -0700 (PDT)
Message-Id: <200305231757.AHP11528@mira-sjc5-c.cisco.com>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
cc: nsis@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [NSIS] framework: proposal on bundling 
In-Reply-To: Message from robert.hancock@roke.co.uk
   of "Fri, 23 May 2003 11:01:39 BST." <76C92FBBFB58D411AE760090271ED41806AC11F9@rsys002a.roke.co.uk> 
Date: Fri, 23 May 2003 13:57:37 -0400
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>

> My proposal is that the NTLP should support bundling.

We've agreed that the protocol will be based on RFCs 2205
and 2961, and 2961 does support bundling (with some
constraints).  This is reflected in the current state of the
draft.  There are some difficulties around the use of
bundling together with the reliable delivery mechanism but
I believe these can be resolved.

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



From mailnull@www1.ietf.org  Fri May 23 14:44:49 2003
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 OAA19596
	for <nsis-archive@odin.ietf.org>; Fri, 23 May 2003 14:44:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NIiL420270
	for nsis-archive@odin.ietf.org; Fri, 23 May 2003 14:44:21 -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 h4NIiEB20239;
	Fri, 23 May 2003 14:44:14 -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 h4NIhJB20178
	for <nsis@optimus.ietf.org>; Fri, 23 May 2003 14:43:19 -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 OAA19549
	for <nsis@ietf.org>; Fri, 23 May 2003 14:43:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JHUG-00017U-00
	for nsis@ietf.org; Fri, 23 May 2003 14:41:52 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JHUF-00017O-00
	for nsis@ietf.org; Fri, 23 May 2003 14:41:51 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h4NIgiNb021636;
	Fri, 23 May 2003 11:42:45 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHP18333;
	Fri, 23 May 2003 11:42:42 -0700 (PDT)
Message-Id: <200305231842.AHP18333@mira-sjc5-c.cisco.com>
To: Michael Thomas <mat@cisco.com>
cc: john.loughney@nokia.com, nsis@ietf.org, Hannes.Tschofenig@mchp.siemens.de
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [NSIS] Mike's security threats comments 
In-Reply-To: Message from mat
   of "Fri, 23 May 2003 10:56:57 PDT." <16078.24809.216265.190878@thomasm-u1.cisco.com> 
Date: Fri, 23 May 2003 14:42:42 -0400
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>

>           Providing end-to-end signaling message protection for NSIS
>           would cause difficulties for authentication and key
>           establishment procedures. It would furthermore limit the
>           flexibility of a signaling protocol in general.
> 
> I don't understand why this is especially
> different than end to middle, etc. In fact, I
> don't even understand why it's different from end
> to first hop. If I were attached to a remote
> network (say in an airport lounge) and the end
> host was my desktop machine, it seems to me that
> that's a case where the trust relationship is
> inverted; that is, I'd have a relation with my
> desktop machine, but not the first NSIS hop.

I don't think that the issue here is end-to-endness as it is
that, in this case, end-to-end necessarily actually means
hop-by-hop and there can be some non-trivial trust issues in
there.

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



From mailnull@www1.ietf.org  Sun May 25 13:32:36 2003
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 NAA06542
	for <nsis-archive@odin.ietf.org>; Sun, 25 May 2003 13:32:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4PHWHl18855
	for nsis-archive@odin.ietf.org; Sun, 25 May 2003 13:32:17 -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 h4PHW1B18847;
	Sun, 25 May 2003 13:32:01 -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 h4PHUhB18774
	for <nsis@optimus.ietf.org>; Sun, 25 May 2003 13:30:43 -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 NAA06515
	for <nsis@ietf.org>; Sun, 25 May 2003 13:30:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JzIu-0007RU-00
	for nsis@ietf.org; Sun, 25 May 2003 13:29:04 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JzIt-0007RN-00
	for nsis@ietf.org; Sun, 25 May 2003 13:29:03 -0400
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h4PHUXL25731;
	Sun, 25 May 2003 19:30:33 +0200 (MEST)
Received: from joe (corcert015.esn.sbs.de [149.246.220.15])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h4PHUV622945;
	Sun, 25 May 2003 19:30:31 +0200 (MEST)
From: "Hannes Tschofenig" <Hannes.Tschofenig@siemens.com>
To: "'Michael Thomas'" <mat@cisco.com>, <john.loughney@nokia.com>
Cc: <nsis@ietf.org>
Date: Sun, 25 May 2003 19:28:40 +0200
Message-ID: <000601c322e3$15d643b0$010aa8c0@joe>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <16078.24809.216265.190878@thomasm-u1.cisco.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4PHUhB18775
Subject: [NSIS] RE: Mike's security threats comments
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>
Content-Transfer-Encoding: 8bit

hi mike, 

thank you for reading the document and sending comments.

please see my comments inline: 

> -----Original Message-----
> From: Michael Thomas [<mailto:mat@cisco.com>] 
> Sent: Freitag, 23. Mai 2003 19:57
> To: john.loughney@nokia.com
> Cc: nsis@ietf.org; Tschofenig Hannes
> Subject: Mike's security threats comments
> 
> 
> 
> Hannes, here are a few random and not well
> integrated on my part's comments:
> 
> in section 2 on end 2 end communication, you state
> that:
> 
>           Providing end-to-end signaling message protection for NSIS
>           would cause difficulties for authentication and key
>           establishment procedures. It would furthermore limit the
>           flexibility of a signaling protocol in general.
> 
> I don't understand why this is especially
> different than end to middle, etc. In fact, I
> don't even understand why it's different from end
> to first hop. If I were attached to a remote
> network (say in an airport lounge) and the end
> host was my desktop machine, it seems to me that
> that's a case where the trust relationship is
> inverted; that is, I'd have a relation with my
> desktop machine, but not the first NSIS hop.
> 
> My general comment here, I guess, is that I'm not
> sure what the overall utility is with these
> distinctions, and/or what they're trying to
> accomplish. I'm not saying that there isn't a
> taxonomy here (I think there is), it's just that
> I'm not sure the distinctions you are trying to
> draw with the examples.
> 
> Maybe it would be better to devise this taxonomy
> two dimensionally, with "adjacent" and "crosses
> trust boundary" as the two axis? This is sort of
> how I think of SIP, for example.

ruediger geib gave me a similar comment to the "difficulty" of end-to-end
vs. end-to-middle security. 

i am open for changing terms. the difficulty of protecting messages or
payloads heavily depends on the given scenario and on the information you
have in advance. 

i have read you sip security framework document but i do not have the
details in mind. i will re-read it again to see whether it helps me. 

the terms "adjacent" and "crosses trust boundary" might not be sufficient, i
guess. 
(i assume that you mean adjacent as belonging to the same admin domain). 
the problem is that you might easily establish security between neighboring
domains in some cases whereas in others this is more complicated. 
an example: network access authentication and end-to-end mobile ip security

> 
> 
> Section 2.1, MITM Attacks:
> 
> This first paragraph is interesting, but it seems
> rather odd to be placed in a discussion of MITM
> attacks. Its more of a discussion about state
> establishment considerations -- though important,
> is it relevant to a discussion of threats?

i guess it is important. if you want to mount attacks against a protocol
then the phase where the security association is established is a good
place. 

it is also good to point to a typical protocol behavior to split
authentication and key exchange from the actually signaling message
protection. 

> 
> In general in this section, it sort of mixes
> threats and solutions.

i tried hard to avoid solutions. however, it is fair to say that security
mechanisms follow typically patterns. i tried to describe these patters in
details and their relevance for nsis. 

since nsis might be used in a number of scenarios and between different
nodes at different parts of the network it is difficult to capture all
possible combinations. hence i have separated the discussion into the
subcategories. 




> That is, establishing an SA
> is what one generally does to counter some set of
> threats. Though proper SA establishment may in
> turn have its own threats, I'm not sure they're
> relevant to this document which I sort of view as
> a "what security threats does the design need to
> have answers for."

i have subdivided these issues in more details. i have briefly described
what happens if you have no authentication (or unilateral authentication).
the result is obvious. 

since nsis is not an attempt to design pathcoupled signaling protocols from
scratch it is fair to look at existing protocols. these protocols show that
some security is provided but in certain cases not sufficient (e.g. weak
authentication).

i cannot exclude security protocols itself from the discussion since
protocols such as rsvp define their own security mechanisms. 
(i.e. if you use standard security mechanisms then you usually do not have
to worry about replay attacks. if you need to create your own security then
you need to consider it.)

> 
> My suggestion is to phrase this only in terms of
> the threats, not ways of countering them in 1, 2
> and 3.

i will go through the text again and try to remove solution oriented parts. 


> 
> Section 2.2, eavesdropping
> 
> I think it's worth parsing apart the difference
> between adjacent and non-adjacent eavesdropping. 
> That is, what happens when signaling
> intermediaries can snoop. The analogous SIP
> situation is proxies and SRTP keys. This is
> distinct from non-participants eavesdropping 
> via sniffers, etc.

might be an idea. 

the analgon with srtp is somewhat misleading since nsis is not a protocol
for commucation purely between end hosts (srtp establishes keys and sas
between the end hosts only). 
 
> 
> Section 2.2, Combining...
> 
> This section really seems to be about DoS. What I
> don't really see here -- and maybe it just needs
> to be separate bullets -- is a discussion of CPU
> and state-storage attacks. Eg, leveraged attacks
> by making a non-complex message force a node to do
> expensive modular arithmetic, as well as the whole
> subject of state retention/spoofing.

you are right that this section mainly addresses dos attacks specifically
addressed to the topic of the section. 
a separate section talks about dos attacks (see section 2.9). 

spoofing is covered in a separate section (see section 2.5).

 The latter is
> a particular concern, I'd think, because of the
> possibility to source-spoof combined with PATH
> state. I might be wrong, but I don't think that
> RSVP handles this well.
> 
> 2.14, Cost control
> 
> I think I understand where you're going here, but
> to me this is a little broader than cost control.

terms :-) 
what term do you suggest instead of cost control? 

> What this really says to me is that any implicit
> trust of the access provider's network as is the
> current case with dialin networks is suspect in
> the brave new world of wireless, etc. The *threat*
> to my mind is that I might accidentally connect to
> a bogus or sleazy provider. (the solution being
> strong auth/authz of the provider).

interesting that you mention this part. i have discussed this issue with
outer ietf members and it turned out that this issue is relevant for a
number of groups such as pana, nemo, eap, mobile ip, etc. 

i placed it in a separate section (labeled as deployment threats) since it
is actually not a threat. if you have a different name, then please let me
know.  that's the reason why is introduced the section with the following
text: 
"
This section addresses problems which could appear during the deployment of
an NSIS protocol in a real-world environment. Although these problems are
theoretically not an obstacle for practical reasons they can represent
threats worth a consideration. 
" 

this section should address the problem that in a mobile environment there
has to be a mechanism which allows the authorizing entity (the entity which
triggers the qos reservation) to know how much it actually costs. i wouldn't
use a "service" where i have no idea about the costs. this is actually one
place where i can see the usefulness of non-repudiation. 



> 
> Part of that threat might be addressed by knowing
> cost structures of the remote provider, but I'm
> not entirely sure that that's a threat per se so
> much as a (debatable) requirement of the protocol.
> One can envision a rate structure XML site which
> the mobile downloads/contacts which is outside of
> the domain of NSIS, after all.

now you go into a solution discussion.  
actually a number of people have proposed different
protocols/payloads/languages for exchanging cost information. if you look in
the "nsis aa" draft then you will notice that something similar is actually
required for more advanced scenarios. 

> 

> 
> 	   Mike
> 

ciao
hannes

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



From mailnull@www1.ietf.org  Tue May 27 05:29:41 2003
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 FAA05709
	for <nsis-archive@odin.ietf.org>; Tue, 27 May 2003 05:29:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4R9Tdr01524
	for nsis-archive@odin.ietf.org; Tue, 27 May 2003 05:29:39 -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 h4R9TRB01511;
	Tue, 27 May 2003 05:29:27 -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 h4R9SSB01465
	for <nsis@optimus.ietf.org>; Tue, 27 May 2003 05:28:28 -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 FAA05689
	for <nsis@ietf.org>; Tue, 27 May 2003 05:27:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Kaix-0002bO-00
	for nsis@ietf.org; Tue, 27 May 2003 05:26:27 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Kaiw-0002bL-00
	for nsis@ietf.org; Tue, 27 May 2003 05:26:26 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <LXWLMHR6>; Tue, 27 May 2003 10:27:29 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9CD@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] framework: proposal on bundling 
Date: Tue, 27 May 2003 10:27:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

excellent news - and a reliable delivery mechanism too! [should make the
fragmentation discussion much more clear cut.]

r.

ps. i still feel it's worth describing these things explicitly rather than 
just referring to 2961. after all, i guess you won't include all 2961 features...

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: 23 May 2003 18:58
> To: Hancock, Robert
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] framework: proposal on bundling 
> 
> 
> > My proposal is that the NTLP should support bundling.
> 
> We've agreed that the protocol will be based on RFCs 2205
> and 2961, and 2961 does support bundling (with some
> constraints).  This is reflected in the current state of the
> draft.  There are some difficulties around the use of
> bundling together with the reliable delivery mechanism but
> I believe these can be resolved.
> 
> Melinda
> 
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



From mailnull@www1.ietf.org  Tue May 27 11:46:08 2003
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 LAA17560
	for <nsis-archive@odin.ietf.org>; Tue, 27 May 2003 11:46:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4RFjfU29834
	for nsis-archive@odin.ietf.org; Tue, 27 May 2003 11:45:41 -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 h4RFjXB29819;
	Tue, 27 May 2003 11:45:33 -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 h4RFiMB29760
	for <nsis@optimus.ietf.org>; Tue, 27 May 2003 11:44:22 -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 LAA17499
	for <nsis@ietf.org>; Tue, 27 May 2003 11:44:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Kgb8-0005ZY-00
	for nsis@ietf.org; Tue, 27 May 2003 11:42:46 -0400
Received: from smtp802.mail.sc5.yahoo.com ([66.163.168.181])
	by ietf-mx with smtp (Exim 4.12)
	id 19Kgb7-0005ZU-00
	for nsis@ietf.org; Tue, 27 May 2003 11:42:45 -0400
Received: from adsl-67-115-110-66.dsl.sntc01.pacbell.net (HELO cs.columbia.edu) (pingpan999@67.115.110.66 with plain)
  by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 27 May 2003 15:44:19 -0000
Message-ID: <3ED387D9.5070807@cs.columbia.edu>
Date: Tue, 27 May 2003 08:44:25 -0700
From: Ping Pan <pingpan@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
CC: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: Re: [NSIS] framework: proposal on bundling
References: <76C92FBBFB58D411AE760090271ED4181EA9CD@rsys002a.roke.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit

Hancock, Robert wrote:
> excellent news - and a reliable delivery mechanism too! [should make the
> fragmentation discussion much more clear cut.]
>

Which is all included in 2961.

> r.
> 
> ps. i still feel it's worth describing these things explicitly rather than 
> just referring to 2961. after all, i guess you won't include all 2961 features...
> 

Which feature in 2961 that you think is not worth to be included?

- Ping

> 
>>-----Original Message-----
>>From: Melinda Shore [mailto:mshore@cisco.com]
>>Sent: 23 May 2003 18:58
>>To: Hancock, Robert
>>Cc: nsis@ietf.org
>>Subject: Re: [NSIS] framework: proposal on bundling 
>>
>>
>>
>>>My proposal is that the NTLP should support bundling.
>>
>>We've agreed that the protocol will be based on RFCs 2205
>>and 2961, and 2961 does support bundling (with some
>>constraints).  This is reflected in the current state of the
>>draft.  There are some difficulties around the use of
>>bundling together with the reliable delivery mechanism but
>>I believe these can be resolved.
>>
>>Melinda
>>
> 
> _______________________________________________
> 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



From mailnull@www1.ietf.org  Tue May 27 12:09:49 2003
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 MAA18294
	for <nsis-archive@odin.ietf.org>; Tue, 27 May 2003 12:09:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4RG9M332359
	for nsis-archive@odin.ietf.org; Tue, 27 May 2003 12:09:22 -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 h4RG9CB32283;
	Tue, 27 May 2003 12:09:12 -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 h4RG3IB30853
	for <nsis@optimus.ietf.org>; Tue, 27 May 2003 12:03:18 -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 MAA18162
	for <nsis@ietf.org>; Tue, 27 May 2003 12:03:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19KgtR-0005kh-00
	for nsis@ietf.org; Tue, 27 May 2003 12:01:41 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19KgtR-0005k9-00
	for nsis@ietf.org; Tue, 27 May 2003 12:01:41 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <LX6CGRJQ>; Tue, 27 May 2003 17:02:44 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9D2@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Ping Pan'" <pingpan@cs.columbia.edu>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] framework: proposal on bundling
Date: Tue, 27 May 2003 17:02:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 ping,

> Hancock, Robert wrote:
> > excellent news - and a reliable delivery mechanism too! 
> [should make the
> > fragmentation discussion much more clear cut.]
> >
> 
> Which is all included in 2961.

fragmentation?

> 
> > r.
> > 
> > ps. i still feel it's worth describing these things 
> explicitly rather than 
> > just referring to 2961. after all, i guess you won't 
> include all 2961 features...
> > 
> 
> Which feature in 2961 that you think is not worth to be included?

summary refresh seems more signalling-application than generic to me.

also, i feel that as we start from a clean sheet, we should be able 
to do better than exponential backoff for congestion control (I got the
impression you and Henning think so too, apologies if I misinterpret that).

r.

> 
> - Ping
> 
> > 
> >>-----Original Message-----
> >>From: Melinda Shore [mailto:mshore@cisco.com]
> >>Sent: 23 May 2003 18:58
> >>To: Hancock, Robert
> >>Cc: nsis@ietf.org
> >>Subject: Re: [NSIS] framework: proposal on bundling 
> >>
> >>
> >>
> >>>My proposal is that the NTLP should support bundling.
> >>
> >>We've agreed that the protocol will be based on RFCs 2205
> >>and 2961, and 2961 does support bundling (with some
> >>constraints).  This is reflected in the current state of the
> >>draft.  There are some difficulties around the use of
> >>bundling together with the reliable delivery mechanism but
> >>I believe these can be resolved.
> >>
> >>Melinda
> >>
> > 
> > _______________________________________________
> > 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



From mailnull@www1.ietf.org  Thu May 29 04:40:48 2003
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 EAA23060
	for <nsis-archive@odin.ietf.org>; Thu, 29 May 2003 04:40:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4T8eL602266
	for nsis-archive@odin.ietf.org; Thu, 29 May 2003 04:40:21 -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 h4T8e7B02250;
	Thu, 29 May 2003 04:40: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 h4T8cxB02201
	for <nsis@optimus.ietf.org>; Thu, 29 May 2003 04:38:59 -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 EAA23042
	for <nsis@ietf.org>; Thu, 29 May 2003 04:38:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LIuV-0004Wj-00
	for nsis@ietf.org; Thu, 29 May 2003 04:37:19 -0400
Received: from thoth.sbs.de ([192.35.17.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LIuU-0004Wg-00
	for nsis@ietf.org; Thu, 29 May 2003 04:37:18 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h4T8ctx05735;
	Thu, 29 May 2003 10:38:55 +0200 (MEST)
Received: from joe ([139.25.62.13])
	by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h4T8csh29023;
	Thu, 29 May 2003 10:38:54 +0200 (MEST)
From: "Hannes Tschofenig" <Hannes.Tschofenig@siemens.com>
To: "'Michael Thomas'" <mat@cisco.com>, <john.loughney@nokia.com>
Cc: <nsis@ietf.org>
Date: Thu, 29 May 2003 10:36:43 +0200
Message-ID: <01ea01c325bd$6f9888e0$010aa8c0@joe>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4T8d0B02202
Subject: [NSIS] RE: Mike's security threats comments
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>
Content-Transfer-Encoding: 8bit

hi mike, 

i looked into your sip security framework draft which describes some threats
against sip to answer one of your questions. please find my comments below:

> -----Original Message-----
> From: Michael Thomas [<mailto:mat@cisco.com>] 
> Sent: Freitag, 23. Mai 2003 19:57
> To: john.loughney@nokia.com
> Cc: nsis@ietf.org; Tschofenig Hannes
> Subject: Mike's security threats comments
> 
> 
> 
> Hannes, here are a few random and not well
> integrated on my part's comments:
> 
> in section 2 on end 2 end communication, you state
> that:
> 
>           Providing end-to-end signaling message protection for NSIS
>           would cause difficulties for authentication and key
>           establishment procedures. It would furthermore limit the
>           flexibility of a signaling protocol in general.
> 
> I don't understand why this is especially
> different than end to middle, etc. In fact, I
> don't even understand why it's different from end
> to first hop. If I were attached to a remote
> network (say in an airport lounge) and the end
> host was my desktop machine, it seems to me that
> that's a case where the trust relationship is
> inverted; that is, I'd have a relation with my
> desktop machine, but not the first NSIS hop.
> 
> My general comment here, I guess, is that I'm not
> sure what the overall utility is with these
> distinctions, and/or what they're trying to
> accomplish. I'm not saying that there isn't a
> taxonomy here (I think there is), it's just that
> I'm not sure the distinctions you are trying to
> draw with the examples.
> 
> Maybe it would be better to devise this taxonomy
> two dimensionally, with "adjacent" and "crosses
> trust boundary" as the two axis? This is sort of
> how I think of SIP, for example.

for the discussion it helps to separate 
a) the judgment of how difficult it is to provide message protection
b) between which messages a protection takes place.

ad a) 
the security work should also help people from making design issues without
thinking about their consequences. this is particularly important after the
initial work is finished and people add some extensions (since they always
only refer to the security of the base document). i guess that there is no
doubt that it is more complex to protect certain messages or parts of
messages than others. i thought that it might be good to add some text to
the document somewhere. i am free for suggestions. 

looking at rfc 3473 (see notify message) one has to notice that additionally
considerations have to be made when, for example, end-to-middle protection
is added to the design. 

ad b) 
reading your draft i noticed that your taxonomy uses more than two
dimensions for sip. both sip and nsis involve communication over a number of
nodes hence it might be good to have a more fine granular differentiation
than only "adjacent" and "crosses trust boundary". 
you use: 
- ua to first hop proxy
- ua to intermediate proxy
- end-to-end uac to uas
- proxy-proxy traffic 
(taken from section 3.2)

the differentiation is not only theoretically but can also be found in the
protocol machinery. 

since sip has a different purpose than nsis there are some differences.
rsvp, for example, 

another difference between the text in security threats for nsis draft and
your sip security framework draft is the following: your draft was written
after sip was nearly finished. hence it was possible for you to refer to
certain threats very precisely (even mentioning the details of the message
payloads). we started earlier with the security work in nsis and hence it is
difficult to refer to one particular protocol only - everyone would treat it
as biased or solution-oriented. 
this is the reason why some text paragraphs look a little bit cryptic. i
simply tried to cover all cases. 


~ snip ~ 

> 2.14, Cost control
> 
> I think I understand where you're going here, but
> to me this is a little broader than cost control.

terms: 
how about calling the section "deployment issues" (not "deployment threats")
and labeling this subsection "Advice of charge"?


ciao
hannes


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



From mailnull@www1.ietf.org  Thu May 29 07:25:52 2003
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 HAA27099
	for <nsis-archive@odin.ietf.org>; Thu, 29 May 2003 07:25:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4TBPNM12202
	for nsis-archive@odin.ietf.org; Thu, 29 May 2003 07:25:23 -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 h4TBPIB12178;
	Thu, 29 May 2003 07:25:18 -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 h4TBJYB11961
	for <nsis@optimus.ietf.org>; Thu, 29 May 2003 07:19:34 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26773;
	Thu, 29 May 2003 07:19:33 -0400 (EDT)
Message-Id: <200305291119.HAA26773@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: nsis@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 29 May 2003 07:19:33 -0400
Subject: [NSIS] I-D ACTION:draft-westberg-rmd-framework-03.txt
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Resource Management in Diffserv (RMD) Framework
	Author(s)	: L. Westberg et al.
	Filename	: draft-westberg-rmd-framework-03.txt
	Pages		: 59
	Date		: 2003-5-28
	
This draft presents the work on the framework for the Resource
Management in Diffserv (RMD) designed for edge-to-edge resource
reservation in a Differentiated Services (Diffserv) domain.  The RMD
extends the Diffserv architecture with new resource reservation
concepts and features. Moreover, this framework enhances the Load
Control protocol described in [WeTu00].
The RMD framework defines two architectural concepts:
- the Per Hop Reservation (PHR)
- the Per Domain Reservation (PDR)
The PHR protocol is used within a Diffserv domain on a per-hop basis
to augment the Diffserv Per Hop Behavior (PHB) with resource
reservation. It is implemented in all nodes in a Diffserv domain. On
the other hand, the PDR protocol manages the resource reservation per
Diffserv domain, relying on the PHR resource reservation status in
all nodes.  The PDR is only implemented at the boundary of the domain
(at the edge nodes).
The RMD framework presented in this draft describes the new
reservation concepts and features. Furthermore it describes the:
- relationship between the PHR and PHB
- interaction between the PDR and PHR
- interoperability between the PDR and external resource
reservation schemes
This framework is an open framework in the sense that it provides the
basis for interoperability with other resource reservation schemes
and can be applied in different types of networks as long as they are
Diffserv domains. It aims at extreme simplicity and low cost of
implementation along with good scaling properties.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westberg-rmd-framework-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-westberg-rmd-framework-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-westberg-rmd-framework-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-5-29072634.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-westberg-rmd-framework-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-westberg-rmd-framework-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-5-29072634.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Thu May 29 07:25:54 2003
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 HAA27113
	for <nsis-archive@odin.ietf.org>; Thu, 29 May 2003 07:25:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4TBPOr12216
	for nsis-archive@odin.ietf.org; Thu, 29 May 2003 07:25:24 -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 h4TBPKB12193;
	Thu, 29 May 2003 07:25:20 -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 h4TBJeB11966
	for <nsis@optimus.ietf.org>; Thu, 29 May 2003 07:19:40 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26789;
	Thu, 29 May 2003 07:19:38 -0400 (EDT)
Message-Id: <200305291119.HAA26789@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: nsis@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 29 May 2003 07:19:38 -0400
Subject: [NSIS] I-D ACTION:draft-couturier-nsis-measure-00.txt
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Signaling for QoS Measurement
	Author(s)	: A. Couturier
	Filename	: draft-couturier-nsis-measure-00.txt
	Pages		: 19
	Date		: 2003-5-28
	
This document defines SQM (Signaling for QoS Measurement), an 
architecture for QoS measurements of IP flows along their paths. The 
goal of this architecture is to configure on demand several probes, 
and to collect and coordinate the results in a multi domain 
environment, in order to determine in real time the QoS experienced 
by a flow on several nodes of its path. A new signaling is used to 
install metering and reporting states in network nodes. A 
coordination of works related to NSIS, PSAMP and IPFIX could achieve 
the SQM specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-couturier-nsis-measure-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-couturier-nsis-measure-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-couturier-nsis-measure-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-5-29072645.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-couturier-nsis-measure-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-couturier-nsis-measure-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-5-29072645.I-D@ietf.org>

--OtherAccess--

--NextPart--


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