From exim@www1.ietf.org Thu Jan 8 04:31:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14212 for ; Thu, 8 Jan 2004 04:31: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 1AeWVO-0004AR-L7 for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 04:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i089V6xr016007 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 04: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 1AeWVL-00049Z-GM; Thu, 08 Jan 2004 04: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 1AeWUs-00048c-50 for nsis@optimus.ietf.org; Thu, 08 Jan 2004 04:30: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 EAA14197 for ; Thu, 8 Jan 2004 04:30:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeWUf-0004Vu-00 for nsis@ietf.org; Thu, 08 Jan 2004 04:30:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeWRg-0004Oz-00 for nsis@ietf.org; Thu, 08 Jan 2004 04:27:16 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AeWNd-0004GG-00 for nsis@ietf.org; Thu, 08 Jan 2004 04:23:06 -0500 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 08 Jan 2004 11:22:38 +0200 Date: Thu, 8 Jan 2004 11:22:38 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Dear all, I did not see any comments during the Last Call period. Does this mean that the document is ready to advance, or that nobody really cared? Cheers, Jukka On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: > Hello all, > > I would like to start a 2 week WG last call on the analysis document. > The current version can be found here: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-03.txt > > The WGLC will run from December 11th to December 24th. I'll leave it up > to the draft editor to co-ordinate issue tracking, etc. > > 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 Thu Jan 8 05:49:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16647 for ; Thu, 8 Jan 2004 05:49: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 1AeXir-00089M-4C for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 05:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08An5M7031318 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 05: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 1AeXim-00088T-UD; Thu, 08 Jan 2004 05:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXiK-00087H-1F for nsis@optimus.ietf.org; Thu, 08 Jan 2004 05:48: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 FAA16615 for ; Thu, 8 Jan 2004 05:48:28 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeXiG-0000Xc-00 for nsis@ietf.org; Thu, 08 Jan 2004 05:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeXgS-0000Rx-00 for nsis@ietf.org; Thu, 08 Jan 2004 05:46:36 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeXeh-0000Lo-00 for nsis@ietf.org; Thu, 08 Jan 2004 05:44:47 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i08Aim618814 for ; Thu, 8 Jan 2004 12:44:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 12:29:29 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jan 2004 12:29: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 Subject: RE: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Date: Thu, 8 Jan 2004 12:29:13 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Thread-Index: AcPVyixe9tkyeJ73TICpUYU6i0p/2wAB/Ovg To: , X-OriginalArrivalTime: 08 Jan 2004 10:29:29.0148 (UTC) FILETIME=[4C00DFC0:01C3D5D2] 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 all, Before the document can be sent to the AD, I would at least need some people to comment that they have read the document, they think it is useful & should go forward. thanks, John > I did not see any comments during the Last Call period. Does this mean = > that the document is ready to advance, or that nobody really cared? >=20 > Cheers, > Jukka >=20 > On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: >=20 > > Hello all, > >=20 > > I would like to start a 2 week WG last call on the analysis = document. =20 > > The current version can be found here: > >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 3.txt > >=20 > > The WGLC will run from December 11th to December 24th. I'll leave it = up > > to the draft editor to co-ordinate issue tracking, etc. > >=20 > > thanks, > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 8 06:16:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17304 for ; Thu, 8 Jan 2004 06: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 1AeY8w-0000tJ-MM for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 06:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08BG2SP003397 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 06:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeY8v-0000sd-RH; Thu, 08 Jan 2004 06:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeY8h-0000s7-E5 for nsis@optimus.ietf.org; Thu, 08 Jan 2004 06:15: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 GAA17297 for ; Thu, 8 Jan 2004 06:15:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeY8W-00021P-00 for nsis@ietf.org; Thu, 08 Jan 2004 06:15:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeY5S-0001y5-00 for nsis@ietf.org; Thu, 08 Jan 2004 06:12:27 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AeY44-0001v2-00 for nsis@ietf.org; Thu, 08 Jan 2004 06:11:00 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i08BAF4G016668 for ; Thu, 8 Jan 2004 06:10:15 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i08BAD4G016652 for ; Thu, 8 Jan 2004 06:10:14 -0500 (EST) 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] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Date: Thu, 8 Jan 2004 13:10:57 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Thread-Index: AcPVyixe9tkyeJ73TICpUYU6i0p/2wAB/OvgAAF2JbA= From: "Romascanu, Dan (Dan)" 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 I have followed this work, I read the current version of the document, I = think that it is very useful, and I support it going forward. Regards, Dan > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On=20 > Behalf Of john.loughney@nokia.com > Sent: 08 January, 2004 12:29 PM > To: jmanner@cs.Helsinki.FI; nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on "Analysis of Existing=20 > Quality of Service Signaling Protocols" >=20 >=20 > Hi all, >=20 > Before the document can be sent to the AD, I would at least need some > people to comment that they have read the document, they think it > is useful & should go forward. >=20 > thanks, > John >=20 > > I did not see any comments during the Last Call period.=20 > Does this mean=20 > > that the document is ready to advance, or that nobody really cared? > >=20 > > Cheers, > > Jukka > >=20 > > On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: > >=20 > > > Hello all, > > >=20 > > > I would like to start a 2 week WG last call on the=20 > analysis document. =20 > > > The current version can be found here: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling > -analysis-03.txt > > >=20 > > > The WGLC will run from December 11th to December 24th.=20 > I'll leave it up > > > to the draft editor to co-ordinate issue tracking, etc. > > >=20 > > > thanks, > > > John >=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 Jan 8 07:53:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21513 for ; Thu, 8 Jan 2004 07:53: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 1AeZeo-0005bi-GL for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 07:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Cr2R9021548 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 07: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 1AeZen-0005b4-10; Thu, 08 Jan 2004 07: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 1AeZeP-0005Yk-Sh for nsis@optimus.ietf.org; Thu, 08 Jan 2004 07:52: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 HAA21479 for ; Thu, 8 Jan 2004 07:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZeO-0000Of-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZci-0000Jz-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:50:53 -0500 Received: from soleil.uvsq.fr ([193.51.24.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeZc9-0000D2-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:50:17 -0500 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.8p2/jtpda-5.4) with ESMTP id i08CoAT0021970 ; Thu, 8 Jan 2004 13:50:10 +0100 (CET) Received: from Asgard (tahiti.prism.uvsq.fr [193.51.25.228]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with ESMTP id i08CoAE00814 ; Thu, 8 Jan 2004 13:50:10 +0100 (MET) Message-Id: <200401081250.i08CoAE00814@guillotin.prism.uvsq.fr> From: "Guillaume Buridant" To: "'Romascanu, Dan \(Dan\)'" , , , Subject: RE: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Date: Thu, 8 Jan 2004 13:50:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcPVyixe9tkyeJ73TICpUYU6i0p/2wAB/OvgAAF2JbAAA1qqEA== X-Antivirus: scanned by sophie at soleil.uvsq.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.7 required=5.0 tests=AWL,MISSING_OUTLOOK_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, I've also read this internet draft, and I think it is a very useful = work. My current research interests concern use of RSVP as a unified signalling protocol. This preliminary analysis can help us to determine important functionalities that have to be considered in further work on this = subject. Regards, Guillaume Buridant PRiSM Laboratory Versailles University France -----Message d'origine----- De=A0: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] De la part de Romascanu, Dan (Dan) Envoy=E9=A0: jeudi 8 janvier 2004 12:11 =C0=A0: john.loughney@nokia.com; jmanner@cs.Helsinki.FI; nsis@ietf.org Objet=A0: RE: [NSIS] WG Last Call on "Analysis of Existing Quality of = Service Signaling Protocols" I have followed this work, I read the current version of the document, I think that it is very useful, and I support it going forward. Regards, Dan > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On=20 > Behalf Of john.loughney@nokia.com > Sent: 08 January, 2004 12:29 PM > To: jmanner@cs.Helsinki.FI; nsis@ietf.org > Subject: RE: [NSIS] WG Last Call on "Analysis of Existing=20 > Quality of Service Signaling Protocols" >=20 >=20 > Hi all, >=20 > Before the document can be sent to the AD, I would at least need some > people to comment that they have read the document, they think it > is useful & should go forward. >=20 > thanks, > John >=20 > > I did not see any comments during the Last Call period.=20 > Does this mean=20 > > that the document is ready to advance, or that nobody really cared? > >=20 > > Cheers, > > Jukka > >=20 > > On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: > >=20 > > > Hello all, > > >=20 > > > I would like to start a 2 week WG last call on the=20 > analysis document. =20 > > > The current version can be found here: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling > -analysis-03.txt > > >=20 > > > The WGLC will run from December 11th to December 24th.=20 > I'll leave it up > > > to the draft editor to co-ordinate issue tracking, etc. > > >=20 > > > thanks, > > > John >=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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 8 07:57:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21639 for ; Thu, 8 Jan 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 1AeZig-0005lp-TU for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 07:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Cv2LZ022136 for nsis-archive@odin.ietf.org; Thu, 8 Jan 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 1AeZig-0005kv-9l; Thu, 08 Jan 2004 07:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZiK-0005jj-8P for nsis@optimus.ietf.org; Thu, 08 Jan 2004 07:56: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 HAA21628 for ; Thu, 8 Jan 2004 07:56:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZiJ-0000cQ-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:56:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZgU-0000WS-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:54:46 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AeZel-0000QN-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:52:59 -0500 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 08 Jan 2004 14:52:57 +0200 Date: Thu, 8 Jan 2004 14:52:57 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" In-Reply-To: Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.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 Dear all, I believe the document is a very good overview of RSVP, its good and bad sides as seen from the point of view of the networks and services available today. The draft actually documents the reasons why the base RSVP does not solve the problems people have, and what extensions the IETF and other groups have designed to enhance the base RSVP. Without such an overview where do we draw the conclusion from that RSVP is not enough? The additional material about other protocols is valuable material, too, and shows some ideas people have had, and what might be learned from them. I think the engineering world at least needs a single document that analyzes RSVP from a more or less objective point of view. Regards, Jukka On Thu, 8 Jan 2004 john.loughney@nokia.com wrote: > Hi all, > > Before the document can be sent to the AD, I would at least need some > people to comment that they have read the document, they think it > is useful & should go forward. > > thanks, > John > > > I did not see any comments during the Last Call period. Does this mean > > that the document is ready to advance, or that nobody really cared? > > > > Cheers, > > Jukka > > > > On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: > > > > > Hello all, > > > > > > I would like to start a 2 week WG last call on the analysis document. > > > The current version can be found here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-03.txt > > > > > > The WGLC will run from December 11th to December 24th. I'll leave it up > > > to the draft editor to co-ordinate issue tracking, etc. > > > > > > 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 Thu Jan 8 08:05:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21933 for ; Thu, 8 Jan 2004 08:05: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 1AeZqR-0006Mu-I8 for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 08:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08D53Rr024444 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 08: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 1AeZqR-0006MA-8t; Thu, 08 Jan 2004 08: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 1AeZpu-0006KP-LW for nsis@optimus.ietf.org; Thu, 08 Jan 2004 08:04: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 IAA21877 for ; Thu, 8 Jan 2004 08:04:29 -0500 (EST) From: louise.burness@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZpt-00012k-00 for nsis@ietf.org; Thu, 08 Jan 2004 08:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZoA-0000xO-00 for nsis@ietf.org; Thu, 08 Jan 2004 08:02:42 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138] helo=i2kc03-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AeZmU-0000oG-00 for nsis@ietf.org; Thu, 08 Jan 2004 08:00:58 -0500 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jan 2004 13:00:47 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jan 2004 13:00:46 +0000 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] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Date: Thu, 8 Jan 2004 13:00:46 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A70046A0638@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Thread-Index: AcPVyixe9tkyeJ73TICpUYU6i0p/2wAB/OvgAAVJSlA= To: , , X-OriginalArrivalTime: 08 Jan 2004 13:00:46.0541 (UTC) FILETIME=[6E8D1FD0:01C3D5E7] 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 all I read it some time ago and find it useful,because its objective. = Haven't read the last call version in detail, although if it would help = I could? Lou -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of john.loughney@nokia.com Sent: 08 January 2004 10:29 To: jmanner@cs.Helsinki.FI; nsis@ietf.org Subject: RE: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Hi all, Before the document can be sent to the AD, I would at least need some people to comment that they have read the document, they think it is useful & should go forward. thanks, John > I did not see any comments during the Last Call period. Does this mean = > that the document is ready to advance, or that nobody really cared? >=20 > Cheers, > Jukka >=20 > On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: >=20 > > Hello all, > >=20 > > I would like to start a 2 week WG last call on the analysis = document. =20 > > The current version can be found here: > >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-0= 3.txt > >=20 > > The WGLC will run from December 11th to December 24th. I'll leave it = up > > to the draft editor to co-ordinate issue tracking, etc. > >=20 > > 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 Thu Jan 8 08:45:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21638 for ; Thu, 8 Jan 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 1AeZig-0005kw-9t for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 07:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Cv2tJ022084 for nsis-archive@odin.ietf.org; Thu, 8 Jan 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 1AeZif-0005k4-Nh; Thu, 08 Jan 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 1AeZiI-0005je-0L for nsis@optimus.ietf.org; Thu, 08 Jan 2004 07:56: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 HAA21625 for ; Thu, 8 Jan 2004 07:56:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZiH-0000bw-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:56:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZgT-0000WH-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:54:46 -0500 Received: from infres.enst.fr ([137.194.160.3]) by ietf-mx with esmtp (Exim 4.12) id 1AeZef-0000QK-00 for nsis@ietf.org; Thu, 08 Jan 2004 07:52:53 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 5E3301951; Thu, 8 Jan 2004 13:52:50 +0100 (MET) Message-ID: <004601c3d5e6$8c861e20$7907c289@pcluu> From: "Thanh Tra LUU" To: "Jukka MJ Manner" Cc: References: Subject: Re: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Date: Thu, 8 Jan 2004 13:54:26 +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=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, I've read this draft version 00 -> 03, i found it good to be forwarded. However, i do not like the appendix A much. The comparison is very very useful, but i dont think it is conventional to be in this document. Sorry to be late. Nary Tra. ENST, Paris ----- Original Message ----- From: "Jukka MJ Manner" To: Sent: Thursday, January 08, 2004 10:22 AM Subject: Re: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" > > Dear all, > > I did not see any comments during the Last Call period. Does this mean > that the document is ready to advance, or that nobody really cared? > > Cheers, > Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 8 10:59:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29690 for ; Thu, 8 Jan 2004 10:59: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 1AecYn-0007iQ-5D for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 10:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Fx1TI029657 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 10: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 1AecYm-0007iB-JF; Thu, 08 Jan 2004 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecYG-0007fS-OA for nsis@optimus.ietf.org; Thu, 08 Jan 2004 10: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 KAA29616 for ; Thu, 8 Jan 2004 10:58:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecYE-0003mJ-00 for nsis@ietf.org; Thu, 08 Jan 2004 10:58:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AecWK-0003d2-00 for nsis@ietf.org; Thu, 08 Jan 2004 10:56:29 -0500 Received: from mail-gw.carrieraccess.com ([65.221.135.10]) by ietf-mx with esmtp (Exim 4.12) id 1AecUX-0003Oi-00 for nsis@ietf.org; Thu, 08 Jan 2004 10:54:37 -0500 Received: from Unknown [172.1.1.254] by MAIL-GW.carrieraccess.com - SurfControl E-mail Filter (4.7); Thu, 08 Jan 2004 08:54:06 -0700 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Jan 2004 08:54:05 -0700 Message-ID: From: "Avella, Alejandro" To: "'nsis@ietf.org'" Date: Thu, 8 Jan 2004 08:54:04 -0700 Subject: RE: [NSIS] WG Last Call on "Analysis of Existing Quality of Servi ce Signaling Protocols" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_08_54_06_Thursday_January_08_2004_3268" X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_30_40,HTML_MESSAGE, MIME_BOUND_NEXTPART 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ----=_NextPart_ST_08_54_06_Thursday_January_08_2004_3268 Content-Type: text/plain; charset="iso-8859-1" I believe this is a good analysis of existing solutions that provides an overview to new comers to this area. I think it is a good informational document. Alejandro -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, December 11, 2003 6:24 AM To: nsis@ietf.org Subject: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Hello all, I would like to start a 2 week WG last call on the analysis document. The current version can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-03.t xt The WGLC will run from December 11th to December 24th. I'll leave it up to the draft editor to co-ordinate issue tracking, etc. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ----=_NextPart_ST_08_54_06_Thursday_January_08_2004_3268 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] WG Last Call on "Analysis of Existing Quality of Ser= vice Signaling Protocols"

I believe this is a good analysis of existing solutions t= hat provides an overview to new comers to this area.  I think it is a = good informational document.

Alejandro

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Thursday, December 11, 2003 6:24 AM
To: nsis@ietf.org
Subject: [NSIS] WG Last Call on "Analysis of Existi= ng Quality of Service
Signaling Protocols"


Hello all,

I would like to start a 2 week WG last call on the analys= is document.  The current version can be found here:

http://www.ietf.org/int= ernet-drafts/draft-ietf-nsis-signalling-analysis-03.txt

The WGLC will run from December 11th to December 24th.&nb= sp; I'll leave it up to the draft editor to co-ordinate issue tracking, etc= =2E

thanks,
John

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

----=_NextPart_ST_08_54_06_Thursday_January_08_2004_3268-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 8 22:09:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25696 for ; Thu, 8 Jan 2004 22:09: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 1Aen1F-00057S-DA for nsis-archive@odin.ietf.org; Thu, 08 Jan 2004 22:09:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09395dT019662 for nsis-archive@odin.ietf.org; Thu, 8 Jan 2004 22:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aen1B-00056v-Ky; Thu, 08 Jan 2004 22:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aen0j-00050N-My for nsis@optimus.ietf.org; Thu, 08 Jan 2004 22:08: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 WAA25681 for ; Thu, 8 Jan 2004 22:08:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aen0R-0005h8-00 for nsis@ietf.org; Thu, 08 Jan 2004 22:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AemxQ-0005WV-00 for nsis@ietf.org; Thu, 08 Jan 2004 22:05:08 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1AemsH-0005Jn-00 for nsis@ietf.org; Thu, 08 Jan 2004 21:59:49 -0500 Received: (qmail 555 invoked from network); 9 Jan 2004 02:29:13 -0000 Received: from unknown (HELO wym-pc) (210.42.103.237) by 202.106.187.158 with SMTP; 9 Jan 2004 02:29:13 -0000 From: "Yuming Wang" To: "nsis@ietf.org" Subject: Re: Re: [NSIS] WG Last Call on "Analysis of Existing Quality of ServiceSignaling Protocols" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Fri, 9 Jan 2004 10:30:40 +0800 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 all, I think it's a good summary and analyzing of the existing solutions, and a good reference for us to inherit advantages and avoid shortcomings of the existing solutions. It helps us do a better job in designing the next step signaling protocols. >Dear all, > >I did not see any comments during the Last Call period. Does this mean >that the document is ready to advance, or that nobody really cared? > >Cheers, >Jukka > >On Thu, 11 Dec 2003 john.loughney@nokia.com wrote: > >> Hello all, >> >> I would like to start a 2 week WG last call on the analysis document. >> The current version can be found here: >> >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-03.txt >> >> The WGLC will run from December 11th to December 24th. I'll leave it up >> to the draft editor to co-ordinate issue tracking, etc. >> >> 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 Yuming 2004-01-09 ---------------- 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 Mon Jan 12 05:01:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20461 for ; Mon, 12 Jan 2004 05:01: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 1Afysd-0004J7-NE for nsis-archive@odin.ietf.org; Mon, 12 Jan 2004 05:01:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CA16bl016538 for nsis-archive@odin.ietf.org; Mon, 12 Jan 2004 05:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfysX-0004Ho-9p; Mon, 12 Jan 2004 05:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfysS-0004H9-Bm for nsis@optimus.ietf.org; Mon, 12 Jan 2004 05:00: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 FAA20451 for ; Mon, 12 Jan 2004 05:00:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfysP-0001DJ-00 for nsis@ietf.org; Mon, 12 Jan 2004 05:00:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afyqa-0001B5-00 for nsis@ietf.org; Mon, 12 Jan 2004 04:59:00 -0500 Received: from infres.enst.fr ([137.194.160.3]) by ietf-mx with esmtp (Exim 4.12) id 1AfypT-00018d-00 for nsis@ietf.org; Mon, 12 Jan 2004 04:57:51 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 838661A71 for ; Mon, 12 Jan 2004 10:57:50 +0100 (MET) Message-ID: <001001c3d8f2$d09644a0$7907c289@pcluu> From: "Thanh Tra LUU" To: References: Date: Mon, 12 Jan 2004 10:59:48 +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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] SESSION_ID Sender: nsis-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 our framework, authors write "the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application". i just want to confirm: is it right that a session-id is only used for one flow and ONE signaling application ? B. regards, Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jan 13 08:03:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10085 for ; Tue, 13 Jan 2004 08: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 1AgO8U-0003qO-9Z for nsis-archive@odin.ietf.org; Tue, 13 Jan 2004 07:59:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DCxAmR014760 for nsis-archive@odin.ietf.org; Tue, 13 Jan 2004 07:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgO8L-0003pW-Ak; Tue, 13 Jan 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 1AgO7i-0003nn-PR for nsis@optimus.ietf.org; Tue, 13 Jan 2004 07:58:22 -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 HAA09935 for ; Tue, 13 Jan 2004 07:58: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 1AgO7c-000454-00 for nsis@ietf.org; Tue, 13 Jan 2004 07:58:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgO3d-0003ww-00 for nsis@ietf.org; Tue, 13 Jan 2004 07:54:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AgNyv-0003oN-00 for nsis@ietf.org; Tue, 13 Jan 2004 07:49:17 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0DCn6218083 for ; Tue, 13 Jan 2004 14:49:06 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 13 Jan 2004 14:49:02 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 14:49:01 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 14:49:00 +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, 13 Jan 2004 14:49:00 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on "Analysis of Existing Quality of Service Signaling Protocols" Thread-Index: AcPVyixe9tkyeJ73TICpUYU6i0p/2wAB/OvgAAVJSlAA+wSiwA== To: X-OriginalArrivalTime: 13 Jan 2004 12:49:00.0890 (UTC) FILETIME=[9E0413A0:01C3D9D3] 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, UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] IETF 59 scheduling Sender: nsis-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, I have just sent in the request for the NSIS meeting slots at IETF 59. = These are the WGs that I have requested to avoid being scheduled at the = same time: MUST AVOID: MIDCOM, IPv6, TSVWG, AAA, ALIAS bof=20 SHOULD AVOID:=20 MIP4, MIPv6, MIPSHOP, SIPPING, CCAMP, TEWG, DCCP If there are any other WGs that should be avoided, please let me know.=20 thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jan 13 13:33:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01938 for ; Tue, 13 Jan 2004 13:33: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 1AgTLe-0002lA-Pd for nsis-archive@odin.ietf.org; Tue, 13 Jan 2004 13:33:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DIX6Qv010592 for nsis-archive@odin.ietf.org; Tue, 13 Jan 2004 13:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTLZ-0002kK-Bk; Tue, 13 Jan 2004 13: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 1AgTL7-0002jN-Ia for nsis@optimus.ietf.org; Tue, 13 Jan 2004 13:32: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 NAA01925 for ; Tue, 13 Jan 2004 13:32:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgTL5-0003ZD-00 for nsis@ietf.org; Tue, 13 Jan 2004 13:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgTJB-0003Vh-00 for nsis@ietf.org; Tue, 13 Jan 2004 13:30:33 -0500 Received: from f34hyatt.fairviewwireless.com ([64.69.75.34] helo=hubble.802wirelessworld.com ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AgTHp-0003SX-00 for nsis@ietf.org; Tue, 13 Jan 2004 13:29:09 -0500 Received: from 10.0.13.218 (unknown [10.0.13.218]) by hubble.802wirelessworld.com (Postfix) with SMTP id 0FABB13B8F0 for ; Tue, 13 Jan 2004 10:29:01 -0800 (PST) From: "Cheng Hong" To: "'Thanh Tra LUU'" , Subject: RE: [NSIS] SESSION_ID Date: Wed, 14 Jan 2004 02:28:46 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <000401c3da03$17c59e50$da0d000a@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 Importance: Normal In-Reply-To: <001001c3d8f2$d09644a0$7907c289@pcluu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-GCMulti: 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.6 required=5.0 tests=SUBJ_ALL_CAPS 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 Nary, I don't think the text suggest that the session ID is just for ONE flow. It is quite possible that ONE signaling application could own multiple flows. Cheers Cheng > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > Behalf Of Thanh Tra LUU > Sent: Monday, January 12, 2004 6:00 PM > To: nsis@ietf.org > Subject: [NSIS] SESSION_ID > > > hi all, > > In our framework, authors write "the session identifier can > be used by the NTLP to demultiplex received signaling > messages between multiple instances of the same signaling > application". > > i just want to confirm: is it right that a session-id is only > used for one flow and ONE signaling application ? > > B. regards, > > 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 Wed Jan 14 04:48:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08464 for ; Wed, 14 Jan 2004 04:48:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aghd8-0004rW-L1 for nsis-archive@odin.ietf.org; Wed, 14 Jan 2004 04:48:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E9m6w8018657 for nsis-archive@odin.ietf.org; Wed, 14 Jan 2004 04:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aghd4-0004qi-FP; Wed, 14 Jan 2004 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AghcA-0004nv-Hq for nsis@optimus.ietf.org; Wed, 14 Jan 2004 04:47: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 EAA08233 for ; Wed, 14 Jan 2004 04:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aghc7-0006C5-00 for nsis@ietf.org; Wed, 14 Jan 2004 04:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AghYQ-0005sW-00 for nsis@ietf.org; Wed, 14 Jan 2004 04:43:14 -0500 Received: from infres.enst.fr ([137.194.160.3]) by ietf-mx with esmtp (Exim 4.12) id 1AghXO-0005lN-00 for nsis@ietf.org; Wed, 14 Jan 2004 04:42:10 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id A49CB4510; Wed, 14 Jan 2004 10:20:32 +0100 (MET) Message-ID: <001901c3da7f$f75bdbc0$7907c289@pcluu> From: "Thanh Tra LUU" To: "Cheng Hong" Cc: References: <000401c3da03$17c59e50$da0d000a@Palpatine> Subject: Re: [NSIS] SESSION_ID Date: Wed, 14 Jan 2004 10:22:42 +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=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, i totally agree. so i made the question for a confirmation. session-id is used to identify one flow + one nslp-id ? (flow is data flow between 2 end hosts. of course, ip addresses can be changed ;-) ) Nary Tra, ENST, Paris. > Hi Nary, > > I don't think the text suggest that the session ID is just for ONE flow. It > is quite possible that ONE signaling application could own multiple flows. > > Cheers > > Cheng > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > > Behalf Of Thanh Tra LUU > > Sent: Monday, January 12, 2004 6:00 PM > > To: nsis@ietf.org > > Subject: [NSIS] SESSION_ID > > > > > > hi all, > > > > In our framework, authors write "the session identifier can > > be used by the NTLP to demultiplex received signaling > > messages between multiple instances of the same signaling > > application". > > > > i just want to confirm: is it right that a session-id is only > > used for one flow and ONE signaling application ? > > > > B. regards, _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 15 06:22:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28161 for ; Thu, 15 Jan 2004 06: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 1Ah5Zb-0006ZC-QA for nsis-archive@odin.ietf.org; Thu, 15 Jan 2004 06:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FBM3Ro025239 for nsis-archive@odin.ietf.org; Thu, 15 Jan 2004 06: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 1Ah5ZY-0006Y5-Hz; Thu, 15 Jan 2004 06:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5Yx-0006Wp-Ec for nsis@optimus.ietf.org; Thu, 15 Jan 2004 06:21: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 GAA28087 for ; Thu, 15 Jan 2004 06:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah5Yt-000755-00 for nsis@ietf.org; Thu, 15 Jan 2004 06:21:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah5Xu-00070n-00 for nsis@ietf.org; Thu, 15 Jan 2004 06:20:19 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Ah5Wx-0006tX-00 for nsis@ietf.org; Thu, 15 Jan 2004 06:19:19 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Jan 2004 11:18:36 -0000 Message-ID: From: "Hancock, Robert" To: "'Thanh Tra LUU'" , Cheng Hong Cc: nsis@ietf.org Subject: RE: [NSIS] SESSION_ID Date: Thu, 15 Jan 2004 11:18:31 -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.3 required=5.0 tests=AWL,SUBJ_ALL_CAPS 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: , nary, you might like to read the thread starting with http://www.ietf.org/mail-archive/working-groups/nsis/current/msg03460.html where precisely this question was (eventually) discussed. the basic point (I believe) is that session-ids are allocated by nodes in a way which (ideally) would be globally unique; since everyone knows that local allocation of globally unique ids is extremely hard, we will settle for probabilistic uniqueness and live with the consequences of that. what is (at the moment deliberately) unspecified is the set of rules which a node should follow in allocating session-ids. so the answer to your question is: "maybe; maybe not; why does it matter?" it may be we will have to specify some rules, but i don't think we should make them up just for the sake of it right now. from an engineering perspective, there are many similar considerations here to the discussions that took place in ipv6 w.g. about how tightly/loosely the flow label should be defined. (although the flow label is a completely independent entity from the session id, the questions like 'who allocates it' and 'what does it map onto' and 'how precisely should we define it' are very similar IMHO.) the end result (currently in draft-ietf-ipv6-flow-label-09.txt) is I think a good guide on how to think about the question. hope this helps, robert h. > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Wednesday, January 14, 2004 09:23 > To: Cheng Hong > Cc: nsis@ietf.org > Subject: Re: [NSIS] SESSION_ID > > > hi Cheng, > > i totally agree. so i made the question for a confirmation. > > session-id is used to identify one flow + one nslp-id ? > > (flow is data flow between 2 end hosts. of course, ip addresses can be > changed ;-) ) > > Nary Tra, > ENST, Paris. > > > Hi Nary, > > > > I don't think the text suggest that the session ID is just > for ONE flow. > It > > is quite possible that ONE signaling application could own > multiple flows. > > > > Cheers > > > > Cheng > > > > > -----Original Message----- > > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On > > > Behalf Of Thanh Tra LUU > > > Sent: Monday, January 12, 2004 6:00 PM > > > To: nsis@ietf.org > > > Subject: [NSIS] SESSION_ID > > > > > > > > > hi all, > > > > > > In our framework, authors write "the session identifier can > > > be used by the NTLP to demultiplex received signaling > > > messages between multiple instances of the same signaling > > > application". > > > > > > i just want to confirm: is it right that a session-id is only > > > used for one flow and ONE signaling application ? > > > > > > B. regards, > > > _______________________________________________ > 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 Jan 15 08:15:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04365 for ; Thu, 15 Jan 2004 08:15: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 1Ah7L4-0005rw-8a for nsis-archive@odin.ietf.org; Thu, 15 Jan 2004 08:15:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FDFAvT022554 for nsis-archive@odin.ietf.org; Thu, 15 Jan 2004 08:15:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7Kz-0005qx-Ov; Thu, 15 Jan 2004 08:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7KO-0005n5-Hs for nsis@optimus.ietf.org; Thu, 15 Jan 2004 08:14: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 IAA04244 for ; Thu, 15 Jan 2004 08:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7KN-0007Qn-00 for nsis@ietf.org; Thu, 15 Jan 2004 08:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7Ix-0007C0-00 for nsis@ietf.org; Thu, 15 Jan 2004 08:13:00 -0500 Received: from infres.enst.fr ([137.194.160.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7HG-0006ry-00 for nsis@ietf.org; Thu, 15 Jan 2004 08:11:14 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 9801018C5; Thu, 15 Jan 2004 14:11:06 +0100 (MET) Message-ID: <007001c3db69$5a601080$7907c289@pcluu> From: "Thanh Tra LUU" To: "Hancock, Robert" , "Cheng Hong" Cc: References: Subject: Re: [NSIS] SESSION_ID Date: Thu, 15 Jan 2004 14:13:19 +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=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 hancock, > the basic point (I believe) is that session-ids are allocated by > nodes in a way which (ideally) would be globally unique; since > everyone knows that local allocation of globally unique ids is > extremely hard, we will settle for probabilistic uniqueness and live > with the consequences of that. i agree and i don't try to mention the golbally unique characteristic of Session-id in this discussion. > what is (at the moment deliberately) unspecified is the set of rules > which a node should follow in allocating session-ids. so the answer > to your question is: "maybe; maybe not; why does it matter?" > > it may be we will have to specify some rules, but i don't think we > should make them up just for the sake of it right now. > > from an engineering perspective, there are many similar considerations > here to the discussions that took place in ipv6 w.g. about how > tightly/loosely the flow label should be defined. (although the flow > label is a completely independent entity from the session id, the > questions like 'who allocates it' and 'what does it map onto' and > 'how precisely should we define it' are very similar IMHO.) the end > result (currently in draft-ietf-ipv6-flow-label-09.txt) is I think a > good guide on how to think about the question. i've had the same engineering perspective of session-id as you stated. Otherwise, nothing is impossible. For example, if i implement a NSLP daemon which is a NSLP environment to support all NSLP signaling application, it is easier for NTLP to pass NSLP payload of all NSLP types to NSLP daemon. Otherwise, i implement a NSLP_A daemon for signaling application A, NSLP_B daemon for signaling application B...in this case, NTLP must decide which daemon is selected to send NSLP payload. just some thoughts about NSLP/NTLP interface. i reread the documents and thanks for your advices. Nary Tra, ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 15 09:54:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09120 for ; Thu, 15 Jan 2004 09:54: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 1Ah8sl-00042t-2q for nsis-archive@odin.ietf.org; Thu, 15 Jan 2004 09:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FEs3a2015535 for nsis-archive@odin.ietf.org; Thu, 15 Jan 2004 09:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8sj-00042R-Sm; Thu, 15 Jan 2004 09: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 1Ah8sM-00041L-0j for nsis@optimus.ietf.org; Thu, 15 Jan 2004 09:53: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 JAA09076 for ; Thu, 15 Jan 2004 09:53:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8sI-00068b-00 for nsis@ietf.org; Thu, 15 Jan 2004 09:53:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8rN-00066i-00 for nsis@ietf.org; Thu, 15 Jan 2004 09:52:37 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8qx-00064c-00 for nsis@ietf.org; Thu, 15 Jan 2004 09:52:11 -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 i0FEqAS19705 for ; Thu, 15 Jan 2004 15:52:10 +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 i0FEq9L21542 for ; Thu, 15 Jan 2004 15:52:09 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Jan 2004 15:51:39 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC05AE@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Thu, 15 Jan 2004 15:51:54 +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=none autolearn=no version=2.60 Subject: [NSIS] TLS for datagram protocols Sender: nsis-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 of you might have noticed that e. rescorla has published a proposal of tls for datagram protocols. this would solve some problems we had with the different transport layer protocols with regard to the offered security mechanisms. although it does not solve some of our problems (not surprising) i think it is a good input and it might be helpful. the draft is available at: http://www.ietf.org/internet-drafts/draft-rescorla-dtls-00.txt btw, in this context the use of shared keys in the tls protocol might also be of interest: http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jan 19 09:11:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17358 for ; Mon, 19 Jan 2004 09:11: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 1Aia7N-0006AU-Kz for nsis-archive@odin.ietf.org; Mon, 19 Jan 2004 09:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JEB5XP023694 for nsis-archive@odin.ietf.org; Mon, 19 Jan 2004 09:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aia7J-00069J-Ms; Mon, 19 Jan 2004 09: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 1Aia6c-00068s-2p for nsis@optimus.ietf.org; Mon, 19 Jan 2004 09:10: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 JAA17332 for ; Mon, 19 Jan 2004 09:10:15 -0500 (EST) From: zinin@psg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aia6V-0006MX-00 for nsis@ietf.org; Mon, 19 Jan 2004 09:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aia4t-0006Jw-00 for nsis@ietf.org; Mon, 19 Jan 2004 09:08:31 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aia31-0006Ei-00 for nsis@ietf.org; Mon, 19 Jan 2004 09:06:35 -0500 Received: from nj7460tchun1 (h135-112-113-69.lucent.com [135.112.113.69]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with SMTP id i0JE5Ze08175 for ; Mon, 19 Jan 2004 08:05:35 -0600 (CST) Date: Mon, 19 Jan 2004 09:04:41 -0500 To: nsis@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------766011005626753" 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] Hi Sender: nsis-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: , ----------766011005626753 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Found virus WORM_BAGLE.A in file lsmcryyhv.exe The file lsmcryyhv.exe is moved to /var/log/virus/virLUCYwnJKa. This is a machine-generated message, please do not reply via email. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770. --------------------------------------------------------- ----------766011005626753 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) kthufrorhqnshgef -- Test, yep. ----------766011005626753 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) lsmcryyhv.exe is removed from here because it contains a virus. --------------------------------------------------------- ----------766011005626753-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jan 19 23:17:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28266 for ; Mon, 19 Jan 2004 23:17: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 1AinK4-00009P-E4 for nsis-archive@odin.ietf.org; Mon, 19 Jan 2004 23:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0K4H47G000573 for nsis-archive@odin.ietf.org; Mon, 19 Jan 2004 23:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinK2-00008m-HQ; Mon, 19 Jan 2004 23: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 1Aiald-000804-3z for nsis@optimus.ietf.org; Mon, 19 Jan 2004 09:52: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 JAA18809 for ; Mon, 19 Jan 2004 09:52:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aialb-0001JH-00 for nsis@ietf.org; Mon, 19 Jan 2004 09:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiakg-0001GJ-00 for nsis@ietf.org; Mon, 19 Jan 2004 09:51:43 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aiak2-00019o-00 for nsis@ietf.org; Mon, 19 Jan 2004 09:51:02 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0JEoUkA013726 for ; Mon, 19 Jan 2004 15:50:30 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0JEoRW3013721 for ; Mon, 19 Jan 2004 15:50:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0JEoQkA013720; Mon, 19 Jan 2004 15:50:27 +0100 (CET) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D7289E464D; Mon, 19 Jan 2004 15:50:25 +0100 (CET) Date: Mon, 19 Jan 2004 15:50:10 +0100 From: Martin Stiemerling To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] IETF 59 scheduling Message-ID: <2147483647.1074527410@[10.1.1.109]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 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 John, could you add DHC WG to the list of "should avoid"? Thanks in advance Martin --On Dienstag, 13. Januar 2004 14:49 Uhr +0200 john.loughney@nokia.com wrote: | Hello all, | | I have just sent in the request for the NSIS meeting slots at IETF 59. | These are the WGs that I have requested to avoid being scheduled at the | same time: | | MUST AVOID: | MIDCOM, IPv6, TSVWG, AAA, ALIAS bof | | SHOULD AVOID: | MIP4, MIPv6, MIPSHOP, SIPPING, CCAMP, TEWG, DCCP | | If there are any other WGs that should be avoided, please let me know. | | thanks, | John | | _______________________________________________ | nsis mailing list | nsis@ietf.org | https://www1.ietf.org/mailman/listinfo/nsis Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jan 20 08:26:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28181 for ; Tue, 20 Jan 2004 08:26: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 1AivtP-0003dt-1C for nsis-archive@odin.ietf.org; Tue, 20 Jan 2004 08:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KDQ6mr013990 for nsis-archive@odin.ietf.org; Tue, 20 Jan 2004 08:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AivtJ-0003az-Em; Tue, 20 Jan 2004 08: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 1Aivsb-0003WZ-2e for nsis@optimus.ietf.org; Tue, 20 Jan 2004 08:25: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 IAA28003 for ; Tue, 20 Jan 2004 08:25:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AivsZ-0006Ht-00 for nsis@ietf.org; Tue, 20 Jan 2004 08:25:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aivrb-00069a-00 for nsis@ietf.org; Tue, 20 Jan 2004 08:24:16 -0500 Received: from smtp0.libero.it ([193.70.192.33]) by ietf-mx with esmtp (Exim 4.12) id 1Aivqo-0005yB-00 for nsis@ietf.org; Tue, 20 Jan 2004 08:23:26 -0500 Received: from libero.it (193.70.192.36) by smtp0.libero.it (7.0.020-DD01) id 3F6F1CE300E6049B for nsis@ietf.org; Tue, 20 Jan 2004 14:22:54 +0100 Date: Tue, 20 Jan 2004 14:22:54 +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] (no subject) Sender: nsis-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 want to know if someone of you are using a Simulator for NSI= S. What kind of Simulator are you using? What, in particular, are you= simulating? Hoping in your answers. Best regards Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jan 20 08:28:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28286 for ; Tue, 20 Jan 2004 08:28: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 1AivvF-0003nf-RS for nsis-archive@odin.ietf.org; Tue, 20 Jan 2004 08:28:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KDS1b0014569 for nsis-archive@odin.ietf.org; Tue, 20 Jan 2004 08:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AivvF-0003mt-K1; Tue, 20 Jan 2004 08:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AivuZ-0003ls-8z for nsis@optimus.ietf.org; Tue, 20 Jan 2004 08:27: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 IAA28214 for ; Tue, 20 Jan 2004 08:27:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AivuY-0006VC-00 for nsis@ietf.org; Tue, 20 Jan 2004 08:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aivta-0006QD-00 for nsis@ietf.org; Tue, 20 Jan 2004 08:26:19 -0500 Received: from smtp3.libero.it ([193.70.192.127]) by ietf-mx with esmtp (Exim 4.12) id 1Aivse-0006Fq-00 for nsis@ietf.org; Tue, 20 Jan 2004 08:25:20 -0500 Received: from libero.it (193.70.192.36) by smtp3.libero.it (7.0.020-DD01) id 3F6F068F00E69293 for nsis@ietf.org; Tue, 20 Jan 2004 14:24:49 +0100 Date: Tue, 20 Jan 2004 14:24:48 +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] Simulations of 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, I want to know if someone of you are using a Simulator for NSI= S. What kind of Simulator are you using? What, in particular, are yo= u simulating? Hoping in your answers. Best regards Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jan 21 03:15:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11668 for ; Wed, 21 Jan 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 1AjDVx-00015F-6I for nsis-archive@odin.ietf.org; Wed, 21 Jan 2004 03:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L8F42l004153 for nsis-archive@odin.ietf.org; Wed, 21 Jan 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 1AjDVu-00014F-8c; Wed, 21 Jan 2004 03:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDVp-00013x-Oh for nsis@optimus.ietf.org; Wed, 21 Jan 2004 03:14: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 DAA11658 for ; Wed, 21 Jan 2004 03:14:56 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjDVn-0005di-00 for nsis@ietf.org; Wed, 21 Jan 2004 03:14:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjDUu-0005bt-00 for nsis@ietf.org; Wed, 21 Jan 2004 03:14:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjDUX-0005ZW-00 for nsis@ietf.org; Wed, 21 Jan 2004 03:13:37 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0L8DYY10376 for ; Wed, 21 Jan 2004 10:13:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 21 Jan 2004 10:13:34 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:13:33 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 10:13:33 +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: Wed, 21 Jan 2004 10:13:33 +0200 Message-ID: Thread-Topic: [AAA-WG]: Reminder on Internet Draft submission deadlines Thread-Index: AcPfcH6qL9GW2c8BRASAXfG7M7yAiQAhe1zw To: X-OriginalArrivalTime: 21 Jan 2004 08:13:33.0739 (UTC) FILETIME=[765EF7B0:01C3DFF6] 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] Reminder on Internet Draft submission deadlines Sender: nsis-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 Here are the ID draft deadlines: February 9, Monday - 00 Internet Draft Cut-off February 16, Monday - Internet Draft cut-off _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 22 09:42:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22565 for ; Thu, 22 Jan 2004 09:42: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 1Ajg22-0005II-U1 for nsis-archive@odin.ietf.org; Thu, 22 Jan 2004 09:42:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MEg6cn020346 for nsis-archive@odin.ietf.org; Thu, 22 Jan 2004 09:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajg1w-0005HO-V9; Thu, 22 Jan 2004 09: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 1Ajg0y-0005Dd-M8 for nsis@optimus.ietf.org; Thu, 22 Jan 2004 09:41: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 JAA22524 for ; Thu, 22 Jan 2004 09:40: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 1Ajg0w-00052A-00 for nsis@ietf.org; Thu, 22 Jan 2004 09:40:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajfzz-000506-00 for nsis@ietf.org; Thu, 22 Jan 2004 09:39:59 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjfzD-0004y9-00 for nsis@ietf.org; Thu, 22 Jan 2004 09:39:12 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0MEd9Y19366 for ; Thu, 22 Jan 2004 16:39:10 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 Jan 2004 16:39:09 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 16:39:07 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 16:39:07 +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] TLS for datagram protocols Date: Thu, 22 Jan 2004 16:39:06 +0200 Message-ID: Thread-Topic: [NSIS] TLS for datagram protocols Thread-Index: AcPbd3pnOstynqXQTgqF3d7vZVJ9SgFfeCKQ To: , X-OriginalArrivalTime: 22 Jan 2004 14:39:07.0205 (UTC) FILETIME=[7D677F50:01C3E0F5] 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 Hannes, I agree, this makes things decidedly nicer for NSIS work. =20 BTW - what is the current status of the Threats & Security Properties = doc? John > some of you might have noticed that e. rescorla has published a = proposal of > tls for datagram protocols. this would solve some problems we had with = the > different transport layer protocols with regard to the offered = security > mechanisms. although it does not solve some of our problems (not = surprising) > i think it is a good input and it might be helpful. >=20 > the draft is available at:=20 > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-00.txt >=20 > btw, in this context the use of shared keys in the tls protocol might = also > be of interest:=20 > http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt >=20 > ciao > hannes >=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 Sat Jan 24 13:47:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17453 for ; Sat, 24 Jan 2004 13: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 1AkSoA-0004lG-C7 for nsis-archive@odin.ietf.org; Sat, 24 Jan 2004 13:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OIl2Vj018293 for nsis-archive@odin.ietf.org; Sat, 24 Jan 2004 13:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkSo8-0004kM-PC; Sat, 24 Jan 2004 13:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkSni-0004kB-7f for nsis@optimus.ietf.org; Sat, 24 Jan 2004 13: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 NAA17449 for ; Sat, 24 Jan 2004 13:46:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkSng-0003ad-00 for nsis@ietf.org; Sat, 24 Jan 2004 13:46:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkSml-0003Z8-00 for nsis@ietf.org; Sat, 24 Jan 2004 13:45:35 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AkSmN-0003Xg-00 for nsis@ietf.org; Sat, 24 Jan 2004 13:45:11 -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 i0OIj5711648; Sat, 24 Jan 2004 19:45:05 +0100 (MET) Received: from verena (rel036149xrelesn1.esn.sbs.de [149.246.36.149]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i0OIj4l26482; Sat, 24 Jan 2004 19:45:04 +0100 (MET) From: "Hannes Tschofenig" To: , Date: Sat, 24 Jan 2004 19:44:56 +0100 Message-ID: <000101c3e2aa$2a234ca0$0105a8c0@verena> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 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] 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: , Content-Transfer-Encoding: quoted-printable hi nary tra,=20 a few weeks ago you pointed me to the following paper: "ISAKMP Handshake = for SSL/TLS Ibrahim Hajjeh, Ahmed Serhrouchni, Ecole Nationale Sup=E9rieure = des T=E9l=E9communications, France, Fr=E9d=E9rique Tastet, Thales = Communications, France" i additionally found another paper by the same authors: "New Key = Management Protocol for SSL/TLS" 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.=20 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.=20 ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jan 27 11:48:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12722 for ; Tue, 27 Jan 2004 11:48: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 1AlWNg-0001EF-GA for nsis-archive@odin.ietf.org; Tue, 27 Jan 2004 11:48:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RGm483004719 for nsis-archive@odin.ietf.org; Tue, 27 Jan 2004 11:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWNc-0001Ds-Sb; Tue, 27 Jan 2004 11:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWNZ-0001Dh-DK for nsis@optimus.ietf.org; Tue, 27 Jan 2004 11:47: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 LAA12714 for ; Tue, 27 Jan 2004 11:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWNY-0005kk-00 for nsis@ietf.org; Tue, 27 Jan 2004 11:47:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWMV-0005gn-00 for nsis@ietf.org; Tue, 27 Jan 2004 11:46:52 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AlWLy-0005bH-00 for nsis@ietf.org; Tue, 27 Jan 2004 11:46:18 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 16:45:33 -0000 Message-ID: From: "Hancock, Robert" To: "Nsis (E-mail)" Date: Tue, 27 Jan 2004 16:45:30 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" 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,LINES_OF_YELLING autolearn=no version=2.60 Subject: [NSIS] GIMPS connection mode and intermediaries Sender: nsis-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, This is the first of two mails which proposes the elimination of some options in the GIMPS (proposed solution for NTLP) design space; it's intended to find out if there is any objection to removing these options (i.e. are people happy to live with the resulting limitations on GIMPS functionality). All of the following refers to http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured UDP transport) and a connection ("C") mode (which can use connection oriented transport protocols like TCP, SCTP, DCCP and channel security mechanisms like IPsec, TLS - details TBD). C-mode is supposed to be used between adjacent peers for a given signalling application, where that signalling application needs industrial-strength transport or security services. C-mode is simple and easy where there is no need to do anything to the signalling messages between the NSLP peers; you just use the "raw" C-mode encapsulation defined in 5.3.2 of the draft. However, there are some cases where "intermediaries" between the NSLP peers want to do something to the messages, and there the situation gets much more messy. A description of how messy it gets is given in the slides from Minneapolis (start at http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm) and one possible solution is outlined in section 5.3.3 of the draft. We'd like to head towards an alternative solution, namely banning intermediaries in C-mode altogether. WHY DID WE EVER WANT THEM? The concept of intermediary functionality seems quite general, but in practice there have IIRC only ever been two concrete applications: a) RMD-like functions in the QoS-NSLP (you want C-mode between the edge nodes of a network, but you want interior nodes to access the signalling messages to update information about resource availability by looking at per-flow messages). This was partly in the background in the wg -00 draft (and several previous individual submissions). b) Signalling through a NAT which doesn't support the NSLP in question (the NAT wants to modify the addressing information which defines what flow is being signalled for, but doesn't want to modify or even understand any of the other information; see further discussion in section 5.3 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts and 4.5, 4.6 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt and to a lesser extent http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-migration-00.txt) WHAT COULD WE DO INSTEAD? (a) Our sources in the QoS-NSLP activity suggest that the favoured approach is now to use separate sessions for the direct edge-edge signalling and edge-interior-edge signalling. The first would be simple C-mode and the second in D-mode. The edge nodes would have to correlate the two (but this is true in any aggregation-like scenario). ==> we don't need to worry about (a) any more. (b) For the NAT case, rather than translating the content of C-mode messages as they go backwards and forwards through the NAT, we should require that the GIMPS instances in the NSLP peers discover during initial message exchanges that a NAT is present and what it will do to packet headers; GIMPS then includes the pre- and post-translation flow-ids in C-mode messages, invisibly for the NAT. Host A ---- NSLP ------- NAT ------- NSLP ----- Host B NTLP NTLP NE1 NE2 C mode messages from NE1 to NE2 would say, at the GIMPS level, "this is a message about a flow which I see as being defined by flow-id-1 but you see as being about flow-id-2". This approach was mentioned in the past at various meetings and is also hinted at in the NATFW drafts, but has not been intensively discussed. [Note: for the purpose of this discussion, it doesn't really matter if the NAT is GIMPS aware or not. Either way, we are saying that once GIMPS discovery is complete and C-mode is being used, the NAT has nothing to do with the payloads of signalling messages.] [We do need to do more thinking about how GIMPS works out how the NAT is there and what it is doing, but that seems unavoidable in any approach and also seems soluble.] ==> if we go this way, we don't need to care about (b) either ==> overall we can allow ourselves to restrict the required GIMPS functionality to the 'no intermediaries' case. Comments welcome, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jan 27 12:30:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15267 for ; Tue, 27 Jan 2004 12: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 1AlX2K-00042x-86 for nsis-archive@odin.ietf.org; Tue, 27 Jan 2004 12:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RHU4TG015535 for nsis-archive@odin.ietf.org; Tue, 27 Jan 2004 12:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlX2J-00042Q-PL; Tue, 27 Jan 2004 12: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 1AlX1P-0003vq-TR for nsis@optimus.ietf.org; Tue, 27 Jan 2004 12:29: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 MAA15042 for ; Tue, 27 Jan 2004 12:29:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlX1O-0001RW-00 for nsis@ietf.org; Tue, 27 Jan 2004 12:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWzn-00018B-00 for nsis@ietf.org; Tue, 27 Jan 2004 12:27:28 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AlWyR-0000sZ-00 for nsis@ietf.org; Tue, 27 Jan 2004 12:26:03 -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 i0RHOGCi020513; Tue, 27 Jan 2004 18:24:16 +0100 (MET) Message-ID: <004701c3e4fa$64f28c40$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , "Nsis \(E-mail\)" References: Subject: Re: [NSIS] GIMPS connection mode and intermediaries Date: Tue, 27 Jan 2004 18:24:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert Please note that the concept of intermediary functionality is also needed in all scenarios that use the RSVP aggregation concept, where edges (i.e., Aggregators/Deaggregators) and interior (intermediate) nodes are used. In particular the interior nodes must not process the E2E RSVP messages. Thus these interior nodes have to be bypassed. Therefore, in addition to the binding functionality we also need to have something similar to the RSVP_E2E_IGNORE (RFC3175) functionality. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "Nsis (E-mail)" Sent: Tuesday, January 27, 2004 5:45 PM Subject: [NSIS] GIMPS connection mode and intermediaries > dear all, > > This is the first of two mails which proposes the elimination > of some options in the GIMPS (proposed solution for NTLP) design > space; it's intended to find out if there is any objection to > removing these options (i.e. are people happy to live with the > resulting limitations on GIMPS functionality). > > All of the following refers to > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt > > BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured > UDP transport) and a connection ("C") mode (which can use connection > oriented transport protocols like TCP, SCTP, DCCP and channel > security mechanisms like IPsec, TLS - details TBD). C-mode is > supposed to be used between adjacent peers for a given signalling > application, where that signalling application needs industrial-strength > transport or security services. > > C-mode is simple and easy where there is no need to do anything > to the signalling messages between the NSLP peers; you just use > the "raw" C-mode encapsulation defined in 5.3.2 of the draft. However, > there are some cases where "intermediaries" between the NSLP peers want > to do something to the messages, and there the situation gets > much more messy. A description of how messy it gets is given in > the slides from Minneapolis (start at > http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm) > and one possible solution is outlined in section 5.3.3 of the draft. > > We'd like to head towards an alternative solution, namely banning > intermediaries in C-mode altogether. > > WHY DID WE EVER WANT THEM? The concept of intermediary functionality > seems quite general, but in practice there have IIRC only ever > been two concrete applications: > > a) RMD-like functions in the QoS-NSLP (you want C-mode between the > edge nodes of a network, but you want interior nodes to access > the signalling messages to update information about resource > availability by looking at per-flow messages). This was partly > in the background in the wg -00 draft (and several previous > individual submissions). > > b) Signalling through a NAT which doesn't support the NSLP in > question (the NAT wants to modify the addressing information which > defines what flow is being signalled for, but doesn't want to > modify or even understand any of the other information; see > further discussion in section 5.3 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts > and 4.5, 4.6 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt > and to a lesser extent > http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-migration-00.txt) > > WHAT COULD WE DO INSTEAD? > > (a) Our sources in the QoS-NSLP activity suggest that the favoured > approach is now to use separate sessions for the direct edge-edge > signalling and edge-interior-edge signalling. The first would be > simple C-mode and the second in D-mode. The edge nodes would have > to correlate the two (but this is true in any aggregation-like > scenario). > ==> we don't need to worry about (a) any more. > > (b) For the NAT case, rather than translating the content of C-mode > messages as they go backwards and forwards through the NAT, we > should require that the GIMPS instances in the NSLP peers discover > during initial message exchanges that a NAT is present and what > it will do to packet headers; GIMPS then includes the pre- and > post-translation flow-ids in C-mode messages, invisibly for the NAT. > > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > NTLP NTLP > NE1 NE2 > > C mode messages from NE1 to NE2 would say, at the GIMPS level, "this > is a message about a flow which I see as being defined by flow-id-1 > but you see as being about flow-id-2". This approach was mentioned > in the past at various meetings and is also hinted at in the NATFW > drafts, but has not been intensively discussed. > [Note: for the purpose of this discussion, it doesn't really matter > if the NAT is GIMPS aware or not. Either way, we are saying that > once GIMPS discovery is complete and C-mode is being used, the NAT > has nothing to do with the payloads of signalling messages.] > > [We do need to do more thinking about how GIMPS works out how the > NAT is there and what it is doing, but that seems unavoidable in > any approach and also seems soluble.] > > ==> if we go this way, we don't need to care about (b) either > > ==> overall we can allow ourselves to restrict the required GIMPS > functionality to the 'no intermediaries' case. > > Comments welcome, > > robert h. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jan 28 03:34:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20760 for ; Wed, 28 Jan 2004 03:34: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 1All98-00029t-AC for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 03:34:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S8Y23p008285 for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 03: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 1All97-00029U-HJ; Wed, 28 Jan 2004 03: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 1All8U-00025U-Kr for nsis@optimus.ietf.org; Wed, 28 Jan 2004 03:33:22 -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 DAA20745 for ; Wed, 28 Jan 2004 03:33:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1All8S-0000vw-00 for nsis@ietf.org; Wed, 28 Jan 2004 03:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1All7X-0000sj-00 for nsis@ietf.org; Wed, 28 Jan 2004 03:32:24 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1All7F-0000oz-00 for nsis@ietf.org; Wed, 28 Jan 2004 03:32:05 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 28 Jan 2004 09:30:20 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jan 2004 09:30:19 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB79C@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Wed, 28 Jan 2004 09:30:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" 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.3 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, |=3D=3D> overall we can allow ourselves to restrict the required GIMPS |functionality to the 'no intermediaries' case [RG: for "C" mode"]. Yes, that's a reasonable conclusion. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jan 28 05:19:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23993 for ; Wed, 28 Jan 2004 05:19: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 1Almmo-0001Ai-Iv for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 05:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SAJ5gg004439 for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 05:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Almmk-00019M-W9; Wed, 28 Jan 2004 05:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Almm9-00015H-EO for nsis@optimus.ietf.org; Wed, 28 Jan 2004 05:18:25 -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 FAA23923 for ; Wed, 28 Jan 2004 05:18:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Almm6-0001DC-00 for nsis@ietf.org; Wed, 28 Jan 2004 05:18:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alml8-00015y-00 for nsis@ietf.org; Wed, 28 Jan 2004 05:17:23 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AlmkG-0000yc-00 for nsis@ietf.org; Wed, 28 Jan 2004 05:16:28 -0500 Received: from esealnt610.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 i0SAGTYG018598; Wed, 28 Jan 2004 11:16:29 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 11:16:32 +0100 Message-ID: From: =?windows-1252?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hancock, Robert" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Wed, 28 Jan 2004 11:19:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" 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 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert, I think in case of a) it is not an issue. We are considering to use two kind of signaling in a stateless domain: edge-to-edge, probably in 'C' mode, and intradomain signaling in 'D' mode. I think the first one is not needed to intercept. In connection with intermediaries, my question is if GIMPS supports a routing alert functions with which a QSpec can be reached fast, without going through all protocol stacks. (Thinking of first of all of our RMD-like NTLP stateless operation.) Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hancock, Robert > Sent: Tuesday, January 27, 2004 5:46 PM > To: Nsis (E-mail) > Subject: [NSIS] GIMPS connection mode and intermediaries > > > dear all, > > This is the first of two mails which proposes the elimination > of some options in the GIMPS (proposed solution for NTLP) design > space; it's intended to find out if there is any objection to > removing these options (i.e. are people happy to live with the > resulting limitations on GIMPS functionality). > > All of the following refers to > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt > > BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured > UDP transport) and a connection ("C") mode (which can use connection > oriented transport protocols like TCP, SCTP, DCCP and channel > security mechanisms like IPsec, TLS - details TBD). C-mode is > supposed to be used between adjacent peers for a given signalling > application, where that signalling application needs > industrial-strength > transport or security services. > > C-mode is simple and easy where there is no need to do anything > to the signalling messages between the NSLP peers; you just use > the "raw" C-mode encapsulation defined in 5.3.2 of the draft. > However, > there are some cases where "intermediaries" between the NSLP > peers want > to do something to the messages, and there the situation gets > much more messy. A description of how messy it gets is given in > the slides from Minneapolis (start at > http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm) > and one possible solution is outlined in section 5.3.3 of the draft. > > We'd like to head towards an alternative solution, namely banning > intermediaries in C-mode altogether. > > WHY DID WE EVER WANT THEM? The concept of intermediary functionality > seems quite general, but in practice there have IIRC only ever > been two concrete applications: > > a) RMD-like functions in the QoS-NSLP (you want C-mode between the > edge nodes of a network, but you want interior nodes to access > the signalling messages to update information about resource > availability by looking at per-flow messages). This was partly > in the background in the wg -00 draft (and several previous > individual submissions). > > b) Signalling through a NAT which doesn't support the NSLP in > question (the NAT wants to modify the addressing information which > defines what flow is being signalled for, but doesn't want to > modify or even understand any of the other information; see > further discussion in section 5.3 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts > and 4.5, 4.6 of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt > and to a lesser extent > http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw -migration-00.txt) WHAT COULD WE DO INSTEAD? (a) Our sources in the QoS-NSLP activity suggest that the favoured approach is now to use separate sessions for the direct edge-edge signalling and edge-interior-edge signalling. The first would be simple C-mode and the second in D-mode. The edge nodes would have to correlate the two (but this is true in any aggregation-like scenario). ==> we don't need to worry about (a) any more. (b) For the NAT case, rather than translating the content of C-mode messages as they go backwards and forwards through the NAT, we should require that the GIMPS instances in the NSLP peers discover during initial message exchanges that a NAT is present and what it will do to packet headers; GIMPS then includes the pre- and post-translation flow-ids in C-mode messages, invisibly for the NAT. Host A ---- NSLP ------- NAT ------- NSLP ----- Host B NTLP NTLP NE1 NE2 C mode messages from NE1 to NE2 would say, at the GIMPS level, "this is a message about a flow which I see as being defined by flow-id-1 but you see as being about flow-id-2". This approach was mentioned in the past at various meetings and is also hinted at in the NATFW drafts, but has not been intensively discussed. [Note: for the purpose of this discussion, it doesn't really matter if the NAT is GIMPS aware or not. Either way, we are saying that once GIMPS discovery is complete and C-mode is being used, the NAT has nothing to do with the payloads of signalling messages.] [We do need to do more thinking about how GIMPS works out how the NAT is there and what it is doing, but that seems unavoidable in any approach and also seems soluble.] ==> if we go this way, we don't need to care about (b) either ==> overall we can allow ourselves to restrict the required GIMPS functionality to the 'no intermediaries' case. Comments welcome, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jan 28 05:45:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24614 for ; Wed, 28 Jan 2004 05:45: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 1AlnBu-0002xk-T4 for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 05:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SAj2Mn011351 for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 05:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnBu-0002wy-6z; Wed, 28 Jan 2004 05: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 1AlnBJ-0002w1-6g for nsis@optimus.ietf.org; Wed, 28 Jan 2004 05:44:25 -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 FAA24570 for ; Wed, 28 Jan 2004 05:44:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnBF-000342-00 for nsis@ietf.org; Wed, 28 Jan 2004 05:44:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnAK-0002zI-00 for nsis@ietf.org; Wed, 28 Jan 2004 05:43:25 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Aln9Q-0002pT-00 for nsis@ietf.org; Wed, 28 Jan 2004 05:42:28 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 10:41:53 -0000 Message-ID: From: "Hancock, Robert" To: =?windows-1252?Q?=27Attila_B=E1der_=28IJ/ETH=29=27?= , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Wed, 28 Jan 2004 10:41:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1252" 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 hi attila (also responding to georgios), > -----Original Message----- > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > Sent: Wednesday, January 28, 2004 10:20 > To: Hancock, Robert; Nsis (E-mail) > Subject: RE: [NSIS] GIMPS connection mode and intermediaries >=20 >=20 > Hi Robert, >=20 > I think in case of a) it is not an issue. We are considering=20 > to use two kind of signaling in a stateless domain:=20 > edge-to-edge, probably in 'C' mode, and intradomain signaling=20 > in 'D' mode. I think the first one is not needed to intercept. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is the critical point. 3175 does this (prevention of the interior nodes seeing these messages) with a special protocol number (as georgios mentions); the current assumption in the -00 draft is that aggregation levels can be encoded into the RAO field with the same effect, although of course=20 that is still open to discussion. in any case, the functionality is clearly needed. >=20 > In connection with intermediaries, my question is if GIMPS=20 > supports a routing alert functions with which a QSpec can be=20 > reached fast, without going through all protocol stacks.=20 > (Thinking of first of all of our RMD-like NTLP stateless operation.) once the RAO has been spotted at the IP layer, our assumption/ hope is that the rest of GIMPS D-mode processing will be=20 fairly simple (e.g. strip of UDP, demultiplex on signalling application ID and flow/session ID matching). time will tell if we are able to hold to this promise, of course... cheers, robert h. >=20 > Best regards, Attila >=20 > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > Hancock, Robert > > Sent: Tuesday, January 27, 2004 5:46 PM > > To: Nsis (E-mail) > > Subject: [NSIS] GIMPS connection mode and intermediaries > >=20 > >=20 > > dear all, > >=20 > > This is the first of two mails which proposes the elimination > > of some options in the GIMPS (proposed solution for NTLP) design > > space; it's intended to find out if there is any objection to > > removing these options (i.e. are people happy to live with the > > resulting limitations on GIMPS functionality). > >=20 > > All of the following refers to > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt > >=20 > > BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured=20 > > UDP transport) and a connection ("C") mode (which can use = connection > > oriented transport protocols like TCP, SCTP, DCCP and channel > > security mechanisms like IPsec, TLS - details TBD). C-mode is=20 > > supposed to be used between adjacent peers for a given signalling > > application, where that signalling application needs=20 > > industrial-strength=20 > > transport or security services. > >=20 > > C-mode is simple and easy where there is no need to do anything > > to the signalling messages between the NSLP peers; you just use > > the "raw" C-mode encapsulation defined in 5.3.2 of the draft.=20 > > However,=20 > > there are some cases where "intermediaries" between the NSLP=20 > > peers want > > to do something to the messages, and there the situation gets=20 > > much more messy. A description of how messy it gets is given in > > the slides from Minneapolis (start at > > http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm) > > and one possible solution is outlined in section 5.3.3 of the = draft. > >=20 > > We'd like to head towards an alternative solution, namely banning > > intermediaries in C-mode altogether. > >=20 > > WHY DID WE EVER WANT THEM? The concept of intermediary = functionality > > seems quite general, but in practice there have IIRC only ever > > been two concrete applications: > >=20 > > a) RMD-like functions in the QoS-NSLP (you want C-mode between the > > edge nodes of a network, but you want interior nodes to access > > the signalling messages to update information about resource > > availability by looking at per-flow messages). This was partly > > in the background in the wg -00 draft (and several previous=20 > > individual submissions). > >=20 > > b) Signalling through a NAT which doesn't support the NSLP in > > question (the NAT wants to modify the addressing information which=20 > > defines what flow is being signalled for, but doesn't want to > > modify or even understand any of the other information; see > > further discussion in section 5.3 of > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts=20 > > and 4.5, 4.6 of=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt > > and to a lesser extent > > http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw > -migration-00.txt) >=20 > WHAT COULD WE DO INSTEAD?=20 >=20 > (a) Our sources in the QoS-NSLP activity suggest that the favoured > approach is now to use separate sessions for the direct edge-edge=20 > signalling and edge-interior-edge signalling. The first would be > simple C-mode and the second in D-mode. The edge nodes would have > to correlate the two (but this is true in any aggregation-like > scenario). > =3D=3D> we don't need to worry about (a) any more. >=20 > (b) For the NAT case, rather than translating the content of C-mode > messages as they go backwards and forwards through the NAT, we=20 > should require that the GIMPS instances in the NSLP peers discover > during initial message exchanges that a NAT is present and what > it will do to packet headers; GIMPS then includes the pre- and > post-translation flow-ids in C-mode messages, invisibly for the NAT. >=20 > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > NTLP NTLP > NE1 NE2 >=20 > C mode messages from NE1 to NE2 would say, at the GIMPS level, "this > is a message about a flow which I see as being defined by flow-id-1 > but you see as being about flow-id-2". This approach was mentioned=20 > in the past at various meetings and is also hinted at in the NATFW=20 > drafts, but has not been intensively discussed. > [Note: for the purpose of this discussion, it doesn't really matter > if the NAT is GIMPS aware or not. Either way, we are saying that=20 > once GIMPS discovery is complete and C-mode is being used, the NAT=20 > has nothing to do with the payloads of signalling messages.] >=20 > [We do need to do more thinking about how GIMPS works out how the > NAT is there and what it is doing, but that seems unavoidable in=20 > any approach and also seems soluble.] >=20 > =3D=3D> if we go this way, we don't need to care about (b) either >=20 > =3D=3D> overall we can allow ourselves to restrict the required GIMPS > functionality to the 'no intermediaries' case. >=20 > Comments welcome, >=20 > robert h. >=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 Jan 28 06:16:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25561 for ; Wed, 28 Jan 2004 06: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 1Alnfx-0004uD-T0 for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 06:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SBG5a5018851 for nsis-archive@odin.ietf.org; Wed, 28 Jan 2004 06: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 1Alnfs-0004t6-J6; Wed, 28 Jan 2004 06: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 1AlnfM-0004ox-PI for nsis@optimus.ietf.org; Wed, 28 Jan 2004 06:15: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 GAA25501 for ; Wed, 28 Jan 2004 06:15:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnfI-0005Ot-00 for nsis@ietf.org; Wed, 28 Jan 2004 06:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlneQ-0005Ky-00 for nsis@ietf.org; Wed, 28 Jan 2004 06:14:31 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1Alnds-0005Gh-00 for nsis@ietf.org; Wed, 28 Jan 2004 06:13:56 -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 i0SBDqCi023960; Wed, 28 Jan 2004 12:13:52 +0100 (MET) Message-ID: <00df01c3e58f$d0c8cb10$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , "=?Windows-1252?Q?'Attila_B=E1der_\=28IJ/ETH\=29_'?=" , "Nsis \(E-mail\)" References: Subject: Re: [NSIS] GIMPS connection mode and intermediaries Date: Wed, 28 Jan 2004 12:13:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 i0SBDqCi023960 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 Robert Thank you very much! In that case I agree with your proposal. Best Regards, Georgios ----- Original Message -----=20 From: "Hancock, Robert" To: "'Attila B=E1der (IJ/ETH) '" ; "Nsis (E-ma= il)" Sent: Wednesday, January 28, 2004 11:41 AM Subject: RE: [NSIS] GIMPS connection mode and intermediaries > hi attila (also responding to georgios), > > > -----Original Message----- > > From: Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] > > Sent: Wednesday, January 28, 2004 10:20 > > To: Hancock, Robert; Nsis (E-mail) > > Subject: RE: [NSIS] GIMPS connection mode and intermediaries > > > > > > Hi Robert, > > > > I think in case of a) it is not an issue. We are considering > > to use two kind of signaling in a stateless domain: > > edge-to-edge, probably in 'C' mode, and intradomain signaling > > in 'D' mode. I think the first one is not needed to intercept. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > this is the critical point. 3175 does this (prevention of the > interior nodes seeing these messages) with a special > protocol number (as georgios mentions); the current assumption > in the -00 draft is that aggregation levels can be encoded > into the RAO field with the same effect, although of course > that is still open to discussion. in any case, the functionality > is clearly needed. > > > > > In connection with intermediaries, my question is if GIMPS > > supports a routing alert functions with which a QSpec can be > > reached fast, without going through all protocol stacks. > > (Thinking of first of all of our RMD-like NTLP stateless operation.) > > once the RAO has been spotted at the IP layer, our assumption/ > hope is that the rest of GIMPS D-mode processing will be > fairly simple (e.g. strip of UDP, demultiplex on signalling > application ID and flow/session ID matching). time will tell > if we are able to hold to this promise, of course... > > cheers, > > robert h. > > > > > Best regards, Attila > > > > > -----Original Message----- > > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > > Hancock, Robert > > > Sent: Tuesday, January 27, 2004 5:46 PM > > > To: Nsis (E-mail) > > > Subject: [NSIS] GIMPS connection mode and intermediaries > > > > > > > > > dear all, > > > > > > This is the first of two mails which proposes the elimination > > > of some options in the GIMPS (proposed solution for NTLP) design > > > space; it's intended to find out if there is any objection to > > > removing these options (i.e. are people happy to live with the > > > resulting limitations on GIMPS functionality). > > > > > > All of the following refers to > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt > > > > > > BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured > > > UDP transport) and a connection ("C") mode (which can use connectio= n > > > oriented transport protocols like TCP, SCTP, DCCP and channel > > > security mechanisms like IPsec, TLS - details TBD). C-mode is > > > supposed to be used between adjacent peers for a given signalling > > > application, where that signalling application needs > > > industrial-strength > > > transport or security services. > > > > > > C-mode is simple and easy where there is no need to do anything > > > to the signalling messages between the NSLP peers; you just use > > > the "raw" C-mode encapsulation defined in 5.3.2 of the draft. > > > However, > > > there are some cases where "intermediaries" between the NSLP > > > peers want > > > to do something to the messages, and there the situation gets > > > much more messy. A description of how messy it gets is given in > > > the slides from Minneapolis (start at > > > http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm) > > > and one possible solution is outlined in section 5.3.3 of the draft. > > > > > > We'd like to head towards an alternative solution, namely banning > > > intermediaries in C-mode altogether. > > > > > > WHY DID WE EVER WANT THEM? The concept of intermediary functionalit= y > > > seems quite general, but in practice there have IIRC only ever > > > been two concrete applications: > > > > > > a) RMD-like functions in the QoS-NSLP (you want C-mode between the > > > edge nodes of a network, but you want interior nodes to access > > > the signalling messages to update information about resource > > > availability by looking at per-flow messages). This was partly > > > in the background in the wg -00 draft (and several previous > > > individual submissions). > > > > > > b) Signalling through a NAT which doesn't support the NSLP in > > > question (the NAT wants to modify the addressing information which > > > defines what flow is being signalled for, but doesn't want to > > > modify or even understand any of the other information; see > > > further discussion in section 5.3 of > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts > > > and 4.5, 4.6 of > > > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt > > > and to a lesser extent > > > http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw > > -migration-00.txt) > > > > WHAT COULD WE DO INSTEAD? > > > > (a) Our sources in the QoS-NSLP activity suggest that the favoured > > approach is now to use separate sessions for the direct edge-edge > > signalling and edge-interior-edge signalling. The first would be > > simple C-mode and the second in D-mode. The edge nodes would have > > to correlate the two (but this is true in any aggregation-like > > scenario). > > =3D=3D> we don't need to worry about (a) any more. > > > > (b) For the NAT case, rather than translating the content of C-mode > > messages as they go backwards and forwards through the NAT, we > > should require that the GIMPS instances in the NSLP peers discover > > during initial message exchanges that a NAT is present and what > > it will do to packet headers; GIMPS then includes the pre- and > > post-translation flow-ids in C-mode messages, invisibly for the NAT. > > > > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > > NTLP NTLP > > NE1 NE2 > > > > C mode messages from NE1 to NE2 would say, at the GIMPS level, "this > > is a message about a flow which I see as being defined by flow-id-1 > > but you see as being about flow-id-2". This approach was mentioned > > in the past at various meetings and is also hinted at in the NATFW > > drafts, but has not been intensively discussed. > > [Note: for the purpose of this discussion, it doesn't really matter > > if the NAT is GIMPS aware or not. Either way, we are saying that > > once GIMPS discovery is complete and C-mode is being used, the NAT > > has nothing to do with the payloads of signalling messages.] > > > > [We do need to do more thinking about how GIMPS works out how the > > NAT is there and what it is doing, but that seems unavoidable in > > any approach and also seems soluble.] > > > > =3D=3D> if we go this way, we don't need to care about (b) either > > > > =3D=3D> overall we can allow ourselves to restrict the required GIMPS > > functionality to the 'no intermediaries' case. > > > > Comments welcome, > > > > robert h. > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 03:44:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08316 for ; Thu, 29 Jan 2004 03:44: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 1Am7mN-0001xx-46 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 03:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T8i3s2007556 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 03:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7mL-0001xl-Ng; Thu, 29 Jan 2004 03: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 1Am7lT-0001u3-Tq for nsis@optimus.ietf.org; Thu, 29 Jan 2004 03:43: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 DAA08266 for ; Thu, 29 Jan 2004 03:43:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am7lR-0005Em-00 for nsis@ietf.org; Thu, 29 Jan 2004 03:43:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am7kV-000585-00 for nsis@ietf.org; Thu, 29 Jan 2004 03:42:07 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Am7jZ-0004wp-00 for nsis@ietf.org; Thu, 29 Jan 2004 03:41:09 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0T8edN8062915 for ; Thu, 29 Jan 2004 09:40:39 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0T8eYKe062912 for ; Thu, 29 Jan 2004 09:40:34 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0T8eXN8062911; Thu, 29 Jan 2004 09:40:34 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 374A2FA52F; Thu, 29 Jan 2004 09:40:33 +0100 (CET) Date: Thu, 29 Jan 2004 09:40:33 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "Nsis (E-mail)" Subject: Re: [NSIS] GIMPS connection mode and intermediaries Message-ID: <90854792.1075369233@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 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 Robert, The NAT case is flawed and there is a third case for intermediaries. See inline. [...] Case c) is the use of intermediaries due to scalability problems of the C-mode. This specifically holds for NAT FW NSLP, but also for other sparsly deployed NSLPs. In the NAT/firewall NSLP case with C-mode we would realistically end-up with one connection per flow. This is because in most realistic cases at the beginning and the end of a path some NATs and firewalls are sitting, but non in the middle of the Internet. So assuming that each flow originating at one place is very diverse in which direction it goes, there is basically a C-mode NTLP connection per-flow. Plain GIMPS nodes would help with this problem. > (b) For the NAT case, rather than translating the content of C-mode > messages as they go backwards and forwards through the NAT, we > should require that the GIMPS instances in the NSLP peers discover > during initial message exchanges that a NAT is present and what > it will do to packet headers; GIMPS then includes the pre- and > post-translation flow-ids in C-mode messages, invisibly for the NAT. > > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > NTLP NTLP > NE1 NE2 > > C mode messages from NE1 to NE2 would say, at the GIMPS level, "this > is a message about a flow which I see as being defined by flow-id-1 > but you see as being about flow-id-2". This approach was mentioned > in the past at various meetings and is also hinted at in the NATFW > drafts, but has not been intensively discussed. > [Note: for the purpose of this discussion, it doesn't really matter > if the NAT is GIMPS aware or not. Either way, we are saying that > once GIMPS discovery is complete and C-mode is being used, the NAT > has nothing to do with the payloads of signalling messages.] > this does not work. If the NAT is NTLP unaware it will naturally change the IP address and potentially even the port numbers of the transport protocol used between the NTLP peers. So it allows to get NTLP signaling through. The other end would most likely be able to detect that there is a NAT, if NTLP has information about it last peer included. But the change of the flow-id (data stream we are signalling for) is unpredictable. And it does matter whether the NAT is GIMPS aware or not. I see 2 solutions 1) we forget that GIMPS is carrying flow-information. This implies that NAT must be NSLP away and you can avoid the intermediaries. 2) we keep NAT intermediaries (probably when the functionality is focused to NATs only, this might help to get a less complex solution, because you do not need to think about general intermediaries. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 04:19:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09293 for ; Thu, 29 Jan 2004 04:19: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 1Am8KG-0004dW-4y for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 04:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T9J3Ok017821 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 04:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am8KE-0004cs-5F; Thu, 29 Jan 2004 04:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am8JP-0004bp-LU for nsis@optimus.ietf.org; Thu, 29 Jan 2004 04:18: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 EAA09267 for ; Thu, 29 Jan 2004 04:18:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am8JM-0000zQ-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:18:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am8IS-0000tT-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:17:13 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1Am8IE-0000o0-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:16:58 -0500 Received: from ns.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F0BC21F514 for ; Thu, 29 Jan 2004 18:16:26 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Thu, 29 Jan 2004 18:16:26 +0900 (KST) Received: from LocalHost (unknown [75.2.47.28]) by ns.sait.samsung.co.kr (Postfix) with SMTP id:CF2EA1F413 for ; Thu, 29 Jan 2004 18:16:25 +0900 (KST) From: "Sung Hyuck Lee" To: "Nsis (E-mail)" Date: Thu, 29 Jan 2004 18:16:25 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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) Importance: Normal In-Reply-To: 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=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [NSIS] Mobility and Internet Signaling Protocols Sender: nsis-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 DQpEZWFyIGFsbCwNCg0KV2Ugc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZHJhZnQgY29uY2Vybmlu ZyBtb2JpbGl0eS1yZWxhdGVkIGlzc3VlcyBpbiBOU0lTOg0KDQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYW55Zm9sa3Mtc2lnbmFsaW5nLXByb3RvY29sLW1vYmls aXR5LTAwLnR4dA0KDQpUaGUgZ29hbHMgb2YgdGhpcyBkcmFmdCBhcmUgdG8gYW5hbHl6ZSB0aGUg ZWZmZWN0cyBvZiBtb2JpbGl0eSBpbiBOVExQL05TTFAgDQphbmQgZ2l2ZSBzb21lIGd1aWRlbGlu ZXMgYWJvdXQgaG93IHRvIHRhY2tsZSAgdmFyaW91cyBpc3N1ZXMgY2F1c2VkIGJ5IA0KbW9iaWxp dHkgKGFzIHdlbGwgYXMgZ2VuZXJpYyByb3V0ZSBjaGFuZ2UpIGluIHRoZSBJbnRlcm5ldCBzaWdu YWxpbmcgcHJvdG9jb2xzLiAgDQoNClRoaXMgZHJhZnQgZGlzY3Vzc2VkIHRoZSBmb2xsb3dpbmcg aXNzdWVzIGluIE5UTFAvTlNMUCBsYXllcnM6DQoNCiAgIC0gYW5hbHlzaXMgb2YgdmFyaW91cyBt b2JpbGl0eSBzY2VuYXJpb3MgaW4gTlNJUyBzaWduYWxpbmcgYW5kIHN0YXRlbWVudA0KICAgICBw cm9ibGVtcw0KICAgLSBDcm9zc292ZXIgbm9kZSBkaXNjb3ZlcnkgYW5kIFBhdGggdXBkYXRlIGNh dXNlZCBieSBtb2JpbGl0eSBhbmQgDQogICAgIHJvdXRlIGNoYW5nZQ0KICAgLSBEZWFkIHBlZXIg ZGlzY292ZXJ5DQogICAtIENhc2UgZXhhbXBsZXMgb2YgTlNJUyBzaWduYWxpbmcgYWNjb3JkaW5n IHRvIGhhbmRvdmVyIGNhc2VzDQogICAtIEludGVyYWN0aW9uIHdpdGggbW9iaWxpdHkgc2lnbmFs aW5ncyAoZS5nLiwgSE1JUHY2LCBGTUlQdjYsIENBUkQsIGFuZCBDVFApDQogICAtIFVuaS0gYW5k IGJpLWRpcmVjdGlvbmFsIHN0YXRlIGVzdGFibGlzaG1lbnQsIFN0YXRlIE1hbmFnZW1lbnQsIGFu ZA0KICAgICBTdGF0ZSBlc3RhYmxpc2htZW50IGluIG5ldHdvcmsgbW9iaWxpdHkgYXMgYWRkaXRp b25hbCBpc3N1ZXMNCiAgIC0gU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdmFyaW91cyBzY2Vu YXJpb3Mgc3VjaCBhcyBNTiBhcyBzZW5kZXIvcmVjZWl2ZXIsICAgICANCiAgICAgbXVsdGlob21p bmcgc2NlbmFyaW9zLCB1c2luZyBjb250ZXh0IHRyYW5zZmVyLCBwcm94eSBzY2VuYXJpbywgYW5k IEFBQS4NCg0KVGhlcmUgYXJlIGFsc28gc29tZSBpc3N1ZXMgd2hpY2ggbmVlZCB0byBiZSBkaXNj dXNzZWQgaW4gdGhlIG5leHQgdmVyc2lvbiANCg0KICAgLSBNdWx0aWhvbWluZyByZWxhdGVkIGlz c3Vlcw0KICAgLSBCb3RoIEVuZC1Ib3N0cyBhcmUgTW9iaWxlIA0KICAgLSBTcGxpdCBvZiBOU0lT IGZ1bmN0aW9uYWxpdHkNCiAgIC0gT3BlbiBxdWVzdGlvbnMgaW4gZWFjaCBzZWN0aW9uDQoNCiBB bGwgY29tbWVudHMgYXJlIHdlbGNvbWUNCg0KUmVnYXJkcywNCg0KU3VuZy1IeXVjaw0KDQoNCg0K ICANCg== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 04:26:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09513 for ; Thu, 29 Jan 2004 04:26: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 1Am8R2-00059i-2o for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 04:26:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T9Q384019812 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 04:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am8Qz-00058Z-Vl; Thu, 29 Jan 2004 04: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 1Am8QB-00053F-8B for nsis@optimus.ietf.org; Thu, 29 Jan 2004 04:25: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 EAA09484 for ; Thu, 29 Jan 2004 04:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am8Q8-0001nG-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am8PH-0001hP-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:24:16 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1Am8OL-0001c2-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:23:17 -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 i0T9MiV22558; Thu, 29 Jan 2004 10:22:54 +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 i0T9MUw19929; Thu, 29 Jan 2004 10:22:30 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 10:21:58 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0627@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'brunner@ccrle.nec.de'" , "Hancock, Robert" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Thu, 29 Jan 2004 10:22:14 +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=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, a small clarification to avoid confusion: in the intermediary discussion there was often the question whether a nat/firewall nslp (or other nslps) could reuse existing infrastructure by utilizing NTLPs along the paths (even if they do not support the desired NSLP). this might have the advantage of reusing existing security associations and transport layer connections. the disadvantage is that you have the known problems with intermediaries (reliability), you might need additional security mechanisms between nslps (over a number of ntlp hops) and additional latency issues. figure 1 tries to describe the two options graphically: Host A NAT Box Host B NAT/FW -- NSLP X ---- QoS NSLP ------- NAT/FW NSLP ------- QoS NSLP ----- NAT/FW NSLP NTL NTLP NTLP NTLP NSLP NTLP NE1 NE2 NE3 NE4 NE5 Figure 1: Signaling message flow if we want to signal an NSLP (e.g., NAT/FW) which is sparsely distributed along the path (i.e., only a few devices are NATs/Firewalls compared to QoS NSLP - hopefully) then there are two possible cases: a) skip NSLPs which do not implement the desired NSLP (in our example the end host is interested in signaling a NAT/FW NSLP) (possible improvement to get rid of the nasty intermediaries) for figure 1 this would mean that Host A addresses the message to NE 3 (the nat box). discovery would have to skip NE 1 and NE 2 since they have nothing todo with nat/firewall signaling. b) incept and process signaling message at every intermediate node (current proposal in the gimps draft) for figure 1 this would mean that the message is addressed towards NE 1, again processed by NE 2 and finally by NE 3 which is the NAT box and so on. if you establish, for example, a tcp connection between neighboring nodes (NE 2 and NE 3) then you can certainly reuse more transport layer connections (and security associations) than in case (a) where you establish a new transport layer connection between end hosts (e.g., Host A) and NE 3. ciao hannes > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, January 29, 2004 9:41 AM > To: Hancock, Robert; Nsis (E-mail) > Subject: Re: [NSIS] GIMPS connection mode and intermediaries > > > Robert, > > The NAT case is flawed and there is a third case for > intermediaries. See > inline. > > [...] > > Case c) is the use of intermediaries due to scalability > problems of the > C-mode. This specifically holds for NAT FW NSLP, but also for > other sparsly > deployed NSLPs. > > In the NAT/firewall NSLP case with C-mode we would > realistically end-up > with one connection per flow. > This is because in most > realistic cases at > the beginning and the end of a path some NATs and firewalls > are sitting, > but non in the middle of the Internet. > So assuming that each flow > originating at one place is very diverse in which direction > it goes, there > is basically a C-mode NTLP connection per-flow. Plain GIMPS > nodes would > help with this problem. > > > (b) For the NAT case, rather than translating the content of C-mode > > messages as they go backwards and forwards through the NAT, we > > should require that the GIMPS instances in the NSLP peers discover > > during initial message exchanges that a NAT is present and what > > it will do to packet headers; GIMPS then includes the pre- and > > post-translation flow-ids in C-mode messages, invisibly for the NAT. > > > > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > > NTLP NTLP > > NE1 NE2 > > > > C mode messages from NE1 to NE2 would say, at the GIMPS level, "this > > is a message about a flow which I see as being defined by flow-id-1 > > but you see as being about flow-id-2". This approach was mentioned > > in the past at various meetings and is also hinted at in the NATFW > > drafts, but has not been intensively discussed. > > [Note: for the purpose of this discussion, it doesn't really matter > > if the NAT is GIMPS aware or not. Either way, we are saying that > > once GIMPS discovery is complete and C-mode is being used, the NAT > > has nothing to do with the payloads of signalling messages.] > > > > > this does not work. > > If the NAT is NTLP unaware it will naturally change the IP > address and > potentially even the port numbers of the transport protocol > used between > the NTLP peers. So it allows to get NTLP signaling through. > The other end > would most likely be able to detect that there is a NAT, if NTLP has > information about it last peer included. But the change of > the flow-id > (data stream we are signalling for) is unpredictable. > > And it does matter whether the NAT is GIMPS aware or not. > > I see 2 solutions > 1) we forget that GIMPS is carrying flow-information. This > implies that NAT > must be NSLP away and you can avoid the intermediaries. > > 2) we keep NAT intermediaries (probably when the > functionality is focused > to NATs only, this might help to get a less complex solution, > because you > do not need to think about general intermediaries. > > > Marcus > > _______________________________________________ > 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 Jan 29 05:01:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10958 for ; Thu, 29 Jan 2004 05:01: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 1Am8yx-00080O-Ku for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 05:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TA17gT030763 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 05:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am8yw-0007zy-IW; Thu, 29 Jan 2004 05:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am8y6-0007yL-Bs for nsis@optimus.ietf.org; Thu, 29 Jan 2004 05:00: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 FAA10946 for ; Thu, 29 Jan 2004 05:00:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am8y3-0005f1-00 for nsis@ietf.org; Thu, 29 Jan 2004 05:00:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am8xE-0005ZT-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:59:21 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Am8wQ-0005O3-00 for nsis@ietf.org; Thu, 29 Jan 2004 04:58:30 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 09:58:01 -0000 Message-ID: From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Thu, 29 Jan 2004 09:58:07 -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.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 marcus, > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, January 29, 2004 08:41 > To: Hancock, Robert; Nsis (E-mail) > Subject: Re: [NSIS] GIMPS connection mode and intermediaries > > > Robert, > > The NAT case is flawed and there is a third case for > intermediaries. See > inline. > > [...] > > Case c) is the use of intermediaries due to scalability > problems of the > C-mode. This specifically holds for NAT FW NSLP, but also for > other sparsly > deployed NSLPs. > > In the NAT/firewall NSLP case with C-mode we would > realistically end-up > with one connection per flow. This is because in most > realistic cases at > the beginning and the end of a path some NATs and firewalls > are sitting, > but non in the middle of the Internet. So assuming that each flow > originating at one place is very diverse in which direction > it goes, there > is basically a C-mode NTLP connection per-flow. i think the strictly correct statement is 'one C mode connection per pair of communicating middleboxes'. if the Internet traffic is dominated by e.g. people running kazaa behind NATting-ADSL routers I agree this would end up as one C mode/flow; N communications between two corporate sites would probably need only one C mode connection. of course, the scalability issue is one we always have to worry about. my naive instinct is that the first case will apply mainly to little NATs, and big NATs are mainly covered by the second, but the dial-access (or mobile access) cases are probably hard. in any case, the underlying question is whether the state involved in a C mode connection is much more, much less, or about the same as required to manage the NAT processing for that flow itself. do you think it could be more? > Plain GIMPS > nodes would > help with this problem. could you elaborate? > > > (b) For the NAT case, rather than translating the content of C-mode > > messages as they go backwards and forwards through the NAT, we > > should require that the GIMPS instances in the NSLP peers discover > > during initial message exchanges that a NAT is present and what > > it will do to packet headers; GIMPS then includes the pre- and > > post-translation flow-ids in C-mode messages, invisibly for the NAT. > > > > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > > NTLP NTLP > > NE1 NE2 > > > > C mode messages from NE1 to NE2 would say, at the GIMPS level, "this > > is a message about a flow which I see as being defined by flow-id-1 > > but you see as being about flow-id-2". This approach was mentioned > > in the past at various meetings and is also hinted at in the NATFW > > drafts, but has not been intensively discussed. > > [Note: for the purpose of this discussion, it doesn't really matter > > if the NAT is GIMPS aware or not. Either way, we are saying that > > once GIMPS discovery is complete and C-mode is being used, the NAT > > has nothing to do with the payloads of signalling messages.] > > > > > this does not work. > > If the NAT is NTLP unaware it will naturally change the IP > address and > potentially even the port numbers of the transport protocol > used between > the NTLP peers. true (for C and D mode, and true regardless of whether the NAT is NTLP aware or not). > So it allows to get NTLP signaling through. > The other end > would most likely be able to detect that there is a NAT, if NTLP has > information about it last peer included. probably true (certainly true in C mode; whether or not it is true in D mode depends on the source addressing used - see open issue 3 section 8.3 of the GIMPS draft and provide comments...) > But the change of > the flow-id > (data stream we are signalling for) is unpredictable. 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). *) a GIMPS aware NAT should change the flow ID in a way to be defined by the GIMPS spec, for which at the moment I see several possibilities: - use existing bindings if they apply to that flow - if there is no applicable existing binding, create one, or - if there is no applicable existing binding, return an error to the peer (this would be one of a large class of "I couldn't handle that flow ID errors") > > And it does matter whether the NAT is GIMPS aware or not. it matters to the GIMPS D mode implementation. it should not matter to the overall function split between C and D mode, and it should not matter to NSLPs. > > I see 2 solutions > 1) we forget that GIMPS is carrying flow-information. This > implies that NAT > must be NSLP away and you can avoid the intermediaries. this is one solution. but it means that every NAT must be aware of every NSLP, which strikes me as a huge deployment issue for new NSLPs. > > 2) we keep NAT intermediaries (probably when the > functionality is focused > to NATs only, this might help to get a less complex solution, > because you > do not need to think about general intermediaries. the solution might be less complex to describe, but the bad implications for C mode functionality are just as severe. r. > > > Marcus > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 09:56:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20084 for ; Thu, 29 Jan 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 1AmDaN-0005Og-HN for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 09:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TEu3WL020742 for nsis-archive@odin.ietf.org; Thu, 29 Jan 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 1AmDaM-0005OR-Rz; Thu, 29 Jan 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 1AmDZk-0005MM-24 for nsis@optimus.ietf.org; Thu, 29 Jan 2004 09:55: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 JAA20074 for ; Thu, 29 Jan 2004 09:55:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDZf-0005aA-00 for nsis@ietf.org; Thu, 29 Jan 2004 09:55:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDYi-0005VL-00 for nsis@ietf.org; Thu, 29 Jan 2004 09:54:21 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AmDXp-0005Ky-00 for nsis@ietf.org; Thu, 29 Jan 2004 09:53:25 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 14:52:45 -0000 Message-ID: From: "Hancock, Robert" To: "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Thu, 29 Jan 2004 14:52:51 -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.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 all, a clarification to the clarification: > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > figure 1 tries to describe the two options graphically: [slightly redrawn to avoid line breaks] > > Host A NAT Box Host B > NAT/FW--NSLP X--QoS NSLP--NAT/FW NSLP--QoS NSLP--NAT/FW > NSLP NTL NTLP NTLP NTLP NSLP > NTLP NE1 NE2 NE3 NE4 NE5 > > Figure 1: Signaling message flow > > if we want to signal an NSLP (e.g., NAT/FW) which is sparsely > distributed > along the path (i.e., only a few devices are NATs/Firewalls > compared to QoS > NSLP - hopefully) then there are two possible cases: > > a) skip NSLPs which do not implement the desired NSLP (in our > example the > end host is interested in signaling a NAT/FW NSLP) > (possible improvement to get rid of the nasty intermediaries) > > for figure 1 this would mean that Host A addresses the > message to NE 3 (the > nat box). discovery would have to skip NE 1 and NE 2 since > they have nothing > todo with nat/firewall signaling. > > b) incept and process signaling message at every intermediate node > (current proposal in the gimps draft) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not really? see below > > for figure 1 this would mean that the message is addressed > towards NE 1, > again processed by NE 2 and finally by NE 3 which is the NAT > box and so on. > what (i hope) actually happens (in the current draft) is that *any* D mode message from Host-A is given the destination address of NE5. In D mode, messages are never addressed to NE1 or NE3. all these messages will be seen (to some extent) at the GIMPS layer of all intermediate nodes (although 'seen' may mean no more than 'is ignored by the RAO processing rules which GIMPS has configured locally'.) which address Host A later knows (e.g. for a C mode connection) is *entirely* dependent on how much e.g. NE1 or NE2 decide they want to take part in the signalling for that flow and signalling application. both scenarios (a) and (b) are possible; in fact, I would say (a) is more likely than (b), but what actually happens is determined by policy. > if you establish, for example, a tcp connection between > neighboring nodes > (NE 2 and NE 3) then you can certainly reuse more transport layer > connections (and security associations) than in case (a) > where you establish > a new transport layer connection between end hosts (e.g., > Host A) and NE 3. this is quite true. whether this is a good idea depends strongly on a more detailed scalability analysis (see previous email to marcus). there are architectural objections to doing this so we need some way to balance this against any scalability gain. cheers, r. > > ciao > hannes > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: Thursday, January 29, 2004 9:41 AM > > To: Hancock, Robert; Nsis (E-mail) > > Subject: Re: [NSIS] GIMPS connection mode and intermediaries > > > > > > Robert, > > > > The NAT case is flawed and there is a third case for > > intermediaries. See > > inline. > > > > [...] > > > > Case c) is the use of intermediaries due to scalability > > problems of the > > C-mode. This specifically holds for NAT FW NSLP, but also for > > other sparsly > > deployed NSLPs. > > > > In the NAT/firewall NSLP case with C-mode we would > > realistically end-up > > with one connection per flow. > > This is because in most > > realistic cases at > > the beginning and the end of a path some NATs and firewalls > > are sitting, > > but non in the middle of the Internet. > > So assuming that each flow > > originating at one place is very diverse in which direction > > it goes, there > > is basically a C-mode NTLP connection per-flow. Plain GIMPS > > nodes would > > help with this problem. > > > > > (b) For the NAT case, rather than translating the content > of C-mode > > > messages as they go backwards and forwards through the NAT, we > > > should require that the GIMPS instances in the NSLP peers discover > > > during initial message exchanges that a NAT is present and what > > > it will do to packet headers; GIMPS then includes the pre- and > > > post-translation flow-ids in C-mode messages, invisibly > for the NAT. > > > > > > Host A ---- NSLP ------- NAT ------- NSLP ----- Host B > > > NTLP NTLP > > > NE1 NE2 > > > > > > C mode messages from NE1 to NE2 would say, at the GIMPS > level, "this > > > is a message about a flow which I see as being defined by > flow-id-1 > > > but you see as being about flow-id-2". This approach was mentioned > > > in the past at various meetings and is also hinted at in the NATFW > > > drafts, but has not been intensively discussed. > > > [Note: for the purpose of this discussion, it doesn't > really matter > > > if the NAT is GIMPS aware or not. Either way, we are saying that > > > once GIMPS discovery is complete and C-mode is being used, the NAT > > > has nothing to do with the payloads of signalling messages.] > > > > > > > > > this does not work. > > > > If the NAT is NTLP unaware it will naturally change the IP > > address and > > potentially even the port numbers of the transport protocol > > used between > > the NTLP peers. So it allows to get NTLP signaling through. > > The other end > > would most likely be able to detect that there is a NAT, if > NTLP has > > information about it last peer included. But the change of > > the flow-id > > (data stream we are signalling for) is unpredictable. > > > > And it does matter whether the NAT is GIMPS aware or not. > > > > I see 2 solutions > > 1) we forget that GIMPS is carrying flow-information. This > > implies that NAT > > must be NSLP away and you can avoid the intermediaries. > > > > 2) we keep NAT intermediaries (probably when the > > functionality is focused > > to NATs only, this might help to get a less complex solution, > > because you > > do not need to think about general intermediaries. > > > > > > Marcus > > > > _______________________________________________ > > 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 Jan 29 10:22:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23842 for ; Thu, 29 Jan 2004 10:22: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 1AmDzW-0006NP-Ak for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 10:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFM29D024490 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 10: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 1AmDzV-0006Mf-HQ; Thu, 29 Jan 2004 10: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 1AmDyx-0005vv-Ex for nsis@optimus.ietf.org; Thu, 29 Jan 2004 10:21:27 -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 KAA23603 for ; Thu, 29 Jan 2004 10:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDyv-00026P-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:21:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDy1-0001zR-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:20:30 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AmDxA-0001mP-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:19:36 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0TFJ5N8014912 for ; Thu, 29 Jan 2004 16:19:05 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0TFJ1aE014904 for ; Thu, 29 Jan 2004 16:19:01 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0TFJ0N8014903; Thu, 29 Jan 2004 16:19:01 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6C351FD0E5; Thu, 29 Jan 2004 16:19:00 +0100 (CET) Date: Thu, 29 Jan 2004 16:19:00 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Message-ID: <114764212.1075393140@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 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 >> In the NAT/firewall NSLP case with C-mode we would >> realistically end-up >> with one connection per flow. This is because in most >> realistic cases at >> the beginning and the end of a path some NATs and firewalls >> are sitting, >> but non in the middle of the Internet. So assuming that each flow >> originating at one place is very diverse in which direction >> it goes, there >> is basically a C-mode NTLP connection per-flow. > > i think the strictly correct statement is 'one C mode connection > per pair of communicating middleboxes'. if the Internet traffic is > dominated by e.g. people running kazaa behind NATting-ADSL routers > I agree this would end up as one C mode/flow; N communications > between two corporate sites would probably need only one C mode > connection. > > of course, the scalability issue is one we always have to worry > about. my naive instinct is that the first case will apply mainly > to little NATs, and big NATs are mainly covered by the second, > but the dial-access (or mobile access) cases are probably hard. > I don't see the problem with the home networking, because they do not have that many connections running. So it really almost end-to-end. I see the problem more in the number of c-mode endpoints on a NAT for lets say a big company network, where the NAT is handling a high number of communications with different partner -> different NATs. Or the GPRS networks (where many run NATs) and having a large number of flows. > > in any case, the underlying question is whether the state > involved in a C mode connection is much more, much less, or > about the same as required to manage the NAT processing for > that flow itself. do you think it could be more? > I assume this depends on the used c-mode transport protocol, so for example TCP end-point state. For the NAT typically not the state but the fast search in the state tables is the problem. >> Plain GIMPS >> nodes would >> help with this problem. > > could you elaborate? > If there are GIMPS-aware nodes in the network, the chances are higher that you can reuse the GIMPS transport protocol for parts of the signaling path. [...] > 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? > *) a GIMPS aware NAT should change the flow ID in a way to > be defined by the GIMPS spec, for which at the moment I > see several possibilities: > - use existing bindings if they apply to that flow > - if there is no applicable existing binding, create one, or This one of these 2 actions are performed in the NAT/FW NSLP spec 00 (no problem to move them to NTLP > - if there is no applicable existing binding, return an error > to the peer (this would be one of a large class of "I couldn't > handle that flow ID errors") > >> >> And it does matter whether the NAT is GIMPS aware or not. > > it matters to the GIMPS D mode implementation. it should not > matter to the overall function split between C and D mode, > and it should not matter to NSLPs. > Sure, I was not referring to any d-mode at all in that mail. D-mode might be a prblem anyway when you run an "intelligent" NAT. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 10:48:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26607 for ; Thu, 29 Jan 2004 10:48: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 1AmEOf-0000VZ-DU for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 10:48:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFm18I001926 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 10:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEOe-0000Ux-Sn; Thu, 29 Jan 2004 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmENz-0000TF-4p for nsis@optimus.ietf.org; Thu, 29 Jan 2004 10:47: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 KAA26410 for ; Thu, 29 Jan 2004 10:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmENw-0006Pn-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmELz-0005uR-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:45:17 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AmEJs-0005E3-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:43:04 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 15:42:33 -0000 Message-ID: From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Date: Thu, 29 Jan 2004 15:42:37 -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 marcus, > > I don't see the problem with the home networking, because > they do not have > that many connections running. So it really almost > end-to-end. sure > I see the > problem more in the number of c-mode endpoints on a NAT for > lets say a big > company network, where the NAT is handling a high number of > communications > with different partner -> different NATs. but will there be lots of different partners or just a few? if there's just a few then that's just a few C mode connections. (maybe a situation with 'many partners' would be remote users with a VPN, but the VPN state will be huge compared to C mode state. > Or the GPRS > networks (where many > run NATs) and having a large number of flows. this is the most problematic case that i see. > > > > > in any case, the underlying question is whether the state > > involved in a C mode connection is much more, much less, or > > about the same as required to manage the NAT processing for > > that flow itself. do you think it could be more? > > > > I assume this depends on the used c-mode transport protocol, > so for example > TCP end-point state. For the NAT typically not the state but the fast > search in the state tables is the problem. for an outgoing message it should be no harder (once the search has been done) to look up the outgoing C mode connection 'handle' (or whatever) directly. for incoming messages, there are issues with simpleminded use of select() or poll(), but these can be handled with more sophisticated APIs (Henning's group have done experiments with this). there is no answer to this question without more detailed specification and some experiments. > > > >> Plain GIMPS > >> nodes would > >> help with this problem. > > > > could you elaborate? > > > > If there are GIMPS-aware nodes in the network, the chances > are higher that > you can reuse the GIMPS transport protocol for parts of the > signaling path. ok, as in Hannes' mail. > [...] > > > 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). > > > > *) a GIMPS aware NAT should change the flow ID in a way to > > be defined by the GIMPS spec, for which at the moment I > > see several possibilities: > > - use existing bindings if they apply to that flow > > - if there is no applicable existing binding, create one, or > > This one of these 2 actions are performed in the NAT/FW NSLP > spec 00 (no > problem to move them to NTLP this is where some alignment is needed. this function is about NATFW management but the need for it seems to be common to all NSLPs. > > > - if there is no applicable existing binding, return an error > > to the peer (this would be one of a large class of "I couldn't > > handle that flow ID errors") > > > >> > >> And it does matter whether the NAT is GIMPS aware or not. > > > > it matters to the GIMPS D mode implementation. it should not > > matter to the overall function split between C and D mode, > > and it should not matter to NSLPs. > > > > Sure, I was not referring to any d-mode at all in that mail. > D-mode might be a prblem anyway when you run an "intelligent" NAT. > > Marcus > r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 10:55:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27854 for ; Thu, 29 Jan 2004 10:55: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 1AmEVU-0000wB-0Y for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 10:55:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFt35f003571 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 10:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEVS-0000v8-7o; Thu, 29 Jan 2004 10:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEUy-0000qa-1M for nsis@optimus.ietf.org; Thu, 29 Jan 2004 10:54: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 KAA27680 for ; Thu, 29 Jan 2004 10:54:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEUv-0000NF-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:54:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmETV-0007nh-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:53:02 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AmERw-0007Jl-00 for nsis@ietf.org; Thu, 29 Jan 2004 10:51:24 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jan 2004 15:50:50 -0000 Message-ID: From: "Hancock, Robert" To: "Nsis (E-mail)" Date: Thu, 29 Jan 2004 15:50: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 Subject: [NSIS] GIMPS connection mode and network re-routing Sender: nsis-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, This is the second of two mails which proposes the elimination of some options in the GIMPS design space; it's intended to find out if there is any objection to removing these options (i.e. are people happy to live with the resulting limitations on GIMPS functionality). All of the following refers to http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt (mainly section 5.3). BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured UDP transport) and a connection ("C") mode (which can use connection oriented transport protocols like TCP, SCTP, DCCP and channel security mechanisms like IPsec, TLS - details TBD). C-mode is supposed to be used between adjacent peers for a given signalling application, where that signalling application needs industrial-strength transport or security services. [==== from this point on, this mail starts to look different from the previous one =========] Because of the way that the 'component' connection mode protocols have (quite reasonably) been designed, it is practically impossible to run a C-mode session except between the (fixed, physical) IP addresses of the adjacent GIMPS peers. Therefore, these addresses have to be discovered (in one procedure) before they are used in C-mode messages. The consequence of this is that, once you have started using C-mode, downstream signalling messages will not be sensitive to route changes. Instead, you have to use other techniques (like looking at routing protocols; there are many other possibilities listed in the framework) to find out that a route change has taken place, and then repeat the initial discovery. If nothing else, you can just repeat the discovery process periodically. There is an (ugly) alternative to this, which is essentially to use a sort of C-mode-inside-D-mode encapsulation (5.3.4 of the GIMPS draft). This shows that it is logically possible to get some of the benefits of C-mode and still have automatic route change detection; but I really don't like this approach in practice (although it is kind of interesting to think about). 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. Comments aree, as always, welcome, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jan 29 12:35:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03563 for ; Thu, 29 Jan 2004 12:35: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 1AmG4F-0008JK-2O for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 12:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THZ2Av031909 for nsis-archive@odin.ietf.org; Thu, 29 Jan 2004 12:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG4E-0008IW-Ls; Thu, 29 Jan 2004 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG3i-0008HX-Vk for nsis@optimus.ietf.org; Thu, 29 Jan 2004 12:34: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 MAA03518 for ; Thu, 29 Jan 2004 12:34:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmG3h-0005VY-00 for nsis@ietf.org; Thu, 29 Jan 2004 12:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmG2o-0005Pm-00 for nsis@ietf.org; Thu, 29 Jan 2004 12:33:34 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AmG2M-0005Iy-00 for nsis@ietf.org; Thu, 29 Jan 2004 12:33:07 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0THWUN8030368 for ; Thu, 29 Jan 2004 18:32:31 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0THWUko030366 for ; Thu, 29 Jan 2004 18:32:30 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0THWTN8030365; Thu, 29 Jan 2004 18:32:30 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D7FECFE9C6; Thu, 29 Jan 2004 18:32:28 +0100 (CET) Date: Thu, 29 Jan 2004 18:32:28 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" Cc: "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and intermediaries Message-ID: <122773388.1075401148@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 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 >> I see the >> problem more in the number of c-mode endpoints on a NAT for >> lets say a big >> company network, where the NAT is handling a high number of >> communications >> with different partner -> different NATs. > > but will there be lots of different partners or just a few? I assume many different ones. > if there's just a few then that's just a few C mode connections. > (maybe a situation with 'many partners' would be remote > users with a VPN, but the VPN state will be huge compared to > C mode state. > I was more thinking about with how many partners is bigger company like yours having telefon conversation outside the company. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jan 30 03:04:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01536 for ; Fri, 30 Jan 2004 03: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 1AmTdD-00036o-2P for nsis-archive@odin.ietf.org; Fri, 30 Jan 2004 03:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U842tX011934 for nsis-archive@odin.ietf.org; Fri, 30 Jan 2004 03: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 1AmTdB-00036N-Td; Fri, 30 Jan 2004 03: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 1AmTd9-000369-Ds for nsis@optimus.ietf.org; Fri, 30 Jan 2004 03:03: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 DAA01533 for ; Fri, 30 Jan 2004 03:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmTd5-0000cg-00 for nsis@ietf.org; Fri, 30 Jan 2004 03:03:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmTcD-0000Wy-00 for nsis@ietf.org; Fri, 30 Jan 2004 03:03:02 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AmTbs-0000PN-00 for nsis@ietf.org; Fri, 30 Jan 2004 03:02:40 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Fri, 30 Jan 2004 09:00:58 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Jan 2004 09:00:57 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB7A5@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] GIMPS connection mode and network re-routing Date: Fri, 30 Jan 2004 09:00:55 +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 Robert,=20 |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. Absolutely correct. My personal preference is to separate route=20 change detections (D mode, high frequency or asynchronus, network=20 specific, probably no AAA requirements) from service state=20 maintenance (C mode, medium frequency, session specific,=20 high security requirements). Of course both must be linked.=20 I didn't analyse details. If anybody is aware of studies=20 comparing above attempt with an RSVP like (where both functions=20 are combined in a single protocol), I'd be happy for a url. Regards, R=FCdiger R=FCdiger Geib T-Systems Systems Integration Senior Expert Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 937-2138 http://www.t-systems.com =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jan 30 04:58:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05185 for ; Fri, 30 Jan 2004 04:58: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 1AmVPa-0002D0-18 for nsis-archive@odin.ietf.org; Fri, 30 Jan 2004 04:58:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U9w5iJ008476 for nsis-archive@odin.ietf.org; Fri, 30 Jan 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmVPW-0002CD-Av; Fri, 30 Jan 2004 04:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmVOW-0002BD-Uo for nsis@optimus.ietf.org; Fri, 30 Jan 2004 04: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 EAA05168 for ; Fri, 30 Jan 2004 04:56:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmVOT-0005tr-00 for nsis@ietf.org; Fri, 30 Jan 2004 04:56:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmVNZ-0005o7-00 for nsis@ietf.org; Fri, 30 Jan 2004 04:56:01 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AmVMe-0005bb-00 for nsis@ietf.org; Fri, 30 Jan 2004 04:55:04 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0U9sUN8059654 for ; Fri, 30 Jan 2004 10:54:30 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0U9ol25058800 for ; Fri, 30 Jan 2004 10:50:47 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0U9olN8058799; Fri, 30 Jan 2004 10:50:47 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C6C8EFF974; Fri, 30 Jan 2004 10:50:46 +0100 (CET) Date: Fri, 30 Jan 2004 10:50:46 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "Nsis (E-mail)" Subject: Re: [NSIS] GIMPS connection mode and network re-routing Message-ID: <5248747.1075459846@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 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 > There is an (ugly) alternative to this, which is essentially to use > a sort of C-mode-inside-D-mode encapsulation (5.3.4 of the GIMPS > draft). This shows that it is logically possible to get some of > the benefits of C-mode and still have automatic route change > detection; but I really don't like this approach in practice > (although it is kind of interesting to think about). > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jan 30 11:38:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25945 for ; Fri, 30 Jan 2004 11:38: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 1Ambec-0007h8-57 for nsis-archive@odin.ietf.org; Fri, 30 Jan 2004 11:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGc14F029558 for nsis-archive@odin.ietf.org; Fri, 30 Jan 2004 11:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ambeb-0007ge-Dq; Fri, 30 Jan 2004 11:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ambdx-0007YF-TA for nsis@optimus.ietf.org; Fri, 30 Jan 2004 11:37: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 LAA25832 for ; Fri, 30 Jan 2004 11:37:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ambdw-0004G6-00 for nsis@ietf.org; Fri, 30 Jan 2004 11:37:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ambcy-00046w-00 for nsis@ietf.org; Fri, 30 Jan 2004 11:36:21 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1Ambc5-0003p3-00 for nsis@ietf.org; Fri, 30 Jan 2004 11:35:26 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Jan 2004 16:34:42 -0000 Message-ID: From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , "Nsis (E-mail)" Subject: RE: [NSIS] GIMPS connection mode and network re-routing Date: Fri, 30 Jan 2004 16:34: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 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