From exim@www1.ietf.org Mon Feb 2 00:21:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05718 for ; Mon, 2 Feb 2004 00:21:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWWC-0004Md-LZ for nsis-archive@odin.ietf.org; Mon, 02 Feb 2004 00:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i125L8JY016759 for nsis-archive@odin.ietf.org; Mon, 2 Feb 2004 00:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWW6-0004LT-AO; Mon, 02 Feb 2004 00:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWVL-0004Hz-87 for nsis@optimus.ietf.org; Mon, 02 Feb 2004 00:20:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05696 for ; Mon, 2 Feb 2004 00:20:12 -0500 (EST) From: luu@infres.enst.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnWVI-0001o4-00 for nsis@ietf.org; Mon, 02 Feb 2004 00:20:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnWUL-0001jv-00 for nsis@ietf.org; Mon, 02 Feb 2004 00:19:13 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnWTe-0001gB-00 for nsis@ietf.org; Mon, 02 Feb 2004 00:18:30 -0500 Received: from infres2.enst.fr (infres2.enst.fr [137.194.192.3]) by infres.enst.fr (Postfix) with ESMTP id D10141BCC; Mon, 2 Feb 2004 06:18:26 +0100 (MET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with SMTP id i125IQl01700; Mon, 2 Feb 2004 06:18:26 +0100 (MET) Received: from localhost ([203.210.199.5]) (proxying for 192.168.105.124) (SquirrelMail authenticated user luu) by www.infres.enst.fr with HTTP; Mon, 2 Feb 2004 06:18:26 +0100 (MET) Message-ID: <44003.203.210.199.5.1075699106.squirrel@www.infres.enst.fr> Date: Mon, 2 Feb 2004 06:18:26 +0100 (MET) To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [NSIS] RE: rsvp doi draft 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 hannes, i see two approaches: -you define a new doi (as in your draft) -you only define a new protocol-id in the ipsec doi in the second one, it will be easier if you want to change from one security protocol (prococol-id) to the others, and it reduces the database for two doi (in the second approach). i've discussed with ibrahim the tls/ssl, it seems that he follows the second. however, for the other reasons, i agree the first is more reasonable. in the msec wg, i see the value doi=2 is used for group multicase doi. i'm interested in this approach and i think you might like it. cheers, Nary Tra ENST,Paris thanks for making me aware of these documents. i have asked the authors to send me a copy and they did it. i have read these two document to address your question. you asked whether it would be possible to register a new doi value only (without anything else) - if i remember it correctly. after reading the paper i must conclude that the approach for writing a doi seems to be reasonable. the authors of the above-mentioned papers also follow the same approach as we did it. their intention is, however, different. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 2 12:50:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25949 for ; Mon, 2 Feb 2004 12:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCz-0004lv-Dt for nsis-archive@odin.ietf.org; Mon, 02 Feb 2004 12:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Ho5kp018320 for nsis-archive@odin.ietf.org; Mon, 2 Feb 2004 12:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCz-0004lO-0Z; Mon, 02 Feb 2004 12:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCA-0004ao-2t for nsis@optimus.ietf.org; Mon, 02 Feb 2004 12:49:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25616 for ; Mon, 2 Feb 2004 12:49:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniC8-0007LK-00 for nsis@ietf.org; Mon, 02 Feb 2004 12:49:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani81-0006Ka-00 for nsis@ietf.org; Mon, 02 Feb 2004 12:44:59 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1Ani1g-0004i6-00 for nsis@ietf.org; Mon, 02 Feb 2004 12:38:24 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: LOGIN fu) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 02 Feb 2004 18:38:23 +0100 Message-ID: <401E8B18.6090409@cs.uni-goettingen.de> Date: Mon, 02 Feb 2004 18:38:32 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: Re: [NSIS] GIMPS connection mode and intermediaries References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, Hancock, Robert wrote: >> ... >>>this is not my assumption. in a sane world >>>*) a GIMPS unaware NAT should not change the flow ID at all, >>>since it is just payload data. >>>[i am aware of NATs which look for things like IP addresses >>>in arbitrary payloads and attempt to rewrite them; I regard >>>being broken by such a NAT as a feature, not a bug ;-).] >>>but then the next GIMPS peer should detect the presence of >>>the NAT (see above) and then try to work out what to do about >>>it (as discussed a bit in Cedric's document). >>> >> >>yes. Does GIMPS keep the previous nodes IP address in its payload? > > > that's not currently defined, but there would not be a problem > to do so e.g. in D mode. (it's not there currently because the > need only seems to arise in this NSIS-unaware NAT traversal case > which we have not really gone into yet). NAT traversal can need this. Furthermore, even in traditional IntServ, it may still require readjust of your reservations in the former hops for a d-mode message passed. This was not a problem for RSVP which is receiver-initiated and the receive knows exactly how much the path can accommodate, but is for source-initiated signaling with GIMPS. Either we rely on another time of e2e d-message refresh (where an e2e or error response is needed to trigger) *soon* after the first attempt, or still maintain PHOP also in GIMPS d-mode. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 2 13:36:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25948 for ; Mon, 2 Feb 2004 12:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCy-0004lM-Vg for nsis-archive@odin.ietf.org; Mon, 02 Feb 2004 12:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Ho42l018291 for nsis-archive@odin.ietf.org; Mon, 2 Feb 2004 12:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCy-0004kt-Fz; Mon, 02 Feb 2004 12:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniC9-0004an-Mt for nsis@optimus.ietf.org; Mon, 02 Feb 2004 12:49:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25611 for ; Mon, 2 Feb 2004 12:49:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniC7-0007LE-00 for nsis@ietf.org; Mon, 02 Feb 2004 12:49:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani7x-0006JN-00 for nsis@ietf.org; Mon, 02 Feb 2004 12:44:57 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1Ani1X-0004i6-00 for nsis@ietf.org; Mon, 02 Feb 2004 12:38:15 -0500 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: LOGIN fu) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 02 Feb 2004 18:38:12 +0100 Message-ID: <401E8B0D.1090204@cs.uni-goettingen.de> Date: Mon, 02 Feb 2004 18:38:21 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: Re: [NSIS] GIMPS connection mode and network re-routing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, Do we have a measurement about the possibility of a route change due to node failure during a session? Unless it is mobility-related route change (very likely more frequent), in either mode (c- or d-), an e2e refresh at NTLP level (which carefully chooses a refresh timer) in general should be ok. If the router which can detect a route change is able to support NTLP, we can certainly reuse RSVP local repair mechanism, as additional enhancement. Xiaoming Hancock, Robert wrote: > hi marcus, > > >>>Therefore, we would propose to get rid of 5.3.4, leaving us with >>>simple D mode and raw C mode. The consequence would be a final >>>acceptance within the group that the lack of automatic route change >>>detection in C mode is something we can all live with. >>> >> >>I have no problem to get rid of this as long as the >>specification defines how route changes are handled. >> >>Marcus >> > > > there are two parts to 'handled': > 1. detected > 2. repaired (in general, "reacted to") > > and (1) can be subdivided into > 1a. detected as possibly having occurred > 1b. confirmed (and the new route discovered) > > my view (but i am thinking aloud here) is that > 1a - GIMPS will describe one method for this (periodic re-issue > of D-mode query/response exchanges); might include protocol > elements which assist other mechanisms (e.g. TTL measurements); > but certainly won't be comprehensive. there is important > stuff to be done here (cf. zappala's routing interface for > RSVP) but not as part of the basic GIMPS spec. > > 1b - GIMPS defines this already (it's the D mode > discover/query), or at least we know it has to. > > 2 - the main point is that GIMPS doesn't carry out > the repair operation itself, it notifies NSLPs that they > may need to do it. so, the main issue from a protocol > perspective is: where (at which node) to deliver the > notification. there are some subtleties here (sections > 6.1.2 and 6.1.3 of the GIMPS draft) which some comments > on would be nice. > > r. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 3 05:42:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01457 for ; Tue, 3 Feb 2004 05:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Any0H-0005N4-Fr for nsis-archive@odin.ietf.org; Tue, 03 Feb 2004 05:42:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Ag1Y9020633 for nsis-archive@odin.ietf.org; Tue, 3 Feb 2004 05:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Any0G-0005Mc-BK; Tue, 03 Feb 2004 05:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anxzb-0005Kx-DL for nsis@optimus.ietf.org; Tue, 03 Feb 2004 05:41:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01361 for ; Tue, 3 Feb 2004 05:41:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnxzX-0005N4-00 for nsis@ietf.org; Tue, 03 Feb 2004 05:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnxyZ-0005EL-00 for nsis@ietf.org; Tue, 03 Feb 2004 05:40:16 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1Anxxa-0004yT-00 for nsis@ietf.org; Tue, 03 Feb 2004 05:39:15 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 10:38:38 -0000 Message-ID: From: "Hancock, Robert" To: "'Xiaoming Fu'" Cc: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Tue, 3 Feb 2004 10:38:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 xiaoming, the [original] question about peer addresses is totally independent of the question about nhop/phop maintenance. GIMPS already (by default) records the phop and (often) the nhop for all signalling sessions it knows about. the question is whether it discovers the phop/nhop from 1) addressing information carried at the IP level 2) addressing information carried in the packet payload 3) both (probably needed for the NSIS unaware NAT traversal case) my suspicion these days is probably (2) or (3) is the right answer for D mode, but people might like to consider the question in more detail (see also draft section 8.3). r. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Monday, February 02, 2004 17:39 > To: Hancock, Robert > Cc: 'brunner@ccrle.nec.de'; Nsis (E-mail) > Subject: Re: [NSIS] GIMPS connection mode and intermediaries > > > Hi Robert, > > Hancock, Robert wrote: > >> ... > >>>this is not my assumption. in a sane world > >>>*) a GIMPS unaware NAT should not change the flow ID at all, > >>>since it is just payload data. > >>>[i am aware of NATs which look for things like IP addresses > >>>in arbitrary payloads and attempt to rewrite them; I regard > >>>being broken by such a NAT as a feature, not a bug ;-).] > >>>but then the next GIMPS peer should detect the presence of > >>>the NAT (see above) and then try to work out what to do about > >>>it (as discussed a bit in Cedric's document). > >>> > >> > >>yes. Does GIMPS keep the previous nodes IP address in its payload? > > > > > > that's not currently defined, but there would not be a problem > > to do so e.g. in D mode. (it's not there currently because the > > need only seems to arise in this NSIS-unaware NAT traversal case > > which we have not really gone into yet). > > NAT traversal can need this. Furthermore, even in traditional > IntServ, > it may still require readjust of your reservations in the former hops > for a d-mode message passed. This was not a problem for RSVP which is > receiver-initiated and the receive knows exactly how much the path can > accommodate, but is for source-initiated signaling with > GIMPS. Either we > rely on another time of e2e d-message refresh (where an e2e or error > response is needed to trigger) *soon* after the first > attempt, or still > maintain PHOP also in GIMPS d-mode. > > Xiaoming > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 3 05:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01768 for ; Tue, 3 Feb 2004 05:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Any3F-0005iu-3E for nsis-archive@odin.ietf.org; Tue, 03 Feb 2004 05:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Aj4qI021944 for nsis-archive@odin.ietf.org; Tue, 3 Feb 2004 05:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Any3D-0005hp-VG; Tue, 03 Feb 2004 05:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Any2f-0005g6-Ii for nsis@optimus.ietf.org; Tue, 03 Feb 2004 05:44:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01631 for ; Tue, 3 Feb 2004 05:44:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Any2c-0005sP-00 for nsis@ietf.org; Tue, 03 Feb 2004 05:44:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Any1f-0005h8-00 for nsis@ietf.org; Tue, 03 Feb 2004 05:43:28 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Any0d-0005R7-00 for nsis@ietf.org; Tue, 03 Feb 2004 05:42:23 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 10:41:54 -0000 Message-ID: From: "Hancock, Robert" To: "'Xiaoming Fu'" Cc: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and network re-routing Date: Tue, 3 Feb 2004 10:42:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 xiaoming, > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Monday, February 02, 2004 17:38 > To: Hancock, Robert > Cc: 'brunner@ccrle.nec.de'; Nsis (E-mail) > Subject: Re: [NSIS] GIMPS connection mode and network re-routing > > > Hi Robert, > > Do we have a measurement about the possibility of a route > change due to > node failure during a session? i have no figures to hand. henning provided a pointer to rerouting statistics in an earlier mail. > Unless it is mobility-related route > change (very likely more frequent), in either mode (c- or d-), an e2e > refresh at NTLP level (which carefully chooses a refresh timer) in > general should be ok. i don't see how a refresh in C mode can do any good to you. this is precisely the point in question. > If the router which can detect a route > change is > able to support NTLP, we can certainly reuse RSVP local repair > mechanism, as additional enhancement. this is certainly something under consideration (although there is a question of whether "RSVP local repair" = "NTLP local repair" or "NSLP local repair". r. > > Xiaoming > > Hancock, Robert wrote: > > hi marcus, > > > > > >>>Therefore, we would propose to get rid of 5.3.4, leaving us with > >>>simple D mode and raw C mode. The consequence would be a final > >>>acceptance within the group that the lack of automatic route change > >>>detection in C mode is something we can all live with. > >>> > >> > >>I have no problem to get rid of this as long as the > >>specification defines how route changes are handled. > >> > >>Marcus > >> > > > > > > there are two parts to 'handled': > > 1. detected > > 2. repaired (in general, "reacted to") > > > > and (1) can be subdivided into > > 1a. detected as possibly having occurred > > 1b. confirmed (and the new route discovered) > > > > my view (but i am thinking aloud here) is that > > 1a - GIMPS will describe one method for this (periodic re-issue > > of D-mode query/response exchanges); might include protocol > > elements which assist other mechanisms (e.g. TTL measurements); > > but certainly won't be comprehensive. there is important > > stuff to be done here (cf. zappala's routing interface for > > RSVP) but not as part of the basic GIMPS spec. > > > > 1b - GIMPS defines this already (it's the D mode > > discover/query), or at least we know it has to. > > > > 2 - the main point is that GIMPS doesn't carry out > > the repair operation itself, it notifies NSLPs that they > > may need to do it. so, the main issue from a protocol > > perspective is: where (at which node) to deliver the > > notification. there are some subtleties here (sections > > 6.1.2 and 6.1.3 of the GIMPS draft) which some comments > > on would be nice. > > > > r. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 3 09:46:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10410 for ; Tue, 3 Feb 2004 09:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao1oU-0000Ig-MD for nsis-archive@odin.ietf.org; Tue, 03 Feb 2004 09:46:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Ek6bQ001146 for nsis-archive@odin.ietf.org; Tue, 3 Feb 2004 09:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao1oP-0000I9-OI; Tue, 03 Feb 2004 09:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao1no-0000GW-Fi for nsis@optimus.ietf.org; Tue, 03 Feb 2004 09:45:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10350 for ; Tue, 3 Feb 2004 09:45:21 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao1nm-0000BV-00 for nsis@ietf.org; Tue, 03 Feb 2004 09:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao1mo-00005d-00 for nsis@ietf.org; Tue, 03 Feb 2004 09:44:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ao1lv-00000C-00 for nsis@ietf.org; Tue, 03 Feb 2004 09:43:27 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13EhMM27691 for ; Tue, 3 Feb 2004 16:43:23 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Feb 2004 16:39:41 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 16:39:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Feb 2004 16:39:40 +0200 Message-ID: Thread-Topic: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea Thread-Index: AcPpuwTgdkUNeNFeSGGkdVKByia3QgAqIaag To: X-OriginalArrivalTime: 03 Feb 2004 14:39:42.0209 (UTC) FILETIME=[8F39AF10:01C3EA63] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea 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: quoted-printable There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting = in Seoul, Korea: February 9th: Cutoff Date for Initial Internet-Draft Submissions (new = documents) All initial Internet-Drafts (-00) and updates to initial Internet-Drafts = must be submitted by Monday, February 9th, at 09:00 ET. As always, all initial = submissions (-00) with a filename beginning with "draft-ietf" MUST be approved by = the appropriate WG Chair before they can be processed or announced. WG Chair approval = MUST be received by Wednesday, February 4th, at 09:00 ET. February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 = and higher) All revised Internet-Drafts (-01 and higher) must be submitted by = Monday, February 16th, at 09:00 ET. Initial and revised Internet-Drafts received after their respective = cutoff dates will NOT be made available in the Internet-Drafts directory OR = announced, and will have to be resubmitted. Please do NOT wait until the last minute to = submit. The Secretariat will begin accepting Internet-Draft submissions starting = Monday, March 8th. Thank you for your understanding and cooperation. If you have any = questions or concerns, then please send a message to internet-drafts@ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates = for the 59th IETF Meeting can be found at = http://www.ietf.org/meetings/cutoff_dates_59.html. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 3 14:11:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25101 for ; Tue, 3 Feb 2004 14:11:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5ww-0005BR-UG for nsis-archive@odin.ietf.org; Tue, 03 Feb 2004 14:11:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13JB6F7019912 for nsis-archive@odin.ietf.org; Tue, 3 Feb 2004 14:11:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5wt-0005Ae-4U; Tue, 03 Feb 2004 14:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5wS-0005A2-QF for nsis@optimus.ietf.org; Tue, 03 Feb 2004 14:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25059 for ; Tue, 3 Feb 2004 14:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5wQ-0007kG-00 for nsis@ietf.org; Tue, 03 Feb 2004 14:10:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5ve-0007f8-00 for nsis@ietf.org; Tue, 03 Feb 2004 14:09:46 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1Ao5us-0007a7-00 for nsis@ietf.org; Tue, 03 Feb 2004 14:08:58 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: LOGIN fu) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 03 Feb 2004 20:08:57 +0100 Message-ID: <401FF1CF.40408@cs.uni-goettingen.de> Date: Tue, 03 Feb 2004 20:09:03 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable To: "Hancock, Robert" CC: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: Re: [NSIS] GIMPS connection mode and network re-routing References: In-Reply-To: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.39.1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hancock, Robert wrote: > >>Unless it is mobility-related route >>change (very likely more frequent), in either mode (c- or d-), an e2e >>refresh at NTLP level (which carefully chooses a refresh timer) in >>general should be ok. > > i don't see how a refresh in C mode can do any good to you. > this is precisely the point in question. While the refreshes are forwarded peer-to-peer way, the NTLP node can choose either to do recovery or simple refresh, depending on the response for such "refreshes". In the formal case, for example, when a NTLP node sees ICMP =93host unreachable=94 or =93network unreachable=94 = message (which indicate a router failure at some point in the network) back to itself, it can initiate a new discovery and setup a new connection. Does= this work? > >>If the router which can detect a route >>change is >>able to support NTLP, we can certainly reuse RSVP local repair >>mechanism, as additional enhancement. > > this is certainly something under consideration (although there > is a question of whether "RSVP local repair" =3D "NTLP local > repair" or "NSLP local repair". I think it will be more likely NTLP local repair in this context. Reusing NTLP local repair as the general level to deal with routing of NSIS messages can avoid several parellel processes take place. This works well if the node detecting a route change also supports NSLPs; if not, a signal can be sent to corresponding NSLPs to carry there corresponding NSLP info stored in previous NSLP hop(s), then this NTLP node can initiate the re-establishment of all states in the new path segment. A problem comes, the same will be as in NSLP local repair, that= this detecting NTLP has no knowledge about how many NSLPs altogether bounded to the flow, and where are they (even with a capacity-based discovery we still needs to know which capacities they can be - how come?). Therefore, I would think a more general approach would be notifying the source node to deliver all NSLPs+NTLP information, i.e., trigger a new e2e refresh. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 3 18:00:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10987 for ; Tue, 3 Feb 2004 18:00:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9WZ-0001Yg-U8 for nsis-archive@odin.ietf.org; Tue, 03 Feb 2004 18:00:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13N07ie005975 for nsis-archive@odin.ietf.org; Tue, 3 Feb 2004 18:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9WW-0001Y8-NN; Tue, 03 Feb 2004 18:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9WJ-0001We-S2 for nsis@optimus.ietf.org; Tue, 03 Feb 2004 17:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10934 for ; Tue, 3 Feb 2004 17:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9WH-0004fF-00 for nsis@ietf.org; Tue, 03 Feb 2004 17:59:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9VE-0004ZK-00 for nsis@ietf.org; Tue, 03 Feb 2004 17:58:44 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9Up-0004UE-00 for nsis@ietf.org; Tue, 03 Feb 2004 17:58:20 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 22:57:45 -0000 Message-ID: From: "Hancock, Robert" To: Xiaoming Fu Cc: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and network re-routing Date: Tue, 3 Feb 2004 22:57:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi, new readers: please note a new open issue below. > >>Unless it is mobility-related route=20 > >>change (very likely more frequent), in either mode (c- or=20 > d-), an e2e=20 > >>refresh at NTLP level (which carefully chooses a refresh timer) in=20 > >>general should be ok. > >=20 > > i don't see how a refresh in C mode can do any good to you.=20 > > this is precisely the point in question. >=20 > While the refreshes are forwarded peer-to-peer way, the NTLP node can = > choose either to do recovery or simple refresh, depending on the=20 > response for such "refreshes". In the formal case, for=20 > example, when a=20 > NTLP node sees ICMP =93host unreachable=94 or =93network=20 > unreachable=94 message=20 > (which indicate a router failure at some point in the=20 > network) back to=20 > itself, it can initiate a new discovery and setup a new=20 > connection. Does=20 > this work? *if* the rerouting is taking place because of a node failure, *and* that node is the downstream NTLP peer, then you will detect that failure in C mode and can think about recovery the way you say (but see below). however, rerouting can take place for many reasons, and only rarely (i would contend) will it fit this scenario. the rerouting might not be related to a node failure (you could be adding or removing a link, or there could be a change in routing protocol state for some other reason. even if it is a node failure, if it doesn't change the reachability between the two peers, ICMP=20 messages won't tell you about this. summary: C mode has weak route change detection capabilities. we have to agree if this is ok to live with (so far I get the impression that it is). there is the question of how GIMPS should handle ICMP messages (and other error messages) in C mode. over-enthusiastic=20 processing can be a source of DoS attacks (as have been=20 identified in BGP of late). anyone with advice on this is welcome to offer it ... >=20 > >=20 > >>If the router which can detect a route=20 > >>change is=20 > >>able to support NTLP, we can certainly reuse RSVP local repair=20 > >>mechanism, as additional enhancement. > >=20 > > this is certainly something under consideration (although there > > is a question of whether "RSVP local repair" =3D "NTLP local > > repair" or "NSLP local repair". >=20 > I think it will be more likely NTLP local repair in this context.=20 > Reusing NTLP local repair as the general level to deal with=20 > routing of=20 > NSIS messages can avoid several parellel processes take place. This=20 > works well if the node detecting a route change also supports=20 > NSLPs;=20 but then it might as well be NSLP local repair, surely? > if=20 > not, a signal can be sent to corresponding NSLPs to carry there=20 > corresponding NSLP info stored in previous NSLP hop(s), then=20 > this NTLP=20 > node can initiate the re-establishment of all states in the new path=20 > segment. A problem comes, the same will be as in NSLP local=20 > repair, that=20 > this detecting NTLP has no knowledge about how many NSLPs altogether=20 > bounded to the flow, and where are they (even with a capacity-based=20 > discovery we still needs to know which capacities they can be - how=20 > come?). Therefore, I would think a more general approach would be=20 > notifying the source node to deliver all NSLPs+NTLP=20 > information, i.e.,=20 > trigger a new e2e refresh. but then the repair is not local anyway! (also, this does not tell you it should be NTLP repair as well.) it is clear that the NTLP has to be able to do the notification. but it is not clear that is has to do the repairs, or even if=20 this is possible. (for example, some route change detection=20 methods may be possible only at the NSLP level.) r. >=20 > Xiaoming >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 4 14:37:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21815 for ; Wed, 4 Feb 2004 14:37:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSpZ-00064L-AB for nsis-archive@odin.ietf.org; Wed, 04 Feb 2004 14:37:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Jb1SM023320 for nsis-archive@odin.ietf.org; Wed, 4 Feb 2004 14:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSpY-00063t-Ko; Wed, 04 Feb 2004 14:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSoy-000636-Ih for nsis@optimus.ietf.org; Wed, 04 Feb 2004 14:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21795 for ; Wed, 4 Feb 2004 14:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSov-0003OL-00 for nsis@ietf.org; Wed, 04 Feb 2004 14:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSo5-0003Ju-00 for nsis@ietf.org; Wed, 04 Feb 2004 14:35:29 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AoSnm-0003Ei-00 for nsis@ietf.org; Wed, 04 Feb 2004 14:35:11 -0500 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: LOGIN fu) by s2.ifi.informatik.uni-goettingen.de with esmtp; Wed, 04 Feb 2004 20:35:09 +0100 Message-ID: <40214974.8000506@cs.uni-goettingen.de> Date: Wed, 04 Feb 2004 20:35:16 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" , "Nsis (E-mail)" Subject: Re: [NSIS] GIMPS connection mode and network re-routing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, I agree that refresh in C mode makes things difficult; ICMP error messages don't work for this purpose in certain cases. Nevertheless, it may make sense to have an e2e refresh message to trigger discovery before being forwarded on to "next peer", allowing a chance to discover any route change in between two peers or next peer itself. Hancock, Robert wrote: >>I think it will be more likely NTLP local repair in this context. >>Reusing NTLP local repair as the general level to deal with >>routing of >>NSIS messages can avoid several parellel processes take place. This >>works well if the node detecting a route change also supports >>NSLPs; > but then it might as well be NSLP local repair, surely? Depends on how we call that. You can forward those NSLP messages from then on no matter what they are, but notify the corresponding NSLP entities when such are found. Routing is still job of the NTLP level - to be "recovered" with active discovery while . >>if >>not, a signal can be sent to corresponding NSLPs to carry there >>corresponding NSLP info stored in previous NSLP hop(s), then >>this NTLP >>node can initiate the re-establishment of all states in the new path >>segment. A problem comes, the same will be as in NSLP local >>repair, that >>this detecting NTLP has no knowledge about how many NSLPs altogether >>bounded to the flow, and where are they (even with a capacity-based >>discovery we still needs to know which capacities they can be - how >>come?). Therefore, I would think a more general approach would be >>notifying the source node to deliver all NSLPs+NTLP >>information, i.e., >>trigger a new e2e refresh. > > but then the repair is not local anyway! I don't argue this is real _local_ any more, but as said this causes a number of challenges. In either case (if this can be made possible or not) refreshing with trigger of discovery is perhaps more realistic. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 5 23:22:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27457 for ; Thu, 5 Feb 2004 23:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoxVF-0002ZP-Pm for nsis-archive@odin.ietf.org; Thu, 05 Feb 2004 23:22:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i164M5Da009875 for nsis-archive@odin.ietf.org; Thu, 5 Feb 2004 23:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoxVB-0002YC-L6; Thu, 05 Feb 2004 23:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopjV-0006YG-0j for nsis@optimus.ietf.org; Thu, 05 Feb 2004 15:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02024 for ; Thu, 5 Feb 2004 15:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AopjS-00009j-00 for nsis@ietf.org; Thu, 05 Feb 2004 15:04:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopib-00003H-00 for nsis@ietf.org; Thu, 05 Feb 2004 15:03:21 -0500 Received: from entcpt.et.tu-dresden.de ([141.30.128.139] helo=141.30.128.139) by ietf-mx with smtp (Exim 4.12) id 1Aophg-0007k2-00 for nsis@ietf.org; Thu, 05 Feb 2004 15:02:24 -0500 From: "MMB & PGTS 04" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Feb 2004 20:57:28 +0100 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,MSGID_FROM_MTA_SHORT, RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA02025 Subject: [NSIS] 2nd Call for Papers to MMB&PGTS04, 12-15 Sep.2004, Dresden, Germany 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: quoted-printable +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + 2nd CALL FOR PAPERS -- Submission Deadline 4 March 2004 + + + MMB&PGTS04 + + 12-15 September 2004, Technische Universitaet Dresden + www.mmbpgts.org + + Joint conference + 12th GI/ITG Conference on Measuring, Modelling + and Evaluation of Computer and=20 + Comummunication Systems (MMB) + together with + 3rd Polish-German Teletraffic Symposium (PGTS) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The German MMB conference series started in 1981, the Polish-German PGTS in 2000. Both conferences are covering all aspects of performance evaluation of communication and data processing systems and networks. The combination of both conferences brings together the active Polish and German teletraffic and data traffic communities. CONFERENCE TOPICS Teletraffic Models and Traffic Theory - Traffic characterization - User behaviour - Traffic measurements - Parameterization Traffic Control and QoS - Internet traffic engineering - Reservation and priority mechanisms Network and System Architectures - High-speed switching fabrics - Photonic switching Mobile Networks - Mobile broadband networks - Ad hoc networks - Mobility management Network Design and Planning - Network topologies - Network optimization - Access and backbone networks - Satellite networks Traffic and Network Management - Service engineering - Network security - Network reliability - Recovery and restoration - Accounting and tariffing Protocol Performance - Wireless networks - Multicast - Routing - Interworking Computer Systems and Networks - Real-time systems - Multiprocessor systems - Embedded systems - Logistic systems and workflows Performance Evaluation Methods - Queueing theory - Queueing networks - Analytical and numerical analysis - Approximations and bound computation - Stochastic Petri nets - Stochastic process algebras - Simulation techniques: rare event simulation, distributed simulation, hybrid simulation - Performance tools Quantitative Measures - Performability - Dependability Performance Measurements - Hard- and software monitors - Hybrid monitors - Statistical data evaluation (time series analysis) - Benchmarking - Application examples IMPORTANT DATES A) Full Papers (approx. 5000 characters or 15 pages typewriter, double spaced, PDF) should be submitted to the conference server by www.mmbpgts.org before 4 March 2004. Accepted papers will be given 30 minutes for presentation and=20 discussion. B) We also solicit to submit Short Papers describing actual ongoing=20 work, tools (approx. 1500 characters or 5 typewriter, double spaced pages, PDF) also before 4 March 2004. Accepted papers will be given 15 minutes for presentation and=20 discussion. Acceptance notification: 1 June 2004 Camera ready papers due: 1 July 2004 TUTORIALS Two tutorials are planned in the afternoon on 12 September 2004.=20 Proposals for tutorials should be sent to Peter Buchholz (email: peter.buchholz@postamt.cs.uni-dortmund.de) TOOLS EXHIBITION Desks and poster stands will be provided for the presentation of software tools. Requests to present a tool should be submitted=20 before 1 July 2004. Due to space limitations, places will be=20 allocated on a FCFS basis. LANGUAGE The official language of conference is English. VENUE Dresden is the capital of Saxony and the new European center of Microelectronics with big fabs of Infineon, AMD and others. The=20 baroque city of Dresden is famous for its beautiful buildings=20 such as the Zwinger, the Semper opera house and the nearly completed reconstruction of the Frauenkirche. The conference dinner is planned=20 to held on a steamboat river Elbe cruise to Pillnitz castle. The=20 "Technische Universitaet Dresden" is one of the biggest universities of technology in Germany with more than 30.000 students. COMMITTEE Conference Chairs Paul J. Kuehn, University of Stuttgart Jozef Wozniak, Gdansk University of Technology Technical Programme Committee Peter Buchholz, University of Dortmund Ralf Lehnert, Technische Universitaet Dresden Michal Pioro, Warsaw University of Technology Wojciech Burakowski, Warsaw University of Technology Tadeusz Chachorski, Polish Academy of Sciences, Gliwice Joachim Charzinski, Siemens AG, Munich Janusz Filipiak, AGH University of Sciences and Technology, Cracow Reinhard German, University of Erlangen-Nuernberg Carmelita Goerg, University of Bremen Adam Grzek, Wroclaw University of Technology Franz Hartleb, T-Systems, Darmstadt Boudewijn Haverkort, University of Twente Andrzej Jajsczyk, AGH University of Sciences and Technology, Cracow Wojciech Kabacinski, Poznan University of Technology Sylwester Kaczmarek, Gdansk University of Technology Andrzej Kasprzak, Wroclaw University of Technology Ullrich Killat, Harburg University of Technology Jerzy Konorski, Gdansk University of Technology Udo Krieger, University of Bamberg Paul J. Kuehn, University of Stuttgart Axel Lehmann, University of Armed Forces, Munich Christoph Lindemann, University of Dortmund Jozef Lubacz, Warsaw University of Technology Andreas Mitschele-Thiel, Technische Universitaet Ilmenau Bruno Mueller-Clostermann, University of Duisburg-Essen Joerg Oehlerich, Siemens AG, Munich Andrzej Pach, AGH Univ. of Science and Technology, Cracow Zdzislaw Papir, AGH Univ. of Science and Technology, Cracow Martin Paterok, Bertelsmann, Guetersloh Georg Roe=DFler, Tenovis GmbH, Frankfurt Maciej Stasiak, Poznan University of Technology Michael Tangemann, Alcatel, Stuttgart Matthias Wippenbeck, Marconi Communications, Backnang Adam Wolisz, Technische Universitaet Berlin Jozef Wozniak, Gdansk University of Technology For more information please contact: Prof.Dr.-Ing.Ralf Lehnert Dipl.-Ing. Rong Zhao Technische Universitaet Dresden Communications Laboratory Chair for Telecommunications D-01062 Dresden, Germany E-Mail: info@mmbpgts.org _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Feb 7 00:19:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08926 for ; Sat, 7 Feb 2004 00:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApKrw-00041z-Bt for nsis-archive@odin.ietf.org; Sat, 07 Feb 2004 00:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i175J4ib015480 for nsis-archive@odin.ietf.org; Sat, 7 Feb 2004 00:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApKrt-00040w-3V; Sat, 07 Feb 2004 00:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0wZ-0006vA-V7 for nsis@optimus.ietf.org; Fri, 06 Feb 2004 03:02:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15934 for ; Fri, 6 Feb 2004 03:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0wV-000373-00 for nsis@ietf.org; Fri, 06 Feb 2004 03:02:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0vY-00035C-00 for nsis@ietf.org; Fri, 06 Feb 2004 03:01:29 -0500 Received: from smtp0.libero.it ([193.70.192.33]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0ux-00031O-00 for nsis@ietf.org; Fri, 06 Feb 2004 03:00:51 -0500 Received: from libero.it (193.70.192.38) by smtp0.libero.it (7.0.020-DD01) id 3F6F1CE3010D0538 for nsis@ietf.org; Fri, 6 Feb 2004 09:00:21 +0100 Date: Fri, 6 Feb 2004 09:00:21 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Ivano De Luca" To: "nsis" X-XaM3-API-Version: 4.1 (b23) X-type: 0 X-SenderIP: 82.104.69.9 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Unsubscribe deluca.ivano@inwind.it 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: quoted-printable Unsubscribe deluca.ivano@inwind.it Ivano from PBG4 =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D If you wanna be a Panther...(Ivano De Luca) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Feb 8 23:25:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16712 for ; Sun, 8 Feb 2004 23:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2yn-0001Yj-G3 for nsis-archive@odin.ietf.org; Sun, 08 Feb 2004 23:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i194P5aP005986 for nsis-archive@odin.ietf.org; Sun, 8 Feb 2004 23:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2yj-0001YF-Vo; Sun, 08 Feb 2004 23:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq1Lt-0002bO-GC for nsis@optimus.ietf.org; Sun, 08 Feb 2004 21:40:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13110 for ; Sun, 8 Feb 2004 21:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq1Lq-00045e-00 for nsis@ietf.org; Sun, 08 Feb 2004 21:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq1Kz-000417-00 for nsis@ietf.org; Sun, 08 Feb 2004 21:39:54 -0500 Received: from simmts7.bellnexxia.net ([206.47.199.165] helo=simmts7-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1Aq1KO-0003uk-00 for nsis@ietf.org; Sun, 08 Feb 2004 21:39:16 -0500 Received: from sandelman.ottawa.on.ca ([156.34.219.246]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040209023843.BULI1231.simmts7-srv.bellnexxia.net@sandelman.ottawa.on.ca> for ; Sun, 8 Feb 2004 21:38:43 -0500 Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i192cgwF014515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 8 Feb 2004 22:38:42 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i192ccji014512 for ; Sun, 8 Feb 2004 22:38:42 -0400 To: nsis@ietf.org Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 08 Feb 2004 22:38:38 -0400 Message-ID: <14511.1076294318@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=LINES_OF_YELLING autolearn=no version=2.60 Subject: [NSIS] review - some security comments on documents Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- I was asked to review the requirements, framework and theats documents, from a security perspective. To be clear my background is Firewalls, IPsec, key management, and I spent some time trying to build programmable fast path policy-based classifiers. I was also involved in the Security Policy Protocol (SPP) as a firewall vendor - i.e. trying to solve the problem of getting IPsec through firewalls before the term NAT was around. REQUIREMENTS My general comment is that this protocol is too general. A key symptom of this is that the requirements are not prioritized. The key thing is, when compromises need to be made, on what basis will the compromise be made? Since security is a major requirement, and there are multiple operational requirements which are very hard to secure, how will things bend? FRAMEWORK The framework document excited me. I thought, this is going to be some sophisticated protocol - end to end, plus hop-to-hop, with mutable objects, and immutable objects, and some way to insert and delete objects while avoiding unwanted manipulation by intermediate nodes. In the end, the framework document actually specified far more requirements than the requirements document. Most of the additions are very specific security requirements. While I understand why there are two documents from a strict work-flow point of view, I think it may be simpler to have one document, perhaps one that isn't quite as big. THREATS The threats document needs work. I was expecting a threat-model. What things need to be defended against. Well, again the protocol is too general to do this, so the document is a bit of a mismash of different things. Who do we need to trust to make this protocol work? {And, is that a realistic business model? If not, can we change the trust model to one what matches reality?} {Please don't tell me that the IETF doesn't do business models. We do. "Best effort zero-settlement" has been the business model for most of the Internet. Our current protocols current support that model. QoS proposes different business models, so we need to know who pays, who gains, and where is the possible fraud. We need to know this so that we can find out if the security protects these relationships.) A key thing that concerned me is that NSLP objects could be inserted/deleted, reordered, or even replayed, by NE that are participating in the hop-by-hop security. End-to-end integrity would protect the objects, but not their existence. NSTL/NSLP need an NXT-like (DNSSEC) object which is always present, so that the receiver can know if objects were removed/inserted. A major threat that I see is CPU exhaustion of the slow-path. Specifically, NSTL's section 8.4 - the system MUST aggregate well. But more than that, it must DEFEND that aggregation at the edges. I want to suggest that there are strong arguments for having an integrity protocol where one can examine the contents of the message first, (since that is often rather cheap to do) determine if it actually changes state, and only if the message needs to be acted on, THEN confirm the integrity of the message. AH, btw, is one integrity protocol that permits this. If one needs hop-by-hop privacy, then one has to provision the decryptor to run at anticipated wire-speed to be able to examine the packets, but the authenticator, (which might even be public key based) does not need to run at that speed. I also want to suggest that the security and trust model be fully developed before any other details are filled on. The threats document also seems to have been written in isolation from the framework and requirements document. I think it should parallel the requirements, explaining why there is a requirement, for instance, for hop-by-hop security, or end-to-end object integrity, etc.. OTHER DOCUMENTS I was not asked specifically to review the nstl-00 or application specific documents, but I did take a look at them. I think that the NSTL is the key to the security. While I am very impressed with this -00 document, I think it is wrong to start with packet formats, and whether or not TLS, UDP, IPsec, is useable. Please start with the public keys - when will they be used, how/if will they be strongly authenticated, etc. Maybe that goes into the framework document. The QoS document claimed that all of this would be offloaded to some AAA protocol -- I think that this is a cop out. I need to know how the AAA will provide the integrity protection, the authentication and authorization that is required. Section 7 of NSTL basically reads as "just use IPsec". NOT ENOUGH. Think about the relationships and where the keys will come from. IKE is signaling. Maybe using signalling to secure signaling is the wrong choice. Maybe not. Please find and read draft-ietf-ipsp-spp-01.txt. I read: "An alternative approach would be to use raw IP with the RSVP protocol numbers and a new RSVP version number." This may also conserve/preserve silicon! I have a question from ignorance of deployed hardware: Are RAO filters really available in production fast-path silicon? I know that some silicon vendors can cope, because they are programmable/configurable, but what about those that aren't? In the NAT-FW document, it says: 3.2 "Discovering security gateways, which was also mentioned as an application for NSIS signaling, for the purpose of executing an IKE to create an IPsec SA, is already solved without requiring NSIS." really? I didn't know that it was solved. Do tell! The QoS and NAT-FW document is clearly too preliminary for me to be able to evaluate whether or not the requirements or features of the framework have been satisfied by this protocol. In particular, no statements are made about the trust relationships, or who may edit what mutable fields, etc. I was hoping that there might be enough meat here to saw whether or not the framework requirement were useful/complete. OTHER: are there really RMF's capable of managing the resources for all paths through a network? I thought that the ATM folks tried to do this and failed, and this was one of the reasons that ATM didn't get the deployment that was originally envisioned? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQCbyqoqHRg3pndX9AQFR/AQAsIXy5Ekd75e9BAWMqX1DdxeZKICdI8fi 2+SX3nd34LzTMI5kTsBtCm5Pohl2Gn0B8s3jFkIeZ5qClCZp/Q7yEqz0+52vjJoJ vwPNNvbJM31bpdY8hlY4ajA9OkNlYCfnexfoMr6G6I0hqpHlwnpDCs+ykK9d8M19 pu0UFTKR09A= =nK5K -----END PGP SIGNATURE----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 9 05:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10019 for ; Mon, 9 Feb 2004 05:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8OZ-0006EH-GH for nsis-archive@odin.ietf.org; Mon, 09 Feb 2004 05:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19AC3RR023930 for nsis-archive@odin.ietf.org; Mon, 9 Feb 2004 05:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8OX-0006Dh-NF; Mon, 09 Feb 2004 05:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8OQ-0006DP-VJ for nsis@optimus.ietf.org; Mon, 09 Feb 2004 05:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09981 for ; Mon, 9 Feb 2004 05:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8ON-0001jW-00 for nsis@ietf.org; Mon, 09 Feb 2004 05:11:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq8NQ-0001dy-00 for nsis@ietf.org; Mon, 09 Feb 2004 05:10:53 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8MY-0001ZG-00 for nsis@ietf.org; Mon, 09 Feb 2004 05:09:58 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i19A9vCi000571; Mon, 9 Feb 2004 11:09:57 +0100 (MET) Message-ID: <008801c3eef4$dfe00fa0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Nsis \(E-mail\)" Cc: Date: Mon, 9 Feb 2004 11:09:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all Last Friday we have submitted the following draft to the IETF (NSIS): "RMD (Resource Management in Diffserv) QoS-NSLP model", draft-bader-RMD-QoS-model-00.txt. It will probably take some time to be announced. Therefore, I am sending you the URL where you, temporarily, can find it: http://wwwhome.cs.utwente.nl/~goering/draft-bader-RMD-QoS-model-00.txt This draft describes an edge-to-edge local QoS model, called Resource Management in Diffserv (RMD), which uses the stateless/reduced state operation mode of QoS-NSLP protocol. The model provides scalability and uses simplified NSIS operation. The specification of this QoS model includes description of QSpec parameters, as well as how that information should be treated and interpreted in the network. In that sense, this QoS model goes beyond the QoS-NSLP protocol level and describes underlying assumptions, conditions and appropriate provisioning mechanisms. If you have any comments or questions please reply to this e-mail (on the NSIS mailing list). Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 9 05:37:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11237 for ; Mon, 9 Feb 2004 05:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8mk-000852-8Z for nsis-archive@odin.ietf.org; Mon, 09 Feb 2004 05:37:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Ab2Yn031036 for nsis-archive@odin.ietf.org; Mon, 9 Feb 2004 05:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8mj-00084O-Gd; Mon, 09 Feb 2004 05:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8lm-00080D-5T for nsis@optimus.ietf.org; Mon, 09 Feb 2004 05:36:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11210 for ; Mon, 9 Feb 2004 05:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8li-0004CT-00 for nsis@ietf.org; Mon, 09 Feb 2004 05:35:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq8l0-00047v-00 for nsis@ietf.org; Mon, 09 Feb 2004 05:35:15 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8kQ-00041w-00 for nsis@ietf.org; Mon, 09 Feb 2004 05:34:38 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i19AYdj14511; Mon, 9 Feb 2004 11:34:39 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i19AYck25442; Mon, 9 Feb 2004 11:34:38 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Feb 2004 11:34:03 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC06DC@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Michael Richardson'" , nsis@ietf.org Subject: RE: [NSIS] review - some security comments on documents Date: Mon, 9 Feb 2004 11:34:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 michael, it is great that you took your time to read our documents. please find my comments inline: > > I was asked to review the requirements, framework and theats > documents, > from a security perspective. To be clear my background is > Firewalls, IPsec, > key management, and I spent some time trying to build > programmable fast > path policy-based classifiers. I was also involved in the > Security Policy > Protocol (SPP) as a firewall vendor - i.e. trying to solve the problem > of getting IPsec through firewalls before the term NAT was around. > > REQUIREMENTS > > My general comment is that this protocol is too general. as a background: this was our first document in the nsis working group. at the beginning we haven't had a clear idea what we were addressing in the working group in detail. for example, nat/fw signaling was not in scope at that time. hence, all requirements are rather high-level. later we decided that we should move forward and finish the work on the requirements rather than re-writing them again to, for example, reflect the two-layer architecture. > A > key symptom of > this is that the requirements are not prioritized. The key thing is, > when compromises need to be made, on what basis will the > compromise be made? that's always a problem with requirements. if you look at other working groups then you will notice that the requirements are not prioritized as well. > > Since security is a major requirement, and there are multiple > operational > requirements which are very hard to secure, how will things bend? could you be more specific? > > FRAMEWORK > > The framework document excited me. I thought, this is going to be some > sophisticated protocol - end to end, plus hop-to-hop, with > mutable objects, > and immutable objects, and some way to insert and delete objects while > avoiding unwanted manipulation by intermediate nodes. In the end, the > framework document actually specified far more requirements than the > requirements document. Most of the additions are very > specific security > requirements. you are right. the framework is more specific than the requirements document since it was written much later and we had more ideas what we are going to solve and how. > > While I understand why there are two documents from a strict > work-flow > point of view, I think it may be simpler to have one > document, perhaps > one that isn't quite as big. > hmmm. in the past we have received a number of comments regarding document restructering. restructuring the documents again and again is very time consuming and might not add that much value. > THREATS > > The threats document needs work. I was expecting a > threat-model. What things > need to be defended against. Well, again the protocol is too > general to do > this, so the document is a bit of a mismash of different things. > > Who do we need to trust to make this protocol work? > > {And, is that a realistic business model? If not, can we > change the trust > model to one what matches reality?} > > {Please don't tell me that the IETF doesn't do business > models. We do. "Best > effort zero-settlement" has been the business model for most of the > Internet. Our current protocols current support that model. > QoS proposes > different business models, so we need to know who pays, who gains, and > where is the possible fraud. We need to know this so that we > can find out if > the security protects these relationships.) certainly true. the initial focus of the working group was oriented towards qos signaling. we wrote a separate draft which addresses authorization aspects in qos signaling to raise peoples attention (; actually two drafts have been written). you might want to take a look at them: http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-qos-authz-issues-00.t xt and http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.txt http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.pdf unforunately, we have not received proper attention. another thing regarding the threat model: you have different security requirements at different layers: first, you need to worry about the signaling exchange between neighboring nodes itself itself and then you need to worry about what you actually signal. you can compare this to diameter. diameter itself needs some the same is true for sip. we tried to capture these issues with Figure 2 in [THREATS]. a document handling issue: it is difficult to address all threats of all possible signaling applications in the threats draft itself. it took us some time to think about the threats and the problems of nat/firewall handling. we have placed them in the nat/firewall nslp draft. some other threats are very specific to some signaling protocols but not present in others. > > A key thing that concerned me is that NSLP objects could be > inserted/deleted, > reordered, or even replayed, by NE that are participating in > the hop-by-hop > security. End-to-end integrity would protect the objects, > but not their > existence. nsis is not really an end-to-end signaling protocol, in most cases. you might want to take a look at section 4 of the draft. there we argue that hop-by-hop security makes a lot of sense in qos signaling with the corresponding authorization model (we called it New Jersey Turnpike Model, just to give it a name). a different model (we called it New Jersey Parkway Model) makes everything very, very difficult - with little utility. you have to trust the intermediate nodes to a certain degree since they can do all sorts of things. > NSTL/NSLP need an NXT-like (DNSSEC) object which is always > present, so that the receiver can know if objects were > removed/inserted. certainly an interesting idea. if you look at the rsvp security property drafts then you see that some people already proposed similar things but they have never been deployed anywhere (in case of qos signaling). for nat/firewall signaling we are currently investigating the need for end-to-end protection. there, however, you have the problem that you only signal a packet filter which might change along the path and, in presence of nats, has no meaning to the other end. > > A major threat that I see is CPU exhaustion of the slow-path. > Specifically, > NSTL's section 8.4 - the system MUST aggregate well. But more > than that, > it must DEFEND that aggregation at the edges. i we need to talk about this issue in more detail. i am not sure what we both mean the same with aggregation. which draft you are referring? > > I want to suggest that there are strong arguments for having > an integrity > protocol where one can examine the contents of the message > first, (since > that is often rather cheap to do) determine if it actually > changes state, > and only if the message needs to be acted on, THEN confirm > the integrity > of the message. AH, btw, is one integrity protocol that > permits this. If > one needs hop-by-hop privacy, then one has to provision the > decryptor to run > at anticipated wire-speed to be able to examine the packets, but the > authenticator, (which might even be public key based) does not need to > run at that speed. we fully agree that you need to have integrity protection. steve bellovin was one of those persons that insisted on having support for encryption (unlike in rsvp where only integrity protection is offered). performance considerations are a separate issue. usually signaling message protection is the least thing we worry about. the key exchange creates more headaches. additionally, if you propose end-to-end security then things get really difficult. > > I also want to suggest that the security and trust model be > fully developed > before any other details are filled on. do you have a draft were we can look at to see what you would like to see? > > The threats document also seems to have been written in > isolation from the > framework and requirements document. why do you think so? the requirements document was written before we started the work on the threats document. I think it should parallel the > requirements, explaining why there is a requirement, for instance, for > hop-by-hop security, or end-to-end object integrity, etc.. you are certainly right. we will double-check whether there is some consistency in there. if there are inconsistencies then i am guilty for it since i wrote the section in the requirements draft, threats draft and the framework draft. > > OTHER DOCUMENTS > > I was not asked specifically to review the nstl-00 or > application specific > documents, but I did take a look at them. > which one? gimps ntlp? the nat/firewall nslp or the qos nslp? i give you an answer for all three of them: - ntlp: we need to work on the security description. the next version will contain more content. - qos nslp: we are working on the security issues. we basically have add the content of the previously mentioned qos authorization drafts in there (and at the same time try to keep the document at a low pagecount.) currently the qos document contains no security since we haven't had time to finish all the work. please note that this is not the first security document. it is a merge of previous document which contained security. however, the process of merging document takes some time - work in progress.if you look at the qos authorization documents than you will be convienced that we serioulsly tooked at qos authorization (based on steve bellovin's request). - nat/fw nslp: see below. > I think that the NSTL is the key to the security. ntlp - gimps: it is the key for security between neighboring nodes. it cannot address authorization issues for nslp applications. > While I am > very impressed > with this -00 document, I think it is wrong to start with > packet formats, > and whether or not TLS, UDP, IPsec, is useable. agreed. the ntlp suffers from detailed threats. unfortunately, editing was done in the last minute and i had no chance to add some text. we discussed threats at the mailing list but we haven't incorporated them into the draft yet. the ntlp is also not the first document in this area. we have had a number of other documents before. some of them had such a detailed security consideration section that people said: "this is not a security protection - keep the security consideration section shorter." > > Please start with the public keys - when will they be used, > how/if will they > be strongly authenticated, etc. Maybe that goes into the > framework document. i guess we need to discuss this issue in more detail. > > The QoS document claimed that all of this would be offloaded > to some AAA > protocol -- I think that this is a cop out. I need to know how the AAA > will provide the integrity protection, the authentication and > authorization > that is required. > > Section 7 of NSTL basically reads as "just use IPsec". > NOT ENOUGH. Think about the relationships and where the keys > will come from. > IKE is signaling. Maybe using signalling to secure signaling > is the wrong > choice. Maybe not. > > Please find and read draft-ietf-ipsp-spp-01.txt. > > I read: "An alternative approach would be to use raw IP with the RSVP > protocol numbers and a new RSVP version number." > This may also conserve/preserve silicon! certainly not my idea (since it also creates problems with some ipsec implementations with regard to the supported traffic selectors). > > I have a question from ignorance of deployed hardware: > Are RAO filters really available in production fast-path > silicon? I know that > some silicon vendors can cope, because they are > programmable/configurable, > but what about those that aren't? this issue is, among many others, discussed in the analysis document. you might also want to take a look at michael's web page which talks about the impact of ip option processing: http://www.welzl.at/ip-options/ > > In the NAT-FW document, it says: > 3.2 > "Discovering security gateways, which was also mentioned as an > application for NSIS signaling, for the purpose of > executing an IKE > to create an IPsec SA, is already solved without requiring NSIS." > > really? I didn't know that it was solved. Do tell! we tried to scope our work. our work started with installation of packet filters in a path-coupled way. we are not developing a solution for ike to discover ipsec gateways. you might want to take a look at tunnel endpoint discovery (ted) for such a solution. > > The QoS and NAT-FW document is clearly too preliminary for me > to be able to > evaluate whether or not the requirements or features of the > framework have > been satisfied by this protocol. In particular, no statements > are made about > the trust relationships, or who may edit what mutable fields, > etc. for nat-fw draft: actually the draft contains a fair amount of discussion on trust relationships (see section 3.5, section 4., appendix b, appendix D). that's more than i have ever seen in the are of path-coupled firewall signaling. there are no requirements for nat/firewall signaling. melinda shore suggested the idea in the midcom working group. she presented her idea at the tist bof and the work was moved to nsis. > I was > hoping that there might be enough meat here to saw whether or not the > framework requirement were useful/complete. the framework focuses on qos signaling and not really on nat/firewall signaling. > > OTHER: > are there really RMF's capable of managing the resources for all > paths through a network? I thought that the ATM folks > tried to do > this and failed, and this was one of the reasons that ATM didn't > get the deployment that was originally envisioned? that's a qos question which many folks in the nsis working group will be glad to give you an answer for :-) thanks again for your detailed comments and for the time looking at the drafts. your comments will certainly improve the quality of the documents. ciao hannes > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Xelerance Corporation, Ottawa, ON > |net architect[ > ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQCbyqoqHRg3pndX9AQFR/AQAsIXy5Ekd75e9BAWMqX1DdxeZKICdI8fi 2+SX3nd34LzTMI5kTsBtCm5Pohl2Gn0B8s3jFkIeZ5qClCZp/Q7yEqz0+52vjJoJ vwPNNvbJM31bpdY8hlY4ajA9OkNlYCfnexfoMr6G6I0hqpHlwnpDCs+ykK9d8M19 pu0UFTKR09A= =nK5K -----END PGP SIGNATURE----- _______________________________________________ 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 exim@www1.ietf.org Mon Feb 9 07:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14334 for ; Mon, 9 Feb 2004 07:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqA8w-0008JL-Bz for nsis-archive@odin.ietf.org; Mon, 09 Feb 2004 07:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19C42ub031946 for nsis-archive@odin.ietf.org; Mon, 9 Feb 2004 07:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqA8v-0008J9-Q8; Mon, 09 Feb 2004 07:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqA83-0008HF-AL for nsis@optimus.ietf.org; Mon, 09 Feb 2004 07:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14281 for ; Mon, 9 Feb 2004 07:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqA7z-0004Rj-00 for nsis@ietf.org; Mon, 09 Feb 2004 07:03:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqA71-0004Mz-00 for nsis@ietf.org; Mon, 09 Feb 2004 07:02:05 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AqA6m-0004Hw-00 for nsis@ietf.org; Mon, 09 Feb 2004 07:01:49 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Feb 2004 12:01:10 -0000 Message-ID: From: "Hancock, Robert" To: "'Michael Richardson'" , nsis@ietf.org Subject: RE: [NSIS] review - some security comments on documents Date: Mon, 9 Feb 2004 12:01:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Michael, Thanks for these comments. I'll try to address those which affect the framework and NTLP (my main focus). NSLP authors should definitely read this (it is a request for input for NTLP development). On the document structure, I think everyone (including the authors) would accept the structure we have for the 'informationals' is not ideal. It's something that is too late to change now, but might be avoided in the future if the IETF had better defined working processes (although that might be a double-edged sword, of course). If we have managed to set ourselves up to design the 'right' protocols, I think that's the best we can do (and I think we have, maybe with one exception you point out). The primary open security issue - as it affects the NTLP, and as maybe should have been explained more in the f/w but weren't - is how the trust and security models should be reflected in the actual operation of the protocol. Specifically, the NTLP draft currently says (mainly in section 7): - there is some stuff about DoS attacks and routing integrity attacks, which have to be handled (and handled non-cryptographically) in the NTLP (in fact, I regard this as the main security service provided by the NTLP) - if you want channel protection, use existing security protocols - BUT it doesn't say how those protocols should be invoked in detail (or, really, at all). The problem is that the trust/security models IMHO can't be fully defined by the NTLP but are signalling application specific (and probably in fact also deployment specific). This issue is (implicitly) defined as open in section 8.6 of the NTLP draft. Therefore: Maybe what we need to do is to get the NSLP authors to say how their trust/security models imply that channel security protocols should be invoked, and then make sure that the NTLP can be used compatibly with those requirements (and still maintain the DoS/routing integrity protection which is its major goal). I'm fairly certain in my own head, however, that the NTLP needs to be flexible (i.e. not constrain) what trust/security models can be used. To draw a comparison, 3436 and 3554 contain basically no discussion of such issues; I think the NTLP needs to go a bit further, but not very far. robert h. PS you also raise a couple of points about IP layer issues (RAO processing, IP protocol number). Basically, I don't think there is a 'right' answer - all we can do is gather all the information we can and make a (hard) judgement call. However, my impressions are: - if RAO processing with some discrimination can't be done on the fast path, we are stuffed anyway. I think the way the RAO has been defined is a perfect fit to our requirements, and if people haven't implemented it there isn't much we can do. - I don't see much difference either way between "RSVPv2" and "UDP to the RSVP port" from a complexity perspective. The motivation for UDP comes mainly from NAT handling issues (maybe this should be explained a bit more in section 8.2). > -----Original Message----- > From: Michael Richardson > [mailto:mcr@cyphermail.sandelman.ottawa.on.ca] > Sent: Monday, February 09, 2004 02:39 > To: nsis@ietf.org > Subject: [NSIS] review - some security comments on documents > > > -----BEGIN PGP SIGNED MESSAGE----- > > > I was asked to review the requirements, framework and theats > documents, > from a security perspective. To be clear my background is > Firewalls, IPsec, > key management, and I spent some time trying to build > programmable fast > path policy-based classifiers. I was also involved in the > Security Policy > Protocol (SPP) as a firewall vendor - i.e. trying to solve the problem > of getting IPsec through firewalls before the term NAT was around. > > REQUIREMENTS > > My general comment is that this protocol is too general. A > key symptom of > this is that the requirements are not prioritized. The key thing is, > when compromises need to be made, on what basis will the > compromise be made? > > Since security is a major requirement, and there are multiple > operational > requirements which are very hard to secure, how will things bend? > > FRAMEWORK > > The framework document excited me. I thought, this is going to be some > sophisticated protocol - end to end, plus hop-to-hop, with > mutable objects, > and immutable objects, and some way to insert and delete objects while > avoiding unwanted manipulation by intermediate nodes. In the end, the > framework document actually specified far more requirements than the > requirements document. Most of the additions are very > specific security > requirements. > > While I understand why there are two documents from a strict > work-flow > point of view, I think it may be simpler to have one > document, perhaps > one that isn't quite as big. > > THREATS > > The threats document needs work. I was expecting a > threat-model. What things > need to be defended against. Well, again the protocol is too > general to do > this, so the document is a bit of a mismash of different things. > > Who do we need to trust to make this protocol work? > > {And, is that a realistic business model? If not, can we > change the trust > model to one what matches reality?} > > {Please don't tell me that the IETF doesn't do business > models. We do. "Best > effort zero-settlement" has been the business model for most of the > Internet. Our current protocols current support that model. > QoS proposes > different business models, so we need to know who pays, who gains, and > where is the possible fraud. We need to know this so that we > can find out if > the security protects these relationships.) > > A key thing that concerned me is that NSLP objects could be > inserted/deleted, > reordered, or even replayed, by NE that are participating in > the hop-by-hop > security. End-to-end integrity would protect the objects, > but not their > existence. NSTL/NSLP need an NXT-like (DNSSEC) object which is always > present, so that the receiver can know if objects were > removed/inserted. > > A major threat that I see is CPU exhaustion of the slow-path. > Specifically, > NSTL's section 8.4 - the system MUST aggregate well. But more > than that, > it must DEFEND that aggregation at the edges. > > I want to suggest that there are strong arguments for having > an integrity > protocol where one can examine the contents of the message > first, (since > that is often rather cheap to do) determine if it actually > changes state, > and only if the message needs to be acted on, THEN confirm > the integrity > of the message. AH, btw, is one integrity protocol that > permits this. If > one needs hop-by-hop privacy, then one has to provision the > decryptor to run > at anticipated wire-speed to be able to examine the packets, but the > authenticator, (which might even be public key based) does not need to > run at that speed. > > I also want to suggest that the security and trust model be > fully developed > before any other details are filled on. > > The threats document also seems to have been written in > isolation from the > framework and requirements document. I think it should parallel the > requirements, explaining why there is a requirement, for instance, for > hop-by-hop security, or end-to-end object integrity, etc.. > > OTHER DOCUMENTS > > I was not asked specifically to review the nstl-00 or > application specific > documents, but I did take a look at them. > > I think that the NSTL is the key to the security. While I am > very impressed > with this -00 document, I think it is wrong to start with > packet formats, > and whether or not TLS, UDP, IPsec, is useable. > > Please start with the public keys - when will they be used, > how/if will they > be strongly authenticated, etc. Maybe that goes into the > framework document. > > The QoS document claimed that all of this would be offloaded > to some AAA > protocol -- I think that this is a cop out. I need to know how the AAA > will provide the integrity protection, the authentication and > authorization > that is required. > > Section 7 of NSTL basically reads as "just use IPsec". > NOT ENOUGH. Think about the relationships and where the keys > will come from. > IKE is signaling. Maybe using signalling to secure signaling > is the wrong > choice. Maybe not. > > Please find and read draft-ietf-ipsp-spp-01.txt. > > I read: "An alternative approach would be to use raw IP with the RSVP > protocol numbers and a new RSVP version number." > This may also conserve/preserve silicon! > > I have a question from ignorance of deployed hardware: > Are RAO filters really available in production fast-path > silicon? I know that > some silicon vendors can cope, because they are > programmable/configurable, > but what about those that aren't? > > In the NAT-FW document, it says: > 3.2 > "Discovering security gateways, which was also mentioned as an > application for NSIS signaling, for the purpose of > executing an IKE > to create an IPsec SA, is already solved without requiring NSIS." > > really? I didn't know that it was solved. Do tell! > > The QoS and NAT-FW document is clearly too preliminary for me > to be able to > evaluate whether or not the requirements or features of the > framework have > been satisfied by this protocol. In particular, no statements > are made about > the trust relationships, or who may edit what mutable fields, > etc. I was > hoping that there might be enough meat here to saw whether or not the > framework requirement were useful/complete. > > OTHER: > are there really RMF's capable of managing the resources for all > paths through a network? I thought that the ATM folks > tried to do > this and failed, and this was one of the reasons that ATM didn't > get the deployment that was originally envisioned? > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Xelerance Corporation, Ottawa, ON > |net architect[ > ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQCbyqoqHRg3pndX9AQFR/AQAsIXy5Ekd75e9BAWMqX1DdxeZKICdI8fi 2+SX3nd34LzTMI5kTsBtCm5Pohl2Gn0B8s3jFkIeZ5qClCZp/Q7yEqz0+52vjJoJ vwPNNvbJM31bpdY8hlY4ajA9OkNlYCfnexfoMr6G6I0hqpHlwnpDCs+ykK9d8M19 pu0UFTKR09A= =nK5K -----END PGP SIGNATURE----- _______________________________________________ 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 exim@www1.ietf.org Tue Feb 10 05:13:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10010 for ; Tue, 10 Feb 2004 05:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUtA-0005zL-C8 for nsis-archive@odin.ietf.org; Tue, 10 Feb 2004 05:13:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AAD7rp023003 for nsis-archive@odin.ietf.org; Tue, 10 Feb 2004 05:13:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUt7-0005ya-00; Tue, 10 Feb 2004 05:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUss-0005xk-3x for nsis@optimus.ietf.org; Tue, 10 Feb 2004 05:12:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10003 for ; Tue, 10 Feb 2004 05:12:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUso-000465-00 for nsis@ietf.org; Tue, 10 Feb 2004 05:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUrs-00041V-00 for nsis@ietf.org; Tue, 10 Feb 2004 05:11:49 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1AqUrQ-0003wM-00 for nsis@ietf.org; Tue, 10 Feb 2004 05:11:20 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.10/8.12.10/F1) with ESMTP id i1AAAoO3019600 for ; Tue, 10 Feb 2004 11:10:50 +0100 From: Michael Welzl To: nsis@ietf.org Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1076407698.4806.60.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 Feb 2004 11:08:19 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 () RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.39 at uibk.ac.at X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] FYI: impact of slow path processing 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 Dear all, I remember that there was a discussion here about the impact of slow path processing (related to Router Alert); therefore, you might be interested in our technical report "on the impact of ip option processing" at the following web site: http://www.welzl.at/research/projects/ip-options/index.html I will continue to update this site as our research progresses: a new, more exhaustive measurement study is ongoing, and we will be working on different types of measurements related to option processing in the future. Cheers, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 10 06:21:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11947 for ; Tue, 10 Feb 2004 06:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVwx-0001js-JK for nsis-archive@odin.ietf.org; Tue, 10 Feb 2004 06:21:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ABL7BD006669 for nsis-archive@odin.ietf.org; Tue, 10 Feb 2004 06:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVwr-0001ie-Et; Tue, 10 Feb 2004 06:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVwc-0001hq-35 for nsis@optimus.ietf.org; Tue, 10 Feb 2004 06:20:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11939 for ; Tue, 10 Feb 2004 06:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVwY-0002QY-00 for nsis@ietf.org; Tue, 10 Feb 2004 06:20:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVvb-0002MF-00 for nsis@ietf.org; Tue, 10 Feb 2004 06:19:44 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AqVuy-0002IA-00 for nsis@ietf.org; Tue, 10 Feb 2004 06:19:04 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1ABJ5223170 for ; Tue, 10 Feb 2004 12:19:05 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1ABJ4k12350 for ; Tue, 10 Feb 2004 12:19:04 +0100 (MET) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA25116 for ; Tue, 10 Feb 2004 12:18:27 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Feb 2004 12:19:03 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7BC8@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "Nsis (E-mail)" Date: Tue, 10 Feb 2004 12:19:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Controlled-load QoS model ID submitted to NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all,=20 yesterday I submitted the following ID to the nsis working group: Title: "A QoS Model for Signaling IntServ Controlled-Load Service with = NSIS" Author: Cornelia Kappler Until the ID is on the official IETF web pages you can download it = here: http://sigcomp.srmr.co.uk/~adm/draft-kappler-nsis-qosmodel-controlledloa= d-00.txt The ID presents a validation of QoS-NSLP by adapting an existing QoS = model, controlled-load service from IntServ, for signaling with = QoS-NSLP. It describes how to signal for controlled-load service with = QoS-NSLP, and clarifies the features necessary for a QoS model = description in QoS-NSLP.=20 I am looking forward to comments, Cornelia > -----Urspr=FCngliche Nachricht----- > Von: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] Im=20 > Auftrag von Georgios Karagiannis > Gesendet: Montag, 9. Februar 2004 11:10 > An: Nsis (E-mail) > Cc: john.loughney@nokia.com > Betreff: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS >=20 >=20 > Dear all >=20 > Last Friday we have submitted the following draft to the IETF (NSIS): > "RMD (Resource Management in Diffserv) QoS-NSLP model", > draft-bader-RMD-QoS-model-00.txt. >=20 > It will probably take some time to be announced. > Therefore, I am sending you the URL where > you, temporarily, can find it: >=20 http://wwwhome.cs.utwente.nl/~goering/draft-bader-RMD-QoS-model-00.txt This draft describes an edge-to-edge local QoS model, called Resource Management in Diffserv (RMD), which uses the stateless/reduced state operation mode of QoS-NSLP = protocol. The model provides scalability and uses simplified NSIS operation. The specification of this QoS model includes description of QSpec parameters, as well as how that information should be treated and interpreted in the = network. In that sense, this QoS model goes beyond the QoS-NSLP protocol level and describes underlying assumptions, conditions and appropriate provisioning mechanisms. If you have any comments or questions please reply to this e-mail (on the NSIS mailing list). Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 11 00:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19730 for ; Wed, 11 Feb 2004 00:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqn9L-0005Dd-SX for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 00:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B5h3o6020045 for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 00:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqn9J-0005Cm-I1; Wed, 11 Feb 2004 00:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqn92-00058K-Fz for nsis@optimus.ietf.org; Wed, 11 Feb 2004 00:42:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19664 for ; Wed, 11 Feb 2004 00:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqn8z-0005do-00 for nsis@ietf.org; Wed, 11 Feb 2004 00:42:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqn8A-0005WW-00 for nsis@ietf.org; Wed, 11 Feb 2004 00:41:50 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1Aqn7U-0005Oc-00 for nsis@ietf.org; Wed, 11 Feb 2004 00:41:09 -0500 Received: from ns.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3990F1F33F for ; Wed, 11 Feb 2004 14:40:38 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Wed, 11 Feb 2004 14:40:37 +0900 (KST) Received: from LocalHost (unknown [75.2.47.28]) by ns.sait.samsung.co.kr (Postfix) with SMTP id:696CF1F339 for ; Wed, 11 Feb 2004 14:40:37 +0900 (KST) From: "Sung Hyuck Lee" To: Subject: [NSIS] FYI: IETF Seoul meeting Date: Wed, 11 Feb 2004 14:40:37 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1076407698.4806.60.camel@lap10-c703.uibk.ac.at> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 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: base64 DQogSGkgYWxsLCANCg0KIElFVEYgU2VvdWwgbWVldGluZyBpcyBjb21pbmcgIC4uLg0KIEhvd2V2 ZXIsIElmIHlvdSBkaWQgbm90IG1ha2UgYW55IHJlc2VydmF0aW9uIGZvciBhY2NvbW1vZGF0aW9u IHlldCAoYWx0aG91Z2ggDQogeW91IGhhdmUgdXNlZCBOU0lTIHNpZ25hbGluZyBmb3IgaXQgOi0p KSwgcGxlYXNlIGxldCBtZSBrbm93LiBJIGNhbiBoZWxwIHRoZSANCiBmb2xrcyB3aG8gaGF2ZSBu b3QgZm91bmQgYSBhcHByb3ByaWF0ZSBob3RlbC4gDQoNCiBwLnMuIFRoaXMgbWFpbCBpcyBub3Qg YWQuDQoNCiBSZWdhcmRzLA0KDQogU3VuZy1IeXVjaw0KDQoNCiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KIG5zaXMgbWFpbGluZyBsaXN0DQogbnNpc0Bp ZXRmLm9yZw0KIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zaXMNCiAN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQog _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 11 00:49:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20140 for ; Wed, 11 Feb 2004 00:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnF7-0005vp-Su for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 00:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B5n1jX022780 for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 00:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnF7-0005un-7b; Wed, 11 Feb 2004 00:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnEi-0005kx-3l for nsis@optimus.ietf.org; Wed, 11 Feb 2004 00:48:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20085 for ; Wed, 11 Feb 2004 00:48:32 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqnEf-0006fx-00 for nsis@ietf.org; Wed, 11 Feb 2004 00:48:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqnD2-0006Ln-00 for nsis@ietf.org; Wed, 11 Feb 2004 00:46:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqnBq-000687-00 for nsis@ietf.org; Wed, 11 Feb 2004 00:45:38 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1B5jcq07192 for ; Wed, 11 Feb 2004 07:45:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 07:45:38 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 07:45:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2004 07:45:38 +0200 Message-ID: Thread-Topic: [NSIS] FYI: IETF Seoul meeting Thread-Index: AcPwYfcDXKkPdOTCTAOVf2yqkih8wgAAAqWA To: X-OriginalArrivalTime: 11 Feb 2004 05:45:38.0282 (UTC) FILETIME=[46DC74A0:01C3F062] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Agenda items 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: quoted-printable Hi all, Please send to me possible topics for the Seoul meeting. Include the=20 presenter's name, link to draft and amount of time needed. Our priority is to work on the existing WG drafts.=20 thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 11 17:25:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04036 for ; Wed, 11 Feb 2004 17:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2n3-0007Zr-6m for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 17:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMP5IW029126 for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 17:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2n1-0007Z7-Ei; Wed, 11 Feb 2004 17:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2me-0007Vy-C8 for nsis@optimus.ietf.org; Wed, 11 Feb 2004 17:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03950 for ; Wed, 11 Feb 2004 17:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2mb-0003SE-00 for nsis@ietf.org; Wed, 11 Feb 2004 17:24:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2le-0003Hy-00 for nsis@ietf.org; Wed, 11 Feb 2004 17:23:39 -0500 Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2ki-00034v-00 for nsis@ietf.org; Wed, 11 Feb 2004 17:22:40 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i1BM0rji007687 for ; Wed, 11 Feb 2004 17:22:10 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 401694950089016E for nsis@ietf.org; Wed, 11 Feb 2004 17:21:41 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2004 16:22:01 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0201F06B@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt Thread-Index: AcPw7FUEtsIHLyk6StS3/sUQTcdSEgAAIdlw From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: I-D ACTION:draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.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: , Content-Transfer-Encoding: quoted-printable Hi All, Please review and comment on 'NSIS Network Service Layer Protocol QoS = Signaling Proof-of-Concept' = http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-= concept-01.txt. This is a proposed NSIS NSLP QoS signaling model and = Qspec template, as described in 'NSLP for Quality-of-Service Signaling' = http://ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-01.txt. John Loughney suggested such proof-of-concept models in his posting to = the NSIS list on 19 November = http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03557.ht= ml: "One suggestion would be to take 1 or 2 existing QoS models and detail = them in a separate draft, as a sort of proof-of-concept for the QoS = NSLP. These documents could exist as individual submissions, but could = be considered by the WG." Also, in his 27 October posting = http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03427.ht= ml, John said: "My opinion about this is that there are already a number = of QoS models specified outside of the IETF, for example the ITU, 3GPP, = etc. I do not think it wise for the IETF to make there own QoS model, = but to allow consenting peers to use the QoS NSLP with particular QoS = models. I think one way to achieve this is to use IANA registries to = register QoS models, and the QoS NSLP to signal these." The proposed QoS signaling model is based on 3 ITU-T Recommendations on = QoS signaling: 1. [TRQ-QoS-SIG] "Signaling Requirements for IP-QoS," January 2004. 2. [Y.1541] "Network Performance Objectives for IP-Based Services," May = 2002. 3. [E.361] "QoS Routing Support for Interworking of QoS Service Classes = Across Routing Technologies," May 2003. These Recommendations are summarized in the draft. We welcome your comments, suggestions, and inputs on the draft.=20 Hopefully this work can also be discussed at IETF-59/Seoul. Thanks, Jerry Ash -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 11, 2004 3:50 PM Subject: I-D ACTION:draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : NSIS Network Service Layer Protocol QoS Signaling = Proof-of-Concept Author(s) : J. Ash Filename : draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt Pages : 0 Date : 2004-2-11 =09 This draft describes a proof-of-concept example of NSIS Signaling Layer=20 Protocol (NSLP) for signaling QoS reservations in the Internet. The=20 example is based on standardization work in the ITU-T of QoS signaling=20 requirements. The QoS-NSLP is independent of the underlying QoS=20 specification or architecture and provides support for different=20 reservation models. Together with the NSIS Transport Layer Protocol=20 (NTLP), the NSLP provides functionality similar to RSVP and extends it.=20 This draft provides a proof-of-concept example of the NSIS NSLP for QoS=20 signaling. The example is based on standardization work in the ITU-T on = QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in=20 terms of the QoS-signaling model and Qspec template given in the 'NSLP=20 for QoS Signaling' specification [QoS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-= concept-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 11 20:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16876 for ; Wed, 11 Feb 2004 20:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5UQ-0003R3-K8 for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 20:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C1I2wx013190 for nsis-archive@odin.ietf.org; Wed, 11 Feb 2004 20:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5UP-0003QB-57; Wed, 11 Feb 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5UG-0003Op-RL for nsis@optimus.ietf.org; Wed, 11 Feb 2004 20:17:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16819 for ; Wed, 11 Feb 2004 20:17:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5UE-0002sL-00 for nsis@ietf.org; Wed, 11 Feb 2004 20:17:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5TD-0002lq-00 for nsis@ietf.org; Wed, 11 Feb 2004 20:16:48 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5SR-0002ai-00 for nsis@ietf.org; Wed, 11 Feb 2004 20:15:59 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.10/8.12.10) with ESMTP id i1C17Dum000715 for ; Thu, 12 Feb 2004 09:07:22 +0800 (SGT) From: "Cheng Hong" To: Date: Thu, 12 Feb 2004 09:15:13 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <015f01c3f105$ae054fa0$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0160_01C3F148.BC288FA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] FW: I-D ACTION:draft-cheng-mobility-issues-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: , This is a multi-part message in MIME format. ------=_NextPart_000_0160_01C3F148.BC288FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find below a draft we submitted regarding the mobility issues = related to QoS NSLP.=20 Best regards Cheng=20 -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, February 12, 2004 4:50 AM To: IETF-Announce: Subject: I-D ACTION:draft-cheng-mobility-issues-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility related issues for the QoS NSLP Author(s) : H. Cheng Filename : draft-cheng-mobility-issues-00.txt Pages : 10 Date : 2004-2-11 =09 The draft listed out some of the issues related to IP mobility that=20 may have impact on the design and implementation of the NSIS=20 protocols. These issues, namely, the multiple flow support and the=20 ping-pong type of movement, needs to be considered in the context of=20 the QoS NSLP protocol design, so that the NSIS framework would not=20 break when they present. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-mobility-issues-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-cheng-mobility-issues-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-cheng-mobility-issues-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0160_01C3F148.BC288FA0 Content-Type: Message/External-body; name="ATT00192.dat" Content-Disposition: attachment; filename="ATT00192.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-11160158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-mobility-issues-00.txt ------=_NextPart_000_0160_01C3F148.BC288FA0 Content-Type: Message/External-body; name="draft-cheng-mobility-issues-00.txt" Content-Disposition: attachment; filename="draft-cheng-mobility-issues-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-11160158.I-D@ietf.org> ------=_NextPart_000_0160_01C3F148.BC288FA0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 12 03:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13728 for ; Thu, 12 Feb 2004 03:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArC00-0007We-JY for nsis-archive@odin.ietf.org; Thu, 12 Feb 2004 03:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C8F4nY028918 for nsis-archive@odin.ietf.org; Thu, 12 Feb 2004 03:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBzx-0007Vz-Ha; Thu, 12 Feb 2004 03:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBzu-0007VX-Mz for nsis@optimus.ietf.org; Thu, 12 Feb 2004 03:14:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13695 for ; Thu, 12 Feb 2004 03:14:57 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBzs-0004zt-00 for nsis@ietf.org; Thu, 12 Feb 2004 03:14:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArByu-0004uV-00 for nsis@ietf.org; Thu, 12 Feb 2004 03:13:57 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArBxx-0004q9-00 for nsis@ietf.org; Thu, 12 Feb 2004 03:12:57 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1C8Csv05550 for ; Thu, 12 Feb 2004 10:12:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Feb 2004 10:12:50 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 10:12:52 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 10:12:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2004 10:12:50 +0200 Message-ID: Thread-Topic: 59th IETF - NSIS (2 sessions) Thread-Index: AcPvK43bWql+5YjvSGy5ywgml/lZ3wCFExjA To: X-OriginalArrivalTime: 12 Feb 2004 08:12:52.0570 (UTC) FILETIME=[02EB93A0:01C3F140] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: 59th IETF - NSIS (2 sessions) 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: quoted-printable Hi all, Here is the currently planned meeting times in Seoul. John > This is to confirm that NSIS is currently scheduled on: > Monday, March 1 at 1930-2200 >=20 > Other groups scheduled at that time are: > simple, mip4, hiprr, rmonmib, rtgarea >=20 > and >=20 > Tuesday, March 2 at 1300-1400 > Other groups scheduled at that time are: > webdav, l3vpn, dnsop _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 13 07:57:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07693 for ; Fri, 13 Feb 2004 07:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArcsQ-0002Ke-JY for nsis-archive@odin.ietf.org; Fri, 13 Feb 2004 07:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DCv2a2008949 for nsis-archive@odin.ietf.org; Fri, 13 Feb 2004 07:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArcsP-0002Jo-0R; Fri, 13 Feb 2004 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArcsO-0002Ja-9Y for nsis@optimus.ietf.org; Fri, 13 Feb 2004 07:57:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07674 for ; Fri, 13 Feb 2004 07:56:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArcsN-0005XK-00 for nsis@ietf.org; Fri, 13 Feb 2004 07:56:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArcrU-0005TZ-00 for nsis@ietf.org; Fri, 13 Feb 2004 07:56:05 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1Arcqz-0005Ot-00 for nsis@ietf.org; Fri, 13 Feb 2004 07:55:33 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1DCtVK00546 for ; Fri, 13 Feb 2004 13:55:31 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1DCtVV27344 for ; Fri, 13 Feb 2004 13:55:31 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Feb 2004 13:54:55 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D45@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Fri, 13 Feb 2004 13:55:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] NSIS weblog (blog) 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 all, i have created an nsis webpage. please take a look at: http://www.tschofenig.priv.at/cgi-bin/nsis.cgi the aim of this page is to allow ietf members to retrieve up-to-date nsis wg information. it should contain nsis related draft and paper announcements, presentations and press news. please feel free to send me postings or links to be included on the webpage. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 16 07:07:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13241 for ; Mon, 16 Feb 2004 07:07:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshWj-00008G-3N for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 07:07:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GC74kc000493 for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 07:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshWf-00006G-Nz; Mon, 16 Feb 2004 07:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshVx-0008PG-B2 for nsis@optimus.ietf.org; Mon, 16 Feb 2004 07:06:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13153 for ; Mon, 16 Feb 2004 07:06:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshVt-0006VW-00 for nsis@ietf.org; Mon, 16 Feb 2004 07:06:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshUz-0006S5-00 for nsis@ietf.org; Mon, 16 Feb 2004 07:05:18 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AshUX-0006Or-00 for nsis@ietf.org; Mon, 16 Feb 2004 07:04:49 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1GC4nR20250 for ; Mon, 16 Feb 2004 13:04:49 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1GC4nV21975 for ; Mon, 16 Feb 2004 13:04:49 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Feb 2004 13:04:12 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D78@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: nsis@ietf.org Date: Mon, 16 Feb 2004 13:04:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] QoS - NATFW Comparison 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 all, i compared the content of the QoS and the NATFW document to see where they differ and where not. Here is my conclusion: In the NATFW document we cannot find the following issues: - Sending a Query: We had some discussion about the usefulness of a query message but we decided that we don't need one. In QoS signaling it has a different meaning and more expressiveness. - Use of Local QoS Models: For NATFW signaling we couldn't find something similar. - Reduced State Interior Nodes: Same as above. - Session binding: So far we couldn't find use for this functionality. - Layering: Might not be applicable in the NATFW case. I furthermore found the following difference between the QoS and the NATFW document: - Signaling message handling: In the QoS NSLP a reserve message optionally creates a RESPONSE. In NATFW signaling a response message is always created. The NATFW document should add the following topics from the QoS (or from a related) document: - Message scoping: Although this issue is not covered in detail in the QoS document it should certainly be added to the NATFW document. - State timers: Both protocols use the soft-state principle and should therefore use similar mechanisms for refresh message handling. It is, however, not quite clear whether the NATFW document should also use peer-to-peer refresh messages. This issue is for further study. - Priority: There are two issues here: In concept of preemption for QoS reservations might not be immediately applicable to NATFW signaling. To have a higher priority for certain signaling messages might also be an issue for NATFW. The NSLP itself cannot provide much help except for indicating which message needs priority based handling. - Rerouting / Mobility handling: This issue is applicable to both documents. A separate ID was written to analyse mobility issues. - State storage: This section in the QoS NSLP draft only serves informational purposes. Still it would be useful to have such a section in the NATFW document. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 16 07:22:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13732 for ; Mon, 16 Feb 2004 07:22:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshlC-0001Li-H8 for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 07:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GCM2LV005171 for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 07:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshlC-0001LI-6y; Mon, 16 Feb 2004 07:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshkR-0001It-OG for nsis@optimus.ietf.org; Mon, 16 Feb 2004 07:21:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13708 for ; Mon, 16 Feb 2004 07:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshkR-0007YD-00 for nsis@ietf.org; Mon, 16 Feb 2004 07:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ashje-0007VZ-00 for nsis@ietf.org; Mon, 16 Feb 2004 07:20:27 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AshjF-0007Rr-00 for nsis@ietf.org; Mon, 16 Feb 2004 07:20:01 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1GCJxR06474 for ; Mon, 16 Feb 2004 13:20:00 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1GCJuV11949 for ; Mon, 16 Feb 2004 13:19:57 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Feb 2004 13:19:19 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D7B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Mon, 16 Feb 2004 13:19:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] NSIS NAT handling 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 all, in the past few weeks i have written a NSIS NAT handling summary. this document can be found at http://www.tschofenig.priv.at/drafts/NSIS-NAT-Handling.txt and might of interest to those who would like to understand the different places where NAT handling in NSIS has to be dealt with. i would like to thank cedric, miquel, marcus, martin and robert for their time discussing various topics in this document with me. comments are welcome. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 16 08:50:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17677 for ; Mon, 16 Feb 2004 08:50:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj8U-00076u-9E for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 08:50:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GDoAv7027309 for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 08:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj8T-00075X-Hn; Mon, 16 Feb 2004 08:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asj8E-00071a-T8 for nsis@optimus.ietf.org; Mon, 16 Feb 2004 08:49:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17593 for ; Mon, 16 Feb 2004 08:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asj8D-0004lt-00 for nsis@ietf.org; Mon, 16 Feb 2004 08:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asj7L-0004ep-00 for nsis@ietf.org; Mon, 16 Feb 2004 08:48:59 -0500 Received: from smtp3.libero.it ([193.70.192.127]) by ietf-mx with esmtp (Exim 4.12) id 1Asj6W-0004WB-00 for nsis@ietf.org; Mon, 16 Feb 2004 08:48:08 -0500 Received: from libero.it (193.70.192.38) by smtp3.libero.it (7.0.020-DD01) id 3F6F068F01211862 for nsis@ietf.org; Mon, 16 Feb 2004 14:47:36 +0100 Date: Mon, 16 Feb 2004 14:47:36 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "nsis" X-XaM3-API-Version: 4.1 (b23) X-type: 0 X-SenderIP: 193.204.86.168 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RSB and PSB 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: quoted-printable Hi All, I' ve a question for you! Why in NSIS Mailing List I haven't= read mail about lists like RSB and PSB (http://www.ietf.org/rfc/ rfc220= 9.txt) ? Many thanks for your replies, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 16 09:58:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21010 for ; Mon, 16 Feb 2004 09:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskC9-0004IJ-9a for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 09:58:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GEw1nS016497 for nsis-archive@odin.ietf.org; Mon, 16 Feb 2004 09:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskC8-0004Hs-Oz; Mon, 16 Feb 2004 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskBS-0004G7-Ud for nsis@optimus.ietf.org; Mon, 16 Feb 2004 09:57:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20924 for ; Mon, 16 Feb 2004 09:57:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AskBQ-0001SZ-00 for nsis@ietf.org; Mon, 16 Feb 2004 09:57:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskAT-0001Mk-00 for nsis@ietf.org; Mon, 16 Feb 2004 09:56:18 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1Ask9X-0001F1-00 for nsis@ietf.org; Mon, 16 Feb 2004 09:55:19 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMHSZQ>; Mon, 16 Feb 2004 14:54:48 -0000 Message-ID: From: "Hancock, Robert" To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] RSB and PSB Date: Mon, 16 Feb 2004 14:54:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Elena, 2209 and RSB/PSB are about details of RSVP message processing. The NSIS work is not modifying the original RSVP specification. The current protocol work will (undoubtably) go into similar details about message processing rules and data structures (although it hasn't quite got there yet); however, it isn't clear how closely these will map onto the RSVP structure, at least in part because the NSIS protocol suite architecture is somewhat different from the RSVP protocol architecture. Hope this helps. Robert H. > -----Original Message----- > From: Elena Scialpi [mailto:scel@inwind.it] > Sent: Monday, February 16, 2004 13:48 > To: nsis > Subject: [NSIS] RSB and PSB > > > Hi All, > > I' ve a question for you! > Why in NSIS Mailing List I haven't read mail about lists like > RSB and PSB (http://www.ietf.org/rfc/ > rfc2209.txt) ? > > > Many thanks for your replies, > Elena > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 17 05:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22834 for ; Tue, 17 Feb 2004 05:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2hu-0006iS-Fq for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 05:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HAi2bF025801 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 05:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2hs-0006hb-TG; Tue, 17 Feb 2004 05:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2h0-0006gi-72 for nsis@optimus.ietf.org; Tue, 17 Feb 2004 05:43:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22807 for ; Tue, 17 Feb 2004 05:43:02 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At2gw-0004Zc-00 for nsis@ietf.org; Tue, 17 Feb 2004 05:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At2fw-0004Wh-00 for nsis@ietf.org; Tue, 17 Feb 2004 05:42:01 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1At2fP-0004Tl-00 for nsis@ietf.org; Tue, 17 Feb 2004 05:41:28 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1HAfHes027047; Tue, 17 Feb 2004 11:41:18 +0100 To: hcheng@psl.com.sg, khling@psl.com.sg Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 17 Feb 2004 11:41:15 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/17/2004 11:41:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP 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, I have gone through your draft. If I understand correctly, the issues you raise are: - the need for the QoS NSLP to support a change of FlowID for the same sessionID (e.g. multi-homing) - the need to deal intelligently with very frequent (ping-pong) mobility events I agree with the need for both types of functionality, but I don't think the impact on QoS NSLP is very large. From what you propose in the draft, the current version of the QoS NSLP (draft-ietf-nsis-qos-nslp-02.txt) supports: - ability to reserve zero resources - ability to retain/remove state on the old path: supported in QoS NSLP (with SII) but the decision to keep state is a policy issue at the QNE, not indicated by MN What you propose that is currently not there: - MN indication of desire to maintain old path state. We could do this via a flag in the header which is minimal impact but I am concerned about: 1. security: can be solved by making support optional and leave the QNE the freedom to disregard it 2. relation to charging, ...: if it is just an indication, not mandatory, who will be charged for maintaining the reservation Have you thought about these issues? Best regards, Sven Van den Bosch _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 08:17:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27025 for ; Tue, 17 Feb 2004 08:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At561-00073n-Ag for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 08:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HDH5pY027124 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 08:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At55x-000732-J4; Tue, 17 Feb 2004 08:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At551-000724-KY for nsis@optimus.ietf.org; Tue, 17 Feb 2004 08:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26984 for ; Tue, 17 Feb 2004 08:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At550-0005uu-00 for nsis@ietf.org; Tue, 17 Feb 2004 08:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At547-0005qY-00 for nsis@ietf.org; Tue, 17 Feb 2004 08:15:08 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1At53A-0005hx-00 for nsis@ietf.org; Tue, 17 Feb 2004 08:14:08 -0500 Received: from pcluu (dhcp192-215.enst.fr [137.194.192.215]) by infres.enst.fr (Postfix) with SMTP id 6E4232F85 for ; Tue, 17 Feb 2004 14:14:06 +0100 (MET) Message-ID: <009301c3f557$f56e1ce0$d7c0c289@enst.fr> From: "Thanh Tra LUU" To: Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 14:14:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C3F560.57189440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C3F560.57189440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi Attila, i've read your draft. i see it as the continuation of rmd model, an one = of many models that qos-nslp can support. i find it very interesting and i = have some questions to understand better your model. 1. How to translate a resource request into resource units request? The translation ensures all qos parameters of the original request ? (e.g. delay) 2. There is a timer for each reservation per flow in interior nodes , so = an interior node charge will linearly increase following the number of per = flow sessions? 3. In the last paragraph of 2(protocol model), 'they are not able to establish and maintain security associations with their neighbors, which means, they can only be applied in a trusted domain'. The stateless does = not mean no security association. In rsvp, the sa is not specified how it = can create (maybe by ike, manual) and which node is the next rsvp-aware = node. 4. you didn't introduce what TIME_VALUES object is. Just because i'd = like to know it more clearly. 5. an interior node can be an edge node of other flows ? 6. it seems that an ingress node must know the egress node before making = the local reservation. Can it be done at the same time ? tell me the reason = why you don't integrate the e2e reservation and local reservation in a same message. I might see the reason in rfc3175, but it's not the answer in = your case. thanks & regards Nary Tra, ENST, Paris ------=_NextPart_000_0090_01C3F560.57189440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi =20 Attila,

i've read your draft. i see it as the continuation of rmd = model,=20 an one of
many models that qos-nslp can support. i find it very = interesting=20 and i have
some questions to understand better your model.

1. = How to=20 translate a resource request into resource units request? = The
translation=20 ensures all qos parameters of the original request ? =20 (e.g.
delay)

2. There is a timer for each reservation per flow = in=20 interior nodes , so an
interior node charge will linearly increase = following=20 the number of per flow
sessions?

3. In the last paragraph of=20 2(protocol model), 'they are not able to
establish and maintain = security=20 associations with their neighbors, which
means, they can only be = applied in a=20 trusted domain'. The stateless does not
mean no security = association. =20 In rsvp, the sa is not specified how it can
create (maybe by ike, = manual) and=20 which node is the next rsvp-aware node.

4. you didn't introduce = what=20 TIME_VALUES object is. Just because i'd like to
know it more=20 clearly.

5. an interior node can be an edge node of other flows=20 ?

6. it seems that an ingress node must know the egress node = before=20 making the
local reservation. Can it be done at the same time ? tell = me the=20 reason why
you don't integrate the e2e reservation and local = reservation in a=20 same
message. I might see the reason in rfc3175, but it's not the = answer in=20 your
case.

thanks & regards

Nary Tra,
ENST,=20 Paris
------=_NextPart_000_0090_01C3F560.57189440-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 09:11:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28889 for ; Tue, 17 Feb 2004 09:11:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5wF-0002WR-P6 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEB3Vo009675 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5wF-0002Vs-8i; Tue, 17 Feb 2004 09:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5vQ-0002U4-G1 for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:10:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28857 for ; Tue, 17 Feb 2004 09:10:10 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5vO-0001lM-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5uZ-0001hz-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:09:20 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1At5u5-0001dj-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:08:50 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HE8mT01964; Tue, 17 Feb 2004 16:08:48 +0200 (EET) X-Scanned: Tue, 17 Feb 2004 16:08:19 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1HE8JKN028352; Tue, 17 Feb 2004 16:08:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00BPoVCx; Tue, 17 Feb 2004 16:08:18 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HDnp727950; Tue, 17 Feb 2004 15:49:51 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 15:49:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:49:36 +0200 Message-ID: Thread-Topic: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Thread-Index: AcP1WGbIOhtFRbeDSuGMqDzcAsTvkgAA77lg To: , X-OriginalArrivalTime: 17 Feb 2004 13:49:49.0557 (UTC) FILETIME=[E93FBA50:01C3F55C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Attila, Nary Tra's email also raised a question in my mind: > 3. In the last paragraph of 2(protocol model), 'they are not able to > establish and maintain security associations with their neighbors, = which > means, they can only be applied in a trusted domain'. The stateless = does not > mean no security association. In rsvp, the sa is not specified how it = can > create (maybe by ike, manual) and which node is the next rsvp-aware = node. In an IESG review of a SIGTRAN document of mine, the IESG (specifically the Security Area Director) said that the IESG will not standardize=20 anything with the 'trusted domain' concept. The Security AD commented that compromised nodes in a 'trusted network' have caused far more serious problems than is always documented. For example, a disgruntled employee with a key to the server room can do a lot of hacking. With = this in my mind, I think that you will have to rethink this part of your draft. You need to be able to provide a mechansims of how neighbors can establish & maintain security associations. This does not mean that a security association always must be used, but the the possibility for creating a security association is mandatory, in my opinion. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 09:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29746 for ; Tue, 17 Feb 2004 09:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Fe-0003s8-46 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEV6fM014883 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Fc-0003qs-LP; Tue, 17 Feb 2004 09:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Ej-0003pM-Ag for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:30:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29700 for ; Tue, 17 Feb 2004 09:30:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6Eh-00036B-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:30:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6Dn-00033U-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:29:12 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1At6DN-0002zp-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:28:45 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMH7FW>; Tue, 17 Feb 2004 14:28:07 -0000 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 14:28:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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. so far as i can tell, (it's certainly what is in my head), it could probably be made a MUST for GIMPS implementations that it should be possible to configure a node policy that - no NSLP data is carried in datagram mode; - connection mode must be secured. in the case that the QoS-NSLP is prepared to rely entirely on GIMPS for its security services (*which is of course an issue for discussion at the moment*), this would therefore seem to address the concern below, at least partially. [of course, the node would no longer have the performance/ scalability properties that some people apparently desire, because of the GIMPS behaviour when this type of policy is in place; however, the NSLP behaviour would not need to be redefined.] robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, February 17, 2004 14:50 > To: luu@enst.fr; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > Hi Attila, > > Nary Tra's email also raised a question in my mind: > > > 3. In the last paragraph of 2(protocol model), 'they are not able to > > establish and maintain security associations with their > neighbors, which > > means, they can only be applied in a trusted domain'. The > stateless does not > > mean no security association. In rsvp, the sa is not > specified how it can > > create (maybe by ike, manual) and which node is the next > rsvp-aware node. > > In an IESG review of a SIGTRAN document of mine, the IESG > (specifically > the Security Area Director) said that the IESG will not standardize > anything with the 'trusted domain' concept. The Security AD commented > that compromised nodes in a 'trusted network' have caused far more > serious problems than is always documented. For example, a > disgruntled > employee with a key to the server room can do a lot of > hacking. With this > in my mind, I think that you will have to rethink this part of your > draft. You need to be able to provide a mechansims of how neighbors > can establish & maintain security associations. This does not mean > that a security association always must be used, but the the > possibility > for creating a security association is mandatory, in my opinion. > > thanks, > 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 exim@www1.ietf.org Tue Feb 17 09:39:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00150 for ; Tue, 17 Feb 2004 09:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6NK-0004t4-3b for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEd2dJ018769 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6NJ-0004sV-H2; Tue, 17 Feb 2004 09:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6MV-0004nt-IN for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00095 for ; Tue, 17 Feb 2004 09:38:08 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6MT-0003j4-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6Lb-0003g1-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:37:16 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1At6LA-0003cJ-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:36:48 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1HEaGes012843; Tue, 17 Feb 2004 15:36:17 +0100 Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS To: "Hancock, Robert" Cc: "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 17 Feb 2004 15:36:10 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/17/2004 15:36:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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, Please see inline. Sven "Hancock, Robert" @ietf.org on 17/02/2004 15:28:13 Sent by: nsis-admin@ietf.org To: "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org cc: Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS hi. so far as i can tell, (it's certainly what is in my head), it could probably be made a MUST for GIMPS implementations that it should be possible to configure a node policy that - no NSLP data is carried in datagram mode; - connection mode must be secured. in the case that the QoS-NSLP is prepared to rely entirely on GIMPS for its security services (*which is of course an issue for discussion at the moment*), this would therefore seem to address the concern below, at least partially. Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its security services but GIMPS alone is not sufficient because it does not protect against compromised QNEs, only against their interconnection. [of course, the node would no longer have the performance/ scalability properties that some people apparently desire, because of the GIMPS behaviour when this type of policy is in place; however, the NSLP behaviour would not need to be redefined.] robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, February 17, 2004 14:50 > To: luu@enst.fr; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > Hi Attila, > > Nary Tra's email also raised a question in my mind: > > > 3. In the last paragraph of 2(protocol model), 'they are not able to > > establish and maintain security associations with their > neighbors, which > > means, they can only be applied in a trusted domain'. The > stateless does not > > mean no security association. In rsvp, the sa is not > specified how it can > > create (maybe by ike, manual) and which node is the next > rsvp-aware node. > > In an IESG review of a SIGTRAN document of mine, the IESG > (specifically > the Security Area Director) said that the IESG will not standardize > anything with the 'trusted domain' concept. The Security AD commented > that compromised nodes in a 'trusted network' have caused far more > serious problems than is always documented. For example, a > disgruntled > employee with a key to the server room can do a lot of > hacking. With this > in my mind, I think that you will have to rethink this part of your > draft. You need to be able to provide a mechansims of how neighbors > can establish & maintain security associations. This does not mean > that a security association always must be used, but the the > possibility > for creating a security association is mandatory, in my opinion. > > thanks, > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 09:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00334 for ; Tue, 17 Feb 2004 09:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6TA-0005Ns-Ns for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEj4iH020681 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6T7-0005Mk-FK; Tue, 17 Feb 2004 09:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6SG-0005GO-14 for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:44:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00307 for ; Tue, 17 Feb 2004 09:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6SE-00043F-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:44:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6RK-00040J-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:43:10 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1At6Qh-0003uA-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:42:31 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMH7KS>; Tue, 17 Feb 2004 14:41:58 -0000 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" Cc: "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 14:42:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 sven, [snip] > > in the case that the QoS-NSLP is prepared to rely entirely > on GIMPS for its security services (*which is of course an > issue for discussion at the moment*), this would therefore > seem to address the concern below, at least partially. > > Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > security services but GIMPS alone is not sufficient because > it does not > protect against compromised QNEs, only against their interconnection. > fair enough. but protecting against a compromised QNE is a much harder topic (and not the focus of John's comment, AFAICT). if someone can compromise the QNE they can probably legitimately request practically anything from the neighbours. securing against this sort of attack is much more a matter of making sure that damage does not propagate, operating gracefully under overload conditions, and so on. r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 09:52:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00587 for ; Tue, 17 Feb 2004 09:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Zt-0005l0-7q for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:52:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEq1u5022115 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Zs-0005kX-OI; Tue, 17 Feb 2004 09:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6Z8-0005jT-EL for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:51:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00546 for ; Tue, 17 Feb 2004 09:51:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6Z6-0004bt-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:51:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6YC-0004Xp-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:50:17 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1At6Xf-0004UG-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:49:43 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i1HEncCi001387; Tue, 17 Feb 2004 15:49:38 +0100 (MET) Message-ID: <010601c3f565$45bc5ba0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , References: Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:49:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 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 > > In an IESG review of a SIGTRAN document of mine, the IESG (specifically > the Security Area Director) said that the IESG will not standardize > anything with the 'trusted domain' concept. The Security AD commented > that compromised nodes in a 'trusted network' have caused far more > serious problems than is always documented. For example, a disgruntled > employee with a key to the server room can do a lot of hacking. With this > in my mind, I think that you will have to rethink this part of your > draft. You need to be able to provide a mechansims of how neighbors > can establish & maintain security associations. This does not mean > that a security association always must be used, but the the possibility > for creating a security association is mandatory, in my opinion. The RMD QoS-NSLP model draft is just specifying a QoS model that can be used in combination with the QoS-NSLP protocol. The QoS-NSLP protocol, independently of the used QoS model, should be able to establishsh & maintain security associations between certain neighbours (e.g., edge nodes) in such a way that the end to end security association will not brake. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 09:56:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00736 for ; Tue, 17 Feb 2004 09:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6dm-00066R-V3 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEu2uM023443 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6dm-00065U-25; Tue, 17 Feb 2004 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6cv-0005zh-TC for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:55:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00659 for ; Tue, 17 Feb 2004 09:55:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6ct-0004wT-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6c4-0004so-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:54:17 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6bF-0004oq-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:53:25 -0500 Received: from pcluu (dhcp192-215.enst.fr [137.194.192.215]) by infres.enst.fr (Postfix) with SMTP id AAEC93125 for ; Tue, 17 Feb 2004 15:53:20 +0100 (MET) Message-ID: <00c401c3f565$cf64d620$d7c0c289@enst.fr> From: "Thanh Tra LUU" To: References: Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:53:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Sven, > Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > security services but GIMPS alone is not sufficient because it does not > protect against compromised QNEs, only against their interconnection. do you mean QoS-NSLP would support authentication policy elements (as rsvp) and NTLP would support integrity elements (in rsvp) or QoS-NSLP may do all in some cases ? Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 09:56:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00753 for ; Tue, 17 Feb 2004 09:56:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6dn-00067b-PC for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HEu3cU023488 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 09:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6dn-00066j-F9; Tue, 17 Feb 2004 09:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6d3-00061X-C6 for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00666 for ; Tue, 17 Feb 2004 09:55:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6d1-0004xX-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:55:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6c8-0004tV-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:54:21 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1At6bV-0004pR-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:53:41 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1HErcR29161; Tue, 17 Feb 2004 15:53:38 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1HErcV23396; Tue, 17 Feb 2004 15:53:38 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 15:53:01 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D92@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:53:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, thanks for raising this issue. it would be important to state very clearly that some signaling messages in gimps cannot be secured (or at least with some degree of difficulty). i have proposed this addition. (i was actually surprised that michael richardson did not mention anything along these lines in his comments.) relying on gimps to provide security for the upper layer is, per default, not a bad thing for some scenarios but some additional assumptions need to be spelled out (as robert said). i also agree that the concept of a 'trusted domain' (as pointed out by Nary Tra's mail) cannot be a justification for not providing security. mechanisms need to be in place to allow protection of signaling messages. hence it would be good to find some use cases for signaling applications which need NO security protection. ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, February 17, 2004 3:28 PM > To: 'john.loughney@nokia.com'; luu@enst.fr; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi. > > so far as i can tell, (it's certainly what is in my head), > it could probably be made a MUST for GIMPS implementations > that it should be possible to configure a node policy that > > - no NSLP data is carried in datagram mode; > - connection mode must be secured. > > in the case that the QoS-NSLP is prepared to rely entirely > on GIMPS for its security services (*which is of course an > issue for discussion at the moment*), this would therefore > seem to address the concern below, at least partially. > > [of course, the node would no longer have the performance/ > scalability properties that some people apparently desire, > because of the GIMPS behaviour when this type of policy is > in place; however, the NSLP behaviour would not need to be > redefined.] > > robert h. > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Tuesday, February 17, 2004 14:50 > > To: luu@enst.fr; nsis@ietf.org > > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > > > > Hi Attila, > > > > Nary Tra's email also raised a question in my mind: > > > > > 3. In the last paragraph of 2(protocol model), 'they are > not able to > > > establish and maintain security associations with their > > neighbors, which > > > means, they can only be applied in a trusted domain'. The > > stateless does not > > > mean no security association. In rsvp, the sa is not > > specified how it can > > > create (maybe by ike, manual) and which node is the next > > rsvp-aware node. > > > > In an IESG review of a SIGTRAN document of mine, the IESG > > (specifically > > the Security Area Director) said that the IESG will not standardize > > anything with the 'trusted domain' concept. The Security > AD commented > > that compromised nodes in a 'trusted network' have caused far more > > serious problems than is always documented. For example, a > > disgruntled > > employee with a key to the server room can do a lot of > > hacking. With this > > in my mind, I think that you will have to rethink this part of your > > draft. You need to be able to provide a mechansims of how neighbors > > can establish & maintain security associations. This does not mean > > that a security association always must be used, but the the > > possibility > > for creating a security association is mandatory, in my opinion. > > > > thanks, > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 10:00:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01087 for ; Tue, 17 Feb 2004 10:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6hg-0006g8-Dc for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:00:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF02gZ025491 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6hd-0006d3-Fa; Tue, 17 Feb 2004 10:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6gr-0006bK-D7 for nsis@optimus.ietf.org; Tue, 17 Feb 2004 09:59:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00996 for ; Tue, 17 Feb 2004 09:59:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6gp-0005Fx-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:59:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6fx-0005Bg-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:58:18 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1At6fD-00057n-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:57:32 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1HEvUt23707; Tue, 17 Feb 2004 15:57:30 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1HEvTV28509; Tue, 17 Feb 2004 15:57:29 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 15:56:52 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D93@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'sven.van_den_bosch@alcatel.be'" Cc: "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:57:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, a discussion of mechanisms to prevent compromised intermediate nodes can also be found in the "rsvp security properties" draft. some people proposed mechanisms but they have never reached the standardization (i guess) since you can do a number of things at a compromised node other than "only" changing qos signaling messages ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, February 17, 2004 3:42 PM > To: 'sven.van_den_bosch@alcatel.be' > Cc: 'john.loughney@nokia.com'; luu@enst.fr; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi sven, > > [snip] > > > > in the case that the QoS-NSLP is prepared to rely entirely > > on GIMPS for its security services (*which is of course an > > issue for discussion at the moment*), this would therefore > > seem to address the concern below, at least partially. > > > > Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > > security services but GIMPS alone is not sufficient because > > it does not > > protect against compromised QNEs, only against their > interconnection. > > > > fair enough. but protecting against a compromised QNE is a > much harder topic (and not the focus of John's comment, AFAICT). > if someone can compromise the QNE they can probably legitimately > request practically anything from the neighbours. securing > against this sort of attack is much more a matter of making > sure that damage does not propagate, operating gracefully under > overload conditions, and so on. > > r. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 10:02:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01205 for ; Tue, 17 Feb 2004 10:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6jZ-000886-JH for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:02:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF2169031197 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6jZ-000873-6l; Tue, 17 Feb 2004 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6it-0007bs-QA for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:01:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01151 for ; Tue, 17 Feb 2004 10:01:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6ir-0005RB-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:01:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6i0-0005Md-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:00:24 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1At6hT-0005Hr-00 for nsis@ietf.org; Tue, 17 Feb 2004 09:59:51 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1HExnQ11499; Tue, 17 Feb 2004 15:59:49 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1HExmV01380; Tue, 17 Feb 2004 15:59:48 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 15:59:11 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D94@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:59:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Nary Tra, you might want to take a look at the latest qos nslp draft. we have included a description in there which might help. please see http://www.tschofenig.priv.at/cgi-bin/nsis.cgi ciao hannes > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Tuesday, February 17, 2004 3:53 PM > To: nsis@ietf.org > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi Sven, > > > Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > > security services but GIMPS alone is not sufficient because > it does not > > protect against compromised QNEs, only against their > interconnection. > > do you mean QoS-NSLP would support authentication policy > elements (as rsvp) > and NTLP would support integrity elements (in rsvp) or > QoS-NSLP may do all > in some cases ? > > Nary Tra, > ENST, Paris. > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 17 10:03:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01264 for ; Tue, 17 Feb 2004 10:03:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6kY-0000cM-33 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:03:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF31gM002264 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6kX-0000a6-BV; Tue, 17 Feb 2004 10:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6k3-00008e-7W for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:02:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01201 for ; Tue, 17 Feb 2004 10:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6k1-0005ZH-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:02:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6iu-0005RZ-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:01:21 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1At6iA-0005Mv-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:00:35 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1HF0WqY009188 for ; Tue, 17 Feb 2004 16:00:33 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Feb 2004 16:00:32 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJ2KALN>; Tue, 17 Feb 2004 16:01:50 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: john.loughney@nokia.com, luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 16:04:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Feb 2004 15:00:32.0842 (UTC) FILETIME=[CA71A2A0:01C3F566] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, Probably this is not good news for us, in our concept edge nodes should be treated as nodes responsible for security and interior nodes are hidden from outside. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, February 17, 2004 2:50 PM > To: luu@enst.fr; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > Hi Attila, > > Nary Tra's email also raised a question in my mind: > > > 3. In the last paragraph of 2(protocol model), 'they are not able to > > establish and maintain security associations with their > neighbors, which > > means, they can only be applied in a trusted domain'. The > stateless does not > > mean no security association. In rsvp, the sa is not > specified how it can > > create (maybe by ike, manual) and which node is the next > rsvp-aware node. > > In an IESG review of a SIGTRAN document of mine, the IESG > (specifically > the Security Area Director) said that the IESG will not standardize > anything with the 'trusted domain' concept. The Security AD commented > that compromised nodes in a 'trusted network' have caused far more > serious problems than is always documented. For example, a > disgruntled > employee with a key to the server room can do a lot of > hacking. With this > in my mind, I think that you will have to rethink this part of your > draft. You need to be able to provide a mechansims of how neighbors > can establish & maintain security associations. This does not mean > that a security association always must be used, but the the > possibility > for creating a security association is mandatory, in my opinion. > > thanks, > John > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 10:05:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01617 for ; Tue, 17 Feb 2004 10:05:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6mV-0001gR-UO for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:05:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF53Bj006395 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6mT-0001ej-Pw; Tue, 17 Feb 2004 10:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6lb-0001NJ-Cx for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:04:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01351 for ; Tue, 17 Feb 2004 10:04:04 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6lZ-0005nl-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:04:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6k0-0005Z7-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:02:28 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1At6iu-0005RT-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:01:20 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1HF1Ges012726; Tue, 17 Feb 2004 16:01:16 +0100 Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS To: "Thanh Tra LUU" Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 17 Feb 2004 16:01:06 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/17/2004 16:01:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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 Nary, QoS NSLP has POLICY_DATA in its current version of the spec. Even if GIMPS provides integrity, I am not sure it is unneeded in QoS NSLP (e.g. if QoS NSLP is carrying information that is opaque for (some) intermediate nodes). Sven "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 Sent by: nsis-admin@ietf.org To: cc: Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS hi Sven, > Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > security services but GIMPS alone is not sufficient because it does not > protect against compromised QNEs, only against their interconnection. do you mean QoS-NSLP would support authentication policy elements (as rsvp) and NTLP would support integrity elements (in rsvp) or QoS-NSLP may do all in some cases ? Nary Tra, ENST, Paris. _______________________________________________ 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 exim@www1.ietf.org Tue Feb 17 10:09:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02257 for ; Tue, 17 Feb 2004 10:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6qN-00038d-DG for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:09:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF93gf012024 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6qM-00037p-KR; Tue, 17 Feb 2004 10:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6pe-0002ym-Vs for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:08:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02112 for ; Tue, 17 Feb 2004 10:08:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6pc-0006NJ-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6or-0006JA-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:07:30 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1At6oF-0006Dl-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:06:52 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1HF6pt04598; Tue, 17 Feb 2004 16:06:51 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1HF6oV10846; Tue, 17 Feb 2004 16:06:50 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 16:06:13 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D98@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'sven.van_den_bosch@alcatel.be'" , Thanh Tra LUU Cc: nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 16:06:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 sven, the policy object is certainly needed in some scenarios. ciao hannes > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, February 17, 2004 4:01 PM > To: Thanh Tra LUU > Cc: nsis@ietf.org > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > Hi Nary, > > QoS NSLP has POLICY_DATA in its current version of the spec. > Even if GIMPS > provides integrity, I am not sure it is unneeded in QoS NSLP > (e.g. if QoS > NSLP is carrying information that is opaque for (some) > intermediate nodes). > > Sven > > > > > > > "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 > > Sent by: nsis-admin@ietf.org > > > To: > cc: > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi Sven, > > > Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > > security services but GIMPS alone is not sufficient because > it does not > > protect against compromised QNEs, only against their > interconnection. > > do you mean QoS-NSLP would support authentication policy > elements (as rsvp) > and NTLP would support integrity elements (in rsvp) or > QoS-NSLP may do all > in some cases ? > > Nary Tra, > ENST, Paris. > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 17 10:33:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05080 for ; Tue, 17 Feb 2004 10:33:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Da-0000VB-PO for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:33:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFX2Ii001921 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7DZ-0000Uo-SE; Tue, 17 Feb 2004 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Cl-0000P9-VT for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:32:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04779 for ; Tue, 17 Feb 2004 10:32:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Cj-0000gt-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:32:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Br-0000da-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:31:15 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1At7BW-0000a4-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:30:54 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1HFUGID018191; Tue, 17 Feb 2004 16:30:16 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004021716301470:5036 ; Tue, 17 Feb 2004 16:30:14 +0100 Message-ID: <40323387.1040303@alcatel.fr> Date: Tue, 17 Feb 2004 16:30:15 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: sven.van_den_bosch@alcatel.be Cc: Thanh Tra LUU , nsis@ietf.org Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/17/2004 16:30:14, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/17/2004 16:30:15, Serialize complete at 02/17/2004 16:30:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 nary, QoS-NSLP POLICY_DATA object carries policy elements for authorization purposes between two policy-capable nodes. like what was done in RSVP. how far QoS-NSLP relies on NTLP for the so-called integrity objects (RSVP terminology) is the issue. yacine sven.van_den_bosch@alcatel.be wrote: > Hi Nary, > > QoS NSLP has POLICY_DATA in its current version of the spec. Even if GIMPS > provides integrity, I am not sure it is unneeded in QoS NSLP (e.g. if QoS > NSLP is carrying information that is opaque for (some) intermediate nodes). > > Sven > > > > > > > "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 > > Sent by: nsis-admin@ietf.org > > > To: > cc: > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi Sven, > > >>Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its >>security services but GIMPS alone is not sufficient because it does not >>protect against compromised QNEs, only against their interconnection. > > > do you mean QoS-NSLP would support authentication policy elements (as rsvp) > and NTLP would support integrity elements (in rsvp) or QoS-NSLP may do all > in some cases ? > > Nary Tra, > ENST, Paris. > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 17 10:36:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05722 for ; Tue, 17 Feb 2004 10:36:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7GV-00012k-4N for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFa3Yx003977 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7GU-000120-PS; Tue, 17 Feb 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Fi-0000xQ-GE for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:35:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05446 for ; Tue, 17 Feb 2004 10:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Fg-0000wN-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:35:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Eo-0000ro-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:34:19 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1At7E6-0000jc-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:33:34 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMH762>; Tue, 17 Feb 2004 15:33:00 -0000 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:33:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, just in case there is any unclarity: > thanks for raising this issue. it would be important to state > very clearly > that some signaling messages in gimps cannot be secured (or > at least with > some degree of difficulty). the version -00 draft (basically unchanged in -01) states: on page 5 "Datagram mode: A mode of sending GIMPS messages between nodes without using any transport layer state or security protection." and on page 6 "Here, with details discussed later, "easy" messages are those that [...] do not need transport or network-layer security support." and on page 7 "The datagram mode uses a lower-layer unreliable unsecured datagram transport mechanism, with UDP as the initial choice." and on page 14 "The main decision is whether the message must be sent in connection mode or datagram mode. Reasons for using the former could be: * NSLP requirements: for example, the signaling application has requested channel secured delivery, or reliable delivery;" and so on. if people think this needs to be emphasised more clearly, please let me know. r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 10:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07325 for ; Tue, 17 Feb 2004 10:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7PD-0003JC-BT for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFj31H012701 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7PC-0003Ib-4G; Tue, 17 Feb 2004 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7OD-0003GR-KD for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06874 for ; Tue, 17 Feb 2004 10:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7OB-00027r-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7M9-0001hs-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:41:53 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1At7KV-0001PG-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:40:11 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1HFe8Q19688; Tue, 17 Feb 2004 16:40:09 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1HFe7V18337; Tue, 17 Feb 2004 16:40:07 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 16:39:30 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D9C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'john.loughney@nokia.com'" , luu@enst.fr, nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 16:39:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, a possible reason for confusion might be - many pages in the draft talk mention it here and there - 'no security' is vague (what we call cookies in the the discovery message exchange would be classified as weak authentiction by others) - nslp applications which need no security have not been discussed (maybe a traceroute would provide it) - the terminology of c-mode and d-mode is new (and, as you know, not the best choice - my opinion only). ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, February 17, 2004 4:33 PM > To: Tschofenig Hannes; 'john.loughney@nokia.com'; luu@enst.fr; > nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi all, > > just in case there is any unclarity: > > > thanks for raising this issue. it would be important to state > > very clearly > > that some signaling messages in gimps cannot be secured (or > > at least with > > some degree of difficulty). > > the version -00 draft (basically unchanged in -01) states: > > on page 5 > > "Datagram mode: A mode of sending GIMPS messages between nodes without > using any transport layer state or security protection." > > and on page 6 > > "Here, with details discussed later, "easy" messages are those that > [...] do not need transport or network-layer security support." > > and on page 7 > > "The datagram mode uses a lower-layer unreliable unsecured datagram > transport mechanism, with UDP as the initial choice." > > and on page 14 > > "The main decision is whether the message must be sent in > connection mode or datagram mode. Reasons for using the former > could be: > > * NSLP requirements: for example, the signaling application has > requested channel secured delivery, or reliable delivery;" > > and so on. > > if people think this needs to be emphasised more clearly, please > let me know. > > r. > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 10:46:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07564 for ; Tue, 17 Feb 2004 10:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7QD-0003YX-Vx for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFk5Wr013654 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 10:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7QA-0003Vm-5Z; Tue, 17 Feb 2004 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7PH-0003LN-Rc for nsis@optimus.ietf.org; Tue, 17 Feb 2004 10:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07175 for ; Tue, 17 Feb 2004 10:45:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7PF-0002Lh-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:45:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7NH-0001vp-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:43:04 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1At7LO-0001TD-00 for nsis@ietf.org; Tue, 17 Feb 2004 10:41:06 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1F9Z>; Tue, 17 Feb 2004 15:40:34 -0000 Message-ID: From: "Hancock, Robert" To: "'Yacine.El_Mghazli@alcatel.fr'" , sven.van_den_bosch@alcatel.be Cc: Thanh Tra LUU , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 15:40:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, GIMPS can only provide integrity protection between adjacent QNEs. if a QNE needs to send a message with a policy object and have it received with intact integrity protection several QNEs away, this integrity protection must be provided within the QoS NSLP. r. > -----Original Message----- > From: Yacine.El_Mghazli@alcatel.fr > [mailto:Yacine.El_Mghazli@alcatel.fr] > Sent: Tuesday, February 17, 2004 16:30 > To: sven.van_den_bosch@alcatel.be > Cc: Thanh Tra LUU; nsis@ietf.org > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > nary, > > QoS-NSLP POLICY_DATA object carries policy elements for authorization > purposes between two policy-capable nodes. like what was done in RSVP. > > how far QoS-NSLP relies on NTLP for the so-called integrity objects > (RSVP terminology) is the issue. > > yacine > > > > sven.van_den_bosch@alcatel.be wrote: > > > Hi Nary, > > > > QoS NSLP has POLICY_DATA in its current version of the > spec. Even if GIMPS > > provides integrity, I am not sure it is unneeded in QoS > NSLP (e.g. if QoS > > NSLP is carrying information that is opaque for (some) > intermediate nodes). > > > > Sven > > > > > > > > > > > > > > "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: > > cc: > > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > > > > hi Sven, > > > > > >>Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its > >>security services but GIMPS alone is not sufficient because > it does not > >>protect against compromised QNEs, only against their > interconnection. > > > > > > do you mean QoS-NSLP would support authentication policy > elements (as rsvp) > > and NTLP would support integrity elements (in rsvp) or > QoS-NSLP may do all > > in some cases ? > > > > Nary Tra, > > ENST, Paris. > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Feb 17 11:12:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11298 for ; Tue, 17 Feb 2004 11:12:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7pI-0007dt-O1 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 11:12:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HGC0w5029362 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 11:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7pI-0007dT-Ee; Tue, 17 Feb 2004 11:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7pG-0007cb-Kc for nsis@optimus.ietf.org; Tue, 17 Feb 2004 11:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11149 for ; Tue, 17 Feb 2004 11:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7pD-0006vp-00 for nsis@ietf.org; Tue, 17 Feb 2004 11:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7nP-0006YP-00 for nsis@ietf.org; Tue, 17 Feb 2004 11:10:03 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7lv-0006H1-00 for nsis@ietf.org; Tue, 17 Feb 2004 11:08:31 -0500 Received: from pcluu (dhcp192-215.enst.fr [137.194.192.215]) by infres.enst.fr (Postfix) with SMTP id E276A308F for ; Tue, 17 Feb 2004 17:08:29 +0100 (MET) Message-ID: <016f01c3f570$4c9ce9c0$d7c0c289@enst.fr> From: "Thanh Tra LUU" To: References: Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 17:08:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, > GIMPS can only provide integrity protection between adjacent > QNEs. if a QNE needs to send a message with a policy object > and have it received with intact integrity protection several > QNEs away, this integrity protection must be provided within > the QoS NSLP. does QoS-NSLP really need to require NTLP more than it (integrity protection between adjacent QNEs) ? Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 11:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12789 for ; Tue, 17 Feb 2004 11:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7xA-0008E4-Gq for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 11:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HGK8pc031589 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 11:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7x8-0008DG-3f; Tue, 17 Feb 2004 11:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7wz-0008Bu-UF for nsis@optimus.ietf.org; Tue, 17 Feb 2004 11:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12642 for ; Tue, 17 Feb 2004 11:19:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7wz-0000dm-00 for nsis@ietf.org; Tue, 17 Feb 2004 11:19:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7vD-0000Fa-00 for nsis@ietf.org; Tue, 17 Feb 2004 11:18:08 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1At7t9-0007eY-00 for nsis@ietf.org; Tue, 17 Feb 2004 11:15:59 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1HGFwt15852; Tue, 17 Feb 2004 17:15:58 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1HGFvV24550; Tue, 17 Feb 2004 17:15:57 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Feb 2004 17:15:21 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DA0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Tue, 17 Feb 2004 17:15:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, in the two party authorization model it does not need more than that. for the three party scenarios, however, it is necessary to provide additional information at the qos nslp. ciao hannes > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Tuesday, February 17, 2004 5:09 PM > To: nsis@ietf.org > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > hi all, > > > GIMPS can only provide integrity protection between adjacent > > QNEs. if a QNE needs to send a message with a policy object > > and have it received with intact integrity protection several > > QNEs away, this integrity protection must be provided within > > the QoS NSLP. > > does QoS-NSLP really need to require NTLP more than it > (integrity protection > between adjacent QNEs) ? > > Nary Tra, > ENST, Paris. > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 17 22:43:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26437 for ; Tue, 17 Feb 2004 22:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIc2-0006gU-34 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 22:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I3h22c025679 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 22:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIc1-0006fp-7R; Tue, 17 Feb 2004 22:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIbX-0006VT-Lx for nsis@optimus.ietf.org; Tue, 17 Feb 2004 22:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26391 for ; Tue, 17 Feb 2004 22:42:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtIbT-0004sF-00 for nsis@ietf.org; Tue, 17 Feb 2004 22:42:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtIaV-0004nK-00 for nsis@ietf.org; Tue, 17 Feb 2004 22:41:27 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AtIZY-0004hg-00 for nsis@ietf.org; Tue, 17 Feb 2004 22:40:28 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id i1I3dplu002094 for ; Wed, 18 Feb 2004 12:39:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id i1I3drv19206 for ; Wed, 18 Feb 2004 12:39:53 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id i1I3dse01946 for ; Wed, 18 Feb 2004 12:39:54 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml25) id i1I3dq106799 for nsis@ietf.org; Wed, 18 Feb 2004 12:39:52 +0900 (JST) Received: from [10.68.136.49] (localhost [127.0.0.1]) by soml25.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i1I3dpw06793 for ; Wed, 18 Feb 2004 12:39:51 +0900 (JST) Date: Wed, 18 Feb 2004 12:39:53 +0900 From: Takako Sanda To: nsis@ietf.org Message-Id: <20040218122221.B8EC.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Draft for pre CRN discovery and fast state installation 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, I submitted the following Internet Draft. http://www.ietf.org/internet-drafts/draft-sanda-nsis-mobility-qos-proxy-01.txt Title: "Pre CRN discovery from proxy on candidate new path" File Name: draft-sanda-nsis-mobility-qos-proxy-01.txt Abstract: NSIS WG has been discussing the ways to minimize/avoid QoS interruption during handover. One solution is to install new path before MN's move (fast state installation). This document proposes a procedure of pre CRN discovery for fast state installation by using proxies on candidate new paths. An example of fast state installation is shown. Any comments are welcome. Best Regards, Takako Sanda and Toyoki Ue _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 17 23:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27728 for ; Tue, 17 Feb 2004 23:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJHe-0000RW-Aa for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 23:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I4Q2Zg001694 for nsis-archive@odin.ietf.org; Tue, 17 Feb 2004 23:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJHd-0000Qy-HO; Tue, 17 Feb 2004 23:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJHI-0000NB-Kh for nsis@optimus.ietf.org; Tue, 17 Feb 2004 23:25:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27676 for ; Tue, 17 Feb 2004 23:25:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtJHG-00005E-00 for nsis@ietf.org; Tue, 17 Feb 2004 23:25:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtJGX-00000r-00 for nsis@ietf.org; Tue, 17 Feb 2004 23:24:54 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AtJFR-0007hw-00 for nsis@ietf.org; Tue, 17 Feb 2004 23:23:46 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1I4EhBx018893; Wed, 18 Feb 2004 12:14:52 +0800 (SGT) From: "Cheng Hong" To: Cc: , , Date: Wed, 18 Feb 2004 12:22:47 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <01a801c3f5d6$e09cba40$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP 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: quoted-printable Hi Sven, Thanks a lot for reviewing the draft. Please see some response to the questions inline: Best regards Cheng Hong PS: A copy of the draft is available at link below: http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be]=20 > Sent: Tuesday, February 17, 2004 6:41 PM > To: hcheng@psl.com.sg; khling@psl.com.sg > Cc: nsis@ietf.org > Subject: discussion on draft-cheng-mobility-issues-01.txt=20 > impact on QoS NSLP >=20 >=20 > Hi, >=20 > I have gone through your draft. If I understand correctly, > the issues you raise are: > - the need for the QoS NSLP to support a change of FlowID for=20 > the same sessionID (e.g. multi-homing) > - the need to deal intelligently with very frequent=20 > (ping-pong) mobility events [CH]: That is correct.=20 [/CH] > I agree with the need for both types of functionality, but I > don't think the impact on QoS NSLP is very large. From what=20 > you propose in the draft, the current version of the QoS NSLP=20 > (draft-ietf-nsis-qos-nslp-02.txt) > supports: > - ability to reserve zero resources [CH]: I have browsed through the qos-nslp-02 draft. Seems there were = quite some details added.=20 As for the RZR proposed, it is different from the normal zero = reservation using the QSPEC. It is more like another version of the TEAR. Here below = are some of the reasons that the RZR is needed in the qos-nslp. 1) The RZR is for a QoS NSLP layer CRN to put states over old path to "dormant" mode. It is not simply set corresponding QSPEC to zero. E.g. = it could indicate the QNE for other special treatment, gradual reduce of resource, etc. The action to be taken at each node is as you mentioned a policy issue. Using the normal QSPEC to set to resource to zero could = not achieve this.=20 2) Using the zero QSPEC would cause the QNE lost information about the = old state. It is not good for the restore process. A RZR option instead = could allow QNE retain the original state information, even the QSPEC. 3) The tear down RESERV message may not carry QSPEC object. In this = case, an RZR option, similar to the TEAR, would be more suitable than an extra = QSPEC that puts burden on the network. 4) To use the current QSPEC to indicate the RZR requires each QoS model = to generate a QSPEC with zero resources involved. It could be heavy for the QNE. Besides above, I feel that the lacking part in the current qos-nslp = draft is how the RZR is used. Supposedly, the RZR should replace the TEAR RESERV message to be sent from an QoS NSLP layer CRN. Since a CRN could be any = QNE, this behavior should be defined in the QoS NSLP. Also, how the = corresponding QNE response to the RZR should be explained. Other than that, how the return to the old path is recognized, and how = to restore and reuse the state over the old path could be incorporated into = the qos-nslp draft as well. [/CH]=20 > - ability to retain/remove state on the old path: supported=20 > in QoS NSLP (with SII) but the decision to keep state is a=20 > policy issue at the QNE, not indicated by MN [CH] Although the QNE could decide how to deal with the old state, it = still needs information from other nodes to make the decision. For example, = how would the QNE know the MN is doing multi-homing with the indication from = the MN? Of course, the QNE could decide how to react at this indication according to its local policy. [/CH] > What you propose that is currently not there: > - MN indication of desire to maintain old path state. We > could do this via a flag in the header which is minimal=20 > impact but I am concerned about: >=20 > 1. security: can be solved by making support optional and > leave the QNE the freedom to disregard it 2. relation to=20 > charging, ...: if it is just an indication, not mandatory,=20 > who will be charged for maintaining the reservation >=20 > Have you thought about these issues? [CH] You are correct that a flag could achieve the purpose at most of = the time. But, as we briefly described in the draft that in certain case, = the Flow-ID is needed, and a flag is necessary for each of the FLOW-ID. As for the security, the indication (flag) would be bundled with the = RESERV (or the corresponding RESPONSE) of the new path. It should maintain the = same security level as the RESERV message. In case the MN is not the QNE, the communication would be between MN and a NSIS proxy, which would be out = of scope of the draft.=20 Since this option is to be indicated in the reservation process over the = new path, the QoS NSLP layer CRN has already been discovered (at least = RESERV could indicate that), some cookies could used for enhancing the security = of the message. For example, if the RESERV is send from CRN to MN, the CRN could include a cookie in the RESERV, and MN can make use the cookie to secure its RESPONSE or NOTIFY to the CRN that indicates it's desire. As for the charging, the MN should be charged for maintaining the reservation, since it's requested by the MN. (could be a special service subscription option? Or QoS level?) If the MN does not indicate the preservation, reservation could be just torn down according to local = policy. [/CH] > Best regards, > Sven Van den Bosch >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 18 17:44:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27326 for ; Wed, 18 Feb 2004 17:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaQE-0000MR-P1 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 17:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IMi2tJ001383 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 17:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaQE-0000Lx-8m; Wed, 18 Feb 2004 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaPv-0000Gl-Bm for nsis@optimus.ietf.org; Wed, 18 Feb 2004 17:43:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27307 for ; Wed, 18 Feb 2004 17:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtaPs-0006U4-00 for nsis@ietf.org; Wed, 18 Feb 2004 17:43:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtaP0-0006NI-00 for nsis@ietf.org; Wed, 18 Feb 2004 17:42:47 -0500 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 1AtaO4-0006Ei-00 for nsis@ietf.org; Wed, 18 Feb 2004 17:41:48 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1IMf5c86189; Wed, 18 Feb 2004 17:41:05 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1IMf4B28232; Wed, 18 Feb 2004 17:41:04 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id RAA12025; Wed, 18 Feb 2004 17:41:04 -0500 (EST) Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS From: Steven Blake To: john.loughney@nokia.com Cc: nsis@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Ericsson IP Infrastructure Message-Id: <1077144062.21616.101.camel@newcastle.torrentnet.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 18 Feb 2004 17:41:03 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 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 On Tue, 2004-02-17 at 08:49, john.loughney@nokia.com wrote: > Hi Attila, > > Nary Tra's email also raised a question in my mind: > > > 3. In the last paragraph of 2(protocol model), 'they are not able to > > establish and maintain security associations with their neighbors, which > > means, they can only be applied in a trusted domain'. The stateless does not > > mean no security association. In rsvp, the sa is not specified how it can > > create (maybe by ike, manual) and which node is the next rsvp-aware node. > > In an IESG review of a SIGTRAN document of mine, the IESG (specifically > the Security Area Director) said that the IESG will not standardize > anything with the 'trusted domain' concept. The Security AD commented > that compromised nodes in a 'trusted network' have caused far more > serious problems than is always documented. For example, a disgruntled > employee with a key to the server room can do a lot of hacking. With this > in my mind, I think that you will have to rethink this part of your > draft. You need to be able to provide a mechansims of how neighbors > can establish & maintain security associations. This does not mean > that a security association always must be used, but the the possibility > for creating a security association is mandatory, in my opinion. The notion of "trusted domain" is inherent in the Diffserv architecture (RFC 2475). Any sort of service assurance within a network is dependent on the ability to condition the traffic at the edges according to the service provisioning policy of the network operator. Diffserv cannot work as intended unless the boundary of the network is "air-tight" with respect to admitting traffic with certain DSCP markings. The RMD-QoS-NSLP draft introduces a signaling mechanism by which admissions control can be implemented and the traffic conditioning at the domain boundary can be more carefully configured (e.g., to achieve higher utilization at a certain service assurance level). I see this as very much in line with the Diffserv architecture in the sense that the only additional requirement on the boundary QNEs is to ensure that rogue signaling messages don't enter the domain (this is not mentioned specifically in the draft but should be). Imposing hop-by-hop security associations as a mandatory operating mode for QoS-NSLP will make that protocol just as useful as RSVP/Intserv in the Internet; i.e., not very. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 18 21:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07773 for ; Wed, 18 Feb 2004 21:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdeZ-0006Df-6L for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 21:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J2B3LC023892 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 21:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdeX-0006Cp-SO; Wed, 18 Feb 2004 21:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdeK-00064L-Ve for nsis@optimus.ietf.org; Wed, 18 Feb 2004 21:10:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07757 for ; Wed, 18 Feb 2004 21:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtdeI-0001nU-00 for nsis@ietf.org; Wed, 18 Feb 2004 21:10:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtddQ-0001lr-00 for nsis@ietf.org; Wed, 18 Feb 2004 21:09:53 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Atdch-0001gf-00 for nsis@ietf.org; Wed, 18 Feb 2004 21:09:08 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1J20KkF008156; Thu, 19 Feb 2004 10:00:28 +0800 (SGT) From: "Cheng Hong" To: "'Sung Hyuck Lee'" Cc: "'Nsis \(E-mail\)'" , , , Subject: RE: [NSIS] Mobility and Internet Signaling Protocols Date: Thu, 19 Feb 2004 10:08:24 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <029501c3f68d$44d83eb0$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Dear Authors, We noticed that in the section 3.5 of your draft, the Ping-pong type of = handover is listed as one of the issue to be solved. Therefore, we would = like to bring to your attention that an ID we submitted recently also = covers the same topic (draft-cheng-mobility-issues-01.txt). And that ID = discussed some of the possible solutions. If possible, we would like to = hear your comments on the draft.=20 Since our draft is still not yet placed on the IETF server, please find = a copy at: http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt Thanks and regards Cheng Hong =20 > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On=20 > Behalf Of Sung Hyuck Lee > Sent: Thursday, January 29, 2004 5:16 PM > To: Nsis (E-mail) > Subject: [NSIS] Mobility and Internet Signaling Protocols >=20 >=20 >=20 > Dear all, >=20 > We submitted the following draft concerning mobility-related=20 > issues in NSIS: >=20 http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mo= bility-00.txt The goals of this draft are to analyze the effects of mobility in = NTLP/NSLP=20 and give some guidelines about how to tackle various issues caused by=20 mobility (as well as generic route change) in the Internet signaling = protocols. =20 This draft discussed the following issues in NTLP/NSLP layers: - analysis of various mobility scenarios in NSIS signaling and = statement problems - Crossover node discovery and Path update caused by mobility and=20 route change - Dead peer discovery - Case examples of NSIS signaling according to handover cases - Interaction with mobility signalings (e.g., HMIPv6, FMIPv6, CARD, = and CTP) - Uni- and bi-directional state establishment, State Management, and State establishment in network mobility as additional issues - Security considerations in various scenarios such as MN as = sender/receiver, =20 multihoming scenarios, using context transfer, proxy scenario, and = AAA. There are also some issues which need to be discussed in the next = version=20 - Multihoming related issues - Both End-Hosts are Mobile=20 - Split of NSIS functionality - Open questions in each section All comments are welcome Regards, Sung-Hyuck =20 =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=A7=C2=B2+= &j)b=C5=BE = b=C2=B2=C3=99=C3=AC=C5=A0=C3=8F=C3=A2z=C3=97=C3=BF=C2=A2=C2=B8!=C2=B6=C3=9A= l=C3=BF=C3=BF=C3=B0=C3=83 =C3=BF=E2=80=B0=C3=AB_=C3=BE=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BE= X=C2=AC=C2=B6)=C3=9F=C2=A3=C3=B9=C3=AC _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 18 21:21:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08527 for ; Wed, 18 Feb 2004 21:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdoE-0007Be-HB for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 21:21:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J2L2el027579 for nsis-archive@odin.ietf.org; Wed, 18 Feb 2004 21:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdoD-0007Ae-UX; Wed, 18 Feb 2004 21:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdnU-00076S-U0 for nsis@optimus.ietf.org; Wed, 18 Feb 2004 21:20:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08432 for ; Wed, 18 Feb 2004 21:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtdnS-0002et-00 for nsis@ietf.org; Wed, 18 Feb 2004 21:20:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtdmR-0002UB-00 for nsis@ietf.org; Wed, 18 Feb 2004 21:19:12 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1Atdkz-0002Ch-00 for nsis@ietf.org; Wed, 18 Feb 2004 21:17:42 -0500 Received: (qmail 783 invoked from network); 19 Feb 2004 02:17:35 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.158 with SMTP; 19 Feb 2004 02:17:35 -0000 Date: Thu, 19 Feb 2004 10:19:07 +0800 From: "Yuming Wang" To: "nsis" Subject: Re: [NSIS] Draft for pre CRN discovery and fast state installation X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Takako Sanda, In chapter 2, you've mentioned: "MN cannot directly initiate resource reservation signaling on candidate new paths before it actually moves." Why cannot? you mean the MN cannot connect to the NAR? When the MN is at the overlap of OAR and NAR, it can connect to the NAR and initiate resource reservation signaling on candidate new paths. Is it proper to initiate resource reservation signaling on the candidate new paths before the MN can connect to the NAR? because it's not easy to decide who is the next NAR. >Hi John and all, > >I submitted the following Internet Draft. > >http://www.ietf.org/internet-drafts/draft-sanda-nsis-mobility-qos-proxy-01.txt > > Title: "Pre CRN discovery from proxy on candidate new path" > File Name: draft-sanda-nsis-mobility-qos-proxy-01.txt > Abstract: > NSIS WG has been discussing the ways to minimize/avoid QoS > interruption during handover. One solution is to install new > path before MN's move (fast state installation). > This document proposes a procedure of pre CRN discovery for fast > state installation by using proxies on candidate new paths. An > example of fast state installation is shown. > > >Any comments are welcome. > >Best Regards, >Takako Sanda and Toyoki Ue > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > Yuming 2004-02-19 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 02:41:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03833 for ; Thu, 19 Feb 2004 02:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atiny-0007pO-OG for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 02:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J7f6kt030089 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 02:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atinv-0007ot-VS; Thu, 19 Feb 2004 02:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtinA-0007e2-6c for nsis@optimus.ietf.org; Thu, 19 Feb 2004 02:40:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03262 for ; Thu, 19 Feb 2004 02:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atin5-0001vq-00 for nsis@ietf.org; Thu, 19 Feb 2004 02:40:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atim9-0001o5-00 for nsis@ietf.org; Thu, 19 Feb 2004 02:39:13 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1Atil7-0001ZP-00 for nsis@ietf.org; Thu, 19 Feb 2004 02:38:09 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id i1J7bblu026144; Thu, 19 Feb 2004 16:37:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id i1J7bdn06338; Thu, 19 Feb 2004 16:37:39 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id i1J7bb728503; Thu, 19 Feb 2004 16:37:37 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml21) id i1J7bcA26578; Thu, 19 Feb 2004 16:37:38 +0900 (JST) Received: from [10.68.136.41] (localhost [127.0.0.1]) by soml21.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i1J7bcH26573; Thu, 19 Feb 2004 16:37:38 +0900 (JST) Date: Thu, 19 Feb 2004 16:37:39 +0900 From: Takako Sanda To: acer_wym@sina.com, nsis@ietf.org Subject: Re: [NSIS] Draft for pre CRN discovery and fast state installation Cc: nsis In-Reply-To: References: Message-Id: <20040219161500.8B77.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Yuming Wang, Thank you for your comment. My explanation in the draft seems to make some confusion. The answers are inline. > "MN cannot directly initiate resource reservation signaling on > candidate new paths before it actually moves." > > Why cannot? you mean the MN cannot connect to the NAR? > When the MN is at the overlap of OAR and NAR, it can connect to > the NAR and initiate resource reservation signaling on candidate > new paths. The meaning of "candidate new path" is "the path that is expected to be established when MN moves to other network". Assume that MN is currently connected to AR0, and "path0" is established between MN and CN via AR0. And AR1 is one of neighboring ARs of AR0. If the MN moves to AR1, a new path "path1" will be established between MN and CN through AR1. This path1 is candidate paths. But, MN cannot directly establish path1 when it is still connected to AR0. This is the meaning of "MN cannot directly initiate resource reservation signaling on candidate new paths before it actually moves." > Is it proper to initiate resource reservation signaling on the > candidate new paths before the MN can connect to the NAR? because > it's not easy to decide who is the next NAR. For example, if MN and network support FMIP and CARD, it can decide NAR when it is still connected to current AR. Or, as I mentioned in my Internet draft, if MN has "a table" locally, MN can decide NAR even without FMIP or CARD support. Do I answer your questions? BR, Takako Sanda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 03:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06022 for ; Thu, 19 Feb 2004 03:54:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtjwY-0004nb-Hv for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 03:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J8s2h5018430 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 03:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtjwX-0004mb-HT; Thu, 19 Feb 2004 03:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjvf-0004k0-FE for nsis@optimus.ietf.org; Thu, 19 Feb 2004 03:53:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05988 for ; Thu, 19 Feb 2004 03:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atjvc-0005hd-00 for nsis@ietf.org; Thu, 19 Feb 2004 03:53:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atjus-0005fD-00 for nsis@ietf.org; Thu, 19 Feb 2004 03:52:19 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1AtjuH-0005ad-00 for nsis@ietf.org; Thu, 19 Feb 2004 03:51:41 -0500 Received: (qmail 12743 invoked from network); 19 Feb 2004 08:51:23 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.158 with SMTP; 19 Feb 2004 08:51:23 -0000 Date: Thu, 19 Feb 2004 16:52:56 +0800 From: "Yuming Wang" To: "Cheng Hong" Cc: "nsis" Subject: Re: [NSIS] FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Cheng Hong, Some more considerations: In your RZR solution for the ping-pong type of movement, admission control should be carried out when the old path is re-established using a modification RESERVE message. If there is not enough resource on the old path, access of the MN will be denied. so, how to do admission control is another issue. >Hi Sven, > >Thanks a lot for reviewing the draft. Please see some response to the >questions inline: > >Best regards > >Cheng Hong > >PS: A copy of the draft is available at link below: >http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt > > >> -----Original Message----- >> From: sven.van_den_bosch@alcatel.be >> [mailto:sven.van_den_bosch@alcatel.be] >> Sent: Tuesday, February 17, 2004 6:41 PM >> To: hcheng@psl.com.sg; khling@psl.com.sg >> Cc: nsis@ietf.org >> Subject: discussion on draft-cheng-mobility-issues-01.txt >> impact on QoS NSLP >> >> >> Hi, >> >> I have gone through your draft. If I understand correctly, >> the issues you raise are: >> - the need for the QoS NSLP to support a change of FlowID for >> the same sessionID (e.g. multi-homing) >> - the need to deal intelligently with very frequent >> (ping-pong) mobility events > >[CH]: That is correct. >[/CH] > >> I agree with the need for both types of functionality, but I >> don't think the impact on QoS NSLP is very large. From what >> you propose in the draft, the current version of the QoS NSLP >> (draft-ietf-nsis-qos-nslp-02.txt) >> supports: >> - ability to reserve zero resources > >[CH]: I have browsed through the qos-nslp-02 draft. Seems there were quite >some details added. > >As for the RZR proposed, it is different from the normal zero reservation >using the QSPEC. It is more like another version of the TEAR. Here below are >some of the reasons that the RZR is needed in the qos-nslp. > >1) The RZR is for a QoS NSLP layer CRN to put states over old path to >"dormant" mode. It is not simply set corresponding QSPEC to zero. E.g. it >could indicate the QNE for other special treatment, gradual reduce of >resource, etc. The action to be taken at each node is as you mentioned a >policy issue. Using the normal QSPEC to set to resource to zero could not >achieve this. > >2) Using the zero QSPEC would cause the QNE lost information about the old >state. It is not good for the restore process. A RZR option instead could >allow QNE retain the original state information, even the QSPEC. > >3) The tear down RESERV message may not carry QSPEC object. In this case, an >RZR option, similar to the TEAR, would be more suitable than an extra QSPEC >that puts burden on the network. > >4) To use the current QSPEC to indicate the RZR requires each QoS model to >generate a QSPEC with zero resources involved. It could be heavy for the >QNE. > >Besides above, I feel that the lacking part in the current qos-nslp draft is >how the RZR is used. Supposedly, the RZR should replace the TEAR RESERV >message to be sent from an QoS NSLP layer CRN. Since a CRN could be any QNE, >this behavior should be defined in the QoS NSLP. Also, how the corresponding >QNE response to the RZR should be explained. > >Other than that, how the return to the old path is recognized, and how to >restore and reuse the state over the old path could be incorporated into the >qos-nslp draft as well. > >[/CH] > >> - ability to retain/remove state on the old path: supported >> in QoS NSLP (with SII) but the decision to keep state is a >> policy issue at the QNE, not indicated by MN > >[CH] Although the QNE could decide how to deal with the old state, it still >needs information from other nodes to make the decision. For example, how >would the QNE know the MN is doing multi-homing with the indication from the >MN? Of course, the QNE could decide how to react at this indication >according to its local policy. >[/CH] > > >> What you propose that is currently not there: >> - MN indication of desire to maintain old path state. We >> could do this via a flag in the header which is minimal >> impact but I am concerned about: >> >> 1. security: can be solved by making support optional and >> leave the QNE the freedom to disregard it 2. relation to >> charging, ...: if it is just an indication, not mandatory, >> who will be charged for maintaining the reservation >> >> Have you thought about these issues? > >[CH] You are correct that a flag could achieve the purpose at most of the >time. But, as we briefly described in the draft that in certain case, the >Flow-ID is needed, and a flag is necessary for each of the FLOW-ID. > >As for the security, the indication (flag) would be bundled with the RESERV >(or the corresponding RESPONSE) of the new path. It should maintain the same >security level as the RESERV message. In case the MN is not the QNE, the >communication would be between MN and a NSIS proxy, which would be out of >scope of the draft. > >Since this option is to be indicated in the reservation process over the new >path, the QoS NSLP layer CRN has already been discovered (at least RESERV >could indicate that), some cookies could used for enhancing the security of >the message. For example, if the RESERV is send from CRN to MN, the CRN >could include a cookie in the RESERV, and MN can make use the cookie to >secure its RESPONSE or NOTIFY to the CRN that indicates it's desire. > >As for the charging, the MN should be charged for maintaining the >reservation, since it's requested by the MN. (could be a special service >subscription option? Or QoS level?) If the MN does not indicate the >preservation, reservation could be just torn down according to local policy. > >[/CH] > >> Best regards, >> Sven Van den Bosch >> >> >> > > > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis Cheers, Yuming 2004-02-19 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 04:05:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06413 for ; Thu, 19 Feb 2004 04:05:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atk7F-0005nu-Lq for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:05:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J955WI022270 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atk7C-0005mk-Jo; Thu, 19 Feb 2004 04:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atk77-0005mP-5F for nsis@optimus.ietf.org; Thu, 19 Feb 2004 04:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06397 for ; Thu, 19 Feb 2004 04:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atk74-0006El-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:04:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atk67-0006Bw-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:03:56 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Atk5A-00068E-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:02:56 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1J8sI8F021856; Thu, 19 Feb 2004 16:54:23 +0800 (SGT) From: "Cheng Hong" To: "'Yuming Wang'" Cc: "'nsis'" Subject: RE: [NSIS] FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP Date: Thu, 19 Feb 2004 17:02:22 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <02c501c3f6c7$16356a30$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200402190843.i1J8hhwg021526@mailsrv.psl.com.sg> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Yuming, Thanks for the comments. I think the admission control is always a separate problem. If the old = path could not provide the resources for re-establishment, the RESERVE will = fail. This is common regardless of whether RZR solution is used. To use the = RZR solution would allow you to know that the old path could not suppor the session faster. (since it get rid of the signaling association setup process) It is not to guarantee that MN could be supported when it moves back, which is the job of resource management module, and is out of = scope of the draft. Cheers Cheng Hong > -----Original Message----- > From: Yuming Wang [mailto:acer_wym@sina.com]=20 > Sent: Thursday, February 19, 2004 4:53 PM > To: Cheng Hong > Cc: nsis > Subject: Re: [NSIS] FW: discussion on=20 > draft-cheng-mobility-issues-01.txt impact on QoS NSLP >=20 >=20 > Hi Cheng Hong, >=20 > Some more considerations: > In your RZR solution for the ping-pong type of movement,=20 > admission control should be carried out when the old path is=20 > re-established using a modification RESERVE message. If there=20 > is not enough resource on the old path, access of the MN will=20 > be denied. so, how to do admission control is another issue. >=20 > >Hi Sven, > > > >Thanks a lot for reviewing the draft. Please see some=20 > response to the=20 > >questions inline: > > > >Best regards > > > >Cheng Hong > > > >PS: A copy of the draft is available at link below:=20 > >http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt > > > > > >> -----Original Message----- > >> From: sven.van_den_bosch@alcatel.be=20 > >> [mailto:sven.van_den_bosch@alcatel.be] > >> Sent: Tuesday, February 17, 2004 6:41 PM > >> To: hcheng@psl.com.sg; khling@psl.com.sg > >> Cc: nsis@ietf.org > >> Subject: discussion on draft-cheng-mobility-issues-01.txt > >> impact on QoS NSLP > >>=20 > >>=20 > >> Hi, > >>=20 > >> I have gone through your draft. If I understand correctly,=20 > the issues=20 > >> you raise are: > >> - the need for the QoS NSLP to support a change of FlowID for > >> the same sessionID (e.g. multi-homing) > >> - the need to deal intelligently with very frequent=20 > >> (ping-pong) mobility events > > > >[CH]: That is correct. > >[/CH] > > > >> I agree with the need for both types of functionality, but I don't=20 > >> think the impact on QoS NSLP is very large. From what you=20 > propose in=20 > >> the draft, the current version of the QoS NSLP > >> (draft-ietf-nsis-qos-nslp-02.txt) > >> supports: > >> - ability to reserve zero resources > > > >[CH]: I have browsed through the qos-nslp-02 draft. Seems there were=20 > >quite some details added. > > > >As for the RZR proposed, it is different from the normal zero=20 > >reservation using the QSPEC. It is more like another version of the=20 > >TEAR. Here below are some of the reasons that the RZR is=20 > needed in the=20 > >qos-nslp. > > > >1) The RZR is for a QoS NSLP layer CRN to put states over=20 > old path to=20 > >"dormant" mode. It is not simply set corresponding QSPEC to=20 > zero. E.g.=20 > >it could indicate the QNE for other special treatment,=20 > gradual reduce=20 > >of resource, etc. The action to be taken at each node is as you=20 > >mentioned a policy issue. Using the normal QSPEC to set to=20 > resource to=20 > >zero could not achieve this. > > > >2) Using the zero QSPEC would cause the QNE lost information=20 > about the=20 > >old state. It is not good for the restore process. A RZR=20 > option instead=20 > >could allow QNE retain the original state information, even=20 > the QSPEC. > > > >3) The tear down RESERV message may not carry QSPEC object. In this=20 > >case, an RZR option, similar to the TEAR, would be more=20 > suitable than=20 > >an extra QSPEC that puts burden on the network. > > > >4) To use the current QSPEC to indicate the RZR requires=20 > each QoS model=20 > >to generate a QSPEC with zero resources involved. It could=20 > be heavy for=20 > >the QNE. > > > >Besides above, I feel that the lacking part in the current qos-nslp=20 > >draft is how the RZR is used. Supposedly, the RZR should replace the=20 > >TEAR RESERV message to be sent from an QoS NSLP layer CRN.=20 > Since a CRN=20 > >could be any QNE, this behavior should be defined in the QoS NSLP.=20 > >Also, how the corresponding QNE response to the RZR should be=20 > >explained. > > > >Other than that, how the return to the old path is=20 > recognized, and how=20 > >to restore and reuse the state over the old path could be=20 > incorporated=20 > >into the qos-nslp draft as well. > > > >[/CH] > > > >> - ability to retain/remove state on the old path: supported > >> in QoS NSLP (with SII) but the decision to keep state is a=20 > >> policy issue at the QNE, not indicated by MN > > > >[CH] Although the QNE could decide how to deal with the old=20 > state, it=20 > >still needs information from other nodes to make the decision. For=20 > >example, how would the QNE know the MN is doing multi-homing=20 > with the=20 > >indication from the MN? Of course, the QNE could decide how=20 > to react at=20 > >this indication according to its local policy. [/CH] > > > > > >> What you propose that is currently not there: > >> - MN indication of desire to maintain old path state. We could do=20 > >> this via a flag in the header which is minimal impact but I am=20 > >> concerned about: > >>=20 > >> 1. security: can be solved by making support optional and=20 > leave the=20 > >> QNE the freedom to disregard it 2. relation to charging,=20 > ...: if it=20 > >> is just an indication, not mandatory, who will be charged for=20 > >> maintaining the reservation > >>=20 > >> Have you thought about these issues? > > > >[CH] You are correct that a flag could achieve the purpose=20 > at most of=20 > >the time. But, as we briefly described in the draft that in certain=20 > >case, the Flow-ID is needed, and a flag is necessary for each of the=20 > >FLOW-ID. > > > >As for the security, the indication (flag) would be bundled with the=20 > >RESERV (or the corresponding RESPONSE) of the new path. It should=20 > >maintain the same security level as the RESERV message. In=20 > case the MN=20 > >is not the QNE, the communication would be between MN and a=20 > NSIS proxy,=20 > >which would be out of scope of the draft. > > > >Since this option is to be indicated in the reservation process over=20 > >the new path, the QoS NSLP layer CRN has already been discovered (at=20 > >least RESERV could indicate that), some cookies could used for=20 > >enhancing the security of the message. For example, if the RESERV is=20 > >send from CRN to MN, the CRN could include a cookie in the=20 > RESERV, and=20 > >MN can make use the cookie to secure its RESPONSE or NOTIFY=20 > to the CRN=20 > >that indicates it's desire. > > > >As for the charging, the MN should be charged for maintaining the=20 > >reservation, since it's requested by the MN. (could be a special=20 > >service subscription option? Or QoS level?) If the MN does=20 > not indicate=20 > >the preservation, reservation could be just torn down according to=20 > >local policy. > > > >[/CH] > > > >> Best regards, > >> Sven Van den Bosch > >>=20 > >>=20 > >>=20 > > > > > > > > > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis >=20 > Cheers, > Yuming > 2004-02-19 > ---------------- Yuming Wang ----------------- > NGIT Research Group, ITEC R&D Center, EI Dpt., > HuaZhong University of Science and Technology. > Email: acer_wym@sina.com > Home Page: http://itec.hust.edu.cn/wym.htm > TEL: +86-27-87453207 FAX: +86-27-87456436 > ---- >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 04:43:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11266 for ; Thu, 19 Feb 2004 04:43:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atki2-0001CU-5e for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:43:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J9h4jV004579 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkhx-0001Be-Nx; Thu, 19 Feb 2004 04:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkh3-00017u-Qx for nsis@optimus.ietf.org; Thu, 19 Feb 2004 04:42:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11085 for ; Thu, 19 Feb 2004 04:42:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atkgy-0001Mq-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:42:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atkfx-0001IH-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:40:57 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1Atkf6-0001Gz-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:40:05 -0500 Received: (qmail 53975 invoked from network); 19 Feb 2004 09:40:00 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.158 with SMTP; 19 Feb 2004 09:40:00 -0000 Date: Thu, 19 Feb 2004 17:41:37 +0800 From: "Yuming Wang" To: "Takako Sanda" Cc: "nsis" Subject: Re: Re: [NSIS] Draft for pre CRN discovery and fast state installation X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Takako Sanda, The comments inline: >Hi Yuming Wang, > >Thank you for your comment. > >My explanation in the draft seems to make some confusion. >The answers are inline. > > >> "MN cannot directly initiate resource reservation signaling on >> candidate new paths before it actually moves." >> >> Why cannot? you mean the MN cannot connect to the NAR? >> When the MN is at the overlap of OAR and NAR, it can connect to >> the NAR and initiate resource reservation signaling on candidate >> new paths. > >The meaning of "candidate new path" is "the path that is expected to be >established when MN moves to other network". >Assume that MN is currently connected to AR0, and "path0" is established >between MN and CN via AR0. And AR1 is one of neighboring ARs of AR0. >If the MN moves to AR1, a new path "path1" will be established between >MN and CN through AR1. >This path1 is candidate paths. >But, MN cannot directly establish path1 when it is still connected to >AR0. > >This is the meaning of "MN cannot directly initiate resource reservation >signaling on candidate new paths before it actually moves." > IMO, If the MN still cannot communicate with the AR1 (because AR1 is too far from the MN, and the signaling strength is so weak), path1 should not be the candidate path. Assume that MN is currently connected to AR0, and AR1 & AR2 are neighboring ARs of AR0, but MN can only get signaling strength of AR0 and AR2, that means, it can only communicate with AR0 and AR2, then, path2 will be the candidate path and path1 will not be necessary to be. Now that the MN can communicate with AR2, so, why it cannot directly initiate resource reservation signaling on path2? I don't know whether I am right. > >> Is it proper to initiate resource reservation signaling on the >> candidate new paths before the MN can connect to the NAR? because >> it's not easy to decide who is the next NAR. > >For example, if MN and network support FMIP and CARD, it can decide NAR >when it is still connected to current AR. >Or, as I mentioned in my Internet draft, if MN has "a table" locally, MN >can decide NAR even without FMIP or CARD support. > >Do I answer your questions? > >BR, >Takako Sanda > > > > >. Thanks, Yuming 2004-02-19 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 04:45:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11326 for ; Thu, 19 Feb 2004 04:45:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkjy-0001Sc-Nu for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:45:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J9j6Vh005585 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkjx-0001Rp-6P; Thu, 19 Feb 2004 04:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkiu-0001Nm-So for nsis@optimus.ietf.org; Thu, 19 Feb 2004 04:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11284 for ; Thu, 19 Feb 2004 04:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atkir-0001ax-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:43:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atkhs-0001Ui-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:42:57 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1Atkgq-0001Lt-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:41:52 -0500 Received: (qmail 54825 invoked from network); 19 Feb 2004 09:41:48 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.158 with SMTP; 19 Feb 2004 09:41:48 -0000 Date: Thu, 19 Feb 2004 17:43:25 +0800 From: "Yuming Wang" To: "Cheng Hong" Cc: "nsis" Subject: Re: RE: [NSIS] FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Cheng Hong, I'm really appreciated for you answer. Thank you! >Hi Yuming, > >Thanks for the comments. > >I think the admission control is always a separate problem. If the old path >could not provide the resources for re-establishment, the RESERVE will fail. >This is common regardless of whether RZR solution is used. To use the RZR >solution would allow you to know that the old path could not suppor the >session faster. (since it get rid of the signaling association setup >process) It is not to guarantee that MN could be supported when it moves >back, which is the job of resource management module, and is out of scope of >the draft. > >Cheers > >Cheng Hong > >> -----Original Message----- >> From: Yuming Wang [mailto:acer_wym@sina.com] >> Sent: Thursday, February 19, 2004 4:53 PM >> To: Cheng Hong >> Cc: nsis >> Subject: Re: [NSIS] FW: discussion on >> draft-cheng-mobility-issues-01.txt impact on QoS NSLP >> >> >> Hi Cheng Hong, >> >> Some more considerations: >> In your RZR solution for the ping-pong type of movement, >> admission control should be carried out when the old path is >> re-established using a modification RESERVE message. If there >> is not enough resource on the old path, access of the MN will >> be denied. so, how to do admission control is another issue. >> >> >Hi Sven, >> > >> >Thanks a lot for reviewing the draft. Please see some >> response to the >> >questions inline: >> > >> >Best regards >> > >> >Cheng Hong >> > >> >PS: A copy of the draft is available at link below: >> >http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt >> > >> > >> >> -----Original Message----- >> >> From: sven.van_den_bosch@alcatel.be >> >> [mailto:sven.van_den_bosch@alcatel.be] >> >> Sent: Tuesday, February 17, 2004 6:41 PM >> >> To: hcheng@psl.com.sg; khling@psl.com.sg >> >> Cc: nsis@ietf.org >> >> Subject: discussion on draft-cheng-mobility-issues-01.txt >> >> impact on QoS NSLP >> >> >> >> >> >> Hi, >> >> >> >> I have gone through your draft. If I understand correctly, >> the issues >> >> you raise are: >> >> - the need for the QoS NSLP to support a change of FlowID for >> >> the same sessionID (e.g. multi-homing) >> >> - the need to deal intelligently with very frequent >> >> (ping-pong) mobility events >> > >> >[CH]: That is correct. >> >[/CH] >> > >> >> I agree with the need for both types of functionality, but I don't >> >> think the impact on QoS NSLP is very large. From what you >> propose in >> >> the draft, the current version of the QoS NSLP >> >> (draft-ietf-nsis-qos-nslp-02.txt) >> >> supports: >> >> - ability to reserve zero resources >> > >> >[CH]: I have browsed through the qos-nslp-02 draft. Seems there were >> >quite some details added. >> > >> >As for the RZR proposed, it is different from the normal zero >> >reservation using the QSPEC. It is more like another version of the >> >TEAR. Here below are some of the reasons that the RZR is >> needed in the >> >qos-nslp. >> > >> >1) The RZR is for a QoS NSLP layer CRN to put states over >> old path to >> >"dormant" mode. It is not simply set corresponding QSPEC to >> zero. E.g. >> >it could indicate the QNE for other special treatment, >> gradual reduce >> >of resource, etc. The action to be taken at each node is as you >> >mentioned a policy issue. Using the normal QSPEC to set to >> resource to >> >zero could not achieve this. >> > >> >2) Using the zero QSPEC would cause the QNE lost information >> about the >> >old state. It is not good for the restore process. A RZR >> option instead >> >could allow QNE retain the original state information, even >> the QSPEC. >> > >> >3) The tear down RESERV message may not carry QSPEC object. In this >> >case, an RZR option, similar to the TEAR, would be more >> suitable than >> >an extra QSPEC that puts burden on the network. >> > >> >4) To use the current QSPEC to indicate the RZR requires >> each QoS model >> >to generate a QSPEC with zero resources involved. It could >> be heavy for >> >the QNE. >> > >> >Besides above, I feel that the lacking part in the current qos-nslp >> >draft is how the RZR is used. Supposedly, the RZR should replace the >> >TEAR RESERV message to be sent from an QoS NSLP layer CRN. >> Since a CRN >> >could be any QNE, this behavior should be defined in the QoS NSLP. >> >Also, how the corresponding QNE response to the RZR should be >> >explained. >> > >> >Other than that, how the return to the old path is >> recognized, and how >> >to restore and reuse the state over the old path could be >> incorporated >> >into the qos-nslp draft as well. >> > >> >[/CH] >> > >> >> - ability to retain/remove state on the old path: supported >> >> in QoS NSLP (with SII) but the decision to keep state is a >> >> policy issue at the QNE, not indicated by MN >> > >> >[CH] Although the QNE could decide how to deal with the old >> state, it >> >still needs information from other nodes to make the decision. For >> >example, how would the QNE know the MN is doing multi-homing >> with the >> >indication from the MN? Of course, the QNE could decide how >> to react at >> >this indication according to its local policy. [/CH] >> > >> > >> >> What you propose that is currently not there: >> >> - MN indication of desire to maintain old path state. We could do >> >> this via a flag in the header which is minimal impact but I am >> >> concerned about: >> >> >> >> 1. security: can be solved by making support optional and >> leave the >> >> QNE the freedom to disregard it 2. relation to charging, >> ...: if it >> >> is just an indication, not mandatory, who will be charged for >> >> maintaining the reservation >> >> >> >> Have you thought about these issues? >> > >> >[CH] You are correct that a flag could achieve the purpose >> at most of >> >the time. But, as we briefly described in the draft that in certain >> >case, the Flow-ID is needed, and a flag is necessary for each of the >> >FLOW-ID. >> > >> >As for the security, the indication (flag) would be bundled with the >> >RESERV (or the corresponding RESPONSE) of the new path. It should >> >maintain the same security level as the RESERV message. In >> case the MN >> >is not the QNE, the communication would be between MN and a >> NSIS proxy, >> >which would be out of scope of the draft. >> > >> >Since this option is to be indicated in the reservation process over >> >the new path, the QoS NSLP layer CRN has already been discovered (at >> >least RESERV could indicate that), some cookies could used for >> >enhancing the security of the message. For example, if the RESERV is >> >send from CRN to MN, the CRN could include a cookie in the >> RESERV, and >> >MN can make use the cookie to secure its RESPONSE or NOTIFY >> to the CRN >> >that indicates it's desire. >> > >> >As for the charging, the MN should be charged for maintaining the >> >reservation, since it's requested by the MN. (could be a special >> >service subscription option? Or QoS level?) If the MN does >> not indicate >> >the preservation, reservation could be just torn down according to >> >local policy. >> > >> >[/CH] >> > >> >> Best regards, >> >> Sven Van den Bosch >> >> >> >> >> >> >> > >> > >> > >> > >> > >> >_______________________________________________ >> >nsis mailing list >> >nsis@ietf.org >> >https://www1.ietf.org/mailman/listinfo/nsis >> >> Cheers, >> Yuming >> 2004-02-19 >> ---------------- Yuming Wang ----------------- >> NGIT Research Group, ITEC R&D Center, EI Dpt., >> HuaZhong University of Science and Technology. >> Email: acer_wym@sina.com >> Home Page: http://itec.hust.edu.cn/wym.htm >> TEL: +86-27-87453207 FAX: +86-27-87456436 >> ---- >> >> >> >> > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > >. Yuming 2004-02-19 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 04:49:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11460 for ; Thu, 19 Feb 2004 04:49:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atknp-0001jc-S2 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:49:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J9n5lC006633 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 04:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkno-0001in-9Z; Thu, 19 Feb 2004 04:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atkmu-0001hS-T1 for nsis@optimus.ietf.org; Thu, 19 Feb 2004 04:48:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11419 for ; Thu, 19 Feb 2004 04:48:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atkmr-0001r5-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:48:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atkly-0001oY-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:47:10 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1AtklB-0001lg-00 for nsis@ietf.org; Thu, 19 Feb 2004 04:46:21 -0500 Received: (qmail 57751 invoked from network); 19 Feb 2004 09:46:13 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.158 with SMTP; 19 Feb 2004 09:46:13 -0000 Date: Thu, 19 Feb 2004 17:47:51 +0800 From: "Yuming Wang" To: "nsis" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Datagram mode of GIMPS 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 all, In the datagram mode of GIMPS, upstream messages are sent UDP encapsulated directly to the signaling destination; but, why downstream messages are sent towards the flow receiver with a router alert option? Thanks! Cheers, Yuming 2004-02-19 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 06:17:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14348 for ; Thu, 19 Feb 2004 06:17:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmAv-0008Rn-VN for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 06:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JBH1wd032456 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 06:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmAv-0008RN-On; Thu, 19 Feb 2004 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmA5-0008QS-7X for nsis@optimus.ietf.org; Thu, 19 Feb 2004 06:16:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14323 for ; Thu, 19 Feb 2004 06:16:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmA1-0006Vr-00 for nsis@ietf.org; Thu, 19 Feb 2004 06:16:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atm97-0006TW-00 for nsis@ietf.org; Thu, 19 Feb 2004 06:15:10 -0500 Received: from smtp0.libero.it ([193.70.192.33]) by ietf-mx with esmtp (Exim 4.12) id 1Atm8j-0006R2-00 for nsis@ietf.org; Thu, 19 Feb 2004 06:14:45 -0500 Received: from libero.it (193.70.192.38) by smtp0.libero.it (7.0.020-DD01) id 3F6F1CE301284F63 for nsis@ietf.org; Thu, 19 Feb 2004 12:14:15 +0100 Date: Thu, 19 Feb 2004 12:14:14 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.168 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Session in NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, In RFC 2205 (http://ietf.org/rfc/rfc2205.txt?number=3D2205= ) a RSVP session is defined as "a data flow with a particular destinati= on and transport-layer protocol" and it "is defined by the triple: (Des= tAddress, ProtocolId [, DstPort])" NSIS framework (http://www.ietf.org= /internet-drafts/draft-ietf-nsis-fw-05.txt) defines session as "applic= ation layer flow of information for which some network control state info= rmation is to be manipulated or monitored". Session_ID is a random n= umber but which parameters can be used to represent a session? Regar= ds, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 06:18:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14370 for ; Thu, 19 Feb 2004 06:18:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmBs-000072-QZ for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 06:18:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JBI0Mq000395 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 06:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmBs-00006H-H4; Thu, 19 Feb 2004 06:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmB1-0008SL-M8 for nsis@optimus.ietf.org; Thu, 19 Feb 2004 06:17:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14341 for ; Thu, 19 Feb 2004 06:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmAx-0006Y3-00 for nsis@ietf.org; Thu, 19 Feb 2004 06:17:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtmA5-0006WV-00 for nsis@ietf.org; Thu, 19 Feb 2004 06:16:09 -0500 Received: from smtp0.libero.it ([193.70.192.33]) by ietf-mx with esmtp (Exim 4.12) id 1Atm9l-0006Tw-00 for nsis@ietf.org; Thu, 19 Feb 2004 06:15:49 -0500 Received: from libero.it (193.70.192.38) by smtp0.libero.it (7.0.020-DD01) id 3F6F1CE30128506C for nsis@ietf.org; Thu, 19 Feb 2004 12:15:20 +0100 Date: Thu, 19 Feb 2004 12:15:20 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.168 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Session in NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, In RFC 2205 (http://ietf.org/rfc/rfc2205.txt?number=3D2205= ) a RSVP session is defined as "a data flow with a particular destinati= on and transport-layer protocol" and it "is defined by the triple: (Des= tAddress, ProtocolId [, DstPort])" NSIS framework (http://www.ietf.org= /internet-drafts/draft-ietf-nsis-fw-05.txt) defines session as "applic= ation layer flow of information for which some network control state info= rmation is to be manipulated or monitored". Session_ID is a random n= umber but which parameters can be used to represent a session? Regar= ds, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 07:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15723 for ; Thu, 19 Feb 2004 07:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmvQ-0003dQ-0t for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 07:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JC53EI013957 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 07:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmvN-0003cC-CA; Thu, 19 Feb 2004 07:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmuS-0003an-IN for nsis@optimus.ietf.org; Thu, 19 Feb 2004 07:04:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15661 for ; Thu, 19 Feb 2004 07:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmuO-0000in-00 for nsis@ietf.org; Thu, 19 Feb 2004 07:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtmtP-0000fV-00 for nsis@ietf.org; Thu, 19 Feb 2004 07:03:00 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AtmsR-0000aU-00 for nsis@ietf.org; Thu, 19 Feb 2004 07:01:59 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1JC1xQ16919; Thu, 19 Feb 2004 13:01:59 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1JC1xT16112; Thu, 19 Feb 2004 13:01:59 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Feb 2004 13:01:22 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DB3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] Session in NSIS Date: Thu, 19 Feb 2004 13:01:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 elena, in nsis the concept of a session is separated from the flow identifier. the advantage of this approach is also visible in many of the nsis mobility drafts. you can find the latest version (a merge of previous drafts) at: http://www.tschofenig.priv.at/drafts/draft-manyfolks-signaling-protocol-mobility -00.txt you might also want to take a look at : http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-sid-00.txt this draft describes alternative ways to create the session id with security properties. as a summary, the session id allows you to change the flow identfier - during the lifetime of a session (e.g., due to mobility, IPv6 privacy,...), - somewhere along the path and - to group different flows together does this answer your question? ciao hannes > -----Original Message----- > From: Elena Scialpi [mailto:scel@inwind.it] > Sent: Thursday, February 19, 2004 12:15 PM > To: nsis > Subject: [NSIS] Session in NSIS > > > > > Hi all, > > In RFC 2205 (http://ietf.org/rfc/rfc2205.txt?number=2205) a > RSVP session is defined as "a data > flow with a particular destination and transport-layer > protocol" and it "is defined by the triple: > (DestAddress, ProtocolId [, DstPort])" > > NSIS framework > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt > ) defines session as > "application layer flow of information for which some network > control state information is to be > manipulated or monitored". > > Session_ID is a random number but which parameters can be > used to represent a session? > > > Regards, > Elena > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Feb 19 09:17:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19449 for ; Thu, 19 Feb 2004 09:17:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtozD-0000Fr-MU for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 09:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JEH7gs000978 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 09:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atoz8-0000Ed-Av; Thu, 19 Feb 2004 09:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atoya-0000CD-Qx for nsis@optimus.ietf.org; Thu, 19 Feb 2004 09:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19392 for ; Thu, 19 Feb 2004 09:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtoyY-0006Vf-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:16:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atoxc-0006Qg-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:15:29 -0500 Received: from smtp2.libero.it ([193.70.192.52]) by ietf-mx with esmtp (Exim 4.12) id 1Atox0-0006Ku-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:14:50 -0500 Received: from libero.it (193.70.192.38) by smtp2.libero.it (7.0.020-DD01) id 3F6F0DA001282680; Thu, 19 Feb 2004 15:14:49 +0100 Date: Thu, 19 Feb 2004 15:14:07 +0100 Message-Id: Subject: RE: [NSIS] Session in NSIS MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "hannes\.tschofenig" , "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.168 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable ---------- Initial Header ----------- From : nsis-admin@ietf.org=0D = To : "Elena Scialpi" scel@inwind.it,"nsis" nsis@ietf.org Cc = : Date : Thu, 19 Feb 2004 13:01:40 +0100 Subject : RE: [NSI= S] Session in NSIS > hi elena, > > in nsis the concept of a sessio= n is separated from the flow identifier. the > advantage of this approac= h is also visible in many of the nsis mobility > drafts. you can find th= e latest version (a merge of previous drafts) at: > http://www.tschofeni= g.com/drafts/draft-manyfolks-signaling-protocol-mobility > -00.txt > =0D = > you might also want to take a look at : > http://www.tschofenig.priv.at/dr= afts/draft-tschofenig-nsis-sid-00.txt > > this draft describes alterna= tive ways to create the session id with security > properties. > > = as a summary, the session id allows you to change the flow identfier > -= during the lifetime of a session (e.g., due to mobility, IPv6 > privacy= ,...), > - somewhere along the path and > - to group different flows t= ogether > > does this answer your question? I haven't understand= very well the concept of session. I think that a session is between tw= o specific nodes (sender and receiver of signaling) while in RSVP it c= onsider only one node. Is it right? Thanks for your reply, Elena =0D = > > ciao > hannes > > > > -----Original Message----- > >= From: Elena Scialpi [mailto:scel@inwind.it] > > Sent: Thursday, Februar= y 19, 2004 12:15 PM > > To: nsis > > Subject: [NSIS] Session in NSIS=0D = > > > > > > > > > > Hi all, > > > > In RFC 2205 (http://ietf.o= rg/rfc/rfc2205.txt?number=3D2205) a > > RSVP session is defined as "a d= ata > > flow with a particular destination and transport-layer > > pr= otocol" and it "is defined by the triple: > > (DestAddress, ProtocolId = [, DstPort])" > > > > NSIS framework > > (http://www.ietf.org/intern= et-drafts/draft-ietf-nsis-fw-05.txt > > ) defines session as > > "app= lication layer flow of information for which some network > > control s= tate information is to be > > manipulated or monitored". > > > > Ses= sion_ID is a random number but which parameters can be > > used to repr= esent a session? > > > > > > Regards, > > Elena > > > > > > _= ______________________________________________ > > nsis mailing list > = > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > =0D = > > _______________________________________________ > nsis mailing lis= t > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 09:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19834 for ; Thu, 19 Feb 2004 09:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpBj-0001p8-VE for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 09:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JEU3HX006991 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 09:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpBi-0001oE-0P; Thu, 19 Feb 2004 09:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpB8-0001nM-M9 for nsis@optimus.ietf.org; Thu, 19 Feb 2004 09:29:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19766 for ; Thu, 19 Feb 2004 09:29:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtpB6-0007C2-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:29:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtpA3-00078C-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:28:20 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Atp9H-000752-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:27:31 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1JERUN10199; Thu, 19 Feb 2004 15:27:30 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1JERUT13563; Thu, 19 Feb 2004 15:27:30 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Feb 2004 15:26:52 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DBD@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] Session in NSIS Date: Thu, 19 Feb 2004 15:27:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 elena, ~ snip ~ > > I haven't understand very well the concept of session. > I think that a session is between two specific nodes (sender > and receiver of signaling) while in > RSVP it consider only one node. > Is it right? not quite. the session id remains the same over all traversed nsis entities along the path. you can compare this with figure 1 (of the nsis framework draft). Sender Receiver +-----------+ +----+ +----+ +----+ +-----------+ |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application| | +--+ | |+--+| |+--+| +----+ | +--+ | | |NE|====|======||NE||======||NE||==================|===|NE| | | +--+ | |+--+| |+--+| | +--+ | +-----------+ +----+ +----+ +-----------+ +--+ |NE| = NSIS ==== = Signaling ---> = Data flow messages +--+ Entity Messages (unidirectional) Figure 1: Simple Signaling and Data Flows in figure 1 all NEs use the same session id. it is not modified. let's assume that R1 is a NAT then the flow identifier is modified but the session id remains the same. in rsvp there was no requirement to support mobility (or similar functionality which causes a flow id modificiation). hence there was no need to introduce a separate identfier and only the flow identifier was used. in nsis we use both - the flow identifier and the session identifier. both identifiers carried via nsis signaling along the path between the ni and nr. does this make more sense? ciao hannes > > Thanks for your reply, > Elena > ciao hannes > > > > > > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Elena Scialpi [mailto:scel@inwind.it] > > > Sent: Thursday, February 19, 2004 12:15 PM > > > To: nsis > > > Subject: [NSIS] Session in NSIS > > > > > > > > > > > > > > > > Hi all, > > > > > > In RFC 2205 (http://ietf.org/rfc/rfc2205.txt?number=2205) a > > > RSVP session is defined as "a data > > > flow with a particular destination and transport-layer > > > protocol" and it "is defined by the triple: > > > (DestAddress, ProtocolId [, DstPort])" > > > > > > NSIS framework > > > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt > > > ) defines session as > > > "application layer flow of information for which some network > > > control state information is to be > > > manipulated or monitored". > > > > > > Session_ID is a random number but which parameters can be > > > used to represent a session? > > > > > > > > > Regards, > > > Elena > > > > > > > > > _______________________________________________ > > > 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 exim@www1.ietf.org Thu Feb 19 09:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21204 for ; Thu, 19 Feb 2004 09:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atpdm-0004kd-1P for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 09:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JEx1aX018248 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 09:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atpdl-0004k5-B3; Thu, 19 Feb 2004 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atpcx-0004dG-AA for nsis@optimus.ietf.org; Thu, 19 Feb 2004 09:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21157 for ; Thu, 19 Feb 2004 09:58:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atpcv-0001Br-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atpbv-000190-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:57:08 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atpay-00015Q-00 for nsis@ietf.org; Thu, 19 Feb 2004 09:56:08 -0500 Received: from Olivier (dhcp192-236.enst.fr [137.194.192.236]) by infres.enst.fr (Postfix) with SMTP id 92CFD31EF for ; Thu, 19 Feb 2004 15:56:01 +0100 (MET) Message-ID: <005201c3f6f8$7a242fa0$ecc0c289@Olivier> From: "Thanh Tra LUU" To: "nsis" References: Subject: Re: [NSIS] Session in NSIS Date: Thu, 19 Feb 2004 15:55:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, elena, if there is no change of address, flow-id is enough to globally identify an signaling session. to help a signaling entity recognize a session, something is required other than flow-id. hannes, the session-id can be randomly created, however, do you think which signaling entity should do it (NI, NR or other entities). i read your sid draft, but it did not answer completely me. Nary Tra ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 11:13:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25493 for ; Thu, 19 Feb 2004 11:13:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqnL-0002ce-PW for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 11:12:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JGCxQ1010067 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 11:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtqnK-0002cG-W7; Thu, 19 Feb 2004 11:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atqmq-0002bG-MG for nsis@optimus.ietf.org; Thu, 19 Feb 2004 11:12:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25456 for ; Thu, 19 Feb 2004 11:12:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atqmp-0005av-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atqlx-0005XK-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:11:34 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AtqlH-0005TF-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:10:51 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1JGAn402518; Thu, 19 Feb 2004 17:10:50 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1JGAnT03921; Thu, 19 Feb 2004 17:10:49 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Feb 2004 17:10:12 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DC1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" , nsis Subject: RE: [NSIS] Session in NSIS Date: Thu, 19 Feb 2004 17:10:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Nary Tra, ~ snip~ > hannes, the session-id can be randomly created, however, do > you think which > signaling entity should do it (NI, NR or other entities). i > read your sid > draft, but it did not answer completely me. i personally think that it should be done by the ni. if we create the session id with cryptographic properties (such as a hash of a public key) then the answer depends a bit on the outcome of the mobility discussion. i have described the problems at some level of detail in the manyfolks-mobility draft. unfortunately, i haven't seen many comments yet. (actually, i haven't seen many comments on the sid draft as well.) ciao hannes > > Nary Tra > ENST, Paris. > > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Feb 19 11:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26466 for ; Thu, 19 Feb 2004 11:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrHO-0006M1-TN for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 11:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JGi29C024404 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 11:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrHN-0006Kj-GL; Thu, 19 Feb 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrGc-0006Hi-Cu for nsis@optimus.ietf.org; Thu, 19 Feb 2004 11:43:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26432 for ; Thu, 19 Feb 2004 11:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtrGb-00078m-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:43:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtrFd-00077A-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:42:14 -0500 Received: from smtp1.libero.it ([193.70.192.51]) by ietf-mx with esmtp (Exim 4.12) id 1AtrFM-00075a-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:41:56 -0500 Received: from libero.it (193.70.192.38) by smtp1.libero.it (7.0.020-DD01) id 3F6F0E4501294173; Thu, 19 Feb 2004 17:41:50 +0100 Date: Thu, 19 Feb 2004 17:41:19 +0100 Message-Id: Subject: RE: [NSIS] Session in NSIS MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "hannes\.tschofenig" , "luu" , "nsis" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.168 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Thanks for your comments! I have understand session and session_ID c= oncept but I have an other question. In your opinion, which elements are= useful in a Session class? It's a detail, but I'd like to know your o= pinions! Many thanks, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 11:44:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26470 for ; Thu, 19 Feb 2004 11:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrHO-0006M2-Ti for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 11:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JGi2l6024407 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 11:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrHN-0006Kb-1y; Thu, 19 Feb 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrGb-0006Hd-Ti for nsis@optimus.ietf.org; Thu, 19 Feb 2004 11:43:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26429 for ; Thu, 19 Feb 2004 11:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtrGa-00078h-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:43:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtrFd-000772-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:42:13 -0500 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 1AtrFC-00075b-00 for nsis@ietf.org; Thu, 19 Feb 2004 11:41:46 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 1009) by s2.ifi.informatik.uni-goettingen.de with local; Thu, 19 Feb 2004 17:41:43 +0100 References: <2A8DB02E3018D411901B009027FD3A3F04685DC1@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685DC1@mchp905a.mch.sbs.de> From: "Xiaoming Fu" To: Tschofenig Hannes Cc: "'Thanh Tra LUU'" , nsis Date: Thu, 19 Feb 2004 17:41:43 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: fu@s2.ifi.informatik.uni-goettingen.de Message-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: Session in NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tschofenig Hannes writes: > hi Nary Tra, > > ~ snip~ > >> hannes, the session-id can be randomly created, however, do >> you think which >> signaling entity should do it (NI, NR or other entities). i >> read your sid >> draft, but it did not answer completely me. > i personally think that it should be done by the ni. if we create the > session id with cryptographic properties (such as a hash of a public key) I agree NI could be the place. Nevertheless, it might be a concern if we create reasonable amount of sessions in a single NI - profiling of the our implementation showed the crypto-sid generation costs 58% of the overall processing in NI in repeated experiments. Thus, it should be taken into consideration in mobilility considerations, given the limited computing power in mobiles... however if we put NR into the place of sid generator, some servers can suffer certain dos attacks (if i'm right). Xiaoming > then the answer depends a bit on the outcome of the mobility discussion. i > have described the problems at some level of detail in the > manyfolks-mobility draft. unfortunately, i haven't seen many comments yet. > (actually, i haven't seen many comments on the sid draft as well.) > > ciao > hannes > >> >> Nary Tra >> ENST, Paris. >> >> >> >> _______________________________________________ >> 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 exim@www1.ietf.org Thu Feb 19 20:24:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09587 for ; Thu, 19 Feb 2004 20:24:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzOg-0002Zl-Mb for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 20:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K1O6cb009886 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 20:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzOb-0002Yg-Fg; Thu, 19 Feb 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzO7-0002WP-Jv for nsis@optimus.ietf.org; Thu, 19 Feb 2004 20:23:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09527 for ; Thu, 19 Feb 2004 20:23:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtzO5-0003J7-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:23:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtzNC-0003GI-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:22:35 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AtzML-000392-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:21:41 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id i1K1L8cK025599; Fri, 20 Feb 2004 10:21:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id i1K1LAn12797; Fri, 20 Feb 2004 10:21:10 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id i1K1L9d13212; Fri, 20 Feb 2004 10:21:09 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml25) id i1K1L9a13858; Fri, 20 Feb 2004 10:21:09 +0900 (JST) Received: from [10.68.136.41] (localhost [127.0.0.1]) by soml25.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i1K1L8w13853; Fri, 20 Feb 2004 10:21:08 +0900 (JST) Date: Fri, 20 Feb 2004 10:21:11 +0900 From: Takako Sanda To: acer_wym@sina.com Subject: Re: [NSIS] Draft for pre CRN discovery and fast state installation Cc: nsis In-Reply-To: References: Message-Id: <20040220100825.AE5A.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Yuming Wang, Please see inline. > IMO, If the MN still cannot communicate with the AR1 (because AR1 is too > far from the MN, and the signaling strength is so weak), path1 should not > be the candidate path. > Assume that MN is currently connected to AR0, and AR1 & AR2 are neighboring ARs > of AR0, but MN can only get signaling strength of AR0 and AR2, that means, it > can only communicate with AR0 and AR2, then, path2 will be the candidate path > and path1 will not be necessary to be. What do you mean "signal strength of AR0 and AR2"? Is it radio signal, such as beacon, from APs connecting to AR0 or AR2? > Now that the MN can communicate with AR2, so, why it cannot directly initiate > resource reservation signaling on path2? > I don't know whether I am right. If my understanding for your "signal strength of AR0 and AR2" is correct, MN cannot communicate with AR2 in this stage because MN does not complete even L2 level association to AP connecting to AR2. If you are assuming that MN has multiple radio interfaces and can connect to multiple ARs at the same time, it is out of scope of my I-D. --Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 19 20:41:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10521 for ; Thu, 19 Feb 2004 20:41:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atzf5-00045M-Ta for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 20:41:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K1f33f015698 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 20:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atzf5-000455-CT; Thu, 19 Feb 2004 20:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atzev-00043z-2f for nsis@optimus.ietf.org; Thu, 19 Feb 2004 20:40:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10508 for ; Thu, 19 Feb 2004 20:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atzes-0004Zm-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:40:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atze0-0004VP-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:39:56 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AtzdJ-0004O5-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:39:13 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1K1TnEE001657; Fri, 20 Feb 2004 09:29:56 +0800 (SGT) From: "Cheng Hong" To: "'Xiaoming Fu'" , "'Tschofenig Hannes'" Cc: "'Thanh Tra LUU'" , "'nsis'" Subject: RE: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 09:37:55 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <004e01c3f752$2c0686b0$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 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 Xiaming, > implementation showed the crypto-sid generation costs 58% of > the overall > processing in NI in repeated experiments. Thus, it should be > taken into > consideration in mobilility considerations, given the limited > computing > power in mobiles... however if we put NR into the place of > sid generator, > some servers can suffer certain dos attacks (if i'm right). Xiaoming It is not necessary that the NI always be the mobile. Also, wouldn't the computation cost just an implementation issue? If it is that computational intensive, could it be placed into certain hardware, e.g. some smart card? Another issue for NR generating the id would mean that the first message sent from NI would not carry the SID information. Does this have any impact on the design of the protocls? Cheers Cheng Hong > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Xiaoming Fu > Sent: Friday, February 20, 2004 12:42 AM > To: Tschofenig Hannes > Cc: 'Thanh Tra LUU'; nsis > Subject: [NSIS] Re: Session in NSIS > > > Tschofenig Hannes writes: > > > hi Nary Tra, > > > > ~ snip~ > > > >> hannes, the session-id can be randomly created, however, do > >> you think which > >> signaling entity should do it (NI, NR or other entities). i > >> read your sid > >> draft, but it did not answer completely me. > > i personally think that it should be done by the ni. if we > create the > > session id with cryptographic properties (such as a hash of > a public > > key) > > I agree NI could be the place. Nevertheless, it might be a > concern if we > create reasonable amount of sessions in a single NI - > profiling of the our > implementation showed the crypto-sid generation costs 58% of > the overall > processing in NI in repeated experiments. Thus, it should be > taken into > consideration in mobilility considerations, given the limited > computing > power in mobiles... however if we put NR into the place of > sid generator, > some servers can suffer certain dos attacks (if i'm right). Xiaoming > > > then the answer depends a bit on the outcome of the mobility > > discussion. i have described the problems at some level of > detail in > > the manyfolks-mobility draft. unfortunately, i haven't seen many > > comments yet. (actually, i haven't seen many comments on > the sid draft > > as well.) > > > > ciao > > hannes > > > >> > >> Nary Tra > >> ENST, Paris. > >> > >> > >> > >> _______________________________________________ > >> 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 exim@www1.ietf.org Thu Feb 19 20:51:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10983 for ; Thu, 19 Feb 2004 20:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atzok-0004Zn-OW for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 20:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K1p2UR017562 for nsis-archive@odin.ietf.org; Thu, 19 Feb 2004 20:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atzoj-0004Yi-JZ; Thu, 19 Feb 2004 20:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzoK-0004Xf-5p for nsis@optimus.ietf.org; Thu, 19 Feb 2004 20:50:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10917 for ; Thu, 19 Feb 2004 20:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtzoH-0005NB-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:50:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtznI-0005HN-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:49:33 -0500 Received: from [202.106.187.143] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1AtzmL-0005AG-00 for nsis@ietf.org; Thu, 19 Feb 2004 20:48:33 -0500 Received: (qmail 32475 invoked from network); 20 Feb 2004 01:48:23 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.143 with SMTP; 20 Feb 2004 01:48:23 -0000 Date: Fri, 20 Feb 2004 09:50:00 +0800 From: "Yuming Wang" To: "Takako Sanda" Cc: "nsis" Subject: Re: Re: [NSIS] Draft for pre CRN discovery and fast state installation X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Takako Sanda, >Hi Yuming Wang, > >Please see inline. > >> IMO, If the MN still cannot communicate with the AR1 (because AR1 is too >> far from the MN, and the signaling strength is so weak), path1 should not >> be the candidate path. >> Assume that MN is currently connected to AR0, and AR1 & AR2 are neighboring ARs >> of AR0, but MN can only get signaling strength of AR0 and AR2, that means, it >> can only communicate with AR0 and AR2, then, path2 will be the candidate path >> and path1 will not be necessary to be. > >What do you mean "signal strength of AR0 and AR2"? >Is it radio signal, such as beacon, from APs connecting to AR0 or AR2? Right. > >> Now that the MN can communicate with AR2, so, why it cannot directly initiate >> resource reservation signaling on path2? >> I don't know whether I am right. > >If my understanding for your "signal strength of AR0 and AR2" is correct, >MN cannot communicate with AR2 in this stage because MN does not >complete even L2 level association to AP connecting to AR2. > > >If you are assuming that MN has multiple radio interfaces and can >connect to multiple ARs at the same time, it is out of scope of my I-D. > This is exactly what I mean. I've got it, thanks! :-) Yuming 2004-02-20 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 04:25:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11554 for ; Fri, 20 Feb 2004 04:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6ti-0005fk-Pp for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 04:24:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9OcMK021780 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 04:24:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6te-0005eV-Qe; Fri, 20 Feb 2004 04:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6oL-00054M-0L for nsis@optimus.ietf.org; Fri, 20 Feb 2004 04:19:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11291 for ; Fri, 20 Feb 2004 04:19:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6oI-0004lh-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6nF-0004gz-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:17:58 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1Au6mZ-0004ci-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:17:15 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i1K9H9Ci000924; Fri, 20 Feb 2004 10:17:09 +0100 (MET) Message-ID: <001c01c3f792$51b702a0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Yuming Wang" , "nsis" References: Subject: Re: [NSIS] Datagram mode of GIMPS Date: Fri, 20 Feb 2004 10:17:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 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 Yuming This is similar to how RSVP (see, e.g., RFC2205) operates. The router alert option may be used in the fast forwarding path of a high-speed router to detect datagrams that require special processing. Best Regards, Georgios ----- Original Message ----- From: "Yuming Wang" To: "nsis" Sent: Thursday, February 19, 2004 10:47 AM Subject: [NSIS] Datagram mode of GIMPS > Hi all, > > In the datagram mode of GIMPS, upstream messages are sent UDP encapsulated > directly to the signaling destination; but, why downstream messages are > sent towards the flow receiver with a router alert option? > > Thanks! > > Cheers, > Yuming > 2004-02-19 > ---------------- Yuming Wang ----------------- > NGIT Research Group, ITEC R&D Center, EI Dpt., > HuaZhong University of Science and Technology. > Email: acer_wym@sina.com > Home Page: http://itec.hust.edu.cn/wym.htm > TEL: +86-27-87453207 FAX: +86-27-87456436 > ---- > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Feb 20 04:25:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11571 for ; Fri, 20 Feb 2004 04:25:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6tm-0005i4-Cl for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 04:24:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9OgqE021911 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 04:24:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6tl-0005hH-TH; Fri, 20 Feb 2004 04:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6rs-0005Nl-Uy for nsis@optimus.ietf.org; Fri, 20 Feb 2004 04:22:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11498 for ; Fri, 20 Feb 2004 04:22:41 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6rq-00051B-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:22:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6qs-0004z5-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:21:43 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Au6q1-0004xA-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:20:49 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1K9Kles009030; Fri, 20 Feb 2004 10:20:47 +0100 To: "Cheng Hong" Cc: , , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 20 Feb 2004 10:20:45 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/20/2004 10:20:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] Re: FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP 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 Cheng Hong, Thanks for your replies. Please see my comments inline. Best regards, Sven "Cheng Hong" on 18/02/2004 05:22:47 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , , Subject: FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP Hi Sven, Thanks a lot for reviewing the draft. Please see some response to the questions inline: Best regards Cheng Hong PS: A copy of the draft is available at link below: http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, February 17, 2004 6:41 PM > To: hcheng@psl.com.sg; khling@psl.com.sg > Cc: nsis@ietf.org > Subject: discussion on draft-cheng-mobility-issues-01.txt > impact on QoS NSLP > > > Hi, > > I have gone through your draft. If I understand correctly, > the issues you raise are: > - the need for the QoS NSLP to support a change of FlowID for > the same sessionID (e.g. multi-homing) > - the need to deal intelligently with very frequent > (ping-pong) mobility events [CH]: That is correct. [/CH] > I agree with the need for both types of functionality, but I > don't think the impact on QoS NSLP is very large. From what > you propose in the draft, the current version of the QoS NSLP > (draft-ietf-nsis-qos-nslp-02.txt) > supports: > - ability to reserve zero resources [CH]: I have browsed through the qos-nslp-02 draft. Seems there were quite some details added. As for the RZR proposed, it is different from the normal zero reservation using the QSPEC. It is more like another version of the TEAR. Here below are some of the reasons that the RZR is needed in the qos-nslp. 1) The RZR is for a QoS NSLP layer CRN to put states over old path to "dormant" mode. It is not simply set corresponding QSPEC to zero. E.g. it could indicate the QNE for other special treatment, gradual reduce of resource, etc. The action to be taken at each node is as you mentioned a policy issue. Using the normal QSPEC to set to resource to zero could not achieve this. Sven>> I still don't understand why. If you want to gradually reduce resources for instance. this can be achieved by refreshing on the old path with decrementing resource requirements. The indication of what you call 'special treatment' is always possible. We have for instance QoS-model specific control information that can be used for that. 2) Using the zero QSPEC would cause the QNE lost information about the old state. It is not good for the restore process. A RZR option instead could allow QNE retain the original state information, even the QSPEC. Sven>> What the CRN QNE could do is send a RESERVE with zero resources and keep the QSpec locally in order to be used once the resources on the old path become needed again. Wouldn't this achieve the same purpose? 3) The tear down RESERV message may not carry QSPEC object. In this case, an RZR option, similar to the TEAR, would be more suitable than an extra QSPEC that puts burden on the network. Sven>> Could you clarfiy this point? 4) To use the current QSPEC to indicate the RZR requires each QoS model to generate a QSPEC with zero resources involved. It could be heavy for the QNE. Sven>> I don't think it will be heavier than RZR since you don't need to put anything in the QSpec (zero resources) Besides above, I feel that the lacking part in the current qos-nslp draft is how the RZR is used. Supposedly, the RZR should replace the TEAR RESERV message to be sent from an QoS NSLP layer CRN. Since a CRN could be any QNE, this behavior should be defined in the QoS NSLP. Also, how the corresponding QNE response to the RZR should be explained. Other than that, how the return to the old path is recognized, and how to restore and reuse the state over the old path could be incorporated into the qos-nslp draft as well. Sven>> I agree we could better explain how RESERVE with zero resources can be used to address the points that you raise. [/CH] > - ability to retain/remove state on the old path: supported > in QoS NSLP (with SII) but the decision to keep state is a > policy issue at the QNE, not indicated by MN [CH] Although the QNE could decide how to deal with the old state, it still needs information from other nodes to make the decision. For example, how would the QNE know the MN is doing multi-homing with the indication from the MN? Of course, the QNE could decide how to react at this indication according to its local policy. [/CH] > What you propose that is currently not there: > - MN indication of desire to maintain old path state. We > could do this via a flag in the header which is minimal > impact but I am concerned about: > > 1. security: can be solved by making support optional and > leave the QNE the freedom to disregard it 2. relation to > charging, ...: if it is just an indication, not mandatory, > who will be charged for maintaining the reservation > > Have you thought about these issues? [CH] You are correct that a flag could achieve the purpose at most of the time. But, as we briefly described in the draft that in certain case, the Flow-ID is needed, and a flag is necessary for each of the FLOW-ID. Sven>> I don't follow you completely here. Do you mean that a single RESERVE message of a multi-homed host needs to contain more than one flowID? Or would you send different RESERVEs for each flowID and know that they can share resources on common paths because they belong to the same sessionID? As for the security, the indication (flag) would be bundled with the RESERV (or the corresponding RESPONSE) of the new path. It should maintain the same security level as the RESERV message. In case the MN is not the QNE, the communication would be between MN and a NSIS proxy, which would be out of scope of the draft. Since this option is to be indicated in the reservation process over the new path, the QoS NSLP layer CRN has already been discovered (at least RESERV could indicate that), some cookies could used for enhancing the security of the message. For example, if the RESERV is send from CRN to MN, the CRN could include a cookie in the RESERV, and MN can make use the cookie to secure its RESPONSE or NOTIFY to the CRN that indicates it's desire. Sven>> OK, if it is the expression of a 'desire' the security risks are less. I was worried you wanted to mandate the CRN to honour the MN's desire. As for the charging, the MN should be charged for maintaining the reservation, since it's requested by the MN. (could be a special service subscription option? Or QoS level?) If the MN does not indicate the preservation, reservation could be just torn down according to local policy. Sven>> If it is a specific QoS level, we don't need it in the QoS NSLP. QoS models are described in other drafts. Is the conclusion of this discussion that: - we propose to the WG to foresee a flag that allows QNEs to indicate that they want resources on old paths be kept and refreshed - better explain how RESERVE with zero resources may be used to support this Would this address your issues? Best regards, Sven [/CH] > Best regards, > Sven Van den Bosch > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 05:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13187 for ; Fri, 20 Feb 2004 05:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7Tw-0000Tl-Jl for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 05:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KA24Xn001807 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 05:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7Tv-0000T0-BT; Fri, 20 Feb 2004 05:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7Tf-0000Se-Fw for nsis@optimus.ietf.org; Fri, 20 Feb 2004 05:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13177 for ; Fri, 20 Feb 2004 05:01:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Tb-00004i-00 for nsis@ietf.org; Fri, 20 Feb 2004 05:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au7Sg-00001o-00 for nsis@ietf.org; Fri, 20 Feb 2004 05:00:47 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Ru-0007hi-00 for nsis@ietf.org; Fri, 20 Feb 2004 04:59:58 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1K9p1iS018247; Fri, 20 Feb 2004 17:51:09 +0800 (SGT) From: "Cheng Hong" To: Cc: , , Date: Fri, 20 Feb 2004 17:59:06 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <000f01c3f798$30c3bdd0$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP 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: quoted-printable Hi Sven, Thanks a lot for your detail comment. I think my feeling is that the = RESERV with a zero QSPEC could achieve the purpose if the behavior of the QNE = for processing this type of RESERV message is well defined. But, this may = put some limit for the future extension, and therefore, it maybe better to = make it a separate object/option by analogy to the introduction of the TEAR = flag. Please see some furhter comments inline. >=20 > 1) The RZR is for a QoS NSLP layer CRN to put states over old=20 > path to "dormant" mode. It is not simply set corresponding=20 > QSPEC to zero. E.g. it could indicate the QNE for other=20 > special treatment, gradual reduce of resource, etc. The=20 > action to be taken at each node is as you mentioned a policy=20 > issue. Using the normal QSPEC to set to resource to zero=20 > could not achieve this. >=20 > Sven>> I still don't understand why. If you want to gradually reduce > resources for instance. this can be achieved by refreshing on=20 > the old path with decrementing resource requirements. The=20 > indication of what you call 'special treatment' is always=20 > possible. We have for instance QoS-model specific control=20 > information that can be used for that. [CH]=20 The point I tried to make is that if the zero QSPEC is used to achieve = this purpose, the QNE must be configured to interpret it in a specific way. Therefore, it is not that flexible. And make the RZR a separate object = would allow more information to be included. [/CH] > 2) Using the zero QSPEC would cause the QNE lost information=20 > about the old state. It is not good for the restore process.=20 > A RZR option instead could allow QNE retain the original=20 > state information, even the QSPEC. >=20 > Sven>> What the CRN QNE could do is send a RESERVE with zero=20 > resources=20 > Sven>> and > keep the QSpec locally in order to be used once the resources=20 > on the old path become needed again. Wouldn't this achieve=20 > the same purpose? [CH]=20 Yes. It can achieve the goal. But, CRN would need to update all the QNE = of the QSPEC when restoring the old path. [/CH] > 3) The tear down RESERV message may not carry QSPEC object.=20 > In this case, an RZR option, similar to the TEAR, would be=20 > more suitable than an extra QSPEC that puts burden on the network. >=20 > Sven>> Could you clarfiy this point? [CH] I am assuming that the QSPEC used to set the resource to zero would = still have all the fields included, just with all the parameters set to zero. Therefore, it takes more bits to indicate the same meaning than a RZR = flag (or something similar). Of course, if the zero QSPEC you meant is = something special, e.g. a simple header field, etc, it may be similar to the = proposed RZR object. [/CH] > 4) To use the current QSPEC to indicate the RZR requires each=20 > QoS model to generate a QSPEC with zero resources involved.=20 > It could be heavy for the QNE. >=20 > Sven>> I don't think it will be heavier than RZR since you=20 > don't need to > put anything in the QSpec (zero resources) [CH] Similar to the point above. Also, I am assuming that the QSPEC is = generated by the individual QoS models. So, it would be most costy to generate = than a generic QoS NSLP layer RZR flag/object. [/CH] > Besides above, I feel that the lacking part in the current=20 > qos-nslp draft is how the RZR is used. Supposedly, the RZR=20 > should replace the TEAR RESERV message to be sent from an QoS=20 > NSLP layer CRN. Since a CRN could be any QNE, this behavior=20 > should be defined in the QoS NSLP. Also, how the=20 > corresponding QNE response to the RZR should be explained. >=20 > Other than that, how the return to the old path is=20 > recognized, and how to restore and reuse the state over the=20 > old path could be incorporated into the qos-nslp draft as well. >=20 > Sven>> I agree we could better explain how RESERVE with zero=20 > resources=20 > Sven>> can > be used to address the points that you raise. >=20 [CH] This could also be a way to solve the problem. My concern is just that = it may not be that extensible. [/CH] >=20 > [CH] You are correct that a flag could achieve the purpose at=20 > most of the time. But, as we briefly described in the draft=20 > that in certain case, the Flow-ID is needed, and a flag is=20 > necessary for each of the FLOW-ID. >=20 > Sven>> I don't follow you completely here. Do you mean that a single > RESERVE message of a multi-homed host needs to contain more=20 > than one flowID? Or would you send different RESERVEs for=20 > each flowID and know that they can share resources on common=20 > paths because they belong to the same sessionID? [CH] I think the point is that if there are multiple flows associated with = the same session, this indication object should contain the specifc flow id = to be tear down, so that other flows would not be affected. The indication object is just an attachment to the RESERVE message, and would not = affect the normal content of the RESERV message. [/CH] >=20 > Sven>> If it is a specific QoS level, we don't need it in the=20 > QoS NSLP.=20 [CH] Sorry for causing the confusion. What I meant is that about the = charging, it could linked to the subcription of the user. If the user request to keep = the old path, he would be charge according to certain SLA he signed. [/CH] > Sven>> QoS > models are described in other drafts. Is the conclusion of=20 > this discussion > that: > - we propose to the WG to foresee a flag that allows QNEs to=20 > indicate that they want resources on old paths be kept and refreshed [CH] Yes. We agree to forward with this.=20 [/CH] > - better explain how RESERVE with zero resources may be used=20 > to support this [CH]=20 Please see my comments above.=20 [/CH] Cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 05:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14330 for ; Fri, 20 Feb 2004 05:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au85f-0003cW-LB for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 05:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KAf30B013902 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 05:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au85e-0003c1-JY; Fri, 20 Feb 2004 05:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au84n-0003XC-Cf for nsis@optimus.ietf.org; Fri, 20 Feb 2004 05:40:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14301 for ; Fri, 20 Feb 2004 05:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au84j-0002rB-00 for nsis@ietf.org; Fri, 20 Feb 2004 05:40:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au83v-0002md-00 for nsis@ietf.org; Fri, 20 Feb 2004 05:39:15 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au83G-0002fk-00 for nsis@ietf.org; Fri, 20 Feb 2004 05:38:34 -0500 Received: from pcluu (fraise.enst.fr [137.194.192.31]) by infres.enst.fr (Postfix) with SMTP id 82262321D; Fri, 20 Feb 2004 11:38:26 +0100 (MET) Message-ID: <001c01c3f79d$bb89c400$1fc0c289@enst.fr> From: "Thanh Tra LUU" To: "Cheng Hong" Cc: "'nsis'" References: <004e01c3f752$2c0686b0$4971510a@Palpatine> Subject: Re: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 11:38:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Cheng Hong, > It is not necessary that the NI always be the mobile. Also, wouldn't the > computation cost just an implementation issue? If it is that computational > intensive, could it be placed into certain hardware, e.g. some smart card? > > Another issue for NR generating the id would mean that the first message > sent from NI would not carry the SID information. Does this have any impact > on the design of the protocls? i think it maybe a problem. Seeing NAT/FW, NI and NR can initiate its own session NI ---> NAT/FW_I ----> Internet---->NAT/FW_R---->NR. NR can initiate the signaling session and some states are established on NAT/FW_R to permit NI can send signaling message to it. This session-id is sent by SIP or other means. Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 06:07:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15362 for ; Fri, 20 Feb 2004 06:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8Uo-0005ZX-DP for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 06:07:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KB71Bx021375 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 06:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8Um-0005Y5-Ul; Fri, 20 Feb 2004 06:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8Tu-0005Wn-7F for nsis@optimus.ietf.org; Fri, 20 Feb 2004 06:06:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15342 for ; Fri, 20 Feb 2004 06:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8Tq-0004vX-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:06:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8Sk-0004sL-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:04:55 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Au8S0-0004n1-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:04:08 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1KAtLwd019631; Fri, 20 Feb 2004 18:55:28 +0800 (SGT) From: "Cheng Hong" To: "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 19:03:26 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <001401c3f7a1$2d257250$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <001c01c3f79d$bb89c400$1fc0c289@enst.fr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Nary, Does this mean that the SIP or other types of signaling has be used in conjunction of the NSIS signaling to achieve the NR SID generation? = Wouldn't it be a bigger issue? Cheers Cheng Hong > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr]=20 > Sent: Friday, February 20, 2004 6:39 PM > To: Cheng Hong > Cc: 'nsis' > Subject: Re: [NSIS] Re: Session in NSIS >=20 >=20 > hi Cheng Hong, >=20 > > It is not necessary that the NI always be the mobile. Also,=20 > wouldn't=20 > > the computation cost just an implementation issue? If it is that=20 > > computational intensive, could it be placed into certain hardware,=20 > > e.g. some smart card? > > > > Another issue for NR generating the id would mean that the first=20 > > message sent from NI would not carry the SID information. Does this=20 > > have any > impact > > on the design of the protocls? >=20 > i think it maybe a problem. Seeing NAT/FW, NI and NR can=20 > initiate its own session >=20 > NI ---> NAT/FW_I ----> Internet---->NAT/FW_R---->NR. >=20 > NR can initiate the signaling session and some states are=20 > established on NAT/FW_R to permit NI can send signaling=20 > message to it. This session-id is sent by SIP or other means. >=20 > Nary Tra, > ENST, Paris. >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 06:53:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16982 for ; Fri, 20 Feb 2004 06:53:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9DJ-0000yU-CC for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 06:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBr1lJ003724 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 06:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9DI-0000xo-Jx; Fri, 20 Feb 2004 06:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9CK-0000wN-0F for nsis@optimus.ietf.org; Fri, 20 Feb 2004 06:52:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16954 for ; Fri, 20 Feb 2004 06:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9CF-00002Q-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:51:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9BO-0007n6-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:51:03 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9B1-0007j5-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:50:39 -0500 Received: from pcluu (fraise.enst.fr [137.194.192.31]) by infres.enst.fr (Postfix) with SMTP id 2C2F53232; Fri, 20 Feb 2004 12:50:31 +0100 (MET) Message-ID: <002e01c3f7a7$d1fca360$1fc0c289@enst.fr> From: "Thanh Tra LUU" To: "Cheng Hong" Cc: "'nsis'" References: <001401c3f7a1$2d257250$4971510a@Palpatine> Subject: Re: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 12:51:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Cheng, >Does this mean that the SIP or other types of signaling has be used in >conjunction of the NSIS signaling to achieve the NR SID generation? Wouldn't >it be a bigger issue? i think it's an open issue now. however, imho, it is possible to let other entities (NR, third party...) create session-id. for example, in the case bidirectional, NR and NI can create the session-id. Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 06:56:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17082 for ; Fri, 20 Feb 2004 06:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9GG-0001CM-87 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 06:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBu4FE004575 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 06:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9GF-0001BU-TF; Fri, 20 Feb 2004 06:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9GA-00019y-4n for nsis@optimus.ietf.org; Fri, 20 Feb 2004 06:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17077 for ; Fri, 20 Feb 2004 06:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9G5-0000I7-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9FG-0000Fa-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:55:03 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Au9En-0000Bd-00 for nsis@ietf.org; Fri, 20 Feb 2004 06:54:33 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1KBsXN02891; Fri, 20 Feb 2004 12:54:33 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1KBsXT16238; Fri, 20 Feb 2004 12:54:33 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 12:53:55 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DC6@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Cheng Hong'" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 12:54:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 cheng, if the nsis initiator creates the sid then the other nodes receive the value as part of regular nsis signaling. no application signaling is involved. the difficulty with a cryptographically generated session id is that in many cases only the creator of the sid is able to start signaling (and not intermediate nodes as sometimes required by nsis mobility optimized solutions). in the nat/fw nslp we, however, found a scenario (receiver behind a nat) where you could (as one possible solution) signal the sid via sip (as one example). we that that this might be a deployment problem and hence considered a different approach which is explained in the nat/fw draft. we mentioned it also at the last ietf nat/fw presentation (see "reserve mode of operation approaches" slide) http://www.tschofenig.priv.at/nsis/IETF58/NAT-FW-NSLP_ietf58.ppt ciao hannes > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Friday, February 20, 2004 12:03 PM > To: 'Thanh Tra LUU' > Cc: 'nsis' > Subject: RE: [NSIS] Re: Session in NSIS > > > Hi Nary, > > Does this mean that the SIP or other types of signaling has be used in > conjunction of the NSIS signaling to achieve the NR SID > generation? Wouldn't > it be a bigger issue? > > Cheers > > Cheng Hong > > > -----Original Message----- > > From: Thanh Tra LUU [mailto:luu@enst.fr] > > Sent: Friday, February 20, 2004 6:39 PM > > To: Cheng Hong > > Cc: 'nsis' > > Subject: Re: [NSIS] Re: Session in NSIS > > > > > > hi Cheng Hong, > > > > > It is not necessary that the NI always be the mobile. Also, > > wouldn't > > > the computation cost just an implementation issue? If it is that > > > computational intensive, could it be placed into certain > hardware, > > > e.g. some smart card? > > > > > > Another issue for NR generating the id would mean that the first > > > message sent from NI would not carry the SID information. > Does this > > > have any > > impact > > > on the design of the protocls? > > > > i think it maybe a problem. Seeing NAT/FW, NI and NR can > > initiate its own session > > > > NI ---> NAT/FW_I ----> Internet---->NAT/FW_R---->NR. > > > > NR can initiate the signaling session and some states are > > established on NAT/FW_R to permit NI can send signaling > > message to it. This session-id is sent by SIP or other means. > > > > Nary Tra, > > ENST, Paris. > > > > > > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Feb 20 07:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17623 for ; Fri, 20 Feb 2004 07:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Um-0003Rk-KY for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 07:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KCB4oW013213 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 07:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Um-0003Qw-5I; Fri, 20 Feb 2004 07:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Ug-0003Py-1Z for nsis@optimus.ietf.org; Fri, 20 Feb 2004 07:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17589 for ; Fri, 20 Feb 2004 07:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9Ub-0001HD-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9Tl-0001DN-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:10:02 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Au9Ss-00019p-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:09:06 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1KC97N19589; Fri, 20 Feb 2004 13:09:07 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1KC97T02882; Fri, 20 Feb 2004 13:09:07 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 13:08:29 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DC7@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" , Cheng Hong Cc: "'nsis'" Subject: RE: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 13:08:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, a small comment: the session ownership problem does not only appear in a mobility environment. based on a discussion with ruediger we got the impression that the same problem can actually appear with rsvp as well. maybe i should send a summary of our discussions. what could be a motivation for the nr to create the session id? i am very much in favor of separating nslp authorization decisions from the session id. in the past peopled had the tendency to mix, for example qos authorization, with session ownership. michael richardson commented our threats draft and he also made the comment that the user could authenticate to all intermediate nsis nodes. this would solve the session ownership problem even if most intermediate nodes do not need (or are even unable) to authorize the end host. the solution would, however, raise some further issues (but that's another story). ciao hannes > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Friday, February 20, 2004 11:39 AM > To: Cheng Hong > Cc: 'nsis' > Subject: Re: [NSIS] Re: Session in NSIS > > > hi Cheng Hong, > > > It is not necessary that the NI always be the mobile. Also, > wouldn't the > > computation cost just an implementation issue? If it is > that computational > > intensive, could it be placed into certain hardware, e.g. > some smart card? > > > > Another issue for NR generating the id would mean that the > first message > > sent from NI would not carry the SID information. Does this have any > impact > > on the design of the protocls? > > i think it maybe a problem. Seeing NAT/FW, NI and NR can > initiate its own > session > > NI ---> NAT/FW_I ----> Internet---->NAT/FW_R---->NR. > > NR can initiate the signaling session and some states are > established on > NAT/FW_R to permit NI can send signaling message to it. This > session-id is > sent by SIP or other means. > > Nary Tra, > ENST, Paris. > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Feb 20 07:49:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19276 for ; Fri, 20 Feb 2004 07:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuA5W-0006Z5-KB for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 07:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KCn2e0025199 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 07:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuA5V-0006Y3-TG; Fri, 20 Feb 2004 07:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuA50-0006Ob-FS for nsis@optimus.ietf.org; Fri, 20 Feb 2004 07:48:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19203 for ; Fri, 20 Feb 2004 07:48:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuA4z-00043X-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:48:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuA48-0003t7-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:47:36 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuA2w-0003gp-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:46:22 -0500 Received: from pcluu (fraise.enst.fr [137.194.192.31]) by infres.enst.fr (Postfix) with SMTP id 192C830FE; Fri, 20 Feb 2004 13:46:19 +0100 (MET) Message-ID: <004501c3f7af$9dee8d60$1fc0c289@enst.fr> From: "Thanh Tra LUU" To: "Tschofenig Hannes" Cc: "'nsis'" References: <2A8DB02E3018D411901B009027FD3A3F04685DC7@mchp905a.mch.sbs.de> Subject: Re: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 13:46:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 hannes, > a small comment: the session ownership problem does not only appear in a > mobility environment. based on a discussion with ruediger we got the > impression that the same problem can actually appear with rsvp as well. > maybe i should send a summary of our discussions. i totally agree. > what could be a motivation for the nr to create the session id? > > i am very much in favor of separating nslp authorization decisions from the > session id. in the past peopled had the tendency to mix, for example qos > authorization, with session ownership. i agree. in any case, session-id does not give enough information for authentication, authorization. however, how to use the session-id for re-authentication and re-authorization is not clear now :o) Nary Tra, ENST, Paris _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 07:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19871 for ; Fri, 20 Feb 2004 07:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAFB-0007PC-Kd for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 07:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KCx1Ah028451 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 07:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAFB-0007Om-9Q; Fri, 20 Feb 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAF5-0007OC-BJ for nsis@optimus.ietf.org; Fri, 20 Feb 2004 07:58:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19865 for ; Fri, 20 Feb 2004 07:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuAF4-000550-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:58:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuAEL-00052o-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:58:10 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AuADw-0004zB-00 for nsis@ietf.org; Fri, 20 Feb 2004 07:57:44 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1KCvg416978; Fri, 20 Feb 2004 13:57:43 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1KCvgT00447; Fri, 20 Feb 2004 13:57:42 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 20 Feb 2004 13:57:04 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DC9@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: [NSIS] Re: Session in NSIS Date: Fri, 20 Feb 2004 13:57:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Nary Tra, ~snip~ > > i agree. in any case, session-id does not give enough information for > authentication, authorization. however, how to use the session-id for > re-authentication and re-authorization is not clear now :o) true. i think that the reason for this is that the mobility handling is not fully specified and needs more discussions. once the expected signaling behavior is clarified it would be useful to take a look at the proposed security mechanisms again and to provide some text for the individual nslps. ciao hannes > > Nary Tra, > ENST, Paris > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 09:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22515 for ; Fri, 20 Feb 2004 09:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBG7-0003xA-0I for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 09:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KE42Os015181 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 09:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBG5-0003wP-7v; Fri, 20 Feb 2004 09:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuBF7-0003t0-1k for nsis@optimus.ietf.org; Fri, 20 Feb 2004 09:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22487 for ; Fri, 20 Feb 2004 09:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBF5-0002DH-00 for nsis@ietf.org; Fri, 20 Feb 2004 09:02:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBE9-00029Y-00 for nsis@ietf.org; Fri, 20 Feb 2004 09:02:02 -0500 Received: from [202.106.187.143] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1AuBD8-000268-00 for nsis@ietf.org; Fri, 20 Feb 2004 09:00:58 -0500 Received: (qmail 82266 invoked from network); 20 Feb 2004 14:00:46 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.143 with SMTP; 20 Feb 2004 14:00:46 -0000 Date: Fri, 20 Feb 2004 22:02:25 +0800 From: "Yuming Wang" To: "Georgios Karagiannis" Cc: "nsis" Subject: Re: Re: [NSIS] Datagram mode of GIMPS X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Georgios, A moment ago, I've just found the answer in draft-ietf-nsis-ntlp-01, so, in datagram mode, the downstream messages are also encapsulated in UDP like the upstream messages, while a router alert option is used for the interception of the downstream messages. Thank you any way. >Hi Yuming > >This is similar to how RSVP (see, e.g., RFC2205) operates. >The router alert option may be used in the fast forwarding path >of a high-speed router to detect datagrams that require special processing. > >Best Regards, >Georgios > > >----- Original Message ----- >From: "Yuming Wang" >To: "nsis" >Sent: Thursday, February 19, 2004 10:47 AM >Subject: [NSIS] Datagram mode of GIMPS > > >> Hi all, >> >> In the datagram mode of GIMPS, upstream messages are sent UDP encapsulated >> directly to the signaling destination; but, why downstream messages are >> sent towards the flow receiver with a router alert option? >> >> Thanks! >> >> Cheers, >> Yuming >> 2004-02-19 >> ---------------- Yuming Wang ----------------- >> NGIT Research Group, ITEC R&D Center, EI Dpt., >> HuaZhong University of Science and Technology. >> Email: acer_wym@sina.com >> Home Page: http://itec.hust.edu.cn/wym.htm >> TEL: +86-27-87453207 FAX: +86-27-87456436 >> ---- >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > >. Yuming 2004-02-20 ---------------- Yuming Wang ----------------- NGIT Research Group, ITEC R&D Center, EI Dpt., HuaZhong University of Science and Technology. Email: acer_wym@sina.com Home Page: http://itec.hust.edu.cn/wym.htm TEL: +86-27-87453207 FAX: +86-27-87456436 ---- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 20 15:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10158 for ; Fri, 20 Feb 2004 15:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGtU-0007gl-BZ for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 15:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KK54cT029555 for nsis-archive@odin.ietf.org; Fri, 20 Feb 2004 15:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGtT-0007g0-C2; Fri, 20 Feb 2004 15:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGsb-0007Ch-Aq for nsis@optimus.ietf.org; Fri, 20 Feb 2004 15:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09929 for ; Fri, 20 Feb 2004 15:04:05 -0500 (EST) From: Franck.Le@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuGsY-0004ua-00 for nsis@ietf.org; Fri, 20 Feb 2004 15:04:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuGrc-0004rA-00 for nsis@ietf.org; Fri, 20 Feb 2004 15:03:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AuGql-0004o8-00 for nsis@ietf.org; Fri, 20 Feb 2004 15:02:15 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KK2EK02514 for ; Fri, 20 Feb 2004 22:02:14 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 20 Feb 2004 22:02:13 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 20 Feb 2004 12:02:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2004 14:02:11 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811017CA721@daebe007.americas.nokia.com> Thread-Topic: draft-ietf-nsis-nslp-natfw-01 Thread-Index: AcP37GzhqC9dC0S1RJ+zWcQqeyFntg== To: X-OriginalArrivalTime: 20 Feb 2004 20:02:11.0461 (UTC) FILETIME=[6D4CFB50:01C3F7EC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] draft-ietf-nsis-nslp-natfw-01 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: quoted-printable Hello, I read the NAT/Firewall NSIS Signaling Layer Protocol (NSLP) = (draft-ietf-nsis-nslp-natfw-01) and the problems as well as the = scenarios are well described. I would have some comments: Technical comments: 1) Looking at the Protocol Description (section 5), it is not clear if = it is currently supported or not, but it would be useful if in addition = to opening pinholes in the firewall, the protocol could also allow to = install filters in the firewall. This would e.g. allow undesired packets = to be dropped in the network, before being forwarded over the access = link to the end nodes. This can more particularly be useful in access = networks with limited bandwidth access links. 2) As another feature that could be useful, the node may be behind a NAT = and may want to reserve a public address. However the node may not yet = know the IP address of its correspondent nodes to send the NSLP request = to. E.g. this could be the case when the node wants to receive incoming = requests (for P2P applications, Web server, etc.). The node may also be = behind a firewall, and similarly, the node may want to open the = appropriate pinholes in the firewall to accept incoming requests. So to = summarize, it would be useful if the node could open pinholes in the = firewall, and/or make reservation for a public IP address in a NAT = without knowing the IP address of the data sender (the node may not know = it yet), nor the IP address at the Application Server (there may not be = any Application Server) (section 4.2.1). 3) Finally it seems that the draft requires the firewall to forward some = of the messages (such as the create one) without performing any = authentication on them. Such requirement may present security issues = since a malicious node may send many of these messages and flood a node = behind the firewall. Also this may result in an overbilling attack in = access networks where data is charged by packet volume since the victim = has to pay for the access link utilization (delivery of these = unsolicited messages over the access link to the node). References: A protocol such as the NSLP could help solving some of the problems = identified in draft-le-mip6-firewalls-00.txt. As a suggestion, this = draft could be referred to, to complement the use cases of this = protocol, and the problems/challenges this protocol could help solving = (section 3) Franck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 00:39:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25141 for ; Mon, 23 Feb 2004 00:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8o3-00073D-6I for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 00:39:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N5d3bP027088 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 00:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8o1-00072h-SM; Mon, 23 Feb 2004 00:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av8n6-00071g-Pa for nsis@optimus.ietf.org; Mon, 23 Feb 2004 00:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25067 for ; Mon, 23 Feb 2004 00:38:00 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av8n4-00025v-00 for nsis@ietf.org; Mon, 23 Feb 2004 00:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av8mG-00021a-00 for nsis@ietf.org; Mon, 23 Feb 2004 00:37:13 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Av8lS-0001uj-00 for nsis@ietf.org; Mon, 23 Feb 2004 00:36:22 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1N5ZfS03210 for ; Mon, 23 Feb 2004 07:36:06 +0200 (EET) X-Scanned: Mon, 23 Feb 2004 07:35:20 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1N5ZKj0030131 for ; Mon, 23 Feb 2004 07:35:20 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00aCFCwX; Mon, 23 Feb 2004 07:35:19 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1N5ZI729169 for ; Mon, 23 Feb 2004 07:35:18 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 07:35:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2004 07:35:17 +0200 Message-ID: Thread-Topic: Info on multicast from IETF 59 Thread-Index: AcP5ztHmVzf8saF2Tx205YSO3hpq9Q== To: X-OriginalArrivalTime: 23 Feb 2004 05:35:18.0565 (UTC) FILETIME=[D2702550:01C3F9CE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Info on multicast from IETF 59 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: quoted-printable For those who cannot attend in person, info on multicast usage. John > From: Pete Resnick > Date: February 18, 2004 8:33:03 PM EST > To: "Eric Burger" > Cc: > Subject: Re: Multicast Sessions > > On 2/18/04 at 7:38 PM -0500, Eric Burger wrote: > >> Are the directions for participating in multicast sessions posted=20 >> anywhere? I've got a bunch of people in NA and Europe that plan on=20 >> joining my multicasted sessions, if they only knew how :-) > > Have them start out by making sure they've got multicast access. An=20 > easy to test multicast content feed is .=20 > Those with Macintosh's can just use QuickTime to do the deed. Those=20 > with other platforms might look at=20 > for software options. > > Once they're set with that, check out =20 > for the actual feed. The page for Seoul isn't posted there yet. As a=20 > matter of fact, the last thing posted there was from Minneapolis. But=20 > I'm sure it'll be there soon. > > pr > --=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 05:37:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18323 for ; Mon, 23 Feb 2004 05:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDSR-00031m-13 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 05:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NAb2vA011618 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 05:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDSP-000319-PY; Mon, 23 Feb 2004 05:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDRX-0002zT-Qg for nsis@optimus.ietf.org; Mon, 23 Feb 2004 05:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18283 for ; Mon, 23 Feb 2004 05:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDRU-0006CR-00 for nsis@ietf.org; Mon, 23 Feb 2004 05:36:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDQd-0006AA-00 for nsis@ietf.org; Mon, 23 Feb 2004 05:35:11 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AvDPx-00063j-00 for nsis@ietf.org; Mon, 23 Feb 2004 05:34:29 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1M29>; Mon, 23 Feb 2004 10:33:59 -0000 Message-ID: From: "Hancock, Robert" To: "'Elena Scialpi'" , nsis Subject: RE: [NSIS] Session in NSIS Date: Mon, 23 Feb 2004 10:34:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Elena, I'm sorry but I don't really follow your question. The phrase 'session class' doesn't appear in either the framework or NTLP documents, which makes it difficult to work out what the elements could really be ... Maybe you could give a bit more context to what you are really asking about. cheers, robert h. > -----Original Message----- > From: Elena Scialpi [mailto:scel@inwind.it] > Sent: Thursday, February 19, 2004 16:41 > To: hannes.tschofenig; luu; nsis > Subject: RE: [NSIS] Session in NSIS > > > > > Thanks for your comments! > I have understand session and session_ID concept but I have > an other question. > In your opinion, which elements are useful in a Session class? > It's a detail, but I'd like to know your opinions! > > Many thanks, > Elena > > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 23 06:06:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19254 for ; Mon, 23 Feb 2004 06:06:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDuU-0004zD-70 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 06:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NB62vs019166 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 06:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDuT-0004ym-2F; Mon, 23 Feb 2004 06:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvDte-0004xY-QQ for nsis@optimus.ietf.org; Mon, 23 Feb 2004 06:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19213 for ; Mon, 23 Feb 2004 06:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvDtb-0000Bv-00 for nsis@ietf.org; Mon, 23 Feb 2004 06:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvDsg-00006o-00 for nsis@ietf.org; Mon, 23 Feb 2004 06:04:11 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AvDrn-0007ll-00 for nsis@ietf.org; Mon, 23 Feb 2004 06:03:15 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMJQ67>; Mon, 23 Feb 2004 11:02:46 -0000 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Mon, 23 Feb 2004 11:02:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, some comments on this from the actual protocol operational perspective. 1. GIMPS currently requires a Session-ID *and* flow information in each message. This means that any NSIS message *has* to have a session-id set to some value. We could think about changing this. At the moment, GIMPS doesn't use the Session-ID internally so probably one could make it mandatory only in messages containing an NSLP payload. (An example could be a message setting up path (GIMPS) state for a signalling application but which actually created no signalling application state.) (However, the mobility discussion or other further refinements may imply that GIMPS would look at the Session-ID in message processing. It's probably a bit early to rule that out.) 2. I think the discussion of which node 'chooses' the Session-ID is a bit reversed. Any node can set the Session-ID for a message to be anything it likes; if the signalling application doesn't set a value in an outgoing message, I guess GIMPS will have to choose one. It's entirely up to NSLP designers to decide the rules whereby a either a new value is chosen, or one is used from another message (e.g. an incoming one). It's impossible in general to say anything more than that without getting into circular definitions (for example: - signalling session = messages with the same session id; - initiator = node which begins the signalling session; ==> "the NI sets the Session-ID" but that doesn't really say anything). More detail has to come from the individual NSLP designers saying how this message field is actually being used. That could well be different between different signalling applications. cheers, robert h. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Friday, February 20, 2004 12:57 > To: 'Thanh Tra LUU' > Cc: 'nsis' > Subject: RE: [NSIS] Re: Session in NSIS > > > hi Nary Tra, > > ~snip~ > > > > > i agree. in any case, session-id does not give enough > information for > > authentication, authorization. however, how to use the > session-id for > > re-authentication and re-authorization is not clear now :o) > > true. i think that the reason for this is that the mobility > handling is not > fully specified and needs more discussions. once the expected > signaling > behavior is clarified it would be useful to take a look at > the proposed > security mechanisms again and to provide some text for the > individual nslps. > > > ciao > hannes > > > > > Nary Tra, > > ENST, Paris > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 23 06:39:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20172 for ; Mon, 23 Feb 2004 06:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEQP-0007rI-1q for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 06:39:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NBd1Wd030199 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 06:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEQO-0007qt-KH; Mon, 23 Feb 2004 06:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEPa-0007kb-9R for nsis@optimus.ietf.org; Mon, 23 Feb 2004 06:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20094 for ; Mon, 23 Feb 2004 06:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvEPW-0002BG-00 for nsis@ietf.org; Mon, 23 Feb 2004 06:38:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvEOZ-00026p-00 for nsis@ietf.org; Mon, 23 Feb 2004 06:37:07 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvENf-000230-00 for nsis@ietf.org; Mon, 23 Feb 2004 06:36:11 -0500 Received: from pcluu (fraise.enst.fr [137.194.192.31]) by infres.enst.fr (Postfix) with SMTP id 56AFA2F8E; Mon, 23 Feb 2004 12:36:12 +0100 (MET) Message-ID: <003401c3fa01$5b056f60$1fc0c289@enst.fr> From: "Thanh Tra LUU" To: "Hancock, Robert" Cc: "'nsis'" References: Subject: Re: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Mon, 23 Feb 2004 12:37:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 hancock, > 2. I think the discussion of which node 'chooses' the Session-ID > is a bit reversed. Any node can set the Session-ID for a message > to be anything it likes; if the signalling application doesn't > set a value in an outgoing message, I guess GIMPS will have to > choose one. It's entirely up to NSLP designers to decide the rules > whereby a either a new value is chosen, or one is used from another > message (e.g. an incoming one). It's impossible in general to say > anything more than that without getting into circular definitions > (for example: > - signalling session = messages with the same session id; > - initiator = node which begins the signalling session; > ==> "the NI sets the Session-ID" but that doesn't really say anything). it does not seem very clear. i guess i understand your idea. you mean that some nodes can initiate a signaling session and it depends on NSLP ? for me, a session-id is a flow-id if there is no change of address. session-id is a "symbol" of flow. if a node initiates a signaling session, the session-id must represent a flow which is not established in network or represent an aggregation flow. in this case, the node is NI of the aggregation flow but it is not the NI of individual flows. otherwise, if i misunderstand your idea, do you mean session-id is not global ? Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 07:39:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21855 for ; Mon, 23 Feb 2004 07:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFMT-00039h-K8 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 07:39:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NCd18F012091 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 07:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFMS-00038r-DR; Mon, 23 Feb 2004 07:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFLd-00036y-3U for nsis@optimus.ietf.org; Mon, 23 Feb 2004 07:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21802 for ; Mon, 23 Feb 2004 07:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFLc-0005ek-00 for nsis@ietf.org; Mon, 23 Feb 2004 07:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFKg-0005by-00 for nsis@ietf.org; Mon, 23 Feb 2004 07:37:11 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AvFKL-0005ZZ-00 for nsis@ietf.org; Mon, 23 Feb 2004 07:36:49 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1NCamN17713; Mon, 23 Feb 2004 13:36:48 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1NCalT10457; Mon, 23 Feb 2004 13:36:47 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Feb 2004 13:36:09 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DD6@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Franck.Le@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01 Date: Mon, 23 Feb 2004 13:36:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 frank, thanks for reading the document. please see my comments inline: > Hello, > > I read the NAT/Firewall NSIS Signaling Layer Protocol (NSLP) > (draft-ietf-nsis-nslp-natfw-01) and the problems as well as > the scenarios are well described. thanks a lot. > > I would have some comments: > > Technical comments: > > 1) Looking at the Protocol Description (section 5), it is not > clear if it is currently supported or not, but it would be > useful if in addition to opening pinholes in the firewall, > the protocol could also allow to install filters in the > firewall. This would e.g. allow undesired packets to be > dropped in the network, before being forwarded over the > access link to the end nodes. This can more particularly be > useful in access networks with limited bandwidth access links. our approach currently is that we start with a "deny all" policy and then open pinholes for allowed traffic. your approach seems to be the other way aroung. similar as in midcom we had concerns with "deny packet filters" since conflict resolution is more difficult. i will add this issue to our issue tracker. > > 2) As another feature that could be useful, the node may be > behind a NAT and may want to reserve a public address. > However the node may not yet know the IP address of its > correspondent nodes to send the NSLP request to. E.g. this > could be the case when the node wants to receive incoming > requests (for P2P applications, Web server, etc.). The node > may also be behind a firewall, and similarly, the node may > want to open the appropriate pinholes in the firewall to > accept incoming requests. So to summarize, it would be useful > if the node could open pinholes in the firewall, and/or make > reservation for a public IP address in a NAT without knowing > the IP address of the data sender (the node may not know it > yet), nor the IP address at the Application Server (there may > not be any Application Server) (section 4.2.1). you are right. we should add this to the draft. thanks. > > 3) Finally it seems that the draft requires the firewall to > forward some of the messages (such as the create one) without > performing any authentication on them. Such requirement may > present security issues since a malicious node may send many > of these messages and flood a node behind the firewall. Also > this may result in an overbilling attack in access networks > where data is charged by packet volume since the victim has > to pay for the access link utilization (delivery of these > unsolicited messages over the access link to the node). in some scenario it was difficult to have authorization by one of the parties. authentication and signaling message security is still there. in the internet, in general, it is difficult to prevent someone from sending you traffic. for ip based packet filter you cannot fully avoid that someone sends packets to you since there is no cryptographic protection of the data traffic. the term "overbilling attack" is already used in the 3gpp for a different context but i agree that there might be a problem (particularly if you pay for receiving traffic). > > References: > > A protocol such as the NSLP could help solving some of the > problems identified in draft-le-mip6-firewalls-00.txt. As a > suggestion, this draft could be referred to, to complement > the use cases of this protocol, and the problems/challenges > this protocol could help solving (section 3) thanks for pointing to this draft. ciao hannes > > Franck > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 23 08:12:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23252 for ; Mon, 23 Feb 2004 08:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFsQ-0005SI-S4 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 08:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDC2Uq020967 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 08:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFsP-0005S4-T3; Mon, 23 Feb 2004 08:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvFre-0005Pm-Rq for nsis@optimus.ietf.org; Mon, 23 Feb 2004 08:11:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23239 for ; Mon, 23 Feb 2004 08:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvFrd-0000Hr-00 for nsis@ietf.org; Mon, 23 Feb 2004 08:11:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvFqn-0000Ei-00 for nsis@ietf.org; Mon, 23 Feb 2004 08:10:22 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AvFqN-000090-00 for nsis@ietf.org; Mon, 23 Feb 2004 08:09:55 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMJR9F>; Mon, 23 Feb 2004 13:09:12 -0000 Message-ID: From: "Hancock, Robert" To: "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Mon, 23 Feb 2004 13:09:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, [snip] > > 2. I think the discussion of which node 'chooses' the Session-ID > > is a bit reversed. Any node can set the Session-ID for a message > > to be anything it likes; if the signalling application doesn't > > set a value in an outgoing message, I guess GIMPS will have to > > choose one. It's entirely up to NSLP designers to decide the rules > > whereby a either a new value is chosen, or one is used from another > > message (e.g. an incoming one). It's impossible in general to say > > anything more than that without getting into circular definitions > > (for example: > > - signalling session = messages with the same session id; > > - initiator = node which begins the signalling session; > > ==> "the NI sets the Session-ID" but that doesn't really > say anything). > > it does not seem very clear. i guess i understand your idea. > you mean that > some nodes can initiate a signaling session and it depends on > NSLP ? for me, > a session-id is a flow-id if there is no change of address. > session-id is a > "symbol" of flow. "you" (i.e. the signalling application) can use the Session-ID like this. however, you could use it other ways as well. > if a node initiates a signaling session, > the session-id > must represent a flow which is not established in network or > represent an > aggregation flow. This would be the normal mode of operation, but I don't think we can be that prescriptive about how session-ID is interpreted. examples: a) there is a flow from S to R, and some reverse routing state already exists to get signalling from R to S. Both S and R want to make reservations for the flow, but neither knows the S-ID that the other will use. Consequence: two reservations. (Another way of putting this: in your phrase "must represent a flow which is not established in the network", how would a node ever be able to ensure that a flow was not established in the network? This is information it could never know.) b) at the GIMPS level you receive two discover messages for the same flow but from different directions (different peers). This might be for several reasons (some legitimate, some malicious); GIMPS uses the Session-ID to separate the routing state for each. > in this case, the node is NI of the > aggregation flow but > it is not the NI of individual flows. > > otherwise, if i misunderstand your idea, do you mean session-id is not > global ? Session-ID is as global as the NSLPs make it. Typically, I assume it will be valid along the entire path. (This does not mean that there can be only one for a given flow.) There might also be reasons why the session changed mid-path (e.g. to interwork between sender- and receiver-initiated signalling paradigms at a proxy node.) It all depends on the NSLP. r. > > Nary Tra, > ENST, Paris. > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 08:23:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23719 for ; Mon, 23 Feb 2004 08:23:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG33-0006E6-34 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 08:23:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NDN0Pm023903 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 08:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG32-0006DP-Hh; Mon, 23 Feb 2004 08:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvG2E-0006BT-Tg for nsis@optimus.ietf.org; Mon, 23 Feb 2004 08:22:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23654 for ; Mon, 23 Feb 2004 08:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvG2D-0001OU-00 for nsis@ietf.org; Mon, 23 Feb 2004 08:22:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvG1J-0001Ls-00 for nsis@ietf.org; Mon, 23 Feb 2004 08:21:14 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AvG0g-0001Fu-00 for nsis@ietf.org; Mon, 23 Feb 2004 08:20:34 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1MQ5>; Mon, 23 Feb 2004 13:20:03 -0000 Message-ID: From: "Hancock, Robert" To: "'Tschofenig Hannes'" , "'Franck.Le@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01 Date: Mon, 23 Feb 2004 13:20:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 all, teeny comment: > > 2) As another feature that could be useful, the node may be > > behind a NAT and may want to reserve a public address. > > However the node may not yet know the IP address of its > > correspondent nodes to send the NSLP request to. E.g. this > > could be the case when the node wants to receive incoming > > requests (for P2P applications, Web server, etc.). The node > > may also be behind a firewall, and similarly, the node may > > want to open the appropriate pinholes in the firewall to > > accept incoming requests. So to summarize, it would be useful > > if the node could open pinholes in the firewall, and/or make > > reservation for a public IP address in a NAT without knowing > > the IP address of the data sender (the node may not know it > > yet), nor the IP address at the Application Server (there may > > not be any Application Server) (section 4.2.1). > > you are right. we should add this to the draft. thanks. > as an FYI, there is an open issue on how GIMPS should attempt to handle the NATFW messages that would be needed to make such requests (for public IP addresses). The question is basically whether such messages need some 'special' routing (different from normal on-path routing), or whether they can be handled correctly by concocting flow identifiers with the right set of properties. More is in 8.12 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt (this also addresses some other issues). comments welcome, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 09:35:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27952 for ; Mon, 23 Feb 2004 09:35:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHAt-0005UT-P6 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 09:35:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NEZBbJ021095 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 09:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHAt-0005U8-DE; Mon, 23 Feb 2004 09:35:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHA7-0005QM-3f for nsis@optimus.ietf.org; Mon, 23 Feb 2004 09:34:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27929 for ; Mon, 23 Feb 2004 09:34:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHA5-0000Hp-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:34:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvH9J-0000DQ-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:33:33 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvH8P-00008C-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:32:42 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NEWbAh031935 for ; Mon, 23 Feb 2004 15:32:37 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 15:32:37 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Feb 2004 15:32:45 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hancock, Robert" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Mon, 23 Feb 2004 15:36:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 23 Feb 2004 14:32:37.0523 (UTC) FILETIME=[E25ABE30:01C3FA19] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, In case of bi-directional reservation they must known it, or the flows should be the same session ID, is not it? Attila > > This would be the normal mode of operation, but I don't think > we can be that prescriptive about how session-ID is interpreted. > examples: > > a) there is a flow from S to R, and some reverse routing state > already exists to get signalling from R to S. Both S and R want > to make reservations for the flow, but neither knows the S-ID > that the other will use. Consequence: two reservations. (Another > way of putting this: in your phrase "must represent a flow which > is not established in the network", how would a node ever be able > to ensure that a flow was not established in the network? This > is information it could never know.) > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 09:39:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28135 for ; Mon, 23 Feb 2004 09:39:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHEh-00069d-Ib for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 09:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NEd7KN023596 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 09:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHEf-00065o-Kw; Mon, 23 Feb 2004 09:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHDv-00060a-Sn for nsis@optimus.ietf.org; Mon, 23 Feb 2004 09:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28087 for ; Mon, 23 Feb 2004 09:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHDt-0000Zn-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHD6-0000Wo-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:37:28 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AvHCh-0000SB-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:37:04 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMJSVM>; Mon, 23 Feb 2004 14:36:32 -0000 Message-ID: From: "Hancock, Robert" To: =?iso-8859-1?Q?=27Attila_B=E1der_=28IJ/ETH=29=27?= , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Mon, 23 Feb 2004 14:36:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi attila, in the case of bi-directional reservations *as defined in the QoS-NSLP* you have a particular message flow where *) it's clear how both ends find the same ID [or at least I hope it is], and *) the QoS-NSLP spec actually defines that the Session-ID should be the same. In other words, it depends on the particular NSLP you are talking about. It's hard to make general statements about the session ID. hope this helps, robert h. > -----Original Message----- > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > Sent: Monday, February 23, 2004 14:37 > To: Hancock, Robert; 'Thanh Tra LUU' > Cc: 'nsis' > Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in = NSIS) >=20 >=20 > Hi Robert,=20 >=20 > In case of bi-directional reservation they must known it, or=20 > the flows should be the same session ID, is not it? >=20 > Attila >=20 > >=20 > > This would be the normal mode of operation, but I don't think=20 > > we can be that prescriptive about how session-ID is interpreted. > > examples: > >=20 > > a) there is a flow from S to R, and some reverse routing state > > already exists to get signalling from R to S. Both S and R want > > to make reservations for the flow, but neither knows the S-ID > > that the other will use. Consequence: two reservations. (Another > > way of putting this: in your phrase "must represent a flow which > > is not established in the network", how would a node ever be able > > to ensure that a flow was not established in the network? This > > is information it could never know.) > >=20 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 09:47:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28384 for ; Mon, 23 Feb 2004 09:47:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHMM-0006u5-6d for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 09:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NEl1H1026521 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 09:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHML-0006tf-Si; Mon, 23 Feb 2004 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvHLe-0006jB-8B for nsis@optimus.ietf.org; Mon, 23 Feb 2004 09:46:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28365 for ; Mon, 23 Feb 2004 09:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvHLc-00013r-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:46:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvHKg-00010a-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:45:18 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvHJk-0000xS-00 for nsis@ietf.org; Mon, 23 Feb 2004 09:44:20 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1NEiJAh003036 for ; Mon, 23 Feb 2004 15:44:19 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 15:44:19 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Feb 2004 15:44:27 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hancock, Robert" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Mon, 23 Feb 2004 15:48:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 23 Feb 2004 14:44:19.0610 (UTC) FILETIME=[84D4B7A0:01C3FA1B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Robert,=20 Yes, thank you that is what I wanted to point out, Best regards, Attila > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Monday, February 23, 2004 3:37 PM > To: Attila B=E1der (IJ/ETH); 'Thanh Tra LUU' > Cc: 'nsis' > Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) >=20 >=20 > hi attila, >=20 > in the case of bi-directional reservations *as defined in > the QoS-NSLP* you have a particular message flow where > *) it's clear how both ends find the same ID [or at > least I hope it is], and > *) the QoS-NSLP spec actually defines that the Session-ID > should be the same. >=20 > In other words, it depends on the particular NSLP you are > talking about. It's hard to make general statements about > the session ID. >=20 > hope this helps, >=20 > robert h. >=20 > > -----Original Message----- > > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > > Sent: Monday, February 23, 2004 14:37 > > To: Hancock, Robert; 'Thanh Tra LUU' > > Cc: 'nsis' > > Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re:=20 > Session in NSIS) > >=20 > >=20 > > Hi Robert,=20 > >=20 > > In case of bi-directional reservation they must known it, or=20 > > the flows should be the same session ID, is not it? > >=20 > > Attila > >=20 > > >=20 > > > This would be the normal mode of operation, but I don't think=20 > > > we can be that prescriptive about how session-ID is interpreted. > > > examples: > > >=20 > > > a) there is a flow from S to R, and some reverse routing state > > > already exists to get signalling from R to S. Both S and R want > > > to make reservations for the flow, but neither knows the S-ID > > > that the other will use. Consequence: two reservations. (Another > > > way of putting this: in your phrase "must represent a flow which > > > is not established in the network", how would a node ever be able > > > to ensure that a flow was not established in the network? This > > > is information it could never know.) > > >=20 > > > >=20 > --=20 > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Feb 23 12:22:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07311 for ; Mon, 23 Feb 2004 12:22:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJmT-0000UM-Au for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 12:22:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHM9bw001878 for nsis-archive@odin.ietf.org; Mon, 23 Feb 2004 12:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJmM-0000St-1b; Mon, 23 Feb 2004 12:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJlh-0000QU-Ds for nsis@optimus.ietf.org; Mon, 23 Feb 2004 12:21:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07232 for ; Mon, 23 Feb 2004 12:21:17 -0500 (EST) From: Franck.Le@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJlf-000795-00 for nsis@ietf.org; Mon, 23 Feb 2004 12:21:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJkg-00071X-00 for nsis@ietf.org; Mon, 23 Feb 2004 12:20:18 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AvJjk-0006rw-00 for nsis@ietf.org; Mon, 23 Feb 2004 12:19:20 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NHISS02534; Mon, 23 Feb 2004 19:18:53 +0200 (EET) X-Scanned: Mon, 23 Feb 2004 19:18:10 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1NHIASQ022487; Mon, 23 Feb 2004 19:18:10 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00ahiHFy; Mon, 23 Feb 2004 19:18:10 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NHI9O05436; Mon, 23 Feb 2004 19:18:09 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 11:18:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01 Date: Mon, 23 Feb 2004 11:18:08 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811017CA728@daebe007.americas.nokia.com> Thread-Topic: [NSIS] draft-ietf-nsis-nslp-natfw-01 Thread-Index: AcP6CdP5Hj5nMzsdRSegOK7+IknU+gAJoDGw To: , X-OriginalArrivalTime: 23 Feb 2004 17:18:08.0542 (UTC) FILETIME=[01B3FBE0:01C3FA31] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hello Tschofenig, Thank you for your replies. Please find some comments below, > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 23 February, 2004 06:36 AM > To: Le Franck (Nokia-NRC/Dallas); nsis@ietf.org > Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01 >=20 >=20 > hi frank,=20 >=20 > thanks for reading the document. please see my comments inline: >=20 > > Hello, > >=20 > > I read the NAT/Firewall NSIS Signaling Layer Protocol (NSLP)=20 > > (draft-ietf-nsis-nslp-natfw-01) and the problems as well as=20 > > the scenarios are well described. > thanks a lot.=20 >=20 > >=20 > > I would have some comments: > >=20 > > Technical comments: > >=20 > > 1) Looking at the Protocol Description (section 5), it is not=20 > > clear if it is currently supported or not, but it would be=20 > > useful if in addition to opening pinholes in the firewall,=20 > > the protocol could also allow to install filters in the=20 > > firewall. This would e.g. allow undesired packets to be=20 > > dropped in the network, before being forwarded over the=20 > > access link to the end nodes. This can more particularly be=20 > > useful in access networks with limited bandwidth access links. >=20 > our approach currently is that we start with a "deny all"=20 > policy and then > open pinholes for allowed traffic.=20 > your approach seems to be the other way aroung. similar as in=20 > midcom we had > concerns with "deny packet filters" since conflict resolution is more > difficult.=20 I agree that starting with a "deny all" policy and then opening the = required pinholes is more secure. Also combining "opening rules" and "closing rules" may be difficult to = manage. However, I was thinking that adding more flexibility to the protocol = would allow it to support the needs of more scenarios, and therefore may = make it adopted and deployed in more environments. The default policy rules may e.g. allow some types of traffic to pass = the firewalls but the user does not need this service. It may prefer to = drop these packets at the network not to waste the limited bandwidth = access link resources. > i will add this issue to our issue tracker.=20 Ok, thank you. > > 2) As another feature that could be useful, the node may be=20 > > behind a NAT and may want to reserve a public address.=20 > > However the node may not yet know the IP address of its=20 > > correspondent nodes to send the NSLP request to. E.g. this=20 > > could be the case when the node wants to receive incoming=20 > > requests (for P2P applications, Web server, etc.). The node=20 > > may also be behind a firewall, and similarly, the node may=20 > > want to open the appropriate pinholes in the firewall to=20 > > accept incoming requests. So to summarize, it would be useful=20 > > if the node could open pinholes in the firewall, and/or make=20 > > reservation for a public IP address in a NAT without knowing=20 > > the IP address of the data sender (the node may not know it=20 > > yet), nor the IP address at the Application Server (there may=20 > > not be any Application Server) (section 4.2.1). >=20 > you are right. we should add this to the draft. thanks.=20 Ok, thanks. > > 3) Finally it seems that the draft requires the firewall to=20 > > forward some of the messages (such as the create one) without=20 > > performing any authentication on them. Such requirement may=20 > > present security issues since a malicious node may send many=20 > > of these messages and flood a node behind the firewall. Also=20 > > this may result in an overbilling attack in access networks=20 > > where data is charged by packet volume since the victim has=20 > > to pay for the access link utilization (delivery of these=20 > > unsolicited messages over the access link to the node). >=20 > in some scenario it was difficult to have authorization by one of the > parties. authentication and signaling message security is=20 > still there.=20 >=20 > in the internet, in general, it is difficult to prevent=20 > someone from sending > you traffic. for ip based packet filter you cannot fully=20 > avoid that someone > sends packets to you since there is no cryptographic=20 > protection of the data > traffic.=20 I agree with your comments. However current firewall technology allows = to drop unsolicited incoming traffic. Typically incoming packets are only allowed to pass the firewalls if the = connection was initiated by the node protected (i.e. behind the = firewall). This allows to block flooding (e.g. UDP) by malicious nodes. What I was trying to say is that requiring the firewall to forward the = unsolicited nslp messages before performing any authentication may allow = malicous nodes to flood the nodes behind the firewalls, threat that is = more difficult to execute today. > the term "overbilling attack" is already used in the 3gpp for=20 > a different Thank you for pointing this out. I actually re-used the term = "overbilling" since as in 3gpp, the attack results in the victim having = to pay for packets it has not requested for. > context but i agree that there might be a problem=20 > (particularly if you pay > for receiving traffic).=20 May be, it can be useful to describe it in the "security consideration" = section. Thank you, Franck=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 03:22:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06178 for ; Tue, 24 Feb 2004 03:22:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXpL-0000Bb-Od for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 03:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O8M3lD000699 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 03:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXpK-0000B4-ML; Tue, 24 Feb 2004 03:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvXp7-0000A9-Fk for nsis@optimus.ietf.org; Tue, 24 Feb 2004 03:21:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06134 for ; Tue, 24 Feb 2004 03:21:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvXp5-0000lX-00 for nsis@ietf.org; Tue, 24 Feb 2004 03:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvXo7-0000fE-00 for nsis@ietf.org; Tue, 24 Feb 2004 03:20:48 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AvXnA-0000Vs-00 for nsis@ietf.org; Tue, 24 Feb 2004 03:19:49 -0500 Received: from Palpatine ([10.81.113.74]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1O8ArhD022051; Tue, 24 Feb 2004 16:11:05 +0800 (SGT) From: "Cheng Hong" To: "'Hancock, Robert'" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Tue, 24 Feb 2004 16:18:56 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <005d01c3faae$de7551f0$4a71510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Robert and all, >=20 > Session-ID is as global as the NSLPs make it. Typically, I=20 > assume it will be valid along the entire path. (This does not=20 > mean that=20 > there can be only one for a given flow.) There might also be=20 > reasons why the session changed mid-path (e.g. to interwork=20 > between sender- and receiver-initiated signalling paradigms=20 > at a proxy node.) It all depends on the NSLP. >=20 > r. If the NSLP decides how global the Session-ID is, could we say that Session-ID could only be unique within the specific NSLP space? It means = the different NSLP applications could choose different session ID value for = the same flow, and use the same session id for unrelated flows? Best regards Cheng =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 03:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07313 for ; Tue, 24 Feb 2004 03:52:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYIP-0002Jw-4U for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 03:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O8q4YH008897 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 03:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYIK-0002JA-Vn; Tue, 24 Feb 2004 03:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYIA-0002Ik-Fk for nsis@optimus.ietf.org; Tue, 24 Feb 2004 03:51:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07308 for ; Tue, 24 Feb 2004 03:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYI7-0003PJ-00 for nsis@ietf.org; Tue, 24 Feb 2004 03:51:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYHD-0003LZ-00 for nsis@ietf.org; Tue, 24 Feb 2004 03:50:52 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AvYGO-0003Ds-00 for nsis@ietf.org; Tue, 24 Feb 2004 03:50:00 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1NKV>; Tue, 24 Feb 2004 08:49:30 -0000 Message-ID: From: "Hancock, Robert" To: "'Cheng Hong'" , "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Tue, 24 Feb 2004 08:49:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 cheng, > > > > Session-ID is as global as the NSLPs make it. Typically, I > > assume it will be valid along the entire path. (This does not > > mean that > > there can be only one for a given flow.) There might also be > > reasons why the session changed mid-path (e.g. to interwork > > between sender- and receiver-initiated signalling paradigms > > at a proxy node.) It all depends on the NSLP. > > > > r. > > If the NSLP decides how global the Session-ID is, could we say that > Session-ID could only be unique within the specific NSLP space? that is one possible consequence. however, at this stage i would not like to formalise it in this way. specifically: - the Session-ID is never unique (under any conditions), it is only probabilistically unique - it is just as easy to ask it to be probabilistically unique over the whole NSIS space as over a single NSLP space making statements about how the Session-ID space relates to different NSLPs might have some impacts on NSLP-NSLP interactions (at the moment we are ignoring these but it doesn't mean they don't exist). i'd rather leave it unspecified than overspecify it. > It means the > different NSLP applications could choose different session ID > value for the same flow, this could certainly happen, especially if the 'initiators' for the two NSLPs were on different nodes (e.g. one was a proxy). they would just have no way to synchronise their use of the Session-ID value. > and use the same session id for unrelated flows? this could happen by coincidence (e.g. 1 time in 2^128). I would rather not encourage it, but i do not immediately see what the practical impact would be. robert h. > > Best regards > > Cheng > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 04:17:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08473 for ; Tue, 24 Feb 2004 04:17:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYgh-0004hv-5i for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 04:17:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9HAku018091 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 04:17:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYgY-0004hE-Me; Tue, 24 Feb 2004 04:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvYgM-0004gp-9q for nsis@optimus.ietf.org; Tue, 24 Feb 2004 04:16:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08467 for ; Tue, 24 Feb 2004 04:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvYgJ-0005gC-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:16:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvYfT-0005cj-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:15:55 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AvYee-0005Yg-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:15:06 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1O9F4YG013602 for ; Tue, 24 Feb 2004 10:15:05 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:15:04 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Feb 2004 10:15:01 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'nsis'" , Henning Schulzrinne , "Hancock, Robert" Date: Tue, 24 Feb 2004 10:18:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Feb 2004 09:15:04.0808 (UTC) FILETIME=[B076E680:01C3FAB6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [NSIS] GIMPS scalability 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 Henning and Robert, I have some comment regarding scalability. In GIMPS draft there is a scalabiliy statement: '' Scaleable: As will be discussed in Section 4.3, up to one messaging association is generally kept for each adjacent GIMPS peer and thus association state scales better than the number of sessions. (Many peers may not have association state at all, if there are no messages on sessions visiting those nodes that warrant such treatment.) Messaging associations are managed based on policy at each node, depending on trade-offs between fast peer-to-peer communication and state overhead. Messaging association state can be removed immediately after the last signaling session to a particular next-hop is removed, after some delay to wait for new sessions or only if resource demands warrant it.'' It is clear that association state scales better than number of sessions because usually an associacion is used by more sessions. However, routing states are per-flow e.g. scales with number of flows, which can be an issue. Furthermore, I do not see support for aggregation in the description. Best regards, Attila This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 04:51:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09667 for ; Tue, 24 Feb 2004 04:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZDT-00077h-Pb for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 04:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9p3jL027336 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 04:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZDS-00076J-87; Tue, 24 Feb 2004 04:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZDM-00075F-A3 for nsis@optimus.ietf.org; Tue, 24 Feb 2004 04:50:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09623 for ; Tue, 24 Feb 2004 04:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZDJ-0000fk-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:50:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZCP-0000aL-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:49:59 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AvZBS-0000Uu-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:48:58 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1O9mvq21617; Tue, 24 Feb 2004 10:48:58 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1O9muT25784; Tue, 24 Feb 2004 10:48:56 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Feb 2004 10:48:18 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DED@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Franck.Le@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01 Date: Tue, 24 Feb 2004 10:48:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 franck, thanks for your quick response: please find my comments inline: > Hello Tschofenig, > > Thank you for your replies. Please find some comments below, > > > -----Original Message----- > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: 23 February, 2004 06:36 AM > > To: Le Franck (Nokia-NRC/Dallas); nsis@ietf.org > > Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01 > > > > > > hi frank, > > > > thanks for reading the document. please see my comments inline: > > > > > Hello, > > > > > > I read the NAT/Firewall NSIS Signaling Layer Protocol (NSLP) > > > (draft-ietf-nsis-nslp-natfw-01) and the problems as well as > > > the scenarios are well described. > > thanks a lot. > > > > > > > > I would have some comments: > > > > > > Technical comments: > > > > > > 1) Looking at the Protocol Description (section 5), it is not > > > clear if it is currently supported or not, but it would be > > > useful if in addition to opening pinholes in the firewall, > > > the protocol could also allow to install filters in the > > > firewall. This would e.g. allow undesired packets to be > > > dropped in the network, before being forwarded over the > > > access link to the end nodes. This can more particularly be > > > useful in access networks with limited bandwidth access links. > > > > our approach currently is that we start with a "deny all" > > policy and then > > open pinholes for allowed traffic. > > your approach seems to be the other way aroung. similar as in > > midcom we had > > concerns with "deny packet filters" since conflict > resolution is more > > difficult. > > I agree that starting with a "deny all" policy and then > opening the required pinholes is more secure. > Also combining "opening rules" and "closing rules" may be > difficult to manage. > However, I was thinking that adding more flexibility to the > protocol would allow it to support the needs of more > scenarios, and therefore may make it adopted and deployed in > more environments. that's certainly a good idea to look at other scenarios as well. do you have a more detailed description of these scenarios so that we can take a closer look at the requirements? > > The default policy rules may e.g. allow some types of traffic > to pass the firewalls but the user does not need this > service. It may prefer to drop these packets at the network > not to waste the limited bandwidth access link resources. > > > i will add this issue to our issue tracker. > > Ok, thank you. > > > > 2) As another feature that could be useful, the node may be > > > behind a NAT and may want to reserve a public address. > > > However the node may not yet know the IP address of its > > > correspondent nodes to send the NSLP request to. E.g. this > > > could be the case when the node wants to receive incoming > > > requests (for P2P applications, Web server, etc.). The node > > > may also be behind a firewall, and similarly, the node may > > > want to open the appropriate pinholes in the firewall to > > > accept incoming requests. So to summarize, it would be useful > > > if the node could open pinholes in the firewall, and/or make > > > reservation for a public IP address in a NAT without knowing > > > the IP address of the data sender (the node may not know it > > > yet), nor the IP address at the Application Server (there may > > > not be any Application Server) (section 4.2.1). > > > > you are right. we should add this to the draft. thanks. > > Ok, thanks. > > > > 3) Finally it seems that the draft requires the firewall to > > > forward some of the messages (such as the create one) without > > > performing any authentication on them. Such requirement may > > > present security issues since a malicious node may send many > > > of these messages and flood a node behind the firewall. Also > > > this may result in an overbilling attack in access networks > > > where data is charged by packet volume since the victim has > > > to pay for the access link utilization (delivery of these > > > unsolicited messages over the access link to the node). > > > > in some scenario it was difficult to have authorization by > one of the > > parties. authentication and signaling message security is > > still there. > > > > in the internet, in general, it is difficult to prevent > > someone from sending > > you traffic. for ip based packet filter you cannot fully > > avoid that someone > > sends packets to you since there is no cryptographic > > protection of the data > > traffic. > > I agree with your comments. However current firewall > technology allows to drop unsolicited incoming traffic. > Typically incoming packets are only allowed to pass the > firewalls if the connection was initiated by the node > protected (i.e. behind the firewall). This allows to block > flooding (e.g. UDP) by malicious nodes. i have read your draft and you refer to firewalls performing stateful inspection. if both end hosts are behind such firewalls then there is a problem if you require both hosts to start first. for the nat case this is also difficult and requires the data receiver to start signaling first (i.e., to create a nat binding) but the firewall case is more complicated since you might create state at a firewall which is subsequently not used for the incoming data traffic. this means that the end host would have to know the topology. > > What I was trying to say is that requiring the firewall to > forward the unsolicited nslp messages before performing any > authentication may allow malicous nodes to flood the nodes > behind the firewalls, threat that is more difficult to execute today. we are not trying to have the messages unprotected. it is only the problem that they are unauthorized. you can compare this to the qos signaling case where you would create a qos reservation without knowing where to get the money from. to address this issue we suggested to require that both nodes have to contribute to the authorization. i will show you an example (from section 3.1 of draft-ietf-nsis-nslp-natfw-01): +----------------------+ +--------------------------+ | | | | | Network A | | Network B | | | | | | +---------+ Missing +---------+ | | +-///-+ Middle- | Trust | Middle- +-///-+ | | | | box 1 | Relation- | box 2 | | | | | +---------+ ship +---------+ | | | | | or | | | | | | Authorization| | | | | | | | | | | Trust | | Trust | | | | Relationship | | Relationship | | | | | | | | | | | | | | | | | | | | | +--+---+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +------+ | | +------+ | +----------------------+ +--------------------------+ suppose we both want to communicate (host a and host b). now, middlebox 1 and middlebox 2 can certainly protect signaling messages (inter-domain) but why should network b trust network a to install packet filters (they are, for example, different companies). network b might not even know host a - authentication would not be very helpful in this case. what you can do is to authorize packet filter creation locally at network a (authorized by host a) and in network b (authorized by host b). since we have path-coupled signaling it is necessary to perform this step end-to-end rather than locally. > > > the term "overbilling attack" is already used in the 3gpp for > > a different > > Thank you for pointing this out. I actually re-used the term > "overbilling" since as in 3gpp, the attack results in the > victim having to pay for packets it has not requested for. ok. i guess nsis nat/fw nslp could be used in this area. i tried to add this issue to the issue tracker but you mentioned several issues here: - the overbilling attack: nsis could be helpful to address the overbilling attack to some extend (as a solution). - nsis message authentication: i hope i was able to describe that we authenticate signaling messages. we should actually be more specific which entity we want to authenticate since a number of nodes are involved in nsis signaling. - authorization issues: we described a few possible solutions in the draft. currently we favor one where both nodes contribute to the authorization decision but this is certainly subject to discussion. > > > context but i agree that there might be a problem > > (particularly if you pay > > for receiving traffic). > > May be, it can be useful to describe it in the "security > consideration" section. that's true. i have read your draft . i agree with the issues in the draft and i think that nsis nat/fw signaling could be helpful there. a reference to your draft (and some discussions) would certainly fit into the migration draft. i think you could add a discussion of the symmetric nats in your description since the problems are similar. maybe a reference to would not hurt. ciao hannes > > Thank you, > > Franck > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 04:59:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10223 for ; Tue, 24 Feb 2004 04:59:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZLH-0007he-0n for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 04:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O9x6Dm029565 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 04:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZLB-0007gb-Kt; Tue, 24 Feb 2004 04:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZL0-0007fy-Lg for nsis@optimus.ietf.org; Tue, 24 Feb 2004 04:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10206 for ; Tue, 24 Feb 2004 04:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZKx-0001NJ-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZJy-0001Ik-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:57:47 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZJ0-0001BS-00 for nsis@ietf.org; Tue, 24 Feb 2004 04:56:46 -0500 Received: from pcluu (fraise.enst.fr [137.194.192.31]) by infres.enst.fr (Postfix) with SMTP id D5AB83088; Tue, 24 Feb 2004 10:56:44 +0100 (MET) Message-ID: <00ea01c3fabc$a338a520$1fc0c289@enst.fr> From: "Thanh Tra LUU" To: "Hancock, Robert" Cc: "'nsis'" References: Subject: Re: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Tue, 24 Feb 2004 10:57:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi robert, > a) there is a flow from S to R, and some reverse routing state > already exists to get signalling from R to S. Both S and R want > to make reservations for the flow, but neither knows the S-ID > that the other will use. Consequence: two reservations. (Another > way of putting this: in your phrase "must represent a flow which > is not established in the network", how would a node ever be able > to ensure that a flow was not established in the network? This > is information it could never know.) I don'n mention how to create a global SESSION_ID (e.g. random) here, supposing that there are some ways to do it. in case of bidirectional reservation, if these are two indenpendent reservations, it is easy, you can take two different SESSION_IDs. NTLP can not know the relation between two reservations. If two reservations are not independent, there must be some mechanism to know it (off path signaling, aller-retour (reservation S to R and then R to S or vice versa)...). > b) at the GIMPS level you receive two discover messages for the > same flow but from different directions (different peers). This > might be for several reasons (some legitimate, some malicious); > GIMPS uses the Session-ID to separate the routing state for each. i don't understand what flow you mean. For me, the flow from S to R and the flow from B to A are different. At NTLP level, if it receives two messages for the same flow but from different directions (different peers) and IF it knows the routing is symmetric, the route discovery is not necessary. > > otherwise, if i misunderstand your idea, do you mean session-id is not > > global ? > Session-ID is as global as the NSLPs make it. Typically, I assume > it will be valid along the entire path. (This does not mean that > there can be only one for a given flow.) There might also be reasons > why the session changed mid-path (e.g. to interwork between sender- > and receiver-initiated signalling paradigms at a proxy node.) It > all depends on the NSLP. i agree. Nary Tra, ENST, Paris _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 05:16:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10994 for ; Tue, 24 Feb 2004 05:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZbe-00014M-39 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 05:16:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OAG1bR004066 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 05:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZbc-00013P-K1; Tue, 24 Feb 2004 05:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvZba-00013C-B6 for nsis@optimus.ietf.org; Tue, 24 Feb 2004 05:15:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10984 for ; Tue, 24 Feb 2004 05:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvZbX-0002t6-00 for nsis@ietf.org; Tue, 24 Feb 2004 05:15:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvZac-0002oO-00 for nsis@ietf.org; Tue, 24 Feb 2004 05:14:59 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AvZZj-0002f5-00 for nsis@ietf.org; Tue, 24 Feb 2004 05:14:04 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1NPL>; Tue, 24 Feb 2004 10:13:32 -0000 Message-ID: From: "Hancock, Robert" To: =?iso-8859-1?Q?=27Attila_B=E1der_=28IJ/ETH=29=27?= , "'nsis'" , Henning Schulzrinne Date: Tue, 24 Feb 2004 10:13:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: GIMPS scalability 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: quoted-printable hi attila, you are quite right that the routing state scales as the number of flows. however, i think this is fundamentally an unavoidable consequence of wanting to do per-flow signalling. all that we can do in GIMPS is to ensure that routing state only needs to be kept when absolutely necessary, i.e. to allow the cases where routing state does not need to be kept to be handled efficiently.=20 so far, we've identified two such cases: a) sending downstream signalling without requiring routing state to be installed. this is possible with GIMPS (maybe it needs to be made more clear) if the signalling application so requests. b) protecting the network from per-[micro]-flow signalling when those flows are being handled inside an aggregate.=20 two ways are possible: setting the RAO so datagram messages are ignored and then C-mode signalling runs edge-to-edge only and is not interpreted between the edges; and putting the microflows and their signalling inside a tunnel (so they are invisible). In addition, the current Flow-Routing-Information allows a=20 limited degree of wildcarding (leaving some protocol fields unspecified) so you don't have to store identical routing state for large numbers of nearly identical flows.=20 We're open to additional suggestions about how to minimise per-flow state requirements! I am not sure whether you are asking for more description of aggregation in the GIMPS specification, and if so, where. My view is that aggregation itself is a signalling application function; all that GIMPS can do is enable the micro signalling to be ignored where appropriate. This is basically (b), where the information is already contained in the draft - but if you think it could be better arranged or expressed, please let me know. cheers, robert h. > -----Original Message----- > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > Sent: Tuesday, February 24, 2004 10:19 > To: 'nsis'; Henning Schulzrinne; Hancock, Robert > Subject: GIMPS scalability >=20 >=20 > Hi Henning and Robert, >=20 > I have some comment regarding scalability. In GIMPS draft=20 > there is a scalabiliy statement: >=20 > '' Scaleable: As will be discussed in Section 4.3, up to one = messaging > association is generally kept for each adjacent GIMPS peer and > thus association state scales better than the number of sessions. > (Many peers may not have association state at all, if there are no > messages on sessions visiting those nodes that warrant such > treatment.) Messaging associations are managed based on policy at > each node, depending on trade-offs between fast peer-to-peer > communication and state overhead. Messaging association state can > be removed immediately after the last signaling session to a > particular next-hop is removed, after some delay to wait for new > sessions or only if resource demands warrant it.''=20 >=20 > It is clear that association state scales better than number=20 > of sessions because usually an associacion is used by more=20 > sessions. However, routing states are per-flow e.g. scales=20 > with number of flows, which can be an issue. Furthermore, I=20 > do not see support for aggregation in the description.=20 >=20 > Best regards, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 06:32:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13822 for ; Tue, 24 Feb 2004 06:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvanD-000680-Ah for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 06:32:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OBW30l023555 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 06:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvanC-00067b-EB; Tue, 24 Feb 2004 06:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvanA-00067I-5m for nsis@optimus.ietf.org; Tue, 24 Feb 2004 06:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13819 for ; Tue, 24 Feb 2004 06:31:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avan5-0001dX-00 for nsis@ietf.org; Tue, 24 Feb 2004 06:31:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvamH-0001YL-00 for nsis@ietf.org; Tue, 24 Feb 2004 06:31:05 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Avalb-0001PP-00 for nsis@ietf.org; Tue, 24 Feb 2004 06:30:23 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1NTH>; Tue, 24 Feb 2004 11:29:41 -0000 Message-ID: From: "Hancock, Robert" To: "'Thanh Tra LUU'" Cc: "'nsis'" Subject: RE: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) Date: Tue, 24 Feb 2004 11:29:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Tuesday, February 24, 2004 10:58 > To: Hancock, Robert > Cc: 'nsis' > Subject: Re: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS) > > > hi robert, > > > a) there is a flow from S to R, and some reverse routing state > > already exists to get signalling from R to S. Both S and R want > > to make reservations for the flow, but neither knows the S-ID > > that the other will use. Consequence: two reservations. (Another > > way of putting this: in your phrase "must represent a flow which > > is not established in the network", how would a node ever be able > > to ensure that a flow was not established in the network? This > > is information it could never know.) > > I don'n mention how to create a global SESSION_ID (e.g. random) here, > supposing that there are some ways to do it. in case of bidirectional > reservation, if these are two indenpendent reservations, it is easy, you can > take two different SESSION_IDs. NTLP can not know the relation between two > reservations. If two reservations are not independent, there must be some > mechanism to know it (off path signaling, aller-retour (reservation S to R > and then R to S or vice versa)...). i think we're in agreement here ... > > > b) at the GIMPS level you receive two discover messages for the > > same flow but from different directions (different peers). This > > might be for several reasons (some legitimate, some malicious); > > GIMPS uses the Session-ID to separate the routing state for each. > > i don't understand what flow you mean. For me, the flow from S to R and the > flow from B to A are different. > At NTLP level, if it receives two messages for the same flow but from > different directions (different peers) and IF it knows the routing is > symmetric, the route discovery is not necessary. i'll try again: there is a source address for a flow S, and a destination address R. somewhere in the middle of the network, there is a GIMPS node G. it receives a downstream signalling message claiming to be about S-->R from one peer G1 through one interface with session-ID SID1; and it receives another downstream signalling message claiming to be about S-->R from another peer G2 through another interface with session-ID SID2. it may be possible for GIMPS to work out to reject one of the messages on security grounds. however, if this is not possible, the different SIDs can still be used to prevent the two sets of routing state corrupting each other. > > > > otherwise, if i misunderstand your idea, do you mean > session-id is not > > > global ? > > > Session-ID is as global as the NSLPs make it. Typically, I assume > > it will be valid along the entire path. (This does not mean that > > there can be only one for a given flow.) There might also be reasons > > why the session changed mid-path (e.g. to interwork between sender- > > and receiver-initiated signalling paradigms at a proxy node.) It > > all depends on the NSLP. > > i agree. phew! robert h. > > Nary Tra, > ENST, Paris > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 06:47:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14433 for ; Tue, 24 Feb 2004 06:47:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avb1j-000760-IM for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 06:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OBl37j027241 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 06:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avb1h-00074z-I5; Tue, 24 Feb 2004 06:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avb1f-00074h-2j for nsis@optimus.ietf.org; Tue, 24 Feb 2004 06:46:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14424 for ; Tue, 24 Feb 2004 06:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avb1a-00031h-00 for nsis@ietf.org; Tue, 24 Feb 2004 06:46:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avb0g-0002y3-00 for nsis@ietf.org; Tue, 24 Feb 2004 06:45:59 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Avb04-0002ty-00 for nsis@ietf.org; Tue, 24 Feb 2004 06:45:22 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OBjKqY010611 for ; Tue, 24 Feb 2004 12:45:20 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 12:45:20 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Feb 2004 12:45:31 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hancock, Robert" , "'nsis'" , Henning Schulzrinne Date: Tue, 24 Feb 2004 12:49:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 24 Feb 2004 11:45:20.0369 (UTC) FILETIME=[AE285610:01C3FACB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: GIMPS scalability 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: quoted-printable Hi Robert, Thank you very much for the clarification. The reason I raised this quest= ion is that many times scalability, i.e. storing per-flow routing and res= ervation states, is mentioned as one of the main arguments against using = RSVP. RSVP aggregation targeted this problem and it is addressed in main = places in QoS NSLP draft, as well as in our RMD-QoS-model draft. I think,= it would be useful if it is pointed out also in NTLP how it is supported= in that layer. Though, I see that the necessary elements are included in= the description, a summary, like in your answer, would be useful, e.g. i= n 3.2 under Scalability. Best regards, Attila > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, February 24, 2004 11:14 AM > To: Attila B=E1der (IJ/ETH); 'nsis'; Henning Schulzrinne > Subject: RE: GIMPS scalability >=20 >=20 > hi attila, >=20 > you are quite right that the routing state scales as the > number of flows. >=20 > however, i think this is fundamentally an unavoidable > consequence of wanting to do per-flow signalling. all that > we can do in GIMPS is to ensure that routing state only > needs to be kept when absolutely necessary, i.e. to allow > the cases where routing state does not need to be kept to > be handled efficiently.=20 >=20 > so far, we've identified two such cases: >=20 > a) sending downstream signalling without requiring routing > state to be installed. this is possible with GIMPS (maybe > it needs to be made more clear) if the signalling application > so requests. >=20 > b) protecting the network from per-[micro]-flow signalling > when those flows are being handled inside an aggregate.=20 > two ways are possible: setting the RAO so datagram messages > are ignored and then C-mode signalling runs edge-to-edge > only and is not interpreted between the edges; and putting > the microflows and their signalling inside a tunnel (so they > are invisible). >=20 > In addition, the current Flow-Routing-Information allows a=20 > limited degree of wildcarding (leaving some protocol fields > unspecified) so you don't have to store identical routing state > for large numbers of nearly identical flows.=20 >=20 > We're open to additional suggestions about how to minimise > per-flow state requirements! >=20 > I am not sure whether you are asking for more description > of aggregation in the GIMPS specification, and if so, where. > My view is that aggregation itself is a signalling application > function; all that GIMPS can do is enable the micro signalling > to be ignored where appropriate. This is basically (b), where > the information is already contained in the draft - but if > you think it could be better arranged or expressed, please > let me know. >=20 > cheers, >=20 > robert h. >=20 > > -----Original Message----- > > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > > Sent: Tuesday, February 24, 2004 10:19 > > To: 'nsis'; Henning Schulzrinne; Hancock, Robert > > Subject: GIMPS scalability > >=20 > >=20 > > Hi Henning and Robert, > >=20 > > I have some comment regarding scalability. In GIMPS draft=20 > > there is a scalabiliy statement: > >=20 > > '' Scaleable: As will be discussed in Section 4.3, up to=20 > one messaging > > association is generally kept for each adjacent GIMPS peer and > > thus association state scales better than the number of sessions. > > (Many peers may not have association state at all, if there are no > > messages on sessions visiting those nodes that warrant such > > treatment.) Messaging associations are managed based on policy at > > each node, depending on trade-offs between fast peer-to-peer > > communication and state overhead. Messaging association state can > > be removed immediately after the last signaling session to a > > particular next-hop is removed, after some delay to wait for new > > sessions or only if resource demands warrant it.''=20 > >=20 > > It is clear that association state scales better than number=20 > > of sessions because usually an associacion is used by more=20 > > sessions. However, routing states are per-flow e.g. scales=20 > > with number of flows, which can be an issue. Furthermore, I=20 > > do not see support for aggregation in the description.=20 > >=20 > > Best regards, Attila >=20 > --=20 > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 07:39:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16994 for ; Tue, 24 Feb 2004 07:39:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbq4-0003J8-5c for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 07:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCd4j2012695 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 07:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbq1-0003I6-0x; Tue, 24 Feb 2004 07:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbp6-0003Et-Hj for nsis@optimus.ietf.org; Tue, 24 Feb 2004 07:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16946 for ; Tue, 24 Feb 2004 07:38:03 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avbp5-0000Nv-00 for nsis@ietf.org; Tue, 24 Feb 2004 07:38:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvboC-0000JI-00 for nsis@ietf.org; Tue, 24 Feb 2004 07:37:09 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1Avbnt-0000EQ-00 for nsis@ietf.org; Tue, 24 Feb 2004 07:36:49 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCa7S17854 for ; Tue, 24 Feb 2004 14:36:37 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 14:35:36 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1OCZaGa016546 for ; Tue, 24 Feb 2004 14:35:36 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00FRWp3K; Tue, 24 Feb 2004 14:35:34 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCZT719698 for ; Tue, 24 Feb 2004 14:35:29 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 14:35:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 14:35:28 +0200 Message-ID: Thread-Topic: WG Last Call on draft-ietf-nsis-threats-04.txt Thread-Index: AcP60q61rZtMqthCQrW1Y6BHMOkL8w== To: X-OriginalArrivalTime: 24 Feb 2004 12:35:29.0422 (UTC) FILETIME=[AFB162E0:01C3FAD2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] WG Last Call on draft-ietf-nsis-threats-04.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: , Content-Transfer-Encoding: quoted-printable Hello all, During IESG evaluation of the Framework, it has come-up that security isn't given enough consideration in the FW document. That is mostly because the information is split off into the NSIS Threats document. In order progress the FW document in the IESG, we should also submit the NSIS Threats document. Therefore, I'd like to kick-off a 2 week WG Last Call on the current threats document. The WGLC will run until March 9th. The updated document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 07:41:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17096 for ; Tue, 24 Feb 2004 07:41:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbrz-0003Rx-DG for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 07:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCf3Lc013255 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 07:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbry-0003RO-It; Tue, 24 Feb 2004 07:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbrA-0003QV-IA for nsis@optimus.ietf.org; Tue, 24 Feb 2004 07:40:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17035 for ; Tue, 24 Feb 2004 07:40:11 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avbr9-0000bi-00 for nsis@ietf.org; Tue, 24 Feb 2004 07:40:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbqB-0000Vv-00 for nsis@ietf.org; Tue, 24 Feb 2004 07:39:12 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Avbpm-0000QT-00; Tue, 24 Feb 2004 07:38:46 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCciT05489; Tue, 24 Feb 2004 14:38:44 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 14:38:33 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1OCcXkp025403; Tue, 24 Feb 2004 14:38:33 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00BHl2MC; Tue, 24 Feb 2004 14:38:32 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OCcN721600; Tue, 24 Feb 2004 14:38:23 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 14:33:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 14:33:02 +0200 Message-ID: Thread-Topic: NSIS WG Meeting at IETF59 Thread-Index: AcP60le6TtRBuKWKSeqDkDTP4xsyeA== To: Cc: X-OriginalArrivalTime: 24 Feb 2004 12:33:03.0644 (UTC) FILETIME=[58CD6DC0:01C3FAD2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS WG Meeting at IETF59 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: quoted-printable NSIS WG Meeting=20 IETF 59 MONDAY, March 1, 2004 1930-2200 WG Update - 5 min=20 Chair NSIS Documents updates - 30 min Document editors http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-01.txt NSIS Early Review - 60 min=20 Review Team Early Review discussion - 30 min all TUESDAY, March 2, 2004 1300-1400 Afternoon Sessions I Security Discussion - 20 minutes Hannes Tschofenig http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-04.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-0= 4.txt http://www.ietf.org/internet-drafts/draft-martin-nsis-nslp-security-01.tx= t QoS Model Discussion - 20 minutes Attila Bader, Cornelia Kappler, Jerry Ash http://www.ietf.org/internet-drafts/draft-bader-rmd-qos-model-00.txt http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlle= dload-00.txt http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-= concept-01.txt NSIS Mobility Discussion - 20 minutes TBA http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mo= bility-00.txt http://www.ietf.org/internet-drafts/draft-sanda-nsis-mobility-qos-proxy-0= 1.txt http://www.ietf.org/internet-drafts/draft-cheng-mobility-issues-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Feb 24 10:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23883 for ; Tue, 24 Feb 2004 10:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave5S-0006b1-EZ for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 10:03:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OF36Qe025350 for nsis-archive@odin.ietf.org; Tue, 24 Feb 2004 10:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave5N-0006Wt-Rv; Tue, 24 Feb 2004 10:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ave4Y-0005sF-Ny for nsis@optimus.ietf.org; Tue, 24 Feb 2004 10:02:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23818 for ; Tue, 24 Feb 2004 10:02:07 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ave4W-0006Ux-00 for nsis@ietf.org; Tue, 24 Feb 2004 10:02:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ave3a-0006QL-00 for nsis@ietf.org; Tue, 24 Feb 2004 10:01:10 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Ave34-0006Li-00 for nsis@ietf.org; Tue, 24 Feb 2004 10:00:38 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1OF0Zes021053; Tue, 24 Feb 2004 16:00:35 +0100 To: nsis@ietf.org Cc: "McDonald, Andrew" , "Georgios Karagiannis" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 24 Feb 2004 16:00:30 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/24/2004 16:00:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking 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 all, We have posted draft-ietf-nsis-qos-nslp-02.txt. The draft contains a number of open issues for which feedback from the WG would be helpful. In order to stimulate (and focus) discussion, I'll tackle the issues one by one in separate threads. You may have seen in draft-ietf-nsis-qos-nslp-02.txt that QSPEC objects may be stacked to allow aggregation and layering. In error-free conditions, the top of the QSPEC stack has the QSPEC object that is locally valid. A QNE may receive a QoS NSLP message with a QSPEC stack of which the top object is not recognised. This can occur under error conditions, e.g. when a domain boundary is misconfigured, or it me be the result from a policy to detect domain boundaries by encountering unrecognised QSPEC objects. In some situations, a QNE may be able to recover from the error condition by inspecting a larger portion of the stack. If and how a QNE should deal with this is still an open issue in the draft. In order to resolve this issue, the authors would like to pose the following questions to the working group: 1. Should a QNE attempt to recover from an unrecognised QSPEC stack ... a. ... in addition to sending an error message upstream? b. ... instead of sending an error message upstream? Suggestion: yes, in addition to sending an error 2. How far can a QNE inspect the QSPEC stack? a. only the next QSPEC b. the entire stack This is essentially a trade-off between the amount and type of errors that you want to recover from and the complexity. Suggestion is to allow inspection of the entire stack in case the edge QNE is the same for several layers. 3. What should be done with the stack when a deeper QSPEC is recognised a. leave intact b. discard all QSPECs above the recognised QSPEC Suggestion: discard everything above. This avoids that all subsequent QNEs need to do the same inspection. Thanks for any comments on this. Best regards, Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 01:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00235 for ; Wed, 25 Feb 2004 01:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsYV-000884-OL for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 01:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P6U3oN031244 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 01:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsYV-00087p-I6; Wed, 25 Feb 2004 01:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsY9-00086W-Ca for nsis@optimus.ietf.org; Wed, 25 Feb 2004 01:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00209 for ; Wed, 25 Feb 2004 01:29:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsY6-0002bC-00 for nsis@ietf.org; Wed, 25 Feb 2004 01:29:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsX7-0002W7-00 for nsis@ietf.org; Wed, 25 Feb 2004 01:28:38 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AvsWn-0002QX-00 for nsis@ietf.org; Wed, 25 Feb 2004 01:28:17 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1P6J6nr011989; Wed, 25 Feb 2004 14:19:20 +0800 (SGT) From: "Cheng Hong" To: , Cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 14:27:10 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <005e01c3fb68$6cd7fa10$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Sven, and all, Please see some comments below: > 1. Should a QNE attempt to recover from an unrecognised QSPEC=20 > stack ... > a. ... in addition to sending an error message upstream? > b. ... instead of sending an error message upstream? > Suggestion: yes, in addition to sending an error Does this also depend on what the error message contains and how the QNE peer responds to the error message? If the error message would simply = cause the peer QNE to resend the entire QSPEC stack, would the recover still = be necessary?=20 > 2. How far can a QNE inspect the QSPEC stack? > a. only the next QSPEC > b. the entire stack > This is essentially a trade-off between the amount and type=20 > of errors that you want to recover from and the complexity.=20 > Suggestion is to allow inspection of the entire stack in case=20 > the edge QNE is the same for several layers. Maybe this also depends on whether the recover is possible based on the = next QSPEC. If the recover isn't possible, i.e. whole stack of QSPEC needs to = be resent, there is no need to go any furhter.=20 > 3. What should be done with the stack when a deeper QSPEC is=20 > recognised > a. leave intact > b. discard all QSPECs above the recognised QSPEC > Suggestion: discard everything above. This avoids that all=20 > subsequent QNEs need to do the same inspection. This is closely related to the point 2. Does this assume that there is = no more unrecognized QSPEC between the "deeper QSPEC" and the end of the = stack? Cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 02:47:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01525 for ; Wed, 25 Feb 2004 02:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avtl4-0006CA-Ka for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 02:47:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7l6Us023787 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 02:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avtl0-0006BY-Am; Wed, 25 Feb 2004 02:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtkY-00068Z-Ng for nsis@optimus.ietf.org; Wed, 25 Feb 2004 02:46:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01499 for ; Wed, 25 Feb 2004 02:46:31 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtkU-0003Pk-00 for nsis@ietf.org; Wed, 25 Feb 2004 02:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avtja-0003LB-00 for nsis@ietf.org; Wed, 25 Feb 2004 02:45:34 -0500 Received: from gc-na165.alcatel.fr ([64.208.49.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Avtid-0003Fz-00 for nsis@ietf.org; Wed, 25 Feb 2004 02:44:35 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1P7iYes006622; Wed, 25 Feb 2004 08:44:34 +0100 Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 25 Feb 2004 08:44:31 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/25/2004 08:44:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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 Cheng Hong, Thanks for your reply. Please see my comments inline. Sven "Cheng Hong" on 25/02/2004 07:27:10 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Hi Sven, and all, Please see some comments below: > 1. Should a QNE attempt to recover from an unrecognised QSPEC > stack ... > a. ... in addition to sending an error message upstream? > b. ... instead of sending an error message upstream? > Suggestion: yes, in addition to sending an error Does this also depend on what the error message contains and how the QNE peer responds to the error message? If the error message would simply cause the peer QNE to resend the entire QSPEC stack, would the recover still be necessary? Sven>> The idea underlying the suggestion is to limit the signalling delay while still notifying upstream peers of a potential problem. It is therefore intended for the period before (any of) the upstream QNEs react to the notification by e.g. resending the stack. If the recovery turns out to be wrong, resending the stack will solve it the next time around. If it was correct, the signalling delay is minimised. > 2. How far can a QNE inspect the QSPEC stack? > a. only the next QSPEC > b. the entire stack > This is essentially a trade-off between the amount and type > of errors that you want to recover from and the complexity. > Suggestion is to allow inspection of the entire stack in case > the edge QNE is the same for several layers. Maybe this also depends on whether the recover is possible based on the next QSPEC. If the recover isn't possible, i.e. whole stack of QSPEC needs to be resent, there is no need to go any furhter. Sven>> I'll try to give an example: +-----+ QSpecC +-----+ +-----+ | QNE1|------------------------->| | | | +-----+ | | | | | | | | +-----+ QSpecB | | | | | QNE2|--------------->| QNE4|----->| QNE5| +-----+ | | | | | | | | +-----+QSpecA| | | | | QNE3|----->| | | | +-----+ | | | | +-----+ +-----+ Suppose QNE4 is the edge of the domains in which QSpecs A, B and C are valid. The stack looks like QSpecA (top)-QSpecB-QSpecC. QNE5 only knows QSpecC. Suppose for some reason QNE4 does not terminate domains A and B, then QNE5 can recover from the error by inspecting the stack 2 deep (until it finds QSpecC). The correct behaviour is then to discard everything above. This means that it might be useful to go deeper into the stack. > 3. What should be done with the stack when a deeper QSPEC is > recognised > a. leave intact > b. discard all QSPECs above the recognised QSPEC > Suggestion: discard everything above. This avoids that all > subsequent QNEs need to do the same inspection. This is closely related to the point 2. Does this assume that there is no more unrecognized QSPEC between the "deeper QSPEC" and the end of the stack? Sven>> No, in the example above QSpecB (unrecognised) is between QSpecA (unrecognised) and QSPecC (recognised). Cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 04:24:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04930 for ; Wed, 25 Feb 2004 04:24:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvH1-0003yN-LF for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 04:24:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9OB92015268 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 04:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvGy-0003xm-VO; Wed, 25 Feb 2004 04:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvuFV-0008U8-40 for nsis@optimus.ietf.org; Wed, 25 Feb 2004 03:18:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02642 for ; Wed, 25 Feb 2004 03:18:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvuFS-0006P1-00 for nsis@ietf.org; Wed, 25 Feb 2004 03:18:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvuEU-0006HW-00 for nsis@ietf.org; Wed, 25 Feb 2004 03:17:30 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AvuDX-00061O-00 for nsis@ietf.org; Wed, 25 Feb 2004 03:16:31 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1P87Qdn015400; Wed, 25 Feb 2004 16:07:34 +0800 (SGT) From: "Cheng Hong" To: Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 16:15:30 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <007401c3fb77$8ba85250$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Sven, Please see a few further comments inline: > > > 1. Should a QNE attempt to recover from an unrecognised QSPEC stack=20 > > ... > > a. ... in addition to sending an error message upstream? > > b. ... instead of sending an error message upstream? > > Suggestion: yes, in addition to sending an error >=20 > Does this also depend on what the error message contains and=20 > how the QNE peer responds to the error message? If the error=20 > message would simply cause the peer QNE to resend the entire=20 > QSPEC stack, would the recover still be necessary? >=20 > Sven>> The idea underlying the suggestion is to limit the signalling=20 > Sven>> delay > while still notifying upstream peers of a potential problem.=20 > It is therefore intended for the period before (any of) the=20 > upstream QNEs react to the notification by e.g. resending the=20 > stack. If the recovery turns out to be wrong, resending the=20 > stack will solve it the next time around. If it was correct,=20 > the signalling delay is minimised. So in this case, the QNE must be able to reconginize the certain QSPEC = has already been processed upon receiving the retransmitted QSPEC stack. The = RSN could be used, but it means different QoS Model would have to maintain = its own record of the current sequence number. > > 2. How far can a QNE inspect the QSPEC stack? > > a. only the next QSPEC > > b. the entire stack > > This is essentially a trade-off between the amount and type=20 > of errors=20 > > that you want to recover from and the complexity. Suggestion is to=20 > > allow inspection of the entire stack in case the edge QNE=20 > is the same=20 > > for several layers. >=20 > Maybe this also depends on whether the recover is possible=20 > based on the next QSPEC. If the recover isn't possible, i.e.=20 > whole stack of QSPEC needs to be resent, there is no need to=20 > go any furhter. >=20 > Sven>> I'll try to give an example: >=20 > +-----+ QSpecC +-----+ +-----+ > | QNE1|------------------------->| | | | > +-----+ | | | | > | | | | > +-----+ QSpecB | | | | > | QNE2|--------------->| QNE4|----->| QNE5| > +-----+ | | | | > | | | | > +-----+QSpecA| | | | > | QNE3|----->| | | | > +-----+ | | | | > +-----+ +-----+ >=20 > Suppose QNE4 is the edge of the domains in which QSpecs A, B=20 > and C are valid. The stack looks like QSpecA=20 > (top)-QSpecB-QSpecC. QNE5 only knows QSpecC. Suppose for some=20 > reason QNE4 does not terminate domains A and B, then QNE5 can=20 > recover from the error by inspecting the stack 2 deep (until=20 > it finds QSpecC). The correct behaviour is then to discard=20 > everything above. This means that it might be useful to go=20 > deeper into the stack. Yes. I agree that in this case, the QNE should inspect the whole stack = until it found one recognized Qspec.=20 > > 3. What should be done with the stack when a deeper QSPEC is=20 > > recognised > > a. leave intact > > b. discard all QSPECs above the recognised QSPEC > > Suggestion: discard everything above. This avoids that all=20 > subsequent=20 > > QNEs need to do the same inspection. >=20 > This is closely related to the point 2. Does this assume that=20 > there is no more unrecognized QSPEC between the "deeper=20 > QSPEC" and the end of the stack? >=20 > Sven>> No, in the example above QSpecB (unrecognised) is=20 > between QSpecA > (unrecognised) and QSPecC (recognised). >=20 >=20 My question is if there is any possibility that an Qspec D = (unrecognized) could be appear after QSpecC (recongnized)? E.g. QSpecA (unrecognized)-QspecB (unrecognized)-QspecC (recognized)-QspecD (unrecognized) Cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 04:24:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04954 for ; Wed, 25 Feb 2004 04:24:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvH9-00040d-VY for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 04:24:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9OJHK015392 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 04:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvH8-000408-UE; Wed, 25 Feb 2004 04:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvuZu-0001TK-Nw for nsis@optimus.ietf.org; Wed, 25 Feb 2004 03:39:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03450 for ; Wed, 25 Feb 2004 03:39:36 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvuZs-0000Ty-00 for nsis@ietf.org; Wed, 25 Feb 2004 03:39:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvuYr-0000Pu-00 for nsis@ietf.org; Wed, 25 Feb 2004 03:38:34 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AvuYa-0000MM-00 for nsis@ietf.org; Wed, 25 Feb 2004 03:38:16 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1P8cAes028564; Wed, 25 Feb 2004 09:38:10 +0100 Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 25 Feb 2004 09:38:08 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/25/2004 09:38:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 Cheng Hong, Please see further comments inline. Best regards, Sven "Cheng Hong" on 25/02/2004 09:15:30 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Hi Sven, Please see a few further comments inline: > > > 1. Should a QNE attempt to recover from an unrecognised QSPEC stack > > ... > > a. ... in addition to sending an error message upstream? > > b. ... instead of sending an error message upstream? > > Suggestion: yes, in addition to sending an error > > Does this also depend on what the error message contains and > how the QNE peer responds to the error message? If the error > message would simply cause the peer QNE to resend the entire > QSPEC stack, would the recover still be necessary? > > Sven>> The idea underlying the suggestion is to limit the signalling > Sven>> delay > while still notifying upstream peers of a potential problem. > It is therefore intended for the period before (any of) the > upstream QNEs react to the notification by e.g. resending the > stack. If the recovery turns out to be wrong, resending the > stack will solve it the next time around. If it was correct, > the signalling delay is minimised. So in this case, the QNE must be able to reconginize the certain QSPEC has already been processed upon receiving the retransmitted QSPEC stack. The RSN could be used, but it means different QoS Model would have to maintain its own record of the current sequence number. Sven>> The RSN is used for this (QNE keeps track of his own current sequence number and QoS model ID, see state table). If RSN or QoS model ID changes then the update is regarded as a new reservation. > > 2. How far can a QNE inspect the QSPEC stack? > > a. only the next QSPEC > > b. the entire stack > > This is essentially a trade-off between the amount and type > of errors > > that you want to recover from and the complexity. Suggestion is to > > allow inspection of the entire stack in case the edge QNE > is the same > > for several layers. > > Maybe this also depends on whether the recover is possible > based on the next QSPEC. If the recover isn't possible, i.e. > whole stack of QSPEC needs to be resent, there is no need to > go any furhter. > > Sven>> I'll try to give an example: > > +-----+ QSpecC +-----+ +-----+ > | QNE1|------------------------->| | | | > +-----+ | | | | > | | | | > +-----+ QSpecB | | | | > | QNE2|--------------->| QNE4|----->| QNE5| > +-----+ | | | | > | | | | > +-----+QSpecA| | | | > | QNE3|----->| | | | > +-----+ | | | | > +-----+ +-----+ > > Suppose QNE4 is the edge of the domains in which QSpecs A, B > and C are valid. The stack looks like QSpecA > (top)-QSpecB-QSpecC. QNE5 only knows QSpecC. Suppose for some > reason QNE4 does not terminate domains A and B, then QNE5 can > recover from the error by inspecting the stack 2 deep (until > it finds QSpecC). The correct behaviour is then to discard > everything above. This means that it might be useful to go > deeper into the stack. Yes. I agree that in this case, the QNE should inspect the whole stack until it found one recognized Qspec. > > 3. What should be done with the stack when a deeper QSPEC is > > recognised > > a. leave intact > > b. discard all QSPECs above the recognised QSPEC > > Suggestion: discard everything above. This avoids that all > subsequent > > QNEs need to do the same inspection. > > This is closely related to the point 2. Does this assume that > there is no more unrecognized QSPEC between the "deeper > QSPEC" and the end of the stack? > > Sven>> No, in the example above QSpecB (unrecognised) is > between QSpecA > (unrecognised) and QSPecC (recognised). > > My question is if there is any possibility that an Qspec D (unrecognized) could be appear after QSpecC (recongnized)? E.g. QSpecA (unrecognized)-QspecB (unrecognized)-QspecC (recognized)-QspecD (unrecognized) Sven>> Yes, that would be possible if a domain with a wider scope than QSpecC exists (e.g. end-to-end) Cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 05:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09567 for ; Wed, 25 Feb 2004 05:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwVK-0003X7-BU for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 05:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PAh2Ia013574 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 05:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwVJ-0003Wp-6d; Wed, 25 Feb 2004 05:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwV3-0003WZ-4s for nsis@optimus.ietf.org; Wed, 25 Feb 2004 05:42:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09563 for ; Wed, 25 Feb 2004 05:42:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwUz-0006lS-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:42:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvwUB-0006h5-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:41:52 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvwTs-0006cE-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:41:32 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1PAf04U029801; Wed, 25 Feb 2004 02:41:00 -0800 (PST) Received: from [10.32.245.156] (sjc-vpn3-180.cisco.com [10.21.64.180]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMQ57415; Wed, 25 Feb 2004 02:40:56 -0800 (PST) Date: Tue, 24 Feb 2004 08:21:00 -0500 From: David Oran To: "Hancock, Robert" , "'Yacine.El_Mghazli@alcatel.fr'" , sven.van_den_bosch@alcatel.be cc: Thanh Tra LUU , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Message-ID: <2147483647.1077610860@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 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 --On Tuesday, February 17, 2004 3:40 PM +0000 "Hancock, Robert" wrote: > hi all, > > GIMPS can only provide integrity protection between adjacent > QNEs. if a QNE needs to send a message with a policy object > and have it received with intact integrity protection several > QNEs away, this integrity protection must be provided within > the QoS NSLP. > and once you have this requirement, what exactly does the security provided by the transport level buy you? Bulk encryption? It seems if multiple xNE protocol elements are to be multiplexed over the same transport, but the xNE topology which processes these elements is not congruent, I wonder if the transport level security (e.g. TLS) can be relied on for much of anything. I must be missing something here, since one of the strongest motivations for a C-mode transport was exactly this. Confused, Dave. > r. > >> -----Original Message----- >> From: Yacine.El_Mghazli@alcatel.fr >> [mailto:Yacine.El_Mghazli@alcatel.fr] >> Sent: Tuesday, February 17, 2004 16:30 >> To: sven.van_den_bosch@alcatel.be >> Cc: Thanh Tra LUU; nsis@ietf.org >> Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS >> >> >> nary, >> >> QoS-NSLP POLICY_DATA object carries policy elements for authorization >> purposes between two policy-capable nodes. like what was done in RSVP. >> >> how far QoS-NSLP relies on NTLP for the so-called integrity objects >> (RSVP terminology) is the issue. >> >> yacine >> >> >> >> sven.van_den_bosch@alcatel.be wrote: >> >> > Hi Nary, >> > >> > QoS NSLP has POLICY_DATA in its current version of the >> spec. Even if GIMPS >> > provides integrity, I am not sure it is unneeded in QoS >> NSLP (e.g. if QoS >> > NSLP is carrying information that is opaque for (some) >> intermediate nodes). >> > >> > Sven >> > >> > >> > >> > >> > >> > >> > "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 >> > >> > Sent by: nsis-admin@ietf.org >> > >> > >> > To: >> > cc: >> > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS >> > >> > >> > hi Sven, >> > >> > >> >> Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its >> >> security services but GIMPS alone is not sufficient because >> it does not >> >> protect against compromised QNEs, only against their >> interconnection. >> > >> > >> > do you mean QoS-NSLP would support authentication policy >> elements (as rsvp) >> > and NTLP would support integrity elements (in rsvp) or >> QoS-NSLP may do all >> > in some cases ? >> > >> > Nary Tra, >> > ENST, Paris. >> > >> > >> > _______________________________________________ >> > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 05:52:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09781 for ; Wed, 25 Feb 2004 05:52:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwe0-0004El-67 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 05:52:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PAq0U5016268 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 05:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwdz-0004EF-UF; Wed, 25 Feb 2004 05:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwdh-0004CY-HP for nsis@optimus.ietf.org; Wed, 25 Feb 2004 05:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09768 for ; Wed, 25 Feb 2004 05:51:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avwdd-0007XD-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:51:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avwch-0007Sm-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:50:40 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1Avwbn-0007Oc-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:49:43 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1PAnUq03498; Wed, 25 Feb 2004 11:49:30 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1PAnTV29151; Wed, 25 Feb 2004 11:49:29 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA14991; Wed, 25 Feb 2004 11:49:10 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Feb 2004 11:49:28 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7C22@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org, MCDONALD ANDREW , "'Georgios Karagiannis'" Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 11:49:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Sven, regarding=20 "3. What should be done with the stack when a deeper QSPEC is = recognised a. leave intact b. discard all QSPECs above the recognised QSPEC Suggestion: discard everything above. This avoids that all subsequent = QNEs need to do the same inspection." I think we need to find out whether there are cases where discarding = all QSpecs above may not work, i.e. where the nesting of QoS model = domains is somehow broken (by malfunctioning or malconfigured nodes), = such that too much of the stack is thrown away. E.g. The stack has = QSpecs A-B-C, and QSpec A is not removed at the border of domain A by = QNE a2. The next QNE x doesnt recognize A, nor B, so it removes the two = and works on C. However somehow the QNE b1 after QNE x is still in = domain B and would need QSpec B. Can we come up with such a scenario? = And if we do, would this involve so many problematic QNEs that there is = no way to recover from the problem without delay and more messages = anyways (so option (b) is fine anyways)? The following picture illustrates what I am trying to say: normal operation. Probably QNE x would not be on the path, or at least = would not need to interprete QSpec B: ABC --> BC --> BC QNE a1 QNE a2 QNE b1 faulty operation: Because of QNE a2 malfunctioning, may be it is broken = down, the message gets routed via QNE x, which is outside domain B, or = at least not configured to handle QSpec B, but then reenters the proper = path via domain B: ABC --> ABC --> C --> ? QNE a1 QNE a2 QNE x QNE b1 Is such a scenario at all possible? Cornelia =20 > -----Urspr=FCngliche Nachricht----- > Von: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] Im=20 > Auftrag von sven.van_den_bosch@alcatel.be > Gesendet: Mittwoch, 25. Februar 2004 09:38 > An: Cheng Hong > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > Betreff: RE: [NSIS] QoS NSLP open issue on error cases with=20 > QSPEC stacking >=20 >=20 > Hi Cheng Hong, >=20 > Please see further comments inline. >=20 > Best regards, > Sven >=20 >=20 >=20 >=20 >=20 > "Cheng Hong" on 25/02/2004 09:15:30 >=20 > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > cc: , "'McDonald, Andrew'"=20 > , > "'Georgios Karagiannis'" > Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC > stacking >=20 >=20 > Hi Sven, >=20 > Please see a few further comments inline: >=20 >=20 > > > > > 1. Should a QNE attempt to recover from an unrecognised=20 > QSPEC stack > > > ... > > > a. ... in addition to sending an error message upstream? > > > b. ... instead of sending an error message upstream? > > > Suggestion: yes, in addition to sending an error > > > > Does this also depend on what the error message contains and > > how the QNE peer responds to the error message? If the error > > message would simply cause the peer QNE to resend the entire > > QSPEC stack, would the recover still be necessary? > > > > Sven>> The idea underlying the suggestion is to limit the = signalling > > Sven>> delay > > while still notifying upstream peers of a potential problem. > > It is therefore intended for the period before (any of) the > > upstream QNEs react to the notification by e.g. resending the > > stack. If the recovery turns out to be wrong, resending the > > stack will solve it the next time around. If it was correct, > > the signalling delay is minimised. >=20 > So in this case, the QNE must be able to reconginize the=20 > certain QSPEC has > already been processed upon receiving the retransmitted QSPEC=20 > stack. The > RSN > could be used, but it means different QoS Model would have to=20 > maintain its > own record of the current sequence number. >=20 > Sven>> The RSN is used for this (QNE keeps track of his own current > sequence number and QoS model ID, see state table). If RSN or=20 > QoS model ID > changes then the update is regarded as a new reservation. >=20 >=20 > > > 2. How far can a QNE inspect the QSPEC stack? > > > a. only the next QSPEC > > > b. the entire stack > > > This is essentially a trade-off between the amount and type > > of errors > > > that you want to recover from and the complexity. Suggestion is = to > > > allow inspection of the entire stack in case the edge QNE > > is the same > > > for several layers. > > > > Maybe this also depends on whether the recover is possible > > based on the next QSPEC. If the recover isn't possible, i.e. > > whole stack of QSPEC needs to be resent, there is no need to > > go any furhter. > > > > Sven>> I'll try to give an example: > > > > +-----+ QSpecC +-----+ +-----+ > > | QNE1|------------------------->| | | | > > +-----+ | | | | > > | | | | > > +-----+ QSpecB | | | | > > | QNE2|--------------->| QNE4|----->| QNE5| > > +-----+ | | | | > > | | | | > > +-----+QSpecA| | | | > > | QNE3|----->| | | | > > +-----+ | | | | > > +-----+ +-----+ > > > > Suppose QNE4 is the edge of the domains in which QSpecs A, B > > and C are valid. The stack looks like QSpecA > > (top)-QSpecB-QSpecC. QNE5 only knows QSpecC. Suppose for some > > reason QNE4 does not terminate domains A and B, then QNE5 can > > recover from the error by inspecting the stack 2 deep (until > > it finds QSpecC). The correct behaviour is then to discard > > everything above. This means that it might be useful to go > > deeper into the stack. >=20 > Yes. I agree that in this case, the QNE should inspect the whole = stack > until > it found one recognized Qspec. >=20 >=20 >=20 > > > 3. What should be done with the stack when a deeper QSPEC is > > > recognised > > > a. leave intact > > > b. discard all QSPECs above the recognised QSPEC > > > Suggestion: discard everything above. This avoids that all > > subsequent > > > QNEs need to do the same inspection. > > > > This is closely related to the point 2. Does this assume that > > there is no more unrecognized QSPEC between the "deeper > > QSPEC" and the end of the stack? > > > > Sven>> No, in the example above QSpecB (unrecognised) is > > between QSpecA > > (unrecognised) and QSPecC (recognised). > > > > >=20 > My question is if there is any possibility that an Qspec D=20 > (unrecognized) > could be appear after QSpecC (recongnized)? E.g. QSpecA > (unrecognized)-QspecB (unrecognized)-QspecC (recognized)-QspecD > (unrecognized) >=20 > Sven>> Yes, that would be possible if a domain with a wider scope = than > QSpecC exists (e.g. end-to-end) >=20 > Cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 05:56:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09984 for ; Wed, 25 Feb 2004 05:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwhv-0004nM-8k for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 05:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PAu35b018393 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 05:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwhu-0004mX-Os; Wed, 25 Feb 2004 05:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwha-0004l6-9z for nsis@optimus.ietf.org; Wed, 25 Feb 2004 05:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09921 for ; Wed, 25 Feb 2004 05:55:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwhW-0000AZ-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avwga-00002J-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:54:41 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Avwff-0007ej-00 for nsis@ietf.org; Wed, 25 Feb 2004 05:53:43 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1369>; Wed, 25 Feb 2004 10:53:14 -0000 Message-ID: From: "McDonald, Andrew" To: "'Cheng Hong'" , sven.van_den_bosch@alcatel.be, nsis@ietf.org Cc: "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 10:53:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 all, [I've replied to this message in the thread, since I got confused about some points later on in the discussion....] Cheng Hong wrote: > Please see some comments below: > > >> 1. Should a QNE attempt to recover from an unrecognised QSPEC stack >> ... a. ... in addition to sending an error message upstream? >> b. ... instead of sending an error message upstream? >> Suggestion: yes, in addition to sending an error > > Does this also depend on what the error message contains and how the > QNE peer responds to the error message? If the error message would > simply cause the peer QNE to resend the entire QSPEC stack, would the > recover still be necessary? I think that the error message says "you've sent me a qos model I don't understand. i've recovered from it by looking deeper." or "you've sent me a qos model I don't understand. i've given up.". The node receiving this should not repeat the RESERVE with the same qos model (resending the same QSpec stack doesn't appear to help in any way). It might resend a different QSpec stack (e.g. without the top one, or use some different qos model entirely). >> 2. How far can a QNE inspect the QSPEC stack? >> a. only the next QSPEC >> b. the entire stack >> This is essentially a trade-off between the amount and type >> of errors that you want to recover from and the complexity. >> Suggestion is to allow inspection of the entire stack in case >> the edge QNE is the same for several layers. > > Maybe this also depends on whether the recover is possible based on > the next QSPEC. If the recover isn't possible, i.e. whole stack of > QSPEC needs to be resent, there is no need to go any furhter. There is also option z (which comes before 'a'), which is that you only look at the top QSpec and never try to recover by looking deeper. I'm not sure what you mean by "whole stack of QSPEC needs to be resent", since this about attempting recovering without requiring anything to be resent. (I see later in the thread you've replied to Sven's example and think option (b) is ok). >> 3. What should be done with the stack when a deeper QSPEC is >> recognised a. leave intact >> b. discard all QSPECs above the recognised QSPEC >> Suggestion: discard everything above. This avoids that all >> subsequent QNEs need to do the same inspection. > > This is closely related to the point 2. Does this assume that there > is no more unrecognized QSPEC between the "deeper QSPEC" and the end > of the stack? Yes, this does follow on from (2), but I don't see how your second sentence is relevant. To give an example. A sequence of three QNEs in this part of the path: .... <---> A <---> B <---> C <---> .... A sends B a RESERVE containing {QSpec2,QSpec1} (for qos model 2, and qos model 1). QSpec2 is the 'top' of the stack. B doesn't understand qos model 2. Going with the 'look deeper' solution, it looks at QSpec1. Now, what should B send to C? option (a) is {QSpec2,QSpec1} option (b) is {QSpec1} regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 06:10:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10403 for ; Wed, 25 Feb 2004 06:10:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwvT-0005YJ-9t for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 06:10:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PBA2BW021305 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 06:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwvS-0005XS-EP; Wed, 25 Feb 2004 06:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avwv7-0005W4-PG for nsis@optimus.ietf.org; Wed, 25 Feb 2004 06:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10346 for ; Wed, 25 Feb 2004 06:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avwv4-0001Q7-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avwu6-0001JB-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:08:39 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Avwt9-00018k-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:07:39 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN137V>; Wed, 25 Feb 2004 11:07:07 -0000 Message-ID: From: "Hancock, Robert" To: "'David Oran'" , "'Yacine.El_Mghazli@alcatel.fr'" , sven.van_den_bosch@alcatel.be Cc: Thanh Tra LUU , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Wed, 25 Feb 2004 11:07:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , dave, this is a reasonable question. i would perceive there are being three points (roughly in increasing order of importance, in my perception anyway...) 1. yes, bulk encryption is useful anyway. (one of the points raised by Steve Bellovin during the requirements review was that signalling data is actually more sensitive than 'ordinary' data, and so protection of it was worth making possible almost as a default, without depending on each signalling application to design their own method.) 2. in some (many?) cases, it is *only* adjacent signalling application peers which need direct security associations. in that case, the signalling application doesn't need to specify additional security measures (this depends on how much GIMPS exposes the details of the peer authentication the signalling applications, which is still somewhat open). [A point to note, maybe: as GIMPS develops, we are getting closer to the goal of ensuring that multiple xNEs use the same transport *only* if there is an instance of each xNE at each end of that transport. (This is basically the 'intermediary' discussion, and is one reason to try to get rid of them.) In other words, the situation that you raise of "the xNE topology which processes these elements is not congruent" should be prevented from happening by the way the GIMPS peer discovery process and C-mode setup actually works.] 3. we are keen to prevent signalling applications being DoS'ed with (for example) fake messages, including messages which require a significant computational effort to validate (e.g. traversing a certificate chain and verifying signatures). the GIMPS-level security protection allows you to reduce the number of nodes through which such messages can be sent (only the GIMPS authenticated peers) and to do source authentication to ensure that the messages really have come from those peers. in that sense, the lower level security protection complements (but would not be replaced by) higher level CMS-like methods in the signalling applications. it isn't pretty, I accept. but protecting signalling applications from DoS attacks from random off-path nodes without requiring them all to implement their own message-by-message cookie exchanges (or whatever) is a significant issue (in my view), as well as the other points. cheers, robert h. > -----Original Message----- > From: David Oran [mailto:oran@cisco.com] > Sent: Tuesday, February 24, 2004 13:21 > To: Hancock, Robert; 'Yacine.El_Mghazli@alcatel.fr'; > sven.van_den_bosch@alcatel.be > Cc: Thanh Tra LUU; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > --On Tuesday, February 17, 2004 3:40 PM +0000 "Hancock, Robert" > wrote: > > > hi all, > > > > GIMPS can only provide integrity protection between adjacent > > QNEs. if a QNE needs to send a message with a policy object > > and have it received with intact integrity protection several > > QNEs away, this integrity protection must be provided within > > the QoS NSLP. > > > and once you have this requirement, what exactly does the > security provided > by the transport level buy you? Bulk encryption? It seems if > multiple xNE > protocol elements are to be multiplexed over the same > transport, but the > xNE topology which processes these elements is not congruent, > I wonder if > the transport level security (e.g. TLS) can be relied on for much of > anything. > > I must be missing something here, since one of the strongest > motivations > for a C-mode transport was exactly this. > > Confused, Dave. > > r. > > > >> -----Original Message----- > >> From: Yacine.El_Mghazli@alcatel.fr > >> [mailto:Yacine.El_Mghazli@alcatel.fr] > >> Sent: Tuesday, February 17, 2004 16:30 > >> To: sven.van_den_bosch@alcatel.be > >> Cc: Thanh Tra LUU; nsis@ietf.org > >> Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > >> > >> > >> nary, > >> > >> QoS-NSLP POLICY_DATA object carries policy elements for > authorization > >> purposes between two policy-capable nodes. like what was > done in RSVP. > >> > >> how far QoS-NSLP relies on NTLP for the so-called integrity objects > >> (RSVP terminology) is the issue. > >> > >> yacine > >> > >> > >> > >> sven.van_den_bosch@alcatel.be wrote: > >> > >> > Hi Nary, > >> > > >> > QoS NSLP has POLICY_DATA in its current version of the > >> spec. Even if GIMPS > >> > provides integrity, I am not sure it is unneeded in QoS > >> NSLP (e.g. if QoS > >> > NSLP is carrying information that is opaque for (some) > >> intermediate nodes). > >> > > >> > Sven > >> > > >> > > >> > > >> > > >> > > >> > > >> > "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 > >> > > >> > Sent by: nsis-admin@ietf.org > >> > > >> > > >> > To: > >> > cc: > >> > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > >> > > >> > > >> > hi Sven, > >> > > >> > > >> >> Sven>> Imho, the QoS NSLP should rely on GIMPS for > some/most of its > >> >> security services but GIMPS alone is not sufficient because > >> it does not > >> >> protect against compromised QNEs, only against their > >> interconnection. > >> > > >> > > >> > do you mean QoS-NSLP would support authentication policy > >> elements (as rsvp) > >> > and NTLP would support integrity elements (in rsvp) or > >> QoS-NSLP may do all > >> > in some cases ? > >> > > >> > Nary Tra, > >> > ENST, Paris. > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 06:11:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10469 for ; Wed, 25 Feb 2004 06:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwwQ-0005iI-ES for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 06:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PBB2Yf021847 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 06:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwwP-0005dz-1Q; Wed, 25 Feb 2004 06:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avww7-0005dN-Tl for nsis@optimus.ietf.org; Wed, 25 Feb 2004 06:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10429 for ; Wed, 25 Feb 2004 06:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avww4-0001Xb-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvwvD-0001RF-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:09:48 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AvwuO-0001Fh-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:08:56 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN137Y>; Wed, 25 Feb 2004 11:08:27 -0000 Message-ID: From: "McDonald, Andrew" To: "'Kappler Cornelia'" , "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org, "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 11:08:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Cornelia, Kappler Cornelia wrote: > regarding > > "3. What should be done with the stack when a deeper QSPEC is > recognised a. leave intact > b. discard all QSPECs above the recognised QSPEC > Suggestion: discard everything above. This avoids that all subsequent > QNEs need to do the same inspection." > > I think we need to find out whether there are cases where discarding > all QSpecs above may not work, i.e. where the nesting of QoS model > domains is somehow broken (by malfunctioning or malconfigured nodes), > such that too much of the stack is thrown away. E.g. The stack has > QSpecs A-B-C, and QSpec A is not removed at the border of domain A by > QNE a2. The next QNE x doesnt recognize A, nor B, so it removes the > two and works on C. However somehow the QNE b1 after QNE x is still > in domain B and would need QSpec B. Can we come up with such a > scenario? And if we do, would this involve so many problematic QNEs > that there is no way to recover from the problem without delay and > more messages anyways (so option (b) is fine anyways)? Yes. I agree. Essentially the whole problem is one of trying to recover in the face of misconfiguration anyway. If one thing is broken, how correct should we assume later elements to be. Point 3 can be thought of as 'the edge was missing, so should this node make itself the new edge?'. If it is a node in the middle of the B domain that is 'wrong' then becoming a new edge could break things even more. > The following picture illustrates what I am trying to say: > > normal operation. Probably QNE x would not be on the path, or at > least would not need to interprete QSpec B: > > ABC --> BC --> BC > QNE a1 QNE a2 QNE b1 > > faulty operation: Because of QNE a2 malfunctioning, may be it is > broken down, the message gets routed via QNE x, which is outside > domain B, or at least not configured to handle QSpec B, but then > reenters the proper path via domain B: > > ABC --> ABC --> C --> ? > QNE a1 QNE a2 QNE x QNE b1 > > Is such a scenario at all possible? I think that is a key question. It is not obvious how to prevent it. I suppose, in a way we are asking: 'how are people going to get their network configuration wrong?', which is rather a difficult one to answer. If the problem is that 'edge' nodes don't undo QSpec stacking, then you might want the node receiving the unknown QSpec to become the edge (look deeper, and strip). You probably also want to send back error messages, asking the previous node to become the edge (don't send me a QSpec for that qos model again). If problem is 'non-edge' nodes that don't understand QoS models they should, then you want things to carry on as if that node wasn't there (possibly look deeper, but don't strip). In this case, sending errors back might also be the wrong answer (if it tells previous nodes not to send something they should be sending). regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 06:17:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10774 for ; Wed, 25 Feb 2004 06:17:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx2D-0006Q5-JR for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 06:17:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PBH19n024662 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 06:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx2D-0006Pf-3u; Wed, 25 Feb 2004 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avx1y-0006PG-Kg for nsis@optimus.ietf.org; Wed, 25 Feb 2004 06:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10758 for ; Wed, 25 Feb 2004 06:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avx1u-0002D9-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:16:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avx0v-00026j-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:15:41 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Avx01-0001uM-00 for nsis@ietf.org; Wed, 25 Feb 2004 06:14:45 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1PB5g6p019900; Wed, 25 Feb 2004 19:05:50 +0800 (SGT) From: "Cheng Hong" To: "'McDonald, Andrew'" , , Cc: "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 19:13:46 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <008e01c3fb90$729fbf00$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Andrew, Please see some comments below: >=20 > I think that the error message says "you've sent me a qos=20 > model I don't understand. i've recovered from it by looking=20 > deeper." or "you've sent me a qos model I don't understand.=20 > i've given up.". The node receiving this should not repeat=20 > the RESERVE with the same qos model (resending the same QSpec=20 > stack doesn't appear to help in any way). It might resend a=20 > different QSpec stack (e.g. without the top one, or use some=20 > different qos model entirely). If the peer QNE decides to send a different Qspec, it may means that the = QNE should not do any recover. The resent does not need to be the exact = Qspec stack. It could only contains the "correct" stack. I agree with Sven that the recover can help in saving some time for the = QNE instead of waiting for the peer QNE to reply. But this does not seem to = be a very compelling reason. >=20 > There is also option z (which comes before 'a'), which is=20 > that you only look at the top QSpec and never try to recover=20 > by looking deeper. >=20 > I'm not sure what you mean by "whole stack of QSPEC needs to=20 > be resent", since this about attempting recovering without=20 > requiring anything to be resent. That is the point I raised above. If the "error" triggers the resent, = there may be no need to do recover. Also, how would the peer QNE know if this QNE could recover from the = error message? It might still need to recontruct a correct RESERV message, and resent. > (I see later in the thread you've replied to Sven's example=20 > and think option (b) is ok). In the case drawn out by Sven, it seems that option (b) is OK. > >> 3. What should be done with the stack when a deeper QSPEC is > >> recognised a. leave intact > >> b. discard all QSPECs above the recognised QSPEC > >> Suggestion: discard everything above. This avoids that all=20 > subsequent=20 > >> QNEs need to do the same inspection. > >=20 > > This is closely related to the point 2. Does this assume=20 > that there is=20 > > no more unrecognized QSPEC between the "deeper QSPEC" and=20 > the end of=20 > > the stack? >=20 > Yes, this does follow on from (2), but I don't see how your=20 > second sentence is relevant. >=20 > To give an example. A sequence of three QNEs in this part of=20 > the path: .... <---> A <---> B <---> C <---> .... >=20 > A sends B a RESERVE containing {QSpec2,QSpec1} (for qos model=20 > 2, and qos model 1). QSpec2 is the 'top' of the stack. B=20 > doesn't understand qos model 2. Going with the 'look deeper'=20 > solution, it looks at QSpec1. >=20 > Now, what should B send to C? > option (a) is {QSpec2,QSpec1} > option (b) is {QSpec1} >=20 Suppose the stack looks like (QSpec2, Qspec1, Qspec 0) According to (b), it would be (QSpec1, QSpec0). The question is "is = there any chance that QSpec0" is also unrecongnized? Best regards Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 08:00:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14859 for ; Wed, 25 Feb 2004 08:00:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avye1-0006E8-2S for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 08:00:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PD083G023920 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 08:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avydt-0006D3-Kr; Wed, 25 Feb 2004 08:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avyde-0006C3-RN for nsis@optimus.ietf.org; Wed, 25 Feb 2004 07:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14839 for ; Wed, 25 Feb 2004 07:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avydd-0004k9-00 for nsis@ietf.org; Wed, 25 Feb 2004 07:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avyci-0004fv-00 for nsis@ietf.org; Wed, 25 Feb 2004 07:58:49 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AvycX-0004bW-00 for nsis@ietf.org; Wed, 25 Feb 2004 07:58:37 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i1PCwZq25569; Wed, 25 Feb 2004 13:58:35 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1PCwZT03695; Wed, 25 Feb 2004 13:58:35 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Feb 2004 13:57:56 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685E00@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'David Oran'" , "Hancock, Robert" , "'Yacine.El_Mghazli@alcatel.fr'" , sven.van_den_bosch@alcatel.be Cc: Thanh Tra LUU , nsis@ietf.org Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS Date: Wed, 25 Feb 2004 13:58:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 dave, you addressed different issue in your mail: 1) existing security protocols existing security protocols provide sophisticated authentication and key exchange mechanisms. typically these protocols are split into two phases: one which performs authentication and key exchange and the second phase applies security protection (integrity, confidentiality protection) you need to know to which entity to send a message before you apply security protection. the availability of these security protocols has an impact on the choice of the transport layer protocol (but this is not the only criteria for selection of a transport protocol). 2) security at the nslp layer vs. ntlp layer you need to secure payloads at the nslp layer (some specific qos objects, for exampe) most likely only between non-neighboring nodes. you can compare this functionality with security mechanisms in sip or diameter. cms usage for protection of key transport was suggested in diameter. end-to-end security mechanism in SIP is other example. these mechanisms are used in addition to security protection between neighboring peers due to some specific requirements (with the corresponding semantics). what would you think if i would suggest to protect every diameter or every sip message between neighboring nodes with cms or s/smime? you would, most likely, argue that i am completely crazy. ciao hannes > -----Original Message----- > From: David Oran [mailto:oran@cisco.com] > Sent: Tuesday, February 24, 2004 2:21 PM > To: Hancock, Robert; 'Yacine.El_Mghazli@alcatel.fr'; > sven.van_den_bosch@alcatel.be > Cc: Thanh Tra LUU; nsis@ietf.org > Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > > > --On Tuesday, February 17, 2004 3:40 PM +0000 "Hancock, Robert" > wrote: > > > hi all, > > > > GIMPS can only provide integrity protection between adjacent > > QNEs. if a QNE needs to send a message with a policy object > > and have it received with intact integrity protection several > > QNEs away, this integrity protection must be provided within > > the QoS NSLP. > > > and once you have this requirement, what exactly does the > security provided > by the transport level buy you? Bulk encryption? It seems if > multiple xNE > protocol elements are to be multiplexed over the same > transport, but the > xNE topology which processes these elements is not congruent, > I wonder if > the transport level security (e.g. TLS) can be relied on for much of > anything. > > I must be missing something here, since one of the strongest > motivations > for a C-mode transport was exactly this. > > Confused, Dave. > > r. > > > >> -----Original Message----- > >> From: Yacine.El_Mghazli@alcatel.fr > >> [mailto:Yacine.El_Mghazli@alcatel.fr] > >> Sent: Tuesday, February 17, 2004 16:30 > >> To: sven.van_den_bosch@alcatel.be > >> Cc: Thanh Tra LUU; nsis@ietf.org > >> Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > >> > >> > >> nary, > >> > >> QoS-NSLP POLICY_DATA object carries policy elements for > authorization > >> purposes between two policy-capable nodes. like what was > done in RSVP. > >> > >> how far QoS-NSLP relies on NTLP for the so-called integrity objects > >> (RSVP terminology) is the issue. > >> > >> yacine > >> > >> > >> > >> sven.van_den_bosch@alcatel.be wrote: > >> > >> > Hi Nary, > >> > > >> > QoS NSLP has POLICY_DATA in its current version of the > >> spec. Even if GIMPS > >> > provides integrity, I am not sure it is unneeded in QoS > >> NSLP (e.g. if QoS > >> > NSLP is carrying information that is opaque for (some) > >> intermediate nodes). > >> > > >> > Sven > >> > > >> > > >> > > >> > > >> > > >> > > >> > "Thanh Tra LUU" @ietf.org on 17/02/2004 15:53:29 > >> > > >> > Sent by: nsis-admin@ietf.org > >> > > >> > > >> > To: > >> > cc: > >> > Subject: Re: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS > >> > > >> > > >> > hi Sven, > >> > > >> > > >> >> Sven>> Imho, the QoS NSLP should rely on GIMPS for > some/most of its > >> >> security services but GIMPS alone is not sufficient because > >> it does not > >> >> protect against compromised QNEs, only against their > >> interconnection. > >> > > >> > > >> > do you mean QoS-NSLP would support authentication policy > >> elements (as rsvp) > >> > and NTLP would support integrity elements (in rsvp) or > >> QoS-NSLP may do all > >> > in some cases ? > >> > > >> > Nary Tra, > >> > ENST, Paris. > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Feb 25 09:53:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18784 for ; Wed, 25 Feb 2004 09:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0PG-0007vx-9O for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 09:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEr28E030485 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 09:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0PF-0007va-Tn; Wed, 25 Feb 2004 09:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0OI-0007rO-7r for nsis@optimus.ietf.org; Wed, 25 Feb 2004 09:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18749 for ; Wed, 25 Feb 2004 09:51:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0OG-0007X5-00 for nsis@ietf.org; Wed, 25 Feb 2004 09:52:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0NS-0007Rv-00 for nsis@ietf.org; Wed, 25 Feb 2004 09:51:11 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0Mt-0007L6-00 for nsis@ietf.org; Wed, 25 Feb 2004 09:50:35 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1PHG>; Wed, 25 Feb 2004 14:50:04 -0000 Message-ID: From: "Hancock, Robert" To: "'Michael Richardson'" , nsis@ietf.org Subject: RE: [NSIS] review - some security comments on documents Date: Wed, 25 Feb 2004 14:50:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Michael, Thanks again for this; the belated reply is caused by a desire to do some deeper thinking at leisure. Apologies for the long mail. I fully agree with the view that security attributes of a protocol cannot be divorced from thinking about the way that it is actually going to be used. What is less clear to me is how this desire translates into working methodology. I've tried to explain the "how we got here and how it's justified" in a bit more detail in-line below. But the top level summary is that the framework discussion and process (of which the actual framework document only contains a small proportion) identified the need for a common protocol with a similar degree of application/scenario neutrality to (say) SCTP (i.e. something much less specific than e.g. Diameter or SIP), i.e. a "thin" common protocol. Given that decision, our next step is to design the real NTLP protocol and make sure its security (and other) properties are actually well defined (i.e. not just a wish-list which might be impossible to fulfil in a real design once other requirements are also taken into account). It is then up to users of that protocol (the NSLP designers) to do a proper evaluation of the overall solution, including how they use the NTLP, their other assumptions about the network environment, and what 'internal' security measures they provide. (If you think this is a bad way to proceed, please check out the extra background below as well. The crucial point is whether the amount of background work which was done matches the thin-ness of the protocol we intend to provide.) Since this is in many ways a process discussion, one thing that would be really helpful would be if you could provide some pointers to other protocol development activities in the IETF for similar types of protocol (i.e. - I claim - relatively application-neutral container protocols) where a 'good' process has been gone through in advance to pin down the protocol security requirements more precisely through use cases and so on. That would make it much easier for people like me to understand how to address the issue. Thanks, Robert H. > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Thursday, February 12, 2004 15:41 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] review - some security comments on documents > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Hancock" == Hancock, Robert writes: > Hancock> The problem is that the trust/security models > IMHO can't be > Hancock> fully defined by the NTLP but are signalling application > Hancock> specific (and probably in fact also deployment > specific). > > This is a very serious issue. > It means that it may be really inappropriate to have a > common protocol. > > Yes, other protocols, INCLUDING IPsec suffer from this as well. > Yes, this is a problem. > I suggest more real-life use cases be developed and documented. I think the point here is that it may be really inappropriate to have a 'thick' common protocol, but that it may still be appropriate to have a 'thin' common protocol. In fact, the common protocol got progressively thinner during the framework evolution (it started out rather like Diameter-base, and it has ended up looking from the outside as a sort of UDP+++). Reminiscing, the thought process we have been through was roughly as follows: 1. During the framework activity, we did consider a range of application scenarios, thinking how the signalling would work in them and what features were common between them. A lot of this work was done in separate documents about those signalling applications, and not formally documented. (Partly, we were under constant pressure to keep things concise.) The end result is essentially an educated guess about the right place to put a split in a layer model, where the reasoning which is behind the guesswork is given somewhat abstractly and referring to the concrete scenario work that was also done. 2. We assumed that it was not a good idea to attempt to be more specific about exactly what the common protocol should do in the framework, because there were still a lot of tradeoffs to be made and feasibility to be established. In other words, to get more concreteness, it was better to start the protocol design and just use the framework as guidance. 3. For the security aspects of the common protocol design, we now have a choice: a) Describe how the NTLP could be used in a number of examples for different applications and what the security implications would be, or b) Design a concrete protocol (currently GIMPS) which basically matches the framework goals; establish its security properties more precisely, and then check if it can actually be used. 4. I think we are doing stage (b), but your view is that doing this is premature without going through stage (a). My feeling is that to do (a) would be essentially to repeat the framework activities in more detail and with more documentation, but probably (if we stick with the assumption of a thin NTLP) with not much difference in the result. On the other hand, it would still be a non-authoritative result, since we can only know what are the security properties of something we have designed, not something we would like to be able to design. > > Hancock> I'm fairly certain in my own head, however, that the NTLP needs > Hancock> to be flexible (i.e. not constrain) what trust/security models > Hancock> can be used. To draw a comparison, 3436 and 3554 contain > Hancock> basically no discussion of such issues; I think the NTLP needs > Hancock> to go a bit further, but not very far. > > Flexible = complex => tends to be insecure. > In general I would agree, but this is why we made the 'thin vs. thick' tradeoff described above. To try to be a bit less fluffy, I tried to write down what the actual properties (especially security properties) of GIMPS are in a slightly more formal way. They seem to be: a) To deliver individual messages referring to flow F from node A to node B and back again. b) To ensure that nodes A and B really are on the path taken by flow F. c) To ensure that nodes A and B really are nearest neighbours for a given signalling application. d) To protect the message payloads from on-path attacks by non-NSIS nodes. e) To ensure that signalling applications are only forced to process messages from authenticated peers (for the same signalling application), including rejecting messages from off-path nodes. It is not clear to me how much these would modified by more detailed considerations of trust models for particular use cases (I could be wildly wrong). (b) is done mainly internally by GIMPS based on return-routability-types checks. Where more work might be needed is on (c) and (d), which are basically entirely dependent on on what cryptographic peer authentication method is to be used (which also slightly supports the (e) property). The GIMPS requirement would I think be for "DoS-resistant mutual authentication, generating keying material suitable for protecting signalling messages". There are of course many authentication techniques, and many different methods for distributing credentials and shared keys and so on. However, if the overall authentication goal is met (somehow), how it is met should not have an impact on the other security properties or how the protocol is used. My instinct is to keep this aspect of the discussion as decoupled as possible from the rest of the protocol design, but I know other people disagree with me... [snip] > Hancock> - I don't see much difference either way between "RSVPv2" and > Hancock> "UDP to the RSVP port" from a complexity perspective. The > Hancock> motivation for UDP comes mainly from NAT handling issues (maybe > Hancock> this should be explained a bit more in section 8.2). > > I don't know about UDP to the RSVP port. I guess that it new to me. I should have said 'UDP to the RSVPv2 port' but the issues are the same. I added a bit more in the GIMPS-01 draft to discuss this. Not the biggest issue at the moment, fortunately ... > > p.s. not on nsis@ietf.org. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Feb 25 12:18:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00872 for ; Wed, 25 Feb 2004 12:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2fZ-0003HX-WF for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 12:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PHI1eH012580 for nsis-archive@odin.ietf.org; Wed, 25 Feb 2004 12:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2fY-0003Gn-Rr; Wed, 25 Feb 2004 12:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2eb-0003FF-2S for nsis@optimus.ietf.org; Wed, 25 Feb 2004 12:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00821 for ; Wed, 25 Feb 2004 12:16:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2eZ-0002nH-00 for nsis@ietf.org; Wed, 25 Feb 2004 12:16:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw2dx-0002if-00 for nsis@ietf.org; Wed, 25 Feb 2004 12:16:22 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Aw2dD-0002aa-00 for nsis@ietf.org; Wed, 25 Feb 2004 12:15:36 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1PQ1>; Wed, 25 Feb 2004 17:14:51 -0000 Message-ID: From: "McDonald, Andrew" To: "'Kappler Cornelia'" , "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org, "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Wed, 25 Feb 2004 17:14:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 all, Some further ruminations. Looking at this in a different way, and going back to the fundamentals: is what is being sent a "stack of QSpecs", or a "choice of QSpecs"? I think we're talking about a "stack": The source QNE is requesting the resources in the top object. So, actually processing a different object is wrong (we would be reserving something different to what we were asked for). Then, since it is the source QNE who asked for that QSpec (and sent it with the expectation of it being honoured), the responsiblity for fixing the problem should be pushed back to it. It is an error case anyway, so correctness should be the goal, rather than making it fast/seamless. It is desirable to limit the error propagation - if you know you have got bad data (a QSpec for an unsupported qos model), you should limit how far this gets propagated. Either 'fixing' the set of QSpecs at the receiving QNE, or forwarding them unchanged would result in the error affecting the resources requested at subsequent nodes. If you were to go with the "choice" view, then the source QNE would be asking for any one of the QSpecs in the set to be processed. However, you still need to handle the case where none of the QSpecs can be understood. Allowing the receiving QNE to choose also means that the RESERVE does not have a deterministic result from the sending QNEs point of view - it doesn't know which QSpec will be used. My conclusion would be that the receiving node should not attempt any recovery (looking deeper into the set of QSpecs and maybe subsequently stripping off QSpecs). Instead it should just send an error back and leave the responsibility for recovering to the sending QNE. How does that argument sound? Andrew McDonald, Andrew wrote: > I suppose, in a way we are asking: 'how are people going to get their > network configuration wrong?', which is rather a difficult one to > answer. > > If the problem is that 'edge' nodes don't undo QSpec stacking, then > you might want the node receiving the unknown QSpec to become the > edge (look deeper, and strip). You probably also want to send back > error messages, asking the previous node to become the edge (don't > send me a QSpec for that qos model again). > > If problem is 'non-edge' nodes that don't understand QoS models they > should, then you want things to carry on as if that node wasn't there > (possibly look deeper, but don't strip). In this case, sending errors > back might also be the wrong answer (if it tells previous nodes not > to send something they should be sending). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 00:16:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06145 for ; Thu, 26 Feb 2004 00:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDsT-00088H-Mj for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 00:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q5G5CZ031246 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 00:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDsQ-00087X-Kz; Thu, 26 Feb 2004 00:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDrk-00086j-Rb for nsis@optimus.ietf.org; Thu, 26 Feb 2004 00:15:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06130 for ; Thu, 26 Feb 2004 00:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwDri-0005Vz-00 for nsis@ietf.org; Thu, 26 Feb 2004 00:15:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwDqi-0005SO-00 for nsis@ietf.org; Thu, 26 Feb 2004 00:14:16 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwDq9-0005KB-00 for nsis@ietf.org; Thu, 26 Feb 2004 00:13:41 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1Q54ZH3004691; Thu, 26 Feb 2004 13:04:45 +0800 (SGT) From: "Cheng Hong" To: "'McDonald, Andrew'" , "'Kappler Cornelia'" , Cc: , "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Thu, 26 Feb 2004 13:12:40 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <004b01c3fc27$2cc15e20$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Andrew, Generally I agree that the recover at the QNE could be risky, and seems not that helpful for the system. Please see some comments inline. Cheers Cheng Hong > -----Original Message----- > From: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > Sent: Thursday, February 26, 2004 1:15 AM > To: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be'; Cheng Hong > Cc: nsis@ietf.org; 'Georgios Karagiannis' > Subject: RE: [NSIS] QoS NSLP open issue on error cases with > QSPEC stacking > > > Hi all, > > Some further ruminations. > > Looking at this in a different way, and going back to the > fundamentals: is what is being sent a "stack of QSpecs", or a > "choice of QSpecs"? > > I think we're talking about a "stack": > The source QNE is requesting the resources in the top object. > So, actually processing a different object is wrong (we would > be reserving something different to what we were asked for). > Then, since it is the source QNE who asked for that QSpec > (and sent it with the expectation of it being honoured), the > responsiblity for fixing the problem should be pushed back to it. > > It is an error case anyway, so correctness should be the > goal, rather than making it fast/seamless. It is desirable to > limit the error propagation - if you know you have got bad > data (a QSpec for an unsupported qos model), you should limit > how far this gets propagated. Either 'fixing' the set of > QSpecs at the receiving QNE, or forwarding them unchanged > would result in the error affecting the resources requested > at subsequent nodes. Agree. Based on this reasoning, recover at the QNE may result in unstable system. > If you were to go with the "choice" view, then the source QNE > would be asking for any one of the QSpecs in the set to be > processed. However, you still need to handle the case where > none of the QSpecs can be understood. Allowing the receiving > QNE to choose also means that the RESERVE does not have a > deterministic result from the sending QNEs point of view - it > doesn't know which QSpec will be used. In this case, the QNE should always send ACK (RESPONSE) for the RESERVE, which could inform the peer QNE of the Qspec being accepted. It sounds like a kind of negotiation mechanism. Is there any use case that may require such kind of use of the Qspec in RESERVE? > My conclusion would be that the receiving node should not > attempt any recovery (looking deeper into the set of QSpecs > and maybe subsequently stripping off QSpecs). Instead it > should just send an error back and leave the responsibility > for recovering to the sending QNE. > > How does that argument sound? > > > Andrew > > McDonald, Andrew wrote: > > I suppose, in a way we are asking: 'how are people going to > get their > > network configuration wrong?', which is rather a difficult one to > > answer. > > > > If the problem is that 'edge' nodes don't undo QSpec stacking, then > > you might want the node receiving the unknown QSpec to > become the edge > > (look deeper, and strip). You probably also want to send back error > > messages, asking the previous node to become the edge (don't > > send me a QSpec for that qos model again). > > > > If problem is 'non-edge' nodes that don't understand QoS > models they > > should, then you want things to carry on as if that node > wasn't there > > (possibly look deeper, but don't strip). In this case, > sending errors > > back might also be the wrong answer (if it tells previous nodes not > > to send something they should be sending). > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to Roke Manor Research Ltd and must not be > passed to any third party without permission. This > communication is for information only and shall not create or > change any contractual relationship. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 04:40:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01070 for ; Thu, 26 Feb 2004 04:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwI05-0005at-DU for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 04:40:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9eDaE021500 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 04:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHzv-0005aG-AY; Thu, 26 Feb 2004 04:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHzR-0005YF-6S for nsis@optimus.ietf.org; Thu, 26 Feb 2004 04:39:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01013 for ; Thu, 26 Feb 2004 04:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHzO-0007Lh-00 for nsis@ietf.org; Thu, 26 Feb 2004 04:39:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHyT-0007H3-00 for nsis@ietf.org; Thu, 26 Feb 2004 04:38:34 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AwHxn-0007Cp-00 for nsis@ietf.org; Thu, 26 Feb 2004 04:37:51 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1Q9bSN19009; Thu, 26 Feb 2004 10:37:28 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i1Q9bQV21236; Thu, 26 Feb 2004 10:37:26 +0100 (MET) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA14182; Thu, 26 Feb 2004 10:37:24 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 10:37:25 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7C31@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: MCDONALD ANDREW , Kappler Cornelia , "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org, "'Georgios Karagiannis'" Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Thu, 26 Feb 2004 10:37:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Andrew,=20 I also agree putting too much "intelligence" into QNEs (i.e. = assumptions on what went wrong and hence how it is to be fixed) may = result in hard-to-understand system behaviour and backfire (i.e. not = speed up processing).=20 On the other hand, imagine a QNI trying to set up a reservation with an = unknown QNR many domains away (e.g. reserving IP telephony resources = between Europe and the Solomon Islands). Of course the QNI doesnt know = what QoS model the QNR understands. So it will pick a "well known" QoS = model for the first QSpec, and then may be stack a local QoS model on = top. At the border of QNIs domain, the local QSpec will be popped, and = possibly, depending on SLAs between domains, the bottom QSpec will be = rewritten (is this allowed by qos-nslp?). So the RESERVE proceeds = through a multitude of domains. Now one domain somewhere does not = recognize the QoS model in the bottom QSpec. Do we really want to stop = the RESERVE until this domain and the originating domain came up with a = solution? May be a "graceful fallback" would be to send an error = message, and continue to forward the RESERVE and put up with one domain = on the path not reserving resources. This is similar to how RSVP works = I believe. This raises the question of whether we should have a "default QoS = model" that must be understood by everybody (a can of worms, I know, so = probably not)?=20 How would the "graceful fallback" be realized? Popping a QSpec when = there is no other left is no good (another reason why the original idea = needs amendment). So may be the QNE who does not understand the topmost = QSpec tags it. The next QNE would again try and interpret the topmost = object. If it succeeds, apparently (assumption!) the QNE before was = _within_ the QoS model domain but malconfigured. The RESERVE proceeds = with the tag which tells the QNE popping the topmost QSpec one (or at = least one - depending on how many bits we spend on this) QNE was unable = to reserve resources. May be because we already sent the error message, = the tag is redundant and not necessary. Of course this procedure doesnt = help in the case of a QNE not popping a QSpec it was supposed to pop. = In this case we produce processing overhead because all QNEs up to the = QNR try to interpret a QSpec they are unable to interprete, and the = reservation fails anyways. Thinking aloud (and hoping such issues have not yet been discussed at = length on this list...), Cornelia > -----Urspr=FCngliche Nachricht----- > Von: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk]=20 > Gesendet: Mittwoch, 25. Februar 2004 18:15 > An: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be'; Cheng Hong > Cc: nsis@ietf.org; 'Georgios Karagiannis' > Betreff: RE: [NSIS] QoS NSLP open issue on error cases with=20 > QSPEC stacking >=20 >=20 > Hi all, >=20 > Some further ruminations. >=20 > Looking at this in a different way, and going back to the=20 > fundamentals: is what is being sent a "stack of QSpecs", or a=20 > "choice of QSpecs"? >=20 > I think we're talking about a "stack": > The source QNE is requesting the resources in the top object.=20 > So, actually processing a different object is wrong (we would=20 > be reserving something different to what we were asked for).=20 > Then, since it is the source QNE who asked for that QSpec=20 > (and sent it with the expectation of it being honoured), the=20 > responsiblity for fixing the problem should be pushed back to it. >=20 > It is an error case anyway, so correctness should be the=20 > goal, rather than making it fast/seamless. It is desirable to=20 > limit the error propagation - if you know you have got bad=20 > data (a QSpec for an unsupported qos model), you should limit=20 > how far this gets propagated. Either 'fixing' the set of=20 > QSpecs at the receiving QNE, or forwarding them unchanged=20 > would result in the error affecting the resources requested > at subsequent nodes. >=20 > If you were to go with the "choice" view, then the source QNE=20 > would be asking for any one of the QSpecs in the set to be=20 > processed. However, you still need to handle the case where=20 > none of the QSpecs can be understood. Allowing the receiving=20 > QNE to choose also means that the RESERVE does not have a=20 > deterministic result from the sending QNEs point of view - it=20 > doesn't know which QSpec will be used. >=20 > My conclusion would be that the receiving node should not=20 > attempt any recovery (looking deeper into the set of QSpecs=20 > and maybe subsequently stripping off QSpecs). Instead it=20 > should just send an error back and leave the responsibility=20 > for recovering to the sending QNE. >=20 > How does that argument sound? >=20 >=20 > Andrew >=20 > McDonald, Andrew wrote: > > I suppose, in a way we are asking: 'how are people going to=20 > get their > > network configuration wrong?', which is rather a difficult one to > > answer. =20 > >=20 > > If the problem is that 'edge' nodes don't undo QSpec stacking, then > > you might want the node receiving the unknown QSpec to become the > > edge (look deeper, and strip). You probably also want to send back > > error messages, asking the previous node to become the edge (don't > > send me a QSpec for that qos model again). =20 > >=20 > > If problem is 'non-edge' nodes that don't understand QoS models = they > > should, then you want things to carry on as if that node=20 > wasn't there > > (possibly look deeper, but don't strip). In this case,=20 > sending errors > > back might also be the wrong answer (if it tells previous nodes not > > to send something they should be sending). =20 >=20 >=20 > --=20 > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 04:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01654 for ; Thu, 26 Feb 2004 04:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIIH-0007Ns-TO for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 04:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9x12X028383 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 04:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIIH-0007Ng-J3; Thu, 26 Feb 2004 04:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIHk-0007Kx-CA for nsis@optimus.ietf.org; Thu, 26 Feb 2004 04:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01582 for ; Thu, 26 Feb 2004 04:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIHh-00014Y-00 for nsis@ietf.org; Thu, 26 Feb 2004 04:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIGk-0000zj-00 for nsis@ietf.org; Thu, 26 Feb 2004 04:57:27 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AwIG9-0000r2-00 for nsis@ietf.org; Thu, 26 Feb 2004 04:56:49 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMK37V>; Thu, 26 Feb 2004 09:56:19 -0000 Message-ID: From: "Hancock, Robert" To: "'Kappler Cornelia'" , "McDonald, Andrew" , "'sven.van_den_bosch@alcatel.be'" , Cheng Hong Cc: nsis@ietf.org, "'Georgios Karagiannis'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Thu, 26 Feb 2004 09:56:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA01583 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: quoted-printable cornelia, my mental model of operation is to consider that=20 - nodes where reservations are installed understand the QoS models that they accept reservations for (this is obvious) - nodes which request reservations of other nodes must be able to request it in language that those 'other' (neighbour) nodes understand (not quite so obvious but reasonable IMHO) in that case, the bit in your scenario where it goes > So the RESERVE proceeds through a multitude of=20 > domains. Now one domain somewhere does not recognize the QoS=20 > model in the bottom QSpec. is a should-not-happen error condition (i.e. I think this is an assumption we should make):=20 - the previous domain understood and installed the=20 reservation in its own nodes - it knows it is connected to a neighbour domain - it knows (or should find out as a matter of urgency) if that neighbour doesn't support a QoS-model that it itself does (whether that is the only model on the stack or just the topmost one doesn't really matter) - in that case, it should be able to translate its own=20 understanding of the requested QoS (it must have an=20 understanding, since it installed the reservation...) into language that the neighbour does understand. some details: i assumed that re-writing was allowed only in so far as the qos model specified it (qos models might allow re-writing of some fields but not others, for example). I assumed that arbitrary re-writing is not possible (unless=20 you terminate the signalling session at a node and start a new one) - that is what the stacking is for, to make such things unnecessary. on the gracefull fallback case: this is worth thinking about. conceptually it is not much different from passing through an NSIS-unaware node (and we certainly have to be capable of that!) cheers, robert h. > -----Original Message----- > From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > Sent: Thursday, February 26, 2004 09:37 > To: McDonald, Andrew; Kappler Cornelia;=20 > 'sven.van_den_bosch@alcatel.be'; > Cheng Hong > Cc: nsis@ietf.org; 'Georgios Karagiannis' > Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC > stacking >=20 >=20 > Hi Andrew,=20 >=20 > I also agree putting too much "intelligence" into QNEs (i.e.=20 > assumptions on what went wrong and hence how it is to be=20 > fixed) may result in hard-to-understand system behaviour and=20 > backfire (i.e. not speed up processing).=20 >=20 > On the other hand, imagine a QNI trying to set up a=20 > reservation with an unknown QNR many domains away (e.g.=20 > reserving IP telephony resources between Europe and the=20 > Solomon Islands). Of course the QNI doesnt know what QoS=20 > model the QNR understands. So it will pick a "well known" QoS=20 > model for the first QSpec, and then may be stack a local QoS=20 > model on top. At the border of QNIs domain, the local QSpec=20 > will be popped, and possibly, depending on SLAs between=20 > domains, the bottom QSpec will be rewritten (is this allowed=20 > by qos-nslp?). So the RESERVE proceeds through a multitude of=20 > domains. Now one domain somewhere does not recognize the QoS=20 > model in the bottom QSpec. Do we really want to stop the=20 > RESERVE until this domain and the originating domain came up=20 > with a solution? May be a "graceful fallback" would be to=20 > send an error message, and continue to forward the RESERVE=20 > and put up with one domain on the path not reserving=20 > resources. This is similar to how RSVP works I believe. >=20 > This raises the question of whether we should have a "default=20 > QoS model" that must be understood by everybody (a can of=20 > worms, I know, so probably not)?=20 >=20 > How would the "graceful fallback" be realized? Popping a=20 > QSpec when there is no other left is no good (another reason=20 > why the original idea needs amendment). So may be the QNE who=20 > does not understand the topmost QSpec tags it. The next QNE=20 > would again try and interpret the topmost object. If it=20 > succeeds, apparently (assumption!) the QNE before was=20 > _within_ the QoS model domain but malconfigured. The RESERVE=20 > proceeds with the tag which tells the QNE popping the topmost=20 > QSpec one (or at least one - depending on how many bits we=20 > spend on this) QNE was unable to reserve resources. May be=20 > because we already sent the error message, the tag is=20 > redundant and not necessary. Of course this procedure doesnt=20 > help in the case of a QNE not popping a QSpec it was supposed=20 > to pop. In this case we produce processing overhead because=20 > all QNEs up to the QNR try to interpret a QSpec they are=20 > unable to interprete, and the reservation fails anyways. >=20 > Thinking aloud (and hoping such issues have not yet been=20 > discussed at length on this list...), Cornelia >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk]=20 > > Gesendet: Mittwoch, 25. Februar 2004 18:15 > > An: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be'; Cheng Hong > > Cc: nsis@ietf.org; 'Georgios Karagiannis' > > Betreff: RE: [NSIS] QoS NSLP open issue on error cases with=20 > > QSPEC stacking > >=20 > >=20 > > Hi all, > >=20 > > Some further ruminations. > >=20 > > Looking at this in a different way, and going back to the=20 > > fundamentals: is what is being sent a "stack of QSpecs", or a=20 > > "choice of QSpecs"? > >=20 > > I think we're talking about a "stack": > > The source QNE is requesting the resources in the top object.=20 > > So, actually processing a different object is wrong (we would=20 > > be reserving something different to what we were asked for).=20 > > Then, since it is the source QNE who asked for that QSpec=20 > > (and sent it with the expectation of it being honoured), the=20 > > responsiblity for fixing the problem should be pushed back to it. > >=20 > > It is an error case anyway, so correctness should be the=20 > > goal, rather than making it fast/seamless. It is desirable to=20 > > limit the error propagation - if you know you have got bad=20 > > data (a QSpec for an unsupported qos model), you should limit=20 > > how far this gets propagated. Either 'fixing' the set of=20 > > QSpecs at the receiving QNE, or forwarding them unchanged=20 > > would result in the error affecting the resources requested=20 > > at subsequent nodes. > >=20 > > If you were to go with the "choice" view, then the source QNE=20 > > would be asking for any one of the QSpecs in the set to be=20 > > processed. However, you still need to handle the case where=20 > > none of the QSpecs can be understood. Allowing the receiving=20 > > QNE to choose also means that the RESERVE does not have a=20 > > deterministic result from the sending QNEs point of view - it=20 > > doesn't know which QSpec will be used. > >=20 > > My conclusion would be that the receiving node should not=20 > > attempt any recovery (looking deeper into the set of QSpecs=20 > > and maybe subsequently stripping off QSpecs). Instead it=20 > > should just send an error back and leave the responsibility=20 > > for recovering to the sending QNE. > >=20 > > How does that argument sound? > >=20 > >=20 > > Andrew > >=20 > > McDonald, Andrew wrote: > > > I suppose, in a way we are asking: 'how are people going to=20 > > get their > > > network configuration wrong?', which is rather a difficult one to > > > answer. =20 > > >=20 > > > If the problem is that 'edge' nodes don't undo QSpec=20 > stacking, then > > > you might want the node receiving the unknown QSpec to become the > > > edge (look deeper, and strip). You probably also want to send back > > > error messages, asking the previous node to become the edge (don't > > > send me a QSpec for that qos model again). =20 > > >=20 > > > If problem is 'non-edge' nodes that don't understand QoS=20 > models they > > > should, then you want things to carry on as if that node=20 > > wasn't there > > > (possibly look deeper, but don't strip). In this case,=20 > > sending errors > > > back might also be the wrong answer (if it tells previous=20 > nodes not > > > to send something they should be sending). =20 > >=20 > >=20 > > --=20 > > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > > Oldbury, Bracknell, > > Berkshire. RG12 8FZ > >=20 > > The information contained in this e-mail and any attachments=20 > > is confidential to > > Roke Manor Research Ltd and must not be passed to any third=20 > > party without > > permission. This communication is for information only and=20 > > shall not create or > > change any contractual relationship. > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 08:12:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10142 for ; Thu, 26 Feb 2004 08:12:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLJ3-0000pq-7Z for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 08:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QDC1dN003194 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 08:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLJ2-0000pI-L2; Thu, 26 Feb 2004 08:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLIZ-0000of-MR for nsis@optimus.ietf.org; Thu, 26 Feb 2004 08:11:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10122 for ; Thu, 26 Feb 2004 08:11:29 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLIY-0005Kh-00 for nsis@ietf.org; Thu, 26 Feb 2004 08:11:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLHg-0005F8-00 for nsis@ietf.org; Thu, 26 Feb 2004 08:10:37 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AwLGx-00058y-00 for nsis@ietf.org; Thu, 26 Feb 2004 08:09:51 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1QD9grX018927; Thu, 26 Feb 2004 14:09:43 +0100 Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking To: "Hancock, Robert" Cc: "'Kappler Cornelia'" , "McDonald, Andrew" , Cheng Hong , nsis@ietf.org, "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 26 Feb 2004 14:09:39 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/26/2004 14:09:43 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Robert, Andrew, all, I am starting to feel a lot for Andrew's proposed solution. However, I = am wondering if the correct answer might depend on the mode used by GIMPS,= i.e. - connection mode: reasonable to assume you know which models are suppo= rted by your peer - datagram: not so reasonable to make this assumption I would say that in connection mode, you just send an error message bac= k and let the sender solve the problem (i.e. become the edge of the domai= n if necessary). The solution seems to be either resend in datagram mode (he= nce tunneling through the offending (Q)NE) or to terminate and look deeper.= In datagram mode, maybe you should just pass on the message as is and behave like an NE? Sven "Hancock, Robert" on 26/02/2004 10:56:25 To: "'Kappler Cornelia'" , "McDonald, Andrew" , Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Cheng Hong cc: nsis@ietf.org, "'Georgios Karagiannis'" = Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking cornelia, my mental model of operation is to consider that - nodes where reservations are installed understand the QoS models that they accept reservations for (this is obvious) - nodes which request reservations of other nodes must be able to request it in language that those 'other' (neighbour) nodes understand (not quite so obvious but reasonable IMHO) in that case, the bit in your scenario where it goes > So the RESERVE proceeds through a multitude of > domains. Now one domain somewhere does not recognize the QoS > model in the bottom QSpec. is a should-not-happen error condition (i.e. I think this is an assumption we should make): - the previous domain understood and installed the reservation in its own nodes - it knows it is connected to a neighbour domain - it knows (or should find out as a matter of urgency) if that neighbour doesn't support a QoS-model that it itself does (whether that is the only model on the stack or just the topmost one doesn't really matter) - in that case, it should be able to translate its own understanding of the requested QoS (it must have an understanding, since it installed the reservation...) into language that the neighbour does understand. some details: i assumed that re-writing was allowed only in so far as the qos model specified it (qos models might allow re-writing of some fields but not others, for example). I assumed that arbitrary re-writing is not possible (unless you terminate the signalling session at a node and start a new one) - that is what the stacking is for, to make such things unnecessary. on the gracefull fallback case: this is worth thinking about. conceptually it is not much different from passing through an NSIS-unaware node (and we certainly have to be capable of that!) cheers, robert h. > -----Original Message----- > From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > Sent: Thursday, February 26, 2004 09:37 > To: McDonald, Andrew; Kappler Cornelia; > 'sven.van_den_bosch@alcatel.be'; > Cheng Hong > Cc: nsis@ietf.org; 'Georgios Karagiannis' > Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC > stacking > > > Hi Andrew, > > I also agree putting too much "intelligence" into QNEs (i.e. > assumptions on what went wrong and hence how it is to be > fixed) may result in hard-to-understand system behaviour and > backfire (i.e. not speed up processing). > > On the other hand, imagine a QNI trying to set up a > reservation with an unknown QNR many domains away (e.g. > reserving IP telephony resources between Europe and the > Solomon Islands). Of course the QNI doesnt know what QoS > model the QNR understands. So it will pick a "well known" QoS > model for the first QSpec, and then may be stack a local QoS > model on top. At the border of QNIs domain, the local QSpec > will be popped, and possibly, depending on SLAs between > domains, the bottom QSpec will be rewritten (is this allowed > by qos-nslp?). So the RESERVE proceeds through a multitude of > domains. Now one domain somewhere does not recognize the QoS > model in the bottom QSpec. Do we really want to stop the > RESERVE until this domain and the originating domain came up > with a solution? May be a "graceful fallback" would be to > send an error message, and continue to forward the RESERVE > and put up with one domain on the path not reserving > resources. This is similar to how RSVP works I believe. > > This raises the question of whether we should have a "default > QoS model" that must be understood by everybody (a can of > worms, I know, so probably not)? > > How would the "graceful fallback" be realized? Popping a > QSpec when there is no other left is no good (another reason > why the original idea needs amendment). So may be the QNE who > does not understand the topmost QSpec tags it. The next QNE > would again try and interpret the topmost object. If it > succeeds, apparently (assumption!) the QNE before was > _within_ the QoS model domain but malconfigured. The RESERVE > proceeds with the tag which tells the QNE popping the topmost > QSpec one (or at least one - depending on how many bits we > spend on this) QNE was unable to reserve resources. May be > because we already sent the error message, the tag is > redundant and not necessary. Of course this procedure doesnt > help in the case of a QNE not popping a QSpec it was supposed > to pop. In this case we produce processing overhead because > all QNEs up to the QNR try to interpret a QSpec they are > unable to interprete, and the reservation fails anyways. > > Thinking aloud (and hoping such issues have not yet been > discussed at length on this list...), Cornelia > > > > -----Urspr=FCngliche Nachricht----- > > Von: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > > Gesendet: Mittwoch, 25. Februar 2004 18:15 > > An: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be'; Cheng Hong= > > Cc: nsis@ietf.org; 'Georgios Karagiannis' > > Betreff: RE: [NSIS] QoS NSLP open issue on error cases with > > QSPEC stacking > > > > > > Hi all, > > > > Some further ruminations. > > > > Looking at this in a different way, and going back to the > > fundamentals: is what is being sent a "stack of QSpecs", or a > > "choice of QSpecs"? > > > > I think we're talking about a "stack": > > The source QNE is requesting the resources in the top object. > > So, actually processing a different object is wrong (we would > > be reserving something different to what we were asked for). > > Then, since it is the source QNE who asked for that QSpec > > (and sent it with the expectation of it being honoured), the > > responsiblity for fixing the problem should be pushed back to it. > > > > It is an error case anyway, so correctness should be the > > goal, rather than making it fast/seamless. It is desirable to > > limit the error propagation - if you know you have got bad > > data (a QSpec for an unsupported qos model), you should limit > > how far this gets propagated. Either 'fixing' the set of > > QSpecs at the receiving QNE, or forwarding them unchanged > > would result in the error affecting the resources requested > > at subsequent nodes. > > > > If you were to go with the "choice" view, then the source QNE > > would be asking for any one of the QSpecs in the set to be > > processed. However, you still need to handle the case where > > none of the QSpecs can be understood. Allowing the receiving > > QNE to choose also means that the RESERVE does not have a > > deterministic result from the sending QNEs point of view - it > > doesn't know which QSpec will be used. > > > > My conclusion would be that the receiving node should not > > attempt any recovery (looking deeper into the set of QSpecs > > and maybe subsequently stripping off QSpecs). Instead it > > should just send an error back and leave the responsibility > > for recovering to the sending QNE. > > > > How does that argument sound? > > > > > > Andrew > > > > McDonald, Andrew wrote: > > > I suppose, in a way we are asking: 'how are people going to > > get their > > > network configuration wrong?', which is rather a difficult one to= > > > answer. > > > > > > If the problem is that 'edge' nodes don't undo QSpec > stacking, then > > > you might want the node receiving the unknown QSpec to become the= > > > edge (look deeper, and strip). You probably also want to send bac= k > > > error messages, asking the previous node to become the edge (don'= t > > > send me a QSpec for that qos model again). > > > > > > If problem is 'non-edge' nodes that don't understand QoS > models they > > > should, then you want things to carry on as if that node > > wasn't there > > > (possibly look deeper, but don't strip). In this case, > > sending errors > > > back might also be the wrong answer (if it tells previous > nodes not > > > to send something they should be sending). > > > > > > -- > > Registered Office: Roke Manor Research Ltd, Siemens House, > > Oldbury, Bracknell, > > Berkshire. RG12 8FZ > > > > The information contained in this e-mail and any attachments > > is confidential to > > Roke Manor Research Ltd and must not be passed to any third > > party without > > permission. This communication is for information only and > > shall not create or > > change any contractual relationship. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party witho= ut permission. This communication is for information only and shall not cr= eate or change any contractual relationship. = _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 08:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11718 for ; Thu, 26 Feb 2004 08:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeL-0003qz-H4 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 08:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QDY1pm014802 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 08:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeL-0003qe-8U; Thu, 26 Feb 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeJ-0003qG-L2 for nsis@optimus.ietf.org; Thu, 26 Feb 2004 08:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11507 for ; Thu, 26 Feb 2004 08:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLeI-0000ny-00 for nsis@ietf.org; Thu, 26 Feb 2004 08:33:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLc1-0000JS-00 for nsis@ietf.org; Thu, 26 Feb 2004 08:31:39 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AwLb8-0000Du-00 for nsis@ietf.org; Thu, 26 Feb 2004 08:30:42 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i1QDUTCi017184; Thu, 26 Feb 2004 14:30:29 +0100 (MET) Message-ID: <009701c3fc6c$b450fd60$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , Cc: "'Kappler Cornelia'" , "McDonald, Andrew" , "Cheng Hong" , References: Subject: Re: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Thu, 26 Feb 2004 14:30:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id i1QDUTCi017184 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Sven, Andrew, Robert I also agree with the conclusion derived by Andrew. The sending node has= to be informed about the error. Since the sending node has the required information on making such a decission, and other nodes may not, let the responsibili= ty for recovering to the sending node. Note, however that there are different ways on how the sending node can b= e informed about this error. These ways could depend on the used NTLP mode. Best Regards, Georgios ----- Original Message -----=20 From: To: "Hancock, Robert" Cc: "'Kappler Cornelia'" ; "McDonald, Andre= w" ; "Cheng Hong" ; ; "'Georgios Karagiannis'" Sent: Thursday, February 26, 2004 2:09 PM Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stackin= g > Hi Robert, Andrew, all, > > I am starting to feel a lot for Andrew's proposed solution. However, I = am > wondering if the correct answer might depend on the mode used by GIMPS, > i.e. > - connection mode: reasonable to assume you know which models are supported > by your peer > - datagram: not so reasonable to make this assumption > > I would say that in connection mode, you just send an error message bac= k > and let the sender solve the problem (i.e. become the edge of the domai= n if > necessary). The solution seems to be either resend in datagram mode (he= nce > tunneling through the offending (Q)NE) or to terminate and look deeper. > > In datagram mode, maybe you should just pass on the message as is and > behave like an NE? > > Sven > > > > > > > "Hancock, Robert" on 26/02/2004 10:56:25 > > To: "'Kappler Cornelia'" , "McDonald, > Andrew" , Sven VAN DEN > BOSCH/BE/ALCATEL@ALCATEL, Cheng Hong > cc: nsis@ietf.org, "'Georgios Karagiannis'" > Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC > stacking > > > cornelia, > > my mental model of operation is to consider that > - nodes where reservations are installed understand the > QoS models that they accept reservations for (this is > obvious) > - nodes which request reservations of other nodes must > be able to request it in language that those 'other' > (neighbour) nodes understand (not quite so obvious > but reasonable IMHO) > > in that case, the bit in your scenario where it goes > > > So the RESERVE proceeds through a multitude of > > domains. Now one domain somewhere does not recognize the QoS > > model in the bottom QSpec. > > is a should-not-happen error condition (i.e. I think this > is an assumption we should make): > - the previous domain understood and installed the > reservation in its own nodes > - it knows it is connected to a neighbour domain > - it knows (or should find out as a matter of urgency) if > that neighbour doesn't support a QoS-model that it itself > does (whether that is the only model on the stack or just > the topmost one doesn't really matter) > - in that case, it should be able to translate its own > understanding of the requested QoS (it must have an > understanding, since it installed the reservation...) > into language that the neighbour does understand. > > some details: i assumed that re-writing was allowed only > in so far as the qos model specified it (qos models might > allow re-writing of some fields but not others, for example). > I assumed that arbitrary re-writing is not possible (unless > you terminate the signalling session at a node and start > a new one) - that is what the stacking is for, to make > such things unnecessary. > > on the gracefull fallback case: this is worth thinking about. > conceptually it is not much different from passing through > an NSIS-unaware node (and we certainly have to be capable of > that!) > > cheers, > > robert h. > > > -----Original Message----- > > From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > > Sent: Thursday, February 26, 2004 09:37 > > To: McDonald, Andrew; Kappler Cornelia; > > 'sven.van_den_bosch@alcatel.be'; > > Cheng Hong > > Cc: nsis@ietf.org; 'Georgios Karagiannis' > > Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC > > stacking > > > > > > Hi Andrew, > > > > I also agree putting too much "intelligence" into QNEs (i.e. > > assumptions on what went wrong and hence how it is to be > > fixed) may result in hard-to-understand system behaviour and > > backfire (i.e. not speed up processing). > > > > On the other hand, imagine a QNI trying to set up a > > reservation with an unknown QNR many domains away (e.g. > > reserving IP telephony resources between Europe and the > > Solomon Islands). Of course the QNI doesnt know what QoS > > model the QNR understands. So it will pick a "well known" QoS > > model for the first QSpec, and then may be stack a local QoS > > model on top. At the border of QNIs domain, the local QSpec > > will be popped, and possibly, depending on SLAs between > > domains, the bottom QSpec will be rewritten (is this allowed > > by qos-nslp?). So the RESERVE proceeds through a multitude of > > domains. Now one domain somewhere does not recognize the QoS > > model in the bottom QSpec. Do we really want to stop the > > RESERVE until this domain and the originating domain came up > > with a solution? May be a "graceful fallback" would be to > > send an error message, and continue to forward the RESERVE > > and put up with one domain on the path not reserving > > resources. This is similar to how RSVP works I believe. > > > > This raises the question of whether we should have a "default > > QoS model" that must be understood by everybody (a can of > > worms, I know, so probably not)? > > > > How would the "graceful fallback" be realized? Popping a > > QSpec when there is no other left is no good (another reason > > why the original idea needs amendment). So may be the QNE who > > does not understand the topmost QSpec tags it. The next QNE > > would again try and interpret the topmost object. If it > > succeeds, apparently (assumption!) the QNE before was > > _within_ the QoS model domain but malconfigured. The RESERVE > > proceeds with the tag which tells the QNE popping the topmost > > QSpec one (or at least one - depending on how many bits we > > spend on this) QNE was unable to reserve resources. May be > > because we already sent the error message, the tag is > > redundant and not necessary. Of course this procedure doesnt > > help in the case of a QNE not popping a QSpec it was supposed > > to pop. In this case we produce processing overhead because > > all QNEs up to the QNR try to interpret a QSpec they are > > unable to interprete, and the reservation fails anyways. > > > > Thinking aloud (and hoping such issues have not yet been > > discussed at length on this list...), Cornelia > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > > > Gesendet: Mittwoch, 25. Februar 2004 18:15 > > > An: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be'; Cheng Hong > > > Cc: nsis@ietf.org; 'Georgios Karagiannis' > > > Betreff: RE: [NSIS] QoS NSLP open issue on error cases with > > > QSPEC stacking > > > > > > > > > Hi all, > > > > > > Some further ruminations. > > > > > > Looking at this in a different way, and going back to the > > > fundamentals: is what is being sent a "stack of QSpecs", or a > > > "choice of QSpecs"? > > > > > > I think we're talking about a "stack": > > > The source QNE is requesting the resources in the top object. > > > So, actually processing a different object is wrong (we would > > > be reserving something different to what we were asked for). > > > Then, since it is the source QNE who asked for that QSpec > > > (and sent it with the expectation of it being honoured), the > > > responsiblity for fixing the problem should be pushed back to it. > > > > > > It is an error case anyway, so correctness should be the > > > goal, rather than making it fast/seamless. It is desirable to > > > limit the error propagation - if you know you have got bad > > > data (a QSpec for an unsupported qos model), you should limit > > > how far this gets propagated. Either 'fixing' the set of > > > QSpecs at the receiving QNE, or forwarding them unchanged > > > would result in the error affecting the resources requested > > > at subsequent nodes. > > > > > > If you were to go with the "choice" view, then the source QNE > > > would be asking for any one of the QSpecs in the set to be > > > processed. However, you still need to handle the case where > > > none of the QSpecs can be understood. Allowing the receiving > > > QNE to choose also means that the RESERVE does not have a > > > deterministic result from the sending QNEs point of view - it > > > doesn't know which QSpec will be used. > > > > > > My conclusion would be that the receiving node should not > > > attempt any recovery (looking deeper into the set of QSpecs > > > and maybe subsequently stripping off QSpecs). Instead it > > > should just send an error back and leave the responsibility > > > for recovering to the sending QNE. > > > > > > How does that argument sound? > > > > > > > > > Andrew > > > > > > McDonald, Andrew wrote: > > > > I suppose, in a way we are asking: 'how are people going to > > > get their > > > > network configuration wrong?', which is rather a difficult one to > > > > answer. > > > > > > > > If the problem is that 'edge' nodes don't undo QSpec > > stacking, then > > > > you might want the node receiving the unknown QSpec to become the > > > > edge (look deeper, and strip). You probably also want to send bac= k > > > > error messages, asking the previous node to become the edge (don'= t > > > > send me a QSpec for that qos model again). > > > > > > > > If problem is 'non-edge' nodes that don't understand QoS > > models they > > > > should, then you want things to carry on as if that node > > > wasn't there > > > > (possibly look deeper, but don't strip). In this case, > > > sending errors > > > > back might also be the wrong answer (if it tells previous > > nodes not > > > > to send something they should be sending). > > > > > > > > > -- > > > Registered Office: Roke Manor Research Ltd, Siemens House, > > > Oldbury, Bracknell, > > > Berkshire. RG12 8FZ > > > > > > The information contained in this e-mail and any attachments > > > is confidential to > > > Roke Manor Research Ltd and must not be passed to any third > > > party without > > > permission. This communication is for information only and > > > shall not create or > > > change any contractual relationship. > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party witho= ut > permission. This communication is for information only and shall not create > or > change any contractual relationship. > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 09:19:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14322 for ; Thu, 26 Feb 2004 09:19:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMM5-0007ph-QH for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:19:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEJDE6030100 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:19:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMLt-0007iR-A0; Thu, 26 Feb 2004 09:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMLU-0007ht-FM for nsis@optimus.ietf.org; Thu, 26 Feb 2004 09:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14297 for ; Thu, 26 Feb 2004 09:18:33 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMLS-0005nE-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMKY-0005jA-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:17:39 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AwMJt-0005fD-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:16:57 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1QEG8rb007348; Thu, 26 Feb 2004 15:16:54 +0100 To: nsis@ietf.org Cc: "McDonald, Andrew" , "Georgios Karagiannis" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 26 Feb 2004 15:16:51 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/26/2004 15:16:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] QoS NSLP open issue on region scoping 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 all, While the discussion on the QSPEC stacking error cases finalizes, I would like to focus attention on the second open issue, related to region scoping. The QoS NSLP specification (-02) allows QNEs to scope their messages, i.e. to restrict the extent to which messages may travel along and be interpreted on the path. Note that this is somewhat related to the QSPEC stacking discussion since the set of QNEs that support a certain QSPEC/QoS model can be regarded as a region. Messages can be scoped to a region implicitly (e.g. because the last QNE of a domain is configured to terminate the session) or via the SCOPING object. We are looking for input to determine to what extent the concept of a scope should generalized. At this point we have three types of scope defined: - whole path (default) - single hop (useful to e.g. QUERY a peer QNE) - back to me (RII): used to scope a response so that it does not travel beyond the requesting node. The question is: should the QoS NSLP specification define and support a more generic notion of region (e.g. to implement region policies independent from aggregation regions,...)? Looking forward to your views. Best regards, Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 09:29:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15316 for ; Thu, 26 Feb 2004 09:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMVa-0000Xi-Cp for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QET2D6002063 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMVZ-0000Wn-IJ; Thu, 26 Feb 2004 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMUg-0000V5-HY for nsis@optimus.ietf.org; Thu, 26 Feb 2004 09:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15210 for ; Thu, 26 Feb 2004 09:28:03 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMUe-0007Ck-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:28:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMTc-00074x-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:27:01 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AwMSr-0006y8-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:26:13 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1QEQ6rX021271; Thu, 26 Feb 2004 15:26:06 +0100 To: nsis@ietf.org Cc: "McDonald, Andrew" , "Georgios Karagiannis" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 26 Feb 2004 15:26:04 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/26/2004 15:26:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [NSIS] QoS NSLP open issue on priority 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 all, The current version of the QoS NSLP specification discusses priority in two ways: - priority of the signalling message transport (requirement on GIMPS) - priority of the reservation (related to preemption) In the TE-WG, the concepts of setup priority and holding priority were used to implement similar behaviour for DiffServ TE. Clearly, any given QoS model can include support for setup and/or holding priority. The question is whether people feel this functionality to be generally apllicable (enough) to different QoS models to warrant inclusion of it in the QoS NSLP spec. Looking forward to your views, Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 09:29:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15319 for ; Thu, 26 Feb 2004 09:29:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMVa-0000YP-Mt for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QET2u1002089 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMVa-0000XL-8G; Thu, 26 Feb 2004 09:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMVQ-0000WM-GW for nsis@optimus.ietf.org; Thu, 26 Feb 2004 09:28:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15276 for ; Thu, 26 Feb 2004 09:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMVO-0007JE-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:28:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMUb-0007CC-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:28:01 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AwMTX-00074I-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:26:55 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i1QEQq413615; Thu, 26 Feb 2004 15:26:52 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i1QEQpT08580; Thu, 26 Feb 2004 15:26:51 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 15:26:12 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685E16@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Cc: "McDonald, Andrew" , Georgios Karagiannis Subject: RE: [NSIS] QoS NSLP open issue on region scoping Date: Thu, 26 Feb 2004 15:26:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 sven, thanks for raising this issue. in the nat/firewall case found it interesting to think about a "local network" only scoping. this might be useful in some deployment environments where end-to-end nat/firewall signaling is not an option. the receiver behind the nat scenario is another case. this issue was also raised by cedric's drafts. ciao hannes > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Thursday, February 26, 2004 3:17 PM > To: nsis@ietf.org > Cc: McDonald, Andrew; Georgios Karagiannis > Subject: [NSIS] QoS NSLP open issue on region scoping > > > Hi all, > > While the discussion on the QSPEC stacking error cases > finalizes, I would > like to focus attention on the second open issue, related to region > scoping. The QoS NSLP specification (-02) allows QNEs to scope their > messages, i.e. to restrict the extent to which messages may > travel along > and be interpreted on the path. > Note that this is somewhat related to the QSPEC stacking > discussion since > the set of QNEs that support a certain QSPEC/QoS model can be > regarded as a > region. Messages can be scoped to a region implicitly (e.g. > because the > last QNE of a domain is configured to terminate the session) > or via the > SCOPING object. > We are looking for input to determine to what extent the > concept of a scope > should generalized. At this point we have three types of > scope defined: > - whole path (default) > - single hop (useful to e.g. QUERY a peer QNE) > - back to me (RII): used to scope a response so that it does > not travel > beyond the requesting node. > > The question is: should the QoS NSLP specification define > and support a > more generic notion of region (e.g. to implement region policies > independent from aggregation regions,...)? > > Looking forward to your views. > > Best regards, > Sven > > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Feb 26 09:34:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15527 for ; Thu, 26 Feb 2004 09:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMaQ-0000ug-Cn for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEY2AE003504 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMaQ-0000uP-4k; Thu, 26 Feb 2004 09:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMa0-0000s7-BI for nsis@optimus.ietf.org; Thu, 26 Feb 2004 09:33:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15516 for ; Thu, 26 Feb 2004 09:33:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMZy-0007kb-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:33:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMZ5-0007gm-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:32:41 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AwMYq-0007cI-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:32:25 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1Q5W>; Thu, 26 Feb 2004 14:31:53 -0000 Message-ID: From: "McDonald, Andrew" To: "'Georgios Karagiannis'" , "Hancock, Robert" , sven.van_den_bosch@alcatel.be Cc: "'Kappler Cornelia'" , Cheng Hong , nsis@ietf.org Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Thu, 26 Feb 2004 14:32:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA15518 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: quoted-printable Hi all, From an NSLP perspective, I think that the important thing here is not wh= ether the NTLP is using datagram or connection mode, but rather whether r= everse routing state exists or not. If you haven't got reverse routing state then you can drop the message or= forward it (as if you weren't an NSIS node at all). There is also enough= information at the GIMPS level (from the IP header of the datagram mode = message) to get something back one GIMPS hop. Andrew Georgios Karagiannis wrote: > Hi Sven, Andrew, Robert >=20 > I also agree with the conclusion derived by Andrew. The sending node > has to be > informed about the error. Since the sending node has the required > information > on making such a decission, and other nodes may not, let the > responsibility for recovering to the sending node. >=20 > Note, however that there are different ways on how the sending node > can be informed > about this error. These ways could depend on the used NTLP mode. >=20 > Best Regards, > Georgios >=20 > ----- Original Message ----- > From: > To: "Hancock, Robert" > Cc: "'Kappler Cornelia'" ; "McDonald, > Andrew" ; "Cheng Hong" > ; ; "'Georgios Karagiannis'" > =20 > Sent: Thursday, February 26, 2004 2:09 PM > Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC > stacking=20 >=20 >=20 >> Hi Robert, Andrew, all, >>=20 >> I am starting to feel a lot for Andrew's proposed solution. However, >> I am wondering if the correct answer might depend on the mode used >> by GIMPS, i.e.=20 >> - connection mode: reasonable to assume you know which models are >> supported by your peer=20 >> - datagram: not so reasonable to make this assumption >>=20 >> I would say that in connection mode, you just send an error message >> back and let the sender solve the problem (i.e. become the edge of >> the domain if necessary). The solution seems to be either resend in >> datagram mode (hence tunneling through the offending (Q)NE) or to >> terminate and look deeper.=20 >>=20 >> In datagram mode, maybe you should just pass on the message as is >> and behave like an NE?=20 >>=20 >> Sven >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> "Hancock, Robert" on 26/02/2004 10:56:25 >>=20 >> To: "'Kappler Cornelia'" , >> "McDonald, Andrew" , Sven VAN DEN >> BOSCH/BE/ALCATEL@ALCATEL, Cheng Hong >> cc: nsis@ietf.org, "'Georgios Karagiannis'" >> Subject: RE: [NSIS] QoS NSLP open issue >> on error cases with QSPEC stacking=20 >>=20 >>=20 >> cornelia, >>=20 >> my mental model of operation is to consider that >> - nodes where reservations are installed understand the >> QoS models that they accept reservations for (this is obvious) >> - nodes which request reservations of other nodes must >> be able to request it in language that those 'other' >> (neighbour) nodes understand (not quite so obvious but >> reasonable IMHO)=20 >>=20 >> in that case, the bit in your scenario where it goes >>=20 >>> So the RESERVE proceeds through a multitude of >>> domains. Now one domain somewhere does not recognize the QoS >>> model in the bottom QSpec. >>=20 >> is a should-not-happen error condition (i.e. I think this >> is an assumption we should make): >> - the previous domain understood and installed the >> reservation in its own nodes >> - it knows it is connected to a neighbour domain >> - it knows (or should find out as a matter of urgency) if >> that neighbour doesn't support a QoS-model that it itself >> does (whether that is the only model on the stack or just >> the topmost one doesn't really matter) >> - in that case, it should be able to translate its own >> understanding of the requested QoS (it must have an >> understanding, since it installed the reservation...) >> into language that the neighbour does understand. >>=20 >> some details: i assumed that re-writing was allowed only >> in so far as the qos model specified it (qos models might >> allow re-writing of some fields but not others, for example). >> I assumed that arbitrary re-writing is not possible (unless >> you terminate the signalling session at a node and start >> a new one) - that is what the stacking is for, to make >> such things unnecessary. >>=20 >> on the gracefull fallback case: this is worth thinking about. >> conceptually it is not much different from passing through >> an NSIS-unaware node (and we certainly have to be capable of >> that!) >>=20 >> cheers, >>=20 >> robert h. >>=20 >>> -----Original Message----- >>> From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] >>> Sent: Thursday, February 26, 2004 09:37 >>> To: McDonald, Andrew; Kappler Cornelia; >>> 'sven.van_den_bosch@alcatel.be'; >>> Cheng Hong >>> Cc: nsis@ietf.org; 'Georgios Karagiannis' >>> Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC >>> stacking=20 >>>=20 >>>=20 >>> Hi Andrew, >>>=20 >>> I also agree putting too much "intelligence" into QNEs (i.e. >>> assumptions on what went wrong and hence how it is to be >>> fixed) may result in hard-to-understand system behaviour and >>> backfire (i.e. not speed up processing). >>>=20 >>> On the other hand, imagine a QNI trying to set up a >>> reservation with an unknown QNR many domains away (e.g. >>> reserving IP telephony resources between Europe and the >>> Solomon Islands). Of course the QNI doesnt know what QoS >>> model the QNR understands. So it will pick a "well known" QoS >>> model for the first QSpec, and then may be stack a local QoS >>> model on top. At the border of QNIs domain, the local QSpec >>> will be popped, and possibly, depending on SLAs between >>> domains, the bottom QSpec will be rewritten (is this allowed >>> by qos-nslp?). So the RESERVE proceeds through a multitude of >>> domains. Now one domain somewhere does not recognize the QoS >>> model in the bottom QSpec. Do we really want to stop the >>> RESERVE until this domain and the originating domain came up >>> with a solution? May be a "graceful fallback" would be to >>> send an error message, and continue to forward the RESERVE >>> and put up with one domain on the path not reserving >>> resources. This is similar to how RSVP works I believe. >>>=20 >>> This raises the question of whether we should have a "default >>> QoS model" that must be understood by everybody (a can of >>> worms, I know, so probably not)? >>>=20 >>> How would the "graceful fallback" be realized? Popping a >>> QSpec when there is no other left is no good (another reason >>> why the original idea needs amendment). So may be the QNE who >>> does not understand the topmost QSpec tags it. The next QNE >>> would again try and interpret the topmost object. If it >>> succeeds, apparently (assumption!) the QNE before was >>> _within_ the QoS model domain but malconfigured. The RESERVE >>> proceeds with the tag which tells the QNE popping the topmost >>> QSpec one (or at least one - depending on how many bits we >>> spend on this) QNE was unable to reserve resources. May be >>> because we already sent the error message, the tag is >>> redundant and not necessary. Of course this procedure doesnt >>> help in the case of a QNE not popping a QSpec it was supposed >>> to pop. In this case we produce processing overhead because >>> all QNEs up to the QNR try to interpret a QSpec they are >>> unable to interprete, and the reservation fails anyways. >>>=20 >>> Thinking aloud (and hoping such issues have not yet been >>> discussed at length on this list...), Cornelia >>>=20 >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] >>>> Gesendet: Mittwoch, 25. Februar 2004 18:15 >>>> An: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be'; Cheng Hong >>>> Cc: nsis@ietf.org; 'Georgios Karagiannis' >>>> Betreff: RE: [NSIS] QoS NSLP open issue on error cases with >>>> QSPEC stacking >>>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> Some further ruminations. >>>>=20 >>>> Looking at this in a different way, and going back to the >>>> fundamentals: is what is being sent a "stack of QSpecs", or a >>>> "choice of QSpecs"?=20 >>>>=20 >>>> I think we're talking about a "stack": >>>> The source QNE is requesting the resources in the top object. >>>> So, actually processing a different object is wrong (we would >>>> be reserving something different to what we were asked for). >>>> Then, since it is the source QNE who asked for that QSpec >>>> (and sent it with the expectation of it being honoured), the >>>> responsiblity for fixing the problem should be pushed back to it. >>>>=20 >>>> It is an error case anyway, so correctness should be the >>>> goal, rather than making it fast/seamless. It is desirable to >>>> limit the error propagation - if you know you have got bad >>>> data (a QSpec for an unsupported qos model), you should limit >>>> how far this gets propagated. Either 'fixing' the set of >>>> QSpecs at the receiving QNE, or forwarding them unchanged >>>> would result in the error affecting the resources requested >>>> at subsequent nodes. >>>>=20 >>>> If you were to go with the "choice" view, then the source QNE >>>> would be asking for any one of the QSpecs in the set to be >>>> processed. However, you still need to handle the case where >>>> none of the QSpecs can be understood. Allowing the receiving >>>> QNE to choose also means that the RESERVE does not have a >>>> deterministic result from the sending QNEs point of view - it >>>> doesn't know which QSpec will be used. >>>>=20 >>>> My conclusion would be that the receiving node should not >>>> attempt any recovery (looking deeper into the set of QSpecs >>>> and maybe subsequently stripping off QSpecs). Instead it >>>> should just send an error back and leave the responsibility >>>> for recovering to the sending QNE. >>>>=20 >>>> How does that argument sound? >>>>=20 >>>>=20 >>>> Andrew >>>>=20 >>>> McDonald, Andrew wrote: >>>>> I suppose, in a way we are asking: 'how are people going to get >>>>> their network configuration wrong?', which is rather a difficult >>>>> one to answer.=20 >>>>>=20 >>>>> If the problem is that 'edge' nodes don't undo QSpec stacking, >>>>> then you might want the node receiving the unknown QSpec to >>>>> become the edge (look deeper, and strip). You probably also want >>>>> to send back error messages, asking the previous node to become >>>>> the edge (don't send me a QSpec for that qos model again). >>>>>=20 >>>>> If problem is 'non-edge' nodes that don't understand QoS models >>>>> they should, then you want things to carry on as if that node >>>>> wasn't there (possibly look deeper, but don't strip). In this >>>>> case, sending errors back might also be the wrong answer (if it >>>>> tells previous nodes not to send something they should be >>>>> sending).=20 >>>>=20 >>>>=20 >>>> -- >>>> Registered Office: Roke Manor Research Ltd, Siemens House, >>>> Oldbury, Bracknell, Berkshire. RG12 8FZ >>>>=20 >>>> The information contained in this e-mail and any attachments >>>> is confidential to >>>> Roke Manor Research Ltd and must not be passed to any third >>>> party without >>>> permission. This communication is for information only and >>>> shall not create or >>>> change any contractual relationship. >>>>=20 >>>=20 >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>>=20 >>=20 >> -- >> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, >> Bracknell, Berkshire. RG12 8FZ >>=20 >> The information contained in this e-mail and any attachments is >> confidential to Roke Manor Research Ltd and must not be passed to >> any third party without permission. This communication is for >> information only and shall not create or change any contractual >> relationship.=20 --=20 Andrew McDonald, Senior Engineer Roke Manor Research Ltd, Romsey, Hants SO51 0ZN Phone +44 1794 833833 Fax +44 1794 833434 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 09:44:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16017 for ; Thu, 26 Feb 2004 09:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMk5-0002DR-DZ for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:44:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEi1j6008500 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMk5-0002D0-1T; Thu, 26 Feb 2004 09:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMjd-0002C2-De for nsis@optimus.ietf.org; Thu, 26 Feb 2004 09:43:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15991 for ; Thu, 26 Feb 2004 09:43:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMjb-0000ps-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:43:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMid-0000je-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:42:31 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AwMhf-0000ZU-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:41:32 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMKRSY>; Thu, 26 Feb 2004 14:41:00 -0000 Message-ID: From: "McDonald, Andrew" To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Cc: Georgios Karagiannis Date: Thu, 26 Feb 2004 14:41:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [NSIS] RE: QoS NSLP open issue on region scoping 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: , sven.van_den_bosch@alcatel.be wrote: > The question is: should the QoS NSLP specification define and > support a more generic notion of region (e.g. to implement region > policies independent from aggregation regions,...)? A few additional thoughts (not actually attempting to answer the question yet!): One example might be where the node at the ingress to an administrative domain wants to query the available resources in the 'local' network as part of its local admission control decision. If it is useful/needed, how should it be done? One possibility is for a marker that indicates that the message should not be forwarded outside the local domain, and so is terminated by edge nodes. However, it can also be argued that this is too fragile, and that there isn't a safe way to do such scoping. (The trivial case of 'whole path' vs 'next node' doesn't have this problem. If you get a message with 'next node only' set then you know you shouldn't send it any further.) Should the NSLP do this itself? Or should the NTLP provide some generic functionality to do this? Regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 09:46:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16153 for ; Thu, 26 Feb 2004 09:46:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMm2-0002Mu-52 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEk2gZ009069 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 09:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMm1-0002MA-Or; Thu, 26 Feb 2004 09:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMld-0002L7-NK for nsis@optimus.ietf.org; Thu, 26 Feb 2004 09:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16109 for ; Thu, 26 Feb 2004 09:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMlb-00013x-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:45:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMkl-0000xs-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:44:44 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AwMju-0000mg-00 for nsis@ietf.org; Thu, 26 Feb 2004 09:43:50 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1Q6G>; Thu, 26 Feb 2004 14:43:19 -0000 Message-ID: From: "Hancock, Robert" To: "McDonald, Andrew" , "'Georgios Karagiannis'" , "'sven.van_den_bosch@alcatel.be'" Cc: "'Kappler Cornelia'" , "'Cheng Hong'" , "'nsis@ietf.org'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Thu, 26 Feb 2004 14:43:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA16110 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: quoted-printable hi, > From an NSLP perspective, I think that the important thing=20 > here is not whether the NTLP is using datagram or connection=20 > mode, but rather whether reverse routing state exists or not. precisely. indeed, a future NTLP spec might not have a connection mode at all, or it might divide datagram and connection mode differently, or it might call them something else. (in fact, the NSLP drafts should not refer to datagram/connection mode distinctions since this is a GIMPS design feature which is=20 explicitly intended not to be visible externally except in terms of the performance attributes of the message transfer.) whether to store reverse routing state is one of those=20 attributes, and ... >=20 > If you haven't got reverse routing state then you can drop=20 > the message or forward it (as if you weren't an NSIS node at=20 > all). There is also enough information at the GIMPS level=20 > (from the IP header of the datagram mode message) to get=20 > something back one GIMPS hop. [just to reassure you: if a message arrived in C-mode you=20 can always send back a message along the same association; D-mode messages always include the Node-Addressing of the=20 peer that sent it, so you can respond direct to that.] This is incidentally another reason for responding with an error as soon as possible, rather than trying to propagate the message any further. If you have a region of stateless nodes but only decide the error is fatal at the egress edge, you have (maybe) no way to get back to the ingress edge. If you decide it is fatal as soon as possible, there is a stronger likelihood of getting back to a node which knows enough about what is going on to be able to fix it. (If you have a region of stateless nodes where they don't all understand the same QoS model, you are in real desparate trouble, but it's probably the sort of trouble which has to be handled via network management anyway.) r. >=20 > Andrew >=20 > Georgios Karagiannis wrote: > > Hi Sven, Andrew, Robert > >=20 > > I also agree with the conclusion derived by Andrew. The=20 > sending node > > has to be > > informed about the error. Since the sending node has the required > > information > > on making such a decission, and other nodes may not, let the > > responsibility for recovering to the sending node. > >=20 > > Note, however that there are different ways on how the sending node > > can be informed > > about this error. These ways could depend on the used NTLP mode. > >=20 > > Best Regards, > > Georgios > >=20 > > ----- Original Message ----- > > From: > > To: "Hancock, Robert" > > Cc: "'Kappler Cornelia'" ; "McDonald, > > Andrew" ; "Cheng Hong" > > ; ; "'Georgios Karagiannis'" > > =20 > > Sent: Thursday, February 26, 2004 2:09 PM > > Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC > > stacking=20 > >=20 > >=20 > >> Hi Robert, Andrew, all, > >>=20 > >> I am starting to feel a lot for Andrew's proposed=20 > solution. However, > >> I am wondering if the correct answer might depend on the mode used > >> by GIMPS, i.e.=20 > >> - connection mode: reasonable to assume you know which models are > >> supported by your peer=20 > >> - datagram: not so reasonable to make this assumption > >>=20 > >> I would say that in connection mode, you just send an error message > >> back and let the sender solve the problem (i.e. become the edge of > >> the domain if necessary). The solution seems to be either resend in > >> datagram mode (hence tunneling through the offending (Q)NE) or to > >> terminate and look deeper.=20 > >>=20 > >> In datagram mode, maybe you should just pass on the message as is > >> and behave like an NE?=20 > >>=20 > >> Sven > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> "Hancock, Robert" on=20 > 26/02/2004 10:56:25 > >>=20 > >> To: "'Kappler Cornelia'" , > >> "McDonald, Andrew" ,=20 > Sven VAN DEN > >> BOSCH/BE/ALCATEL@ALCATEL, Cheng Hong > >> cc: nsis@ietf.org, "'Georgios Karagiannis'" > >> Subject: RE: [NSIS] QoS NSLP open issue > >> on error cases with QSPEC stacking=20 > >>=20 > >>=20 > >> cornelia, > >>=20 > >> my mental model of operation is to consider that > >> - nodes where reservations are installed understand the > >> QoS models that they accept reservations for (this is obvious) > >> - nodes which request reservations of other nodes must > >> be able to request it in language that those 'other' > >> (neighbour) nodes understand (not quite so obvious but > >> reasonable IMHO)=20 > >>=20 > >> in that case, the bit in your scenario where it goes > >>=20 > >>> So the RESERVE proceeds through a multitude of > >>> domains. Now one domain somewhere does not recognize the QoS > >>> model in the bottom QSpec. > >>=20 > >> is a should-not-happen error condition (i.e. I think this > >> is an assumption we should make): > >> - the previous domain understood and installed the > >> reservation in its own nodes > >> - it knows it is connected to a neighbour domain > >> - it knows (or should find out as a matter of urgency) if > >> that neighbour doesn't support a QoS-model that it itself > >> does (whether that is the only model on the stack or just > >> the topmost one doesn't really matter) > >> - in that case, it should be able to translate its own > >> understanding of the requested QoS (it must have an > >> understanding, since it installed the reservation...) > >> into language that the neighbour does understand. > >>=20 > >> some details: i assumed that re-writing was allowed only > >> in so far as the qos model specified it (qos models might > >> allow re-writing of some fields but not others, for example). > >> I assumed that arbitrary re-writing is not possible (unless > >> you terminate the signalling session at a node and start > >> a new one) - that is what the stacking is for, to make > >> such things unnecessary. > >>=20 > >> on the gracefull fallback case: this is worth thinking about. > >> conceptually it is not much different from passing through > >> an NSIS-unaware node (and we certainly have to be capable of > >> that!) > >>=20 > >> cheers, > >>=20 > >> robert h. > >>=20 > >>> -----Original Message----- > >>> From: Kappler Cornelia [mailto:cornelia.kappler@siemens.com] > >>> Sent: Thursday, February 26, 2004 09:37 > >>> To: McDonald, Andrew; Kappler Cornelia; > >>> 'sven.van_den_bosch@alcatel.be'; > >>> Cheng Hong > >>> Cc: nsis@ietf.org; 'Georgios Karagiannis' > >>> Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC > >>> stacking=20 > >>>=20 > >>>=20 > >>> Hi Andrew, > >>>=20 > >>> I also agree putting too much "intelligence" into QNEs (i.e. > >>> assumptions on what went wrong and hence how it is to be > >>> fixed) may result in hard-to-understand system behaviour and > >>> backfire (i.e. not speed up processing). > >>>=20 > >>> On the other hand, imagine a QNI trying to set up a > >>> reservation with an unknown QNR many domains away (e.g. > >>> reserving IP telephony resources between Europe and the > >>> Solomon Islands). Of course the QNI doesnt know what QoS > >>> model the QNR understands. So it will pick a "well known" QoS > >>> model for the first QSpec, and then may be stack a local QoS > >>> model on top. At the border of QNIs domain, the local QSpec > >>> will be popped, and possibly, depending on SLAs between > >>> domains, the bottom QSpec will be rewritten (is this allowed > >>> by qos-nslp?). So the RESERVE proceeds through a multitude of > >>> domains. Now one domain somewhere does not recognize the QoS > >>> model in the bottom QSpec. Do we really want to stop the > >>> RESERVE until this domain and the originating domain came up > >>> with a solution? May be a "graceful fallback" would be to > >>> send an error message, and continue to forward the RESERVE > >>> and put up with one domain on the path not reserving > >>> resources. This is similar to how RSVP works I believe. > >>>=20 > >>> This raises the question of whether we should have a "default > >>> QoS model" that must be understood by everybody (a can of > >>> worms, I know, so probably not)? > >>>=20 > >>> How would the "graceful fallback" be realized? Popping a > >>> QSpec when there is no other left is no good (another reason > >>> why the original idea needs amendment). So may be the QNE who > >>> does not understand the topmost QSpec tags it. The next QNE > >>> would again try and interpret the topmost object. If it > >>> succeeds, apparently (assumption!) the QNE before was > >>> _within_ the QoS model domain but malconfigured. The RESERVE > >>> proceeds with the tag which tells the QNE popping the topmost > >>> QSpec one (or at least one - depending on how many bits we > >>> spend on this) QNE was unable to reserve resources. May be > >>> because we already sent the error message, the tag is > >>> redundant and not necessary. Of course this procedure doesnt > >>> help in the case of a QNE not popping a QSpec it was supposed > >>> to pop. In this case we produce processing overhead because > >>> all QNEs up to the QNR try to interpret a QSpec they are > >>> unable to interprete, and the reservation fails anyways. > >>>=20 > >>> Thinking aloud (and hoping such issues have not yet been > >>> discussed at length on this list...), Cornelia > >>>=20 > >>>=20 > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > >>>> Gesendet: Mittwoch, 25. Februar 2004 18:15 > >>>> An: 'Kappler Cornelia'; 'sven.van_den_bosch@alcatel.be';=20 > Cheng Hong > >>>> Cc: nsis@ietf.org; 'Georgios Karagiannis' > >>>> Betreff: RE: [NSIS] QoS NSLP open issue on error cases with > >>>> QSPEC stacking > >>>>=20 > >>>>=20 > >>>> Hi all, > >>>>=20 > >>>> Some further ruminations. > >>>>=20 > >>>> Looking at this in a different way, and going back to the > >>>> fundamentals: is what is being sent a "stack of QSpecs", or a > >>>> "choice of QSpecs"?=20 > >>>>=20 > >>>> I think we're talking about a "stack": > >>>> The source QNE is requesting the resources in the top object. > >>>> So, actually processing a different object is wrong (we would > >>>> be reserving something different to what we were asked for). > >>>> Then, since it is the source QNE who asked for that QSpec > >>>> (and sent it with the expectation of it being honoured), the > >>>> responsiblity for fixing the problem should be pushed back to it. > >>>>=20 > >>>> It is an error case anyway, so correctness should be the > >>>> goal, rather than making it fast/seamless. It is desirable to > >>>> limit the error propagation - if you know you have got bad > >>>> data (a QSpec for an unsupported qos model), you should limit > >>>> how far this gets propagated. Either 'fixing' the set of > >>>> QSpecs at the receiving QNE, or forwarding them unchanged > >>>> would result in the error affecting the resources requested > >>>> at subsequent nodes. > >>>>=20 > >>>> If you were to go with the "choice" view, then the source QNE > >>>> would be asking for any one of the QSpecs in the set to be > >>>> processed. However, you still need to handle the case where > >>>> none of the QSpecs can be understood. Allowing the receiving > >>>> QNE to choose also means that the RESERVE does not have a > >>>> deterministic result from the sending QNEs point of view - it > >>>> doesn't know which QSpec will be used. > >>>>=20 > >>>> My conclusion would be that the receiving node should not > >>>> attempt any recovery (looking deeper into the set of QSpecs > >>>> and maybe subsequently stripping off QSpecs). Instead it > >>>> should just send an error back and leave the responsibility > >>>> for recovering to the sending QNE. > >>>>=20 > >>>> How does that argument sound? > >>>>=20 > >>>>=20 > >>>> Andrew > >>>>=20 > >>>> McDonald, Andrew wrote: > >>>>> I suppose, in a way we are asking: 'how are people going to get > >>>>> their network configuration wrong?', which is rather a difficult > >>>>> one to answer.=20 > >>>>>=20 > >>>>> If the problem is that 'edge' nodes don't undo QSpec stacking, > >>>>> then you might want the node receiving the unknown QSpec to > >>>>> become the edge (look deeper, and strip). You probably also want > >>>>> to send back error messages, asking the previous node to become > >>>>> the edge (don't send me a QSpec for that qos model again). > >>>>>=20 > >>>>> If problem is 'non-edge' nodes that don't understand QoS models > >>>>> they should, then you want things to carry on as if that node > >>>>> wasn't there (possibly look deeper, but don't strip). In this > >>>>> case, sending errors back might also be the wrong answer (if it > >>>>> tells previous nodes not to send something they should be > >>>>> sending).=20 > >>>>=20 > >>>>=20 > >>>> -- > >>>> Registered Office: Roke Manor Research Ltd, Siemens House, > >>>> Oldbury, Bracknell, Berkshire. RG12 8FZ > >>>>=20 > >>>> The information contained in this e-mail and any attachments > >>>> is confidential to > >>>> Roke Manor Research Ltd and must not be passed to any third > >>>> party without > >>>> permission. This communication is for information only and > >>>> shall not create or > >>>> change any contractual relationship. > >>>>=20 > >>>=20 > >>> _______________________________________________ > >>> nsis mailing list > >>> nsis@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/nsis > >>>=20 > >>=20 > >> -- > >> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > >> Bracknell, Berkshire. RG12 8FZ > >>=20 > >> The information contained in this e-mail and any attachments is > >> confidential to Roke Manor Research Ltd and must not be passed to > >> any third party without permission. This communication is for > >> information only and shall not create or change any contractual > >> relationship.=20 >=20 > --=20 > Andrew McDonald, Senior Engineer > Roke Manor Research Ltd, Romsey, Hants SO51 0ZN > Phone +44 1794 833833 Fax +44 1794 833434 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Feb 26 21:18:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22950 for ; Thu, 26 Feb 2004 21:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXZj-0006cz-DE for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 21:18:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R2I3A9025453 for nsis-archive@odin.ietf.org; Thu, 26 Feb 2004 21:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXZi-0006cC-El; Thu, 26 Feb 2004 21:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXYw-0006ZS-OG for nsis@optimus.ietf.org; Thu, 26 Feb 2004 21:17:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22934 for ; Thu, 26 Feb 2004 21:17:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwXYu-0005aU-00 for nsis@ietf.org; Thu, 26 Feb 2004 21:17:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwXXz-0005Tx-00 for nsis@ietf.org; Thu, 26 Feb 2004 21:16:15 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwXX8-0005FR-00 for nsis@ietf.org; Thu, 26 Feb 2004 21:15:22 -0500 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1R266je002745; Fri, 27 Feb 2004 10:06:20 +0800 (SGT) From: "Cheng Hong" To: "'McDonald, Andrew'" , , Cc: "'Georgios Karagiannis'" Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 10:14:11 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <005a01c3fcd7$69d04190$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi all, > > The question is: should the QoS NSLP specification define=20 > and support=20 > > a more generic notion of region (e.g. to implement region policies=20 > > independent from aggregation regions,...)? >=20 > A few additional thoughts (not actually attempting to answer=20 > the question > yet!): >=20 > One example might be where the node at the ingress to an=20 > administrative domain wants to query the available resources=20 > in the 'local' network as part of its local admission control=20 > decision. >=20 > If it is useful/needed, how should it be done? > One possibility is for a marker that indicates that the=20 > message should not be forwarded outside the local domain, and=20 > so is terminated by edge nodes. However, it can also be=20 > argued that this is too fragile, and that there isn't a safe=20 > way to do such scoping. (The trivial case of 'whole path' vs=20 > 'next node' doesn't have this problem. If you get a message=20 > with 'next node only' set then you know you shouldn't send it=20 > any further.) I think another issue is how the node verify the region scope in case of = a generic notion. Considering the error case, if the edge node fail to terminate the scoped message, can a node find out the message violates = the scope? (Different from the Qspec case, this message could be perfectly recognizable) One possible solution is to assign each region a unique identifier and carry the identifier with scope "marker".=20 > Should the NSLP do this itself? Or should the NTLP provide=20 > some generic functionality to do this? NSLP has to be involved in a certain way. A simple example, for the = "next node" scope, the actual next NSLP node could be several NTLP hops away. Also, the scope of the region only has meaning at each NSLP layer. (e.g. = the region for a QoS NSLP would be different for a NAT NSLP at the same NTLP node.) Cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 04:25:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21756 for ; Fri, 27 Feb 2004 04:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweEW-0000P0-VU for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9OaeT001516 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:24:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweEP-0000N8-KL; Fri, 27 Feb 2004 04:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweD7-00009R-64 for nsis@optimus.ietf.org; Fri, 27 Feb 2004 04:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21626 for ; Fri, 27 Feb 2004 04:23:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AweD4-0001fV-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AweC5-0001ZK-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:22:06 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AweB8-0001Q2-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:21:06 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMKZC6>; Fri, 27 Feb 2004 09:20:37 -0000 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Cc: "McDonald, Andrew" , Georgios Karagiannis Subject: RE: [NSIS] QoS NSLP open issue on priority Date: Fri, 27 Feb 2004 09:20:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 sven. > Hi all, > > The current version of the QoS NSLP specification discusses > priority in two > ways: > - priority of the signalling message transport (requirement on GIMPS) > - priority of the reservation (related to preemption) > > In the TE-WG, the concepts of setup priority and holding > priority were used > to implement similar behaviour for DiffServ TE. Clearly, any given QoS > model can include support for setup and/or holding priority. > The question > is whether people feel this functionality to be generally apllicable > (enough) to different QoS models to warrant inclusion of it > in the QoS NSLP > spec. my view: no. reason: i don't see any gain in integrating this aspect of operation with the rest of the NSLP protocol description. (your first point about GIMPS might be more interesting, but it isn't clear if you are asking for anything specific. in any case, you can do so by commenting on section 8.5 of the current GIMPS draft, where the question is raised and left open. so far, the only specific comment i have had on it is that this capability is not necessary...) r. > > Looking forward to your views, > Sven > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Feb 27 04:25:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21768 for ; Fri, 27 Feb 2004 04:25:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweEW-0000Oz-Um for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9OaBt001515 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:24:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweEN-0000Mc-In; Fri, 27 Feb 2004 04:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awe7X-0008N0-54 for nsis@optimus.ietf.org; Fri, 27 Feb 2004 04:17:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21555 for ; Fri, 27 Feb 2004 04:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awe7U-000198-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:17:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awe6X-00013i-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:16:21 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1Awe61-0000sJ-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:15:49 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMKZA0>; Fri, 27 Feb 2004 09:14:19 -0000 Message-ID: From: "Hancock, Robert" To: "'Cheng Hong'" , "McDonald, Andrew" , sven.van_den_bosch@alcatel.be, nsis@ietf.org Cc: "'Georgios Karagiannis'" Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 09:14:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, teeny GIMPS-specific point: > > Should the NSLP do this itself? Or should the NTLP provide > > some generic functionality to do this? > > NSLP has to be involved in a certain way. A simple example, > for the "next > node" scope, the actual next NSLP node > could be several NTLP hops away. ^^^^^^^^^^^^^^^^^ in the current GIMPS design, we are moving towards trying to eliminate that scenario if possible, and if people don't actually want it for some other reason. (the framework allows it and it is difficult to eliminate, but it does lead to a number of problems; cf. for example the security exchange around Dave Oran's mail a few days back.) robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 04:39:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22806 for ; Fri, 27 Feb 2004 04:39:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweSX-0002L4-Gy for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:39:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9d4vm008952 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweSU-0002Ji-9z; Fri, 27 Feb 2004 04:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweRg-0002Cy-52 for nsis@optimus.ietf.org; Fri, 27 Feb 2004 04:38:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22718 for ; Fri, 27 Feb 2004 04:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AweRd-0003dx-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AweQf-0003X6-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:37:10 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AwePl-0003Mc-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:36:13 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 27 Feb 2004 10:35:43 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Feb 2004 10:35:42 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF5EC@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] QoS NSLP open issue on priority Date: Fri, 27 Feb 2004 10:35:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Sven, I agree with Robert on the issue of preemption: it is no generic=20 NSLP functionality. Regards, R=FCdiger |> Hi all, |>=20 |> The current version of the QoS NSLP specification discusses=20 |> priority in two |> ways: |> - priority of the signalling message transport (requirement on = GIMPS) |> - priority of the reservation (related to preemption) |>=20 |> In the TE-WG, the concepts of setup priority and holding=20 |> priority were used to implement similar behaviour for DiffServ TE.=20 |> Clearly, any given QoS model can include support for setup and/or=20 |> holding priority.=20 |> The question is whether people feel this functionality to be=20 |> generally apllicable (enough) to different QoS models to warrant=20 |> inclusion of it in the QoS NSLP spec. | |my view: no.=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 04:39:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22827 for ; Fri, 27 Feb 2004 04:39:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweSc-0002Nn-TT for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:39:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9d9k0009119 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweSb-0002Mq-7j; Fri, 27 Feb 2004 04:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweRo-0002Ea-8V for nsis@optimus.ietf.org; Fri, 27 Feb 2004 04:38:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22752 for ; Fri, 27 Feb 2004 04:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AweRl-0003fB-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AweQt-0003ZE-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:37:23 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AweQS-0003Si-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:36:56 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1R4J>; Fri, 27 Feb 2004 09:36:26 -0000 Message-ID: From: "McDonald, Andrew" To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Cc: Georgios Karagiannis Date: Fri, 27 Feb 2004 09:36:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [NSIS] RE: QoS NSLP open issue on priority 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: , sven.van_den_bosch@alcatel.be wrote: > The current version of the QoS NSLP specification discusses priority > in two ways: > - priority of the signalling message transport (requirement on GIMPS) I think this is the interesting part of the "priority" issue. When does it matter that one message has priority over another? The main situations seem to be: - in the presence of network congestion (at the sending node) - where there is flow control (from the receiving node) As Rob points out, section 8.5 of the GIMPS draft talks about using multiple associations to do this. Usually the API to the underlying protocols doesn't tell you whether you are flow controlled or congestion controlled. Continuing to force data out (through an alternative association) when you are in a state of congestion control might well be considered impolite. There is also a (now expired) draft talking about some of these issues: http://www.watersprings.org/pub/id/draft-hancock-nsis-overload-00.txt > - priority of the reservation (related to preemption) > > In the TE-WG, the concepts of setup priority and holding priority > were used to implement similar behaviour for DiffServ TE. Clearly, > any given QoS model can include support for setup and/or holding > priority. The question is whether people feel this functionality to > be generally apllicable (enough) to different QoS models to warrant > inclusion of it in the QoS NSLP spec. This can be provided in any case at the QoS model level, so providing support at the QoS NSLP level is only necessary if there is a useful, general way of doing this. I'm not convinced at the moment that it is needed. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 04:53:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23547 for ; Fri, 27 Feb 2004 04:53:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwegH-0003Vz-5c for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:53:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9rH4O013447 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 04:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aweg9-0003UW-6N; Fri, 27 Feb 2004 04:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwefL-0003RW-GK for nsis@optimus.ietf.org; Fri, 27 Feb 2004 04:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23482 for ; Fri, 27 Feb 2004 04:52:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwefI-0005MG-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:52:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AweeO-0005FA-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:51:21 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1Awedo-00056O-00 for nsis@ietf.org; Fri, 27 Feb 2004 04:50:45 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 27 Feb 2004 10:50:16 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Feb 2004 10:50:15 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF5ED@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 10:50:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Sven, just a general comment regarding scoping and=20 stacking of QoS objects: I'd prefer NSLP to=20 leave these issues to a later stage. From an=20 operational point of view, they usually don't=20 add value to a service but they increase=20 operational complexity and can result in=20 rather intransparent service delivery.=20 I'd favour the first NSLP spec to support=20 globally well defined QoS models only. More=20 complex solutions should be added later. Regards, R=FCdiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 05:22:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24514 for ; Fri, 27 Feb 2004 05:22:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awf88-0005If-NV for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 05:22:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RAM4m5020338 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 05:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awf86-0005Hv-FY; Fri, 27 Feb 2004 05:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awf7k-0005GW-Kc for nsis@optimus.ietf.org; Fri, 27 Feb 2004 05:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24486 for ; Fri, 27 Feb 2004 05:21:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awf7h-0000QC-00 for nsis@ietf.org; Fri, 27 Feb 2004 05:21:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awf6e-0000IA-00 for nsis@ietf.org; Fri, 27 Feb 2004 05:20:32 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1Awf69-0000AR-00 for nsis@ietf.org; Fri, 27 Feb 2004 05:20:01 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMKZTX>; Fri, 27 Feb 2004 10:19:32 -0000 Message-ID: From: "Hancock, Robert" To: "'Geib, Ruediger'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 10:19:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi, > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Friday, February 27, 2004 09:50 > To: sven.van_den_bosch@alcatel.be > Cc: nsis@ietf.org > Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping >=20 >=20 > Hi Sven, >=20 > just a general comment regarding scoping and=20 > stacking of QoS objects: I'd prefer NSLP to=20 > leave these issues to a later stage. From an=20 > operational point of view, they usually don't=20 > add value to a service but they increase=20 > operational complexity and can result in=20 > rather intransparent service delivery.=20 >=20 > I'd favour the first NSLP spec to support=20 > globally well defined QoS models only.=20 Which ones would those be? (And I assume you mean "globally well defined and universally supported".) This is the root of the complexity (as was discussed in the meeting in Minneapolis IIRC.) robert h. > More=20 > complex solutions should be added later. >=20 > Regards, R=FCdiger =20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 06:01:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25631 for ; Fri, 27 Feb 2004 06:01:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awfjs-0007tH-7A for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 06:01:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RB14ol030316 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 06:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awfjq-0007sX-N9; Fri, 27 Feb 2004 06:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfjL-0007pd-Vz for nsis@optimus.ietf.org; Fri, 27 Feb 2004 06:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25603 for ; Fri, 27 Feb 2004 06:00:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfjI-0004LH-00 for nsis@ietf.org; Fri, 27 Feb 2004 06:00:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfiL-0004FR-00 for nsis@ietf.org; Fri, 27 Feb 2004 05:59:29 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1Awfhy-00048i-00 for nsis@ietf.org; Fri, 27 Feb 2004 05:59:06 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 27 Feb 2004 11:58:38 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Feb 2004 11:58:32 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF5F0@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 11:58:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Robert, |Which ones would those be? Assume one of those to be stacked - seriously, I think the aspect of missing QoS models=20 applies whether you assume there to be just=20 one or a bunch of them. |(And I assume you mean "globally well defined |and universally supported".) "Globally well defined" will do. I'm happy to=20 deploy NSIS in a single domain and learn how to=20 operate it before I go for interworkings,=20 mappings and such things. And I doubt=20 that other carriers will have a different view. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 06:19:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26072 for ; Fri, 27 Feb 2004 06:19:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awg1E-0000gM-Iv for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 06:19:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RBJ01g002607 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 06:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awg1E-0000fw-95; Fri, 27 Feb 2004 06:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awg0l-0000dr-GG for nsis@optimus.ietf.org; Fri, 27 Feb 2004 06:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26051 for ; Fri, 27 Feb 2004 06:18:27 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awg0h-0006OL-00 for nsis@ietf.org; Fri, 27 Feb 2004 06:18:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awg01-0006Ga-00 for nsis@ietf.org; Fri, 27 Feb 2004 06:17:46 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Awfym-00064a-00 for nsis@ietf.org; Fri, 27 Feb 2004 06:16:28 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1RBGExN004814; Fri, 27 Feb 2004 12:16:23 +0100 Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping To: "Geib, Ruediger" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 27 Feb 2004 12:16:16 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/27/2004 12:16:23 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Ruediger, Thanks for your comment (and also for expressing your opinion on the op= en issue). I agree with you that we should not make the specification over= ly complex. I do think that it is good to have these discussions now thoug= h, in order to avoid confusion on what is done in QoS NSLP and what could = be done. At the very least, it won't hurt to have a list of things that we= feel are desirable, although maybe not initially or in every deployment= . Best regards, Sven "Geib, Ruediger" on 27/02/2004 10:50:08 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Hi Sven, just a general comment regarding scoping and stacking of QoS objects: I'd prefer NSLP to leave these issues to a later stage. From an operational point of view, they usually don't add value to a service but they increase operational complexity and can result in rather intransparent service delivery. I'd favour the first NSLP spec to support globally well defined QoS models only. More complex solutions should be added later. Regards, R=FCdiger = _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 08:50:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01716 for ; Fri, 27 Feb 2004 08:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiNR-0003iO-6D for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 08:50:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RDo5ii014280 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 08:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiNQ-0003iD-0C; Fri, 27 Feb 2004 08:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiMo-0003gw-1R for nsis@optimus.ietf.org; Fri, 27 Feb 2004 08:49:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01711 for ; Fri, 27 Feb 2004 08:49:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiMm-0006g3-00 for nsis@ietf.org; Fri, 27 Feb 2004 08:49:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwiLs-0006b0-00 for nsis@ietf.org; Fri, 27 Feb 2004 08:48:28 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AwiLR-0006VG-00 for nsis@ietf.org; Fri, 27 Feb 2004 08:48:01 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1R0N>; Fri, 27 Feb 2004 13:47:24 -0000 Message-ID: From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 13:47:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi, > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Friday, February 27, 2004 10:58 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping >=20 >=20 >=20 > Robert, >=20 > |Which ones would those be? >=20 > Assume one of those to be stacked - seriously, > I think the aspect of missing QoS models=20 > applies whether you assume there to be just=20 > one or a bunch of them. that's quite right - however, if you insist on no stacking and the ability to have end to end qos signalling (without suffering from arbitrary rewriting) then the likelihood of a missing qos model becomes larger (a more serious and hard-to- recover-from-problem), unless you believe there will be one QoS model for the whole internet (which I don't). >=20 > |(And I assume you mean "globally well defined > |and universally supported".) >=20 > "Globally well defined" will do.=20 if it's not supported then it's as good as being not defined (so far as the requesting node being able to signal for something useful is concerned). you still need to be able to reject an un-supported model, for example. > I'm happy to=20 > deploy NSIS in a single domain and learn how to=20 > operate it before I go for interworkings,=20 > mappings and such things. And I doubt=20 > that other carriers will have a different view. that's perfectly reasonable.=20 if you want to do trials and experiments and even real deployments in a single network where you can enforce the policy that each node uses the same QoS model, then the complexity imposed by the QoS model flexibility has very little actual effect on you. (all you need to be able to do is to examine the first element of a list, rather than examine a single field.) and if you want to do work with other carriers you still won't have to do anything especially clever - provided you can persuade them to use the same QoS=20 model that you do. once that stops being possible, I believe that that extensibility allowed for in the design will make life much easier. the basic point is maybe that we should aim to minimise the additional cost of the stacking complexity for people who don't want to use it. i'd rather approach the question from *that* angle (rather than removing the facility completely). hence the discussion on error cases - what we seem to be converging on is that=20 error cases should be handled the same whether or not it applies to a stack of qos models or just a single one. there may be other cases which need similar analysis. r. >=20 > Regards, R=FCdiger >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 08:58:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01851 for ; Fri, 27 Feb 2004 08:58:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiV8-00048k-D6 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 08:58:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RDw2M2015899 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 08:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiV7-000480-NA; Fri, 27 Feb 2004 08:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiUR-00046b-0p for nsis@optimus.ietf.org; Fri, 27 Feb 2004 08:57:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01837 for ; Fri, 27 Feb 2004 08:57:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiUP-0007IQ-00 for nsis@ietf.org; Fri, 27 Feb 2004 08:57:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwiTV-0007EU-00 for nsis@ietf.org; Fri, 27 Feb 2004 08:56:21 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AwiSj-0007A4-00 for nsis@ietf.org; Fri, 27 Feb 2004 08:55:33 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id i1RDtUCi019685; Fri, 27 Feb 2004 14:55:31 +0100 (MET) Message-ID: <0ac801c3fd39$5daf2b30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , "'Geib, Ruediger'" Cc: References: Subject: Re: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 14:55:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Robert and Ruediger > > the basic point is maybe that we should aim to minimise > the additional cost of the stacking complexity for > people who don't want to use it. i'd rather approach > the question from *that* angle (rather than removing the > facility completely). hence the discussion on error > cases - what we seem to be converging on is that > error cases should be handled the same whether or not > it applies to a stack of qos models or just a single one. > there may be other cases which need similar analysis. I totally agree with Robert, see above! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 09:21:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03521 for ; Fri, 27 Feb 2004 09:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwirT-0006vy-8z for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 09:21:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1REL7T3026639 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 09:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwirR-0006vV-Og; Fri, 27 Feb 2004 09:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awiqm-0006rd-F4 for nsis@optimus.ietf.org; Fri, 27 Feb 2004 09:20:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03445 for ; Fri, 27 Feb 2004 09:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awiqk-0002uA-00 for nsis@ietf.org; Fri, 27 Feb 2004 09:20:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awipz-0002kN-00 for nsis@ietf.org; Fri, 27 Feb 2004 09:19:35 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1Awios-0002Lk-00 for nsis@ietf.org; Fri, 27 Feb 2004 09:18:26 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 27 Feb 2004 15:17:50 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Feb 2004 15:17:49 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF5F3@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 15:17:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hello Robert I would prefer the globally well defined solution,=20 but I'm not sure whether I'll see in my lifetime. So I'm with you in saying that NSLP should=20 allow stacking. My point is that stacking, scoping=20 and other features adding complexity will add delay=20 in finishing the standard while the will not be=20 used during initial operation. Why not standardise=20 a simple protocol first and fast, debug it during=20 operation and then continue with something more=20 demanding? I know that standardisation often works=20 the other way around: Do a complex specification=20 of which a subset will be implemented and made=20 operational. Are you really sure that there's a=20 carrier demand for stacking with the roll out of=20 NSLP products? Regards, R=FCdiger |> |Which ones would those be? |>=20 |> Assume one of those to be stacked - seriously, |> I think the aspect of missing QoS models=20 |> applies whether you assume there to be just=20 |> one or a bunch of them. | |that's quite right - however, if you insist on |no stacking and the ability to have end to end |qos signalling (without suffering from arbitrary |rewriting) then the likelihood of a missing qos |model becomes larger (a more serious and hard-to- |recover-from-problem), unless you believe there |will be one QoS model for the whole internet |(which I don't). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 09:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03857 for ; Fri, 27 Feb 2004 09:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awj15-0007bL-KA for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 09:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1REV3bP029200 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 09:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awj15-0007as-08; Fri, 27 Feb 2004 09:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awj0U-0007Yr-Is for nsis@optimus.ietf.org; Fri, 27 Feb 2004 09:30:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03794 for ; Fri, 27 Feb 2004 09:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awj0S-0003oU-00 for nsis@ietf.org; Fri, 27 Feb 2004 09:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwizP-0003iP-00 for nsis@ietf.org; Fri, 27 Feb 2004 09:29:20 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AwiyP-0003Yg-00 for nsis@ietf.org; Fri, 27 Feb 2004 09:28:17 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1SBF>; Fri, 27 Feb 2004 14:27:46 -0000 Message-ID: From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 14:27:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi, i would not like to say how much confidence i have or how little (although i do detect interest increasing rather than decreasing). the key point you raise is that of whether the flexibility implied causes a significant delay to the completion of the standard. at the moment, my impression is that the additional complexity can be made small, provided that we keep awareness of the issue (as we have on the error handling question, where i agree, significant additional complexity could have been introduced, but wasn't.) i'm sure that initial implementations, tests and trials will be done with simpler subsets; standardisation can be continued in parallel. that's how the ietf works (at least, that's the mythology of how the ietf works...) r. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Friday, February 27, 2004 14:18 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping >=20 >=20 > Hello Robert >=20 > I would prefer the globally well defined solution,=20 > but I'm not sure whether I'll see in my lifetime. > So I'm with you in saying that NSLP should=20 > allow stacking. My point is that stacking, scoping=20 > and other features adding complexity will add delay=20 > in finishing the standard while the will not be=20 > used during initial operation. Why not standardise=20 > a simple protocol first and fast, debug it during=20 > operation and then continue with something more=20 > demanding? I know that standardisation often works=20 > the other way around: Do a complex specification=20 > of which a subset will be implemented and made=20 > operational. Are you really sure that there's a=20 > carrier demand for stacking with the roll out of=20 > NSLP products? >=20 > Regards, R=FCdiger >=20 >=20 >=20 > |> |Which ones would those be? > |>=20 > |> Assume one of those to be stacked - seriously, > |> I think the aspect of missing QoS models=20 > |> applies whether you assume there to be just=20 > |> one or a bunch of them. > | > |that's quite right - however, if you insist on > |no stacking and the ability to have end to end > |qos signalling (without suffering from arbitrary > |rewriting) then the likelihood of a missing qos > |model becomes larger (a more serious and hard-to- > |recover-from-problem), unless you believe there > |will be one QoS model for the whole internet > |(which I don't). >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Feb 27 10:34:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08714 for ; Fri, 27 Feb 2004 10:34:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awk09-0000fO-Ms for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 10:34:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RFY9ET002561 for nsis-archive@odin.ietf.org; Fri, 27 Feb 2004 10:34:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awk01-0000eV-7f; Fri, 27 Feb 2004 10:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwjzW-0000bC-57 for nsis@optimus.ietf.org; Fri, 27 Feb 2004 10:33:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08638 for ; Fri, 27 Feb 2004 10:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwjzT-0004zP-00 for nsis@ietf.org; Fri, 27 Feb 2004 10:33:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwjyE-0004gx-00 for nsis@ietf.org; Fri, 27 Feb 2004 10:32:11 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Awjwy-0004Rq-00 for nsis@ietf.org; Fri, 27 Feb 2004 10:30:54 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1RFUpYG018765 for ; Fri, 27 Feb 2004 16:30:51 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Feb 2004 16:30:46 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Feb 2004 16:31:09 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'Geib, Ruediger'" , robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Date: Fri, 27 Feb 2004 16:30:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 27 Feb 2004 15:30:46.0630 (UTC) FILETIME=[ABAD3860:01C3FD46] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi R=FCdiger and Robert, I think everybody would like to have a simple implementation and model. T= he problem is that we want different ones and this is one of the reasons = of generality. I also have negative feelings about complexity. Specifying= individual QoS models also aims to solve this problem.=20 Best regards, Attila -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Geib, Ruediger Sent: Friday, February 27, 2004 3:18 PM To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping Hello Robert I would prefer the globally well defined solution,=20 but I'm not sure whether I'll see in my lifetime. So I'm with you in saying that NSLP should=20 allow stacking. My point is that stacking, scoping=20 and other features adding complexity will add delay=20 in finishing the standard while the will not be=20 used during initial operation. Why not standardise=20 a simple protocol first and fast, debug it during=20 operation and then continue with something more=20 demanding? I know that standardisation often works=20 the other way around: Do a complex specification=20 of which a subset will be implemented and made=20 operational. Are you really sure that there's a=20 carrier demand for stacking with the roll out of=20 NSLP products? Regards, R=FCdiger |> |Which ones would those be? |>=20 |> Assume one of those to be stacked - seriously, |> I think the aspect of missing QoS models=20 |> applies whether you assume there to be just=20 |> one or a bunch of them. | |that's quite right - however, if you insist on |no stacking and the ability to have end to end |qos signalling (without suffering from arbitrary |rewriting) then the likelihood of a missing qos |model becomes larger (a more serious and hard-to- |recover-from-problem), unless you believe there |will be one QoS model for the whole internet |(which I don't). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Feb 28 20:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14722 for ; Sat, 28 Feb 2004 20:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFlN-00076B-Og for nsis-archive@odin.ietf.org; Sat, 28 Feb 2004 20:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1T1f6027272 for nsis-archive@odin.ietf.org; Sat, 28 Feb 2004 20:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFlN-00075l-HL; Sat, 28 Feb 2004 20:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFl0-00073Y-2T for nsis@optimus.ietf.org; Sat, 28 Feb 2004 20:28:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14702 for ; Sat, 28 Feb 2004 20:28:35 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFkx-0004tQ-00 for nsis@ietf.org; Sat, 28 Feb 2004 20:28:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFkA-0004nI-00 for nsis@ietf.org; Sat, 28 Feb 2004 20:27:47 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AxFjZ-0004er-00 for nsis@ietf.org; Sat, 28 Feb 2004 20:27:09 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1T1R8L28561 for ; Sun, 29 Feb 2004 03:27:08 +0200 (EET) X-Scanned: Sun, 29 Feb 2004 03:27:07 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1T1R745031817 for ; Sun, 29 Feb 2004 03:27:07 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 007fMVup; Sun, 29 Feb 2004 03:27:07 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1T1R6706995 for ; Sun, 29 Feb 2004 03:27:07 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 29 Feb 2004 03:27:06 +0200 Date: Sun, 29 Feb 2004 03:27:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message Thread-Topic: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS thread-index: AcP7jKqL2AGP2fhMTsOHrNBUBwvigAC1fFDQ To: X-OriginalArrivalTime: 29 Feb 2004 01:27:06.0665 (UTC) FILETIME=[24A70990:01C3FE63] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Request for QoS model authors 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: quoted-printable Hi all, In some side discussions, some folks have raised some questions about = NSIS state. More specifically, what state are folks talking about and where the state is = expected to be held. What I would like the authors of the QoS model drafts is to think = about what state they are expecting & where they expect the state to be held (all = routers, access routers, border routers, etc.). I'm trying to get a sense of what = people are expecting and also I think that some of this info might be good to provide a = reality check on the mobility discussions as well. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Feb 29 02:49:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11378 for ; Sun, 29 Feb 2004 02:49:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLhB-0008Uq-Ab for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 02:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T7n4hV032639 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 02:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLh7-0008UK-OA; Sun, 29 Feb 2004 02:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLgo-0008Tj-Jd for nsis@optimus.ietf.org; Sun, 29 Feb 2004 02:48:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11352 for ; Sun, 29 Feb 2004 02:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLgk-0002Mp-00 for nsis@ietf.org; Sun, 29 Feb 2004 02:48:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLfm-0002Iq-00 for nsis@ietf.org; Sun, 29 Feb 2004 02:47:39 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AxLfF-0002F7-00 for nsis@ietf.org; Sun, 29 Feb 2004 02:47:05 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1T7l5qY015800 for ; Sun, 29 Feb 2004 08:47:06 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 08:47:05 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Sun, 29 Feb 2004 08:47:35 +0100 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Request for QoS model authors Date: Sun, 29 Feb 2004 08:47:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 29 Feb 2004 07:47:05.0965 (UTC) FILETIME=[3A1821D0:01C3FE98] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, Yes sure, in RMD model this is an important question and I wanted to cover it anyway. Best regards, Attila -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of john.loughney@nokia.com Sent: Sunday, February 29, 2004 2:27 AM To: nsis@ietf.org Subject: [NSIS] Request for QoS model authors Hi all, In some side discussions, some folks have raised some questions about NSIS state. More specifically, what state are folks talking about and where the state is expected to be held. What I would like the authors of the QoS model drafts is to think about what state they are expecting & where they expect the state to be held (all routers, access routers, border routers, etc.). I'm trying to get a sense of what people are expecting and also I think that some of this info might be good to provide a reality check on the mobility discussions as well. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Feb 29 18:40:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16535 for ; Sun, 29 Feb 2004 18:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaXW-0006aw-T9 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 18:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TNe6KX025313 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 18:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaXU-0006a7-Iw; Sun, 29 Feb 2004 18:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaWf-0006Xc-Sj for nsis@optimus.ietf.org; Sun, 29 Feb 2004 18:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16491 for ; Sun, 29 Feb 2004 18:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaWc-0006FE-00 for nsis@ietf.org; Sun, 29 Feb 2004 18:39:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaVi-0006BA-00 for nsis@ietf.org; Sun, 29 Feb 2004 18:38:15 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AxaUt-00062D-00 for nsis@ietf.org; Sun, 29 Feb 2004 18:37:24 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMLN19>; Sun, 29 Feb 2004 23:36:47 -0000 Received: from wlan7.roke.co.uk (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZGN1T1R; Sun, 29 Feb 2004 23:36:42 -0000 Received: by wlan7.roke.co.uk (sSMTP sendmail emulation); Sun, 29 Feb 2004 23:36:38 +0000 From: "McDonald, Andrew" To: nsis@ietf.org Date: Sun, 29 Feb 2004 23:36:34 +0000 Subject: Re: [NSIS] Request for QoS model authors Message-ID: <20040229233633.GA1784@roke.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , On Sun, Feb 29, 2004 at 03:27:05AM +0200, john.loughney@nokia.com wrote: > In some side discussions, some folks have raised some questions about > NSIS state. More specifically, what state are folks talking about > and where the state is expected to be held. What I would like the > authors of the QoS model drafts is to think about what state they are > expecting & where they expect the state to be held (all routers, > access routers, border routers, etc.). I'm trying to get a sense of > what people are expecting and also I think that some of this info > might be good to provide a reality check on the mobility discussions > as well. Also, from a general QoS NSLP view, anything that QoS model drafters have found that is wrong or, more likely, missing from the QoS NSLP draft that they think is necessary would be useful to hear. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Feb 29 19:16:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18244 for ; Sun, 29 Feb 2004 19:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axb6J-0000rh-46 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 19:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210G3Gf003310 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 19:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axb6I-0000qV-GN; Sun, 29 Feb 2004 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axb5r-0000nB-2q for nsis@optimus.ietf.org; Sun, 29 Feb 2004 19:15:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18155 for ; Sun, 29 Feb 2004 19:15:32 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axb5p-0001iI-00 for nsis@ietf.org; Sun, 29 Feb 2004 19:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axb51-0001bK-00 for nsis@ietf.org; Sun, 29 Feb 2004 19:14:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Axb4M-0001U8-00 for nsis@ietf.org; Sun, 29 Feb 2004 19:14:02 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i210E1016274; Mon, 1 Mar 2004 02:14:01 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 02:13:57 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i210Dvm3022044; Mon, 1 Mar 2004 02:13:57 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00qqHCdp; Mon, 01 Mar 2004 02:13:56 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i210DuO11654; Mon, 1 Mar 2004 02:13:56 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 02:13:57 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 02:13:57 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Request for QoS model authors x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 02:13:55 +0200 Message-ID: Thread-Topic: [NSIS] Request for QoS model authors thread-index: AcP/HXvaIeB+MEuBScCea9yQ2bvd/AABIfkA To: , X-OriginalArrivalTime: 01 Mar 2004 00:13:57.0719 (UTC) FILETIME=[170CC670:01C3FF22] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Andrew, > Also, from a general QoS NSLP view, anything that QoS model drafters > have found that is wrong or, more likely, missing from the QoS NSLP > draft that they think is necessary would be useful to hear. Definately, that is a good thing for folks to point out. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Feb 29 20:55:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22994 for ; Sun, 29 Feb 2004 20:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axce8-00023W-D7 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 20:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211t4f8007865 for nsis-archive@odin.ietf.org; Sun, 29 Feb 2004 20:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axce7-00022F-93; Sun, 29 Feb 2004 20:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcdM-0001zN-5h for nsis@optimus.ietf.org; Sun, 29 Feb 2004 20:54:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22936 for ; Sun, 29 Feb 2004 20:54:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcdJ-000435-00 for nsis@ietf.org; Sun, 29 Feb 2004 20:54:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxccL-0003w6-00 for nsis@ietf.org; Sun, 29 Feb 2004 20:53:13 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AxcbO-0003bD-00 for nsis@ietf.org; Sun, 29 Feb 2004 20:52:14 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1TGB>; Mon, 1 Mar 2004 01:51:39 -0000 Message-ID: From: "Hancock, Robert" To: "'Xiaoming Fu'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking Date: Mon, 1 Mar 2004 01:51:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 xiaoming, > Hancock, Robert wrote: > > hi, > > [just to reassure you: if a message arrived in C-mode you > > can always send back a message along the same association; > Just from a programmer's view: > > In TCP, connections are duplex but conceptually "uni-directional" > between a server and a client: once a connection is set up, > data can be > sent by the server back toward the client, but the control is in the > client side (i.e., these data are sent when the server passively > acquires a request from the client). Of course with some tricks in > programming, a true uni-directionality can be made possible, > but at cost > of possibly more complex socket operation. As a tradeoff, another > connection - we just need one connection in maximum per direction > between a GIMPS-peer pair - in the reverse direction could be > an viable > option. GIMPS messaging associations are assumed to be full duplex (i.e. once it has been set up, it can be used identically by either end). TCP can be used in this way. i'm not sure why having a pair of conceptually uni-directional associations would make life easier. (i'm open to suggestions.) > > > D-mode messages always include the Node-Addressing of the > > peer that sent it, so you can respond direct to that.] > If the data does not concern with any other nodes in between > these two > D-mode peers (e.g., just to acknowledge the previous D- sender), this > can work. However, if in the reverse way changing something in the > middle is desired, we have to rely on PHOP info as in RSVP. The Node-Addressing object in GIMPS is the precise analogue the RSVP PHOP object. So, I think we are actually saying the same thing here. cheers, r. > > Cheers, > Xiaoming > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis