From mailnull@www1.ietf.org Tue Apr 1 04:45:25 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 EAA02415 for ; Tue, 1 Apr 2003 04:45:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31A95v15091 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 05:09:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31A8qK15065; Tue, 1 Apr 2003 05:08:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31A7eK15032 for ; Tue, 1 Apr 2003 05:07:40 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02367 for ; Tue, 1 Apr 2003 04:43:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h319nm503565 for ; Tue, 1 Apr 2003 12:49:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 12:45:52 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 12:45:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 12:45:47 +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 question Date: Tue, 1 Apr 2003 12:45:43 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL3mo3Vz5Or6+WPRv2qxTR7eHAstQAmKTAw To: , Cc: , X-OriginalArrivalTime: 01 Apr 2003 09:45:47.0441 (UTC) FILETIME=[78DAA210:01C2F833] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31A7eK15033 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 Melinda, > > Sorry, I disagree here if you do not include RFC 2961 as well. > > If I remember correctly, there was a consensus to use at least > > both 2205+2961 as a starting point. > > That is correct, although that decision should probably be > confirmed on the mailing list. I don't recall anybody > voicing objection to it at the meeting. There was no object at the meeting - however, I'll send a mail, to confirm the consensus. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 05:18:39 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 FAA02959 for ; Tue, 1 Apr 2003 05:18:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31AgK716858 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 05:42:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31AgBK16850; Tue, 1 Apr 2003 05:42:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31AftK16831 for ; Tue, 1 Apr 2003 05:41:55 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02934 for ; Tue, 1 Apr 2003 05:17:42 -0500 (EST) From: john.loughney@nokia.com 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.5) with ESMTP id h31AO4513308 for ; Tue, 1 Apr 2003 13:24:04 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 1 Apr 2003 12:50:08 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 12:50:04 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 12:50:04 +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: Tue, 1 Apr 2003 12:50:03 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL3mo3Vz5Or6+WPRv2qxTR7eHAstQAmOpFQ To: X-OriginalArrivalTime: 01 Apr 2003 09:50:04.0346 (UTC) FILETIME=[11FB39A0:01C2F834] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31AftK16832 Subject: [NSIS] Initial attempt at NTLP - call for consensus: 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, At IETF 56, I made the following suggestion for starting the NTLP work: Starting point Based on RSVP (RFC2205 + RFC2961) Separate service specific stuff out Separate flow spec & session id Keep semantics of PATH (discovery & transport combined) Support Soft state Support of RSVP-proxies Open issues to address (need consensus) Logically separate discovery & transport, in practice they could be piggybacked. Message fragmentation concerns Reliability concerns Optionally supporting other transport protocols Reduction of multicast complexity Support RFC2752 / policy issues Routing interaction (handling mid-session path splitting) Support for explicitly stating message directionality & hop-by-hop vs. end-to-end. Please comment on the above, if you feel that you can live with above suggested starting point. I have asked Henning Schulzrinne & Melinda Shore to put together an initial proposal on the NTLP, for the working group to consider. My hope is that we have a stable starting point for this work already by IETF 57 in Vienna. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 06:45:07 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 GAA04521 for ; Tue, 1 Apr 2003 06:45:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31C8p222315 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 07:08:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31C8iK22304; Tue, 1 Apr 2003 07:08:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31C5EK21416 for ; Tue, 1 Apr 2003 07:05:14 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04428 for ; Tue, 1 Apr 2003 06:40:55 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 12:43:21 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8FF@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Initial attempt at NTLP - call for consensus: Date: Tue, 1 Apr 2003 12:43:16 +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, it might be helpful for some of us if you were able to categorise the points in the list below according to whether they are agreement/questions about a) what the NTLP should do, or b) how the NTLP should do it some of them are clearly (b), others seem more like partly (a) [which cannot then be answered by thinking about the NTLP in isolation, i would contend] in particular, what is the actual meaning/content of 'support soft state'? cheers, robert h. ps. are you going to probe consensus on the interim meeting results in the same way? even despite having been there, i didn't recognise some of them when presented in San Francisco. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 01 April 2003 10:50 > To: nsis@ietf.org > Subject: [NSIS] Initial attempt at NTLP - call for consensus: > > > Hi, > > At IETF 56, I made the following suggestion for starting the > NTLP work: > > Starting point > Based on RSVP (RFC2205 + RFC2961) > Separate service specific stuff out > Separate flow spec & session id > Keep semantics of PATH (discovery & transport combined) > Support Soft state > Support of RSVP-proxies > > Open issues to address (need consensus) > Logically separate discovery & transport, in practice they > could be piggybacked. > Message fragmentation concerns > Reliability concerns > Optionally supporting other transport protocols > Reduction of multicast complexity > Support RFC2752 / policy issues > Routing interaction (handling mid-session path splitting) > Support for explicitly stating message directionality & > hop-by-hop vs. end-to-end. > > Please comment on the above, if you feel that you can live > with above suggested starting point. > > I have asked Henning Schulzrinne & Melinda Shore to put > together an initial proposal on the NTLP, for the working > group to consider. My hope is that we have a stable starting > point for this work already by IETF 57 in Vienna. > > br, > John > _______________________________________________ > 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 Apr 1 07:26: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 HAA07690 for ; Tue, 1 Apr 2003 07:26:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Codi25139 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 07:50:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CoOK25126; Tue, 1 Apr 2003 07:50:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31ClAK24920 for ; Tue, 1 Apr 2003 07:47:10 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07503 for ; Tue, 1 Apr 2003 07:22:53 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 13:25:20 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA903@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Tom Taylor'" Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Tue, 1 Apr 2003 13:25:12 +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: , Tom, thanks (especially for the "totally"). At the NTLP level, we are (probably) talking about state variables including next/previous NTLP peer, time since message last sent/received, and maybe a bit more information about those peers (e.g. what security association to use to talk to them, retransmission timers and so on). *However* a) how much such state there is depends on the details of NTLP functionality b) how that state is managed is in principle invisible unless you are looking inside the NTLP design itself (which I am trying not to do here). At the NSLP level, the state variables depend on the signalling application. For a soft-state resource management application, one could imagine them including a resource description, time since last update sent/received, time until expiration, maybe some status information for reservations in the process of being installed/torn down (2209 has plenty of detail of the sort of thing one might want). Other signalling applications might have rather different state requirements (including none at all). Each signalling application would clearly have its own set. The question for us is: should the NTLP have the functionality to manage some aspects of the NSLP state variables (e.g. generating refresh messages for a resource). At the moment, my assumption is 'no', and I'm finding difficulty getting disagreement except about aspects which can be handled inside an NSLP/NTLP implementation without visible protocol impact. This does have some implications for other aspects of NTLP functionality, however. Hoping this is not totally obscure, Robert H. > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: 31 March 2003 17:27 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] state management question > > > I've seen enough of this dialogue now to decide that this is > not a totally stupid > question. Could we possibly get a bit more concrete and > indicate what sort of state > variables we are talking about at the NTLP level? Is it > next-NTLP-hop for a given > NTLP session, and what else? > > Hancock, Robert wrote: > > Georgios, > > > > That is one aspect of the question. > > > > another way to put it: > > Should there be a single state management procedure which > all signalling applications (and indeed all NSIS entities) > have to use? > > OR > > Should we decouple the lower and upper layers and allow a > clever implementor to integrate them for efficiency for > particular signalling applications? > > > > (i prefer the second.) > > > > another way to put it: > > Should the NTLP internal design be determined by the state > management service it offers externally to signalling applications ? > > > > (sounds like a bad idea to me, though i admit i am more > influenced by philosophical considerations in holding that view.) > > > > cheers, > > > > robert h. > > > > > >>-----Original Message----- > >>From: Georgios Karagiannis (ELN) > >>[mailto:Georgios.Karagiannis@eln.ericsson.se] > >>Sent: 31 March 2003 16:16 > >>To: Hancock, Robert; nsis@ietf.org > >>Subject: RE: [NSIS] state management question > >> > >> > >>Hi Robert > >> > >>I do not understand your question. > >>Are you saying that we need to have two > >>refresh management procedures? > >>One for NTLP states and one for NSLP states! > >> > >>Best Regards, > >>Georgios > >> > >>-----Original Message----- > >>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > >>Sent: maandag 31 maart 2003 17:13 > >>To: Georgios Karagiannis (ELN); nsis@ietf.org > >>Subject: RE: [NSIS] state management question > >> > >> > >>hi georgios, > >> > >>you are right to point out this difference. > >>(in the email at the start of the thread: "(Note that this is > >>entirely not about state that the NTLP uses internally, e.g. > >>to route messages correctly.)") > >> > >>so, my question is about the assertion: > >>"One can use the NTLP state management procedure to maintain > >>the NSLP reservation) states" > >> > >>(can one really? is it a good idea? is it more than an > >>implementation issue?) > >> > >>especially, if it is more than an implementation issue, > >>***what is the actual impact on the protocol?*** (in broad > >>terms, or giving an example) > >> > >>cheers, > >> > >>r. > >> > >> > >>>-----Original Message----- > >>>From: Georgios Karagiannis (ELN) > >>>[mailto:Georgios.Karagiannis@eln.ericsson.se] > >>>Sent: 31 March 2003 16:04 > >>>To: Hancock, Robert; nsis@ietf.org > >>>Subject: RE: [NSIS] state management question > >>> > >>> > >>>Hi Robert > >>> > >>>The NTLP states are in my opinion different than the > >>>NSLP states. > >>>The NTLP states are more associated with forwarding behavior and > >>>the NSLP application states are reservation states. > >>>One can use the NTLP state management procedure to maintain the > >>>NSLP (reservation) states, but this cannot be done the other > >>>way around! > >>>This is for example valid when not all NSIS nodes support > >>>NSLP functionality > >>>(but they support NTLP functionality). > >>> > >>>Best Regards, > >>>Georgios > >>> > >>>-----Original Message----- > >>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > >>>Sent: maandag 31 maart 2003 16:42 > >>>To: Georgios Karagiannis (ELN); nsis@ietf.org > >>>Subject: RE: [NSIS] state management question > >>> > >>> > >>>georgios, > >>> > >>>two questions: > >>>*) regardless of whether the general idea of soft stateness > >>>is good and how well it works in RSVP, why support it > >>>explicitly in the NTLP - why isn't this a signalling > >>>application issue? if something is needed in the NTLP, why > >>>isn't it an implementation issue? > >>>*) assuming the answer is still 'it is meaningfully part of > >>>the NTLP', what kind of detectable impact on the actual > >>>protocol would you expect it to have? > >>> > >>>what i'm trying to make progress from is the generalised view > >>>'let's put soft state in the NTLP' and turn that into a > >>>concrete statement whose impact on the framework can be > >>>evaluated. at the moment, it seems to be a matter of opinion > >>>whether the question has no meaning or very deep meaning (at > >>>least to me). > >>> > >>>robert h. > >>> > >>> > >>>>-----Original Message----- > >>>>From: Georgios Karagiannis (ELN) > >>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] > >>>>Sent: 31 March 2003 14:49 > >>>>To: nsis@ietf.org > >>>>Subject: RE: [NSIS] state management question > >>>> > >>>> > >>>>Hi all > >>>> > >>>>Since the RSVPv1 (RFC2205) refresh procedure and the > >>>>management of refresh > >>>>timers work quite well I think that it should be reasonable > >>>>to try and > >>>>reuse them in NTLP. > >>>> > >>>>Best Regards, > >>>>Georgios > >>>> > >>>>-----Original Message----- > >>>>From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > >>>>Sent: donderdag 27 maart 2003 9:51 > >>>>To: robert.hancock@roke.co.uk > >>>>Cc: nsis@ietf.org > >>>>Subject: RE: [NSIS] state management question > >>>> > >>>> > >>>>Robert, > >>>> > >>>>my answers on your final questions in line. I've > >>>>added some text on the message sequence number > >>>>mechanism, which I think is another issue > >>>>raising concerns. > >>>> > >>>>Regards, Rüdiger > >>>> > >>>> > >>>>| To make it concrete in this case: > >>>>| - should the NTLP contain fields which are refresh times? > >>>>| always? sometimes? > >>>> > >>>>Don't think so. Local time information should be used to > >>>>maintain state only. Also a refresh reduction mechanism > >>>>shouldn't require timestamps to be transmitted. If possible. > >>>> > >>>>| - should the NTLP have a bit in its header which > >>>>| distinguishes between state refreshing and other messages? > >>>> > >>>>As the refresh message initiates completely new state in the > >>>>case of a route change in new routers, the refreshes > >>>>shouldn't be "marked". Your idea is to distinguish between a > >>>>refresh of state and a modification of this state? > >>>>Valid Point. It may be more useful to have > >>>>"state set up & modification" messages instead of > >>>>"state set up & refresh" messages. The NLTP > >>>>receiving a "state set up" with an already existing session > >>>>ID knows that this is a refresh and acts accordingly. > >>>> > >>>>| - should the NTLP make up its own mind whether to acknowledge > >>>>| state creation or deletion messages? > >>>> > >>>>The fast answer is: no, that's an issue of NSLP. It gets > >>>>tricky should NTLP maintain state also for services without > >>>>local NSLP support (the NTLP relay case). I think we should > >>>>clarify what these NTLP relay nodes are supposed to do with > >>>>messages they have no NSLP support for. Or whether we > >>>>allow such a NTLP relay function at all. My personal > >>>>feeling is: > >>>>- NTLP relay may be useful. > >>>>- NTLP service state maintenance only if NSLP is present. > >>>>In this case, each NTLP node must interpret the NSLP field > >>>>of a "state set up" message first and then check the > >>>>session ID. > >>>> > >>>>A concern I have is whether to maintain sequence numbers in > >>>>NTLP or NSLP only or whether to maintain them on both > >>>>layers. If refreshes are handled by NTLP only, NTLP must > >>>>be aware of the sequence numbers. It must maintain the > >>>>service specific sequence numbering mechanism too. In the > >>>>case of an NTLP relay, there's no service specific state, > >>>>hence there's no sequence number maintenance (for relayed > >>>>messages). It might be advantageous to let the sequence > >>>>number mechanism count messages between adjacent NTLP > >>>>peers only. > >>>> > >>>>_______________________________________________ > >>>>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 Tue Apr 1 08:03:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08714 for ; Tue, 1 Apr 2003 08:03:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31DRac27116 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 08:27:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DRRK27106; Tue, 1 Apr 2003 08:27:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DOSK27007 for ; Tue, 1 Apr 2003 08:24:28 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08639 for ; Tue, 1 Apr 2003 08:00:11 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h31D18N05548 for ; Tue, 1 Apr 2003 16:01:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 16:02:36 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:02:37 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:02:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Initial attempt at NTLP - call for consensus: Date: Tue, 1 Apr 2003 16:01:53 +0300 Message-ID: Thread-Topic: [NSIS] Initial attempt at NTLP - call for consensus: Thread-Index: AcL4Q+eAtSOYLO4+SuGHqxbo8WfCsQACdDkg To: , X-OriginalArrivalTime: 01 Apr 2003 13:02:27.0604 (UTC) FILETIME=[F24C9D40:01C2F84E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31DOSK27008 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, > it might be helpful for some of us if you were able to > categorise the points in the list below according to whether > they are agreement/questions about > a) what the NTLP should do, or > b) how the NTLP should do it > > some of them are clearly (b), others seem more like partly > (a) [which cannot then be answered by thinking about the NTLP > in isolation, i would contend] The points I made at the meeting are just meant as starting points for the work - I think part of the what & how are left up to the protocol design stage, which, I hope, is what we are in know. I don't want to get into mandating the protocol design - if you have opinions on the what & the how, now is a good time air your opinions. With regards to starting with RSVP (RFC2205 + RFC2961) - please note, we are not required to be backwards compatible. > in particular, what is the actual meaning/content of 'support > soft state'? In my mind, soft state is state which is not tied to a transport layer connection & will eventually expire. Supporting soft state means that the state which NTLP transport should be soft state. Again, the semantics of how soft soft is, I think, should be part of the protocol design. > ps. are you going to probe consensus on the interim meeting > results in the same way? even despite having been there, i > didn't recognise some of them when presented in San Francisco. As there were no comments on the meeting minutes on the list nor at the meeting, there seemed nothing to probe. I will send my summary to the list - any anyone with comments, clarification or anything I missed are encouraged to speak up. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 08:11:28 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 IAA08853 for ; Tue, 1 Apr 2003 08:11:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31DZEm27450 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 08:35:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DZ9K27443; Tue, 1 Apr 2003 08:35:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DWiK27360 for ; Tue, 1 Apr 2003 08:32:44 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08815 for ; Tue, 1 Apr 2003 08:08:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h31D9ON15208 for ; Tue, 1 Apr 2003 16:09:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 1 Apr 2003 16:10:52 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:10:54 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:07:06 +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: Tue, 1 Apr 2003 16:07:06 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL4Sk+UcqymNSPPSY2czYcai/YGqgABNmow To: X-OriginalArrivalTime: 01 Apr 2003 13:07:07.0184 (UTC) FILETIME=[98F12300:01C2F84F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31DWiK27361 Subject: [NSIS] Interim meeting notes from IETF 56 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, At IETF 56, I presented a short summary of the interim meeting - what I thought were some important points. If I have left anything out or misconstrued things, please speak up. - Seperate transport layer protocol state from NTLP state - Soft-state refresh supported independent of transport protocol state. - Extensibility should be provided (see something which a node does not understand, session should not fail) - Seperate flow identifier and session identifier. - Session identifier should be unique. - Don't overload ids - Link-based congestion control is not a good thing. - Scoping of requests should be avoided (see IPv6 mailing list) Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 08:17: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 IAA09179 for ; Tue, 1 Apr 2003 08:17:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31DfJc28433 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 08:41:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DfBK28423; Tue, 1 Apr 2003 08:41:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DcJK28294 for ; Tue, 1 Apr 2003 08:38:19 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09023 for ; Tue, 1 Apr 2003 08:14:02 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h31DJd524835 for ; Tue, 1 Apr 2003 16:19:39 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 16:15:43 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:15:41 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:15:40 +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 question Date: Tue, 1 Apr 2003 16:15:37 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL3lGHZVqTLTvD3RrWsAqBUqv7CugAu5dVA To: , Cc: X-OriginalArrivalTime: 01 Apr 2003 13:15:41.0034 (UTC) FILETIME=[CB386CA0:01C2F850] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31DcJK28295 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, > I am not against on combining RFC2205 and RFC2961 for providing > state management, but in my opinion > RFC2961 is used as an optimization solution and therefore, > it should not be stated as a mandatory solution, but as an > optional solution! 2961 was a response to issues found in RSVP deployment. I think that if we ignore them, it would be unwise. At present, I think we should include them into the design of NTLP - however, they functionality may be considered as something which needs to be supported but not mandatory to use. If you have issues with parts of 2961, it would be interesting to know what are the technical issues, etc. that you have. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 08:22:29 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 IAA09525 for ; Tue, 1 Apr 2003 08:22:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31DkFS28693 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 08:46:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Dk9K28685; Tue, 1 Apr 2003 08:46:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DheK28591 for ; Tue, 1 Apr 2003 08:43:40 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09393 for ; Tue, 1 Apr 2003 08:19:23 -0500 (EST) From: john.loughney@nokia.com 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.5) with ESMTP id h31DFJN22521 for ; Tue, 1 Apr 2003 16:15:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 16:16:49 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:16:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:16:48 +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-15" Subject: RE: [NSIS] state management question Date: Tue, 1 Apr 2003 16:16:48 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL3lwxlPyU4y2o8Rt+cCbzj/voOngAudEZg To: , Cc: X-OriginalArrivalTime: 01 Apr 2003 13:16:48.0882 (UTC) FILETIME=[F3A93520:01C2F850] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31DhfK28592 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 Roland, > > RFC2961 describes an optimization procedure! > > IMO it describes a number of operational problems > and solutions for them due to feedback of implementers > and operators. RFC 2961 won't be there if it was pure > optimization. However, there may be some environments > in which these extensions are not necessarily required. > But I got the impression from several discussions that > most people think that RFC 2205 alone is not sufficient for > most cases. I agree & paraphrasing, the extensions are probably mandatory to implement - optional to use. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 08:25:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09586 for ; Tue, 1 Apr 2003 08:25:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31DnQM28806 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 08:49:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DnBK28796; Tue, 1 Apr 2003 08:49:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DiFK28609 for ; Tue, 1 Apr 2003 08:44:15 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09448 for ; Tue, 1 Apr 2003 08:19:58 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 14:22:25 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA907@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Initial attempt at NTLP - call for consensus: Date: Tue, 1 Apr 2003 14:22:19 +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, a quick first question - are you saying that *what* the NTLP should do (i.e. what functions it should have) is a protocol *design* question? > > in particular, what is the actual meaning/content of 'support > > soft state'? > > In my mind, soft state is state which is not tied to a transport > layer connection & will eventually expire. Supporting soft state > means that the state which NTLP transport should be soft state. > Again, the semantics of how soft soft is, I think, should be > part of the protocol design. my question here would be, in concrete terms, how is the NTLP functionality (not internal design) impacted by the fact that the (signalling application) state is soft (or indeed that the information is 'state' information in the first place)? robert h. ps. if the consensus is that i am obsessing pointlessly about this question, i'll be happy to shut up. however, the fact that some people think this is important protocol functionality, and others think this is not protocol related at all, seems somehow disconcerting to me. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 08:34:31 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 IAA09797 for ; Tue, 1 Apr 2003 08:34:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31DwH929177 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 08:58:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31DwDK29170; Tue, 1 Apr 2003 08:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Dt5K29072 for ; Tue, 1 Apr 2003 08:55:05 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09689 for ; Tue, 1 Apr 2003 08:30:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h31DbA508927 for ; Tue, 1 Apr 2003 16:37:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 16:33:14 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:33:14 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:33:13 +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] Initial attempt at NTLP - call for consensus: Date: Tue, 1 Apr 2003 16:33:13 +0300 Message-ID: Thread-Topic: [NSIS] Initial attempt at NTLP - call for consensus: Thread-Index: AcL4UneDscQqv/qQQg2rnUeXbl0iawAAA8nw To: , X-OriginalArrivalTime: 01 Apr 2003 13:33:13.0854 (UTC) FILETIME=[3EC001E0:01C2F853] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31Dt5K29073 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, > a quick first question - are you saying that *what* the NTLP should do > (i.e. what functions it should have) is a protocol *design* question? What I mean is that the particular functions it has, with regards to the layer split is part of the design, yes. That layer split should be captured in the framework. > > > in particular, what is the actual meaning/content of 'support > > > soft state'? > > > > In my mind, soft state is state which is not tied to a transport > > layer connection & will eventually expire. Supporting soft state > > means that the state which NTLP transport should be soft state. > > Again, the semantics of how soft soft is, I think, should be > > part of the protocol design. > > my question here would be, in concrete terms, how is the NTLP functionality > (not internal design) impacted by the fact that the (signalling application) > state is soft (or indeed that the information is 'state' information in > the first place)? The impact is that existence of an NTLP (or lower layer protocol) 'connection' should not imply liveliness of state. Periodic refreshes should be considered as the way to keep state alive. John > robert h. > > ps. if the consensus is that i am obsessing pointlessly about this question, > i'll be happy to shut up. however, the fact that some people think this > is important protocol functionality, and others think this is not protocol > related at all, seems somehow disconcerting to me. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 08:50:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10950 for ; Tue, 1 Apr 2003 08:50:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31EEIf05552 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 09:14:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EEEK05491; Tue, 1 Apr 2003 09:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EB5K03028 for ; Tue, 1 Apr 2003 09:11:05 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10479 for ; Tue, 1 Apr 2003 08:46:47 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 14:49:15 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA908@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Interim meeting notes from IETF 56 Date: Tue, 1 Apr 2003 14:49:11 +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, three comments: > - Seperate transport layer protocol state from NTLP state IIRC what was discussed was separating signalling application state from NTLP state; for example, even if the NTLP uses a 'connection' concept, the signalling application state doesn't fate-share with it. Maybe a better phrasing would be 'any internal state used by the NTLP is not visible outside the NTLP'. [I think we're in agreement on this, it's just a question of how to say it.] (The distinction between 'transport layer protocol state' and 'NTLP state' is somewhat awkward since 'TLP' stands for 'transport layer protocol' as well. Personally, I would rather call the NTLP something else. What we are sometimes trying to do is discuss how NSIS-specific functions interact with general transport-related functions, but that's hard to do in protocol terminology without making provocative assumptions about the design of what goes below the signalling applications.) > - Link-based congestion control is not a good thing. The minutes and my recollection of this discussion are equally confused. I think it was clear that relying *only* on local congestion control is not good enough, you need something operating above it as well. If the claim is that local congestion control is actually *harmful*, I'd be interested in a pointer. In particular, I don't see how TCP experience can be directly applied here since, as well as the flow endpoints, there are locations inside the network which keep state and generate messages autonomously. > - Scoping of requests should be avoided (see IPv6 mailing list) In retrospect, I think we didn't do justice to this question. The scoping question that is relevant to NSIS is something like 'limiting the region in which a message can be propagated' which a lot of people seem to like (it's just RSVP proxy operation). The violent, interminable, mind-numbing v6 scoped address argument is I think about quite different things - in particular, the origin of the controversy is in the ability to use ambiguous identifiers, to have identifiers which can be locally allocated, and so on. No one is proposing anything of the sort for NSIS [yet!!], so the v6 lesson doesn't apply. (Which layer - NTLP/NSLP - should play a part in such scoping is of course still very open.) > > Thanks, > John a pleasure, robert h. > _______________________________________________ > 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 Apr 1 09:09: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 JAA12066 for ; Tue, 1 Apr 2003 09:09:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31EXKG11357 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 09:33:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EXCK11340; Tue, 1 Apr 2003 09:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EUBK10729 for ; Tue, 1 Apr 2003 09:30:11 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11906 for ; Tue, 1 Apr 2003 09:05:51 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31E8FP13666; Tue, 1 Apr 2003 09:08:16 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFDAGKW; Tue, 1 Apr 2003 09:08:16 -0500 Received: from nortelnetworks.com (acart1be.ca.nortel.com [47.129.129.24]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWLQ3; Tue, 1 Apr 2003 09:08:15 -0500 Message-ID: <3E899D4E.2080806@nortelnetworks.com> Date: Tue, 01 Apr 2003 09:08:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] state management question References: <76C92FBBFB58D411AE760090271ED4181EA903@rsys002a.roke.co.uk> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA903@rsys002a.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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 And thank you. This makes total sense. I started to give a quick answer on the separation of NTLP and NSLP states but found I need to think a little more about it. One question is whether the same NTLP path will serve more than one NSLP application (e.g. resource reservation, firewall control) at once. Hancock, Robert wrote: > Tom, > > thanks (especially for the "totally"). > > At the NTLP level, we are (probably) talking about state variables including next/previous NTLP peer, time since message last sent/received, and maybe a bit more information about those peers (e.g. what security association to use to talk to them, retransmission timers and so on). *However* > a) how much such state there is depends on the details of NTLP functionality > b) how that state is managed is in principle invisible unless you are looking inside the NTLP design itself (which I am trying not to do here). > > At the NSLP level, the state variables depend on the signalling application. For a soft-state resource management application, one could imagine them including a resource description, time since last update sent/received, time until expiration, maybe some status information for reservations in the process of being installed/torn down (2209 has plenty of detail of the sort of thing one might want). Other signalling applications might have rather different state requirements (including none at all). Each signalling application would clearly have its own set. > > The question for us is: should the NTLP have the functionality to manage some aspects of the NSLP state variables (e.g. generating refresh messages for a resource). At the moment, my assumption is 'no', and I'm finding difficulty getting disagreement except about aspects which can be handled inside an NSLP/NTLP implementation without visible protocol impact. This does have some implications for other aspects of NTLP functionality, however. > > Hoping this is not totally obscure, > > Robert H. > > >>-----Original Message----- >>From: Tom Taylor [mailto:taylor@nortelnetworks.com] >>Sent: 31 March 2003 17:27 >>To: Hancock, Robert >>Cc: nsis@ietf.org >>Subject: Re: [NSIS] state management question >> >> >>I've seen enough of this dialogue now to decide that this is >>not a totally stupid >>question. Could we possibly get a bit more concrete and >>indicate what sort of state >>variables we are talking about at the NTLP level? Is it >>next-NTLP-hop for a given >>NTLP session, and what else? >> >>Hancock, Robert wrote: >> >>>Georgios, >>> >>>That is one aspect of the question. >>> >>>another way to put it: >>>Should there be a single state management procedure which >> >>all signalling applications (and indeed all NSIS entities) >>have to use? >> >>>OR >>>Should we decouple the lower and upper layers and allow a >> >>clever implementor to integrate them for efficiency for >>particular signalling applications? >> >>>(i prefer the second.) >>> >>>another way to put it: >>>Should the NTLP internal design be determined by the state >> >>management service it offers externally to signalling applications ? >> >>>(sounds like a bad idea to me, though i admit i am more >> >>influenced by philosophical considerations in holding that view.) >> >>>cheers, >>> >>>robert h. >>> >>> >>> >>>>-----Original Message----- >>>>From: Georgios Karagiannis (ELN) >>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>>>Sent: 31 March 2003 16:16 >>>>To: Hancock, Robert; nsis@ietf.org >>>>Subject: RE: [NSIS] state management question >>>> >>>> >>>>Hi Robert >>>> >>>>I do not understand your question. >>>>Are you saying that we need to have two >>>>refresh management procedures? >>>>One for NTLP states and one for NSLP states! >>>> >>>>Best Regards, >>>>Georgios >>>> >>>>-----Original Message----- >>>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>>>Sent: maandag 31 maart 2003 17:13 >>>>To: Georgios Karagiannis (ELN); nsis@ietf.org >>>>Subject: RE: [NSIS] state management question >>>> >>>> >>>>hi georgios, >>>> >>>>you are right to point out this difference. >>>>(in the email at the start of the thread: "(Note that this is >>>>entirely not about state that the NTLP uses internally, e.g. >>>>to route messages correctly.)") >>>> >>>>so, my question is about the assertion: >>>>"One can use the NTLP state management procedure to maintain >>>>the NSLP reservation) states" >>>> >>>>(can one really? is it a good idea? is it more than an >>>>implementation issue?) >>>> >>>>especially, if it is more than an implementation issue, >>>>***what is the actual impact on the protocol?*** (in broad >>>>terms, or giving an example) >>>> >>>>cheers, >>>> >>>>r. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Georgios Karagiannis (ELN) >>>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>>>>Sent: 31 March 2003 16:04 >>>>>To: Hancock, Robert; nsis@ietf.org >>>>>Subject: RE: [NSIS] state management question >>>>> >>>>> >>>>>Hi Robert >>>>> >>>>>The NTLP states are in my opinion different than the >>>>>NSLP states. >>>>>The NTLP states are more associated with forwarding behavior and >>>>>the NSLP application states are reservation states. >>>>>One can use the NTLP state management procedure to maintain the >>>>>NSLP (reservation) states, but this cannot be done the other >>>>>way around! >>>>>This is for example valid when not all NSIS nodes support >>>>>NSLP functionality >>>>>(but they support NTLP functionality). >>>>> >>>>>Best Regards, >>>>>Georgios >>>>> >>>>>-----Original Message----- >>>>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>>>>Sent: maandag 31 maart 2003 16:42 >>>>>To: Georgios Karagiannis (ELN); nsis@ietf.org >>>>>Subject: RE: [NSIS] state management question >>>>> >>>>> >>>>>georgios, >>>>> >>>>>two questions: >>>>>*) regardless of whether the general idea of soft stateness >>>>>is good and how well it works in RSVP, why support it >>>>>explicitly in the NTLP - why isn't this a signalling >>>>>application issue? if something is needed in the NTLP, why >>>>>isn't it an implementation issue? >>>>>*) assuming the answer is still 'it is meaningfully part of >>>>>the NTLP', what kind of detectable impact on the actual >>>>>protocol would you expect it to have? >>>>> >>>>>what i'm trying to make progress from is the generalised view >>>>>'let's put soft state in the NTLP' and turn that into a >>>>>concrete statement whose impact on the framework can be >>>>>evaluated. at the moment, it seems to be a matter of opinion >>>>>whether the question has no meaning or very deep meaning (at >>>>>least to me). >>>>> >>>>>robert h. >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Georgios Karagiannis (ELN) >>>>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>>>>>Sent: 31 March 2003 14:49 >>>>>>To: nsis@ietf.org >>>>>>Subject: RE: [NSIS] state management question >>>>>> >>>>>> >>>>>>Hi all >>>>>> >>>>>>Since the RSVPv1 (RFC2205) refresh procedure and the >>>>>>management of refresh >>>>>>timers work quite well I think that it should be reasonable >>>>>>to try and >>>>>>reuse them in NTLP. >>>>>> >>>>>>Best Regards, >>>>>>Georgios >>>>>> >>>>>>-----Original Message----- >>>>>>From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >>>>>>Sent: donderdag 27 maart 2003 9:51 >>>>>>To: robert.hancock@roke.co.uk >>>>>>Cc: nsis@ietf.org >>>>>>Subject: RE: [NSIS] state management question >>>>>> >>>>>> >>>>>>Robert, >>>>>> >>>>>>my answers on your final questions in line. I've >>>>>>added some text on the message sequence number >>>>>>mechanism, which I think is another issue >>>>>>raising concerns. >>>>>> >>>>>>Regards, Rüdiger >>>>>> >>>>>> >>>>>>| To make it concrete in this case: >>>>>>| - should the NTLP contain fields which are refresh times? >>>>>>| always? sometimes? >>>>>> >>>>>>Don't think so. Local time information should be used to >>>>>>maintain state only. Also a refresh reduction mechanism >>>>>>shouldn't require timestamps to be transmitted. If possible. >>>>>> >>>>>>| - should the NTLP have a bit in its header which >>>>>>| distinguishes between state refreshing and other messages? >>>>>> >>>>>>As the refresh message initiates completely new state in the >>>>>>case of a route change in new routers, the refreshes >>>>>>shouldn't be "marked". Your idea is to distinguish between a >>>>>>refresh of state and a modification of this state? >>>>>>Valid Point. It may be more useful to have >>>>>>"state set up & modification" messages instead of >>>>>>"state set up & refresh" messages. The NLTP >>>>>>receiving a "state set up" with an already existing session >>>>>>ID knows that this is a refresh and acts accordingly. >>>>>> >>>>>>| - should the NTLP make up its own mind whether to acknowledge >>>>>>| state creation or deletion messages? >>>>>> >>>>>>The fast answer is: no, that's an issue of NSLP. It gets >>>>>>tricky should NTLP maintain state also for services without >>>>>>local NSLP support (the NTLP relay case). I think we should >>>>>>clarify what these NTLP relay nodes are supposed to do with >>>>>>messages they have no NSLP support for. Or whether we >>>>>>allow such a NTLP relay function at all. My personal >>>>>>feeling is: >>>>>>- NTLP relay may be useful. >>>>>>- NTLP service state maintenance only if NSLP is present. >>>>>>In this case, each NTLP node must interpret the NSLP field >>>>>>of a "state set up" message first and then check the >>>>>>session ID. >>>>>> >>>>>>A concern I have is whether to maintain sequence numbers in >>>>>>NTLP or NSLP only or whether to maintain them on both >>>>>>layers. If refreshes are handled by NTLP only, NTLP must >>>>>>be aware of the sequence numbers. It must maintain the >>>>>>service specific sequence numbering mechanism too. In the >>>>>>case of an NTLP relay, there's no service specific state, >>>>>>hence there's no sequence number maintenance (for relayed >>>>>>messages). It might be advantageous to let the sequence >>>>>>number mechanism count messages between adjacent NTLP >>>>>>peers only. >>>>>> >>>>>>_______________________________________________ >>>>>>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 Tue Apr 1 10:15:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18586 for ; Tue, 1 Apr 2003 10:15:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31FdBj02153 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 10:39:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Fd6K02146; Tue, 1 Apr 2003 10:39:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FZxK32401 for ; Tue, 1 Apr 2003 10:35:59 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17992 for ; Tue, 1 Apr 2003 10:11:41 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h31FE5UE018137; Tue, 1 Apr 2003 17:14:05 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A49KY11; Tue, 1 Apr 2003 17:14:06 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 17:13:09 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9F5@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , "'mshore@cisco.com'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] state management question Date: Tue, 1 Apr 2003 17:14:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John I agree with your proposal! Best Regards, georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 1 april 2003 15:16 To: Georgios Karagiannis (ELN); mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Hi Georgios, > I am not against on combining RFC2205 and RFC2961 for providing > state management, but in my opinion > RFC2961 is used as an optimization solution and therefore, > it should not be stated as a mandatory solution, but as an > optional solution! 2961 was a response to issues found in RSVP deployment. I think that if we ignore them, it would be unwise. At present, I think we should include them into the design of NTLP - however, they functionality may be considered as something which needs to be supported but not mandatory to use. If you have issues with parts of 2961, it would be interesting to know what are the technical issues, etc. that you have. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Apr 1 10:32: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 KAA20336 for ; Tue, 1 Apr 2003 10:32:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31FtmF07591 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 10:55:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FtgK07573; Tue, 1 Apr 2003 10:55:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FmcK05721 for ; Tue, 1 Apr 2003 10:48:38 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19761 for ; Tue, 1 Apr 2003 10:24:18 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h31FQirs027575; Tue, 1 Apr 2003 17:26:44 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4KQXMK; Tue, 1 Apr 2003 17:26:45 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 17:15:34 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9F7@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] state management question Date: Tue, 1 Apr 2003 17:26:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert I think that we should anyway decouple the lower and upper layer state management procedures. However, I am in favor of using NTLP refresh messages to refresh the NSLP states. The NSLP refresh procedure can be based on the NTLP refresh procedure in the following way: 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 node is not refreshed on time then the NTLP functionality at this node informs the NSLP state that the refresh procedure is unsuccessful. The NSLP state can then be tear down. Best Regards, Georgios PS. I will be out of office until the 9th of April -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: maandag 31 maart 2003 17:36 To: nsis@ietf.org Subject: RE: [NSIS] state management question Georgios, That is one aspect of the question. another way to put it: Should there be a single state management procedure which all signalling applications (and indeed all NSIS entities) have to use? OR Should we decouple the lower and upper layers and allow a clever implementor to integrate them for efficiency for particular signalling applications? (i prefer the second.) another way to put it: Should the NTLP internal design be determined by the state management service it offers externally to signalling applications ? (sounds like a bad idea to me, though i admit i am more influenced by philosophical considerations in holding that view.) cheers, robert h. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 16:16 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi Robert > > I do not understand your question. > Are you saying that we need to have two > refresh management procedures? > One for NTLP states and one for NSLP states! > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 31 maart 2003 17:13 > To: Georgios Karagiannis (ELN); nsis@ietf.org > Subject: RE: [NSIS] state management question > > > hi georgios, > > you are right to point out this difference. > (in the email at the start of the thread: "(Note that this is > entirely not about state that the NTLP uses internally, e.g. > to route messages correctly.)") > > so, my question is about the assertion: > "One can use the NTLP state management procedure to maintain > the NSLP reservation) states" > > (can one really? is it a good idea? is it more than an > implementation issue?) > > especially, if it is more than an implementation issue, > ***what is the actual impact on the protocol?*** (in broad > terms, or giving an example) > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 31 March 2003 16:04 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Hi Robert > > > > The NTLP states are in my opinion different than the > > NSLP states. > > The NTLP states are more associated with forwarding behavior and > > the NSLP application states are reservation states. > > One can use the NTLP state management procedure to maintain the > > NSLP (reservation) states, but this cannot be done the other > > way around! > > This is for example valid when not all NSIS nodes support > > NSLP functionality > > (but they support NTLP functionality). > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: maandag 31 maart 2003 16:42 > > To: Georgios Karagiannis (ELN); nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > georgios, > > > > two questions: > > *) regardless of whether the general idea of soft stateness > > is good and how well it works in RSVP, why support it > > explicitly in the NTLP - why isn't this a signalling > > application issue? if something is needed in the NTLP, why > > isn't it an implementation issue? > > *) assuming the answer is still 'it is meaningfully part of > > the NTLP', what kind of detectable impact on the actual > > protocol would you expect it to have? > > > > what i'm trying to make progress from is the generalised view > > 'let's put soft state in the NTLP' and turn that into a > > concrete statement whose impact on the framework can be > > evaluated. at the moment, it seems to be a matter of opinion > > whether the question has no meaning or very deep meaning (at > > least to me). > > > > robert h. > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 31 March 2003 14:49 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] state management question > > > > > > > > > Hi all > > > > > > Since the RSVPv1 (RFC2205) refresh procedure and the > > > management of refresh > > > timers work quite well I think that it should be reasonable > > > to try and > > > reuse them in NTLP. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > Sent: donderdag 27 maart 2003 9:51 > > > To: robert.hancock@roke.co.uk > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] state management question > > > > > > > > > Robert, > > > > > > my answers on your final questions in line. I've > > > added some text on the message sequence number > > > mechanism, which I think is another issue > > > raising concerns. > > > > > > Regards, Rüdiger > > > > > > > > > | To make it concrete in this case: > > > | - should the NTLP contain fields which are refresh times? > > > | always? sometimes? > > > > > > Don't think so. Local time information should be used to > > > maintain state only. Also a refresh reduction mechanism > > > shouldn't require timestamps to be transmitted. If possible. > > > > > > | - should the NTLP have a bit in its header which > > > | distinguishes between state refreshing and other messages? > > > > > > As the refresh message initiates completely new state in the > > > case of a route change in new routers, the refreshes > > > shouldn't be "marked". Your idea is to distinguish between a > > > refresh of state and a modification of this state? > > > Valid Point. It may be more useful to have > > > "state set up & modification" messages instead of > > > "state set up & refresh" messages. The NLTP > > > receiving a "state set up" with an already existing session > > > ID knows that this is a refresh and acts accordingly. > > > > > > | - should the NTLP make up its own mind whether to acknowledge > > > | state creation or deletion messages? > > > > > > The fast answer is: no, that's an issue of NSLP. It gets > > > tricky should NTLP maintain state also for services without > > > local NSLP support (the NTLP relay case). I think we should > > > clarify what these NTLP relay nodes are supposed to do with > > > messages they have no NSLP support for. Or whether we > > > allow such a NTLP relay function at all. My personal > > > feeling is: > > > - NTLP relay may be useful. > > > - NTLP service state maintenance only if NSLP is present. > > > In this case, each NTLP node must interpret the NSLP field > > > of a "state set up" message first and then check the > > > session ID. > > > > > > A concern I have is whether to maintain sequence numbers in > > > NTLP or NSLP only or whether to maintain them on both > > > layers. If refreshes are handled by NTLP only, NTLP must > > > be aware of the sequence numbers. It must maintain the > > > service specific sequence numbering mechanism too. In the > > > case of an NTLP relay, there's no service specific state, > > > hence there's no sequence number maintenance (for relayed > > > messages). It might be advantageous to let the sequence > > > number mechanism count messages between adjacent NTLP > > > peers only. > > > > > > _______________________________________________ > > > 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 Tue Apr 1 13:42:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07537 for ; Tue, 1 Apr 2003 13:42:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31J6Qm08523 for nsis-archive@odin.ietf.org; Tue, 1 Apr 2003 14:06:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31J6JK08489; Tue, 1 Apr 2003 14:06:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31J3AK08254 for ; Tue, 1 Apr 2003 14:03:10 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07286 for ; Tue, 1 Apr 2003 13:38:47 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31IfB4c008924; Tue, 1 Apr 2003 10:41:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACU94659; Tue, 1 Apr 2003 10:41:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA16362; Tue, 1 Apr 2003 10:41:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16009.56643.360624.481373@thomasm-u1.cisco.com> Date: Tue, 1 Apr 2003 10:41:07 -0800 (PST) To: "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] state management question In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA8F6@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA8F6@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 Hancock, Robert writes: > i support this consensus view. > > i.e. some functionality like that of 2961 should be part of our overall solution, and some parts of 2961 should be replicated in the NTLP. (whether they should be mandatory/optional to implement/use is a question we'll get on to.) > > my reading of 2961 is that it doesn't change the underlying concepts of soft state maintenance *within* nodes, but it provides some 'lower layer' functions which make it possible to issue refreshes more efficiently. (i believe a mandatory NACK and optional ACK; in general I think you need one and then the other is an optimisation.) > > one facet of the question before us is therefore: should the NTLP do the equivalent of decision making between summary and full refreshes (knowing when each is appropriate and sending the appropriate messages to make it happen); or, should it just provide transport-like functions (ACK and/or NACK) to enable a soft-state-based signalling application to reduce the refresh load it generates; or, should it do neither. Ok I'm probably clueless here, but isn't that a function of application layer logic? That is, the really interesting state installed for which might want to make that kind of decision is (almost?) always at the application layer? Is there any kind of transport state which would benefit which is *divorced* from the need to reinstall the application layer state too? Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Apr 2 03:19:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00423 for ; Wed, 2 Apr 2003 03:19:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h328hfx15694 for nsis-archive@odin.ietf.org; Wed, 2 Apr 2003 03:43:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328hZK15683; Wed, 2 Apr 2003 03:43:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328epK15542 for ; Wed, 2 Apr 2003 03:40:51 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00361 for ; Wed, 2 Apr 2003 03:16:10 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 09:18:38 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA90E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Tom Taylor'" Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Wed, 2 Apr 2003 09:18:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi tom, > One question is whether the same NTLP path will serve more > than one NSLP > application (e.g. resource reservation, firewall control) at once. Topologically, it seems certain that this situation will arise (see also framework section 3.2.1). For example, you could have a flow between two widely separated networks, with signalling between the firewalls for those networks; you could have resource reservation signalling (for the same flow) aimed at the network between those firewalls. So, there will be NSIS-aware nodes which see the signalling for more than one NSLP at the same time. And the firewall nodes might process both applications. How much the different NSLPs interact with each other is another question - there are several options. One case would be for any two NSLP peers to communicate directly over a dedicated NTLP 'thing' (this would imply some sort of explicit discovery); another would be that messages from all NSLPs are bundled together in a single NTLP 'thing' and processed by every NSIS-aware node at least to some extent (practically unavoidable if you use PATH-like addressing). There are exceptionally strong views on each side. My preference would be that the NTLP should not in any case be aware of interdependencies between signalling applications. This becomes easier to ensure, the thinner the NTLP becomes, and gives the NTLP more freedom to do clever transport-related things without suffering from the law of unintended consequences. cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Apr 2 03:40: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 DAA00770 for ; Wed, 2 Apr 2003 03:40:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3294Jh17031 for nsis-archive@odin.ietf.org; Wed, 2 Apr 2003 04:04:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3293RK16970; Wed, 2 Apr 2003 04:03:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3290lK16544 for ; Wed, 2 Apr 2003 04:00:47 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00711 for ; Wed, 2 Apr 2003 03:36:05 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 09:38:33 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA90F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Michael Thomas'" Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Wed, 2 Apr 2003 09:38: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: , mike, > > one facet of the question before us is therefore: should > the NTLP do the equivalent of decision making between summary > and full refreshes (knowing when each is appropriate and > sending the appropriate messages to make it happen); or, > should it just provide transport-like functions (ACK and/or > NACK) to enable a soft-state-based signalling application to > reduce the refresh load it generates; or, should it do neither. > > Ok I'm probably clueless here, but isn't that a function > of application layer logic? That is, the really interesting > state installed for which might want to make that kind of decision > is (almost?) always at the application layer? Is there any > kind of transport state which would benefit which is *divorced* > from the need to reinstall the application layer state too? > > Mike > I'd be honoured to be clueless along with you, but I can't quite parse your sentences. a) If you are saying 'only the application can decide how interesting its state is' I agree. What I'm trying to determine is if there is any actual real meaningful non-trivial content in the various comments to the effect that "the NTLP should do something about signalling application state management", like provide different classes of something which the application could choose between, or whether the NTLP should just move bits (my increasing preference). b) If you are saying that there is no NTLP state which needs to be managed anything other than softly (and hence that there is no need for ACK/NACK functions at the NTLP layer), I would say that depends on some details of required NTLP functionality, in particular what events it needs to signal up to applications. For example, we are currently assuming that the NTLP handles route change detection and mobility events; you might not want to rely only on soft-state refreshing to ensure you didn't miss these. This is an NTLP design question (but largely independent of what the supported signalling applications are). c) If you are saying that if there is a need for ACK/NACK functions to support signalling applications then they might as well be in the signalling application, I think I probably disagree. Retransmission is actually a very hard problem with subtle interactions with congestion control, round trip timing, it's hard to do well on individual low rate message flows, and so on. If it's needed at all I'd rather see it done properly, once and for all, in the NTLP. (The discussion of whether it is needed is still to come, of course. I'd rather bottom out the state management stuff first.) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Apr 2 04:08:10 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 EAA01267 for ; Wed, 2 Apr 2003 04:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h329WKb19181 for nsis-archive@odin.ietf.org; Wed, 2 Apr 2003 04:32:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329WFK19120; Wed, 2 Apr 2003 04:32:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329RFK18822 for ; Wed, 2 Apr 2003 04:27:15 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01118 for ; Wed, 2 Apr 2003 04:02:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h3298w503582 for ; Wed, 2 Apr 2003 12:08:58 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Apr 2003 12:04:58 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Apr 2003 12:04:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Apr 2003 12:04:56 +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 question Date: Wed, 2 Apr 2003 12:04:56 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL48OUT0fR52nFbTXi/GnEDd2TIfQAAR0Nw To: , Cc: X-OriginalArrivalTime: 02 Apr 2003 09:04:56.0958 (UTC) FILETIME=[EEAA59E0:01C2F8F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h329RFK18823 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 Tom & Robert, > > One question is whether the same NTLP path will serve more > > than one NSLP application (e.g. resource reservation, firewall control) > > at once. > > Topologically, it seems certain that this situation will > arise (see also framework section 3.2.1). Agreed. [text clipped] > My preference would be that the NTLP should not in any case > be aware of interdependencies between signalling > applications. This becomes easier to ensure, the thinner the > NTLP becomes, and gives the NTLP more freedom to do clever > transport-related things without suffering from the law of > unintended consequences. I agree with Robert. We discussed this at the interim meeting, and (I think) decided was a can of worms that we did not want to open (yet). John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Apr 7 07:15:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15330 for ; Mon, 7 Apr 2003 07:15:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37BJGW01448 for nsis-archive@odin.ietf.org; Mon, 7 Apr 2003 07:19: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 h37BJ8801438; Mon, 7 Apr 2003 07:19: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 h37BEu801248 for ; Mon, 7 Apr 2003 07:14:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15022; Mon, 7 Apr 2003 07:10:15 -0400 (EDT) Message-Id: <200304071110.HAA15022@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 07 Apr 2003 07:10:15 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-requirements-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Requirements of a QoS Solution for Mobile IP Author(s) : H. Chaskar Filename : draft-ietf-nsis-qos-requirements-00.txt Pages : 7 Date : 2003-4-4 Mobile IP ensures correct routing of packets to mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qos-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qos-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-4160426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4160426.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Apr 14 03:21: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 DAA26590 for ; Mon, 14 Apr 2003 03:21:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E7SiM29088 for nsis-archive@odin.ietf.org; Mon, 14 Apr 2003 03:28:44 -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 h3E7Qh829032; Mon, 14 Apr 2003 03:26:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7Pk828975 for ; Mon, 14 Apr 2003 03:25:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26400 for ; Mon, 14 Apr 2003 03:17:45 -0400 (EDT) From: john.loughney@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194yGH-0000Kb-00 for nsis@ietf.org; Mon, 14 Apr 2003 03:20:17 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 194yGG-0000KY-00 for nsis@ietf.org; Mon, 14 Apr 2003 03:20:16 -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 h3E7KKQ17064 for ; Mon, 14 Apr 2003 10:20:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 14 Apr 2003 10:20:19 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Apr 2003 10:20:19 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Apr 2003 10:20:19 +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: Mon, 14 Apr 2003 10:20:18 +0300 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcL48OUT0fR52nFbTXi/GnEDd2TIfQAAR0NwAlkNe+A= To: X-OriginalArrivalTime: 14 Apr 2003 07:20:19.0054 (UTC) FILETIME=[4DB338E0:01C30256] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3E7Pk828976 Subject: [NSIS] Meeting Minutes 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, Here are the meeting minutes. Thankes to Hannes & Sven for taking minutes. John NSIS Meeting (Day 1) ++++++++++++++++ Minute Taker: Hannes Tschofenig Agenda Bashing ----------------------- Done by John. Interim Meeting Review --------------------------------- John gave the summary of the interim meeting with a list of consensus and problematic issues. His presentation can be found at: http://www-nrc.nokia.com/sua/nsis/ietf56/nsis-agenda.ppt John will send these issues to the NSIS mailing list. NSIS members might want to comment them. RSVP Discussion (Melinda) ---------------------------------------- Melinda went through her presentation. Q: Is fragmentation not done in a hop-by-hop fashion? A: End-to-end addressing prevents this. Problems to solve (Henning) ----------------------------------------- Henning went through his presentation. Conclusion: - Don't create a custom transport protocol with the ntlp/nslp work - Allow raw ip + other transport protocol - Allow separation between discovery and signaling message delivery MT: The problems of raw transport are not as difficult. We should keep the ability of support for unreliable transport. Henning: This is what I said. We should not exclude some transport protocol. Both agree that different transport protocols should be supported. Melinda: We should not discuss the security issues. We want to modify RSVP as the charter says it. What do we really need to do? Henning: What does it mean to modify RSVP? Modified protocol X can mean a) Keep the protocol backwards capability b) No backwards capability. You have a different protocol then. Does not preclude you from taking design features of the original protocol. John: Initially we wanted to separate different services Should we separate discovery from message delivery? Henning: I assume RFC 2961 when we talk about RSVP. Melinda: The end-to-end behavior is important. Routing is the important issue. Lixia: Could you summarize your talk? Henning: A flexible NSIS protocol is required. Lixia: Have you identified the negative sides? Henning: If a reliable transport is needed then there might be additional delay for setup a TCP connection (only once if it is reused by multiple NSLP sessions). Bob: Melinda mentioned the problem of signaling cases which are so trivial that you cannot amortize. What would you suggest for DNS? Henning: Most of the time signaling fits fine into the architecture. However, you might want to provide a fall-back mechanism. I am not trying to motivate NSIS with a DNS example. If you don't need it then you don't need to use it. Bob: If we don't want to support transport protocol (a), (b) or (c). You don't need to decide. The same is true for discovery. Can this group design a protocol with such a flexibility? Lixia: Look at the most important protocols. They are successful because they are simple. Henning: Separation makes protocols even simpler. Q: What are the assumptions? Henning: - Signaling traffic should be protected - It is unwise to assume that intra-domain signaling messages are protected. We cannot assume any characteristics of the network since we additionally cover other signaling application cases. Melinda: You cannot assume that there are always NSIS capable routers along the path. Henning: This is another motivation for discovery. Q: Provisioning of flows can be done to avoid all the transport layer discussions. DiffServ marking for signaling traffic can be done. Henning: You cannot make this assumption. MT: You get a lot of problems if you support more than one transport protocol. Henning: My motivation is more to prevent people from creating their own transport layer functionality at the NSLP. MT: Allowing fragmentation support (with the ability to switch) sounds ok to me. John: Summary: - Agreement that we want to separate the service part. - We want to modify RSVP. - Off-line discussion with Melinda, Henning and ADs about further procedure. RSVP Analysis (Jukka) ----------------------------------- Idea: Capture knowledge about RSVP. Remove ITSUMO (more architecture work). Revised sections Proposal to move forward: - Add Michael Thomas draft - Add Ping Pan text John: - We have to work on issues where RSVP cannot be used/modified for our purpose. - This work is needed to explain which changes are required. - Avoid stories about RSVP which are not justified (e.g. "RSVP does not scale" ) . - More reasonable to combine documents than to have many separate RFCs. - Jukka should talk to Michael about co-operation. RSVP Transport Issues (Ping) -------------------------------------------- Ping went through his presentation. Ping: This is not RSVP-bashing. It is about observation. Summary: - Timer handling is complex (a single TCP connection between two routers would be a lot easier) - Large number of messages is a problem (message packing). Causes MTU issues. - Nothing should affect RSVP-TE but RSVP-TE is not in scope of NSIS work anyway. Proposed Changes: - No need for IP Router Alert Option for PATH - Flexible message transport Lixia: Timer handling might be similar to TCP. RSVP and TCP data delivery are different. Harmful: Heavy load BGP traffic (later message overwrites previous one) Ping: This is a problem for the NSLP not for the NTLP. RSVP maintains timers for individual sessions. Lixia: The solution to the problem is different. MT: Security objects are not a problem for MTU. Hannes: Proposals available today already cause problems (e.g. Identity Representation objects). NSIS Meeting (Day 2) ++++++++++++++++ Agenda Bashing (John) ------------------------------- Meeting in the morning and discussion with area directors. The conclusion of this discussion can be obtained from: http://www-nrc.nokia.com/sua/nsis/ietf56/nsis-agenda.ppt Summary: The proposal is that Henning and Melinda would start NTLP work. Bob and Michael will act as expert reviewers. Marcus: Some other authors should participate. John: Bring it to the mailing list. Q: Flow Id is used by some other WGs. John: We will make sure to refer to it as the to Flow Spec. Q: Flow Label draft needs to be revised. Please comment on it to the IPv6 mailing list. John: Review the draft and raise your concerns with the requirements document. NSIS Requirements (Marcus) --------------------------------------- Most of the issues have been discussed at the interim meeting. Remove QoS-specific issues Terminology alignment with framework Framework Presentation (Robert) ------------------------------------------------ Robert goes through his presentation. Robert: Some issues need to be discussed case-by-case. Favorite example is bundling (reliability is more complex) which is a local issue only. Melinda: What are local issues? Robert: Message Bundling effects only two peers. Issue 3: Mobility Mobility handling has not yet been captured yet. Impacts what type of optimizations can be achieved. More discussions are needed. Issue 4: One or many hops Refers to whether NTLPs are always co-located with NSLPs. Issue 5: State management Mike: Why is it not an implementation issues? Robert: Example is cost: accumulation of cost. Requirements may be different for different NSLPs. Impact may be: distinguish between refresh and non-refresh at NTLP Next Steps (John) Come to agreement on issues. Next version available in May Charter says submission to IESG in July Schedule NTLP first version before next IETF RSVP security properties (Hannes) ------------------------ Added sections to cover: first hop, last hop. Removed section about AAA - covered in separate document. Next hop: editorial clean up and shortening, add references, comments welcomed [JL] The working group should read the document and make comments. NSIS threats (Hannes) ------------ Introduction rewritten * relationship to other security issues * more detailed threat description * new threats * deployment issues (missing authorization, cost control) [JL] The WG will do thorough read and maybe go the WG last call soon. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Apr 16 14:52: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 OAA11762 for ; Wed, 16 Apr 2003 14:52:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GJ0wm13593 for nsis-archive@odin.ietf.org; Wed, 16 Apr 2003 15:00:58 -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 h3GIvc813338; Wed, 16 Apr 2003 14:57:38 -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 h3GIsP813197 for ; Wed, 16 Apr 2003 14:54:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11520 for ; Wed, 16 Apr 2003 14:45:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195rwa-00037I-00 for nsis@ietf.org; Wed, 16 Apr 2003 14:47:40 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 195rwZ-00037E-00 for nsis@ietf.org; Wed, 16 Apr 2003 14:47:39 -0400 From: "Xiaoning He" To: Date: Wed, 16 Apr 2003 11:46:40 -0700 Message-ID: <002001c30448$865e9dd0$696015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GIsP813198 Subject: [NSIS] RSVP Question 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 I have a simple question regard RSVP. Could anyone give me some information about this? How many RSVP flows a state-of-art router can handle per second currently? Thank you very much, Xiaoning -----------------------------   Xiaoning He, Ph.D Research Engineer   NTT-DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110   Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax:   +1 (408) 573-1090 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Apr 17 06:02: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 GAA14135 for ; Thu, 17 Apr 2003 06:02:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HABv521541 for nsis-archive@odin.ietf.org; Thu, 17 Apr 2003 06:11: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 h3HA8g821384; Thu, 17 Apr 2003 06:08:42 -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 h3HA7o821357 for ; Thu, 17 Apr 2003 06:07: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 FAA14015 for ; Thu, 17 Apr 2003 05:58:15 -0400 (EDT) From: john.loughney@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1966CE-0006OU-00 for nsis@ietf.org; Thu, 17 Apr 2003 06:00:46 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1966CD-0006OR-00 for nsis@ietf.org; Thu, 17 Apr 2003 06:00:45 -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 h3HA0tD12485 for ; Thu, 17 Apr 2003 13:00:55 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Apr 2003 13:00:55 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Apr 2003 13:00:54 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Apr 2003 13:00:54 +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] RSVP Question Date: Thu, 17 Apr 2003 13:00:50 +0300 Message-ID: Thread-Topic: [NSIS] RSVP Question Thread-Index: AcMESSuTtOnKlChCR0m4iq/sQpEHFQAfuOFw To: , X-OriginalArrivalTime: 17 Apr 2003 10:00:54.0018 (UTC) FILETIME=[3BD34E20:01C304C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HA7o821358 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 Xiaoning, > I have a simple question regard RSVP. Could anyone give me some > information about this? > > How many RSVP flows a state-of-art router can handle per second > currently? Currently, RSVP is being handled by the Transport Area WG - though maybe someone on this mailing list has an answer for you. Also, I am not sure if it is active, but there is the RSVP-TEST mailing list, that may have people who can give you pointers. Information on that mailing list is: rsvp-test@isi.edu This is for discussion of RSVP implementation issues, reporting of bugs in implementations, and coordination of interoperability testing. Individual vendors may choose to use (or continue to use) their own lists, but I think there would be a lot of benefit in using a common list for implementation and interoperation discussions. In particular, please direct (or at least CC:) all messages about the ISI implementation to rsvp-test@isi.edu, not to the main rsvp mailing list. This new list is currenly unpopulated. If you are interested in RSVP implementation issues and want to join this list, send a message to majordomo@isi.edu with: subscribe rsvp-test br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Apr 17 13:30:29 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 NAA29516 for ; Thu, 17 Apr 2003 13:30:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HHdfj25208 for nsis-archive@odin.ietf.org; Thu, 17 Apr 2003 13:39:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HHdV825187; Thu, 17 Apr 2003 13:39:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HHcb825147 for ; Thu, 17 Apr 2003 13:38: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 NAA29458 for ; Thu, 17 Apr 2003 13:28:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196DEI-0001Wi-00 for nsis@ietf.org; Thu, 17 Apr 2003 13:31:22 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 196DEH-0001Wf-00 for nsis@ietf.org; Thu, 17 Apr 2003 13:31:21 -0400 From: "Xiaoning He" To: , Subject: RE: [NSIS] RSVP Question Date: Thu, 17 Apr 2003 10:30:27 -0700 Message-ID: <001a01c30507$0ac61710$696015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: 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 John and all Thank you for the information. I just somehow had an impression that from SF IETF, in the nsis meeting, someone mentioned that the current router can easily support thousands of RSVP flows now so that the scalability issue is no longer a real concern to RSVP. Just want to confirm that. Thanks, Xiaoning ----------------------------- Xiaoning He, Ph.D Research Engineer NTT-DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax: +1 (408) 573-1090 -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Thursday, April 17, 2003 3:01 AM To: xiaoning@docomolabs-usa.com; nsis@ietf.org Subject: RE: [NSIS] RSVP Question Hi Xiaoning, > I have a simple question regard RSVP. Could anyone give me some > information about this? > > How many RSVP flows a state-of-art router can handle per second > currently? Currently, RSVP is being handled by the Transport Area WG - though maybe someone on this mailing list has an answer for you. Also, I am not sure if it is active, but there is the RSVP-TEST mailing list, that may have people who can give you pointers. Information on that mailing list is: rsvp-test@isi.edu This is for discussion of RSVP implementation issues, reporting of bugs in implementations, and coordination of interoperability testing. Individual vendors may choose to use (or continue to use) their own lists, but I think there would be a lot of benefit in using a common list for implementation and interoperation discussions. In particular, please direct (or at least CC:) all messages about the ISI implementation to rsvp-test@isi.edu, not to the main rsvp mailing list. This new list is currenly unpopulated. If you are interested in RSVP implementation issues and want to join this list, send a message to majordomo@isi.edu with: subscribe rsvp-test br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Apr 17 19:05: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 TAA13596 for ; Thu, 17 Apr 2003 19:05:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HNEYn18314 for nsis-archive@odin.ietf.org; Thu, 17 Apr 2003 19: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 h3HN9Q818176; Thu, 17 Apr 2003 19:09:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HN8t818147 for ; Thu, 17 Apr 2003 19:08:55 -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 SAA13462 for ; Thu, 17 Apr 2003 18:59:06 -0400 (EDT) From: Axel.Kuttner@alcatel.de Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196INo-0003Uz-00 for nsis@ietf.org; Thu, 17 Apr 2003 19:01:32 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 196INo-0003Uv-00 for nsis@ietf.org; Thu, 17 Apr 2003 19:01:32 -0400 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA24800 for ; Fri, 18 Apr 2003 01:00:27 +0200 (MET DST) To: nsis@ietf.org Message-ID: Date: Fri, 18 Apr 2003 01:01:03 +0200 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/18/2003 01:01:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. 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: , I will be out of the office starting 16.04.2003 and will not return until 22.04.2003. Thank you for keeping me informed. I will respond to your message when I return. In urgent cases please contact Guenther Arheit. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Apr 18 07:20: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 HAA08708 for ; Fri, 18 Apr 2003 07:20:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IBUHu07690 for nsis-archive@odin.ietf.org; Fri, 18 Apr 2003 07:30:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBUB807661; Fri, 18 Apr 2003 07:30:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBPS807498 for ; Fri, 18 Apr 2003 07:25:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08365; Fri, 18 Apr 2003 07:15:24 -0400 (EDT) Message-Id: <200304181115.HAA08365@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Apr 2003 07:15:24 -0400 Subject: [NSIS] I-D ACTION:draft-westberg-proposal-for-rsvpv2-nslp-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Proposal for RSVPv2-NSLP Author(s) : L. Westberg et al. Filename : draft-westberg-proposal-for-rsvpv2-nslp-00.txt Pages : 101 Date : 2003-4-17 The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the demand for technologies offering services with different levels of quality of service to their customers. This memo seeks to initiate a dialog about the design of a new version of RSVPv1, called RSVPv2, that meet the requirements formulated by IETF NSIS working group. It also outlines the motivation for using RSVP2 as 'next step in signaling'. The RSVPv2 framework uses the layer-split architecture separating signaling application and transport functions. This concept was adopted by NSIS WG and the two layers are called NSLP NSIS Signaling Layer Protocol (NSLP) and NSIS Transport Layer Protocol (NTLP). This draft provides design guidelines and specifications for the development of the RSVPv2 NSLP part. RSVP2-NSLP offers increased modularity and contains less mandatory objects compared to RSVPv1, which allow lightweight implementation and flexible application. The new protocol is extended with PHR and PDR objects that makes it possible to use the protocol in different part of multi-domain networks and use the protocol in DiffServ environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-westberg-proposal-for-rsvpv2-nslp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-17132113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-westberg-proposal-for-rsvpv2-nslp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-17132113.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Apr 19 03:22:21 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 DAA19903 for ; Sat, 19 Apr 2003 03:22:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3J7WIV25334 for nsis-archive@odin.ietf.org; Sat, 19 Apr 2003 03:32: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 h3J7Vm825321; Sat, 19 Apr 2003 03:31:48 -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 h3J7Sj825243 for ; Sat, 19 Apr 2003 03:28:45 -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 DAA19846 for ; Sat, 19 Apr 2003 03:18:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196meQ-0003aS-00 for nsis@ietf.org; Sat, 19 Apr 2003 03:20:42 -0400 Received: from smtp809.mail.sc5.yahoo.com ([66.163.168.188]) by ietf-mx with smtp (Exim 4.12) id 196meP-0003aP-00 for nsis@ietf.org; Sat, 19 Apr 2003 03:20:41 -0400 Received: from adsl-64-175-245-21.dsl.sntc01.pacbell.net (HELO cs.columbia.edu) (pingpan999@64.175.245.21 with plain) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 19 Apr 2003 07:20:57 -0000 Message-ID: <3EA0F8DC.9020006@cs.columbia.edu> Date: Sat, 19 Apr 2003 00:21:00 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiaoning He CC: nsis@ietf.org Subject: Re: [NSIS] RSVP Question References: <001a01c30507$0ac61710$696015ac@VAIO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I said that in SF. :-) MPLS routers today can support thousands of LSP's (RSVP sessions) so long as those LSP's don't change too often. The reason for this is mainly due to the fact that the LSP's are pretty static by design. But as soon as you start to consider of using RSVP to manage short-duration sessions (like telephone calls), router performance is likely to dip. Here is some ancient work I had done: http://www1.cs.columbia.edu/~pingpan/projects/yessir.html You may find some measurement numbers on an ancient IBM router... (actually the modern router's CPU is not that much better than I had played with in IBM. :-() Hope this will help. - Ping P.S.: Scalability is a term that has been used in vain by many. So let's be careful with the definition of scalability. :-) Xiaoning He wrote: > Hi John and all > > Thank you for the information. > > I just somehow had an impression that from SF IETF, in the nsis meeting, > someone mentioned that the current router can easily support thousands > of RSVP flows now so that the scalability issue is no longer a real > concern to RSVP. Just want to confirm that. > > Thanks, > > Xiaoning > > ----------------------------- > > Xiaoning He, Ph.D > Research Engineer > > NTT-DoCoMo USA Labs > 181 Metro Drive, Suite 300 > San Jose, CA 95110 > > Email: xiaoning@docomolabs-usa.com > Phone: +1 (408) 451-4737 > Fax: +1 (408) 573-1090 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis