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 ; 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 ; 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 ; 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" To: Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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

Hi John

Could you please inform about the = status of=20 the

NTLP protocol design considerations work?

I am actually very much interested in contributing

to this work!

Best Regards,

Georgios

------=_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 ; 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 ; 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 ; 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 ; 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 ; 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: Thread-Topic: regarding NTLP protocol design considerations work Thread-Index: AcMTo62cpzHJh/iTTTasEgnllm6ZKgAypkZg To: Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Thu, 8 May 2003 13:17:04 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA98E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" To: "Hancock, Robert" , 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Fri, 9 May 2003 17:58:33 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA998@rsys002a.roke.co.uk> From: "Hancock, Robert" 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Fri, 9 May 2003 20:33:03 +0200 (MEST) Message-ID: <000e01c31659$834455e0$d307c289@enst.fr> From: "Thanh Tra LUU" To: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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

Hello everyone,

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

Thanks,

Nary Tra,

ENST, Paris.

Tel: (0033) (0) 1 45 81 71=20 06

------=_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 ; 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 ; 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 ; 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 ; Sun, 11 May 2003 22:20:15 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE660157223B@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Thanh Tra LUU'" , 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ) 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

H= i, Nary.

<= ![if = !supportEmptyParas]>

T= here are two concepts of NSIS proxies discussed in the = framework:

S= o 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)<= o:p>
P= roxies for signaling applications that require/use some off-path = processing facilities

<= ![if = !supportEmptyParas]>

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.

<= ![if = !supportEmptyParas]>

B= est regards,

I= lya Freytsis

<= ![if = !supportEmptyParas]>

-----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,<= /font>=

Nary Tra,

ENST, Paris.

Tel: (0033) (0) 1 45 81 71 06

------_=_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 ; 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 ; 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 ; 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 ; Mon, 12 May 2003 09:46:43 +0200 (MEST) Subject: RE: [NSIS] state management and the nsis framework To: "Hancock, Robert" Cc: nsis@ietf.org Date: Mon, 12 May 2003 09:46:41 +0200 Message-ID: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert, See inline. Regards. Maarten "Hancock, Robert" @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 ; 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 ; 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 ; 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 ; Mon, 12 May 2003 09:38:00 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA999@rsys002a.roke.co.uk> From: "Hancock, Robert" 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" To: "Hancock, Robert" Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; 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 ; 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: Thread-Topic: [NSIS] state management and the nsis framework Thread-Index: AcMYYvtoxlmoLpJES86EWwwLE6fuYAAGQWMA To: , 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Mon, 12 May 2003 13:36:20 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA99C@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis'" 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Mon, 12 May 2003 13:46:33 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA99D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" To: "Hancock, Robert" Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; 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 ; 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: Thread-Topic: [NSIS] state management and the nsis framework Thread-Index: AcMYhJl7ENLzZYzWT0eohZGwkepNUwArHcfg To: , 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Tue, 13 May 2003 11:45:51 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9A7@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Tue, 13 May 2003 11:49:51 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9A8@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis'" 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Tue, 13 May 2003 11:57:57 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA9A9@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis'" 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" cc: nsis@ietf.org From: Melinda Shore 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; 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 ; 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: Thread-Topic: [NSIS] state management and the nsis framework Thread-Index: AcMZSVZTjQRdt0AVRQOJ54uCVi80zgAAEsmg To: , Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" To: "Melinda Shore" Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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" To: "Hancock, Robert" Cc: 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 ; 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 ; 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 ; 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" To: "Hancock, Robert" Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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 ; Tue, 13 May 2003 15:03:06 +0100 Message-ID: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" To: Cc: References: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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: To: ; Cc: 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 ; 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 ; 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 ; 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 ; Tue, 13 May 2003 16:33:38 +0100 Message-ID: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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: To: ; Cc: 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 ; 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 ; 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 ; 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 ; Tue, 13 May 2003 11:47:35 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE660157224B@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis'" , 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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: To: ; Cc: 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 ; 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 ; 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 ; 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 ; Wed, 14 May 2003 08:41:06 +0200 (MEST) Message-ID: <000c01c319e3$f65a75e0$d307c289@enst.fr> From: "Thanh Tra LUU" To: References: <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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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 ; 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 ; 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 ; 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" To: "Freytsis, Ilya" Cc: 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: , List-Id: Next Steps in Signaling List-Post: List-Help: List-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" To: "'Georgios Karagiannis'" ; Cc: 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: > To: ; > Cc: > 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 ; 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 ; 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 ; 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" To: